NIST SP 800-207 Zero Trust Architecture
こんにちは、丸山満彦です。
NIST SP 800-207 Zero Trust Architectureが最終化しましたね。
● NIST - ITL
・2020.08.11 (publication) SP 800-207 Zero Trust Architecture
・[PDF] SP 800-207 (DOI)
Supplemental Material:
・ZTA project at NCCoE (web)
Abstract
Table of Contents
1 Introduction
1.1 History of Zero Trust Efforts Related to Federal Agencies
1.2 Structure of This Document
2 Zero Trust Basics
2.1 Tenets of Zero Trust
2.2 A Zero Trust View of a Network
3 Logical Components of Zero Trust Architecture
3.1 Variations of Zero Trust Architecture Approaches
3.1.1 ZTA Using Enhanced Identity Governance
3.1.2 ZTA Using Micro-Segmentation
3.1.3 ZTA Using Network Infrastructure and Software Defined Perimeters
3.2 Deployed Variations of the Abstract Architecture
3.2.1 Device Agent/Gateway-Based Deployment
3.2.2 Enclave-Based Deployment
3.2.3 Resource Portal-Based Deployment
3.2.4 Device Application Sandboxing
3.3 Trust Algorithm
3.3.1 Trust Algorithm Variations
3.4 Network/Environment Components
3.4.1 Network Requirements to Support ZTA
4 Deployment Scenarios/Use Cases
4.1 Enterprise with Satellite Facilities
4.2 Multi-cloud/Cloud-to-Cloud Enterprise
4.3 Enterprise with Contracted Services and/or Nonemployee Access
4.4 Collaboration Across Enterprise Boundaries
4.5 Enterprise with Public- or Customer-Facing Services
5 Threats Associated with Zero Trust Architecture
5.1 Subversion of ZTA Decision Process
5.2 Denial-of-Service or Network Disruption
5.3 Stolen Credentials/Insider Threat
5.4 Visibility on the Network
5.5 Storage of System and Network Information
5.6 Reliance on Proprietary Data Formats or Solutions
5.7 Use of Non-person Entities (NPE) in ZTA Administration
6 Zero Trust Architecture and Possible Interactions with Existing Federal Guidance
6.1 ZTA and NIST Risk Management Framework
6.2 Zero Trust and NIST Privacy Framework
6.3 ZTA and Federal Identity, Credential, and Access Management Architecture
6.4 ZTA and Trusted Internet Connections 3.0
6.5 ZTA and EINSTEIN (NCPS – National Cybersecurity Protection System)
6.6 ZTA and DHS Continuous Diagnostics and Mitigations (CDM) Program
6.7 ZTA, Cloud Smart, and the Federal Data Strategy
7 Migrating to a Zero Trust Architecture
7.1 Pure Zero Trust Architecture
7.2 Hybrid ZTA and Perimeter-Based Architecture
7.3 Steps to Introducing ZTA to a Perimeter-Based Architected Network
7.3.1 Identify Actors on the Enterprise
7.3.2 Identify Assets Owned by the Enterprise
7.3.3 Identify Key Processes and Evaluate Risks Associated with Executing Process
7.3.4 Formulating Policies for the ZTA Candidate
7.3.5 Identifying Candidate Solutions
7.3.6 Initial Deployment and Monitoring
7.3.7 Expanding the ZTA
References
List of Appendices
Appendix A— Acronyms
Appendix B— Identified Gaps in the Current State-of-the-Art in ZTA
B.1 Technology Survey
B.2 Gaps that Prevent an Immediate Move to ZTA
B.2.1 Lack of Common Terms for ZTA Design, Planning, and Procurement
B.2.2 Perception that ZTA Conflicts with Existing Federal Cybersecurity Policies
B.3 Systemic Gaps that Impact ZTA
B.3.3 Standardization of Interfaces Between Components
B.3.4 Emerging Standards that Address Overreliance on Proprietary APIs
B.4 Knowledge Gaps in ZTA and Future Areas of Research
B.4.5 Attacker Response to ZTA
B.4.6 User Experience in a ZTA Environment
B.4.7 Resilience of ZTA to Enterprise and Network Disruption
B.5 References
List of Figures
Figure 1: Zero Trust Access
Figure 2: Core Zero Trust Logical Components
Figure 3: Device Agent/Gateway Model
Figure 4: Enclave Gateway Model
Figure 5: Resource Portal Model
Figure 6: Application Sandboxes
Figure 7: Trust Algorithm Input
Figure 8: Enterprise with Remote Employees
Figure 9: Multi-cloud Use Case
Figure 10: Enterprise with Nonemployee Access
Figure 11: Cross-Enterprise Collaboration
Figure 12: ZTA Deployment Cycle
List of Tables
Table B-1: Summary of Identified Deployment Gaps
1 Introduction
A typical enterprise’s infrastructure has grown increasingly complex. A single enterprise may operate several internal networks, remote offices with their own local infrastructure, remote and/or mobile individuals, and cloud services. This complexity has outstripped legacy methods of perimeter-based network security as there is no single, easily identified perimeter for the enterprise. Perimeter-based network security has also been shown to be insufficient since once attackers breach the perimeter, further lateral movement is unhindered.
This complex enterprise has led to the development of a new model for cybersecurity known as “zero trust” (ZT). A ZT approach is primarily focused on data and service protection but can and should be expanded to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (end users, applications and other nonhuman entities that request information from resources). Throughout this document, “subject” will be used unless the section relates directly to a human end user in which “user” will be specifically used instead of the more generic “subject.” Zero trust security models assume that an attacker is present in the environment and that an enterprise-owned environment is no different—or no more trustworthy—than any nonenterprise-owned environment. In this new paradigm, an enterprise must assume no implicit trust and continually analyze and evaluate the risks to its assets and business functions and then enact protections to mitigate these risks. In zero trust, these protections usually involve minimizing access to resources (such as data and compute resources and applications/services) to only those subjects and assets identified as needing access as well as continually authenticating and authorizing the identity and security posture of each access request.
A zero trust architecture (ZTA) is an enterprise cybersecurity architecture that is based on zero trust principles and designed to prevent data breaches and limit internal lateral movement. This publication discusses ZTA, its logical components, possible deployment scenarios, and threats. It also presents a general road map for organizations wishing to migrate to a zero trust design approach and discusses relevant federal policies that may impact or influence a zero trust architecture.
ZT is not a single architecture but a set of guiding principles for workflow, system design and operations that can be used to improve the security posture of any classification or sensitivity level [FIPS199]. Transitioning to ZTA is a journey concerning how an organization evaluates risk in its mission and cannot simply be accomplished with a wholesale replacement of technology. That said, many organizations already have elements of a ZTA in their enterprise infrastructure today. Organizations should seek to incrementally implement zero trust principles, process changes, and technology solutions that protect their data assets and business functions by use case. Most enterprise infrastructures will operate in a hybrid zero trust/perimeter-based mode while continuing to invest in IT modernization initiatives and improve organization business processes.
Organizations need to implement comprehensive information security and resiliency practices for zero trust to be effective. When balanced with existing cybersecurity policies and guidance, identity and access management, continuous monitoring, and best practices, a ZTA can protect against common threats and improve an organization’s security posture by using a managed risk approach.
1.1 History of Zero Trust Efforts Related to Federal Agencies
The concept of zero trust has been present in cybersecurity since before the term “zero trust” was coined. The Defense Information Systems Agency (DISA) and the Department of Defense published their work on a more secure enterprise strategy dubbed “black core” [BCORE]. Black core involved moving from a perimeter-based security model to one that focused on the security of individual transactions. The work of the Jericho Forum in 2004 publicized the idea of deperimeterization—limiting implicit trust based on network location and the limitations of relying on single, static defenses over a large network segment [JERICHO]. The concepts of deperimeterization evolved and improved into the larger concept of zero trust, which was later coined by John Kindervag1 while at Forrester.2 Zero trust then became the term used to describe various cybersecurity solutions that moved security away from implied trust based on network location and instead focused on evaluating trust on a per-transaction basis. Both private industry and higher education have also undergone this evolution from perimeter-based security to a security strategy based on zero trust principles.
Federal agencies have been urged to move to security based on zero trust principles for more than a decade, building capabilities and policies such as the Federal Information Security Modernization Act (FISMA) followed by the Risk Management Framework (RMF); Federal Identity, Credential, and Access Management (FICAM); Trusted Internet Connections (TIC); and Continuous Diagnostics and Mitigation (CDM) programs. All of these programs aim to restrict data and resource access to authorized parties. When these programs were started, they were limited by the technical capabilities of information systems. Security policies were largely static and were enforced at large “choke points” that an enterprise could control to get the largest effect for the effort. As technology matures, it is becoming possible to continually analyze and evaluate access requests in a dynamic and granular fashion to a “need to access” basis to mitigate data exposure due to compromised accounts, attackers monitoring a network, and other threats.
1.2 Structure of This Document
The rest of the document is organized as follows:
- Section 2 defines ZT and ZTA and lists some assumptions when designing a ZTA for an enterprise. This section also includes a list of the tenets of ZT design.
- Section 3 documents the logical components, or building blocks, of ZT. It is possible that unique implementations compose ZTA components differently yet serve the same logical functionality.
- Section 4 lists some possible use cases where a ZTA may make enterprise environments more secure and less prone to successful exploitation. These include enterprises with remote employees, cloud services, and guest networks.
- Section 5 discusses threats to an enterprise using a ZTA. Many of these threats are similar to any architected networks but may require different mitigation techniques.
- Section 6 discusses how ZTA tenets fit into and/or complement existing guidance for federal agencies.
- Section 7 presents the starting point for transitioning an enterprise (such as a federal agency) to a ZTA. This includes a description of the general steps needed to plan and deploy applications and enterprise infrastructure that are guided by ZT tenets.
Comments