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.
Zero Trust Architecture is more than networks – it is also about data and applications
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).
Does the new NIST standard meet all requirements?
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:
- Enterprises with satellite offices (includes teleworkers)
- Multi-cloud/cloud-to-cloud enterprises
- Contractors and non-employee access
- Cross domain collaboration
- Public and/or consumer facing organizations
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.
What are the threats when looking into a Zero Trust Architecture?
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:
- assign roles and permissions to users at on-boarding based on attributes and entitlements that their peers have
- perform User Behavioral Analysis (UBA) and provide confidence scores per session
- analyze device intelligence to determine if the sources of access requests are originating from authorized locations, properly patched, free of malware, etc.
- process the output of UBA, device intel, and other types of threat intelligence to generate risk scores per session.
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.
There is a need for standardization in Zero Trust Architectures
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.
KuppingerCole has research publications including Leadership Briefs and Advisory Notes on authentication, authorization, policy-based access controls, privileged access management, monitoring, AI/ML in cybersecurity, and more. We also offer Leadership Compass reports that compare and rank products in each of these constituent products/services. Moreover, our advisory team stands ready to assist clients in architecture and capabilities assessments, roadmap development, and product selection.
