Zta Nist SP 1800 35e Preliminary Draft

NIST SPECIAL PUBLICATION 1800-35E
Implementing a Zero
Trust Architecture
Volume E:
Risk and Compliance Management
Alper Kerman Karen Scarfone

Murugiah Souppaya Scarfone Cybersecurity
National Institute of Standards and Technology Clifton, Virginia
Gaithersburg, Maryland
Susan Symington William Barker

The MITRE Corporation Dakota Consulting
McLean, Virginia Largo, Maryland
December 2022
PRELIMINARY DRAFT
This publication is available free of charge from

https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
PRELIMINARY DRAFT
1 DISCLAIMER
2 Certain commercial entities, equipment, products, or materials may be identified by name or company
3 logo or other insignia in order to acknowledge their participation in this collaboration or to describe an
4 experimental procedure or concept adequately. Such identification is not intended to imply special
5 status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it
6 intended to imply that the entities, equipment, products, or materials are necessarily the best available
7 for the purpose.
8 While NIST and the NCCoE address goals of improving management of cybersecurity and privacy risk
9 through outreach and application of standards and best practices, it is the stakeholder’s responsibility to
10 fully perform a risk assessment to include the current threat, vulnerabilities, likelihood of a compromise,
11 and the impact should the threat be realized before adopting cybersecurity measures such as this
12 recommendation.
13 National Institute of Standards and Technology Special Publication 1800-35E, Natl. Inst. Stand. Technol.
14 Spec. Publ. 1800-3E, 65 pages, December 2022, CODEN: NSPUE2
15 FEEDBACK
16 You can improve this guide by contributing feedback. As you review and adopt this solution for your
17 own organization, we ask you and your colleagues to share your experience and advice with us.
18 Comments on this publication may be submitted to: nccoe-zta-project@list.nist.gov.
19 Public comment period: December 21, 2022 through February 6, 2023
20 All comments are subject to release under the Freedom of Information Act.
21 National Cybersecurity Center of Excellence

22 National Institute of Standards and Technology
23 100 Bureau Drive
24 Mailstop 2002
25 Gaithersburg, MD 20899
26 Email: nccoe@nist.gov
NIST SP 1800-35E: Implementing a Zero Trust Architecture ii

PRELIMINARY DRAFT
27 NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

28 The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards
29 and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and
30 academic institutions work together to address businesses’ most pressing cybersecurity issues. This
31 public-private partnership enables the creation of practical cybersecurity solutions for specific
32 industries, as well as for broad, cross-sector technology challenges. Through consortia under
33 Cooperative Research and Development Agreements (CRADAs), including technology partners—from
34 Fortune 50 market leaders to smaller companies specializing in information technology security—the
35 NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity
36 solutions using commercially available technology. The NCCoE documents these example solutions in
37 the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework
38 and details the steps needed for another entity to re-create the example solution. The NCCoE was
39 established in 2012 by NIST in partnership with the State of Maryland and Montgomery County,
40 Maryland.
41 To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit
42 https://www.nist.gov.
43 NIST CYBERSECURITY PRACTICE GUIDES

44 NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity
45 challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the
46 adoption of standards-based approaches to cybersecurity. They show members of the information
47 security community how to implement example solutions that help them align with relevant standards
48 and best practices, and provide users with the materials lists, configuration files, and other information
49 they need to implement a similar approach.
50 The documents in this series describe example implementations of cybersecurity practices that
51 businesses and other organizations may voluntarily adopt. These documents do not describe regulations
52 or mandatory practices, nor do they carry statutory authority.
53 ABSTRACT
54 A zero trust architecture (ZTA) focuses on protecting data and resources. It enables secure authorized
55 access to enterprise resources that are distributed across on-premises and multiple cloud environments,
56 while enabling a hybrid workforce and partners to access resources from anywhere, at any time, from
57 any device in support of the organization’s mission. Each access request is evaluated by verifying the
58 context available at access time, including criteria such as the requester’s identity and role, the
59 requesting device’s health and credentials, the sensitivity of the resource, user location, and user
60 behavior consistency. If the enterprise’s defined access policy is met, a secure session is created to
61 protect all information transferred to and from the resource. A real-time and continuous policy-driven,
NIST SP 1800-35E: Implementing a Zero Trust Architecture iii

PRELIMINARY DRAFT
62 risk-based assessment is performed to establish and maintain the access. In this project, the NCCoE and
63 its collaborators use commercially available technology to build interoperable, open, standards-based
64 ZTA implementations that align to the concepts and principles in NIST Special Publication (SP) 800-207,
65 Zero Trust Architecture. This NIST Cybersecurity Practice Guide explains how commercially available
66 technology can be integrated and used to build various ZTAs.
67 KEYWORDS
68 cybersecurity framework subcategories; identity credential and access management (ICAM); risk;
69 security controls; zero trust; zero trust architecture (ZTA).
70 ACKNOWLEDGMENTS
71 We are grateful to the following individuals for reviewing the document.
Name Organization
Timothy Jones Forescout
Tim LeMaster Lookout
Parisa Grayeli MITRE
Kevin Stine NIST
Wade Ellery Radiant Logic
Deborah McGinn Radiant Logic
72 The Technology Partners/Collaborators who participated in this build submitted their capabilities in
73 response to a notice in the Federal Register. Respondents with relevant capabilities or product
74 components were invited to sign a Cooperative Research and Development Agreement (CRADA) with
75 NIST, allowing them to participate in a consortium to build this example solution. We worked with:
Technology Collaborators
Appgate IBM Ping Identity
AWS Ivanti Radiant Logic
Broadcom Software Lookout SailPoint
Cisco Mandiant Tenable
DigiCert Microsoft Trellix
F5 Okta VMware
NIST SP 1800-35E: Implementing a Zero Trust Architecture iv

PRELIMINARY DRAFT
Technology Collaborators
Forescout Palo Alto Networks Zimperium
Google Cloud PC Matic Zscaler
76 Collaborators listed above who have already contributed technologies may also provide additional
77 components for integration in future builds.
78 DOCUMENT CONVENTIONS
79 The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the
80 publication and from which no deviation is permitted. The terms “should” and “should not” indicate that
81 among several possibilities, one is recommended as particularly suitable without mentioning or
82 excluding others, or that a certain course of action is preferred but not necessarily required, or that (in
83 the negative form) a certain possibility or course of action is discouraged but not prohibited. The terms
84 “may” and “need not” indicate a course of action permissible within the limits of the publication. The
85 terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.
86 CALL FOR PATENT CLAIMS

87 This public review includes a call for information on essential patent claims (claims whose use would be
88 required for compliance with the guidance or requirements in this Information Technology Laboratory
89 (ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication
90 or by reference to another publication. This call also includes disclosure, where known, of the existence
91 of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant
92 unexpired U.S. or foreign patents.
93 ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in
94 written or electronic form, either:
95 a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not
96 currently intend holding any essential patent claim(s); or
97 b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring
98 to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft
99 publication either:
100 1. under reasonable terms and conditions that are demonstrably free of any unfair discrimination;
101 or
102 2. without compensation and under reasonable terms and conditions that are demonstrably free
103 of any unfair discrimination.
NIST SP 1800-35E: Implementing a Zero Trust Architecture v

PRELIMINARY DRAFT
104 Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its
105 behalf) will include in any documents transferring ownership of patents subject to the assurance,
106 provisions sufficient to ensure that the commitments in the assurance are binding on the transferee,
107 and that the transferee will similarly include appropriate provisions in the event of future transfers with
108 the goal of binding each successor-in-interest.
109 The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of
110 whether such provisions are included in the relevant transfer documents.
111 Such statements should be addressed to: nccoe-zta-project@list.nist.gov
NIST SP 1800-35E: Implementing a Zero Trust Architecture vi

PRELIMINARY DRAFT
112 Contents
113 1 Introduction ........................................................................................1
114 1.1 How to Use this Guide ................................................................................................... 1
115 2 Risk Management ................................................................................3
116 2.1 Threats ........................................................................................................................... 3
117 2.2 Vulnerabilities................................................................................................................ 5
118 2.3 Risk ................................................................................................................................ 5
119 3 ZTA Reference Architecture Security Mappings....................................5
120 3.1 Use Cases ....................................................................................................................... 6
121 3.2 Mapping Producers ....................................................................................................... 6
122 3.3 Mapping Approach ........................................................................................................ 6
123 3.3.1 Mapping Terminology .................................................................................................. 7
124 3.3.2 Mapping Process .......................................................................................................... 8
125 3.3.3 Mapping Subsection Organization ............................................................................... 9
126 3.4 Mapping Between ZTA Functions and the CSF Subcategories ...................................... 9
127 3.4.1 Mapping between E1B1 and the CSF Subcategories.................................................. 26
132 3.5 Mapping Between ZTA Functions and NIST SP 800-53 Controls................................. 26
133 3.5.1 Mapping between E1B1 and NIST SP 800-53 Controls .............................................. 45
138 3.6 Mapping Between ZTA Functions and EO 14028 Security Measures ......................... 45
139 3.6.1 Mapping between E1B1 and the EO 14028 Security Measures ................................. 55
NIST SP 1800-35E: Implementing a Zero Trust Architecture vii

PRELIMINARY DRAFT
144 Appendix A References .......................................................................... 57
145 List of Tables

146 Table 3-1 Mapping between ZTA Reference Design Logical Components and CSF Subcategories...........9
147 Table 3-2 Mapping between ZTA Reference Design Logical Components and NIST SP 800-53 Controls 27
148 Table 3-3 Mapping between ZTA Reference Design Logical Components and EO 14028 Security
149 Measures......................................................................................................................................... 46
NIST SP 1800-35E: Implementing a Zero Trust Architecture viii

PRELIMINARY DRAFT
150 1 Introduction
151 In this project, the NCCoE and its collaborators use commercially available technology to build
152 interoperable, open, standards-based zero trust architecture (ZTA) implementations that align to the
153 concepts and principles in NIST Special Publication (SP) 800-207, Zero Trust Architecture [1]. This NIST
154 Cybersecurity Practice Guide provides a risk assessment and maps ZTA security characteristics to
155 cybersecurity standards and best practices. The mappings include both general ZTA logical component
156 capabilities and specific ZTA example implementation capabilities.
157 1.1 How to Use this Guide

158 This NIST Cybersecurity Practice Guide will help users develop a plan for migrating to ZTA. It
159 demonstrates a standards-based reference design for implementing a ZTA and describes various
160 example implementations of this reference design. Each of these implementations, which are known as
161 builds, are standards-based and align to the concepts and principles in NIST SP 800-207, Zero Trust
162 Architecture. The reference design described in this practice guide is modular and can be deployed in
163 whole or in part, enabling organizations to incorporate ZTA into their legacy environments gradually, in a
164 process of continuous improvement that brings them closer and closer to achieving the ZTA goals that
165 they have prioritized based on risk, cost, and resources.
166 NIST is adopting an agile process to publish this content. Each volume is being made available as soon as
167 possible rather than delaying release until all volumes are completed. Work continues on implementing
168 the example solutions and developing other parts of the content. As a preliminary draft, we will publish
169 at least one additional draft for public comment before it is finalized.
170 When complete, this guide will contain five volumes:
171 ▪ NIST SP 1800-35A: Executive Summary – why we wrote this guide, the challenge we address,
172 why it could be important to your organization, and our approach to solving this challenge
173 ▪ NIST SP 1800-35B: Approach, Architecture, and Security Characteristics – what we built and why
174 ▪ NIST SP 1800-35C: How-To Guides – instructions for building the example implementations,
175 including all the security-relevant details that would allow you to replicate all or parts of this
176 project
177 ▪ NIST SP 1800-35D: Functional Demonstrations – use cases that have been defined to showcase
178 ZTA security capabilities and the results of demonstrating them with each of the example
179 implementations
180 ▪ NIST SP 1800-35E: Risk and Compliance Management – risk analysis and mapping of ZTA security
181 characteristics to cybersecurity standards and recommended practices (you are here)
182 Depending on your role in your organization, you might use this guide in different ways:
NIST SP 1800-35E: Implementing a Zero Trust Architecture 1

PRELIMINARY DRAFT
183 Business decision makers, including chief security and technology officers, will be interested in the
184 Executive Summary, NIST SP 1800-35A, which describes the following topics:
185 ▪ challenges that enterprises face in migrating to the use of ZTA

186 ▪ example solution built at the NCCoE
187 ▪ benefits of adopting the example solution
188 Technology or security program managers who are concerned with how to identify, understand, assess,
189 and mitigate risk will be interested in NIST SP 1800-35B, which describes what we did and why.
190 Also, Section 3 of this guide, NIST SP 1800-35E, will be of particular interest. Section 3, ZTA Reference
191 Architecture Security Mappings, maps logical components of the general ZTA reference design to
192 security characteristics listed in various cybersecurity standards and recommended practices
193 documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity
194 Framework), Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53),
195 and Security Measures for “EO-Critical Software” Use Under Executive Order (EO) 14028.
196 You might share the Executive Summary, NIST SP 1800-35A, with your leadership team members to help
197 them understand the importance of migrating toward standards-based ZTA implementations that align
198 to the concepts and principles in NIST SP 800-207, Zero Trust Architecture.
199 IT professionals who want to implement similar solutions will find the whole practice guide useful. You
200 can use the how-to portion of the guide, NIST SP 1800-35C, to replicate all or parts of the builds created
201 in our lab. The how-to portion of the guide provides specific product installation, configuration, and
202 integration instructions for implementing the example solution. We do not re-create the product
203 manufacturers’ documentation, which is generally widely available. Rather, we show how we
204 incorporated the products together in our environment to create an example solution. Also, you can use
205 Functional Demonstrations, NIST SP 1800-35D, which provides the use cases that have been defined to
206 showcase ZTA security capabilities and the results of demonstrating them with each of the example
207 implementations.
208 This guide assumes that IT professionals have experience implementing security products within the
209 enterprise. While we have used a suite of commercial products to address this challenge, this guide does
210 not endorse these particular products. Your organization can adopt this solution or one that adheres to
211 these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing
212 parts of a ZTA. Your organization’s security experts should identify the products that will best integrate
213 with your existing tools and IT system infrastructure. We hope that you will seek products that are
214 congruent with applicable standards and best practices.
215 A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. This is a
216 preliminary draft guide. As the project progresses, the preliminary draft will be updated, and additional
217 volumes will also be released for comment. We seek feedback on the publication’s contents and

