RBAC and Role Engineering
in Large Organizations
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 concept of the rile is very close to the Unix concept
of a group with two important differences;
- Classic Unix permissions model concept of group is a filesystem-centric, while the ocncept of role is operations centric concept.
A unix group is a set of users which are granted a certain rights for a set of objects of the filesystem (files and directories
that are owned by this group). A role is more process-oriented view, having more in common how sudo operates
on one hand and how Unix ACLs operate on another.
- Group is limited to a predefined set of right (read, write, execute). Role concept is more dynamic and process oriented. It
imply that rights are set of operations on the object which are wider then file permission, and can be created and destroyed and
are not a static set (See Solaris RBAC implementation).
RBAC enables more precise implementation of the Principle of Least Privilege. Subjects may login with most of their roles deactivated,
and activate a role only when a particular right associated with the role is necessary.
With the past noise about SOX compliance one of the few things that would make sense was the implementation of RBAC under the sauce
of SOX compliance. Most of SOX activity resembled Y2K craze and also was equally useless, expensive and superficial
effort that benefited mainly large auditing firms and (to a lesser extent) companies with semi-useless or harmful security products.
But good managers have has a unique opportunity to play their cards more intelligently and persuade upper-level PHBs to implement RBAC
as panacea against all SOX-defined ills. Persuading higher level managers to implement RBAC under SOX-compliance sauce was actually
relatively easy as SOX did not even specify what are "adequate internal control", nor which solutions organizations must implement
in order to meet this particular requirement. In this case using RMAC as "adequate integral control" solution makes a lot of sense.
This opportunity to implement RBAC is now a water under the bridge but that does not mean that such opportunities will never arise
again. This page tries to point you to the relevant resources. Solaris 10 and 11 has RBAC built-in, but other commercial Unixes have
now implementation too (AIX 6 is one example).
Role-based access control (RBAC) 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.
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 implementation
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.
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 mainly developed for use by military and intelligence. Trusted Solaris was workhorse
of military since its Solaris 8. But the most robust implementation is provided by Solaris 10 which can be considered a classic implementation
of RBAC in Unix systems.
Despite long history there is no commonly agreed upon definitions or recognition of formal standards, although Solaris 10 implementation
serves as de-facto standard.
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
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.
Softpanorama Recommended
NIST/Role Based Access Control
-
RBAC Standards: ANSI/INCITS Technical Committee
CS1, Cyber Security,
established RBAC Task Group CS1.1 CS1.1,
RBAC Task Group, meeting Dec. 8, 2005 - agenda
-
RBAC case studies -
in IT infrastructure, financial systems, health care and HIPAA compliance, government and military
-
Sarbanes-Oxley compliance and RBAC -
RBAC solutions to complex identity management requirements
-
Economic Impact Study:
NIST's RBAC research saves industry $295 million
Summary
Full Report
Individual sites
Access Control Model
General papers
- Ferrailo & Kuhn. "Role Based Access Controls." 15th National Computer Security Conference 1992. URL
http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html
11/1/00.
- Barkley. ""Application Engineering in Health Care". 1995. Second Annual CHIN URL
http://hissa.ncsl.nist.gov/rbac/proj/paper/paper.html
11/1/00.
- Sandhu, Ravi. "Report on the First ACM Workshop on Role-based Access Control, Gaithersburg, Maryland". Dec. 1, 1995
URL: http://www.chacs.itd.nrl.navy.mil/ieee/cipher/old-conf-rep/conf-rep-RBAC96.html
11/1/00.
- "An Introduction to Role Based Access Control." NIST CSL URL:
http://csrc.ncsl.nist.gov/nistbul/csl95-12.txt 11/1/00.
- Barkley. " Implementing Role Based Access Control Using Object Technology." First ACM Workshop on Role-Based Access Control.
1995 URL: http://hissa.ncsl.nist.gov/rbac/rbacot/titlewkshp.html
11/1/00.
- Secure Enterprise Computing with the Solaris 8 Operating System URL:
http://www.sun.com/software/white-papers/wp-s8security/
11/1/00
- Role Based Access Control; Solaris 8 System Administration Guide, Volume 2 URL:
http://docs.sun.com/ab2/coll.47.11/SYSADV2/@Ab2PageView/26238?Ab2Lang=C&Ab2Enc=iso-8859-1
11/1/00.
- "Role Based Access Control." 15th National Computer Security Conference 1992. URL:
http://hissa.ncsl.nist.gov/rbac 11/1/00.
- Barkley, Kuhn, Rosenthal, Skall, Cincotta. "Role-Based Access Control for the Web". 1998. CALS Expo International & 21st
Century Commerce 1998: Global Business Solutions for the New Millennium. URL:
http://hissa.ncsl.nist.gov/rbac/cals-paper.html 11/1/00.
- Goh, Cheh; Baldwin, Adrian. Towards a More Complete Model of Role. 1998. URL:
http://www.hpl.hp.com/techreports/98/HPL-98-92.html
- E. Lupu, D. Marriott, M. Sloman, N. Yialelis. A Policy Based Role Framework for Access Control ACM/NIST Workshop on Role-Based
Access Control. 1995 URL: http://www-dse.doc.ic.ac.uk/~ecl1/papers/rbac95/rbac95.pdf
- E. Lupu, M. Sloman. Reconciling Role Based Management and Role Based Access Control., Second Role Based Access Control Workshop.
Nov. 1997 URL: http://www-dse.doc.ic.ac.uk/~ecl1/papers/rbac97/Rbac97.pdf
Links to Security-related conferences (great places to pick papers)
Society
Groupthink :
Two Party System
as Polyarchy :
Corruption of Regulators :
Bureaucracies :
Understanding Micromanagers
and Control Freaks : Toxic Managers :
Harvard Mafia :
Diplomatic Communication
: Surviving a Bad Performance
Review : Insufficient Retirement Funds as
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
Neoliberalism
: The Iron
Law of Oligarchy :
Libertarian Philosophy
Quotes
War and Peace
: Skeptical
Finance : John
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
Keynes :
George Carlin :
Skeptics :
Propaganda : SE
quotes : Language Design and Programming Quotes :
Random IT-related quotes :
Somerset Maugham :
Marcus Aurelius :
Kurt Vonnegut :
Eric Hoffer :
Winston Churchill :
Napoleon Bonaparte :
Ambrose Bierce :
Bernard Shaw :
Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient
markets hypothesis :
Political Skeptic Bulletin, 2013 :
Unemployment Bulletin, 2010 :
Vol 23, No.10
(October, 2011) An observation about corporate security departments :
Slightly Skeptical Euromaydan Chronicles, June 2014 :
Greenspan legacy bulletin, 2008 :
Vol 25, No.10 (October, 2013) Cryptolocker Trojan
(Win32/Crilock.A) :
Vol 25, No.08 (August, 2013) Cloud providers
as intelligence collection hubs :
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
Copyleft Problems
Bulletin, 2004 :
Financial Humor Bulletin, 2011 :
Energy Bulletin, 2010 :
Malware Protection Bulletin, 2010 : Vol 26,
No.1 (January, 2013) Object-Oriented Cult :
Political Skeptic Bulletin, 2011 :
Vol 23, No.11 (November, 2011) Softpanorama classification
of sysadmin horror stories : Vol 25, No.05
(May, 2013) Corporate bullshit as a communication method :
Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000):
the triumph of the US computer engineering :
Donald Knuth : TAoCP
and its Influence of Computer Science : Richard Stallman
: Linus Torvalds :
Larry Wall :
John K. Ousterhout :
CTSS : Multix OS Unix
History : Unix shell history :
VI editor :
History of pipes concept :
Solaris : MS DOS
: Programming Languages History :
PL/1 : Simula 67 :
C :
History of GCC development :
Scripting Languages :
Perl history :
OS History : Mail :
DNS : SSH
: CPU Instruction Sets :
SPARC systems 1987-2006 :
Norton Commander :
Norton Utilities :
Norton Ghost :
Frontpage history :
Malware Defense History :
GNU Screen :
OSS early history
Classic books:
The Peter
Principle : Parkinson
Law : 1984 :
The Mythical Man-Month :
How to Solve It by George Polya :
The Art of Computer Programming :
The Elements of Programming Style :
The Unix Hater�s Handbook :
The Jargon file :
The True Believer :
Programming Pearls :
The Good Soldier Svejk :
The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society :
Ten Commandments
of the IT Slackers Society : Computer Humor Collection
: BSD Logo Story :
The Cuckoo's Egg :
IT Slang : C++ Humor
: ARE YOU A BBS ADDICT? :
The Perl Purity Test :
Object oriented programmers of all nations
: Financial Humor :
Financial Humor Bulletin,
2008 : Financial
Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related
Humor : Programming Language Humor :
Goldman Sachs related humor :
Greenspan humor : C Humor :
Scripting Humor :
Real Programmers Humor :
Web Humor : GPL-related Humor
: OFM Humor :
Politically Incorrect Humor :
IDS Humor :
"Linux Sucks" Humor : Russian
Musical Humor : Best Russian Programmer
Humor : Microsoft plans to buy Catholic Church
: Richard Stallman Related Humor :
Admin Humor : Perl-related
Humor : Linus Torvalds Related
humor : PseudoScience Related Humor :
Networking Humor :
Shell Humor :
Financial Humor Bulletin,
2011 : Financial
Humor Bulletin, 2012 :
Financial Humor Bulletin,
2013 : Java Humor : Software
Engineering Humor : Sun Solaris Related Humor :
Education Humor : IBM
Humor : Assembler-related Humor :
VIM Humor : Computer
Viruses Humor : Bright tomorrow is rescheduled
to a day after tomorrow : Classic Computer
Humor
The Last but not Least Technology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
Copyright � 1996-2021 by Softpanorama Society. www.softpanorama.org
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP)
without any remuneration. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Last modified:
March 12, 2019
