Source-linked AI summary
Role-Based Access Controls
David F. Ferraiolo, D. Richard Kuhn
TL;DR
The paper addresses whether DAC is an appropriate principal access-control model for commercial and civilian government organizations. It formalizes RBAC as a nondiscretionary, role-centered alternative, arguing that it better supports organizational functions, integrity, least privilege, and separation of duties. The paper also notes that RBAC lacks a commonly accepted definition and formal standards.
Problem
Commercial and civilian organizations often do not own the information their employees access, and their function-based security requirements may not be well served by discretionary access control.
Method
The paper defines RBAC through organizational roles, authorized transactions, role-assignment rules, and optional transaction-to-object access controls.
Results
RBAC provides a nondiscretionary mechanism for centrally administering organization-specific security policy and describing relationships between individuals and rights.
Takeaways & Limitations
RBAC can support secure processing in many commercial and civilian government organizations, including least privilege, separation of duties, and integrity protection.
Takeaways & Limitations
RBAC has no commonly accepted definition or formal standards, so evaluation and testing programs have not been established as they have for TCSEC-conforming systems.
Abstract
from arXiv · showhide
While Mandatory Access Controls (MAC) are appropriate for multilevel secure military applications, Discretionary Access Controls (DAC) are often perceived as meeting the security processing needs of industry and civilian government. This paper argues that reliance on DAC as the principal method of access control is unfounded and inappropriate for many commercial and civilian government organizations. The paper describes a type of non-discretionary access control - role-based access control (RBAC) - that is more central to the secure processing needs of non-military systems than DAC.
1 Introduction
The paper argues that security criteria developed for DoD needs do not fully address unclassified sensitive processing, while DAC is not the most appropriate central control for many commercial and civilian government systems.
- DoD-derived security criteria primarily target preventing unauthorized observation of classified information, leaving some unclassified sensitive processing needs insufficiently addressed.Existing mechanisms have been partially successful outside the DoD but are sometimes used instead of more appropriate controls.
- The TCSEC specifies DAC and MAC, with DAC perceived as suitable for commercial and civilian government systems and MAC used mainly for multilevel military systems.
- RBAC is proposed as more appropriate and central than DAC to secure processing needs in industry and civilian government, while DAC remains necessary.
2 Aspects of Security Policies
Commercial and civilian organizations often need centrally administered, role- and function-oriented controls because organizational security requirements emphasize integrity and do not align cleanly with user ownership or traditional DAC and MAC.
- Commercial and civilian organizations face broad security requirements involving the integrity, availability, and confidentiality of software systems, databases, and networks.
- Integrity is especially important in applications such as funds transfer, clinical medicine, environmental research, air traffic control, and avionics.
- DAC lets users grant or revoke access to objects under their control, whereas RBAC bases decisions on organizational roles and authorized functions without allowing users to pass permissions at discretion.
- Many organizations treat the corporation or agency as the owner of information and base control on employee functions rather than data ownership.
- Role-based controls protect integrity by distinguishing authorized acts on information, even when different roles require the same underlying file access.In banking, tellers and accounting supervisors may share read/write access while executing different processes and writing different log values.
- RBAC roles connect users with authorized transactions, procedures, and data, representing many-to-many relationships between individuals and rights.Examples include doctor, pharmacist, teller, and accounting roles with different transaction permissions.
- RBAC has been applied or proposed for commercial systems, including databases and cryptographic authentication devices used in banking.
3 Formal Description of RBAC
The paper formalizes RBAC through role assignment, role authorization, and transaction authorization, while allowing transaction-bound object access and optional object-level restrictions for selected applications.
- The formal description defines RBAC in terms of sets and relations without implying a particular implementation mechanism.
- A subject can execute a transaction only when it has selected or been assigned an active role, and all active users must have an active role.
- A subject’s active role must be among the roles authorized for that subject.
- A subject can execute only transactions authorized for its active role, although additional restrictions may further limit execution.The paper gives a trainee assigned a supervisory role as an example of such additional restrictions.
- RBAC transactions bind transformation procedures to accessed data, allowing access control to rely on transaction design rather than separate object-right checks.
- An optional fourth rule can control a role’s access mode to objects through transactions, supporting cases such as different doctor and pharmacist permissions.
- RBAC supports integrity by restricting data and process modification to authorized ways and authorized users.
- Object-level transaction access control is useful in some applications but may impose significant overhead for limited integrity-enforcement benefit.
4 Centrally Administering Security Using RBAC
RBAC supports centralized administration by organizing users, transactions, and rights into roles that can reflect organizational policy and structure. Roles may be composed hierarchically, with memberships determining inherited transaction access.
- RBAC supports organizational policy and structure while providing centralized administrative capabilities.
- Administrators primarily manage membership in named roles because role transactions tend to remain relatively constant or change slowly.
- Roles can be composed of other roles, allowing membership in a broader role to imply access to transactions assigned to its component roles.
5 Principle of Least Privilege
RBAC can enforce least privilege by restricting users to the minimum transactions necessary for their jobs. This supports integrity objectives by denying unnecessary privileges.
- RBAC can enforce least privilege by giving general system users no more privilege than necessary to perform their jobs.The approach identifies job functions, determines required privileges, and restricts users to those privileges.
- Denying unnecessary transactions limits opportunities to circumvent organizational security policy.
- Least privilege is described as important for meeting integrity objectives.
6 Separation of Duties
RBAC enables administrators to enforce separation-of-duty policies by allocating transactions to roles and restricting combinations of capabilities. Separation of duty may be static or dynamically checked during operation.
- RBAC can enforce separation of duties by preventing one individual from executing every transaction in specified sets.A common example separates payment initiation from payment authorization to deter fraud.
- Separation of duty may be static, based on role assignments, or dynamic, determined during system operation.Dynamic separation provides greater operational flexibility but is more difficult to enforce.
- Role-based allocation helps systems enforce separation of duty because users performing the same function typically share access rights.
7 Summary and Conclusions
The paper presents RBAC as a nondiscretionary mechanism for centrally administering organization-specific security policies and describing relationships between users and rights. It also notes that RBAC lacks a commonly accepted definition and formal standards.
- RBAC is nondiscretionary and supports central administration of organization-specific security policies where end users do not own the information they access.
- RBAC names and describes relationships between individuals and rights through organizational roles and transactions.
- RBAC has no commonly accepted definition or formal standards, so evaluation and testing programs have not been established.