Security Analysis of Role-based Access Control through Program Verification Anna Lisa Ferrara University of Bristol, UK P. Madhusudan University of Illinois, USA Gennaro Parlato University of Southampton, UK

Access control policies are designed to support authorized accesses to protected resources Access Control Policies

Most used access control model - standardized by the NIST - ease of administration Role-based Access Control (RBAC) Users RolesPermissions Permissions are pairs (object, operation) UA = Users X Roles PA = Roles X Permissions

RBAC Example: Hospital Roles: Doctor, Manager, Nurse, Patient, PrimaryD, Receptionist,… Permissions: p 1 = (Create, Appointment) p 2 =(View, OldMedicalRecord) p 3 =(View, RecentMedicalRecords) … PA: (Receptionist, p 1 ) (Doctor, p 2 ) (Doctor, p 3 ) … UA: (Mary, Receptionist) (John, Doctor), (John, PrimaryD) (Jenny, Patient) (Tim, Doctor) …

Uses the concept of role itself to administer RBAC policies: Assign(admin_role, precondition, target_role) - if admin user A has admin_role, then she can assign any user u who satisfies precondition the target_role Revoke(admin_role, precondition, target_role) Administrative RBAC (ARBAC) Admins Users Admin Actions Users Permissions any boolean condition over the roles of u Admins Roles Roles

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

Designer have security properties in mind while designing their policies Security Requirements Availability properties - A doctor must always be able to access patients’ record Escalation of privileges - A receptionist cannot access patients’ records Separation of duties - A doctor cannot be also a receptionist

Importance of Security Analysis r 1 r 2 rnrn state of the system Assign/Revoke actions u1u1 u2u … … … Policies are difficult to inspect by hand Monitoring strategies are not acceptable

Our Contribution RBAC Propose a way to automatically prove correctness - abstractions techniques Show that our solution scales in practice Build VAC, a tool publicly available

Role-reachability Problem - availability - separation of duties, - escalation of privileges, - … Role-reachability Problem each reduces to Can any user reach a particular role goal during the evolution of the system?

Equivalent Representation The cardinalities of all Venn regions determines the precise state of the ARBAC system modulo user identities Role-reachability: Is there a reachable state where #comb i >0, for some comb i containing goal? r 1 r 2 rnrn state of the system u1u1 u2u … … … #comb 1 = 0 #comb 2 = 20 #comb 2 n = 35 state of the system... equivalent modulo identities r1r1 r2r2 r3r3 The ARBAC system can purely be simulated using Venn region cardinalities number of users in each combination of roles

We use abstraction: - over-approximations (correctness) Abstraction Soundness:  s. init C (s) ⇒ init A (  (s))  s,s’. (s s’) ⇒ (  (s)  (s’)) real domainabstract domain C A  s s’s’ abstract function abstract transition  (s)  (s’)

Our Solution Set Abstraction C A’ 11 Numerical Abstraction A” 22 Set Abstraction 11 Numerical Abstraction 22

Set Abstraction (Abstract Domain) Given the set of roles, track only the number of users in a subset Track of role-combinations Example Roles: Manager, Nurse, Patient, PrimaryD, Receptionist, Doctor Track: ManagerNursePatient ManagerDoctorReceptionist DoctorReceptionist Patient May or may not be a Doctor

Set Abstraction (Abstract Transition) Must soundly update the abstract state after any Assign and Revoke action Without knowing the exact number of users in each Venn region it is difficult to update the states Intuition: Choose non-deterministically the user role-combination and update subsets accordingly ManagerNursePatient ManagerDoctorReceptionist Patient ManagerDoctor - Difficulty: Consider Assign(Manager, ¬ Receptionist, Doctor) Track = Is the user a manager or not?

Abstract Transition as a Program while ( true ) do //----- Choose a user consistent with the current configuration // b_Admin=random; assume b_Admin>=0 and b_Admin<=1; b_Doctor=random; assume b_Doctor>=0 and b_Doctor<=1; b_Manager=random; assume b_Manager>=0 and b_Manager<=1; b_Patient=random; assume b_Patient>=0 and b_Patient<=1; b_PrimaryDoctor=random; assume b_PrimaryDoctor>=0 and b_PrimaryDoctor<=1; b_Receptionist=random; assume b_Receptionist>=0 and b_Receptionist<=1; b_target=random; assume b_target>=0 and b_target<=1; //----- CanAssign(Manager, !Receptionist, Doctor ) if (brandom and (ADMIN_Manager>0) and b_Receptionist==0 and b_Doctor==0 ) then tmpAdmin=0; //----- Xt n_Doctor_0Patient // if (b_Patient==0 ) then n_Doctor_0Patient=n_Doctor_0Patient+1; tmpAdmin=1; endif; if (tmpAdmin>0) then ADMIN_Doctor=ADMIN_Doctor+1; endif; //---- ERROR if (n_target>0) then skip; endif; done;...

Numerical Abstraction Interval abstractions of programs for numerical domains each value in Track in each point of the program Interval Range 22 Security of RBAC policies does not depend on the exact number of users in a configuration!

Our tool slicing interval-abstractions using INTERPROC PolicySecurity Query NO: policy correct Yes: may be a false error encode in a program set-abstraction

Experimental Results s0s0.3s s0.01s0.3s s0.1s0.6s s0.2s0.8s s0.2s0.8s 13,3567s44s51s 26,6849s3m 0.2s3m 11s 26,7059s3m 0.3s3m 12s 40,01211s7m 0.8s7m 19s 40,04510s7m 08s7m 18s 53,34011s13m 16s13m 27s 53,3839s13m 15s13m 24s #roles #actions After SlicingVAC Line of code Time to trasform INTERPROC time Total time Hospital University Bank 1 Bank 2 Bank 3 Bank 4 Policy #actions

Conclusion Prove correctness of policies automatically (abstractions) set abstraction interval abstraction Experimentally proved the scalability of our approach VAC is available at