PRELIMINARY DRAFT
218 welcome your input. Comments, suggestions, and success stories will improve subsequent versions of
219 this guide. Please contribute your thoughts to nccoe-zta-project@list.nist.gov.
220 2 Risk Management

221 This section discusses the threats and vulnerabilities addressed by the ZTA reference architecture and
222 the residual risk not addressed by ZTA.
223 2.1 Threats

224 Conventional network security has focused on perimeter defense. Historically, most corporate resources
225 have been located within and protected by the enterprise’s network perimeter, which tended to be
226 large and static. Subjects that are inside the network perimeter are often assumed to be implicitly
227 trusted and are given broad access to the corporate resources within the network perimeter. Attempts
228 to access resources from outside the network perimeter, i.e., from the internet, are often subject to
229 more scrutiny than those originating from within. However, a subject can be compromised regardless of
230 whether it is inside or outside of the network perimeter. Once a subject is compromised, malicious
231 actors—through impersonation and escalation—can gain access to the resources that the subject is
232 authorized to access and move laterally within the network perimeter to access adjacent corporate
233 resources.
234 By protecting each resource individually and employing extensive identity, authentication, and
235 authorization measures to verify a subject’s requirement to access each resource, zero trust can ensure
236 that authorized users, applications, and systems have access to only those resources that they
237 absolutely have a need to access in order to perform their duties, not to a broad set of resources that all
238 happen to be within the network perimeter. This way, if a malicious actor does manage to gain
239 unauthorized access to one resource, this access will not provide them with any advantage when trying
240 to move laterally to other nearby resources. To compromise those other resources, the attacker would
241 be required to figure out how to circumvent the mechanisms that are protecting those resources
242 individually because it is not possible to reach those resources from nearby compromised resources. In
243 this way, ZTA limits the insider threat because instead of having permission to access all resources
244 within the network perimeter, malicious insiders would only be permitted to access those resources
245 they require to perform their official roles.
246 In addition, once a subject is granted access to the resource, this access is often permitted to continue
247 for a substantial period of time without being reevaluated based on a defined policy. The access session
248 is often not monitored or subject to behavioral analysis, and the configuration and health of the devices
249 being used to access resources may be subject to initial, but not ongoing, scrutiny. So, if a subject does
250 manage to gain unauthorized access to a resource, the subject often has ample time to exfiltrate or
251 modify valuable information or further compromise the resource and/or use it as a point from which to
252 pivot and attack other corporate resources. ZTA limits these threats by performing continual verification

PRELIMINARY DRAFT
253 of a subject’s identity and authorization to access a resource. It may also perform behavioral analysis
254 and validation of each system’s health and configuration, and consider other factors such as day, time,
255 and location of subject and resource. Based on the organization’s defined policy, ZTA makes dynamic
256 ongoing assessments of the risk of each access request in real-time to ensure it poses an acceptable
257 level of risk according to corporate policy.
258 A number of trends in how corporations conduct business have also introduced additional security
259 threats. These trends include increased use of cloud computing and remote work.
260 The growth in cloud computing has meant that enterprises are now storing critical corporate resources
261 (e.g., databases, applications, servers) in the cloud (i.e., outside of the traditional network perimeter) as
262 well as on-premises. As a result, these resources cannot be protected by the network perimeter
263 strategy. A new protection paradigm is needed that focuses on protecting resources individually, no
264 matter where they are located, so that they are not at risk of being subjected to security policies that
265 are not under corporate control or not enforced consistently across all enterprise resources. Often the
266 clouds in which resources are hosted are multitenant, meaning that different corporate enterprises have
267 authorized access to their own portions of the cloud infrastructure, with each tenant reliant on the
268 cloud service provider to enforce this separation. If a malicious actor were to figure out how to subvert
269 cloud security and move from one tenant’s account to the next, corporate resources would be at risk.
270 Use of ZTA to protect each resource individually serves as further assurance that the resources will not
271 be accessible to cloud users from other enterprises, nor will they be accessible to users from within the
272 enterprise who do not have a need to access them.
273 The growth of the remote workforce, as well as collaboration with corporate partners and dependence
274 on contractors are other trends that are also challenging the conventional security paradigm. The
275 subjects requesting authorized access to corporate resources may not necessarily be within the network
276 perimeter. They may be employees working from home or from a coffee shop’s public Wi-Fi via the
277 internet, or a corporate partner, contractor, customer, or guest that requires access to some resources
278 but must be restricted from accessing other resources. By relying on strong identity, authentication, and
279 authorization services to determine precisely which resources a subject is authorized to access with
280 respect to their role in or relationship to the corporation, ZTA can restrict subjects to accessing only
281 those resources that they have a need to access and ensure that they are not permitted to access any
282 other resources.
283 The use of cloud applications or other external components that need access to some corporate
284 resources is another trend that is rendering the conventional security paradigm obsolete. Although an
285 external component may need to access some corporate resources in order to perform a required
286 function, if it is granted blanket access to all resources within the network perimeter, it becomes a
287 dangerous potential attack vector. By focusing on the identity, credentials, and authorization of each
288 subject making an access request, whether that subject be a human user or a non-human application,
289 component, or other system, ZTA can help ensure that all subjects are permitted to access only those

PRELIMINARY DRAFT
290 resources that they are required to access in order to fulfill their purpose. In a ZTA architecture, a
291 component that becomes compromised is of limited usefulness to the attacker. It can be used to access
292 only those resources that it is authorized to access rather than serving as a general attack vector.
293 2.2 Vulnerabilities

294 The vulnerability of resources to unauthorized access in an environment in which the network perimeter
295 defense paradigm is in effect is a consequence of the implicit trust that is placed in all subjects within
296 the perimeter. This situation is exacerbated by the fact that all resources within the perimeter tend to
297 be reachable from one another, but none are individually protected beyond the blanket protections that
298 the security perimeter provides from outside threats. Hence, the compromise of a single subject can
299 result in the compromise of many resources that are reachable within the perimeter, regardless of
300 whether the subject has a business need to access those resources. In addition, resource access sessions
301 are not evaluated on a continuing basis, making resources vulnerable to attack by malicious actors that
302 manage to compromise subjects or resources after an initial access request has been granted.
303 2.3 Risk

304 The reference architecture and the example ZTA solutions implemented are designed to ensure that
305 authorized users, applications, systems, and other non-human entities have access to only those
306 resources that they absolutely have a need to access in order to perform their duties, not to a broad set
307 of resources that all happen to be within the network perimeter. A network protected by a ZTA will be
308 vulnerable to exploitation if one or more of the core components of the ZTA itself (e.g., the policy engine
309 [PE], policy administrator [PA], or a policy enforcement point [PEP]) or the functional components that
310 provide crucial information to the core components (e.g., endpoint detection and response capabilities;
311 identity, credential, and access management capabilities; data security capabilities; security analytics
312 capabilities) become compromised. ZTA may help prevent malicious insiders and compromised subjects
313 from accessing resources that they are not authorized to access, and it may help prevent an attacker
314 from using a compromised resource as a landing place from which to pivot and attack additional
315 corporate resources. ZTA may also help find and identify already-compromised subjects, systems, and
316 resources through continuous, real-time monitoring and behavioral analysis. However, ZTA does not
317 help owners correct compromised systems or resources.
318 3 ZTA Reference Architecture Security Mappings

319 This section provides mappings between cybersecurity functions performed by the ZTA reference
320 design’s logical components (see NIST SP 1800-35B Section 4.1) and security characteristics enumerated
321 in a variety of relevant cybersecurity documents. These mappings are intended for any organization that
322 is interested in implementing ZTA or that has begun or completed a ZTA implementation. They provide
323 information on how ZTA cybersecurity functions from the NCCoE’s ZTA project are related to:

PRELIMINARY DRAFT
324 ▪ Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity Framework—
325 CSF) 1.1 [3] Subcategories,
326 ▪ NIST SP 800-53r5 (Security and Privacy Controls for Information Systems and Organizations) [4]
327 security controls, and
328 ▪ Executive Order (EO) 14028 [5] security measures defined in Security Measures for “EO-Critical
329 Software” Use Under Executive Order (EO) 14028 [6]
330 All of the elements in these mappings—the ZTA cybersecurity functions, CSF Subcategories, SP 800-53
331 controls, and EO 14028 security measures—are concepts involving ways to reduce cybersecurity risk and
332 meet compliance requirements involving sectors’ specific recommended practices. In future versions of
333 this document, the NCCoE may perform additional mappings between ZTA cybersecurity functions and
334 security characteristics enumerated in other cybersecurity standards, directives, recommended
335 practices, memoranda, etc.
336 3.1 Use Cases

337 This mapping was developed to support these two primary use cases. They are not intended to be
338 comprehensive.
339 1. Why should organizations implement ZTA? This use case identifies how implementing ZTA can
340 support an organization with achieving CSF Subcategories, SP 800-53 controls, and EO 14028
341 security measures. This helps communicate to an organization’s senior management that
342 expending resources to implement ZTA can also aid in fulfilling other security requirements.
343 2. How can organizations implement ZTA? This use case identifies how an organization’s existing
344 implementations of CSF Subcategories, SP 800-53 controls, and EO 14028 security measures can
345 help support a ZTA implementation. An organization wanting to implement ZTA might first
346 assess its current security capabilities so that it can plan how to add missing capabilities and
347 enhance existing capabilities in order to implement ZTA. Organizations can leverage their
348 existing security investments and prioritize future security technology deployment to address
349 the gaps.
350 3.2 Mapping Producers

351 The NCCoE ZTA project team performed the initial mapping with input and feedback from the
352 collaborators who have contributed technology to demonstrate ZTA capabilities.
353 3.3 Mapping Approach

354 In addition to performing these general mappings between the ZTA reference design’s cybersecurity
355 functions and various sets of security characteristics, the NCCoE intends to also develop mappings that
356 are specific to each ZTA example implementation. To develop these build-specific mappings, the NCCoE

PRELIMINARY DRAFT
357 intends to ask each collaborator for each build to indicate the mapping between the cybersecurity
358 functions its technology components provide in that build and the sets of security characteristics. These
359 build-specific mappings will appear in future drafts of this document. Using the logical components in
360 the ZTA reference design as the organizing principle for mapping cybersecurity functions to security
361 characteristics is intended to make it easier for collaborators to map their build-specific technology
362 contributions. Using this approach, the build-specific technology mappings will be instantiations of the
363 project’s general reference design mappings for each document.
364 3.3.1 Mapping Terminology

365 A mapping defines a relationship between two entities.
366 For this mapping, we have used the following relationship types to describe how the functions in our
367 ZTA reference design are related to the NIST reference documents. Note that the Supports relationship
368 applies to use case 1 only and the Is Supported By relationship applies to use case 2 only.
369 ▪ Supports: ZTA function X supports security control/subcategory/measure Y when X can be

370 applied alone or in combination with one or more other functions to achieve Y in whole or in
371 part.
372 ▪ Is Supported By: ZTA function X is supported by security control/subcategory/measure Y when Y
373 can be applied alone or in combination with one or more other security
374 controls/subcategories/measures to achieve X in whole or in part.
375 ▪ No Relationship: ZTA function X has no relationship to security control/subcategory/measure Y
376 when X and Y are not directly related.
377 Each relationship of type Supports (A supports B) or Is Supported By (B is supported by A) has one of the
378 following properties assigned to it:
379 ▪ Example of: The supporting concept A is an example of how the supported concept B can be
380 achieved in whole or in part. However, B could also be achieved without applying A.
381 ▪ Integral to: The supporting concept A is integral to the supported concept B. A must be applied
382 as part of achieving B.
383 ▪ Precedes: The supporting concept A precedes the supported concept B when A must be
384 achieved before applying B.
385 When determining whether a ZTA function’s support for a given CSF Subcategory, SP 800-53 control, or
386 EO 14028 security measure is integral to that support versus an example of that support, we do not
387 consider how that function may in general be used to support the subcategory, control, security
388 measure, or other item. Rather, we consider only how that function is intended to support that
389 subcategory, control, security measure, or other item within the context of our ZTA reference design.

PRELIMINARY DRAFT
390 Also, when determining whether a ZTA function is supported by a CSF subcategory with the relationship
391 property of precedes, we do not consider whether or not it is possible to apply the function without first
392 achieving the subcategory. Rather, we consider whether or not, according to our ZTA reference design,
393 the subcategory is to be achieved prior to applying that function.
394 3.3.2 Mapping Process

