Background
Since the first animal took a bite out of its neighbor, security concerns have driven an ever-escalating evolution of threat and defense. The evolutionary call and response between threat actors and defenders is punctuated by periods of rapid change between periods of stasis.
We are now in such a period of rapid change. The current security landscape presents us with twin competing challenges: cyber attacks have rapidly increased in scale and sophistication while, at the same time, modern, cloud-native architectures have outgrown traditional network security practices.
In an effort to modernize the security posture of federal agencies and private industry to meet these new challenges, the US government has endorsed zero trust network architecture as a way forward. The National Institute of Standards and Technology (NIST), the body tasked with defining the standards and deployment recommendations for zero trust in the enterprise, has authored a series of special publications to do just that.
In this article, the first of two on NIST zero trust standards, we’ll review NIST’s cornerstone paper, SP 800-207: Zero Trust Architecture, which defines the tenets of zero trust network security and offers recommendations for how to adopt it in your organization.
Why Anything?
Security threats now operate at industrial scale. The same market forces that shape advanced economies have also motivated high-scale economies of cybercrime. In addition, asymmetric geopolitics has made cyber attacks attractive to a range of actors seeking geopolitical leverage. For instance, the war in Ukraine has prompted the US government to issue an urgent warning that Russia may be ramping up cyber attacks.
At the same time, the increasing complexity of modern applications and their deployment environments has outstripped legacy approaches to network security. Even before recent global tensions raised the stakes, legacy perimeter security strained to meet the demands of an enterprise with hundreds to thousands of services spread across multiple clouds and on-premises deployments.
The current challenge is more serious in degree, but also different in kind to the past, which means we need a new security architecture, not just a strengthening of the castle walls. The threat landscape is now acutely more dangerous than it was just a few weeks ago, which means we need to act now.
Why Zero Trust?
Traditional network security relies on a strong defensive perimeter around a trusted internal network to keep bad actors out and sensitive data in. In an increasingly complex networking environment, maintaining a robust perimeter is increasingly complex, expensive, and ineffective. Zero trust architecture inverts the assumptions of perimeter security. In a zero-trust network, every resource is protected internally as if it were exposed to the open internet. Instead of—or, in addition to—building fixed fortifications around a static, vulnerable population, zero trust arms its citizens with lightweight, but highly effective armor suitable for all conditions.
Zero Trust Architecture According to NIST
In SP 800-207, NIST defines zero trust as a set of guiding principles rather than a specific technology or implementation. The goal of a zero trust architecture is to prevent unauthorized access to data and services by making access control enforcement as dynamic and granular as possible, taking into account many aspects of a request, including the “who, what, when, where, and why” of the request. This means that simply being connected to a trusted network isn’t enough to give you the keys to the kingdom; each access request is scrutinized carefully.
Rather than rely on static, trusted network locations—such as an internal enterprise network or VPN—zero trust seeks to dynamically authenticate and authorize network requests for enterprise resources as closely as possible to that resource, minimizing the boundary of implicit trust around all resources, ideally to zero.
Requests are required to be encrypted and are decrypted for evaluation and, if accepted, for execution. Each request is authenticated (verified as to its origin) and authorized or not authorized (certified as valid and appropriate).
Authentication and authorization decisions are made at a policy enforcement point (PEP) that mediates all communication between subjects (people or machines requesting access) and a resource (Figure 1). The PEP establishes a zone of implicit trust only between itself and the resource it protects.
All access decisions enforced at the PEP should be bounded in time (per-session or even per-request) and should be rendered dynamically, based on explicitly authored policy that takes into account contextual information about the request.
Figure 1: Zero Trust Access
The Tenets of Zero Trust
There are many ways to implement a zero trust architecture. Rather than specify any particular implementation in this paper, NIST outlines the tenets that motivate any such implementation. The SP 800-204 series on security for microservices applications goes on to offer recommendations for implementing zero trust architecture using a service mesh.
| Domain | Assumption |
| Enterprise Network Boundary | The entire enterprise private network is not considered an implicit trust zone.
Assets and workflows moving between enterprise and non-enterprise infrastructure should have a consistent security policy and posture. |
| Resources | No resource is inherently trusted. Every asset must have its security posture evaluated by a PEP before a request is granted. |
| Not all enterprise resources are necessarily on enterprise-owned infrastructure. | |
| Devices | Devices on the network are not necessarily owned or configurable by the enterprise. |
| Remote Locations | Remote enterprise subjects and assets cannot fully trust their local network connections. |
Table 1: Basic assumptions for network connectivity in a zero trust view of the network
In the context of some basic assumptions (Table 1), NIST offers the following tenets as the guiding principles of zero trust network architecture. In a zero trust network, access to all enterprise resources should be:
- Authenticated and dynamically authorized, not only at the network layer and the service-to-service layer, but also at the application layer. Network location does not imply trust. Service identity and end-user credentials are authenticated and dynamically authorized before any access is allowed.
- Bounded in time. Authentication and authorization are bound to a short-lived session, or to a single interaction, after which they must be re-established.
- Bounded in space. The perimeter of trust around a service should be as small as possible.
- Encrypted, both to prevent eavesdropping and to ensure messages are authentic and unaltered.
- Observable, so the integrity and security posture of all assets may be continuously monitored and policy enforcement continuously assured. Logging and tracing data enables auditing after the fact. Also, insights gained from monitoring and auditing should be fed back to improve both policy and practice.
Logical Components of Zero Trust Architecture
While specific implementations of a zero trust architecture may differ in topology, NIST posits a core set of logical components they all share (Figure 2), each of which may be deployed in a variety of ways, including on-premises and in the cloud. In this ideal model, the ZTA logical components communicate in a control plane while application components communicate in a separate data plane.
Policy Decision Point (PDP). The PDP is a logical system entity in the control plane that renders verdicts on access requests. It’s composed of a policy engine and a policy administrator and interacts with policy enforcement points in the data plane to enforce those verdicts.
Policy Engine (PE). The PE is responsible for the ultimate decision to grant access to a resource for a given subject. It feeds enterprise policy as well as input from external sources into a trust algorithm to grant, deny, or revoke access to the resource. The PE makes and logs policy decisions, relying on the policy administrator to execute them.
Policy Administrator (PA). The PA is responsible for establishing and/or shutting down the communications path between a subject and a resource based on policy decisions made by the PE and effected via relevant policy enforcement points. The PA relies on the PE to ultimately allow or deny access and, accordingly, programs relevant policy enforcement points to establish or shut down communication paths between subjects and resources.
Policy Enforcement Point (PEP). The PEP mediates access to resources in the data plane. It requests authorization decisions from the PDP in the control plane and enforces those decisions in the data plane. The PEP should be non-bypassable, establishing a trust boundary around a resource such that all communication with that resource is authenticated and authorized before access is granted.
Enterprise Use Cases for Zero Trust Architecture
Satellite Facilities. Enterprises with multiple geographically dispersed locations likely have remote workers who do not use enterprise-owned network infrastructure or devices. It may be impractical or impossible to route all remote employee traffic through the enterprise network. In this case, the policy engine and policy administrator are often hosted as a cloud service for superior availability.
Multi-Cloud, Cloud-to-Cloud. Enterprises using multiple cloud providers may need to provide direct access between resources located in different clouds, bypassing the enterprise network for performance and ease of management. In this case, the zero trust approach is to place policy enforcement points in front of each resource. This allows the enterprise to control policy for resources hosted outside the enterprise. A particular challenge to this approach is matching the requirements for hosting the PEP with each cloud’s differing features and capabilities.
Contracted Services and Non-employee Access. Enterprises may need to offer Internet access to on-site visitors and service providers, but limit access to internal resources. In this case, PEs and PAs placed in front of sensitive resources can deny unauthorized access to those resources.
Collaboration Across Enterprise Boundaries. Teams from different enterprises that need to collaborate with each other may need selective access to each other’s enterprise resources. In this case, providing outside users with temporary, specialized enterprise accounts can quickly become difficult to manage. In this case, both enterprises can enroll in a federated identity management system, eliminating the need for complex firewall rules or enterprise-wide access control lists.
Hosting a policy decision point as a cloud service would provide symmetric access to the authentication and authorization infrastructure to multiple enterprises.
Public or Customer-Facing Services. Enterprises that provide services to the public or to customers are constrained in what internal security policies they can enforce on those outside users. In this case, the dynamic attribute values and observability tenets of ZTA are particularly relevant. Detection and alerting of behaviors deviating from a known baseline can help security teams defend against automated attacks when, for example, there is a sudden increase in unknown or outdated browser requests. A security architecture sensitive to dynamic context and able to compare against a known-good baseline can help enterprises defend against such attacks.
Getting There: Incremental Migration
To conclude the paper, NIST offers guidance for adopting zero trust principles, advocating a repeatable, incremental approach to successively expanding zero trust adoption across the enterprise.
The first steps are to thoroughly identify the actors (who), assets (what), and business processes involved, and to formulate policies about them. NIST then offers recommendations for identifying and evaluating candidate solutions for implementing policy, followed by guidance on initial deployment and monitoring.
The incremental approach allows lessons learned from earlier migrations to be fed back into the adoption cycle while achieving steady-state operation with a proven process that can then be applied to more and more of the enterprise.
From Groundwork to Implementation
NIST SP 800-207 defines zero trust network architecture in the abstract without making specific implementation recommendations. It lays the groundwork for understanding the basic principles of zero trust and how to start thinking about adopting it in the enterprise. In our next article, we examine NIST’s SP 800-204 series, co-authored by Tetrate founding engineer Zack Butcher, on security strategies for microservices-based application systems. The SP 800-204 series takes up where SP 800-207 leaves off, offering deployment strategies for implementing zero trust networking using a service mesh.