RBAC, SOX and Role Engineering
in Large Organizations

News	Recommended Links	Solaris Implementation	RBAC and Solaris privileges	What is a Role
SOX	Principle of least privilege	Separation of duties	History	Humor	Etc

With all this noise about SOX compliance one of the few things that make sense is adoption of RBAC. Most of SOX activity resembles Y2K craze and also is a very expensive and superficial effort that benefits large auditing firms and (to a lesser extent) companies with semi-useless or harmful security products. But good managers can play thier cards more intelligently that regular PHBs and try to add technologies which time has come, but which would never be implemented unless they are in SOX compliance bandwagon with its financial excesses ;-). Role-based access control (RBAC) is definitely one of such technologies.

Persuading higher level managers to implement RBAC under SOX-compliance sauce is relatively easy (in fact, SOX does not even specify what are "adequate internal control", nor which solutions organizations must implement in order to meet that requirement). Using RMAC as "adequate integral control" solution makes a lot of sense.

This page tries to point you to relevant resources. Of course my preference is Solaris, but among commercial RBAC products we can also mention Tivoli TME Security Management, BMC INCONTROL, Sybase SQL Server, Siemens rbacDirX, Sysor Security Administration Manager, and Computer Associates Protect IT.

Role-based access control (RBAC) defines and enforce enterprise-wide security policies. It was introduced in 1992 by David Ferraiolo and Rick Kuhn of the NIST. In April of 2004 the American National Standards Institute approved Standard 359-2004: American National Standard for Information Technology—Role Based Access Control. NIST maintains a Web site dedicated to RBAC at http://csrc.nist.gov/rbac. There are two key principles of role-based access control:

Granting of access is based on the user’s role rather than his or her identity. A user has access rights and privileges based on the assigned role.
Roles define access rights and privileges based on job authority and responsibilities within a job function. Permissions are grouped by role name.

From the point of view of security theory RBAC bases access control decisions on the functions a user is allowed to perform within an organization. The users cannot pass access permissions on to other users at their discretion. This is a fundamental difference between RBAC and DAC. That means that RBAC is in fact a form of mandatory access control, but unlike a typical MAC environment it is not based on multilevel security requirements (clearances and security labels). As defined in the TCSEC, MAC is:

A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e. clearance) of subjects to access information of such sensitivity. [Orangebook]

RBAC) can lower the cost and complexity of security administration of large servers. RBAC organize privileges into roles.

In large organizations, the application owners do not "own'' the information of the application for which he/she is responsible. For these organizations, the corporation itself or even some government agency is the actual "owner'' of system objects and application owner is simply a custodian.

Role-Based Access Control (RBAC) is a nondiscretionary access control mechanism which allows the central security policy and as such is very suitable to large organizations environment.

The act of granting membership and specifying transactions for a role is loosely analogous to the process of clearing users (granting membership) and the labeling (association of operational sensitivities) of objects.

Unlike MAC where the main focus is on capability: who can read what information within a role-based system, the principal concern in RBAC is protecting the integrity of information: "who can perform what actions on what information''

A role can be thought of as a set of transactions that a user or set of users can perform within the context of an organization. Membership in a role is granted and revoked by a system administrator.

Roles are group oriented; the simplest model of roles is probably Unix groups implmentation

The key questions here are:

