Role-Based Access Control Standard ANSI INCITS 359-2004 James Joshi, Associate Professor University of Pittsburgh Hi I am James Joshi, Associate Professor at the University of Pittsburgh, and welcome to this module on Role Based Access Control standard. The ANSI INCITS 359-2004 model. In this module we will overview the RBAC model and the various features it provides.

Access Control Access Control refers to Ensuring principals are allowed or denied privileges to access resources Basic Access Control Matrix model Subjects: Active entities (rows) E.g., user processes Objects: Passive entities (columns) E.g., files Rights: refers to access mode entries in each matrix cell representing what action a subject can perform on the corresponding object Confidentiality Authorized to read We start with a quick overview of Access Control models. Access control refers to making sure an information system appropriately authorizes different principals or subjects to different protected resources. There has been a lot of work in the area of Access control models. One of the very basic/generic access control model is the Access Control Matrix model – it defines a set of subjects which represent active entities that perform some operations (for instance, a subject maybe a user process in a system) , a set of objects that represent passive entities on which some actions maybe performed (for instance, files) and a set of rights that represent set of operations that are authorized for a subject over available objects. Access control models address the need for ensuring the confidentiality and integrity requirements of systems by restricting Read and Write or Modify privileges. Integrity Authorized to modify

Access Control Matrix Here is an example of an access control matrix. The rows represent subjects and The columns represent objects. Each cell contains the rights that the corresponding subject has over the corresponding object. Given a system there might a huge matrix and many of the cells may be empty – and hence for actual implementation, one of the two approaches is often used. The first approach is the “Capabilities” based approach where one list is maintained for each subject as shown. In the ACL based approach, a separate list is maintained for each object.

Access Control Models Several models exist Some models Discretionary Access Control (DAC) Model Users can give rights to other users Mandatory Access Control (MAC) model System enforces mandatory rules Some models Bell LaPadula model Biba model of integrity Clark-wilson model Chinese wall model DAC is too flexible and MAC is often too restrictive Researchers have looked for more flexible and more expressive models RBAC has been considered a better Various access control models have been proposed in the literature to capture the diverse requirements of different application domains. These traditional access control models can be categorized as Discretionary Access Control or DAC models and Mandatory Access Control or MAC models. In a DAC model, a user typically has the discretionary power to share the rights that he has with other users. In a MAC model, however, a user does not have such a discretionary power – instead the rights and its use are controlled by system enforced rules. Some models are as listed here. In general, most of the traditional DAC models have been found to be too flexible and MAC models too restrictive. There has been a lot of efforts towards developing models that are flexible and expressive and can be generic enough to support different types of organizational access control policies. Role based access control has been found to be a promising approach in this direction.

RBAC: Role Based Access Control Access control in organizations is based on “roles that individual users take on as part of the organization” Access depends on function, not identity Example: Allison is bookkeeper for Math Dept. She has access to financial records. She leaves and Betty is hired as bookkeeper The role of “bookkeeper” dictates access, not the identity of the individual. A role is “is a collection of permissions” The basic premise of the role-based access control approach is the fact that access privileges in an organization are typically distributed to users based on what roles they play in the organization. That is, access rights need to be authorized to users based on the functions that he needs to engaged in and not solely based on his identity. For example, say Allison is a .. BK Access privileges

RBAC – two key advantages Total number Of assignments n + m n x m Role hierarchy

RBAC standard Standards efforts Annual ACM RBAC Workshop – in 1990s NIST Standard proposed in 2001 (TISSEC) XACML Profile for RBAC ANSI INCITS 359-2004 RBAC standard in 2004 The ANSI standard consists of two parts Reference Model System and Administrative Functional Specification

ANSI RBAC standard – Reference Model Basic elements of the model Users, Roles, Permissions, Relationships Four model components Core RBAC Hierarchical RBAC Static Separation of Duty RBAC Dynamic Separation of Duty RBAC

Core RBAC Permissions UA PA Users Roles Operations Objects user_sessions (one-to-many) role_sessions (many-to-many) Sessions

Core RBAC (relations) Permissions = 2Operations x Objects UA ⊆ Users x Roles PA ⊆ Permissions x Roles assigned_users: Roles  2Users assigned_permissions: Roles  2Permissions Op(p): set of operations associated with permission p Ob(p): set of objects associated with permission p user_sessions: Users  2Sessions session_user: Sessions  Users session_roles: Sessions  2Roles session_roles(s) = {r | (session_user(s), r)  UA)} avail_session_perms: Sessions  2Permissions

Hierarchical RBAC RH (role hierarchy) Permissions UA PA Users Roles Operations Objects user_sessions (one-to-many) role_sessions (many-to-many) Sessions

Role Hierarchy General Role Hierarchy Limited Role hierarchy Inheritance from multiple roles allowed Limited Role hierarchy No multiple inheritances Single immediate descendant