395 The process that the NCCoE used to create the mapping from the logical components of the ZTA
396 reference design to the security characteristics of a given document was as follows:
397 1. Create a table that lists each of the logical components of the ZTA reference design in column 1.
398 2. Describe each logical component’s cybersecurity function in column 2.
399 3. Map each cybersecurity function to each of the security characteristics in the document to
400 which the function is most strongly related, and list each of these security characteristics on
401 different sub-rows within column 3. Begin each security characteristic entry with an underlined
402 keyword that describes the mapping’s relationship type (e.g., Supports, Is Supported By, or No
403 Relationship). After the keyword describing the relationship type, put in parentheses the
404 underlined keyword(s) describing the relationship’s property (e.g., Example of, Integral to, or
405 Precedes).
406 4. In the fourth column, provide a brief explanation of why that relationship type and property
407 apply to the mapping.
408 5. After completing the mapping table entries as described above for all the logical components in
409 the reference design, examine the mapping in the other direction, i.e., starting with the security
410 characteristics listed in the document and considering whether they have a relationship to the
411 logical components’ cybersecurity functions in the reference design. In other words, step
412 through each of the security characteristics in the document and determine if there is some
413 logical component in the reference design that has a relationship to that security characteristic.
414 If so, add an entry for that security characteristic mapping to that logical component’s row in the
415 table. By examining the mapping in both directions in this manner, security characteristic
416 mappings are less likely to be overlooked or omitted.
417 The NCCoE applied this mapping process separately for each reference document. None of the
418 mappings are intended to be exhaustive; they all focus on the strongest relationships involving each
419 cybersecurity function in order to help organizations prioritize their work. Mapping every possible
420 relationship, no matter how tenuous, would create so many mappings that they would not have any
421 value in prioritization.

PRELIMINARY DRAFT
422 3.3.3 Mapping Subsection Organization

423 The mappings are organized in the remainder of this document as follows:
424 ▪ Section 3.4 – NIST CSF 1.1

425 ▪ Section 3.5 – NIST SP 800-53r5
426 ▪ Section 3.6 – EO 14028 Security Measures
427 In each section, the mapping from the logical components of the ZTA reference design is provided first,
428 followed by each of the build-specific mappings that has been completed so far. Builds are denoted
429 using the abbreviations defined in volume B, where E1B1, for example, refers to Build 1 of the example
430 implementation in Enterprise 1, E2B1 refers to Build 1 of the example implementation in Enterprise 2,
431 and E1B2 refers to Build 2 of the example implementation in Enterprise 1. The composition of each build
432 is described in an appendix of volume B.
433 3.4 Mapping Between ZTA Functions and the CSF Subcategories
434 In Table 3-1 we provide a mapping between the logical components of the ZTA reference design and the
435 NIST CSF subcategories. This table indicates how ZTA functions help support CSF subcategories and vice
436 versa.
437 Table 3-1 Mapping between ZTA Reference Design Logical Components and CSF Subcategories
ZTA Logical ZTA Component’s Function’s Relationships Relationship Explanation

Architecture Function to CSF Subcategories
Component (and Relationship
Properties)
Policy Engine Decides whether to Supports (integral to) The PE makes remote access decisions
(PE) grant, deny, or PR.AC-3: Remote access based on policy. In a ZTA, the PE must be
revoke access to a is managed applied to help manage remote access.
resource, based on Note that in ZTA, the same policy applies
enterprise policy, to all access requests, regardless of
information from whether they are remote or local.
functional Although ZTA does not differentiate
components, and a between local and remote access policy,
trust algorithm however, compliance frameworks might.
Policy Executes the PE’s Supports (integral to) The PA supports the enforcement of
Administrator policy decision by PR.AC-3: Remote access remote access decisions by conveying the
(PA) sending commands is managed access decision information from the PE to
to a PEP that the PEP, where the decision can be
establishes and shuts enforced. In a ZTA, the PA must be applied
down the to help manage remote access.
communication path
between subject and
resource

PRELIMINARY DRAFT

Properties)
Policy Guards the trust zone Supports (integral to) The PEP enforces remote access decisions.
Enforcement that hosts an PR.AC-3: Remote access In a ZTA, the PEP must be applied in order
Point (PEP) enterprise resource; is managed to help manage remote access.
enables, monitors, Supports (example of) The PEP can prevent unauthorized access
and terminates the PR.AC-5: Network to the portions of the enterprise that it
connection between integrity is protected guards. If it is used to protect a single
subject and resource; (e.g., network resource, then it does not necessarily
forwards requests to segregation, network provide network segregation or network
and receives segmentation) segmentation. However, it can be
commands from the deployed to protect and segregate
PA discrete network segments. Network
segmentation may also be provided by
other mechanisms besides a PEP.
Supports (integral to) The PEP prevents unauthorized transfer of
PR.DS-5: Protections information out of the portion of the
against data leaks are enterprise that it guards. In a ZTA, the PEP
implemented must be applied to help protect against
data leaks.
Supports (integral to) To support ZTA, the data plane and
PR.PT-4: control plane (networks) must be logically
Communications and separate. The PEP is the only component
control networks are that can send and receive messages from
protected both planes. It protects the planes from
each other and ensures that the control
plane is not directly accessible by
enterprise assets and resources.
Supports (example of) The PEP may be used to monitor
DE.CM-1: The network is connections between a subject and an
monitored to detect enterprise resource to detect prohibited
potential cybersecurity or suspicious activity. However, it must
events not necessarily be configured to do so.
Network monitoring may also be provided
by other mechanisms besides a PEP.
Supports (integral to) In a ZTA, the PEP is central to containing
RS.MI-1: Incidents are incidents. If a resource is compromised,
contained the PEPs protecting other resources
prevent attackers from moving laterally
from the compromised resource to the
resources protected by those other PEPs.
Access Define the conditions Is supported by In order to properly formulate policy
Policies that must be met to (precedes) ID.AM-3: regarding each subject’s access to
grant each subject Organizational resources, the expected, permissible data

PRELIMINARY DRAFT

Properties)
access to each communication and data flows between subjects and resources
resource flows are mapped must be well-understood.
Is supported by In order to properly formulate policy
(precedes) ID.AM-4: regarding each subject’s access to external
External information information systems, the systems to which
systems are catalogued access is to be permitted must be
catalogued.
Is supported by The access policies that are formulated for
(precedes) ID.AM-5: the organization must be based in part on
Resources (e.g., the classification, criticality, and business
hardware, devices, data, value of the resources to which access is
time, personnel, and being requested.
software) are prioritized
based on their
classification, criticality,
and business value
Supports (example of) The organization can define “confidence
ID.RA-5: Threats, level” or similar access policies that
vulnerabilities, calculate risk based on various factors
likelihoods, and impacts such as detected threats and
are used to determine vulnerabilities, and then determine the
risk ZTA’s response to a given access request
based on this calculated risk.
Supports (example of) The organization can define “confidence
ID.RA-6: Risk responses level” or similar access policies that
are identified and calculate risk based on various factors
prioritized such as detected threats and
vulnerabilities, user behavior, and user
location, and then base the ZTA’s
response to a given access request based
on this calculated risk. For example, if the
risk is determined to be at or below a
certain threshold, the request would be
permitted. If the risk is above a certain
threshold, the request would be denied.
Supports (integral to) Access policies are the mechanisms for
PR.AC-4: Access ensuring that permissions and
permissions and authorization to access any given resource
authorizations are conform with the principles of least
managed, incorporating privilege and separation of duties.
the principles of least

PRELIMINARY DRAFT

Properties)
privilege and separation
of duties
PR.AC-7: Users, devices, ensuring that subjects are authenticated
and other assets are commensurate with the risk of the
authenticated (e.g., transaction.
single-factor,
multifactor)
commensurate with the
risk of the transaction
(e.g., individuals’
security and privacy risks
and other organizational
risks)
Is supported by The organization Is expected to develop a
(precedes) PR.IP-12: A vulnerability management plan and to
vulnerability define and enforce its access policies
management plan is based in part on this plan.
developed and
implemented
Is supported by Before defining access policies, a baseline
(precedes) DE.AE-1: A of network operations and expected data
baseline of network flows for users and systems must be
operations and expected established so that the authorized data
data flows for users and flows are well-understood and policies
systems is established that enforce them can be defined.
and managed
Supports (example of) Once established, access policies manage
DE.AE-1: A baseline of and enforce the desired data flows.
network operations and
expected data flows for
users and systems is
established and
managed
Supports (example of) Policies that set incident alert thresholds
DE.AE-5: Incident alert can be defined such that when the
thresholds are threshold is reached, a specified action
established will be performed, e.g., alert generation.
Identity Creates and manages Is supported by Identity Management supports the
Management enterprise user and (precedes) ID.AM-6: creation, storage, and management of
device accounts, Cybersecurity roles and digital representations of cybersecurity
identity records, role responsibilities for the roles and their associated permissions and

PRELIMINARY DRAFT

Properties)
information, and entire workforce and responsibilities. It also supports the
access attributes that third-party stakeholders assignment of roles to user identities. To
form the basis of (e.g., suppliers, be able to create, store, and manage
access decisions customers, partners) are these representations of user roles and
within an established responsibilities, the roles and
organization to responsibilities themselves must have
ensure the correct already been established.
subjects have the Supports (integral to) Identity Management supports issuance,
appropriate access to PR.AC-1: Identities and storage, management, and revocation of
the correct resources credentials are issued, identities and their associated roles and
at the appropriate managed, verified, credentials. It also supports the
time. revoked, and audited for verification of credentials when
authorized devices, performing user and device
users, and processes authentication.
Supports (integral to) Identity Management is used to define
PR.AC-4: Access and manage digital representations of
permissions and roles and associated access authorizations
authorizations are that are based on the principle of least
managed, incorporating privilege and separation of duties, and it is
the principles of least used to assign users to roles that best
privilege and separation match their responsibilities, based on the
of duties principle of least privilege and separation
of duties, and to manage each user’s roles
as their responsibilities in the enterprise
change, or as they leave employment.
Supports (integral to) Identity Management stores and manages
PR.AC-6: Identities are the association of identities with
proofed and bound to credentials.
credentials and asserted
in interactions
Access & Manages access to Is supported by To determine whether an access request
Credential resources by (precedes) PR.AC-6: is authorized, the Access and Credential
Management performing user and Identities are proofed Management component authenticates
device and bound to the user or device that is requesting
authentication (e.g., credentials and asserted access by verifying the credentials that are
SSO and MFA) and in interactions bound to the user or device and asserted
using identity, role, as part of the access request. The user and
and access attributes device identities must be asserted for this
to determine which component to be able to authenticate
them.

PRELIMINARY DRAFT

Properties)
access requests are Supports (integral to) The key function of the Access and
authorized. PR-AC-7: Users, devices, Credential Management component is to
and other assets are perform user and device authentication.
authenticated (e.g.,
single-factor, multi-
factor) commensurate
with the risk of the
transaction (e.g.,
individuals’ security and
privacy risks and other
organizational risks)
Supports (example of) If a legitimate user’s credentials are stolen
RS.MI-1: Incidents are and an attacker uses them to gain
contained unauthorized access to a resource, the
Access and Credential Management
component will limit the attacker to
accessing only those resources that the
legitimate user’s role or attributes allow.
This is one example of how incidents can
be contained.
RS.MI-2: Incidents are and an attacker uses them to gain
mitigated unauthorized access to a resource, the
attacker will only be allowed to access
that resource in the way that the
legitimate user’s role allows (e.g., read-
only vs. read-write). This is one example of
how incidents can be mitigated.
Supports (integral to) The Access and Credential Management
DE.CM-7: Monitoring for component can perform ongoing,
unauthorized personnel, intermittent user authentication and
connections, devices, authorization, thereby monitoring for
and software is unauthorized users and devices.
performed
Federated Aggregates and Is supported by The Federated Identity component
Identity correlates all (precedes) enables enforcement of the cybersecurity
attributes relating to ID.AM-6: Cybersecurity roles and responsibilities that have been
an identity or object roles and responsibilities established and stored for many different
that is being for the entire workforce groups—the enterprise workforce and
authorized by a ZTA. and third-party third-party stakeholders (e.g., suppliers,
It enables users of stakeholders (e.g., customers, partners) to be managed and
one domain to enforced. These roles and responsibilities

PRELIMINARY DRAFT

Properties)
securely access data suppliers, customers, must already be established before they
or systems of partners) are established can be enforced.
another domain
seamlessly, and
without the need for
completely
redundant user
administration.
Federated identity
encompasses the
traditional ICAM
data, supports
identities that may
be part of a larger
federated ICAM
community, and may
include non-
enterprise
employees.
Identity Provides policy- Supports (integral to) A key function of the Identity Governance
Governance based, centralized, PR.AC-1: Identities and component is to support the auditing of
automated processes credentials are issued, identities and credentials.
to manage user managed, verified,
identity and access revoked, and audited for
control functions authorized devices,
(e.g., ensuring users, and processes
segregation of duties, Supports (integral to) The Identity Governance component
role management, PR.AC-4: Access manages access permissions and
logging, auditing, permissions and authorizations in a way that incorporates
access reviews, authorizations are the principles of least privilege and
analytics, and managed, incorporating separation of duties.
reporting) to ensure the principles of least
compliance with privilege and separation
requirements and of duties
regulations. Is supported by The Identity Governance component
(precedes) ID.GV-1: ensures that the organization’s
Organizational cybersecurity policy is enforced in such a
cybersecurity policy is way that it complies with regulatory, legal,
established and and other governance-related
communicated requirements. This policy must already be
established before it can be enforced by
the Identity Governance component.

PRELIMINARY DRAFT

