A Guide to the NIST Zero Trust Architecture

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.

The Resource

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).

The Implicit Trust Zone

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.

The Policy Decision/Enforcement Point

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 Untrusted Zone

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.

The Subject

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.

Deployment Models for a Zero Trust Architecture

NIST 800-207 defines several models for consideration when planning Zero Trust protection for a resource. They are:

• ZTA Using Enhanced Identity Governance
  
  This model uses an open network, where all resources are open and accessible; the identity of subjects is checked prior to granting access at the application level. An example would be requiring identity and MFA to guarantee users are identified and have authorization to access an HR web application.
  
  The problem with this model is that controls that are baked into an application are only effective for that application. In the HR web app example, enhanced identity governance alone would not prevent a malicious actor in the network from probing other open network ports and moving laterally onto the HR web app server. This shortcoming makes enhanced identity governance alone a relatively weak approach for enforcing Zero Trust.
  
  
• ZTA Using Micro-Segmentation
  
  This logical model uses microsegmentation to create the implicit trust zone. NIST 800-207 mentions that this could be accomplished by programming switch access control lists (ACL), deploying resources behind next-generation firewalls, or by installing software agents to the resource.
  
  It is important to note that microsegmentation by itself is not aware of identity, and is used only for the purpose of creating the implicit trust zone; NIST 800-207 points out that "[t]his approach requires an identity governance program (IGP)..." In other words, micro-segmentation alone is not a ZTA, as it must be combined with some other kind of identity check.
  
  
• ZTA Using Network Infrastructure and Software-Defined Perimeters
  
  The final model uses software-defined perimeters (SDP), which are based on overlay networks. An overlay network builds a private and secure communications channel from the subject to the resource, leveraging communications at a different level of the OSI stack.
  
  This model overcomes the shortcomings of the previous models as it allows identity to be used for overlay network setup and access decisions. In this model as defined, traditional network infrastructure techniques are used to create the implicit trust zone, but fundamentally, nothing prevents these models from being combined.

Key Considerations for Selecting a Zero Trust Architecture

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:

• What resource am I protecting?
  
  All of the other questions hinge on this critical question - the considerations for protecting a HR web app in the cloud will be radically different from the considerations for a SCADA server in a nuclear power plant. Again, NIST 800-207 Zero Trust is not about protecting networks or users, so you need to start by answering this key question.
  
  
• How will I create the implicit trust zone?
  
  Once you have defined what you're protecting, ask yourself how you plan to enforce the implicit trust zone. In many cases, network infrastructure-based methods like switch ACL programming or VLANs are difficult to implement and hard to change; is disrupting the availability of an application an option?
  
  If infrastructure methods are undesirable, consider "zero touch" deployment models, like software agents or gatekeeper appliances.
  
  
• Who needs to access the resource, and how?
  
  If the implicit trust zone is properly enforced, you will need policies that enable access for all authenticated and authorized subjects.
  
  This can be tricky, as some of the policies may be obvious (e.g. https access to the HR web app), while others may be known only to the application owner (e.g. ssh access for maintenance, outbound connections to an application performance monitor) or to IT/Infosec (e.g. EDR tools or syslog aggregators).
  
  To streamline this process, look for tools that support Learn functions, which generate a baseline of normal resource traffic to support visibility and coverage.
  
  You may also consider using a mix of criteria-based policies, which map authorizations to specific subjects, and score-based policies, which score the trust of an access based on some defined characteristics such as subject location.
• What Zero Trust policy controls do I need for this resource?
  
  You may find that different resources have quite different requirements for policy controls based on security or compliance requirements.
  
  For example, user authentication and authorization may be sufficient to protect an HR web app in the United States with Zero Trust. However, the same web app hosted in the EU may also be subject to GDPR requirements; in this case, it may be useful to apply country-level location controls to ensure that access comes from within the EU.
  
  
• How can I defeat the controls if necessary?
  
  As with any security tool, having "break glass" capabilities can be important in the event the security is "too secure." However, implementing a fallback can be difficult with network infrastructure methods; once you have moved the resource into its own VLAN, it is a huge effort to move it back.
  
  

  This may be particularly true if the resource prioritizes availability over confidentiality and integrity.
  

  
  

How CoIP Platform Implements NIST 800-207

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.