ISA 562 Information Security Theory and Practice Rolebased

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

References 1. 2. 3. 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 ARBAC 97 model for role-based administration of roles (1999)

Discretionary AC l Restricts access to objects based solely on the identity of users who are trying to access them. Individuals s Le g acy p Ap Resources Server 1 Server 2 Server 3 Application Access List Name Access Tom Yes John No Cindy Yes

Mandatory AC l 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 “Secret” Server 3 “Classified”

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

Role-Based AC l l 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 l Constraining Components l l Hierarchical RBAC l General l Limited l Separation l Static l Dynamic of Duty Relations

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

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

USERS Process People: • Alice • 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). Developer Budget Manager Help Desk Representative Director Many-to-many relation between Users & Permissions

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) The set of permissions that each grant the approval to perform an operation on a protected object. User. DB 1 User. F 1 • View • Update • Append • 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. l PA(r, (op, ob)): says that role r is permitted to execute operation op on object ob. l user-session(u, s): says that user u has opened session s. l session-role(s, r): iff says that some user has invoked the role r within session s. l

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

Some Consequences UA(u, r 1) and r 1 > r 2 UA(u, r 2) l PA(r 2, (ob, op)) and r 1 > r 2 PA(r 2, (ob, op)) l session-role(s, r 1) and r 1 > r 2 sessionrole(s, r 1) l

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

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

Specifying Constraints static. Conflict(r 1, r 2): says that roles r 1 and r 2 have a static conflict l Implying that they should not be assigned to the same user l dynamic. Conflict(r 1, r 2): says that roles r 1 and r 2 have a dynamic conflict l Implying that they should not be invoked in the same session by the same user l l The same user may invoke roles r 1 and r 2 in different sessions!

A Hierarchy of RBAC Models Least Privileged Separation of Duties Most Complex Models Hierarchies Constraints RBAC 0 No No RBAC 1 Yes No RBAC 2 No Yes RBAC 3 Effort RBAC Model

RBAC System and Administrative Functional Specification l Administrative Operations l l Administrative Reviews l l Create, Delete, Modify and Maintain elements and relations of the RBAC model Query operations System Level Dynamic Functions l l 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 User. F 1 User. F 2 User. F 3 User. DB 1 • View • Update • Append permissions USERS set User. DB 1 object assigned_user(r) gives the set of users assigned to the role r assigned_user(r)={u: UA(u, r)} assigned_user: ROLES 2 USERS User. DB 1

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

PA (perms assignment) Mapping of role r onto a set of permissions PRMS set ROLES set User. F 1 User. F 2 User. F 3 Admin. DB 1 • Read • Write • Execute • View • Update • Append • Create • Drop SQL 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) Mapping of operations to permissions OPS set public int read(byte. Buffer dst) throws IOException PRMS set READ Inherited methods from java. nio. channls close() is. Open() 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 BLD 1. door 2 Gives the set of objects with the permission ob(p: PERMS) {ob∈ OBJECT: p=(obj, op)} SQL DB 1. table 1

SESSIONS The set of sessions that each user invokes. est SESSION admin FIN 1. report 1 gu USER es in k vo SQL user DB 1. table 1 APP 1. desktop

SESSIONS The mapping of user u onto a set of sessions. USERS SESSION t es gu User 2. FIN 1. report 1. session USER 1 es k vo in admin SQL User 2. DB 1. table 1. session user USER 2 User 2. APP 1. desktop. session user_sessions(u: USERS) 2 SESSIONS

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

SESSIONS Permissions available to a user in a session. ROLE DB 1. ADMIN PRMS • View • Update • Append • Create • Drop SESSION SQL DB 1. table 1. session 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)}

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

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

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

RH (Role Hierarchies) l l l Natural means of structuring roles to reflect organizational lines of authority and responsibilities General and Limited Define the inheritance relation among roles i. e. r 1 inherits r 2 User r-w-h Guest -r- < ⊆ 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. DB 1 User. DB 2 User. DB 3 User. DB 1 • View • Update • Append objects permissions authorized_users(r)= {u∈USRES : r’>r and (u, r’) ∈UA} User. DB 1 User. DB 2

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

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

Limiting Inheritance 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 Role 1 and Role 2 Role 3 ┓[ ∃ r ∈ ROLES r’ < r 1 and r < r 2 ]

Limiting the Role Hierarchy Fred Tom Acct. Rec. Spv Acct. Rec Curt Sally Joe Auditing Tammy Cashier Accounting Tuan Cashier. Spv Frank Billing. Spv Billing 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

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

Separation of Duties l l l 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: l l Static Separation of Duties (SSo. D) Dynamic Separation of Duties (DSo. D)

SSo. D: Static Separation of Duty l l l SSo. D 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: SSo. D(r. Set: 2 ROLES, n: Integer) satisfying the condition ∩{r⊆r. Set and |r| > n} authorized_users(r)=Ø

Properties of SSo. D l l 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.

DSo. D: Dynamic Separation of Duty l l 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 DSo. D l l DSo. D(r. Set: 2 ROLE, n: Integer) ∀ r. Set ⊆ ROLE ∀n∈Integer ∀s ∈ Session ∀ r. S ⊆ ROLE n > 2 and DSo. D(r. Set, n), r. S ⊆ r. Set, r. S ⊆ session_role(s) |r. S| < n Says that every subset r. S of the set of active roles in session s must have size < n. Specifies session specific DSo. D

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

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

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

Specifying Pre and Post-Conditions Operations: l invoke. Role(u: USER, s: Session, r: ROLE) l rescend. Role(u: USER, s: Session, r: ROLE) Maintain Tables (Predicates): l User(u), Roles(r), Perms(p), Session(s) l UA(u: USER, r: ROLE), PA(r: ROLE, p: Perms) l US(u: USER, s: Session), SR(s: Session, r: ROLE) l SSo. D(rs: 2 ROLE, n: Int), DSo. D(rs: 2 ROLE, n: Int)

Pre-Conditions for invoke. Role(u: USER, s: Session, r: ROLE) l Steps: 1. 2. 3. 4. 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: 1. UA(u, r) exists: UA(u, r) Check if invoking r would violate DSo. D(r. Set, n), r. S ⊆ r. Set, r. S ⊆session_role(s) |r. S| < n

Post-Conditions for invoke. Role(u: USER, s: Session, r: ROLE) l Steps: 1. Update US, SR: SR’ = SR U {(s, r)}