Automatic Construction and Validation of Access Control Policies from Natural-Language Documents

1. Xusheng Xiao, Tao Xie North Carolina State University xxiao2,txie@ncsu.edu Automatic Construction and Validation of Access Control Policies from Natural-Language Documents AmitParadkar IBM T.J. Watson Research Center paradkar@us.ibm.com

2. Access Control • Access control is one of the most widely used privacy and security mechanisms • used to prevent security vulnerabilities by controlling access to resources • Access control is often governed by security policies called Access Control Policies (ACP)

3. Access Control Policy (ACP) • ACP includes rules to control which principalshave access to which resources • A policy rule includes four elements • subject – HCP • action - edit • resource - patient's account • effect - deny ex. “The Health Care Personnel (HCP)does not have the ability to edit the patient's account.”

4. Motivation NL Functional Requirement NL ACPs • How to ensure correct specification of ACPs? • ACPs may be complex/error-prone to specify • ACPs are often written in natural language (NL) • How to ensure correct enforcement of ACPs? • Gap btw ACPs (domain concepts) and system implementation (programming concepts) • Functional requirements bridge the gap but are often written in NL System Implementation conformance

5. Proposed Solution: Ensuring Correct ACP Specification and Enforcement Correct Specification Properties Functional Requirement Non-Functional Requirement Automated Extraction of ACPs Verification and Testing Tools Extracted ACPs Detected Issues Automated Validation against ACPs System Implementation Correct Enforcement

6. Background: Correct Specification • How to ensure correct specification of ACPs? • ACPs may be complex/error-prone to specify • Existing approaches on ACP testing and verification • require ACPs to be formally specified, such as in XACML(eXtensibleAccess Control Markup Language)

7. XACML (eXtensible Access Control Markup Language) <Rule Effect=“deny"RuleId="rule-1"> <Target> <Subjects> <Subject> <SubjectMatchMatchId="string-equal"> <AttrValue>HCP</AttrValue> <SubjectAttrDesignatorAttrId="subject:role"/> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatchMatchId="string-equal"> <AttrValue>edit</AttrValue> <ResourceAttrDesignatorAttrId="resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatchMatchId="string-equal"> <AttrValueDataType="string">patient.account</AttrValue> <ActionAttriDesignatorAttrId="action-id"/> </ActionMatch> </Action> </Actions> </Target> </Rule> OASIS standard XML-based language to specify ACPs “The Health Care Personnel (HCP)does not have the ability to edit the patient's account.” Organization for the Advancement of Structured Information Standards

8. Specifying XACML • Specify ACPs directly in XACML • via XML editor • Specify ACPs using GUI tool • via NIST/NCSU ACPT tool

9. NIST/NCSU Access Control Policy Test Tool (ACPT) • Model Construction • specify and combine access control (AC) models (e.g., Multi-Level, RBAC ) • Model Verification • verify AC models against given properties • Implementation Testing • test AC implementation with NIST ACTS • XACML Synthesis Contact: Vincent Huvhu@nist.gov http://csrc.nist.gov/groups/SNS/acpt/acpt-beta.htm

10. ACP in NL Documents • In practice, ACPs are often written in natural language (NL), especially in legacy systems • Supposed to be written in non-functional requirements (e.g., security requirement) • But often buried inside functional requirements …… Patient MID should be the number assigned when the patient is added to the system and cannot be edited. The HCP does not have the ability to edit the patient's security question and password. ……. ( UC1 of iTrust use cases) ex.

11. Manual Extraction of ACP from NL Documents Non-Functional Requirements Functional Requirements • Manually inspect NL documents and identify sentences describing ACPs Specify via XML Editor Formal ACPs Specify via GUI Tool

12. Example Extraction of ACPs “The Health Care Personnel (HCP)does not have the ability to edit the patient's account.” Access Control Policy Subject Action Resource Effect HCP deny patient.account edit ACP Extraction

