# Presentation: 009440

## Proposal for Fast-TrackingNIST Role-Based Access Control Standard

- David Ferraiolo
- Rick Kuhn
- National Institute of Standards and Technology
- Gathersburg, Maryland
- Ravi Sandhu
- George Mason University
- Fairfax, Virginia

## Agenda

- Why an RBAC Standard?
- Is the Standard Ready to Go?

## Some of the Vendors Offering RBAC Products

## Accurate Configuration Control Over User Privileges

**Lots of users and privileges scattered over many platforms and applications.**
**Who are the valid users?**
**What are they entitled to access?****How do you keep access rights up-to-date?**
**How do you specify and enforce policy?**

**Notes:**
Wherever I go, I ask two questions:
What is the most important asset of your company?    They kind of hem and haw.  If I’m talking to a bank they might initially say my holdings; if I’m talking to a manufacturer company, they might say my incredible manufacturing plant.  But when you really push them, it will get down to the answer being my people.  
Whether it’s their employees, their customers, their contractors, or their partners, ultimately it’s the people.  Why?  Gartner has done studies that state that over 85% of any information about a corporation is inside somebody’s head.  Only 15% of the corporation’s information is actually in repositories, in databases, on the web, in some kind of a manual infrastructure.  So if 85% of the intelligence around how companies work is in people’s head, it’s pretty easy to see why people are the most important asset of a company.
Then the next question I ask is “what’s your biggest challenge?”  You get everything from Greenspan’s killing me, we just had an earthquake 2 days ago and that’s killing me, to XYZ Corporation, my competitor, did this and that’s really killing me.  But when you really circle around it, it’s change.  If you really think about it, what company have you ever worked for that has not required you to rethink or change how you do something, who you do it with, what tools you get to use?  Every time there is a government regulation change, natural or manmade disaster, economic or currency fluctuation, competitive pressure, the CEO woke up with a headache, there’s some other reason, but ultimately, it how fast a company can react or proact to change while still maintaining policy, still ensuring security, and still dealing with privacy issues.  It’s the timing and the accuracy of access that really predicates the success that dictates how effective or ineffective that you are going to be.  

## Maintaining Access Configurations is Labor-Intensive

**Estimated Privilege distribution Activity ****in Typical Companies**

**Adding IT Staff Scales Linearly**
**Administering Privileges Scales Non-Linearly**
**Symptoms of the problem**
**Unused accounts proliferate**
**Turn-on time rises for user privilege creation**
**Privilege review is impractical**
**Security audits fail**
**User down-time increases**
**Security admin requests staff increases**
**Help desk requests staff increases**

## Manually Configuring Privileges

**Organizations use slow and inconsistent processes to create user access rights**

**User Change**

**Notes:**
The manual process for provisioning poses a huge challenge for today’s businesses.   Believe it or not, most companies still use manual processes to provision access rights to users.

 Build 1	First, when an employee is hired, a new user profile is created and stored in an HR database.
 Build 2 	A request for access is created.
 Build 3	The user profile is compared to a company’s role-authorization policies.
 Build 4	The request is then routed for the necessary approval, and 
 Build 5	Sent to the IT department if approval is granted. 
 Build 6	Finally, the IT department submits the approved request to various system administrators to provision user access rights.
 Build 7	The user is provisioned and the approval is recorded in a history file.

Key Point: 	Manual provisioning can take up to 12 days for each user. 

## RBAC Supports Front-End Processes

**Maintain who gets what based on your organization’s operational policies**

**User Change**

**Notes:**
The manual process for provisioning poses a huge challenge for today’s businesses.   Believe it or not, most companies still use manual processes to provision access rights to users.

 Build 1	First, when an employee is hired, a new user profile is created and stored in an HR database.
 Build 2 	A request for access is created.
 Build 3	The user profile is compared to a company’s role-authorization policies.
 Build 4	The request is then routed for the necessary approval, and 
 Build 5	Sent to the IT department if approval is granted. 
 Build 6	Finally, the IT department submits the approved request to various system administrators to provision user access rights.
 Build 7	The user is provisioned and the approval is recorded in a history file.

Key Point: 	Manual provisioning can take up to 12 days for each user. 

## Installed Technology Base

