Skip to main content

NIST

The National Institute of Standards and Technology (NIST) is a division of the US Department of Commerce. NIST has a broad portfolio of services. What unites all of its services is the mission to promote US innovation and industrial competitiveness.

For more than 50 years, NIST had conducted cybersecurity research. NIST develops standards, guidance, best practices, and other resources for the public and private sectors. See this fact sheet for an overview of NIST's cybersecurity program.

In 2020, NIST published special report 800-207 on zero trust architecture.

Notably, in SP 800-207, NIST distinguishes between "zero trust" and "zero trust architecture."

NIST's definition of Zero Trust:


NIST's definition of Zero Trust Architecture:


NIST ZTA

At its most abstract, NIST diagrams zero trust access like this:


As we can see, central to NIST's conception of zero trust is the policy decision/enforcement point. NIST breaks down the core logical components - which can be on-premise and/or a cloud-service - involved in zero trust architecture like this:

The key logical components in NIST's ZTA are the policy engine, policy administrator, and policy enforcement point. They are defined in the following way:

  • Policy Engine - This component is responsible for the ultimate decision to grant access to a resource for a given subject. The PE uses enterprise policy as well as input from external sources (e.g., CDM systems, threat intelligence services described below) as input to a trust algorithm (see Section 3.3 for more details) to grant, deny, or revoke access to the resource. The PE is paired with the policy administrator component. The policy engine makes and logs the decision (as approved, or denied), and the policy administrator executes the decision.

  • Policy Administrator - This component is responsible for establishing and/or shutting down the communication path between a subject and a resource (via commands to relevant PEPs). It would generate any session-specific authentication and authentication token or credential used by a client to access an enterprise resource. It is closely tied to the PE and relies on its decision to ultimately allow or deny a session. If the session is authorized and the request authenticated, the PA configures the PEP to allow the session to start. If the session is denied (or a previous approval is countermanded), the PA signals to the PEP to shut down the connection. Some implementations may treat the PE and PA as a single service; here, it is divided into its two logical components. The PA communicates with the PEP when creating the communication path. This communication is done via the control plane.

  • Policy Enforcement Point - This system is responsible for enabling, monitoring, and eventually terminating connections between a subject and an enterprise resource. The PEP communicates with the PA to forward requests and/or receive policy updates from the PA. This is a single logical component in ZTA but may be broken into two different components: the client (e.g., agent on a laptop) and resource side (e.g., gateway component in front of resource that controls access) or a single portal component that acts as a gatekeeper for communication paths. Beyond the PEP is the trust zone (see Section 2) hosting the enterprise resource.

Broadly speaking, the role of the other components in the figure above is to act as data sources that provide input and policy rules to the policy engine when it makes decisions. This is to say, the policy engine can almost be thought of as the 'brain' of an organization's ZTA. And this brain's primary thought process amounts to a Trust Algorithm that integrates input to make the allow/deny decision for an access request.

ZTA Deployment Cycle

At a high-level, these are the steps NIST recommends organizations take to introduce ZTA to a traditional, perimeter-based network.

Practical Questions

When it comes to implementing NIST's theoretical approach to zero trust architecture, an organization will have to ask itself a number of practical questions. These include:

  • How many Policy Decision Points (PDP) do you have?

  • How many Policy Information Point (PIP) integrations are required?

  • How many different groups own these different PIPs and PDPs?

  • How do you plan to operationalize zero trust?