Properties)
Supports (integral to) The Identity Governance component
ID.GV-2: Cybersecurity supports the coordination and alignment
roles and responsibilities of cybersecurity roles and responsibilities
are coordinated and with internal roles and external partners
aligned with internal to ensure that the organization operates
roles and external in accordance with regulatory, legal, and
partners other governance-related requirements.
Is supported by The processes that the Identity
(precedes) ID.GV-3: Governance component follows have
Legal and regulatory been defined to ensure that the
requirements regarding organization operates in conformance
cybersecurity, including with all legal and regulatory requirements.
privacy and civil liberties These requirements must be well
obligations, are understood in order to define the Identity
understood and Governance processes. As these
managed requirements change, they must be
managed on an ongoing basis, and they
may require changes to identity
governance processes.
Supports (integral to) The processes that the Identity
ID.GV-4: Governance Governance component follows are
and risk management defined and managed with the objective
processes address of addressing cybersecurity risks.
cybersecurity risks
PR.PT-1: Audit/log performs logging and audits all identity
records are determined, management activities in accordance with
documented, policy and regulations.
implemented, and
reviewed in accordance
with policy
Multi-Factor Authenticates user Supports (integral to) The MFA component enables users to be
Authenticatio identity by requiring PR.AC-7: Users, devices, authenticated using a second factor,
n (MFA) the user to provide and other assets are which is required for higher-risk access
not only something authenticated (e.g., requests.
they know (e.g., a single-factor,
password), but also multifactor)
something they have commensurate with the
(e.g., a token). risk of the transaction
(e.g., individuals’
security and privacy risks

PRELIMINARY DRAFT

Properties)
and other organizational
risks)
Unified Manages and secures Is supported by For a device to be enrolled into a
Endpoint enterprise desktop (precedes) ID.AM-1: UEM/MDM system, the device must be
Management computers, laptops, Physical devices and known to be part of the organization’s
(UEM)/Mobile and/or mobile systems within the inventory.
Device devices in organization are
Management accordance with inventoried
(MDM) enterprise policy to Supports (integral to) The UEM/MDM installs, manages,
protect applications ID.AM-2: Software configures, and updates applications on
and data; ensure platforms and UEM/MDM-managed devices, so it
device compliance; applications within the provides inventory information regarding
mitigate and organization are these applications.
remediate inventoried
vulnerabilities and Supports (integral to) The UEM/MDM may be able to identify
threats; monitor for ID.RA-1: Asset and remediate device vulnerabilities by
suspicious activity to vulnerabilities are updating software on managed devices,
prevent and detect identified and for example.
intrusions; prevent, documented
detect, and disable Supports (integral to) The UEM/MDM may monitor for
malware, viruses, ID.RA-3: Threats, both suspicious activity; detect and disable
and other malicious internal and external, malware, viruses, and other malicious
or unauthorized are identified and traffic; and repair infected files on
traffic; repair documented managed devices.
infected files when Supports (integral to) The UEM/MDM may prevent a remote
possible; provide PR.AC-3: Remote access device that it is managing from being able
alerts and is managed to access any resources until the device is
recommend brought into compliance.
remediation actions; Supports (example of) The UEM/MDM may encrypt data stored
and encrypt data. PR.DS-1: Data-at-rest is on the device, but data stored on the
Pushes enterprise protected device could also be encrypted via a
applications and different mechanism.
updates to devices, Supports (example of) The UEM/MDM may encrypt data sent
enables users to PR-DS-2: Data-in-transit from the device, but this data could also
download enterprise is protected be encrypted via a different mechanism.
applications that Supports (example of) The UEM/MDM may track user activity on
they are authorized PR.DS-5: Protections the device and monitor for unauthorized
to access, remotely against data leaks are traffic to help prevent, detect, and
deletes all implemented mitigate data leaks.
applications and data Supports (example of) The UEM/MDM may use integrity
from devices if PR.DS-6: Integrity checking to verify updates prior to
needed, tracks user checking mechanisms installing them. It may also use integrity

PRELIMINARY DRAFT

Properties)
activity on devices, are used to verify checking to verify compliance of device
and detects and software, firmware, and software and firmware.
addresses security information integrity
issues on the device. Supports (example of) The UEM/MDM may rely on device
PR.DS-8: Integrity attestation or similar mechanisms that use
checking mechanisms integrity checking to verify the hardware
are used to verify integrity of the device before trusting the
hardware integrity device.
Supports (integral to) The UEM/MDM ensures that devices are
PR.IP-1: A baseline compliant with organizational policy in
configuration of terms of having the expected baseline
information installation and configuration of software
technology/industrial and firmware. UEM/MDM enforces and
control systems is maintains these baselines at endpoints.
created and maintained
incorporating security
principles (e.g., concept
of least functionality)
Is supported by The baseline configuration on the
(precedes) PR.IP-1: A endpoints that the UEM/MDM enforces
baseline configuration of must have been developed based on
information security principles, such as the concept of
technology/industrial least functionality, in accordance with the
control systems is organization’s policies. UEM/MDM
created and maintained operation depends on the existence of
incorporating security such baselines.
principles (e.g., concept
of least functionality)
Supports (example of) The UEM/MDM can remotely delete
PR.IP-6: Data is applications and data from devices as
destroyed according to needed according to policy. Other
policy mechanisms are also capable of
destroying data as needed.
Is supported by The UEM/MDM can mitigate and
(precedes) PR.IP-12: A remediate vulnerabilities and threats that
vulnerability it detects in device software, firmware,
management plan is and configuration by enforcing the
developed and organization’s vulnerability management
implemented policies. These policies must exist before
the UEM/MDM can enforce them, and
they constitute at least one portion of the

PRELIMINARY DRAFT

Properties)
organization’s vulnerability management
plan.
Supports (example of) The UEM/MDM can restrict the use of
PR.PT-2: Removable removable media as required by policy.
media is protected and
its use restricted
according to policy
Supports (example of) The UEM/MDM can be used to configure
PR.PT-3: The principle of devices to provide only essential
least functionality is capabilities.
incorporated by
configuring systems to
provide only essential
capabilities
Supports (example of) The UEM/MDM can monitor user activity
DE.CM-3: Personnel for suspicious behavior.
activity is monitored to
detect potential
cybersecurity events
Supports (example of) The UEM/MDM prevents, detects, and
DE.CM-4: Malicious code disables numerous types of malicious
is detected code.
Supports (example of) The UEM/MDM may be able to detect
DE.CM-5: Unauthorized unauthorized mobile code.
mobile code is detected
Supports (integral to) The UEM/MDM monitors the device for
DE.CM-7: Monitoring for unauthorized software and connections.
unauthorized personnel,
connections, devices,
and software is
performed
Supports (integral to) The UEM/MDM performs many activities
RS.MI-1: Incidents are that help to contain incidents, such as
contained detecting and disabling malware and
other malicious or unauthorized activity;
repairing infected files when possible; and
providing alerts and recommending
remediation actions when suspicious or
malicious activity is detected on a device.
It also encrypts data stored on the device,
which limits the data’s usefulness to
someone who steals a locked device.

PRELIMINARY DRAFT

Properties)
Supports (integral to) The UEM/MDM performs many activities
RS.MI-2: Incidents are that help to mitigate incidents, such as
mitigated detecting and disabling malware and
other malicious or unauthorized activity;
repairing infected files when possible; and
providing alerts and recommending
remediation actions when suspicious or
malicious activity is detected on a device.
It also encrypts data stored on the device,
which limits the data’s usefulness to
someone who steals a locked device.
Endpoint Detects and stops Is supported by For a device to have EDR/EPP software
Detection and threats to endpoints (precedes) ID.AM-1: installed on it, the device must be known
Response through an Physical devices and to be part of the organization’s inventory.
(EDR)/ integrated suite of systems within the
Endpoint endpoint protection organization are
Protection technologies inventoried
Platform (EPP) including antivirus, Supports (integral to) The EDR/EPP can inventory software on
data encryption, ID.AM-2: Software the device.
intrusion prevention, platforms and
EDR, and data loss applications within the
prevention (DLP). organization are
May include inventoried
mechanisms that are Supports (integral to) The EDR/EPP scans the device to detect
designed to protect ID.RA-1: Asset missing patches or outdated software and
applications and vulnerabilities are report them. It can also install patches if
data; ensure device identified and instructed to do so later.
compliance with documented
policies regarding Supports (integral to) The EDR/EPP detects and disable
hardware, firmware, ID.RA-3: Threats, both malware, viruses, and other signature-
software, and internal and external, based threats.
configuration; are identified and
monitor endpoints documented
for vulnerabilities, Supports (integral to) The EDR/EPP may include a firewall that
suspicious activity, PR.AC-3: Remote access blocks unauthorized connections to and
intrusion, infection, is managed from the device.
and malware; block Supports (example of) The EDR/EPP may encrypt data stored on
unauthorized traffic; PR.DS-1: Data-at-rest is the device, but data stored on the device
disable malware and protected could also be encrypted via a different
repair infections; mechanism.

PRELIMINARY DRAFT

Properties)
manage and Supports (example of) The EDR/EPP may encrypt data sent from
administer software PR-DS-2: Data-in-transit the device, but this data could also be
and updates; is protected encrypted via a different mechanism.
monitor behavior Supports (example of) The EDR/EPP may include a firewall that
and critical data; and PR.DS-5: Protections blocks unauthorized traffic to and from
enable endpoints to against data leaks are the device.
be tracked, implemented
troubleshooted, and Supports (example of) The EDR/EPP may use integrity checking
wiped, if necessary. PR.DS-6: Integrity to verify updates prior to installing them.
checking mechanisms It may also use integrity checking to verify
are used to verify compliance of device software and
software, firmware, and firmware.
information integrity
Supports (integral to) The EDR/EPP ensures that devices are
and Is supported by compliant with organizational policy in
(precedes) PR.IP-1: A terms of having the expected baseline
baseline configuration of installation and configuration of software
information and firmware. This baseline that the
technology/industrial EDR/EPP enforces must have been
control systems is developed based on security principles,
created and maintained such as the concept of least functionality,
incorporating security in accordance with the organization’s
principles (e.g., concept policies. So EDR/EPP operation depends
of least functionality) on the existence of such baselines, but it
also enforces and maintains these
baselines.
Supports (example of) The EDR/EPP can remotely delete
PR.IP-6: Data is applications and data from devices as
destroyed according to needed according to policy. Other
policy mechanisms are also capable of
destroying data as needed.
Is supported by The EDR/EPP can mitigate and remediate
(precedes) PR.IP-12: A vulnerabilities and threats that it detects
vulnerability in device software, firmware, and
management plan is configuration by enforcing the
developed and organization’s vulnerability management
implemented policies. These policies must exist before
the EDR/EPP can enforce them, and they
constitute at least one portion of the
plan.

PRELIMINARY DRAFT

Properties)
Supports (example of) The EDR/EPP can restrict the use of
PR.PT-2: Removable removable media as required by policy.
media is protected and
its use restricted
according to policy
Supports (example of) The EDR/EPP can be used to configure
PR.PT-3: The principle of devices to provide only essential
least functionality is capabilities.
incorporated by
configuring systems to
provide only essential
capabilities
Supports (example of) The EDR/EPP detects and disable
DE.CM-4: Malicious code malware, viruses, and other signature-
is detected based threats.
Supports (example of) The EDR/EPP may be able to detect
DE.CM-5: Unauthorized unauthorized mobile code.
mobile code is detected
Supports (integral to) The EDR/EPP monitors the device for
DE.CM-7: Monitoring for unauthorized software and connections.
unauthorized personnel,
and software is
performed
Supports (example of) The EDR/EPP can monitor user activity for
DE.CM-3: Personnel suspicious behavior.
activity is monitored to
detect potential
cybersecurity events
Supports (integral to) The EDR/EPP performs many activities
RS.MI-1: Incidents are that help to contain incidents, such as
contained detecting and disabling malware, viruses,
and other malicious or unauthorized
traffic; repairing infected files when
possible; and providing alerts and
recommending remediation actions when
suspicious activity or malicious activity is
detected on a device. It also encrypts data
stored on the device, which limits the
data’s usefulness if it is exfiltrated.

PRELIMINARY DRAFT

Properties)
Supports (integral to) The EDR/EPP performs many activities
RS.MI-2: Incidents are that help to mitigate incidents, such as
mitigated detecting and disabling malware, viruses,
and other malicious or unauthorized
traffic; repairing infected files when
possible; and providing alerts and
recommending remediation actions when
suspicious activity or malicious activity is
Security Collects and Supports (example of) The SIEM collects security and event
Information consolidates security DE.AE-2: Detected information from many components. This
and Event information and events are analyzed to aggregated data may be analyzed to
Management security event data understand attack understand attack targets and methods.
(SIEM) from many sources; targets and methods
correlates and Supports (integral to) A key function of the SIEM is to collect and
analyzes the data to DE.AE-3: Event data are correlate security event data from
help detect collected and correlated multiple sources.
anomalies and from multiple sources
recognize potential and sensors
threats and Supports (example of) Security analysts may use SIEM data to
vulnerabilities; and DE.AE-4: Impact of help them determine the impact of
logs the data to events is determined events.
adhere to data Supports (example of) The SIEM can aggregate logs of security
compliance PR.PT-1: Audit/log information and event activity as required
requirements. records are determined, by policy.
documented,
implemented, and
reviewed in accordance
with policy
Supports (example of) SIEM logs can be examined as an indirect
DE.CM-1: The network is and non-real-time method of monitoring
monitored to detect network activity to detect anomalous
potential cybersecurity behavior and other indicators of potential
events cybersecurity events.
Supports (example of) The SIEM logs can provide data that helps
RS.AN-2: The impact of security analysts to understand the impact
the incident is of cybersecurity incidents.
understood

PRELIMINARY DRAFT

