Zero trust

Zero trust is a security model in which no subject, device or network location is trusted by default, and every access to a resource is decided individually, using current information. The reference text is NIST SP 800-207, Zero Trust Architecture (August 2020). This page summarizes it from the document: its definition, its seven tenets, its logical components, the deployment approaches it describes, and what it means for identity and privileged access. It also covers what zero trust is not.

The definition

SP 800-207 gives an operative definition:

Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.

A zero trust architecture (ZTA) is the enterprise's plan for applying those concepts: components, workflows and access policies. The document is explicit that "ZT is not a single architecture but a set of guiding principles", and that moving to it "cannot simply be accomplished with a wholesale replacement of technology".

The problem it targets is implicit trust. In a perimeter model, once a subject passes the gateway, everything inside the "implicit trust zone" trusts it. SP 800-207 uses an airport analogy: once passengers clear security, everyone in the boarding area is treated as trusted. Zero trust moves the decision point as close to each resource as possible and shrinks the implicit trust zone.

The seven tenets

SP 800-207 section 2.1 lists seven tenets. It calls them "the ideal goal" and acknowledges that not all may be fully implemented in every strategy. Paraphrased, in the document's order:

1. Everything is a resource. All data sources and computing services count as resources, including small devices, SaaS, and possibly personally owned devices that reach enterprise resources.
2. All communication is secured regardless of network location. Being on the enterprise network grants nothing. Requests from inside must meet the same requirements as requests from anywhere else, with confidentiality, integrity and source authentication.
3. Access is granted per session. Trust is evaluated before access, with the least privilege needed for the task. Access to one resource does not grant access to another.
4. Access is decided by dynamic policy. Inputs include client identity, the application or service, the requesting asset's observable state, and possibly behavioral and environmental attributes.
5. The enterprise monitors the integrity and security posture of all owned and associated assets. No asset is inherently trusted. Unpatched, subverted or unmanaged devices may get less access or none.
6. Authentication and authorization are dynamic and strictly enforced before access. This is a continuous cycle of obtaining access, assessing threats, adapting and re-evaluating trust. It assumes identity, credential and access management (ICAM) with MFA for some or all resources, and possible reauthentication during a session.
7. The enterprise collects as much information as possible about assets, infrastructure and communications, and uses it to improve policy and enforcement.

The document notes that these tenets apply to work inside an organization or with partners, not to anonymous public or consumer-facing services, where an organization cannot impose its internal policy on outsiders.

Logical components: PE, PA and PEP

SP 800-207 splits the access decision into three logical components. They are logical roles, not products. One system can play several, and one role can span several systems.

Policy engine (PE)

Makes the final decision to grant, deny or revoke access, using enterprise policy and external inputs fed into a trust algorithm. It also logs the decision.

Policy administrator (PA)

Sets up or shuts down the path between subject and resource by commanding PEPs. It may generate session-specific authentication tokens or credentials. Together, PE and PA form the policy decision point (PDP).

Policy enforcement point (PEP)

Enables, monitors and terminates connections between subject and resource. It may be split into a client-side agent and a resource-side gateway, or be a single portal.

Data sources feeding the policy engine include continuous diagnostics and mitigation (CDM) systems, industry compliance systems, threat intelligence, network and system activity logs, data access policies, enterprise PKI, the ID management system and a SIEM.

Trust algorithms

Section 3.3.1 describes two choices for how the policy engine decides. Criteria-based versus score-based: all required attributes must be met, or a weighted confidence score must exceed a threshold. Singular versus contextual: each request is judged alone, or the subject's recent history is taken into account. The document states that ideally the algorithm should be contextual, because a singular one can miss an attacker who stays within a compromised account's normal role.

Deployment approaches

Section 3.1 describes three approaches. A full solution includes elements of all three, with one usually driving policy:

Section 3.2 then describes deployment variations: device agent/gateway, enclave-based, resource portal, and device application sandboxing.

What zero trust means for identity and privileged access

• Identity becomes the main policy input. In the identity governance approach, access privileges granted to the subject are the primary requirement. That makes least privilege and access reviews core zero trust controls, not hygiene.
• Stolen credentials still work, within their scope. Section 5.3 is candid: an attacker with valid credentials "may still be able to access resources for which the account has been granted access". Zero trust limits lateral movement. It does not make an over-privileged account safe.
• Per-session, least-privilege access (tenet 3) is the architectural basis for just-in-time access.
• Strong authentication is assumed (tenet 6). For US federal agencies, OMB M-22-09 turns this into specific actions: centralized enterprise identity, phishing-resistant MFA for staff, contractors and partners, MFA enforced at the application layer rather than the network layer, and at least one device-level signal in authorization decisions. See phishing-resistant MFA.
• The PDP is a crown jewel. Section 5.1 warns that administrators with configuration access to policy engine rules can make unapproved changes, and that a compromised policy administrator could allow access that should be denied. Treat these administrators as control-plane admins (see privileged accounts).
• Non-person entities need identities too. Section 5.7 flags automated agents that authenticate with weaker credentials than humans, and the risk of an attacker tricking or impersonating them. See service accounts and secrets.

Myths

Where to start

• Inventory subjects (people and non-person entities) and assets. Section 7.3 starts here.
• Pick one business process and its resources as a first candidate rather than the whole enterprise.
• Put strong, preferably phishing-resistant, authentication in front of that process at the application layer.
• Write access policy in terms of identity attributes and device state, and remove access granted only because of network location.
• Protect and monitor the policy components and their administrators as control-plane systems.
• Log decisions and use them to tune policy before expanding to the next process.

Sources

1. NIST SP 800-207: Zero Trust Architecture, NIST. Public domain (U.S. government work).
2. OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, Office of Management and Budget. Public domain (U.S. government work).