Interagency Report 7316Assessment ofAccess Control SystemsVincent C. HuDavid F. FerraioloD. Rick Kuhn

Interagency Report 7316Assessment of Access ControlSystemsVincent C. HuDavid F. FerraioloD. Rick KuhnC O M P U T E RS E C U R I T YComputer Security DivisionInformation Technology LaboratoryNational Institute of Standards and TechnologyGaithersburg, MD 20899-8930September 2006U.S. Department of CommerceCarlos M. Gutierrez, SecretaryTechnology AdministrationRobert C. Cresanti, Under Secretary of Commerce forTechnologyNational Institute of Standards and TechnologyWilliam Jeffrey, Directorii

NISTIR 7316Assessment of Access Control SystemsReports on Computer Systems TechnologyThe Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, testmethods, reference data, proof of concept implementations, and technical analyses to advancethe development and productive use of information technology. ITL’s responsibilities include thedevelopment of technical, physical, administrative, and management standards and guidelines forthe cost-effective security and privacy of sensitive unclassified information in federal computersystems. This Interagency Report discusses ITL’s research, guidance, and outreach efforts incomputer security, and its collaborative activities with industry, government, and academicorganizations.National Institute of Standards and Technology Interagency Report 7316,60 pages (September 2006)Certain commercial entities, equipment, or materials may be identified in thisdocument in order to describe an experimental procedure or conceptadequately. Such identification is not intended to imply recommendation orendorsement by the National Institute of Standards and Technology, nor is itintended to imply that the entities, materials, or equipment are necessarily thebest available for the purpose.iii

NISTIR 7316Assessment of Access Control SystemsAbstractAdequate security of information and information systems is a fundamental managementresponsibility. Nearly all applications that deal with financial, privacy, safety, or defense includesome form of access control. Access control is concerned with determining the allowed activitiesof legitimate users, mediating every attempt by a user to access a resource in the system. In somesystems, complete access is granted after successful authentication of the user, but most systemsrequire more sophisticated and complex control. In addition to the authentication mechanism(such as a password), access control is concerned with how authorizations are structured. Insome cases, authorization may mirror the structure of the organization, while in others it may bebased on the sensitivity level of various documents and the clearance level of the user accessingthose documents. This publication explains some of the commonly used access control servicesavailable in information technology systems.Organizations planning to implement an access control system should consider threeabstractions: access control policies, models, and mechanisms. Access control policies are highlevel requirements that specify how access is managed and who may access information underwhat circumstances. For instance, policies may pertain to resource usage within or acrossorganizational units or may be based on need-to-know, competence, authority, obligation, orconflict-of-interest factors. At a high level, access control policies are enforced through amechanism that translates a user’s access request, often in terms of a structure that a systemprovides. An access control list is a familiar example of an access control mechanism. Accesscontrol models bridge the gap in abstraction between policy and mechanism. Rather thanattempting to evaluate and analyze access control systems exclusively at the mechanism level,security models are usually written to describe the security properties of an access controlsystem. Security models are formal presentations of the security policy enforced by the systemand are useful for proving theoretical limitations of a system. Discretionary access control, whichallows the creator of a file to delegate access to others, is one of the simplest examples of amodel.As systems grow in size and complexity, access control is a special concern for systems that aredistributed across multiple computers. These distributed systems can be a formidable challengefor developers, because they may use a variety of access control mechanisms that must beintegrated to support the organization’s policy; for example, role-based access control that canenforce administrator-specified rules is often used. Popular database management systemdesigns, such as Structured Query Language (SQL), incorporate many aspects of role- and rulebased access. Services that are particularly useful in implementing distributed access controlinclude the Lightweight Directory Access Protocol (LDAP), capability-based Kerberos, and theExtensible Markup Language (XML)-based Extensible Access Control Markup Language(XACML).A state of access control is said to be safe if no permission can be leaked to an unauthorized oruninvited principal. To assure the safety of an access control system, it is essential to makecertain that the access control configuration (e.g., access control model) will not result in theleakage of permissions to an unauthorized principal. Even though the general safety computationiv