Properties)
Supports (example of) The SIEM logs can provide data that can
RS.AN-3: Forensics are help security analysts to perform forensic
performed analysis of cybersecurity incidents.
Vulnerability Scans and assesses Supports (integral to) A key function of the Vulnerability
Scanning and the enterprise DE.CM-8: Vulnerability Scanning and Assessment component is to
Assessment infrastructure and scans are performed perform vulnerability scans.
resources for security
risks; identifies
vulnerabilities and
misconfigurations;
and provides
remediation
guidance regarding
investigating and
prioritizing responses
to incidents.
Security Integrates the SIEM Supports (example of) A Security Integration Platform can
Integration and other security RS.RP-1: Response plan execute predefined incident response
Platform tools into a single is executed during or workflows.
pane of glass to after an incident
support generation Supports (example of) Security analysts can use a Security
of insights into RS.AN-2: The impact of Integration Platform to visualize security
threats and help the incident is events and their impacts, thereby
track, manage, and understood enabling incidents to be better
resolve cybersecurity understood.
incidents. Executes Supports (example of) Security analysts can use a Security
predefined incident RS.AN-3: Forensics are Integration Platform to help them perform
response workflows performed forensic analysis of cybersecurity
to automatically incidents.
analyze information
and orchestrate the
operations required
to respond.
Security Continuously Supports (integral to) Security Validation is used to test and
Validation monitor, measure, DE.DP-3: Detection verify the effectiveness of detection
and validate the processes are tested processes and other ZTA cybersecurity
effectiveness of the controls.
ZTA’s cybersecurity Supports (example of) The organization can use Security
controls DE.DP-5: Detection Validation to continuously monitor,
processes are measure, and validate the effectiveness of
continuously improved cybersecurity controls, thereby enabling

PRELIMINARY DRAFT

Properties)
the organization to continuously improve
the detection processes.
Network Discovers, classifies, Supports (integral to) A key function of Network Discovery is to
Discovery and assesses the risk ID.RA-3: Threats, both monitor the network to find, identify, and
posed by devices and internal and external, document unknown and/or unexpected
users on the are identified and devices and activity that may pose a
network. documented threat to the organization.
Supports (example of) Network Discovery can help identify
DE.CM-1: The network is unknown and/or unexpected devices and
monitored to detect activity that may be indicative of
potential cybersecurity suspicious events, making it an example of
events how the network can be monitored to
detect potential cybersecurity events.
Supports (integral to) A key function of the Network Discovery
DE.CM-7: Monitoring for component is to discover unauthorized
unauthorized personnel, devices and connections on the network.
and software is
performed
Virtual Private Enables authorized Supports (example of) Requiring remote users to access the
Network remote users to PR.AC-3: Remote access enterprise via VPN is one mechanism that
securely access the is managed can be used to manage remote access.
inside of the Supports (example of) VPNs are one method of encrypting data
enterprise. (Once PR.DS-2: Data-in-transit in transit.
inside, the ZTA is protected
manages the user’s Supports (example of) Traffic sent on the VPN can be monitored
access to resources.) DE.CM-1: The network is to detect prohibited or suspicious activity.
monitored to detect
potential cybersecurity
events
Certificate Provides automated Is supported by Servers and software must be identified
Management capabilities to issue, (precedes) ID.AM-2: and known to be within the organization’s
install, inspect, Software platforms and inventory in order for them to be issued
revoke, renew, and applications within the certificates.
otherwise manage organization are
TLS certificates. inventoried
Supports (integral to) Verification (i.e., authentication) of the
PR.AC-1: Identities and identity of servers depends on the
credentials are issued, issuance, use, and management of TLS
managed, verified, certificates.
revoked, and audited for

PRELIMINARY DRAFT

Properties)
authorized devices,
users, and processes
Supports (integral to) Proofing (i.e., authenticating) server
PR.AC-6: Identities are identities requires TLS certificates.
proofed and bound to
credentials and asserted
in interactions
Supports (integral to) The setup of encrypted TLS transport
PR.DS-2: Data-in-transit connections depends on TLS certificates.
is protected
Supports (integral to) TLS transport connections provide
PR.DS-6: Integrity integrity checking on their traffic, and the
checking mechanisms setup of TLS connections depends on TLS
are used to verify certificates. Any integrity mechanism that
software, firmware, and relies on public key cryptography is
information integrity supported by TLS certificates.
438 3.4.1 Mapping between E1B1 and the CSF Subcategories

439 This mapping will be provided in a future version of this document.




448 3.5 Mapping Between ZTA Functions and NIST SP 800-53 Controls
449 In Table 3-2 we provide a mapping between the logical components of the ZTA reference design and
450 NIST SP 800-53 security controls. This table indicates how ZTA functions help support NIST SP 800-53

PRELIMINARY DRAFT
451 controls. Because hundreds of NIST SP 800-53 controls can help support ZTA functions, we have omitted
452 use case 2 (see Section 3.1), identifying how existing SP 800-53 controls can help support a ZTA
453 implementation. Readers needing to determine how their SP 800-53 implementations apply to a ZTA
454 implementation can follow the Risk Management Framework.
455 Table 3-2 Mapping between ZTA Reference Design Logical Components and NIST SP 800-53 Controls
ZTA Project ZTA Project Function Function’s Relationships Relationship Explanation

Component with SP 800-53 Controls
(and Relationship
Properties)
Policy Engine Decides whether to Supports (integral to) The PE authorizes each type of remote
(PE) grant, deny, or AC-17: Remote Access access to the system prior to allowing
revoke access to a such connections.
resource, based on Supports (integral to) The PE authorizes the connection of
enterprise policy, AC-19: Access Control mobile devices to organizational systems.
information from for Mobile Devices
functional Supports (integral to) The PE authorizes or denies access to
components, and a AC-20: External Systems systems that are used by but are not part
trust algorithm of on-premises systems, and for which the
organization has no direct control over the
implementation of required controls or
the assessment of control effectiveness.
Supports (integral to) The key function of the PE is to make
AC-24: Access Control access control decisions based on policy.
Decisions
Supports (integral to) The PE permits or prohibits remote
SC-15: Collaborative activation of collaborative computing
Computing Devices and devices and applications.
Applications
Administrator policy decision by AC-3: Access access decisions by conveying the access
(PA) sending commands Enforcement decision information from the PE to the
to a PEP that PEP, where the decision can be enforced.
establishes and shuts Supports (integral to) The PA supports the enforcement of
down the AC-17: Remote Access remote access decisions by conveying the
communication path access decision information from the PE to
between subject and the PEP, where the decision can be
resource enforced.
Supports (integral to) The PA conveys mobile device access
AC-19: Access Control decision information from the PE to the
for Mobile Devices PEP, where the decision can be enforced.
Supports (integral to) The PA conveys external system access
AC-20: External Systems decision information from the PE to the
PEP, where the decision can be enforced.

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (integral to) The PA conveys collaborative computing
SC-15: Collaborative device activation decision information
Computing Devices and from the PE to the PEP, where the
Applications decision can be enforced.
Policy Guards the trust zone Supports (integral to) The PEP enforces authorized access to the
Enforcement that hosts an AC-2: Account system based on valid access
Point (PEP) enterprise resource; Management authorization or intended system usage.
enables, monitors, Supports (integral to) The PEP enforces access decisions.
and terminates the AC-3: Access
connection between Enforcement
subject and resource; Supports (integral to) The PEP enforces approved authorizations
forwards requests to AC-4: Information Flow for controlling the flow of information
and receives Enforcement within the system and between connected
commands from the systems. The data plane and control plane
PA (networks) are logically separate. The PEP
is the only component that can send and
receive messages from both planes. It can
protect the planes from each other and
ensure that the control plane is not
directly accessible by enterprise assets
and resources.
Supports (integral to) The PEP can terminate connections to
AC-12: Session enforce compliance with policies.
Termination
Supports (integral to) The PEP can enforce remote access
AC-17: Remote Access decisions.
Supports (integral to) The PEP can enforce wireless access
AC-18: Wireless Access decisions.
Supports (integral to) The PEP can enforce access decisions
AC-19: Access Control regarding connection to mobile devices.
for Mobile Devices
AC-20: External Systems regarding connection to external systems.
Supports (integral to) The PEP monitors connections between a
CA-7: Continuous subject and an enterprise resource to
Monitoring detect prohibited or suspicious activity.
Supports (integral to) IR- If a resource is compromised, incidents
4: Incident Handling are contained because attackers cannot
move laterally from the compromised
resource to any resources that are not
also in that part of the enterprise guarded
by the compromised resource’s PEP.

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (example of) The PEP can enforce access decisions to
SC-7: Boundary key internal managed interfaces within
Protection the system including publicly accessible
system components that are separated
from internal organizational networks. It
can prevent unauthorized access to the
portions of the enterprise that it guards. If
it is used to protect a single resource, then
it does not necessarily provide network
segregation or network segmentation.
However, it can be deployed to protect
and segregate discrete network segments.
SC-15: Collaborative regarding activation of collaborative
Computing Devices and computing devices.
Applications
Supports (integral to) The PEP is the only component that can
SC-23: Session send and receive messages from both the
Authenticity data and control planes. It can protect the
planes from each other and ensure that
the control plane is not directly accessible
by enterprise assets and resources.
Supports (integral to) The PEP can enforce approved
SC-32: System authorizations for controlling the flow of
Partitioning information within the system.
Supports (integral to) The PEP can enforce authorizations for
SC-41: Port and I/O access to I/O ports and devices.
Device Access
Supports (integral to) The PEP can enforce authorization and
SC-43: Usage control of usage restrictions for system
Restrictions components.
Supports (example of) The PEP monitors connections between a
SI-4: System Monitoring subject and an enterprise resource to
detect prohibited or suspicious activity.
Access Define the conditions Supports (integral to) Enforcement of approved authorizations
Policies that must be met to AC-3: Access for logical access to information and
grant each subject Enforcement system resources is accomplished in
access to each accordance with applicable access control
resource policies.
Supports (precedes) AC- Access policies are the basis for
4: Information Flow enforcement of approved authorizations
Enforcement for controlling the flow of information

PRELIMINARY DRAFT

(and Relationship
Properties)
within the system and between connected
systems.
AC-5: Separation of ensuring that permissions and
Duties authorization to access any given resource
conform with the principle of separation
of duties.
AC-6: Least Privilege ensuring that permissions and
authorization to access any given resource
conform with the principle of least
privilege.
Supports (example of) Access policies must identify any user
AC-14: Permitted actions that can be performed on the
Actions Without system without identification or
Identification or authentication consistent with
Authentication organizational mission and business
functions; and document and provide
supporting rationales for user actions not
requiring identification or authentication.
Supports (integral to) Access policies determine what
AC-20: Use of External connections to external systems by each
Systems subject are authorized.
Supports (precedes) CA- Access policies determine approval and
3: Information Exchange management of the exchange of
information between the system and
other systems.
Supports (precedes) CA- Access policies determine which system
9: Internal System connections are authorized.
Connections
Supports (example of) Access policies enforce identification and
IA-1: Policy and authentication policies and their
Procedures associated controls.
Supports (integral to) IA- Access policies are the mechanisms for
2: Identification and ensuring that subjects are authenticated
Authentication commensurate with the risk of the
(Organizational Users) transaction.
Supports (integral to) IA- Access policies derive from organizational
3: Device Identification policies and determine the requirements
and Authentication for identification and authentication of
organization-defined device types,

PRELIMINARY DRAFT

(and Relationship
Properties)
including devices that are not owned by
the organization.
Supports (integral to) IA- Access policies derive from organizational
4: Identifier policies and determine how authorization
Management is received from where/whom for
assigning individual, group, role, service,
or device identifiers; selecting the
identifier; assigning the identifier; and
preventing reuse of identifiers for a
defined time period.
Supports (integral to) IA- Access policies determine requirements
5: Authenticator for strength of authentication
Management mechanisms and for authenticator
management procedures.
Supports (integral to) IA- Access policies determine requirements to
8: Identification and uniquely identify and authenticate non-
Authentication (For Non- organizational users or processes acting
Organizational Users) on behalf of non-organizational users.
Supports (integral to) IA- Access policies determine requirements to
9: Service Identification uniquely identify and authenticate
and Authentication organization-defined system services and
applications before establishing
communications with devices, users, or
other services or applications.
Supports (precedes) SA- Access policies determine organizational
9: External System security and privacy requirements to be
Services met by external systems to permit
connection to their services.
Identity Creates and manages Supports (integral to) The Identity Management function
Management enterprise user and AC-2: Account includes account management such as
device accounts, Management definition of the types of accounts allowed
identity records, role and specifically prohibited for use within
information, and the system, authorized users of the
access attributes that system, group and role membership,
form the basis of access authorizations (i.e., privileges), and
access decisions assignment of organization-defined
within an attributes for each account.
organization to Supports (integral to) The Identity Management function
ensure the correct AC-3: Access enforces approved authorizations
subjects have the Enforcement associated with logical access to
appropriate access to information and system resources in

PRELIMINARY DRAFT

