NIST has published a draft Zero Trust Architecture (ZTA) special publication (SP.800.207). The purpose is to develop a technology-neutral lexicon of the logical components of a zero trust strategy, and to define ZTA, describe possible deployment scenarios, and highlight threats.
NIST stresses that the primary purpose of the document (PDF) is to develop a standard taxonomy for ZTA components rather than give guidance or recommendations on how to deploy them. Nevertheless, the document provides a very detailed introduction to the components, their interrelationship, the problems involved, and how the components could be implemented in a migration to a zero trust architecture.
Zero trust is a security approach designed to counter the loss of a defendable perimeter in the modern distributed, cloud encompassing, remote working infrastructure. With no ‘visible’ perimeter, zero trust suggests that enterprises consider everything — whether part of the internet or owned by the enterprise — to be hostile. There is zero assumed trust in any access to protected resources, whether the access is attempted north/south or east/west or is by a person or a process.
“In this new paradigm,” says NIST, “an enterprise must continuously analyze and evaluate the risks to their internal assets and business functions and then enact protections to mitigate these risks. In ZTA, these protections usually involve minimizing access to resources to only those who are validated as needing access and continuously authenticating the identity and security posture of each access request.”
NIST warns that ZTA is not a single architecture but a set of principles that cannot be fully implemented without a “wholesale replacement of technology.” It suggests that organizations should seek to incrementally implement zero trust principles and operate a hybrid zero trust/legacy mode during the transition.
In the NIST idealized zero trust architecture, there are three areas: access actor, policy enforcement point (comprising a policy engine and a policy administrator), and the enterprise resource. The actor does not differentiate between a person, a process, or a location; but the policy enforcement point needs enough information to confidently allow or deny access to the required resource.
Core Zero Trust Logical Components
This decision by the policy engine is supported by multiple data sources from both within and outside the enterprise. Such sources could include:
A continuous diagnostic and mitigation (CDM) system, to ensure that all necessary patches have been applied, that the access actor is running the appropriate and patched operating system, and is free of known vulnerabilities.
An industry compliance system to ensure that the enterprise and any request remains compliant with any necessary regulatory regime.
Threat intelligence feeds that will provide information about newly discovered attacks or vulnerabilities, and DNS blacklists that might cause the policy engine to deny the actor’s request.
Data access policies, comprising the rules and policies concerning access to specific resources as defined by the enterprise. These rules could be encoded in the policy engine, or dynamically generated by the policy administrator.
Enterprise PKI, responsible for generating and logging certificates issued to resources, actors and applications. This should include the global CA ecosystem and the Federal PKI where applicable.
ID management system, responsible for creating, storing, and managing enterprise user accounts and identity records, and containing the necessary user information.
A SIEM, which aggregates logs, network traffic and resource entitlements providing data that can be used to refine policies and warn on possible active attacks against the enterprise.
These are logical components of a ZTA, and do not all need to be discrete systems. Similarly, there are possible variations on this thematic, such as a device agent/gateway-based deployment, a microperimeter-based deployment, and a resource portal-based deployment. In all cases, however, the basic intent is the same — to have a policy enforcement point with sufficient information to deny or allow access to an access actor that by definition starts from an untrusted position.
In all cases, the decision to grant or deny access is provided by a trust algorithm typically in or used by the policy engine. The policy engine is the brain of the system, taking data from the various components, weighting its importance, and applying the access policy. The decision is then enforced by the policy administrator component.
Just as there are various possible configurations of the ZTA, so are there various approaches to the trust algorithm. NIST gives two concepts: criteria versus score-based, and singular versus contextual. In a criteria algorithm, different criteria for different resources must be met by the access actor before access is granted. In a score-based system, different weights for different resources can be applied to the access actor. If a required score is reached, access is granted.
A singular rather than contextual algorithm looks at each access request individually. This can provide fast decisions, but could allow attacks that stay within a user’s allowed role to remain undetected. Contextual algorithms include the user’s recent activity. It requires the policy engine to retain some information on each user’s recent requests, but may be more likely to detect the use of subverted credentials if an unusual pattern is seen.
A zero trust architecture, says NIST, “can reduce overall risk exposure and protect against common threats. However, there are some threat risks unique to ZTA.” First and foremost, since the policy engine is the brain of the whole concept, any subversion of that engine would be damaging. This could be done purposefully by an attacker with the correct credentials, or accidentally by a legitimate user. The policy engine and policy administrator components “must be properly configured and monitored, and any configuration changes must be logged and subject to audit.”
Denial of service, by whatever cause, is another issue. If access to the policy enforcement point is prevented, and zero trust implemented, it will adversely affect enterprise operations. This can be mitigated to an extent by locating the engine in the cloud, or replicating it across several locations. This doesn’t eliminate the threat. NIST points to the power of IoT botnets such as Mirai that could deliver massive DDoS attacks against key Internet service providers.
It points to potential errors from the hosting provider that could accidentally take the policy enforcement point offline. “Similar to the Amazon S3 outage in February 2017 that prevented access to customers, an operational error could prevent an entire enterprise from functioning if the policy enforcement component becomes inaccessible from the network.”
ZTA reduces but does not eliminate the insider threat. It would help contain the threat by preventing lateral movement, but an insider with valid credentials will still be able to access all parts of the network allowed to the credentials. Use of MFA would reduce this residual threat further.
Non-person entities (NPE) potentially pose a greater threat than people since authentication is usually just an API key rather than MFA. An associated risk is that where an attacker can induce or coerce an NPE agent that interacts with the ZTA, the attacker could alter the operation of the ZTA and introduce scope for a wider attack.
While NIST believes that ZTA is an effective strategy for improving security and limiting or preventing lateral movement, it notes that it is new approach effective against existing attacker techniques. It is not known how attackers will evolve their techniques against ZTA in the future.
NIST describes the implementation of ZTA as a journey rather than the wholesale replacement of existing infrastructure. However, all journeys have a starting point, and NIST warns that this must be from a baseline of competence that includes a catalog of all assets, physical and virtual users and business processes. This information is required by the policy engine when evaluating access requests. If it is incomplete, it could lead to a business process failure where the policy engine denies valid requests due to insufficient information.
Theoretically, a new business with no existing infrastructure could build its ZTA from the ground up. This is not likely for any existing organization. Similarly, it is unlikely that any existing organization could migrate to ZTA in a single technology refresh cycle. “There will be a (perhaps indefinite) period of time when ZTA workflows coexist in a traditional enterprise,” says NIST. “The migration to a ZTA approach to the enterprise may take place one business process at a time.”
Workflows using ZTA should be implemented incrementally. NIST suggests that initially an application used by a subset of users (such as a purchasing system) might be preferred over an application vital to everyone (such as email). The administrators then need to determine the criteria or trusted score weights that need to be applied to the resource, and make adjustments during the tuning phase of implementation.
From a list of candidate business processes, a list of candidate solutions can be developed. NIST warns that some solutions may require components to installed on the client system, which may limit processes where non-enterprise-owned systems are used (such as BYOD). Other solutions may assume that that requested resources will reside in the cloud rather than within an enterprise perimeter.
NIST suggests that one solution is to start with a pilot program operating in a ‘reporting only mode’ rather than a replacement. This pilot can then be used as a proving field for ZTA before more fully transitioning to ZTA from the traditional process infrastructure. From a successful pilot program, the move to ZTA can be expanded to other workflows.
Related: The (Re-)Emergence of Zero Trust