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 ACPsNon-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

EffectSubject Action Resour

ce

HCP editpatient.accoun

tden

y

“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 Deny

ACPs

ResourceAccess

Information

Combined ACPs

Action-stepExtraction

Automatic Validation

DetectedInconsistencies

High-level Overview of Text2Policy – in the Absence of Non-functional Requirement

FunctionalRequirement

ACPExtraction Deny

ACPs

ResourceAccess

InformationAction-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 TextShallow 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