NIST Explains Zero Trust Architecture: A Closer Look

NIST, the US National Institute for Standards and Technology, recently released SP 800-207 Zero Trust Architecture. The NIST special publication examines the principles of and motivations for ZTA, as well as implementation considerations, security concerns, and suggestions for improvements to architecture. NIST SPs are authored primarily for consumption by other US government agencies. In practice, however, their documents often become de facto standards and guidelines used more broadly in industry. In this post I’ll review the strengths of the SP and identify areas for improvement.

The NIST document serves as a good introduction for ZTA. The authors correctly describe the fundamental principles of ZTA, which are a combination of traditional security tenets of Least Privilege and Defense-in-Depth. In practice, Least Privilege means only granting sufficient permissions to accomplish specific actions and not more than that; Defense-in-Depth means inserting layers and gates of security at all relevant control points in a use case. Wide open networks behind firewalls are easy targets. These ideas have become more commonly accepted in modern security architectures, as organizations realize that firewalls and other perimeter-based designs are porous and not sufficient for protecting against proliferating threats.

We have often heard about “Zero Trust Networking” at trade shows and conferences. SP 800-207 does a good job of explaining that ZTA is not limited to networks. In fact, ZTA must transcend network-layer thinking in order to be successful. ZTA requires proper authentication and authorization for each session involving users, applications, networks (including clouds), and data. Other key components of ZTA are continuous risk-adaptive authentication and dynamic policy evaluation.

SP 800-207 references OASIS XACML 2.0 architecture, including Policy Administration Points (PAPs), Policy Decision Points (PDPs), and Policy Enforcement Points (PEPs). The document should have referenced the updated XACML 3.0, which contains the elements of Obligations and Advice that can be used in ZTA scenarios where risk-adaptive authentication and authorization may be required by policies. There are also rule and policy combining algorithm optimizations in v. 3 that fit better with the description of Trust Algorithms in the NIST SP (p. 17).

SP 800-207 defines conceptual components that go beyond the standard XACML PAP/PDP/PEP reference architecture. In my view, the breakdown of PDP into Policy Engine and Policy Administrator doesn’t add value and can create confusion. The XACML 3.0 reference architecture is still valid today, and is used in authorization and access control solutions even where explicit support for the XACML language is missing.

The illustration and definition of contributing components in Figure 2 (p. 9), namely CDM System, Industry Compliance, Activity Logs, SIEM System, etc. adhere to other US federal program definitions, but do not exactly match common usage. For example, Continuous Diagnostics and Mitigations (CDM) roughly translate to asset, vulnerability, and configuration management. Industry Compliance is not a set of functions localized to one product or platform. Activity logs are consumed by SIEM, SOAR, and forensics tools. Some extrapolation and normalization of terminology and illustration may make this section applicable outside the US government.

SP 800-207 claims that threat intelligence “is the only component that will most likely be under the control of a service rather than the enterprise” (p. 19). Such a view discounts the prevalence and use of Identity-as-a-Service (IDaaS) and other kinds of 3rd-party services, including discrete authentication services, and fraud risk services. At KuppingerCole, expect to see more usage and development of additional modular functional services that can enhance the ZTA authentication and authorization experiences for enterprises, covering all permutations of user-device-app-data interactions.

Section 4 of the new doc addresses use cases and deployment scenarios:

There are some variations to these use cases that could use additional detail, such as more about remote workforces and cloud-native enterprises. Section 4 is good starting point for planning how to migrate to ZTA.

Most discussions of ZTA tend to highlight the security advantages, of which there are several. Section 5 of SP 800-207 provides a list of possible threats specific to ZTA that industry needs to consider and begin mitigating against. Of special note here are DoS attacks on PDPs, the need for full enterprise monitoring (not just endpoint or network), and potential weaknesses in proprietary/non-standard APIs.

SP 800-207 also lists the use of non-person entities in ZTA administration as a possible threat. It is true that innovative IAM and IGA solutions increasingly employ non-person agents/processes to reduce the workload on human admins. For example, machine learning algorithms can be used to:

It is possible that ML detection models can be manipulated (or gamed) to produce both false positives and negatives, and these outcomes can then be exploited by malicious actors. Even though these types of attacks require sophistication, such attacks have migrated from the theoretical to the real world. Vendors and implementers must take knowledge of these scenarios into consideration when performing threat modeling.

NIST correctly surmises the need for standardization in ZTA, especially in the areas of APIs. Most identity and security products expose APIs for other applications to use, therefore securing these APIs must be a top priority. The proprietary nature of APIs is itself a source of security concern.

In summary, NIST SP 800-207 is a good primer on ZTA which includes some high-level, practical design advice. The authors clearly state that there is no single ZTA solution, and that the road to fully instrumented ZTA is a long one.

John Tolbert is lead analyst & managing director at KuppingerCole. Read more KuppingerCole blogs here.