Policy Analysis for Self-administrated

1. Policy Analysis for Self-administrated Role-based Access Control Gennaro Parlato U. Southampton, UK Anna Lisa Ferrara P. Madhusudan U. Bristol, UKUIUC, USA

2. Role-based Access Control (RBAC) RBACis an access control model - for large organization - standard (NIST) - supported by: Microsoft SQL Servers, Microsoft Active Directory, SELinux, Oracle DBMS Users Roles Permissions Permissions are pairs (object, operation) UA = Users X Roles PA = Roles X Permissions

3. RBAC Example: Hospital Roles: Doctor, Manager, Nurse, Patient, PrimaryD, Receptionist,… Permissions: p1= Create_Appointment p2= View_OldMedicalRecord p3= View_RecentMedicalRecords … UA: (Mary, Receptionist) (John, Doctor), (John, PrimaryD) (Jenny, Patient) (Tim, Doctor) … PA: (p1, Receptionist) (p2, Doctor) (p3, Doctor) …

4. UA and PA relations may change by means of administrative rules: Assign(admin_role, precondition, target_role) - if admin user A has admin_role, then A can assign any user u who satisfies precondition to target_role Revoke(admin_role, precondition, target_role) Administrative RBAC (ARBAC) Roles Permissions Users Admin Actions Admins Admins Roles PA UA Users conjunction of literals over the set of Roles

5. Example of ARBAC Policy Admins: Manager, Patient, Receptionist,… Assign Rules - assign( Manager, ¬Doctor, Receptionist ) - assign( Manager, true, Nurse ) - assign( Patient, Doctor∧¬Patient, PrimaryDoctor ) … Revoke Rules - revoke( Manager, true, Receptionist ) - revoke( Manager, true, Nurse ) …

6. Security Requirements Designers have security properties in mind while designing the set of assignment/revocation rules • Availability properties - A doctor must always be able to access patients’ record • Escalation of privileges - A receptionist cannot be granted doctors’ permissions • Separation of duties - A doctor cannot be also a receptionist

7. Role-reachability Problem - availability - separation of duties, - escalation of privileges - … each reduces to • Role-reachability Problem Can any user gain access to a given role goal using the ARBAC rules?