13. Issues in Manual Extraction of ACPs • NL documents, such as functional requirements, could be large in size, only a small portion describes ACPs • iTrust requirement has 464 sentences • only 10 sentences describe ACPs • Manual extraction of ACPs Very tedious and error-prone

14. Functional Requirements – Use Cases • Scenario-based functional requirements: • use case: a sequence of action steps, describing • principals access different resources for achieving some functionalities • Resource access information: • subject – patient • action – view • resource – access log ex. The patientviewsaccess log.

15. Inconsistencies in Functional Requirements • Manual validation to detect inconsistencies • Action steps inconsistent with formalized/extracted ACPs • Inconsistent names used for referring to the same entity (e.g., user) across different use cases ex. editorused in UC 4 of iTrust use cases actually refers to all users.

16. Problems Caused by Inconsistencies • Action-step inconsistencies cause problems for enforcing policies • Mismatch btw ACP entities and their counterparts in functional requirements • user used in ACP vs. editor used in use cases • If inconsistencies not resolved at requirement stage, cost grows much higher for fixing them in later stages

17. Our approach – Text2Policy • Ensure correct specification • automatically extract ACPs from NL documents • Ensure correct enforcement • automatically extract action steps from NL use cases • Novel Natural Language Processing (NLP) techniques • syntactic analysis: extract syntactic structure (noun group, verb group) • semantic analysis: extract semantic meaning of elements (e.g., subject, action, resource, and effect)

18. High-level Overview of Text2Policy Functional Requirement Non-function Requirements ACP Extraction Formal ACPs Combined ACPs ACP Extraction Deny ACPs Resource Access Information Automatic Validation Action-step Extraction Detected Inconsistencies

19. High-level Overview of Text2Policy – in the Absence of Non-functional Requirement Functional Requirement Combined ACPs ACP Extraction Deny ACPs Resource Access Information Action-step Extraction Permit ACPs

20. Technical Challenges (TC) in Policy Extraction • TC1: Semantic Structure Variance • different ways to specify the same rule • TC2: Negative Meaning Implicitness • verb could have negative meaning ACP 1: An HCP cannot change patient’s account. ACP2: An HCP is disallowed to change patient’s account.

21. Technical Challenges in Action-step Extraction • TC3: Anaphora • TC4: Transitive Subject • TC5: Perspective Variance These challenges apply when extracting ACPs from Functional Requirements Step 1: An HCP creates an account. Step 2:He edits the account. Step 3: The system updates the account. Step 4: The system displays the updated account. HCP HCP views the updated account.

22. Overview of Text2Policy ACP Extraction Action-step Extraction Use Cases (UC) Non-Functional Reqs ACP Linguistic Analysis Use Case Linguistic Analysis Use Cases (UC) Model Construction Action Steps ACP Model Resource Access Extraction Resource Access Information Specification (e.g., XACML) Transformation

23. Overview of Text2Policy ACP Extraction Action-step Extraction Use Cases (UC) Non-Functional Reqs ACP Linguistic Analysis Use Case Linguistic Analysis Use Cases (UC) Model Construction Action Steps ACP Model Resource Access Extraction Resource Access Information Specification (e.g., XACML) Transformation

24. ACP Linguistic Analysis Words with POS tags, Phrases, Grammatical Functions Shallow Parsing NL Text Semantic Pattern Matching Phrases marked with annotations Words associated with semantic classes Domain Dictionary

25. Shallow Parsing • Part-Of-Speech Tag (POS) • Phrase Identification • Grammatical Functions to-infinitive phrase NP VG PNP Active Voice ACP 1: An HCP can view patient’s account. ACP2: An HCP is disallowed to change the patient’s account. Passive Voice Subject Main Verb Group Object

26. Semantic Pattern Matching • Address TC1 Semantic Structure Variance • Compose pattern based on grammatical function ex. An HCP is disallowed to change the patient’s account. passive voice to-infinitive phrase followed by

