RBAC and Usage Control System Security

Role Based Access Control Enterprises organise employees in different roles RBAC maps roles to access rights After Subjects are authenticated they can activate roles Access rights are assigned per active roles

A simple example

Using ACL for 702 Andrew Robert Patricia Sam …

Using Uni Level

Role to Access Rights

User to Role Andrew Robert Patricia Sam

From User to Access Right

Extensions to the Model A user can be in more than one role Robert Amor is both Prof. and Head of Department Roles can be organised into Hierarchies Professor > Assistant Professor > Senior Lecturer > Lecturer Top Roles inherit access rights of Lower Roles Constraints to enforce organisation-specific requirements

RBAC Constraints Separation of Duties (SoD) Protecting the organisation from frauds Chinese Wall (CW) Conflict of interests between different domains

Separation of Duties Details Used when an activity involves more than one role Purchase order needs to be prepared by a clerk and then authorized by a manager To avoid a fraud, the user that prepares the order should not be the same that authorizes it

Static Separation of Duties The same subject cannot be a member of two mutually exclusive roles A clerk’s and a manager’s roles are mutually exclusive Too restrictive: the user might get assigned to both roles as long as they are not working on the same order!

Dynamic Separation of Duties The same subject can be member of two mutually exclusive roles However, it requires extra checks that need to be done at runtime to avoid undesired behaviour Simple DSoD, Object DSoD, Operational DSoD, History DSoD

Controlling the usage of resources DAC, MAC and RBAC are concerned with checking the access rights of entities Once the access is granted no more controls are enforced

Examples Read a file only 5 times Write data into a directory but only up to 1 GB Connect to the Internet only if there is enough remaining bandwidth (capping plan) Withdraw from ATM only if there is enough credit in account

Usage Control Model (UCON) Focuses on controlling usage and not only access to an object Addresses Digital Right Management (DRM) concerns DAC, MAC and RBAC can also be expressed by UCON

UCON Model Usage control is based on: Authorizations Obligations Conditions Mutability of Attributes Continuity of Enforcement Finer grained control Defined by J. Park and R. Sandhu The UCON Usage Control Model. ACM Trans. on Information and System Security, 7(1), 2004

Usage Control Model (UCON) Applications Simple, familiar, usable and effective use cases demonstrate the need for UCON Automatic Teller Machines CAPTCHAs at Public web sites End User License Agreements Terms of Usage for WiFi in Hotels, Airports Rate limits on call center worker

UCON (cont’d)

Subjects and Objects Subjects: entities that perform actions on Objects. Are characterized by Attributes: Identity Role Reputation Credits Objects: entities that are used by Subjects. Are characterized by Attributes: Value Identity Status

Mutability of Attributes Attributes of Subjects and Objects Can be static (IMMUTABLE) Can be updated (MUTABLE): Before the action execution (PRE) During the action execution (ONGOING) After the action execution (POST) Example: A storage service charges its users when they read documents. The credit attribute of an user is updated before he reads a document.

Authorization Authorization rules are a set of requirements that should be satisfied before allowing subjects’ access to objects or use of objects. Rights-related Authorization Rules (RAR) and Obligation-related Authorization Rules (OAR). Functional predicates for usage decisions that evaluate: Subject Attributes Object Attributes Right (Action) Authorization rules Example: a computational service exploits a security policy to decide whether the user U can perform the action “read” on the file “a.txt”

Obligations Conditions are a set of decision factors that the system should verify at authorization process along with authorization rules before allowing usage of rights on a digital object. Dynamic conditions and Static conditions Obligations are mandatory requirements that a subject has to perform after obtaining or exercising rights on an object. Functional predicates that verify mandatory requirements that must have been performed by the subject. Actions Example: the user of a storage service must download the license agreement before downloading any other document.

Conditions Environmental or system based decision factors Not directly related with Subjects and Objects e.g. Current local time Current system workload System status Example: night-users can submit jobs to a computational resource only from 8pm to 8am

Continuity Mutable Attributes change their values The evaluation of a usage right can be performed Before the action (PRE) Continuously during the action (ONGOING) The right could be revoked and the action interrupted Used for long lived actions (days, months,..)

Resources Chapter 8 in Mark Stamp, Information Security: Principles and Practice, Wiley Matt Bishop, Computer Security: Art and Science, Addison- Wesley Sandhu, et al. "Role-based access control models," Computer, vol.29, no.2, pp.38,47, Feb 1996 (doi: / )

Questions?