The term "zero trust" can lead you to believe that it may be an impossible concept to apply. You may think, "How can we build systems and applications that trust nothing?" Fortunately for us, it’s not as extreme as it sounds. Referencing the National Institute of Standards and Technology (NIST) Special Publication 800-207 as a guide, you come to understand zero trust as a principle that is less about not trusting anything and more about not trusting by default.

What Is Zero Trust?

A traditional network environment focuses on protecting the network from external threats. Once traffic makes it past the perimeter, an implicit level of trust is given. In practice, that means authenticated users can freely access resources within the network, because the assumption made was, "if they got through the front door, then they must belong here."

That logic collapses when you consider the possibility of an attacker compromising an internal system or using stolen credentials. Since they’re now inside, does that mean they belong there with access to a company's sensitive resources? Certainly not.

Zero trust challenges this way of thinking and how we design security around access. The fundamental principle relies on explicitly verifying all systems, applications, and users. Regardless of where a request originates, it gets evaluated against several criteria before access is granted.

How NIST SP 800-207 Helps

NIST released SP 800-207 to give organizations a guideline for implementing zero trust architecture.

It offers a baseline of what zero trust architecture is and what it should look like operationally, with emphasis on the components, how they should interact, and the principles that should guide implementation decisions. That gives an organization something to measure its own implementation against.

The Principles

NIST lays out seven principles that define zero trust architecture and help an organization decide how to integrate it into its environment. Some carry more weight in practice than others, but each one contributes to the model.

Resources

All data sources and computing services, such as database servers, applications, and file shares, are considered resources that need protection. There are no tiers where some systems are trusted and others are scrutinized, because zero trust evaluates all systems equally.

Secure Traffic

Regardless of network location, all communication must be secured. Traffic between two servers in the same data center should be authenticated and encrypted the same way traffic coming in from the internet is. This is a big change from traditional perimeter security, because internal and external traffic now receive the same level of scrutiny.

Device Evaluation

To make good access decisions, you must first evaluate the security of a requesting device. A zero trust platform checks whether a device is patched and running the appropriate security software, and whether it's showing signs of compromise. The answers to these questions feed into access decisions, and because the device is monitored continuously, a change in its posture can affect the next request.

Continuous Data Collection

The organization must collect as much information as possible about the current state of its assets, network infrastructure, and communications. That data feeds back into the zero trust platform, where it informs the policies that future requests are evaluated against.

Policy Decisions

Access to resources is determined by a policy that considers several factors:

  • Who's requesting access
  • What device they're using
  • Where they're connecting from
  • What they're trying to access
  • What time it is
  • What the current threat level looks like

Each request is evaluated on a per-session basis against specific conditions. This session-based approach means access can be revoked as conditions change.

Let's walk through what happens when someone tries to access a resource in a zero trust environment.

When an employee needs to access a customer database to pull a report, the request first goes to the Policy Enforcement Point (PEP). This is the gatekeeper standing between the employee and the database. The PEP hands the request to the Policy Administrator (PA), which works with the Policy Engine (PE) to find out whether the request should be allowed. Together, the PE and PA make up what NIST calls the Policy Decision Point (PDP).

The Policy Engine checks the request against configured policies, using the factors above. This list is not exhaustive; an organization gets to determine its own access conditions.

Maybe one policy says database access requires an employee to be authenticated, having successfully completed MFA in the last hour, connecting from an approved geographic location, and using a managed device with the latest patches.

If the Policy Engine approves the request, it communicates this to the Policy Administrator to carry out the decision. The Policy Administrator then instructs the Policy Enforcement Point to open the session and issues whatever the connection requires, like a short-lived token or a set of session credentials. When the session ends or conditions change, the same path is used to shut it down.

Where to Start

Applying zero trust to your environment doesn't require a tear-down. NIST SP 800-207 gives you a guide you can apply to any environment. Start with a gap analysis. Finding where implicit trust exists in your environment points you to the areas that need better access decisions.