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

2. References 1. NIST documents at http://csrc.nist.gov/rbac/ http://csrc.nist.gov/rbac/ 2. 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. PDF 3. The ARBAC97 model for role-based administration of roles (1999)

3. Discretionary AC Name Access Tom Yes John No Cindy Yes Application Access List Restricts access to objects based solely on the identity of users who are trying to access them. 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 Legacy Apps

4. 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. 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

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

6. Role-Based AC IndividualsRolesResources Role 1 Role 2 Role 3 Server 1 Server 3 Server 2 User’s change frequently, Roles don’t

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

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

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

10. RBAC Core user_sessionssession_roles (UA) User Assign- ment (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS

11. USERS Proces s People: Alice Bob Cindy Processes: Intelligent Agent mailer daemon A mal-ware process

12. 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.

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

14. 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

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

16. 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.

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

18. Some Consequences UA(u,r 1 ) and r 1 > r 2  UA(u,r 2 ) PA(r 2,(ob,op)) and r 1 > r 2  PA(r 2,(ob,op)) session-role(s,r 1 ) and r 1 > r 2  session- role(s,r 1 )

19. Role Hierarchy & Constraints user_sessions (RH) Role Hierarchy session_roles (UA) User Assign- ment (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS SSD DSD

20. Separation of Duty Constraints Two kinds: Static separation of duty Static separation of duty Determined when users are assigned to roles Affects the UA(user,role) predicate Dynamic separation of duty 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.

21. Specifying Constraints staticconflict staticConflict(r 1,r 2 ): says that roles r 1 and r 2 have a static conflict Implying that they should not be assigned to the same user dynamicconflict dynamicConflict(r 1,r 2 ): says that roles r 1 and r 2 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 r 1 and r 2 in different sessions!

22. A Hierarchy of RBAC Models ModelsHierarchiesConstraints RBAC 0 NoNo RBAC 1 YesNo RBAC 2 NoYes RBAC 3 YesYes Most Complex Least Privileged Separation of Duties RBAC Model Effort RBAC 3

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

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

25. UA (user assignment) Mapping of role r onto a set of users User.DB1 View Update Append USERS set ROLES set User.DB1 permissions object User.F1 User.F2 User.F3 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

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

27. PA (perms assignment) PRMS set ROLES set User.F1 User.F2 User.F3 Admin.DB1 Mapping of role r onto a set of permissions 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

28. PA (perms assignment) PRMS setOPS set Mapping of operations to permissions 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)}

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

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

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

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

33. SESSIONS Permissions available to a user in a session. DB1.ADMIN View Update Append Create Drop SQL DB1.table1.session PRMSROLESESSION 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)}

34. Hierarchal RBAC user_sessions (RH) Role Hierarchy session_roles (UA) User Assignment (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS

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

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

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

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

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

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

41. 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 3 Role 1 Role 2 Role 2 may inherits from Role 1 Role 3 does not inherit from Role1 and Role 2 ┓ [ ∃ r ∈ ROLES r’ < r 1 and r < r 2 ]

42. Limiting the Role Hierarchy Tom AcctRec AcctRecSpv Accounting Tammy Cashier CashierSpv Fred Sally Auditing Joe Frank Billing BillingSpv CurtTuan 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

43. Constrained RBAC user_sessions (RH) Role Hierarchy session_roles (UA) User Assign- ment (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS SSD DSD

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

45. SSoD: Static Separation of Duty SSoD places restrictions on the set of roles and in particular on their ability to form UA relations. 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. 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. A user may be in one role, but not in another— mutually exclusive. Prevents a person from submitting and approving their own request for a pay hike. Example: Prevents a person from submitting and approving their own request for a pay hike. SSoD(rSet: 2 ROLES,n:Integer) satisfying the condition Specification: SSoD(rSet: 2 ROLES,n:Integer) satisfying the condition ∩{r⊆rSet and |r| > n}  authorized_users(r)=Ø

46. Properties of SSoD A constraint on authorized users of the roles that have an SSD relation. A constraint on authorized users of the roles that have an SSD relation. Based on authorized users rather than assigned users. Based on authorized users rather than assigned users. Ensures that inheritance does not undermine SSD policies. 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. 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.

47. 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. 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. 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. 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. Note: timely revocation of role assignment will ensures that permissions do not persist beyond the time that they are required for performance of duty.

48. Formalizing DSoD DSoD(rSet: 2 ROLE,n:Integer) DSoD(rSet: 2 ROLE,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

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

50. Role-Based Access Control user_sessions (RH) Role Hierarchy session_roles (UA) User Assign- ment (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS SSDDSD

51. 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

52. 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:2 ROLE,n:Int), DSoD(rs:2 ROLE,n:Int)

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

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