(and Relationship
Properties)
the correct resources accordance with applicable access control
at the appropriate policies.
time.
Supports (precedes) AC- The Identity Management function is a
4: Information Flow necessary component of access
Enforcement authorizations on which information flow
enforcement depends.
AC-5: Separation of and manage digital representations of
Duties roles and associated access authorizations
that are based on the principle of
separation of duties, and it is used to
assign users to roles that best match their
responsibilities, based on the principle of
separation of duties, and to manage each
user’s roles as their responsibilities in the
enterprise change, or as they leave
employment.
AC-6: Least Privilege and manage digital representations of
roles and associated access authorizations
that are based on the principle of least
privilege, and it is used to assign users to
roles that best match their
responsibilities, based on the principle of
least privilege, and to manage each user’s
roles as their responsibilities in the
enterprise change, or as they leave
employment.
Supports (integral to) The Identity Management function
AC-17: Remote Access, authorizes each type of remote access to
including enhancement the system prior to allowing such
#1 connections.
Supports (integral to) The Identity Management function is a
AC-24: Access Control mechanism for ensuring that organization-
Decisions defined access control decisions are
applied to access requests prior to access
enforcement.
Supports (integral to) IA- The Identity Management function is
2: Identification and necessary for unique identification and
Authentication authentication of organizational users.
(Organizational Users)

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (integral to) IA- The Identity Management function
5: Authentication permits verification, as part of the initial
Management authenticator distribution, of the identity
of the individual receiving the
authenticator.
Supports (integral to) IA- The Identity Management function is
8: Identification and necessary for unique identification and
Authentication (Non- authentication of non-organizational
organizational Users) users.
Supports (integral to) The Identity Management function is the
PE-2: Physical Access basis for authorization of credentials for
Authorizations facility access, including physical access to
security-critical devices.
Access & Manages access to Supports (integral to) The Access and Credential Management
Credential resources by AC-2: Account function includes account management
Management performing user and Management such as definition of the types of accounts
device allowed and specifically prohibited for use
authentication (e.g., within the system, authorized users of the
SSO and MFA) and system, group and role membership,
using identity, role, access authorizations (i.e., privileges), and
and access attributes assignment of organization-defined
to determine which attributes for each account by performing
access requests are user authentication.
authorized. Supports (integral to) The Access and Credential Management
AC-3: Access function enforces approved authorizations
Enforcement for logical access to information and
system resources in accordance with
applicable access control policies.
Supports (precedes) AC- The Access and Credential Management
4: Information Flow function is a necessary component of
Enforcement access authorizations on which
information flow enforcement depends.
Supports (integral to) Access and Credential Management is
AC-5: Separation of used to define and manage digital
Duties representations of roles and associated
access authorizations that are based on
the principle of separation of duties, and it
is used to assign users to roles that best
match their responsibilities, based on the
principle of separation of duties, and to
manage each user’s roles as their

PRELIMINARY DRAFT

(and Relationship
Properties)
responsibilities in the enterprise change,
or as they leave employment.
Supports (integral to) Access and Credential Management is
AC-6: Least Privilege used to define and manage digital
representations of roles and associated
access authorizations that are based on
the principle of least privilege, and it is
used to assign users to roles that best
match their responsibilities, based on the
principle of least privilege, and to manage
each user’s roles as their responsibilities in
the enterprise change, or as they leave
employment.
Supports (integral to) The Access and Credential Management
AC-24: Access Control function is a mechanism for ensuring that
Decisions organization-defined access control
decisions are applied to access requests
prior to access enforcement using
authentication.
Supports (integral to) IA- The Access and Credential Management
1: Policy and Procedures function is integral to implementation of
the organization’s identification and
authentication policies and procedures.
Supports (integral to) IA- Access and Credential Management is a
2: Identification and necessary element of uniquely identifying
Authentication and authenticating organizational users.
(Organizational Users) To determine whether an access is
authorized, the Access and Credential
Management component authenticates
the user or device that is requesting
access by verifying the credentials that are
bound to the user or device and asserted
as part of the access request. These
credentials must be asserted for this IDAM
component to be able to authenticate the
user request.
Supports (precedes) IA- The Access and Credential Management
3: Device Identification function is prerequisite to uniquely
and Authentication identifying and authenticating
organization-defined devices and/or types
of devices before establishing a local,
remote, or network connection.

PRELIMINARY DRAFT

(and Relationship
Properties)
5: Authentication function permits verification, as part of
Management the initial authenticator distribution, of
the identity of the individual receiving the
authenticator.
8: Identification and function is necessary for unique
Authentication (Non- identification and authentication of non-
Organizational Users) organizational users.
9: Service Identification function is necessary for authorization of
and Authentication user/system connections to services
employing identification and
authentication mechanisms.
IR-4: Incident Handling and an attacker uses them to gain
unauthorized access to a resource, the
Access and Credential Management
component will limit the attacker to
accessing only those resources that the
legitimate user’s role allows.
Federated Aggregates and Supports (example of) An extension of IA-5 (9) requires
Identity correlates all IA-5: Authentication acceptance and verification of federated
attributes relating to Management or PKI credentials.
an identity or object Supports (example of) Extensions of IA-8 (5 and 6) require
that is being IA-8: Identification and acceptance and verification of federated
authorized by a ZTA. Authentication (Non- or PKI credentials.
It enables users of Organizational Users)
one domain to
Supports (example of) An extension of IA-12 (6) calls for
securely access data IA-12: Identity Proofing accepting externally proofed identities, a
or systems of fundamental component of managing
another domain federated identities across agencies and
seamlessly, and organizations.
without the need for
completely
redundant user
administration.
Federated identity
encompasses the
traditional ICAM
data, supports
identities that may

PRELIMINARY DRAFT

(and Relationship
Properties)
be part of a larger
federated ICAM
community, and may
include non-
enterprise
employees.
Identity Provides policy- Supports (integral to) The Identity Governance function includes
Governance based, centralized, AC-2: Account account management such as authorized
automated processes Management users of the system, access authorizations
to manage user (i.e., privileges), and assignment of
identity and access organization-defined attributes.
control functions Supports (integral to) The Identity Governance function
(e.g., ensuring AC-3: Access enforces approved authorizations for
segregation of duties, Enforcement logical access to information and system
role management, resources by identified users in
logging, auditing, accordance with applicable access control
access reviews, policies.
analytics, and Supports (precedes) AC- The Identity Governance function is a
reporting) to ensure 4: Information Flow necessary component of the identity
compliance with Enforcement component of access authorizations on
requirements and which information flow enforcement
regulations. depends.
Supports (integral to) The Identity Governance component can
AC-5: Separation of manage access permissions and
Duties authorizations in a way that incorporates
the separation of duties principle.
Supports (integral to) The Identity Governance component can
AC-6: Least Privilege manage access permissions and
authorizations in a way that incorporates
the least privilege principle.
Supports (integral to) The Identity Governance function is a
AC-24: Access Control mechanism for ensuring that organization-
Decisions defined access control decisions are
enforcement and that organization-
defined access control decisions are
enforcement using authentication.
Supports (integral to) The Identity Governance component logs
AU-2: Event Logging all identity management activities in
accordance with policy and regulations.

PRELIMINARY DRAFT

(and Relationship
Properties)
AU-12: Audit Record audits all identity management activities
Generation in accordance with policy and regulations.
Unified Manages and secures Supports (integral to) UEM/MDM devices enforce access control
Endpoint enterprise desktop AC-1: Policy and policies and procedures and associated
Management computers, laptops, Procedures access controls.
(UEM)/Mobile and/or mobile Supports (integral to) The UEM/MDM can monitor the use of
Device devices in AC-2: Account accounts user activity for prohibited use.
Management accordance with Management
(MDM) enterprise policy to Supports (integral to) The UEM/MDM can be used to configure
protect applications AC-6: Least Privilege devices to provide only essential
and data; ensure capabilities.
device compliance; Supports (integral to) The UEM/MDM enforces usage
mitigate and AC-17: Remote Access restrictions, configuration/connection
remediate requirements, and implementation
vulnerabilities and guidance for each type of remote access
threats; monitor for allowed and authorizes each type of
suspicious activity to remote access to the system prior to
prevent and detect allowing such connections. May use
intrusions; prevent, encrypted VPNs to enhance confidentiality
detect, and disable and integrity for remote connections.
malware, viruses, Supports (integral to) The UEM/MDM enforces configuration
and other malicious AC-18: Access Control requirements, connection requirements,
or unauthorized for Wireless Access and implementation guidance for each
traffic; repair type of wireless access and authorizes
infected files when each type of wireless access to the system
possible; provide prior to allowing such connections. An AC-
alerts and 18 extension (1) requires protection of
recommend wireless access to the system using
remediation actions; authentication of users and devices and
and encrypt data. encryption.
Pushes enterprise Supports (integral to) The UDM/MDM enforces configuration
applications and AC-19: Access Control requirements, connection requirements,
updates to devices, for Mobile Devices and implementation guidance for
enables users to organization-controlled mobile devices, to
download enterprise include when such devices are outside of
applications that controlled areas and authorizes the
they are authorized connection of mobile devices to
to access, remotely organizational systems.
deletes all Supports (integral to) The UDM/MDM enforces organization-
applications and data AC-20: Use of External defined controls asserted to be
Systems implemented on external systems

PRELIMINARY DRAFT

(and Relationship
Properties)
from devices if consistent with the trust relationships
needed, tracks user established with other organizations
activity on devices, owning, operating, and/or maintaining
and detects and external systems, allowing only authorized
addresses security individuals to access the system from
issues on the device. external systems and processing, storing,
or transmitting organization-controlled
information using external systems.
Supports (integral to) The UEM/MDM enforces configuration of
CA-7: Least Functionality the system to provide only organization-
defined mission essential capabilities. The
UEM/MDM can monitor user activity.
Supports (integral to) The UEM/MDM ensures that the devices
CM-2: Baseline are compliant with organizational policy in
Configuration terms of having the expected baseline
installation and configuration of software
and firmware.
Supports (integral to) The UEM/MDM ensures that the devices
CM-4: Impact Analysis are compliant with organizational policy
regarding analysis of changes to the
system to determine potential security
and privacy impacts prior to change
implementation.
Supports (integral to) The UEM/MDM enforces physical and
CM-5: Access logical access restrictions associated with
Restrictions for Change changes to the system.
Supports (integral to) The UEM/MDM enforces configuration
CM-6: Configuration settings for components employed within
Settings the system that reflect the most
restrictive mode consistent with
operational requirements using
organization-defined common secure
configurations and implements the
configuration settings.
Supports (integral to) The UEM/MDM can monitor user activity
CM-10: Software Usage for violation of usage restrictions.
Restrictions
Supports (example of) The UEM/MDM can monitor user activity
CM-11: User Installed to enforce software installation policies.
Software

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (example of) The UEM/MDM may use integrity
CM-14: Signed checking to verify updates prior to
Components installing them. It may also use integrity
checking to verify compliance of device
software and firmware.
Supports (integral to) IR- The UEM/MDM performs many activities
4: Incident Handling that help to contain and mitigate
incidents, such as detecting and disabling
malware, viruses, and other malicious or
unauthorized traffic; repairing infected
files when possible; and providing alerts
and recommending remediation actions
when suspicious activity or malicious
activity is detected on a device. It also
encrypts data stored on the device, which
limits the data’s usefulness if it is
exfiltrated.
Supports (example of) The UEM/MDM can remotely delete
MP-6: Media applications and data from devices as
Sanitization needed according to policy (not complete
sanitization).
Supports (example of) The UEM/MDM can restrict the use of
MP-7: Media Use removable media as required by policy.
Supports (integral to) The UEM/MDM installs, manages,
PM-5: System Inventory configures, and updates applications on
UEM/MDM managed devices, so it
provides inventory information regarding
these applications.
Supports (example of) The UEM/MDM may be able to identify
RA-3: Risk Assessment device vulnerabilities by updating
software, for example. The UEM/MDM
may monitor for suspicious activity; detect
and disable malware, viruses, and other
malicious traffic; and repair infected files.
The UEM/MDM can mitigate and
remediate vulnerabilities and threats that
it detects in device software, firmware,
and configuration by enforcing the
policies.

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (integral to) The UEM/MDM can monitor device
RA-5: Vulnerability software, firmware, and configurations for
Monitoring and vulnerabilities and threats.
Scanning
Supports (integral to) The UEM/MDM may be able to detect
SA-18: Mobile Code unauthorized mobile code.
Supports (example of) The UEM/MDM can restrict access to
SC-3: Security Function security functions using access control
Isolation mechanisms and by implementing least
privilege capabilities.
Supports (example of) The UEM/MDM can provide cryptographic
SC-8: Transmission protection for transmitted information.
Confidentiality and
Integrity
Supports (integral to) The UEM/MDM may provide
SC-13: Cryptographic cryptographic protection to support a
Protection variety of security solutions.
Supports (example of) The UEM/MDM can provide cryptographic
SC-28: Protection of protection for data that is stored onsite.
Data at Rest
Supports (integral to) SI- The UEM/MDM mitigates and remediates
2: Flaw Remediation vulnerabilities that it detects in device
software, firmware, and configuration.
Supports (integral to) SI- The UEM/MDM prevents, detects, and
3: Malicious Code disables malware, viruses, and other
Protection malicious traffic. It also repairs infected
files when possible. When malicious code
is detected, it provides alerts and may
recommend remediation action.
Supports (integral to) SI- The UEM/MDM monitors the device for
4: System Monitoring unauthorized software and connections.
The UEM/MDM monitors the system to
detect attacks and indicators of potential
attacks in accordance with organization-
defined monitoring objectives and
unauthorized local, network, and remote
connections to identify unauthorized use
of the system.
Endpoint Detects and stops Supports (integral to) The EDR/EPP can monitor the use of
Detection and threats to endpoints AC-2: Account accounts.
Response Management

PRELIMINARY DRAFT

