View
218
Download
3
Category
Tags:
Preview:
Citation preview
Automatic Construction and Validation of Access Control Policies from Natural-
Language Documents
Xusheng Xiao, Tao XieNorth Carolina State
Universityxxiao2,txie@ncsu.edu
Amit ParadkarIBM T.J. Watson
Research Centerparadkar@us.ibm.com
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)
Access Control Policy (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.
Motivation 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 ImplementationNL ACPs
conformance
Proposed Solution: Ensuring Correct ACP Specification and Enforcement
Properties
Functional Requirement
AutomatedExtraction
of ACPs
Non-Functional Requirement
System Implementation
Verification and Testing Tools
Correct Specification
Correct Enforcement
DetectedIssues
AutomatedValidation
against ACPs
ExtractedACPs
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(eXtensible Access Control Markup Language)
XACML (eXtensible Access Control Markup Language)
OASIS standard XML-based
language to specify ACPs
<Rule Effect=“deny" RuleId="rule-1"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="string-equal">
<AttrValue>HCP</AttrValue> <SubjectAttrDesignator AttrId="subject:role"/> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="string-equal">
<AttrValue>edit</AttrValue> <ResourceAttrDesignator AttrId="resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="string-equal">
<AttrValue DataType="string">patient.account</AttrValue> <ActionAttriDesignator AttrId="action-id"/> </ActionMatch> </Action> </Actions> </Target> </Rule>
Organization for the Advancement of Structured Information Standards
“The Health Care Personnel (HCP) does not have the ability to edit the patient's account.”
Specifying XACML
Specify ACPs directly in XACML via XML editor
Specify ACPs using GUI tool via NIST/NCSU ACPT tool
NIST/NCSU Access Control Policy Test Tool (ACPT)
Contact: Vincent Hu vhu@nist.gov
http://csrc.nist.gov/groups/SNS/acpt/acpt-beta.htm
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
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.
Manual Extraction of ACP from NL Documents
Manually inspect NL documents and identify sentences describing ACPs
Specify via XML EditorNon-Functional
RequirementsFormalACPs
Functional Requirements
Specifyvia GUI Tool
Example Extraction of ACPs
ACP Extraction
Access Control Policy
EffectSubjec
t Action Resource
HCP editpatient.accoun
t
deny
“The Health Care Personnel (HCP) does not have the ability to edit the patient's account.”
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
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
The patient views access log.ex.
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 caseseditor used in UC 4 of iTrust use cases
actually refers to all users.
ex.
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
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)
High-level Overview of Text2Policy
FunctionalRequirement
Non-functionRequirements
ACPExtraction
Formal ACPs
ACPExtraction
DenyACPs
ResourceAccess
Information
Combined ACPs
Action-stepExtraction
Automatic Validation
DetectedInconsistencies
High-level Overview of Text2Policy – in the Absence of Non-functional Requirement
FunctionalRequirement
ACPExtraction
DenyACPs
ResourceAccess
Information
Action-stepExtraction
PermitACPs
Combined ACPs
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.
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.
Overview of Text2Policy
Non-Functional
Reqs
Specification (e.g., XACML)
Transformation
ACPLinguisti
c Analysis
Model Constructio
n
ACP Model
Resource Access
Extraction
Use Cases (UC)
Use Case Linguistic Analysis
ActionSteps
Resource Access
Information
Action-step Extraction
ACP Extraction
Use Cases (UC)
Overview of Text2Policy
Specification (e.g., XACML)
Transformation
ACPLinguisti
c Analysis
Model Constructio
n
ACP Model
Resource Access
Extraction
Use Cases (UC)
Use Case Linguistic Analysis
ActionSteps
Resource Access
Information
Action-step Extraction
ACP ExtractionNon-
Functional Reqs
Use Cases (UC)
ACP Linguistic Analysis
NL Text
Shallow Parsing
Words with POS tags, Phrases,
Grammatical Functions
Semantic Pattern
MatchingPhrases marked with annotations
Words associated with
semantic classes
DomainDictionar
y
Part-Of-Speech Tag (POS) Phrase Identification Grammatical Functions
Active Voice
Shallow Parsing
ACP 1: An HCP can view patient’s account.ACP2: An HCP is disallowed to change the patient’s account.
NP VG PNP
Main Verb Group
Subject ObjectPassive Voice
to-infinitive phrase
Semantic Pattern Matching
Address TC1 Semantic Structure Variance
Compose pattern based on grammatical function
An HCP is disallowed to change the patient’s account.
ex.
passive voice to-infinitive phrasefollowed by
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.
Domain Dictionary
Used to associate verbs with semantic class
Include synonyms (collected from WordNet)
“prohibit, disallow” -> NEGATIVE“edit, change, update” -> UPDATE
ex.
Negative Meaning Inference 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.
ex. An HCP is disallowed to change the patient’s account.
Overview of Text2Policy
Specification (e.g., XACML)
Transformation
ACPLinguisti
c Analysis
Model Constructio
n
ACP Model
Resource Access
Extraction
Use Cases (UC)
Use Case Linguistic Analysis
ActionSteps
Resource Access
Information
Action-step Extraction
ACP ExtractionNon-
Functional Reqs
Use Cases (UC)
Model Construction
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.
Overview of Text2Policy
Specification (e.g., XACML)
Transformation
ACPLinguisti
c Analysis
Model Constructio
n
ACP Model
Resource Access
Extraction
Use Cases (UC)
Use Case Linguistic Analysis
ActionSteps
Resource Access
Information
Action-step Extraction
ACP ExtractionNon-
Functional Reqs
Use Cases (UC)
Transformation
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
Effect
Subject Action Resourc
e
HCP update patient’s account Deny
<Rule Effect="Deny" RuleId="rule-1"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="string-equal"> <AttrValue>HCP</AttrValue> <SubjectAttrDesignator AttrId="subject:role"/> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="string-equal"> <AttrValue>update</AttrValue> <ResourceAttrDesignator AttrId="resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="string-equal"> <AttrValue DataType="string">patient.account</AttrValue> <ActionAttriDesignator AttrId="action-id"/> </ActionMatch> </Action> </Actions> </Target> </Rule>
Overview of Text2Policy
Specification (e.g., XACML)
Transformation
ACPLinguisti
c Analysis
Model Constructio
n
ACP Model
Resource Access
Extraction
Use Cases (UC)
Use Case Linguistic Analysis
ActionSteps
Resource Access
Information
Action-step Extraction
ACP ExtractionNon-
Functional Reqs
Use Cases (UC)
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
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
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
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 andaction is to output
Converting to “HCP views the updated account”
Example Use Case Action Step
Use Case Linguistic Analysis
Action Step
Actor Type Parameter
Patient OUTPUT- view
Access log
The patient views access log.
Overview of Text2Policy
Specification (e.g., XACML)
Transformation
ACPLinguisti
c Analysis
Model Constructio
n
ACP Model
Resource Access
Extraction
Use Cases (UC)
Use Case Linguistic Analysis
ActionSteps
Resource Access
Information
Action-step Extraction
ACP ExtractionNon-
Functional Reqs
Use Cases (UC)
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
Action
Actor Type Parameter
Patient
OUTPUT- view
Access log
Subject: patient Action: view Resource: access
log
Validation of Action Steps against ACPs
Validate resource access information from each action step against specified/extracted ACPs
Report detected inconsistencies
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
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)
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?
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%
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.”
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.”
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
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!
Questions?
http://csrc.nist.gov/groups/SNS/acpt/acpt-beta.htm
Recommended