NISTIR 7316Assessment of Access Control Systemsis proven undecidable [HRU76], practical mechanisms exist for achieving the safetyrequirement, such as safety constraints built into the mechanism.Access control systems come with a wide variety of features and administrative capabilities, andthe operational impact can be significant. In particular, this impact can pertain to administrativeand user productivity, as well as to the organization’s ability to perform its mission. Therefore, itis reasonable to use a quality metric to verify the administrative capabilities, administrative cost,policy coverage, extensibility, and performance qualities of access control systems.Appendix C summarizes mechanisms and models supported by popular platforms such asMicrosoft Windows, UNIX/Linux, and SQL database management systems.v

NISTIR 7316Assessment of Access Control SystemsAcknowledgementsThe authors wish to thank their colleagues who reviewed drafts of this document, includingKaren Kent, Shirley Radack, Wayne Jansen, Tim Grance, and Tom Karygiannis. The authorsalso gratefully acknowledge and appreciate the comments and contributions made bygovernment agencies, private organizations, and individuals in providing direction and assistancein the development of this

NISTIR 7316Assessment of Access Control SystemsTABLE OF CONTENTSTABLE OF CONTENTS.VIITABLE OF FIGURES . IXTABLE OF TABLES. IX1INTRODUCTION . .1Document Scope and Purpose .1Audience and Assumptions.1Document Organization .1OVERVIEW OF ACCESS CONTROL . 32.1Concepts.32.2Policies, Models, and Mechanisms.42.2.1Discretionary Access Control (DAC) .62.2.2Non-Discretionary Access Control .63CAPABILITIES AND LIMITATIONS OF ACCESS CONTROL MECHANISMS113.1Access Control List (ACL) and Limitations.113.2Protection Bits and Limitations .143.3Capability List and Limitations .153.4Role-Based Access Control (RBAC) and 3Statically Constrained.173.4.4Dynamically Constrained .183.4.5Limitations of RBAC .193.5Rule-Based Access Control (RuBAC) and Limitations.203.6XML-Based Access Control Languages and Limitations .213.6.1The Extensible Access Control Markup Language (XACML) .213.6.2Using XML for Other Access Control Models.233.6.3Limitations of XML-Based Access Control Languages .244 CAPABILITIES AND LIMITATIONS OF ACCESS CONTROL FOR DISTRIBUTEDSYSTEMS. 254.1User Grouping by Roles.254.2Access Rules .274.3Centralized Control.284.3.1Centralized Object Access .284.3.2Delegation of Administration.324.4Limitations for Distributed Systems .325SAFETY LIMITATIONS . 33vii

NISTIR 7316Assessment of Access Control Systems5.1Achieving Safety.335.1.1Restricted Access Control Model for Safety .335.1.2Constraints for Safety .335.2Separation of Duty and Safety .345.2.1Static Separation of Duty (SSOD).345.2.2Dynamic Separation of Duty (DSOD) .356QUALITY METRIC FOR ACCESS CONTROL SYSTEMS . 366.1Quality Metrics .366.1.1The steps required for assigning and dis-assigning user capabilitiesinto the system.376.1.2The steps required for assigning and dis-assigning object accesscontrol entries into the system .376.1.3The degree to which an access control system supports the concept ofleast privilege.376.1.4Support for separation of duty .376.1.5Number of relationships required to create an access control policy .386.1.6The degree to which an access control system is adaptable to theimplementation and evolution of access control policies .386.1.7The horizontal scope (across platforms and applications) of control inwhich users and resources are regulated under an access control policy .396.1.8The vertical scope (between application, DBMS, and OS) of control .396.1.9Support for safety.396.1.10The degree of freedoms for AC management.406.1.11Performance of AC enforcement.406.1.12Policy conflicts that the access control system can resolve or prevent .406.1.13Flexibilities of configuration into existing systems: microkernel,application, or client/server.406.1.14Capabilities of policy encapsulation for policy combination,composition, and constraint.406.2Metric Element Selection.417CONCLUSION . 42APPENDIX A - GLOSSARY . 43APPENDIX B - ACRONYMS . 46APPENDIX C - COMMERCIAL ACCESS CONTROL SYSTEMS . 48REFERENCES . 49viii

