This article is part of our series on Zero Trust. For more information on Zero Trust, check out Zero Trust, Explained.
Have you been searching for a more formal definition of Zero Trust? Look no further, NIST has you covered with Special Publication 800-207, which defines a Zero Trust Architecture.
If you haven't read it, we highly recommend it — at 50 pages, it doesn't take long. However, busy people who don't have the time to analyze the architecture may find this short summary useful.
In this article, we'll cover:
When the Biden Administration directed the US Federal Government to adopt Zero Trust with Executive Order 14028, implementors needed a way of knowing if they were on the right track. Recognizing this, EO14028 also directed NIST to develop formal guidance for implementors, and NIST created SP 800-207 as the definitive reference in response.
NIST SP 800-207 was released in August 2020.
The core of the NIST Zero Trust Architecture — Figure 1 in the spec — is shown below.
National Institute of Standards and Technology (2020) Zero Trust Architecture. (Department of Commerce, Washington, D.C.),
Special Publication 800-207, https://doi.org/10.6028/NIST.SP.800-207
While there are several variations and models that are presented in the document, this diagram underpins all of them.
The user or application on the left is considered untrusted, and this digram shows how trust is established and enforced. But to analyze this diagram, we will start on the right, and move to the left.
This figure shows that Zero Trust protects some kind of resource - a system, some data, or an application. As far as NIST 800-207 is concerned, Zero Trust doesn't protect networks, clouds, or even users' endpoints. It protects resources.
The resource is presumably something of high value, such as a database, an application, or a collection of IoT or OT devices - something that is really worth the effort to protect.
The arrows to the resource are bidirectional; the diagram does not specify the direction or mode of access. The Zero Trust Architecture should apply to all possible modes (for example, normal resource access over https as well as ssh needed for maintenance by the resource owner) and directions (inbound to block malware coming in from the outside, outbound to block data leaking from the inside).
Moving to the left, we encounter the Implicit Trust Zone. Even though it is not depicted as a zone in the diagram, the Implicit Trust Zone refers to the network zone where all communications is implicitly trusted.
Let's say the resource is a HR application, which may consist of a front end web server that serves user sessions, and a back end database server that hosts the HR database. If the HR application is the resource to be protected with Zero Trust, then both components may be placed in the same network zone so they can communicate with each other. If there are no security controls applied between these two components, then they implicitly trust each other.
Continuing our journey toward the user, we reach the policy decision/enforcement point. Technically, these are two separate functions, but shown merged here together for simplicity.
The policy decision point (PDP) is responsible for making an access decision. NIST SP 800-207 does not specify how it makes the access decision or what factors it should use, but the general idea is that at a minimum, the identity of the user or device requesting access (authentication) and the right of that user to complete the access (authorization) should be checked somehow. This validation process builds the trust necessary to allow the access.
The policy enforcement point (PEP) is responsible for enforcing the security decision of the policy decision point. It may also serve as the initial access point, collecting the factors needed to make a decision and passing them on to the policy decision point.
This is a lot like the boarding process at the airport - the gate agent (PEP) collects your boarding pass (the factor to be checked) and checks with the computer (PDP) to see if you are allowed to board. The gate agent is responsible for enforcing the computer's decision.
The access originates from the untrusted zone, which is everything outside the implicit trust zone. Note that this includes everything in the corporate network - users in the office, users coming in from VPN, and machines in the datacenter, for example.
We continue leftward from the untrusted zone and reach the user's machine. However, accesses may not always originate from a human, so NIST 800-207 uses the term subject instead, highlighting the fact that non-human accesses must also be secured. The subject is subjected to Zero Trust checks and validation in order to access the resource.
NIST 800-207 defines several models for consideration when planning Zero Trust protection for a resource. They are:
With this understanding of the NIST 800-207 Zero Trust Architecture, let's turn our attention to the key questions that should be answered when planning for Zero Trust security:
This may be particularly true if the resource prioritizes availability over confidentiality and integrity.
Zentera's CoIP Platform combines the best options from the NIST 800-207 logical architectures.
Identity
CoIP Platform implements strong identity-based controls, authenticating users against the identity provider and MFA scheme of your choice, fingerprinting user devices, and identifying client software and process context that can inform the authorization decision.
Micro-Segmentation
CoIP Platform implements powerful micro-segmentation, allowing you to cloak resources to hide them on shared networks, without making any changes to the application or network infrastructure.
Software-Defined Perimeters
CoIP Platform implements a Layer 5 overlay network that is transparent to applications at Layer 7 and the networks at Layer 4 and below. This puts the subject and resource in a private network, subject to authorization and authentication.
For a more detailed overview of how CoIP Platform implements NIST 800-207, click below to download our whitepaper.