(and Relationship
Properties)
(EDR)/ through an Supports (integral to) The EDR/EPP may include a firewall that
Endpoint integrated suite of AC-4: Information Flow blocks unauthorized connections to and
Protection endpoint protection Enforcement from the device.
Platform (EPP) technologies Supports (integral to) The EDR/EPP may include a firewall that
including antivirus, AC-17: Remote Access blocks unauthorized connections to and
data encryption, from the device.
intrusion prevention, Supports (integral to) The EDR/EPP may include a firewall that
EDR, and data loss AC-19: Access Control blocks unauthorized connections to and
prevention (DLP). for Mobile Devices from the device.
May include Supports (integral to) The EDR/EPP may include a firewall that
mechanisms that are AC-20: Use of External blocks unauthorized connections to and
designed to protect Systems from the device.
applications and Supports (integral to) The EDR/EPP scans the device to detect
data; ensure device CA-7: Continuous missing patches or outdated software and
compliance with Monitoring report them.
policies regarding Supports (integral to) The EDR/EPP ensures that the devices are
hardware, firmware, CM-2: Baseline compliant with organizational policy in
software, and Configuration terms of having the expected baseline
configuration; installation and configuration of software.
monitor endpoints It is a prerequisite that the compliance
for vulnerabilities, policies incorporate appropriate security
suspicious activity, principles.
intrusion, infection, Supports (integral to) The EDR/EPP can be used to configure
and malware; block CM-7: Least devices to provide only essential
unauthorized traffic; Functionality capabilities.
disable malware and Supports (integral to) For a device to have EDR/EPP software
repair infections; CM-8: System installed on it, the device must be known
manage and Component Inventory to be part of the organization’s inventory.
administer software Supports (integral to) IR- The EDR/EPP performs many activities
and updates; 4: Incident Handling that help to contain incidents, such as
monitor behavior detecting and disabling malware, viruses,
and critical data; and and other malicious or unauthorized
enable endpoints to traffic; repairing infected files when
be tracked, possible; and providing alerts and
troubleshooted, and recommending remediation actions when
wiped, if necessary. suspicious activity or malicious activity is
MP-2: Media Access removable media as required by policy.

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (example of) The EDR/EPP can remotely delete
MP-6: Media applications and data from devices as
Sanitization needed according to policy (not full
sanitization).
MP-7: Media Use organization-defined types of system
media on organization-defined systems or
system.
Supports (example of) The EDR/EPP can inventory software on
PM-5: System Inventory the device.
Supports (integral to) The EDR/EPP supports Identification of
RA-3: Risk Assessment threats to and vulnerabilities in the system
by scanning the device to detect missing
patches or outdated software and
reporting them. The EDR/EPP also detects
malware, viruses, and other signature-
based threats.
Supports (integral to) The EDR/EPP may include a firewall that
SC-7: Boundary blocks unauthorized traffic to and from
Protection the device.
Supports (integral to) The EDR/EPP may encrypt data sent from
SC-8: Transmission the device and may include a firewall that
Confidentiality and blocks unauthorized traffic to and from
Integrity the device.
Supports (example of) The EDR/EPP can monitor user activity to
SC-10: Software Usage enforce usage restrictions.
Restrictions
Supports (example of) The EDR/EPP can monitor activity to
SC-11: User-Installed enforce software installation policies.
Software
Supports (integral to) The EDR/EPP may encrypt data sent from
SC-13: Cryptographic the device or stored on the device.
Protection
Supports (integral to) The EDR/EPP may include a firewall that
SC-15: Collaborative blocks unauthorized remote activation of
Computing Devices and collaborative computing devices and
Applications applications.
Supports (integral to) The EDR/EPP may be able to detect
SC-18: Mobile Code unauthorized mobile code.
Supports (integral to) The EDR/EPP may encrypt data stored on
SC-28: Protection of the device.
Information at Rest

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (example of) The EDR/EPP can mitigate and remediate
SI-2: Flaw Remediation vulnerabilities and threats that it detects
in device software, firmware, and
configuration by enforcing the
policies.
Supports (integral to) SI- The EDR/EPP detects and disable
3: Malicious Code malware, viruses, and other signature-
Protection based threats.
Supports (integral to) SI- The EDR/EPP monitors the device for
4: System Monitoring unauthorized software and connections.
Supports (example of) The EDR/EPP may use integrity checking
SI-7: Software, to verify updates prior to installing them.
Firmware, and It may also use integrity checking to verify
Information Integrity compliance of device software and
firmware.
Security Collects and Supports (integral to) The SIEM logs security information and
Information consolidates security AU-2: Event Logging event activity as required by policy.
and Event information and Supports (integral to) The SIEM collects security and event
Management security event data AU-6: Audit Record information from many components. This
(SIEM) from many sources; Review, Analysis, and data may be analyzed to understand
correlates and Reporting attack targets and methods. Security
analyzes the data to analysts rely at least in part on SIEM data
help detect to help them determine the impact of
anomalies and events.
recognize potential Supports (example of) The SIEM logs can provide helpful data
threats and AU-7: Audit Record that can help with forensic analysis of
vulnerabilities; and Reduction and Report cybersecurity incidents.
logs the data to Generation
adhere to data Supports (integral to) The SIEM collects security and event
compliance CA-7: Continuous information from many components.
requirements. Monitoring
Supports (integral to) IR- The SIEM collects security and event
4: Incident Handling information from many components. This
data may be analyzed to understand
attack targets and methods and the
impact of cybersecurity incidents.
Supports (integral to) IR- The SIEM collects security and event
5: Incident Monitoring information from many components to
support tracking and documentation of
events. The SIEM logs can be examined as
an indirect and non-real-time method of

PRELIMINARY DRAFT

(and Relationship
Properties)
monitoring network activity to detect
anomalous behavior and other indicators
of potential cybersecurity events.
Supports (integral to) Security analysts rely at least in part on
RA-3: Risk Assessment SIEM data to help them determine the
impact of events.
Supports (integral to) The SIEM acts as a vulnerability scanning
RA-5: Vulnerability and assessment tool.
Monitoring and
Scanning
Supports (integral to) The SIEM collects and correlates event
SC-7: Boundary information. The SIEM logs can be
Protection examined as an indirect and non-real-time
method of monitoring network activity to
detect anomalous behavior and other
indicators of potential cybersecurity
events.
Virtual Private Enables authorized Supports (integral to) Requiring remote users to access the
Network remote users to AC-17: Remote Access enterprise via VPN is one mechanism that
(VPN) securely access the helps manage remote access.
inside of the Supports (integral to) Limiting external users to access the
enterprise. (Once AC-20: Use of External enterprise via VPN is one mechanism that
inside, the ZTA Systems helps manage remote access.
manages the user’s Supports (example of) Traffic sent on the VPN can be monitored
access to resources.) CA-7: Continuous to detect prohibited or suspicious activity.
Monitoring
Supports (example of) VPNs encrypt data in transit.
SC-8: Transmission
Confidentiality and
Integrity
Supports (integral to) VPNs encrypt data in transit.
SC-13: Cryptographic
Protection
Certificate Provides automated Supports (integral to) Proofing server identities requires TLS
Management capabilities to issue, AC-16: Security and certificates.
install, inspect, Privacy Attributes
revoke, renew, and Supports (integral to) IA- Verification of the identity of servers
otherwise manage 2: Identification and depends on the issuance, use, and
TLS certificates. Authentication management of TLS certificates.
(Organizational Users)

PRELIMINARY DRAFT

(and Relationship
Properties)
Supports (integral to) The setup of encrypted TLS transport
SC-8: Transmission connections depends on TLS certificates.
Confidentiality and
Integrity
Supports (integral to) TLS transport connections provide
SC-16: Transmission of integrity checking on their traffic, and the
Security and Privacy setup of TLS connections depends on TLS
Attributes certificates.
Supports (integral to) SI- TLS transport connections provide
7: Software, Firmware, integrity checking on their traffic, and the
and Information setup of TLS connections depends on TLS
Integrity certificates.
456 3.5.1 Mapping between E1B1 and NIST SP 800-53 Controls





466 3.6 Mapping Between ZTA Functions and EO 14028 Security Measures
467 In Table 3-3 we provide a mapping between the logical components of the ZTA reference design and the
468 EO 14028 security measures. This table indicates how ZTA functions help support EO 14028 security
469 measures for EO-critical software and EO-critical software platforms, and vice versa.

PRELIMINARY DRAFT
470 Table 3-3 Mapping between ZTA Reference Design Logical Components and EO 14028 Security
471 Measures

Architecture Function to EO 14028 Security
Component Measures (and
Relationship Properties)
Policy Engine Decides whether to Supports (integral to) The PE makes access decisions based on
(PE) grant, deny, or SM 1.4: Employ policy.
revoke access to a boundary protection
resource, based on techniques as
enterprise policy, appropriate to minimize
information from direct access to EO-
functional critical software, EO-
components, and a critical software
trust algorithm platforms, and
associated data.
Supports (integral to) The PE makes access decisions based on
SM 2.2: Use fine-grained policy.
access control for data
and resources used by
EO-critical software and
EO-critical software
platforms to enforce the
principle of least
privilege to the extent
possible.
Administrator policy decision by SM 1.4: Employ access decisions by conveying the access
(PA) sending commands boundary protection decision information from the PE to the
to a PEP that techniques as PEP, where the decision can be enforced.
establishes and shuts appropriate to minimize
down the direct access to EO-
communication path critical software, EO-
between subject and critical software
resource platforms, and
associated data.
Supports (integral to) The PA supports the enforcement of
SM 2.2: Use fine-grained access decisions by conveying the access
access control for data decision information from the PE to the
and resources used by PEP, where the decision can be enforced.
principle of least

PRELIMINARY DRAFT

possible.
Policy Guards the trust zone Supports (integral to) The PEP prevents unauthorized access to
Enforcement that hosts an SM 1.4: Employ the portions of the enterprise that it
Point (PEP) enterprise resource; boundary protection guards.
enables, monitors, techniques as
and terminates the appropriate to minimize
connection between direct access to EO-
subject and resource; critical software, EO-
forwards requests to critical software
and receives platforms, and
commands from the associated data.
PA Supports (integral to) The PEP enforces access decisions. The
SM 2.2: Use fine-grained PEP can be placed in front of a single or
access control for data multiple resources, making access control
and resources used by as fine-grained as desired.
principle of least
possible.
Supports (example of) The PEP can monitor connections
SM 4.4: Employ network between a subject and an EO-critical
security protection to software platform to detect prohibited or
monitor the network suspicious activity.
traffic to and from EO-
critical software
platforms to protect the
platforms and their
software using
networks.
Access Define the conditions Is supported by In order to properly formulate policy
Policies that must be met to (precedes) SM 2.1: regarding each subject’s access to data,
grant each subject Establish and maintain a the data for EO-critical software and EO-
access to each data inventory for EO- critical platforms must be catalogued.
resource critical software and EO-
critical platforms.
SM 2.2: Use fine-grained ensuring that permissions and
access control for data authorization to access any given data and
and resources used by

PRELIMINARY DRAFT

EO-critical software and resource conform with the principle of
EO-critical software least privilege.
principle of least
possible.
Is supported by In order to properly formulate policy
(precedes) SM 3.1: regarding each subject’s access to
Establish and maintain a resources, the software resources
software inventory for deployed to each platform running EO-
all platforms running EO- critical software must be catalogued.
critical software and all
software (both EO-
critical and non-EO-
critical) deployed to
each platform.
Identity Creates and manages Supports (integral to) Identity Management is used to create
Management enterprise user and SM 1.1: Use multi-factor and manage the identities that are
device accounts, authentication that is verified using multi-factor authentication.
identity records, role verifier impersonation-
information, and resistant for all users
access attributes that and administrators of
form the basis of EO-critical software and
access decisions EO-critical software
within an platforms.
organization to Supports (integral to) Identity Management is used to define
ensure the correct SM 2.2: Use fine-grained and manage digital representations of
subjects have the access control for data roles and associated access authorizations
appropriate access to and resources used by that are based on the principle of least
the correct resources EO-critical software and privilege, and to manage each user’s roles
at the appropriate EO-critical software as their responsibilities in the enterprise
time. platforms to enforce the change, or as they leave employment.
principle of least
possible.
Access & Manages access to Supports (integral to) Access & Credential Management is used
Credential resources by SM 1.1: Use multi-factor to perform multi-factor authentication.
Management performing user and authentication that is
device verifier impersonation-
authentication (e.g., resistant for all users
SSO and MFA) and and administrators of
using identity, role, EO-critical software and

PRELIMINARY DRAFT

and access attributes EO-critical software
to determine which platforms.
access requests are
authorized.
Supports (integral to) Performing user and device authentication

SM 2.4: Protect data in is necessary for mutual authentication.
transit by using mutual
authentication
whenever feasible and
by encrypting sensitive
data communications
for EO-critical software
and EO-critical software
platforms consistent
with NIST’s
cryptographic standards.
Federated Aggregates and Supports (example of) Federated identities can be verified using
Identity correlates all SM 1.1: Use multi-factor multi-factor authentication.
attributes relating to authentication that is
an identity or object verifier impersonation-
that is being resistant for all users
authorized by a ZTA. and administrators of
It enables users of EO-critical software and
one domain to EO-critical software
securely access data platforms.
or systems of Supports (example of) Federated identities can be used with
another domain SM 2.2: Use fine-grained digital representations of roles and
seamlessly, and access control for data associated access authorizations.
without the need for and resources used by
completely EO-critical software and
redundant user EO-critical software
administration. platforms to enforce the
Federated identity principle of least
encompasses the privilege to the extent
traditional ICAM possible.
data, supports
identities that may
be part of a larger
federated ICAM
community, and may

PRELIMINARY DRAFT