NISTIR 7316Assessment of Access Control SystemsTABLE OF FIGURESFigure 1 - Components of the Workflow Management System . 9Figure 2 - XACML Architecture . 23Figure 3 - Mapping RBAC for Distributed Systems . 27TABLE OF TABLESTable 1 – Simplified Example of an ACL . 13Table 2 – Permission Bits . 14Table 3 – Capability List. 15Table 4 – Advantages and Disadvantages of ACLs and Capability Lists . 16ix

NISTIR 731611.1Assessment of Access Control SystemsINTRODUCTIONAuthorityThe National Institute of Standards and Technology (NIST) developed this document infurtherance of its statutory responsibilities under the Federal Information Security ManagementAct (FISMA) of 2002, Public Law 107-347.NIST is responsible for developing standards and guidelines, including minimum requirements,for providing adequate information security for all agency operations and assets, but suchstandards and guidelines shall not apply to national security systems. This document is consistentwith the requirements of the Office of Management and Budget (OMB) Circular A-130, Section8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis ofKey Sections. Supplemental information is provided in A-130, Appendix III.This guideline has been prepared for use by federal agencies. It may be used bynongovernmental organizations on a voluntary basis and is not subject to copyright, thoughattribution is desired.Nothing in this document should be taken to contradict standards and guidelines mademandatory and binding on federal agencies by the Secretary of Commerce under statutoryauthority, nor should these guidelines be interpreted as altering or superseding the existingauthorities of the Secretary of Commerce, Director of the OMB, or any other federal official.1.2Document Scope and PurposeThe purpose of this document is to provide agencies with background information on accesscontrol policies, models, and mechanisms to assist them in securing their computer applications.The document discusses the capabilities, limitations, and qualities of the access controlmechanisms that are embedded for each access control policy.1.3Audience and AssumptionsThis document is intended to provide practical and conceptual guidance for security managers,administrators, and procurement officers whose expertise is related to access control. The authorsassume that the readers have basic operating system, database, and networking expertise, as wellas some security expertise, especially in the field of access control. Because of the constantlychanging nature of the information technology industry, readers are strongly encouraged to takeadvantage of other resources (including those listed in this document) for more current anddetailed information.1.4Document OrganizationThis document is divided into seven sections, followed by three appendixes. Section 1 states theauthority, scope, purpose, audience, and assumptions of this document. Section 2 introduces the1

NISTIR 7316Assessment of Access Control Systemsterminology that is widely used in the field of access control and basic abstractions of controls:access control policies, models, and mechanisms. Section 2 also introduces major access controlpolicies; popular policies are provided with the discussions. The focus of this document ispresented in Section 3, which introduces some popular access control mechanisms and presentstheir advantages and limitations, along with examples. Section 4 is devoted to the broaderapplications of access control mechanisms for distributed systems. Section 5 discusses the safetyissues of access control systems. Section 6 lists and explains some measurements for the qualityof an access control mechanism. Section 7 presents the conclusion to the document. AppendixesA - Glossary, B - Acronyms, C - Commercial Access Control Systems, and References provideinformation that supports the document.2

