1 of 35

Role-Based Access Control

user_sessions

(RH)

Role Hierarchy

session_roles

(UA)

User Assign-

ment

(PA)

Permission

Assignment

USERS

OBS

OPS

SESSIONS

ROLES

PRMS

SSD

DSD

2 of 35

Access Controls - Basics

Access Control a system to control, monitor and restrict the movement of people, assets or vehicles around a building or site

Access Control types

Discretionary Access Control
Mandatory Access Control
Role-Based Access Control

http://www.ifour-consultancy.com

Offshore software development company India

3 of 35

Discretionary AC

Restricts access to objects based solely on the identity of users who are trying to access them.

Name Access

Tom Yes

John No

Cindy Yes

Application

Access List

Individuals

Resources

Server 1

Server 3

Server 2

Legacy Apps

http://www.ifour-consultancy.com

Offshore software development company India

4 of 35

Mandatory AC

Individuals

Resources

Server 1

“Top Secret”

Server 3

“Classified”

Server 2

“Secret”

SIPRNET

Legacy Apps

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.

Better security than DAC

http://www.ifour-consultancy.com

Offshore software development company India

5 of 35

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 job authority and responsibilities within a job function.

Operations on an object are invocated based on the permissions.

The object is concerned with the user’s role and not the user.

“Ideally, the [RBAC] system is clearly defined and agile, making the addition of new applications, roles, and employees as efficient as possible”

http://www.ifour-consultancy.com

Offshore software development company India

6 of 35

Role-Based AC

Individuals

Roles

Resources

Role 1

Role 2

Role 3

Server 1

Server 3

Server 2

User’s change frequently, Roles don’t

http://www.ifour-consultancy.com

Offshore software development company India

7 of 35

Rules of RBAC

Three primary rules are defined for RBAC:

Role assignment
Role authorization
Permission authorization

http://www.ifour-consultancy.com

Offshore software development company India

8 of 35

RBAC Variance

RBAC Model

Effort

RBAC₃

A family of RBAC with four models

RBAC0: min functionality
RBAC1: RBAC0 plus role inheritance
RBAC2: RBAC0 plus constraints

(restrictions on RBAC configuration)

4. RBAC3: RBAC0 plus all of the above

http://www.ifour-consultancy.com

Offshore software development company India

9 of 35

Role-Based AC Framework

Core Components

Constraining Components

Hierarchical RBAC

General
Limited

Separation of Duty Relations

Static
Dynamic

http://www.ifour-consultancy.com

Offshore software development company India

10 of 35

Core Components

Defines:

USERS
ROLES
OPERATIONS (ops)
OBJECTS (obs)
User Assignments (ua)

assigned_users

Permissions (prms)

Assigned Permissions
Object Permissions
Operation Permissions

Sessions

User Sessions
Available Session Permissions
Session Roles

http://www.ifour-consultancy.com

Offshore software development company India

11 of 35

Constraint Components

Role Hierarchies (rh)

General
Limited

Separation of Duties

Static
Dynamic

http://www.ifour-consultancy.com

Offshore software development company India

12 of 35

Core RBAC

user_sessions

session_roles

(UA)

User Assign-

ment

(PA)

Permission

Assignment

USERS

OBS

OPS

SESSIONS

ROLES

PRMS

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

http://www.ifour-consultancy.com

Offshore software development company India

13 of 35

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

http://www.ifour-consultancy.com

Offshore software development company India

14 of 35

PA (prms assignment)

A prms can be assigned to one or more roles

Admin.DB1

PRMS set

ROLES set

A role can be assigned

to one or more prms

User.DB1

View

Update

Append

Create

Delete

Drop

http://www.ifour-consultancy.com

Offshore software development company India

15 of 35

SESSIONS Assignment

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

http://www.ifour-consultancy.com

Offshore software development company India

16 of 35

SESSIONS Assignment

The mapping of session s onto a set of roles

SESSION

ROLES

Admin
User
Guest

SQL

DB1.table1.session

http://www.ifour-consultancy.com

Offshore software development company India

17 of 35

user_sessions

(RH)

Role Hierarchy

session_roles

(UA)

User Assign-

ment

(PA)

Permission

Assignment

USERS

OBS

OPS

SESSIONS

ROLES

PRMS

Hierarchal RBAC

Role Hierarchies (rh)

General

Limited

http://www.ifour-consultancy.com

Offshore software development company India

It adds requirements for supporting role hierarchies. A hierarchy is mathematically a partial order defining a seniority relation between roles, whereby the seniors roles acquire the permission of their juniors, and junior roles acquire the user membership of their seniors. This standard recognizes two types of role hierarchies

