ISA 562 Information Security Theory and Practice Role-based Access Control

References NIST documents at http://csrc.nist.gov/rbac/ D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R. Chandramouli, "A Proposed Standard for Role Based Access Control (PDF)," ACM Transactions on Information and System Security , vol. 4, no. 3 (August, 2001) - draft of a consensus standard for RBAC. The ARBAC97 model for role-based administration of roles (1999)

Discretionary AC Restricts access to objects based solely on the identity of users who are trying to access them. Individuals Resources Server 1 Server 3 Server 2 Application Access List Legacy Apps Name Access Tom Yes John No Cindy Yes

Mandatory AC MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. Principle: Read Down Access equal or less Clearance Write Up Access equal or higher Clearance

Mandatory AC (cont) Users Resources Server 1 “Top Secret” Server 2 “Classified”

Role-Based AC Individuals Roles Resources Role 1 Role 2 Role 3 Server 1 Server 2 Server 3 User’s change frequently, Roles don’t

Role-Based AC A user has access to an object based on the assigned role. Roles are defined based on job functions. Permissions are defined based on authorities and responsibilities of a job. Operations on an object are invocated based on the permissions.

Role-Based AC Framework Core Components Constraining Components Hierarchical RBAC General Limited Separation of Duty Relations Static Dynamic

Core Components Defines: USERS ROLES OPERATIONS (ops) OBJECTS (obs) Permissions: (operation, object) pairs User-to-Role Assignments (ua) assigned_users Sessions

RBAC Core user_sessions session_roles (UA) User Assign- ment (PA) Permission Assignment USERS OBS OPS SESSIONS ROLES PRMS

USERS Process People: Processes: Alice Intelligent Agent Bob Cindy Processes: Intelligent Agent mailer daemon A mal-ware process

OBS (objects) An entity that contains or receives information, or has exhaustible system resources. Examples: OS Files or Directories DB Columns, Rows, Tables, or Views Printer Disk Space Lock Mechanisms RBAC will deal with all the objects listed in the permissions assigned to roles.

ROLES An organizational job function with a clear definition of inherent responsibility and authority (permissions). Director Developer Budget Manager Many-to-many relation between Users & Permissions Help Desk Representative

OPS (operations) An execution of an a program specific function that’s invocated by a user. Examples: Object – Operations …. Database – Update Insert Append Delete Locks – Open Close Reports – Create View Print Applications - Read Write Execute SQL

PRMS (permissions) Perms ⊆ 2 OBJ x ACTIONS The set of permissions that each grant the approval to perform an operation on a protected object. User.DB1 View Update Append permissions object User.F1 Read Write Execute permissions object Perms ⊆ 2 OBJ x ACTIONS

Some Notation: Four Predicates UA(u,r): says that user u is assigned to role r. PA(r,(op,ob)): says that role r is permitted to execute operation op on object ob. user-session(u,s): says that user u has opened session s. session-role(s,r): iff says that some user has invoked the role r within session s.

Constraint Components - 1 Role Hierarchies Based on role inheritance. R1 is a senior to R2 (written R1 > R2 ) iff All permissions assigned to R2 are available to R1. > is a partial order on the set of roles

Some Consequences UA(u,r1) and r1 > r2  UA(u,r2) PA(r2,(ob,op)) and r1 > r2  PA(r2,(ob,op)) session-role(s,r1) and r1 > r2  session-role(s,r1)

Role Hierarchy & Constraints user_sessions (RH) Role Hierarchy session_roles (UA) User Assign- ment (PA) Permission Assignment USERS OBS OPS SESSIONS ROLES PRMS SSD DSD

Separation of Duty Constraints Two kinds: Static separation of duty Determined when users are assigned to roles Affects the UA(user,role) predicate Dynamic separation of duty Constraints the roles invoke-able by a user Affects the session-role(session,role) predicate directly, and consequently the permissions available to a user.

Specifying Constraints staticConflict(r1,r2): says that roles r1 and r2 have a static conflict Implying that they should not be assigned to the same user dynamicConflict(r1,r2): says that roles r1 and r2 have a dynamic conflict Implying that they should not be invoked in the same session by the same user The same user may invoke roles r1 and r2 in different sessions!

A Hierarchy of RBAC Models Least Privileged Separation of Duties Models Hierarchies Constraints RBAC0 No RBAC1 Yes RBAC2 RBAC3 Most Complex RBAC3 Effort RBAC Model

RBAC System and Administrative Functional Specification Administrative Operations Create, Delete, Modify and Maintain elements and relations of the RBAC model Administrative Reviews Query operations System Level Dynamic Functions Creation of user sessions Role activation/deactivation Constraint enforcement Computing Access Decisions

