Computer Science 1 Detection of Multiple-Duty-Related Security Leakage in Access Control Policies JeeHyun Hwang 1, Tao Xie 1, and Vincent Hu 2 North Carolina.

Computer Science

1

Detection of Multiple-Duty-Related Security Leakage in Access Control Policies

JeeHyun Hwang1, Tao Xie1, and Vincent Hu2

North Carolina State University1

National Institute of Standards and Technology2

(SSIRI 2009)

Automated Software Engineering Research Group 2

Access Control Policy Evaluation

• Access control mechanisms control which subjects (such as users or processes) have access to which resources.

Policy

Request Response

(Permit, Deny, or Not-applicable)


Motivation

– Access control policies are increasingly written in specification languages such as XACML

– Misconfiguration and mistakes in access control policies leads to security problems

– Identifying discrepancies between policy and their intended function is necessary

Security leakage in

access control policies?


Problem

• Multiple-Duty-Related Security Leakage– In XACML, a subject can hold multiple roles

(e.g., both TA and student)• Mistakes in handling such requests introduces a

security leakage

• Verification of access control policies to detect such leakage is necessary

•Can a faculty member write Grade? Yes• Can a student write a Grade? No

•Can a person who holds both student and faculty roles give a Grade???


Outline

• Motivation• Problem• Background and Example• Framework

– Inconsistency Detection– Policy Fixing– Change Impact Analysis

• Evaluation Results• Conclusion

Automated Software Engineering Research Group 6May 12, 2007

WWW 2007, Banff, Alberta, Canada

6

XACML Policy Structure

• eXtensible Access Control Markup Language– OASIS standard XML syntax for specifying policies, requests, and

responsesA flexible and expressive language but complex and verbose

Key concepts• A Policy Set holds other policies or policy sets.• A Policy is expressed as a set of rules.• A Rule have targets and a set of conditions• Both rule and policy Combining Algorithms exist to reconcile

conflicts.– First-Applicable, Only-One-Applicable, Permit-Overrides,

and Deny-Overrides algorithms

• Evaluated Decision can be Permit, Deny, Not-applicable, or Intermediate



7

XACML Example<?xml version="1.0" encoding="UTF-8"?><PolicySet xmlns="urn:oasis:names:tc:xacml:1.0:policy" PolicySetId="college"

PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable"> <Description>A College Policy on Grades</Description> <Target> <Subjects> <AnySubject /> </Subjects> <Resources> <AnyResource /> </Resources> <Actions> <AnyAction /> </Actions> </Target> <Policy PolicyId="fac"

RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"> <Description>Faculty Policy</Description> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

Faculty </AttributeValue> <SubjectAttributeDesignator AttributeId="role" DataType="http://www.w3.org/2001/XMLSchema#string" /> </SubjectMatch> </Subject> </Subjects> <Resources> <AnyResource /> </Resources> <Actions> <AnyAction /> </Actions> </Target>

Policy Set

Policy

Target Subject



8

XACML Example

<Rule RuleId="fac-assign-view-grades" Effect="Permit"> <Target> <Subjects> <AnySubject /> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">ExternalGrades</AttributeValue> <ResourceAttributeDesignator AttributeId="resource-class" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ResourceMatch> </Resource> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">InternalGrades</AttributeValue> <ResourceAttributeDesignator AttributeId="resource-class" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Assign</AttributeValue> <ActionAttributeDesignator AttributeId="command" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ActionMatch> </Action> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Receive</AttributeValue> <ActionAttributeDesignator AttributeId="command" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy></PolicySet>

Target Resource

Rule

Target Action

More Rules can be added


Example Policy and Request Evaluation

• Request: Member of Faculty role wishes to Write ExternalGrades • Decision:Permit decision is evaluated (by satisfying 1st Rule’s condition)

If role = Facultyand resource = (ExternalGrades or InternalGrades)and action = (View or Write) then Permit

If role = Studentand resource = ExternalGradesand action = View then Permit

