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.

Post on 17-Jan-2016

212 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

Transcript

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)

Automated Software Engineering Research Group 3

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?

Automated Software Engineering Research Group 4

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

Automated Software Engineering Research Group 5

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

Automated Software Engineering Research Group 7May 12, 2007

WWW 2007, Banff, Alberta, Canada

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

Automated Software Engineering Research Group 8May 12, 2007

WWW 2007, Banff, Alberta, Canada

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

Automated Software Engineering Research Group 9

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

Automated Software Engineering Research Group 10

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

Automated Software Engineering Research Group 11

Framework

Automated Software Engineering Research Group 12

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

Automated Software Engineering Research Group 13

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

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

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

Deny

New Rule Addition

The example policy fixed by static separation of duty

Automated Software Engineering Research Group 14

Policy Fixing Example (2/3)

If role = Faculty and role != Studentand 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

Rule Constraint

The example policy fixed by adding constraint on the first rule

Automated Software Engineering Research Group 15

Policy Fixing Example (3/3)

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

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

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

Deny

Chane Rule Location

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

Chane Rule Location

Automated Software Engineering Research Group 16

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

Automated Software Engineering Research Group 17

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

Automated Software Engineering Research Group 18

11 XACML Policy Subjects

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

Automated Software Engineering Research Group 19

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.

Automated Software Engineering Research Group 20

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

Automated Software Engineering Research Group 21

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

Automated Software Engineering Research Group 22

Questions?

Automated Software Engineering Research Group 23

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]

Automated Software Engineering Research Group 24

Discussion

top related