General Hierarchical RBAC: In this case, there is support for an arbitrary partial order to serve as role hierarchy, to include the concept of multiple inheritance of permissions and user membership among roles.

Limited Hierarchical RBAC: Some systems may impose restrictions on the role hierarchy. Most commonly, hierarchies are limited to simple structures such as trees and inverted trees

Offshore software development company India – http://www.ifour-consultancy.com

18 of 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

http://www.ifour-consultancy.com

Offshore software development company India

19 of 35

Lattice Hierarchy

Production

Engineer 1

Quality

Engineer 1

Engineering Dept

Production

Engineer 2

Quality

Engineer 2

Project Lead 1

Director

Project Lead 2

Upper roles have all the access rights of the lower roles as well other access rights not available to a lower role

20 of 35

General RH

User

r-w-h

Guest

-r-

Only if all permissions of r₁ are also permissions of r₂

Only if all users of r₁ are also users of r₂

i.e. r1 inherits r2

Guest Role Set

Power User Role Set

User Role Set

Admin Role Set

Support Multiple Inheritance

http://www.ifour-consultancy.com

Offshore software development company India

General role hierarchies support the concept of multiple inheritance, which provides the ability to inherit permission from two or more role sources and to inherit user membership from two or more role sources. Multiple inheritances provide important hierarchy properties.

The first is the ability to compose a role from multiple subordinate roles (with fewer permissions) in defining roles and relations that are characteristic of the organization and business structures, which these roles are intended to represent.

Second, multiple inheritances provide uniform treatment of user/role assignment relations and role/role inheritance relations. Users can be included in the role hierarchy, using the same relation to denote the user assignment to roles, as well as permission inheritance from a role to its assigned users.

General role hierarchies support the concept of multiple inheritance, which provides the ability to inherit permission from two or more role sources and to inherit user membership from two or more role sources. Multiple inheritances provide important hierarchy properties.

The first is the ability to compose a role from multiple subordinate roles (with fewer permissions) in defining roles and relations that are characteristic of the organization and business structures, which these roles are intended to represent.

Second, multiple inheritances provide uniform treatment of user/role assignment relations and role/role inheritance relations. Users can be included in the role hierarchy, using the same relation to denote the user assignment to roles, as well as permission inheritance from a role to its assigned users.

Offshore software development company India – http://www.ifour-consultancy.com

21 of 35

Limited RH

A restriction on the immediate descendants of the general role hierarchy

Role1

Role2

Role3

Role2 inherits from Role1

Role3 does not inherit from

Role1 or Role2

http://www.ifour-consultancy.com

Offshore software development company India

22 of 35

user_sessions

(RH)

Role Hierarchy

session_roles

(UA)

User Assign-

ment

(PA)

Permission

Assignment

USERS

OBS

OPS

SESSIONS

ROLES

PRMS

SSD

DSD

Constrained RBAC

Static

Dynamic

http://www.ifour-consultancy.com

Offshore software development company India

23 of 35

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 (SSD)
Dynamic Separation of Duties (DSD)

http://www.ifour-consultancy.com

Offshore software development company India

24 of 35

SSD

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

Prevents a person from submitting and approving their own request.

http://www.ifour-consultancy.com

Offshore software development company India

Separation of duty relations are used to enforce conflict of interest policies. Conflict of interest in a role-based system may arise as a result of a user gaining authorization for permissions associated with conflicting roles.

One means of preventing this form of conflict of interest is though static separation of duty (SSD), that is, to enforce constraints on the assignment of users to roles.

An example of such a static constraint is the requirement that two roles be mutually exclusive; for example, if one role requests expenditures and another approves them, the organization may prohibit the same user from being assigned to both roles.

The SSD policy can be centrally specified and then uniformly imposed on specific roles. Because of the potential for inconsistencies with respect to static separation of duty relations and inheritance relations of a role hierarchy, we define SSD requirements both in the presence and absence of role hierarchies

Offshore software development company India – http://www.ifour-consultancy.com

25 of 35

SSD in Presence of RH

A constraint on the authorized users of the roles that have an SSD relation.

Based on the 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.

http://www.ifour-consultancy.com

Offshore software development company India

26 of 35

DSD

Places constraints on the users that can be assigned to a set of roles, thereby reducing the number of potential permission that can be made available to a user.

Constraints are across or within a user’s session.

No user may activate n or more roles from the roles set in each user session.

Timely Revocation of Trust ensures that permission do not persist beyond the time that they are required for performance of duty.

