ISA 562 Information Security Theory and Practice

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

2. 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)

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

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. 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 2 “Secret” Server 3 “Classified”

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

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

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

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

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

11. USERS Process • 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 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

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) • User.DB1 • View • Update • Append • User.F1 • Read • Write • Execute permissions permissions object object The set of permissions that each grant the approval to perform an operation on a protected object. 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 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

18. 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)

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

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

21. Specifying Constraints staticConflict(r1,r2): says that roles r1 and r2 have a staticconflict Implying that they should not be assigned to the same user dynamicConflict(r1,r2): says that roles r1 and r2 have a dynamicconflict 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!

22. A Hierarchy of RBAC Models Least Privileged Separation of Duties Most Complex RBAC3 Effort RBAC Model

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

24. 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)

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

26. PA (perms assignment) 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

27. PA (perms assignment) 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

28. PA (perms assignment) 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)}

29. 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)}

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

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

32. 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}

33. SESSIONS SQL DB1.table1.session DB1.ADMIN Permissions available to a user in a session. ROLE PRMS SESSION • 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)}

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

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

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

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

38. 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}

39. Authorized Permissions Mapping of a role onto a set of permissions in the presence of a role hierarchy PRMSset 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}

40. General RH 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)

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 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 ]

42. Limiting the Role Hierarchy Fred Curt Tuan Tom AcctRecSpv Sally Joe Tammy CashierSpv Frank BillingSpv Billing AcctRec Auditing Cashier Accounting 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. SSD (RH) Role Hierarchy (UA) User Assign- ment (PA) Permission Assignment USERS ROLES OPS OBS PRMS user_sessions session_roles SESSIONS DSD Constrained RBAC

44. 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)

45. 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 nor 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)=Ø

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

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

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

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

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