UA (user assignment) USERS set ROLES set A user can be assigned to one or more roles Developer A role can be assigned to one or more users Help Desk Rep UA ⊆ Users X Roles: Example: UA(Alice, Developer), UA(Bob, Help Desk Rep)

UA (user assignment) Mapping of role r onto a set of users ROLES set USERS set User.F1 User.F2 User.F3 User.DB1 View Update Append User.DB1 permissions object assigned_user(r) gives the set of users assigned to the role r assigned_user(r)={u:UA(u,r)} assigned_user: ROLES  2USERS User.DB1

PA (perms assignment) PA ⊆ USERS x Permissions ROLES set PRMS set A perms can be assigned to one or more roles Create Delete Drop Admin.DB1 View Update Append A role can be assigned to one or more perms PA ⊆ USERS x Permissions User.DB1

PA (perms assignment) assigned_permissions(r) gives the Mapping of role r onto a set of permissions PRMS set ROLES set Read Write Execute View Update Append Create Drop SQL User.F1 User.F2 User.F3 Admin.DB1 assigned_permissions(r) gives the set of permissions assigned to role r assigned_permissions(r) = {p : PA(r,p)} assigned_permissions: ROLES  2 PERMS

PA (perms assignment) READ Mapping of operations to permissions OPS set PRMS set public int read(byteBuffer dst) throws IOException Inherited methods from java.nio.channls close() isOpen() READ Gives the set of operations associated with the permission. Namely, those that have the permission! op(p: PERMS)  {op∈ OPERATION: p=(obj,op)}

PA (perms assignment) Mapping of permissions to objects Objects PRMS set Open Close View Update Append Create Drop BLD1.door2 SQL Gives the set of objects with the permission DB1.table1 ob(p: PERMS)  {ob∈ OBJECT: p=(obj,op)}

SESSIONS The set of sessions that each user invokes. SESSION USER SQL guest user admin invokes USER FIN1.report1 SQL DB1.table1 APP1.desktop

SESSIONS The mapping of user u onto a set of sessions. USERS SESSION guest user admin invokes User2.FIN1.report1.session USER1 SQL User2.DB1.table1.session USER2 User2.APP1.desktop.session user_sessions(u: USERS)  2SESSIONS

SESSIONS The mapping of session s onto a set of roles SESSION ROLES SQL Admin User Guest DB1.table1.session session_roles(s:SESSION)2ROLE session_role(s) ={ r∈ROLE: session_user(s)∈UA}

SESSIONS avail_session_perms(s) gives the set of permissions Permissions available to a user in a session. ROLE PRMS SESSION SQL DB1.table1.session DB1.ADMIN View Update Append Create Drop avail_session_perms(s) gives the set of permissions available to a user within a session avail_session_perms(s) = ⋃ {assigened_perms(r) : r ∈session_roles(s)}

Hierarchal RBAC (RH) Role Hierarchy (UA) User Assignment (PA) Permission Assignment USERS ROLES OPS OBS PRMS user_sessions session_roles SESSIONS Hierarchal RBAC

Tree Hierarchies Tree Inverted Tree Production Engineer 1 Quality Engineering Dept Engineer 2 Tree Inverted Tree Production Engineer 1 Project Lead 1 Quality Director Engineer 2 Project Lead 2

Lattice Hierarchy Production Engineer 1 Quality Engineering Dept Project Lead 1 Director Project Lead 2

RH (Role Hierarchies) < ⊆ ROLES x ROLES Natural means of structuring roles to reflect organizational lines of authority and responsibilities General and Limited Define the inheritance relation among roles i.e. r1 inherits r2 Guest -r- User r-w-h x < ⊆ ROLES x ROLES

Authorized Users Mapping of a role onto a set of users in the presence of a role hierarchy First Tier USERS set ROLE set Admin.DB1 User.DB2 User.DB3 objects User.DB1 User.DB1 View Update Append User.DB2 permissions authorized_users(r)= {u∈USRES : r’>r and (u,r’) ∈UA}

Authorized Permissions Mapping of a role onto a set of permissions in the presence of a role hierarchy PRMS set ROLES set View Update Append Create Drop SQL User.DB1 User.DB2 User.DB3 Admin.DB1 authorized_permissions: ROLE  2 PERMS authorized_permissions(r)={p∈PERMS: r’>r and (p,r) ∈PA}

General RH r1 > r2  authorized_users(r2) ⊆ authorized_users(r1) Guest Role Set Support Multiple Inheritance User Role Set Power User Role Set Admin Role Set Only if all permissions of r1 are also permissions of r2 i.e. r1 > r2 Only if all users of r1 are also users of r2 User r-w-x Guest -r- r1 > r2  authorized_users(r2) ⊆ authorized_users(r1) r1 > r2  authorized_permissions(r2) ⊆ authorized_permissions(r1)