8. Importance of Automated Analysis • Monitoring strategies are not acceptable: denial-of-service • Verification is essential • Policies are difficult to inspect by hand:state space = O((2#roles) #users) … … … . . . . . . . . . . . . . . . configuration of the system Assign/Revoke actions

9. State-of-the-art • Reachability problem is • - PSPACE-complete [CSFW’06] • fixed parameter tractable in # roles [CCS’07] • Restrictedscenarios to tackle reachability • separate administration (limits expressiveness) • administrative roles and regular roles are disjoint • assignment/revocation admin roles is not allowed • allows to track only one user as opposed to tracking all users • [CCS’07] • under-approximation techniques (under separate administration) • error-finding (shallow errors) not appropriate for correctness • [CCS’11]

10. State-of-the-art (beyond separate administration) • Proving correctness • [Ferrara, Madhusudan, Parlato, • Security Analysis of RBAC through Program Verification – CSF’12] • Idea: • - simulate precisely the system with a program with integers • - each variable tracks the # of users in a role combination • - exponential # of variables • Over-approximation (effective) • - create a program that tracks only few role combinations • - analysis with Interproc with box domain • - scalable analysis (correctness) • - we cannot generate security attacks

11. Our Contribution • Achieving completeness and correctness without any restriction Fundamental Theorem : It is enough to track only k users at any time, where k is the # of admin roles - leads to a significant trimming procedure (much smaller # of users, admin roles) Novel Pruning technique : Transform the policy in a smaller one preserving role-reachability (effective also for separate administration) Tool: VAC Verifier of Access Control http://users.ecs.soton.ac.uk/gp4/VAC.html Experiments on realistic policies from the literature hospital, university, bank, and three suites of complex policies

12. Experimental Results (hospital, university policies) After Pruning #users #rules #roles #users #admin Reach #roles Time #rules #admin Policy Hospital University Bank4 Complete analysis without separate admin restriction!

13. Experimental Results After Pruning Second Suite Third Suite First Suite Size Policy Time Time Time #rules #roles #rules #rules #roles #rules #roles #roles Time Time Time #rules #rules #rules Complete analysis on complex policies! only error-finding tools were successful

14. Experimental Results After Pruning #rules #roles #rules #roles Time Policy Bank1 Bank2 Bank3 Bank4 only error-finding tools were successful

15. Our Contribution • Achieving completeness and correctness without any restriction Fundamental Theorem : It is enough to track only k users at any time, where k is the # of admin roles - leads to a significant trimming procedure (much smaller # of users, admin roles, roles) Novel Pruning technique : Transform the policy in a smaller one preserving role-reachability (effective also for separate administration) Tool: VAC Verifier of Access Control http://users.ecs.soton.ac.uk/gp4/VAC.html Experiments on realistic policies from the literature hospital, university, bank, and three suites of complex policies ✔

16. Finite Model Property Theorem: The role-reachability problem can be solved by tracking at most k+1 users where k is the # of administrative roles

17. Idea of the proof 1/3 mn mi m2 m1 … … cn+1 cn ci+1 c2 ci c1 π = Rule made by Admini … … ci= … . . . . . . . . . . . . . . . • A user u is • engaged if u’s configuration changes along the run • essential if there is index i in which u is the only • user in Admini at configuration ci

18. Idea of the proof 2/3 mn mi m2 m1 … … cn+1 cn ci+1 c2 ci c1 π = Rule made by Admini • Simplification rules • pick a non essential user u and remove all transitions changing u’s configuration • if all users are essential then • pick an engaged user and remove all transitions • changing u’s configuration after the last configuration • in which u is essential • … termination is guaranteed

19. Idea of the proof 3/3 mn mi m2 m1 … … cn+1 cn ci+1 c2 ci c1 π = For each 2 distinct engaged users u1 and u2 if u1 is essential for role admin1 (the last time) u2 is essential for role admin2 (the last time) then admin1 ≠ admin2 There are at most k engaged users in the run π, where k = # admin roles

20. Exploiting the Theorem Can we track less users??? NO Theoretically the k+1 bound is tight !!! Heuristics??? REMOVE ADMIN ROLES An admin role A is immaterial if there are more than k+1 users in role A. Transform immaterial roles into regular ones. REMOVE USERS for each role-combination we need at most k+1 users.

21. Our Contribution • Achieving completeness and correctness without any restriction Fundamental Theorem : It is enough to track only k users at any time, where k is the # of admin roles - leads to a significant trimming procedure (much smaller # of users, admin roles, roles) Novel Pruning technique : Transform the policy in a smaller one preserving role-reachability (effective also for separate administration) Tool: VAC Verifier of Access Control http://users.ecs.soton.ac.uk/gp4/VAC.html Experiments on realistic policies from the literature hospital, university, bank, and three suites of complex policies ✔ ✔

22. Our tool Policy role pruning CSF’12 TACAS’13 ad hoc-abstraction boolean program encoding integer program model-checking GetaFix interval-abstractions using INTERPROC Yes error NO: policy correct NO: policy correct Yes: may be a false error

23. Conclusions & Future work

24. Conclusions - foundation of reasoning with ARBAC policies (no separate administration) - small model property: tracking a bounded # of users suffices for role-reachability - developed heuristics to effectively reduce ARBAC systems on real-world policies. - VAC : Verifier of Access Control http://users.ecs.soton.ac.uk/gp4/VAC.html - developped Apply our techniques to systems supporting RBAC - OS, Microsoft SQL Servers, Microsoft Active Directory, SELinux, Oracle DBMS - Extend our results to more expressive specs (e.g., info flow, data leakage) - Provide a counter-example guided abstraction scheme