27. Semantic Patterns • Modal Verb in Main Verb Group • Passive Voice followed by To-infinitive Phrase • Access Expression An HCP can view the patient’s account. An admin should not update patients’ password. An HCP is disallowed to update patient’s password. An HCP is allowed to view patient’s account. An HCP has read access to patient’s account. An patient’s account is accessible to an HCP.

28. Domain Dictionary • Used to associate verbs with semantic class • Include synonyms (collected from WordNet) ex. “prohibit, disallow” -> NEGATIVE “edit, change, update” -> UPDATE

29. Negative Meaning Inference • Address TC2 Negative Meaning Implicitness • Negative expression • “not” in subject: • “not” in verb group: • Negative meaning words in main verb group ex. No HCP can edit patient’s account. ex. HCP can not edit patient’s account. HCP can never edit patient’s account. ex. An HCP is disallowed to change the patient’s account.

30. Overview of Text2Policy ACP Extraction Action-step Extraction Use Cases (UC) Non-Functional Reqs ACP Linguistic Analysis Use Case Linguistic Analysis Use Cases (UC) Model Construction Action Steps ACP Model Resource Access Extraction Resource Access Information Specification (e.g., XACML) Transformation

31. Model Construction ex. • Identify subject, action, and resource: • Subject: HCP • Action: change • Resource: patient’s account • Infer effect: • Negative Expression: none • Negative Verb: disallow • Inferred Effect: deny An HCP is disallowed to change the patient’s account.

32. Overview of Text2Policy ACP Extraction Action-step Extraction Use Cases (UC) Non-Functional Reqs ACP Linguistic Analysis Use Case Linguistic Analysis Use Cases (UC) Model Construction Action Steps ACP Model Resource Access Extraction Resource Access Information Specification (e.g., XACML) Transformation

33. Transformation <Rule Effect="Deny" RuleId="rule-1"> <Target> <Subjects> <Subject> <SubjectMatchMatchId="string-equal"> <AttrValue>HCP</AttrValue> <SubjectAttrDesignatorAttrId="subject:role"/> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatchMatchId="string-equal"> <AttrValue>update</AttrValue> <ResourceAttrDesignatorAttrId="resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatchMatchId="string-equal"> <AttrValueDataType="string">patient.account</AttrValue> <ActionAttriDesignatorAttrId="action-id"/> </ActionMatch> </Action> </Actions> </Target> </Rule> • Synthesize a corresponding policy rule in XACML in input formats for policy modeling and testing tools such as the NIST/NCSU ACPT tool <Policy PolicyId="ExamplePolicy” RuleCombiningAlgId=“…”> <Target/> <Rule RuleId=”rule-1" Effect="Permit"> <Target> …</Target> </Rule> </Policy> Access Control Policy Subject Action Resource Effect update patient’s account Deny HCP

34. Overview of Text2Policy ACP Extraction Action-step Extraction Use Cases (UC) Non-Functional Reqs ACP Linguistic Analysis Use Case Linguistic Analysis Use Cases (UC) Model Construction Action Steps ACP Model Resource Access Extraction Resource Access Information Specification (e.g., XACML) Transformation

35. Use Case Linguistic Analysis • We adapt the linguistic analysis engine from our previous approach [DSN’09] with additional techniques to address TC3, TC4, and TC5. • The linguistic analysis engine is based on shallow parsing

36. Anaphora Resolution • Address TC3 Anaphora • Resolve Anaphora • adapt anaphora algorithm from “Anaphora for everyone: Pronominal anaphora resolution without a parser” [COLING’96] Step 1: An HCP creates an account. Step 2:He edits the patient’s account. HCP

37. Subject Flow Tracking • Address TC4 Transitive Subject • Apply data flow of non-system subject: Step 1: The HCP edits the account. Step 2: The system updates the account. Tracking Only system as subject adding HCP as subject

38. Perspective Conversion • Address TC5 Perspective Variance • Apply data flow of non-system subject: Step 1: The HCP edits the account. Step 2: The system shows the updated account. Tracking Only system as subject and action is to output Converting to “HCP views the updated account”