If role = Studentand resource = ExternalGradesand action = Write then Denyse

Deny

• Request: Member of Student role wishes to Write ExternalGrades. • Decision:Deny decision is evaluated (by satisfying 3rd Rule’s condition)

• Request: Member of Student and Faculty roles wishes to Write ExternalGrades.• Decision:Permit decision is evaluated (1st and 3rd Rule’s conditions) considereing first applicable rule algorithm


Inconsistency and Potential Security Leakage

• Student can take an additional faculty role?• Restriction on using conflicting roles in a request

• However, if multiple role assignment is allowed,• Inspect that 3rd request includes any potential security leakage• Student can write his own grade !!!

• 3rd Request is permitted: Member of Student (with an additional Faculty role) wishes to Write ExternalGrades.

• 2nd Request is denied: Member of Student role wishes to Write ExternalGrades.

Decision is inconsistent


Framework


Inconsistency Detection

• Candidate Request R1 (Student, Write, ExternalGrades)• Multiple-Duty Request R2 (Student and Faculty, Write,

ExternalGrades)• Inconsistency check• Manual inspection is required if a detected inconsistency

causes real security leakage


Policy Fixing Example (1/3)

If role = (Faculty and Student) then DenyIf role = Faculty

and resource = (ExternalGrades or InternalGrades)and action = (View or Write) then Permit



Deny

New Rule Addition

The example policy fixed by static separation of duty



If role = Faculty and role != Studentand resource = (ExternalGrades or InternalGrades)and action = (View or Write) then Permit



Deny

Rule Constraint

The example policy fixed by adding constraint on the first rule






Deny

Chane Rule Location

The example policy fixed by moving the originally last rule to the top

Chane Rule Location


Change Impact Analysis

• Revised policy may include unintended changes• Change-impact analysis to avoid faults

– Comparing two policies and check if there are unintended changes

– Leverages an existing access control policy change impact analysis tool called Margrave

Original Policy

Original Policy

Revised Policy

Revised Policy

Compare


Evaluation

• A request includes at least 1 subject, 1 resource, and 1 action

• 3 Policy Structure Types– Permit (Deny) policy includes permit (deny) rules and a

deny (permit) fall through rule– Hybrid policy includes both permit and deny rules

• 6 Inconsistency Types– deci – decj inconsistency (e.g., permit-deny)

• Two decisions are inconsistent• A request r is evaluated to deci and a request r’ (holding an

additional role on r) is evaluated to decj


11 XACML Policy Subjects

• 6 Permit, 2 deny, and 3 hybrid XACML policies


Evaluation Results (1/2)

• In the gradeSheet policy, a student cannot write grades; however, a student (holding a TA) can write grades.

• In the health-care policy, a doctor can view private notes; however, a manager (holding a doctor) cannot view private notes.


Evaluation Results (2/2)

• NA (Not-applicable) to deny (permit) inconsistencies are detected; most of such inconsistencies are introduced by a single matching rule

• No deny (permit) to NA (Not-applicable) inconsistencies are detected


Conclusion

• XACML is designed to be flexible by allowing a request with multiple roles (duties) and this feature may cause multiple-duty-related security leakage

• We have developed a novel framework to detect such leakage

• Our empirical results show that our framework can effectively pinpoint potential multiple-duty-related security leakage


Questions?


Related Work

• Testing of XACML access control policies [Martin et al. ICICS 2006, WWW 2007]

• Change Impact Analysis of XACML access control policies [Fisler et al. ICSE 2005]

• Verification of access control policies using Alloy or RW specification language [Hughes et al. Tech Report 2004 and Zhang et al. ISC 2005 ]

• Analysis of Firewall policies [Yuan et al. S & P 2006 and El-Atawy et al. Infocomm 2007]


Discussion

Computer Science 1 Detection of Multiple-Duty-Related Security Leakage in Access Control Policies JeeHyun Hwang 1, Tao Xie 1, and Vincent Hu 2 North Carolina.

Documents