General Role Hierarchy A role can inherit from multiple roles RH ⊆ Roles x Roles is a partial order called the inheritance relation written as ≥. (r1 ≥ r2)  authorized_users(r1) ⊆ authorized_users(r2) & authorized_permisssions(r2) ⊆ authorized_permisssions(r1) authorized_users: Roles 2Users authorized_users(r) = {u | r’ ≥ r &(r’, u)  UA} authorized_permissions: Roles 2Permissions authorized_permissions(r) = {p | r ≥ r’ &(p, r’) PA}

Limited Role Hierarchy Imposes restriction on the immediate descendents of the general role hierarchy That is, Limited role hierarchy is a General role hierarchy with the following limitation  r, r1, r2 , r2  Roles, r ≥ r1  r ≥ r2  r1  r ≥ r2 In Limited Role hierarchy, a role can have only one descendent

Example authorized_users(Employee)? authorized_users(Administrator)? authorized_permissions(Employee)? authorized_permissions(Administrator)? e10 e8, e9 e5 pp e3, e4 e6, e7 po pa, pb e1, e2 px, py pm, pn p1, p2

Constrained RBAC: SSD RBAC & DSD RBAC RH (role hierarchy) Static Separation of Duty Permissions UA PA Users Roles Operations Objects user_sessions (one-to-many) Dynamic Separation of Duty Sessions

Separation of Duty SoD Security principle Example, Widely recognized Captures conflict of interest policies to restrict authority of a single authority Prevent Fraud Example, A single person should not be allowed to “approve a check” & “cash it”

Static Separation of Duty Example: ({r1, r2}, 2) SSD SSD ⊆2Roles x N In absence of hierarchy Collection of pairs (RS, n) where RS is a role set, n ≥ 2 for all (RS, n)  SSD, for all t ⊆RS: |t| ≥ n  ∩rt assigned_users(r)=  Example Assume u1, u2, u3 are assigned to r1 Assume u2, u4 are assigned to r2 Is ({r1, r2}, 2)  SSD valid?

Static Separation of Duty Example: ({r1, r2, r3}, 2) SSD SSD ⊆2Roles x N In presence of hierarchy Collection of pairs (RS, n) where RS is a role set, n ≥ 2; for all (RS, n)  SSD, for all t ⊆RS: |t| ≥ n  ∩rt authorized_uers(r)=  Example Assume u1, u2, u3 are assigned to r1 Assume u4 are assigned to r2 Is ({r1, r2}, 2)  DSD valid? What if u2 is assigned to r3 and r3 ≥ r2

Dynamic Separation of Duty DSD ⊆2Roles x N Collection of pairs (RS, n) where RS is a role set, n ≥ 2; A user cannot activate n or more roles from RS What is the difference between SSD or DSD containing: (RS, n)? Consider (RS, n) = ({r1, r2, r3}, 2)? If SSD – can r1, r2 and r3 be assigned to u? If DSD – can r1, r2 and r3 be assigned to u?

ANSI RBAC standard – Functional specification Administrative operations Creation and maintenance of sets and relations Administrative review functions To perform administrative queries System level functionality Creating and managing RBAC attributes on user sessions and making access decisions

Functional components for CORE RBAC Administrative commands AddUser Delete User AddRole Delete Role GrantPermissions RevokePermissions AssignUser DeassignUser CreateSession DeleteSession AddActiveRole DropActiveRole Supporting System functins CreateSession, DeleteSession, AddActiveRole, DropActive Role, CheckAccess

Functional components for CORE RBAC Review functions AssignedUSers AssignedRoles RolePermissions UserPermissions SessionRoles SessionPermissions RoleOperationsOnObject UserOperationOnObject For other RBAC Extended/redefined set with regards to inheritance Extended/redefined with regards to SSD/DSD

Functional Specification Package Core RBAC Hierarchical RBAC (a) General (b) Limited Methodology for Creating functional packages SSD Relations (a) w/Hierachy (b)wo/Hierarchy DSD Relations

Advantages of RBAC Allows Efficient Security Management Administrative roles, Role hierarchy Principle of least privilege allows minimizing damage Separation of Duty constraints to prevent fraud Allows grouping of objects / users Policy-neutral - Provides generality Encompasses DAC and MAC policies

RBAC’s Economic Benefits

Cost Benefits Saves about 7.01 minutes per employee, per year in administrative functions Assume Average IT admin salary - $59.27 per hour The annual cost saving is: $6,924/1000; $692,471/100,000

Quantified Economic Benefits NIST did an economic benefit survey analysis in 2009 More efficient provisioning by network and systems administrators, Reduced employee downtime from more efficient provisioning, and More efficient access control policy maintenance and certification

Quantified Economic Benefits Quantified economic benefits of RBAC for adopting firms, per employee From NIST Report: 2010 Economic Analysis of Role-Based Access Control

RBAC Extensions Several Extensions have been made to make RBAC applicable to different application scenarios TRBAC/GTRBAC (time based RBAC0 LoT/Geo RBAC (Location based) GeoSocial RBAC Privacy aware RBAC Etc.

Summary Overview of ANSI RBAC standard Four component models Functional Specification Advantages and Economic benefits