Security Analysis of Role-based Access Control through Program Verification Anna Lisa Ferrara...

Post on 17-Dec-2015

214 views 0 download

Tags:

Transcript of Security Analysis of Role-based Access Control through Program Verification Anna Lisa Ferrara...

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 Roles Permissions

Permissions are pairs (object, operation)UA = Users X Roles

PA = Roles X Permissions

RBAC Example: Hospital

Roles: Doctor, Manager, Nurse, Patient, PrimaryD, Receptionist,…

Permissions: p1= (Create, Appointment) p2=(View, OldMedicalRecord) p3=(View, RecentMedicalRecords) …

PA: (Receptionist, p1) (Doctor, p2) (Doctor, p3) …

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

UsersAdminActions

Users

Permissions

any boolean conditionover 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

1 0 0

0 0 1

r1 r2 rn

state of the system

Assign/Revoke actions

u1

u2... ...

……

...... ...

• 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 #combi >0, for some combi containing goal?

1 0 0

0 0 1

r1 r2 rn

state of the system

u1

u2... ...

……

...... ...

#comb1 = 0

#comb2 = 20

#comb2n = 35

state of the system

.

..equivalent modulo

identities

r1 r2

r3

• 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. initC(s) init⇒ A((s)) • s,s’. (s s’) ( ⇒ (s) (s’))

real domain abstract domain

C A

s

s’

abstractfunction

abstracttransition

(s)

(s’)

Our Solution

Set Abstraction

C A’1

Numerical Abstraction

A”2

Set Abstraction

1

Numerical Abstraction

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

ManagerNursePatientManagerDoctorReceptionist ManagerDoctorReceptionistPatientManagerDoctor

- Difficulty: Consider Assign(Manager, ¬Receptionist, Doctor)

Track =

Is the user a manager or not?

Abstract Transition as a Programwhile ( 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; 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

Security of RBAC policies does not depend on the exact number of users in a configuration!

Our tool

slicing

interval-abstractions using INTERPROC

Policy Security Query

NO:policy correct

Yes:may be a false error

encode in a program

set-abstraction

Experimental Results

12 24 3 4

12 24 5 8

32 132 5 9

32 132 13 37

32 132 15 43

34 593 34 593

68 1186 68 1186

68 1186 68 1186

102 1779 102 1779

102 1779 102 1779

136 2372 136 2372

136 2372 136 2372

73 0.3s 0s 0.3s

134 0.3s 0.01s 0.3s

162 0.5s 0.1s 0.6s

541 0.6s 0.2s 0.8s

535 0.6s 0.2s 0.8s

13,356 7s 44s 51s

26,684 9s 3m 0.2s 3m 11s

26,705 9s 3m 0.3s 3m 12s

40,012 11s 7m 0.8s 7m 19s

40,045 10s 7m 08s 7m 18s

53,340 11s 13m 16s 13m 27s

53,383 9s 13m 15s 13m 24s

#roles #roles#actions

After Slicing VAC

Line ofcode

Time totrasform

INTERPROC

timeTotaltime

Hospital

University

Bank1

Bank2

Bank3

Bank4

Policy #actions

Conclusion

• Prove correctness of policies automatically (abstractions)• set abstraction • interval abstraction

• Experimentally proved the scalability of our approach

• VAC is available at

http://users.ecs.soton.ac.uk/gp4/VAC.html