NIST SPECIAL PUBLICATION 1800-35B
Implementing a Zero Trust Architecture
Volume B:
Approach, Architecture, and Security Characteristics
Oliver Borchert
Gema Howell
Alper Kerman
Scott Rose
Murugiah Souppaya
National Institute of
Standards and Technology
Gaithersburg, MD
Jason Ajmo
Yemi Fashina
Parisa Grayeli
Joseph Hunt
Jason Hurlburt
Nedu Irrechukwu
Joshua Klosterman
Oksana Slivina
Susan Symington
Allen Tan
The MITRE Corporation
McLean, VA
Karen Scarfone
Scarfone Cybersecurity
Clifton, VA
Peter Gallagher
Aaron Palermo
Appgate
Coral Gables, FL
Adam Cerini
Conrad Fernandes
AWS (Amazon Web Services)
Arlington, VA
Kyle Black
Sunjeet Randhawa
Broadcom Software
San Jose, CA
Matthew Hyatt
Peter Romness
Cisco
Herndon, VA
Corey Bonnell
Dean Coclin
DigiCert
Lehi, UT
Ryan Johnson
Dung Lam
F5
Seattle, WA
Tim Jones
Tom May
Forescout
San Jose, CA
Marco Genovese
Tim Knudson
Google Cloud
Mill Valley, CA
Harmeet Singh
Mike Spisak
IBM
Armonk, NY
Corey Lund
Farhan Saifudin
Ivanti
South Jordan, UT
Hashim Khan
Tim LeMaster
Lookout
Reston, VA
Ken Durbin
Earl Matthews
Mandiant
Reston, VA
Tarek Dawoud
Clay Taylor
Microsoft
Redmond, WA
Vinu Panicker
Okta
San Francisco, CA
Sean Morgan
Norman Wong
Palo Alto Networks
Santa Clara, CA
Zack Austin
PC Matic
Myrtle Beach, SC
Mitchell Lewars
Bryan Rosensteel
Ping Identity
Denver, CO
Wade Ellery
Deborah McGinn
Radiant Logic
Novato, CA
Frank Briguglio
Ryan Tighe
SailPoint
Austin, TX
Chris Jensen
Joshua Moll
Tenable
Columbia, MD
Jason White
Trellix, Public Sector
Reston, VA
Peter Bjork
Keith Luck
VMware
Palo Alto, CA
Joe Brown
Jim Kovach
Zimperium
Dallas, TX
Syed Ali
Bob Smith
Zscaler
San Jose, CA
July 2023
THIRD PRELIMINARY DRAFT
This publication is available free of charge from
https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture ii
DISCLAIMER
1
Certain commercial entities, equipment, products, or materials may be identified by name or company
2
logo or other insignia in order to acknowledge their participation in this collaboration or to describe an
3
experimental procedure or concept adequately. Such identification is not intended to imply special
4
status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it
5
intended to imply that the entities, equipment, products, or materials are necessarily the best available
6
for the purpose.
7
National Institute of Standards and Technology Special Publication 1800-35B, Natl. Inst. Stand. Technol.
8
Spec. Publ. 1800-35B, 245 pages, (July 2023), CODEN: NSPUE2
9
FEEDBACK
10
You can improve this guide by contributing feedback. As you review and adopt this solution for your
11
own organization, we ask you and your colleagues to share your experience and advice with us.
12
Comments on this publication may be submitted to: nccoe-[email protected].
13
Public comment period: July 19, 2023 through September 4, 2023
14
All comments are subject to release under the Freedom of Information Act.
15
National Cybersecurity Center of Excellence
16
National Institute of Standards and Technology
17
100 Bureau Drive
18
Mailstop 2002
19
Gaithersburg, MD 20899
20
Email: ncc[email protected]
21
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture iii
NATIONAL CYBERSECURITY CENTER OF EXCELLENCE
22
The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards
23
and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and
24
academic institutions work together to address businesses’ most pressing cybersecurity issues. This
25
public-private partnership enables the creation of practical cybersecurity solutions for specific
26
industries, as well as for broad, cross-sector technology challenges. Through consortia under
27
Cooperative Research and Development Agreements (CRADAs), including technology partners—from
28
Fortune 50 market leaders to smaller companies specializing in information technology security—the
29
NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity
30
solutions using commercially available technology. The NCCoE documents these example solutions in
31
the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework
32
and details the steps needed for another entity to re-create the example solution. The NCCoE was
33
established in 2012 by NIST in partnership with the State of Maryland and Montgomery County,
34
Maryland.
35
To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit
36
https://www.nist.gov.
37
NIST CYBERSECURITY PRACTICE GUIDES
38
NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity
39
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the
40
adoption of standards-based approaches to cybersecurity. They show members of the information
41
security community how to implement example solutions that help them align with relevant standards
42
and best practices, and provide users with the materials lists, configuration files, and other information
43
they need to implement a similar approach.
44
The documents in this series describe example implementations of cybersecurity practices that
45
businesses and other organizations may voluntarily adopt. These documents do not describe regulations
46
or mandatory practices, nor do they carry statutory authority.
47
ABSTRACT
48
A zero trust architecture (ZTA) focuses on protecting data and resources. It enables secure authorized
49
access to enterprise resources that are distributed across on-premises and multiple cloud environments,
50
while enabling a hybrid workforce and partners to access resources from anywhere, at any time, from
51
any device in support of the organization’s mission. Each access request is evaluated by verifying the
52
context available at access time, including criteria such as the requester’s identity and role, the
53
requesting device’s health and credentials, the sensitivity of the resource, user location, and user
54
behavior consistency. If the enterprise’s defined access policy is met, a secure session is created to
55
protect all information transferred to and from the resource. A real-time and continuous policy-driven,
56
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture iv
risk-based assessment is performed to establish and maintain the access. In this project, the NCCoE and
57
its collaborators use commercially available technology to build interoperable, open, standards-based
58
ZTA implementations that align to the concepts and principles in NIST Special Publication (SP) 800-207,
59
Zero Trust Architecture. This NIST Cybersecurity Practice Guide explains how commercially available
60
technology can be integrated and used to build various ZTAs.
61
KEYWORDS
62
enhanced identity governance (EIG); identity, credential, and access management (ICAM);
63
microsegmentation; software-defined perimeter (SDP); zero trust; zero trust architecture (ZTA).
64
ACKNOWLEDGMENTS
65
We are grateful to the following individuals for their generous contributions of expertise and time.
66
Name
Organization
Madhu Balaji
Amazon Web Services
Harrison Holstein
Amazon Web Services
Quint Van Deman
Amazon Web Services
Jason Garbis
Appgate
Adam Rose
Appgate
Jonathan Roy
Appgate
Eric Michael
Broadcom Software
Ken Andrews
Cisco
Robert Bui
Cisco
Brian Butler
Cisco
Mike Delaguardia
Cisco
Leo Lebel
Cisco
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture v
Name
Organization
Randy Martin
Cisco
Tom Oast
Cisco
Aaron Rodriguez
Cisco
Steve Vetter
Cisco
Micah Wilson
Cisco
Daniel Cayer
F5
David Clark
F5
Jay Kelley
F5
Yejin Jang
Forescout
Neal Lucier
Forescout
Christopher Altman
Google Cloud
Nilesh Atal
IBM
Andrew Campagna
IBM
John Dombroski
IBM
Adam Frank
IBM
Himanshu Gupta
IBM
Lakshmeesh Hegde
IBM
Nalini Kannan
IBM
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture vi
Name
Organization
Sharath Math
IBM
Naveen Murthy
IBM
Priti Patil
IBM
Nikhil Shah
IBM
Deepa Shetty
IBM
Harishkumar Somashekaraiah
IBM
Krishna Yellepeddy
IBM
Vahid Esfahani
IT Coalition
Ebadullah Siddiqui
IT Coalition
Musumani Woods
IT Coalition
Tyler Croak
Lookout
Madhu Dodda
Lookout
Jeff Gilhool
Lookout
James Elliott
Mandiant
David Pricer
Mandiant
Joey Cruz
Microsoft
Janet Jones
Microsoft
Carmichael Patton
Microsoft
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture vii
Name
Organization
Hemma Prafullchandra
Microsoft
Enrique Saggese
Microsoft
Brandon Stephenson
Microsoft
Sarah Young
Microsoft
Eileen Division*
MITRE
Spike Dog
MITRE
Sallie Edwards
MITRE
Ayayidjin Gabiam
MITRE
Jolene Loveless
MITRE
Karri Meldorf
MITRE
Kenneth Sandlin
MITRE
Lauren Swan
MITRE
Jessica Walton
MITRE
Mike Bartock
NIST
Douglas Montgomery
NIST
Kevin Stine
NIST
Sean Frazier
Okta
Kelsey Nelson
Okta
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture viii
Name
Organization
Imran Bashir
Palo Alto Networks
Seetal Patel
Palo Alto Networks
Shawn Higgins
PC Matic
Andy Tuch
PC Matic
Rob Woodworth
PC Matic
Ivan Anderson
Ping Identity
Aubrey Turner
Ping Identity
Bill Baz
Radiant Logic
Don Coltrain
Radiant Logic
Rusty Deaton
Radiant Logic
John Petrutiu
Radiant Logic
Lauren Selby
Radiant Logic
Peter Amaral
SailPoint
Jim Russell
SailPoint
Esteban Soto
SailPoint
Jeremiah Stallcup
Tenable
Bill Stritzinger
Tenable
Andrew Babakian
VMware
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture ix
Name
Organization
Genc Domi
VMware
Paul Mancuso
VMware
Dennis Moreau *
VMware
Wayne Pauley
VMware
Jacob Rapp *
VMware
Jeffrey Adorno
Zscaler
Jeremy James
Zscaler
Lisa Lorenzin*
Zscaler
Matt Moulton
Zscaler
Patrick Perry
Zscaler
* Former employee; all work for this publication was done while at that organization
67
Special thanks to all who reviewed and provided feedback on this document.
68
The Technology Partners/Collaborators who have or will participate in this project’s current or upcoming
69
builds submitted their capabilities in response to a notice in the Federal Register. Respondents with
70
relevant capabilities or product components were invited to sign a Cooperative Research and
71
Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build this
72
example solution. We are working with the following list of collaborators.
73
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture x
Technology Collaborators
IBM
Ivanti
Lookout
Mandiant
Microsoft
Okta
Palo Alto Networks
PC Matic
DOCUMENT CONVENTIONS
74
The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the
75
publication and from which no deviation is permitted. The terms “should” and “should not” indicate that
76
among several possibilities, one is recommended as particularly suitable without mentioning or
77
excluding others, or that a certain course of action is preferred but not necessarily required, or that (in
78
the negative form) a certain possibility or course of action is discouraged but not prohibited. The terms
79
“may” and “need not” indicate a course of action permissible within the limits of the publication. The
80
terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.
81
CALL FOR PATENT CLAIMS
82
This public review includes a call for information on essential patent claims (claims whose use would be
83
required for compliance with the guidance or requirements in this Information Technology Laboratory
84
(ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication
85
or by reference to another publication. This call also includes disclosure, where known, of the existence
86
of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant
87
unexpired U.S. or foreign patents.
88
ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in
89
written or electronic form, either:
90
a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not
91
currently intend holding any essential patent claim(s); or
92
b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring
93
to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft
94
publication either:
95
1. under reasonable terms and conditions that are demonstrably free of any unfair discrimination;
96
or
97
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xi
2. without compensation and under reasonable terms and conditions that are demonstrably free
98
of any unfair discrimination.
99
Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its
100
behalf) will include in any documents transferring ownership of patents subject to the assurance,
101
provisions sufficient to ensure that the commitments in the assurance are binding on the transferee,
102
and that the transferee will similarly include appropriate provisions in the event of future transfers with
103
the goal of binding each successor-in-interest.
104
The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of
105
whether such provisions are included in the relevant transfer documents.
106
Such statements should be addressed to: nccoe-zta-[email protected]
107
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xii
Contents
108
1 Summary ............................................................................................. 1
109
1.1 Challenge ....................................................................................................................... 1
110
1.2 Solution.......................................................................................................................... 2
111
1.3 Benefits .......................................................................................................................... 4
112
2 How to Use This Guide ......................................................................... 5
113
2.1 Typographic Conventions .............................................................................................. 6
114
3 Approach ............................................................................................. 7
115
3.1 Audience ........................................................................................................................ 9
116
3.2 Scope ............................................................................................................................. 9
117
3.3 Assumptions ................................................................................................................ 10
118
3.4 Collaborators and Their Contributions ........................................................................ 11
119
3.4.1 Appgate....................................................................................................................... 12
120
3.4.2 Appgate SDP ............................................................................................................... 12
121
3.4.3 AWS ............................................................................................................................ 12
122
3.4.4 Broadcom Software .................................................................................................... 14
123
3.4.5 Cisco ............................................................................................................................ 17
124
3.4.6 DigiCert ....................................................................................................................... 20
125
3.4.7 F5 ................................................................................................................................ 21
126
3.4.8 Forescout .................................................................................................................... 23
127
3.4.9 Google Cloud .............................................................................................................. 24
128
3.4.10 IBM.............................................................................................................................. 25
129
3.4.11 Ivanti ........................................................................................................................... 27
130
3.4.12 Lookout ....................................................................................................................... 28
131
3.4.13 Mandiant .................................................................................................................... 29
132
3.4.14 Microsoft .................................................................................................................... 30
133
3.4.15 Okta ............................................................................................................................ 34
134
3.4.16 Palo Alto Networks ..................................................................................................... 35
135
3.4.17 PC Matic ...................................................................................................................... 38
136
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xiii
3.4.18 Ping Identity ................................................................................................................ 38
137
3.4.19 Radiant Logic............................................................................................................... 41
138
3.4.20 SailPoint ...................................................................................................................... 42
139
3.4.21 Tenable ....................................................................................................................... 44
140
3.4.22 Trellix .......................................................................................................................... 45
141
3.4.23 VMware ...................................................................................................................... 48
142
3.4.24 Zimperium .................................................................................................................. 51
143
3.4.25 Zscaler ......................................................................................................................... 51
144
4 Architecture ....................................................................................... 53
145
4.1 General ZTA Reference Architecture .......................................................................... 53
146
4.1.1 ZTA Core Components ................................................................................................ 55
147
4.1.2 ZTA Supporting Components ...................................................................................... 55
148
4.1.3 ZTA in Operation ......................................................................................................... 60
149
4.2 EIG Crawl Phase Reference Architecture .................................................................... 65
150
4.3 EIG Run Phase .............................................................................................................. 67
151
4.4 SDP and Microsegmentation Builds ............................................................................ 67
152
4.5 ZTA Laboratory Physical Architecture ......................................................................... 68
153
4.5.1 Enterprise 1................................................................................................................. 70
154
4.5.2 Enterprise 1 Branch Office .......................................................................................... 75
155
4.5.3 Enterprise 2................................................................................................................. 77
156
4.5.4 Enterprise 3................................................................................................................. 77
157
4.5.5 Enterprise 4................................................................................................................. 77
158
4.5.6 Coffee Shop ................................................................................................................ 79
159
4.5.7 Management and Orchestration Domain .................................................................. 79
160
4.5.8 Emulated WAN Service Provider ................................................................................ 80
161
4.5.9 Cloud Services ............................................................................................................. 80
162
4.6 Phase 0 Baseline Security Capability Deployment ...................................................... 87
163
5 Functional Demonstration ................................................................. 87
164
6 General Findings ................................................................................ 87
165
6.1 EIG Crawl Phase Findings ............................................................................................ 88
166
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xiv
6.2 EIG Run Phase Findings ............................................................................................... 89
167
6.3 SDP and Microsegmentation Phase Findings .............................................................. 90
168
6.4 Zero Trust Journey Takeaways .................................................................................... 91
169
6.4.2 Formulate access policy to support the mission and business use cases .................. 92
170
6.4.3 Identify existing security capabilities and technology ............................................... 93
171
6.4.4 Eliminate Gaps in Zero Trust Policy and Processes by Applying a Risk-Based
172
Approach Based on the Value of Data ....................................................................... 93
173
6.4.5 Implement ZTA components (people, process, and technology) and incrementally
174
leverage deployed security solutions to achieve the end goal .................................. 94
175
6.4.6 Verify the implementation to support zero trust outcomes ...................................... 95
176
6.4.7 Continuously improve and evolve due to changes in threat landscape, mission,
177
technology, and regulations ....................................................................................... 95
178
7 Future Build Considerations ............................................................... 96
179
Appendix A List of Acronyms ................................................................. 97
180
Appendix B Glossary ............................................................................ 103
181
Appendix C References ........................................................................ 105
182
Appendix D Enterprise 1 Build 1 (E1B1) – EIG Crawl ............................. 107
183
D.1 Technologies .............................................................................................................. 107
184
D.2 Build Architecture...................................................................................................... 111
185
D.2.1 Logical Architecture .................................................................................................. 111
186
D.2.2 ICAM Information Architecture ................................................................................ 112
187
D.2.3 Physical Architecture ................................................................................................ 124
188
D.2.4 Message Flow for a Successful Resource Access Request ....................................... 124
189
Appendix E Enterprise 2 Build 1 (E2B1) – EIG Crawl ............................. 128
190
E.1 Technologies .............................................................................................................. 128
191
E.2 Build Architecture...................................................................................................... 132
192
E.2.1 Logical Architecture .................................................................................................. 132
193
E.2.2 ICAM Information Architecture ................................................................................ 133
194
E.2.3 Physical Architecture ................................................................................................ 145
195
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xv
E.2.4 Message Flow for a Successful Resource Access Request ....................................... 145
196
Appendix F Enterprise 3 Build 1 (E3B1) – EIG Crawl ............................. 148
197
F.1 Technologies .............................................................................................................. 148
198
F.2 Build Architecture...................................................................................................... 152
199
F.2.1 Logical Architecture .................................................................................................. 152
200
F.2.2 Physical Architecture ................................................................................................ 153
201
F.2.3 Message Flows for a Successful Resource Access Request ...................................... 153
202
Appendix G Enterprise 1 Build 2 (E1B2) – EIG Run ................................ 158
203
G.1 Technologies .............................................................................................................. 158
204
G.2 Build Architecture...................................................................................................... 162
205
G.2.1 Logical Architecture .................................................................................................. 162
206
G.2.2 ICAM Information Architecture ................................................................................ 163
207
G.2.3 Physical Architecture ................................................................................................ 164
208
G.2.4 Message Flows for Successful Resource Access Requests ....................................... 164
209
Appendix H Enterprise 3 Build 2 (E3B2) – EIG Run ................................ 172
210
H.1 Technologies .............................................................................................................. 172
211
H.2 Build Architecture...................................................................................................... 178
212
H.2.1 Logical Architecture .................................................................................................. 178
213
H.2.2 Physical Architecture ................................................................................................ 179
214
H.2.3 Message Flows for a Successful Resource Access Request ...................................... 179
215
Appendix I Enterprise 1 Build 3 (E1B3) – SDP ...................................... 187
216
Appendix J Enterprise 2 Build 3 (E2B3) — Microsegmentation
217
(Network) ......................................................................... 188
218
J.1 Technologies .............................................................................................................. 188
219
J.2 Build Architecture...................................................................................................... 193
220
J.2.1 Logical Architecture .................................................................................................. 193
221
J.2.2 ICAM Information Architecture ................................................................................ 194
222
J.2.3 Physical Architecture ................................................................................................ 194
223
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xvi
J.2.4 E2B3 Message Flows for Resource Access Requests, Non-Compliant Endpoints,
224
Forbidden Access Requests, and Policy Discovery ................................................... 195
225
Appendix K Enterprise 3 Build 3 (E3B3) — SDP and
226
Microsegmentation ........................................................... 207
227
K.1 Technologies .............................................................................................................. 207
228
K.2 Build Architecture...................................................................................................... 214
229
K.2.1 Logical Architecture .................................................................................................. 214
230
K.2.2 Physical Architecture ................................................................................................ 215
231
K.2.3 Message Flows for a Successful Resource Access Request ...................................... 215
232
Appendix L Enterprise 4 Build 3 (E4B3) — EIG Run ............................... 221
233
L.1 Technologies .............................................................................................................. 221
234
L.2 Build Architecture...................................................................................................... 226
235
L.2.1 Logical Architecture .................................................................................................. 226
236
L.2.2 Physical Architecture ................................................................................................ 227
237
L.2.3 Message Flows for Successful Resource Access Requests ....................................... 227
238
Appendix M Enterprise 1 Build 4 (E1B4) – SDP ...................................... 232
239
M.1 Technologies .............................................................................................................. 232
240
M.2 Build Architecture...................................................................................................... 236
241
M.2.1 Logical Architecture .................................................................................................. 236
242
M.2.2 ICAM Information Architecture ................................................................................ 237
243
M.2.3 Physical Architecture ................................................................................................ 238
244
M.2.4 Message Flows for Successful Resource Access Requests ....................................... 238
245
List of Figures
246
Figure 4-1 General ZTA Reference Architecture ................................................................................. 54
247
Figure 4-2 EIG Crawl Phase Reference Architecture ........................................................................... 66
248
Figure 4-3 Physical Architecture of ZTA Lab ....................................................................................... 69
249
Figure 4-4 Physical Architecture of Enterprise 1 ................................................................................ 71
250
Figure 4-5 Shared Services Domain of Enterprise 1 ............................................................................ 73
251
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xvii
Figure 4-6 Physical Architecture of the Enterprise 1 Branch Office ..................................................... 76
252
Figure 4-7 Enterprise 4 Physical Infrastructure .................................................................................. 78
253
Figure 4-8 Physical Architecture of the Coffee Shop .......................................................................... 79
254
Figure 4-9 Physical Architecture of the Management and Orchestration Domain ............................... 80
255
Figure 4-10 Physical Architecture of the AWS Infrastructure Used by Enterprise 1.............................. 82
256
Figure 4-11 Physical Architecture of the Azure Infrastructure Used by Enterprise 3 ............................ 84
257
Figure 4-12 Physical Architecture of the IBM Cloud Infrastructure Used by Enterprise 4 ..................... 86
258
Figure D-1 Logical Architecture of E1B1 ........................................................................................... 112
259
Figure D-2 E1B1 ICAM Information Architecture – Identity Correlation ............................................ 115
260
Figure D-3 E1B1 ICAM Information Architecture – New User Onboarding ........................................ 118
261
Figure D-4 E1B1 ICAM Information Architecture - User Changes Roles ............................................. 121
262
Figure D-5 E1B1 ICAM Information Architecture - User Termination ................................................ 123
263
Figure D-6 Successful Access Request Enforced by Okta, Ivanti, and Zimperium Components ........... 125
264
Figure E-1 Logical Architecture of E2B1 ........................................................................................... 133
265
Figure E-2 E2B1 ICAM Information Architecture – Identity Correlation ............................................. 136
266
Figure E-3 E2B1 ICAM Information Architecture – New User Onboarding ......................................... 139
267
Figure E-4 E2B1 ICAM Information Architecture - User Changes Roles .............................................. 142
268
Figure E-5 E2B1 ICAM Information Architecture - User Termination ................................................. 144
269
Figure E-6 Use Case—E2B1 – Access Enforced by PingFederate, Cisco Duo, and Radiant Logic........... 146
270
Figure F-1 Logical Architecture of E3B1 ........................................................................................... 153
271
Figure F-2 Use Case—E3B1 – Access Enforced by Azure AD .............................................................. 155
272
Figure F-3 Use Case—E3B1 – Access Enforced by F5 BIG-IP .............................................................. 156
273
Figure G-1 Logical Architecture of E1B2........................................................................................... 163
274
Figure G-2 Access to an Internal Resource is Enforced by Zscaler ZPA and Okta Identity Cloud ......... 167
275
Figure G-3 Access to an Externally-Facing Resource is Enforced by Zscaler ZIA and Okta Identity
276
Cloud ............................................................................................................................................. 169
277
Figure H-1 Logical Architecture of E3B2 ........................................................................................... 179
278
Figure H-2 Use Case— E3B2 – Access to an Internal Resource is Enforced by Azure AD and Azure
279
AD’s Application Proxy ................................................................................................................... 182
280
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xviii
Figure H-3 Use Case— E3B2 – Access to an Externally-Facing Resource is Enforced by Azure AD and
281
Microsoft Defender for Cloud Apps ................................................................................................ 184
282
Figure H-4 Use Case—E3B2 – Forescout Discovers a Non-Compliant Endpoint on the Network and
283
Directs the Palo Alto Networks Firewall to Block it .......................................................................... 186
284
Figure J-1 Logical Architecture of E2B3 ............................................................................................ 194
285
Figure J-2 Use Case—E2B3 – User Authentication and Access Enforcement When the Requesting
286
Device Is Non-Mobile ..................................................................................................................... 196
287
Figure J-3 Use Case—E2B3 – User Authentication and Access Enforcement When the Requesting
288
Device Is Mobile ............................................................................................................................ 199
289
Figure J-4 Use Case—E2B3 – Message Flow When an Endpoint is Determined to Be Non-Compliant. 201
290
Figure J-5 Use Case—E2B3 – Message Flow When a User’s Endpoint is Compliant but the User
291
Requests Access to a Domain that Is Not Permitted by Policy .......................................................... 202
292
Figure J-6 Use Case—E2B3 – Cisco Secure Workload Policy Discovery .............................................. 204
293
Figure J-7 Use Case—E2B3 – Cisco ISE Manages Access to the Network and Resources ..................... 205
294
Figure K-1 Logical Architecture of E3B3 ........................................................................................... 214
295
Figure K-2 Use Case— E3B3 – Azure Decisions Are Based on Sentinel Log Information ..................... 216
296
Figure K-3 Use Case— E3B3 – A Device that Intune Determines to be Non-Compliant is Temporarily
297
Blocked from Accessing the Resource until It is Remediated and Brought Back Into Compliance ...... 217
298
Figure K-4 Use Case—E3B3 – Purview DLP Blocks an Attempt to Retrieve PII from the Resource ...... 218
299
Figure K-5 Use Case—E3B3 – Service-to-Microsoft Service Access .................................................... 219
300
Figure L-1 Logical Architecture of E4B3 ........................................................................................... 227
301
Figure L-2 Use Case— E4B3 – The Requesting Endpoint Is Managed, so Access Is Enforced by IBM
302
Security Verify/Trusteer and IBM MaaS360 .................................................................................... 229
303
Figure L-3 Use Case— E4B3 – The Requesting Endpoint Is Unmanaged, so Access Is Enforced by IBM
304
Security Verify/Trusteer ................................................................................................................. 230
305
Figure M-1 Logical Architecture of E1B4 .......................................................................................... 237
306
Figure M-2 Use Case—E1B4 – Access to an On-Premises Resource Is Enforced by Appgate ............... 240
307
Figure M-3 Use Case—E1B4 – Access to an AWS Cloud Resource Is Enforced by Appgate ................. 242
308
Figure M-4 Use Case—E1B4 – Server-to-Server Access Enforced by Appgate .................................... 244
309
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture xix
List of Tables
310
Table 3-1 Technology Partners/Collaborators ................................................................................... 11
311
Table 4-1 Mapping of Builds to Architectures and Appendices ........................................................... 69
312
Table D-1 E1B1 Products and Technologies ..................................................................................... 107
313
Table E-1 E2B1 Products and Technologies ...................................................................................... 128
314
Table F-1 E3B1 Products and Technologies ...................................................................................... 148
315
Table G-1 E1B2 Products and Technologies ..................................................................................... 158
316
Table H-1 E3B2 Products and Technologies ..................................................................................... 172
317
Table J-1 E2B3 Products and Technologies ...................................................................................... 188
318
Table K-1 E3B3 Products and Technologies ..................................................................................... 207
319
Table L-1 E4B3 Products and Technologies ...................................................................................... 221
320
Table M-1 E1B4 Products and Technologies .................................................................................... 232
321
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 1
1 Summary
322
1.1 Challenge
323
Protecting enterprise resources, particularly data, has become increasingly challenging as resources
324
have become distributed across both on-premises environments and multiple clouds. Many users need
325
access from anywhere, at any time, from any device to support the organization’s mission. Data is
326
programmatically stored, transmitted, and processed across different boundaries under the control of
327
different organizations to meet ever-evolving business use cases. It is no longer feasible to simply
328
enforce access controls at the perimeter of the enterprise environment and assume that all subjects
1
329
(e.g., end users, applications, and other non-human entities that request information from resources)
330
within it can be trusted. A zero-trust architecture (ZTA) addresses this challenge by enforcing granular,
331
secure authorized access near the resources, whether located on-premises or in the cloud, for both
332
remote and onsite workforces and partners based on an organization’s defined access policy.
333
Many organizations would like to address these challenges by migrating to a ZTA, but they have been
334
hindered by several factors, which may include:
335
▪ Lack of adequate asset inventory and management needed to fully understand the business
336
applications, assets, and processes that need to be protected, with no clear understanding of
337
the criticality of these resources
338
▪ Lack of adequate digital definition, management, and tracking of user roles across the
339
organization needed to enforce fine-grained, need-to-know access policy for specific
340
applications and services
341
▪ Ever-increasing complexity of communication flows and distributed IT components across the
342
environments on-premises and in the cloud, making them difficult to manage consistently
343
▪ Hiring and retaining skilled personnel to both oversee and operate within the environment, and
344
keeping the IT and security teams trained and informed while complexity is increasing and new
345
skills need to be developed on an ongoing basis
346
▪ Lack of visibility of the organization’s communications and usage patterns—limited
347
understanding of the transactions that occur between an organization’s subjects, assets,
348
applications, and services, and absence of the data necessary to identify these communications
349
and their specific flows
350
1
As with NIST Special Publication (SP) 800-207 [1], throughout this document subject will be used unless the
section relates directly to a human end user, in which case user will be used instead of the more generic subject.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 2
▪ Lack of awareness regarding everything that encompasses the organization’s entire attack
351
surface. Organizations can usually address threats with traditional security tools in the layers
352
that they currently manage and maintain such as networks and applications, but elements of a
353
ZTA may extend beyond their normal purview. False assumptions are often made in
354
understanding the health of a device as well as its exposure to supply chain risks.
355
▪ Lack of understanding regarding what interoperability issues may be involved or what additional
356
skills and training administrators, security personnel, operators, end users, and policy decision
357
makers may require; lack of resources to develop necessary policies and a pilot or proof-of-
358
concept implementation needed to inform a transition plan
359
▪ Leveraging existing investments and balancing priorities while making progress toward a ZTA via
360
modernization initiatives
361
▪ Integrating various types of commercially available technologies of varying maturities, assessing
362
capabilities, and identifying technology gaps to build a complete ZTA
363
▪ Concern that ZTA might negatively impact the operation of the environment or end-user
364
experience
365
▪ Lack of a standardized policy to distribute, manage, and enforce security policy, causing
366
organizations to face either a fragmentary policy environment or non-interoperable
367
components
368
▪ Lack of common understanding and language of ZTA across the community and within the
369
organization, gauging the organization’s ZTA maturity, determining which ZTA approach is most
370
suitable for the business, and developing an implementation plan
371
▪ Perception that ZTA is suited only for large organizations and requires significant investment
372
rather than understanding that ZTA is a set of guiding principles suitable for organizations of any
373
size.
374
▪ Not knowing how to prioritize or scope individual ZTA projects.
375
▪ There is not a single ZTA that fits all, for both organizations as well as subsets of their users. ZTAs
376
need to be designed and integrated for each organization and their users based on the
377
organization’s requirements and risk tolerance, as well as its existing invested technologies and
378
environments.
379
1.2 Solution
380
This project is designed to help address the challenges discussed above by building, demonstrating, and
381
documenting several example ZTAs using products and technologies from a variety of vendors. The
382
example solutions are designed to provide secure authorized access to individual resources by enforcing
383
enterprise security policy dynamically and in near-real-time. They restrict access to authenticated,
384
authorized users and devices while flexibly supporting a complex set of diverse business use cases.
385
These use cases involve legacy enterprise networks; remote workforces; use of the cloud; use of
386
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 3
corporate-provided, bring your own device (BYOD), and guest endpoints; collaboration with partners;
387
guest users; and support for contractors and other authorized third parties. The example solutions are
388
also designed to demonstrate having visibility within the various environments as well as recognizing
389
both internal and external attacks and malicious actors. They showcase the ability of ZTA products to
390
interoperate with legacy enterprise and cloud technologies to protect resources with minimal impact on
391
end-user experience.
392
The concepts and principles in NIST SP 800-207, Zero Trust Architecture are applied to enterprise
393
networks that are composed of pre-established devices and components and that store critical
394
corporate assets and resources both on-premises and in the cloud. For each data access session
395
requested, ZTA verifies the requester’s identity, role, and authorization to access the requested assets,
396
the requesting device’s health and credentials, and possibly other information. If defined policy is met,
397
ZTA dynamically creates a secure connection to protect all information transferred to and from the
398
accessed resource. ZTA performs real-time, continuous behavioral analysis and risk-based assessment of
399
the access transaction or session.
400
The example solutions, which are based on reference architectures, are built starting with a baseline
401
designed to resemble a notional existing enterprise environment that is assumed to have an identity
402
store and other security components in place. This enables the project to represent how a typical
403
enterprise is expected to evolve toward ZTA, i.e., by starting with their already-existing legacy enterprise
404
environment and gradually adding capabilities. In phase 0 of the project, four major cybersecurity
405
baseline functions were implemented: security information and event management (SIEM), vulnerability
406
scanning and assessment, security validation, and discovery. Next, a limited version of the enhanced
407
identity governance (EIG) deployment approach described in NIST SP 800-207 was implemented, during
408
what we refer to as the EIG crawl phase of the project. The first iteration of ZTA implementations was
409
based on the EIG approach because EIG is a foundational component of the other deployment
410
approaches utilized in today’s hybrid environments. The EIG approach uses the identity of subjects and
411
device health as the main determinants of policy decisions. However, instead of using a separate,
412
dedicated component to serve as a policy decision point (PDP), our crawl phase leveraged the identity,
413
credential, and access management (ICAM) components to serve as the PDP.
414
After completing the example solutions that were implemented as part of the EIG crawl phase of the
415
project, the EIG run phase was performed. In the EIG run phase, an EIG approach that was not limited to
416
using an ICAM component as the PDP was implemented. Next, we began the software-defined
417
perimeter (SDP) and microsegmentation phase of the project. As its name suggests, this phase involved
418
integrating ZTA components that support one or both of the SDP and microsegmentation deployment
419
models. It also integrated additional supporting components and features to provide an increasingly rich
420
set of ZTA functionalities.
421
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 4
1.3 Benefits
422
The demonstrated approach documented in this practice guide can provide organizations wanting to
423
migrate to ZTA with information and confidence that will help them develop transition plans for
424
integrating ZTA into their own legacy environments, based on the example solutions and using a risk-
425
based approach. Executive Order 14028, Improving the Nation’s Cybersecurity [2], requires all federal
426
agencies to develop plans to implement ZTA. This practice guide can inform agencies in developing their
427
ZTA implementation plans. When integrated into their enterprise environments, ZTA will enable
428
organizations to:
429
▪ Support teleworkers by enabling them to securely access corporate resources regardless of
430
their location—on-premises, at home, or on public Wi-Fi at a neighborhood coffee shop.
431
▪ Protect resources and assets regardless of their location—on-premises or in the cloud.
432
▪ Provision healthy devices from vendors that can verify that the device is authentic and free of
433
known exploitable vulnerabilities.
434
▪ Improve the end user experience by tailoring zero trust to the user and their devices and
435
working style. Access to specific resources can be authenticated and managed according to the
436
user’s risk profile as well as information such as device posture, location and time, and access
437
attempts. In cases of low risk, SSO can facilitate passwordless access to resources; in cases of
438
high risk, step-up authentication can be used or access can be denied.
439
▪ Limit the insider threat by rejecting the outdated assumption that any user located within the
440
network boundary should be automatically trusted and by enforcing the principle of least
441
privilege.
442
▪ Limit breaches by reducing an attacker’s ability to move laterally in the network. Access controls
443
can be enforced on an individual resource basis, so an attacker who has access to one resource
444
won’t be able to use it as a springboard for reaching other resources.
445
▪ Improve incident detection, response, and recovery to minimize impact when breaches occur.
446
Limiting breaches reduces the footprint of any compromise and the time to recovery.
447
▪ Protect sensitive corporate data by using strong encryption both while data is in transit and
448
while it is at rest. Grant subjects’ access to a specific resource only after enforcing consistent
449
identification, authentication, and authorization procedures, verifying device health, and
450
performing all other checks specified by enterprise policy.
451
▪ Improve visibility into which users are accessing which resources, when, how, and from
452
whereby monitoring and logging every access request within every access session.
453
▪ Perform dynamic, risk-based assessment of resource access through continuous reassessment
454
of all access transactions and sessions, gathering information from periodic reauthentication
455
and reauthorization, ongoing device health and posture verification, behavior analysis, ongoing
456
resource health verification, anomaly detection, and other security analytics.
457
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 5
2 How to Use This Guide
458
This NIST Cybersecurity Practice Guide will help users develop a plan for migrating to ZTA. It
459
demonstrates a standards-based ZTA reference design and provides users with the information they
460
need to replicate one or more standards-based ZTA implementations that align to the concepts and
461
principles in NIST SP 800-207, Zero Trust Architecture. This reference design is modular and can be
462
deployed in whole or in part, enabling organizations to incorporate ZTA into their legacy environments
463
gradually, in a process of continuous improvement that brings them closer and closer to achieving the
464
ZTA goals that they have prioritized based on risk, cost, and resources.
465
NIST is adopting an agile process to publish this content. Each volume is being made available as soon as
466
possible rather than delaying release until all volumes are completed. Work continues on implementing
467
the example solutions and developing other parts of the content. As a third preliminary draft, we will
468
publish at least one additional draft of this volume for public comment before it is finalized.
469
This guide contains five volumes:
470
▪ NIST SP 1800-35A: Executive Summary – why we wrote this guide, the challenge we address,
471
why it could be important to your organization, and our approach to solving this challenge
472
▪ NIST SP 1800-35B: Approach, Architecture, and Security Characteristics – what we built and why
473
(you are here)
474
▪ NIST SP 1800-35C: How-To Guides – instructions for building the example implementations,
475
including all the security-relevant details that would allow you to replicate all or parts of this
476
project
477
▪ NIST SP 1800-35D: Functional Demonstrations – use cases that have been defined to showcase
478
ZTA security capabilities and the results of demonstrating them with each of the example
479
implementations
480
▪ NIST SP 1800-35E: Risk and Compliance Management – risk analysis and mapping of ZTA security
481
characteristics to cybersecurity standards and recommended practices
482
Depending on your role in your organization, you might use this guide in different ways:
483
Business decision makers, including chief security and technology officers, will be interested in the
484
Executive Summary, NIST SP 1800-35A, which describes the following topics:
485
▪ challenges that enterprises face in migrating to the use of ZTA
486
▪ example solution built at the NCCoE
487
▪ benefits of adopting the example solution
488
Technology or security program managers who are concerned with how to identify, understand, assess,
489
and mitigate risk will be interested in this part of the guide, NIST SP 1800-35B, which describes what we
490
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 6
did and why. Also, Section 3 of Risk and Compliance Management, NIST SP 1800-35E, will be of
491
particular interest. Section 3, ZTA Reference Architecture Security Mappings, maps logical components
492
of the general ZTA reference design to security characteristics listed in various cybersecurity guidelines
493
and recommended practices documents, including Framework for Improving Critical Infrastructure
494
Cybersecurity (NIST Cybersecurity Framework), Security and Privacy Controls for Information Systems
495
and Organizations (NIST SP 800-53), and Security Measures for “EO-Critical Software” Use Under
496
Executive Order (EO) 14028.
497
You might share the Executive Summary, NIST SP 1800-35A, with your leadership team members to help
498
them understand the importance of migrating toward standards-based ZTA implementations that align
499
to the concepts and principles in NIST SP 800-207, Zero Trust Architecture.
500
IT professionals who want to implement similar solutions will find the whole practice guide useful. You
501
can use the how-to portion of the guide, NIST SP 1800-35C, to replicate all or parts of the builds created
502
in our lab. The how-to portion of the guide provides specific product installation, configuration, and
503
integration instructions for implementing the example solution. We do not re-create the product
504
manufacturers’ documentation, which is generally widely available. Rather, we show how we
505
incorporated the products together in our environment to create an example solution. Also, you can use
506
Functional Demonstrations, NIST SP 1800-35D, which provides the use cases that have been defined to
507
showcase ZTA security capabilities and the results of demonstrating them with each of the example
508
implementations.
509
This guide assumes that IT professionals have experience implementing security products within the
510
enterprise. While we have used a suite of commercial products to address this challenge, this guide does
511
not endorse these particular products. Your organization can adopt this solution or one that adheres to
512
these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing
513
parts of a ZTA. Your organization’s security experts should identify the products that will best integrate
514
with your existing tools and IT system infrastructure. We hope that you will seek products that are
515
congruent with applicable standards and best practices. The example solutions in this guide are not
516
intended to be wholly implemented by most enterprise organizations because each organization’s
517
transition to zero trust will depend on the organization’s risk profile and tolerance, among other factors.
518
A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. This is a
519
second preliminary draft guide. As the project progresses, this second preliminary draft will be updated,
520
and additional volumes will also be released for comment. We seek feedback on the publication’s
521
contents and welcome your input. Comments, suggestions, and success stories will improve subsequent
522
versions of this guide. Please contribute your thoughts to ncc[email protected].
523
2.1 Typographic Conventions
524
The following table presents typographic conventions used in this volume.
525
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 7
Typeface/Symbol
Meaning
Example
Italics
file names and path names; references
to documents that are not hyperlinks;
new terms; and placeholders
For language use and style guidance,
see the NCCoE Style Guide.
Bold
names of menus, options, command
buttons, and fields
Choose File > Edit.
Monospace
command-line input, onscreen
computer output, sample code
examples, and status codes
mkdir
Monospace Bold
command-line user input contrasted
with computer output
service sshd start
blue text
link to other parts of the document, a
web URL, or an email address
All publications from NIST’s NCCoE
are available at
https://www.nccoe.nist.gov.
3 Approach
526
The NCCoE issued an open invitation to technology providers to participate in demonstrating
527
approaches to deploying ZTA in a typical enterprise network environment. The objective was to use
528
commercially available technology to produce example ZTA implementations that manage secure access
529
to corporate resources hosted on-premises or in the cloud while supporting access from anywhere, at
530
any time, using any device.
531
The NCCoE prepared a Federal Register Notice [3] inviting technology providers to provide products
532
and/or expertise to compose prototype ZTAs. Core components sought included ZTA policy engines,
533
policy administrators, and policy enforcement points. Supporting components supporting data security,
534
endpoint security, identity and access management, and security analytics were also requested. In
535
addition, device and network infrastructure components such as laptops, tablets, and other devices that
536
connect to the enterprise were sought, as were data and compute resources, applications, and services
537
that are hosted and managed on-premises, in the cloud, at the edge, or some combination of these. The
538
NCCoE provided a network infrastructure that was designed to encompass the existing (non-ZTA)
539
network resources that a medium or large enterprise might typically have deployed, and the ZTA core
540
and supporting components and devices were integrated into this.
541
Cooperative Research and Development Agreements (CRADAs) were established with qualified
542
respondents, and build teams were assembled. The build teams fleshed out the initial architectures, and
543
the collaborators’ components have so far been composed into ten example implementations (i.e.,
544
builds), with several other builds in progress and additional future builds planned. With twenty-four
545
collaborators participating in the project, the build teams that were assembled sometimes included
546
vendors that offer overlapping capabilities. We made an effort to showcase capabilities from each
547
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 8
vendor when possible. In other cases, we consulted with the collaborators to have them work out a
548
solution. Each build team documented the architecture and design of its build. As each build progressed,
549
its team documented the steps taken to install and configure each component of the build. The teams
550
then conducted functional demonstrations of the builds, including the ability to securely manage access
551
to resources across a set of use cases that were defined to exercise a wide variety of typical enterprise
552
situations. Use cases for the project include the following:
553
▪ access by employees, privileged third parties, and guests
554
▪ access requested by users who are located at headquarters, a branch office, or teleworking via
555
public Wi-Fi and the internet
556
▪ inter-server access
557
▪ protection of resources that are located both on-premises and in the cloud
558
▪ use of enterprise-managed devices, contractor-managed devices, and personal devices
559
▪ access of both corporate resources and publicly available internet services
560
▪ the ability to automatically and dynamically calculate fine-grained confidence levels for resource
561
access requests
562
This project began with a clean laboratory environment that we populated with various applications and
563
services that would be expected in a typical enterprise to create several baseline enterprise
564
architectures. As part of our phase 0 baseline effort, we deployed SIEMs, vulnerability scanning and
565
assessment tools, security validation tools, and discovery tools. Next, we designed and built three
566
implementations of the EIG crawl phase deployment approach using a variety of commercial products.
567
After that, we built three implementations of the EIG run phase deployment approach and four
568
implementations of the SDP and/or microsegmentation deployment models (two SDP, one network
569
microsegmentation, and one combination of both SDP and microsegmentation implementations).
570
Given the importance of discovery to the successful implementation of a ZTA, as part of Phase 0 we
571
deployed discovery and other security tools into the baseline environment to continuously observe the
572
environment and use those observations to audit and validate the documented baseline map on an
573
ongoing basis. Because we had instantiated the baseline environment ourselves, we already had a good
574
initial understanding of it. However, we were able to use the discovery tools to audit and validate what
575
we deployed and provisioned, correlate known data with information reported by the tools, and use the
576
tool outputs to formulate initial zero trust policy, ultimately ensuring that observed network flows
577
correlate to static policies.
578
EIG uses the identity of subjects and device health as the main determinants of policy decisions.
579
Depending on the current state of identity management in the enterprise, deploying EIG solutions is an
580
initial key step that we expect organizations to leverage to eventually support the microsegmentation
581
and SDP deployment approaches. Therefore, that is the incremental path that we have followed in this
582
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 9
project. Our strategy has been to follow an agile implementation methodology to build everything
583
iteratively and incrementally while adding more capabilities to evolve to a complete ZTA. We started
584
with the minimum viable EIG solution that allowed us to achieve some level of ZTA and then we are
585
gradually deploying additional supporting components and features to address an increasing number of
586
the ZTA requirements, progressing the project toward eventual implementation and demonstration of
587
the more robust microsegmentation and SDP deployment builds that we are introducing in this draft.
588
3.1 Audience
589
The focus of this project is on medium and large enterprises. Its solution is targeted to address the
590
needs of these enterprises, which are assumed to have a legacy network environment and trained
591
operators and network administrators. These operators and administrators are assumed to have the
592
skills to deploy ZTA components as well as related supporting components for data security, endpoint
593
security, identity and access management, and security analytics. The enterprises are also assumed to
594
have critical resources that require protection, some of which are located on-premises and others of
595
which are in the cloud; and a requirement to provide partners, contractors, guests, and employees, both
596
local and remote, with secure access to these critical resources. The reader is assumed to be familiar
597
with NIST SP 800-207, Zero Trust Architecture.
598
3.2 Scope
599
The scope of this project is initially limited to implementing a ZTA for a conventional, general-purpose
600
enterprise IT infrastructure that combines users (including employees, partners, contractors, guests,
601
customers, and non-person entities [NPEs]), devices, and enterprise resources. Resources could be
602
hosted and managed—by the corporation itself or a third-party provider—either on-premises or in the
603
cloud, or some combination of these. There may also be branch or partner offices, teleworkers, and
604
support for fully managed BYOD and non-managed (i.e., guest) device usage. While mobile device
605
management (MDM) is used to support these device types, demonstrating the full spectrum of MDM
606
capabilities is beyond the scope of this project. Initially, support for traditional IT resources such as
607
laptops, desktops, servers, and other systems with credentials is within scope. In future phases, the
608
scope may expand to include ZTA support for Internet of Things (IoT) devices. ZTA support for both IPv4
609
and IPv6 is in scope, as are the three deployment approaches of EIG, microsegmentation, and SDP,
610
which can be used in various combinations to holistically deliver zero trust, and both agent-based and
611
agentless implementations.
612
It is important to establish the trustworthiness of ZTA component devices to mitigate the possibility that
613
the ZTA will be vulnerable to compromise through the hardware or software supply chain, but
614
discussion of methods for establishing and maintaining the trustworthiness of the underlying hardware
615
and supporting software comprising the ZTA is outside the scope of this document. Also, this document
616
is only concerned with using the ZTA to protect access to enterprise data. Addressing the risk and policy
617
requirements of discovering and classifying the data is out of scope.
618
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 10
This project focuses primarily on various types of user access to enterprise resources sprinkled across a
619
hybrid network environment. More specifically, the focus is on behaviors of enterprise employees,
620
partners, contractors, and guests accessing enterprise resources while connected from the corporate (or
621
enterprise headquarters) network, a branch office, or the public internet. Access requests can occur
622
over both the enterprise-owned part of the infrastructure and the public/non-enterprise-owned part.
623
This requires that all access requests be secure, authorized, and verified before access is enforced,
624
regardless of where the request is initiated or where the resources are located, i.e., whether on-
625
premises or in the cloud. Discovery of resources, assets, communication flows, and other elements is
626
also within scope.
627
ZTAs for industrial control systems and operational technology (OT) environments are explicitly out of
628
scope for this project. However, the project seeks to provide an approach and security principles for a
629
ZTA that could potentially be extended to OT environments. Any such application of ZTA principles to OT
630
environments would be part of a separate project. Please refer to other related NCCoE projects
631
[4][5][6][7]. The project is not concerned with addressing Federal Risk and Authorization Management
632
Program (FedRAMP) or other federal requirements at this time, although doing so could potentially be a
633
follow-on exercise.
634
Only implementations of the baseline, Phase 0, EIG crawl, EIG run, and SDP and microsegmentation
635
phase deployment approaches are within scope at this time.
636
3.3 Assumptions
637
This project is guided by the following assumptions:
638
▪ NIST SP 800-207, Zero Trust Architecture is a definitive source of ZTA concepts and principles.
639
▪ Enterprises that want to migrate gradually to an increasing use of ZTA concepts and principles in
640
their network environments may desire to integrate ZTA with their legacy enterprise and cloud
641
systems.
642
▪ To prepare for a migration to ZTA, enterprises may want to inventory and prioritize all resources
643
that require protection based on risk. They will also need to define policies that determine
644
under what set of conditions subjects will be given access to each resource based on attributes
645
of both the subject and the resource (e.g., location, type of authentication used, user role), as
646
well as other variables such as day and time.
647
▪ Enterprises should use a risk-based approach to set and prioritize milestones for their gradual
648
adoption and integration of ZTA across their enterprise environment.
649
▪ There is no single approach for migrating to ZTA that is best for all enterprises.
650
▪ There is not necessarily a clear point at which an organization can be said to have achieved a
651
state of “full” or 100% ZTA compliance. Continuous improvement is the objective.
652
▪ Devices, applications, and other non-human entities can have different levels of capabilities:
653
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 11
• Neither host-based firewalls nor host-based intrusion prevention systems (IPS) are
654
mandatory components; they are, however, capabilities that can be added when a device is
655
capable of supporting them.
656
• Some limited functionality devices that are not able to host firewall, IPS, and other
657
capabilities on their own may be associated with services that provide these capabilities for
658
them. In this case, both the device and its supporting services can be considered the
659
subject in the ZTA access interaction.
660
• Some devices are bound to users (e.g., desktop, laptop, smartphone); other devices are not
661
bound to users (e.g., kiosk endpoints, servers, applications, services). Both types of devices
662
can be subjects and request access to enterprise resources.
663
▪ ZTA components used in any given enterprise solution should be interoperable regardless of
664
their vendor origin.
665
3.4 Collaborators and Their Contributions
666
Organizations participating in this project submitted their capabilities in response to an open call in the
667
Federal Register for all sources of relevant security capabilities from academia and industry (vendors
668
and integrators). The following respondents with relevant capabilities or product components (identified
669
as “Technology Partners/Collaborators” herein) signed a CRADA to collaborate with NIST in a consortium
670
to build example ZTA solutions:
671
Table 3-1 Technology Partners/Collaborators
672
Technology Collaborators
IBM
Ivanti
Lookout
Mandiant
Microsoft
Okta
Palo Alto Networks
PC Matic
Each of these technology partners and collaborators, as well as the relevant products and capabilities
673
they bring to this ZTA effort, are described in the following subsections. The NCCoE does not certify or
674
validate products or services. We demonstrate the capabilities that can be achieved by using
675
participants’ contributed technology.
676
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 12
3.4.1 Appgate
677
Appgate is the secure access company. It empowers how people work and connect by providing
678
solutions purpose-built on zero trust security principles. This security approach enables fast, simple, and
679
secure connections from any device and location to workloads across any IT infrastructure in cloud, on-
680
premises, and hybrid environments.
681
3.4.2 Appgate SDP
682
The Appgate SDP solution has been designed with the intent to provide all the critical elements of NIST
683
SP 800-207. The Appgate SDP has a controller that offers policy administrator (PA) and policy engine (PE)
684
functionality and gateways that offer policy enforcement point (PEP) functionality. Appgate SDP natively
685
integrates with components via representational state transfer (REST) application programming
686
interfaces (APIs) and metadata. By providing highly performant, scalable, secure, integrated, and
687
cloaked zero trust access, Appgate SDP is able to ensure that the correct device and user (under the
688
appropriate conditions at that moment in time) are connected. For more information about Appgate
689
SDP, see https://www.appgate.com/zero-trust-network-access/how-it-works.
690
3.4.3 AWS
691
AWS provides a platform in the cloud that hosts private and public sector agencies in most countries
692
around the world. AWS offers more than 200 services which include compute, storage, networking,
693
database, analytics, application services, deployment, management, developer, mobile, IoT, artificial
694
intelligence (AI), security, and hybrid and enterprise applications. Additionally, AWS provides several
695
security-related services and features such as Identity and Access Management (IAM), Virtual Private
696
Cloud (VPC), PrivateLink, and Security Hub, allowing AWS customers to build and deliver their services
697
worldwide with a high degree of confidence and assurance. AWS’s array of third-party applications
698
provides complementary functionality that further extends the capabilities of the AWS environment. To
699
learn more about security services and compliance on AWS, please visit:
700
https://aws.amazon.com/products/security.
701
The following subsections briefly list some AWS services relevant to ZTA that are being provided in
702
support of this project, organized by category of service.
703
3.4.3.1 Identity
704
IAM: AWS Identity and Access Management (IAM) provides fine-grained access control across all of
705
AWS. With IAM, organizations can specify who can access which services and resources, and under
706
which conditions. With IAM policies, organizations manage permissions to their workforce and systems
707
to ensure least-privilege permissions.
708
Cognito: Amazon Cognito lets organizations add user sign-up, sign-in, and access control to web and
709
mobile apps quickly and easily. Cognito scales to millions of users and supports sign-in with social
710
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 13
identity providers, such as Apple, Facebook, Google, and Amazon, and enterprise identity providers via
711
Security Assertion Markup Language (SAML) 2.0 and OpenID Connect.
712
3.4.3.2 Network/Network Security
713
VPC: Amazon Virtual Private Cloud (Amazon VPC) gives organizations full control over their virtual
714
networking environment, including resource placement, connectivity, and security. A couple of key
715
security features found in VPCs are network access control lists (ACLs) that act as firewalls for controlling
716
traffic in and out of subnets, and security groups that act as host-based firewalls for controlling traffic to
717
individual Amazon Elastic Compute Cloud (Amazon EC2) instances.
718
PrivateLink: AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-
719
premises networks without exposing traffic to the public internet. AWS PrivateLink makes it easy to
720
connect services across different accounts and VPCs to significantly simplify network architecture.
721
Network Firewall: AWS Network Firewall is a managed service that makes it easy to deploy essential
722
network protections for all of an organization’s Amazon VPCs.
723
Web Application Firewall: AWS WAF is a web application firewall (WAF) that helps protect web
724
applications and APIs against common web exploits and bots that may affect availability, compromise
725
security, or consume excessive resources.
726
Route 53: Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web
727
service. It is designed to give developers and businesses an extremely reliable and cost-effective way to
728
route end users to internet applications. Amazon Route 53 is fully compliant with IPv6 as well. With
729
Route 53 Resolver an organization can filter and regulate outbound DNS traffic for its VPC.
730
3.4.3.3 Compute
731
EC2: Amazon EC2 is a web service that provides secure, resizable compute capacity in the cloud. It is
732
designed to make web-scale cloud computing easier for developers.
733
ECS: Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service
734
that makes it easy to deploy, manage, and scale containerized applications.
735
EKS: Amazon Elastic Kubernetes Service (Amazon EKS) is a managed container service to run and scale
736
Kubernetes applications in the cloud or on-premises.
737
3.4.3.4 Storage
738
EBS: Amazon Elastic Block Store (Amazon EBS) is an easy-to-use, scalable, high-performance block-
739
storage service designed for Amazon EC2.
740
S3: Amazon Simple Storage Service (Amazon S3) is an object storage service that offers scalability, data
741
availability, security, and performance.
742
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 14
3.4.3.5 Management/Monitoring
743
Systems Manager: AWS Systems Manager is the operations hub for AWS applications and resources,
744
and it is broken into four core feature groups: Operations Management, Application Management,
745
Change Management, and Node Management.
746
Security Hub: AWS Security Hub is a cloud security posture management service that performs security
747
best practice checks, aggregates alerts, and enables automated remediation.
748
CloudWatch: Amazon CloudWatch is a monitoring and observability service built for DevOps engineers,
749
developers, site reliability engineers (SREs), IT managers, and product owners. CloudWatch provides
750
data and actionable insights to monitor applications, respond to system-wide performance changes, and
751
optimize resource utilization.
752
CloudTrail: AWS CloudTrail monitors and records account activity across AWS infrastructures, giving
753
organizations control over storage, analysis, and remediation actions.
754
GuardDuty: Amazon GuardDuty is a threat detection service that continuously monitors AWS accounts
755
and workloads for malicious activity and delivers detailed security findings for visibility and remediation.
756
Firewall Manager: AWS Firewall Manager is a security management service which allows organizations
757
to centrally configure and manage firewall rules across their accounts and applications in AWS
758
Organizations.
759
3.4.4 Broadcom Software
760
Broadcom Software provides business-critical software designed to modernize, optimize, and protect
761
complex hybrid environments. As part of Broadcom Software, the Symantec Enterprise business invests
762
more than 20% of revenue into research and development (R&D), enabling it to innovate across its
763
cybersecurity portfolio and deliver new functionality that delivers both effective zero trust security and
764
an exceptional user experience. With more than 80% of its workforce dedicated to R&D and operations,
765
Broadcom Software’s engineering-centered culture supports a comprehensive portfolio of enterprise
766
software, enabling scalability, agility, and security for organizations. For more information, go to
767
https://software.broadcom.com/.
768
3.4.4.1 Web Security Service with Advanced Malware Analysis
769
Symantec Web Security Service (WSS), built upon secure web gateway (SWG) technology, is a cloud-
770
delivered network security service that offers protection against advanced threats, provides access
771
control, and safeguards critical business information for secure and compliant use of cloud applications
772
and the web.
773
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 15
3.4.4.2 Web Isolation
774
Web Isolation enables safe web browsing that protects against malware and phishing threats, even
775
when inadvertently visiting uncategorized and risky websites. Remotely executing web sessions in a
776
secured container stops malware downloads, and read-only browsing defeats phishing attacks. Available
777
as a cloud service or an on-premises virtual appliance, Web Isolation can be standalone or integrated
778
with a proxy or email security solution.
779
3.4.4.3 CASB with Data Loss Prevention (DLP)
780
Cloud Access Security Broker (CASB) identifies all cloud apps in use, enforces cloud application
781
management policies, detects and blocks unusual behavior, and integrates with other Symantec
782
solutions, including ProxySG, Data Loss Prevention (DLP), Validation and ID Protection (VIP)
783
Authentication Service, Secure Access Cloud, and Email Security.cloud, to extend network security
784
policies to the cloud. The integration with DLP consistently extends data compliance policies to over 100
785
Software as a Service (SaaS) cloud apps and automates policy sync with cloud properties. Additional APIs
786
for AWS and Azure also provide visibility and control of the management plane, along with cloud
787
workload assurance for discovering new cloud deployments and monitoring them for critical
788
misconfigurations.
789
3.4.4.4 Secure Access Cloud
790
Secure Access Cloud is a cloud-delivered service providing highly secure zero trust network access for
791
enterprise applications deployed in Infrastructure as a Service (IaaS) clouds or on-premises data center
792
environments. This SaaS platform eliminates inbound connections to a network, creates an SDP
793
between users and corporate applications, and establishes application-level access. This service avoids
794
the management complexity and security limitations of traditional remote access tools, ensuring that all
795
corporate applications and services are completely cloaked—invisible to attackers targeting
796
applications, firewalls, and virtual private networks (VPNs).
797
3.4.4.5 Information Centric Analytics (ICA), part of Data Loss Prevention
798
User and entity behavior analytics is a vital tool to reduce user-based risk. Using it, customers can
799
identify anomalous or suspicious activity to help discover potential insider threats and data exfiltration.
800
It builds behavior profiles of users and entities so high-risk accounts can be investigated. Wider risk
801
context is available when security event telemetry is correlated from many data sources, including DLP,
802
Endpoint Protection, and ProxySG.
803
3.4.4.6 Symantec Endpoint Security Complete, including Endpoint Detection and
804
Response (EDR) and Mobile Security
805
Symantec’s endpoint security offering delivers protection, detection, and response in a single solution.
806
Symantec Endpoint Security Complete addresses threats along the entire attack chain. It protects all
807
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 16
endpoints (workstations, servers, iOS and Android mobile phones and tablets) across all major operating
808
systems, is easy to deploy with a single-agent installation, and provides flexible management options
809
(cloud, on-premises, and hybrid).
810
3.4.4.7 VIP Authentication Service
811
VIP is a secure, reliable, and scalable authentication service that provides risk-based and multi-factor
812
authentication (MFA) for all types of users. Risk-based authentication transparently collects data and
813
assesses risk using a variety of attributes such as device identification, geolocation, user behavior, and
814
threat information from the Symantec Global Intelligence Network (GIN). VIP provides MFA using a
815
broad range of authenticators such as push, Short Message Service (SMS) or voice one-time password
816
(OTP), Fast Identity Online (FIDO) Universal 2
nd
Factor (U2F), and fingerprint biometric. This intelligent,
817
layered security approach prevents inappropriate access and online identity fraud without impacting the
818
user experience. VIP also denies access to compromised devices before they can attempt authentication
819
to the network and tracks advanced and persistent threats. An intuitive credential provisioning portal
820
enables self-service that reduces help desk and administrator costs. An integration with Symantec
821
CloudSOC protects against risky behavior even after application login.
822
3.4.4.8 VIP Authentication Hub
823
Authentication Hub is a highly scalable authentication engine that meets zero trust needs by providing
824
phishing-resistant authentication using FIDO2 as well as other multi-factor options, combined with a
825
highly flexible authentication policy model. It includes risk assessment to enable context-sensitive
826
authentication branching. The microservice architecture is built API-first for broad deployment and
827
integration options, and it integrates out of the box with Broadcom’s IAM portfolio.
828
3.4.4.9 Privileged Access Management
829
Privileged Access Management can minimize the risk of data breaches by continually protecting
830
sensitive administrative credentials, controlling privileged user access, and monitoring and recording
831
privileged user activity.
832
3.4.4.10 Security Analytics
833
Security Analytics is an advanced network traffic analysis (NTA) and forensics solution that performs full-
834
packet capture to provide complete network security visibility, anomaly detection, and real-time
835
content inspection for all network traffic to help detect and resolve security incidents more quickly and
836
thoroughly.
837
3.4.4.11 SiteMinder
838
While providing the convenience of a single sign-on experience, SiteMinder was built from the ground
839
up using zero trust principles. Every individual resource that is accessed via SiteMinder is only reached
840
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 17
once SiteMinder determines if the resource is sufficiently protected, if the user is authenticated, and if
841
the user has authorization to the specific resource. This zero trust approach is applied across all resource
842
access methods (e.g., traditional HTTP, SAML, WS-Federation, OpenID Connect [OIDC], Open
843
Authorization [OAuth]). SiteMinder is deployed in extremely high-performance critical-path business
844
environments. It supports a range of authenticators and in combination with VIP offerings (noted above)
845
provides capabilities to meet the most challenging use cases.
846
3.4.4.12 Identity Governance and Administration (IGA)
847
Having a comprehensive ability to manage the lifecycle of user accounts across on-premises and cloud
848
environments is an essential element of a zero trust infrastructure. Symantec IGA delivers
849
comprehensive access governance and management capabilities through an easy-to-use, business-
850
oriented interface. Broad provisioning support for on-premises and cloud apps enables you to automate
851
the granting of new entitlements and removal of unnecessary ones from users throughout the identity
852
lifecycle. Finally, access governance streamlines and simplifies the processes associated with reviewing
853
and approving entitlements, helping ensure a 360-degree view of user entitlements and improving your
854
adherence to zero trust principles.
855
3.4.5 Cisco
856
Cisco Systems, or Cisco, delivers collaboration, enterprise, and industrial networking and security
857
solutions. The company’s cybersecurity team, Cisco Secure, is one of the largest cloud and network
858
security providers in the world. Cisco’s Talos Intelligence Group, the largest commercial threat
859
intelligence team in the world, is comprised of world-class threat researchers, analysts, and engineers,
860
and supported by unrivaled telemetry and sophisticated systems. The group feeds rapid and actionable
861
threat intelligence to Cisco customers, products, and services to help identify new threats quickly and
862
defend against them. Cisco solutions are built to work together and integrate into your environment,
863
using the “network as a sensor” and “network as an enforcer” approach to both make your team more
864
efficient and keep your enterprise secure. Learn more about Cisco at https://www.cisco.com/go/secure.
865
3.4.5.1 Cisco Secure Access by Duo
866
Duo is a PE, PA, and PEP for users and their devices. It delivers simple, safe access to all applications —
867
on-premises or in the cloud — for any user, device, or location. It makes it easy to effectively implement
868
and enforce security policies and processes, using strong authentication to reduce the risk of data
869
breaches due to compromised credentials and access from unauthorized devices.
870
3.4.5.2 Cisco Identity Services Engine (ISE)
871
Cisco ISE is a network central PDP that includes both the PE and PA to help organizations provide secure
872
access to users, their devices, and the non-user devices in their network environment. It simplifies the
873
delivery of consistent and secure access control to PEPs across wired and wireless multi-vendor
874
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 18
networks, as well as remote VPN connections. It controls switches, routers, and other network devices
875
as PEPs, enabling granular control of every connection down to the individual port, delivering a dynamic,
876
granular, and automated approach to policy enforcement that simplifies the delivery of highly secure,
877
microsegmented network access control. ISE is tightly integrated with and enhances network and
878
security devices, allowing it to transform the network from a simple conduit for data into an intuitive
879
and adaptive security sensor and enforcer that acts to accelerate the time to detection and time to
880
resolution of network threats.
881
3.4.5.3 Cisco Secure Endpoint (formerly AMP)
882
Cisco Secure Endpoint addresses the full life cycle of the advanced malware problem before, during, and
883
after an attack. It uses global threat intelligence to strengthen defenses, antivirus to block known
884
malware, and static and dynamic file analysis to detect emerging malware, continuously monitoring file
885
and system activity for emerging threats. When something new is detected, the solution provides a
886
retrospective alert with the full recorded history of the file back to the point of entry, and the rich
887
contextual information needed during a potential breach investigation to both prioritize remediation
888
and create response plans.
889
As a policy input point, Secure Endpoint delivers deep visibility, context, and control to rapidly detect,
890
contain, and remediate advanced threats if they evade front-line defenses. It can also eliminate malware
891
with a few clicks and provide a cost-effective security solution without affecting operational efficiency.
892
3.4.5.4 Cisco Firepower Threat Defense (FTD)
893
Cisco FTD is a threat-focused, next-generation firewall with unified management. It provides advanced
894
threat protection before, during, and after attacks. By delivering comprehensive, unified policy
895
management of firewall functions, application control, threat prevention, and advanced malware
896
protection, from network to endpoint, it increases visibility and security posture while reducing risk.
897
3.4.5.5 Cisco Secure Network Analytics (formerly Stealthwatch)
898
Cisco Secure Network Analytics aggregates and analyzes network telemetry — information generated by
899
network devices — to turn the network into a sensor. As a policy input point, it provides enterprise-wide
900
network visibility and applies advanced security analytics to detect and respond to threats in real time. It
901
delivers end-to-end network visibility on-premises, in private clouds, and in public clouds. Secure
902
Network Analytics detects a wide range of network and data center issues ranging from command-and-
903
control (C&C) attacks to ransomware, from distributed denial of service (DDoS) attacks to illicit
904
cryptomining, and from malware to insider threats.
905
Secure Network Analytics can be deployed on-premises as a hardware appliance or virtual machine
906
(VM), or cloud-delivered as a SaaS solution. It works with the entire Cisco router and switch portfolio as
907
well as a wide variety of other security solutions.
908
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 19
3.4.5.6 Cisco Encrypted Traffic Analytics (ETA)
909
Cisco ETA helps illuminate the dark corners of encrypted traffic without decryption by using new types
910
of data elements and enhanced NetFlow telemetry independent of protocol details. Cisco ETA can help
911
detect malicious activity in encrypted traffic by applying advanced security analytics. At the same time,
912
the integrity of the encrypted traffic is maintained because there is no need for bulk decryption.
913
3.4.5.7 Cisco SecureX
914
Cisco SecureX is an extended detection and response (XDR) cloud-native integrated threat response
915
platform within the Cisco Secure portfolio. Its open, extensible integrations connect to the
916
infrastructure, providing unified visibility and simplicity in one location. It maximizes operational
917
efficiency to secure the network, users and endpoints, cloud edge, and applications. Cisco SecureX
918
radically reduces the dwell time and human-powered tasks involved with detecting, investigating, and
919
remediating threats to counter attacks, or securing access and managing policy to stay compliant. The
920
time savings and better collaboration involved with orchestrating and automating security across
921
SecOps, ITOps, and NetOps teams help advance the security maturity level.
922
3.4.5.8 Cisco Endpoint Security Analytics (CESA)
923
Cisco Endpoint Security Analytics (CESA) analyzes endpoint telemetry generated by the Network
924
Visibility Module (NVM), which is built into the Cisco AnyConnect® Secure Mobility Client. CESA feeds
925
Splunk Enterprise software to analyze NVM data provided by endpoints to uncover endpoint-specific
926
security risks and breaches. This data includes information about data loss, unapproved applications and
927
SaaS usage, security evasion, unknown malware, user behavior when not connected to the enterprise,
928
endpoint asset inventory, and destination allowlists and denylists.
929
3.4.5.9 Cisco AnyConnect Secure Mobility Client
930
Cisco AnyConnect Secure Mobility Client is a unified endpoint software client compatible with several of
931
today’s major enterprise mobility platforms. It helps manage the security risks associated with extended
932
networks. Built on foundational VPN technology, it extends beyond remote-access capabilities to offer
933
user-friendly, network-based security including:
934
▪ Simple and context-aware security policy enforcement
935
▪ An uninterrupted, intelligent, always-on security connection to remote devices
936
▪ Visibility into network and device-user behavior
937
▪ Web inspection technology to defend against compromised websites
938
3.4.5.10 Cisco Network Devices
939
Cisco network devices do more than move packets on the network; they provide a platform to improve
940
user experience, unify management, automate tasks, analyze activity, and enhance security across the
941
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 20
enterprise. In a zero-trust environment, Cisco switches, routers, and other devices provide continuous
942
visibility using the “network as a sensor” to monitor network activity, reporting 100% of NetFlow and
943
other metadata. These devices act as PEPs utilizing a “network as an enforcer” approach to
944
microsegment network access control to each port and enable dynamic and automated policy
945
enforcement. This policy enforcement simplifies the delivery of highly secure control across
946
environments.
947
3.4.5.11 Cisco Secure Workload (CSW—formerly Tetration)
948
Today’s networks include applications running in a hybrid multi-cloud environment that uses bare-
949
metal, virtualized, cloud-based and container-based workloads. A key challenge is how to better secure
950
applications and data without compromising agility. Cisco Secure Workload (formerly known as Cisco
951
Tetration) is designed to address this security challenge by providing comprehensive workload
952
protection by bringing security closer to applications and tailoring the security posture based on the
953
application behavior. Secure Workload achieves this by using advanced machine learning and behavior
954
analysis techniques. This platform provides a ready-to-use solution to support the following security use
955
cases:
956
▪ Microsegmentation policies that allow implementation of a zero trust model: It enforces policies
957
that allow only the traffic required for business purposes
958
▪ Behavioral baselining, analysis, and identifying anomalies on the workloads
959
▪ Detection of common vulnerabilities and exposures associated with the software packages
960
installed on the resources
961
▪ Enforcement of policies that proactively quarantine servers when vulnerabilities are detected,
962
blocking communication
963
3.4.6 DigiCert
964
DigiCert is a global provider of digital trust, enabling individuals and businesses to engage online with
965
the confidence that their footprint in the digital world is secure. DigiCert® ONE, the platform for digital
966
trust, provides organizations with centralized visibility and control over a broad range of public and
967
private trust needs, securing websites, enterprise access and communication, software, identity,
968
content, and devices. For more information, visit digicert.com.
969
3.4.6.1 DigiCert CertCentral TLS Manager
970
DigiCert CertCentral is used to provision publicly trusted Transport Layer Security (TLS) server
971
authentication certificates. CertCentral relies on DigiCert’s publicly trusted root certificates with
972
excellent ubiquity to provide the necessary interoperability with the widest range of third-party
973
products.
974
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 21
3.4.6.2 DigiCert Enterprise PKI Manager
975
DigiCert Enterprise PKI Manager is a digital certificate management solution for enterprise identity and
976
access public key infrastructure (PKI) use cases. Enterprise PKI Manager simplifies and streamlines
977
certificate lifecycle management for identity and access of users, devices, and applications, supporting a
978
broad array of certificate types with automated workflows, preconfigured templates, multiple
979
enrollment and authentication methods, and a rich ecosystem of integrated technology partners. It is
980
part of the DigiCert family of products delivering digital trust solutions. Enterprise PKI Manager is built
981
on DigiCert ONE’s modern, containerized architecture, delivering scalability capable of serving high
982
volumes of certificates, supporting flexible deployment in cloud, on-premises, or hybrid deployment
983
models, and enabling dynamic and rapid intermediate Certificate Authority (ICA) creation to meet the
984
diverse needs of different business groups.
985
3.4.7 F5
986
F5 empowers its customers to create, secure, and operate applications that deliver extraordinary digital
987
experiences. Fueled by automation and AI-driven insights, these applications will naturally adapt based
988
on their changing environment—so companies can focus on their core business, boost speed to market,
989
improve operations, and build trust with their customers. By enabling these adaptive applications, F5
990
with NGINX and F5 Distributed Cloud Services technologies offers a comprehensive suite of solutions for
991
every digital organization.
992
3.4.7.1 BIG-IP Product Family
993
The BIG-IP product family provides full proxy security, application intelligence, and scalability for
994
application traffic. As the amount of traffic grows or shrinks, BIG-IP can be adjusted or it can request
995
addition or removal of application servers. It provides rich application traffic programmability to further
996
enhance application security and application traffic steering requirements. In addition, BIG-IP’s rich
997
control plane programmability allows for integrations into on-premises orchestration engines, cloud
998
automation/orchestration, and continuous integration/continuous delivery (CI/CD) pipelines, and the
999
ability to deliver application security in a DevSecOps manner. All capabilities can be propagated as
1000
common policy throughout the enterprise regardless of whether an organization utilizes F5 hardware or
1001
a virtualized on-premises or cloud environment.
1002
BIG-IP modules provide the ability to layer on additional capabilities. The modules being considered for
1003
this project are discussed in the subsections below.
1004
3.4.7.1.1 BIG-IP Local Traffic Manager (LTM)
1005
BIG-IP LTM is an enterprise-class load balancer providing granular layer 7 control, Secure Sockets Layer
1006
(SSL) offloading, and acceleration capabilities. It allows for massive scaling of traditional and modern
1007
apps across the enterprise and provides visibility into TLS-encrypted streams, TLS security enforcement,
1008
and Federal Information Processing Standards (FIPS) certified cryptography [9].
1009
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 22
3.4.7.1.2 BIG-IP Access Policy Manager (APM)
1010
BIG-IP APM integrates and unifies secure user access to ensure the correct people have the correct
1011
access to the correct applications—anytime, anywhere, providing the ability to authenticate users into
1012
applications allowing for granular application access control and zero trust capabilities across the
1013
application landscape. BIG-IP APM sits in front of applications and APIs to enforce application
1014
authentication and access control for each user as part of zero trust.
1015
3.4.7.1.3 BIG-IP Web Application Firewall (WAF)
1016
BIG-IP WAF provides the flexibility to deploy WAF services closer to the apps so they’re protected
1017
wherever they reside. It has the ability to virtually patch applications for security vulnerabilities such as
1018
the latest Common Vulnerabilities and Exposures (CVE) entry without application code changes. It also
1019
reduces unwanted application traffic, allowing the application to be more responsive to its intended
1020
users while providing complete visibility into the application traffic. WAF provides API security,
1021
protecting against web application security concerns. WAF provides secure communication and vetting
1022
of traffic to APIs and applications.
1023
3.4.7.2 NGINX Product Family
1024
NGINX is a cloud-native, easy-to-use reverse proxy, load balancer, and API gateway. It integrates
1025
advanced monitoring, strengthens security controls, and orchestrates Kubernetes containers.
1026
3.4.7.2.1 NGINX Ingress Controller
1027
NGINX Ingress Controller combines software load balancing with simplified configuration based on
1028
standard Kubernetes Ingress resources or custom NGINX Ingress resources to ensure that applications in
1029
a Kubernetes cluster are delivered reliably, securely, and at high velocity. It provides security to
1030
Kubernetes-based microservices and APIs using API gateway and WAF capabilities. The Ingress
1031
Controller protects application and API containers in the Kubernetes environment by enforcing security
1032
on all traffic entering the Kubernetes node.
1033
3.4.7.2.2 NGINX Plus
1034
NGINX Plus is an all-in-one load balancer, web server, content cache, WAF, and API gateway. NGINX Plus
1035
is built on NGINX Open Source. It is intended to reduce complexity and simplify management by
1036
consolidating several capabilities, including reverse proxy and TLS termination, into a single elastic
1037
ingress/egress tier. It acts as a webserver to server applications that are secured by the system’s zero
1038
trust capabilities.
1039
3.4.7.2.3 NGINX Service Mesh
1040
NGINX Service Mesh scales from open-source projects to a fully supported, secure, and scalable
1041
enterprise-grade solution. It provides a turnkey service-to-service solution featuring a unified data plane
1042
for ingress and egress Kubernetes management in a single configuration. NGINX Service Mesh provides
1043
for mutual TLS authentication (mTLS) enforcement, rate limiting, quality of service (QoS), and an API
1044
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 23
gateway to enforce security at each pod, securing pods from both north/south (N/S) and east/west
1045
(E/W) traffic and allowing for zero trust enforcement for all pod traffic.
1046
3.4.8 Forescout
1047
Forescout delivers automated cybersecurity across the digital terrain. It empowers its customers to
1048
achieve continuous alignment of their security frameworks with their digital realities, across all asset
1049
types – IT, IoT, OT, and Internet of Medical Things (IoMT). Forescout enables organizations to manage
1050
cyber risk through automation and data-powered insights.
1051
The Forescout Platform provides complete asset visibility of connected devices, continuous compliance,
1052
network segmentation, network access control, and a strong foundation for zero trust. Forescout
1053
customers gain data-powered intelligence to accurately detect risks and quickly remediate cyberthreats
1054
without disruption of critical business assets. https://www.forescout.com/company/
1055
3.4.8.1 Forescout eyeSight
1056
Forescout eyeSight delivers comprehensive device visibility across an organization’s entire digital terrain
1057
– without disrupting critical business processes. It discovers every IP-connected device, auto-classifies it,
1058
and assesses its compliance posture and risk the instant the device connects to the network.
1059
https://www.forescout.com/products/eyesight/
1060
3.4.8.2 Forescout eyeControl
1061
Forescout eyeControl provides flexible and frictionless network access control for heterogeneous
1062
enterprise networks. It enforces and automates zero trust security policies for least-privilege access on
1063
all managed and unmanaged assets across an organization’s digital terrain. Policy-based controls can
1064
continuously enforce asset compliance, proactively reduce attack surfaces, and rapidly respond to
1065
incidents. https://www.forescout.com/products/eyecontrol/
1066
3.4.8.3 Forescout eyeSegment
1067
Forescout eyeSegment accelerates zero trust segmentation. It simplifies the design, planning, and
1068
deployment of non-disruptive, dynamic segmentation across an organization’s digital terrain to reduce
1069
attack surface and regulatory risk. https://www.forescout.com/products/eyesegment/
1070
3.4.8.4 Forescout eyeExtend
1071
Forescout eyeExtend automates security workflows across disparate products. It shares device context
1072
between the Forescout platform and other IT and security products, automates policy enforcement
1073
across disparate tools, and accelerates system-wide response to mitigate risks.
1074
https://www.forescout.com/products/eyeextend/
1075
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 24
3.4.9 Google Cloud
1076
Google Cloud brings the best of Google’s innovative products and services to enable enterprises of all
1077
sizes to create new user experiences, transform their operations, and operate more efficiently. Google’s
1078
mission is to accelerate every organization’s ability to digitally transform its business with the best
1079
infrastructure, platform, industry solutions, and expertise. Google Cloud helps customers protect their
1080
data using the same infrastructure and security services Google uses for its own operations, defending
1081
against the toughest threats. Google pioneered the zero trust model at the core of its services and
1082
operations, and it enables its customers to do the same with its broad portfolio of solutions. Learn more
1083
about Google Cloud at https://cloud.google.com/.
1084
3.4.9.1 BeyondCorp Enterprise (BCE)
1085
BeyondCorp Enterprise (BCE) is a zero trust solution, built on the Google platform and global network,
1086
which provides customers with simple and secure access to applications and cloud resources and offers
1087
integrated threat and data protection. It leverages the Chrome Browser and the Google Cloud platform
1088
(GCP) to protect and proxy traffic from an organization’s network. It allows customers to enforce
1089
context-aware policies (using factors such as identity, device posturing, and other signal information) to
1090
authorize access to SaaS applications and resources hosted on Google Cloud, third-party clouds, or on-
1091
premises. This solution is built from Google’s own approach of shifting access controls from the network
1092
perimeter to individual users and devices, allowing for secure access without the need for a VPN.
1093
BCE key capabilities include:
1094
▪ Zero trust access
1095
• Context-aware access proxy (identity-aware proxy): Globally deployed proxy built on the
1096
GCP that leverages identity, device, and contextual information to apply continuous
1097
authorization access decisions to applications and VMs in real-time in the GCP, other
1098
clouds, or on-premises data centers.
1099
• Browser-based application access: Agentless zero trust access, using Chrome or other
1100
browsers, to browser-based apps hosted on the GCP, other clouds (e.g., AWS, Azure), or
1101
on-premises data centers.
1102
• Legacy client application access (client connector): Extension that enables zero trust
1103
access to non-HTTP, thick-client apps hosted in the GCP, other clouds, or on-premises data
1104
centers.
1105
▪ Protections
1106
• Data protection: Built-in Chrome browser capabilities to detect and prevent sensitive data
1107
loss, stop pasting of protected content in and out of the browser, prevent accidental and
1108
intentional exfiltration of corporate data, and enforce data protection policies across
1109
applications.
1110
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 25
• Threat protection: Built-in Chrome browser capabilities to filter and block harmful or
1111
unauthorized URLs in real-time, identify phishing sites and malicious content in real-time,
1112
stop suspicious files and malware transfers, and protect user credentials and passwords.
1113
▪ Integrations
1114
• BeyondCorp Alliance ecosystem integrations: A collection of integrations from
1115
BeyondCorp Alliance member partners that enable organizations to share signal
1116
information from EDR, MDM, enterprise mobility management (EMM), and other device or
1117
ecosystem endpoints to use in access policy decisions. (Members include Broadcom
1118
Software, Check Point, Citrix, CrowdStrike, Jamf, Lookout, Netskope, Palo Alto Networks,
1119
Tanium, and VMware.)
1120
▪ Network connectivity
1121
• On-premises connector: Private connectivity from Google Cloud to applications outside of
1122
Google Cloud (i.e., hosted by other clouds or on-premises data centers.)
1123
• VPN interconnect: Private connectivity via an Interconnect from Google Cloud to
1124
applications outside of Google Cloud (i.e., hosted by other clouds or on-premises data
1125
centers.)
1126
• App connector: Secure internet-based connectivity from Google Cloud to applications
1127
outside of Google Cloud (i.e., hosted by other clouds or on-premises data centers.)
1128
▪ Platform
1129
• Google Platform: Google’s public cloud computing services including data management,
1130
application development, storage, hybrid & multi-cloud, security, and AI & ML that run on
1131
Google infrastructure.
1132
• Google Network: Google’s global backbone with 146 edge locations in over 200 countries
1133
and territories provides low-latency connections, integrated DDoS protection, elastic
1134
scaling, and private transit.
1135
3.4.10 IBM
1136
International Business Machines Corporation (IBM) is an American multinational technology corporation
1137
headquartered in Armonk, New York, with operations in over 171 countries. IBM produces and sells
1138
computer hardware, middleware, and software, and provides hosting and consulting services in areas
1139
ranging from mainframe computers to nanotechnology. IBM is also a major research organization,
1140
holding the record for most annual U.S. patents generated by a business (as of 2020) for 28 consecutive
1141
years. IBM has a large and diverse portfolio of products and services that range in the categories of
1142
cloud computing, AI, commerce, data and analytics, IoT, IT infrastructure, mobile, digital workplace, and
1143
cybersecurity.
1144
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 26
3.4.10.1 IBM Security Trusteer
1145
IBM Security® Trusteer® solutions help detect fraud, authenticate users, and establish identity trust
1146
across a digital user journey. Trusteer uses cloud-based intelligence, AI, and ML to holistically identify
1147
new and existing users while improving the overall user experience by reducing the friction created with
1148
traditional forms of MFA. Within a ZTA, Trusteer acts as a risk engine that improves the efficacy of policy
1149
decisions enforced by various identity and access management solutions.
1150
3.4.10.2 IBM Security QRadar XDR
1151
IBM Security QRadar® XDR suite provides a single unified workflow across an organization’s security
1152
tools. Built on a unified cross-domain security platform, IBM Cloud Pak® for Security, the open
1153
architecture of QRadar XDR suite enables organizations to integrate their EDR, SIEM, network detection
1154
and response (NDR), security orchestration, automation, and response (SOAR), and threat intelligence
1155
solutions in support of a ZTA.
1156
IBM Security QRadar SIEM helps security teams detect, prioritize, and respond to threats across the
1157
enterprise. As an integral part of an organization’s XDR and zero trust strategies, it automatically
1158
aggregates and analyzes log and flow data from thousands of devices, endpoints, and apps across the
1159
network, providing single, prioritized alerts to speed incident analysis and remediation. QRadar SIEM is
1160
available for on-premises and cloud environments.
1161
IBM Security QRadar SOAR is designed to help security teams respond to cyberthreats with confidence,
1162
automate with intelligence, and collaborate with consistency. It guides a team in resolving incidents by
1163
codifying established incident response processes into dynamic playbooks. The open and agnostic
1164
platform helps accelerate and orchestrate response by automating actions with intelligence and
1165
integrating with other security tools.
1166
IBM Security QRadar XDR Connect is a cloud-native, open XDR solution that saves time by connecting
1167
tools, workflows, insights, and people. The solution adapts to a team’s skills and needs, whether the
1168
user is an analyst looking for streamlined visibility and automated investigations or an experienced
1169
threat hunter looking for advanced threat detection. XDR Connect empowers organizations with tools
1170
that strengthen their zero trust model and enable them to be more productive.
1171
3.4.10.3 IBM Security Verify
1172
Modernized, modular IBM Security Verify provides deep, AI-powered context for both consumer and
1173
workforce identity and access management. It protects users and apps, inside and outside the
1174
enterprise, with a low-friction, cloud-native, SaaS approach. Verify delivers critical features for
1175
supporting a zero trust strategy based on least privilege and continuous verification, including single
1176
sign-on (SSO), multi-factor and passwordless authentication, adaptive access, identity lifecycle
1177
management, and identity analytics.
1178
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 27
3.4.10.4 IBM Security MaaS360
1179
IBM Security MaaS360® with Watson protects devices, apps, content, and data, which allows
1180
organizations to rapidly scale their hybrid workforce and BYOD initiatives. IBM Security MaaS360 can
1181
help build a zero trust strategy with modern device management. And with Watson, organizations can
1182
take advantage of contextual analytics via AI for actionable insights.
1183
3.4.10.5 IBM Security Guardium
1184
IBM Security Guardium® Insights is a data security hub for the modern data source environment. It
1185
builds and automates compliance policy enforcement and streams and centralizes data activity across a
1186
multi-cloud ecosystem. It can apply advanced analytics to uncover data risk insights. Guardium Insights
1187
can complement and enhance existing Guardium Data Protection deployments or be installed on its own
1188
to help solve compliance and cloud data activity monitoring challenges. Built on a unified cross-domain
1189
security platform, IBM Cloud Pak for Security, Guardium Insights can deploy and scale in any data
1190
environment — as well as integrate and share insights with major security tools such as IBM Security
1191
QRadar XDR, Splunk, ServiceNow, and more, in support of a ZTA.
1192
3.4.10.6 IBM Cloud Pak for Security
1193
IBM Cloud Pak for Security is a unified cross-domain security platform that integrates existing security
1194
tools to generate insights into threats across hybrid, multi-cloud environments. It provides organizations
1195
with the ability to track, manage, and resolve cybersecurity incidents and create response plans that are
1196
based on industry standards and best practices.
1197
3.4.11 Ivanti
1198
Ivanti finds, heals, manages, and protects devices regardless of location – automatically. It is an
1199
enterprise software company specializing in endpoint management, network security, risk-based
1200
vulnerability management, and service and asset management. The Ivanti solution is able to discover,
1201
manage, secure, and service all endpoints across the enterprise including corporate/government-owned
1202
and BYOD. Ivanti is actively involved with helping to better prepare government and enterprises with
1203
cybersecurity and zero trust best practices. Learn more about Ivanti here: https://www.ivanti.com/. The
1204
Ivanti solution enables an enterprise to centrally manage/monitor endpoints and trigger adaptive
1205
policies to remediate threats, quarantine devices, and maintain compliance.
1206
3.4.11.1 Ivanti Neurons for Unified Endpoint Management (UEM)
1207
Ivanti Neurons for UEM helps enterprises create a secure workspace on any device with apps,
1208
configurations, and policies for the user based on their role. Users get easy and secure access to the
1209
resources they need for their productivity. For more information, see
1210
https://www.ivanti.com/products/ivanti-neurons-for-mdm.
1211
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 28
The Ivanti Neurons for UEM platform provides the fundamental visibility and IT controls needed to
1212
secure, manage, and monitor any corporate or employee-owned mobile device or desktop that accesses
1213
business-critical data. The Neurons for UEM platform allows organizations to secure a vast range of
1214
employee and BYOD devices being used within the organization while managing the entire life cycle of
1215
the device, including:
1216
▪ Policy configuration management and enforcement
1217
▪ Application distribution and management
1218
▪ Script management and distribution for desktop devices
1219
▪ Automated device actions
1220
▪ Continuous access control and MFA
1221
▪ Threat detection and remediation against device, network application, and phishing attacks
1222
3.4.11.2 Ivanti Sentry
1223
Ivanti Sentry is an in-line intelligent gateway that helps secure access to on-premises resources and
1224
provides authentication and authorization to enterprise data. For more information, see
1225
https://www.ivanti.com/products/secure-connectivity/sentry.
1226
3.4.11.3 Ivanti Access ZSO
1227
Ivanti Access Zero Sign-On (ZSO) enforces risk-based policies to prevent unauthorized users, endpoints,
1228
apps or services from connecting to enterprise cloud services. ZSO helps identify the user, device, app,
1229
location, network type, and presence of threats. The adaptive access control check is the basis of the
1230
zero trust model. ZSO provides a frictionless single sign-on experience to end users leveraging secure
1231
mobile based MFA. The solution is federated with the Okta Identity Cloud to provide continuous
1232
authentication and authorization. For more information, see https://www.ivanti.com/products/zero-
1233
sign-on
1234
3.4.11.4 Ivanti Mobile Threat Defense
1235
The combination of cloud and mobile threat defense (MTD) protects data on-device and on-the-network
1236
with state-of-the-art encryption and threat monitoring to detect and remediate device, network, app-
1237
level, and phishing attacks. For more information, see https://www.ivanti.com/products/mobile-threat-
1238
defense.
1239
3.4.12 Lookout
1240
Lookout is a cybersecurity company focused on securing users, devices, and data as users operate in the
1241
cloud. The Lookout platform helps organizations consolidate IT security, get complete visibility across all
1242
cloud services, and protect sensitive data wherever it goes.
1243
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 29
3.4.12.1 Lookout Mobile Endpoint Security (MES)
1244
Lookout MES is a SaaS-based MTD solution that protects devices from threats and risks via the Lookout
1245
for Work mobile application. Lookout protects Android and Apple mobile devices from malicious or risky
1246
apps, device threats, network threats, and phishing attacks. Lookout attests to the security posture of
1247
the mobile device, which is provided to the policy engine to determine access to a resource. The mobile
1248
asset is continuously monitored by Lookout for any change to its security posture. Lookout protection
1249
can be deployed to managed or unmanaged devices and works on trusted or untrusted networks.
1250
Lookout has integrations with productivity and collaboration solutions, as well as unified endpoint
1251
management solutions.
1252
3.4.13 Mandiant
1253
Mandiant scales its intelligence and expertise through the Mandiant Advantage SaaS platform to deliver
1254
current intelligence, automation of alert investigation, and prioritization and validation of security
1255
control products from a variety of vendors. (http://www.mandiant.com/)
1256
3.4.13.1 Mandiant Security Validation (MSV)
1257
Mandiant Security Validation (MSV), continuously informed by Mandiant frontline intelligence on the
1258
latest attacker tactics, techniques, and procedures (TTPs), automates a testing program that gives real
1259
data on how security controls are performing. This solution provides visibility and evidence on the status
1260
of security controls’ effectiveness against adversary threats targeting organizations and data to optimize
1261
the environment against relevant threats. MSV can provide many benefits to an organization (for
1262
example, identify limitations in current cybersecurity stack, evaluate proposed cybersecurity tools for an
1263
organization, determine overlapping controls, automate assessment actions, and train cybersecurity
1264
operators). To support these use cases, MSV emulates attackers to safely process advanced cyberattack
1265
security content within production environments. It is designed so defenses respond to it as if an attack
1266
is taking place across the most critical areas of the enterprise.
1267
Using the natural design of the Security Validation platform, Mandiant is able to support the project in
1268
testing and documenting the outcome of one of the key tenets of ZTA, “The enterprise monitors and
1269
measures the integrity and security posture of all owned and associated resources.” To do this, the
1270
software produces quantifiable evidence that shows how people, processes, and technologies perform
1271
when specific malicious behaviors are encountered, such as attacks by a specific threat actor or attack
1272
vector.
1273
The core Validation components of the MSV platform are:
1274
▪ The Director - This is the main component of the platform and provides the following
1275
functionality:
1276
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 30
• Acts as the Integration point and content manager for the SIEM and other components of
1277
the security stack
1278
• Hosts the Content Library (Actions, Sequences, Evaluations, and Files) used for testing
1279
security controls
1280
• Manages the Actor assignment during testing
1281
• Aggregates testing results and facilitates report creation
1282
• Maintains connections with the Mandiant Updater and Content Services, allowing updates
1283
to be received automatically for the platform and its content
1284
▪ Actors (also referred to as flex, Endpoint, and Network Actors) - The components that safely
1285
perform tests in production environments. Specifically, use these to verify the configuration and
1286
test the effectiveness of network security controls; Windows, Mac, and Linux endpoint controls;
1287
and email controls.
1288
▪ Cloud controls
1289
▪ Policy compliance
1290
The Director is the component that receives the information from the systems in the environment based
1291
on an integration with a SIEM and/or directly with the security appliance itself. Tests are run between
1292
Actors and not directly on systems in the environment.
1293
3.4.14 Microsoft
1294
Microsoft Security brings together the capabilities of security, compliance, identity, and management to
1295
natively integrate individual layers of protection across clouds, platforms, endpoints, and devices.
1296
Microsoft Security helps reduce the risk of data breaches and compliance violations and improve
1297
productivity by providing the necessary coverage to enable zero trust. Microsoft’s security products give
1298
IT leaders the tools to confidently help their organization digitally transform with Microsoft’s protection
1299
across their entire environment.
1300
3.4.14.1 Azure
1301
Microsoft Azure is Microsoft's public cloud computing platform. It provides a range of cloud services,
1302
including compute, analytics, storage, and networking.
1303
3.4.14.2 Azure Active Directory (Azure AD)
1304
Azure AD is an IAM/identity as a service (IDaaS) product from Microsoft that performs ICAM
1305
management, authentication (both SSO and MFA), authorization, federation, and governance, and also
1306
functions as a PE, PA, and PEP.
1307
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 31
3.4.14.3 Microsoft Intune – Device Management
1308
In Intune, devices are managed using an approach that’s suitable for the organization. For organization-
1309
owned devices, an organization may want full control over the devices, including settings, features, and
1310
security. In this approach, devices and users of these devices “enroll” in Intune. Once enrolled, they
1311
receive the organization’s rules and settings through policies configured in Intune. For example,
1312
organizations can set password and PIN requirements, create a VPN connection, set up threat
1313
protection, and more.
1314
3.4.14.4 Microsoft Intune – Application Management
1315
Microsoft Intune provides mobile application management (MAM), which is designed to protect
1316
organization data at the application level, including custom apps and store apps. App management can
1317
be used on organization-owned devices and personal devices. When apps are managed in Intune,
1318
administrators can:
1319
▪ add and assign mobile apps to user groups and devices, including users in specific groups,
1320
devices in specific groups, and more;
1321
▪ configure apps to start or run with specific settings enabled and update existing apps already on
1322
the device;
1323
▪ see reports on which apps are used and track their usage; and
1324
▪ do a selective wipe by removing only organization data from apps.
1325
3.4.14.5 Microsoft Defender for Endpoint
1326
Microsoft Defender for Endpoint is an enterprise endpoint security platform designed to help enterprise
1327
networks prevent, detect, investigate, and respond to advanced threats.
1328
3.4.14.6 Microsoft Sentinel
1329
Microsoft Sentinel is a scalable, cloud-native solution for SIEM. It was previously known as Azure
1330
Sentinel.
1331
3.4.14.7 Microsoft Defender for Identity
1332
Microsoft Defender for Identity (formerly Azure Advanced Threat Protection, also known as Azure ATP)
1333
is a cloud-based security solution that leverages an organization’s on-premises AD signals to identify,
1334
detect, and investigate advanced threats, compromised identities, and malicious insider actions directed
1335
at the organization. Defender for Identity enables SecOps analysts and security professionals struggling
1336
to detect advanced attacks in hybrid environments to:
1337
▪ monitor users, entity behavior, and activities with learning-based analytics;
1338
▪ protect user identities and credentials stored in AD;
1339
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 32
▪ identify and investigate suspicious user activities and advanced attacks throughout the kill chain;
1340
and
1341
▪ provide clear incident information on a simple timeline for fast triage.
1342
3.4.14.8 Azure AD Identity Protection
1343
Identity Protection, which is part of Azure AD, is a tool that allows organizations to accomplish three key
1344
tasks:
1345
▪ automate the detection and remediation of identity-based risks;
1346
▪ investigate risks using data in the portal; and
1347
▪ export risk detection data to the SIEM.
1348
Identity Protection uses the learnings Microsoft has acquired from its position in organizations with
1349
Azure AD, in the consumer space with Microsoft Accounts, and in gaming with Xbox to protect users.
1350
Microsoft analyses 6.5 trillion signals per day to identify and protect customers from threats.
1351
The signals generated by and fed to Identity Protection can be further fed into tools like Conditional
1352
Access to make access decisions or fed back to a SIEM tool for further investigation based on an
1353
organization’s enforced policies.
1354
3.4.14.9 Microsoft Defender for Office 365 (for email)
1355
Microsoft Defender for Office 365 (for email) prevents broad, volume-based, known attacks. It protects
1356
email and collaboration from zero-day malware, phishing, and business email compromise. It also adds
1357
post-breach investigation, hunting, and response, as well as automation and simulation (for training).
1358
3.4.14.10 Azure App Proxy & Intune VPN Tunnel
1359
Azure Active Directory Application Proxy provides secure remote access and cloud-scale security to an
1360
organization’s private applications.
1361
Microsoft Tunnel is a VPN gateway solution for Microsoft Intune that runs in a container on Linux and
1362
allows access to on-premises resources from iOS/iPadOS and Android Enterprise devices using modern
1363
authentication and conditional access.
1364
3.4.14.11 Secure Admin Workstation (SAW)
1365
Secure Admin Workstations are limited-use client computers—built on Windows 10—that help protect
1366
high-risk environments from security risks such as malware, phishing, and pass-the-hash attacks. They
1367
provide secure access to restricted environments.
1368
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 33
3.4.14.12 Windows 365 for Enterprise and Azure Virtual Desktop
1369
Windows 365 for Enterprise is a cloud-based service that automatically creates a new type of Windows
1370
virtual machine (Cloud PCs) for your end users that provides the productivity, security, and collaboration
1371
benefits of Microsoft 365.
1372
Azure Virtual Desktop is a desktop and app virtualization service that runs on the cloud.
1373
For this project, Microsoft 365 for Enterprise and Azure Virtual Desktop can both be used to show how
1374
to secure virtual desktop infrastructure (VDI).
1375
3.4.14.13 Microsoft Defender for Cloud
1376
Defender for Cloud is a tool for security posture management and threat protection. It strengthens the
1377
security posture of an organization’s cloud resources, and with its integrated Microsoft Defender plans,
1378
Defender for Cloud protects workloads running in Azure, hybrid, and other cloud platforms. Because it’s
1379
natively integrated, deployment of Defender for Cloud is easy, providing an organization with simple
1380
auto provisioning to secure its resources by default.
1381
3.4.14.14 Microsoft Purview
1382
Microsoft Purview is a unified data governance service that helps organizations manage and govern
1383
their on-premises, multi-cloud, and SaaS data. It creates a holistic, up-to-date map of an organization’s
1384
data landscape with automated data discovery, sensitive data classification, and end-to-end data
1385
lineage, enabling data curators to manage and secure the organization’s data estate. It also empowers
1386
data consumers to find valuable, trustworthy data.
1387
3.4.14.15 Microsoft Defender for Cloud Apps
1388
Microsoft Defender for Cloud Apps is a CASB that supports various deployment modes, including log
1389
collection, API connectors, and reverse proxy. It provides rich visibility, control over data travel, and
1390
sophisticated analytics to identify and combat cyberthreats across all of an organization’s Microsoft and
1391
third-party cloud services. Microsoft Defender for Cloud Apps natively integrates with Microsoft
1392
solutions and is designed with security professionals in mind. It provides simple deployment, centralized
1393
management, and innovative automation capabilities.
1394
3.4.14.16 Microsoft Entra Permissions Management
1395
Microsoft Entra Permissions Management (formerly known as CloudKnox) is a cloud infrastructure
1396
entitlement management (CIEM) solution that provides comprehensive visibility into permissions
1397
assigned to all identities, for example, overprivileged workload and user identities, actions, and
1398
resources across multi-cloud infrastructures in Microsoft Azure, AWS, and GCP.
1399
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 34
3.4.15 Okta
1400
Okta is an independent identity provider helping organizations protect the identities of their extended
1401
workforces, partners, and customers. With more than 7,000 pre-built integrations to applications and
1402
infrastructure providers, Okta provides simple and secure access to people and organizations
1403
everywhere, giving them the confidence to reach their full potential. Learn more about Okta here:
1404
Okta.com.
1405
3.4.15.1 Okta Identity Cloud
1406
The Okta Identity Cloud is an independent and neutral platform that securely connects the correct
1407
people to the correct technologies at the appropriate time. The Okta Identity Cloud includes identity and
1408
access management products, integrations, and platform services for extended Workforce Identity and
1409
Customer Identity use cases.
1410
The Okta Identity Cloud provides secure user storage, authentication capabilities (primary and MFA) to
1411
applications and resources (infrastructure, APIs) regardless of location (on-premises, cloud, or hybrid),
1412
as well as automation and orchestration capabilities for identity use cases, such as for automating user
1413
onboarding and offboarding or for identifying and acting on inactive user accounts. Products used in this
1414
project include the following.
1415
3.4.15.1.1 Universal Directory
1416
Okta Universal Directory is a cloud metadirectory that is used as a single source of truth to manage all
1417
users (employees, contractors, customers), groups, and devices. These users can be sourced directly
1418
within Okta or from any number of sources including AD, Lightweight Directory Access Protocol (LDAP),
1419
HR systems, and other SaaS applications.
1420
3.4.15.1.2 Single Sign-On (SSO)
1421
Okta SSO delivers seamless and secure access to all cloud and on-premises apps for end users,
1422
centralizing and protecting all user access via Okta’s cloud portal.
1423
Okta FastPass, available as a part of Okta SSO, enables passwordless authentication. Organizations can
1424
use Okta FastPass to minimize end-user friction when accessing corporate resources, while still
1425
enforcing Okta’s adaptive policy checks.
1426
3.4.15.1.3 Adaptive Multi-Factor Authentication (MFA)
1427
Okta Adaptive MFA uses intelligent policies to enable contextual access management, allowing
1428
administrators to set policies based on risk signals native to Okta as well as from third parties, such as
1429
device posture from EDR vendors. Okta Adaptive MFA also enables administrators to choose the
1430
factor(s) that work best for their organization, balancing security and ease of use with options such as
1431
secure authenticator apps, WebAuthn, and biometrics, which many organizations also choose as
1432
passwordless options.
1433
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 35
3.4.15.1.4 Okta Access Gateway
1434
Okta Access Gateway is an application access proxy that delivers access management (SSO, MFA, and
1435
URL authorization) to on-premises apps using legacy on-premises protocols – header-based
1436
authentication and Kerberos – without requiring changes in source code. In combination with Okta SSO,
1437
it allows users to access cloud and on-premises apps remotely from a single place and delivers the same
1438
easy and secure login experience for SaaS and on-premises apps.
1439
3.4.15.1.5 Okta Verify
1440
Okta Verify is a lightweight application that is used both as an authenticator option (e.g., OTP or push,
1441
available on macOS, Windows, iOS, and Android) with Okta MFA as well as to register a device to Okta.
1442
Registering a device to Okta enables organizations to deliver secure, seamless, passwordless
1443
authentication to apps, strong device-level security, and more. Okta Verify is FIPS 140-2 validated. [10]
1444
3.4.15.1.6 Okta Integration Network
1445
The Okta Integration Network serves as a conduit to connect thousands of applications and resources
1446
(infrastructure, APIs) to Okta for access management (SSO/MFA) and provisioning (automating
1447
onboarding and offboarding of user accounts). This integration network makes it easy for administrators
1448
to manage and control access for all users behind a single pane of glass, and easy for users to get to the
1449
tools they need with a unified access experience.
1450
In addition, the Okta Integration Network also serves as a rich ecosystem to support risk signal sharing
1451
for zero trust security. Okta’s deep integration with partners in the zero trust ecosystem allows the Okta
1452
Identity Cloud to take in risk signals for the purpose of making smarter contextual decisions regarding
1453
access. For example, integrations with EMM or EDR solutions allow the Okta IDaaS platform to know the
1454
managed state of a device or device risk posture and make decisions regarding access accordingly. Okta
1455
can also pass risk signals to third parties such as inline network solutions, which can in turn leverage
1456
Okta’s risk assessment to limit actions within SaaS apps when risk is high (e.g., read-only). Okta’s risk-
1457
based approach to access allows for fine-grained control of user friction and provides organizations with
1458
a truly zero trust PDP to make just-in-time, contextual-based authentication decisions to any resource,
1459
from anywhere.
1460
3.4.16 Palo Alto Networks
1461
Palo Alto Networks is shaping the cloud-centric future with technology designed to transform the way
1462
people and organizations operate by using the latest breakthroughs in AI, analytics, automation, and
1463
orchestration. By delivering an integrated platform and empowering a growing ecosystem of partners,
1464
Palo Alto Networks security technologies enable organizations to apply consistent security controls
1465
across clouds, networks, endpoints, and mobile devices.
1466
Their core capabilities include the ability to inspect all traffic, including all applications, threats, and
1467
content, and tie that traffic to the user, regardless of location or device type. The user, application, and
1468
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 36
content—the elements that run your business—become integral components of your enterprise’s zero
1469
trust security policy.
1470
Towards that end, their Next Generation Firewall (including all hardware-based, VM, and containerized
1471
form factors) and Prisma Access have consistent core capabilities fundamental for zero trust policy
1472
enforcement—including User-ID, App-ID, and Device-ID.
1473
▪ User-ID™ technology enables organizations to identify users in all locations, no matter their
1474
device type or OS. Visibility into application activity—based on users and groups, instead of IP
1475
addresses—safely enables applications by aligning usage with business requirements.
1476
▪ App-ID™ technology enables organizations to accurately identify applications in all traffic
1477
passing through the network, including applications disguised as authorized traffic, using
1478
dynamic ports, or trying to hide under the veil of encryption. App-ID allows organizations to
1479
understand and control applications and their functions, such as video streaming versus chat,
1480
upload versus download, and screen-sharing versus remote device control.
1481
▪ Device-ID™ technology enables organizations to enforce policy rules based on a device,
1482
regardless of changes to its IP address or location. By providing traceability for devices and
1483
associating network events with specific devices, Device-ID allows organizations to gain context
1484
for how events relate to devices and write policies that are associated with devices, instead of
1485
users, locations, or IP addresses, which can change over time.
1486
All NGFW form factors and Prisma Access also include the following cloud-delivered security service
1487
(CDSS) capabilities: Advanced Threat Prevention (ATP), Wildfire (WF) malware analysis, Advanced URL
1488
Filtering (AURL), and DNS Security (DNS). These capabilities are supported by the GlobalProtect (GP)
1489
remote access solution and can all be centrally managed by Panorama.
1490
3.4.16.1 Next-Generation Firewall (NGFW)
1491
The Palo Alto Networks Next-Generation Firewall (NGFW) is a machine learning (ML) powered network
1492
security platform available in physical, virtual, containerized, and cloud-delivered form factors—all
1493
managed centrally via Panorama. The Palo Alto Networks NGFWs inspect all traffic, including all
1494
applications, threats, and content, and tie that traffic to the user, regardless of location or device type.
1495
Built on a single-pass architecture, the Palo Alto Networks NGFW performs full-stack, single-pass
1496
inspection of all traffic across all ports, providing complete context around the application, associated
1497
content, and user identity to form the basis for zero trust security policy decisions.
1498
Additional NGFWs, including cloud-delivered, software-based VMs (VM-Series), and container-based
1499
(CN-Series), are anticipated to be used as part of the microsegmentation deployment model phase of
1500
this project, deployed as PEPs deeper within each enterprise environment. Regardless of form factor,
1501
any NGFW or Prisma Access instance can serve as a PEP, enabled by the core (User-ID, Application-ID,
1502
Device-ID) technologies described above—helping organizations achieve common zero trust use cases
1503
such as data center segmentation, user or application-based segmentation, or cloud transformation.
1504
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 37
3.4.16.2 Prisma Access
1505
Prisma Access allows organizations to securely enable remote workforces and branch locations, and will
1506
be more extensively demonstrated during the SDP deployment model phase of the project. The cloud-
1507
native architecture of Prisma Access is designed to ensure on-demand and elastic scaling of
1508
comprehensive networking and security services across a global, high-performance network. Together
1509
with Prisma SD-WAN (software-defined wide area network), Prisma Access provides the foundational
1510
layer for a complete secure access service edge (SASE) solution that delivers networking and security
1511
with a common service delivery model.
1512
Prisma Access combines least-privileged access with deep and ongoing security inspection as well as
1513
enterprise DLP to protect all users, devices, apps, and data. Prisma Access fully inspects all application
1514
traffic bidirectionally—including TLS-encrypted traffic—on all ports, whether communicating with the
1515
internet, the cloud, the data center, or between branches. Additionally, Prisma Access provides more
1516
security coverage consolidating multiple point products into a single converged platform that includes
1517
Firewall as a Service (FWaaS), Zero Trust Network Access (ZTNA), next-generation CASB, cloud SWG,
1518
VPN, and more—all managed through a single console.
1519
Prisma Access connects users and applications with fine-grained access controls, providing behavior-
1520
based continuous trust verification after users connect to dramatically reduce the attack surface.
1521
3.4.16.3 Cortex XDR
1522
Cortex XDR is an XDR tool that natively integrates network, endpoint, and cloud data to stop
1523
sophisticated attacks. Leveraging behavioral analytics, it identifies unknown and highly evasive threats
1524
targeting your environment. ML and AI models uncover threats from multiple sources, including
1525
managed and unmanaged devices. Cortex XDR speeds alert triage and incident response by providing a
1526
comprehensive picture of each threat and revealing the root cause. By stitching different types of data
1527
together and simplifying investigations, Cortex XDR reduces the time and experience required at every
1528
stage of security operations, from triage to threat hunting. Native integration with enforcement points
1529
lets you respond to threats quickly and apply the knowledge gained from investigations to mitigate
1530
future attacks.
1531
Cortex XDR features Identity Analytics, which detects malicious user activities by applying ML and
1532
behavioral analytics to users, machines, and entities. Using an analytics engine to examine logs and data,
1533
Identity Analytics can understand normal behaviors across your environment and create a baseline so
1534
that it can raise alerts when abnormal activity occurs. With this function, suspicious user activity such as
1535
stolen or misused credentials, lateral movement, credential harvesting, exfiltration, and brute-force
1536
attacks can be detected. This ML-derived insight offers critical identity context specific to each bespoke
1537
environment Cortex XDR is deployed into, allowing for higher-fidelity alerts to aid organizations in fine-
1538
tuning access granted to critical assets—an imperative for ZTA.
1539
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 38
3.4.17 PC Matic
1540
PC Matic is an endpoint protection solution for enterprises of all sizes, utilizing PC Matic’s proactive
1541
application allowlisting technology. Through a series of global and local allowlists, PC Matic’s software
1542
asset management restricts unauthorized programs and processes from accessing resources such as
1543
data or services on a network. Unlike traditional application allowlisting products that solely rely on self-
1544
made local allowlists, PC Matic operates off both the user’s local list and a real-time automated global
1545
allowlist consisting of verified files, processes, digital certificates, and scripts. PC Matic eliminates
1546
governance issues by granting users the ability to create application, digital certificate, directory, or
1547
scripting policies within their local lists. This capability takes immediate effect and can be deployed to
1548
individual endpoints, departments, groups, whole organizations, and all agencies and enterprises
1549
managed across the account.
1550
3.4.17.1 PC Matic Pro
1551
PC Matic Pro’s on-premises endpoint protection provides default-deny protection at the device. PC
1552
Matic Pro monitors for any process that attempts to execute and automatically denies access to any
1553
unauthorized or known malicious entities. When the unauthorized files and/or processes are denied
1554
access, all metadata pertaining to the block is then communicated to the architecture’s SIEM for
1555
prioritizing and further investigation. This integration provides users with increased visibility over their
1556
managed devices and networks. If a block is verified and warranted, the SIEM of choice can utilize the
1557
policy engine from either PC Matic or a third-party vendor to create and enforce the exception, granting
1558
immediate access to the desired deployment. PC Matic’s real-time policy offerings eliminate governance
1559
issues, take immediate effect without delay or issue, and provide users with streamlined management
1560
across their managed architectures. PC Matic’s allow-by-exception approach to prevention enhances the
1561
zero trust model and minimizes the network’s attack surface by ensuring only authorized processes are
1562
granted privileges to execute and proceed further.
1563
3.4.18 Ping Identity
1564
Ping Identity delivers intelligent identity solutions for the enterprise. Ping enables companies to achieve
1565
zero trust identity-defined security and more personalized, streamlined user experiences. The PingOne
1566
Cloud Platform provides customers, workforces, and partners with access to cloud, mobile, SaaS, and
1567
on-premises applications across the hybrid enterprise. Over half of the Fortune 100 choose Ping for their
1568
identity expertise, open standards, and partnerships with companies including Microsoft and Amazon.
1569
Ping Identity provides flexible identity solutions that accelerate digital business initiatives and secure the
1570
enterprise through multi-factor authentication, single sign-on, access management, intelligent API
1571
security, and directory and data governance capabilities. For more information, please visit
1572
https://www.pingidentity.com/.
1573
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 39
3.4.18.1 PingFederate
1574
PingFederate is an enterprise federation server that enables user authentication and single sign-on. It is
1575
a global authentication authority that allows customers, employees, and partners to access all the
1576
applications they need from any device securely. PingFederate easily integrates with applications across
1577
the enterprise, third-party authentication sources, diverse user directories, and existing IAM systems, all
1578
while supporting current and past versions of identity standards. It will connect everyone to everything.
1579
PingFederate can be deployed within Ping Identity’s SaaS offerings, in a customer cloud, as a traditional
1580
application, and within air-gapped or network segmented environments.
1581
The deployment architecture of PingFederate eliminates the need to maintain redundant copies of
1582
configurations and trust relationships. Supported federation standards include OAuth, OpenID, OpenID
1583
Connect, SAML, WS-Federation, WS-Trust, and System for Cross-Domain Identity Management (SCIM).
1584
3.4.18.2 PingOne DaVinci
1585
PingOne DaVinci is a SaaS platform that enables a flexible and adaptive integration framework, allowing
1586
you to easily create identity journeys via a drag-and-drop interface. Through DaVinci, administrators can
1587
quickly design automated workflows for different identity use cases including authentication, identity
1588
proofing, and fraud detection. DaVinci is an open interface with integrations and connections across
1589
multiple applications and identity ecosystems.
1590
3.4.18.3 PingOne SSO
1591
PingOne SSO is a SaaS federation platform. Using single sign-on (SSO), users can sign on to all their
1592
applications and services with one set of credentials. It gives employees, partners, and customers
1593
secure, one-click access from anywhere, on any device, and it reduces the number of separate accounts
1594
and passwords they need to manage.
1595
SSO is made possible by a centralized authentication service that all apps (even third-party) can use to
1596
confirm a user’s identity. Identity standards like SAML, OAuth, and OpenID Connect allow for encrypted
1597
tokens to be transmitted securely between the server and the apps to indicate that a user has already
1598
been authenticated and has permission to access the additional apps.
1599
3.4.18.4 PingOne Risk
1600
PingOne Risk is a SaaS platform that enables administrators to configure intelligence-based
1601
authentication policies by combining the results of multiple risk predictors to calculate a single risk
1602
score. Data feeds and inputs roll into set risk predictors. The predictors are assigned different scores and
1603
aggregated into a risk policy to determine if a user poses low, medium, or high risk to the organization
1604
and what level of authentication will be required. Administrators can create multiple risk policies and
1605
apply them in different use cases to meet business requirements.
1606
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 40
3.4.18.5 PingOne Verify
1607
PingOne Verify is a SaaS platform that reduces uncertainty during onboarding and prevents fraudulent
1608
registration with convenient identity verification. PingOne Verify enables secure user verification based
1609
on a government-issued document and real-time face capture (a live selfie). The Verify dashboard
1610
summarizes all transactions, which enables you to manage all verifications, exceptions, and rejections
1611
within the PingOne platform.
1612
3.4.18.6 PingOne Authorize
1613
PingOne Authorize is a SaaS platform that leverages real-time data to make authorization decisions for
1614
access to data, services, APIs, and other resources. Organizations increasingly want to codify their
1615
authorization requirements as policies, giving business owners the flexibility to adapt and evolve access
1616
control rules over time. Our solution helps organizations accurately control what users can see and do
1617
within applications and APIs. With an exploding number of applications, regulations, and access control
1618
requirements to manage, abstracting authorization logic to a centralized administrative control plane is
1619
the key to enabling scale and consistency.
1620
3.4.18.7 PingID
1621
PingID is a SaaS platform that provides an MFA solution for the workforce and partners that drastically
1622
improves organizational security posture in minutes. PingID protects applications accessed via SSO and it
1623
integrates seamlessly with Microsoft Azure AD, Active Directory Federation Services (AD FS), and
1624
Windows login, macOS login, and SSH applications.
1625
Supported authentication methods include mobile push, email OTP, SMS OTP, time-based OTP (TOTP)
1626
authenticator apps, Quick Response (QR) codes, FIDO2-bound biometrics, and security keys.
1627
3.4.18.8 PingAccess
1628
PingAccess is a centralized access security solution with a comprehensive policy engine. It provides
1629
secure access to applications and APIs down to the URL level and ensures that only authorized users can
1630
access the resources they need. PingAccess allows organizations to protect web apps, APIs, and other
1631
resources using rules and other authentication criteria.
1632
PingAccess can be deployed within Ping Identity’s SaaS offerings, in a customer cloud, as a traditional
1633
application, and within air-gapped or network segmented environments.
1634
3.4.18.9 PingDirectory
1635
PingDirectory is a fast, scalable directory used to store identity and rich profile data. Organizations that
1636
need maximum uptime for millions of identities use PingDirectory to securely store and manage
1637
sensitive customer, partner, and employee data. PingDirectory acts as a single source of identity truth.
1638
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 41
Users get loaded into PingDirectory through import, API connection, manual entry, or bidirectional, real-
1639
time synchronization from LDAP, relational database management system (RDBMS), Java Database
1640
Connectivity (JDBC), or SCIM data stores. Both structured and unstructured user data are secured and
1641
stored by leveraging encryption, password validators, cryptographic log signing, and more. Out-of-the-
1642
box load balancing, rate limiting, and data transformations with an integrated proxy ensure maximum
1643
server performance and user data availability at scale during peak usage.
1644
PingDirectory can be deployed within Ping Identity’s SaaS offerings, in a customer cloud, as a traditional
1645
application, and within air-gapped or network segmented environments.
1646
3.4.19 Radiant Logic
1647
Radiant Logic, the enterprise Identity Data Fabric company, helps organizations combat complexity and
1648
improve defenses by making identity data easy to access, manage, use, and protect. With Radiant, it’s
1649
fast and easy to put identity data to work, creating the identity data foundation of the enterprise where
1650
organizations can realize meaningful business value, accelerate innovation, and achieve zero trust. Built
1651
to combat identity sprawl, enterprise technical debt, and interoperability issues, the RadiantOne
1652
platform connects many disparate identity data sources across legacy and cloud infrastructures, without
1653
disruption. It can accelerate the success of initiatives including SSO, mergers and acquisitions
1654
integrations, identity governance and administration, hybrid and multi-cloud environments, customer
1655
identity and access management, and more with an identity data fabric foundation. Visit
1656
http://www.radiantlogic.com/ to learn more.
1657
3.4.19.1 RadiantOne Intelligent Identity Data Platform
1658
The RadiantOne Intelligent Identity Data Platform builds an identity data fabric using federated identity
1659
as the foundation for zero trust. It is the single authoritative source for identity data, enabling critical
1660
initiatives by making identity data and related context available in real time to consumers regardless of
1661
where that data resides. RadiantOne’s Intelligent Identity Data Platform uses patented identity
1662
unification methods to abstract and enrich identity data from multiple sources, build complete global
1663
user profiles, and deliver real-time identity data on-demand to any service or application. Zero trust
1664
relies on evaluating a rich and authoritative granular set of attributes in real time against an access
1665
policy to determine authorization. RadiantOne provides a single authoritative place for all components
1666
of the ZTA to quickly and easily request the exact data they need in the format, structure, schema, and
1667
protocol each requires. In order to provide the flexibility and scalability that organizations need, the
1668
platform is broken into six distinct modules: Federated Identity Engine; Universal Directory; Global
1669
Synchronization; Directory Migration; Insights, Reports & Administration; and Single Sign-On.
1670
3.4.19.1.1 RadiantOne Federated Identity Engine
1671
The Federated Identity Engine abstracts and unifies identity data from all sources (on-premises or cloud-
1672
based) to form an identity data fabric that is flexible and scalable, and turns identity data into a reusable
1673
resource. The identity data fabric provides a central access point for authoritative identity data to all
1674
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 42
applications, and encompasses all subjects, users, and objects (employees, contractors, partners,
1675
customers, members, non-enterprise employees, devices, NPEs, service accounts, bots, IoT, risk scoring,
1676
and data and other assets). RadiantOne gathers, maps, normalizes, and transforms identity data to build
1677
a de-duplicated list of users, enriched with all identity attributes to create a single global profile for each
1678
user. The Federated Identity Engine is schema-agnostic and standards-based, which allows it to build
1679
unlimited and flexible views correlated from all sources of rich and granular identity data, updated in
1680
near-real-time, and delivered at speed in the format required by all the consuming applications in the
1681
ZTA. These views are stored in a highly scalable, modern big data store kept in near-real-time sync with
1682
local identity sources of truth.
1683
3.4.19.1.2 RadiantOne Universal Directory
1684
The RadiantOne Universal Directory provides a modern way of storing and accessing identity
1685
information in a highly scalable, fault-tolerant, containerized solution for distributed identity storage. Its
1686
highly performant cluster architecture scales easily to hundreds of millions of objects, delivering
1687
automation, high availability, and multi-cluster deployments to easily accommodate distributed data
1688
centers. Universal Directory is FIPS 140-2 certified for securing data-in-transit and data-at-rest, and it
1689
provides detailed audit logs and reports [11]. Universal Directory is accessible by all LDAP, SQL, SCIM,
1690
and REST-enabled applications.
1691
3.4.19.1.3 RadiantOne Single Sign On (SSO)
1692
Single Sign On is the gateway between identity stores and applications that support federation
1693
standards—SAML, OIDC, WS-Federation—for connecting users with seamless, secure, and uniform
1694
access to federated applications. SSO enables a secure federated infrastructure, creating one access
1695
point to connect all internal identity and authentication sources for strong authentication. It also
1696
provides a self-service portal for managing passwords and user profiles.
1697
3.4.19.1.4 RadiantOne Global Synchronization
1698
Global Synchronization leverages bidirectional connectors to propagate identity data and keep it
1699
coherent across enterprise systems in near-real-time, regardless of the location of the underlying
1700
identity source data (on-premises, cloud-based, or hybrid). It builds a reliable and highly scalable
1701
infrastructure with a transport layer based on message queuing for guaranteed delivery of changes.
1702
Global Synchronization reduces complexity and administrative burden, simplifies provisioning and
1703
syncing identity centrally, and ensures consistency and accuracy with real-time change detection to
1704
underlying identity data attributes.
1705
3.4.20 SailPoint
1706
SailPoint offers identity security technologies that automate the identity lifecycle; manage the integrity
1707
of identity attributes; enforce least privilege through dynamic access controls, role-based policies, and
1708
separation of duties (SoD); and continuously assess, govern, and respond to access risks using AI and
1709
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 43
ML. SailPoint Identity Security is the cornerstone of an effective zero trust strategy. Discover more at
1710
https://www.sailpoint.com/.
1711
3.4.20.1 IdentityIQ Platform
1712
SailPoint IdentityIQ is an identity and access management software platform custom-built for complex
1713
enterprises. It delivers full lifecycle and compliance management for provisioning, access requests,
1714
access certifications, and SoD. The platform integrates with SailPoint’s extensive library of connectors to
1715
intelligently govern access to today’s essential business applications. Harnessing the power of AI and
1716
ML, SailPoint’s AI Services seamlessly automate access, delivering only the required access to the correct
1717
identities and technology at the appropriate time.
1718
As an identity governance platform, SailPoint provides organizations with a foundation that enables a
1719
compliant and secure infrastructure driven by a zero trust approach with complete visibility of all access,
1720
frictionless automation of processes, and comprehensive integration across hybrid environments.
1721
SailPoint connects to enterprise resources to aggregate accounts and correlate with authoritative
1722
records to build a foundational identity profile from which all enterprise access is based. Users are
1723
granted birthright access based on dynamic attribute evaluation, and additional access for all integrated
1724
resources is requested and governed through a centralized SailPoint request portal. The SailPoint
1725
governance platform is enriched through its extensible API framework to support integrations with
1726
other identity security tools. The IdentityIQ platform contains two components, IdentityIQ Compliance
1727
Manager and IdentityIQ Lifecycle Manager.
1728
3.4.20.1.1 IdentityIQ Compliance Manager
1729
IdentityIQ Compliance Manager automates access certifications, policy management, and audit
1730
reporting to streamline compliance processes and improve the effectiveness of identity governance.
1731
Access certification ensures least-privileged access by continuously monitoring and removing accounts
1732
and entitlements that are no longer needed.
1733
Separation of duties policies enforce business procedures to detect and prevent inappropriate access or
1734
actions by proactively scanning for violations.
1735
Audit reporting simplifies the collection the information needed to manage the compliance process and
1736
replaces manual searches for data located in various systems around the enterprise through an
1737
integrated platform.
1738
3.4.20.1.2 IdentityIQ Lifecycle Manager
1739
IdentityIQ Lifecyle Manager enables an organization to manage changes to access through user-friendly
1740
self-service requests and lifecycle events for fast, automated delivery of access to users.
1741
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 44
Access requests enable users to request and receive access to enterprise on-premises and SaaS
1742
applications and data while ensuring compliance through policy enforcement and elevating reviews for
1743
privileged access.
1744
Automated provisioning detects and triggers changes to a user’s access based on a user joining, moving
1745
within, or leaving an organization. Direct provisioning reduces risk by automatically changing or
1746
removing accounts and access in an appropriate manner with automated role and attribute-based
1747
access.
1748
3.4.21 Tenable
1749
Tenable®, Inc. is the Cyber Exposure company. Organizations around the globe rely on Tenable to
1750
understand and reduce cyber risk. As the creator of Nessus®, Tenable extended its expertise in
1751
vulnerabilities to see and secure any digital asset on any computing platform.
1752
3.4.21.1 Tenable.io
1753
Powered by Nessus technology and managed in the cloud, Tenable.io provides comprehensive
1754
vulnerability coverage with the ability to predict which security issues to remediate first. Using an
1755
advanced asset identification algorithm, Tenable.io can provide accurate information about dynamic
1756
assets and vulnerabilities in ever-changing environments. As a cloud-delivered solution, its intuitive
1757
dashboard visualizations, comprehensive risk-based prioritization, and seamless integration with third-
1758
party solutions help security teams maximize efficiency and scale for greater productivity.
1759
3.4.21.2 Tenable.ad
1760
Tenable.ad is a software solution that helps organizations harden their AD by finding and fixing AD
1761
weaknesses and vulnerabilities before attacks happen. Tenable.ad Indicators of Exposure discover and
1762
prioritize weaknesses within existing AD domains and reduce exposure by following Tenable.ad step-by-
1763
step remediation guidance. Tenable.ad keeps an AD in this hardened state by continuously monitoring
1764
and alerting in real time of any new misconfigurations, while Tenable.ad Indicators of Attacks enable
1765
detection and response to AD attacks in real time. In addition, Tenable.ad tracks and records all changes
1766
to an AD, helping show the link between AD changes and malicious actions. Tenable.ad can send alerts
1767
using email or through an existing SIEM solution.
1768
3.4.21.3 Tenable.cs
1769
Tenable.cs is Tenable’s cloud security solution to help organizations programmatically detect and fix
1770
cloud infrastructure security issues in design, build, and runtime phases of the software development
1771
lifecycle (SDLC). Tenable.cs enables organizations to establish guardrails in DevOps processes to prevent
1772
unresolved misconfigurations or vulnerabilities in Infrastructure as Code (IaC) from reaching production
1773
environments. The product monitors cloud resources deployed in AWS, Azure, and GCP to ensure any
1774
runtime changes are compliant with policies, and remediations to address configuration drifts are
1775
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 45
automatically propagated back to the IaC. Tenable.cs also provides continuous visibility to assess cloud
1776
hosts and container images for vulnerabilities whether they’re deployed for days or hours, without the
1777
need to manage scan schedules, credentials, or agents. All cloud assets—including ephemeral assets—
1778
are continuously reassessed as new vulnerability detections are added and as new assets are deployed.
1779
This always-on approach allows organizations to spend more time focusing on the highest priority
1780
vulnerabilities and less time on managing scans and software.
1781
3.4.22 Trellix
1782
Trellix is redefining the future of cybersecurity. The company’s open and native XDR platform helps
1783
organizations confronted by today’s most advanced threats gain confidence in the protection and
1784
resilience of their operations. Trellix’s security experts, along with an extensive partner ecosystem,
1785
accelerate technology innovation through ML and automation to empower customers. See more at
1786
https://trellix.com/. Trellix solutions can play a pivotal role in assisting organizations in meeting their
1787
zero trust outcomes through Trellix’s extensive portfolio of enforcement points and ability to quickly
1788
quantify risk and orchestrate responses.
1789
Trellix offers a comprehensive portfolio of tools that align with zero trust objectives and outcomes. The
1790
following subsections discuss the tools from the portfolio currently being included in this NCCoE effort.
1791
3.4.22.1 MVISION Complete Suite
1792
MVISION Complete delivers a comprehensive suite of tools that provide threat and data protection
1793
across endpoints, web, and cloud. Individual products included in the MVISION Complete Suite include
1794
the following.
1795
3.4.22.1.1 Trellix ePO
1796
Trellix ePolicy Orchestrator (ePO) is a centralized management console for deploying, configuring, and
1797
managing Trellix endpoint security solutions including threat prevention, data protection, and EDR. For
1798
more information on Trellix ePO, please visit ePolicy Orchestrator | Trellix.
1799
3.4.22.1.2 Trellix Insights
1800
Trellix Insights is a threat intelligence platform integrated with the Trellix solution portfolio that enables
1801
customers to gain contextual understanding of active global threat campaigns relevant to their vertical.
1802
Through integrated understanding of compensating controls and detection events, Insights enables
1803
organizations to predictively stay ahead of threats, quickly identify campaign activity within their
1804
environment, and receive the guidance necessary to proactively defend against campaigns. For more
1805
information on Trellix Insights, please visit Trellix Insights | Trellix.
1806
3.4.22.1.3 Trellix Endpoint Security Platform
1807
Trellix Endpoint Security Platform blocks malicious and targeted attacks using traditional and enhanced
1808
detection techniques as part of a layered protection strategy. Techniques include generic malware
1809
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 46
detection, behavioral detection, ML, containment, and enhanced remediation. For more information on
1810
Trellix Endpoint Security, please visit Trellix Endpoint Security | Trellix.
1811
3.4.22.1.4 Trellix EDR
1812
Trellix EDR collects and analyzes device trace data using advanced detection techniques in order to
1813
surface suspected threats within an enterprise. Trellix EDR empowers security operations teams to gain
1814
important context about the environment with true real-time enterprise search capabilities and
1815
integrated threat intelligence. Trellix EDR is an asset to resource-starved security operations teams
1816
working to keep up with the ever-growing threat landscape by incorporating integrated AI-assisted
1817
guided investigations. Guided investigations analyze thousands of artifacts beyond the initial detection
1818
event to replicate a traditionally manual playbook process. By automating this process, analysts can
1819
reach conclusions faster, reduce time to detection, and accelerate confident response activities. For
1820
more information on Trellix EDR, please visit Trellix EDR – Endpoint Detection & Response | Trellix.
1821
3.4.22.1.5 Trellix DLP Endpoint
1822
Trellix DLP Endpoint enables organizations to discover, control, and block access to sensitive data on the
1823
endpoint. Trellix DLP Endpoint integrates with identity providers to assign policy based on users’ roles
1824
and groups, and in a ZTA can adjust data protection policy as user trust changes. Additionally, DLP
1825
Endpoint is managed by ePO, and it includes a full case management system for aggregating multiple
1826
DLP incidents and identifying malicious insiders. For more information on Trellix DLP Endpoint, please
1827
visit DLP Endpoint | Trellix.
1828
3.4.22.1.6 Skyhigh Security SSE Platform
1829
Skyhigh Security, once part of Trellix’s foundational company, McAfee Enterprise, has been established
1830
as a separate business entity and sister company to Trellix. Skyhigh Security’s Security Service Edge (SSE)
1831
platform is part of the MVISION Complete Suite, delivered by Skyhigh Security, and offers
1832
comprehensive protection for cloud, web, and data protection. Skyhigh Security integrates a CASB
1833
platform with strong cloud-hosted web security and data protection controls to deliver a highly secure,
1834
highly available platform for protecting hybrid and multi-cloud enterprises. For more information on
1835
Skyhigh Security’s SSE platform please visit What is SSE? | Security Service Edge | Skyhigh Security.
1836
The MVISION Complete Suite aids in the ability to meet zero trust objectives by delivering device-level
1837
protection and alerting, application protection through contextual access controls, user trust through
1838
user activity monitoring, data security through comprehensive data protection and discovery, and
1839
analytics and intelligence through EDR and Insights.
1840
3.4.22.2 Full Remote Browser Isolation
1841
Remote browser isolation enables organizations to fully contain web applications within a secure
1842
container to prevent malware and data leakage and provide complete control over a browser session.
1843
The Skyhigh SSE solution out of the box offers remote browser isolation for risky websites to ensure no
1844
implicit trust is being granted to web applications prior to trust validation. In some cases, organizations
1845
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 47
would choose that no implicit trust is ever extended to web traffic, regardless of known reputation. In
1846
this scenario, full-time browser isolation is required to meet this objective. The Trellix offering, with
1847
sister company Skyhigh Security, includes the ability for full remote browser isolation as an add-on
1848
module. For more information on remote browser isolation, see Remote Browser Isolation | McAfee
1849
Products.
1850
3.4.22.3 Helix (XDR)
1851
To achieve zero trust outcomes, it is necessary to have a common platform that applies AI-driven, real-
1852
time threat intelligence to data collected from devices and security sensors as a mechanism for surfacing
1853
advanced attacks and associated entity risk, and to orchestrate proactive and remediating responses
1854
across native and open security tools. Within many zero trust reference architectures, this platform
1855
could be considered the dynamic access control plane, or the trust algorithm.
1856
Trellix delivers this capability through Helix. Helix is a cloud-hosted, intelligence-driven platform that
1857
collects data from over 600 different sensors and point solutions, analyzes the data against known
1858
threats, behaviors, and campaigns using AI and enhanced detection rules, and powers automated and
1859
manual responses across Trellix native and third-party policy engines. For more information on Trellix
1860
XDR, see Trellix-Platform | Trellix.
1861
3.4.22.4 CloudVisory
1862
It’s no secret that cloud services are now pervasive; many applications have been moved either through
1863
SaaS or cloud services development to cloud data centers. This presents new challenges for many
1864
organizations as they work to gain better visibility and control over IaaS-hosted cloud applications and
1865
the thousands of microservices that support them. As organizations look to adopt zero trust principles
1866
within the cloud, it will become imperative that proper service configuration, IAM roles, cloud network
1867
traffic, and workloads are fully evaluated for risk and protected. CloudVisory supports these objectives
1868
through:
1869
▪ CI/CD integration to ensure proper service configuration, and continuous posture assessments
1870
to guard against configuration drift
1871
▪ IAM policy inspection
1872
▪ intelligent network microsegmentation
1873
▪ intra-cloud and cloud-to-cloud network monitoring
1874
▪ multi-cloud support
1875
For more information on CloudVisory, see ds-cloudvisory.pdf (fireeye.com).
1876
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 48
3.4.23 VMware
1877
Enabling secure work from anywhere is a critical requirement for most businesses, and a zero trust
1878
architecture is best suited to enable that. But zero trust is not a single product; rather, it is a solution
1879
that requires visibility and control at the various points that link a user with the resources they need.
1880
The VMware Anywhere Workspace is designed for zero trust with connected control points for devices,
1881
users, networks, and applications.
1882
3.4.23.1 Securing Devices
1883
The foundation of trust is the posture of devices used by users to access applications and resources.
1884
VMware Workspace ONE™ enables customers to manage the configuration and posture of any device.
1885
Via the Compliance engine in Workspace ONE, policies are created using a customer-selectable set of
1886
attributes and configurations. Minimum posture requirements for application access can be defined for
1887
any device, whether managed by Workspace ONE or not. To limit the on-device software footprint for
1888
personally owned devices, Workspace ONE Mobile Application Management (MAM) capabilities can
1889
provide posture assessment and compliance within applications such as Workspace ONE Tunnel, Boxer,
1890
and Web, as well as for customer-developed applications. With the addition of endpoint security
1891
solutions such as Workspace ONE Mobile Threat Defense (MTD) and Carbon Black Cloud, advanced
1892
security can be implemented to ensure the device is trustworthy; and out-of-compliance devices can
1893
trigger response and remediation via Workspace ONE UEM. Integrations with other leading endpoint
1894
and network security solutions also are made possible through Workspace ONE Trust Network, where
1895
threat signals are used to inform and influence device posture assessments and trigger remediation and
1896
response.
1897
3.4.23.2 Secure Identities
1898
User identity, posture, and behavior are also critical to zero trust. Workspace ONE Access integrates
1899
seamlessly with leading identity providers and layers on a rich set of controls that provide conditional
1900
access to any application or resource while delivering an optimal end user experience. Workspace ONE
1901
Access integrates with user, device, and login risk analytics provided by Workspace ONE Intelligence,
1902
thereby adding behavioral context to conditional application access policies and in case of established
1903
trust, granting passwordless SSP based access to applications and resources. Adoption of zero trust
1904
solutions including MFA is eased with choices including integrations for third party FIDO2
1905
authentications or the use of phishing resistant multi-factor authentication client included with
1906
Workspace ONE Intelligent Hub.
1907
3.4.23.3 Secure Network Connectivity
1908
Providing secure connectivity to resources, regardless of location, in an efficient and safe manner is
1909
critical to zero trust. With Zero Trust Network Access, which VMware delivers with Workspace ONE
1910
Tunnel and Secure Access, companies can tailor access based on resource sensitivity, device posture,
1911
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 49
user role, and authentication strength, as well as the application being used to access the network.
1912
VMware is unique in providing per-app tunneling capabilities for both managed and unmanaged
1913
devices, meaning that access to a resource can be allowed only via specified applications (e.g., Chrome,
1914
Firefox or a native client application). Traffic policies can be sculpted to provide different access to each
1915
application. With Tunnel, a device is not placed onto a network or given an internal IP address, which
1916
further minimizes network-borne threats to endpoints, and the security risks of hub-based network
1917
architectures. Secure access can be provided as either a managed service from VMware or with the
1918
customer-deployed Unified Access Gateway (UAG). Integrating with NSX can further segment access by
1919
limiting access to NSX Security Groups to specific applications managed by Workspace ONE.
1920
In addition to Workspace ONE Tunnel and Secure Access, VMware Horizon also provides secure access
1921
to virtual desktops and applications that run inside your data center, which also provides complete data
1922
containerization.
1923
3.4.23.4 Application Workload
1924
VMware vSphere provides workload isolation through virtualization. VMware NSX secures access to
1925
workloads by providing microsegmentation within the data center, which provides granular access
1926
policies that allow traffic only between specific resources. The deep integration between vSphere, NSX,
1927
and Carbon Black Cloud, allows for security to be further improved by restricting communication
1928
between specific processes between disparate workloads, thus ensuring that only traffic between
1929
processes and workloads that is specifically intended is permitted.
1930
NSX provides additional east-west (intra-data center) inspection of traffic, including IDS/IPS capabilities,
1931
Network Traffic Analytics (NTA), and Network Detection and Response (NDR), which provide advanced
1932
threat protection against advanced threats and lateral movement.
1933
3.4.23.5 Data
1934
VMware Workspace ONE Unified Endpoint Management (UEM) is responsible for device enrollment, a
1935
mobile application catalog, policy enforcement regarding device compliance, and integration with key
1936
enterprise services, such as email, content, and social media.
1937
Workspace ONE UEM features include:
1938
▪ Device management platform – Allows full lifecycle management of a wide variety of devices,
1939
including phones, tablets, Windows 10, and rugged and special-purpose devices.
1940
▪ Application deployment capabilities – Provides automatic deployment or self-service application
1941
access for employees.
1942
▪ User and device profile services – Ensures that configuration settings for users and devices
1943
comply with enterprise security requirements and simplify end-user access to applications
1944
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 50
▪ Productivity tools – Includes an email client with secure email functionality, a content
1945
management tool for securely storing and managing content, and a web browser to ensure
1946
secure access to corporate information and tools.
1947
3.4.23.6 Visibility and Analytics
1948
Having visibility into the operation of the zero trust solution requires bringing together data from many
1949
solution elements. Additionally, bringing data together can enable analysis and generation of insights
1950
that can inform a ZTA.
1951
Workspace ONE Intelligence provides visibility and analytics for device, identity, and network activities
1952
and highlights conditions that deviate significantly from the norm. Enterprises now can see how devices
1953
compare to their enterprise fleet, and these insights can be used for reporting and visualization and as
1954
input to automated response actions and playbooks. Resource access attempts can be profiled to look
1955
for new or unusual access patterns, and that information can be used to directly inform zero trust access
1956
policies.
1957
Workspace ONE Intelligence can incorporate threat data from leading security providers via Workspace
1958
ONE Trust Network, which gives additional context and insights that administrators can use to assess
1959
hygiene and posture.
1960
3.4.23.7 Automation and Orchestration
1961
Workspace ONE Intelligence provides automation and orchestration capabilities that can be triggered by
1962
any event. Automations can be as simple as notifying a user that their device needs an operating system
1963
(OS) update to remain compliant, or complex actions that involve multiple products, such as responding
1964
to detected malicious code on a device by opening a ticket in a ticketing system, then notifying IT and
1965
security teams, removing sensitive enterprise applications and data, followed by quarantining the device
1966
from the network. This is all made possible through API integrations with VMware and third-party
1967
products and is enabled in a low- or no-code manner.
1968
VMware's product offerings provide the foundation for ZTA.
1969
▪ Connected control points – device, user, network, and workload
1970
▪ Freedom of choice – any device, any application, any cloud
1971
▪ Respecting privacy – clearly communicate what data the enterprise can – and cannot – see
1972
▪ End-user experience – better security delivered in a way that improves user experience
1973
For more information about VMware's zero trust offerings, please see
1974
https://www.vmware.com/solutions/zero-trust-security.html.
1975
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 51
3.4.24 Zimperium
1976
Zimperium secures both mobile devices and applications so they can safely and securely access data.
1977
Patented on-device ML-based security provides visibility and protection against known and zero-day
1978
threats and attacks.
1979
3.4.24.1 Zimperium Mobile Threat Defense
1980
Zimperium Mobile Threat Defense is an advanced MTD solution for enterprises, providing persistent, on-
1981
device protection to both corporate-owned and BYOD devices against modern attack vectors.
1982
Leveraging Zimperium’s patented z9 on-device detection engine, Zimperium MTD detects threats across
1983
the kill chain, including device compromise, network, phishing, and application attacks.
1984
Zimperium’s MTD provides on-device behavior detection via an on-device agent, even when the device
1985
is not connected to a network. Zimperium’s MTD begins protecting devices against all primary attack
1986
vectors immediately after deployment. The Zimperium zConsole provides a management interface used
1987
to configure threat policies, manage device groups/users, and view events and the forensics that are
1988
associated with those events.
1989
Zimperium provides critical mobile security data for organizations, with integrations into multiple,
1990
concurrent enterprise SIEM/SOAR, UEM, XDR, and IAM platforms. Data is securely shared via REST API,
1991
syslog, etc. Zimperium MTD provides comprehensive device attestation enabling a complete picture of
1992
mobile endpoint security and increased visibility into risks such as jailbreak detections. Zimperium MTD
1993
provides continuous protection for mobile devices, providing the risk intelligence and forensic data
1994
necessary for security administrators to raise their mobile security confidence. Zimperium integrates
1995
mobile threat data into security reporting systems and processes. Using Zimperium’s vast integrations
1996
ecosystem, mobile device state, security posture, events, etc. are shared, enabling multimodal
1997
protections to be automatically deployed, including “conditional access” to sensitive information via
1998
MDM/UEMs, SOAR, and IAM, for example. Zimperium MTD protects devices against all primary attack
1999
vectors, including via USB and removable storage, and even when the device is not connected to a
2000
network.
2001
3.4.25 Zscaler
2002
Zscaler provides secure user access to public-facing sites and on- or off-premises private applications via
2003
the Zscaler Zero Trust Exchange, a cloud-delivered security service edge technology. The Zero Trust
2004
Exchange helps IT move away from legacy network infrastructure to achieve modern workforce
2005
enablement, infrastructure modernization, and security transformation.
2006
Zscaler’s role in the ZTA is to provide full visibility and control of context-based, least-privilege access to
2007
internet and SaaS applications as well as private applications in Infrastructure as a Service (IaaS),
2008
Platform as a Service (PaaS), or internally hosted environments via the Zero Trust Exchange.
2009
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 52
3.4.25.1 Zscaler Zero Trust Exchange
2010
Users accessing the internet or a SaaS application can leverage the Zscaler Internet Access (ZIA)
2011
solution. This solution delivers a comprehensive security stack—including TLS inspection, advanced
2012
firewall, SWG, DLP, virus protection, and sandbox capabilities—for end users, which follows them no
2013
matter where they are.
2014
Users accessing private applications either locally or in the cloud can leverage the Zscaler Private Access
2015
(ZPA) solution, which also provides a virtual PDP+PEP in the cloud.
2016
The Zscaler Client Connector brokers access for both ZIA and ZPA, offering lightweight single-agent
2017
protection and visibility, as well as optionally gathering telemetry for end-user experience monitoring.
2018
Combining ZIA and ZPA provides a FedRAMP-accredited solution that organizations can integrate into
2019
their unique digital ecosystems today. Moreover, since Zscaler is an integral part of any zero trust
2020
framework, organizations can leverage Zscaler’s cloud service provider, EDR, SIEM/SOAR, and software-
2021
defined wide area network (SD-WAN) integration partnerships with Microsoft, AWS, Okta, CrowdStrike,
2022
and other industry leaders to promote data visibility and access management.
2023
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 53
4 Architecture
2024
The project architecture is designed to include the core zero trust logical components as depicted in
2025
NIST SP 800-207. In Section 4.1 we present a general ZTA and describe its components and operation.
2026
These components may be operated as either on-premises or cloud-based services.
2027
In Section 4.2 we describe a particular version of this general ZTA that we call the EIG crawl phase
2028
reference architecture. Three of the ZTA builds that are documented in this practice guide are
2029
instantiations of this EIG crawl phase reference architecture. This architecture relies mainly on ICAM and
2030
endpoint protection platform (EPP) components, does not include any components that are specifically
2031
dedicated to providing PE or PA functionality, and is currently limited to protecting on-premises
2032
resources.
2033
In Section 4.3 we describe a second version of the general ZTA that we call the EIG run phase reference
2034
architecture. Three of the ZTA builds that are documented in this practice guide are instantiations of this
2035
EIG run phase reference architecture. Like the EIG crawl phase architecture, the EIG run phase
2036
architecture bases resource access decisions mainly on information provided by ICAM and EPP
2037
components. However, unlike the EIG crawl phase architecture, it may include PA and PE components
2038
that are not furnished by the ICAM provider. The EIG run phase architecture also protects both on-
2039
premises and cloud resources, and it supports device discovery and the establishment of tunnels
2040
between requesting endpoints and resources.
2041
In Section 4.4 we list the builds that are based on the SDP and microsegmentation deployment models.
2042
In Section 4.5 we describe the physical architecture of the baseline laboratory environment in which we
2043
implemented all of the builds documented in this guide.
2044
In Section 4.6 we describe the set of Phase 0 security analytics tools that we deployed to augment the
2045
set of shared services and conventional security tools that were deployed as part of our baseline
2046
environment.
2047
Volume B will be updated throughout the project lifecycle as the architecture evolves to include
2048
additional functionalities, security capabilities, and builds.
2049
4.1 General ZTA Reference Architecture
2050
Figure 4-1 depicts the high-level logical architecture of a general ZTA reference design independent of
2051
deployment models. It consists of three types of core components: PEs, PAs, and PEPs, as well as several
2052
supporting components that assist the policy engine in making its decisions by providing data and policy
2053
rules related to areas such as ICAM, endpoint security, security analytics, data security, and resource
2054
protection. Specific capabilities that fall into each of these supporting component categories are
2055
discussed in more detail later in this section. The various sets of information either generated via policy
2056
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 54
or collected by the supporting components and used as input to ZTA policy decisions are referred to as
2057
policy information points (PIPs). Each of the logical components in the reference architecture does not
2058
necessarily directly correlate to physical (hardware or software) components. In fact, although the
2059
simplicity of the architecture may seem to imply that the supporting components are simple plug-ins
2060
that respond in real-time to the PDP, in many cases the ICAM, EDR/EPP, security analytics, and data
2061
security PIPs will each represent complex infrastructures. Some ZTA logical component functions may be
2062
performed by multiple hardware or software components, or a single software component may perform
2063
multiple logical functions.
2064
Subjects (devices, end users, applications, servers, and other non-human entities that request
2065
information from resources) request and receive access to enterprise resources via the ZTA. Human
2066
subjects (i.e., users) are authenticated. Non-human subjects are both authenticated and protected by
2067
endpoint security. Enterprise resources may be located on-premises or in the cloud. Existing enterprise
2068
subjects and resources are not part of the reference architecture itself; however, any changes required
2069
to existing endpoints, such as installing ZTA agents, should be considered part of the reference
2070
architecture.
2071
Figure 4-1 General ZTA Reference Architecture
2072
Supporting Components
Policy Information
Points (PIPs)
Data Security
Endpoint Security
ICAM
Security Analytics
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B)/R(B). Information needed
to continually evaluate access
I(4).
Allow/
deny
access
R(1). Authenticate and validate resource
S(C). Continue/revoke/limit
session access
R(C). Revoke/limit resource
access
S(A)/R(A).
Access
requests; info
needed to
periodically
verify subject,
resource, and
endpoints
R(D). Periodic resource reauthentication
challenge/response and endpoint hygiene
verification
I(N): Initial Connection
S(X): Session Management
R(X): Resource Management
Policy Engine(s) (PEs)
Policy Administrator(s)
(PAs)
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Cloud
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 55
4.1.1 ZTA Core Components
2073
The types of ZTA core components are:
2074
▪ Policy Engine (PE): The PE handles the ultimate decision to grant, deny, or revoke access to a
2075
resource for a given subject. The PE calculates the trust scores/confidence levels and ultimate
2076
access decisions based on enterprise policy and information from supporting components. The
2077
PE executes its trust algorithm to evaluate each resource request it receives. The PE may be a
2078
single system or a federation of systems (i.e., a “system of systems”) that covers sectors of the
2079
ZTA. Each PE in the federation would be responsible for its sector based on the overall set of
2080
enterprise policies.
2081
▪ Policy Administrator (PA): The PA executes the PE’s policy decision by sending commands to the
2082
PEP to establish and terminate the communications path between the subject and the resource.
2083
It generates any session-specific authentication and authorization token or credential used by
2084
the subject to access the enterprise resource.
2085
▪ Policy Enforcement Point (PEP): The PEP guards the trust zone that hosts one or more
2086
enterprise resources. It handles enabling, monitoring, and eventually terminating connections
2087
between subjects and enterprise resources. It operates based on commands that it receives
2088
from the PA.
2089
When combined, the functions of the PE and PA comprise a PDP. The PDP is where the decision as to
2090
whether or not to permit a subject to access a resource is made. The PIPs provide various types of
2091
telemetry and other information needed for the PDP to make informed access decisions. The PEP is the
2092
location at which this access decision is enforced.
2093
Three approaches for how an enterprise can enact a ZTA for workflows can be supported by the
2094
architecture represented in Figure 4-1: use of EIG, microsegmentation, and SDP. If the
2095
microsegmentation approach is used, then when the PEP grants a subject access to a resource, it
2096
permits the subject to gain access to the unique network segment on which the resource resides. If the
2097
SDP approach is used, then when the PE decides to grant a subject access to a resource, the PA often
2098
acts like a network controller by setting up a secure channel between the subject and the resource via
2099
the PEP.
2100
4.1.2 ZTA Supporting Components
2101
The various sets of information either generated via policy or collected by the ZTA supporting
2102
components and used as input to ZTA policy decisions are referred to as PIPs.
2103
We have organized the ZTA supporting components and policy information points into five major
2104
categories: ICAM, Endpoint Security, Data Security, Security Analytics, and Resource Protection. These
2105
five categories and the various ZTA components that fall into each are listed below. There is also a sixth
2106
category of components found in our builds but they are not, strictly speaking, considered to be part of
2107
the ZTA. We categorize these components as General. General components include virtualized
2108
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 56
infrastructure, cloud infrastructure, endpoints, applications, etc. The other five categories of ZTA
2109
supporting components are:
2110
▪ ICAM: ICAM components include the strategy, technology, and governance for creating, storing,
2111
and managing subject (e.g., enterprise user) accounts and identity records and their access to
2112
enterprise resources. Aspects of ICAM include:
2113
• Identity management – Creation and management of enterprise user and device accounts,
2114
identity records, role information, and access attributes that form the basis of access
2115
decisions within an organization to ensure the correct subjects have the appropriate access
2116
to the correct resources at the appropriate time. This includes least privilege management,
2117
i.e., ensuring that the subject performing the access is given just enough privileges at the
2118
time they are needed to complete the task at hand and then removing those privileges to
2119
ensure that subjects do not have privileges that are not required. This concept can be
2120
characterized as just-enough and just-in-time access rights.
2121
• Access and credential management – Use of authentication (e.g., SSO and MFA) to verify
2122
subject identity and authorization to manage access to resources. This includes continuous
2123
access evaluation, i.e., repeatedly authenticating subjects and verifying their access to
2124
resources on an ongoing basis throughout an access session. This includes use of risk-based
2125
conditional access to trigger MFA when required to increase barriers against suspicious and
2126
unpermitted use and to reduce friction for low-risk permitted use.
2127
• Federated identity – Aggregation and correlation of all attributes relating to an identity or
2128
object that is being authorized by a ZTA. It enables users of one domain to securely access
2129
data or systems of another domain seamlessly, and without the need for completely
2130
redundant user administration. Federated identity encompasses the traditional ICAM data,
2131
supports identities that may be part of a larger federated ICAM community, and may
2132
include non-enterprise employees. Guidelines for the use of federated identity are
2133
discussed in NIST SP 800-63C, Digital Identity Guidelines [12].
2134
• Identity governance – Use of policy-based centralized automated processes to manage
2135
user identity and access control functions (e.g., segregation of duties, role management,
2136
logging, access reviews, auditing, analytics, reporting) to ensure compliance with
2137
requirements and regulations.
2138
• Multi-factor authentication – Grant a user access to a resource only after successfully
2139
presenting two or more pieces of evidence (factors) to an authentication mechanism.
2140
▪ Endpoint Security
2141
• EDR/EPP – The strategy, technology, and governance to protect endpoints (e.g., servers,
2142
desktops, mobile phones, IoT devices, and other non-human devices) and their data from
2143
threats and attacks, as well as protect the enterprise from threats from managed and
2144
unmanaged devices. In some cases, extended detection and response (XDR) solutions may
2145
be used that consolidate multiple EDR/EPP, network monitoring, and other security tools
2146
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 57
into a unified security solution. Such a unified solution provides automated monitoring,
2147
analysis, detection, and remediation for the purpose of improving detection accuracy while
2148
simultaneously improving efficiency of security operations and remediation. Some EDR/EPP
2149
solutions may depend on EDR/EPP agents being installed on endpoints while other
2150
solutions may be agentless. Aspects of endpoint protection may include:
2151
▪ Host firewall – Preventing the individual endpoint from receiving traffic that is not
2152
explicitly permitted, thereby helping to protect the endpoint from receiving malware
2153
and other malicious traffic
2154
▪ Malware protection – Scanning endpoint software for signatures that belong to known
2155
malware or using non-signature-based offerings that may use ML or AI to detect
2156
malicious code; if detected, disabling the malware, quarantining and repairing infected
2157
files if possible, and providing alerts that include any available remediation and
2158
mitigation recommendations
2159
▪ Vulnerability/threat mitigation – Monitoring endpoint software and configurations to
2160
detect known vulnerabilities and, when found, providing alerts that include
2161
remediation and mitigation recommendations, if available
2162
▪ Host intrusion protection – Monitoring an endpoint for suspicious activity that may
2163
indicate an attempted intrusion, infection, or other malware; stopping malicious
2164
activity on the endpoint, notifying potential victims, logging the suspicious events, and
2165
stopping future traffic from suspicious sources
2166
• Unified endpoint management (UEM)/mobile device management (MDM) – Technologies
2167
used to secure and manage a wide range of employee devices and operating systems from
2168
a single console, including both mobile and non-mobile endpoints. UEM/MDM tools
2169
manage and administer mobile, desktop, and laptop devices to ensure that they are secure.
2170
They provision software to devices in accordance with enterprise security policies to
2171
monitor behavior and critical data on the device, thereby protecting the device’s
2172
applications, data, and content and enabling the device to be tracked, monitored,
2173
troubleshooted, and wiped, if necessary. Aspects of UEM/MDM may include:
2174
▪ Endpoint compliance – Ensuring that an endpoint contains the hardware, firmware,
2175
software, and configurations required by enterprise policy and includes nothing
2176
unauthorized by enterprise policy. Guidelines for validating the integrity of computing
2177
devices are discussed in NIST SP 1800-34, Validating the Integrity of Computing
2178
Devices. Endpoint compliance may also be provided by a component that is separate
2179
from a UEM/MDM.
2180
▪ Application protection – Managing and protecting data within an application by
2181
enforcing protection policies that apply to the application
2182
▪ Data protection enforcement – Ensuring that data stored on the device is protected in
2183
accordance with enterprise policies
2184
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 58
• Continuous diagnostics and mitigation (CDM) – Gathering information about enterprise
2185
assets and their current state and applying updates to configuration and software
2186
components. A CDM system provides information to the policy engine about the asset
2187
making the access request. Guidelines for applying patches and updates are discussed in
2188
NIST SP 1800-31, Improving Enterprise Patching for General IT Systems: Utilizing Existing
2189
Tools and Performing Processes in Better Ways.
2190
▪ Data Security: The data security component includes the policies that an enterprise needs to
2191
secure access to enterprise resources, as well as the means to protect data at rest and in transit.
2192
Aspects of data security include the following capabilities:
2193
• Data discovery – Scanning and classifying digital assets, including unstructured data
2194
• Data classification and labeling – Describing an organization’s data security levels to the
2195
system and applying those labels to the data (note that classification and labeling are
2196
considered out of scope for this project, so these capabilities were exercised only to the
2197
extent necessary to demonstrate access enforcement)
2198
• Data encryption – Protecting data from unauthorized disclosure while at rest and in transit;
2199
ability to encrypt/watermark data as needed to protect it on user devices and/or to
2200
prevent tampering
2201
• Data integrity – Protecting data from unauthorized modification while at rest and in transit
2202
• Data availability – Protecting the ability of authorized users to access data in a timely
2203
manner and guarding against unauthorized deletion
2204
• Data access protection – Restricting access to/actions on data based on permanent or
2205
transient attributes of the entity accessing the data, with the ability to revoke access as
2206
needed. Includes all data access policies and rules needed to secure access to enterprise
2207
information and resources.
2208
• Auditing and compliance – Proving that the data security policies are in effect and
2209
delivering the desired protections
2210
▪ Security Analytics: The security analytics component encompasses all the threat intelligence
2211
feeds and traffic/activity monitoring for an IT enterprise. It gathers security and behavior
2212
analytics about the current state of enterprise assets and continuously monitors those assets to
2213
actively respond to threats or malicious activity. This information could feed the policy engine to
2214
help make dynamic access decisions. Aspects of security analytics include:
2215
• SIEM – Collect and consolidate security information and security event data from many
2216
sources; correlate and analyze the data to help detect anomalies and recognize potential
2217
threats and vulnerabilities; log the data to adhere to data compliance requirements
2218
• SOAR – Collect and monitor alerts from the SIEM and other security systems, and execute
2219
predefined incident response workflows to automatically analyze the information and
2220
orchestrate the operations required to respond
2221
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 59
• Vulnerability scanning and assessment – Scan and assess enterprise infrastructure and
2222
resources for security risks, identify vulnerabilities and misconfigurations, and provide
2223
remediation guidance regarding investigating and prioritizing responses to incidents
2224
• Network discovery – Discover, classify, and assess the risk posed by devices and users on
2225
the network
2226
• Security controls validation – Validate the ZTA cybersecurity controls implemented
2227
through visibility into network traffic and transaction flows
2228
• Identity monitoring – Monitor the identity of subjects to detect and send alerts for
2229
indicators that user accounts or credentials may be compromised, or to detect sign-in risks
2230
for a particular access session
2231
• Security monitoring – Monitor and detect malicious or suspicious user actions based on
2232
directory signals
2233
• Application protection and response – Protect specific applications from phishing, spam,
2234
malware, and other attacks
2235
• Cloud access permission manager – Provide visibility and control of permissions used by
2236
identities in various cloud services
2237
• Security analytics and access monitoring – Monitor cloud resource access sessions for
2238
conformance to policy
2239
• Network monitoring – Aggregate and analyze network telemetry—information generated
2240
by network devices—to provide network visibility to detect and respond to threats on-
2241
premises and in the cloud
2242
• Traffic inspection – Intercept, examine, and record relevant traffic transmitted on the
2243
network. Not all communication may be intercepted and not all intercepted traffic may be
2244
subject to the same level of examination (e.g., deep packet inspection, only metadata
2245
analysis) depending on policy or capability.
2246
• Endpoint monitoring – Discover all IP-connected endpoints and continuously collect,
2247
examine, and analyze software versions, configurations, and other information regarding
2248
hosts (devices or VMs) that are connected to the network
2249
• Threat intelligence – Use information regarding known existing or emerging vulnerabilities,
2250
attacks, and other menaces to enterprise operations and assets to inform decisions
2251
regarding how to defend against and respond to those threats
2252
• User behavior analytics – Monitor and analyze user behavior to detect unusual patterns or
2253
anomalies that might indicate an attack
2254
• Firmware assurance – Continuously monitor IT device firmware
2255
▪ Resource Protection: This category includes build components that do not fit neatly into one of
2256
the four supporting component/PIP categories enumerated above. They include components
2257
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 60
that are deployed on-premises or in the cloud to serve as proxies for a resource or otherwise
2258
protect it through monitoring and control, as well as secure desktops and workstations.
2259
• Application connector - Component that is deployed to be the front-end for an internal
2260
resource (whether located on-premises or in the cloud) and act as a proxy for it. Enables
2261
access to a resource to be controlled without requiring the resource to be visible on the
2262
network.
2263
• Cloud workload protection – Secure cloud workloads to protect them from known security
2264
risks, monitors traffic to and from cloud and web applications to prevent sensitive
2265
information from leaving, and provides alerts to enable real-time reaction
2266
• Cloud security posture management – Continually assess the security posture of cloud
2267
resources
2268
4.1.3 ZTA in Operation
2269
Figure 4-1 depicts the general, high-level ZTA reference architecture. If an enterprise has highly
2270
distributed systems, it may have many PEPs to protect resources in different locations; it may also have
2271
multiple PEPs to support load balancing. For simplicity, Figure 4-1 limits its focus to the interactions
2272
involving a single PEP, a single subject, and a single resource. The labeled arrows in Figure 4-1 depict the
2273
high-level steps performed in support of the ZTA reference architecture. These steps can be understood
2274
in terms of three separate processes:
2275
▪ Resource Management—R(): Resource management steps ensure that the resource is
2276
authenticated and that its endpoint conforms to enterprise policy. Upon first being brought
2277
online, a resource’s identity is authenticated and its endpoint hygiene (i.e., health) is verified.
2278
The resource is then connected to the PEP. Once connected to the PEP, access to the resource is
2279
granted only through that PEP at the discretion of the PDP. For as long as the resource continues
2280
to be online, resource management steps are performed to periodically reauthenticate the
2281
resource and verify its endpoint hygiene, thereby continually monitoring its health. These steps
2282
are labeled R(1) and R(A) through R(D). Step R(1) occurs first, but the other steps do not
2283
necessarily occur in any specific order with respect to each other, which is why they are labeled
2284
with letters instead of numbers. Their invocation is determined by enterprise policy. For
2285
example, enterprise policy determines how frequently the resource is reauthenticated, what
2286
resource-related information the PDP needs to evaluate each access request and when it needs
2287
it, and what resource-related changes (environmental, security analytics, etc.) would cause the
2288
PDP to decide to revoke or limit access to a particular resource.
2289
▪ Session Establishment Steps—I(): Session establishment steps are a sequence of actions that
2290
culminate in the establishment of the initial session between a subject and the resource to
2291
which it has requested access. These steps are labeled I(1) through I(5) and they occur in
2292
sequential order.
2293
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 61
▪ Session Management Steps—S(): Session management steps describe the actions that enable
2294
the PDP to continually evaluate the session once it has been established. These steps begin to
2295
be performed after the session has been established, i.e., after Step I(5), and they continue to
2296
be invoked periodically for as long as the session remains active. These steps are labeled S(A)
2297
through S(D) so that they can be distinguished from each other. However, the letters A through
2298
D in the labels are not meant to imply an ordering. The session management steps do not
2299
necessarily occur in any specific order with respect to each other. Their invocation is determined
2300
by the access requests that are made by the subject in combination with enterprise policy. For
2301
example, enterprise policy determines how frequently the subject is reauthenticated, what
2302
information the PDP needs to evaluate each access request and when it needs it, and what
2303
changes (environmental, security analytics, etc.) would cause the PDP to decide to deny a
2304
particular access request or terminate an established session altogether.
2305
The following additional details describe each of the steps in each of the three processes depicted in
2306
Figure 4-1:
2307
Resource Management
2308
▪ Step R(1). Authenticate and validate resource: In our model, it is assumed that the resource has
2309
already been registered as an authorized resource. Initially, when the resource is brought online,
2310
its identity must be authenticated and its endpoint hygiene must be validated to ensure
2311
compliance. This authentication and validation could be accomplished by a variety of
2312
mechanisms, such as the ICAM and EPP capabilities, the PEP itself, or a connector. The diagram
2313
is not concerned with depicting how it is authenticated, just that the authentication and
2314
validation are performed.
2315
In some implementations, in order for the resource to communicate with the service provider
2316
where the PEP is located, a connector or proxy may need to be installed to enable that
2317
connection to the service provider. For example, a database in an existing enterprise may not
2318
currently have the capability to interact with a service provider PEP directly. To make this
2319
communication possible, a connector, which behaves like a proxy module, may be installed
2320
between the resource and the PEP. There are multiple possible types of connectors and ways of
2321
connecting. This level of detail (i.e., whether a connector is present and, if so, what type) is not
2322
shown in the figure. Authentication and validation of the resource and connection of the
2323
resource to the PEP must be completed prior to any users requesting access.
2324
▪ Step R(A). Information needed to periodically verify resource and endpoint: Throughout the
2325
lifetime of the session, the PEP will periodically challenge the resource to reauthenticate itself.
2326
After doing so, the PEP will provide the PDP with the identity and credentials that the resource
2327
provided. Similarly, throughout the lifetime of the session, the PEP will request hygiene
2328
information from the resource’s endpoint. After obtaining this hygiene information, the PEP will
2329
provide it to the PDP. The frequency with which the resource should be issued authentication
2330
challenges is determined by enterprise policy, as is the frequency with which the hygiene of its
2331
endpoint should be validated.
2332
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 62
▪ Step R(B). Information needed to continually evaluate access: Throughout the course of the
2333
access session, the PDP requests and receives any resource-related information that it needs to
2334
evaluate the resource’s ongoing compliance with enterprise policy. This could include
2335
information such as authentication information provided by the ICAM system, endpoint hygiene
2336
information provided by the EPP, and anomaly detection analysis regarding resource behavior
2337
provided by logging and security analytics functionality.
2338
▪ Step R(C). Revoke/limit resource access: The connection between the PEP and the resource
2339
may be terminated or reconfigured based on changes to the resource or operating environment
2340
that indicate the resource no longer conforms to enterprise policy.
2341
▪ Step R(D). Periodic resource reauthentication challenge/response and endpoint hygiene
2342
verification: The resource undergoes continual reauthentication and hygiene checks to ensure
2343
that its security posture conforms to enterprise policy. These actions are usually taken by the
2344
various systems that may make up the PDP and are performed regardless of any current open
2345
sessions. The frequency with which reauthentication and hygiene checks are performed is
2346
determined by enterprise policy.
2347
Session Establishment
2348
▪ Step I(1). Initial access request (identity and credentials): The subject interacts with the PEP to
2349
request access to the resource and provide its identity and credentials.
2350
▪ Step I(2). Information needed to verify subject and its endpoint: The PEP forwards the subject’s
2351
identity and credentials to the PE within the PDP.
2352
▪ Step I(3). Information needed to approve/deny access request: The PE requests and receives
2353
any additional information that it needs to determine whether it should approve or deny the
2354
subject’s access request. This includes information provided by the various supporting
2355
components of the ZTA. ICAM-related information is used most heavily, i.e., user and endpoint
2356
identity, authorization (i.e., subject privileges), federation, and identity governance information;
2357
but additional information from other ZTA supporting components, e.g., endpoint compliance,
2358
endpoint monitoring, and threat intelligence, may also be relied upon as specified by enterprise
2359
policy. The PIPs depicted in Figure 4-1 represent the collection of information required by the PE
2360
to decide, in accordance with enterprise policy, whether or not to grant the access request. The
2361
PE authenticates the subject, determines what the subject’s authorizations are, and evaluates
2362
additional information as needed to determine whether to allow or deny the subject access to
2363
the requested resource.
2364
▪ Step I(4). Allow/deny access: The PDP informs the PEP whether to allow or deny the subject
2365
access to the resource.
2366
▪ Step I(5). Session: Assuming the PDP has decided to allow access, the PEP establishes a session
2367
between the subject and the resource through which the subject can access the resource. At the
2368
completion of Step I(5), the session is set up and the session management processes begin being
2369
performed.
2370
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 63
Session Management
2371
Once the session has been established, several session management processes are performed
2372
simultaneously on an ongoing basis for the duration of the session. The session management processes
2373
depicted in Figure 4-1 include ongoing evaluation of each of the subject’s access requests, ongoing
2374
continual evaluation of the session, periodic reauthentication of the subject, and periodic verification of
2375
the subject’s endpoint hygiene. These processes are described below.
2376
Ongoing evaluation of the access requests made by the subject: The steps of this process are depicted
2377
by steps S(A), S(B), and S(C) in Figure 4-1.
2378
▪ Step S(A). Access requests: Throughout the course of the access session, the actions that the
2379
subject sends to the resource are monitored by the PEP and sent to the PDP for evaluation as to
2380
whether the access should continue. When TLS or another form of encryption is used to secure
2381
the session between the subject and the resource, it is not possible for a PEP that is situated in
2382
the middle of that connection to have visibility into the messages that the subject is sending
2383
because they are encrypted. The PEP must have access to the necessary unencrypted traffic
2384
needed in order to provide the PDP with the necessary information to make the access decision.
2385
The PEP may have full access to monitor the session traffic or may rely on another system
2386
(including the resource itself) to monitor the session activity. To enable the access session to be
2387
continuously monitored by the PEP, the PEP could be situated adjacent to the subject so it can
2388
receive unencrypted requests from the subject and send them to the PDP for monitoring before
2389
forwarding them over the encrypted access session to the resource; the PEP could be situated
2390
adjacent to the resource so it can decrypt requests it receives from the subject on the access
2391
session and send them to the PDP for monitoring before forwarding them to the resource; or
2392
the PEP could be located elsewhere and have plaintext requests forwarded to it that it would
2393
then send to the PDP for monitoring. Because there are many possible ways the monitoring
2394
could be accomplished, Figure 4-1 does not attempt to depict where the access session is
2395
terminated with respect to the PEP. It is only meant to convey the fact that the subject’s access
2396
requests are monitored on an ongoing basis and forwarded to the PDP for evaluation.
2397
▪ Step S(B). Information needed to continually evaluate access: Throughout the course of the
2398
access session, the PDP requests and receives any additional information from the PIP that it
2399
needs to evaluate the subject’s ongoing access to determine whether it should continue. This
2400
information is provided by the various ZTA supporting components in the architecture.
2401
Examples of such information include subject identity information provided by ICAM
2402
functionality, subject endpoint hygiene information provided by endpoint security functionality,
2403
and behavioral analysis (e.g., whether the subject has attempted to elevate privileges beyond
2404
what is authorized) and anomaly detection information provided by logging and security
2405
analytics functionality. Evaluation of the access requests is performed in accordance with
2406
enterprise policy.
2407
▪ Step S(C). Continue/revoke/limit session access: If the PDP determines that the access should
2408
continue, it will allow the PEP to forward the access request made in step S(A) to the resource.
2409
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 64
However, if the PDP determines that, in light of the information received from the PIP (e.g.,
2410
federated identity, endpoint security information, security analytics), the session should be
2411
terminated or limited, the PDP may inform the PEP not to forward the action to the resource.
2412
Note that in an ideal world, the PEP would wait for the PDP to pass judgement on every request
2413
that is made on a session before forwarding each request to the resource. However, in reality,
2414
the cost of having the PDP evaluate every individual request in real time may be too great. In
2415
most cases the PEP would have a set of rules determining allowed requests and (possibly) a set
2416
of policies on when to require reauthentication or additional checks before forwarding requests
2417
to the resource.
2418
Ongoing continual evaluation of the session: The steps of this process are depicted by steps S(B) and
2419
S(C) in Figure 4-1.
2420
▪ Step S(B). Information needed to continually evaluate access: Throughout the course of the
2421
access session, the information in the PIPs is updated by the various ZTA supporting
2422
components and made available to the PDP so it can dynamically evaluate whether the session
2423
continues to be in accordance with enterprise policy. At any moment, information could
2424
become available that causes the session to be non-compliant. For example, threat intelligence
2425
information could be received regarding vulnerabilities in the endpoint or software used by the
2426
subject, anomalies could be detected in the subject’s behavior (e.g., attempts to elevate access),
2427
or the subject could fail authentication when trying to access a different resource.
2428
▪ Step S(C). Continue/revoke/limit session access: If the PDP determines that the ongoing access
2429
session continues to be compliant, it will permit it to continue. However, if the PDP determines
2430
that, based on information available from the PIPs (e.g., endpoint security information, threat
2431
intelligence, security analytics), the access session should be limited or revoked, the PDP will
2432
direct the PEP to deny some requests that are made on the session or to disconnect the session
2433
altogether.
2434
Periodic reauthentication of the subject and periodic verification of the hygiene of the subject
2435
endpoint: These are two separate and distinct processes, but they are depicted by the same steps in
2436
Figure 4-1, steps S(A), S(D), and S(C), so we will discuss them together:
2437
▪ Step S(A). Information needed to periodically verify subject and endpoint: Throughout the
2438
lifetime of the session, the PDP will periodically notify the PEP to challenge the subject to
2439
reauthenticate itself. After doing so, the PEP will provide the PDP with the identity and
2440
credentials that the subject provided. Similarly, throughout the lifetime of the session, the PDP
2441
will periodically notify the PEP to request hygiene information from the subject’s endpoint,
2442
operating environment, etc. After obtaining this hygiene information, the PEP will provide it to
2443
the PDP. The frequency with which the subject should be issued authentication challenges is
2444
determined by enterprise policy, as is the frequency with which the hygiene of the subject
2445
endpoint should be validated.
2446
▪ Step S(D). Periodic reauthentication challenge/response and endpoint hygiene verification: As
2447
directed by the PDP in step S(A), the PEP periodically issues reauthentication challenges to the
2448
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 65
subject. It also periodically requests and receives endpoint hygiene (software, configuration,
2449
etc.) information. The frequency with which each of these types of information is requested is
2450
specified by enterprise policy.
2451
▪ Step S(C). Continue/revoke/limit session access: Based on the subject identity and credential
2452
information received and/or on the endpoint hygiene information received, the PDP determines
2453
whether to permit the access session to continue. If at any time the reauthentication of the
2454
subject fails or if the subject’s endpoint hygiene cannot be satisfactorily verified (as determined
2455
by policy), the PDP will direct the PEP to disconnect or limit the session.
2456
4.2 EIG Crawl Phase Reference Architecture
2457
The reference architecture depicted in Figure 4-1 is intentionally general and is not meant to describe
2458
any particular ZTA deployment approach. This project has implemented all three deployment
2459
approaches described in NIST SP 800-207, Zero Trust Architecture: EIG, microsegmentation, and SDP.
2460
The EIG approach to developing a ZTA uses the identity of subjects as the key component of policy
2461
creation. Access privileges granted to the given subject is the main requirement for resource access.
2462
Other factors such as device used, endpoint hygiene and status, and environmental factors may also
2463
impact whether and what access is authorized.
2464
This section of the practice guide documents the reference architecture of the builds that were created
2465
in the project’s EIG crawl phase. The crawl phase used what we call an EIG crawl phase deployment
2466
approach. Figure 4-2 depicts the reference architecture for this approach. The EIG crawl phase reference
2467
architecture, as its name suggests, uses a subject’s identity and its access privileges as the main
2468
determinants for granting resource access, along with the endpoint used and its hygiene status. Hence,
2469
as can be seen in Figure 4-2, the reference architecture for this EIG crawl phase build includes ICAM and
2470
endpoint protection components. In the area of ICAM, it supports capabilities in all the four main areas
2471
of identity management, access and credential management, federated identity, and identity
2472
governance.
2473
The labeled steps in Figure 4-2 are the same as those in Figure 4-1. The main difference between the
2474
two figures can be found in the set of supporting components that have been included. The EIG crawl
2475
phase reference architecture depicted in Figure 4-2 is a constrained form of the general ZTA reference
2476
architecture in Figure 4-1. The EIG crawl phase reference architecture relies on the PE and PA
2477
capabilities provided by its ICAM components. Also, the only security analytics functionality that it
2478
includes is a SIEM. It does not include any additional data security or security analytics functionality.
2479
These limitations were intentionally placed on the architecture with the goal of demonstrating the ZTA
2480
functionality that an enterprise with legacy ICAM and endpoint protection solutions deployed will be
2481
able to support without having to add ZTA-specific capabilities.
2482
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 66
Figure 4-2 EIG Crawl Phase Reference Architecture
2483
2484
Three EIG crawl phase builds have been implemented. Each of these EIG crawl phase builds instantiates
2485
the architecture that is depicted in Figure 4-2 in a unique way, depending on the equipment used and
2486
the capabilities supported. The products used in each build were based on having out-of-box
2487
integration. Briefly, the three builds are as follows:
2488
▪ Enterprise 1 Build 1 (E1B1) uses products from Amazon Web Services, IBM, Ivanti, Mandiant,
2489
Okta, Radiant Logic, SailPoint, Tenable, and Zimperium. Certificates from DigiCert are also used.
2490
▪ Enterprise 2 Build 1 (E2B1) uses products from Cisco Systems, IBM, Mandiant, Palo Alto
2491
Networks, Ping Identity, Radiant Logic, SailPoint, and Tenable. Certificates from DigiCert are also
2492
used.
2493
▪ Enterprise 3 Build 1 (E3B1) uses products from F5, Forescout, Lookout, Mandiant, Microsoft,
2494
Palo Alto Networks, PC Matic, and Tenable. Certificates from DigiCert are also used.
2495
Each of these builds is described in detail in its own appendix (see Appendix D, Appendix E, and
2496
Appendix F).
2497
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B)/R(B). Information needed
to continually evaluate access
I(4).
Allow/
deny
access
R(1). Authenticate and validate resource
S(C). Continue/revoke/limit
session access
R(C). Revoke/limit resource
access
S(A)/R(A).
Access
requests; info
needed to
periodically
verify subject,
resource, and
endpoints
R(D). Periodic resource reauthentication
challenge/response and endpoint hygiene
verification
I(N): Initial Connection
S(X): Session Management
R(X): Resource Management
ICAM System’s PE
ICAM System’s PA
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Cloud
Policy Information Points
(PIPs)
Endpoint Security
Multi-Factor
Authentication (MFA)
Security Analytics
ICAM System’s PEPs
Other PEPs
Federated Identity
Identity Governance
Access and Credential
Management
Supporting Components
Identity Management
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 67
4.3 EIG Run Phase
2498
This section of the practice guide documents the builds that have been created in the project’s EIG run
2499
phase. The EIG run phase builds upon the EIG crawl phase architecture. The EIG run phase no longer
2500
imposes the requirement that the PE and PA components are provided by the ICAM products used in
2501
the build. It also adds capabilities to the EIG crawl phase. In addition to protecting access to resources
2502
that are located on-premises, the run phase protects access to some resources that are hosted in the
2503
cloud. The EIG run phase also includes a device discovery capability, which is performed as part of the
2504
baseline. In addition to monitoring and alerting when new devices are detected, enforcement can be
2505
enabled to deny access to devices that are not compliant. The run phase also includes the capability to
2506
establish a tunnel between the requesting endpoint and the resource being accessed over which access
2507
to the resource can be brokered.
2508
Three EIG run phase builds have been implemented. Each of these EIG run phase builds is unique, based
2509
on the equipment used and the capabilities supported. Briefly, the three builds are as follows:
2510
▪ Enterprise 1 Build 2 (E1B2) uses products from Amazon Web Services, IBM, Ivanti, Mandiant,
2511
Okta, Radiant Logic, SailPoint, Tenable, and Zscaler. Certificates from DigiCert are also used.
2512
▪ Enterprise 3 Build 2 (E3B2) uses products from F5, Forescout, Mandiant, Microsoft, Palo Alto
2513
Networks, PC Matic, and Tenable. Certificates from DigiCert are also used.
2514
▪ Enterprise 4 Build 3 (E4B3) uses products from IBM, Mandiant, Palo Alto Networks, Tenable,
2515
and VMware. Certificates from DigiCert are also used.
2516
Each of these builds is described in detail in its own appendix (see Appendix G, Appendix H, and
2517
Appendix L).
2518
4.4 SDP and Microsegmentation Builds
2519
Unlike the EIG crawl and run phase builds, which are based on a constrained version of the general
2520
reference architecture that is depicted in Figure 4-2, there are no constraints on the ZTA reference
2521
architecture when used as the underlying design for a build in the SDP or microsegmentation phase of
2522
the project. The SDP and microsegmentation phase builds that have been implemented as part of this
2523
project are based on the general ZTA described in Section 4.1.
2524
Two SDP builds have been implemented (E1B3 and E1B4), one microsegmentation (network) build has
2525
been implemented (E2B3), and one combined SDP and microsegmentation build has been implemented
2526
(E3B3). Each of these builds is unique, based on the equipment used and the capabilities supported.
2527
Briefly, the four builds are as follows:
2528
▪ Enterprise 1 Build 3 (E1B3) uses products from Amazon Web Services, IBM, Ivanti, Mandiant,
2529
Okta, Radiant Logic, SailPoint, Tenable, and Zscaler. Certificates from DigiCert are also used.
2530
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 68
▪ Enterprise 2 Build 3 (E2B3) uses products from Cisco Systems, IBM, Mandiant, Palo Alto
2531
Networks, Ping Identity, Radiant Logic, SailPoint, Tenable, and VMware. Certificates from
2532
DigiCert are also used.
2533
▪ Enterprise 3 Build 3 (E3B3) uses products from F5, Forescout, Mandiant, Microsoft, Palo Alto
2534
Networks, PC Matic, and Tenable. Certificates from DigiCert are also used.
2535
▪ Enterprise 1 Build 4 (E1B4) uses products from Amazon Web Services, Appgate, IBM, Ivanti,
2536
Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zimperium. Certificates from DigiCert are
2537
also used.
2538
Each of these builds is described in detail in its own appendix (see Appendix I, Appendix J, Appendix K,
2539
and Appendix M).
2540
4.5 ZTA Laboratory Physical Architecture
2541
Figure 4-3 depicts the high-level physical architecture of the ZTA laboratory environment, which is
2542
located at the NCCoE site. The NCCoE provides VM resources and physical infrastructure for the ZTA lab.
2543
It also hosts GitLab, which is used as a DevOps platform that stores Terraform and Ansible configuration
2544
information and provides version control for configuration file and change management activities. The
2545
NCCoE hosts all the collaborators’ ZTA-related software for Enterprises 1, 2, 3, and 4. The NCCoE also
2546
provides connectivity from the ZTA lab to the NIST Data Center, which provides connectivity to the
2547
internet and public IP spaces (both IPv4 and IPv6).
2548
Access to and from the ZTA lab from within ITOps is protected by a Palo Alto Networks Next Generation
2549
Firewall (PA-5250). (The brick box icons in Figure 4-3 represent firewalls.) The ZTA lab network
2550
infrastructure includes four independent enterprises (Enterprises 1, 2, 3, and 4), a branch office used
2551
only by Enterprise 1, a coffee shop that all enterprises can use, a management and orchestration
2552
domain, and an emulated WAN/internet service provider. The emulated WAN service provider provides
2553
connectivity among all the ZTA laboratory networks, i.e., among all the enterprises, the coffee shop, the
2554
branch office, and the management and orchestration domain. Another Palo Alto Networks PA-5250
2555
firewall that is split into separate virtual systems protects the network perimeters of each of the
2556
enterprises and the branch office. The emulated WAN service provider also connects the ZTA laboratory
2557
network to ITOps. The ZTA laboratory network has access to cloud services provided by AWS, Azure, and
2558
Google Cloud, as well as connectivity to SaaS services provided by various collaborators, all of which are
2559
available via the internet.
2560
Each enterprise within the NCCoE laboratory environment is protected by a firewall and has both IPv4
2561
and IPv6 (dual stack) configured. Each of the enterprises is equipped with a baseline architecture that is
2562
intended to represent the typical environment of an enterprise before a zero trust deployment model is
2563
instantiated.
2564
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 69
Figure 4-3 Physical Architecture of ZTA Lab
2565
The details of the baseline physical architecture of enterprise 1, enterprise 1 branch office, enterprises
2566
2, 3, and 4, the management and orchestration domain, and the coffee shop, as well as the baseline
2567
software running on this physical architecture are described in the subsections below. The details of
2568
each of the builds that occupy Enterprises 1, 2, 3, and 4 are provided in the appendices. Table 4-1 maps
2569
each build to the appendix where each is described.
2570
Table 4-1 Mapping of Builds to Architectures and Appendices
2571
Build
ZTA Architecture Instantiated
Appendix
E1B1
EIG Crawl
Appendix D
E2B1
EIG Crawl
Appendix E
E3B1
EIG Crawl
Appendix F
E1B2
EIG Run
Appendix G
E3B2
EIG Run
Appendix H
E1B3
SDP
Appendix I
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 70
Build
ZTA Architecture Instantiated
Appendix
E2B3
Microsegmentation (Network)
Appendix J
E3B3
SDP and Microsegmentation
Appendix K
E4B3
EIG Run
Appendix L
E1B4
SDP
Appendix M
4.5.1 Enterprise 1
2572
Figure 4-4 is a close-up of the high-level physical architecture of Enterprise 1 in the NCCoE laboratory
2573
baseline environment. Its components are described in the subsections below. See Appendix E, G, I, and
2574
L for detailed descriptions of the ZTA components used in the builds that have been implemented in
2575
Enterprise 1.
2576
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 71
Figure 4-4 Physical Architecture of Enterprise 1
2577
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 72
4.5.1.1 Firewall
2578
Enterprise 1, like Enterprise 3, Enterprise 1 Branch Office, and the management and orchestration
2579
domain, is protected by a Palo Alto Networks 5250 firewall. This is one physical firewall that provides
2580
independent virtual firewalls to protect each of the above domains. Each enterprise is configured with
2581
an autonomous ZTA solution set. These virtual firewalls provide firewall and gateway capabilities,
2582
support a site-to-site Internet Protocol Security (IPsec) connection between the Enterprise 1 Branch
2583
Office and Enterprise 1, provide a remote access VPN (Global Protect) to sites, filter traffic among
2584
various internal and external subnets, provide IPv4 and IPv6 routing, and block all inbound traffic unless
2585
explicitly allowed, e.g., for communication with cloud resources. These firewalls are integrated with AD
2586
to leverage the enterprise user directory store for their respective domains.
2587
4.5.1.2 Switch
2588
Enterprise 1 uses a Cisco C9300 multilayer switch to provide internal network connectivity within the
2589
enterprise. It provides layer 2/3 interfaces for each virtual local area network (VLAN) subnetwork with
2590
802.1q trunking. Both IPv4 and IPv6 addresses are assigned. This switch is integrated with the Remote
2591
Authentication Dial-In User Service (RADIUS) networking protocol to provide centralized authentication,
2592
authorization, and accounting (AAA) management for users requesting access to an Enterprise 1
2593
network service. The switch hosts physical wireless access points and allows connections for their virtual
2594
controllers. It also provides wired access for endpoints such as laptops within the lab.
2595
4.5.1.3 ZTA Components Specific to Enterprise 1
2596
Enterprise 1 contains VLANs that pertain specifically to enterprise 1’s ZTA build. See Appendix D for a
2597
detailed description of the ZTA components used in Enterprise 1 Build 1 (E1B1) and Appendix G for a
2598
detailed description of the ZTA components used in Enterprise 1 Build 2 (E1B2).
2599
4.5.1.4 Demilitarized Zone (DMZ) Subnet
2600
Enterprise 1’s demilitarized zone (DMZ) is a virtual subnet that separates the rest of the Enterprise 1
2601
network from the internet. The DMZ includes web applications and other services that Enterprise 1
2602
makes available to users on the public internet. For example, the DMZ subnet includes Jump-box
2603
Remote Desktop Server (RDS) and Secure Shell (SSH) protocol to provide some collaborators with
2604
remote access to Enterprise 1. It also includes applications such as Simple Mail Transfer Protocol (SMTP),
2605
NGINX Plus, and Apache Guacamole.
2606
4.5.1.5 Internal Corporate Subnet
2607
The internal corporate subnet is where applications that support Enterprise 1’s internal services reside.
2608
For example, the internal corporate subnet includes applications such as GitLab.
2609
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 73
4.5.1.6 Corporate User Subnet
2610
The corporate user subnet is where users and devices such as mobile devices (iOS and Android), tablets,
2611
Windows clients, macOS clients, Linux clients, and printers reside. Some of these devices are connected
2612
via wires to the C9300 switch, while others are connected via Wi-Fi using the Cisco AP 18321 wireless
2613
access point.
2614
4.5.1.7 Guest Subnet
2615
The guest subnet is where guests reside. Guests are users who don’t have any sort of network ID and are
2616
not authorized to access any enterprise resources. They use their own devices rather than corporate-
2617
owned or corporate-managed devices. Devices on the guest subnet include mobile devices, tablets,
2618
Windows clients, macOS clients, and Linux clients. The guest subnet allows for BYOD access, with all
2619
devices connecting via Wi-Fi using the Cisco AP 18321 wireless access point.
2620
4.5.1.8 Shared Services
2621
A closeup of the shared services domain of Enterprise 1 is depicted in Figure 4-5. The services it includes
2622
are discussed in the following subsections.
2623
Figure 4-5 Shared Services Domain of Enterprise 1
2624
4.5.1.8.1 Certificate Authority (CA)
2625
The CA provides certificate and cryptographic services for the enterprise. It is a Windows 2016 server
2626
using AD certificate services. A two-tier CA architecture is used, with an offline CA and an issuing AD-
2627
connected CA. The CA automatically issues and reissues certificates via AD group policy, and it can
2628
generate and issue certificates to AD domain-connected Windows devices. It issues certificates for both
2629
device authentication and web services using TLS.
2630
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 74
4.5.1.8.2 Active Directory (AD)
2631
AD provides centralized administration of users, computers, and resources. It runs on Windows 2016
2632
servers and uses multiple domain controllers to ensure high availability and redundancy in hot-hot
2633
mode. It also includes a built-in DNS authoritative server and resolver.
2634
4.5.1.8.3 Domain Name Server (DNS)
2635
DNS provides name-to-IP address mappings for internal hosts and answers to DNS queries of external
2636
hosts. It runs on a Windows 2016 server and is the authoritative server for the lab.nccoe.org internal
2637
domain. Internal DNS services are integrated with AD. DNS servers within ITOps are used as forwarders
2638
and to resolve DNS queries from external devices. Two DNS servers are used to ensure high availability
2639
and redundancy in hot-hot mode.
2640
4.5.1.8.4 Dynamic Host Configuration Protocol (DHCP)
2641
The Dynamic Host Configuration Protocol (DHCP) allocates and assigns IP address and configuration
2642
information to hosts. It runs on a Windows 2016 server and is integrated with AD. Two DHCP servers are
2643
used to ensure high availability and redundancy.
2644
4.5.1.8.5 RADIUS
2645
The RADIUS networking protocol is used to provide centralized AAA management services at the switch
2646
for users requesting access to Enterprise 1 network services. It runs on a Windows 2016 network policy
2647
server (NPS) and is integrated with AD.
2648
4.5.1.8.6 Access Point (AP) Controller
2649
The access point controller manages the enterprise’s wireless access points. It runs on a Cisco virtual
2650
wireless controller. It manages two APs: models 1852I and 1832I, one for the corporate user subnet and
2651
one for the guest subnet.
2652
4.5.1.8.7 SSH File Transfer Protocol (SFTP)
2653
SFTP is used to provide secure file transfer services. It runs on a Windows 2016 server.
2654
4.5.1.8.8 Network Time Protocol (NTP)
2655
NTP provides timing and clock synchronization between systems. It runs on a Windows 2019 server.
2656
4.5.1.8.9 Syslog
2657
Syslog is used to collect logs and diagnostic data. It runs on a Linux Ubuntu 20.04 platform.
2658
4.5.1.8.10 Windows Server Update Service (WSUS)
2659
Windows Server Update Service (WSUS) provides downloads and manages updates and patches for
2660
Windows servers. It runs on a Windows 2019 server.
2661
4.5.1.8.11 Server Message Block (SMB)
2662
Server Message Block (SMB) provides Windows file sharing services. It runs on a Windows 2019 server.
2663
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 75
4.5.1.8.12 Collaborator Products
2664
The shared services domain of Enterprise 1 also includes some collaborator products that provide
2665
shared services for the enterprise: IBM QRadar XDR, Tenable.ad, Tenable scanner, Tenable NNM, and
2666
Mandiant MSV Director.
2667
4.5.1.9 Baseline Applications
2668
The following applications were installed and configured as part of the baseline architecture to
2669
represent the types of applications that would be found in a typical brownfield enterprise environment.
2670
These applications serve as the enterprise resources to which the ZTA is managing access.
2671
4.5.1.9.1 Guacamole
2672
Apache Guacamole is a remote desktop solution that supports a wide range of protocols such as SSH
2673
and Remote Desktop Protocol (RDP).
2674
4.5.1.9.2 GitLab
2675
GitLab is a DevOps tool that allows software developers to develop, test, and operate software in one
2676
application. We used GitLab as an enterprise application being accessed by end users.
2677
4.5.1.9.3 NGINX Plus
2678
NGINX Plus provides HTTP, reverse proxy, and load balancer services.
2679
4.5.2 Enterprise 1 Branch Office
2680
Figure 4-6 is a closeup of the high-level level physical architecture of the Enterprise 1 Branch Office in
2681
the NCCoE laboratory environment. The Enterprise 1 Branch Office has three main components: a
2682
firewall, a switch, and a subnet for corporate users.
2683
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 76
Figure 4-6 Physical Architecture of the Enterprise 1 Branch Office
2684
4.5.2.1 Firewall
2685
One of the independent virtual firewalls provided by the Palo Alto Networks 5250 physical firewall is
2686
used for the Enterprise 1 Branch Office. It provides firewall and gateway capabilities, connecting the
2687
Branch Office to Enterprise 1 via the emulated WAN/internet service provider and supports a site-to-site
2688
VPN IPsec connection from the Branch Office to Enterprise 1. This firewall is integrated with the AD of
2689
Enterprise 1 so it can leverage Enterprise 1’s user directory store.
2690
4.5.2.2 Switch
2691
The Branch Office includes a Cisco C3650 multilayer switch that provides internal network connectivity
2692
within the Branch Office. It is integrated with Enterprise 1’s AAA (RADIUS) server to leverage Enterprise
2693
1’s authentication and authorization services.
2694
4.5.2.3 Corporate Users Subnet
2695
The corporate users subnet at the Branch Office is where users and devices such as mobile devices,
2696
tablets, Windows clients, and printers reside. Some of these devices are connected via wires to the Cisco
2697
3650 switch, while others are connected via Wi-Fi using an ASUS RC-AC66U wireless access point.
2698
Printer
Smartphone
Windows
Client
10.151.18.0/24
Enterprise 1
Branch Office
10.151.16.0/20
C3650-48
ASUS
AP RC-AC66U
VLAN: N/A = 1519
10.151.17.0/24
PAN 5250 (2)
VSYS4
Instant Wireless
Link/Act
Power Act Act Ful/Col
Diag Link Link 100
WLAN WLAN
54g 802.11a
LAN
Instant Wireless
Series
Dual-Band Wirele ss A+G
Access Point
Model WAP55AG
2.4
GHz
5
GHz
Instant Wireless
TM
Wireless A+G Access Point
Dual-Band
24
GHz
5
GHz
54g 802.11a
54g 802. 11a
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 77
4.5.3 Enterprise 2
2699
The high-level physical architecture of Enterprise 2 is the same as that of Enterprise 1, except Enterprise
2700
2 does not have an associated branch office. The baseline network topology, hardware, and software of
2701
Enterprise 2 are configured the same as Enterprise 1’s. Enterprise 2 leverages the same setup as
2702
Enterprise 1 using the Palo Alto Networks NGFW and Cisco switches. It also includes the same setup and
2703
capabilities as Enterprise 1 with respect to its DMZ, internal corporate subnetwork, corporate user
2704
subnetwork, guest subnetwork, shared services, and baseline applications. The only differences
2705
between Enterprise 2 and Enterprise 1 are with respect to the on-premises and cloud-based ZTA
2706
components used in each enterprise. See Appendix E and Appendix J for detailed descriptions of the ZTA
2707
components used in the builds that have been implemented in Enterprise 2.
2708
4.5.4 Enterprise 3
2709
The high-level physical architecture of Enterprise 3 is the same as that of Enterprise 2. The only
2710
differences between Enterprise 3 and Enterprise 2 are with respect to the on-premises and cloud-based
2711
ZTA components used in each enterprise. See Appendix E, H, and K for a detailed description of the ZTA
2712
components used in the builds that have been implemented in Enterprise 3.
2713
4.5.5 Enterprise 4
2714
The high-level physical architecture of Enterprise 4 is similar to Enterprise 2 except it is hosted on a
2715
different VMware farm from Enterprises 1-3. There are also differences between Enterprise 4 and
2716
Enterprise 2 with respect to the on-premises and cloud-based ZTA components used in each enterprise.
2717
See Appendix L for a detailed description of the ZTA components used in the build that has been
2718
implemented in Enterprise 4.
2719
Figure 4-7 is a close-up of the high-level physical architecture of Enterprise 4 in the NCCoE laboratory
2720
baseline environment. Its components are described in the subsections below.
2721
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 78
Figure 4-7 Enterprise 4 Physical Infrastructure
2722
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 79
4.5.5.1 Virtual Infrastructure
2723
Virtual Infrastructure for Enterprise 4 is provided via three VMware virtual storage area network (vSAN)
2724
clusters, with two clusters hosting compute services and one cluster hosting management services. Each
2725
cluster is connected to a 10GbE fabric served by a Dell S4048T-ON top-of-rack BASE-T switch with
2726
separate VLANs for vMotion, vSAN, and Management functions. Each cluster is running VMware
2727
vSphere 8.0 and is managed with a single VCenter server instance under a single Datacenter. The
2728
VMware clusters connect back to the NIST network using the same firewall and switch in Enterprises 1-
2729
3.
2730
4.5.6 Coffee Shop
2731
Figure 4-8 is a closeup of the high-level level physical architecture of the coffee shop in the NCCoE
2732
laboratory environment. As shown, the coffee shop provides users and mobile devices (e.g.,
2733
smartphones and laptops) wireless access to the internet via an ASUS RC-AC66U access point.
2734
Figure 4-8 Physical Architecture of the Coffee Shop
2735
4.5.7 Management and Orchestration Domain
2736
The management and orchestration domain, as depicted in Figure 4-9, includes components that
2737
support Infrastructure as Code (IaC) automation and orchestration across the ZTA lab environment. It
2738
includes Terraform, which is used to automate the setup of VMs across the four enterprises, and
2739
Ansible, which automates the setup of VMs and services such as DHCP, DNS, and AD across all four
2740
enterprises. It also hosts the Mandiant MSV Director and the MSV Protected Theater.
2741
Smartphone
Laptop
Internet
(Coffee Shop)
ASUS
AP RC-AC66U
Instant Wireless
Link/Act
Power Act Act Ful/Col
Diag Link Link 100
WLAN WLAN
54g 802.11a
LAN
Instant Wireless
Series
Dual-Band Wireless A+G
Access Point
ModelWAP55AG
2.4
GHz
5
GHz
Instant Wireless
TM
Wireless A+G Access Point
Dual-Band
24
GHz
5
GHz
54g 802.11a
54g 802.11a
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 80
Figure 4-9 Physical Architecture of the Management and Orchestration Domain
2742
4.5.8 Emulated WAN Service Provider
2743
A subnetwork within the ZTA laboratory network is leveraged to emulate a WAN service provider. The
2744
emulated WAN service provider using a Cisco SG550X switch and a Palo Alto Networks 5250 NGFW
2745
provides connectivity among all the ZTA laboratory network domains, i.e., the enterprises, the coffee
2746
shop, the branch office, and the management and orchestration domain. It also connects the ZTA
2747
laboratory network to ITOps, which provides connectivity to the internet. Via the internet, the emulated
2748
WAN services provide the ZTA lab network with connectivity to cloud services.
2749
4.5.9 Cloud Services
2750
As mentioned, the NCCoE lab environment has access to various cloud services via the internet. The
2751
cloud services that have been set up are described in this section.
2752
VLAN 1527
10.131.11.128/25
Infrastructure as Code
Automation & Orchestration
Management & Orchestration
10.130.11.140 & .141/25
PAN 5250 (2)
VSYS4
Ansible Terraform
MSV
Director
MSV
Protected
Theater
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 81
4.5.9.1 IaaS – Amazon Web Services (AWS)
2753
Figure 4-10 depicts the physical architecture of the AWS infrastructure that has been set up for use by
2754
Enterprise 1. As shown, the NCCoE ZTA lab is connected to AWS via a site-to-site VPN, and work is
2755
underway to set up a direct connection between the NCCoE ZTA lab and AWS as well. Both a production
2756
VPC (labeled Ent 1 Prod VPC) and a management VPC (labeled Ent 1 Mgmt VPC) have been set up within
2757
AWS for Enterprise 1 to use. There is a transit gateway (TGW) for routing traffic between the production
2758
and management VPCs, and there is also an NCCoE TGW within AWS. CloudFormation was used to set
2759
up the production and management VPC infrastructure within AWS through the NCCoE and Enterprise
2760
TGWs. The TGW acts as a hub for routing traffic between production and management VPCs and
2761
includes multiple routing tables for secure routing between the VPCs.
2762
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 82
Figure 4-10 Physical Architecture of the AWS Infrastructure Used by Enterprise 1
2763
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B-Implementing a Zero Trust Architecture 83
The production VPC has both a public subnetwork and three private subnetworks in each availability
2764
zone. The public subnetwork is used for connecting external users to the production VPC. The private
2765
subnetworks have EC2s that can host web, application, and database tiers.
2766
The management VPC also has a public subnetwork and three private subnetworks in each availability
2767
zone. The public subnetwork is used to support software updates and to enable administrators and
2768
other authorized internal staff who are located remotely to SSH into cloud components. The private
2769
subnetworks include a satellite tier, domain controller tier, and security management tier.
2770
Each VPC uses two availability zones for redundancy and high availability. Each availability zone uses
2771
automatic scaling as needed.
2772
4.5.9.2 IaaS – Azure
2773
Figure 4-11 depicts the physical architecture of the Azure IaaS that has been set up for use by Enterprise
2774
3. As shown, the NCCoE ZTA lab is connected to Azure IaaS via a site-to-site VPN. If coming from on-
2775
premises through the site-to-site VPN into Azure IaaS, connections go through the hub virtual network
2776
before getting to the application virtual networks for both the public-facing and private applications.
2777
The hub virtual network consists of the gateway subnet, the firewall subnet, and the bastion subnet. The
2778
gateway subnet consists of virtual network gateways in multiple availability zones. The firewall subnet
2779
consists of firewalls in multiple availability zones. The bastion subnet consists of Azure Bastion in
2780
multiple availability zones.
2781
The public application virtual network consists of a gateway subnet, an application subnet, and utility,
2782
web, and data subnets. Each of these subnets is secured by network security group (NSG). The gateway
2783
subnet consists of application gateways in multiple availability zones and WAF policies. The application
2784
subnet hosts the virtual machines and the applications, all of which are secured by application security
2785
groups.
2786
The private application virtual network consists of a gateway subnet and an application subnet. Each of
2787
these subnets is secured by NSG. The gateway subnet consists of application gateways in multiple
2788
availability zones and WAF policies. The application subnet hosts the virtual machines and the
2789
applications, as well as application proxies, all of which are secured by application security groups. The
2790
application proxies are meant to be used by remote users connecting to private applications through the
2791
internet.
2792
Traffic between subnets is allowed only if the NSGs on the subnets allow it. With the zero trust design,
2793
traffic between subnets should not be assumed; it must be explicitly granted.
2794
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 84
Figure 4-11 Physical Architecture of the Azure Infrastructure Used by Enterprise 3
2795
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 85
4.5.9.3 IaaS – IBM
2796
Figure 4-12 depicts the physical architecture of the IBM IaaS that has been set up for use by Enterprise
2797
4. As shown, the NCCoE ZTA lab is connected to IBM Cloud via a site-to-site VPN, and work is underway
2798
to set up a direct connection between the NCCoE ZTA lab and IBM Cloud as well. A VPC (labeled Ent 4
2799
VPC) and a Classic Infrastructure VPC have been set up within IBM Cloud for Enterprise 4 to use. There is
2800
an implicit route setup for securely routing traffic between the Classic Infrastructure and Ent 4 VPCs.
2801
Two types of network access controls have been set up for VPC security: ACLs and Security Groups. An
2802
ACL is used to limit who can access a particular subnet within the VPC. A Security Group is a collection of
2803
firewall rules that specify which traffic to allow or deny for one or more virtual server instances. The Ent
2804
4 VPC uses two zones for redundancy and high availability. Each zone has two subnets with private IP
2805
addresses. Additionally, a public gateway is set up. The Virtual Server Instances (VSIs), also known as
2806
virtual servers have been set up for hosting applications such as GitLab. A Classic Infrastructure VPC is
2807
set up that includes Bare Metal, VSIs, Load Balancers, and Gateway Applications.
2808
Also, for observability, tools such as IBM Log Analysis, IBM Cloud Activity Tracker, and IBM Cloud
2809
Monitoring are used.
2810
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 86
Figure 4-12 Physical Architecture of the IBM Cloud Infrastructure Used by Enterprise 4
2811
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 87
4.5.9.4 SaaS
2812
The project is also using collaborators’ ZTA SaaS offerings. The SaaS-based ZTA products used are listed
2813
in the appendices describing each build.
2814
4.6 Phase 0 Baseline Security Capability Deployment
2815
We began our project by building the ZTA laboratory physical architecture that is described in Section
2816
4.5 and populating it with the various applications and services that would be expected in a
2817
conventional enterprise environment to create the four baseline enterprise architectures that are
2818
described in Section 4.5. Next, as Phase 0 of our effort, we deployed a set of security analytics tools to
2819
augment the set of shared services and conventional security tools that had already been deployed as
2820
part of our four baseline architectures.
2821
The security analytics capabilities deployed in Phase 0 of our effort included SIEM components, as well
2822
as tools for vulnerability scanning and assessment, security validation, and discovery. Specifically, the
2823
following security analytics products were deployed:
2824
▪ IBM QRadar XDR SIEM was deployed in enterprises 1, 2, and 4; the Microsoft Sentinel SIEM was
2825
deployed in enterprise 3
2826
▪ Tenable.io, Tenable.ad, and Tenable NNM vulnerability scanning and assessment tools were
2827
deployed in enterprises 1, 2, 3, and 4
2828
▪ Mandiant Security Validation was deployed in enterprises 1, 2, 3, and 4
2829
▪ Forescout eyeSight discovery tool was deployed in enterprise 3
2830
5 Functional Demonstration
2831
Functional demonstrations were performed to showcase the security characteristics supported by each
2832
ZTA build. These demonstrations show the extent to which the example solutions meet their security
2833
objectives under a variety of conditions. NIST SP 1800-35D, ZTA Functional Demonstrations documents
2834
each of the demonstration scenarios and use cases that have been designed for this ZTA project. The
2835
results of the demonstrations that have been conducted on each ZTA build are also listed in NIST SP
2836
1800-35D.
2837
6 General Findings
2838
When deploying ZTA using the EIG approach, the following capabilities are considered to be
2839
fundamental to determining whether a request to access a resource should be granted and, once
2840
granted, whether the access session should be permitted to persist:
2841
▪ Authentication and periodic reauthentication of the requesting user’s identity
2842
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 88
▪ Authentication and periodic reauthentication of the requesting endpoint
2843
▪ Authentication and periodic reauthentication of the endpoint that is hosting the resource being
2844
accessed
2845
In addition, the following capabilities are also considered highly desirable:
2846
▪ Verification and periodic reverification of the requesting endpoint’s health
2847
▪ Verification and periodic reverification of the health of the endpoint that is hosting the resource
2848
being accessed
2849
6.1 EIG Crawl Phase Findings
2850
In the EIG crawl phase, we followed two patterns. First, we leveraged our ICAM solutions to also act as
2851
PDPs. We discovered that many of the vendor solutions used in the EIG crawl phase do not integrate
2852
with each other out-of-the-box in ways that are needed to enable the ICAM solutions to function as
2853
PDPs. Typically, network-level PEPs, such as routers, switches, and firewalls, do not integrate directly
2854
with ICAM solutions. However, network-level PEPs that are identity-aware may integrate with ICAM
2855
solutions. Also, endpoint protection solutions in general do not typically integrate directly with ICAM
2856
solutions. However, some of the endpoint protection solutions considered for use in the builds have
2857
out-of-the-box integrations with the MDM/UEM solutions used, which provide the endpoint protection
2858
solutions with an indirect integration with the ICAM solutions.
2859
Second, we used out-of-the-box integrations offered by the solution providers rather than performing
2860
custom integrations. These two patterns combined do not support all the desired zero trust capabilities.
2861
Both builds E1B1 and E3B1 were capable of authenticating and reauthenticating requesting users and
2862
requesting endpoints, and of verifying and periodically reverifying the health of requesting endpoints,
2863
and both builds were able to base their access decisions on the results of these actions. Access requests
2864
were not granted unless the identities of the requesting user and the requesting endpoint could be
2865
authenticated and the health of the requesting endpoint could be validated; however, no check was
2866
performed to authenticate the identity or verify the health of the endpoint hosting the resource.
2867
Access sessions that are in progress in both builds are periodically reevaluated by reauthenticating the
2868
identities of the requesting user and the requesting endpoint and by verifying the health of the
2869
requesting endpoint. If these periodic reauthentications and verifications cannot be performed
2870
successfully, the access session will eventually be terminated; however, neither the identity nor the
2871
health of the endpoint hosting the resource is verified on an ongoing basis, nor does its identity or
2872
health determine whether it is permitted to be accessed.
2873
Neither build E1B1 nor build E3B1 was able to support resource management as envisioned in the ZTA
2874
logical architecture depicted in Figure 4-1. These builds do not include any ZTA technologies that
2875
perform authentication and reauthentication of resources that host endpoints, nor are these builds
2876
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 89
capable of verifying or periodically reverifying the health of the endpoints that host resources. In
2877
addition, when using both builds E1B1 and E3B1, devices (requesting endpoints and endpoints hosting
2878
resources) were initially joined to the network manually. Neither of the two EIG crawl phase builds
2879
includes any technologies that provide network-level enforcement of an endpoint’s ability to access the
2880
network. That is, there is no tool in either build that can keep any endpoint (either one that is hosting a
2881
resource or one that is used by a user) from initially joining the network based on its authentication
2882
status. The goal is to try to support resource management in future builds as allowed by the
2883
technologies used.
2884
6.2 EIG Run Phase Findings
2885
The EIG run phase enabled us to demonstrate additional capabilities over the EIG crawl phase, such as:
2886
▪ establishment of secure, direct access tunnels from requesting endpoints to private enterprise
2887
resources, regardless of whether the resources are located on-premises or in the cloud, driven
2888
by policy and enforced by PEPs
2889
▪ use of connectors that act as proxies for internal, private enterprise resources, enabling
2890
resources to be accessed by authenticated, authorized users while ensuring that they are not
2891
discoverable by or visible to others
2892
▪ protection for private enterprise resources hosted in the cloud that enables authenticated,
2893
authorized remote users to access those resources directly rather than having to hairpin
2894
through the enterprise network
2895
▪ ability to monitor, inspect, and enforce policy controls on traffic being sent to and from
2896
resources in the cloud or on the internet
2897
▪ discovery of new endpoints on the network and the ability to block newly discovered endpoints
2898
that are not compliant with policy
2899
Build E1B2, which uses Zscaler as its PE, PA, and PEP, does not have an EPP because this build does not
2900
include any collaborators with EPP solutions that integrate with Zscaler. Zscaler (e.g., the Zscaler client
2901
connector) has capabilities to enforce policies based on a defined set of endpoint compliance checks to
2902
allow or deny user/endpoint access to a resource. However, it does not perform the functions of an EPP
2903
solution to protect an endpoint. Zscaler integrates with EPP solutions to receive a more robust set of
2904
information about the endpoints in order to make a decision to allow or deny access to a resource.
2905
However, in build E1B2, we do not have a collaborator with an EPP solution that can integrate with
2906
Zscaler.
2907
Because there is no EPP in E1B2, there is no automatic solution to remediate an issue on the endpoint
2908
either.
2909
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 90
Build E1B2 also does not have a collaborator with a solution that supports determination of confidence
2910
level/trust scores that can integrate with Zscaler. Due to the absence of a collaborator with this
2911
capability, Build E1B2 does not support the calculation of confidence levels/trust scores.
2912
Build E2B1, which uses Ping Identity as its PE and PA and Ping Identity and Cisco Duo as its PEP, does not
2913
have an EPP. Cisco Duo provides limited device health information, but not the full spectrum that an EPP
2914
would provide. Because there is no official EPP in this build, there is no automatic solution to remediate
2915
an issue on the endpoint. An EPP for Enterprise 2 was included in a later build phase (E2B3).
2916
Build E3B2 currently supports one-way integration between Microsoft Intune and Forescout eyeExtend.
2917
If Intune detects an endpoint out of compliance, eyeExtend can become informed of this problem by
2918
pulling information from Intune. However, if one of Forescout’s discovery tools detects a problem with
2919
an endpoint, there is currently no mechanism for this information to be passed from Forescout
2920
eyeExtend to Microsoft Intune. Ideally, future integration of these products would allow Forescout
2921
eyeExtend to inform Microsoft Intune when it detects a non-Azure AD-connected endpoint that is non-
2922
compliant, as this would enable Intune to direct Azure AD to block sign-in from the non-compliant
2923
endpoint. Without a mechanism for enabling Forescout eyeExtend to send endpoint compliance
2924
information to Microsoft Intune, Azure AD does not have a way of knowing that a non-Azure AD-
2925
connected endpoint is not compliant.
2926
6.3 SDP and Microsegmentation Phase Findings
2927
More integration of zero trust products from different vendors is needed to support the implementation
2928
of ZTAs that are built using components from a variety of vendors. For the most effective zero trust
2929
solutions, PDPs should integrate with a variety of security tools and other supporting components that
2930
enable the PDP to assess the real-time risk of any given access request.
2931
It is not unusual for a ZTA to have multiple PDPs, each of which may be integrated with one or more
2932
different supporting component and/or PEPs. As a result, the policies that the ZTA enforces are not
2933
centrally located. Rather, they are configured and managed in association with each of the various PDPs.
2934
This makes it challenging to understand, articulate, and manage the ZTA’s policies as a comprehensive
2935
whole.
2936
In addition, the multiple PDPs that comprise a ZTA do not typically integrate with each other to share
2937
information and so do not have a shared understanding of what users, endpoints, or other subjects may
2938
pose risks. For example, one PDP may be aware that an endpoint is non-compliant, whereas this same
2939
endpoint compliance information is not available to another PDP. On the other hand, the second PDP
2940
may be aware that the endpoint’s user may have exhibited suspicious behavior, whereas the first PDP is
2941
not. Ideally, when a ZTA has multiple PDPs, it is desirable to have an integrated approach that enables
2942
the PDPs to share information so that they can each be more fully informed, share a common,
2943
consolidated understanding of risks, and make a decision based on all information available.
2944
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 91
The SIEM and/or SOAR components contain a wealth of information that could prove useful to a PDP as
2945
it tries to determine whether any given access request should be allowed or not. Ideally, the SIEM and
2946
SOAR should send this information to the PDP in real-time, if possible, to ensure that the PDP’s access
2947
decisions are fully informed.
2948
Ideally, data security tools should be integrated with the PDP so that the PDP can be made aware of
2949
instances in which access requests are denied by the tools that are designed to protect data.
2950
Additionally, risk information and user behavior analytics should be shared with the PDP to potentially
2951
improve ZTA security.
2952
Some zero trust SDP solutions for managing endpoints can also manage resources by installing clients
2953
onto those resources. However, solutions that are specifically designed to manage resources should be
2954
leveraged rather than the zero trust solutions that have the primary purpose of managing endpoints.
2955
Endpoint compliance is essential for security. It is important to have tools that are capable of detecting
2956
when an endpoint is not compliant and ensuring that the endpoint is not permitted to access resources
2957
as a result. Furthermore, automatic solutions to remediate noncompliance issues on the endpoint
2958
should be deployed when possible, and these should be integrated with the organization’s configuration
2959
and patch management systems.
2960
6.4 Zero Trust Journey Takeaways
2961
Based on our experience building example implementations in the lab, we recommend that an
2962
organization that wants to deploy and implement zero trust embark on a journey that includes the steps
2963
listed as subsection headings below.
2964
6.4.1 Discover and inventory the existing environment
2965
The first step any organization should take on its zero trust journey is to identify all of its assets by
2966
determining what resources it has in its existing environment (hardware, software, applications, data,
2967
and services). This may involve deploying tools that monitor traffic to discover what resources are active
2968
and being accessed and used. It is necessary to have a complete understanding and inventory of the
2969
organization’s resources because these are the entities that the zero trust architecture will be designed
2970
to protect. If resources are overlooked, it’s likely that they won’t be appropriately protected by the ZTA.
2971
They could be vulnerable to exfiltration, modification, deletion, denial-of-service, or other types of
2972
attack. It is imperative that all of the organization’s resources, whether on-premises or cloud-based, be
2973
identified and inventoried.
2974
Discovery tools that are used to identify organization resources may do so, for example, by monitoring
2975
transaction flows and communication patterns. These tools may also be useful in helping the
2976
organization identify the business and access rules that are currently being enforced, and in identifying
2977
access patterns that business operations require. Understanding how resources are accessed, by whom,
2978
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 92
and in what context will help the organization formulate its access policies. In addition, once the
2979
organization has begun deploying a ZTA, continuing to use the discovery tools to observe the
2980
environment can be helpful to the organization as it audits and validates the ZTA on an ongoing basis.
2981
6.4.2 Formulate access policy to support the mission and business use cases
2982
Once the organization has identified all of the resources that it needs to protect and where they are, it
2983
must formulate the policies that the ZTA will enforce to specify who is allowed to access each resource
2984
and under what conditions. The access policies should be designed to ensure that permissions and
2985
authorizations to access each resource conform with the principles of least privilege and separation of
2986
duties. Typically, access to each resource will be denied by default, and access policies should be
2987
formulated to authorize subjects to access only the minimum level of resources that they are required
2988
to access in order for them to perform their assigned tasks. This requires understanding the types of
2989
users that will be accessing resources, their access requirements, work locations, employment
2990
arrangements, device types, and ownership models (e.g., BYOD and corporate-owned) because these
2991
will all influence policy creation. Access authorizations may be constrained according to the location of
2992
the individual requesting access, time of day, or other parameters that can further limit access without
2993
interfering with organizational operations. All access policies should be informed by the criticality of the
2994
resource being protected.
2995
Initially, an organization may not have a clear sense of what resources each employee requires access
2996
to. They may not be aware of which employees are accessing which resources or whether or not such
2997
access conforms to the principles of least privilege and separation of duties. Information provided by the
2998
tools that were used to discover resources can be useful in this regard. They can monitor access patterns
2999
and produce a list of access flows and patterns that are observed. For the remote access example, an
3000
organization transitioning from a full device VPN to per-app tunneling could first set up a full device
3001
tunnel and observe traffic, then begin enabling only the traffic that is required for the user profile. The
3002
organization’s security team can then examine this list to determine which access flows should be
3003
permitted and then formulate access rules that permit them. Any observed access flows that should not
3004
be permitted may be denied by default or explicitly prohibited in the access policy. By basing access
3005
policy on observed access patterns, an organization reduces the chances that it will create overly
3006
restrictive policies that interfere with its ability to conduct normal operations. By taking into
3007
consideration the criticality of the data being protected when formulating the access policy, an
3008
organization can help ensure that the protections being provided to a resource are commensurate with
3009
its value.
3010
One challenge that organizations may have when formulating policy is that their ZTA may consist of
3011
numerous components that each perform policy engine and policy administration roles. As a result,
3012
access policy may not be centralized in one location; rules may be distributed across numerous
3013
products, i.e., with some rules configured in an endpoint protection component; some configured in
3014
identity, credential, and access management components; other rules configured in a network security
3015
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 93
component; and still other rules configured in a data security or other components. The lack of a single
3016
location where all policy rules can be centralized may make it challenging for an organization to
3017
maintain an organized, complete, consistent understanding of its access policy. To help organizations
3018
manage their access policies, they should explicitly keep track of not only what their access rules are,
3019
but where each of the rules is configured.
3020
6.4.3 Identify existing security capabilities and technology
3021
If an organization is planning to install a ZTA into a greenfield environment, meaning that it will not have
3022
any existing IT equipment or security capabilities that it will want to use or accommodate, this step
3023
would not be needed. Most organizations embarking on a zero trust journey, however, will not be
3024
starting from scratch. Instead, they will have an existing infrastructure and technology systems that
3025
already perform security functions. Organizations will typically have at least network firewalls and
3026
intrusion detection systems to help provide perimeter security, and identity and credential access
3027
management systems that enable them to authenticate users and enforce authorized access based on
3028
identity and role. They may have endpoint security systems protecting their laptops and/or mobile
3029
devices to provide firewall protections and ensure that they are running required antivirus or other
3030
security software. They may have tools for vulnerability and configuration management, log
3031
management, and, and other security-related functions. They also likely have some sort of security
3032
operations center.
3033
An organization should identify and inventory its existing security technology components and
3034
capabilities to understand what protections they already provide, then determine whether these
3035
components should continue to provide these protections as part of the deployed ZTA or should be
3036
repurposed. To save money, an organization will want to continue to use or repurpose as much of its
3037
existing technology as possible without sacrificing security. Continuing to use existing technology will
3038
require the organization to understand what potential zero trust components and products its existing
3039
security technology will integrate with. Any additional components that are purchased specifically for
3040
deployment in the ZTA should, ideally, integrate with the security technology components that the
3041
organization already has and plans to continue to use.
3042
6.4.4 Eliminate Gaps in Zero Trust Policy and Processes by Applying a Risk-Based
3043
Approach Based on the Value of Data
3044
Once an organization has inventories of the resources it needs to protect and the security capabilities it
3045
already has, the organization is ready to begin planning its access protection topology, in terms of
3046
whether and where its infrastructure will be segmented and at what level of granularity each resource
3047
will be protected. The access topology should be designed using a risk-based approach, isolating critical
3048
resources in their own trust zones protected by a PEP but permitting multiple lower-value resources to
3049
share a trust zone. In designing its access protection topology, the organization will identify which PEP is
3050
responsible for protecting each resource as well as what supporting technologies will be involved in
3051
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 94
providing input to resource access decisions. Initially, the organization’s network may not be very
3052
segmented at all. In fact, before zero trust is implemented, when the organization is still relying on
3053
perimeter-based protections, such a topology can be thought of as the organization protecting all of its
3054
resources behind a single PEP, i.e., the perimeter firewall. As the organization implements ZTA, it should
3055
segment its infrastructure into smaller parts. Such segmentation will enable it to limit the potential
3056
impact of a breach or attack and make it easier to monitor network traffic. In designing its access
3057
protection topology, the organization should apply access control enforcement at multiple levels:
3058
application, host, and network.
3059
6.4.5 Implement ZTA components (people, process, and technology) and
3060
incrementally leverage deployed security solutions to achieve the end goal
3061
Once an organization has: 1) a good understanding of its current environment in terms of the resources
3062
it needs to protect and the security capabilities that it already has deployed; 2) formulated the access
3063
policies that are appropriate to support its mission and business use cases; and 3) designed its access
3064
protection topology to identify the granularity at which access to various resources will be protected
3065
and the supporting technologies that will provide input to the PDP, the organization is ready to begin
3066
incrementally implementing ZTA. Given the importance of discovery to the successful implementation of
3067
a ZTA, the organization may begin by deploying tools to continuously monitor the environment, if it has
3068
not done so already. The organization can use these observations to audit and validate the ZTA on an
3069
ongoing basis.
3070
In addition to discovery tools, the organization should ensure that any other baseline security tools such
3071
as SIEMs, vulnerability scanning and assessment tools, and security validation tools are operational and
3072
configured to log, scan, assess, and validate the ZTA components that will be deployed. Having security
3073
baseline tools in place before the organization begins deploying new ZTA components helps ensure that
3074
the ZTA rollout will be well-monitored, enabling the organization to proceed with high confidence that it
3075
will understand the security ramifications of the incremental deployment as it proceeds.
3076
Identity, authentication, and authorization are critical to making resource access decisions. Given that
3077
making and enforcing access decisions are the two main responsibilities of a ZTA, the organization will
3078
want to use its existing or a new ICAM solution as a foundational building block of its initial ZTA
3079
implementation. The organization should strongly consider implementing MFA for all of its users. An
3080
endpoint protection or similar solution that can assess device health and that integrates with the ICAM
3081
solution may also be another foundational component of an initial ZTA deployment. An initial ZTA based
3082
on these two main components will be able to use the identity and authorizations of subjects and the
3083
health and compliance of requesting endpoints as the basis for making access decisions. Additional
3084
supporting components and features can then be deployed to address an increasing number of ZTA
3085
requirements. Which types of components are deployed and in what order will depend on the
3086
organization’s mission and business use cases. If data security is essential, then data security
3087
components will be prioritized; if behavior-based anomaly detection is essential, then monitoring and
3088
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 95
AI-based analytics may be installed. The ZTA can be built incrementally, adding and integrating more
3089
supporting components, features, and capabilities to gradually evolve to a more comprehensive ZTA.
3090
6.4.6 Verify the implementation to support zero trust outcomes
3091
The organization should continue to monitor all network traffic in real time for suspicious activity, both
3092
to look for known attack signatures and patterns and to apply behavioral analytics to try to detect
3093
anomalies or other activity that may be attack indicators. The organization should use deployed
3094
discovery and other baseline security tools to audit and validate the access enforcement decision of the
3095
ZTA it has provisioned, correlating known data with information reported by the tools. The organization
3096
should perform ongoing verification that the policies that are being enforced, as revealed by the
3097
observed network flows, are in fact the policies that the organization has defined. Periodic testing
3098
should be performed across a variety of use case scenarios, including those in which the resource is
3099
located on-premises and in the cloud, the requesting endpoint is located on-premises and on the
3100
internet, the requesting subject is and is not authorized to access the requested resource, the
3101
requesting endpoint is and is not managed, and the requesting resource is and is not compliant. In
3102
addition, service-to-service requests, both authorized and unauthorized, should also be tested. The use
3103
cases selected for testing should reflect those which most closely mirror how the organization’s users
3104
access the organization’s resources on a day-to-day basis. Ideally, the organization can create a suite of
3105
tests that it can use to validate the ZTA not only before deploying each new ZTA capability in the
3106
incremental rollout process, but also on a periodic basis once the ZTA rollout is considered complete.
3107
6.4.7 Continuously improve and evolve due to changes in threat landscape,
3108
mission, technology, and regulations
3109
Once rolled out and considered complete, the ZTA must continue to adapt to changing conditions. If
3110
technology components used in the ZTA are upgraded or obsoleted by their manufacturer, they should
3111
be replaced. If innovative new technologies become available, the organization should consider whether
3112
they could be integrated into the existing ZTA to take advantage of new defensive tactics, techniques,
3113
and procedures that might improve the organization’s security posture. If the organization’s security
3114
goals change, either as a result of a shifting mission or changes in regulations, the ZTA’s policies and the
3115
ZTA itself may need to evolve to best address these new goals.
3116
In addition, the ZTA may need to adapt to a changing threat landscape. As new types of adversary
3117
attacks become known and prevalent, the ZTA will need to add the threat signatures for these attacks to
3118
the list of things it monitors for. Ideally the ZTA will also perform behavior-based monitoring that
3119
enables it to detect anomalies that may signal zero-day attacks for which threat signatures are not yet
3120
know. Behavior-based monitoring tools provide the ZTA with some degree of agility and readiness with
3121
respect to its ability to detect attacks by adversaries who are constantly changing their tactics and
3122
techniques. In any case, as the threat landscape changes, the organization’s CISO and security team
3123
need to continually assess the ZTA’s topology, components, and policies to ensure that they are best
3124
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 96
designed to address newly emerging threats. If the value of one or more of an organization’s resources
3125
increases substantially, the organization may want to change how that resource is protected by the ZTA,
3126
as well as what its access policies are.
3127
As input to this ongoing process of validation and improvement, organizations should continuously
3128
monitor their network and other infrastructure and update policies, technologies, and network
3129
segmentation topologies to ensure that they remain effective. Creating a ZTA is not a one-time project
3130
but an ongoing process. The organization’s CISO or other security team members should perform
3131
ongoing validation of their ZTA access policies to ensure that they continue to be defined in a manner
3132
that supports the organization’s mission and business use cases while conforming with the principles of
3133
least privilege and separation of duties.
3134
7 Future Build Considerations
3135
At this time, three EIG crawl phase builds are complete (E1B1, E2B1, and E3B1). We skipped the EIG walk
3136
phase and proceeded directly to the run phase. Three EIG run phase builds (E1B2, E3B2, and E4B3) are
3137
also complete. Four SDP and microsegmentation builds are also complete (E1B3, E2B3, E3B3, and E1B4).
3138
All ten of these builds are documented in this guide.
3139
The next phase of the project will continue to focus on the microsegmentation and SDP deployment
3140
models, and a combination of the two.
3141
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 97
Appendix A List of Acronyms
3142
AAA
Authentication, Authorization, and Accounting
ACL
Access Control List
AD
Active Directory
AD FS
Active Directory Federation Services
AI
Artificial Intelligence
AP
Access Point
API
Application Programming Interface
APM
(F5 BIG-IP) Access Policy Manager
ATP
(Microsoft Azure) Advanced Threat Protection, (Palo Alto Networks) Advanced
Threat Prevention
AURL
(Palo Alto Networks) Advanced URL Filtering
AWS
Amazon Web Services
BCE
(Google) BeyondCorp Enterprise
BYOD
Bring Your Own Device
C&C
Command-and-Control
CA
Certificate Authority, (Zscaler) Central Authority
CASB
Cloud Access Security Broker
CDM
Continuous Diagnostics and Mitigation
CDSS
Cloud-Delivered Security Service
CESA
Cisco Endpoint Security Analytics
CI/CD
Continuous Integration/Continuous Delivery
CIEM
Cloud Infrastructure Entitlement Management
CRADA
Cooperative Research and Development Agreement
CSW
Cisco Secure Workload
CVE
Common Vulnerabilities and Exposures
DDoS
Distributed Denial of Service
DHCP
Dynamic Host Configuration Protocol
DLP
Data Loss Prevention
DMZ
Demilitarized Zone
DNS
Domain Name System
DTLS
Datagram Transport Layer Security
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 98
EBS
(Amazon) Elastic Block Store
EC2
(Amazon) Elastic Compute Cloud
ECS
(Amazon) Elastic Container Service
EDR
Endpoint Detection and Response
EIG
Enhanced Identity Governance
EKS
(Amazon) Elastic Kubernetes Service
EMM
Enterprise Mobility Management
EO
Executive Order
ePO
(Trellix) ePolicy Orchestrator
EPP
Endpoint Protection Platform
ETA
(Cisco) Encrypted Traffic Analytics
E/W
East/West
FedRAMP
Federal Risk and Authorization Management Program
FIDO U2F
Fast Identity Online Universal 2
nd
Factor
FIPS
Federal Information Processing Standards
FTD
(Cisco) Firepower Threat Defense
FWaaS
Firewall as a Service
GCP
Google Cloud Platform
GDE
(IBM Security) Guardium Data Encryption
GIN
(Symantec) Global Intelligence Network
GP
(Palo Alto Networks) GlobalProtect
HR
Human Resources
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol Secure
IaaS
Infrastructure as a Service
IaC
Infrastructure as Code
IAM
(AWS) Identity and Access Management
IBM
International Business Machines Corporation
ICA
Intermediate Certificate Authority
ICAM
Identity, Credential, and Access Management
IDaaS
Identity as a Service
IdP
Identity Provider
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 99
IGA
(Symantec) Identity Governance and Administration
IoMT
Internet of Medical Things
IoT
Internet of Things
IP
Internet Protocol
IPsec
Internet Protocol Security
IPv4
Internet Protocol version 4
IPv6
Internet Protocol Version 6
ISE
(Cisco) Identity Services Engine
IT
Information Technology
ITL
Information Technology Lab
ITOps
Information Technologies Operations
JDBC
Java Database Connectivity
KCD
Kerberos Constrained Delegation
LDAP
Lightweight Directory Access Protocol
LTM
(F5 BIG-IP) Local Traffic Manager
MAM
Mobile Application Management
MDM
Mobile Device Management
MES
(Lookout) Mobile Endpoint Security
MFA
Multi-Factor Authentication
ML
Machine Learning
MSV
Mandiant Security Validation
MTD
Mobile Threat Defense
mTLS
Mutual Transport Layer Security
NCCoE
National Cybersecurity Center of Excellence
NDR
Network Detection and Response
NGFW
Next-Generation Firewall
NIST
National Institute of Standards and Technology
NNM
(Tenable) Nessus Network Monitor
NPE
Non-Person Entity
NPS
Network Policy Server
N/S
North/South
NSG
Network Security Group
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 100
NTA
Network Traffic Analysis
NTP
Network Time Protocol
NVM
(Cisco) Network Visibility Module
OAuth
Open Authorization
OIDC
OpenID Connect
OMB
Office of Management and Budget
OS
Operating System
OT
Operational Technology
OTP
One-Time Password
PA
Policy Administrator
PaaS
Platform as a Service
PDP
Policy Decision Point
PE
Policy Engine
PEP
Policy Enforcement Point
PII
Personally Identifiable Information
PIP
Policy Information Point
PKI
Public Key Infrastructure
QoS
Quality of Service
QR
Quick Response
RADIUS
Remote Authentication Dial-In User Service
R&D
Research and Development
RDBMS
Relational Database Management System
RDP
Remote Desktop Protocol
RDS
Remote Desktop Server
REST
Representational State Transfer
S3
(Amazon) Simple Storage Service
SaaS
Software as a Service
SAML
Security Assertion Markup Language
SASE
Secure Access Service Edge
SAW
(Microsoft) Secure Admin Workstation
SCIM
System for Cross-Domain Identity Management
SDLC
Software Development Lifecycle
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 101
SDP
Software-Defined Perimeter
SD-WAN
Software-Defined Wide Area Network
SFTP
SSH File Transfer Protocol
SIEM
Security Information and Event Management
SMB
Server Message Block
SMS
Short Message Service
SMTP
Simple Mail Transfer Protocol
SNA
(Cisco) Secure Network Analytics
SOAR
Security Orchestration and Response
SoD
Separation of Duties
SP
Special Publication
SPA
Single Packet Authentication
SQL
Structured Query Language
SRE
Site Reliability Engineer
SSE
(Skyhigh Security) Security Service Edge
SSH
Secure Shell
SSL
Secure Sockets Layer
SSO
Single Sign-On
SWG
Secure Web Gateway
TGW
Transit Gateway
TLS
Transport Layer Security
TOTP
Time-Based One-Time Pad
TTP
Tactics, Techniques, and Procedures
UAG
Unified Access Gateway
UDP
User Datagram Protocol
UEM
Unified Endpoint Management
URL
Uniform Resource Locator
USB
Universal Serial Bus
VDI
Virtual Desktop Infrastructure
VIP
(Symantec) Validation and ID Protection
VLAN
Virtual Local Area Network
VM
Virtual Machine
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 102
VPC
Virtual Private Cloud
VPN
Virtual Private Network
vSAN
Virtual Storage Area Network
VSI
Virtual Server Instance
WAF
Web Application Firewall
WF
(Palo Alto Networks) Wildfire
WSS
(Symantec) Web Security Service
WSUS
(Microsoft) Windows Server Update Service
XDR
Extended Detection and Response
ZCC
Zscaler Client Connector
ZIA
Zscaler Internet Access
ZPA
Zscaler Private Access
ZSO
(Ivanti) Zero Sign-On
ZTA
Zero Trust Architecture
ZTNA
Zero Trust Network Access
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 103
Appendix B Glossary
3143
Managed Devices
Personal computers, laptops, mobile devices, virtual machines, and
infrastructure components require management agents, allowing information
technology staff to discover, maintain, and control them. Those with broken or
missing agents cannot be seen or managed by agent-based security products.
[NIST SP 1800-15 Vol. B]
Policy
Statements, rules, or assertions that specify the correct or expected behavior
of an entity. For example, an authorization policy might specify the correct
access control rules for a software component. [NIST SP 800-95 and NIST IR
7621 Rev. 1]
Policy
Administrator (PA)
An access control mechanism component that executes the PE’s policy
decision by sending commands to the PEP to establish and terminate the
communications path between the subject and the resource.
Policy Decision
Point (PDP)
An access control mechanism component that computes access decisions by
evaluating the applicable policies. The functions of the PE and PA comprise a
PDP. [NIST SP 800-162, adapted]
Policy Enforcement
Point (PEP)
An access control mechanism component that enforces access policy decisions
in response to a request from a subject requesting access to a protected
resource. [NIST SP 800-162, adapted]
Policy Engine (PE)
An access control mechanism component that handles the ultimate decision to
grant, deny, or revoke access to a resource for a given subject.
Policy Information
Point (PIP)
An access control mechanism component that provides telemetry and other
information generated by policy or collected by supporting components that
the PDP needs for making policy decisions. [NIST SP 800-162, adapted]
Risk
The net negative impact of the exercise of a vulnerability, considering both the
probability and the impact of occurrence. [NIST SP 1800-15 Vol. B]
Security Control
A safeguard or countermeasure prescribed for an information system or an
organization designed to protect the confidentiality, integrity, and availability
of its information and to meet a set of defined security requirements. [NIST SP
800-53 Rev. 5]
Threat
Any circumstance or event with the potential to adversely impact
organizational operations (including mission, functions, image, or reputation),
organizational assets, or individuals through an information system via
unauthorized access, destruction, disclosure, modification of information,
and/or denial of service. Also, the potential for a threat-source to successfully
exploit a particular information system vulnerability. [Federal Information
Processing Standards 200]
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 104
Vulnerability
Weakness in an information system, system security procedures, internal
controls, or implementation that could be exploited or triggered by a threat
source. [NIST SP 800-37 Rev. 2]
Zero Trust
A cybersecurity paradigm focused on resource protection and the premise that
trust is never granted implicitly but must be continually evaluated. [NIST SP
800-207]
Zero Trust
Architecture (ZTA)
An enterprise cybersecurity architecture that is based on zero trust principles
and designed to prevent data breaches and limit internal lateral movement.
Zero trust architecture is an end-to-end approach to enterprise resource and
data security that encompasses identity (person and non-person entities),
credentials, access management, operations, endpoints, hosting
environments, and the interconnecting infrastructure. [NIST SP 800-207]
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 105
Appendix C References
3144
[1] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, National Institute of
3145
Standards and Technology (NIST) Special Publication (SP) 800-207, Gaithersburg, Md., August
3146
2020, 50 pp. Available: https://csrc.nist.gov/publications/detail/sp/800-207/final.
3147
[2] Executive Order no. 14028, Improving the Nation’s Cybersecurity, Federal Register Vol. 86,
3148
No.93, May 17, 2021. Available: https://www.federalregister.gov/documents/2021/05/17/2021-
3149
10460/improving-the-nations-cybersecurity.
3150
[3] “National Cybersecurity Center of Excellence (NCCoE) Zero Trust Cybersecurity: Implementing a
3151
Zero Trust Architecture,” Federal Register Vol. 85, No. 204, October 21, 2020, pp. 66936-66939.
3152
Available: https://www.federalregister.gov/documents/2020/10/21/2020-23292/national-
3153
cybersecurity-center-of-excellence-nccoe-zero-trust-cybersecurity-implementing-a-zero-trust.
3154
[4] National Cybersecurity Center of Excellence, Internet of Things (IoT). Available:
3155
https://www.nccoe.nist.gov/iot
3156
[5] National Cybersecurity Center of Excellence, Manufacturing. Available:
3157
https://www.nccoe.nist.gov/manufacturing
3158
[6] National Cybersecurity Center of Excellence, Energy. Available:
3159
https://www.nccoe.nist.gov/energy
3160
[7] National Cybersecurity Center of Excellence, Healthcare. Available:
3161
https://www.nccoe.nist.gov/healthcare
3162
[8] The President’s National Security Telecommunications Advisory Committee, NSTAC Report to
3163
the President: Zero Trust and Trusted Identity Management, February 23, 2022. Available:
3164
https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20Presid
3165
ent%20on%20Zero%20Trust%20and%20Trusted%20Identity%20Management%20%2810-17-
3166
22%29.pdf
3167
[9] F5, Certifications. Available: https://www.f5.com/company/certifications
3168
[10] NIST, Cryptographic Module Validation Program Certificate #3344, updated March 8, 2022.
3169
Available: https://csrc.nist.gov/projects/cryptographic-module-validation-
3170
program/Certificate/3344
3171
[11] NIST, Cryptographic Module Validation Program Certificate #3452, May 7, 2019. Available:
3172
https://csrc.nist.gov/Projects/cryptographic-module-validation-program/Certificate/3452
3173
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 106
[12] P. Grassi, J. Richer, S. Squire, J. Fenton, E. Nadeau, N. Lefkovitz, J. Danker, Y. Choong, K. Greene,
3174
and M. Theofanos, Digital Identity Guidelines Federation and Assertions, National Institute of
3175
Standards and Technology (NIST) Special Publication (SP) 800-63C, Gaithersburg, Md., June
3176
2017, 40 pp. Available: https://www.nist.gov/identity-access-management/nist-special-
3177
publication-800-63-digital-identity-guidelines.
3178
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 107
Appendix D Enterprise 1 Build 1 (E1B1) – EIG Crawl
3179
D.1 Technologies
3180
E1B1 uses products from Amazon Web Services, IBM, Ivanti, Mandiant, Okta, Radiant Logic, SailPoint,
3181
Tenable, and Zimperium. Certificates from DigiCert are also used. For more information on these
3182
collaborators and the products and technologies that they contributed to this project overall, see
3183
Section 3.4.
3184
E1B1 components consist of Okta Identity Cloud, Ivanti Access ZSO, Ivanti Sentry, Radiant Logic
3185
RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Okta Verify App, Ivanti Neurons for
3186
UEM, Zimperium MTD, IBM Security QRadar XDR, Tenable.io, Tenable.ad, IBM Cloud Pak for Security,
3187
Mandiant Security Validation (MSV), Ivanti Tunnel, DigiCert CertCentral, and AWS IaaS.
3188
Table D-1 lists all of the technologies used in E1B1. It lists the products used to instantiate each ZTA
3189
component and the security function that each component provides.
3190
Table D-1 E1B1 Products and Technologies
3191
Component
Product
Function
PE
Okta Identity Cloud and
Ivanti Access ZSO
Decides whether to grant, deny, or revoke access to a
resource based on enterprise policy, information from
supporting components, and a trust algorithm.
PA
Okta Identity Cloud and
Ivanti Access ZSO
Executes the PE’s policy decision by sending commands to
a PEP that establishes and shuts down the communication
path between subject and resource.
PEP
Ivanti Sentry
Guards the trust zone that hosts one or more enterprise
resources; establishes, monitors, and terminates the
connection between subject and resource as directed by
the PA; forwards requests to and receives commands from
the PA.
ICAM -
Identity
Management
Okta Identity Cloud
Creates and manages enterprise user and device accounts,
identity records, role information, and access attributes
that form the basis of access decisions within an
organization to ensure the correct subjects have the
appropriate access to the correct resources at the
appropriate time.
ICAM -
Access &
Credential
Management
Okta Identity Cloud
Manages access to resources by performing user and
device authentication (e.g., SSO and MFA) and using
identity, role, and access attributes to determine which
access requests are authorized.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 108
Component
Product
Function
ICAM -
Federated
Identity
Radiant Logic
RadiantOne Intelligent
Identity Data Platform
Aggregates and correlates all attributes relating to an
identity or object that is being authorized by a ZTA. It
enables users of one domain to securely access data or
systems of 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.
ICAM -
Identity
Governance
SailPoint IdentityIQ
Provides policy-based, centralized, automated processes to
manage user identity and access control functions (e.g.,
ensuring segregation of duties, role management, logging,
access reviews, analytics, reporting) to ensure compliance
with requirements and regulations.
ICAM - MFA
Okta Verify app
Supports MFA of a user identity by requiring the user to
provide not only something they know (e.g., a password),
but also something they have (e.g., a token).
Endpoint
Security -
UEM/MDM
Ivanti Neurons for
Unified Endpoint
Management (UEM)
Platform
Manages and secures enterprise desktop computers,
laptops, and/or mobile devices in accordance with
enterprise policy to protect applications and data; ensure
device compliance; mitigate and remediate vulnerabilities
and threats; monitor for suspicious activity to prevent and
detect intrusions; prevent, detect, and disable malware
and other malicious or unauthorized traffic; repair infected
files when possible; provide alerts and recommend
remediation actions; and encrypt data.
Pushes enterprise applications and updates to devices,
enables users to download enterprise applications that
they are authorized to access, remotely deletes all
applications and data from devices if needed, tracks user
activity on devices, and detects and addresses security
issues on the device.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 109
Component
Product
Function
Endpoint
Security -
EPP
Zimperium MTD
Detects and stops threats to endpoints through an
integrated suite of endpoint protection technologies
including antivirus, data encryption, intrusion prevention,
EDR, and DLP. May include mechanisms that are designed
to protect applications and data; ensure device compliance
with policies regarding hardware, firmware, software, and
configuration; monitor endpoints for vulnerabilities,
suspicious activity, intrusion, infection, and malware; block
unauthorized traffic; disable malware and repair
infections; manage and administer software and updates;
monitor behavior and critical data; and enable endpoints
to be tracked, troubleshooted, and wiped, if necessary.
Security
Analytics -
SIEM
IBM Security QRadar
XDR
Collects and consolidates security information and security
event data from many sources; correlates and analyzes the
data to help detect anomalies and recognize potential
threats and vulnerabilities; and logs the data to adhere to
data compliance requirements.
Security
Analytics –
Endpoint
Monitoring
Tenable.io
Discovers all IP-connected endpoints and performs
continuous collection, examination, and analysis of
software versions, configurations, and other information
regarding hosts (devices or VMs) that are connected to the
network.
Security
Analytics -
Vulnerability
Scanning and
Assessment
Tenable.io and
Tenable.ad
Scans and assesses the enterprise infrastructure and
resources for security risks, identifies vulnerabilities and
misconfigurations, and provides remediation guidance
regarding investigating and prioritizing responses to
incidents.
Security
Analytics -
SOAR
IBM Cloud Pak for
Security
Integrates the SIEM and other security tools into a single
pane of glass to support generation of insights into threats
and to help track, manage, and resolve cybersecurity
incidents.
Executes predefined incident response workflows to
automatically analyze information and orchestrate the
operations required to respond.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 110
Component
Product
Function
Security
Analytics -
Security
Validation
Mandiant Security
Validation
Provides visibility and evidence on the status of the
security controls’ effectiveness in the ZTA. Enables security
capabilities of the enterprise to be monitored and verified
by continuously validating and measuring the
cybersecurity controls; also used to automate the
demonstrations that were performed to showcase ZTA
capabilities. Deployed throughout the project’s laboratory
environment to enable monitoring and verification of
various security aspects of the builds. VMs that are
intended to operate as actors are deployed on each of the
subnetworks in each of the enterprises. These actors can
be used to initiate various actions for the purpose of
verifying that security controls are working to support the
objectives of zero trust.
General -
Remote
Connectivity
Ivanti Tunnel
Enables authorized remote users to securely access the
inside of the enterprise. (Once inside, the ZTA manages the
users’ access to resources.)
General -
Certificate
Management
DigiCert CertCentral TLS
Manager
Provides automated capabilities to issue, install, inspect,
revoke, renew, and otherwise manage TLS certificates.
General -
Cloud IaaS
AWS - GitLab,
WordPress
Provides computing resources, complemented by storage
and networking capabilities, hosted by a cloud service
provider, offered to customers on demand, and exposed
through a GUI and an API.
General -
Cloud SaaS
Digicert CertCentral,
Ivanti Access ZSO, Ivanti
Neurons for UEM, Okta
Identity Cloud, and
Tenable.io, and
Zimperium MTD
Cloud-based software delivered for use by the enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In this build,
GitLab is integrated with Okta using SAML, and IBM
Security QRadar XDR pulls logs from GitLab.)
General -
Enterprise-
Managed
Device
Mobile devices (iOS and
Android)
Example endpoints to be protected. All enterprise-
managed devices are running an Ivanti Neurons for UEM
agent and also have the Okta Verify App installed.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 111
Component
Product
Function
General -
BYOD
Mobile devices (iOS and
Android)
Example endpoints to be protected.
D.2 Build Architecture
3192
In this section we present the logical architecture of E1B1 relative to how it instantiates the EIG crawl
3193
phase reference architecture depicted in Figure 4-2. We also describe E1B1’s physical architecture and
3194
present message flow diagrams for some of its processes.
3195
D.2.1 Logical Architecture
3196
Figure D-1 depicts the logical architecture of E1B1. Figure D-1 uses numbered arrows to depict the
3197
general flow of messages needed for a subject to request access to a resource and have that access
3198
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
3199
user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting
3200
periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of
3201
requesting endpoint health, all of which must be performed to continually reevaluate access. The
3202
labeled steps in Figure D-1 have the same meanings as they do in Figure 4-1 and Figure 4-2. However,
3203
while Figure 4-2 depicts generic EIG crawl phase ZTA components, Figure D-1 includes the specific
3204
products that instantiate the architecture of E1B1. Figure D-1 also does not depict any of the resource
3205
management steps found in Figure 4-1 and Figure 4-2 because the ZTA technologies deployed in E1B1
3206
do not support the ability to perform authentication and reauthentication of the resource or periodic
3207
verification of resource health.
3208
E1B1 was designed with a single ICAM system (Okta Identity Cloud) that serves as the identity, access,
3209
and credential manager as well as the ZTA PE and PA. It includes the Ivanti Sentry as its PEP, and it also
3210
delegates some PDP responsibilities to Ivanti Access ZSO. Radiant Logic acts as a PIP for the PDP as it
3211
responds to inquiries and provides identity information on demand in order for Okta to make near-real-
3212
time access decisions. A more detailed depiction of the messages that flow among components to
3213
support a user access request can be found in Appendix D.2.4.
3214
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 112
Figure D-1 Logical Architecture of E1B1
3215
D.2.2 ICAM Information Architecture
3216
How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used
3217
among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture
3218
ensures that when a subject requests access to a resource, the aggregated set of identity information
3219
and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a
3220
basis on which to make the access decision.
3221
In E1B1, Okta, Radiant Logic, and SailPoint integrate with each other as well as with other components
3222
of the ZTA to support the ICAM information architecture. Okta Identity Cloud uses authentication and
3223
authorization to manage access to enterprise resources. SailPoint governs and RadiantOne aggregates
3224
identity information that is available from many sources within the enterprise. Radiant Logic stores,
3225
normalizes, and correlates this aggregation of information and extended attributes and provides
3226
appropriate views of the information in response to queries. RadiantOne monitors each source of truth
3227
for identity and updates changes in near real-time to ensure that Okta is able to enforce access based on
3228
accurate data. SailPoint is responsible for governance of the identity data. It executes automated, policy-
3229
based workflows to manage the lifecycle of user identity information and manage user accounts and
3230
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Okta Identity Cloud
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Supporting Components
Endpoint Security:
• Ivanti Neurons for UEM
• Zimperium MTD
ICAM: Okta Identity Cloud
Federated Identity:
Radiant Logic RadiantOne
Identity Governance:
SailPoint IdentityIQ
Security Analytics:
• IBM Security QRadar XDR
• IBM Cloud Pak for Security
• Tenable.io and Tenable.ad
• Mandiant MSV
Ivanti Sentry
Multi-Factor Authentication:
• Okta IDaaS and Okta Verify App
Ivanti Access ZSO
AWS
Cloud
Policy Information Points
(PIPs)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 113
permissions, ensuring compliance with requirements and regulations. To perform its identity
3231
aggregation and correlation functions, Radiant Logic connects to all locations within the enterprise
3232
where identity data exists to create a virtualized central identity data repository. SailPoint may also
3233
connect directly to sources of identity data or receive additional normalized identity data from Radiant
3234
Logic in order to perform its governance functions.
3235
Use of these three components to support the ICAM information architecture in Enterprise 1 is intended
3236
to demonstrate how a large enterprise with a complex identity environment might operate—for
3237
example, an enterprise with two ADs and multiple sources of identity information, such as HR platforms,
3238
the back-end database of a risk-scoring application, a credential management application, a learning
3239
management application, on-premises LDAP and databases, etc. Mimicking a large, complex enterprise
3240
enables the project to demonstrate the ability to aggregate identity data from many sources and
3241
provide identity managers with a rich set of attributes on which to base access policy. By aggregating
3242
risk-scoring and training data with more standard identity profile information found in AD, rich user
3243
profiles can be created, enabling enterprise managers to formulate and enforce highly granular access
3244
policies. Information from any number of the identity and attribute sources can be used to make
3245
authentication and authorization decisions. In addition, such aggregation allows identities for users in a
3246
partner organization whose identity information is not in the enterprise AD to be made available to the
3247
enterprise identity manager, so it has the information required to grant or deny partner user access
3248
requests. Policy-based access enforcement is also possible, in which access groups can be dynamically
3249
generated based on attribute values.
3250
Although federated identity and identity governance technologies provide automation to ease the
3251
burden of aggregating identity information and enforcing identity governance, they are not required
3252
supporting components for implementing a ZTA in situations in which there may only be one or a few
3253
sources of identity data. However, they may become increasingly useful with the incorporation of
3254
additional non-traditional identity data, such as application allow-lists, training and certification levels,
3255
and travel data into the attribute set.
3256
The subsections below explain the operations of the ICAM information architecture for E1B1 when
3257
correlating identity information and when a user joins, changes roles, or leaves the enterprise. The
3258
operations depicted support identity correlation, identity management, identity authentication and
3259
authorization, and SIEM notification. It is worth noting that both Okta and SailPoint also support
3260
additional features that we have not deployed at this time, such as the ability to perform just-in-time
3261
provisioning of user accounts and permissions and the ability to remove access permissions or
3262
temporarily disable access authorizations from user accounts in response to alerts triggered by
3263
suspicious user activity.
3264
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 114
D.2.2.1 Identity Correlation
3265
Figure D-2 depicts the ICAM information architecture for E1B1 showing the steps involved in correlating
3266
identity information to build a rich global profile that includes not just identity profiles found in AD, but
3267
additional profiles and attributes from other platforms as well. The steps are as follows:
3268
1. RadiantOne aggregates, correlates, and normalizes identity information from all sources of
3269
identity information in the enterprise. In complex architectures, a ZTA requires an identity data
3270
foundation that bridges legacy systems and cloud technologies, and that extends beyond legacy
3271
AD domains. In our builds, the identity source used is an example human resources (HR)
3272
database that is augmented by extended user profile and attribute information that is
3273
representative of information that could come from a variety of identity sources in a large
3274
enterprise. A credential management database, an LDAP database, and a learning management
3275
application are some examples of such identity sources. These are depicted in the lower left-
3276
hand corner of Figure D-2 in the box labeled “Enhanced Identity Data Sources.”
3277
2. The correlated identity profiles in RadiantOne are consumed by SailPoint.
3278
3. SailPoint provisions identities into AD. Multiple AD instances may be present in the enterprise,
3279
as depicted. However, each of our builds includes only one AD instance.
3280
4. RadiantOne correlates endpoint identities from AD.
3281
5. SailPoint provisions identities into appropriate enterprise resources—e.g., SaaS, IaaS, enterprise
3282
applications, and endpoint protection platforms. (This provisioning may occur directly or via
3283
Okta.)
3284
6. As the new identities appear in the SaaS, IaaS, enterprise application, endpoint protection, and
3285
other components, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes
3286
this new identity information and adds it back into the global identity profile that it is
3287
maintaining. It also updates its HR, authentication, and authorization views to reflect the recent
3288
changes. Okta will eventually query these authentication and authorization information views in
3289
Radiant Logic to determine whether to grant future user access requests.
3290
7. Because Okta is maintaining its own internal identity directory, which is a mirrored version of
3291
the information in Radiant Logic, Okta consumes identities from Radiant Logic RadiantOne
3292
profiles. However, Okta does not store user password information.
3293
8. RadiantOne correlates identities that it gets from Okta.
3294
The identity correlation lifecycle is an ongoing process that occurs continuously as events that affect
3295
user identity information, accounts, and permissions occur, ensuring that the global identity profile is up
3296
to date. Example of such events are depicted in the subsections below.
3297
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 115
Figure D-2 E1B1 ICAM Information Architecture – Identity Correlation
3298
Credential
Mgt
SAP HR
SIEM
AD
1
Okta
SaaS
IaaS
Enterprise App
Endpoint
Protection
Event Triggers
Incident Enrichment
Identity Metadata
Lifecycle Automation
Joiner, Mover, Leaver,
Entitlement Request
SailPoint
AuthN
/AuthZ
Radiant
Logic
6. RadiantOne correlates
additional sources of identity
data
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premises
LDAP and Db
Learning Mgt
1. Existing
sources of
identity are
correlated in
RadiantOne
2. Identity
profiles are
consumed from
RadiantOne by
SailPoint
3. SailPoint
provisions
identities into
endpoints
4. RadiantOne
correlates
endpoint identity
7. Okta
consumes
identities from
RadiantOne
profiles
8. RadiantOne
correlates Okta
identities
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
5. SAILPOINT provisions
identities into appropriate
enterprise resources
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 116
D.2.2.2 User Joins the Enterprise
3299
Figure D-3 depicts the ICAM information architecture for E1B1 showing the steps required to provision a
3300
new identity and associated access privileges when a new user is onboarded to the enterprise. The steps
3301
are as follows:
3302
1. When a new user joins the enterprise, an authorized HR staff member is assumed to input
3303
information into some sort of enterprise employee onboarding and management HR application
3304
that will ultimately result in a new, active HR record for the employee appearing in the Radiant
3305
Logic human resources record view. In practice, the application that the HR staff member uses
3306
will typically store identity records in backend databases like the ones depicted in the lower left-
3307
hand corner of Figure D-3 that are in the box labeled “Enhanced Identity Data Sources.” As these
3308
databases get updated, Radiant Logic is notified, and it responds by collecting the new
3309
information and using it to dynamically update its HR view.
3310
2. In the course of performing its governance activities, SailPoint detects the new HR record in
3311
Radiant Logic. SailPoint evaluates this new HR record, which triggers a Joiner lifecycle event,
3312
causing SailPoint to execute a policy-driven workflow that includes steps 3, 4, and 5.
3313
3. SailPoint provisions access permissions to specific enterprise resources for this new user. These
3314
access permissions, known as the user’s Birthright Role Access, are automatically determined
3315
according to policy based on factors such as the user’s role, type, group memberships, and
3316
status. These permissions comprise the access entitlements that the employee has on day 1.
3317
SailPoint creates an account for the new user in AD, thereby provisioning appropriate enterprise
3318
resource access for the new user. Also (not labeled in the diagram), Radiant Logic then collects
3319
and correlates this user information from AD into the global identity profile that it is
3320
maintaining.
3321
4. Assuming there are resources for which access is not managed by AD that the new user is
3322
authorized to access according to their Birthright Role, SailPoint also provisions access to these
3323
resources for the new user by creating new accounts for the user, as appropriate, on SaaS, IaaS,
3324
enterprise application, MDM, EPP, and other components. (This provisioning may occur directly
3325
or via Okta.)
3326
5. Once the new identity and its access privileges have been provisioned, SailPoint audits the
3327
identity and provisioning actions that were just performed.
3328
6. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint
3329
protection, and other components, Radiant Logic is notified. Radiant Logic collects, correlates,
3330
and virtualizes this new identity information, then adds it back into the global identity profile
3331
that it is maintaining. It also updates its HR, authentication, and authorization (AuthN/AuthZ)
3332
views to reflect the recent changes. Okta will eventually query these authentication and
3333
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 117
authorization information views in Radiant Logic to determine whether or not to grant future
3334
user access requests. (Note that Okta will only query these views in Radiant Logic when a user
3335
tries to access a resource; it will not query if there is no action from the user.)
3336
7. In addition, because Okta is maintaining its own internal identity directory, which is a mirrored
3337
version of the information in Radiant Logic, Radiant Logic pushes the new account identity
3338
information into Okta, thereby synchronizing its extended user profile attribute information
3339
with Okta. This provides Okta with additional contextual data regarding users and devices that
3340
Radiant Logic has aggregated from all identity sources, beyond the birthright provisioning
3341
information that SailPoint provided. Also (not labeled in the diagram), Radiant Logic then
3342
collects and correlates identity information from Okta back into the global identity profile that it
3343
is maintaining.
3344
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 118
Figure D-3 E1B1 ICAM Information Architecture – New User Onboarding
3345
Credential
Mgt
SAP HR
SIEM
AD
1
Okta
SaaS
IaaS
Enterprise App
Endpoint Prot
Event Triggers
Incident Enrichment
Identity Metadata
SailPoint
AuthN
/AuthZ
Radiant
Logic
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premises
LDAP and Db
Learning Mgt
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
1) New, active
HR record
appears in
Radiant Logic HR
view
2) SailPoint detects
new HR record,
which triggers a
Joiner lifecycle event
3) SailPoint
provisions
Birthright
Role access
to
appropriate
enterprise
resources
4) SailPoint provisions
Birthright Role access to
appropriate enterprise
resources
5) SailPoint audits new
identity and provisioning
actions
6) Radiant Logic updates
the HR and AuthN/AuthZ
views as new enterprise
accounts appear
7) Radiant Logic
provides extended user
profile attribute
synchronization with
Okta
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 119
D.2.2.3 User Changes Roles
3346
Figure D-4 depicts the ICAM information architecture for E1B1, showing the steps required to remove
3347
some access privileges and add other access privileges for a user in response to that user changing roles
3348
within the enterprise. The steps are as follows:
3349
1. When a user changes roles within the enterprise, an authorized HR staff member is assumed to
3350
input information into some sort of enterprise employee management application that will
3351
result in the Radiant Logic HR record for that user indicating that the user has changed roles.
3352
2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR
3353
record, which triggers a Mover lifecycle event, causing SailPoint to execute a policy-driven
3354
workflow that includes steps 3, 4, 5, and 6.
3355
3. SailPoint removes access permissions associated with the user’s prior role (but not with the
3356
user’s new role) from the user’s AD account and removes access from other enterprise
3357
resources (e.g., SaaS, IaaS, enterprise applications, MDM) that the user had been authorized to
3358
access as a result of their prior role, but they are not authorized to access as a result of their
3359
new role. Also (not labeled in the diagram), Radiant Logic then collects and correlates any
3360
changes that were made to the user’s account from AD into the global identity profile that it is
3361
maintaining.
3362
4. Assuming there are enterprise resources that the user’s new role entitles them to access that
3363
are not managed by AD, SailPoint provisions access to these resources for the user by creating
3364
new accounts for the user, as appropriate, in SaaS, IaaS, enterprise application, endpoint
3365
protection, MDM, and other components. (This provisioning may occur directly or via Okta.)
3366
5. SailPoint generates an access review for management to confirm or revoke the changes that
3367
have been made. Such an access review is not strictly necessary. The permission changes could
3368
be executed in a fully automated manner, if desired, and specified by policy. However, having an
3369
access review provides management with the opportunity to exercise some supervisory
3370
discretion to permit the user to temporarily continue to have access to some resources
3371
associated with their former role that may still be needed.
3372
6. Once the access review has been completed and any access privilege changes deemed
3373
necessary have been performed, SailPoint audits the changes.
3374
7. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint
3375
protection, and other components, and as existing account access is removed, Radiant Logic is
3376
notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds
3377
it back into the global identity profile that it is maintaining. It also updates its HR,
3378
authentication, and authorization views to reflect the recent changes. Okta will eventually query
3379
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 120
these authentication and authorization information views in Radiant Logic to determine
3380
whether to grant future user access requests.
3381
8. In addition, because Okta is maintaining its own internal identity directory, which is a mirrored
3382
version of the information in Radiant Logic, Radiant Logic pushes the modified account identity
3383
information into Okta, thereby synchronizing its user profile attribute information with Okta.
3384
Also (not labeled in the diagram), Radiant Logic then collects and correlates identity information
3385
from Okta back into the global identity profile that it is maintaining.
3386
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 121
Figure D-4 E1B1 ICAM Information Architecture - User Changes Roles
3387
Credential
Mgt
SAP HR
SIEM
AD
1
Okta
SaaS
IaaS
Enterprise App
Endpoint Prot
Event Triggers
Incident Enrichment
Identity Metadata
SailPoint
AuthN
/AuthZ
Radiant
Logic
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premises
LDAP and Db
Learning Mgt
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
1) Radiant Logic
HR record
indicates an
existing user
changes roles
2) SailPoint detects
updated HR record,
which triggers Mover
lifecycle event
3) SailPoint
removes
access
associated
with old role
4) SailPoint provisions
access associated with
new role
5) SailPoint generates
access review for
management to
confirm/revoke change
6) SailPoint audits changes
7) Radiant Logic updates
HR and AuthN/AuthZ
views as account
permissions change
8) RadiantLogic
provides extended user
profile attribute
synchronization with
Okta
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 122
D.2.2.4 User Leaves the Enterprise
3388
Figure D-5 depicts the ICAM information architecture for E1B1 showing the steps required to disable or
3389
delete an identity and remove access privileges in response to a user leaving the enterprise. The steps
3390
are as follows:
3391
1. When a user’s employment is terminated, an authorized HR staff member is assumed to input
3392
information into some sort of enterprise employee management application that will result in
3393
the Radiant Logic HR record for that user indicating that the user has changed from active to
3394
inactive status.
3395
2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR
3396
record, which triggers a Leaver lifecycle event, causing SailPoint to execute a policy-driven
3397
workflow that includes steps 3, 4, 5, and 6.
3398
3. SailPoint removes all access permissions associated with the user identity from AD. Also (not
3399
labeled in the diagram), Radiant Logic then collects and correlates this user access authorization
3400
change from AD into the global identity profile that it is maintaining.
3401
4. SailPoint either disables or deletes all enterprise resource accounts associated with the user
3402
identity, as defined by policy, from components such as SaaS, IaaS, enterprise applications, and
3403
endpoint protection platforms. (SailPoint may perform these actions directly or via Okta.)
3404
5. SailPoint removes the user identity from all governance groups the identity is in.
3405
6. SailPoint audits the changes made as a result of this user termination.
3406
7. As the enterprise accounts associated with the user’s identity are deleted or disabled, Radiant
3407
Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information
3408
and adds it back into the global identity profile that it is maintaining. It also updates its HR,
3409
authentication, and authorization views to reflect the recent changes. Okta will eventually query
3410
these authentication and authorization information views in Radiant Logic to determine
3411
whether or not to grant future user access requests.
3412
8. In addition, because Okta is maintaining its own internal identity directory, which is a mirrored
3413
version of the information in Radiant Logic, Radiant Logic pushes the modified account identity
3414
information into Okta, thereby synchronizing its user profile attribute information with Okta.
3415
Also (not labeled in the diagram), Radiant Logic then collects and correlates identity information
3416
from Okta back into the global identity profile that it is maintaining.
3417
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 123
Figure D-5 E1B1 ICAM Information Architecture - User Termination
3418
Credential
Mgt
SAP HR
SIEM
AD
1
Okta
SaaS
IaaS
Enterprise App
Endpoint Prot
Event Triggers
Incident Enrichment
Identity Metadata
SailPoint
AuthN
/AuthZ
Radiant
Logic
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premises
LDAP and Db
Learning Mgt
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
1) Radiant Logic
HR record
indicates a status
change from
active to inactive
2) SailPoint
detects updated
HR record which
triggers Leaver
lifecycle event
3) SailPoint
removes
access
associated
with identity
4) SailPoint
disables/deletes
enterprise resource
accounts as defined by
policy
5) SailPoint removes user
from governance groups
6) SailPoint audits
termination
7) Radiant Logic updates
HR and AuthN/AuthZ
views as identity accounts
are disabled/deleted
8) Radiant Logic
provides extended user
profile attribute
synchronization with
Okta
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 124
D.2.3 Physical Architecture
3419
Sections 4.4.1 and 4.5.2 describe and depict the physical architecture of the E1B1 headquarters network
3420
and the E1B1 branch office network, respectively. In addition to what is represented in Section 3.4 E1B1
3421
has a VLAN on which servers hosting IBM Cloud Pak for Security components reside. It also has
3422
MobileIron Connector in its Shared Services VLAN and MobileIron Sentry in its DMZ VLAN.
3423
D.2.4 Message Flow for a Successful Resource Access Request
3424
Figure D-6 shows the high-level message flow for a use case in which a subject who has an enterprise ID,
3425
is located on-premises, and is authorized to access an enterprise resource requests and receives access
3426
to that resource. In the case depicted in the figure, access to the resource is protected by the Ivanti
3427
Sentry gateway, which acts as a PEP; Ivanti Neurons for UEM, which consists of a UEM agent on the
3428
endpoint and a cloud component that work together to authenticate the requesting endpoint and
3429
determine whether or not it is compliant; Ivanti Access ZSO, which acts as a delegated IdP and consults
3430
the Okta Identity Cloud to authenticate the requesting user; and the Okta Verify App, which performs
3431
second-factor user authentication.
3432
The message flow depicted in Figure D-6 shows only the messages that are sent in response to the
3433
access request. However, the authentication process also relies on the following additional background
3434
communications that occur among components on an ongoing basis:
3435
▪ The Ivanti Neurons for UEM agent periodically synchronizes with Ivanti Neurons for UEM to
3436
reauthenticate the requesting endpoint device using a unique certificate that has been
3437
provisioned specifically for that device and send Ivanti Neurons for UEM information about
3438
device attributes.
3439
▪ Zimperium periodically sends mobile defense threat information to Ivanti Neurons for UEM.
3440
▪ Ivanti Neurons for UEM determines device health status based on the above information that it
3441
receives from both the Ivanti Neurons for UEM agent and Zimperium.
3442
▪ Ivanti Neurons for UEM periodically sends device health information to Ivanti Access ZSO.
3443
▪ Ivanti Neurons for UEM also periodically sends device health information to the Ivanti Sentry
3444
gateway.
3445
▪ Okta periodically synchronizes with Ivanti Neurons for UEM and Ivanti Access ZSO to get the
3446
most up-to-date identity information and ensure that the endpoint device is managed by Ivanti
3447
Neurons for UEM.
3448
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 125
Figure D-6 Successful Access Request Enforced by Okta, Ivanti, and Zimperium Components
3449
The message flow depicted in Figure D-6 assumes that a VPN between an app on the user’s endpoint
3450
and the Ivanti Sentry gateway (PEP) has already been set up and connected prior to the user’s access
3451
request. This VPN connection is established automatically as soon as the device is connected to the
3452
network, and it can be configured to be in an “Always On” state. The steps in this message flow, which
3453
depicts a successful resource access, are as follows:
3454
1. The user logs into their device and authenticates themselves according to organization policy as
3455
configured in Ivanti Neurons for UEM. (This login could be accomplished with a fingerprint ID,
3456
face ID, PIN, derived credentials, or any other mechanism that is supported by the device and
3457
permitted by organizational policy as configured in the UEM.)
3458
2. The user requests to access a resource. This request is sent on the VPN from the user’s endpoint
3459
to the Ivanti Sentry gateway, which acts as a PEP.
3460
3. Based on information about the endpoint and user that the Ivanti Sentry gateway has received
3461
in the background from Ivanti Neurons for UEM, the Ivanti Sentry gateway determines that,
3462
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
Ivanti
Sentry
Gateway
Okta Identity Cloud
3. Ivanti Sentry permits the request to go to Okta
Resource
Subject
Ivanti
Neurons for
UEM Agent
Ivanti
Access ZSO
User
2. User makes a request to access the resource. The request
is sent on the Ivanti VPN to Ivanti Sentry (a PEP)
Ivanti Neurons for UEM,
Zimperium Mobile
Threat Defense
15. Resource accepts the token and grants the access request.
The user access session between the endpoint and the resource is secured according to policy
Ivanti
VPN App
7. Ivanti Access ZSO
authenticates the user and
verifies that the request is
compliant with policy
Okta Verify
App
14. Ivanti Sentry permits the token to go to the resource
6. Okta forwards request
to Ivanti Access ZSO
8. Ivanti Access ZSO notifies Okta that
it has approved the access request
11. Okta creates SAML token
and sends it to endpoint
12. Endpoint sends the token to the resource via the Ivanti VPN
13. Ivanti Sentry verifies device health
9. Okta challenges user to provide
second factor authentication via
the Okta Verify App
10. User provides second authentication factor
(biometrics)
1. User logs
into device
4. Okta challenges user to provide
first factor authentication
5. User chooses first authentication factor
(Okta FastPass + Ivanti Certificate)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 126
according to policy, this request is permitted to be sent to Okta, so it allows the access request
3463
to proceed to the Okta Identity Cloud component.
3464
4. Okta requests the user to provide authentication information by using Okta FastPass. Okta
3465
FastPass allows the user to bypass username and password authentication because Okta trusts
3466
that the user properly authenticated when they initially logged into the device in step 1, and
3467
Okta knows (from background communications with Ivanti Access ZSO) that Ivanti Neurons for
3468
UEM is managing the device.
3469
5. The user provides first-factor authentication information by pressing the Okta FastPass button
3470
displayed on the device.
3471
6. Okta forwards the access request information to Ivanti Access ZSO because Okta will rely on and
3472
trust Ivanti Access ZSO to perform user authentication and verify the request’s attributes to
3473
ensure that they conform with policy. In this instance, Ivanti Access will act as a PDP to
3474
determine whether the access request should be granted.
3475
7. Ivanti Access authenticates the user using the access request information relayed by Okta. Ivanti
3476
Access gets user identities, attributes, and device information from a published certificate that
3477
was provisioned uniquely to the device. The certificate contains user information in a Certificate
3478
Subject Alternative field. Ivanti Neurons for UEM uses Okta as an identity provider and regularly
3479
syncs with Okta to remain up to date. It does not reach back to Okta every time an identity
3480
request comes in. Ivanti Access also verifies that the device complies with its conditional access
3481
policy. If any policy is being violated, device access is blocked, and a remediation page is
3482
presented to the user. Ivanti Access ZSO makes this determination based on information it has
3483
been receiving in the background from Ivanti Neurons for UEM and Zimperium.
3484
8. Ivanti Access ZSO notifies Okta that it has approved the access request by signing an
3485
authentication token using the Ivanti Access ZSO signing certificate.
3486
9. Okta initiates second-factor authentication using the Okta Verify App. Okta requires the user to
3487
present their biometric information to authenticate themselves to the device, and then the Okta
3488
Verify App displays a notification on the device informing the user that they must respond (e.g.,
3489
tap a confirmation button on the display) to prove that they are in possession of the device.
3490
10. The user presents their biometric information and responds to the Okta Verify notification,
3491
thereby providing the second authentication factor.
3492
11. Okta creates a SAML assertion and sends it to the requesting endpoint.
3493
12. The requesting endpoint sends the SAML assertion to the resource via the VPN that connects to
3494
the Ivanti Sentry gateway.
3495
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 127
13. The Ivanti Sentry gateway verifies device health and compliance based on the device
3496
information it has been receiving in the background from Ivanti Neurons for UEM.
3497
14. The Ivanti Sentry gateway permits the SAML assertion to proceed to the resource.
3498
15. The resource accepts the assertion and grants the access request. User traffic to and from the
3499
resource is secured according to policy (e.g., using TLS or HTTPS).
3500
Note that the message flow depicted in Figure D-6 applies to several of the use cases we are
3501
considering. It applies to all cases in which a user with an enterprise ID who can successfully
3502
authenticate themselves and who is using an enterprise-owned endpoint requests and receives access
3503
to an enterprise resource that they are authorized to access. The message flow is the same regardless of
3504
whether the employee is located on-premises at headquarters, on-premises at a branch office, or off-
3505
premises at home or elsewhere. It is also the same regardless of whether the resource is located on-
3506
premises or in the cloud.
3507
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 128
Appendix E Enterprise 2 Build 1 (E2B1) – EIG Crawl
3508
E.1 Technologies
3509
E2B1 uses products from Cisco Systems, IBM, Mandiant, Palo Alto Networks, Ping Identity, Radiant
3510
Logic, SailPoint, and Tenable. Certificates from DigiCert are also used. For more information on these
3511
collaborators and the products and technologies that they contributed to this project overall, see
3512
Section 3.4.
3513
E2B1 components consist of PingFederate, which is connected to the Ping Identity SaaS offering of
3514
PingOne, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Cisco Duo,
3515
Palo Alto Networks Next Generation Firewall, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable
3516
Nessus Network Monitor (NNM), Mandiant Security Validation (MSV), and DigiCert CertCentral.
3517
Table E-1 lists all of the technologies used in E2B1. It lists the products used to instantiate each ZTA
3518
component and the security function that each component provides.
3519
Table E-1 E2B1 Products and Technologies
3520
Component
Product
Function
PE
Ping Identity
PingFederate
Decides whether to grant, deny, or revoke access to a
resource based on enterprise policy, information from
supporting components, and a trust algorithm.
PA
Ping Identity
PingFederate
Executes the PE’s policy decision by sending commands to a
PEP that establishes and shuts down the communication
path between subject and resource.
PEP
Ping Identity
PingFederate
Cisco Duo
Guards the trust zone that hosts one or more enterprise
resources; establishes, monitors, and terminates the
connection between subject and resource as directed by
the PA; forwards requests to and receives commands from
the PA.
ICAM - Identity
Management
Ping Identity
PingFederate
Creates and manages enterprise user and device accounts,
identity records, role information, and access attributes
that form the basis of access decisions within an
organization to ensure the correct subjects have the
appropriate access to the correct resources at the
appropriate time.
ICAM - Access &
Credential
Management
Ping Identity
PingFederate
Manages access to resources by performing user and
device authentication (e.g., SSO and MFA) and using
identity, role, and access attributes to determine which
access requests are authorized.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 129
Component
Product
Function
ICAM - Federated
Identity
Radiant Logic
RadiantOne
Intelligent Identity
Data Platform
Aggregates and correlates all attributes relating to an
identity or object that is being authorized by a ZTA. It
enables users of one domain to securely access data or
systems of 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.
ICAM - Identity
Governance
SailPoint
IdentityIQ
Provides policy-based, centralized, automated processes to
manage user identity and access control functions (e.g.,
ensuring segregation of duties, role management, logging,
access reviews, analytics, reporting) to ensure compliance
with requirements and regulations.
ICAM - MFA
Cisco Duo
Supports MFA of a user identity by requiring the user to
provide not only something they know (e.g., a password),
but also something they have (e.g., a token).
Endpoint Security
- UEM/MDM
None
Manages and secures enterprise desktop computers,
laptops, and/or mobile devices in accordance with
enterprise policy to protect applications and data; ensure
device compliance; mitigate and remediate vulnerabilities
and threats; monitor for suspicious activity to prevent and
detect intrusions; prevent, detect, and disable malware and
other malicious or unauthorized traffic; repair infected files
when possible; provide alerts and recommend remediation
actions; and encrypt data.
Pushes enterprise applications and updates to devices,
enables users to download enterprise applications that they
are authorized to access, remotely deletes all applications
and data from devices if needed, tracks user activity on
devices, and detects and addresses security issues on the
device.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 130
Component
Product
Function
Endpoint Security
- EPP
None
Detects and stops threats to endpoints through an
integrated suite of endpoint protection technologies
including antivirus, data encryption, intrusion prevention,
EDR, and DLP. May include mechanisms that are designed
to protect applications and data; ensure device compliance
with policies regarding hardware, firmware, software, and
configuration; monitor endpoints for vulnerabilities,
suspicious activity, intrusion, infection, and malware; block
unauthorized traffic; disable malware and repair infections;
manage and administer software and updates; monitor
behavior and critical data; and enable endpoints to be
tracked, troubleshooted, and wiped, if necessary.
Endpoint Security
- Endpoint
Compliance
Cisco Duo
Performs device health checks by validating specific tools or
services within the endpoint including antivirus, data
encryption, intrusion prevention, EPP, and firewall. If the
device does not pass the health check, Duo fails second-
factor authentication and denies user access.
Security Analytics
- SIEM
IBM Security
QRadar XDR
Collects and consolidates security information and security
event data from many sources; correlates and analyzes the
data to help detect anomalies and recognize potential
threats and vulnerabilities; and logs the data to adhere to
data compliance requirements.
Security Analytics
- Endpoint
Monitoring
Tenable.io
Discovers all IP-connected endpoints and performs
continuous collection, examination, and analysis of
software versions, configurations, and other information
regarding hosts (devices or VMs) that are connected to the
network
Security Analytics
- Vulnerability
Scanning and
Assessment
Tenable.io and
Tenable.ad
Scans and assesses the enterprise infrastructure and
resources for security risks, identifies vulnerabilities and
misconfigurations, and provides remediation guidance
regarding investigating and prioritizing responses to
incidents.
Security Analytics
- Traffic Inspection
Tenable NNM
Intercepts, examines, and records relevant traffic
transmitted on the network.
Security Analytics
- Network
Discovery
Tenable NNM
Discovers, classifies, and assesses the risk posed by devices
and users on the network.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 131
Component
Product
Function
Security Analytics
- Security
Validation
Mandiant Security
Validation
Provides visibility and evidence on the status of the security
controls’ effectiveness in the ZTA. Enables security
capabilities of the enterprise to be monitored and verified
by continuously validating and measuring the cybersecurity
controls; also used to automate the demonstrations that
were performed to showcase ZTA capabilities. Deployed
throughout the project’s laboratory environment to enable
monitoring and verification of various security aspects of
the builds. VMs that are intended to operate as actors are
deployed on each of the subnetworks in each of the
enterprises. These actors can be used to initiate various
actions for the purpose of verifying that security controls
are working to support the objectives of zero trust.
General - Remote
Connectivity
Palo Alto
Networks NGFW
Enables authorized remote users to securely access the
inside of the enterprise. (Once inside, the ZTA manages the
user’s access to resources.)
General -
Certificate
Management
DigiCert
CertCentral TLS
Manager
Provides automated capabilities to issue, install, inspect,
revoke, renew, and otherwise manage TLS certificates.
General - Cloud
IaaS
None
Provides computing resources, complemented by storage
and networking capabilities, hosted by a cloud service
provider, offered to customers on demand, and exposed
through a GUI and an API.
General - Cloud
SaaS
Cisco Duo,
Digicert
CertCentral Ping
Identity PingOne
(PingFederate
service), and
Tenable.io
Cloud-based software delivered for use by the enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In this build,
GitLab and WordPress are integrated with Okta using
SAML, and IBM Security QRadar XDR pulls logs from
GitLab.)
General -
Enterprise-
Managed Device
Windows client,
macOS client, and
mobile devices
(iOS and Android)
Example endpoints to be protected. All enterprise-managed
devices are running an Ivanti Neurons for UEM agent and
also have the Okta Verify App installed.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 132
Component
Product
Function
General - BYOD
Windows client,
macOS client, and
mobile devices
(iOS and Android)
Example endpoints to be protected.
E.2 Build Architecture
3521
In this section we present the logical architecture of E2B1 relative to how it instantiates the EIG crawl
3522
phase reference architecture depicted in Figure 4-2. We also describe E2B1’s physical architecture and
3523
present message flow diagrams for some of its processes.
3524
E.2.1 Logical Architecture
3525
Figure E-1 depicts the logical architecture of E2B1. The figure uses numbered arrows to depict the
3526
general flow of messages needed for a subject to request access to a resource and have that access
3527
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
3528
user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting
3529
periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of
3530
requesting endpoint health, all of which must be performed to continually reevaluate access. The
3531
labeled steps in Figure E-1 have the same meanings as they do in Figure 4-1 and Figure 4-2. However,
3532
Figure E-1 includes the specific products that instantiate the architecture of E2B1. Figure E-1 also does
3533
not depict any of the resource management steps found in Figure 4-1 and Figure 4-2 because the ZTA
3534
technologies deployed in E2B1 do not support the ability to perform authentication and
3535
reauthentication of the resource or periodic verification of resource health.
3536
E2B1 was designed with a single ICAM system (Ping Identity PingFederate) that serves as the identity,
3537
access, and credential manager as well as the ZTA PE and PA. PingFederate also serves as its PEP.
3538
Radiant Logic acts as a PIP for the PDP as it responds to inquiries and provides user identity and
3539
authentication information on demand in order for Ping Identity PingFederate to make near-real-time
3540
access decisions. Cisco Duo provides endpoint protection by monitoring the status and configuration of
3541
the endpoint to ensure that its health posture continues to conform with enterprise policy. Duo also
3542
provides second-factor user authentication. Note that both multifactor authentication and directory
3543
services are also available through Ping, but for purposes of this collaborative build, Ping is
3544
demonstrating standards-based interoperability by integrating with Cisco Duo for MFA and Radiant Logic
3545
RadiantOne for federated identity services. A more detailed depiction of the messages that flow among
3546
components to support a user access request can be found in Appendix E.2.4.
3547
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 133
Figure E-1 Logical Architecture of E2B1
3548
E.2.2 ICAM Information Architecture
3549
How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used
3550
among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture
3551
ensures that when a subject requests access to a resource, the aggregated set of identity information
3552
and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a
3553
basis on which to make the access decision.
3554
In E2B1, Ping, Radiant Logic, and SailPoint integrate with each other as well as with other components of
3555
the ZTA to support the ICAM information architecture. Ping Identity PingFederate uses authentication
3556
and authorization to manage access to enterprise resources. SailPoint governs and RadiantOne
3557
aggregates identity information that is available from many sources within the enterprise. Radiant One
3558
stores, normalizes, and correlates this aggregation of information and extended attributes and provides
3559
appropriate views of the information in response to queries. RadiantOne monitors each source of
3560
identity truth and updates changes in near real-time to ensure that Ping is able to enforce access based
3561
on accurate data. SailPoint is responsible for governance of the identity data. It executes automated,
3562
policy-based workflows to manage the lifecycle of user identity information and manage user accounts
3563
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Ping Identity Ping
Federate
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Google
Cloud
Ping Identity Ping Access
Cisco Duo
Supporting Components
Endpoint Security:
• Cisco Duo
ICAM: Ping Identity Ping Federate
Federated Identity:
Radiant Logic RadiantOne
Identity Governance:
SailPoint IdentityIQ
Security Analytics:
• IBM QRadar
• Tenable.io, Tenable.ad, and
Tenable NNM
• Mandiant MSV
Multi-Factor Authentication:
Cisco Duo
Policy Information Points
(PIPs)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 134
and permissions, ensuring compliance with requirements and regulations. To perform its identity
3564
aggregation and correlation functions, Radiant Logic connects to all locations within the enterprise
3565
where identity data exists to create a virtualized central identity data repository. SailPoint may also
3566
connect directly to sources of identity data or receive additional normalized identity data from Radiant
3567
Logic in order to perform its governance functions.
3568
Use of these three components to support the ICAM information architecture in Enterprise 2 is intended
3569
to demonstrate how a large enterprise with a complex identity environment might operate—for
3570
example, an enterprise with two ADs and multiple sources of identity information, such as HR platforms,
3571
the back-end database of a risk-scoring application, a credential management application, a learning
3572
management application, on-premises LDAP and databases, etc. Mimicking a large, complex enterprise
3573
enables the project to demonstrate the ability to aggregate identity data from many sources and
3574
provide identity managers with a rich set of attributes on which to base access policy. By aggregating
3575
risk-scoring and training data with more standard identity profile information found in AD, rich user
3576
profiles can be created, enabling enterprise managers to formulate and enforce highly granular access
3577
policies. Information from any number of the identity and attribute sources can be used to make
3578
authentication and authorization decisions. In addition, such aggregation allows identities for users in a
3579
partner organization whose identity information is not in the enterprise AD to be made available to the
3580
enterprise identity manager so it has the information required to grant or deny partner user access
3581
requests. Policy-based access enforcement is also possible, in which access groups can be dynamically
3582
generated based on attribute values.
3583
Although federated identity and identity governance technologies provide automation to ease the
3584
burden of aggregating identity information and enforcement of identity governance, they are not
3585
required supporting components for implementing a ZTA in situations in which there may only be one or
3586
a few sources of identity data.
3587
The subsections below explain the operations of the ICAM information architecture for E2B1 when
3588
correlating identity information and when a user joins, changes roles, or leaves the enterprise. The
3589
operations depicted support identity correlation, identity management, identity authentication and
3590
authorization, and SIEM notification. It is worth noting that both Ping Identity and SailPoint also support
3591
additional features that we have not deployed at this time, such as the ability to perform just-in-time
3592
provisioning of user accounts and permissions and the ability to remove access permissions or
3593
temporarily disable access authorizations from user accounts in response to alerts triggered by
3594
suspicious user activity.
3595
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 135
E.2.2.1 Identity Correlation
3596
Figure E-2 depicts the ICAM information architecture for E2B1, showing the steps involved in correlating
3597
identity information to build a rich global profile that includes not just identity profiles found in AD, but
3598
additional profiles and attributes from other platforms as well. The steps are as follows:
3599
1. RadiantOne aggregates, correlates, and normalizes identity information from all sources of
3600
identity information in the enterprise. In complex architectures, a ZTA requires an identity data
3601
foundation that bridges legacy systems and cloud technologies, and that extends beyond legacy
3602
AD domains. In our builds, the identity source used is an example HR database that is
3603
augmented by extended user profile and attribute information that is representative of
3604
information that could come from a variety of identity sources in a large enterprise. A credential
3605
management database, an LDAP database, and a learning management application are some
3606
examples of such identity sources. These are depicted in the lower left-hand corner of Figure E-2
3607
in the box labeled “Enhanced Identity Data Sources.”
3608
2. The correlated identity profiles in RadiantOne are consumed by SailPoint.
3609
3. SailPoint provisions identities into AD. Multiple AD instances may be present in the enterprise,
3610
as depicted. However, each of our builds includes only one AD instance.
3611
4. RadiantOne correlates endpoint identities from AD.
3612
5. SailPoint provisions identities into appropriate enterprise resources—e.g., SaaS, IaaS, enterprise
3613
applications, and endpoint protection platforms. (This provisioning may occur directly or via
3614
Ping.)
3615
6. As the new identities appear in the SaaS, IaaS, enterprise application, endpoint protection, and
3616
other components, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes
3617
this new identity information and adds it back into the global identity profile that it is
3618
maintaining. It also updates its HR, authentication, and authorization views to reflect the recent
3619
changes. Ping will eventually query these authentication and authorization information views in
3620
Radiant Logic to determine whether to grant future user access requests.
3621
Note that in this architecture, persistent storage of personally identifiable information (PII) is
3622
not required within any SaaS service. RadiantOne stores all user identity information, and
3623
RadiantOne has been installed on-premises. Ping does not store any user data. When Ping needs
3624
user identity data, it looks up this information directly from RadiantOne.
3625
The identity correlation lifecycle is an ongoing process that occurs continuously as events that affect
3626
user identity information, accounts, and permissions occur, ensuring that the global identity profile is up
3627
to date. Examples of such events are depicted in the subsections below.
3628
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 136
Figure E-2 E2B1 ICAM Information Architecture – Identity Correlation
3629
Credential
Mgt
SAP HR
SIEM
AD
1
Ping Identity
SaaS
IaaS
Enterprise App
Endpoint Prot
Event Triggers
Incident Enrichment
Identity Metadata
AuthN
/AuthZ
Lifecycle Automation
Joiner, Mover, Leaver,
Entitlement Request
SailPoint
Radiant
Logic
6. RadiantOne correlates
additional sources of identity
data
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premise
LDAP and Db
Learning Mgt
1. Existing
sources of
identity are
correlated in
RadiantOne
2. Identity
profiles are
consumed from
RadiantOne by
SailPoint
3. SailPoint
provisions
identities into
endpoints
4. RadiantOne
correlates
endpoint identity
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
5) SailPoint provisions
identities into appropriate
enterprise resources
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 137
E.2.2.2 User Joins the Enterprise
3630
Figure E-3 depicts the ICAM information architecture for E2B1, showing the steps required to provision a
3631
new identity and associated access privileges when a new user is onboarded to the enterprise. The steps
3632
are as follows:
3633
1. When a new user joins the enterprise, an authorized HR staff member is assumed to input
3634
information into some sort of enterprise employee onboarding and management HR application
3635
that will ultimately result in a new, active HR record for the employee appearing in the Radiant
3636
Logic human resources record view. In practice, the application that the HR staff member uses
3637
will typically store identity records in backend databases like the ones depicted in the lower left-
3638
hand corner of Figure D-3 that are in the box labeled “Enhanced Identity Data Sources.” As these
3639
databases get updated, Radiant Logic is notified, and it responds by collecting the new
3640
information and using it to dynamically update its HR view.
3641
2. In the course of performing its governance activities, SailPoint detects the new HR record in
3642
Radiant Logic. SailPoint evaluates this new HR record, which triggers a Joiner lifecycle event,
3643
causing SailPoint to execute a policy-driven workflow that includes steps 3, 4, and 5.
3644
3. SailPoint provisions access permissions to specific enterprise resources for this new user. These
3645
access permissions, known as the user’s Birthright Role Access, are automatically determined
3646
according to policy based on factors such as the user’s role, type, group memberships, and
3647
status. These permissions comprise the access entitlements that the employee has on day 1.
3648
SailPoint creates an account for the new user in AD, thereby provisioning appropriate enterprise
3649
resource access for the new user. Also (not labeled in the diagram), Radiant Logic then collects
3650
and correlates this user information from AD into the global identity profile that it is
3651
maintaining.
3652
4. Assuming there are resources for which access is not managed by AD that the new user is
3653
authorized to access according to their Birthright Role, SailPoint also provisions access to these
3654
resources for the new user by creating new accounts for the user, as appropriate, on SaaS, IaaS,
3655
enterprise application, MDM, EPP, and other components. (This provisioning may occur directly
3656
or via Ping.)
3657
5. Once the new identity and its access privileges have been provisioned, SailPoint audits the
3658
identity and provisioning actions that were just performed.
3659
6. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint
3660
protection, and other components, Radiant Logic is notified. Radiant Logic collects, correlates,
3661
and virtualizes this new identity information and adds it back into the global identity profile that
3662
it is maintaining. It also updates its HR, authentication, and authorization (AuthN/AuthZ) views
3663
to reflect the recent changes. Ping will eventually query these authentication and authorization
3664
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 138
information views in Radiant Logic to determine whether or not to grant future user access
3665
requests. (Note that Ping will only query these views in Radiant Logic when a user tries to access
3666
a resource; it will not query if there is no action from the user. Also, RadiantOne stores all user
3667
identity information; Ping does not store any user data. When Ping needs user identity data, it
3668
looks up this information directly from RadiantOne.)
3669
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 139
Figure E-3 E2B1 ICAM Information Architecture – New User Onboarding
3670
Credential
Mgt
SAP HR
SIEM
AD
1
Ping Identity
SaaS
IaaS
Enterprise App
Endpoint Prot
Event Triggers
Incident Enrichment
Identity Metadata
AuthN
/AuthZ
SailPoint
Radiant
Logic
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premise
LDAP and Db
Learning Mgt
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
1) New, active
HR record
appears in
Radiant Logic HR
view
2) SailPoint detects
new HR record,
which triggers Joiner
lifecycle event
3) SailPoint
provisions
Birthright
Role access
to
appropriate
enterprise
resources
4) SailPoint provisions
Birthright Role access to
appropriate enterprise
resources
5) SailPoint audits new
identity and provisioning
actions
6) Radiant Logic updates
HR and AuthN/AuthZ
views as new enterprise
accounts appear
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 140
E.2.2.3 User Changes Roles
3671
Figure E-4 depicts the ICAM information architecture for E2B1, showing the steps required to remove
3672
some access privileges and add other access privileges for a user in response to that user changing roles
3673
within the enterprise. The steps are as follows:
3674
1. When a user changes roles within the enterprise, an authorized HR staff member is assumed to
3675
input information into some sort of enterprise employee management application that will
3676
result in the Radiant Logic HR record for that user indicating that the user has changed roles.
3677
2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR
3678
record, which triggers a Mover lifecycle event, causing SailPoint to execute a policy-driven
3679
workflow that includes steps 3, 4, 5, and 6.
3680
3. SailPoint removes access permissions associated with the user’s prior role (but not with the
3681
user’s new role) from the user’s AD account and removes access from other enterprise
3682
resources (e.g., SaaS, IaaS, enterprise applications, MDM) that the user had been authorized to
3683
access as a result of their prior role but is not authorized to access as a result of their new role.
3684
Also (not labeled in the diagram), Radiant Logic then collects and correlates any changes that
3685
were made to the user’s account from AD into the global identity profile that it is maintaining.
3686
4. Assuming there are enterprise resources that the user’s new role entitles them to access that
3687
are not managed by AD, SailPoint provisions access to these resources for the user by creating
3688
new accounts for the user, as appropriate, in SaaS, IaaS, enterprise application, endpoint
3689
protection, MDM, and other components. (This provisioning may occur directly or via Ping.)
3690
5. SailPoint generates an access review for management to confirm or revoke the changes that
3691
have been made. Such an access review is not strictly necessary. The permission changes could
3692
be executed in a fully automated manner, if desired, and specified by policy. However, having an
3693
access review provides management with the opportunity to exercise some supervisory
3694
discretion to permit the user to temporarily continue to have access to some resources
3695
associated with their former role that may still be needed.
3696
6. Once the access review has been completed and any access privilege changes deemed
3697
necessary have been performed, SailPoint audits the changes.
3698
7. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint
3699
protection, and other components, and as existing account access is removed, Radiant Logic is
3700
notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds
3701
it back into the global identity profile that it is maintaining. It also updates its HR,
3702
authentication, and authorization views to reflect the recent changes. Ping will eventually query
3703
these authentication and authorization information views in Radiant Logic to determine
3704
whether to grant future user access requests. (RadiantOne stores all user identity information;
3705
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 141
Ping does not store any user data. When Ping needs user identity data, it looks up this
3706
information directly from RadiantOne.)
3707
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 142
Figure E-4 E2B1 ICAM Information Architecture - User Changes Roles
3708
Credential
Mgt
SAP HR
SIEM
AD
1
Ping Identity
SaaS
IaaS
Enterprise App
Endpoint Prot
Event Triggers
Incident Enrichment
Identity Metadata
AuthN
/AuthZ
SailPoint
Radiant
Logic
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premise
LDAP and Db
Learning Mgt
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
1) Radian tLogic
HR record
indicates an
existing user
changes roles
2) SailPoint detects
updated HR record
which triggers Mover
lifecycle event
3) SailPoint
removes
access
associated
with old role
4) SailPoint provisions
access associated with
new role
5) SailPoint generates
access review for
management to
confirm/revoke change
6) SailPoint audits changes
7) Radiant Logic updates
HR and AuthN/AuthZ
views as account
permissions change
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 143
E.2.2.4 User Leaves the Enterprise
3709
Figure E-5 depicts the ICAM information architecture for E2B1, showing the steps required to disable or
3710
delete an identity and remove access privileges in response to a user leaving the enterprise. The steps
3711
are as follows:
3712
1. When a user’s employment is terminated, an authorized HR staff member is assumed to input
3713
information into some sort of enterprise employee management application that will result in
3714
the Radiant Logic HR record for that user indicating that the user has changed from active to
3715
inactive status.
3716
2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR
3717
record, which triggers a Leaver lifecycle event, causing SailPoint to execute a policy-driven
3718
workflow that includes steps 3, 4, 5, and 6.
3719
3. SailPoint removes all access permissions associated with the user identity from AD. Also (not
3720
labeled in the diagram), Radiant Logic then collects and correlates this user access authorization
3721
change from AD into the global identity profile that it is maintaining.
3722
4. SailPoint either disables or deletes all enterprise resource accounts associated with the user
3723
identity, as defined by policy, from components such as SaaS, IaaS, enterprise applications, and
3724
endpoint protection platforms. (SailPoint may perform these actions directly or via Ping.)
3725
5. SailPoint removes the user identity from all governance groups the identity is in.
3726
6. SailPoint audits the changes made as a result of this user termination.
3727
7. As the enterprise accounts associated with the user’s identity are deleted or disabled, Radiant
3728
Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information
3729
and adds it back into the global identity profile that it is maintaining. It also updates its HR,
3730
authentication, and authorization views to reflect the recent changes. Ping will eventually query
3731
these authentication and authorization information views in Radiant Logic to determine
3732
whether or not to grant future user access requests. (RadiantOne stores all user identity
3733
information; Ping does not store any user data. When Ping needs user identity data, it looks up
3734
this information directly from RadiantOne.)
3735
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 144
Figure E-5 E2B1 ICAM Information Architecture - User Termination
3736
Credential
Mgt
SAP HR
SIEM
AD
1
Ping Identity
SaaS
IaaS
Enterprise App
Endpoint Prot
Event Triggers
Incident Enrichment
Identity Metadata
AuthN
/AuthZ
SailPoint
Radiant
Logic
Enhanced Identity Data Sources
AD
2
Workday
Risk Scoring
On Premise
LDAP and Db
Learning Mgt
Legend
Identity Correlation
Identity Management
Identity AuthN/AuthZ
SIEM Notifications
1) Radiant Logic
HR record
indicates a status
change from
active to inactive
2) SailPoint
detects updated
HR record which
triggers Leaver
lifecycle event
3) SailPoint
removes
access
associated
with Identity
4) SailPoint
disables/deletes
enterprise resource
accounts as defined by
policy
5) SailPoint removes user
from governance groups
6) SailPoint audits
termination
7) Radiant Logic updates
HR and AuthN/AuthZ
views as identity accounts
are disabled/deleted
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 145
E.2.3 Physical Architecture
3737
Section 4.5.3 describes the physical architecture of the E2B1 network.
3738
E.2.4 Message Flow for a Successful Resource Access Request
3739
Below is depicted the high-level message flow supporting the use case in which a subject who has an
3740
enterprise ID, who is located on-premises, and who is authorized to access an enterprise resource,
3741
requests and receives access to that resource. In the case depicted here, access to the resource is
3742
protected by PingFederate, which acts as a PDP and an identity provider; Cisco Duo, which consists of an
3743
agent on the endpoint and a cloud component that work together to perform second-factor user
3744
authentication and also to gather device health information to ensure device compliance; and Radiant
3745
Logic, which performs credential validation for authentication and provides granular user-relevant
3746
attributes and groups for authorization at the request of PingFederate.
3747
The message flow depicted in Figure E-6 shows only the messages that are sent in response to the
3748
access request. However, the authentication process also relies on the following additional background
3749
communications that occur among components on an ongoing basis:
3750
▪ The Cisco Duo endpoint agent periodically syncs with the Cisco Duo cloud component to
3751
reauthenticate the requesting endpoint device using a unique certificate that has been
3752
provisioned specifically for that device and sends the cloud component information about
3753
device health (e.g., firewall running, anti-malware software, iOS version).
3754
▪ Cisco Duo is integrated with PingFederate and periodically sends PingFederate assurance that,
3755
based on the device health information collected by Cisco Duo, the device is compliant with
3756
configured policy.
3757
Figure E-6 depicts the message flow for the user’s request to access the resource.
3758
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 146
Figure E-6 Use Case—E2B1 – Access Enforced by PingFederate, Cisco Duo, and Radiant Logic
3759
The message flow depicted in Figure E-6 consists of the following steps:
3760
1. A user requests to access a resource by typing the resource’s URL into a browser.
3761
2. The resource receives the access request and sends a user authentication request to
3762
PingFederate.
3763
3. PingFederate consults the device health information it has received in the background from
3764
Cisco Duo verifying that the device has been authenticated and is compliant with policy.
3765
4. PingFederate prompts for username and password.
3766
5. The user responds with username and password.
3767
6. PingFederate sends the user’s username and password to the Ping LDAP Gateway to facilitate
3768
communication between the cloud-hosted Ping and the on premises Radiant Logic resources.
3769
7. The LDAP gateway forwards the LDAP authentication request to Radiant Logic.
3770
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
Cisco
Duo
Ping Federate
2. Resource sends user authentication request to Ping Federate
Resource
Subject
Radiant
Logic
User
6. Ping Federate sends the username
and password to the Ping LDAP gateway
4. Ping Federate prompts for username and password
5. User responds with credential
Sailpoint
16. The user access session between the endpoint and the resource is secured according to policy
1. User requests access to resource by entering its fully qualified domain name
Cisco
Duo
Agent
3. Ping Federate verifies device health using
endpoint info it has received from Cisco Duo
15. Ping sends SAML assertion token to the resource
and the user is granted access
LDAP
Gateway
7.LDAP
authentication
request
14. Successful authentication
10. User attributes
12. Cisco Duo challenges user for second factor authentication
13. User provides second authentication factor
9. Successful
authentication
and user
attributes
11. Asks Cisco Duo to perform
second factor authentication
8. Radiant Logic
authenticates
user
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 147
8. Radiant Logic authenticates that the username exists in the master user record and the provided
3771
password (credential) is valid based on credentials stored in Radiant Logic or in another source
3772
of identity credentials federated by Radiant Logic.
3773
9. Radiant Logic replies to the LDAP gateway with a valid BIND indicating a successful user
3774
authentication and all additional user attributes requested by Ping at the time of Authentication
3775
10. The LDAP gateway forwards the response from Radiant Logic to PingFederate with the
3776
successful BIND and applicable user’s attributes.
3777
11. PingFederate requests Cisco Duo to perform second-factor user authentication.
3778
12. Cisco Duo challenges the user to provide the second authentication factor.
3779
13. The user responds with the second authentication factor.
3780
14. Cisco Duo responds to PingFederate, indicating that the user authenticated successfully.
3781
15. PingFederate sends a SAML assertion token to the resource. The resource accepts the assertion
3782
and grants the access request.
3783
16. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).
3784
Note that the message flow depicted in Figure E-6 applies to several of the use cases we are considering.
3785
It applies to all cases in which a user with an enterprise ID who can successfully authenticate themselves
3786
and who is using an enterprise-owned endpoint requests and receives access to an enterprise resource
3787
that they are authorized to access. The message flow is the same regardless of whether the employee is
3788
located on-premises at headquarters, on-premises at a branch office, or off-premises at home or
3789
elsewhere. It is also the same regardless of whether the resource is located on-premises or in the cloud.
3790
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 148
Appendix F Enterprise 3 Build 1 (E3B1) – EIG Crawl
3791
F.1 Technologies
3792
E3B1 uses products from F5, Forescout, Lookout, Mandiant, Microsoft, Palo Alto Networks, PC Matic,
3793
and Tenable. Certificates from DigiCert are also used. For more information on these collaborators and
3794
the products and technologies that they contributed to this project overall, see Section 3.4.
3795
E3B1 components consist of Microsoft Azure AD, Microsoft AD, F5 BIG-IP, Microsoft Intune, Microsoft
3796
Defender for Endpoint, Lookout MES, PC Matic Pro, Microsoft Sentinel, Tenable.io, Tenable.ad,
3797
Mandiant Security Validation, Forescout eyeSight, Palo Alto Networks NGFW, and DigiCert CertCentral.
3798
Table F-1 lists all of the technologies used in E3B1 ZTA. It lists the products used to instantiate each ZTA
3799
component and the security function that the component provides.
3800
Table F-1 E3B1 Products and Technologies
3801
Component
Product
Function
PE
Azure AD
(Conditional
Access)
Decides whether to grant, deny, or revoke access to a resource
based on enterprise policy, information from supporting
components, and a trust algorithm.
PA
Azure AD
(Conditional
Access)
Executes the PE’s policy decision by sending commands to a
PEP that establishes and shuts down the communication path
between subject and resource.
PEP
Azure AD
(Conditional
Access), F5 BIG-IP,
and Lookout MES
Guards the trust zone that hosts one or more enterprise
resources; establishes, monitors, and terminates the
connection between subject and resource as directed by the
PA; forwards requests to and receives commands from the PA.
ICAM - Identity
Management
Microsoft AD and
Azure AD
Creates and manages enterprise user and device accounts,
identity records, role information, and access attributes that
form the basis of access decisions within an organization to
ensure the correct subjects have the appropriate access to the
correct resources at the appropriate time.
ICAM - Access
& Credential
Management
Microsoft AD and
Azure AD
Manages access to resources by performing user and device
authentication (e.g., SSO and MFA) and using identity, role,
and access attributes to determine which access requests are
authorized.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 149
Component
Product
Function
ICAM -
Federated
Identity
Microsoft AD and
Azure AD
Aggregates and correlates all attributes relating to an identity
or object that is being authorized by a ZTA. It enables users of
one domain to securely access data or systems of 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.
ICAM - Identity
Governance
Microsoft AD and
Azure AD
Provides policy-based, centralized, automated processes to
manage user identity and access control functions (e.g.,
ensuring segregation of duties, role management, logging,
access reviews, analytics, reporting) to ensure compliance with
requirements and regulations.
ICAM - MFA
Azure AD
(Multifactor
Authentication)
Authenticates user identity by requiring the user to provide
not only something they know (e.g., a password), but also
something they have (e.g., a token).
Endpoint
Security -
UEM/MDM
Microsoft Intune
Manages and secures enterprise desktop computers, laptops,
and/or mobile devices in accordance with enterprise policy to
protect applications and data; ensure device compliance;
mitigate and remediate vulnerabilities and threats; monitor for
suspicious activity to prevent and detect intrusions; prevent,
detect, and disable malware and other malicious or
unauthorized traffic; repair infected files when possible;
provide alerts and recommend remediation actions; and
encrypt data.
Pushes enterprise applications and updates to devices, enables
users to download enterprise applications that they are
authorized to access, remotely deletes all applications and
data from devices if needed, tracks user activity on devices,
and detects and addresses security issues on the device.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 150
Component
Product
Function
Endpoint
Security - EPP
Microsoft
Defender for
Endpoint, Lookout
MES, PC Matic Pro
Detects and stops threats to endpoints through an integrated
suite of endpoint protection technologies including antivirus,
data encryption, intrusion prevention, EDR, and DLP. May
include mechanisms that are designed to protect applications
and data; ensure device compliance with policies regarding
hardware, firmware, software, and configuration; monitor
endpoints for vulnerabilities, suspicious activity, intrusion,
infection, and malware; block unauthorized traffic; disable
malware and repair infections; manage and administer
software and updates; monitor behavior and critical data; and
enable endpoints to be tracked, troubleshooted, and wiped, if
necessary.
Security
Analytics -
SIEM
Microsoft Sentinel
Collects and consolidates security information and security
event data from many sources; correlates and analyzes the
data to help detect anomalies and recognize potential threats
and vulnerabilities; and logs the data to adhere to data
compliance requirements.
Security
Analytics –
Endpoint
Monitoring
Tenable.io and
Forescout
eyeSight
Discovers all IP-connected endpoints and performs continuous
collection, examination, and analysis of software versions,
configurations, and other information regarding hosts (devices
or VMs) that are connected to the network.
Security
Analytics -
Vulnerability
Scanning and
Assessment
Tenable.io and
Tenable.ad
Scans and assesses the enterprise infrastructure and resources
for security risks; identifies vulnerabilities and
misconfigurations; and provides remediation guidance
regarding investigating and prioritizing responses to incidents.
Security
Analytics -
Security
Validation
Mandiant Security
Validation
Provides visibility and evidence on the status of the security
controls’ effectiveness in the ZTA. Enables security capabilities
of the enterprise to be monitored and verified by continuously
validating and measuring the cybersecurity controls; also used
to automate the demonstrations that were performed to
showcase ZTA capabilities. Mandiant Security Validation is
deployed throughout the project’s laboratory environment to
enable monitoring and verification of various security aspects
of the builds. VMs that are intended to operate as actors are
deployed on each of the subnetworks in each of the
enterprises. These actors can be used to initiate various
actions for the purpose of verifying that security controls are
working to support the objectives of zero trust.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 151
Component
Product
Function
Security
Analytics –
Traffic
Inspection
Forescout
eyeSight
Intercepts, examines, and records relevant traffic transmitted
on the network.
Security
Analytics –
Network
Discovery
Forescout
eyeSight
Discovers, classifies, and assesses the risk posed by devices
and users on the network.
General -
Remote
Connectivity
Palo Alto
Networks NGFW
Enables authorized remote users to securely access the inside
of the enterprise. (Once inside, the ZTA manages the users’
access to resources.)
General -
Certificate
Management
DigiCert
CertCentral TLS
Manager
Provides automated capabilities to issue, install, inspect,
revoke, renew, and otherwise manage TLS certificates.
General - Cloud
IaaS
Azure
Provides computing resources, complemented by storage and
networking capabilities, hosted by a cloud service provider,
offered to customers on demand, and exposed through a GUI
and an API.
General - Cloud
SaaS
Digicert
CertCentral,
Lookout MES,
Microsoft Azure
AD, Microsoft
Defender for
Endpoint,
Microsoft Intune,
Microsoft Office
365, Microsoft
Sentinel, and
Tenable.io,
Cloud-based software delivered for use by the enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In this build,
GitLab is integrated directly with Azure AD using SAML, and
Microsoft Sentinel pulls logs from GitLab.)
General -
Application
Guacamole
Example enterprise resource to be protected. (In this build,
BIG-IP serves as an identity-aware proxy that protects access
to Guacamole, and BIG-IP is integrated with Azure AD using
SAML. Also, Microsoft Sentinel pulls logs from Guacamole.)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 152
Component
Product
Function
General -
Enterprise-
Managed
Device
Windows client,
macOS client, and
mobile devices
(iOS and Android)
Example endpoints to be protected. (In this build, all
enterprise-managed devices are enrolled into Microsoft
Intune.)
General - BYOD
Windows client,
macOS client, and
mobile devices
(iOS and Android)
Example endpoints to be protected.
F.2 Build Architecture
3802
In this section we present the logical architecture of E3B1 relative to how it instantiates the crawl phase
3803
EIG reference architecture depicted in Figure 4-2 . We also describe E3B1’s physical architecture and
3804
present message flow diagrams for some of its processes.
3805
F.2.1 Logical Architecture
3806
Figure F-1 depicts the logical architecture of E3B1. Figure F-1 uses numbered arrows to depict the
3807
general flow of messages needed for a subject to request access to a resource and have that access
3808
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
3809
authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic
3810
reauthentication of the requesting user and the requesting endpoint and periodic verification of
3811
requesting endpoint health, all of which must be performed to continually reevaluate access. The
3812
labeled steps in Figure F-1 have the same meanings as they do in Figure 4-1 and Figure 4-2. However,
3813
while Figure 4-2 depicts generic crawl phase ZTA components, Figure F-1 includes the specific products
3814
that instantiate the architecture of E3B1. Figure F-1 also does not depict any of the resource
3815
management steps found in Figure 4-1 and Figure 4-2 because the ZTA technologies deployed in E3B1
3816
do not support the ability to perform authentication and reauthentication of the resource or periodic
3817
verification of resource health.
3818
E3B1 was designed with a single ICAM system (Microsoft Azure AD) that serves as identity, access, and
3819
credential manager and also serves as the ZTA PE and PA. It includes three PEPs: Microsoft Azure AD, F5
3820
BIG-IP, and Lookout MES. A more detailed depiction of the messages that flow among components to
3821
support user access requests in the two different cases when the resource is being protected by the
3822
Azure AD PEP versus the F5 BIG-IP PEP can be found in Appendices F.2.3.1 and F.2.3.2.
3823
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 153
Figure F-1 Logical Architecture of E3B1
3824
F.2.2 Physical Architecture
3825
Section 4.5.4 describes the physical architecture of the E3B1 network.
3826
F.2.3 Message Flows for a Successful Resource Access Request
3827
This section depicts two high-level message flows, both of which support the use case in which a subject
3828
who has an enterprise ID, is located on-premises, and is authorized to access an enterprise resource,
3829
requests and receives access to that resource.
3830
The two message flows that are supported by Enterprise 3 for this use case depend on whether the
3831
resource being accessed is protected by Azure AD alone (see Appendix F.2.3.1) or by Azure AD in
3832
conjunction with the F5 BIG-IP PEP (see Appendix F.2.3.2).
3833
Regardless of which components are being used to protect the resource, all endpoints are enrolled into
3834
Microsoft Intune, which is an MDM (and a UEM) that can configure and manage devices and can also
3835
retrieve and report on device security settings that can be used to determine compliance, such as
3836
whether the device is running a firewall or anti-malware. Non-Windows devices have an MDM agent
3837
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Microsoft Azure AD
(Conditional Access)
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Azure
Cloud
F5 BIG-IP
Supporting Components
Endpoint Security:
• Microsoft Endpoint Manager
• Microsoft Defender for
Endpoint
• Lookout MES
• PC Matic Pro
ICAM, Federated Identity, and
Identity Governance:
Microsoft AD and Azure AD
Security Analytics:
• Microsoft Sentinel
• Forescout eyeSight
• Tenable.io and Tenable.ad
• Mandiant MSV
Multi-Factor Authentication:
Azure AD
Policy Information Points
(PIPs)
Lookout MES
Microsoft Azure AD
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 154
installed on them to enable them to report compliance information to Microsoft Intune, but Windows
3838
devices do not require a separate agent because Windows has built-in agents that are designed to
3839
communicate with Intune. Intune-enrolled devices check in with Intune periodically, allowing it to
3840
authenticate the requesting endpoint, determine how the endpoint is configured, modify certain
3841
configurations, and collect much of the information it needs to determine whether the endpoint is
3842
compliant. Intune reports the device compliance information that it collects to Azure AD, which will not
3843
permit a device to access any resources unless it is compliant.
3844
For demonstration purposes, one of the criteria that devices are expected to meet to be considered
3845
compliant in our example implementation is that they must have antivirus software updated and
3846
running. In both scenarios below, some requesting endpoints have Microsoft Defender Antivirus running
3847
on them and other requesting endpoints have PC Matic Pro (also antivirus software) running; no
3848
endpoints have both turned on. If a device is running Microsoft Defender Antivirus, the Intune MDM can
3849
sense this and report it to Azure AD. If a device is running PC Matic Pro, however, the device is
3850
configured to notify Windows Security Center that the endpoint has antivirus software installed, and the
3851
Security Center provides this information to Azure AD.
3852
The authentication message flows depicted below show only the messages that are sent in response to
3853
the access request. However, the authentication process also relies on the following additional
3854
background communications that occur among components on an ongoing basis:
3855
▪ Microsoft AD periodically synchronizes with Azure AD to provide it with the most up-to-date
3856
identity information.
3857
▪ Intune-enrolled devices check in with Intune periodically. Checking in allows Intune to
3858
determine how the endpoint is configured and modify certain configurations that have been
3859
previously specified. It also allows Intune to report the compliance of the device to Azure AD.
3860
▪ Microsoft Defender for Endpoint has both a cloud component and built-in sensors that detect
3861
threat signals from Windows endpoints. So not only can it tell that a firewall is disabled or
3862
antivirus is off, but it can tell when certain malicious signals seen elsewhere have also been
3863
observed on your endpoint. It periodically reports this information to its cloud/management
3864
component, which uses it for risk determination. This information can be passed off to Intune to
3865
include in its compliance determination of an endpoint.
3866
▪ Microsoft Defender Antivirus (an endpoint agent) periodically syncs with Microsoft Intune and
3867
Microsoft Defender for Endpoint.
3868
▪ Microsoft Intune periodically sends device health information to Azure AD so that it can be sure
3869
that the device is managed and compliant.
3870
▪ PC Matic periodically syncs with Windows Security Center to inform it that that the endpoint has
3871
antivirus installed and active.
3872
▪ Windows Security Center periodically syncs with Azure AD to provide it with endpoint status
3873
information, e.g., that endpoints have antivirus installed.
3874
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 155
F.2.3.1 Use Case in which Resource Access Is Enforced by Azure AD
3875
Figure F-2 depicts the message flow for the case in which access to the resource is protected by Azure
3876
AD (with the Conditional Access feature), which acts as a PDP; and Microsoft AD, which provides identity
3877
information.
3878
Figure F-2 Use Case—E3B1 – Access Enforced by Azure AD
3879
The message flow depicted in Figure F-2 consists of the following steps:
3880
1. A user requests access to a resource.
3881
2. The resource sends the authentication request to Azure AD.
3882
3. Azure AD prompts for username and password.
3883
4. The user responds with username and password.
3884
5. Azure AD authenticates the user. Azure AD consults the information about the device that it has
3885
received in the background from Microsoft Intune and Defender for Endpoint to authenticate
3886
the device and verify that it is managed and meets compliance requirements. If the device has
3887
PC Matic running on it, Azure AD also consults information about the device that it has received
3888
in the background from Windows Security Center to verify that the device is running antivirus
3889
software.
3890
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
Microsoft AD
Azure AD
(Conditional Access)
Subject
PC Matic
Endpoint Suite
Microsoft Intune and
Defender for Endpoint
User
Microsoft
Defender
Lookout MES
2. Resource sends authentication request to
Azure AD
1. User requests access to resource
3. Azure AD
prompts for username
and password
4. User responds
The user access session between the endpoint and the resource is secured according to policy
5. Azure AD authenticates the user and
verifies device health/compliance
6. Azure AD challenges user for
second factor authentication
7. User provides second authentication factor
8. Azure AD sends SAML assertion
token to the resource
9. The resource accepts the SAML assertion token and grants access
Windows
Security
Center
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 156
6. Azure AD challenges the user to provide the second authentication factor.
3891
7. The user responds with the second authentication factor.
3892
8. Azure AD sends a SAML assertion to the resource.
3893
9. The resource accepts the assertion and grants the access request. User traffic to and from the
3894
resource is secured according to policy (e.g., using TLS or HTTPS).
3895
F.2.3.2 Use Case in which Resource Access Is Enforced by an F5 BIG-IP PEP
3896
Figure F-3 depicts the message flow for the case in which access to the resource is protected by F5 BIG-
3897
IP, which acts as an identity-aware proxy PEP; Microsoft Azure AD, which acts as an ICAM provider and
3898
PDP; and Microsoft AD, which provides identity information.
3899
Figure F-3 Use Case—E3B1 – Access Enforced by F5 BIG-IP
3900
The message flow depicted in Figure F-3 consists of the following steps:
3901
1. A user requests access to a resource.
3902
2. BIG-IP, which is acting as an identity-aware proxy PEP that sits in front of the resource,
3903
intercepts and forwards the request to Azure AD.
3904
3. Azure AD prompts for username and password.
3905
4. The user responds with username and password.
3906
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
F5 BIG-IP
Proxy/PEP
Microsoft AD
Azure AD
(Conditional Access)
Resource
Subject
PC Matic
Endpoint Suite
Microsoft Intune and
Defender for Endpoint
User
Microsoft
Defender
Lookout MES
2. BIG-IP forwards the request to Azure AD
1. User requests access to resource; BIG-IP acts as a PEP and intercepts the request
3. Aure AD prompts for username and password
4. User responds
The user access session between the endpoint and the resource is secured according to policy
5. Azure AD authenticates the user and
verifies device health/compliance
9. BIG-IP permits the access request to proceed to the resource
8. Azure AD sends a SAML assertion to BIG-IP
6. Azure AD challenges user to provide
second factor authentication
7. User provides second authentication factor
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 157
5. Azure AD authenticates the user. Azure AD consults the information about the device that it has
3907
received in the background from Microsoft Intune and Defender for Endpoint to authenticate
3908
the device and verify that it is managed and meets compliance requirements. If the device has
3909
PC Matic running on it, Azure AD also consults information about the device that it has received
3910
in the background from Windows Security Center to verify that the device is running antivirus
3911
software.
3912
6. Azure AD challenges the user to provide the second authentication factor.
3913
7. The user responds with the second authentication factor.
3914
8. Azure AD sends a SAML assertion to BIG-IP which serves as an identity-aware proxy, service
3915
provider, and the PEP protecting the resource.
3916
9. BIG-IP accepts the SAML assertion and permits the access request to proceed to the resource.
3917
User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).
3918
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 158
Appendix G Enterprise 1 Build 2 (E1B2) – EIG Run
3919
G.1 Technologies
3920
E1B2 uses products from Amazon Web Services, IBM, Ivanti, Mandiant, Okta, Radiant Logic, SailPoint,
3921
Tenable, and Zscaler. Certificates from DigiCert are also used. For more information on these
3922
collaborators and the products and technologies that they contributed to this project overall, see
3923
Section 3.4.
3924
E1B2 components consist of Zscaler Admin Portal, Zscaler Central Authority, Zscaler Internet Access
3925
(ZIA) Public Service Edges, Zscaler Private Access (ZPA) Public Service Edges, Okta Identity Cloud, Radiant
3926
Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Okta Verify App, Zscaler Client
3927
Connector, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable NNM, IBM Cloud Pak for Security,
3928
Mandiant Security Validation (MSV), Zscaler Application Connector, DigiCert CertCentral, and AWS IaaS.
3929
Table G-1 lists all of the technologies used in E1B2. It lists the products used to instantiate each ZTA
3930
component and the security function that each component provides.
3931
Table G-1 E1B2 Products and Technologies
3932
Component
Product
Function
PE
Zscaler ZPA
Central Authority
(CA)
Decides whether to grant, deny, or revoke access to a resource
based on enterprise policy, information from supporting
components, and a trust algorithm.
PA
Zscaler ZPA
Admin Portal and
ZPA CA
Executes the PE’s policy decision by sending commands to a PEP
that establishes and shuts down the communication path
between subject and resource.
PEP
Zscaler Public
Service Edges
Guards the trust zone that hosts one or more enterprise
resources; establishes, monitors, and terminates the connection
between subject and resource as directed by the PA; forwards
requests to and receives commands from the PA.
ICAM -
Identity
Management
Okta Identity
Cloud
Creates and manages enterprise user and device accounts,
identity records, role information, and access attributes that form
the basis of access decisions within an organization to ensure the
correct subjects have the appropriate access to the correct
resources at the appropriate time.
ICAM -
Access &
Credential
Management
Okta Identity
Cloud
Manages access to resources by performing user and device
authentication (e.g., SSO and MFA) and using identity, role, and
access attributes to determine which access requests are
authorized.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 159
Component
Product
Function
ICAM -
Federated
Identity
Radiant Logic
RadiantOne
Intelligent
Identity Data
Platform
Aggregates and correlates all attributes relating to an identity or
object that is being authorized by a ZTA. It enables users of one
domain to securely access data or systems of 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.
ICAM -
Identity
Governance
SailPoint
IdentityIQ
Provides policy-based, centralized, automated processes to
manage user identity and access control functions (e.g., ensuring
segregation of duties, role management, logging, access reviews,
analytics, reporting) to ensure compliance with requirements and
regulations.
ICAM - MFA
Okta Verify app
Supports MFA of a user identity by requiring the user to provide
not only something they know (e.g., a password), but also
something they have (e.g., a token).
Endpoint
Security -
UEM/MDM
Ivanti Neurons
for Unified
Endpoint
Management
(UEM) Platform
Manages and secures enterprise desktop computers, laptops,
and/or mobile devices in accordance with enterprise policy to
protect applications and data; ensure device compliance; mitigate
and remediate vulnerabilities and threats; monitor for suspicious
activity to prevent and detect intrusions; prevent, detect, and
disable malware and other malicious or unauthorized traffic;
repair infected files when possible; provide alerts and
recommend remediation actions; and encrypt data.
Pushes enterprise applications and updates to devices, enables
users to download enterprise applications that they are
authorized to access, remotely deletes all applications and data
from devices if needed, tracks user activity on devices, and
detects and addresses security issues on the device.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 160
Component
Product
Function
Endpoint
Security -
EPP
None
Detects and stops threats to endpoints through an integrated
suite of endpoint protection technologies including antivirus, data
encryption, intrusion prevention, EDR, and DLP. May include
mechanisms that are designed to protect applications and data;
ensure device compliance with policies regarding hardware,
firmware, software, and configuration; monitor endpoints for
vulnerabilities, suspicious activity, intrusion, infection, and
malware; block unauthorized traffic; disable malware and repair
infections; manage and administer software and updates;
monitor behavior and critical data; and enable endpoints to be
tracked, troubleshooted, and wiped, if necessary.
Endpoint
Security -
Endpoint
Compliance
Zscaler Client
Connector
Can enforce policies based on a defined set of endpoint
compliance checks to allow or deny user/endpoint access to a
resource, but does not perform the functions of an EPP solution
to automatically remediate an endpoint.
Security
Analytics -
SIEM
IBM Security
QRadar XDR
Collects and consolidates security information and security event
data from many sources; correlates and analyzes the data to help
detect anomalies and recognize potential threats and
vulnerabilities; and logs the data to adhere to data compliance
requirements.
Security
Analytics –
Endpoint
Monitoring
Tenable.io
Discovers all IP-connected endpoints and performs continuous
collection, examination, and analysis of software versions,
configurations, and other information regarding hosts (devices or
VMs) that are connected to the network.
Security
Analytics -
Vulnerability
Scanning and
Assessment
Tenable.io and
Tenable.ad
Scans and assesses the enterprise infrastructure and resources
for security risks, identifies vulnerabilities and misconfigurations,
and provides remediation guidance regarding investigating and
prioritizing responses to incidents.
Security
Analytics -
Traffic
Inspection
Tenable NNM
Intercepts, examines, and records relevant traffic transmitted on
the network.
Security
Analytics -
Network
Discovery
Tenable NNM
Discovers, classifies, and assesses the risk posed by devices and
users on the network.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 161
Component
Product
Function
Security
Analytics -
SOAR
IBM Cloud Pak
for Security
Integrates the SIEM and other security tools into a single pane of
glass to support generation of insights into threats and help track,
manage, and resolve cybersecurity incidents.
Executes predefined incident response workflows to
automatically analyze information and orchestrate the operations
required to respond.
Security
Analytics -
Security
Validation
Mandiant
Security
Validation
Provides visibility and evidence on the status of the security
controls’ effectiveness in the ZTA. Enables security capabilities of
the enterprise to be monitored and verified by continuously
validating and measuring the cybersecurity controls; also used to
automate the demonstrations that were performed to showcase
ZTA capabilities. Deployed throughout the project’s laboratory
environment to enable monitoring and verification of various
security aspects of the builds. VMs that are intended to operate
as actors are deployed on each of the subnetworks in each of the
enterprises. These actors can be used to initiate various actions
for the purpose of verifying that security controls are working to
support the objectives of zero trust.
General -
Remote
Connectivity
Zscaler ZPA
Zscaler ZIA
ZPA is used to provide remote users’ connectivity to on-premises
resources. To support remote users’ connectivity to resources in
IaaS, ZPA is used for private applications and ZIA is used for
public-facing applications.
Resource
Protection -
Application
Connector
Zscaler
Application
Connector
Component that is deployed to be the front-end for an internal
resource (whether located on-premises or in the cloud) and act as
a proxy for it. Requests to access the resource are directed to the
connector, which responds by initiating a secure connection to
the PEP. A connector enables access to a resource to be
controlled without requiring the resource to be visible on the
network.
General -
Certificate
Management
DigiCert
CertCentral TLS
Manager
Provides automated capabilities to issue, install, inspect, revoke,
renew, and otherwise manage TLS certificates.
General -
Cloud IaaS
AWS - GitLab,
WordPress
Provides computing resources, complemented by storage and
networking capabilities, hosted by a cloud service provider,
offered to customers on demand, and exposed through a GUI and
an API. An IPsec tunnel is used to provide a secure connection
from the enterprise to the cloud.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 162
Component
Product
Function
General -
Cloud SaaS
Digicert
CertCentral,
Ivanti Neurons
for UEM, Okta
Identity Cloud,
Tenable.io,
Zscaler ZPA, and
Zscaler ZIA
Cloud-based software delivered for use by the enterprise.
General -
Application
On-premises -
GitLab
Example enterprise resource to be protected. (In this build,
GitLab is integrated with Okta using SAML, and IBM Security
QRadar XDR pulls logs from GitLab.)
General -
Enterprise-
Managed
Device
Mobile devices
(iOS and Android)
and
desktops/laptops
(Windows and
Mac)
Example endpoints to be protected. All enterprise-managed
mobile devices are running an Ivanti Neurons for UEM agent and
also have the Okta Verify App installed. If Ivanti Neurons for UEM
agent is used to push Zscaler Client Connector (ZCC) to the
endpoint, that endpoint is considered to be a managed device.
General -
BYOD
Mobile devices
(iOS and Android)
and
desktops/laptops
(Windows and
Mac)
Example endpoints to be protected.
G.2 Build Architecture
3933
In this section we present the logical architecture of E1B2. We also describe E1B2’s physical architecture
3934
and present message flow diagrams for some of its processes.
3935
G.2.1 Logical Architecture
3936
Figure G-1 depicts the logical architecture of E1B2. Figure G-1 uses numbered arrows to depict the
3937
general flow of messages needed for a subject to request access to a resource and have that access
3938
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
3939
user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting
3940
periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of
3941
requesting endpoint health, all of which must be performed to continually reevaluate access. The
3942
labeled steps in Figure G-1 have the same meanings as they do in Figure 4-1. However, Figure G-1
3943
includes the specific products that instantiate the architecture of E1B2. Figure G-1 also does not depict
3944
any of the resource management steps found in Figure 4-1 because the ZTA technologies deployed in
3945
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 163
E1B2 do not support the ability to perform authentication and reauthentication of the resource or
3946
periodic verification of resource health.
3947
E1B2 was designed with Zscaler components that serve as the PE, PA, and PEP, and Okta Identity Cloud
3948
that serves as the identity, access, and credential manager. Radiant Logic acts as a PIP for the PDP as it
3949
responds to inquiries and provides identity information on demand in order for Okta to make near-real-
3950
time access decisions. A more detailed depiction of the messages that flow among components to
3951
support a user access request can be found in Appendix G.2.4.
3952
Figure G-1 Logical Architecture of E1B2
3953
G.2.2 ICAM Information Architecture
3954
How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used
3955
among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture
3956
ensures that when a subject requests access to a resource, the aggregated set of identity information
3957
and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a
3958
basis on which to make the access decision.
3959
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Supporting Components
Endpoint Security:
• Ivanti Neurons for UEM
• Zscaler Client Connector
ICAM: Okta Identity Cloud
Federated Identity:
Radiant Logic RadiantOne
Identity Governance:
SailPoint IdentityIQ
Security Analytics:
• IBM Security QRadar XDR
• IBM Cloud Pak for Security
• Tenable.io, Tenable.ad, and
Tenable NNM
• Mandiant MSV
Multi-Factor Authentication:
• Okta Verify App
AWS
Cloud
Policy Information Points
(PIPs)
• Zscaler Admin Portal
• Zscaler Central
Authority (CA)
• Zscaler ZPA Public
Service Edges and
• Zscaler ZIA Public
Service Edges
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 164
In E1B2, Okta, Radiant Logic, and SailPoint integrate with each other as well as with other components
3960
of the ZTA to support the ICAM information architecture. The ways that these components work
3961
together to correlate identity information and to support actions such as users joining, changing roles,
3962
and leaving the enterprise are the same in E1B2 as they are in E1B1. These interactions are described in
3963
Appendix D.2.2.
3964
G.2.3 Physical Architecture
3965
Sections 4.5.1 and 4.5.2 describe and depict the physical architecture of the E1B2 headquarters network
3966
and the E1B2 branch office network, respectively. In addition to what is represented in Section 3.4, E1B2
3967
has Zscaler App Connector in the shared services VLAN.
3968
G.2.4 Message Flows for Successful Resource Access Requests
3969
Below are two high-level message flows, both of which support the use case in which a user who has an
3970
enterprise ID and who is authorized to access a resource requests and receives access to that resource.
3971
The user may be located either on-premises or at a remote location, such as a coffee shop.
3972
In both use cases depicted below, Zscaler platform components are serving as the PDP and PEPs, and
3973
Okta Identity Cloud provides a database of users, groups, permissions, and other identity and
3974
authorization information that Zscaler consumes. The Zscaler platform and Okta have a SAML federation
3975
that provides real-time synchronization of user identity information (to support user authentication) as
3976
well as a SCIM federation that provides real-time synchronization of role and group information (to
3977
support user authorization). These SAML and SCIM integrations are required because Zscaler relies on
3978
Okta to authenticate the identity of users making access requests as well as to help ensure that the user
3979
is authorized to access the requested resource.
3980
The Zscaler Central Authority (CA) is the PDP. A Zscaler Client Connector (ZCC) application is assumed to
3981
have been installed on the endpoint that the user is using to request access. The ZCC enforces policies
3982
that have been configured and applied to the device. When the user requests access to a resource, the
3983
ZCC intercepts the request and sends it to either the Zscaler Private Access (ZPA) Service Edge (PEP) or
3984
the Zscaler Internet Access (ZIA) Service Edge (PEP). Both the ZPA Service Edge and the ZIA Service Edge
3985
perform policy enforcement based on policies that the resource owner is assumed to have already
3986
configured. The choice of which PEP to send the request to depends on whether the resource being
3987
protected is an internal, private resource (e.g., an enterprise application located on the organization’s
3988
internal infrastructure--either in an on-premises data center or in the organization’s virtual private cloud
3989
(VPC) portion of a public cloud infrastructure such as AWS IaaS) or an externally-facing, public resource
3990
(e.g., a Microsoft Office 365 application located in a SaaS cloud or a web server on the internet). ZPA is
3991
used to broker access to an enterprise’s internal resources, while ZIA is used to inspect and secure traffic
3992
sent to and from externally facing and public resources.
3993
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 165
G.2.4.1 Use Case in which Access to an Internal Resource is Protected Using ZPA
3994
Figure G-2 depicts the message flow for the case in which ZPA acts as the PEP/PDP. In this use case, the
3995
resource being accessed is an internal, private resource that does not have a public-facing IP address
3996
and may be located either on-premises or in the organization’s VPC of AWS IaaS. To support this use
3997
case, domains (wildcard or exact) are configured as application segments and context-based access
3998
policies must also be configured in the ZPA Administrator Portal (Policy Administrator). ZCC, which is
3999
installed on the user’s endpoint, validates if a domain accessed is internal based on the Application
4000
Segments in the ZPA Administrator Portal. Once ZCC determines the domain is internal, the ZPA Service
4001
Edge (PEP) will use the access policies as the basis for deciding whether to broker access to the internal
4002
resource. To broker the connection between the ZPA PEP and the internal applications, a ZPA
4003
application connector must have been installed near the resource (either on-premises or in the
4004
enterprise’s VPC in the cloud) and an application segment must have been linked to that connector so
4005
that the connector that is near the resources acts as a proxy to the resource(s) on the application
4006
segment. ZCC provides a secure, authenticated interface between the endpoint and the ZPA service
4007
edge, and the ZPA Application Connector provides a secure, authenticated interface between the
4008
resource(s) and the ZPA service edge.
4009
Once the user has logged into the ZCC on his endpoint, all traffic destined for internal resources (e.g.,
4010
resources within an organization’s domain, which may be physically located either on-premises or in a
4011
VPC) will be sent to the ZPA PEP in the ZPA cloud that is closest to the user. The ZCC authenticates to the
4012
ZPA PEP and then establishes a secure tunnel to it. As a result, user endpoints never connect directly to
4013
internal resources. Instead, requests are sent to the ZPA PEP and if they are permitted by ZPA policy
4014
(i.e., if the user is authenticated, their access to the resource is authorized, and the requesting endpoint
4015
is compliant), then the ZPA PEP brokers access between the user and the application connector for the
4016
resource.
4017
Assuming the access request is permitted by policy, another secure tunnel is created between the ZPA
4018
PEP and the application connector for the resource. For security reasons, connectors do not accept
4019
inbound connections, so the connection that is established between the application connector for the
4020
resource and the ZPA PEP is outbound, from the application connector to the ZPA PEP. The ZPA PEP uses
4021
the TLS control channel (the reverse TLS tunnel) to signal the application connector to build a data
4022
tunnel from the application connector to the ZPA PEP. Then the ZPA PEP stitches together the two TLS
4023
tunnels in the cloud, enabling traffic to be exchanged securely between the user endpoint’s ZCC and the
4024
application connector. If a user connects to multiple resources that are being protected by a single
4025
application connector, there will be one TLS/Datagram Transport Layer Security (DTLS) tunnel created
4026
per resource.
4027
When a user requests access to an internal resource, ZCC intercepts DNS lookup queries for these
4028
domains and dynamically assigns the domains IP addresses within the 100.64.0.0/16 carrier-grade NAT
4029
subnet. Browsers and applications attempting to access the internal resource(s) will route the traffic to
4030
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 166
the IP addresses set up by ZCC. Due to this, the user accessing the resource never knows the real IP
4031
address of the resource, only the address of the temporary IP address assigned by ZCC. The user is not
4032
on the network, so connecting to the network via ZPA provides no presumption of access. The only
4033
connection that the user’s endpoint has is with the ZPA PEP. Logically, the ZPA PEP is positioned
4034
between the user endpoint connector and the resource’s connector.
4035
All traffic that is sent between a user and an internal resource must be directed through the application
4036
connector for that resource. So, for optimal performance, if an enterprise has internal resources in
4037
multiple locations (e.g., both on-premises and in a VPC on AWS), it should deploy application connectors
4038
in each location. Then it should link the respective Application Segment(s) to each location where the
4039
application exists so that the traffic sent from the user to the application can traverse an optimal path
4040
rather than having to be hairpinned through a connector that is not located close to the resource.
4041
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 167
Figure G-2 Access to an Internal Resource is Enforced by Zscaler ZPA and Okta Identity Cloud
4042
The message flow depicted in Figure G-2 consists of two parts: steps 1-6 depict the high-level message
4043
flow that occurs when a user logs into Zscaler, and steps 7-14 depict the high-level message flow that
4044
occurs when an authenticated user attempts to access an internal resource. The steps are as follows:
4045
1. The user uses the ZCC to try to log into ZPA, and the access request is received at the ZPA PEP.
4046
2. ZPA PEP provides ZCC with a SAML Request redirect to the Identity Provider.
4047
3. The ZCC relays the SAML request to Okta, which is the enterprise’s identity provider.
4048
4. Okta requests and receives the user’s credentials (and MFA, if configured) and uses these to
4049
authenticate the user and ensure that the user is authorized to use ZPA.
4050
Requesting
endpoint
GitLab
ZTA Components
Resource
Connector
Internal
Resource
Subject
Okta
Identity
Cloud
User
8. ZCC intercepts request and sends
it through the client connector
to the ZPA Service Edge (PEP)
ZPA Central Authority
(CA) (PDP) and ZPA
Service Edge (PEP)
14. Throughout the course of the user s session with GitLab, the ZPA PEP is receiving traffic from the user on the TLS
tunnel that it has with the ZCC and receiving traffic from GitLab on the TLS tunnel that it has with the GitLab
connector and stitching this traffic, thereby brokering the connection between the user s endpoint and the resource.
Zscaler
Client
Connector
(ZCC)
9. ZPA consults policy to determine if the authenticated user is authorized
to access the resource. It also performs a device health check.
Okta Verify
App
3. ZCC relays SAML request to Okta
11. Send user's access request to GitLab
7.User types GitLab
URL into browser
4. Okta requests and receives login credentials and authenticates and authorizes the user
13. User logs into the GitLab application. (Not depicted in detail.) User is redirected to Okta for login
credentials. Okta authenticates user, verifies that user is authorized to access GitLab, and provides
the user with a SAML assertion for the user to send to GitLab, which then grants the user access.
10. Build a TLS tunnel from the ZCC to ZPA PEP, build
a TLS tunnel from Resource Connector to ZPA PEP,
and stitch the two tunnels together
12. request
1.User tries to log in to ZPA via ZCC
5. Okta generates a SAML assertion and sends it back to ZCC
2. The ZPA PEP provides ZCC a
SAML request redirect to
the identity provider
6. ZCC relays SAML assertion back to
ZPA PEP. User is authenticated and
is now successfully logged in and
able to use ZPA
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 168
5. Okta generates a SAML assertion and sends it back to ZCC.
4051
6. ZCC relays the SAML assertion back to ZPA PEP. The user is authenticated and is now
4052
successfully logged in and able to use ZPA.
4053
7. A user requests to access an internal resource by typing the resource URL into their browser.
4054
8. The ZCC intercepts this request, determines if it is an internal resource, and sends it to the ZPA
4055
Service Edge (PEP) if it is. (In this use case, the resource is internal.)
4056
9. The ZPA PEP consults access policy to determine if the user is authorized to access the resource.
4057
The ZPA PEP performs a device health check to determine if the endpoint requesting access is
4058
compliant according to endpoint compliance polices that have been configured in the Zscaler CA
4059
(PDP). Information such as device OS version, patch level, anti-virus version, and whether the
4060
firewall is running has been collected from the device by the ZCC and provided to ZPA. The ZPA
4061
PEP determines if the user is authorized based on username and/or user group.
4062
10. Assuming the user is authorized, the ZPA PEP will broker access to the resource. This is
4063
accomplished by building one TLS tunnel from the ZCC to the ZPA PEP and a second TLS tunnel
4064
from the resource connector to the ZPA PEP. The ZPA PEP then stitches these two tunnels
4065
together in the Zscaler cloud.
4066
11. The ZPA PEP sends the user’s original request to access the resource to the resource connector.
4067
12. The resource connector sends the access request to the resource (GitLab).
4068
13. At this point, the user must still complete their login to the GitLab application, so they will select
4069
“login via Okta” on the GitLab login screen. The user is then redirected to an Okta screen for
4070
login credentials. Okta authenticates the user, verifies that they are authorized to access GitLab,
4071
and provides the user with a SAML assertion for the user to send to GitLab. Upon receipt of this
4072
SAML assertion, GitLab grants the user access. (These interactions with Okta are not shown in
4073
the flow diagram.)
4074
14. Once the user has logged into GitLab, the access session begins. Throughout the course of the
4075
user’s access session with GitLab, the ZPA PEP brokers the connection between the user’s
4076
endpoint and the resource. The ZPA PEP receives traffic from the user on the tunnel it has with
4077
the ZCC and stitches this traffic to the tunnel it has with the GitLab connector. Similarly, it
4078
receives traffic from GitLab on the tunnel it has with the GitLab connector and stitches this
4079
traffic to the tunnel it has with the ZCC.
4080
G.2.4.2 Use Case in which Access to an Externally Facing Resource is Protected Using ZIA
4081
Figure G-3 depicts the message flow for the case in which the ZIA Service Edge acts as the PEP. In this
4082
use case, the resource being accessed is externally facing and would typically be located external to the
4083
enterprise—e.g., either in a SaaS cloud or on the internet. Once the user has logged into the ZCC on his
4084
endpoint, traffic from the user that is destined for external, public resources will be sent to the ZIA
4085
Service Edge (PEP) that is closest to the user. A secure TLS tunnel will be established from the ZCC to this
4086
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 169
ZIA PEP and the traffic destined for this externally facing resource will be forwarded through the tunnel
4087
so the ZIA PEP can apply enterprise policies to it.
4088
ZIA PEP is used to determine if access to the resource is permitted at all and, if so, to inspect and secure
4089
traffic sent between the requesting endpoint and this external resource. To support this use case, ZIA is
4090
typically configured with policies which permit or block access to resources. ZIA can also be configured
4091
with traffic inspection policies. The ZIA PEP can inspect all traffic sent between the user and the resource
4092
bidirectionally. For example, it can inspect traffic for malware and enforce security, firewall, and web
4093
compliance policies (e.g., it may be configured to block PDFs from being sent from the enterprise, or
4094
block documents that contain social security numbers). Based on policy, ZIA will either forward the
4095
traffic to its destination or drop it. In either case, all traffic is logged and can be reviewed by an
4096
administrator.
4097
Unlike ZPA, ZIA does not make use of connectors. The ZIA PEP is used to broker the connection between
4098
the user and an externally facing resource. ZIA access policies can be configured based on URLs, URL
4099
categories, cloud applications, user location, time, usernames, and/or groups. Providing that the
4100
requested resource is permitted based on policy, ZIA enables traffic to be sent directly from the
4101
endpoint to the resource (not via a resource connector).
4102
Figure G-3 Access to an Externally-Facing Resource is Enforced by Zscaler ZIA and Okta Identity Cloud
4103
The message flow depicted in Figure G-3 depicts the message flow for the case in which the ZIA Service
4104
Edge acts as the PEP. In this use case, the resource being accessed is externally facing and would
4105
typically be located external to the enterprise—e.g., either in a SaaS cloud or on the internet. Once the
4106
Requesting
endpoint
GitLab
ZTA Components
Externally-
Facing
Resource
Subject
Okta
Identity
Cloud
User
2. ZCC intercepts the access request,
establishes a TLS connection with the
ZIA Service Edge (PEP) and forwards
the request to the ZIA (PEP)
ZIA Service Edge (PEP)
6. Throughout the course of the user s session with GitLab, the ZIA PEP is inspecting the traffic
being transmitted between the Zscaler client connector and GitLab
Zscaler
Client
Connector
(ZCC)
3. The ZIA PEP checks configured policies to determine
whether the access is permissible and, if so, determines
what traffic inspection may be required, if any
Okta Verify
App
4. If permitted, the ZIA PEP sends the user's access request to Gitlab
1.User types GitLab
URL into browser
5. The user logs into the GitLab application. (Not depicted in detail.) User is redirected to Okta for login
credentials. Okta authenticates user, verifies that user is authorized to access GitLab, and provides
the user with a SAML assertion for the user to send to GitLab, which then grants the user access.
A protected connection between the user's endpoint and GitLab is establised.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 170
user has logged into the ZCC on his endpoint, traffic from the user that is destined for external, public
4107
resources will be sent to the ZIA Service Edge (PEP) that is closest to the user. A secure TLS tunnel will be
4108
established from the ZCC to this ZIA PEP and the traffic destined for this externally facing resource will
4109
be forwarded through the tunnel so the ZIA PEP can apply enterprise policies to it.
4110
ZIA PEP is used to determine if access to the resource is permitted at all and, if so, to inspect and secure
4111
traffic sent between the requesting endpoint and this external resource. To support this use case, ZIA is
4112
typically configured with policies which permit or block access to resources. ZIA can also be configured
4113
with traffic inspection policies. The ZIA PEP can inspect all traffic sent between the user and the resource
4114
bidirectionally. For example, it can inspect traffic for malware and enforce security, firewall, and web
4115
compliance policies (e.g., it may be configured to block PDFs from being sent from the enterprise, or
4116
block documents that contain social security numbers). Based on policy, ZIA will either forward the
4117
traffic to its destination or drop it. In either case, all traffic is logged and can be reviewed by an
4118
administrator.
4119
Unlike ZPA, ZIA does not make use of connectors. The ZIA PEP is used to broker the connection between
4120
the user and an externally facing resource. ZIA access policies can be configured based on URLs, URL
4121
categories, cloud applications, user location, time, usernames, and/or groups. Providing that the
4122
requested resource is permitted based on policy, ZIA enables traffic to be sent directly from the
4123
endpoint to the resource (not via a resource connector.
4124
Figure G-3 assumes that the user has already logged into ZCC on their endpoint. The message flow
4125
consists of the following steps:
4126
1. A user requests access to an externally facing resource (GitLab) by typing the resource URL into
4127
their browser.
4128
2. The ZCC intercepts this request, establishes a TLS connection with the ZIA Service Edge (PEP),
4129
and forwards the request to the ZIA PEP through this tunnel.
4130
3. ZIA PEP checks configured policies to determine whether the access is permissible and, if
4131
permissible, determines what traffic inspection may be required, if any.
4132
4. If permitted, ZIA PEP sends the user’s access request to the resource (GitLab)
4133
5. At this point, the user must still complete their login to the GitLab application, so they will select
4134
“login via Okta” on the GitLab login screen. The user is then redirected to an Okta screen for
4135
login credentials. Okta authenticates the user, verifies that they are authorized to access GitLab,
4136
and provides the user with a SAML assertion for the user to send to GitLab. Upon receipt of this
4137
SAML assertion, GitLab grants the user access. (These interactions with Okta are not shown in
4138
the flow diagram.) A protected connection between the user’s endpoint and GitLab is
4139
established.
4140
6. Throughout the course of the user’s access session with GitLab, the ZIA PEP can inspect the
4141
traffic being transmitted between GitLab and the user’s endpoint and either forward or drop the
4142
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 171
traffic depending upon whether the traffic conforms to the firewall, web, and other security
4143
policies that have been defined.
4144
Although ZIA is typically used to protect access to an externally facing resource that is located either in a
4145
SaaS cloud or on the internet, NCCoE demonstrated the use of ZIA to protect access to an externally
4146
facing resource that is in the NCCoE VPC of AWS IaaS. This resource, GitLab, was placed on a public
4147
subnetwork that was segmented from the private subnetwork within that VPC on which internal
4148
applications reside. Even though the resource was publicly accessible, access to GitLab was still
4149
protected by an identity provider, which in this case is Okta.
4150
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 172
Appendix H Enterprise 3 Build 2 (E3B2) – EIG Run
4151
H.1 Technologies
4152
E3B2 uses products from F5, Forescout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, and
4153
Tenable. Certificates from DigiCert are also used. For more information on these collaborators and the
4154
products and technologies that they contributed to this project overall, see Section 3.4.
4155
E3B2 components consist of F5 BIG-IP, Microsoft AD, Microsoft Azure AD, Microsoft Azure AD
4156
(Conditional Access), Microsoft Intune, Microsoft Defender for Endpoint, Microsoft Defender for Cloud
4157
Apps, PC Matic Pro, Microsoft Sentinel, Microsoft Azure AD Identity Protection, Tenable.io, Tenable.ad,
4158
Tenable NNM, Mandiant Security Validation, Forescout eyeControl, Forescout eyeExtend, Forescout
4159
eyeSight, Forescout eyeSegment, Palo Alto Networks NGFW, Microsoft Defender for Cloud, Microsoft
4160
Azure (IaaS), Microsoft Office 365 (SaaS), and DigiCert CertCentral.
4161
Table H-1 lists all of the technologies used in E3B2 ZTA. It lists the products used to instantiate each ZTA
4162
component and the security function that each component provides.
4163
Table H-1 E3B2 Products and Technologies
4164
Component
Product
Function
PE
Microsoft Azure AD
(Conditional Access),
Microsoft Intune, Forescout
eyeControl, and Forescout
eyeExtend
Decides whether to grant, deny, or revoke access to a
resource based on enterprise policy, information from
supporting components, and a trust algorithm.
PA
Microsoft Azure AD
(Conditional Access),
Microsoft Intune, Forescout
eyeControl, and Forescout
eyeExtend
Executes the PE’s policy decision by sending
commands to a PEP that establishes and shuts down
the communication path between subject and
resource.
PEP
Microsoft Azure AD
(Conditional Access),
Microsoft Intune, F5 BIG-IP,
and Palo Alto Networks Next
Generation Firewall (NGFW)
Guards the trust zone that hosts one or more
enterprise resources; establishes, monitors, and
terminates the connection between subject and
resource as directed by the PA; forwards requests to
and receives commands from the PA.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 173
Component
Product
Function
ICAM -
Identity
Management
Microsoft AD and Azure AD
Creates and manages enterprise user and device
accounts, identity records, role information, and
access attributes that form the basis of access
decisions within an organization to ensure the correct
subjects have the appropriate access to the correct
resources at the appropriate time.
ICAM -
Access &
Credential
Management
Microsoft AD and Azure AD
Manages access to resources by performing user and
device authentication (e.g., SSO and MFA) and using
identity, role, and access attributes to determine
which access requests are authorized.
ICAM -
Federated
Identity
Microsoft AD and Azure AD
Aggregates and correlates all attributes relating to an
identity or object that is being authorized by a ZTA. It
enables users of one domain to securely access data or
systems of 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.
ICAM -
Identity
Governance
Microsoft AD and Azure AD
Identity Governance
Provides policy-based, centralized, automated
processes to manage user identity and access control
functions (e.g., ensuring segregation of duties, role
management, logging, access reviews, analytics,
reporting) to ensure compliance with requirements
and regulations.
ICAM - MFA
Azure AD (Multifactor
Authentication)
Authenticates user identity by requiring the user to
provide not only something they know (e.g., a
password), but also something they have (e.g., a
token).
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 174
Component
Product
Function
Endpoint
Security -
UEM/MDM
Microsoft Intune
Manages and secures enterprise desktop computers,
laptops, and/or mobile devices in accordance with
enterprise policy to protect applications and data;
ensure device compliance; mitigate and remediate
vulnerabilities and threats; monitor for suspicious
activity to prevent and detect intrusions; prevent,
detect, and disable malware and other malicious or
unauthorized traffic; repair infected files when
possible; provide alerts and recommend remediation
actions; and encrypt data.
Pushes enterprise applications and updates to devices,
enables users to download enterprise applications
that they are authorized to access, remotely deletes all
applications and data from devices if needed, tracks
user activity on devices, and detects and addresses
security issues on the device.
Endpoint
Security -
EPP
Microsoft Defender for
Endpoint, Forescout
eyeSight, and PC Matic Pro
Detects and stops threats to endpoints through an
integrated suite of endpoint protection technologies
including antivirus, data encryption, intrusion
prevention, EDR, and DLP. May include mechanisms
that are designed to protect applications and data;
ensure device compliance with policies regarding
hardware, firmware, software, and configuration;
monitor endpoints for vulnerabilities, suspicious
activity, intrusion, infection, and malware; block
unauthorized traffic; disable malware and repair
infections; manage and administer software and
updates; monitor behavior and critical data; and
enable endpoints to be tracked, troubleshooted, and
wiped, if necessary.
Security
Analytics -
SIEM
Microsoft Sentinel
Collects and consolidates security information and
security event data from many sources; correlates and
analyzes the data to help detect anomalies and
recognize potential threats and vulnerabilities; and
logs the data to adhere to data compliance
requirements.
Security
Analytics -
Identity
Monitoring
Microsoft Azure AD Identity
Protection
Monitors the identity of subjects to detect and send
alerts for indicators that user accounts or credentials
may be compromised, or to detect sign-in risks for a
particular access session.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 175
Component
Product
Function
Security
Analytics -
User
Behavior
Analytics
Microsoft Azure AD Identity
Protection
Monitors and analyzes user behavior to detect unusual
patterns or anomalies that might indicate an attack.
Security
Analytics -
Endpoint
Monitoring
Tenable.io and Forescout
eyeSight
Discovers all IP-connected endpoints and performs
continuous collection, examination, and analysis of
software versions, configurations, and other
information regarding hosts (devices or VMs) that are
connected to the network.
Security
Analytics -
Vulnerability
Scanning and
Assessment
Tenable.io and Tenable.ad
Scans and assesses the enterprise infrastructure and
resources for security risks; identifies vulnerabilities
and misconfigurations; and provides remediation
guidance regarding investigating and prioritizing
responses to incidents.
Security
Analytics -
Traffic
Inspection
Forescout eyeSight and
Tenable NNM
Intercepts, examines, and records relevant traffic
transmitted on the network.
Security
Analytics -
Network
Discovery
Forescout eyeSight and
Tenable NNM
Discovers, classifies, and assesses the risk posed by
devices and users on the network.
Security
Analytics -
Validation of
Control
Forescout eyeSegment
Validates the controls implemented through visibility
into network traffic and transaction flows.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 176
Component
Product
Function
Security
Analytics -
Security
Validation
Mandiant Security
Validation
Provides visibility and evidence on the status of the
security controls’ effectiveness in the ZTA. Enable
security capabilities of the enterprise to be monitored
and verified by continuously validating and measuring
the cybersecurity controls; also used to automate the
demonstrations that were performed to showcase ZTA
capabilities. Mandiant Security Validation is deployed
throughout the project’s laboratory environment to
enable monitoring and verification of various security
aspects of the builds. VMs that are intended to
operate as actors are deployed on each of the
subnetworks in each of the enterprises. These actors
can be used to initiate various actions for the purpose
of verifying that security controls are working to
support the objectives of zero trust.
Security
Analytics -
Security
Analytics and
Access
Monitoring
Microsoft Defender for
Cloud Apps
Monitors cloud resource access sessions for
conformance to policy.
General -
Remote
Connectivity
Azure AD Application Proxy,
Microsoft Defender for
Cloud Apps, and Palo Alto
Networks NGFW
Palo Alto Networks NGFW is used to provide remote
users’ connectivity to on-premises resources. Also,
two options are available to support remote users’
connectivity to resources in IaaS:
• The Azure AD Application Proxy can be used to
connect directly to private applications, and
Microsoft Defender for Cloud Apps can be used to
connect to public-facing applications.
• Palo Alto Networks NGFW can be used to reach
on-premises and then the IPsec tunnel can be
used to connect from on-premises to IaaS.
General -
Certificate
Management
DigiCert CertCentral TLS
Manager
Provides automated capabilities to issue, install,
inspect, revoke, renew, and otherwise manage TLS
certificates.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 177
Component
Product
Function
Resource
Protection -
Cloud
Workload
Protection
Microsoft Defender for
Cloud
Secures cloud workloads to protect them from known
security risks and provides alerts to enable real-time
reaction to prevent security events from developing.
Monitors traffic to and from cloud and web
applications and provides session control to prevents
sensitive information from leaving.
Resource
Protection -
Cloud
Security
Posture
Management
Microsoft Defender for
Cloud
Continually assesses the security posture of cloud
resources.
General -
Cloud IaaS
Azure – GitLab and
WordPress
Provides computing resources, complemented by
storage and networking capabilities, hosted by a cloud
service provider, offered to customers on demand,
and exposed through a GUI and an API.
General -
Cloud SaaS
Digicert CertCentral,
Microsoft Azure AD,
Microsoft Defender for
Endpoint, Microsoft
Defender for Cloud,
Microsoft Defender for
Cloud Apps, Microsoft
Identity Governance,
Microsoft Intune, Microsoft
Office 365, Microsoft
Sentinel, and Tenable.io
Cloud-based software delivered for use by the
enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In this
build, GitLab is integrated directly with Azure AD using
SAML, and Microsoft Sentinel pulls logs from GitLab.)
General -
Application
Guacamole
Example enterprise resource to be protected. (In this
build, BIG-IP serves as an identity-aware proxy that
protects access to Guacamole, and BIG-IP is integrated
with Azure AD using SAML. Also, Microsoft Sentinel
pulls logs from Guacamole.)
General -
Enterprise-
Managed
Device
Windows client, macOS
client, and mobile devices
(iOS and Android)
Example endpoints to be protected. (In this build, all
enterprise-managed devices are enrolled into
Microsoft Intune.)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 178
Component
Product
Function
General –
BYOD
Windows client, macOS
client, and mobile devices
(iOS and Android)
Example endpoints to be protected.
H.2 Build Architecture
4165
In this section we present the logical architecture of E3B2. We also describe E3B2’s physical architecture
4166
and present message flow diagrams for some of its processes.
4167
H.2.1 Logical Architecture
4168
Figure H-1 depicts the logical architecture of E3B2. Figure H-1 uses numbered arrows to depict the
4169
general flow of messages needed for a subject to request access to a resource and have that access
4170
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
4171
authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic
4172
reauthentication of the requesting user and the requesting endpoint and periodic verification of
4173
requesting endpoint health, all of which must be performed to continually reevaluate access. The
4174
labeled steps in Figure H-1 have the same meanings as they do in Figure 4-1. However, Figure H-1
4175
includes the specific products that instantiate the architecture of E3B2. Figure H-1 also does not depict
4176
any of the resource management steps found in Figure 4-1 because the ZTA technologies deployed in
4177
E3B2 do not support the ability to perform authentication and reauthentication of the resource or
4178
periodic verification of resource health.
4179
E3B2 was designed with Microsoft Azure AD (Conditional Access), Microsoft Intune, Forescout eyesight,
4180
and Forescout eyeExtend as the ZTA PEs and Pas, and Microsoft AD and Azure AD providing ICAM
4181
support. It includes four PEPs: Microsoft Azure AD (Conditional Access), Microsoft Intune, F5 BIG-IP, and
4182
Palo Alto Networks NGFW. A more detailed depiction of the messages that flow among components to
4183
support user access requests in the case in which a new endpoint is detected on the network and
4184
checked for compliance can be found in Appendix H.2.3.
4185
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 179
Figure H-1 Logical Architecture of E3B2
4186
H.2.2 Physical Architecture
4187
Section 4.5.4 describes the physical architecture of the E3B2 network.
4188
H.2.3 Message Flows for a Successful Resource Access Request
4189
The two message flows for E3B1 that are described in Appendix F.2.3 both still apply to E3B2 for cases in
4190
which the resource being accessed is located on-premises. Those message flows depict the use cases in
4191
which an on-premises resource being accessed is protected by Azure AD alone (see Appendix F.2.3.1),
4192
and in which an on-premises resource being accessed is protected by Azure AD in conjunction with the
4193
F5 BIG-IP PEP (see Appendix F.2.3.2).
4194
This section depicts three additional high-level message flows. The first two new message flows support
4195
the use case in which a user who has an enterprise ID and who is authorized to access a cloud-based
4196
resource requests and receives access to that resource. The user may be located on-premises or at a
4197
remote location, such as a coffee shop. In the first of these two new use cases, the resource accessed is
4198
an internal resource. In the second of these new use cases, the resource is externally facing. The third
4199
new message flow presented in this section depicts the use case in which a new endpoint is discovered
4200
S(D). Periodic reauthentication
challenge/response and
endpoint hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Microsoft Azure AD
(Conditional Access)
Microsoft Intune
Policy Decision
Point (PDP)
Subject
User
Endpoint
Resource
On-Prem
Azure
Cloud
F5 BIG-IP
Supporting Components
Endpoint Security:
• Microsoft Intune
• Microsoft Defender for Endpoint
• Forescout eyeSight
• PC Matic Pro
ICAM, Federated Identity, and Identity
Governance: Microsoft AD and Azure AD
MFA: Microsoft Azure AD
Policy Information Points (PIPs)
Lookout MES
Microsoft Azure AD
(Conditional Access)
Microsoft Intune
Palo Alto NGFW
Cloud Security: Microsoft Defender for Cloud
Forescout eyeControl
Forescout eyeExtend
Security Analytics:
• Microsoft Sentinel
• Microsoft Azure AD Identity Protection
• Tenable.io, Tenable.ad and Tenable NNM
• Forescout eyeSight
• Forescout eyeSegment
• Mandiant MSV
• Microsoft Defender for Cloud Apps
Policy Enforcement
Point(s) (PEPs)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 180
on the network, found to be non-compliant with enterprise policy, and blocked from accessing all
4201
resources.
4202
In both of the cloud-based resource access use cases depicted below, all endpoints are enrolled into
4203
Microsoft Intune, which is an MDM that can configure and manage devices, and it can also retrieve and
4204
report on device security settings that can be used to determine compliance, such as whether the device
4205
is running a firewall or anti-malware. Non-Windows devices have an MDM Agent installed on them to
4206
enable them to report compliance information to Microsoft Intune, but Windows devices do not require
4207
a separate agent because Windows has built-in agents that are designed to communicate with Intune.
4208
Intune-enrolled devices check in with Intune periodically, allowing Intune to authenticate the requesting
4209
endpoint, determine how the endpoint is configured, modify certain configurations, and collect much of
4210
the information it needs to determine whether or not the endpoint is compliant. Intune reports the
4211
device compliance information that it collects to Azure AD, which will not permit a device to access any
4212
resources unless it meets configured access policies.
4213
One of the criteria that devices must meet to be considered compliant is that they must have anti-virus
4214
software updated and running. Some requesting endpoints have Microsoft Defender Antivirus running
4215
on them and other requesting endpoints have PC Matic Pro (also antivirus software) running; no
4216
endpoints have both turned on. If a device is running Microsoft Defender Antivirus, the Intune MDM can
4217
sense this and report it to Azure AD. If a device is running PC Matic Pro, however, the device is
4218
configured to notify Windows Security Center that the endpoint has anti-virus software installed, and
4219
the Security Center provides this information to Azure AD.
4220
The authentication message flows depicted below show only the messages that are sent in response to
4221
the access request. However, the authentication process also relies on the following additional
4222
background communications that occur among components on an ongoing basis:
4223
▪ Microsoft AD periodically synchronizes with Azure AD to provide it with the most up-to-date
4224
identity information.
4225
▪ Intune-enrolled devices check in with Intune periodically. Checking in allows Intune to
4226
determine how the endpoint is configured and modify certain configurations that have been
4227
previously specified. It also allows Intune to report the compliance of the device to Azure AD.
4228
▪ Microsoft Defender for Endpoint has both a cloud component and built-in sensors that detect
4229
threats on Windows endpoints. So not only can it tell that a firewall is off or antivirus is off, but
4230
it can tell when certain malicious signals seen elsewhere have also been observed on the
4231
endpoint. It periodically reports this information to its cloud/management component, which
4232
uses it for risk determination. This information can be passed off to Intune to include in its
4233
compliance determination of an endpoint.
4234
▪ Microsoft Defender Antivirus (an endpoint agent) periodically syncs with Microsoft Intune MDM
4235
and Microsoft Defender for Endpoint.
4236
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 181
▪ Microsoft Intune periodically sends device health information to Azure AD so that it can be sure
4237
that the device is managed and compliant.
4238
▪ PC Matic periodically syncs with Windows Security Center to inform it that the endpoint has
4239
anti-virus installed and active.
4240
▪ Windows Security Center periodically syncs with Azure AD to provide it with endpoint status
4241
information, i.e., that endpoints have anti-virus installed.
4242
H.2.3.1 Use Case in which Access to a Private Cloud Resource is Enforced by Azure AD
4243
and Azure AD’s Application Proxy
4244
Figure H-2 depicts the message flow for the use case in which Azure AD’s Application Proxy acts as the
4245
PEP and Azure AD serves as identity manager. In this use case, the resource being accessed is an
4246
internal, private resource that does not have a publicly facing IP address and may be located either on-
4247
premises at the owning organization or in a private portion of Azure IaaS or another public cloud that
4248
the organization controls. Application Proxy includes both the Application Proxy service, which runs in
4249
the cloud as part of Azure AD, and the Application Proxy connector, which is a software agent that runs
4250
on a server inside the enterprise’s network (either on-premises or in the enterprise’s private portion of
4251
the cloud) and sits in front of the application being protected to manage communication between the
4252
Application Proxy service and the application. The Application Proxy connector uses only outbound
4253
HTTPS connections, so there is no need for the enterprise to open inbound ports. The connector can
4254
also perform “Kerberos Constrained Delegation (KCD)” in the case of enterprise Kerberos apps, which
4255
means that the user authenticating to the cloud can get SSO to Kerberos apps on-premises without re-
4256
authentication. For KCD to work, the Application Proxy connector would also need to have a path to an
4257
enterprise domain controller.
4258
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 182
Figure H-2 Use Case— E3B2 – Access to an Internal Resource is Enforced by Azure AD and Azure AD’s
4259
Application Proxy
4260
Prior to the flow above, the administrator configures both the Application Proxy connector and the
4261
application. This provides the administrator with an internet-facing URL they can give users who are
4262
coming off the internet (by default it would be something like app-contoso.msappprox.net, but they can
4263
customize the DNS URL with a SSL certificate). The message flow depicted in Figure H-2 consists of the
4264
following steps:
4265
1. A user requests to access an internal resource in the cloud by typing in the external URL
4266
provided by the App Proxy service for that resource. This access request is directed to the
4267
Microsoft AD sign-in page.
4268
2. Azure AD prompts the user for credentials (e.g., username + password, certificate auth, FIDO2
4269
keys).
4270
3. The user responds with credentials.
4271
Requesting
endpoint
ZTA Components
Azure AD
Application
Proxy
Service
Azure AD
(Conditional
Access)
Internal
Resource
Subject
PC Matic
Endpoint Suite
Microsoft
Endpoint
Manager and
Defender for
Endpoint
User
Microsoft
Defender
Lookout
MES
1. User requests access to the resource and
is directed to the Azure AD sign-in page
2. Azure AD prompts for
username and password
3. User responds
5. Azure AD sends OAuth assertion
token to the endpoint and
redirects the user acces request
to the Application Proxy service
6. Endpoint sends token to
the Application Proxy service
Azure AD
Application
Proxy
Connector
Cloud-
Hosted
Application
8. Connector
sends request
to application
and user is
granted access
10. Connector tunnels content to the
Application Proxy Service
Windows
Security
Center
Microsoft
AD
4. Azure AD authenticates the user, possibly challenging
the user for second factor authentication if required by
policy, and verifies device health/compliance
7. Application Proxy service retrieves user
principal name and security principal name
from the token and sends the request to
the Application Proxy connector
All traffic exchanged between the user and the resource on the access session flows through the connector
9.Response is
sent to
connector
11. Application Proxy Service serves the content
back to the user endpoint and browser
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 183
4. If required by policy, Azure AD also prompts the user for second-factor authentication. Azure AD
4272
Conditional Access can enforce these additional controls (e.g., MFA, device trust, user risk).
4273
Azure AD consults the information about the device that it has received in the background from
4274
Microsoft Intune and Defender for Endpoint to authenticate the device and verify that it is
4275
managed and meets compliance requirements. If the device has PC Matic running on it, Azure
4276
AD also consults information about the device that it has received in the background from
4277
Windows Security Center to verify that the device is running anti-virus software.
4278
5. Azure AD sends an Oauth token to the user’s browser to return to the App Proxy service (SAML
4279
can also be configured) and redirects the user access request to Azure AD Application Proxy
4280
Service.
4281
6. The endpoint sends the access request and Oauth token to Azure AD Application Proxy Service.
4282
7. The Application Proxy service retrieves the user principal name and security principal name from
4283
the token and sends the request to the Application Proxy connector. If KCD was configured (see
4284
above), the Proxy Connector reaches out to the domain controller to acquire a Kerberos ticket
4285
on behalf of the user identified in the Oauth token for the intended on-premises resource.
4286
Alternatively, the Proxy Connector can be configured to inject authentication headers if the
4287
application on-premises requests headers. (This KCD-related step is not depicted in the figure
4288
because it was not configured in the NCCoE demonstration.)
4289
8. The Application Proxy connector sends the request to the resource (optionally with a Kerberos
4290
ticket or headers) and the resource grants the user access.
4291
9. The resource returns content to the Application Proxy connector.
4292
10. The Application Proxy connector tunnels the content to the App Proxy service.
4293
11. The Application Proxy Service serves the content back to the user’s end point and browser.
4294
Once the access session is established, all traffic exchanged between the user and the resource flows
4295
through the Application Proxy connector.
4296
H.2.3.2 Use Case in which Access to an Externally Facing Cloud Resource is Enforced by
4297
Azure AD and Monitored by Microsoft Defender for Cloud Apps
4298
Figure H-3 depicts the message flow for the case in which access to the resource is protected by Azure
4299
AD (with the Conditional Access feature), which acts as a PDP; Microsoft AD, which provides identity
4300
information, and Microsoft Defender for Cloud Apps, which monitors cloud resource access sessions for
4301
conformance to policy. In this use case, the resource being accessed is externally facing, meaning that it
4302
has a publicly reachable IP address. Even though the application is externally facing, because the
4303
application is in the part of the cloud that is under the organization’s control (i.e., configured for SSO
4304
with the organization’s Identity Provider through SAML or Oauth), it is still protected by the
4305
organization’s identity provider, Azure AD, which requires the user to authenticate and then verifies that
4306
the user is authorized to access the resource and that the resource is compliant before granting access.
4307
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 184
Once the access session has been established, Microsoft Defender for Cloud Apps monitors all traffic
4308
that is exchanged between the user and the resource (see here for a detailed flow explanation).
4309
Microsoft Defender for Cloud Apps is therefore able to provide user behavior analytics functionality and
4310
prevent harmful or malicious actions within the resource. For example, it can block download of
4311
corporate data onto unmanaged devices, or block upload of data onto cloud storage services that
4312
contains PII or credit card numbers.
4313
Figure H-3 Use Case— E3B2 – Access to an Externally-Facing Resource is Enforced by Azure AD and
4314
Microsoft Defender for Cloud Apps
4315
The message flow depicted in Figure H-3 consists of the following steps:
4316
1. A user requests to access an externally facing, cloud-hosted resource, e.g., a SaaS application
4317
that has a publicly reachable IP address. For example, app.saas.com.
4318
Requesting
endpoint
ZTA Components
Microsoft
AD
Azure AD
(Conditional
Access)
Externally-
Facing
Resource
Subject
PC Matic
Endpoint Suite
Microsoft
Endpoint
Manager and
Defender for
Endpoint
User
Microsoft
Defender
Lookout
MES
2. Resource sends authentication request to
Azure AD
1. User requests access to resource
3. Azure AD prompts for
username and password
4. User responds
Microsoft Defender for Cloud Apps inline proxy inspects all traffic exchanged on the access session for conformance to policy
5. Azure AD authenticates the user and
verifies device health/compliance
6. Azure AD challenges user for
second factor authentication
7. User provides second authentication factor
8. Azure AD sends SAML assertion
token to the endpoint and redirects
the user access request to a
uniquely-generated URL
that is run by Microsoft Defender
for Cloud Apps inline proxy
9. Endpoint sends request and SAML assertion token to the uniquely-generated
URL that is run by Microsoft Defender for Cloud Apps inline proxy
Microsoft
Defender for
Cloud Apps
Cloud-
Hosted
Application
10. Forward request
and SAML
assertion and user
is granted access
Windows
Security
Center
11. Receive and
parse response
12. Microsoft Defender for Cloud Apps streams content back to the user's
endpoint, first rewriting any URLs as necessary.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 185
2. The resource sends the authentication request to Azure AD.
4319
3. Azure AD prompts for credentials.
4320
4. The user responds with credentials.
4321
5. Azure AD authenticates the user. Azure AD consults the information about the device that it has
4322
received in the background from Microsoft Intune and Defender for Endpoint to authenticate
4323
the device and verify that it is managed and meets compliance requirements. If the device has
4324
PC Matic running on it, Azure AD also consults information about the device that it has received
4325
in the background from Windows Security Center to verify that the device is running anti-virus
4326
software.
4327
6. Azure AD challenges the user to provide the second authentication factor or any other controls.
4328
7. The user responds with the second authentication factor.
4329
8. Azure AD sends a SAML assertion token back to the user’s browser/endpoint but does not
4330
redirect the user to the resource’s original redirect URL configured in the SAML setup (e.g.,
4331
app.saas.com/saml) and instead redirects the user to a uniquely generated URL that is run by
4332
Microsoft Defender for Cloud Apps inline proxy (e.g., app.saml.com.cas.com).
4333
9. The endpoint sends the access request and SAML assertion to Microsoft Defender for Cloud
4334
Apps’ generated URL.
4335
10. The Microsoft Defender for Cloud Apps inline proxy forwards the request and SAML assertion to
4336
the resource’s original URL.
4337
11. Microsoft Defender for Cloud Apps receives and parses the response.
4338
12. Before streaming the content back to the user’s endpoint, Microsoft Defender for Cloud Apps
4339
rewrites any saas.com URLs to be saas.com.cas.com URLs.
4340
The user receives the resulting content from the SaaS app and as they click on any link in the page, they
4341
submit their requests back to the Defender for Cloud Apps-generated URL. Defender for Cloud Apps
4342
inspects the action and the payload and enforces any DLP or other policies configured. If the action is
4343
allowed, Defender for Cloud Apps passes the request on to app.saas.com and, once again, rewrites the
4344
URLs of the response before delivery back to the user.
4345
In this manner, for the remainder of the access session, Microsoft Defender for Cloud Apps inline proxy
4346
monitors all traffic that is exchanged between the requesting endpoint and the resource endpoint to
4347
ensure that is permitted according to enterprise policy. For example, it can inspect the traffic that is sent
4348
to and from the cloud for PII or other prohibited content. Microsoft Defender for Cloud Apps inline
4349
proxy is integrated with Azure AD Conditional Access, enabling Azure AD to apply its controls to
4350
Microsoft Defender for Cloud Apps-governed applications. Furthermore, Defender for Cloud Apps can
4351
discover users and endpoints accessing resources, understand and report the risk posture of resources,
4352
and identify malicious activity either targeting or sourced from resources, as well as apply DLP policies
4353
that mitigate the risk of malicious data exfiltration.
4354
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 186
H.2.3.3 Use Case in which a Non-Compliant Endpoint is Discovered on the Network and
4355
Blocked from Accessing Resources
4356
Figure H-4 depicts a high-level message flow that supports the use case in which Forescout discovers a
4357
non-compliant endpoint on the network and directs the Palo Alto Networks NGFW to block traffic to and
4358
from that device.
4359
Figure H-4 Use Case—E3B2 – Forescout Discovers a Non-Compliant Endpoint on the Network and
4360
Directs the Palo Alto Networks Firewall to Block it
4361
The message flow depicted in Figure H-4 depicts a high-level message flow that supports the use case in
4362
which Forescout discovers a non-compliant endpoint on the network and directs the Palo Alto Networks
4363
NGFW to block traffic to and from that device.
4364
Figure H-4 consists of the following steps:
4365
1. Forescout discovers a new endpoint on the network.
4366
2. Forescout determines what other resources the endpoint is communicating with and then
4367
determines whether or not the endpoint is conformant with policy. (In this use case example,
4368
the endpoint is found to be non-conformant.)
4369
3. Forescout direct the Palo Alto Networks NGFW to block traffic to and from this device.
4370
4. When the endpoint attempts to access a resource that is beyond the NGFW, the NGFW blocks
4371
the endpoint’s traffic.
4372
Discovered Endpoint
ZTA Components
ForeScout
(PDP)
Resource
Subject
User
1. Forescout discovers an
endpoint on the network
3. Forescout directs the PEP to block traffic from
the newly-discovered, non-conformant endpoint
2. Forescout Identifies what the endpoint is communicating
with and then determines whether or not the endpoint is
conformant with policy. In this case, the endpoint is found
to be non-conformant.
4. The endpoint's attempts to access a resource beyond the PEP are blocked
Palo Alto
NGFW
(PEP)
Application
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 187
Appendix I Enterprise 1 Build 3 (E1B3) – SDP
4373
E1B3 uses all of the same products and technologies as E1B2, and the architecture of E1B3 is the same
4374
as the architecture of E1B2. (See Appendix G.)
4375
The difference between E1B3 and E1B2 is that some modifications were made to Zscaler configurations
4376
and parameters to enable E1B3 to perform additional use cases that were defined for demonstration
4377
purposes after E1B2 was completed. These modifications were as follows:
4378
▪ altering ZCC re-authentication time limits
4379
▪ modifications to some policies to demonstrate new use cases
4380
Some use cases in Volume D, including Confidence Level and Service-to-Service Interactions were not
4381
demonstrated due to products that were unavailable for the build. These tools included Deception,
4382
Zscaler for Workloads, and Cloud Browser Isolation.
4383
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 188
Appendix J Enterprise 2 Build 3 (E2B3) —
4384
Microsegmentation (Network)
4385
J.1 Technologies
4386
E2B3 uses products from Cisco Systems, IBM, Mandiant, Palo Alto Networks, Ping Identity, Radiant
4387
Logic, SailPoint, Tenable, and VMware. Certificates from DigiCert are also used. For more information on
4388
these collaborators and the products and technologies that they contributed to this project overall, see
4389
Section 3.4.
4390
E2B3 components consist of PingFederate, which is connected to the Ping Identity SaaS offering of
4391
PingOne, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Cisco ISE,
4392
Cisco Secure Workload, Cisco Duo, Cisco Secure Endpoint, Cisco Secure Network Analytics, Cisco
4393
network devices, Palo Alto Networks Next Generation Firewall (NGFW), IBM Security QRadar XDR,
4394
Tenable.io, Tenable.ad, Tenable Nessus Network Monitor (NNM), Mandiant Security Validation (MSV),
4395
VMware Workspace ONE UEM and Access, and DigiCert CertCentral.
4396
Table J-1 lists all of the technologies used in E2B3. It lists the products used to instantiate each ZTA
4397
component and the security function that each component provides.
4398
Table J-1 E2B3 Products and Technologies
4399
Component
Product
Function
PE
Ping Identity
PingFederate, Cisco ISE,
and Cisco Secure
Workload
Decides whether to grant, deny, or revoke access to
a resource based on enterprise policy, information
from supporting components, and a trust algorithm.
PA
Ping Identity
PingFederate, Cisco ISE,
and Cisco Secure
Workload
Executes the PE’s policy decision by sending
commands to a PEP that establishes and shuts down
the communication path between subject and
resource.
PEP
Ping Identity
PingFederate, Cisco Duo,
Cisco Network Devices,
and Cisco Secure
Workload
Guards the trust zone that hosts one or more
enterprise resources; establishes, monitors, and
terminates the connection between subject and
resource as directed by the PA; forwards requests to
and receives commands from the PA.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 189
Component
Product
Function
ICAM - Identity
Management
Ping Identity PingFederate
Creates and manages enterprise user and device
accounts, identity records, role information, and
access attributes that form the basis of access
decisions within an organization to ensure the
correct subjects have the appropriate access to the
correct resources at the appropriate time.
ICAM - Access &
Credential
Management
Ping Identity PingFederate
Manages access to resources by performing user
and device authentication (e.g., SSO and MFA) and
using identity, role, and access attributes to
determine which access requests are authorized.
ICAM - Federated
Identity
Radiant Logic RadiantOne
Intelligent Identity Data
Platform
Aggregates and correlates all attributes relating to
an identity or object that is being authorized by a
ZTA. It enables users of one domain to securely
access data or systems of 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.
ICAM - Identity
Governance
SailPoint IdentityIQ
Provides policy-based, centralized, automated
processes to manage user identity and access
control functions (e.g., ensuring segregation of
duties, role management, logging, access reviews,
analytics, reporting) to ensure compliance with
requirements and regulations.
ICAM - MFA
Cisco Duo
Supports MFA of a user identity by requiring the
user to provide not only something they know (e.g.,
a password), but also something they have (e.g., a
token).
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 190
Component
Product
Function
Endpoint
Security -
UEM/MDM
VMware Workspace ONE
UEM
Manages and secures enterprise desktop computers,
laptops, and/or mobile devices in accordance with
enterprise policy to protect applications and data;
ensure device compliance; mitigate and remediate
vulnerabilities and threats; monitor for suspicious
activity to prevent and detect intrusions; prevent,
detect, and disable malware and other malicious or
unauthorized traffic; repair infected files when
possible; provide alerts and recommend
remediation actions; and encrypt data.
Pushes enterprise applications and updates to
devices, enables users to download enterprise
applications that they are authorized to access,
remotely deletes all applications and data from
devices if needed, tracks user activity on devices,
and detects and addresses security issues on the
device.
Endpoint
Security - EPP
Cisco Secure Endpoint
Detects and stops threats to endpoints through an
integrated suite of endpoint protection technologies
including antivirus, data encryption, intrusion
prevention, EDR, and DLP. May include mechanisms
that are designed to protect applications and data;
ensure device compliance with policies regarding
hardware, firmware, software, and configuration;
monitor endpoints for vulnerabilities, suspicious
activity, intrusion, infection, and malware; block
unauthorized traffic; disable malware and repair
infections; manage and administer software and
updates; monitor behavior and critical data; and
enable endpoints to be tracked, troubleshooted, and
wiped, if necessary.
Endpoint
Security -
Endpoint
Compliance
Cisco Duo
Performs device health checks by validating specific
tools or services within the endpoint including
antivirus, data encryption, intrusion prevention, EPP,
and firewall. If the device does not pass the health
check, Duo fails second-factor authentication and
denies user access.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 191
Component
Product
Function
Security Analytics
- SIEM
IBM Security QRadar XDR
Collects and consolidates security information and
security event data from many sources; correlates
and analyzes the data to help detect anomalies and
recognize potential threats and vulnerabilities; and
logs the data to adhere to data compliance
requirements.
Security Analytics
– Endpoint
Monitoring
Tenable.io
Discovers all IP-connected endpoints and performs
continuous collection, examination, and analysis of
software versions, configurations, and other
information regarding hosts (devices or VMs) that
are connected to the network.
Security Analytics
- Vulnerability
Scanning and
Assessment
Tenable.io and Tenable.ad
Scans and assesses the enterprise infrastructure and
resources for security risks, identifies vulnerabilities
and misconfigurations, and provides remediation
guidance regarding investigating and prioritizing
responses to incidents.
Security Analytics
- Traffic
Inspection
Tenable NNM
Intercepts, examines, and records relevant traffic
transmitted on the network.
Security Analytics
- Network
Discovery
Tenable NNM
Discovers, classifies, and assesses the risk posed by
devices and users on the network.
Security Analytics
- Network
Monitoring
Cisco Secure Network
Analytics
Aggregates and analyzes network telemetry—
information generated by network devices—to
provide network visibility on-premises and detect
and respond to threats. Threat information can be
passed to PDP, which can then perform additional
actions such as blocking or quarantining a device.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 192
Component
Product
Function
Security Analytics
- Security
Validation
Mandiant Security
Validation
Provides visibility and evidence on the status of the
security controls’ effectiveness in the ZTA. Enables
security capabilities of the enterprise to be
monitored and verified by continuously validating
and measuring the cybersecurity controls; also used
to automate the demonstrations that were
performed to showcase ZTA capabilities. Deployed
throughout the project’s laboratory environment to
enable monitoring and verification of various
security aspects of the builds. VMs that are intended
to operate as actors are deployed on each of the
subnetworks in each of the enterprises. These actors
can be used to initiate various actions for the
purpose of verifying that security controls are
working to support the objectives of zero trust.
General - Remote
Connectivity
Palo Alto Networks
NGFW, Palo Alto
Networks Panorama
Enables authorized remote users to securely access
the inside of the enterprise. (Once inside, the ZTA
manages the users’ access to resources.)
General -
Certificate
Management
DigiCert CertCentral TLS
Manager
Provides automated capabilities to issue, install,
inspect, revoke, renew, and otherwise manage TLS
certificates.
General - Cloud
IaaS
None
Provides computing resources, complemented by
storage and networking capabilities, hosted by a
cloud service provider, offered to customers on
demand, and exposed through a GUI and an API.
General - Cloud
SaaS
Cisco Secure Endpoint,
Cisco Duo, Cisco Secure
Workload, Digicert
CertCentral, Ping Identity
PingOne (PingFederate
service), Tenable.io, and
VMware Workspace ONE
Cloud-based software delivered for use by the
enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In this
build, Gitlab is integrated with Ping Identity and IBM
Security QRadar XDR pulls logs from GitLab.)
General -
Enterprise-
Managed Device
Windows client, macOS
client, and mobile devices
(iOS and Android)
Example endpoints to be protected. All enterprise-
managed devices are running an Ivanti Neurons for
UEM agent and also have the Okta Verify App
installed.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 193
Component
Product
Function
General - BYOD
Windows client, macOS
client, and mobile devices
(iOS and Android)
Example endpoints to be protected.
J.2 Build Architecture
4400
In this section we present the logical architecture of E2B3 relative to how it instantiates the reference
4401
architecture depicted in Figure 4-1. We also describe E2B3’s physical architecture and present message
4402
flow diagrams for some of its processes.
4403
J.2.1 Logical Architecture
4404
Figure J-1 depicts the logical architecture of E2B3. The figure uses numbered arrows to depict the
4405
general flow of messages needed for a subject to request access to a resource and have that access
4406
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
4407
user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting
4408
periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of
4409
requesting endpoint health, all of which must be performed to continually reevaluate access. The
4410
labeled steps in Figure J-1 have the same meanings as they do in Figure 4-1 and Figure 4-2. However,
4411
Figure J-1 includes the specific products that instantiate the architecture of E2B3. Figure J-1 also does
4412
not depict any of the resource management steps found in Figure 4-1 and Figure 4-2 because the ZTA
4413
technologies deployed in E2B3 do not support the ability to perform authentication and
4414
reauthentication of the resource or periodic verification of resource health.
4415
E2B3 was designed to have three PDPs: Cisco ISE, Cisco Secure Workload, and Ping Identity
4416
PingFederate. Ping Identity PingFederate also serves as the identity, access, and credential manager.
4417
PingFederate, Cisco Duo, Cisco network devices, and Cisco Secure Workload also serve as PEPs. Radiant
4418
Logic acts as a PIP for the PDP as it responds to inquiries and provides user identity and authentication
4419
information on demand in order for Ping Identity PingFederate to make near-real-time access decisions.
4420
VMware Workspace One UEM provides endpoint management, and Cisco Secure Endpoint provides
4421
endpoint protection. Cisco Duo provides second-factor user authentication. Note that both multifactor
4422
authentication and directory services are also available through Ping, but for purposes of this
4423
collaborative build, Ping is demonstrating standards-based interoperability by integrating with Cisco Duo
4424
for MFA and Radiant Logic RadiantOne for federated identity services. A more detailed depiction of the
4425
messages that flow among components to support a user access request can be found in Appendix J.2.4.
4426
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 194
Figure J-1 Logical Architecture of E2B3
4427
J.2.2 ICAM Information Architecture
4428
How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used
4429
among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture
4430
ensures that when a subject requests access to a resource, the aggregated set of identity information
4431
and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a
4432
basis on which to make the access decision.
4433
In E2B3, Ping Identity, Radiant Logic, and SailPoint integrate with each other as well as with other
4434
components of the ZTA to support the ICAM information architecture. The ways that these components
4435
work together to correlate identity information and to support actions such as users joining, changing
4436
roles, and leaving the enterprise are the same in E2B3 as they are in E2B1. These interactions are
4437
described in Appendix E.2.2.
4438
J.2.3 Physical Architecture
4439
Section 4.5.3 describes the physical architecture of the E2B3 network.
4440
E2B3 ARCHITECTURE
S(D). Periodic reauthentication
challenge/response and
endpoint hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Ping Identity Ping
Federate
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Ping Identity Ping
Federate
Cisco Duo,
Cisco Secure Workload
Cisco Network Devices
Supporting Components
Endpoint Security:
• Cisco Secure Endpoint, Cisco Duo
• VMware Workspace ONE UEM
ICAM: Ping Identity Ping Federate
Federated Identity:
Radiant Logic RadiantOne
Identity Governance:
SailPoint IdentityIQ
Security Analytics:
• Cisco Secure Network Analytics
• IBM QRadar XDR
• Tenable.io, Tenable.ad, and Tenable NNM
• Mandiant MSV
• Cisco Secure Network Analytics
Multi-Factor Authentication:
Cisco Duo
Policy Information Points (PIPs)
Cisco ISE
Cisco Secure Workload
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 195
J.2.4 E2B3 Message Flows for Resource Access Requests, Non-Compliant
4441
Endpoints, Forbidden Access Requests, and Policy Discovery
4442
This section depicts five message flow scenarios that demonstrate various build capabilities.
4443
J.2.4.1 Authentication Message Flow for Non-Mobile Endpoints (PingFederate, Cisco
4444
Duo, Cisco Secure Endpoint, Cisco ISE, Cisco Secure Workload, and Radiant
4445
Logic)
4446
Figure J-2 depicts the high-level message flow supporting the use case in which a subject who has an
4447
enterprise ID, is using a laptop (i.e., a non-mobile) endpoint, and is authorized to access an enterprise
4448
resource, requests and receives access to that resource. In the case depicted here, access to the
4449
resource is authenticated and authorized by:
4450
▪ PingFederate, which acts as a PDP and identity provider;
4451
▪ Cisco ISE, which also acts as a PDP;
4452
▪ Cisco Duo, which consists of an agent on the endpoint and a cloud component that work
4453
together to perform second-factor user authentication and also to gather device health
4454
information to ensure device compliance;
4455
▪ Cisco Secure Endpoint, which runs on the endpoint and performs continuous monitoring to
4456
detect threats;
4457
▪ Radiant Logic, which performs user authentication at the request of PingFederate; and
4458
▪ Cisco Secure Workload (CSW), which provides resource protection by applying policies directly
4459
to the resource.
4460
These policies allow and deny communications to and from the resource by configuring the firewall on
4461
the resource.
4462
The message flow depicted in Figure J-2 shows only the messages that are sent in response to the access
4463
request. However, the authentication and access process also relies on the following additional
4464
background communications that occur among components on an ongoing basis:
4465
▪ The Cisco Duo endpoint agent periodically syncs with the Cisco Duo cloud component to
4466
reauthenticate the requesting endpoint device using a unique certificate that has been
4467
provisioned specifically for that device and sends the cloud component information about
4468
device health (e.g., firewall running, anti-malware software, iOS version).
4469
▪ Cisco Duo is integrated with PingFederate. During the authentication flow, Cisco Duo sends
4470
PingFederate assurance that, based on the device health information it has collected, the device
4471
is compliant with configured policy.
4472
▪ Cisco Secure Endpoint threat detection is continuously running on the endpoint and also acts as
4473
a PEP. If Secure Endpoint detects a threat, it notifies both Cisco Duo and Cisco ISE, and it can
4474
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 196
perform an automated response. For example, it can isolate the infected endpoint and perform
4475
a forensic snapshot of it.
4476
▪ Cisco ISE acts as a PDP. It receives notifications from Cisco Secure Endpoint and relies on
4477
telemetry information that Secure Endpoint provides to make its access decisions. If Cisco
4478
Secure Endpoint detects a threat in the device posture and notifies ISE, ISE can prevent the
4479
endpoint from sending packets and also shut down the port that the user is trying to reach.
4480
Figure J-2 depicts the message flow for the user’s request to access the resource from a non-mobile
4481
device.
4482
Figure J-2 Use Case—E2B3 – User Authentication and Access Enforcement When the Requesting
4483
Device Is Non-Mobile
4484
The message flow depicted in Figure J-2 consists of the following steps:
4485
1. A user on a non-mobile device requests to access a resource by typing the resource’s URL into a
4486
browser.
4487
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
Cisco
Duo
Ping Federate
2. Resource sends user authentication request to Ping Federate
Resource
Subject
Radiant
Logic
User
5. Ping Federate sends the username
and password to the Ping LDAP gateway
3. Ping prompts for username and credential
4. User responds with credential
Sailpoint
16. The user access session between the endpoint and the resource is secured according to policy
1. User requests access to resource by entering its fully qualified domain name
15. Ping sends SAML assertion token to the resource
and the user is granted access
Ping
Gateway
6.LDAP
authentication
request
14. Successful authentication
9. User attributes
12. Cisco Duo challenges user for second factor authentication
13. User provides second authentication factor
8. Successful
authentication
and user
attributes
10. Asks Cisco Duo to perform
second factor authentication
7. Radiant Logic
authenticates
user
Cisco ISE
Laptop
Cisco
Secure
Workload
Cisco Secure
Workload
VMware
Workspace
ONE
Cisco
Duo
Agent
11. Cisco Duo verifies the device
certificate and device health
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 197
2. Because Cisco CSW policy allows this communication, resource firewall rules have been
4488
configured to allow the resource to receive the access request. The resource receives the access
4489
request and sends a user authentication request to PingFederate.
4490
3. PingFederate prompts for username and password.
4491
4. The user responds with username and password.
4492
5. PingFederate sends the user’s credentials to the LDAP gateway.
4493
6. The LDAP gateway sends an LDAP authentication request to Radiant Logic.
4494
7. Radiant Logic authenticates the user.
4495
8. Radiant Logic replies to the LDAP gateway with indication of a successful user authentication
4496
and the user’s attributes.
4497
9. The LDAP gateway responds to PingFederate with the user’s attributes.
4498
10. PingFederate requests Cisco Duo to perform second-factor user authentication.
4499
11. Cisco Duo verifies that the requesting device has the unique certificate that it was provisioned
4500
and verifies that device health is according to policy (e.g., firewall running, anti-malware
4501
software, iOS version).
4502
12. Cisco Duo challenges the user to provide the second authentication factor.
4503
13. The user responds with the second authentication factor.
4504
14. Cisco Duo responds to PingFederate, indicating that the user authenticated successfully.
4505
15. PingFederate sends a SAML assertion token to the resource. The resource accepts the assertion
4506
and grants the access request.
4507
16. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).
4508
Note that the message flow described above is the same regardless of whether the employee is located
4509
on-premises at headquarters, on-premises at a branch office, or off-premises at home or elsewhere. It is
4510
also the same regardless of whether the resource is located on-premises or in the cloud.
4511
J.2.4.2 Authentication Message Flow for Mobile Endpoints (PingFederate, VMware
4512
Workspace ONE, Cisco Duo, Cisco Secure Endpoint, Cisco ISE, Cisco Secure
4513
Workload, and Radiant Logic)
4514
Figure J-3 depicts the high-level message flow supporting the use case in which a subject who has an
4515
enterprise ID, is using a mobile device, and is authorized to access an enterprise resource, requests and
4516
receives access to that resource. In the case depicted here, access to the resource is protected by
4517
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 198
PingFederate, which acts as a PDP and is the centralized identity provider in the identity federation. In
4518
addition to performing its own user authentication, PingFederate is integrated with VMware Workspace
4519
ONE and delegates localized authentication of the mobile device and user to Workspace ONE.
4520
Workspace ONE manages the mobile endpoint, ensures that its certificate is valid, gathers device health
4521
information to ensure device compliance, performs remediation if possible, and then authenticates the
4522
user and device. After successfully authenticating the user and the device, Workspace ONE notifies
4523
PingFederate, which, as the centralized identity provider, determines what additional authentication
4524
must be performed, if any. In the use case depicted here, PingFederate oversees multifactor
4525
authentication of the user by requesting username and credentials, delegating initial authentication to
4526
Radiant Logic, and then asking Cisco Duo to perform second-factor user authentication. In addition,
4527
Cisco Secure Endpoint performs continuous endpoint threat detection, Cisco Secure Workload applies
4528
policies directly to the resource to protect it, and Cisco ISE acts as a PDP to enforce policy beyond user
4529
and device authentication.
4530
The message flow depicted in Figure J-3 shows only the messages that are sent in response to the access
4531
request. However, the authentication and access process also rely on the following additional
4532
background communications that occur among components on an ongoing basis:
4533
▪ VMware Workspace ONE is integrated with PingFederate and Cisco ISE. Workspace ONE
4534
periodically sends Cisco ISE assurance that, based on device health information it is collecting,
4535
the mobile device is managed, has the unique certificate that was provisioned specifically for
4536
that device, and is compliant with configured policy (e.g., firewall running, anti-malware
4537
software enabled, iOS version correct). Workspace ONE may also provide this information to
4538
Ping as part of the authentication flow.
4539
▪ The Cisco Duo endpoint agent periodically syncs with the Cisco Duo cloud component to
4540
reauthenticate the requesting endpoint device using a unique certificate that has been
4541
provisioned specifically for that device, and sends the cloud component information about
4542
device health (e.g., firewall running, anti-malware software, iOS version).
4543
▪ Cisco Duo is integrated with PingFederate. During the authentication flow, Cisco Duo sends
4544
PingFederate assurance that, based on the device health information it has collected, the device
4545
is compliant with configured policy.
4546
▪ Cisco Secure Endpoint threat detection is continuously running on the endpoint and also acts as
4547
a PEP. If Secure Endpoint detects a threat, it notifies Cisco ISE, which can perform an automated
4548
response. For example, it can isolate the infected endpoint and perform a forensic snapshot of
4549
it.
4550
▪ Cisco ISE acts as a PDP. It receives notifications from Cisco Secure Endpoint and VMware
4551
Workspace ONE and relies on telemetry information that they provide to it to make its access
4552
decisions. If Cisco Secure Endpoint detects a threat in the device posture and notifies ISE, ISE can
4553
shut down the port that the user is trying to reach. If VMware Workspace ONE determines that
4554
the device is out of compliance, is no longer managed, or does not have a valid certificate, and
4555
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 199
notifies ISE, ISE can shut down the target port until the device’s security posture can be
4556
remediated.
4557
Figure J-3 depicts the message flow for the user’s request to access the resource from a mobile device.
4558
Figure J-3 Use Case—E2B3 – User Authentication and Access Enforcement When the Requesting
4559
Device Is Mobile
4560
4561
The message flow depicted in Figure J-3 consists of the following steps:
4562
1. A user on a mobile device requests to access a resource by typing the resource’s URL into a
4563
browser.
4564
2. The user gets redirected to PingFederate for authentication.
4565
3. PingFederate recognizes that the user is on a mobile device and redirects the user to VMware
4566
Workspace ONE.
4567
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
Cisco
Duo
Ping Federate
Resource
Subject
Radiant
Logic
User
Sailpoint
12. The user is single signed-on into the target application and the access session between the
endpoint and the resource is secured according to policy
1. User requests
access to resource
11. Ping sends SAML assertion token to the resource
and redirects the user to the target resource
Workspace
ONE Access
Connector
Cisco
ISE
VMware
Workspace
ONE
4. Workspace ONE performs device certificate and compliance checks
5. Workspace ONE
redirects the user to Ping
Mobile Device
Cisco
Duo
Agent
Cisco
Secure
Workload
10. Successful authentication
8. Cisco Duo challenges user for second factor authentication
9. User provides second authentication factor
7. Ping asks Duo to perform
multi-factor authentication
2. User gets redirected to Ping for authentication
3. Ping recognizes that the
user is on a mobile device
and redirects user to
Workspace ONE
6. Ping now knows that the user is authenticated and
that the device is compliant to corporate policies.
Ping will now require step-up authentication.
Cisco Secure
Workload
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 200
4. VMware Workspace ONE performs a device certificate check and a device compliance check.
4568
5. With a successful user and device authentication, VMware Workspace ONE redirects the now-
4569
authenticated user to PingFederate.
4570
6. PingFederate now knows that the user is authenticated and that the device is compliant to
4571
corporate policies. As required by the configured access policies, PingFederate will require step-
4572
up authentication using Duo for MFA.
4573
7. Ping requests Duo to perform step-up authentication.
4574
8. Cisco Duo challenges the user to provide the second authentication factor.
4575
9. The user responds with the second authentication factor.
4576
10. Cisco Duo contacts PingFederate, indicating that the user authenticated successfully.
4577
11. PingFederate generates the assertion to the target resource and redirects the user there.
4578
12. The user is single signed-on into the target resource.
4579
Note that the message flow described above is the same regardless of whether the employee is located
4580
on-premises at headquarters, on-premises at a branch office, or off-premises at home or elsewhere. It is
4581
also the same regardless of whether the resource is located on-premises or in the cloud.
4582
J.2.4.3 Message Flow When an Endpoint is Determined to Be Non-Compliant
4583
(PingFederate, VMware Workspace ONE, Cisco Secure Endpoint, and Cisco ISE)
4584
Figure J-4 depicts the high-level message flow supporting the use case in which a subject who has
4585
already been granted access to an enterprise resource is using a device that goes out of compliance
4586
because it no longer has a required security tool running. In the case depicted here, Cisco ISE serves as a
4587
PDP; VMware Workspace ONE UEM is running on the endpoint and monitoring device posture.
4588
The message flow depicted in Figure J-4 is assumed to take place after the user has been authenticated,
4589
authorized, and granted access to the resource.
4590
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 201
Figure J-4 Use Case—E2B3 – Message Flow When an Endpoint is Determined to Be Non-Compliant
4591
The message flow depicted in Figure J-4 consists of the following steps:
4592
1. The user, who has already been authenticated and is using a compliant device, is securely
4593
accessing an enterprise resource that they are authorized to access.
4594
2. VMware Workspace ONE periodically reauthenticates the requesting endpoint device using a
4595
unique certificate that has been provisioned specifically for that device and also monitors the
4596
device posture (e.g., firewall running, anti-malware software, OS version) to ensure that it is
4597
compliant with configured policy.
4598
3. Cisco Secure Endpoint threat detection is running on the endpoint and also acts as a PEP. If
4599
Secure Endpoint detects a threat, it notifies both Cisco Duo and Cisco ISE, and it can perform an
4600
automated response. For example, it can isolate the infected endpoint and perform a forensic
4601
snapshot of it. In this use case, Secure Endpoint does not detect any threats on the device.
4602
4. Workspace ONE detects that the firewall (or other required security tool) is no longer running
4603
on the device and informs Cisco ISE that the device is not compliant with policy.
4604
5. ISE updates its PEPs (i.e., routers, switches, firewalls) to prevent the device from reaching the
4605
resource.
4606
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
Cisco
Duo
Ping
Federate
Resource
Subject
Network
Switch
User
5. ISE prevents user's mobile
device from accessing
the resource
4. VMware Workspace ONE notifies Cisco ISE
that the device no longer has a required security
tool and is therefore out of compliance
Sailpoint
1. An authenticated, authorized user is accessing a resource securely
Cisco
ISE
VMware
Workspace
ONE
2. VMware Workspace ONE monitors the device to ensure that its posture conforms to policy
3. Cisco Secure Endpoint periodically examines the device for threats
6. Workspace ONE patches the device, bringing it into compliance
7. Workspace ONE notifies ISE that the
device is compliant again
8. ISE permits the device
to access the resource
9. The user is again able to access the resource securely
Mobile Device
Cisco
Duo
Agent
Radiant
Logic
Cisco
Secure
Workload
Cisco Secure
Workload
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 202
6. Meanwhile, Workspace ONE works to patch the endpoint and eventually brings it into
4607
compliance.
4608
7. When the update is complete, Workspace ONE notifies ISE that the device is compliant again.
4609
8. ISE permits the device to access the resource again.
4610
9. The device is able to access the resource again.
4611
J.2.4.4 Message Flow When an Endpoint is Compliant but a User Access Request Is Not
4612
Permitted by Policy (PingFederate and Cisco ISE)
4613
Figure J-5 depicts the high-level message flow supporting the use case in which a subject who has
4614
already been granted access to an enterprise resource tries to access an IP address that is known to be
4615
the command-and-control site for malware, thereby indicating that the subject endpoint is
4616
compromised. In the case depicted here, Cisco ISE serves as a PDP, Cisco Secure Endpoint examines the
4617
endpoint for threats, and Cisco Secure Network Analytics (SNA) monitors IP flows throughout the
4618
network to detect threats such as requests to connect to forbidden IP addresses.
4619
The message flow depicted in Figure J-5 is assumed to take place after the user has been authenticated,
4620
authorized, and granted access to the resource.
4621
Figure J-5 Use Case—E2B3 – Message Flow When a User’s Endpoint is Compliant but the User
4622
Requests Access to a Domain that Is Not Permitted by Policy
4623
The message flow depicted in Figure J-5 consists of the following steps:
4624
1. The user, who has already been authenticated and is using a compliant device, is securely
4625
accessing an enterprise resource that they are authorized to access.
4626
Requesting
endpoint
Endpoint
Hosting
Resource
ZTA Components
Cisco
Duo
Ping
Federate
Resource
Subject
Network
Switch
User
6. ISE limits the device's access to the network
4. The endpoint attempts to connect to an IP address
of a known malware command and control site,
which indicates that the endpoint is compromised
Sailpoint
1. An authenticated, authorized user is accessing a resource securely
Cisco
Duo
Agent
Cisco
ISE
2. Cisco Secure Endpoint is running on the endpoint to detect threats, e.g., malware.
Workspace ONE is monitoring device compliance.
Laptop
5. Cisco SNA detects the
forbidden access request
and notifies Cisco ISE
Radiant
Logic
Cisco
Secure
Workload
Cisco Secure
Network
Analytics
3. Cisco Secure Network Analytics (SNA) is
pulling traffic from switches and firewalls to
monitor IP flows throughout the network
Cisco Secure
Workload
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 203
2. Cisco Secure Endpoint, which is running on the user’s device, is monitoring the device for
4627
threats. VMware Workspace ONE UEM is running on the endpoint to ensure device compliance.
4628
3. Cisco SNA is pulling traffic from switches and firewalls throughout the network to monitor IP
4629
flows.
4630
4. The user’s endpoint attempts to access the IP address of a known malware command-and-
4631
control site. This attempt to access a prohibited domain indicates that the endpoint has been
4632
compromised.
4633
5. Cisco SNA detects the request to access the prohibited IP address and notifies Cisco ISE.
4634
6. ISE limits the device’s access to the network.
4635
J.2.4.5 Message Flow When Cisco Secure Workload (CSW) Is Used to Automatically
4636
Discover Policies
4637
Figure J-6 depicts the high-level message flow supporting the use case in which Cisco Secure Workload
4638
(CSW) is used to discover resource access policies. CSW includes both a cloud-based SaaS component
4639
and an agent that is deployed on the on-premises resource. The CSW agent on the resource
4640
communicates with the cloud-based CSW component on an ongoing basis to inform the cloud-based
4641
component of all communications flows that the resource is engaged in and to apply policies created by
4642
CSW to the resource.
4643
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 204
Figure J-6 Use Case—E2B3 – Cisco Secure Workload Policy Discovery
4644
The message flow depicted in Figure J-6 consists of the following steps:
4645
1. The CSW agent informs the CSW cloud component about the communications flows that the
4646
resource is engaged in.
4647
2. Based on these communications flows, the CSW cloud component discovers what endpoints the
4648
resource is communicating with and in what manner, and it formulates these communications
4649
flows into policies.
4650
3. A system administrator examines these policies, determines which ones describe legitimate
4651
resource communications and which ones do not, and updates them to ensure that only
4652
authorized access will be permitted and all unauthorized access will be blocked. Once the
4653
system administrator is satisfied that the policies are correct, the policies are turned on to be
4654
enforced. (Note that when CSW is being used, all communications between the resource and
4655
the CSW cloud component are automatically considered to be legitimate and will be permitted,
4656
even if a system administrator tries to mark them as unauthorized. The CSW agent on the
4657
resource must be able to communicate with the CSW cloud in order to discover flows and
4658
provide policies to the CSW agent.)
4659
Server Hosting the Resource
SaaS Component
Resource
Cisco Secure
Workload (CSW)
Cloud Component
1. CSW agent sends CSW cloud resource
communication flow information
Endpoint Permitted
to Access Resource
4. CSW sends the newly-updated policies to
the CSW agent on the resource
Cisco Secure
Workload
(CSW) Agent
2. CSW formulates resource communication
policies that describe the communications flows
6. Endpoints that are permitted by policy to communicate with the resource are allowed to do so
Resource
Firewall
Endpoint Not
Permitted to Access
Resource
3. A system administrator identifies which policies
are legitimate and which are not, updates the policies
so that authorized communications will be permitted
and unauthorized communications will be blocked,
and turns on the policies to be enforced
5. The policies
are applied to
the resource's
firewall
7. Endpoints that are not permitted by policy to
communicate with the resource are blocked
X
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 205
4. The CSW cloud component sends the newly formulated policies to the CSW agent on the
4660
resource.
4661
5. The policies are applied to the resource’s firewall.
4662
6. All communications to and from the resource that are permitted by the resource’s newly
4663
configured firewall policies will be allowed.
4664
7. All communications to and from the resource that are not permitted by the resource’s newly
4665
configured firewall policies will be blocked.
4666
J.2.4.6 Message Flow in which Cisco ISE Manages User Access to the Network and
4667
Resources
4668
Figure J-7 depicts the high-level message flow supporting the use case in which Cisco ISE manages user
4669
connection to the network and access to resources. The user’s endpoint has Cisco AnyConnect running
4670
on it for purposes of validating endpoint compliance.
4671
Figure J-7 Use Case—E2B3 – Cisco ISE Manages Access to the Network and Resources
4672
The message flow depicted in Figure J-7 consists of the following steps:
4673
1. The user logs into the endpoint using their credentials.
4674
Requesting endpoint
ZTA Components
Network Access
Point (AP) or
Switch
5. ISE notifies AP/switch that
user is authorized to connect to
network and which resources
the user is permitted to access
2. User requests connection to
network (wired or wireless)
1. User logs onto
endpoint with
credentials
Cisco
ISE
Cisco
AnyConnect
6. AP/switch allows user to connect to the network
Endpoint
Subject
User
3. AP/switch authenticates
user with ISE
4. AnyConnect provides endpoint compliance information to ISE
Endpoint
Hosting
Resource
7. The AP/switch permits the user to access all resources that the user is authorized to access according to ISE policy
8. The AP/switch blocks user attempts to access resources
that the user is not authorized to access according to ISE policy
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 206
2. Cisco Anyconnect connects to the network, which may be either a wired or wireless connection.
4675
This request is received at the AP or switch.
4676
3. The AP or switch interacts with Cisco ISE to ensure that the user is authenticated.
4677
4. The Cisco AnyConnect ISE posture module, which is running on the user’s endpoint, provides
4678
information to ISE to enable it to validate that the endpoint is compliant.
4679
5. ISE notifies the AP/switch that the user is authorized to connect to the network and also
4680
indicates which resources the user is permitted to access.
4681
6. The AP/switch allows the user to connect to the network.
4682
7. All subsequent attempts to access resources that the user is authorized to access are permitted
4683
by the AP/switch.
4684
All subsequent attempts to access resources that the user is not authorized to access are blocked by the
4685
AP/switch.
4686
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 207
Appendix K Enterprise 3 Build 3 (E3B3) — SDP and
4687
Microsegmentation
4688
K.1 Technologies
4689
E3B3 uses products from F5, Forescout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, and
4690
Tenable. Certificates from DigiCert are also used. For more information on these collaborators and the
4691
products and technologies that they contributed to this project overall, see Section 3.4.
4692
E3B3 components consist of F5 BIG-IP, Microsoft AD, Microsoft Azure AD, Microsoft Azure AD
4693
(Conditional Access), Microsoft Azure AD Identity Governance, Microsoft Intune, Microsoft Sentinel,
4694
Microsoft Azure App Proxy, Microsoft Defender for Endpoint, Microsoft Azure AD Identity Protection,
4695
Microsoft Defender for Identity, Microsoft Defender for Office, Microsoft Entra Permissions
4696
Management, Microsoft Defender for Cloud Apps, PC Matic Pro, Tenable.io, Tenable.ad, Tenable NNM,
4697
Mandiant Security Validation, Forescout eyeControl, Forescout eyeExtend, Forescout eyeSight,
4698
Forescout eyeSegment, Palo Alto Networks NGFW, Microsoft Purview – DLP, Microsoft Purview
4699
Information Protection, Microsoft Purview Information Protection Scanner, Microsoft Intune VPN
4700
Tunnel, Microsoft Azure Arc, Microsoft Azure Automanage, Microsoft Intune Privilege Access
4701
Workstation, Microsoft Azure Virtual Desktop Windows 365, Microsoft Defender for Cloud, Microsoft
4702
Azure (IaaS), Microsoft Office 365 (SaaS), and DigiCert CertCentral.
4703
Table K-1 lists all of the technologies used in E3B3 ZTA. It lists the products used to instantiate each ZTA
4704
component and the security function that each component provides.
4705
Table K-1 E3B3 Products and Technologies
4706
Component
Product
Function
PE
Microsoft Azure AD
(Conditional Access),
Microsoft Intune,
Microsoft Sentinel,
Forescout eyeControl, and
Forescout eyeExtend
Decides whether to grant, deny, or revoke access
to a resource based on enterprise policy,
information from supporting components, and a
trust algorithm.
PA
Microsoft Azure AD
(Conditional Access),
Microsoft Intune,
Microsoft Sentinel,
Forescout eyeControl, and
Forescout eyeExtend
Executes the PE’s policy decision by sending
commands to a PEP that establishes and shuts
down the communication path between subject
and resource.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 208
Component
Product
Function
PEP
Microsoft Azure AD
(Conditional Access),
Microsoft Intune,
Microsoft Azure App
Proxy, F5 BIG-IP, and Palo
Alto Networks Next
Generation Firewall
(NGFW)
Guards the trust zone that hosts one or more
enterprise resources; establishes, monitors, and
terminates the connection between subject and
resource as directed by the PA; forwards requests
to and receives commands from the PA.
ICAM - Identity
Management
Microsoft AD and Azure
AD
Creates and manages enterprise user and device
accounts, identity records, role information, and
access attributes that form the basis of access
decisions within an organization to ensure the
correct subjects have the appropriate access to
the correct resources at the appropriate time.
ICAM - Access &
Credential
Management
Microsoft AD and Azure
AD
Manages access to resources by performing user
and device authentication (e.g., SSO and MFA)
and using identity, role, and access attributes to
determine which access requests are authorized.
ICAM - Federated
Identity
Microsoft AD and Azure
AD
Aggregates and correlates all attributes relating
to an identity or object that is being authorized
by a ZTA. It enables users of one domain to
securely access data or systems of 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.
ICAM - Identity
Governance
Microsoft AD and Azure
AD Identity Governance
Provides policy-based, centralized, automated
processes to manage user identity and access
control functions (e.g., ensuring segregation of
duties, role management, logging, access
reviews, analytics, reporting) to ensure
compliance with requirements and regulations.
ICAM - MFA
Azure AD (Multi-Factor
Authentication)
Authenticates user identity by requiring the user
to provide not only something they know (e.g., a
password), but also something they have (e.g., a
token).
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 209
Component
Product
Function
Endpoint Security -
UEM/MDM
Microsoft Intune
Manages and secures enterprise desktop
computers, laptops, and/or mobile devices in
accordance with enterprise policy to protect
applications and data; ensure device compliance;
mitigate and remediate vulnerabilities and
threats; monitor for suspicious activity to prevent
and detect intrusions; prevent, detect, and
disable malware and other malicious or
unauthorized traffic; repair infected files when
possible; provide alerts and recommend
remediation actions; and encrypt data.
Pushes enterprise applications and updates to
devices, enables users to download enterprise
applications that they are authorized to access,
remotely deletes all applications and data from
devices if needed, tracks user activity on devices,
and detects and addresses security issues on the
device.
Endpoint Security -
EPP
Microsoft Defender for
Endpoint, Forescout
eyeSight, and PC Matic
Pro
Detects and stops threats to endpoints through
an integrated suite of endpoint protection
technologies including antivirus, data encryption,
intrusion prevention, EDR, and DLP. May include
mechanisms that are designed to protect
applications and data; ensure device compliance
with policies regarding hardware, firmware,
software, and configuration; monitor endpoints
for vulnerabilities, suspicious activity, intrusion,
infection, and malware; block unauthorized
traffic; disable malware and repair infections;
manage and administer software and updates;
monitor behavior and critical data; and enable
endpoints to be tracked, troubleshooted, and
wiped, if necessary.
Security Analytics -
SIEM
Microsoft Sentinel
Collects and consolidates security information
and security event data from many sources;
correlates and analyzes the data to help detect
anomalies and recognize potential threats and
vulnerabilities; and logs the data to adhere to
data compliance requirements.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 210
Component
Product
Function
Security Analytics -
SOAR
Microsoft Sentinel
Integrates the SIEM and other security tools into
a single pane of glass to support generation of
insights into threats and help track, manage, and
resolve cybersecurity incidents.
Executes predefined incident response workflows
to automatically analyze information and
orchestrate the operations required to respond.
Security Analytics -
Identity Monitoring
Microsoft Azure AD
Identity Protection
Monitors the identity of subjects to detect and
send alerts for indicators that user accounts or
credentials may be compromised, or to detect
sign-in risks for a particular access session.
Security Analytics –
User Behavior
Analytics
Microsoft Azure AD
Identity Protection
Monitors and analyzes user behavior to detect
unusual patterns or anomalies that might
indicate an attack.
Security Analytics -
Security Monitoring
Microsoft Defender for
Identity
Monitors and detects malicious or suspicious user
actions based on on-premises AD signals.
Security Analytics -
Application
Protection and
Response
Microsoft Defender for
Office
Protects Exchange Online and other Office
applications from phishing, spam, malware and
other zero-day attacks.
Security Analytics -
Cloud Access
Permission Manager
Microsoft Entra
Permissions Management
Provides visibility and control of permissions used
by identities in Azure, Amazon Web Services, and
Google Cloud Platform.
Security Analytics –
Endpoint
Monitoring
Tenable.io and Forescout
eyeSight
Discovers all IP-connected endpoints and
performs continuous collection, examination, and
analysis of software versions, configurations, and
other information regarding hosts (devices or
VMs) that are connected to the network.
Security Analytics -
Vulnerability
Scanning and
Assessment
Tenable.io and Tenable.ad
Scans and assesses the enterprise infrastructure
and resources for security risks; identifies
vulnerabilities and misconfigurations; and
provides remediation guidance regarding
investigating and prioritizing responses to
incidents.
Security Analytics -
Traffic Inspection
Forescout eyeSight and
Tenable NNM
Intercepts, examines, and records relevant traffic
transmitted on the network.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 211
Component
Product
Function
Security Analytics -
Network Discovery
Forescout eyeSight and
Tenable NNM
Discovers, classifies, and assesses the risk posed
by devices and users on the network.
Security Analytics -
Validation of
Control
Forescout eyeSegment
Validates the controls implemented through
visibility into network traffic and transaction
flows.
Security Analytics -
Security Validation
Mandiant Security
Validation
Provides visibility and evidence on the status of
the security controls’ effectiveness in the ZTA.
Enable security capabilities of the enterprise to
be monitored and verified by continuously
validating and measuring the cybersecurity
controls; also used to automate the
demonstrations that were performed to
showcase ZTA capabilities. Mandiant Security
Validation is deployed throughout the project’s
laboratory environment to enable monitoring
and verification of various security aspects of the
builds. VMs that are intended to operate as
actors are deployed on each of the subnetworks
in each of the enterprises. These actors can be
used to initiate various actions for the purpose of
verifying that security controls are working to
support the objectives of zero trust.
Security Analytics -
Security Analytics
and Access
Monitoring
Microsoft Defender for
Cloud Apps
Monitors cloud resource access sessions for
conformance to policy.
Data Security - Data
Discovery,
Classification,
Labeling, Access
Protection, and
Auditing and
Compliance
Microsoft Purview DLP,
Microsoft Purview
Information Protection,
and Microsoft Purview
Information Protection
Scanner
Discovers, classifies, and labels sensitive business
critical data in the cloud and on-premises, and
provides protection by preventing unauthorized
access and minimizing the risk of data theft and
data leaks using security policy rules.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 212
Component
Product
Function
General - Remote
Connectivity
Azure AD Application
Proxy, Microsoft Defender
for Cloud Apps, Microsoft
Intune VPN Tunnel, and
Palo Alto Networks NGFW
Microsoft Intune VPN Tunnel provides secure
remote access from mobile devices to on-
premises resources using modern authentication
and conditional access.
Palo Alto Networks NGFW is used to provide
remote users’ connectivity to on-premises
resources. Also, two options are available to
support remote users’ connectivity to resources
in IaaS:
• The Azure AD Application Proxy can be used
to connect directly to private applications,
and Microsoft Defender for Cloud Apps can
be used to connect to public-facing
applications.
• Palo Alto Networks NGFW can be used to
reach on-premises, and then the IPsec tunnel
can be used to connect from on-premises to
IaaS.
General - Certificate
Management
DigiCert CertCentral TLS
Manager
Provides automated capabilities to issue, install,
inspect, revoke, renew, and otherwise manage
TLS certificates.
General -
Configuration
Management
Microsoft Azure Arc and
Microsoft Azure
Automanage
Enables the management and configuration of
resources such as VMs and containers on-
premises and in other clouds via Azure
management tools.
General - Secure
Admin Workstation
Microsoft Intune Privilege
Access Workstation (PAW)
Provides a securely configured workstation that is
dedicated to performing sensitive tasks.
General - Virtual
Desktop
Microsoft Azure Virtual
Desktop Windows 365
Enables secure streaming of the Windows
desktop experience from the cloud to an
endpoint or handheld device.
Resource Protection
- Cloud Workload
Protection
Microsoft Defender for
Cloud
Secures cloud workloads to protect them from
known security risks and provides alerts to enable
real-time reaction to prevent security events
from developing. Monitors traffic to and from
cloud and web applications and provides session
control to prevents sensitive information from
leaving.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 213
Component
Product
Function
Resource Protection
- Cloud Security
Posture
Management
Microsoft Defender for
Cloud
Continually assesses the security posture of cloud
resources.
General - Cloud IaaS
Azure – GitLab and
WordPress
Provides computing resources, complemented by
storage and networking capabilities, hosted by a
cloud service provider, offered to customers on
demand, and exposed through a GUI and an API.
General - Cloud
SaaS
Digicert CertCentral,
Microsoft Azure AD,
Microsoft Defender for
Endpoint, Microsoft
Defender for Cloud,
Microsoft Defender for
Cloud Apps, Microsoft
Identity Governance,
Microsoft Intune,
Microsoft Office 365,
Microsoft Sentinel, and
Tenable.io
Cloud-based software delivered for use by the
enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In
this build, GitLab is integrated directly with Azure
AD using SAML, and Microsoft Sentinel pulls logs
from GitLab.)
General -
Application
Guacamole
Example enterprise resource to be protected. (In
this build, BIG-IP serves as an identity-aware
proxy that protects access to Guacamole, and
BIG-IP is integrated with Azure AD using SAML.
Also, Microsoft Sentinel pulls logs from
Guacamole.)
General -
Enterprise-Managed
Device
Windows client, macOS
client, and mobile devices
(iOS and Android)
Example endpoints to be protected. (In this build,
all enterprise-managed devices are enrolled into
Microsoft Intune.)
General - BYOD
Windows client, macOS
client, and mobile devices
(iOS and Android)
Example endpoints to be protected.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 214
K.2 Build Architecture
4707
In this section we present the logical architecture of E3B3. We also describe E3B3’s physical architecture
4708
and present message flow diagrams for some of its processes.
4709
K.2.1 Logical Architecture
4710
Figure K-1 depicts the logical architecture of E3B3. Figure K-1 uses numbered arrows to depict the
4711
general flow of messages needed for a subject to request access to a resource and have that access
4712
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
4713
authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic
4714
reauthentication of the requesting user and the requesting endpoint and periodic verification of
4715
requesting endpoint health, all of which must be performed to continually reevaluate access. The
4716
labeled steps in Figure K-1 have the same meanings as they do in Figure 4-1. However, Figure K-1
4717
includes the specific products that instantiate the architecture of E3B3. Figure K-1 also does not depict
4718
any of the resource management steps found in Figure 4-1 because the ZTA technologies deployed in
4719
E3B3 do not support the ability to perform authentication and reauthentication of the resource or
4720
periodic verification of resource health.
4721
E3B3 was designed with Microsoft Azure AD (Conditional Access), Microsoft Intune, Forescout
4722
eyeControl, and Forescout eyeExtend as the ZTA PEs and PAs, and Microsoft AD and Azure AD providing
4723
ICAM support. It includes four PEPs: Microsoft Azure AD (Conditional Access), Microsoft Intune, F5 BIG-
4724
IP, and Palo Alto Networks NGFW. A more detailed depiction of the messages that flow among
4725
components to support user access requests in the case in which a new endpoint is detected on the
4726
network and checked for compliance can be found in Appendix H.2.3.
4727
Figure K-1 Logical Architecture of E3B3
4728
S(D). Periodic reauthentication
challenge/response and
endpoint hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Microsoft Azure AD
(Conditional Access)
Microsoft Intune
Microsoft Sentinel
Policy Decision
Point (PDP)
Subject
User
Endpoint
Resource
On-Prem
Azure
Cloud
F5 BIG-IP
Supporting Components
Endpoint Security:
• Microsoft Intune
• Microsoft Defender
for Endpoint
• Forescout eyeSight
• PC Matic Pro
• Microsoft Azure Arc
• Microsoft Azure
Automanage
• Microsoft Intune
Privilege Access
Workstation
• Microsoft Azure
Virtual Desktop
Windows 365
ICAM, Federated Identity, and Identity
Governance: Microsoft AD, Azure AD, and
Azure AD Identity Governance
MFA: Microsoft Azure AD
Policy Information Points (PIPs)
Microsoft Azure AD
(Conditional Access)
Microsoft Intune
Microsoft Azure App
Proxy
Palo Alto NGFW
Cloud Security: Microsoft Defender for Cloud
Forescout eyeControl
Forescout eyeExtend
Security Analytics:
• Microsoft Sentinel
• Microsoft Azure AD
Identity Protection
• Microsoft Defender
for Identity
• Microsoft Defender
for Office
• Microsoft Entra
Permissions
Management
• Tenable.io,
Tenable.ad and
Tenable NNM
• Forescout eyeSight
• Forescout
eyeSegment
• Mandiant MSV
• Microsoft Defender
for Cloud Apps
Policy Enforcement
Point(s) (PEPs)
Data Security
• Microsoft Purview – DLP
• Microsoft Purview Information Protection,
• Microsoft Purview Information Protection
Scanner
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 215
K.2.2 Physical Architecture
4729
Section 4.5.4 describes the physical architecture of the E3B3 network.
4730
K.2.3 Message Flows for a Successful Resource Access Request
4731
The two message flows for E3B1 that are described in Appendix F.2.3 both still apply to E3B3 for cases in
4732
which the resource being accessed is located on-premises. Those message flows depict the use cases in
4733
which an on-premises resource being accessed is protected by Azure AD alone (see Appendix F.2.3.1),
4734
and in which an on-premises resource being accessed is protected by Azure AD in conjunction with the
4735
F5 BIG-IP PEP (see Appendix F.2.3.2).
4736
In addition, three additional high-level message flows that are described in Appendix H.2.3 also still
4737
apply to E3B3. These message flows describe the cases in which a private resource being accessed is
4738
located in the cloud (see Appendix H.2.3.1); an externally-facing resource being accessed is in the cloud
4739
(see Appendix H.2.3.2); and a new endpoint is discovered on the network, found to be non-compliant
4740
with enterprise policy, and blocked from accessing all resources (see Appendix H.2.3.3).
4741
This section presents high-level message flows, each of which supports the use case in which an
4742
authenticated, authorized user who has already been granted access to a resource is engaged in an
4743
active access session when events occur that cause the user’s access to be revoked.
4744
In the first flow, many Microsoft Defender components are running to monitor and protect access to the
4745
resource (Defender for Endpoint, Defender for Cloud, Defender for Cloud Apps, Defender for Identity).
4746
The Defender security portal enables a network administrator to see all of the information produced by
4747
these Defender components in a single pane of glass. These Defender components all send suspicious or
4748
anomalous event information to Microsoft Sentinel. Sentinel uses configured automation rules to
4749
determine that the detected event is a dangerous enough activity that it warrants revoking the user's
4750
existing access. Sentinel directs Azure AD to restrict user access and take other policy-based action
4751
based on the event information.
4752
In the second flow, Intune MDM monitors the endpoint for compliance and sends logs to Sentinel.
4753
When Intune detects that the device posture is no longer compliant, it notifies Azure AD, which prevents
4754
the user from accessing the resource until the endpoint can be remediated and brought back into
4755
compliance.
4756
In the third flow, as the user is accessing the resource, Microsoft Purview DLP detects that the user is
4757
attempting to send PII to the resource, which is prohibited by policy. Purview DLP blocks this data from
4758
being transferred and sends logs to Sentinel.
4759
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 216
K.2.3.1 Use Case in which Azure AD takes action based on log information forwarded by
4760
Sentinel
4761
Figure K-2 depicts the message flow for the use case in which Azure AD blocks user access based on
4762
information forwarded by Sentinel.
4763
Figure K-2 Use Case— E3B3 – Azure Decisions Are Based on Sentinel Log Information
4764
The message flow depicted in Figure K-2 consists of the following steps:
4765
1. An authenticated, authorized user is securely accessing a resource.
4766
2. Throughout this ongoing access session, all Microsoft defender components (e.g., Defender for
4767
Endpoint, Defender for Cloud, Defender for Cloud Apps, Defender for Identity) send information
4768
regarding events that are considered suspicious or anomalous to Microsoft Sentinel.
4769
3. Sentinel, which has been configured with rule-based analytics and automation workflows,
4770
detects a suspicious user based on observed anomalous activities in conjunction with its
4771
configured analytics rules. Sentinel acts as the PE and initiates an automated response based on
4772
its automation rules. As part of its automated response, Sentinel decides to terminate the user’s
4773
access and invokes Azure AD to revoke current sessions and terminate further access.
4774
4. Azure AD executes the decisions made by Sentinel by directing Defender for Cloud Apps to
4775
terminate the user’s access session, and Azure AD also disables the user’s access to resources.
4776
Requesting
endpoint
ZTA Components
Defender
for
Endpoint
Azure AD
(Conditional
Access)
Resource
Subject
PC Matic
Endpoint Suite
Defender
for Identity
User
Defender for
Endpoint
Lookout
MES
3. Sentinel detects a suspicious user based on observed
anomalous activities in conjunction with its configured
analytics rules. Acting as a PE, Sentinel executes an
automated response. It terminates the user's access
and invokes Azure AD to revoke current sessions and
terminate further access.
4. Azure AD executes the decisions made
by Sentinel. It directs Defender for Cloud
Apps to terminate the user's access session,
and it disables the user's acces to resources
Microsoft
Sentinel
Defender
for Cloud
Apps
Defender
for Cloud
1. An authenticated, authorized user is securely accessing a resource
2. Throughout the access session,
all Microsoft Defender components
send information regarding
suspicious or anomalous events to
Microsoft Sentinel, as configured
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 217
K.2.3.2 Use Case in which Intune determines that an endpoint is non-compliant and
4777
blocks its access to the resource until device posture can be remediated
4778
Figure K-3 depicts the message flow for the case in which Azure AD blocks user access based on device
4779
non-compliance information provided by Intune.
4780
Figure K-3 Use Case— E3B3 – A Device that Intune Determines to be Non-Compliant is Temporarily
4781
Blocked from Accessing the Resource until It is Remediated and Brought Back Into Compliance
4782
The message flow depicted in Figure K-3 consists of the following steps:
4783
1. An authenticated, authorized user is securely accessing a resource.
4784
2. Throughout this ongoing access session, Intune monitors the endpoint for compliance and sends
4785
logs to Microsoft Sentinel.
4786
3. Intune detects that the device’s posture is no longer compliant, so it alerts Azure AD.
4787
4. Azure AD directs Defender for Cloud Apps to prevent the user from accessing the resource.
4788
5. Intune remediates the device posture to bring it into compliance with enterprise policy.
4789
6. Intune notifies Azure AD that the device is compliant.
4790
Requesting
endpoint
ZTA Components
Defender
for
Endpoint
Azure AD
(Conditional
Access)
Resource
Subject
PC Matic
Endpoint Suite
Defender
for Identity
User
Defender for
Endpoint
Intune
MDM
3. Intune detects that the
device posture is no longer
compliant and notifies Azure AD
4. Azure AD directs Defender for
Cloud Apps to prevent the user
from accessing the resource.
Microsoft
Sentinel
Defender
for Cloud
Apps
Defender
for Cloud
2. Throughout the access session, Intune monitors the endpoint for compliance
1. An authenticated, authorized user is securely accessing a resource
and sends logs to Microsoft Sentinel
5. Intune remediates the device to bring it into compliance with enterprise policy
6. Intune notifies Azure AD
that the device is compliant
7. Azure AD directs Defender for
Cloud Apps to permit the user
to access the resource.
8. User access to the resource is restored
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 218
7. Azure AD directs Defender for Cloud Apps to permit the user to access the resource.
4791
K.2.3.3 Use Case in which Purview DLP blocks the transfer of data that is prohibited
4792
from being sent from the enterprise
4793
Figure K-4 depicts a high-level message flow that supports the use case in which Purview DLP blocks a
4794
user’s attempt to retrieve PII from the resource.
4795
Figure K-4 Use Case—E3B3 – Purview DLP Blocks an Attempt to Retrieve PII from the Resource
4796
The message flow depicted in Figure K-4 consists of the following steps:
4797
1. An authenticated, authorized user is securely accessing a resource.
4798
2. Throughout this ongoing access session, Purview DLP and Purview Information Protection
4799
monitor the information transferred between the endpoint and the resource to provide data
4800
security, document protection, and data loss prevention.
4801
3. Purview DLP detects that the user is attempting to retrieve PII from the resource, which is
4802
forbidden according to enterprise policy.
4803
4. Purview DLP blocks the data transfer, preventing the user from retrieving the PII from the
4804
resource.
4805
Requesting
endpoint
ZTA Components
Defender
for
Endpoint
Azure AD
(Conditional
Access)
Resource
Subject
PC Matic
Endpoint Suite
Purview,
Purview DLP,
Purview
Information
Protection
User
Defender for
Endpoint
Intune
MDM
4. Purview DLP blocks the data transfer,
preventing the user from retrieving
PII from the resource
Microsoft
Sentinel
Defender
for Cloud
Apps
Defender
for Cloud
2. Throughout the access session, Purview DLP
and Purview Information Protection monitor the
information transferred between the endpoint
and the resource to provide data security,
document protection, and data loss prevention
1. An authenticated, authorized user is securely accessing a resource
5. Purview DLP sends a log to
Sentinel regarding the
DLP action
6. Sentinel informs Azure AD regarding the DLP action
3. Purview DLP detects that the user is
attempting to retrieve PII from the resource,
which is forbidden according to policy
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 219
5. Purview DLP sends a log to Sentinel regarding the DLP action.
4806
6. Sentinel informs Azure AD regarding the DLP action.
4807
K.2.3.4 Use Case in which a service/application requests access to a Microsoft
4808
Application
4809
This subsection discusses the steps needed to enable one application/service to access a Microsoft
4810
application. Prior to such a service-to-service request, the application or service that will request access
4811
to the Microsoft service, also referred to as the client, must be registered in the Authorization
4812
Server/IdP (which, in this case, is Microsoft Azure AD) and issued a client ID and a client secret. The
4813
client’s permissions must also be configured.
4814
Figure K-5 depicts the message flow for the use case in which an application/service requests access to a
4815
Microsoft Application. Microsoft Azure AD issues access tokens to authenticated users or applications
4816
seeking to make API calls to various Microsoft services and applications. In this example Microsoft Graph
4817
is the example application to which access is being requested.
4818
Figure K-5 Use Case—E3B3 – Service-to-Microsoft Service Access
4819
The message flow depicted in Figure K-5 consists of the following steps:
4820
1. The client authenticates to Microsoft Azure AD (Conditional Access) and requests an access
4821
token to Microsoft Graph with specific scopes (for example: User.Read.All or Files.Read.AsUser).
4822
2. Microsoft Azure AD (Conditional Access) verifies the client credentials, and that the client is
4823
authorized (coarse-grained authorization) to request such scopes from Graph. Azure AD then
4824
issues a time-bound access token to the client.
4825
ZTA Component
Azure AD
(Conditional
Access)
1. Client authenticates to Azure AD (Conditional Access)
and requests an access token to Microsoft Graph with
specific scopes
3. Client calls the Graph API with the access token bearing the specified scopes
2. Azure AD verifies the client credentials and that the client
is authorized to request such scopes from Graph. Azure AD
then issues a time-bound access token to the client
Client
(Application or
Service)
Resource
(Microsoft
Application),
e.g., Graph
API service
4. Graph API service responds with the appropriate content requested by the client
or denies the access request if the scopes that were requested were not permitted
Graph API service will allow or deny the access request based on
whether the client is permitted to request the requested scopes
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 220
3. The client calls the Graph API with the access token bearing the specified scopes.
4826
4. The Graph API service responds with the appropriate content requested by the client or denies
4827
the access request if the scopes requested are not permitted.
4828
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 221
Appendix L Enterprise 4 Build 3 (E4B3) — EIG Run
4829
L.1 Technologies
4830
E4B3 uses products from IBM, Mandiant, Palo Alto Networks, Tenable, and VMware. Certificates from
4831
DigiCert are also used. For more information on these collaborators and the products and technologies
4832
that they contributed to this project overall, see Section 3.4.
4833
E4B3 components consist of IBM Security Verify, IBM Security MaaS360 (for both laptops and mobile
4834
devices), IBM Cloud Pak for Security, IBM QRadar XDR, Mandiant Security Validation, Palo Alto Networks
4835
GlobalProtect VPN, Tenable.io, Tenable.ad, Tenable NNM, IBM Security Guardium Data Encryption,
4836
VMware infrastructure, and DigiCert CertCentral.
4837
Table L-1 lists all of the technologies used in E4B3 ZTA. It lists the products used to instantiate each ZTA
4838
component and the security function that each component provides.
4839
Table L-1 E4B3 Products and Technologies
4840
Component
Product
Function
PE
IBM Security Verify
Decides whether to grant, deny, or revoke access
to a resource based on enterprise policy,
information from supporting components, and a
trust algorithm.
PA
IBM Security Verify
Executes the PE’s policy decision by sending
commands to a PEP that establishes and shuts
down the communication path between subject
and resource.
PEP
IBM Security Verify
Guards the trust zone that hosts one or more
enterprise resources; establishes, monitors, and
terminates the connection between subject and
resource as directed by the PA; forwards requests
to and receives commands from the PA.
ICAM - Identity
Management
IBM Security Verify
Creates and manages enterprise user and device
accounts, identity records, role information, and
access attributes that form the basis of access
decisions within an organization to ensure the
correct subjects have the appropriate access to the
correct resources at the appropriate time.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 222
Component
Product
Function
ICAM - Access &
Credential
Management
IBM Security Verify
Manages access to resources by performing user
and device authentication (e.g., SSO and MFA) and
using identity, role, and access attributes to
determine which access requests are authorized.
ICAM - Federated
Identity
IBM Security Verify
Aggregates and correlates all attributes relating to
an identity or object that is being authorized by a
ZTA. It enables users of one domain to securely
access data or systems of 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.
ICAM - Identity
Governance
IBM Security Verify
Provides policy-based, centralized, automated
processes to manage user identity and access
control functions (e.g., ensuring segregation of
duties, role management, logging, access reviews,
analytics, reporting) to ensure compliance with
requirements and regulations.
ICAM - MFA
IBM Security Verify
Authenticates user identity by requiring the user to
provide not only something they know (e.g., a
password), but also something they have (e.g., a
token).
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 223
Component
Product
Function
Endpoint Security
- UEM/MDM
IBM Security MaaS360
Manages and secures enterprise desktop
computers, laptops, and/or mobile devices in
accordance with enterprise policy to protect
applications and data; ensure device compliance;
mitigate and remediate vulnerabilities and threats;
monitor for suspicious activity to prevent and
detect intrusions; prevent, detect, and disable
malware and other malicious or unauthorized
traffic; repair infected files when possible; provide
alerts and recommend remediation actions; and
encrypt data.
Pushes enterprise applications and updates to
devices, enables users to download enterprise
applications that they are authorized to access,
remotely deletes all applications and data from
devices if needed, tracks user activity on devices,
and detects and addresses security issues on the
device.
Endpoint Security
- EPP
IBM Security MaaS360
Detects and stops threats to endpoints through an
integrated suite of endpoint protection
technologies including antivirus, data encryption,
intrusion prevention, EDR, and DLP. May include
mechanisms that are designed to protect
applications and data; ensure device compliance
with policies regarding hardware, firmware,
software, and configuration; monitor endpoints for
vulnerabilities, suspicious activity, intrusion,
infection, and malware; block unauthorized traffic;
disable malware and repair infections; manage and
administer software and updates; monitor
behavior and critical data; and enable endpoints to
be tracked, troubleshooted, and wiped, if
necessary.
Endpoint Security
– Endpoint
Compliance
IBM Security MaaS360
Performs device health checks by validating
specific tools or services within the endpoint
including antivirus, data encryption, intrusion
prevention, EPP, and firewall.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 224
Component
Product
Function
Security Analytics
- SIEM
IBM QRadar XDR
Collects and consolidates security information and
security event data from many sources; correlates
and analyzes the data to help detect anomalies and
recognize potential threats and vulnerabilities; and
logs the data to adhere to data compliance
requirements.
Security Analytics
- SOAR
IBM Cloud Pak for Security
Integrates the SIEM and other security tools into a
single pane of glass to support generation of
insights into threats and help track, manage, and
resolve cybersecurity incidents.
Executes predefined incident response workflows
to automatically analyze information and
orchestrate the operations required to respond.
Security Analytics
– Endpoint
Monitoring
Tenable.io
Discovers all IP-connected endpoints and performs
continuous collection, examination, and analysis of
software versions, configurations, and other
information regarding hosts (devices or VMs) that
are connected to the network.
Security Analytics
- Vulnerability
Scanning and
Assessment
Tenable.io and Tenable.ad
Scans and assesses the enterprise infrastructure
and resources for security risks; identifies
vulnerabilities and misconfigurations; and provides
remediation guidance regarding investigating and
prioritizing responses to incidents.
Security Analytics
- Traffic
Inspection
Tenable NNM
Intercepts, examines, and records relevant traffic
transmitted on the network.
Security Analytics
- Network
Discovery
Tenable NNM
Discovers, classifies, and assesses the risk posed by
devices and users on the network.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 225
Component
Product
Function
Security Analytics
- Security
Validation
Mandiant Security
Validation
Provides visibility and evidence on the status of the
security controls’ effectiveness in the ZTA. Enable
security capabilities of the enterprise to be
monitored and verified by continuously validating
and measuring the cybersecurity controls; also
used to automate the demonstrations that were
performed to showcase ZTA capabilities. Mandiant
Security Validation is deployed throughout the
project’s laboratory environment to enable
monitoring and verification of various security
aspects of the builds. VMs that are intended to
operate as actors are deployed on each of the
subnetworks in each of the enterprises. These
actors can be used to initiate various actions for
the purpose of verifying that security controls are
working to support the objectives of zero trust.
Security Analytics
– User Behavior
Analytics
IBM Security
Verify/Trusteer
Monitors and analyzes user behavior to detect
unusual patterns or anomalies that might indicate
an attack.
Data Security -
Data Encryption
IBM Security Guardium
Data Encryption (GDE)
Provides strong encryption and key management
capabilities for both structured and unstructured
data both on-premises and in the cloud.
Data Security -
Data Access
Protection
IBM Security Guardium
Data Encryption (GDE)
Discovers, classifies, and labels sensitive business
critical data in the cloud and on-premises and
provides protection by preventing unauthorized
access and minimizing the risk of data theft and
data leaks using security policy rules.
General - Remote
Connectivity
Palo Alto Networks
GlobalProtect VPN
Provides remote users’ connectivity to on-premises
and IaaS resources.
General -
Certificate
Management
DigiCert CertCentral TLS
Manager
Provides automated capabilities to issue, install,
inspect, revoke, renew, and otherwise manage TLS
certificates.
General -
Virtualized
Infrastructure
VMware
On-premises virtualized infrastructure hosting
enterprise resources.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 226
Component
Product
Function
General - Cloud
IaaS
IBM Cloud – GitLab
Provides computing resources, complemented by
storage and networking capabilities, hosted by a
cloud service provider, offered to customers on
demand, and exposed through a GUI and an API.
General - Cloud
SaaS
Digicert CertCentral, IBM
MaaS360, IBM Security
Verify, Tenable.io
Cloud-based software delivered for use by the
enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In
this build, GitLab is integrated directly with Azure
AD using SAML, and Microsoft Sentinel pulls logs
from GitLab.)
General -
Enterprise-
Managed Device
Windows client, and
mobile devices (iOS and
Android)
Example endpoints to be protected. (In this build,
all enterprise-managed devices are enrolled into
Microsoft Intune.)
General - BYOD
Windows client, and
mobile devices (iOS and
Android)
Example endpoints to be protected.
L.2 Build Architecture
4841
In this section we present the logical architecture of E4B3. We also describe E4B3’s physical architecture
4842
and present message flow diagrams for some of its processes.
4843
L.2.1 Logical Architecture
4844
Figure L-1 depicts the logical architecture of E4B3. Figure L-1 uses numbered arrows to depict the
4845
general flow of messages needed for a subject to request access to a resource and have that access
4846
request evaluated based on subject identity (both requesting user and requesting endpoint identity),
4847
authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic
4848
reauthentication of the requesting user and the requesting endpoint and periodic verification of
4849
requesting endpoint health, all of which must be performed to continually reevaluate access. The
4850
labeled steps in Figure L-1 have the same meanings as they do in Figure 4-1. However, Figure L-1
4851
includes the specific products that instantiate the architecture of E4B3. Figure L-1 also does not depict
4852
any of the resource management steps found in Figure 4-1 because the ZTA technologies deployed in
4853
E4B3 do not support the ability to perform authentication and reauthentication of the resource or
4854
periodic verification of resource health.
4855
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 227
E4B3 was designed with IBM Security Verify as the ZTA PE, PA, and PEP, and IBM Security Verify
4856
providing ICAM support. Other components that support endpoint security, security analytics, and data
4857
security are also listed in Figure L-1.
4858
Figure L-1 Logical Architecture of E4B3
4859
L.2.2 Physical Architecture
4860
Section 4.5.4 describes the physical architecture of the E4B3 network.
4861
L.2.3 Message Flows for Successful Resource Access Requests
4862
This section depicts some high-level message flows for E4B3 supporting the use case in which a subject
4863
who has an enterprise ID and who is authorized to access an enterprise resource requests and receives
4864
access to that resource. In both use cases depicted here, access to the resource is protected by IBM
4865
Security Verify/Trusteer, which acts as a PDP and an identity provider. In the first use case, the access
4866
request is coming from a managed device, and in the second use case, the access request is coming from
4867
an unmanaged device.
4868
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
IBM Security Verify
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
VMware
AWS
Supporting Components
Endpoint Security:
• IBM Security MaaS360
ICAM, Federated Identity, and
Identity Governance:
IBM Security Verify
Security Analytics:
• IBM QRadar XDR
• IBM Cloud Pak for Security
• Tenable.io, Tenable.ad, and
Tenable NNM
• Mandiant MSV
Multi-Factor Authentication:
IBM Security Verify
Policy Information Points
(PIPs)
IBM Security Verify
Data Security:
IBM Security Guardium Data
Encryption
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 228
L.2.3.1 Use Case in which the Requesting Endpoint is Managed, so Access Is Enforced by
4869
IBM Security Verify/Trusteer and Authentication Is Performed by IBM MaaS360
4870
In this use case, the requesting endpoint is managed by IBM MaaS360. MaaS360 is a UEM that consists
4871
of an agent on the endpoint and a cloud component that work together to perform device
4872
authentication and first and second-factor user authentication, and also to gather device posture
4873
information to ensure device compliance.
4874
The message flow depicted in Figure L-2 shows only the messages that are sent in response to the
4875
access request. However, the authentication process also relies on the following additional background
4876
communications that occur among components on an ongoing basis:
4877
▪ The IBM MaaS360 endpoint agent periodically syncs with the IBM MaaS360 cloud component to
4878
reauthenticate the requesting endpoint device using a unique certificate that has been
4879
provisioned specifically for that device and sends the cloud component information about
4880
device health (e.g., firewall running, anti-malware software, iOS version).
4881
▪ IBM MaaS360 is integrated with IBM Security Verify/Trusteer and periodically sends
4882
Verify/Trusteer assurance that, based on the device health information collected by IBM
4883
MaaS360, the device is compliant with configured policy.
4884
Figure L-2 depicts the message flow for the user’s request to access the resource when the requesting
4885
endpoint is managed.
4886
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 229
Figure L-2 Use Case— E4B3 – The Requesting Endpoint Is Managed, so Access Is Enforced by IBM
4887
Security Verify/Trusteer and IBM MaaS360
4888
The message flow depicted in Figure L-2 consists of the following steps:
4889
1. A user requests to access a resource from a managed endpoint.
4890
2. The resource receives the access request and sends a user authentication request to IBM
4891
Security Verify/Trusteer.
4892
3. Certificate authentication is initiated with the MaaS360 agent.
4893
4. IBM Security Verify/Trusteer authenticates the requesting device’s certificate.
4894
5. Verify/Trusteer checks the endpoint’s compliance status based on information shared by
4895
MaaS360.
4896
6. Verify/Trusteer evaluates the access policy rules to determine if the access request is
4897
authorized.
4898
7. Assuming the request is authorized and the endpoint has passed the authentication and
4899
authorization checks, IBM Security Verify/Trusteer creates a SAML assertion token and sends it
4900
to the resource. The resource accepts the assertion and grants the access request.
4901
8. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).
4902
Requesting
endpoint
ZTA Components
IBM Security
Verify/
Trusteer
Resource
Subject
MaaS360
Agent
User
7. Verify/Trusteer creates a SAML assertion token and
sends it to the resource. The resource accepts the
assertion and grants the access request
IBM
MaaS360
Cloud
1. User requests access to resource
2. Resource sends authentication request
to IBM Security Verify/Trusteer
4. Verify/Trusteer authenticates the requesting device's certificate
8. The user access session between the endpoint and the resource is secured according to policy
Managed Endpoint
3. Certificate authentication is
initiated with MaaS360 agent
5. Verify/Trusteer verifies the
endpoint's compliance status
6. Verify/Trusteer evaluates the access policy rules
to determine if the access request is authorized
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 230
L.2.3.2 Use Case in which the Requesting Endpoint Is Unmanaged, so Access Is Enforced
4903
by IBM Security Verify/Trusteer, which Also Performs User Authentication
4904
In this use case, the requesting endpoint is unmanaged. There is no endpoint agent running on the
4905
device, so device compliance cannot be enforced.
4906
Figure L-3 depicts the message flow for the user’s request to access the resource when the requesting
4907
endpoint is unmanaged.
4908
Figure L-3 Use Case— E4B3 – The Requesting Endpoint Is Unmanaged, so Access Is Enforced by IBM
4909
Security Verify/Trusteer
4910
The message flow depicted in Figure L-3 consists of the following steps:
4911
1. A user requests to access a resource from an unmanaged endpoint.
4912
2. The resource receives the access request and sends a user authentication request to IBM
4913
Security Verify/Trusteer.
4914
3. The user is prompted to provide username and password.
4915
4. IBM Security Verify/Trusteer verifies the username and password.
4916
5. Verify/Trusteer evaluates the access policy rules to determine if the access request is
4917
authorized.
4918
Requesting
endpoint
ZTA Components
IBM Security
Verify/
Trusteer
Resource
Subject
User
6. Verify/Trusteer creates a SAML assertion token and
sends it to the resource. The resource accepts the
assertion and grants the access request
1. User requests access to resource
2. Resource sends authentication request
to IBM Security Verify/Trusteer
4. Verify/Trusteer validates the username/password
7. The user access session between the endpoint and the resource is secured according to policy
Unmanaged
Endpoint
3. Username and password are
requested and received
5. Verify/Trusteer evaluates the access policy rules
to ensure that the access request is authorized
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 231
6. Assuming the request is authorized and the endpoint has passed the authentication and
4919
authorization checks, IBM Security Verify/Trusteer creates a SAML assertion token and sends it
4920
to the resource. The resource accepts the assertion and grants the access request.
4921
7. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).
4922
Note that the message flows depicted in both of these use cases applies to several of the other use
4923
cases we are considering. It applies to all cases in which a user with an enterprise ID who can
4924
successfully authenticate themselves requests and receives access to an enterprise resource that they
4925
are authorized to access. The message flow is the same regardless of whether the user is located on-
4926
premises at headquarters, on-premises at a branch office, or off-premises at home or elsewhere. It is
4927
also the same regardless of whether the resource is located on-premises or in the cloud.
4928
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 232
Appendix M Enterprise 1 Build 4 (E1B4) – SDP
4929
M.1 Technologies
4930
E1B4 uses products from Amazon Web Services, Appgate, IBM, Ivanti, Mandiant, Okta, Radiant Logic,
4931
SailPoint, Tenable, and Zimperium. Certificates from DigiCert are also used. For more information on
4932
these collaborators and the products and technologies that they contributed to this project overall, see
4933
Section 3.4.
4934
E1B4 components consist of Appgate SDP Controller, Appgate SDP Gateway, Appgate SDP client,
4935
Appgate Portal, Appgate Injector (Appgate for Kubernetes), Okta Identity Cloud, Radiant Logic
4936
RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Okta Verify App, Ivanti Neurons for
4937
Unified Endpoint Management (UEM) Platform, Zimperium Mobile Threat Defense, IBM Security QRadar
4938
XDR, Tenable.io, Tenable.ad, Tenable NNM, IBM Cloud Pak for Security, Mandiant Security Validation
4939
(MSV), DigiCert CertCentral, and AWS IaaS and SaaS.
4940
Table M-1 lists all of the technologies used in Build E1B4. It lists the products used to instantiate each
4941
ZTA component and the security function that each component provides.
4942
Table M-1 E1B4 Products and Technologies
4943
Component
Product
Function
PE
Appgate SDP
Controller
Decides whether to grant, deny, or revoke access to a
resource based on enterprise policy, information from
supporting components, and a trust algorithm.
PA
Appgate SDP
Controller
Executes the PE’s policy decision by sending commands to a
PEP that establishes and shuts down the communication path
between subject and resource.
PEP
Appgate SDP
Gateway
Appgate SDP
Client
Guards the trust zone that hosts one or more enterprise
resources; establishes, monitors, and terminates the
connection between subject and resource as directed by the
PA; forwards requests to and receives commands from the
PA.
ICAM - Identity
Management
Okta Identity
Cloud
Creates and manages enterprise user and device accounts,
identity records, role information, and access attributes that
form the basis of access decisions within an organization to
ensure the correct subjects have the appropriate access to
the correct resources at the appropriate time.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 233
Component
Product
Function
ICAM - Access &
Credential
Management
Okta Identity
Cloud
Manages access to resources by performing user and device
authentication (e.g., SSO and MFA) and using identity, role,
and access attributes to determine which access requests are
authorized.
ICAM -
Federated
Identity
Radiant Logic
RadiantOne
Intelligent
Identity Data
Platform
Aggregates and correlates all attributes relating to an identity
or object that is being authorized by a ZTA. It enables users of
one domain to securely access data or systems of 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.
ICAM - Identity
Governance
SailPoint
IdentityIQ
Provides policy-based, centralized, automated processes to
manage user identity and access control functions (e.g.,
ensuring segregation of duties, role management, logging,
access reviews, analytics, reporting) to ensure compliance
with requirements and regulations.
ICAM - MFA
Okta Verify app
Supports MFA of a user identity by requiring the user to
provide not only something they know (e.g., a password), but
also something they have (e.g., a token).
Endpoint
Security -
UEM/MDM
Ivanti Neurons
for Unified
Endpoint
Management
(UEM) Platform
Manages and secures enterprise desktop computers, laptops,
and/or mobile devices in accordance with enterprise policy to
protect applications and data; ensure device compliance;
mitigate and remediate vulnerabilities and threats; monitor
for suspicious activity to prevent and detect intrusions;
prevent, detect, and disable malware and other malicious or
unauthorized traffic; repair infected files when possible;
provide alerts and recommend remediation actions; and
encrypt data.
Pushes enterprise applications and updates to devices,
enables users to download enterprise applications that they
are authorized to access, remotely deletes all applications and
data from devices if needed, tracks user activity on devices,
and detects and addresses security issues on the device.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 234
Component
Product
Function
Endpoint
Security - EPP
Zimperium
Mobile Threat
Defense
Detects and stops threats to endpoints through an integrated
suite of endpoint protection technologies including antivirus,
data encryption, intrusion prevention, EDR, and DLP. May
include mechanisms that are designed to protect applications
and data; ensure device compliance with policies regarding
hardware, firmware, software, and configuration; monitor
endpoints for vulnerabilities, suspicious activity, intrusion,
infection, and malware; block unauthorized traffic; disable
malware and repair infections; manage and administer
software and updates; monitor behavior and critical data; and
enable endpoints to be tracked, troubleshooted, and wiped, if
necessary.
Endpoint
Security -
Endpoint
Compliance
Appgate SDP
Client
Can enforce policies based on a defined set of endpoint
compliance checks to allow or deny user/endpoint access to a
resource, but does not perform the functions of an EPP
solution to automatically remediate an endpoint.
Security
Analytics - SIEM
IBM Security
QRadar XDR
Collects and consolidates security information and security
event data from many sources; correlates and analyzes the
data to help detect anomalies and recognize potential threats
and vulnerabilities; and logs the data to adhere to data
compliance requirements.
Security
Analytics –
Endpoint
Monitoring
Tenable.io
Discovers all IP-connected endpoints and performs
continuous collection, examination, and analysis of software
versions, configurations, and other information regarding
hosts (devices or VMs) that are connected to the network.
Security
Analytics -
Vulnerability
Scanning and
Assessment
Tenable.io and
Tenable.ad
Scans and assesses the enterprise infrastructure and
resources for security risks, identifies vulnerabilities and
misconfigurations, and provides remediation guidance
regarding investigating and prioritizing responses to incidents.
Security
Analytics - Traffic
Inspection
Tenable NNM
Intercepts, examines, and records relevant traffic transmitted
on the network.
Security
Analytics -
Network
Discovery
Tenable NNM
Discovers, classifies, and assesses the risk posed by devices
and users on the network.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 235
Component
Product
Function
Security
Analytics - SOAR
IBM Cloud Pak
for Security
Integrates the SIEM and other security tools into a single pane
of glass to support generation of insights into threats and help
track, manage, and resolve cybersecurity incidents.
Executes predefined incident response workflows to
automatically analyze information and orchestrate the
operations required to respond.
Security
Analytics -
Security
Validation
Mandiant
Security
Validation
Provides visibility and evidence on the status of the security
controls’ effectiveness in the ZTA. Enables security capabilities
of the enterprise to be monitored and verified by
continuously validating and measuring the cybersecurity
controls; also used to automate the demonstrations that were
performed to showcase ZTA capabilities. Deployed
throughout the project’s laboratory environment to enable
monitoring and verification of various security aspects of the
builds. VMs that are intended to operate as actors are
deployed on each of the subnetworks in each of the
enterprises. These actors can be used to initiate various
actions for the purpose of verifying that security controls are
working to support the objectives of zero trust.
General -
Remote
Connectivity
Appgate SDP
Appgate components are used to provide remote users’
connectivity to on-premises or cloud resources.
Resource
Protection -
PaaS/Kubernetes
Security
Appgate Injector
The Appgate Injector (Appgate for Kubernetes) creates a per-
pod secure connection to the PEP, enabling authorized
service-to-service and service-to-resource communication
without the Pod or the resource visible on the Internet.
General -
Certificate
Management
DigiCert
CertCentral TLS
Manager
Provides automated capabilities to issue, install, inspect,
revoke, renew, and otherwise manage TLS certificates.
General - Cloud
IaaS
AWS - GitLab,
WordPress
Provides computing resources, complemented by storage and
networking capabilities, hosted by a cloud service provider,
offered to customers on demand, and exposed through a GUI
and an API. An IPsec tunnel is used to provide a secure
connection from the enterprise to the cloud.
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 236
Component
Product
Function
General - Cloud
SaaS
AWS - Digicert
CertCentral,
Ivanti Neurons
for UEM, Okta
Identity Cloud,
Tenable.io,
Zimperium MTD
Cloud-based software delivered for use by the enterprise.
General -
Application
GitLab
Example enterprise resource to be protected. (In this build,
GitLab is integrated with Okta using SAML, and IBM Security
QRadar XDR pulls logs from GitLab). There are instances of
Gitlab on-premises and in AWS.
General -
Enterprise-
Managed Device
Mobile devices
(iOS and Android)
and
desktops/laptops
(Windows and
Mac)
Example endpoints to be protected. All enterprise-managed
mobile devices are running an Ivanti Neurons for UEM agent
and also have the Okta Verify App installed. If Ivanti Neurons
for UEM agent is used to push Appgate SDP Client to the
endpoint, that endpoint is considered to be a managed
device.
General - BYOD
Mobile devices
(iOS and Android)
and
desktops/laptops
(Windows, Linux
and Mac)
Example endpoints to be protected.
M.2 Build Architecture
4944
In this section we present the logical architecture of E1B4. We also describe E1B4’s physical architecture
4945
and present message flow diagrams for some of its processes.
4946
M.2.1 Logical Architecture
4947
Figure M-1 depicts the logical architecture of E1B4. It uses numbered arrows to depict the general flow
4948
of messages needed for a subject to request access to a resource and have that access request
4949
evaluated based on subject identity (both requesting user and requesting endpoint identity), user
4950
authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic
4951
reauthentication of the requesting user and the requesting endpoint and periodic verification of
4952
requesting endpoint health, all of which must be performed to continually reevaluate access. The
4953
labeled steps in Figure M-1 have the same meanings as they do in Figure 4-1. However, Figure M-1
4954
includes the specific products that instantiate the architecture of E1B4. Figure M-1 also does not depict
4955
any of the resource management steps found in Figure 4-1 because the ZTA technologies deployed in
4956
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 237
E1B4 do not support the ability to perform authentication and reauthentication of the resource or
4957
periodic verification of resource health.
4958
E1B4 was designed with Appgate components that serve as PEs, PAs, and PEPs, and Okta Identity Cloud
4959
that serves as the identity, access, and credential manager. Radiant Logic acts as a PIP for the PDP as it
4960
responds to inquiries and provides identity information on demand in order for Okta to make near-real-
4961
time access decisions. A more detailed depiction of the messages that flow among components to
4962
support a user access request can be found in Appendix M.2.4.
4963
Figure M-1 Logical Architecture of E1B4
4964
M.2.2 ICAM Information Architecture
4965
How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used
4966
among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture
4967
ensures that when a subject requests access to a resource, the aggregated set of identity information
4968
and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a
4969
basis on which to make the access decision.
4970
S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification
Data Plane
I(5). Session
I(1). Initial access request
(identity and credentials)
Control Plane
I(2). Info needed
to verify subject
and its endpoint
I(3). Information needed to
approve/deny access request
S(B). Information needed to
continually evaluate access
I(4).
Allow/
deny
access
S(C). Continue/revoke/limit
session access
S(A). Access
requests; info
needed to
periodically
verify subject
(both user and
endpoint)
I(N): Initial Connection
S(X): Session Management
Policy Decision
Point (PDP)
Policy Enforcement
Point(s) (PEPs)
Subject
User
Endpoint
Resource
On-Prem
Supporting Components
Endpoint Security:
• Ivanti Neurons for UEM
• Appgate SDP Client
• Zimperium Mobile Threat Defense
ICAM: Okta Identity Cloud
Federated Identity:
Radiant Logic RadiantOne
Identity Governance:
SailPoint IdentityIQ
Security Analytics:
• IBM Security QRadar XDR
• IBM Cloud Pak for Security
• Tenable.io, Tenable.ad, and
Tenable NNM
• Mandiant MSV
Multi-Factor Authentication:
• Okta Verify App
AWS
Cloud
Policy Information Points
(PIPs)
Appgate SDP Controller
Appgate SDP Gateway
Appgate SDP Client
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 238
In E1B4, Okta, Radiant Logic, and SailPoint integrate with each other as well as with other components
4971
of the ZTA to support the ICAM information architecture. The ways that these components work
4972
together to correlate identity information and to support actions such as users joining, changing roles,
4973
and leaving the enterprise are the same in E1B4 as they are in E1B1, E1B2, and E1B3. These interactions
4974
are described in Appendix D.2.2.
4975
M.2.3 Physical Architecture
4976
Sections 4.5.1 and 4.5.2 describe and depict the physical architecture of E1B4 headquarters network and
4977
E1B4 branch office network, respectively.
4978
M.2.4 Message Flows for Successful Resource Access Requests
4979
This section presents the high-level message flows supporting the use cases in which a subject who has
4980
an enterprise ID and who is authorized to access an enterprise resource requests and receives access to
4981
that resource. In the cases depicted here, access to the resource is protected by the Appgate SDP
4982
System, which is comprised of Controllers that act as PDPs; Gateways that acts as PEPs; and the Appgate
4983
SDP Client, which supports endpoint compliance. The Appgate system integrates with Okta, which acts
4984
as identity provider (IdP); Ivanti Neurons for UEM, which acts as endpoint manager; and Zimperium
4985
Mobile Threat Defense. Two message flows are depicted: one in which the resource being accessed is
4986
located on-premises and another in which the resource is in the AWS cloud. For the on-premises case,
4987
the Appgate SDP Controller and Gateway are located on-premises. For the AWS case, the Appgate SDP
4988
Controller and Gateway are located in the cloud.
4989
Both use cases that are depicted show only the messages that are sent in response to the access
4990
request. However, the authentication process also relies on the following additional background
4991
communications that occur among components:
4992
▪ The Ivanti Neurons for UEM agent that is running on the user’s endpoint (mobile devices only)
4993
periodically syncs with the Ivanti Neurons for UEM Platform in the cloud to reauthenticate the
4994
requesting endpoint device using a unique certificate that has been provisioned specifically for
4995
that device, and sends the cloud component information about device posture and health (e.g.,
4996
risk score, threat defense status, iOS version).
4997
▪ Zimperium Mobile Threat Defense is integrated with Ivanti Neurons for UEM, and Zimperium
4998
periodically sends threat information to it. When Zimperium detects a threat, it can also block
4999
the threat as well as send Ivanti information about the threat.
5000
▪ When a user initiates login with the Appgate Mobile Client, the Appgate SDP Controller queries
5001
the Ivanti Neurons for UEM Platform to obtain real-time information regarding device health for
5002
the user’s device. The Appgate SDP Client running on the user’s endpoint periodically syncs with
5003
the Appgate SDP System to provide information regarding device compliance and dynamically
5004
adjusts user and device attributes and authorizations.
5005
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 239
To access a resource in both use cases depicted here, the user must log into the Appgate SDP Client that
5006
is running on the user’s endpoint. When the user logs into the client, the following steps are performed
5007
to initiate operations:
5008
1. The Appgate SDP Client sends an encrypted Single Packet Authorization (SPA) UDP packet to the
5009
Controller to pre-authorize the subsequent TLS connection.
5010
2. The Appgate SDP Client establishes a TLS connection and authenticates to the Appgate SDP
5011
Controller. During this process, the user is redirected to Okta and the SAML assertion is sent to
5012
the Controller.
5013
3. The Appgate SDP Controller issues a signed and encrypted entitlement token to the client that
5014
contains user and device attributes, protected resource authorizations, and the hostnames and
5015
SPA keys for authorized Appgate Gateways.
5016
4. The Appgate SDP Client creates a TLS tunnel and passes the signed Entitlement token to an
5017
Appgate Gateway that is guarding resources the client is authorized to access. (Note: When
5018
there are multiple gateways guarding the same resource, the client chooses one of the gateways
5019
based on load balancing information contained in the entitlement token.)
5020
5. The Appgate Gateway validates the token and creates a session-based microfirewall for the
5021
user/device to enforce policies created on the Appgate SDP Controller.
5022
Once an authorized user has logged into the Appgate SDP Client, they may access any resource, either
5023
on-premises or in the cloud, that they are authorized to access, with the Gateway in each location acting
5024
as the PEP.
5025
M.2.4.1 Use Case in which Access to a Resource that Is On-Premises Is Enforced by
5026
Appgate
5027
Figure M-2 depicts the message flow for the user’s request to access the resource located on-premises.
5028
The message flow begins after the user has already successfully logged into the Appgate SDP Client and
5029
established tunnels to all authorized Gateways guarding access to protected resources, which, in this
5030
case, is the Appgate SDP Gateway that is located on-premises.
5031
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 240
Figure M-2 Use Case—E1B4 – Access to an On-Premises Resource Is Enforced by Appgate
5032
The message flow depicted in Figure M-2 consists of the following steps:
5033
1. A user initiates access to an on-premises resource, e.g., GitLab.
5034
2. The endpoint sends a request packet to the resource via this tunnel. The request is sent in the
5035
tunnel from the client to the Gateway, and then the Gateway forwards the message to the
5036
resource.
5037
3. The resource, which in this case is GitLab, displays the option for the user to sign in with SAML.
5038
When the user clicks on the sign-on with SAML icon on the GitLab screen, the resource creates a
5039
SAML request and sends the SAML request to the user’s endpoint via the Appgate Gateway and
5040
the tunnel.
5041
4. The user’s endpoint sends the SAML request to the Okta Identity Cloud, which is located on the
5042
internet.
5043
Requesting
endpoint
ZTA Components
Ivanti
Neurons
for UEM
Platform
Appgate SDP
Controller
Resource
Subject
Appgate SDP
Client
User
6. User responds
5. Okta prompts for username and password
On-
Premises
Appgate
SDP
Gateway
1. User initiates access to protected resource
3. Resource sends the SAML authentication request to the endpoint via the tunnel and gateway
11. The endpoint sends the SAML assertion token to the resource via the
tunnel that was set up between the Appgate SDP client and the Appgate SDP
gateway. The resource accepts the assertion and grants the access request
4. Endpoint sends the SAML
request to Okta
7. Okta authenticates
the user and verifies the
device certificate
10. Okta generates a SAML assertion
token and sends it to the endpoint
12. Traffic on the user session between the endpoint and the resource is transmitted back and
forth through the tunnel and is secured according to policy
Zimperium
Mobile
Threat
Defense
Okta
Identity
Cloud
Ivanti Neurons
for UEM Agent
On-
Premises
Endpoint
Hosting
Resource
Okta
Verify
App
2. The endpoint sends a request packet to the resource via the tunnel and gateway
8. Okta challenges user to provide
second factor authentication via
the Okta Verify App
9. User provides second authentication factor
(biometrics)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 241
5. Okta prompts for username and password.
5044
6. The user responds with username and password.
5045
7. Okta authenticates the user and verifies the device certificate.
5046
8. Okta challenges the user to perform second-factor authentication using the Okta Verify App.
5047
9. The user provides the second authentication factor (i.e., biometrics).
5048
10. Okta generates a SAML assertion and sends it to the user’s endpoint.
5049
11. The user’s endpoint sends the SAML assertion to the resource (GitLab) via the tunnel between
5050
the Appgate SDP Client and the Appgate SDP Gateway. The resource accepts the assertion and
5051
grants the access request.
5052
12. User traffic to and from the resource is transmitted back and forth through the Appgate tunnel,
5053
ensuring it is secured according to policy.
5054
The Appgate SDP Client collects system attributes every five minutes and updates the Appgate SDP
5055
Controller to ensure the client conforms with policy.
5056
Note that the message flow depicted in Figure M-2 is the same regardless of whether the employee is
5057
located on-premises at headquarters, on-premises at a branch office, or off-premises at a remote
5058
location.
5059
M.2.4.2 Use Case in which Access to a Resource in the AWS Cloud is Enforced by
5060
Appgate
5061
Figure M-3 depicts the message flow for the user’s request to access the resource located in the AWS
5062
cloud. The message flow begins after the user has already successfully logged into the Appgate SDP
5063
Client and established tunnels to all authorized Gateways guarding access to protected resources,
5064
which, in this case, is the Appgate SDP Gateway that is located in AWS.
5065
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 242
Figure M-3 Use Case—E1B4 – Access to an AWS Cloud Resource Is Enforced by Appgate
5066
The message flow depicted in Figure M-3 consists of the following steps:
5067
1. A user initiates access to an AWS cloud resource, e.g., GitLab.
5068
2. The endpoint sends a request packet to the resource via this tunnel. The request is sent in the
5069
tunnel from the client to the Gateway, and then the Gateway forwards the message to the
5070
resource.
5071
3. The resource, which in this case is GitLab, displays the option for the user to sign in with SAML.
5072
When the user clicks on the sign-on with SAML icon on the GitLab screen, the resource creates a
5073
SAML request and sends the SAML request to the user’s endpoint via the Appgate Gateway and
5074
the tunnel.
5075
4. The user’s endpoint sends the SAML request to the Okta Identity Cloud, which is located on the
5076
internet.
5077
Resource in the
AWS cloud
Requesting
endpoint
ZTA Components
Ivanti
Neurons
for UEM
Platform
Appgate SDP
Controller
Subject
Appgate SDP
Client
User
6. User responds
5. Okta prompts for username and password
On-
Premises
Appgate
SDP
Gateway
1. User initiates access to protected resource
3. Resource sends the SAML authentication request to the endpoint via the tunnel and gateway
11. The endpoint sends the SAML assertion token to the resource via the
tunnel that was set up between the Appgate SDP client and the Appgate SDP
gateway. The resource accepts the assertion and grants the access request
4. Endpoint sends the SAML
request to Okta
7. Okta authenticates
the user and verifies the
device certificate
10. Okta generates a SAML assertion
token and sends it to the endpoint
12. Traffic on the user session between the endpoint and the resource is transmitted back and
forth through the tunnel and is secured according to policy
Zimperium
Mobile
Threat
Defense
Okta
Identity
Cloud
Ivanti Neurons
for UEM Agent
On-
Premises
Endpoint
Hosting
Resource
Okta
Verify
App
2. The endpoint sends a request packet to the resource via the tunnel and gateway
8. Okta challenges user to provide
second factor authentication via
the Okta Verify App
9. User provides second authentication factor
(biometrics)
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 243
5. Okta prompts for username and password.
5078
6. The user responds with username and password.
5079
7. Okta authenticates the user and verifies the device certificate.
5080
8. Okta challenges the user to perform second-factor authentication using the Okta Verify App.
5081
9. The user provides the second authentication factor (i.e., biometrics).
5082
10. Okta generates a SAML assertion and sends it to the user’s endpoint.
5083
11. The user’s endpoint sends the SAML assertion to the resource (GitLab) via the tunnel between
5084
the Appgate SDP Client and the Appgate SDP Gateway. The resource accepts the assertion and
5085
grants the access request.
5086
12. User traffic to and from the resource is transmitted back and forth through the Appgate tunnel,
5087
ensuring it is secured according to policy.
5088
The Appgate SDP Client collects system attributes every five minutes and updates the Appgate SDP
5089
Controller to ensure the client conforms with policy.
5090
Note that the message flow depicted in Figure M-3 is the same regardless of whether the employee is
5091
located on-premises at headquarters, on-premises at a branch office, or off-premises at home or
5092
elsewhere.
5093
M.2.4.3 Service-to-Service Use Case in which a request by one service to access another
5094
service is controlled by Appgate
5095
For this use case, the requesting service has an embedded headless client, i.e., a client that does not
5096
have a user interface. This headless client must be pre-configured with an identity profile and
5097
credentials. Upon boot-up, the headless client immediately tries to sign in to the Appgate SDP Controller
5098
(and it will continue retrying if it fails). The steps in the process are depicted in Figure M-4 and described
5099
below.
5100
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 244
Figure M-4 Use Case—E1B4 – Server-to-Server Access Enforced by Appgate
5101
The message flow depicted in Figure M-4 consists of the following steps:
5102
1. The headless client sends an encrypted SPA UDP packet to the Controller to pre-authorize the
5103
subsequent TLS connection.
5104
2. The headless client establishes a TLS connection and authenticates to the Appgate SDP
5105
Controller.
5106
3. The Appgate SDP Controller issues a signed entitlement token to the headless client that
5107
enables it to access the resources protected by Appgate SDP that it has been authorized to
5108
access according to policy created on the Controller.
5109
4. The headless client will automatically try to establish a secure connection with an Appgate
5110
Gateway that is guarding resources that the headless client is authorized to access by passing
5111
the signed entitlement token to the Gateway.
5112
5. The Gateway validates the token and creates a session-based micro-firewall for the headless
5113
client to enforce policies created on the Appgate SDP Controller.
5114
Once a session-based micro-firewall for the headless client has been created on an Appgate SDP
5115
Gateway at each site (e.g., on-premises and in AWS), the headless client may access any authorized
5116
resource, with the Gateway(s) in each location acting as the PEP. If the headless client initiates access to
5117
Server
Resource
7. Client initiates access to a resource that it is authorized to access, and access is permitted
6. Every 5 minutes, the Appgate SDP Headless Client updates
posture information and updates the Appgate SDP System
to verify that the client conforms with policy
Appgate
SDP
Gateway
1. Server boots up. Client sends an encrypted SPA to the Appgate SDP Controller
3. Controller sends client an entitlement token
that describes the client's access authorizations
4.Client establishes a secure connection with one of the Appgate Gateways
guarding resources that the client is authorized to access
and sends the signed entitlement token to that Gateway
5. Gateway validates the
token and establishes a session-
based microfirewall for the
headless client to enforce
the client's access authorizations
Appgate
SDP
Controller
Headless
Client
Server
Hosting
Resource
2. Client establishes a TLS connection and authenticates to the SDP Controller
8. Client initiates access to a resource that it is not authorized to access
and access is denied (packets are dropped) at the Appgate Gateway
X
THIRD PRELIMINARY DRAFT
NIST SP 1800-35B: Implementing a Zero Trust Architecture 245
a protected resource it is authorized to access, the Gateway will route the request to the resource. If the
5118
headless client initiates access to a protected resource it is not authorized to access, the Gateway’s
5119
session-based micro-firewall will drop the network packets.
5120
The headless client is not re-authenticated every time it initiates access to a protected resource.
5121
However, the Appgate SDP Headless Client collects system attributes every five minutes and updates the
5122
Appgate SDP Controller to ensure the client conforms with policy.
5123