NISTIR 73162Assessment of Access Control SystemsOVERVIEW OF ACCESS CONTROLThis section introduces concepts, common terms, and basic (popular) policies and models ofaccess control. The contents of this section are referenced throughout the document.Access control is concerned with determining the allowed activities of legitimate users,mediating every attempt by a user to access a resource in the system. A given informationtechnology (IT) infrastructure can implement access control systems in many places and atdifferent levels. Operating systems use access control to protect files and directories. Databasemanagement systems DBMS apply access control to regulate access to tables and views. Mostcommercially available application systems implement access control, often independent of theoperating systems and/or DBMSs on which they are installed.The objectives of an access control system are often described in terms of protecting systemresources against inappropriate or undesired user access. From a business perspective, thisobjective could just as well be described in terms of the optimal sharing of information. After all,the main objective of IT is to make information available to users and applications. A greaterdegree of sharing may get in the way of resource protection; in reality, a well-managed andeffective access control system actually facilitates sharing. A sufficiently fine-grained accesscontrol mechanism can enable selective sharing of information where in its absence, sharing maybe considered too risky altogether [FKC03].2.1ConceptsThis section introduces some of the concepts that are commonly used in the access controlresearch community and are also used throughout this document. Object: An entity that contains or receives information. Access to an object potentiallyimplies access to the information it contains. Examples of objects are records, fields (in adatabase record), blocks, pages, segments, files, directories, directory trees, process, andprograms, as well as processors, video displays, keyboards, clocks, printers, and networknodes. Devices such as electrical switches, disc drives, relays, and mechanical componentsconnected to a computer system may also be included in the category of objects [NCSC88].Subject: An active entity, generally in the form of a person, process, or device that causesinformation to flow among objects (see below) or changes the system state [NCSC88].Operation: An active process invoked by a subject; for example, when an automatic tellermachine (ATM) user enters a card and correct personal identification number (PIN), thecontrol program operation on the user’s behalf is a process, but the subject can initiate morethan one operation-deposit, withdrawal, balance inquiry, etc. [FKC03]Permission (privilege): An authorization to perform some action on the system. In mostcomputer security literature, the term permission refers to some combination of object andoperation. A particular operation used on two different objects represents two distinctpermissions, and similarly, two different operations applied to a single object represent twodistinct permissions. For example, a bank teller may have permissions to execute debit andcredit operations on customer records through transactions, while an accountant may3

NISTIR 7316 2.2Assessment of Access Control Systemsexecute debit and credit operations on the general ledger, which consolidates the bank’saccounting data [FKC03].Access Control List (ACL): A list associated with an object that specifies all the subjectsthat can access the object, along with their rights to the object. Each entry in the list is a pair(subject, set of rights). An ACL corresponds to a column of the access control matrix(described next). ACLs are frequently implemented directly or as an approximation inmodern operating systems.Access Control Matrix: A table in which each row represents a subject, each columnrepresents an object, and each entry is the set of access rights for that subject to that object.In general, the access control matrix is sparse: most subjects do not have access rights tomost objects. Therefore, different representations have been proposed. The access controlmatrix can be represented as a list of triples, having the form subject, rights, object .Searching a large number of these triples is inefficient enough that this implementation isseldom used [Sum97]. Rather, the matrix is typically subdivided into columns (ACLs) orrows (capabilities).Separation of Duty (SOD): The principle that no user should be given enough privileges tomisuse the system. For example, the person authorizing a paycheck should not also be theone who can prepare it. Separation of duties can be enforced either statically by definingconflicting roles (i.e., roles which cannot be executed by the same user) or dynamically byenforcing the control at access time. An example of dynamic separation of duty is the twoperson rule. The first user to execute a two-person operation can be any authorized user,whereas the second user can be any authorized user different from the first. There arevarious types of SOD; an important one is a history-based SOD that regulates, for example,that the same subject (role) cannot access the same object a certain number of times.Safety: Measures that the access control configuration (e.g., access control mechanism ormodel) will not result in the leakage of permissions to an unauthorized principal. Thus, aconfiguration is said to be safe if no permission can be leaked to an unauthorized orunintended principal.Domain and Type Enforcement: The grouping of processes into domains, and objects intotypes, such that access operations (such as read, write, execute, and create) are restrictedfrom domains to types and between domains. A process belongs to one domain at any giventime and transits to other domains by sending signals or executing a file in a new domain[BSS95].Policies, Models, and MechanismsWhen planning an access control system, three abstractions of controls should be considered:access control policies, models, and mechanisms. Access control policies are high-levelrequirements that specify how access is managed and who, under what circumstances, mayaccess what information. While access control policies can be application-specific and thus takeninto consideration by the application vendor, policies are just as likely to pertain to user actionswithin the context of an organizational unit or across organizational boundaries. For instance,policies may pertain to resource usage within or across organizational units or may be based onneed-to-know, competence, authority, obligation, or conflict-of-interest factors. Such policiesmay span multiple computing platforms and applications.4