include non-
enterprise
employees.
Identity Provides policy- Supports (integral to) The Identity Governance component
Governance based, centralized, SM 1.1: Use multi-factor manages user identity functions.
automated processes authentication that is
to manage user verifier impersonation-
identity and access resistant for all users
control functions and administrators of
(e.g., ensuring EO-critical software and
segregation of duties, EO-critical software
role management, platforms.
logging, auditing, Supports (integral to) The Identity Governance component
access reviews, SM 2.2: Use fine-grained manages access control functions.
analytics, and access control for data
reporting) to ensure and resources used by
compliance with EO-critical software and
requirements and EO-critical software
regulations. platforms to enforce the
principle of least
possible.
SM 4.1: Configure performs logging and audits all identity
logging to record the management activities in accordance with
necessary information policy and regulations.
about security events
involving EO-critical
software platforms and
all software running on
those platforms.
MFA Authenticates user Supports (integral to) The MFA component enables users to be
identity by requiring SM 1.1: Use multi-factor authenticated using a second factor.
the user to provide authentication that is
not only something verifier impersonation-
they know (e.g., a resistant for all users
password), but also and administrators of
something they have EO-critical software and
(e.g., a token). EO-critical software
platforms.
Unified Supports (example of) The UEM/MDM may encrypt data stored
Endpoint SM 2.3: Protect data at on the device, but data stored on the

PRELIMINARY DRAFT

Management Manages and secures rest by encrypting the device could also be encrypted via a
(UEM)/Mobile enterprise desktop sensitive data used by different mechanism.
Device computers, laptops, EO-critical software and
Management and/or mobile EO-critical software
(MDM) devices in platforms consistent
accordance with with NIST’s
enterprise policy to cryptographic standards.
protect applications Supports (integral to) The UEM/MDM installs, manages,
and data; ensure SM 3.1: Establish and configures, and updates software on
device compliance; maintain a software UEM/MDM-managed devices, so it
mitigate and inventory for all provides inventory information regarding
remediate platforms running EO- this software.
vulnerabilities and critical software and all
threats; monitor for software (both EO-
suspicious activity to critical and non-EO-
prevent and detect critical) deployed to
intrusions; prevent, each platform.
detect, and disable Supports (integral to) The UEM/MDM installs, manages,
malware, viruses, SM 3.2: Use patch configures, and updates software on
and other malicious management practices UEM/MDM-managed devices.
or unauthorized to maintain EO-critical
traffic; repair software platforms and
infected files when all software deployed to
possible; provide those platforms.
alerts and Supports (integral to) The UEM/MDM component performs
recommend SM 4.1: Configure security event logging on UEM/MDM-
remediation actions; logging to record the managed devices.
and encrypt data. necessary information
Pushes enterprise about security events
applications and involving EO-critical
updates to devices, software platforms and
enables users to all software running on
download enterprise those platforms.
applications that Supports (integral to) The UEM/MDM component provides
they are authorized SM 4.3: Employ several forms of endpoint security
to access, remotely endpoint security protection on UEM/MDM-managed
deletes all protection on EO-critical devices.
applications and data software platforms to
from devices if protect the platforms
needed, tracks user and all software running
activity on devices, on them.
and detects and

PRELIMINARY DRAFT

addresses security
issues on the device.
Endpoint Detects and stops Supports (example of) The EDR/EPP may encrypt data stored on
Detection and threats to endpoints SM 2.3: Protect data at the device, but data stored on the device
Response through an rest by encrypting the could also be encrypted via a different
(EDR)/ integrated suite of sensitive data used by mechanism.
Endpoint endpoint protection EO-critical software and
Protection technologies EO-critical software
Platform (EPP) including antivirus, platforms consistent
data encryption, with NIST’s
intrusion prevention, cryptographic standards.
EDR, and data loss Supports (integral to) The EDR/EPP inventories software on the
prevention (DLP). SM 3.1: Establish and device.
May include maintain a software
mechanisms that are inventory for all
designed to protect platforms running EO-
applications and critical software and all
data; ensure device software (both EO-
compliance with critical and non-EO-
policies regarding critical) deployed to
hardware, firmware, each platform.
software, and Supports (integral to) The EDR/EPP installs, manages,
configuration; SM 3.2: Use patch configures, and updates software on
monitor endpoints management practices EDR/EPP-managed devices.
for vulnerabilities, to maintain EO-critical
suspicious activity, software platforms and
intrusion, infection, all software deployed to
and malware; block those platforms.
unauthorized traffic; Supports (integral to) The EDR/EPP ensures that devices are
disable malware and SM 3.3: Use compliant with organizational policy in
repair infections; configuration terms of having the expected software
manage and management practices configurations.
administer software to maintain EO-critical
and updates; software platforms and
monitor behavior all software deployed to
those platforms.

PRELIMINARY DRAFT

and critical data; and Supports (integral to) The EDR/EPP provides several forms of
enable endpoints to SM 4.3: Employ endpoint security protection on EDR/EPP-
be tracked, endpoint security managed devices.
troubleshooted, and protection on EO-critical
wiped, if necessary. software platforms to
protect the platforms
and all software running
on them.
Supports (example of) The EDR/EPP can monitor the device for
SM 4.4: Employ network unauthorized network connections. Other
security protection to network monitoring technologies can be
monitor the network used instead of EDR/EPP to do this.
traffic to and from EO-
critical software
platforms and their
software using
networks.
Security Collects and Is supported by The SIEM aggregates logs of security
Information consolidates security (precedes) SM 4.1: information and security event activity
and Event information and Configure logging to generated by EO-critical software
Management security event data record the necessary platforms.
(SIEM) from many sources; information about
correlates and security events involving
analyzes the data to EO-critical software
help detect platforms and all
anomalies and software running on
recognize potential those platforms.
threats and Supports (example of) The SIEM can collect, analyze, and
vulnerabilities; and SM 4.2: Continuously correlate security information and security
logs the data to monitor the security of event data from many platforms.
adhere to data EO-critical software
compliance platforms and all
requirements. software running on
those platforms.
Vulnerability Scans and assesses Supports (integral to) A key function of the Vulnerability
Scanning and the enterprise SM 3.2: Use patch Scanning and Assessment component is to
Assessment infrastructure and management practices perform vulnerability scans for missing
resources for security to maintain EO-critical patches.
risks; identifies software platforms and
vulnerabilities and all software deployed to
those platforms.

PRELIMINARY DRAFT

misconfigurations; Supports (integral to) A key function of the Vulnerability
and provides SM 3.3: Use Scanning and Assessment component is to
remediation configuration perform vulnerability scans for
guidance regarding management practices misconfigurations.
investigating and to maintain EO-critical
prioritizing responses software platforms and
to incidents. all software deployed to
those platforms.
Security Integrates the SIEM Supports (example of) The Security Integration Platform
Integration and other security SM 4.2: Continuously component can support monitoring of
Platform tools into a single monitor the security of security data from many platforms.
pane of glass to EO-critical software
support generation platforms and all
of insights into software running on
threats and help those platforms.
track, manage, and
resolve cybersecurity
incidents. Executes
predefined incident
response workflows
to automatically
analyze information
and orchestrate the
operations required
to respond.
Security Continuously Supports (integral to) The ZTA’s cybersecurity controls are a
Validation monitor, measure, SM 4.2: Continuously subset of the EO-critical software
and validate the monitor the security of platforms’ controls, so continuous
effectiveness of the EO-critical software monitoring of the ZTA’s cybersecurity
ZTA’s cybersecurity platforms and all controls achieves a part of continuous
controls software running on monitoring for EO-critical software
those platforms. platforms.
Network Discovers, classifies, Supports (integral to) Discovering, classifying, and assessing the
Discovery and assesses the risk SM 4.4: Employ network risk posed by devices on the network is
posed by devices and security protection to vital for monitoring and analyzing network
users on the monitor the network traffic to and from devices.
network. traffic to and from EO-
critical software
platforms and their
software using
networks.

PRELIMINARY DRAFT

Virtual Private Enables authorized Supports (example of) VPNs are one method of encrypting data
Network remote users to SM 2.4: Protect data in in transit.
securely access the transit by using mutual
inside of the authentication
enterprise. (Once whenever feasible and
inside, the ZTA by encrypting sensitive
manages the user’s data communications
access to resources.) for EO-critical software
with NIST’s
Certificate Provides automated Supports (example of) Services can be identified and
Management capabilities to issue, SM 1.2: Uniquely authenticated through the use of TLS
install, inspect, identify and certificates.
revoke, renew, and authenticate each
otherwise manage service attempting to
TLS certificates. access EO-critical
software or EO-critical
software platforms.
Supports (integral to) TLS certificates are widely used for mutual
SM 2.4: Protect data in authentication and communications
transit by using mutual encryption—for example, in HTTPS.
authentication
whenever feasible and
by encrypting sensitive
data communications
for EO-critical software
with NIST’s
472 3.6.1 Mapping between E1B1 and the EO 14028 Security Measures

PRELIMINARY DRAFT

PRELIMINARY DRAFT
482 Appendix A References

483 [1] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, National Institute of
484 Standards and Technology (NIST) Special Publication (SP) 800-207, Gaithersburg, Md., August
485 2020, 50 pp. Available: https://csrc.nist.gov/publications/detail/sp/800-207/final
486 [2] S. Rose, Planning for a Zero Trust Architecture: A Planning Guide for Federal Administrators,
487 National Institute of Standards and Technology (NIST) Cybersecurity White Paper (CSWP) 20,
488 Gaithersburg, Md., May 2022, 14 pp. Available:
489 https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.20.pdf
490 [3] NIST. Cybersecurity Framework. Available: https://www.nist.gov/cyberframework/
491 [4] Joint Task Force, Security and Privacy Controls for Information Systems and Organizations,
492 National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Revision 5,
493 Gaithersburg, Md., September 2020, 465 pp. Available:
494 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
495 [5] Executive Order no. 14028, Improving the Nation’s Cybersecurity, Federal Register Vol. 86,
496 No.93, May 17, 2021. Available: https://www.federalregister.gov/documents/2021/05/17/2021-
497 10460/improving-the-nations-cybersecurity
498 [6] Security Measures for “EO-Critical Software” Use Under Executive Order (EO) 14028, National
499 Institute of Standards and Technology (NIST). Available: https://www.nist.gov/itl/executive-
500 order-improving-nations-cybersecurity/security-measures-eo-critical-software-use-2

Zta Nist SP 1800 35e Preliminary Draft

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zta Nist SP 1800 35e Preliminary Draft

Uploaded by

Copyright:

Available Formats

NIST SPECIAL PUBLICATION 1800-35E

Alper Kerman Karen Scarfone

Susan Symington William Barker

This publication is available free of charge from

18 Comments on this publication may be submitted to: nccoe-zta-project@list.nist.gov.

19 Public comment period: December 21, 2022 through February 6, 2023

21 National Cybersecurity Center of Excellence

NIST SP 1800-35E: Implementing a Zero Trust Architecture ii

27 NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

43 NIST CYBERSECURITY PRACTICE GUIDES

NIST SP 1800-35E: Implementing a Zero Trust Architecture iii

Timothy Jones Forescout

Tim LeMaster Lookout

Parisa Grayeli MITRE

Kevin Stine NIST

Wade Ellery Radiant Logic

Deborah McGinn Radiant Logic

NIST SP 1800-35E: Implementing a Zero Trust Architecture iv

86 CALL FOR PATENT CLAIMS

NIST SP 1800-35E: Implementing a Zero Trust Architecture v

111 Such statements should be addressed to: nccoe-zta-project@list.nist.gov

NIST SP 1800-35E: Implementing a Zero Trust Architecture vi

NIST SP 1800-35E: Implementing a Zero Trust Architecture vii

144 Appendix A References .......................................................................... 57

145 List of Tables

NIST SP 1800-35E: Implementing a Zero Trust Architecture viii

157 1.1 How to Use this Guide

170 When complete, this guide will contain five volumes:

NIST SP 1800-35E: Implementing a Zero Trust Architecture 1

185 ▪ challenges that enterprises face in migrating to the use of ZTA

NIST SP 1800-35E: Implementing a Zero Trust Architecture 2

220 2 Risk Management

223 2.1 Threats

NIST SP 1800-35E: Implementing a Zero Trust Architecture 3

NIST SP 1800-35E: Implementing a Zero Trust Architecture 4

293 2.2 Vulnerabilities

303 2.3 Risk

318 3 ZTA Reference Architecture Security Mappings

NIST SP 1800-35E: Implementing a Zero Trust Architecture 5

336 3.1 Use Cases

350 3.2 Mapping Producers

353 3.3 Mapping Approach

NIST SP 1800-35E: Implementing a Zero Trust Architecture 6

364 3.3.1 Mapping Terminology

369 ▪ Supports: ZTA function X supports security control/subcategory/measure Y when X can be

NIST SP 1800-35E: Implementing a Zero Trust Architecture 7

394 3.3.2 Mapping Process

398 2. Describe each logical component’s cybersecurity function in column 2.

NIST SP 1800-35E: Implementing a Zero Trust Architecture 8

422 3.3.3 Mapping Subsection Organization

424 ▪ Section 3.4 – NIST CSF 1.1

ZTA Logical ZTA Component’s Function’s Relationships Relationship Explanation

NIST SP 1800-35E: Implementing a Zero Trust Architecture 9

ZTA Logical ZTA Component’s Function’s Relationships Relationship Explanation

NIST SP 1800-35E: Implementing a Zero Trust Architecture 10

ZTA Logical ZTA Component’s Function’s Relationships Relationship Explanation

NIST SP 1800-35E: Implementing a Zero Trust Architecture 11

ZTA Logical ZTA Component’s Function’s Relationships Relationship Explanation

NIST SP 1800-35E: Implementing a Zero Trust Architecture 12

ZTA Logical ZTA Component’s Function’s Relationships Relationship Explanation

NIST SP 1800-35E: Implementing a Zero Trust Architecture 13

ZTA Logical ZTA Component’s Function’s Relationships Relationship Explanation

NIST SP 1800-35E: Implementing a Zero Trust Architecture 14