39. Example Use Case Action Step The patient views access log. Action Step Type Actor Parameter Patient Access log OUTPUT - view Use Case Linguistic Analysis

40. Overview of Text2Policy ACP Extraction Action-step Extraction Use Cases (UC) Non-Functional Reqs ACP Linguistic Analysis Use Case Linguistic Analysis Use Cases (UC) Model Construction Action Steps ACP Model Resource Access Extraction Resource Access Information Specification (e.g., XACML) Transformation

41. Resource Access Extraction • Extract resource access information from extracted action steps • Apply union on resource access information of extracted action steps to form permit ACP rules • Permit rules + Deny rules  Combined rules • Subject: patient • Action: view • Resource: access log Action Type Actor Parameter Patient Access log OUTPUT - view

42. Validation of Action Steps against ACPs • Validate resource access information from each action step against specified/extracted ACPs • Report detected inconsistencies

43. Summary: Benefits of Text2Policy • Extracted ACPs • serve as initial version for policy authors to improve • validated with specified ACPs for completeness and correctness • Extracted action steps • detect inconsistencies with specified/extracted ACPs • extract ACPs from functional requirements • locate policy enforcement points

44. Evaluation – Subject • Prototype system implemented for Text2Policy • Subject: iTrust open source project • http://agile.csc.ncsu.edu/iTrust/wiki/doku.php?id=requirements • 448 use-case sentences (37 use cases) • 10 non-functional-requirement sentences • 8 constraint sentences • Total lines of code: 28514 • source: 13528 • unittests: 11445 • Httptests: 3541 • Subject: collected NL ACP rules • 115 rules • From 18 sources (published papers, public websites, iTrust)

45. Research Questions • RQ1: How effectively does Text2Policy identify sentences describing ACP rules in NL documents? • RQ2: How effectively does Text2Policy extract ACP rules from sentences describing ACP rules? • RQ3: How effectively does Text2Policy extract action steps from use cases?

46. Evaluation – RQ1 ACP Sentence Identification • Apply Text2Policy to identify sentences describing deny ACP rules in iTrust requirements • 10 sentences among 448 sentences describing deny ACP rules • 2 false negative • Ex. “The administrator is not allowed to modify the hospital ID number in an existing entry.” • 0 false positive • precision: 100% • recall: 80%

47. Evaluation –RQ2 Accuracy of Policy Extraction • Apply Text2Policy to extract ACP rules from collected NL ACP sentences • 115 sentences describing ACP rules • Successfully extract 106 ACP rules • Accuracy: 92.17% • Unsuccessful Ex. “Any subject with an e-mail name in the med.example.com domain can perform any action on any resource.” • Unsuccessful Ex. “A reviewer of a paper can resign the review of the paper, unless he has already appointed a sub-reviewer for the paper.”

48. Evaluation –RQ3 Accuracy of Action-Step Extraction • Apply Text2Policy to extract action steps from iTrust use cases • 438 sentences (excluding sentences describing ACP rules) • Successfully extract action steps from 367 sentences • Accuracy: 83.79% • Unsuccessful Ex. “The HCP must provide instructions, or else they cannot add the prescription.” • Unsuccessful Ex. “Upon reading the report, the public health agent can send a "fake email" message to the adverse event reporter to gain more information about the report.”

49. Conclusion • How to ensure correct specification of ACPs? • Extract ACPs from security requirements • Extract ACPs from functional requirements • Detect inconsistencies among ACPs • How to ensure correct enforcement of ACPs? • Extract action steps from functional requirements • Detect inconsistencies btw ACPs and action steps Text2Policy Automatic Construction and Validation of ACPs from NL Documents

50. Future Work • Improve Text2Policy prototype • Integrate Text2Policy to NIST/NCSU ACPT • Conditions in ACP rules • Ordering among ACP rules • Different application domains • Healthcare • Law statutes • NIST NVD (National Vulnerability Database) and CWE (Common Weakness Enumeration) • Mail lists • … • Collaborations are welcome!