Can roles be hierarchical (in Unix groups the answer is no).
What privileges can be assigned or revoked (in Unix group only regular RWX privileges.
What is the logging mechanism used for switching into the role and switching back to your original identity.

The applicability of RBAC to commercial systems is apparent from its widespread use. Baldwin describes a database system using roles to control access. Nash and Poland Nash and Poland discuss the application of role based access control to cryptographic authentication devices commonly used in the banking industry. Working with industry groups, the National Institute of Standards and Technology has developed a proposed standard, "Security Requirements for Cryptographic Modules,'' (Federal Information Processing Standard 140-1) that will require support for access control and administration through roles. To date, these role based systems have been developed by a variety of organizations, with no commonly agreed upon definition or recognition in formal standards.

Notes:

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Google Search
Open directory	Research Index

Old News

[Oct 28, 2005] Role based access and Sarbanes-Oxley Compliance

The Sarbanes-Oxley Act establishes a set of requirements for financial systems, to deter fraud and increase corporate accountability. For information technology systems, regulators may need to know who used a system, when they logged in and out, what accesses or modifications were made to what files, and what authorizations were in effect. IT vendors responding to Sarbanes-Oxley requirements have adopted RBAC as central to compliance solutions because RBAC was designed to solve this type of problem.

Sarbanes-Oxley Act of 2002 and Impact on the IT Auditor, IT Knowledgebase - comprehensive introduction to Sarbanes-Oxley requirements
Compliance: Thinking outside the Sarbox, NetworkWorldFusion, February 7, 2005 - experience with SOX compliance in a number of firms
Rules and policies vs. actual practice, NetworkWorldFusion, February 7, 2005 - identity management and role based access
"Information Risk": A New Approach to Information Technology Security, Sys-con.com - risk management aspects
Implementing Sarbanes-Oxley, WebSphere Journal, November 26, 2004 - a case study of implementing SOX compliance
Addressing the Key Implications of Sarbanes-Oxley, The Business Forum, 2004 - implications for corporate IT systems
Solving Sarbanes-Oxley: A Business Intelligence Perspective, DMReview, December, 2003 - business intelligence approach

RBAC Principles Disclaimer & Definitions

This document is merely a re-sorting of the “Principles” output from the NAC 2001 Fall conference, which will hopefully act as a starting point to more comprehensive documentation. The conference material did not contain all of the “principles” that may apply to RBAC, but there were also some good ideas expressed in the contents that were not “principles” as well. This document re-sorts the conference document into “RBAC Principles” items and “Role Engineering Best Practices” items for further discussion.

Definitions:
Principle: A “principle”, as used in this context, is a constant (some might call a “rule”) that defines a particular behavior or characteristic that any RBAC system must include, exhibit or comply with.

Best Practice: A “best practice” can be an insight based on experience, a recommendation based on research, or even an opinion based on sound reasoning. In this case, certain “best practices” for role engineering or role discovery were contained within the NAC conference “Principle” document.

Principles:
1.      The RBAC system must delineate users, roles, and permissions.

2.      A user can be assigned to multiple roles.

3.      The system must support the notion of “Separation of Duty “ constraints.

4.      Must leverage existing standards to the extent possible.

5.      An inheritance model must be supported so that a role can inherit rights other roles .

6.      The permission with the least privilege applies, in cases where a user is assigned to multiple roles, and two or more roles define a permission on the same object.

7.      The system must log changes to role assignments.

8.      The system must provide an aggregated view of all permissions assigned to a particular user.

9.      The system must provide a view of all users assigned to a particular permission.

110.     There must be an administrative interface to add/change/delete roles, permissions and users – as well as the assignments of permissions to roles and roles to users.

111.     A role should be able to map to one or more “groups” on one or more target systems.

112.     ”Users” can be people, applications, devices or functions.

Best Practices for Role Engineering:

1.      Roles are abstractions of system entitlements that consider two design criteria:

Consolidation of entities into meaningful groups that facilitate ease of administration.

Collections of permissions that are meaningful to specific user communities

2.      There are three basic approaches to role engineering:

“Bottom Up”: which derives roles from the groups and permissions defined on the existing systems and platforms in the enterprise.

“Top Down”: which derives roles from an analysis of business function and organizational criteria, typically from a “zero base” starting point.

“Hybrid”: which, as the name implies, derives roles using a combination of bottom up and top down approaches.

3.      The top down approach typically is much more difficult to implement, because it will probably result in significant changes to legacy group and permission models.

4.      The bottom up approach is typically easier to implement, because the RBAC system will overlay the legacy group and permission models.

5.      A successful role definition approach will likely be a hybrid approach

6.      The objective of role modeling is to maximize flexibility with minimal administrative effort.

7.      Role engineering should consider how role and user administration is to be delegated. More decentralized models benefit from more top down analysis.

8.      Top down role engineering will aggregate business processes into organizational parameters.

9.      A top down approach can only be successful with participation and buy-in from business units.

110.     A role typically maps to a group on a legacy system.

111.     Successful implementation of RBAC benefits from a cultural commitment to define common roles that supercede individual privileges.

112.     Roles do not have meaning unless they are used to define access privileges.

113.     Plan for role life cycle management

114.     Consider using use case modeling to validate role definitions.

Etc

Links to Security-related conferences (great places to pick papers)

History

Computer Security History Project at UC Davis Security Laboratory has copies of old but seminal papers.
Professor Ronald L. Rivest's Cryptography and Security page
Applied Security Reading Group at MIT
Berkeley Crypto Reading Group at UC Berkeley
Security Reading Group at UIUC

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 05, 2008

RBAC, SOX and Role Engineering in Large Organizations

Old News

Recommended Links

Etc

History

RBAC, SOX and Role Engineering
in Large Organizations