A Close Read at NIST’s Definition of Zero Trust Architecture

This is written based on the second draft of SP 1800-35.

NIST has released the second preliminary draft of SP 1800-35, Implementing a Zero Trust Architecture. The lengthy documents lay out their definition of Zero Trust Architecture (ZTA), the benefits, why it’s important, a few examples of how an organization can implement them, expected results associated with their example builds, and a mapping of ZTA security characteristics to current cybersecurity standards and compliance.

There’s a lot to dig through and we highly recommend interested practitioners to take the time to read through it all. However, given that some of the volumes are over 100 pages in length, we thought we’d help save some time. This post pulls out NIST’s definition of ZTA for some closer examination of what is being said (and unsaid). We’ll dig into it here, what it means, and why it’s important with some commentary.

(Not entirely sure what Zero Trust even is? Here’s a no-marketing-fluff Children’s Guide to Zero Trust you can read to your children … or executives!)

Ultimately, why should organizations care?

NIST’s Definition of Zero Trust Architecture

Here’s how NIST defines ZTA in the Executive Summary of NIST SP 1800 Volume A, Page 1, Line 9.

Those five sentences are doing a lot of heavy lifting. Let’s break that down sentence by sentence.

1. ZTA provides secure access to all assets based on access policy

A zero-trust architecture (ZTA) enables secure authorized access to assets—machines, applications and services running on them, and associated data and resources—whether located on-premises or in the cloud, for a hybrid workforce and partners based on an organization’s defined access policy.

Today, organizations of all sizes can be expected to have complex infrastructure spanning multiple clouds, on-premise or hybrid-combinations of servers, third-party platforms, and other varied assets from mergers and acquisitions.

So What?

ZTA asks: How do you defend a perimeter that can’t be defined or enforced?

When VPNs are tunneling in and data is transitioning from on-prem to the cloud to a third-party tool or service, where exactly is your perimeter? The only perimeters that exist today are for networks that are fully on-prem and are not constantly connected to the internet.

And as the concept of the perimeter becomes either meaningless or unenforceable, protecting sensitive assets and resources has become harder and more meaningful in an increasingly connected world. This is the reason why organizations should begin adoption of ZTA.

2. How does ZTA secure this access?

For each access request, ZTA explicitly verifies the context available at access time—this includes both static user profile information or non-person entity information such as the requester’s identity and role; and dynamic information such as geolocation, the requesting device’s health and credentials, the sensitivity of the resource, access pattern anomalies, and whether the request is warranted and in accordance with the organization’s business process logic.

This sentence dives into the how — a brief overview of why ZTA will function effectively as the solution. ZTA verifies the following for each access request:

• Identity and role (verifying identity is where most existing security postures stop)
• Contextual and dynamic information (why does context even matter?)
• Device health and credentials (an increasingly important piece of context)
• Resource sensitivity (how bad is it if this data gets stolen?)
• Access patterns (another piece of context)
• Request context (does it make sense to grant this user access to the Finance department’s credit card database?)

ZTA and infrastructure changes are closely intertwined due to the limitation of existing infrastructure in incorporating all necessary information into the access control system. It is a starting point that all of these need to be met before a particular system can be considered zero trust.

Note that while this explains each of the information buckets that feed into the overall access decision, NIST has an entire How-To Guide for making the infrastructure support this architecture.

So What?

It turns out an access control system is only as good as the data used in policy decisions.

If you’ve noticed “identity-aware” shifting towards “context-aware,” this is the reason. Identity-aware access controls can authenticate the requesting entity, but identity is merely a subset of context. Access control decisions should be informed by all the data feasibly possible. In fact, compromised credentials (which is basically identity) cause 19% of data breaches.

Organizations want ZTA’s context-aware access controls to protect themselves from situations where identity checks out but context does not, such as malicious insiders, compromised credentials, and more.

3. The resulting secure session

If the defined policy is met, a secure session is created to protect all information transferred to and from the resource.

Only after everything checks out does the user get access.

So What?

While it seems obvious to grant access only after verifying everything, the amount of breaches and unsecured portals tells us that this best practice is not well-practiced. Moreover, access is being granted that isn’t then being monitored and assessed, resulting in the next line…

4. Emphasis on continuous assessment to maintain access

A real-time, risk-based assessment of resource access and access pattern anomaly detection with continuous policy evaluation are performed to establish and maintain the access.

This is continuous verification, a core component of zero trust. Just because the accessing entity passed the check at first and is now granted a session doesn’t mean your infrastructure should grant access throughout the session.

A zero trust architecture should be continuously validating the entity’s authentication and authorization alongside any contextual and dynamic information with the goal of restricting access the moment something looks wrong.

So What?

If you let a plumber into your house to fix the pipes but they begin stealing food from your refrigerator, wouldn’t you want to kick them out?

And yet, most organizations aren’t continuously validating what users are doing in each session; typically, they only bother to check if the requesting entity is authenticated when waving them in. Insider risk, stolen tokens, and compromised credentials have proven that organizations need to continuously verify and validate user activity and requests throughout the session.

ZTA infrastructure recommends incorporating continuous verification by implementing short-lived sessions that provide visibility into what users are doing and whether it’s even acceptable (based on policy). If a user’s activity seems to trespass beyond the organization’s risk tolerance, ZTA empowers the organization to act on it by restricting access, mitigating the damage done.

5. ZTA protects organizations from variables outside of their control

A ZTA can also protect organizations from non-organizational resources that their users and applications may connect to, helping to stop threats originating from outside of the organization’s control.

This dives into how malware and malicious access can originate from events outside of the organization’s control.

While the immediate thought might be protecting the organization’s infrastructure from unsecure networks or compromised user devices, ZTA wants to go a step beyond that. From smart devices to various connectivity enablers, ZTA assumes that the public internet has a path to access sensitive resources unless extraordinary steps are taken to sequester said resources.

So What?

ZTA acknowledges the modern reality of our digitally connected world: everything is connected and hostile until proven safe.

Security posture may have previously examined internal and external threats, but ZTA demands a new security posture: one that assumes you are already hacked (because given the mean time to identify, you probably already are).

Many assume that zero trust means trust nothing, but it simply means that you don’t implicitly trust anything until you’ve established it is safe. From there, ZTA asks you to replace the variables you used to trust (e.g., perimeter and identity) with contextual factors around the user, device identity, and state to establish trust.

Integrating this concept helps organizations better protect their sensitive data and resources from internal or external forces whether it be malicious or negligent in nature.

Implementing Zero Trust Architecture

Luckily, implementation doesn’t need to happen overnight. NIST acknowledges it in Volume B, line 561:

Enterprises should use a risk-based approach to set and prioritize milestones for their gradual adoption and integration of ZTA across their enterprise environment.

Adopting ZTA is never rip and replace and should be a gradual roll-out across an organization’s enterprise environment. For those who want to see some architecture examples and expected results, NIST includes How-To Guides and Functional Demonstrations in NIST SP 1800-35.

If you just want to start implementing access control to sensitive resources today, Pomerium is an open-source context-aware access gateway to secure access to applications and services following NIST’s best practices as outlined above. Our customers depend on us to secure zero trust, clientless access to their web applications everyday.

You can check out our open-source Github Repository or give Pomerium a try today!