- 	Access Control List (ACL) are the most common access control mechanism in use today
- Fine when end-users are viewed as “owners” of enterprise resources
- Resource Oriented: poorly organized to address many commercial and Government security policies
- Costly and difficult to centrally administrate
- At the wrong level of abstraction
- Platform Dependent with proprietary administrative tools

## Role-Based Access Control – A Strategy for Security Policy Management

- Centrally administered and locally enforced role based access control policies
- Policy Rich: highly configurable (richer set of parameters)
- Enforces access control across the virtual enterprise
- Employees
- Suppliers
- Consultants
- Role membership is based on Competency, Duty, Authority, giving the user’s the potential to execute privileges
- Role centric (roles are global and persistent)

## Motivations

- Simple and Intuitive Administrative Interface
- Administrative Efficiency
- Automatic user privilege assignment
- Automatic revocation of user privilege
- Simple user functional re-assignment
- Administrative Flexibility
- Static Separation of duty (SSD)
- Fine granularity of resource/administration partitioning
- Scalability, Extensibility, Accuracy
- Agreement of core RBAC Features
- For Each RBAC feature in the standard there are one or more known implementations
- Broad industry involvement in ACM RBAC Workshops

## Background

- NIST study reviewed the access control practices of 30 large organizations
- First RBAC model published in 1992
- Combined several existing and emerging concepts (OS user groups, DBMS privilege groups [Baldwin90], separation of duty [Clark-Wilson87, Sandhu88, Brewer-Nash89] into a single relational model [Ferraiolo-Kuhn92]
- Reference implementation led to a revision [Ferraiolo-Cugini-Kuhn95]
- Annual ACM RBAC Workshop series started in 1995 with international vendor and researcher participation
- Sandhu et al, developed a well accepted comprehensive RBAC framework in 96
- Sybase implemented most of NIST RBAC model in 1996, DBMS survey showed other vendors have RBAC features
- Based on these efforts numerous other models have been proposed that have often included reference implementations

## Background

- Since 1995 vendors, users, and researchers have gathered on an annual basis to present papers and discuss issues related to RBAC, in a formal ACM workshop setting
- RBAC has matured to the point where it is being consistently prescribed as a generalized approach to access control
- “the most attractive solution for providing security in e-government” IEEE COMPUTER, Feb. 2001
- “most relevant in meeting complex policy needs of Web-based applications” ACM COMMUNICATIONS, Feb. 2001
- First effort to define a consensus standard for RBAC was proposed in a special session at the 5th ACM Workshop on RBAC
- Published comments resulted in the existing proposed standard

## Diffusion of RBAC - 2001

## Estimated Use of RBAC in 2005 - by industry (mid-range est)

## Timeliness & Appropriateness of RBAC Standard

- Need for consistent, universally understood semantics for RBAC
- Vendors value “establishing a taxonomy and a shared vocabulary for us, our customers, and the industry as a whole”

## Is RBAC ready for a standard?

- Network Applications Consortium - $500,000,000,000 customer base says:**“If RBAC is going to ‘move to the mainstream’, then there will have to be some sort of standard.”**

## Current Situation - Problem

- Although existing models and implementations use similar RBAC concepts, they differ in significant areas and use different terminology
- RBAC is a rich and open-ended technology, ranging from the very simple to the complex
- Not all features are appropriate for all environments
- No vendors implement all RBAC features
- Research continues to promote its use in other applications and extended features

## Solution - RBAC Standard

- Standardization over a collection of basic and well accepted RBAC features
- Features are divided into logical components and sub-components
- Sub-components can be combined into relevant packages giving:
- IT consumers a basis for uniform acquisition specification and a basis for making purchasing decisions
- Vendors a set of benchmarks use in the characterization and marketing of their products
- Each feature is known to be viable in that there exists at least one example commercial and/or reference implementation

## Standard Organization

- Two Main Parts
-     -- RBAC Reference Models
-     -- Requirement Specification
- Four Components
-     -- Core RBAC
-     -- Hierarchical RBAC
-         --- Limited Hierarchies
-         --- General Hierarchies
-     -- Static Separation of Duty Relations
-         --- Without Hierarchies
-         --- With Hierarchies
-     -- Dynamic Separation of Duty Relations

## Conformance 	

- Standard provides for conformance by vendor self-declaration
- Standard provides foundation for third-party conformance testing sought by vendors and customers

## Requirement Specification

- Requirements are specified using the relations defined by the reference model
- Administrative Operations
-     (e.g., create/delete role, create/delete user assignment, create/delete hierarchical relation)
- Administrative Queries and Review Functions
-      (e.g., assigned users, assigned roles, authorized users, authorized permissions, separation of duty relations)
- System Functions
-     (e.g., session management, access calculation)

## Methodology for Creating 

- Core RBAC

- Hier. RBAC
- a. Limited
- b. General

- SSD Relations
- a. w/hierarchies
- b. wo/hierarchies

-  DSD Relations

**Requirements**
**Package**

- Select Core RBAC
- Option: Advanced Review

- Choose a. or b
- Option: Advanced Review

- Adhere to dependency

**Methodology for Creating **
**Requirement Packages**

## Conclusion RBAC is ready for a standard

- User need - $500,000,000,000 customer base says:**“If RBAC is going to ‘move to the mainstream’, then there will have to be some sort of standard.” – NAC**
- Vendors - At least 28 vendors offer some type of RBAC product
- Future solutions - “the most attractive solution for providing security in e-government” IEEE COMPUTER, Feb. 2001

## Additional Information on Standard Components

- Core RBAC
- Hierarchical RBAC
- Role Inheritance
- Static Separation of Duty
- Dynamic Separation of Duty

## Core RBAC

** **Many-to-many relationship among individual users and privileges
-  Session is a mapping between a user and an activated subset of assigned roles
-   User/role relations can be defined independent of role/privilege relations
-   Privileges are system/application dependent
-  Accommodates traditional but robust group-based access control

**USERS**

**ROLES**

**OPERA**
**TIONS**

**OBJECTS**

***privileges***

- (*UA*) User Assignment

- (*PA*)
- Permission Assignment

**Sess-**
**ions**

*user_sessions*

*session_roles*

## Hierarchical RBAC

-  Role/role relation defining user membership and privilege inheritance
-  Reflects organizational structures and functional delineations
-  Two types of hierarchies:
- -  Limited hierarchies
- -  General hierarchies

**USERS**

**ROLES**

**OPERA**
**TIONS**

**OBJECTS**

***privileges***

- (*UA*) User Assignment

- (*PA*)
- Permission Assignment

**Sess-**
**ions**

*user_sessions*

*session_roles*

- Role Hierarchy

## Role Inheritance

**Doctor**

**Cardiologist**

**“****contains”**

**“****contains”**

**“****contains”**

**Specialist**

**“****contains”**

**Employee**

**Dermatologist**

**p**
**r**
**i**
**v**
**i**
**l**
**e**
**g**
**e**

**m**
**e**
**m**
**b**
**e**
**r**
**s**
**h**
**i**
**p**

- NIST Secretary

- ITL Secretary

- MEL Secretary

- CSD Secretary

- Comp Security Division

- a-Limited Hierarchies

- Added Advantages:
-  User’s can be included on edges of graph
-  Role’s can be defined from the privileges
-    of two or more subordinate roles

- b-General Hierarchies

- Jill

## Static Separation of Duty

**USERS**

**ROLES**

**OPERA**
**TIONS**

**OBJECTS**

***privileges***

- Role Hierarchy

- (UA) User
- Assignment

- (PA) Permission
- Assignment

**SES-**
**SIONS**

*session_roles*

*user_sessions*

- SoD policies deter fraud by placing constrains on administrative actions and there by restricting combinations of privileges that are available to users
- E.g., no user can be a member of both Cashier and AR Clerk roles in Accounts Receivable Department

- SSD

## Dynamic Separation of Duty

**USERS**

**ROLES**

**OPERA**
**TIONS**

**OBJECTS**

***privileges***

- Role Hierarchy

- User Assign-
- ment

- Permission
- Assignment

**SES-**
**SIONS**

*session_roles*

*user_sessions*

- Dynamic
- Separation of Duty

- DSoD policies deter fraud by placing constrains on the roles that can be activated in any given session there by restricting combinations of privileges that are available to users
- E.g., No user can active both cashier and cashier supervisor role although the user maybe assigned to both
- Valuable in the Enforcement of least privilege