Limiting Inheritance ┓[ ∃ r ∈ ROLES r’ < r1 and r < r2 ] Places restrictions on the immediate descendants of roles in a role hierarchy: Example: No role can inherit from Role 1 and Role 2 Role 1 Role 2 may inherits from Role 1 Role 3 does not inherit from Role1 and Role 2 Role 2 Role 3 ┓[ ∃ r ∈ ROLES r’ < r1 and r < r2 ]

Limiting the Role Hierarchy Tom AcctRec AcctRecSpv Accounting Tammy Cashier CashierSpv Fred Sally Auditing Joe Frank Billing BillingSpv Curt Tuan Accounting Role Frank has two roles: Billing and Cashier This requires the union of two distinct roles and prevents Frank from being a node to others

Constrained RBAC user_sessions (RH) Role Hierarchy session_roles (UA) User Assign- ment (PA) Permission Assignment USERS OBS OPS SESSIONS ROLES PRMS SSD DSD Constrained RBAC

Separation of Duties Enforces conflict of interest policies employed to prevent users from exceeding a reasonable level of authority for their position. Ensures that failures of omission or commission within an organization can be caused only as a result of collusion among individuals. Two Types: Static Separation of Duties (SSoD) Dynamic Separation of Duties (DSoD)

SSoD: Static Separation of Duty SSoD places restrictions on the set of roles and in particular on their ability to form UA relations. No user is assigned to n or more roles from the same role set, where n or more roles conflict with each other. A user may be in one role, but not in another—mutually exclusive. Example: Prevents a person from submitting and approving their own request for a pay hike. Specification: SSoD(rSet: 2ROLES,n:Integer) satisfying the condition ∩{r⊆rSet and |r| > n}  authorized_users(r)=Ø

Properties of SSoD A constraint on authorized users of the roles that have an SSD relation. Based on authorized users rather than assigned users. Ensures that inheritance does not undermine SSD policies. Reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles.

DSoD: Dynamic Separation of Duty Places constraints on the users that can be assigned to a set of roles, thereby reducing the number of potential permissions that can be made available to a user at any given time. Constraints can be across or within a user’s session. No user may activate n or more roles from the roles set in each user session. Note: timely revocation of role assignment will ensures that permissions do not persist beyond the time that they are required for performance of duty.

Formalizing DSoD DSoD(rSet: 2ROLE,n:Integer) ∀ rSet ⊆ ROLE ∀n∈Integer ∀s ∈ Session ∀ rS ⊆ ROLE n > 2 and DSoD(rSet,n), rS ⊆ rSet, rS ⊆ session_role(s)  |rS| < n Says that every subset rS of the set of active roles in session s must have size < n. Specifies session specific DSoD

DSoD Supervisor Roles Cashier Cashier Correct Error Supervisor inherits Cashier Reduce COI Cashier Correct Error Supervisor Closes Cashier Role session Close Cash Drawer Opens Supervisory Role session Open Cash Drawer Accounting Error

Role-Based Access Control user_sessions (RH) Role Hierarchy session_roles (UA) User Assign- ment (PA) Permission Assignment USERS OBS OPS SESSIONS ROLES PRMS SSD DSD

Specifying Pre and Post-Conditions Consider an RBAC system with the following operations: invokeRole(u:USER, s:Session, r:ROLE) rescendRole(u:USER, s:Session, r:ROLE) Maintain Tables (Predicates) Users, Roles, Permissions, UA, PA, US, SR

Specifying Pre and Post-Conditions Operations: invokeRole(u:USER, s:Session, r:ROLE) rescendRole(u:USER, s:Session, r:ROLE) Maintain Tables (Predicates): User(u), Roles(r), Perms(p), Session(s) UA(u:USER, r:ROLE), PA(r:ROLE,p:Perms) US(u:USER, s:Session), SR(s:Session,r:ROLE) SSoD(rs:2ROLE,n:Int), DSoD(rs:2ROLE,n:Int)

Pre-Conditions for invokeRole invokeRole(u:USER, s:Session, r:ROLE) Steps: Check if u, s, and r already exists u∈USER /\ s ∈ SESSION /\ r∈ROLE Check if US(u,s): US(u,s) Check static conditions: UA(u,r) exists: UA(u,r) Check if invoking r would violate DSoD DSoD(rSet,n), rS ⊆ rSet, rS ⊆session_role(s)  |rS| < n

Post-Conditions for invokeRole invokeRole(u:USER, s:Session, r:ROLE) Steps: Update US, SR: SR’ = SR U {(s,r)}