RBAC-PAT: A Policy Analysis Tool for Role Based Access Control

1. RBAC-PAT: A Policy Analysis Tool for Role Based Access Control Mikhail I. Gofman, Ruiqi Luo, Ayla C. Solomon, Yingbin Zhang, Ping Yang and Scott D. Stoller

2. Outline Background: RBAC, ARBAC, and Policy Analysis • RBAC-PAT Architecture and Functionality • Performance Results • Demonstration

3. Role-Based Access Control (RBAC) • Users are assigned to roles, e.g., doctor, nurse, patient. • Example:UA = {(Bob, Doctor)} • Permissions are associated with roles. • Example:PA = {(Doctor,Modify,Prescriptions)} • A user has a permission if he is a member of some role with that permission. • RBAC is relatively simple and widely used. User Assignment Permission Assignment UA PA Role User Permission

4. Role Hierarchy • r1 ≥ r2 (r1is senior to r2) means every member of r1 is also an implicit member of r2. Thus, members of r1 have all the permissions that members of r2 have. • Permission flows up. Membership flows down. • Role hierarchy reduces redundancy and eases administration. Project Manager Tester Programmer Membership Permission Project Member

5. Administrative RBAC (ARBAC) • ARBAC is a generic name for administrative policy models for RBAC. • ARBAC97 [Sandhu+ 1999] is a classic ARBAC model • ARBAC97 has three components: • User-Role Administration: controls user assignment • Permission-Role Administration: controls permission assignment • Role-Role Administration: controls role hierarchy

6. ARBAC Syntax • Example: • can_assign(President, Professor  ¬DeptChair, Dean): Administrator in role President can assign a user in role Professor and not in role DeptChair to role Dean. • Professor is a positive precondition, DeptChair is a negative precondition and Dean is postcondition. • Professor is a positive role. DeptChair is a negative role. A role that is both positive and negative is called mixed. • Role President is administrative: has an administrative permission, ie. is the first component of a can_assign rule. • Role Professor is regular: appears in the precondition of the rule. • Example: • can_revoke(DeptChair, TA): an administrator in role DeptChair can remove any user from role TA.

7. ARBAC Syntax Cont. • can_assignp and can_revokep: used to control permission-role assignment. Syntax similar to user-role administration. • Separate Administration Restriction: administrative roles and regular roles are disjoint.

8. Motivation: Administrative Policy Analysis • Large organizations have large and complex policies which are managed by multiple administrators. • The effects of an ARBAC policy are often hardto understand by manual inspection alone. • Changes by one administrator may interact in unintended ways with changes by other administrators. • We developed RBAC-PAT: a suite of policy analysis tools for ARBAC policies.

9. Outline • Background: RBAC, ARBAC, and Policy Analysis • RBAC-PAT Architecture and Functionality • Performance Results • Demonstration

10. RBAC-PAT Architecture ARBAC Policy Property GUI FRONT-END Parser Parsed Policy Hierarchy Converter Converted Policy Policy Analysis Engine BACK-END Evidence Generator Evidence

11. RBAC-PAT Architecture Property ARBAC Policy • Front-End: • Parser/Checker: Checks the policy for: • Syntax Errors • Hierarchy Converter: converts hierarchical policies into equivalent non-hierarchical policies [Sasturkar+ 2006]. • Back-End: • Policy Analysis Engine: Implements analysis algorithms. • Evidence Generator: provides explanation of the analysis result. GUI Parser Parsed Policy Hierarchy Converter FRONT-END Converted Policy BACK-END Policy Analysis Engine Evidence Generator Evidence

12. Policy Analysis Problems • User-Role Reachability: given an initial RBAC policy, an ARBAC policy, a set of administrators, a target user, and a set of roles (called the “goal”), is it possible for those administrators to modify the RBAC policy so that the target user is a member of those roles? • User-Role Availability: can a user u be removed from a role r by a group of administrators A? • Weakest Preconditions:what are the minimal setsof initial role memberships of the target user for which a given reachability goal is achievable?