http://www.ifour-consultancy.com

Offshore software development company India

27 of 35

RBAC Defense in Depth

http://www.ifour-consultancy.com

Offshore software development company India

28 of 35

RBAC for GIAC Enterprises

The small scale of GIAC Enterprises is both a plus and minus for implementing RBAC

Smaller companies will most likely mean users will be assuming multiple roles within the organization thus making it difficult to create static roles for each users or process.

At first glance the implementation of RBAC in a company with under 10 employees may seem simple. If roles are not properly identified and categorized, scalability becomes a problem. The sooner you can implement principles of least privilege and segregation of duties, the more reliable your process will become.

At a high level GIAC Enterprises can be broken into four divisions

Business (CEO, CFO, Sales Manager, Product Manager)
Development (Developer)
Administration (System Administrator)
Audit (External Resource)

http://www.ifour-consultancy.com

Offshore software development company India

29 of 35

RBAC in the DMZ

The DMZ houses the Email gateway, IPS, Web Server, and MetaFrame Presentation Server

Windows systems (Email, MetaFrame) use Active Directory (AD) for maintaining role-based access controls

Linux systems (Web, App, IPS) use Vintela Authentication Services (VAS) which sits on the AD framework for administering role-based access controls

Within AD, the following roles are defined specific to the DMZ:

User - read-only access to web pages
Administrator - read/write access to deploy changes made by developer
Auditor – read-only access to specified systems

http://www.ifour-consultancy.com

Offshore software development company India

30 of 35

RBAC for Internal Systems

Access to the majority of GIAC Enterprise’s internal systems (Email, File, HR, Antivirus, DC, DNS) is governed by Windows Active Directory (AD)

Access to the Linux/Apache web server and the Solaris/Weblogic App Server is controlled via Vintela Authentication Services (VAS) managed through AD

Internally the following roles are defined:

User - read-only access to web pages
Administrator - read/write access to deploy changes to production after they’ve been made by a developer
Developer – read/write access to development partitions of web/app/db servers
Auditor – read-only access to specified systems

Employees access the sales and HR database utilizing a web-to-app interface thereby abiding by a 3-tier architecture

Systems are partitioned and segmented into development and production environments to facilitate configuration management practices

http://www.ifour-consultancy.com

Offshore software development company India

31 of 35

RBAC for Network Devices

Cisco’s Network Admission Control (NAC) is used to control workstations and laptop access to the internal network

IBNS and 802.1x is integrated into NAC (next slide)

802.1x provides controls for both wired and wireless devices

NAC Profiler is used to automatically identify and assess non-PC devices such as Voice over IP phones and printers

Appropriate device roles are created. For example, business user, guest user, etc...

NAC is used to isolate vender connections (i.e. visiting laptops), while still allowing Internet access

Ensure that authorized endpoint devices have been patched (operating systems, critical applications, anti-virus, anti-spyware, etc..) via the policy server.

http://www.ifour-consultancy.com

Offshore software development company India

32 of 35

RBAC for Infrastructure

Use Cisco’s AAA & TACACS+ via Cisco Secure Access Control Server & Active Directory for centralized router and firewall Authentication, Authorization, and Accounting.

Use Cisco's Identity-Based Networking Services (IBNS) identity management solution

IBNS is based on 802.1x and offers authentication, access control, and user policies to secure the network

802.1X allows enforcement of port based network access control when devices attempt to access the network

IBNS leverages Cisco's switches, Wireless APs, Cisco Secure ACS and Cisco Secure Services Client

Cisco’s Role-Based CLI Access is used to define auditor and helpdesk views

These views are configured to restrict access to Cisco IOS commands and configuration while allowing timely problem resolution and audit access to the IOS

33 of 35

RBAC for Auditing

RBAC will ease auditing of network and systems

Enforces unique usernames; only one username per user

Define ‘read’ or ‘view’ only access to auditing roles

Auditors can then be granted access to audit roles

Appropriate event logs from servers, Active Directory, IPS, routers, Vintela Authentication Services, NAC, key card system and other network infrastructure devices are stored in a centralized log server

Access to the centralized log server data is restricted, IT can not access, modify or delete logs without audit’s permission

An event correlation and reporting server is used by both IT and audit to correlate and review the data

34 of 35

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)

Symbiosis

Neha Kabra
Jayesh Singhal
Rohit Gedam
Sunil Saroj

http://www.ifour-consultancy.com

Offshore software development company India

35 of 35

THANK YOU

http://www.ifour-consultancy.com

Offshore software development company India