ИСТИНА

The objective of an access control (AC) system is often described in terms of protecting system resources against inappropriate or undesired user access. From a business perspective, this objective could just as well be described in terms of the optimal sharing of information to users and applications. However, a greater degree of sharing may get in the way of resource protection, so a sufficiently fine-grained AC policy should enable selective sharing of information where in its absence, sharing may be considered too risky altogether. Correct implementation and enforcement of AC policies is based on the premise that the policy specifications are correct without hidden or conflicted rules that cause leaking or blocking access to objects. AC policy specifications must undergo rigorous verification and validation through systematic testing to ensure that the policy specifications truly encapsulate the desires of the policy authors. Verifying and testing of AC policies is a lot like general application software testing, but there are differences as well. To formally and precisely capture the safety requirements that the AC system should adhere to, models are usually written to bridge the rather wide gap in abstraction between policy and mechanism. Thus, an AC model provides unambiguous and precise expression as well as a reference for design and implementation of safety requirements. AC policies are high-level requirements that specify how access is managed and who, under what circumstances, may access what information. While AC policies can be application-specific and thus taken into consideration by the application vendor, policies are just as likely to pertain to user actions within 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 on need-to-know, competence, authority, obligation, or conflict-of-interest factors. Such policies may span multiple computing platforms and applications. [NIST-IR-7316] It is not practical to generate a list of generic AC policies, since business objectives, tolerance for risk, corporate culture, and the regulatory responsibilities that influence policy differ from enterprise to enterprise, and even from one organizational unit to another. The AC policies within a hospital may pertain to privacy and competency (e.g., only doctors and nurse practitioners may prescribe medication), and hospital policies will differ greatly from those of a military system or a financial institution. Even within a specific business domain, policy will differ from institution to institution. Furthermore, AC policies are dynamic in nature, in that they are likely to change over time in reflection of ever evolving business factors, government regulations, and environmental conditions. There are several well-known AC policies, which can be categorized as discretionary or non-discretionary. Typically, discretionary AC policies are associated with identity-based AC, and non-discretionary ACs are associated with rule-based controls (for example, mandatory security policy). Discretionary AC (DAC) leaves a certain amount of AC to the discretion of the object's owner, or anyone else who is authorized to control the object's access. For example, DAC is generally used to limit a user's access to a file; 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, etc. permissions to the file. DAC policy tends to be very flexible and is widely used in commercial and government sectors. However, DAC is known to be inherently weak for two reasons. First, granting read access is transitive; for example, when Ann grants Bob read access to a file, nothing stops Bob from copying the contents of Ann’s file to an object that Bob controls. Bob may now grant any other user access to the copy of Ann’s file without Ann’s knowledge. Second, DAC policy is vulnerable to Trojan horse attacks. Because programs inherit the identity of the invoking user, Bob may, for example, write a program for Ann that, on the surface, performs some useful function, while at the same time destroy the contents of Ann’s files. When investigating the problem, the audit files would indicate that Ann destroyed her own files. Thus, formally, the drawbacks of DAC are as follows: • Information can be copied from one object to another; therefore, there is no real assurance on the flow of information in a system. • No restrictions apply to the usage of information when the user has received it. • The privileges for accessing objects are decided by the owner of the object, rather than through a system-wide policy that reflects the organization’s safety requirements. ACLs and owner/group/other AC mechanisms (e.g. permission bits in UNIX) are by far the most common mechanisms for implementing DAC policies. Other mechanisms, even though not designed with DAC in mind, may have the capabilities to implement a DAC policy. In general, all AC policies other than DAC are grouped under the category of non-discretionary AC (NDAC). As the name implies, policies in this category have rules that are not established at the discretion of the user. Non-discretionary policies establish controls that cannot be changed by users, but only through administrative action. Static NDAC, for example, are MLS, ABAC, and RBAC, and dynamic NDAC such as Separation of duty (SOD) policy can be used to enforce constraints on the assignment of users to roles or tasks. An example of a constraint is the requirement that two roles be mutually exclusive; e.g., if one role requests expenditures and another approves them, the organization may prohibit the same user from being assigned to both roles. So, membership in one role may prevent the user from being a member of one or more other roles, depending on the SOD rules, such as Work Flow and RBAC. Another example of NDAC is a history-based SOD policy that regulates, for example, whether the same subject (role) can access the same object for a variable number of times. Due to the fact that DAC policies have no well-defined variables in terms of model definition, they are in general hard to formalize and verify efficiently with first order models, which most of the black box and white box verification tools are based on. This document does not cover DAC policies.