13. Policy Analysis Problems Cont. • Role-Role Containment [Li+ 2006]: In every state reachable from a given initial state, is every member of role r1also a member of role r2? • DeadRoles:Does the policy contain roles which cannot be assigned to any users? • Information Flow: Can information flow, directly or transitively, from object O1 to object O2?[Osborn+ 2002]. • Permission-Role Reachability • User-Permission Reachability

14. Fixed Parameter Tractability (FPT) • Reachability analysis for ARBAC is PSPACE complete in general [Sasturkar+ 2006]. • We developed practical analysis algorithms that [Stoller+ 2007]: • Exploit typical characteristics of realistic policies • Are fixed-parameter tractable (FPT), i.e., have • high complexity W.R.T. a (small) parameter k • low complexity W.R.T. overall problem size, when value of k is fixed. • [Sasturkar+2006] A. Sasturkar, P. Yang, S. Stoller, and C. R. Ramakrishnan, Policy Analysis for Administrative Role Based Access Control, CSFW 2006 • [Stoller+2007] S.D. Stoller, P. Yang, C. R. Ramakrishnan, M. Gofman, Efficient Policy Analysis of ARBAC policies, CCS 2007

15. Efficient Reachability Analysis • Given an ARBAC policy, if the separate administration restriction holds: • Forward Algorithm • Backward algorithm • Otherwise: • Forward Algorithm

16. Forward Algorithm for ARBAC with Sep. Admin. • With the separate administration assumption, it suffices to consider the role assignment of the target user u only. • Standard reachability computation optimized with a reduction. • A state is the set of roles that the target user u is in. • Reduction • Transitions that revoke non-negative roles or add non-positive roles are prohibited; • Transitions that add non-negative roles or revoke non-positive roles are called invisible; others are called visible. • Invisible transitions get combined with a preceding visible transition to form a single composite transition.

17. Forward Algorithm with Sep. Admin.: Example • ARBAC Policy • 1. can_assign(DeptChair, Grad, TA) • 2. can_assign(GradAdmComm, ¬UnderGrad, Grad) • 3. can_assign(Faculty, Undergrad, Grader) • All Roles are revocable • Can administrators in roles {DeptChair, GradAdmComm, Facutly} assign a user initially in {UnderGrad} to {TA, Grader}? Yes Grader UnderGrad ur(Undergrad) Grad Grader TA

18. Forward Algorithm for ARBAC with Sep. Admin. Cont. • Slicing eliminates parts of the policy irrelevant to the given reachability query. • FPT w.r.t number of mixed roles (|mixed|).

19. search direction Backward Algorithm for ARBAC with Sep. Admin. • Stage 1: use backwards search from goal to construct a graph (V, E). Nodes are user assignments (sets of roles). Edges are labeled with can_assign rules. • Stage 1 cannot check if the negative precondition holds • Stage 2: perform forward search to check if the goal is reachable set of roles role can_assign(ar, p¬N, r) UA UA \ {r}  {p} r ∈ UA

20. Backward Algorithm with Sep. Admin.: Example • ARBAC Policy • 1. can_assign(ar, true, r1) • 2. can_assign(ar, r1, r2) • 3. can_assign(ar, r2r1, r3) • 4. can_revoke(ar, r2) • Initial state = {}, Goal = {r3}, • The goal is not reachable, because r1 is irrevocable and disables the last transition. • Fixed-parameter tractable W.R.T. {|goal|, |IR|} for ARBAC with |ppre| ≤ 1, where |IR| is the number of irrevocable roles. cana(ar, true, r1) cana(ar, r1, r2) cana(ar, r2r1, r3) Ø r1 r2 r3

21. Beyond Separate Administration • In realistic ARBAC policies the sets of administrative and regular roles may notalways be disjoint. • They violate the separate administration restriction • Administrators may assign themselves to new roles. • Example: DeptChair assigns himself to HonorsPgmDir and then assigns students to HonorsStudent. • Need to consider multiple users and check their roles. The problem is FPT with respect to # mixed roles and # administrators.