NISTIR 7316Assessment of Access Control SystemsAt a high level, access control policies are enforced through a mechanism that translates a user’saccess request, often in terms of a structure that a system provides. There are a wide variety ofstructures; for example, a simple table lookup can be performed to grant or deny access.Although no well-accepted standard yet exists for determining their policy support, some accesscontrol mechanisms are direct implementations of formal access control policy concepts[FKC03].Rather than attempting to evaluate and analyze access control systems exclusively at themechanism level, security models are usually written to describe the security properties of anaccess control system. A model is a formal presentation of the security policy enforced by thesystem and is useful for proving theoretical limitations of a system. Access control models are ofgeneral interest to both users and vendors. They bridge the rather wide gap in abstractionbetween policy and mechanism. Access control mechanisms can be designed to adhere to theproperties of the model. Users see an access control model as an unambiguous and preciseexpression of requirements. Vendors and system developers see access control models as designand implementation requirements. On one extreme, an access control model may be rigid in itsimplementation of a single policy. On the other extreme, a security model will allow for theexpression and enforcement of a wide variety of policies and policy classes [FKC03, HFF01]. Asstated previously, the focus of this document is on the practical side of the access control system;detailed descriptions of access control models are not included in this publication [NCSC91].This section provides additional information on access control policies and gives examples ofseveral types of policies. Section introduces the concept of role-based access control.Finally, Section discusses the type and use of temporal constraints in access controlpolicies.Generating a list of access control policies is of limited value, since business objectives,tolerance for risk, corporate culture, and the regulatory responsibilities that influence policydiffer from enterprise to enterprise, and even from organizational unit to organizational unit. Theaccess control policies within a hospital may pertain to privacy and competency (e.g., onlydoctors and nurse practitioners may prescribe medication), and hospital policies will differgreatly from those of a military system or a financial institution. Even within a specific businessdomain, policy will differ from institution to institution. Furthermore, access control policies aredynamic in nature, in that they are likely to change over time in reflection of ever-evolvingbusiness factors, government regulations, and environmental conditions. There are several wellknown access control policies, which can be categorized as discretionary or non-discretionary.Typically, discretionary access control policies are associated with identity-based access control,and non-discretionary access controls are associated with rule-based controls (for example,mandatory security policy).5

NISTIR 73162.2.1Assessment of Access Control SystemsDiscretionary Access Control (DAC)DAC leaves a certain amount of access control to the discretion of the object's owner or anyoneelse who is authorized to control the object's access [NCSC87]. For example, it is generally usedto limit a user's access to a file [NSP94]; it is the owner of the file who controls other users'accesses to the file. Only those users specified by the owner may have some combination of read,write, execute, and other permissions to the file. DAC policy tends to be very flexible and iswidely used in the commercial and government sectors. However, DAC is known to beinherently weak for two reasons. First, granting read access is transitive; for example, when Anngrants Bob read access to a file, nothing stops Bob from copying the contents of Ann’s file to anobject that Bob controls. Bob may now grant any other user access to the copy of Ann’s filewithout Ann’s knowledge. Second, DAC policy is vulnerable to Trojan horse attacks. Becauseprograms inherit the identity of the invoking user, Bob may, for example, write a program forAnn that, on the surface, performs some useful function, while at the same time destroys thecontents of Ann’s files. When investigating the problem, the audit files would indicate that Anndestroyed her own files. Thus, formally, the drawbacks of DA

A state of access control is said to be safe if no permission can be leaked to an unauthorized or uninvited principal. To assure the safety of an access control system, it is essential to make certain that the access control configuration (e.g., access control model) will not result in