NIST SP 800-207: Zero Trust Architecture

NIST Special Publication 800-207 on Zero Trust Architecture (ZTA) offers guidance and a roadmap for deploying zero trust security concepts in an enterprise environment. Here's the abstract:

Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterprise- owned network boundary. Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource. This document contains an abstract definition of zero trust architecture (ZTA) and gives general deployment models and use cases where zero trust could improve an enterprise’s overall information technology security posture.

Over the years, the network infrastructure for traditional enterprises has grown increasingly complex, and perimeter-based network security controls are not effective in dealing with modern threats. This has led to the development of the zero trust (ZT) security model, which moves away from the implicit trust lent by a network location and towards a continual validation of the identity and security posture of each access request. ZT is not a single architecture or product but a set of guiding principles to improve the security posture of an organization, and the transition to a ZTA will require technology and process changes over time.

Tenets of Zero Trust

All data sources and computing services are considered resources.
All communication is secured regardless of network location.
Access to individual enterprise resources is granted on a per-session basis.
Access to resources is determined by dynamic policy - including the observable state of client identity, application/service, and the requesting asset - and may include other behavioural and environmental attributes.
The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

A Zero Trust View of a Network (Assumptions)

The entire enterprise private network is not considered as implicit trust zone.
Devices on the network may not be owned or configurable by the enterprise.
No resource is inherently trusted.
Not all enterprise resources are on enterprise-owned infrastructure.
Remote enterprise subjects and assets cannot fully trust their local network connection.
Assets and workflows moving between enterprise and non-enterprise infrastructure should have a consistent security policy and posture.

Logical Components of Zero Trust Architecture

Core Zero Trust Logical Components (image source: NIST)

The core logical components of an ideal ZTA, and their interactions, are shown in the figure above. The ZTA components use the control plane to communicate, while application data is sent on a data plane. The policy decision point and policy enforcement point are core to ZTA, while others are supporting components.

Policy engine (PE): responsible for the ultimate decision to grant access; feeds enterprise policy and input from external sources to a trust algorithm.
Policy administrator (PA): responsible for communicating with the PEP to execute the PE decision.
Policy enforcement point (PEP): responsible for enabling, monitoring and terminating connections between users and resources, with input from PA.
Continuous diagnostics and mitigation (CDM) system: responsible for cataloguing enterprise assets and their posture, and feeding it to PE.
Industry compliance system: ensures that the enterprise complies with regulatory requirements.
Threat intelligence feeds: shares threat and vulnerability data with PE.
Network and system activity logs: collects asset logs, network traffic, resource access actions and other relevant events.
Data access policies: attributes, rules and policies for resource access.
Enterprise public key infrastructure (PKI): responsible for generating and logging certificates issued to users, resources, services and applications.
ID management system: responsible for creating, storing and managing enterprise user accounts and identity records.
Security information and event management (SIEM) system: collects and analyzes security events.

ZTA Approaches

ZTA using enhanced identity governance: uses the identity and attributes of actors as the key component of policy creation; may be augmented by device status, asset status and environmental factors.
ZTA using micro-segmentation: places resources on unique network segments protected by gateway security components; may implement host-based micro-segmentation using agents too.
ZTA using network infrastructure and software defined perimeters: uses an overlay network i.e. software-defined perimeter approach.

ZTA Deployment Models

Device agent/gateway-based deployment: an agent on enterprise-issued assets to coordinate connections, and a gateway/proxy in front of the protected resources to approve connection requests; does not support BYOD.
Enclave-based deployment: variation of the above model with all resources within an enclave protected by the same gateway/proxy; does not protect each resource individually, increasing the blast radius of a compromise.
Resource portal-based deployment: no agent on enterprise assets, resulting in limited visibility into device health; supports BYOD.
Device application sandboxing: enterprise assets run approved, vetted applications inside a sandbox; leads to increase in maintenance overheads.

ZTA Trust Algorithm

The trust algorithm is the process used by the PE to grant or deny access to resources. The inputs to this process may be weighted, and can be categorized into access request, subject database ("who"), asset database and observable status, resource requirements, and general threat intelligence. The trust algorithm may be evaluated based on qualified criteria vs confidence scores, or based on individual vs contextual (historical) access requests.

ZTA Network Requirements

In a ZT environment, the control plane for network control communications should be separate from the data plane for application/service communications. In addition, the following network requirements should be considered:

Enterprise assets have basic network connectivity.
The enterprise must be able to distinguish between what assets are owned or managed by the enterprise and the devices' current security posture.
The enterprise can observe all network traffic.
Enterprise resources should not be reachable without accessing a PEP.
The data plane and control plane are logically separate.
Enterprise assets can reach the PEP component.
The PEP is the only component that accesses the PA as part of a business flow.
Remote enterprise assets should be able to access enterprise resources without needing. to traverse enterprise network infrastructure first.
The infrastructure used to support the ZTA access decision process should be made scalable to account for changes in process load.
Enterprise assets may not be able to reach certain PEPs due to policy or observable factors.

Threats Associated with ZTA

A ZTA can help reduce overall security risk significantly, but the implementation and maintenance of ZTA can pose its own threats too.

Subversion of ZTA decision process: unauthorized or erroneous changes to the PE configuration rules.
Denial-of-service or network disruption: operational errors, cloud service outages, heavy usage, or denial of service attacks on the PEP or PE/PA.
Stolen credentials/insider threat: social engineering or other means of administrative account compromise, usually where MFA is not enabled.
Visibility on the network: lack of visibility into non enterprise-owned assets, encrypted traffic, or applications/services that are resistant to passive monitoring; metadata analysis and machine learning can be adopted.
Storage of system and network information: audit logs, scan results, raw network traffic and metadata, stored for future analysis, become a honeypot for attackers and can aid in reconnaissance activities.
Reliance on proprietary data formats or solutions: enterprise may be locked into ZTA providers due to interoperability issues.
Use of non-person entities in ZTA administration: impersonation of non-human entities (e.g. service accounts) in administrative activities.

Migrating to a ZTA (Roadmap)

Implementing a ZTA should be viewed as a journey rather than a replacement of infrastructure and processes. An enterprise should baseline their assets, subjects, business processes, traffic flows, and dependency mappings before starting the ZTA journey. The enterprise should recognize that they will be in a hybrid state for an extended period of time, and should identify low-risk candidate solutions to kickstart the migration based on compatibility with ZTA principles. Once the candidate workflow and ZTA components are chosen, the deployment can start in a reporting-only mode to avoid business disruptions.

A gist is meant to offer an "escalator preview" of the white paper being reviewed. It is not intended to be exhaustive or to offer an opinion, and readers are encouraged to read the white paper in its entirety for full benefit.