mopdf.com

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 2.2.2.2 introduces the concept of role-based access control.Finally, Section 2.2.2.3 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