1. 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 State University 1 National Institute of Standards and Technology 2 (SSIRI 2009)

2. 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)

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

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

5. Automated Software Engineering Research Group 5 Outline Motivation Problem Background and Example Framework –Inconsistency Detection –Policy Fixing –Change Impact Analysis Evaluation Results Conclusion

6. Automated Software Engineering Research Group 6 May 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 responses A 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. Automated Software Engineering Research Group 7 May 12, 2007 WWW 2007, Banff, Alberta, Canada 7 XACML Example <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 "> A College Policy on Grades <Policy PolicyId="fac" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm: first-applicable "> Faculty Policy <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> Faculty <SubjectAttributeDesignator AttributeId="role" DataType="http://www.w3.org/2001/XMLSchema#string" /> Policy Set Policy Target Subject

8. Automated Software Engineering Research Group 8 May 12, 2007 WWW 2007, Banff, Alberta, Canada 8 XACML Example ExternalGrades http://www.w3.org/2001/XMLSchema#string <ResourceAttributeDesignator AttributeId="resource-class" DataType="http://www.w3.org/2001/XMLSchema#string" /> InternalGrades http://www.w3.org/2001/XMLSchema#string <ResourceAttributeDesignator AttributeId="resource-class" DataType="http://www.w3.org/2001/XMLSchema#string" /> Assign http://www.w3.org/2001/XMLSchema#string <ActionAttributeDesignator AttributeId="command" DataType="http://www.w3.org/2001/XMLSchema#string" /> Receive http://www.w3.org/2001/XMLSchema#string <ActionAttributeDesignator AttributeId="command" DataType="http://www.w3.org/2001/XMLSchema#string" /> Target Resource Rule Target Action More Rules can be added

9. 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 1 st Rule’s condition) If role = Faculty and resource = (ExternalGrades or InternalGrades) and action = (View or Write) then Permit If role = Student and resource = ExternalGrades and action = View then Permit If role = Student and resource = ExternalGrades and 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 (1 st and 3 rd Rule’s conditions) considereing first applicable rule algorithm

10. 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 3 rd request includes any potential security leakage Student can write his own grade !!! 3 rd Request is permitted: Member of Student (with an additional Faculty role) wishes to Write ExternalGrades. 2 nd Request is denied: Member of Student role wishes to Write ExternalGrades. Decision is inconsistent

11. Automated Software Engineering Research Group 11 Framework

12. Automated Software Engineering Research Group 12 Inconsistency Detection Candidate Request R 1 (Student, Write, ExternalGrades) Multiple-Duty Request R 2 (Student and Faculty, Write, ExternalGrades) Inconsistency check Manual inspection is required if a detected inconsistency causes real security leakage

13. Automated Software Engineering Research Group 13 Policy Fixing Example (1/3) If role = (Faculty and Student) then Deny If role = Faculty and resource = (ExternalGrades or InternalGrades) and action = (View or Write) then Permit If role = Student and resource = ExternalGrades and action = View then Permit If role = Student and resource = ExternalGrades and action = Write then Denyse Deny New Rule Addition The example policy fixed by static separation of duty

14. Automated Software Engineering Research Group 14 Policy Fixing Example (2/3) If role = Faculty and role != Student and resource = (ExternalGrades or InternalGrades) and action = (View or Write) then Permit If role = Student and resource = ExternalGrades and action = View then Permit If role = Student and resource = ExternalGrades and action = Write then Denyse Deny Rule Constraint The example policy fixed by adding constraint on the first rule

15. Automated Software Engineering Research Group 15 Policy Fixing Example (3/3) If role = Student and resource = ExternalGrades and action = Write then Denyse If role = Faculty and resource = (ExternalGrades or InternalGrades) and action = (View or Write) then Permit If role = Faculty and 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

16. 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 Revised Policy Compare

17. 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 –dec i – dec j inconsistency (e.g., permit-deny) Two decisions are inconsistent A request r is evaluated to dec i and a request r’ (holding an additional role on r) is evaluated to dec j

18. Automated Software Engineering Research Group 18 11 XACML Policy Subjects 6 Permit, 2 deny, and 3 hybrid XACML policies

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

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

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

22. Automated Software Engineering Research Group 22 Questions?

23. 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]

24. Automated Software Engineering Research Group 24 Discussion