Zero Trust Architecture

Abstract

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

Migrating to Zero Trust Architecture: Reviews and Challenges

“…ese problems brought about the concept of "Zero Trust" (ZT) in which an enterprise must assume that there is no implicit trust in every subject. In the ZT security model, the enterprise-owned environments are considered no more trustworthy than any nonenterprise-owned environment [2]. More details regarding ZT and zero trust architecture (ZTA) are provided in Section 2.…”

“…ere are 5 major logical components in ZTA as displayed in Figure 1: subject, resource, policy decision point (PDP), policy enforcement point (PEP), and supplement [2]. Subject refers to a user or any device requesting access to the enterprise resources.…”

“…NIST SP 800-207 [2] classifies ZTA deployment into 4 types, i.e., device agent-based, enclavebased, resource portal-based deployments, and lastly the ZTA deployment using device application sandboxing, depending on how resources are managed and safeguarded. ere are both agent and agent-less approaches with PEP acting as a gateway to the enterprise resources.…”

“…e goal of utilizing a sandbox in this model is to prevent the trusted application from any malicious activities that may originate from a possibly compromised subject (host). Please refer to Section 3.2 of [2] for further information regarding the ZTA deployment model.…”

“…Generally, the legacy method of perimeter-based security allows the use of an implicit trust in which once the subject is authenticated and allowed to enter the internal network, it is considered trusted. is allows a malicious (compromised) subject to perform further lateral movement and roam freely once it infiltrated the internal network [2].…”