- csrc home
- news & events
A primary objective of enterprise computing (via a data center, cloud, etc.) is the controlled delivery of data services (DSs) to its users. Typical DSs include applications such as email, workflow management, enterprise calendar, and records management, as well as system level features, such as file, access control and identity management. Although access control (AC) currently plays an important role in securing DSs, if properly designed, AC can be more fundamental to computing than one might expect. That is, the program logic that deals with implementation, distribution, and control over execution of capabilities (to perform operations on data objects) of individual DSs can be accommodated by a single underlying AC framework. The Policy Machine (PM) is an AC framework that has been designed with this objective in mind. The PM has evolved beyond just a concept to a prototype implementation and is now being directed toward an open source project.
To appreciate the PM's benefits in computing, it is important to recognize the methods in which DSs are delivered today. Each DS runs in an Operating Environment (OE) and an OE can be of many types (e.g., operating systems, middleware, and database and database applications), each implementing its own routines to enable the execution of DS specific operations (e.g., read, send, and approve) on their respective data types (e.g., files, messages, and fields). To impose control over executions of DS capabilities, each OE typically implements a method for identifying and authenticating its users. In addition to authentication, many OEs implement finer grained controls to selectively limit a user's ability to perform operations on objects.
This heterogeneity among OEs introduces a number of administrative and policy enforcement challenges and user inconveniences. Administrators must contend with a multitude of security domains when implementing access policy, and ordinary users and administrators alike must authenticate to and establish sessions within different OEs in order to exercise legitimate DS capabilities. Even if properly coordinated across OEs, access control policies are not always globally enforced. An email application may, for example, distribute files to users regardless of an operating system's protection settings on those files. Also, while researchers, practitioners, and policy makers have specified a large variety of access control policies to address real-world security issues, only a relatively small subset of these policies can be enforced through off-the-shelf technology, and even a smaller subset can be enforced by any one OE.
It is our experience that the PM can provide an enterprise wide OE that dramatically alleviates many of the administrative, policy enforcement, data interoperability, and usability issues that enterprises face today.
Like most other AC mechanisms, the PM comprises: (1) AC data used to express access control policies and deliver capabilities of DSs to perform operations on objects; (2) a set of administrative operations for configuring the AC; and (3) a set of functions for enforcing policy on requests to execute operations on objects and for computing access decisions to accommodate or reject those requests based on the current state of the AC data.
What distinguish the PM from other mechanisms are the data elements and relations that define its AC data, the type of operations that are recognized, and the functions that it implements. These specifics are driven by a redefinition of AC and DSs in terms of what is believed to be their common and underlying elements, relations, and functions.
The PM provides an enterprise–wide OE that can implement and execute capabilities of arbitrary DSs and can specify and enforce mission–tailored AC policies (to include combinations of discretionary, mandatory, and history–based policies) over those executions through configuration of its AC data alone. The PM–enabled OE is object type agnostic the data of its DSs naturally interoperate, and users can view and consume all data in a manner consistent with the defined policies, under a single authenticated session.
Although the PM can be implemented in a number of architectures, NIST has implemented its prototype within a virtualized environment providing "cloud like" features. In particular, our infrastructure is an OE in which the PM's functional components run in virtual machines. In this deployment, users and data objects can be provisioned, and DSs can be selected by the subscriber. DSs can be provided as SaaS or PaaS if they conform to the PM's API. Our PM motivated cloud differs from other types of clouds in the properties that it provides to its subscribers (see What Can the Policy Machine Do?) as well as the degree of control offered. AC Policies can be imported from a library of predefined configurations, or can be configured from scratch by the subscriber, conferring PM the attributes of a POLICYaaS provider.
NIST, and other members of an Ad Hoc International Committee for Information Technology Standards (INCITS) working group is developing a three part PM standard under the title of "Next Generation Access Control" (NGAC). This work is being conducted under three sub-projects:
The Policy Machine's architecture has been adopted by the American National Standards Institute, International Committee for Information Technology Standards (ANSI/INCITS) and is now available as ANSI INCITS 499 Draft – Information technology – Next Generation Access Control – Functional Architecture (NGAC–FA).
Perhaps what is most appealing about the PM–enabled OE are the properties that it offers–users and objects are global, the framework is object type agnostic, DSs naturally interoperate, and AC policies are managed and enforced comprehensively across all DSs.
The practical advantages are many. Through a single authenticated session, users are offered capabilities of a variety of DSs to include office applications, file management, email, workflow, and records management. Data is naturally protected across DSs. Instead of deploying and managing different AC schemes for different DSs, select capabilities (of different DSs) are delivered to select users, under combinations of arbitrary, but mission–tailored forms of discretionary, mandatory, and history–based ACs. This interoperability property is not achieved through features or interfaces built into the DS, but rather through the OE that inherently provides a foundational basis for interoperability.
Certain software products are identified in this document. Such identification does not imply recommendation by NIST, nor does it imply that the products identified are necessarily the best available for the purpose..