22. Hierarchical Role Assignment • A query satisfies hierarchical role assignment if can_assign(ari, c, r) implies ari ≥ r for each ari. • Each administrator is already an implicit member of roles to which he can be assigned, so such assignments can be ignored. • Algorithms that assume separate administration apply. • In our university policy, most queries satisfy this.

23. Outline • Background: RBAC, ARBAC, and Policy Analysis • RBAC-PAT Architecture and Functionality • Performance Results • Demonstration

24. Performance Results • Evaluate algorithms on case studies and synthetic policies. • University policy and Health care case study results: • University policy: 372 rules. Healthcare policy: 13 rules • Analysis algorithms terminate in at most 0.2 seconds • Randomly generated policies: vary the size parameters, while maintaining similar characteristics as case studies (distribution of can_assign rules per role, positive and negative preconditions per rule, …).

25. Performance Results: Synthetic Policies Largest # of states: 5593 Largest # of transitions: 50511 Largest # of states: 74 Largest # of transitions: 266

26. Performance Results: Synthetic Policies Cont. Largest # of states: 14395 Largest # of transitions: 215396 Largest # of states: 401 Largest # of transitions: 1789

27. Demonstration: Separate Administration Checker

28. Demonstration: User-Role Reachability with Sep. Admin. 9999

29. Demonstration: Role-Role Containment 9999

30. Demonstration: Weakest Precondition

31. Demonstration: User-Role Reachability Without Sep. Admin. 9999 9999 9999

32. Demonstration: Dead Role Analysis 9999 9999 9999

33. Demonstration: The Hint Giver

34. Demonstration: Information Flow

35. Thank You!

36. Related Work • All previous reduction and partial-order reduction techniques proposed treating given sequences of transitions in the control flow graph of the program as composite transitions. • In contrast, our reduction itself defines composite transitions, and justifies using them instead of the original transitions. This is because ARBAC has no control flow; • Also, we present fixed-parameter tractability results. • In previous work on reductions and partial-order reductions, the performance was evaluated in a purely empirical way. • Lipton reduction • Partial order

37. Related Work Cont. • [Schaad+ 2002], [Li+ 2004] analyze properties of ARBAC97 policies: • No negative preconditions • No fixed parameter tractability results

38. Performance Results: Synthetic Policies Cont. Fwd. Alg. is 90 times faster

39. Statistics Demonstration

40. Conflict Detection Demonstration

41. search direction Backward Algorithm for ARBAC with Sep. Admin.: Stage 1 • Use backwards search from goal to construct a graph (V, E). Nodes are user assignments (sets of roles). Edges are labeled with can_assign rules. set of roles role can_assign(ar, p¬N, r) UA \ {r} ∈ {p} UA r ∈ UA

42. Backward Algorithm with Sep. Admin.: Stage 1 Example • ARBAC Policy • 1. can_assign(ar, true, r1) • 2. can_assign(ar, r1, r2) • 3. can_assign(ar, r2r1, r3) • 4. can_revoke(ar, r2) • Initial state = {}, Goal = {r3}, cana(ar, true, r1) cana(ar, r1, r2) cana(ar, r2r1, r3) Ø r1 r2 r3

43. R {I1,I2,…} Backward Algorithm for ARBAC with Sep. Admin.: Stage 2 • To detect if the goal is reachable, Stage 2 performs a forward analysis, labeling each node R with sets I1, I2,… of additional irrevocable roles. represents states R  I1, R  I2,… • Example: • Irrev = {r1} • Initial state = {}, Goal = {r3} • The goal is not reachable, because r1 is irrevocable and disables the last transition. • Fixed-parameter tractable W.R.T. {|goal|, |IR|} for ARBAC with |ppre| ≤ 1, where |IR| is the number of irrevocable roles. cana(ar, true, r1) cana(ar, r1, r2) cana(ar, r2r1, r3) Ø r1 r2 r3 {Ø} {{r1}} {} {Ø}

44. Demonstration: Hierarchical Role Assignment Checker