Xusheng Xiao, Tao Xie North Carolina State University Amit Paradkar IBM T.J. Watson Research Center

 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)

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

 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 NL Functional Requirement System Implementation NL ACPs conformance

Properties Functional Requirement Automated Extraction of ACPs Non-Functional Requirement System Implementation Verification and Testing Tools Correct Specification Correct Enforcement Detected Issues Automated Validation against ACPs Extracted ACPs

 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(eXtensible Access Control Markup Language)

OASIS standard XML-based language to specify ACPs HCP edit patient.account Organization for the Advancement of Structured Information Standards “The Health Care Personnel (HCP) does not have the ability to edit the patient's account.”

 Specify ACPs directly in XACML  via XML editor  Specify ACPs using GUI tool  via NIST/NCSU ACPT tool

Contact: Vincent Hu  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

 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.

 Manually inspect NL documents and identify sentences describing ACPs Specify via XML Editor Non-Functional Requirements Formal ACPs Functional Requirements Specify via GUI Tool

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

 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

 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 The patient views access log. ex.

 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 editor used in UC 4 of iTrust use cases actually refers to all users. ex.

 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

 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)

Functional Requirement Non-function Requirements ACP Extraction Formal ACPs ACP Extraction Deny ACPs Resource Access Information Combined ACPs Action-step Extraction Automatic Validation Detected Inconsistencies

Functional Requirement ACP Extraction Deny ACPs Resource Access Information Action-step Extraction Permit ACPs Combined ACPs

 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.

 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.

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

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

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

 Part-Of-Speech Tag (POS)  Phrase Identification  Grammatical Functions Active Voice ACP 1: An HCP can view patient’s account. ACP2: An HCP is disallowed to change the patient’s account. NPVGPNP Main Verb GroupSubjectObject Passive Voice to-infinitive phrase

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

 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.

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

 Address TC2 Negative Meaning Implicitness  Negative expression  “not” in subject:  “not” in verb group:  Negative meaning words in main verb group 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.

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

 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. ex.

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

 Synthesize a corresponding policy rule in XACML in input formats for policy modeling and testing tools such as the NIST/NCSU ACPT tool … Access Control Policy Effect Subject Action Resource HCP update patient’s account Deny HCP update patient.account

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

 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

 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

 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

 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”

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

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

 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 Action Actor Type Parameter Patient OUTPUT - view Access log  Subject: patient  Action: view  Resource: access log

 Validate resource access information from each action step against specified/extracted ACPs  Report detected inconsistencies

 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

 Prototype system implemented for Text2Policy  Subject: iTrust open source project  ts ts  448 use-case sentences (37 use cases)  10 non-functional-requirement sentences  8 constraint sentences  Total lines of code: ▪ source: ▪ unittests: ▪ Httptests: 3541  Subject: collected NL ACP rules  115 rules  From 18 sources (published papers, public websites, iTrust)

 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?

 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%

 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 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.”

 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 " message to the adverse event reporter to gain more information about the report.”

 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

 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!