NIST SPECIAL PUBLICATION 1800-35C
Implementing a Zero Trust Architecture
Volume C:
How-To Guides
Gema Howell
Alper Kerman
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
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
Aaron Rodriguez
Micah Wilson
Cisco
Herndon, VA
Corey Bonnell
Dean Coclin
DigiCert
Lehi, UT
Ryan Johnson
Dung Lam
F5
Seattle, WA
Neal Lucier
Tom May
Forescout
San Jose, CA
Tim Knudsen
Google Cloud
Mill Valley, CA
Harmeet Singh
Krishna Yellepeddy
IBM
Armonk, NY
Corey Lund
Farhan Saifudin
Ivanti
South Jordan, UT
Hashim Khan
Tim LeMaster
Lookout
Reston, VA
James Elliott
David Pricer
Mandiant
Reston, VA
Carmichael Patton
Brandon Stephenson
Microsoft
Redmond, WA
Vinu Panicker
Okta
San Francisco, CA
Andrew Keffalas
Norman Wong
Palo Alto Networks
Santa Clara, CA
Rob Woodworth
Shawn Higgins
PC Matic
Myrtle Beach, SC
Bryan Rosensteel
Mitchell Lewars
Ping Identity
Denver, CO
Wade Ellery
Don Coltrain
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
Jacob Rapp
Paul Mancuso
VMware
Palo Alto, CA
Joe Brown
Jim Kovach
Zimperium
Dallas, TX
Bob Smith
Syed Ali
Zscaler
San Jose, CA
December 2022
SECOND PRELIMINARY DRAFT
This publication is available free of charge from
https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: 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
While NIST and the NCCoE address goals of improving management of cybersecurity and privacy risk
8
through outreach and application of standards and best practices, it is the stakeholder’s responsibility to
9
fully perform a risk assessment to include the current threat, vulnerabilities, likelihood of a compromise,
10
and the impact should the threat be realized before adopting cybersecurity measures such as this
11
recommendation.
12
National Institute of Standards and Technology Special Publication 1800-35C, Natl. Inst. Stand. Technol.
13
Spec. Publ. 1800-35C, 90 pages, (December 2022), CODEN: NSPUE2
14
FEEDBACK
15
You can improve this guide by contributing feedback. As you review and adopt this solution for your
16
own organization, we ask you and your colleagues to share your experience and advice with us.
17
Comments on this publication may be submitted to: [email protected].
18
Public comment period: December 21, 2022 through February 6, 2023
19
All comments are subject to release under the Freedom of Information Act.
20
National Cybersecurity Center of Excellence
21
National Institute of Standards and Technology
22
100 Bureau Drive
23
Mailstop 2002
24
Gaithersburg, MD 20899
25
Email: nccoe@nist.gov
26
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture iii
NATIONAL CYBERSECURITY CENTER OF EXCELLENCE
27
The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards
28
and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and
29
academic institutions work together to address businesses’ most pressing cybersecurity issues. This
30
public-private partnership enables the creation of practical cybersecurity solutions for specific
31
industries, as well as for broad, cross-sector technology challenges. Through consortia under
32
Cooperative Research and Development Agreements (CRADAs), including technology collaborators—
33
from Fortune 50 market leaders to smaller companies specializing in information technology security—
34
the NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity
35
solutions using commercially available technology. The NCCoE documents these example solutions in
36
the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework
37
and details the steps needed for another entity to re-create the example solution. The NCCoE was
38
established in 2012 by NIST in partnership with the State of Maryland and Montgomery County,
39
Maryland.
40
To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit
41
https://www.nist.gov.
42
NIST CYBERSECURITY PRACTICE GUIDES
43
NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity
44
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the
45
adoption of standards-based approaches to cybersecurity. They show members of the information
46
security community how to implement example solutions that help them align with relevant standards
47
and best practices, and provide users with the materials lists, configuration files, and other information
48
they need to implement a similar approach.
49
The documents in this series describe example implementations of cybersecurity practices that
50
businesses and other organizations may voluntarily adopt. These documents do not describe regulations
51
or mandatory practices, nor do they carry statutory authority.
52
ABSTRACT
53
A zero trust architecture (ZTA) focuses on protecting data and resources. It enables secure authorized
54
access to enterprise resources that are distributed across on-premises and multiple cloud environments,
55
while enabling a hybrid workforce and partners to access resources from anywhere, at any time, from
56
any device in support of the organization’s mission. Each access request is evaluated by verifying the
57
context available at access time, including the requester’s identity and role, the requesting device’s
58
health and credentials, and the sensitivity of the resource. If the enterprise’s defined access policy is
59
met, a secure session is created to protect all information transferred to and from the resource. A real-
60
time and continuous policy-driven, risk-based assessment is performed to establish and maintain the
61
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture iv
access. In this project, the NCCoE and its collaborators use commercially available technology to build
62
interoperable, open, standards-based ZTA implementations that align to the concepts and principles in
63
NIST Special Publication (SP) 800-207, Zero Trust Architecture. This NIST Cybersecurity Practice Guide
64
explains how commercially available technology can be integrated and used to build various ZTAs.
65
KEYWORDS
66
enhanced identity governance (EIG); identity, credential, and access management (ICAM); zero trust;
67
zero trust architecture (ZTA).
68
ACKNOWLEDGMENTS
69
We are grateful to the following individuals for their generous contributions of expertise and time.
70
Name
Organization
Quint Van Deman
Amazon Web Services
Jason Garbis
Appgate
Adam Rose
Appgate
Jonathan Roy
Appgate
Eric Michael
Broadcom Software
Ken Andrews
Cisco
Matthew Hyatt
Cisco
Leo Lebel
Cisco
Tom Oast
Cisco
Peter Romness
Cisco
Steve Vetter
Cisco
Daniel Cayer
F5
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture v
Name
Organization
David Clark
F5
Jay Kelley
F5
Tim Jones
Forescout
Yejin Jang
Forescout
Andrew Campagna
IBM
Adam Frank
IBM
Nalini Kannan
IBM
Priti Patil
IBM
Nikhil Shah
IBM
Mike Spisak
IBM
Vahid Esfahani
IT Coalition
Ebadullah Siddiqui
IT Coalition
Musumani Woods
IT Coalition
Tyler Croak
Lookout
Madhu Dodda
Lookout
Jeff Gilhool
Lookout
Ken Durbin
Mandiant
Earl Matthews
Mandiant
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture vi
Name
Organization
Joey Cruz
Microsoft
Tarek Dawoud
Microsoft
Janet Jones
Microsoft
Hemma Prafullchandra
Microsoft
Clay Taylor
Microsoft
Sarah Young
Microsoft
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
Oliver Borchert
NIST
Douglas Montgomery
NIST
Scott Rose
NIST
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture vii
Name
Organization
Kevin Stine
NIST
Sean Frazier
Okta
Kelsey Nelson
Okta
Shankar Chandrasekhar
Palo Alto Networks
Sean Morgan
Palo Alto Networks
Seetal Patel
Palo Alto Networks
Zack Austin
PC Matic
Andy Tuch
PC Matic
Ivan Anderson
Ping Identity
Bill Baz
Radiant Logic
John Petrutiu
Radiant Logic
Rusty Deaton
Radiant Logic
Deborah McGinn
Radiant Logic
Lauren Selby
Radiant Logic
Peter Amaral
SailPoint
Jim Russell
SailPoint
Esteban Soto
SailPoint
Karen Scarfone
Scarfone Cybersecurity
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture viii
Name
Organization
Jeremiah Stallcup
Tenable
Bill Stritzinger
Tenable
Andrew Babakian
VMware
Peter Bjork
VMware
Genc Domi
VMware
Keith Luck
VMware
Dennis Moreau
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
71
The Technology Partners/Collaborators who participated in this build submitted their capabilities in
72
response to a notice in the Federal Register. Respondents with relevant capabilities or product
73
components were invited to sign a Cooperative Research and Development Agreement (CRADA) with
74
NIST, allowing them to participate in a consortium to build this example solution. We worked with:
75
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture ix
Technology Collaborators
Appgate
Ping Identity
AWS
Radiant Logic
Broadcom Software
SailPoint
Cisco
Tenable
DigiCert
Trellix
F5
VMware
Forescout
Zimperium
Google Cloud
Zscaler
DOCUMENT CONVENTIONS
76
The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the
77
publication and from which no deviation is permitted. The terms “should” and “should not” indicate that
78
among several possibilities, one is recommended as particularly suitable without mentioning or
79
excluding others, or that a certain course of action is preferred but not necessarily required, or that (in
80
the negative form) a certain possibility or course of action is discouraged but not prohibited. The terms
81
“may” and “need not” indicate a course of action permissible within the limits of the publication. The
82
terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.
83
CALL FOR PATENT CLAIMS
84
This public review includes a call for information on essential patent claims (claims whose use would be
85
required for compliance with the guidance or requirements in this Information Technology Laboratory
86
(ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication
87
or by reference to another publication. This call also includes disclosure, where known, of the existence
88
of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant
89
unexpired U.S. or foreign patents.
90
ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in
91
written or electronic form, either:
92
a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not
93
currently intend holding any essential patent claim(s); or
94
b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring
95
to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft
96
publication either:
97
1. under reasonable terms and conditions that are demonstrably free of any unfair discrimination;
98
or
99
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture x
2. without compensation and under reasonable terms and conditions that are demonstrably free
100
of any unfair discrimination.
101
Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its
102
behalf) will include in any documents transferring ownership of patents subject to the assurance,
103
provisions sufficient to ensure that the commitments in the assurance are binding on the transferee,
104
and that the transferee will similarly include appropriate provisions in the event of future transfers with
105
the goal of binding each successor-in-interest.
106
The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of
107
whether such provisions are included in the relevant transfer documents.
108
Such statements should be addressed to: nccoe-zta-project@list.nist.gov
109
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture xi
Contents
110
1 Introduction ........................................................................................1
111
1.1 How to Use this Guide ................................................................................................... 1
112
1.2 Build Overview .............................................................................................................. 3
113
1.2.1 EIG Crawl Phase Build Features .................................................................................... 4
114
1.2.2 EIG Run Phase Build Features ....................................................................................... 4
115
1.2.3 Physical Architecture Overview .................................................................................... 5
116
1.3 Typographic Conventions .............................................................................................. 7
117
2 Enterprise 1 Build 1 (EIG E1B1) Technology Guides ..............................8
118
2.1 Okta Identity Cloud ....................................................................................................... 8
119
2.1.1 Configuration and Integration ...................................................................................... 8
120
2.1.2 Okta Verify App............................................................................................................. 9
121
2.1.3 Okta Access Gateway ................................................................................................... 9
122
2.2 Radiant Logic RadiantOne ........................................................................................... 10
123
2.2.1 Installation .................................................................................................................. 10
124
2.2.2 Configuration .............................................................................................................. 10
125
2.2.3 Integration .................................................................................................................. 14
126
2.3 SailPoint IdentityIQ ...................................................................................................... 15
127
2.3.1 Installation and Configuration .................................................................................... 15
128
2.3.2 Integration with Radiant Logic ................................................................................... 18
129
2.3.3 Integration with AD .................................................................................................... 19
130
2.3.4 Integration with Okta ................................................................................................. 21
131
2.4 Ivanti Neurons for UEM ............................................................................................... 22
132
2.4.1 Installation and Configuration .................................................................................... 22
133
2.4.2 Integration with Ivanti Connector .............................................................................. 27
134
2.4.3 Integration with Okta ................................................................................................. 27
135
2.4.4 Integration with QRadar ............................................................................................. 29
136
2.5 Ivanti Sentry ................................................................................................................ 30
137
2.5.1 Installation and Configuration .................................................................................... 30
138
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture xii
2.5.2 Ivanti Tunnel Configuration and Deployment ............................................................ 30
139
2.6 Ivanti Access ZSO ......................................................................................................... 31
140
2.6.1 Integration with Ivanti Neurons for UEM ................................................................... 31
141
2.6.2 Integration with Okta ................................................................................................. 31
142
2.7 Zimperium Mobile Threat Defense (MTD) .................................................................. 32
143
2.7.1 Installation, Configuration, and Integration ............................................................... 32
144
2.8 IBM Cloud Pak for Security .......................................................................................... 36
145
2.9 IBM Security QRadar XDR ............................................................................................ 37
146
2.10 Tenable.io .................................................................................................................... 37
147
2.10.1 Installation and Configuration .................................................................................... 37
148
2.10.2 Integration with QRadar ............................................................................................. 38
149
2.11 Tenable.ad ................................................................................................................... 38
150
2.12 Tenable NNM............................................................................................................... 39
151
2.12.1 Deploy a Tenable NNM instance ................................................................................ 39
152
2.13 Mandiant Security Validation (MSV) ........................................................................... 39
153
2.13.1 MSV Director Installation/Configuration .................................................................... 39
154
2.13.2 MSV Network Actor Installation/Configuration ......................................................... 40
155
2.13.3 MSV Endpoint Actor Installation/Configuration ........................................................ 40
156
2.13.4 MSV Evaluation Configuration.................................................................................... 41
157
2.13.5 MSV Evaluation Execution .......................................................................................... 43
158
2.14 DigiCert CertCentral .................................................................................................... 44
159
2.14.1 Requesting a certificate .............................................................................................. 44
160
2.14.2 Obtaining and implementing a certificate.................................................................. 45
161
3 Enterprise 2 Build 1 (EIG E2B1) Product Guides .................................. 45
162
3.1 Ping Identity PingOne .................................................................................................. 45
163
3.1.1 Configuration: PingOne and PingFederate ................................................................. 45
164
3.1.2 Integration with Radiant Logic ................................................................................... 46
165
3.1.3 Integration with Cisco Duo ......................................................................................... 47
166
3.2 Radiant Logic RadiantOne ........................................................................................... 47
167
3.2.1 Installation and Configuration .................................................................................... 47
168
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture xiii
3.2.2 Configuration .............................................................................................................. 47
169
3.2.3 Integration .................................................................................................................. 47
170
3.3 SailPoint IdentityIQ ...................................................................................................... 47
171
3.3.1 Installation and Configuration .................................................................................... 47
172
3.3.2 Integration with Radiant Logic ................................................................................... 47
173
3.3.3 Integration with AD .................................................................................................... 48
174
3.3.4 Integration with Ping Identity..................................................................................... 48
175
3.4 Cisco Duo ..................................................................................................................... 48
176
3.4.1 Configuration .............................................................................................................. 48
177
3.4.2 Integration .................................................................................................................. 48
178
3.5 Palo Alto Networks Next Generation Firewall ............................................................ 49
179
3.6 IBM Security QRadar XDR ............................................................................................ 49
180
3.7 Tenable.io .................................................................................................................... 49
181
3.8 Tenable.ad ................................................................................................................... 49
182
3.9 Tenable NNM............................................................................................................... 49
183
3.10 Mandiant Security Validation (MSV) ........................................................................... 49
184
3.11 DigiCert CertCentral .................................................................................................... 49
185
4 Enterprise 3 Build 1 (EIG E3B1) Product Guides .................................. 49
186
4.1 Microsoft Azure Active Directory (AD) ........................................................................ 50
187
4.2 Microsoft Endpoint Manager ...................................................................................... 50
188
4.2.1 Configuration and Integration .................................................................................... 51
189
4.3 Microsoft Defender for Endpoint ................................................................................ 52
190
4.3.1 Configuration and Integration .................................................................................... 52
191
4.3.2 Microsoft Defender Antivirus ..................................................................................... 53
192
4.4 Microsoft Sentinel ....................................................................................................... 53
193
4.5 Microsoft Office 365 .................................................................................................... 53
194
4.6 F5 BIG-IP ...................................................................................................................... 54
195
4.6.1 Installation, Configuration, and Integration ............................................................... 54
196
4.7 Lookout Mobile Endpoint Security (MES) ................................................................... 55
197
4.7.1 Configuration and Integration .................................................................................... 56
198
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture xiv
4.7.2 Create MTD Device Compliance Policy with Intune ................................................... 58
199
4.8 PC Matic Pro ................................................................................................................ 58
200
4.9 Tenable.io .................................................................................................................... 59
201
4.9.1 Integration with Microsoft Sentinel ........................................................................... 59
202
4.10 Tenable.ad ................................................................................................................... 60
203
4.11 Tenable NNM............................................................................................................... 60
204
4.12 Mandiant Security Validation (MSV) ........................................................................... 60
205
4.13 Forescout eyeSight ...................................................................................................... 60
206
4.13.1 Integration with AD .................................................................................................... 60
207
4.13.2 Integration with Cisco Switch ..................................................................................... 60
208
4.13.3 Integration with Cisco Wireless Controller................................................................. 61
209
4.13.4 Integration with Microsoft Sentinel ........................................................................... 61
210
4.13.5 Integration with Palo Alto Networks NGFW .............................................................. 61
211
4.13.6 Integration with Tenable.io ........................................................................................ 61
212
4.14 Palo Alto Networks Next Generation Firewall ............................................................ 61
213
4.15 DigiCert CertCentral .................................................................................................... 61
214
5 Enterprise 4 Build 1 (EIG E4B1) Product Guides .................................. 61
215
6 Enterprise 1 Build 2 (EIG E1B2) Product Guides .................................. 61
216
6.1 Zscaler .......................................................................................................................... 62
217
6.1.1 Zscaler ZPA Configuration and Integration ................................................................ 62
218
6.1.2 Zscaler ZIA Configuration............................................................................................ 63
219
6.1.3 Zscaler Client Connector ............................................................................................. 63
220
6.1.4 Zscaler Application Connector .................................................................................... 63
221
6.2 Okta Identity Cloud ..................................................................................................... 63
222
6.3 Radiant Logic RadiantOne ........................................................................................... 63
223
6.4 SailPoint IdentityIQ ...................................................................................................... 64
224
6.5 Ivanti Neurons for UEM ............................................................................................... 64
225
6.6 IBM Security QRadar XDR ............................................................................................ 64
226
6.7 Tenable.io .................................................................................................................... 64
227
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture xv
6.8 Tenable.ad ................................................................................................................... 64
228
6.9 Tenable NNM............................................................................................................... 64
229
6.10 Mandiant Security Validation (MSV) ........................................................................... 64
230
6.11 DigiCert CertCentral .................................................................................................... 64
231
6.12 AWS IaaS ...................................................................................................................... 64
232
6.12.1 Configuration .............................................................................................................. 65
233
7 Enterprise 3 Build 2 (EIG E3B2) Product Guides .................................. 65
234
7.1 Microsoft Azure Active Directory (AD) ........................................................................ 65
235
7.2 Microsoft Azure AD Identity Protection ...................................................................... 65
236
7.3 Microsoft Azure AD Identity Governance ................................................................... 66
237
7.4 Microsoft Intune .......................................................................................................... 66
238
7.5 Microsoft Defender for Endpoint ................................................................................ 66
239
7.6 Microsoft Defender for Cloud Apps ............................................................................ 66
240
7.7 Microsoft Azure AD Application Proxy ........................................................................ 67
241
7.8 Microsoft Defender for Cloud ..................................................................................... 67
242
7.9 Microsoft Sentinel ....................................................................................................... 68
243
7.10 Microsoft Office 365 .................................................................................................... 68
244
7.11 F5 BIG-IP ...................................................................................................................... 68
245
7.12 PC Matic Pro ................................................................................................................ 68
246
7.13 Tenable.io .................................................................................................................... 68
247
7.14 Tenable.ad ................................................................................................................... 68
248
7.15 Tenable NNM............................................................................................................... 68
249
7.16 Mandiant Security Validation (MSV) ........................................................................... 68
250
7.17 Forescout eyeSight ...................................................................................................... 68
251
7.18 Forescout eyeControl .................................................................................................. 68
252
7.18.1 Configuring a policy .................................................................................................... 69
253
7.19 Forescout eyeSegment ................................................................................................ 69
254
7.19.1 Access the eyeSegment Dashboard ........................................................................... 69
255
7.20 Forescout eyeExtend ................................................................................................... 69
256
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture xvi
7.20.1 Integration with Microsoft Endpoint Manager .......................................................... 70
257
7.21 Palo Alto Next Generation Firewall ............................................................................. 70
258
7.22 DigiCert CertCentral .................................................................................................... 70
259
7.23 Microsoft Azure IaaS ................................................................................................... 70
260
Appendix A List of Acronyms ................................................................. 72
261
List of Figures
262
Figure 1-1 Laboratory Infrastructure for the EIG Builds ........................................................................6
263
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 1
1 Introduction
264
The following volume of this guide shows information technology (IT) professionals and security
265
engineers how we implemented five example zero trust architecture (ZTA) solutions. We cover all of the
266
products employed in this reference design.
267
Note: This is not comprehensive documentation. There are many possible service and security
268
configurations for these products that are out of scope for these demonstrations.
269
1.1 How to Use this Guide
270
This NIST Cybersecurity Practice Guide will help users develop a plan for migrating to ZTA. It
271
demonstrates a standards-based reference design for implementing a ZTA and provides users with the
272
information they need to replicate five different implementations of this reference design. Each of these
273
implementations, which are known as builds, are standards-based and align to the concepts and
274
principles in NIST Special Publication (SP) 800-207, Zero Trust Architecture. The reference design
275
described in this practice guide is modular and can be deployed in whole or in part, enabling
276
organizations to incorporate ZTA into their legacy environments gradually, in a process of continuous
277
improvement that brings them closer and closer to achieving the ZTA goals that they have prioritized
278
based on risk, cost, and resources.
279
NIST is adopting an agile process to publish this content. Each volume is being made available as soon as
280
possible rather than delaying release until all volumes are completed. Work continues on implementing
281
the example solutions and developing other parts of the content. As a second preliminary draft, we will
282
publish at least one additional draft for public comment before it is finalized.
283
When complete, this guide will contain five volumes:
284
▪ NIST SP 1800-35A: Executive Summary – why we wrote this guide, the challenge we address,
285
why it could be important to your organization, and our approach to solving this challenge
286
▪ NIST SP 1800-35B: Approach, Architecture, and Security Characteristics – what we built and why
287
▪ NIST SP 1800-35C: How-To Guides – instructions for building the example implementations,
288
including all the security-relevant details that would allow you to replicate all or parts of this
289
project (you are here)
290
▪ NIST SP 1800-35D: Functional Demonstrations – use cases that have been defined to showcase
291
ZTA security capabilities and the results of demonstrating them with each of the example
292
implementations
293
▪ NIST SP 1800-35E: Risk and Compliance Management– risk analysis and mapping of ZTA security
294
characteristics to cybersecurity standards and recommended practices
295
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 2
Depending on your role in your organization, you might use this guide in different ways:
296
Business decision makers, including chief security and technology officers, will be interested in the
297
Executive Summary, NIST SP 1800-35A, which describes the following topics:
298
▪ challenges that enterprises face in migrating to the use of ZTA
299
▪ example solution built at the National Cybersecurity Center of Excellence (NCCoE)
300
▪ benefits of adopting the example solution
301
Technology or security program managers who are concerned with how to identify, understand, assess,
302
and mitigate risk will be interested in this part of the guide, NIST SP 1800-35B, which describes what we
303
did and why.
304
Also, Section 3 of Risk and Compliance Management, NIST SP 1800-35E, will be of particular interest.
305
Section 3, ZTA Reference Architecture Security Mappings, maps logical components of the general ZTA
306
reference design to security characteristics listed in various cybersecurity guidelines and recommended
307
practices documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST
308
Cybersecurity Framework), Security and Privacy Controls for Information Systems and Organizations
309
(NIST SP 800-53), and Security Measures for “EO-Critical Software” Use Under Executive Order (EO)
310
14028.
311
You might share the Executive Summary, NIST SP 1800-35A, with your leadership team members to help
312
them understand the importance of migrating toward standards-based ZTA implementations that align
313
to the concepts and principles in NIST SP 800-207, Zero Trust Architecture.
314
IT professionals who want to implement similar solutions will find the whole practice guide useful. You
315
can use the how-to portion of the guide, NIST SP 1800-35C, to replicate all or parts of the builds created
316
in our lab. The how-to portion of the guide provides specific product installation, configuration, and
317
integration instructions for implementing the example solutions. We do not re-create the product
318
manufacturers’ documentation, which is generally widely available. Rather, we show how we
319
incorporated the products together in our environment to create an example solution. Also, you can use
320
Functional Demonstrations, NIST SP 1800-35D, which provides the use cases that have been defined to
321
showcase ZTA security capabilities and the results of demonstrating them with each of the example
322
implementations.
323
This guide assumes that IT professionals have experience implementing security products within the
324
enterprise. While we have used a suite of commercial products to address this challenge, this guide does
325
not endorse these particular products. Your organization can adopt this solution or one that adheres to
326
these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing
327
parts of a ZTA. Your organization’s security experts should identify the products that will best integrate
328
with your existing tools and IT system infrastructure. We hope that you will seek products that are
329
congruent with applicable standards and best practices.
330
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 3
A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. This is a
331
second preliminary draft guide. As the project progresses, the second preliminary draft will be updated,
332
and additional volumes will also be released for comment. We seek feedback on the publication’s
333
contents and welcome your input. Comments, suggestions, and success stories will improve subsequent
334
versions of this guide. Please contribute your thoughts to [email protected].
335
1.2 Build Overview
336
This NIST Cybersecurity Practice Guide addresses the challenge of using standards-based protocols and
337
available technologies to build a ZTA. In our lab at the NCCoE and using our collaborator’s cloud
338
infrastructure, we plan to implement and demonstrate a variety of builds that serve as example ZTA
339
solutions, each of which is designed to dynamically and securely manage access to resources across a set
340
of use cases that a medium or large enterprise might typically deploy. Our plan is to implement these
341
builds in a series of phases, starting with a baseline enterprise architecture that represents the typical
342
legacy components that an enterprise might start with when deciding to begin adding zero trust
343
capabilities.
344
We began with builds for enhanced identity governance (EIG) that were restricted to a limited set of
345
capabilities. We call these EIG crawl phase builds. The central capabilities of these builds are identity,
346
credential, and access management (ICAM) and endpoint protection. In particular, these EIG crawl
347
phase builds do not include the separate, centralized policy engine (PE) or policy administration (PA)
348
components. Instead, these initial EIG crawl phase builds rely upon the PE and PA capabilities provided
349
by their ICAM components. We did not perform an EIG walk phase. After completing the EIG crawl
350
phase builds, we enhanced these implementations by adding specialized PE and PA components, device
351
discovery, and cloud-based resources in the EIG run phase. In future phases, we plan to introduce
352
capabilities such as software-defined perimeter and micro-segmentation.
353
This practice guide provides instructions for reproducing the builds that we have implemented so far:
354
▪ EIG crawl phase builds:
355
• EIG Enterprise 1 Build 1 (E1B1)
356
• EIG Enterprise 2 Build 1 (E2B1)
357
• EIG Enterprise 3 Build 1 (E3B1)
358
▪ EIG run phase builds:
359
• EIG Enterprise 1 Build 2 (E1B2)
360
• EIG Enterprise 3 Build 2 (E3B2)
361
The NCCoE worked with members of the ZTA community of interest to develop a diverse but non-
362
comprehensive set of use cases and scenarios to demonstrate the capabilities of the builds. The use
363
cases are summarized in NIST SP 1800-35D, Functional Demonstrations.
364
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 4
1.2.1 EIG Crawl Phase Build Features
365
A general ZTA reference design is depicted in Figure 4-1 of Volume B. It consists of ZTA core
366
components: a policy decision point (PDP), which includes both a PE and a PA, and one or more policy
367
enforcement points (PEPs); and ZTA functional components for ICAM, security analytics, data security,
368
and endpoint security. The EIG crawl phase builds that have been created so far differ from this
369
reference design insofar as they do not include separate, dedicated PDP components. Their ICAM
370
component serves as their PDP, and they include very limited data security and security analytics
371
functionality. These limitations were intentionally placed on the initial builds in an attempt to
372
demonstrate the ZTA functionality that an enterprise that currently has ICAM and endpoint protection
373
solutions deployed will be able to support without having to add additional ZTA-specific capabilities.
374
Each EIG crawl phase build is instantiated in a unique way, depending on the equipment used and the
375
capabilities supported. Briefly, the three builds are as follows:
376
▪ E1B1 uses products from IBM, Ivanti, Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and
377
Zimperium. Certificates from DigiCert are also used.
378
▪ E2B1 uses products from Cisco Systems, IBM, Mandiant, Palo Alto Networks, Ping Identity,
379
Radiant Logic, SailPoint, and Tenable. Certificates from DigiCert are also used.
380
▪ E3B1 uses products from F5, Forescout, Lookout, Mandiant, Microsoft, Palo Alto Networks, PC
381
Matic, and Tenable. Certificates from DigiCert are also used.
382
1.2.2 EIG Run Phase Build Features
383
The EIG run phase, as its name suggests, builds upon the EIG crawl phase architecture. The EIG run
384
phase no longer imposes the requirement that the PE and PA components must be provided by the
385
ICAM products used in the build. It also adds capabilities to the EIG crawl phase. In addition to
386
protecting access to resources that are located on-premises, the run phase also protects access to some
387
resources that are hosted in the cloud. The EIG run phase includes a device discovery capability, which is
388
performed as part of the baseline. In addition to monitoring and alerting when new devices are
389
detected, enforcement can be enabled to deny access to devices that are not compliant. The run phase
390
also includes the capability to establish a tunnel between the requesting endpoint and the resource
391
being accessed over which access to the resource can be brokered.
392
Each EIG run phase build is instantiated in a unique way, depending on the equipment used and the
393
capabilities supported. Briefly, the two builds are as follows:
394
▪ E1B2 uses products from Amazon Web Services, IBM, Ivanti, Mandiant, Okta, Radiant Logic,
395
SailPoint, Tenable, and Zscaler. Certificates from DigiCert are also used.
396
▪ E3B2 uses products from F5, Forescout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, and
397
Tenable. Certificates from DigiCert are also used.
398
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 5
1.2.3 Physical Architecture Overview
399
The laboratory environment in which the builds have been implemented is depicted and described in
400
detail in Section 4.3 of Volume B. The laboratory architecture drawing from that volume is reproduced
401
here in Figure 1-1. As shown, this laboratory environment includes three separate enterprise
402
environments, each hosting its own distinct implementation of a ZTA architecture. The enterprises may
403
interoperate as needed by a given use case, and the baseline enterprise environments have the
404
flexibility to support enhancements. The laboratory environment also includes a management virtual
405
local area network (VLAN) on which the following components are installed: Ansible, Terraform, MSV
406
Director, and MSV Protected Theater. These management components support infrastructure as code
407
(IaC) automation and orchestration.
408
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 6
Figure 1-1 Laboratory Infrastructure for the EIG Builds
409
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 7
The following EIG phase builds are supported within the physical architecture depicted in Figure 1-1 and
410
documented in the remainder of this guide:
411
▪ EIG E1B1 components consist of DigiCert CertCentral, IBM Cloud Pak for Security, IBM Security
412
QRadar XDR, Ivanti Access ZSO, Ivanti Neurons for UEM, Ivanti Sentry, Ivanti Tunnel, Mandiant
413
Security Validation (MSV), Okta Identity Cloud, Okta Verify App, Radiant Logic RadiantOne
414
Intelligent Identity Data Platform, SailPoint IdentityIQ, Tenable.ad, Tenable.io, and Zimperium
415
MTD.
416
▪ EIG E2B1 components consist of Cisco Duo, DigiCert CertCentral, IBM Security QRadar XDR,
417
Mandiant MSV, Palo Alto Networks Next Generation Firewall (NGFW), PingFederate, which is a
418
service in the Ping Identity Software as a Service (SaaS) offering of PingOne, Radiant Logic
419
RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Tenable.ad, Tenable.io, and
420
Tenable Nessus Network Monitor (NNM).
421
▪ EIG E3B1 components consist of DigiCert CertCentral, F5 BIG-IP, Forescout eyeSight, Lookout
422
MES, Mandiant MSV, Microsoft Azure AD, Microsoft Defender for Endpoint, Microsoft Endpoint
423
Manager, Microsoft Sentinel, Palo Alto Networks NGFW, PC Matic Pro, Tenable.ad, and
424
Tenable.io.
425
▪ EIG E1B2 components consist of AWS Infrastructure as a Service (IaaS), DigiCert CertCentral, IBM
426
Cloud Pak for Security, IBM Security QRadar XDR, Mandiant MSV, Okta Identity Cloud, Okta
427
Verify App, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ,
428
Tenable.ad, Tenable.io, Tenable NNM, Zscaler Admin Portal, Zscaler Application Connector,
429
Zscaler Central Authority, Zscaler Client Connector, Zscaler Internet Access (ZIA) Public Service
430
Edges, and Zscaler Private Access (ZPA) Public Service Edges.
431
▪ EIG E3B2 components consist of DigiCert CertCentral, F5 BIG-IP, Forescout eyeControl,
432
Forescout eyeExtend, Forescout eyeSegment, Forescout eyeSight, Mandiant MSV, Microsoft AD,
433
Microsoft Azure AD, Microsoft Azure AD (Conditional Access), Microsoft Azure AD Identity
434
Protection, Microsoft Azure (IaaS), Microsoft Defender for Cloud, Microsoft Defender for Cloud
435
Apps, Microsoft Defender for Endpoint, Microsoft Intune, Microsoft Office 365 (SaaS), Microsoft
436
Sentinel, Palo Alto Networks NGFW, PC Matic Pro, Tenable.ad, Tenable.io, and Tenable NNM.
437
For a detailed description of the architecture of each build, see Volume B, Appendices D, E, F, H and J.
438
The remainder of this guide describes how to implement the EIG crawl and run phase builds E1B1, E2B1,
439
E3B1, E1B2, and E3B2.
440
1.3 Typographic Conventions
441
The following table presents typographic conventions used in this volume.
442
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 8
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.
2 Enterprise 1 Build 1 (EIG E1B1) Technology Guides
443
This section of the practice guide contains detailed instructions for installing, configuring, and
444
integrating all of the products used to implement EIG E1B1. For additional details on EIG E1B1’s logical
445
and physical architectures, please refer to Volume B.
446
2.1 Okta Identity Cloud
447
The Okta Identity Cloud is a SaaS solution that provide ICAM capabilities to an enterprise. The following
448
sections describe the setup of the Okta Identity Cloud, the Okta Access Gateway, and the Okta Verify
449
application. Okta integrates with Radiant Logic for identity information, SailPoint to receive governance
450
information, and Ivanti to delegate authentication for users accessing resources using mobile devices.
451
2.1.1 Configuration and Integration
452
The purpose of this subsection is to set up NCCoE’s own instance of the Okta cloud so it can integrate
453
with other ICAM tools so Okta can manage authentication and authorization of users accessing
454
resources. Most configurations are completed within this instance of the Okta cloud.
455
1. Sign up for an account with Okta (okta.com) and follow steps to set up an admin account, along
456
with configuring Okta Verify for the admin account. This will allow the admin to start configuring
457
integrations and services.
458
2. Set up directory integration with Radiant Logic. User identity information is pulled from Radiant
459
Logic into Okta for authentication and authorization. An Okta LDAP agent is installed on the
460
Radiant Logic server for integration. Note: This step should be completed after Radiant Logic is
461
configured.
462
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 9
3. Create Groups for Okta to apply a specific set of users to specific services or applications. This
463
allows for automation of user governance at a large scale rather than manual configuration of
464
individual users.
465
4. Create API tokens to be used by SailPoint and Radiant Logic for communication. These tokens
466
will allow Okta to give specific read/write privileges to other applications.
467
5. Create a delegated authentication for Okta to be able to import users from Radiant Logic via
468
LDAP. This allows Okta to delegate the actual authentication to Radiant Logic. Okta does not
469
store or know the password of the user. Note that a service account, created in the Radiant
470
Logic Integration section of this document, needs to be created and used in this configuration.
471
6. Create application integration via Security Assertion Markup Language (SAML). We have Ivanti
472
Neurons for UEM and 2 GitLab instances in Enterprise 1. Okta Access Gateway (AG) needs to be
473
installed in order to configure on-premises applications. The Okta AG gives the Okta Identity
474
Cloud visibility to the resources inside the enterprise. See Section 2.1.3 for installation
475
instructions, which include information on configuring on-premises applications.
476
7. Create Identity Provider integration for Ivanti Access ZSO. This will allow delegated
477
authentication for Ivanti for mobile devices. This involves creating a custom application using
478
SAML and then creating a SAML Identity Provider.
479
8. Configure Device Trust on iOS and Android devices to create device integrations.
480
9. Create authentication policies. These policies define how users will authenticate. By default, a
481
“Catch All” policy is created when an application is created. We are creating an authentication
482
policy that will allow Okta to trust Ivanti Access ZSO to be the delegated Identity Provider (IdP).
483
To do this, when Okta checks that Okta Verify is a managed application on a device, it will
484
delegate authentication to Ivanti Access ZSO.
485
2.1.2 Okta Verify App
486
The Okta Verify app is installed, usually on a mobile device, when a new user is onboarded. It serves as a
487
tool to provide a second factor for authentication. The user can log in to the Okta Identity Cloud for the
488
first time. For this setup, the user will be asked to change their password and perform setup. After the
489
password update, the user can set up Okta Verify. Follow the instructions for Android or iOS devices to
490
install Okta Verify and complete the process.
491
2.1.3 Okta Access Gateway
492
The Okta Access Gateway (AG) is part of the Okta Identity Cloud. It can be leveraged to integrate legacy,
493
on-prem applications into the Okta Identity Cloud. Since the Okta Identity Cloud cannot communicate
494
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 10
with Enterprise 1 resources directly, the Okta AG acts as a proxy to facilitate that communication. More
495
information on installing and configuring the Okta AG is available online.
496
2.2 Radiant Logic RadiantOne
497
Radiant Logic RadiantOne is an ICAM solution that unifies identity data, making access reusable and
498
scalable for the enterprise.
499
2.2.1 Installation
500
RadiantOne is to be installed on a Microsoft Windows 2019 server. See the RadiantOne v7.4.1
501
documentation from the Radiant Logic website for system specifications. Prerequisites are in Chapter 1
502
of the RadiantOne Installation Guide. Note: You need to create an account within the Radiant Logic
503
website in order to access the installation and configuration documentation.
504
Once you download and launch the executable for a Windows server installation, follow the step-by-
505
step instructions provided on the screen. We used default settings unless specified below. Instructions
506
can also be found in Chapter 2 of the RadiantOne Installation Guide.
507
▪ Choose RadiantOne Federated Identity Suite New Cluster/Standalone for the Install Set.
508
▪ Provide a name and password for the Cluster settings.
509
▪ For the Server Configuration step, use the following ports: LDAP = 389, LDAPS = 636, and
510
Scheduler Port = 1099.
511
2.2.2 Configuration
512
2.2.2.1 Sync with an LDAP server
513
1. Once installation is complete, log in to RadiantOne from a web browser on the Radiant Logic
514
server, https://localhost:7171. Note: ensure the proper SSL certificate is on the server for
515
HTTPS.
516
2. Initial configuration is to sync up with an LDAP server. Go to Settings > Server Backend > LDAP
517
Data Sources. The screenshot below shows the information created for Enterprise 1 AD. See the
518
RadiantOne Namespace Configuration Guide Chapter 3 for details.
519
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 11
3. Once the connection is tested and successful, the integration is completed.
520
4. Next, create a Directory Namespace by going to Directory Namespace and selecting Create New
521
Naming Context. Click Next and click OK.
522
5. Find DC=NCCOE,DC=ORG under Root Naming Contexts on the left side of the screen. Click the
523
New Level button. Enter ent1 as the name for the OU and click OK.
524
6. Click on ou=ent1 on the left side and click the New Level button on the right to create a sub-ou
525
called groups.
526
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 12
7. Click on ou=ent1 on the left side as shown below and click the New Level button on the right to
527
create a sub-ou called users.
528
8. Once configured and saved, click on ou=users and click on Backend Mapping on the right. Select
529
LDAP Backend. Click Next and Browse for the proper Remote Base DN. Then click OK. The
530
screenshot is the completed configuration for the sub-ou users Proxy Backend.
531
9. Go to Objects and create a primary object and Join Profile by clicking Add on each. Click Save.
532
Now we have data sources from LDAP and our database.
533
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 13
2.2.2.2 Create a namespace to bring in users
534
1. In Directory Namespace, click the + sign. Create a naming context:
535
ou=hr,ou=lab,ou=nccoe,ou=org and select Virtual Tree for the naming context type, then click
536
Next.
537
2. Configure the Virtual Tree by choosing Create a new view (.dvx), setting the Directory View to
538
dv=ou_hr_ou_lab_ou_nccoe_ou_org and clicking OK.
539
3. Next, create a sub-Namespace by clicking the + New level button and entering the information
540
depicted below.
541
4. Click on the sub-Namespace that was just created and click on Backend Mapping. Specify
542
ou=east,ou=hr,ou=lab,ou=nccoe,ou=org as the naming context and select HDAP Store as the
543
type, then click Next. Note: Instead of having an actual HR database, we are importing sample
544
users from a text file.
545
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 14
5. Click on ou=east to edit properties. Scroll down to the bottom of the screen and click on the
546
Initialize button. Then select a file with database users to import for initializing the HDAP store.
547
Note: We are emulating an HR database with this file.
548
6. Go to the Directory Browser tab and refresh the data by clicking the Refresh Tree button.
549
7. Go to the OU that you just configured and expand it. The new users should now be available.
550
8. Go to Directory Namespace and click the + button to add new naming context (in our build, we
551
used ou=testing). This is used to map to the LDAP backend the database information that was
552
imported.
553
9. Click on the OU that was created. Click OK and Save.
554
10. Go to Directory Browser and hit the Refresh button.
555
11. Go to Settings > Configuration > ORX Schema, and find OU=Testing and check it. Click on
556
Generate LDAP Schema at the bottom of the screen and click OK.
557
2.2.3 Integration
558
Other applications, including SailPoint and Okta, will need the following information in order to
559
integrate with Radiant Logic and pull information from it:
560
▪ Hostname: radiant1.lab.nccoe.org (hostname of the Radiant Logic server)
561
▪ Port: 389 (LDAP) and 636 (LDAPS)
562
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 15
Also, a service account and password need to be created on Radiant Logic for each application to be
563
integrated. The service account is in the form of: uid=sailpointadmin,ou=globalusers,cn=config.
564
Follow these steps to create each service account for SailPoint, Okta, and any other desired applications:
565
1. Go to Directory Browser.
566
2. On the left, go to cn=config, then ou=globalusers underneath it. Right-click on ou=globalusers,
567
click Add, then click New InetOrgPerson.
568
3. Fill in the necessary entries. Click Confirm to save the configuration.
569
2.3 SailPoint IdentityIQ
570
SailPoint IdentityIQ is the identity and access management software platform for governing the lifecycle
571
of the enterprise user’s identity.
572
2.3.1 Installation and Configuration
573
The steps below explain the installation of the IdentityIQ server, initial configuration to import users
574
from the Radiant Logic identity store, and configuration to manage the lifecycle of users.
575
1. To install IdentityIQ, first identify the platform and prerequisites. For this build, we used
576
Windows 2019 with Apache Tomcat 9.0 and MS SQL Server 2019 as recommended
577
requirements for release 8.2. Download the installation file from the SailPoint website and
578
follow the installation instructions.
579
2. Login into IdentityIQ from a web browser (http://localhost:8080) using the default login and
580
password identified in the IdentityIQ Installation Guide. Make sure to change the default
581
password by following the instructions provided in the Guide.
582
3. Configure IQService. This is needed in order to set up integration with AD.
583
4. Govern permissions by pushing both employee and contractor users and groups to AD and Okta.
584
Note: This step should be completed after the integration with AD and Okta is completed. Steps
585
to configure integration are in Sections 2.3.3 and 2.3.4. After integration with AD and Okta is
586
completed, navigate to the Setup drop-down menu and select Roles. Here we will create a
587
birthright role and access profile for employees and contractors.
588
a. Select New Role drop-down button and select Role. The screenshot lists the four roles
589
that are created for this build.
590
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 16
b. For the Employee Birthright Role, use the configuration shown in the next two
591
screenshots. Note that the Assignment Rule is where the value of employee is used to
592
identify the users. This will push users into AD as a birthright. Once that role is
593
configured, configure the corresponding contractor role the same way. Note that the
594
Assignment Rule should be different for the contractor based on user information in
595
SailPoint.
596
c. For the Employee Access Profile role, add the groups that the employees belong to. This
597
means that these users will have access to these groups as a birthright. Perform the
598
same for the corresponding contractor role. Note that the Entitlements should be
599
different for the contractor based on group information in Okta and AD.
600
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 17
601
5. The next step is to synchronize users and groups. To begin, navigate to the Setup tab and select
602
Tasks.
603
a. To create user aggregation, select the New Task drop down button and select Account
604
Aggregation. The screenshot below depicts the aggregation configuration for Radiant
605
Logic. This allows SailPoint to sync with Radiant Logic on any updates made to users.
606
Repeat this step for AD and Okta accounts. Note that the Account Aggregation Options
607
section is where the AD and Okta applications need to be selected to create the proper
608
account aggregation.
609
b. To create group aggregation, select the New Task drop down button and select Account
610
Aggregation. This allows SailPoint to sync with AD on any updates made to users.
611
Repeat this step for the Okta account. Note that the Account Group Aggregation
612
Options section is where the Okta applications need to be selected to create the proper
613
account aggregation.
614
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 18
6. Configure lifecycle processes through Rapid Setup Configuration. Click on the Setup cog and
615
select Rapid Setup to begin. The Rapid Setup Configuration process allows onboarding of
616
applications and manage functions such as joiner, mover, and leaver of identities. Use the
617
“Using Rapid Setup” section of the IdentityIQ Rapid Setup Guide to guide the configuration.
618
a. Configure Joiner, Mover, and Leaver.
619
b. Configure Identity Operations.
620
c. Configure Rapid Setup specific to AD users: Aggregation, Joiner, Mover, and Leaver.
621
7. Govern user permissions to applications on an individual basis. Configure procedures to
622
provision and approve user access to resources. For Enterprise 1, the process is for an
623
administrator or user to request approval to access an application. That request goes to the
624
user’s manager for review and approval. Once the manager approves the request, SailPoint kicks
625
off an API call to Okta to configure access for that user.
626
2.3.2 Integration with Radiant Logic
627
1. In the Applications tab, select Application Definition. When the screen comes up, click on the
628
Add New Application button.
629
2. Enter values for the Name (e.g., “Ent1-HR”) and Owner (e.g., “The Administrator”) fields. Select
630
LDAP as the Application Type and ensure that Authoritative Application is enabled.
631
3. Click on the Configuration tab next to the current tab. The credentials that were created in
632
Radiant Logic will need to be added.
633
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 19
4. Scroll down the screen and under the Account tab, add the Search DN, which is the one created
634
from Radiant Logic.
635
5. Click on Test Connection to make sure that SailPoint is able to connect to Radiant Logic. Click
636
Save.
637
6. You can go back into the Configuration tab and Schema sub-tab. Toward the bottom of the
638
screen, there is a Preview button. You can click on that to preview the imported attributes.
639
Note: We manually added schema attributes. This can be completed from Radiant Logic and
640
imported. Please ensure that you have the correct attributes to integrate this.
641
7. To complete the setup, click Save to finish and import users from Radiant Logic.
642
8. Go to the Setup tab and click Tasks. Once in the new tab, click on the New Task button at the
643
top right corner to create the account aggregation for Radiant Logic.
644
9. Perform identity attribute mapping. The screenshot shows mappings specific to this build only.
645
2.3.3 Integration with AD
646
1. Navigate to the Applications tab, click on Application Definition, then click the Add New
647
Application button. Fill out the Name (e.g., “Ent1-AD-Ent-Users”), Owner (e.g., “The
648
Administrator”), and Application Type (“Active Directory – Direct”).
649
2. Navigate to the Configuration tab. From here, input information for the IQ Service Host. The IP
650
address is this server, the IdentityIQ server. IQ Service User is a user that was created in AD for
651
this integration.
652
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 20
3. Scroll down to the Domain Configuration section. Input the domain information for where the
653
users will be provisioned.
654
4. Scroll down to the User Search Scope section and input the Search DN information. This should
655
be the AD domain location for your enterprise.
656
5. Navigate to the Schema and Provisioning Policies sub-tabs, and update information as
657
necessary.
658
6. Then navigate to the Correlation tab to configure the correlation for application and identity
659
attributes between SailPoint and AD.
660
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 21
7. Click Save to complete the configuration.
661
8. Go to Setup tab and click Tasks. Once in the new tab, click on the New Task button at the top
662
right corner to create the account aggregation for AD.
663
2.3.4 Integration with Okta
664
1. Go into the Applications tab and select Application Definition. When the screen comes up, click
665
on the Add New Application button.
666
2. Fill out the Name (e.g., “Ent1-Okta”) and Owner (“The Administrator”), select Okta as the
667
Application Type, and enable the Authoritative Application option.
668
3. In the Configuration settings tab, the Okta URL and API token are needed. Note that the API
669
token is created in Okta. Click Save to finish the setup.
670
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 22
2.4 Ivanti Neurons for UEM
671
Ivanti Neurons for UEM is a unified endpoint management (UEM) solution which is used to provision
672
endpoints, grant access to enterprise resources, protect data, distribute applications, and enforce
673
measures as required.
674
2.4.1 Installation and Configuration
675
2.4.1.1 Install an MDM certificate for Apple devices
676
The Apple Push Notification service (APNs) certificate needs to be installed in Ivanti Neurons for UEM to
677
communicate with Apple devices. Apple devices use an APNs certificate to learn about updates, MDM
678
policies, and incoming messages.
679
To acquire and install the MDM certificate:
680
1. Open the Ivanti Neurons for UEM console and go to Admin > Apple > MDM Certificate page to
681
download a certificate signing request (CSR).
682
2. Upload the CSR to the Apple Push Certificates Portal to create a new certificate.
683
3. Save the resulting certificate.
684
4. Install the certificate for the Ivanti Neurons for UEM tenant.
685
2.4.1.2 Configure Android Enterprise
686
Android Enterprise allows personal and corporate applications on the same Android device. Android
687
Enterprise configuration depends on the type of Google subscription. Please follow Ivanti
688
documentation to set up the integration.
689
The Android Enterprise Work Profile configuration defines which features and apps are allowed, and
690
which are restricted on Android enterprise devices. Do the following to configure the profile:
691
1. In the Cloud portal, go to Configurations and click Add.
692
2. Select the Lockdown & Kiosk: Android Enterprise configuration.
693
3. Enter a configuration name and description.
694
4. Click the Work Profile lockdown type.
695
5. Select the lockdown settings for Android devices.
696
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 23
2.4.1.3 Add a certificate authority
697
A certificate authority (CA) generates self-signed certificates to be used by the devices that Ivanti
698
Neurons for UEM manages. For this implementation we used an external certificate authority (DigiCert)
699
and a Connector to access it. Ivanti Cloud Connector provides access from the Ivanti Neurons for UEM
700
service to corporate resources, such as an LDAP server or CA.
701
1. Install and configure a Connector (Admin > Connector).
702
2. In the Certificate Management page, click Add under the Certificate Authority section.
703
3. Choose Connect to a publicly-trusted Cloud Certificate Authority.
704
4. Enter a name for the CA.
705
5. Download the certificate from DigiCert and upload it to Ivanti Neurons for UEM.
706
2.4.1.4 Configure user settings
707
User settings define device registration options. Access them by opening Ivanti Neurons for UEM and
708
going to Users > User Settings. Configure device and password settings there.
709
2.4.1.5 Add a policy
710
Policies define requirements for devices and compliance actions (what happens if the rule is violated).
711
To add a policy:
712
1. Go to Policies and click +Add (upper right).
713
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 24
2. Select a policy type and complete the settings. Policy types include Compromised Devices, Data
714
Protection/Encryption Disabled, MDM/Device Administration Disabled, Out of Contact, and
715
Allowed Apps.
716
3. Select the device groups that will receive this policy.
717
The following screenshots show an example of a Data Protection policy to be distributed to a custom
718
group of devices.
719
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 25
2.4.1.6 Add a configuration for managed devices
720
Configurations are collections of settings that Ivanti Neurons for UEM sends to devices. To add a
721
configuration:
722
1. Click Add.
723
2. Select the type of configuration. There are numerous types of configurations available, including
724
Privacy, Certificate, Default App Runtime Permissions, Passcode, Exchange, Wi-Fi, VPN,
725
iOS/macOS/Windows Restrictions, and Software Updates.
726
3. Click Next.
727
4. Select a distribution level for the configuration.
728
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 26
Here is an example of a Privacy configuration:
729
This is an example of an iOS AppConnect configuration:
730
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 27
This screenshot shows a list of configurations pushed to a device:
731
2.4.2 Integration with Ivanti Connector
732
Ivanti Connector provides access from Ivanti Neurons for UEM to corporate resources, such as an LDAP
733
server. For the latest Connector installation instructions, select the appropriate version of the Cloud
734
Connector Guide.
735
1. Once the Ivanti Connector has been set up and configured, navigate to the Ivanti Neurons for
736
UEM console.
737
2. Connect to an LDAP Server to import users and groups. Navigate to Admin > Infrastructure >
738
LDAP > Add Server. Complete configurations and save. Users can now be imported from the
739
LDAP server.
740
2.4.3 Integration with Okta
741
2.4.3.1 IdP setup
742
1. Go to Admin > Infrastructure > Identity > Add IdP.
743
2. Generate a key for uploading to Okta IdP.
744
3. Log in to Okta IdP. Search IdP for the MobileIron Cloud App and add it to the IdP account.
745
4. Configure the MobileIron Cloud App on the IdP by pasting the above-generated key and the
746
host information.
747
5. Export metadata from Okta to the Ivanti Neurons for UEM console.
748
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 28
6. In Admin > Infrastructure > Identity > Add IdP, select Choose File to import the downloaded
749
metadata file to Ivanti Neurons for UEM and complete the setup.
750
7. When an IdP is added, user authentication automatically switches from LDAP to IdP.
751
2.4.3.2 Okta Verify app configuration preparation
752
1. In the Okta Admin console, navigate to Security > Device Integrations and click Add Platform.
753
2. Select platform and click Next.
754
3. Copy the Secret Key for later usage and enter Device Management Provider and Enrollment Link
755
settings.
756
4. Repeat for any other device platforms.
757
2.4.3.3 Okta Verify app configuration - Android
758
1. In the Ivanti Neurons for UEM console, navigate to Apps > App Catalog. Click Add.
759
2. Select the Google Play Store and search for Okta Verify. Select the official Okta Verify app.
760
3. Continue through the wizard until you reach the App Configurations page. Click the + button in
761
the Managed Configurations for Android section.
762
4. Add desired settings. Under Managed Configurations, add the Org URL and Management Hint
763
from the Okta Admin console. The Management hint will be the Secret Key you saved from the
764
Okta console during preparation.
765
5. Click Next, then click Done.
766
2.4.3.4 Okta Verify app configuration - iOS
767
1. In the Ivanti Neurons for UEM console, navigate to Apps > App Catalog. Click Add.
768
2. Select the iOS Store and search for Okta Verify. Select the official Okta Verify app.
769
3. Continue through the wizard until you reach the App Configurations page. Click the + button in
770
the Apple Managed App Configuration section.
771
4. Add desired settings. Under Apple Managed App Settings, click Add and add two items.
772
a. For the first item, the key will be domainName, the value will be your Org URL, and the
773
type will be STRING.
774
b. For the second item, the key will be managementHint, the value will be the Secret Key
775
you saved from the Okta console during preparation, and the type will be STRING.
776
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 29
5. Click Next, then click Done.
777
2.4.4 Integration with QRadar
778
2.4.4.1 Ivanti log transfer setup
779
1. Set up an SSH server to host log files. Create a user account that can be used to host/transfer
780
Ivanti Log Files.
781
2. In the Ivanti Neurons for UEM console, navigate to Admin > Infrastructure > Audit Trails.
782
3. Turn on Audit Trails Export and Device Check-in Trails.
783
4. Under Export Format, select CEF.
784
5. Enter the IP address or hostname for the SSH server you set up previously.
785
6. Enter the username and password for the user you set up previously.
786
7. Enter the server path for where you would like the Ivanti log files to be stored on the SSH server.
787
8. Click Test Connection and Save. Ivanti log files will now be transferred to the SSH server on a
788
regular basis.
789
2.4.4.2 QRadar setup
790
1. In the QRadar console, navigate to Admin > Extensions Management. Click Add.
791
2. Select the Ivanti extension file provided by IBM. Click Add.
792
3. Continue through the wizard until you completed the extension installation.
793
4. In the QRadar console, navigate to Admin > Log Sources. Click +New Log Source.
794
5. In the search box, type Ivanti. Make sure Ivanti is selected in the menu and click Step 2: Select
795
Protocol Type.
796
6. In the search box, type Log File. Make sure Log File is selected in the menu and click Step 3:
797
Configure Log Source Parameters.
798
7. Enter a name for the log source and turn off Coalescing Events. Click Step 4: Configure Protocol
799
Parameters. The settings are as follows:
800
a. Log Source Identifier: MobileIron Cloud
801
b. Service Type: SFTP
802
c. Remote IP or Hostname: <Log server you set up previously>
803
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 30
d. Remote port: 22
804
e. Remote User/Password: <Credentials created earlier, if not using key file
805
authentication>
806
f. SSH Key File: <Credentials created earlier, if not using password authentication>
807
g. Remote directory: Directory where Ivanti logs are being stored
808
h. Recursive: On
809
i. FTP File Type Pattern (Regex for Ivanti log files): ^.*\.(zip|ZIP)$
810
j. Processor: ZIP
811
k. All other settings can be left as default
812
8. Click Step 5: Test Protocol Parameters. Run the tests and ensure the configuration is valid.
813
9. From the QRadar console, navigate to the Admin tab. Click Deploy Changes.
814
2.5 Ivanti Sentry
815
Ivanti Sentry is an in-line gateway that manages, encrypts, and secures traffic between the mobile
816
device and back-end enterprise systems. In this build, Ivanti Sentry acts as a PEP that controls access to
817
enterprise resources.
818
2.5.1 Installation and Configuration
819
For this implementation we used a Standalone Sentry installation on-premises. For the latest Sentry
820
installation instructions, select the appropriate version of the Standalone Sentry On-Premises
821
Installation Guide at https://www.ivanti.com/support/product-documentation.
822
Next, create a profile for Standalone Sentry in the Ivanti Neurons for UEM console. For information on
823
how to create a profile for Standalone Sentry and configure Standalone Sentry for ActiveSync and
824
AppTunnel, see the Sentry Guide for Cloud. For the latest Sentry installation instructions, click on Sentry,
825
then select the appropriate version of the Standalone Sentry On-Premises Installation Guide.
826
2.5.2 Ivanti Tunnel Configuration and Deployment
827
Ivanti Tunnel is an application that connects a mobile device to the Ivanti Sentry. The process to deploy
828
this app is similar to the deployment of the Okta Verify app in Section 2.1.2.
829
1. On the App Configurations page for the Tunnel app, create a Managed Configuration.
830
2. Set the Tunnel Profile Mode to MobileIron Sentry + Access.
831
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 31
3. Set the Sentry Server to the Sentry instance you created previously.
832
4. Set the SentryService to the name of the IP Tunnel defined on the Sentry.
833
5. Set the ClientCertAlias to the Sentry certificates you defined during Sentry configuration.
834
6. Set any other options as needed.
835
7. Save the Managed Configuration and deploy to devices as needed.
836
2.6 Ivanti Access ZSO
837
Ivanti Access ZSO is a cloud-based service that allows access to enterprise cloud resources based on user
838
and device posture, and whether apps are managed or not. In this build, Ivanti Access ZSO functions as a
839
delegated IdP, with Okta passing certain responsibilities to Ivanti Access ZSO.
840
2.6.1 Integration with Ivanti Neurons for UEM
841
1. Ensure that you have the Manage MobileIron Access Integration role in Ivanti Neurons for UEM
842
enabled at Admin > System > Roles Management.
843
2. Navigate to Users > Users and click Add > API User.
844
3. Next, navigate to Users > Users and click on the username of the user you just created. Navigate
845
to the Roles tab of that user and add the Manage MobileIron Access Integration role.
846
4. In the Ivanti Neurons for UEM console, go to Admin > Infrastructure > Access.
847
5. Enter the following: Access Admin URL, Access Admin Username (username for the Access
848
administrator account created for Access integration), and Access Admin Password.
849
6. Click Register.
850
7. When Access is registered with Ivanti Neurons for UEM, you should see the following:
851
2.6.2 Integration with Okta
852
1. In the Okta Admin console, navigate to Security > API and generate an API token. Save this
853
token for use in Access.
854
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 32
2. In the Ivanti Access ZSO console, navigate to Profile > Federation.
855
3. Select Add Pair > Delegated IDP and choose Okta.
856
4. Enter the Okta Domain URL and the Okta API Token you generated in Step 1. Click Verify.
857
5. Once the verification is complete, select the routing rules you’d like configured and click Next.
858
6. Verify the Signing Certificate settings and Encryption Certificate settings are correct, and click
859
Next.
860
7. Choose the desired Unmanaged Device Authentication setting and click Done.
861
8. You will see Okta in the Delegated IDP section. Okta will route authentication requests based on
862
your settings.
863
2.7 Zimperium Mobile Threat Defense (MTD)
864
Zimperium can retrieve various device attributes, such as device name, model, OS, OS version, and
865
owner’s email address. It then continuously monitors the device’s risk posture and reports any changes
866
in the posture to Ivanti Neurons for UEM.
867
2.7.1 Installation, Configuration, and Integration
868
2.7.1.1 Create an API user
869
To configure a Zimperium MTD console to work with Ivanti Neurons for UEM, an API user needs to be
870
created and assigned a few roles.
871
1. In the Ivanti Neurons for UEM admin console, select Users.
872
2. Click + Add > API user. The Add API User dialog page opens.
873
3. Enter the following details: Username, Email, First Name, Last Name, Display Name, and
874
Password.
875
4. Confirm the password.
876
5. Deselect the Cisco ISE Operations option.
877
6. Click Done.
878
2.7.1.2 Assign roles to the API user
879
1. From the admin console, go to Users.
880
2. Select the new API user created previously.
881
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 33
3. Click Actions.
882
4. From the User details page, select Assign Roles.
883
5. Select the following roles: App & Content Management, App & Content Read Only, Common
884
Platform Services (CPS), Device Actions, Device Management, Device Read Only, System Read
885
Only, and User Read Only.
886
2.7.1.3 Add an MDM server to the Zimperium console
887
1. Log in to the Zimperium MTD console.
888
2. Navigate to Manage > Integrations > Add MDM.
889
3. Select Cloud to add it to the MTD console as an MDM server.
890
4. Enter the following required information: URL, Username/Password, MDM Name, and
891
Background Sync.
892
5. Click Finish.
893
2.7.1.4 Activate MTD on Ivanti Neurons for UEM
894
1. From the Ivanti Neurons for UEM admin console, go to Configurations.
895
2. Click +Add.
896
3. Click Mobile Threat Defense Activation.
897
4. In the Create Mobile Threat Defense Configuration page, enter a name for the configuration.
898
5. In the Configuration Setup section, select the vendor Zimperium.
899
6. In the License Key field, enter a unique encrypted Mobile Threat Defense activation code.
900
7. In the Wake up Intervals (mins) field, set a time.
901
8. Click Next.
902
9. Select the Enable this configuration option.
903
10. Select All Devices.
904
11. Click Done.
905
2.7.1.5 Add custom attributes in Ivanti Neurons for UEM
906
Custom device attributes will be applied to both Android and iOS devices based on threat severity.
907
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 34
1. To create custom attributes, in the Ivanti Neurons for UEM admin console go to Admin > System
908
> Attributes. Enter each attribute name in lower case.
909
2. Create the custom attribute mtdnotify for Low or Normal severity threats:
910
a. Click Add New. The Attribute Name and Attribute Type fields are displayed.
911
b. Select Device as the attribute type.
912
c. Name the custom attribute mtdnotify.
913
d. Click Save to monitor and notify.
914
3. Create the custom attribute mtdblock for Elevated or Critical severity threats:
915
a. Click Add New.
916
b. Select Device as the attribute type.
917
c. Name the custom attribute mtdblock.
918
d. Click Save to monitor and notify.
919
4. Create the custom attribute mtdquarantine for Elevated or Critical severity threats:
920
a. Click Add New.
921
b. Select Device as the attribute type.
922
c. Name the custom attribute mtdquarantine.
923
d. Click Save to monitor, notify, and quarantine.
924
5. Create the custom attribute mtdtiered4hours for Low, Normal, Elevated, or Critical severity
925
threats:
926
a. Click Add New.
927
b. Select Device as the attribute type.
928
c. Name the custom attribute mtdtiered4hours.
929
d. Click Save to monitor and notify, wait for four hours, block, wait for another four hours,
930
and quarantine.
931
2.7.1.6 Create compliance policy
932
Create compliance actions using custom policies based on the MTD custom attributes created above.
933
1. In Ivanti Neurons for UEM admin console, go to Policies.
934
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 35
2. Click + Add.
935
3. Select Custom Policy.
936
4. Enter mtdnotify as the policy name.
937
5. Under Conditions, select Custom Device Attribute.
938
6. Select mtdnotify from the drop-down box and set the condition is equal to 1.
939
7. Under Choose Actions, select Monitor and Send Email and Push Notification.
940
8. Under Email Message fields, enter the subject and body text.
941
9. Under Push Notification, enter message text.
942
10. Click Yes, Next, and Done.
943
11. Repeat this procedure to add the following policies: mtdblock, mtdquarantine,
944
mtdtiered4hours.
945
12. Add other policies if needed.
946
2.7.1.7 Create device groups and match with custom policies and custom device
947
attributes created above
948
1. In Ivanti Neurons for UEM admin console, go to Devices > Device Groups.
949
2. Click + Add.
950
3. Enter mtdNotify as the device group name.
951
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 36
4. Under Dynamically Managed groups, select Custom Device Attribute.
952
5. Select mtdnotify from the drop-down box and set the condition is equal to 1.
953
6. Click Save.
954
7. Repeat this procedure to add the following groups: mtdBlock, mtdQuarantine,
955
mtdTiered4hours.
956
2.7.1.8 Configure Zimperium MTD management console
957
Set up, configure, and use the MTD console for supported MTD activities. When configuring policies in
958
the Zimperium admin console, use the available MDM actions and mitigation actions.
959
2.8 IBM Cloud Pak for Security
960
IBM Cloud Pak for Security platform enables the integration of existing security tools and provides
961
understanding and management of threats in the environment.
962
1. Deploy an OpenShift cluster. OpenShift needs to be in place before Cloud Pak for Security can be
963
installed.
964
2. Install Cloud Pak for Security.
965
3. Configure LDAP authentication so Cloud Pak for Security can leverage an existing LDAP directory
966
server for authentication.
967
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 37
Once those steps are complete, open a web browser and navigate to the DNS name for Cloud Pak for
968
Security. Additional documentation can be found at Cloud Pak for Security Documentation.
969
2.9 IBM Security QRadar XDR
970
IBM Security QRadar platform provides various security capabilities including threat detection and
971
response, security information and event management (SIEM), and security orchestration, automation,
972
and response (SOAR).
973
Install and configure QRadar following IBM’s QRadar Installation and Configuration Guide.
974
Once that is complete, open a web browser and navigate to the QRadar server web interface by using its
975
IP address or DNS name.
976
2.10 Tenable.io
977
Tenable.io is a cloud-based platform that is used in this build to provide network discovery, vulnerability,
978
and scanning capabilities for on-premises components.
979
2.10.1 Installation and Configuration
980
As a cloud-based platform, a license must first be obtained, and a cloud instance deployed by Tenable.
981
Once deployed by a Tenable representative, Tenable.io can be accessed through the web interface
982
located at https://cloud.tenable.com.
983
2.10.1.1 Deploy an agent
984
1. In Tenable.io, click the hamburger menu (☰) in the top left corner and navigate to Settings >
985
Sensors > Nessus Agents.
986
2. Click Add Nessus Agent and save the Linking Key.
987
3. On the target endpoint, download the agent from https://downloads.tenable.com. When the
988
download completes, run the executable file.
989
4. In the setup window, fill in the key from step 2, the server (in our case, cloud.tenable.com:443),
990
and the agent groups that this agent will be part of (in our case, Default). Click Next.
991
5. Click Install and approve the request if User Account Control (UAC) comes up.
992
6. When installation completes, updates will continue running in the background. The update and
993
connection process may take some time. The endpoint will then be shown in the cloud tenant.
994
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 38
2.10.1.2 Deploy a scanner
995
1. In Tenable.io, navigate to Settings > Sensors > Cloud Scanners.
996
2. Click Add Nessus Scanner and save the Linking Key.
997
3. Download the Nessus Scanner .ova file from https://downloads.tenable.com.
998
4. Deploy the .ova file in your virtual environment.
999
5. Once the scanner is running, navigate to the IP address shown in the console in a web browser.
1000
6. Login with the default username wizard and default password admin.
1001
7. Enter new administrator credentials and click Create Account.
1002
8. Click Finish Setup and authenticate with the new administrator credentials.
1003
9. On the left-side navigation pane, click Nessus.
1004
10. Click the URL shown in the Nessus Installation Info pane.
1005
11. Click the radio button next to Managed Scanner and click Continue.
1006
12. Enter the Linking Key from step 2 and click Continue.
1007
13. Enter credentials for a new administrator account and click Submit.
1008
14. The scanner will initialize and be visible on tenable.io. Scans can now be scheduled.
1009
2.10.2 Integration with QRadar
1010
For Tenable.io and QRadar integration, follow the Tenable and IBM QRadar SIEM Integration Guide.
1011
2.11 Tenable.ad
1012
Tenable.ad provides AD monitoring to detect attacks and identify vulnerabilities. In this build,
1013
Tenable.ad is integrated with the on-premises AD installation and configured to forward alerts to the
1014
IBM QRadar SIEM.
1015
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 39
For Tenable.ad installation and configuration, follow the Tenable.ad On-Premise Installation Guide.
1016
For Tenable.ad and QRadar integration, follow the Tenable and IBM QRadar SIEM Integration Guide.
1017
2.12 Tenable NNM
1018
Tenable Nessus Network Monitoring (NNM) monitors network traffic at the packet level to provide
1019
visibility into both server and client-side vulnerabilities. In this build, NNM was set to Asset Discovery
1020
mode and linked to Tenable.io in order to provide visibility into all network actors.
1021
For Tenable.ad installation and configuration, follow the Tenable NNM Documentation.
1022
2.12.1 Deploy a Tenable NNM instance
1023
1. In Tenable.io, navigate to Settings > Sensors > Nessus Network Monitors.
1024
2. Click Add Nessus Network Monitor and save the Linking Key.
1025
3. Download the NNM .ova file from https://downloads.tenable.com.
1026
4. Deploy the .ova file in your virtual environment.
1027
5. Once the NNM instance is running, navigate to the IP address shown in the console in a web
1028
browser on port 8835.
1029
6. Enter credentials for a new administrator account and click Submit.
1030
7. Enter the Linking Key from step 2 and click Continue.
1031
8. The NNM instance will initialize and be visible on Tenable.io. Additional NNM configuration can
1032
now occur if needed.
1033
2.13 Mandiant Security Validation (MSV)
1034
Mandiant Security Validation (MSV) allows organizations to continuously validate the effectiveness of
1035
their cybersecurity controls by running actions that may conflict with the organization’s policy and
1036
determining if those actions are detected and/or blocked. In this build, MSV is configured to regularly
1037
test the build’s zero trust policies and report on the results.
1038
2.13.1 MSV Director Installation/Configuration
1039
1. Download the MSV Director software from the Mandiant web portal and deploy it in a virtual
1040
environment.
1041
2. Log into the MSV command line interface using credentials provided by Mandiant.
1042
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 40
3. Run the command sudo vsetnet to apply network configuration.
1043
4. Run the command sudo vsetdb --password new_password to set a new password for the
1044
Director database.
1045
5. Use a web browser to access the MSV Director web interface at https://Director IP/.
1046
6. Sign into the web interface using credentials provided by Mandiant.
1047
7. Accept the End User Licensing Agreement and apply the license provide by Mandiant.
1048
8. Configure the DNS settings by navigating to Settings > Director Settings > DNS Servers.
1049
9. Configure the NTP settings by navigating to Settings > Director Settings > NTP Servers.
1050
10. Add Security Zones corresponding with the enterprise’s network segments by navigating to
1051
Environment > Security Zones.
1052
11. Download security content from the Mandiant web portal.
1053
12. Navigate to Settings > Director Settings > Content.
1054
13. Select Import, browse to the downloaded security content, and select the content files.
1055
14. Click Upload Import and upload the files into the MSV Director web interface.
1056
15. Once the upload is complete, click Apply Import to import the content files into MSV.
1057
2.13.2 MSV Network Actor Installation/Configuration
1058
1. Download the MSV Network Actor software from the Mandiant web portal and deploy it in a
1059
virtual environment.
1060
2. Log into the MSV command line interface using credentials provided by Mandiant.
1061
3. Run the command sudo vsetnet to apply network configuration.
1062
4. In the MSV Director web interface, navigate to Environment > Actors.
1063
5. Click Add Network Actors and fill out the new Actor form.
1064
6. Identify the Actor you just created in the Pending Actors table, expand the Actions menu, and
1065
click Connect to initiate a Director-to-Actor registration.
1066
7. Enter the Actor’s FQDN or IP address.
1067
2.13.3 MSV Endpoint Actor Installation/Configuration
1068
1. Deploy an endpoint machine running Windows, macOS, or Linux.
1069
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 41
2. In the MSV Director web interface, navigate to Library > Actor Installer Files and download the
1070
relevant installer onto the endpoint.
1071
3. Navigate to Environment > Actors, click Add Endpoint Actors, and fill out the new Actor form.
1072
4. Execute the Actor installer on the endpoint and proceed through the install process.
1073
5. At the end of the install process, identify the actor you just created in the Pending Actors table
1074
and enter the value from the Code field into the Actor configuration field.
1075
6. The endpoint will register itself with the MSV Director, and setup will be complete.
1076
2.13.4 MSV Evaluation Configuration
1077
1. Once the MSV Director and Actors have been configured, evaluations can be created to test
1078
security controls and policies. In the MSV Director web interface, navigate to Library > Actions.
1079
2. Find the action(s) you would like to use for the evaluation and select the +Queue button to add
1080
the action to the Queue. Repeat this process until you have added all needed actions to the
1081
Queue.
1082
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 42
3. After actions have been added to the Queue, click the Queue button in the upper right side of
1083
the web interface.
1084
4. Select each of the actions in the Unassigned section and drag them to the Current Actions
1085
section.
1086
5. Scroll up to the top of the page and click the Save button.
1087
6. Under the Test Type dropdown, choose Evaluation.
1088
7. Under the Name section, enter a name.
1089
8. Under the Description section, enter a description.
1090
9. Select the Save button to save the evaluation.
1091
10. Your new evaluation can be found by navigating to Library > Evaluations and filtering on User
1092
Created.
1093
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 43
2.13.5 MSV Evaluation Execution
1094
1. Navigate to Library > Evaluations and select the evaluation you’d like to run. Click the Run
1095
button.
1096
2. From the Evaluation screen, press the Run Evaluation button.
1097
3. Select the Source Actor and Destination Actor from the dropdown menus. Click Run Now.
1098
4. The evaluation will run, providing results once the actions have been attempted/completed.
1099
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 44
2.14 DigiCert CertCentral
1100
CertCentral simplifies digital trust and automates certificate management by consolidating tasks for
1101
issuing, installing, inspecting, remediating, and renewing TLS/SSL certificates in one place. In this build,
1102
CertCentral provided TLS/SSL certificates to any system needing those services.
1103
For the latest CertCentral setup and usage instructions, see https://docs.digicert.com/get-started/.
1104
2.14.1 Requesting a certificate
1105
1. Generate a Certificate Signing Request. This can be done with OpenSSL or DigiCert’s Certificate
1106
Utility. Save the private key for later use.
1107
2. In the DigiCert CertCentral dashboard, navigate to Certificates > Requests and click Request a
1108
Certificate. Select the certificate type.
1109
3. Upload or paste the Certificate Signing Request in the provided field.
1110
4. Select the coverage length, and add any other additional options as needed.
1111
5. Click Submit Request.
1112
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 45
2.14.2 Obtaining and implementing a certificate
1113
1. In the DigiCert CertCentral dashboard, navigate to Certificates > Orders and select the request
1114
that you previously created.
1115
2. Click Download certificate as and select More Options…
1116
3. You will be presented with a list of certificate format options. Select the option/format that best
1117
pertains to the platform you will be using the certificate on. Click Download.
1118
4. Obtain the private key that was originally generated with your Certificate Signing Request. If
1119
using DigiCert’s Certificate Utility, this can be found using the Export function.
1120
5. The certificate and private key can now be imported/installed and used on the intended
1121
platform.
1122
3 Enterprise 2 Build 1 (EIG E2B1) Product Guides
1123
This section of the practice guide contains detailed instructions for installing, configuring, and
1124
integrating all of the products used to implement EIG E2B1. For additional details on EIG E2B1’s logical
1125
and physical architectures, please refer to Volume B.
1126
3.1 Ping Identity PingOne
1127
Ping Identity PingOne is a SaaS solution that provides ICAM capabilities to an enterprise. The following
1128
sections describe the setup of PingOne and its PingFederate service, and various integrations to other
1129
products. Ping Identity integrates with Radiant Logic for identity information, and with Cisco Duo to
1130
delegate the second authentication factor for users accessing resources.
1131
3.1.1 Configuration: PingOne and PingFederate
1132
1. PingOne setup: From your web browser, type pingone.com and click the “Try Ping” at the top
1133
right of the screen. Follow the instructions to sign up.
1134
2. Once the PingOne environment is set up and functioning, scroll down the screen and click on the
1135
PingFederate service. A new browser tab will open. Most of the configuration will be performed
1136
on PingFederate for this build.
1137
3. Create an IDP adaptor. This configuration should include some required values like mail and
1138
group membership (these will be mapped in steps below to the policy contract) and it is used as
1139
the first authentication factor and will be applied in the policy in the next step.
1140
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 46
4. Create a policy contract as a list to map values to the connection(s). They will use a policy to
1141
fulfill the mappings from sources (such as LDAP or Third-Party Identity Provider using a
1142
Federated Hub).
1143
5. Create an authentication policy that will be used to dictate application authentication. For our
1144
policies, we are using user ID and password for the first authentication factor (step 2 above) and
1145
Duo as the second authentication factor (step 2 in the Integration with Cisco Duo section).
1146
6. Create a policy contract to connect that uses the above policy.
1147
7. Configure SAML application integrations. Note that all applications are different. For our
1148
resources (applications), certain SAML formats and attributes are used. Follow the linked
1149
documentation above to configure the specific setup of your own application.
1150
8. For this build, we developed policies that allow employees to access all resources (resource 1
1151
and resource 2) and contractors to access resource 2 only. In order to do that, we leveraged the
1152
“memberof” attribute from Radiant Logic to identify employees and contractors. Once this
1153
information is identified, refer to:
1154
a. Authentication Policies to define the attribute mappings using this information, Policy
1155
Contract
1156
b. SAML applications to configure issuance criteria to information retrieved from Radiant
1157
Logic
1158
3.1.2 Integration with Radiant Logic
1159
1. For this build we installed a PingOne Gateway, which is “on-premise software that allows
1160
PingOne to communicate with other systems like LDAP servers,” to communicate with
1161
RadiantOne. The PingOne Gateway was installed on a Windows Server on the same subnet as
1162
the RadiantOne server. We used the PingOne Gateway due to restrictions of multiple firewalls
1163
and NAT rules within our lab environments (some are not under our control) from allowing
1164
PingOne from the Internet to reach RadiantOne in Enterprise 2. In many environments, the
1165
LDAP gateway is not needed if NAT is not used, and opening the proper TCP/UDP ports on the
1166
enterprise firewalls will allow communication between PingOne and the on-prem resource.
1167
Note: Prerequisites and instructions to install the gateway are available under
1168
Connections/Gateway in the PingOne console.
1169
2. Once the Gateway is configured, click the Add button within the Connections/Gateway screen.
1170
Follow instructions on the screen to complete the integration with Radiant Logic. Note: A service
1171
account and other information from Radiant Logic is needed for the setup. Ensure this service
1172
account is created within Radiant Logic prior to configuring the PingOne Gateway.
1173
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 47
3. From PingFederate, go to Data Stores and create a New Data Store for Radiant Logic. Select
1174
LDAP for your LDAP Type and fill in the variables to complete the configuration.
1175
3.1.3 Integration with Cisco Duo
1176
Make sure that configuration from Cisco Duo is completed before performing the integration.
1177
For IDP application integration, from the Authentication tab, select IDP Adaptors, and click Create New
1178
Instance to create the integration with Cisco Duo to use Duo MFA as the second authentication factor.
1179
Specific API configuration information that was created from Cisco Duo is needed here to complete the
1180
setup.
1181
Note: For this build, we are using Duo although Ping Identity has its own MFA.
1182
3.2 Radiant Logic RadiantOne
1183
3.2.1 Installation and Configuration
1184
Refer to Section 2.2.1.
1185
3.2.2 Configuration
1186
Refer to Section 2.2.2.
1187
3.2.3 Integration
1188
Refer to Section 2.2.3 for integration with SailPoint.
1189
For integration with Ping Identity, a service account was created in RadiantOne. This service account,
1190
along with various credential information is used by PingFederate to communicate with RadiantOne to
1191
authenticate users. The communication between RadiantOne and PingFederate is through the Ping
1192
Gateway, which was installed on the same subnet as RadiantOne.
1193
3.3 SailPoint IdentityIQ
1194
3.3.1 Installation and Configuration
1195
Refer to Section 2.3.1.
1196
3.3.2 Integration with Radiant Logic
1197
Refer to Section 2.3.2.
1198
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 48
3.3.3 Integration with AD
1199
Refer to Section 2.3.3.
1200
3.3.4 Integration with Ping Identity
1201
There is no integration with Ping Identity. For this build, SailPoint provides AD user information and Duo
1202
pulls from AD.
1203
3.4 Cisco Duo
1204
Cisco Duo is a SaaS solution that implements and enforces security policies and processes, using strong
1205
authentication to reduce the risk of data breaches due to compromised credentials and access from
1206
unauthorized devices. For this build, we use Cisco Duo as the second authentication factor for resources.
1207
3.4.1 Configuration
1208
Sign up with Cisco Duo to create a Duo instance. Once you have admin access, create policies and
1209
integration with AD and Ping Identity.
1210
Create a policy to enable MFA for users. Navigate to Policy and click Edit Global Policy. In the Global
1211
Policy, there are many sub-policies that can be applied. For this build, we enabled the following:
1212
▪ New User policy: prompt any user without the Duo app to enroll
1213
▪ Authentication policy: require two-factor
1214
▪ Authentication methods: Duo Mobile app (Duo Push)
1215
▪ Device Health application: enable macOS and Windows (note: these are the only operating
1216
systems that are capable of device health monitoring)
1217
▪ Custom Policies: Create a policy to monitor device health if the authentication request comes
1218
from PingFederate. Self-enrollment is enabled so users will be prompted to install a Duo client
1219
on the end device for health monitoring. For this build, users will not be given access to a
1220
resource if their macOS or Windows firewall is turned off. There are other health checks
1221
available.
1222
3.4.2 Integration
1223
For integration with PingFederate, navigate to Applications and click Protect an application. Follow the
1224
instructions to complete the configuration. Note the three pieces of information provided: Client ID,
1225
Client secret, and API hostname. This information will be used to configure the integration within
1226
PingFederate to communicate with Duo.
1227
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 49
For integration with Microsoft Active Directory, navigate to Users and click on Directory Sync. Follow
1228
the instructions to configure the AD integration. A Duo Authentication Proxy is needed for this build
1229
since the Enterprise 2 AD is not visible to the Internet.
1230
3.5 Palo Alto Networks Next Generation Firewall
1231
In this build, a virtualized Palo Alto Next Generation Firewall (NGFW) was deployed on-premises as a
1232
security and access control device. The firewall provides zone-based network filtering for both inbound
1233
and outbound traffic, including remote access virtual private networks (VPNs) using the GlobalProtect
1234
clients. For GlobalProtect VPN access installation instructions, visit:
1235
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFbCAK
1236
3.6 IBM Security QRadar XDR
1237
For installation, configuration, and integration instructions, refer to Section 2.9.
1238
3.7 Tenable.io
1239
For installation, configuration, and integration instructions, refer to Section 2.10.
1240
3.8 Tenable.ad
1241
For installation, configuration, and integration instructions, refer to Section 2.11.
1242
3.9 Tenable NNM
1243
For installation, configuration, and integration instructions, refer to Section 2.12.
1244
3.10 Mandiant Security Validation (MSV)
1245
For installation, configuration, and integration instructions, refer to Section 2.13.
1246
3.11 DigiCert CertCentral
1247
For installation, configuration, and integration instructions, refer to Section 2.14.
1248
4 Enterprise 3 Build 1 (EIG E3B1) Product Guides
1249
This section of the practice guide contains detailed instructions for installing, configuring, and
1250
integrating all of the products used to implement EIG E3B1. For additional details on EIG E3B1’s logical
1251
and physical architectures, please refer to NIST SP 1800-35B.
1252
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 50
4.1 Microsoft Azure Active Directory (AD)
1253
Azure AD is a SaaS identity and access management platform. No installation steps are required. You will
1254
need to create your organization’s instance of Azure AD and configure it to allow your users access to
1255
applications that use it for authentication and authorization.
1256
1. After logging in to portal.azure.com, create an Azure AD Tenant.
1257
2. Create a connection between your on-premises AD and Azure AD to replicate user, group, and
1258
authentication information from your AD to Azure AD.
1259
3. Configure the Azure AD Tenant to enable Single Sign-On Password Reset (SSPR). This gives users
1260
the ability to reset their passwords from https://aka.ms/sspr or from within their profile in
1261
Azure AD. This will be effective for both their AD and Azure AD accounts.
1262
4. Configure password writeback, which enables password changes in Azure AD to be replicated
1263
back to the on-premises AD.
1264
5. The conditional access feature in Azure AD specifies conditions under which a user would be
1265
given access to a resource or application that uses Azure AD for authentication. MFA was
1266
configured as a requirement for access to all applications. Configure MFA for all users.
1267
6. Access to resources based on device compliance was implemented as an essential feature in this
1268
solution. Access would only be granted to a user if the client device is compliant. Compliance is
1269
reported to Azure AD by Microsoft Endpoint Manager. Enable this feature, Conditional Access
1270
Device Compliance.
1271
7. Configure an enterprise application, GitLab, to use Azure AD for authentication:
1272
a. GitLab was configured to directly authenticate to Azure AD using the SAML protocol.
1273
GitLab must first be registered in Azure AD before Azure AD can be configured as the
1274
application’s IdP.
1275
b. Configure Azure AD as a SAML IdP for the GitLab application. Once that is implemented,
1276
access attempts to the target application will be redirected to Azure AD for
1277
authentication and authorization.
1278
4.2 Microsoft Endpoint Manager
1279
Microsoft Endpoint Manager is a cloud-based service that focuses on mobile device management
1280
(MDM) and mobile application management (MAM).
1281
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 51
4.2.1 Configuration and Integration
1282
4.2.1.1 Add and verify a custom domain
1283
To connect an organization’s domain name with Intune, a DNS registration needs to be configured. This
1284
gives users a familiar domain when connecting to Intune and using resources. Use the information found
1285
at the hyperlink to create a custom domain.
1286
4.2.1.2 Add users
1287
Use the information at the hyperlink to add users to Intune.
1288
4.2.1.3 Enroll devices in Microsoft Intune
1289
Enrolling devices allows them to receive configuration profiles and compliance policies. Configuration
1290
profiles configure features and settings on devices. Compliance policies help devices meet an
1291
organization’s rules.
1292
1. Get an Apple MDM push certificate and add it to Endpoint Manager. This certificate is required
1293
to enroll iOS/iPadOS devices. Then enroll iOS devices in Microsoft Intune.
1294
2. Create an iOS enrollment profile. An enrollment profile defines the settings applied to a group of
1295
devices during enrollment.
1296
3. Enroll Android devices in Microsoft Intune. To enable Android Enterprise, an administrative
1297
Google account needs to be connected to the Intune tenant.
1298
4. Create an iOS compliance policy in Microsoft Intune. It will be evaluated before access is allowed
1299
from iOS devices.
1300
5. Create an Android compliance policy in Microsoft Intune. It will be evaluated before access is
1301
allowed from Android devices.
1302
6. Create an iOS/macOS configuration profile for iOS or Mac devices.
1303
4.2.1.4 Configure conditional access rules
1304
Conditional access is used to control the devices and apps that can connect to company resources. Use
1305
the information in the hyperlink to create device based conditional access policies.
1306
4.2.1.5 Manage applications
1307
iOS/iPadOS: Use the instructions at Add iOS Store Apps to select apps from the iOS/iPadOS store that
1308
will be approved for installation on your managed iOS or iPadOS devices.
1309
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 52
Android: For this build we added Managed Google Play apps. Managed Google Play is Google’s
1310
enterprise app store which serves as a source of applications for Android Enterprise in Intune. Use the
1311
instructions at Add Android Store Apps to select apps that will be approved for installation and made
1312
available to your managed devices.
1313
Windows: Use the information provided at select approved apps to choose which apps should be added
1314
to your Windows devices.
1315
There is more than one way to configure Windows apps in Intune. We configured the app using App
1316
suite information. For other ways, refer to the Microsoft documentation.
1317
4.3 Microsoft Defender for Endpoint
1318
Microsoft Defender for Endpoint provides endpoint protection, detection, and response to threats.
1319
4.3.1 Configuration and Integration
1320
4.3.1.1 Enable Microsoft Defender for Endpoint
1321
Use the information at Configure Microsoft Defender for Endpoint in Microsoft Intune | Microsoft Learn
1322
to enable Defender for Endpoint.
1323
1. Use the information in the provided hyperlink to onboard devices. Once devices are onboarded,
1324
threat signals and vulnerability information are automatically collected from them.
1325
2. You can optionally enable supervised mode on iOS devices using information at the hyperlink.
1326
Supervised mode gives administrators greater control over corporate-owned devices.
1327
3. Alerts and security incidents can be viewed and responded to by accessing the Defender for
1328
Endpoint cloud component. Use the information in the hyperlink to view and respond to
1329
discovered threats.
1330
4.3.1.2 Create Endpoint Detection and Response policy (Windows 10 and later)
1331
Endpoint detection and response (EDR) policies are used to detect advanced attacks in near real-time.
1332
Use the information in the hyperlink to create an EDR policy.
1333
4.3.1.3 Create an antivirus policy
1334
An antivirus policy defines the behavior of the antivirus software agent on the endpoint. Use the
1335
information in the hyperlinks to create an antivirus policy and configure antivirus policy settings.
1336
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 53
4.3.1.4 Create Defender compliance policy
1337
Compliance policies can help protect organizational data by requiring users and devices to meet defined
1338
security requirements. Use the information in the hyperlink to create a Defender for Endpoint
1339
compliance policy.
1340
4.3.2 Microsoft Defender Antivirus
1341
Microsoft Defender Antivirus is leveraged by Microsoft Defender by Endpoint. It is anti-malware
1342
software built into Windows client devices that detects threats and malware on client devices and
1343
quarantines infected files. Defender Antivirus is enabled by default.
1344
1. Check the status of real-time protection to ensure it’s on.
1345
2. Turn real-time protection on or off.
1346
4.4 Microsoft Sentinel
1347
Microsoft Sentinel is a cloud-native SIEM and SOAR system. It can be used for security analytics, threat
1348
intelligence, attack detection, and threat response.
1349
There is no need to install Sentinel, as it is a managed service. Instead, it needs to be enabled and
1350
configured in your Azure environment. It also needs a workspace to store and correlate ingested data.
1351
1. Enable Sentinel and configure a workspace.
1352
2. Use the general instructions found at Connector to Data Sources to enable log forwarding to
1353
Sentinel from various devices, systems, and services. Each data source will have to be connected
1354
independently from other data sources, so you must perform this step once per data source. In
1355
this build, Azure AD, Endpoint Manager, Defender for Endpoint, Office365, and Tenable.io were
1356
configured to send logs using this method.
1357
3. The Log Analytics Agent is a log forwarder that accepts syslog and common event format (CEF)
1358
formatted logs and then forwards the logs to Sentinel. If you have a product or device without a
1359
native Sentinel integration, install and configure the Log Analytics Agent on a virtual machine.
1360
Once completed, the log forwarder will be able to receive syslog data on UDP port 514. Then
1361
configure the product or device that will be the data source to send logs via syslog to the log
1362
forwarder using the product’s instructions.
1363
4.5 Microsoft Office 365
1364
Microsoft Office 365 is a suite of SaaS-based productivity applications used for a variety of activities such
1365
as word processing, accounting, creating presentations, email, and others. Office 365 was enabled in the
1366
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 54
environment and was used as a set of protected target applications. Use the information at Activate
1367
Microsoft Office 365 to activate your office 365 subscription.
1368
Use Office 365 Sign-in link to log on to Microsoft Office 365. Use your email address and password. You
1369
will be required to authenticate using multi-factor authentication.
1370
Once authentication is complete, you will see the various office applications, such as Word, Excel,
1371
PowerPoint, and Outlook in your dashboard.
1372
4.6 F5 BIG-IP
1373
BIG-IP is both a load balancer and an identity-aware proxy. In this phase of the build, it was primarily
1374
used as an identity-aware reverse proxy that forwarded or denied traffic to protected back-end
1375
applications.
1376
4.6.1 Installation, Configuration, and Integration
1377
BIG-IP was deployed into the environment using a virtual machine image or open virtual appliance
1378
(OVA) file. Once this OVA import operation is complete, log into the virtual machine console and assign
1379
an IP address to a network interface, then continue configuration by connecting to its web interface.
1380
This BIG-IP image has both the Access Policy Manager (APM) and the Local Traffic Manager modules
1381
installed.
1382
1. Deploy BIG-IP OVA into your VMWare environment.
1383
2. Access the BIG-IP web interface by entering the IP address or DNS name into a web browser.
1384
Then complete the initial setup and configuration of BIG-IP.
1385
3. Create virtual servers which map to back-end protected applications—in this build, to our
1386
Guacamole application server.
1387
4. Configure BIG-IP to use Azure AD as the SAML IdP for external authentication to access back-end
1388
applications. The instructions at Configure BIG-IP Easy Button for Header Based SSO and the
1389
video at Azure AD and BIG-IP APM Integration Video provide additional references.
1390
5. Once these instructions are completed, BIG-IP, leveraging Azure AD for external authentication,
1391
will only allow successfully authenticated and authorized users to access Guacamole. Access to
1392
the backend application is either done by connecting directly via the DNS name of the
1393
application or by going to myapps.microsoft.com and selecting the backend application icon,
1394
such as F5 Guacamole_SSO as shown below.
1395
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 55
6. For this build, configure BIG-IP to send logs to Microsoft Sentinel. Then you can observe BIG-IP
1396
logs in Sentinel, as shown below.
1397
4.7 Lookout Mobile Endpoint Security (MES)
1398
Lookout Mobile Endpoint Security (MES) solution is used to control mobile device access to corporate
1399
resources based on risk assessment. Risk is assessed based on information collected from devices by the
1400
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 56
Lookout service. Lookout then communicates this risk level to the MDM (Microsoft Endpoint Manager
1401
(Intune)) which determines whether the device is compliant or not.
1402
4.7.1 Configuration and Integration
1403
Before configuring Lookout, collect the following information from Azure AD: Azure AD tenant ID and
1404
Azure AD group object ID.
1405
1. Go to Azure Active Directory > Properties and locate Tenant ID. Copy and save it to the text file.
1406
2. Go to Azure Active Directory > Groups to open the Groups | All groups pane.
1407
3. Select the group with full access rights (Lookout Admin group).
1408
4. Copy the (group) Object Id, and then save it in a text file.
1409
The following steps are to be completed in the Lookout Enterprise admin console and will enable a
1410
connection to Lookout's service for Intune enrolled devices.
1411
1. Sign in to the Lookout for Work console and go to System > Integrations, and then select
1412
Choose a product to set up. Select Microsoft Azure. Copy and paste the Azure AD (AAD) tenant
1413
ID and group object ID from the text file that was created in previous steps.
1414
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 57
2. Stay in System > Integrations, and then select Choose a product to set up. Select Microsoft
1415
Intune.
1416
3. Configure Intune connector settings.
1417
After Lookout MES is enabled, a connection to Lookout in Intune needs to be set up.
1418
1. Go back to Microsoft Endpoint Manager and enable the Mobile Threat Defense connector there.
1419
2. Select Tenant administration > Connectors and tokens > Mobile Threat Defense.
1420
3. On the Mobile Threat Defense pane, select Add.
1421
4. For Mobile Threat Defense connector to setup, select Lookout MTD solution from the drop-
1422
down list.
1423
5. Configure the toggle options according to the organization's requirements. This screenshot
1424
shows examples.
1425
When Lookout is integrated with Intune MTD and the connection to Intune is enabled, Intune creates a
1426
classic conditional access policy in Azure AD. To view classic conditional access policy, go to Azure Active
1427
Directory > Conditional Access > Classic policies. Classic conditional access policy is used by Intune MTD
1428
to require that devices are registered in Azure AD so that they have a device ID before communicating to
1429
Lookout MTD. The ID is required so that devices can report their status to Intune.
1430
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 58
4.7.2 Create MTD Device Compliance Policy with Intune
1431
Compliance policy is needed to detect threats and assess risks on mobile devices to determine if a
1432
device is compliant or not.
1433
1. Open the Microsoft Endpoint Manager admin center.
1434
2. Select Endpoint security > Device Compliance > Create Policy.
1435
3. Select the Platform, and then Create.
1436
4. On Basics, provide Name and Description. Select Next to continue.
1437
5. On Compliance settings, expand and configure Device Health. Choose the Mobile Threat Level
1438
from the drop-down list for Require the device to be at or under the Device Threat Level.
1439
Choose the level for compliance.
1440
6. Select Next to go to Assignments. Select the groups or users to which this policy should be
1441
assigned.
1442
4.8 PC Matic Pro
1443
PC Matic Pro is an endpoint protection system that consists of a server for centralized management and
1444
agents installed on endpoints. In addition to scanning for malware, it uses a default-deny approach in
1445
preventing malicious or unauthorized programs and processes from executing. To configure PC Matic
1446
Pro, you will need to install the server, install the agents, and configure a list of allowed software.
1447
PC Matic Pro Server needs to be installed on a server with Windows 2019 Server and SQL server
1448
preinstalled.
1449
1. Obtain the OnPremInstallerRun.ps1 installation script from the vendor and open an elevated
1450
PowerShell window.
1451
2. Execute the OnPremInstallerRun.ps1 script by entering .\OnPremInstallerRun.ps1
1452
registryUser pcmatic -registryPwd <insert_password_here> -localDBUser pcm-app to
1453
install docker, pull down the container images, and deploy the container instances that make up
1454
the PC Matic Pro server.
1455
3. Navigate to the PC Matic web server and verify that it is operational by opening a web browser
1456
and going to https://<pcmaticDNSName>/web_portal. In this build, the DNS name is
1457
nist.pcmaticfederal.com; as such, to access the server’s web interface, we would go to
1458
https://nist.pcmaticfederal.com/web_portal.
1459
Follow these steps to install PC Matic Endpoint Agents:
1460
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 59
1. Open a web browser on a Windows or macOS client device. Navigate to the PC Matic Server
1461
web interface by browsing to https://nist.pcmaticfederal.com from the client device and log on
1462
with your credentials.
1463
2. Click Add a Device and then click Windows Installer or Mac Installer, as appropriate, to
1464
download the PC Matic Endpoint Agent.
1465
3. Install the agent.
1466
4. Once installed, the agent will establish communications with the server and show up on the list
1467
of managed devices once you log on to the server as previously described.
1468
5. Devices with an agent will register and come online.
1469
4.9 Tenable.io
1470
For installation, configuration, and integration instructions, refer to Section 2.10.
1471
4.9.1 Integration with Microsoft Sentinel
1472
1. In Tenable.io, click the hamburger menu (☰) in the top left corner and navigate to Settings >
1473
Access Control > Users.
1474
2. (Optional) Click Create User and create a new API user for Microsoft Sentinel. In this
1475
implementation, a standard administrator account was used.
1476
3. Click the user who needs API keys generated. Then click API KEYS > Generate > Continue. Save
1477
the Access and Secret Keys, as they will not be shown again.
1478
4. In Microsoft Sentinel, navigate to Data Connectors. Search tenable and click Tenable.io
1479
Vulnerability Management (Preview) > Open Connector Page.
1480
5. Scroll down in the Instructions panel and save the Workspace ID and Primary Key.
1481
6. Click Deploy to Azure.
1482
7. Select the appropriate resource group.
1483
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 60
8. In the Workspace ID and Workspace Key fields, enter the values obtained in step 5.
1484
9. In the Tenable Access Key and Tenable Secret Key fields, enter the values obtained in step 3.
1485
10. Click Review + create.
1486
11. Click Create. Function deployment will begin. Once deployment is complete, it will take some
1487
time before Sentinel begins making calls to Tenable.io.
1488
4.10 Tenable.ad
1489
For installation, configuration, and integration instructions, refer to Section 2.11.
1490
4.11 Tenable NNM
1491
For installation, configuration, and integration instructions, refer to Section 2.12.
1492
4.12 Mandiant Security Validation (MSV)
1493
For installation, configuration, and integration instructions, refer to Section 2.13.
1494
4.13 Forescout eyeSight
1495
Forescout eyeSight provides asset discovery with both active and passive techniques, and through
1496
integrations with network and security infrastructure. In this build, Forescout was deployed on-premises
1497
in two virtual hosts: an Enterprise Manager and Forescout Appliance.
1498
For Forescout installation instructions, visit the Forescout Installation Overview.
1499
4.13.1 Integration with AD
1500
1. In AD, create a domain administrator service account for Forescout and save the credentials.
1501
2. In the Forescout console, navigate to Tools > Options > HPS Inspection Engine.
1502
3. In the Domain Credentials section, click the Add button.
1503
4. Enter the domain information and credentials you saved earlier. Click OK.
1504
5. Click Apply. After the new configuration is saved, click Test to verify that the credentials are
1505
working as expected.
1506
4.13.2 Integration with Cisco Switch
1507
For Cisco Switch integration instructions, visit the Switch Plugin Configuration Guide.
1508
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 61
4.13.3 Integration with Cisco Wireless Controller
1509
For Cisco Wireless Controller integration instructions, visit the Wireless Plugin Configuration Guide.
1510
4.13.4 Integration with Microsoft Sentinel
1511
1. In the Forescout console, navigate to Tools > Options > CEF.
1512
2. Click Add.
1513
3. In the Add Server dialog, enter a Name, select Use UDP for Connection, and enter the IP address
1514
of the Sentinel Log Forwarder. Click Next.
1515
4. Click the Assign CounterACT Devices radio button, and check all of the checkboxes next to the
1516
listed devices.
1517
5. Click Finish. Verify that logs are being received by the Sentinel Log Forwarder.
1518
4.13.5 Integration with Palo Alto Networks NGFW
1519
For Palo Alto Networks Next-Generation Firewall (NGFW) integration instructions, visit the eyeExtend
1520
for Palo Alto Networks Next-Generation Firewall Configuration Guide.
1521
4.13.6 Integration with Tenable.io
1522
For Tenable.io integration instructions, visit the eyeExtend for Tenable.io Vulnerability Management
1523
Configuration Guide.
1524
4.14 Palo Alto Networks Next Generation Firewall
1525
For installation, configuration, and integration instructions, refer to Section 3.5.
1526
4.15 DigiCert CertCentral
1527
For setup and usage instructions, refer to Section 2.14.
1528
5 Enterprise 4 Build 1 (EIG E4B1) Product Guides
1529
This section will be completed during the next phase.
1530
6 Enterprise 1 Build 2 (EIG E1B2) Product Guides
1531
This section of the practice guide contains detailed instructions for installing, configuring, and
1532
integrating all of the products used to implement EIG E1B2. For additional details on EIG E1B2’s logical
1533
and physical architectures, please refer to Volume B.
1534
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 62
6.1 Zscaler
1535
Zscaler provides secure user access to public-facing sites and on- or off-premises private applications via
1536
the Zscaler Zero Trust Exchange, a cloud-delivered security service edge technology. The Zscaler Internet
1537
Access (ZIA) manages user access to the internet. Zscaler Private Access (ZPA) manages user access to
1538
applications within an enterprise. Zscaler integrates with Okta for authentication and authorization of
1539
users.
1540
To begin, contact Zscaler to create an instance of ZIA and ZPA. To do this, Zscaler will need the FQDN of
1541
the enterprise using ZIA and ZPA. Admin user information will need to be provided to Zscaler to create
1542
admin accounts. Refer to documents for ZIA and ZPA.
1543
6.1.1 Zscaler ZPA Configuration and Integration
1544
Once admin access available, log in to ZPA to perform the following:
1545
1. Create additional admin accounts as needed.
1546
2. Create an Zscaler App Connector Group and Zscaler App Connector in the ZPA portal. Note: App
1547
Connector Groups are recommended by Zscaler for availability and scaling. Note: This build has
1548
two App Connector Groups, one for on-prem applications and one for cloud applications in
1549
AWS.
1550
3. Once the App Connector is configured in the ZPA portal, install the actual Zscaler App connector.
1551
Refer to the Zscaler Application Connector section below. Note: This build has two App
1552
Connectors, one for on-prem applications and one for cloud applications in AWS.
1553
4. Create integration with Okta. All users accessing resources within the enterprise will use two-
1554
factor authentication when logging into the Zscaler Client Connector. Note: Step 1 of
1555
configuration is completed in the Okta cloud. Refer to Section 6.2. Step 2 of configuration is
1556
completed on the ZPA admin portal.
1557
5. Deploy Zscaler Client Connectors (ZCCs) for various endpoints, including configuring ZCC policies
1558
to control the settings and behavior of ZCC. Refer to the Zscaler Client Connector section below.
1559
6. Set up ZPA Application configuration for access to resources. In this step, applications are
1560
defined and applied to segments so that the proper App Connector can perform PEP functions.
1561
7. Configure Access Policies to control user access to various applications. For our policies, we
1562
defined specific App Segments, configured specific IDP authentication parameters, and
1563
configured client posture checks.
1564
8. Configure a log receiver for the IBM QRadar SIEM tool to receive logs for ZPA.
1565
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 63
6.1.2 Zscaler ZIA Configuration
1566
Once admin access is available, login to ZIA to perform the following:
1567
1. Create additional admin accounts as needed.
1568
2. Set up IdP integration with Okta.
1569
3. Create policies to manage user access to various resources on the internet. For this build, we
1570
used many of the defaults built into ZIA. We created policies to allow certain users access to a
1571
resource on the internet and block certain users based on their role and time of day.
1572
4. Integrate ZIA Nanolog Streaming Service with IBM QRadar SIEM tool to receive ZIA logs.
1573
6.1.3 Zscaler Client Connector
1574
Zscaler Client Connectors (ZCCs) are available for Windows, Mac, Linux, iOS, and Android endpoints.
1575
Deployment of ZCC includes configuring ZCC policies to control the settings and behavior of ZCC. For all
1576
these endpoints, a device manager can be leveraged to push the ZCC. For this build, we tested the use of
1577
Ivanti to push ZCC to Windows, iOS, and Android endpoints. For other devices we manually installed
1578
ZCC. Once ZCC is installed, users are prompted to login, which allows the user and device to be managed
1579
by ZPA and ZIA, depending on the type of resource the user is accessing.
1580
6.1.4 Zscaler Application Connector
1581
The Zscaler Application Connector is installed and configured on the same subnet where the resource
1582
will be protected. For this build, we use the documentation for Linux OS to install the App Connector.
1583
Zscaler supports other operating systems. Repeat steps 1 and 2 in the configuration section if an
1584
application residing in a different subnet segment needs to be protected. If that application is in the
1585
same subnet, then only one App Connector is needed to protect both applications.
1586
6.2 Okta Identity Cloud
1587
For this build, the integration between Okta and Ivanti was disabled in Okta Identity Cloud. Users logging
1588
into a resource are authenticated via Okta with a password for the first factor and Okta Verify for the
1589
second factor. Use the link for integration with Zscaler to configure Okta.
1590
No changes were made from Build 1 Sections 2.1.2 and 2.1.3 (Okta Access Gateway). Refer to those
1591
sections for configuration details.
1592
6.3 Radiant Logic RadiantOne
1593
No changes were made from Build 1. Refer to Section 2.2.
1594
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 64
6.4 SailPoint IdentityIQ
1595
No changes were made from Build 1. Refer to Section 2.3.
1596
6.5 Ivanti Neurons for UEM
1597
No significant changes were made from Build 1. Ivanti Neurons for UEM was configured to deploy the
1598
Zscaler Client Connector to managed devices. For information, configuration and integration
1599
instructions, refer to Section 2.4.
1600
6.6 IBM Security QRadar XDR
1601
For installation, configuration, and integration instructions, refer to Section 2.9.
1602
6.7 Tenable.io
1603
For installation, configuration, and integration instructions, refer to Section 2.10.
1604
6.8 Tenable.ad
1605
For installation, configuration, and integration instructions, refer to Section 2.11.
1606
6.9 Tenable NNM
1607
For installation, configuration, and integration instructions, refer to Section 2.12.
1608
6.10 Mandiant Security Validation (MSV)
1609
For installation, configuration, and integration instructions, refer to Section 2.13.
1610
6.11 DigiCert CertCentral
1611
For setup and usage instructions, refer to Section 2.14.
1612
6.12 AWS IaaS
1613
Amazon Web Services is a cloud computing platform provided by Amazon that includes a mixture of
1614
IaaS, platform-as-a-service (PaaS), and SaaS offerings. The following section describes the setup of AWS
1615
IaaS resources to serve as a public/private cloud host.
1616
For details on the logical architecture the AWS environment, please refer to Volume B, Section 4.4.9.1.
1617
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 65
6.12.1 Configuration
1618
The purpose of this subsection is to provide an outline of how to set up a cloud infrastructure to provide
1619
a platform to host public and private resources which integrate with products from EIG E1B2. AWS
1620
CloudFormation templates were used during the build of the AWS IaaS environment but are considered
1621
outside of the scope of this document. More information about CloudFormation may be found here.
1622
1. Create and activate an AWS account. Use the root account to create administrative accounts
1623
with rights to create necessary resources for the project.
1624
2. Create a Production and Management Virtual Private Cloud (VPC). Configure ingress and egress
1625
Security Group rules for each VPC.
1626
3. Create Transit gateways to attach on-prem networks to the AWS environment. Create Internet
1627
gateways for access to the internet.
1628
4. Within the Prod VPC, configure redundant public subnets in different Availability Zones for fault
1629
tolerance. Configure redundant private subnets for Web, Application, and Database tiers.
1630
5. Set up resources for testing in the Prod VPC. For demonstration purposes, a private WordPress
1631
and GitLab server pair and a public WordPress server were built. Configure auto scaling and
1632
Elastic Load Balancing for servers/services set up on the Web, Application, and Database tiers.
1633
6. Within the Mgmt VPC, configure redundant public subnets in different Availability Zones for
1634
fault tolerance. Configure private subnets for Satellite, Domain Controller, and Security
1635
Management Tiers.
1636
7. Set up AWS Session Manager access for remote admins.
1637
8. For shared AWS services, configure VPC endpoints with ICAM policies to control access.
1638
7 Enterprise 3 Build 2 (EIG E3B2) Product Guides
1639
This section of the practice guide contains detailed instructions for installing, configuring, and
1640
integrating all the products used to implement EIG E3B2. For additional details on EIG E3B2’s logical and
1641
physical architectures, please refer to Volume B.
1642
7.1 Microsoft Azure Active Directory (AD)
1643
For setup and usage instructions, refer to Section 4.1.
1644
7.2 Microsoft Azure AD Identity Protection
1645
This section offers a guide for setting up the various components that make up Azure AD Identity
1646
Protection in your environment.
1647
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 66
1. To ensure that all users register for multifactor authentication, configure Azure AD Multifactor
1648
Authentication registration policy using the information found at Configure MFA Registration
1649
Policy.
1650
2. Sign-in risk policy enables detection of and response to suspicious logon sessions and unusual
1651
logon activity. Use the information found at Configure Sign-in Risk Policy to configure the sign-in
1652
risk policy.
1653
3. User-risk policy enables detection of and response to compromised user accounts. To configure
1654
this policy, use the information found at Configure User-Risk Policy.
1655
7.3 Microsoft Azure AD Identity Governance
1656
Azure AD Identity Governance enables organizations to manage access to resources applying access
1657
request and approval workflows, access assignments and removals, access expiration, and access
1658
reviews.
1659
1. Create an access package to encapsulate the target resources in a single object.
1660
2. Create policies to define approvers and eligible requestors.
1661
3. Requesting access to the access package can be done using the information found at Request
1662
access.
1663
4. To approve or deny access requests, use the information found at Approve or deny request.
1664
7.4 Microsoft Intune
1665
For setup and usage instructions of Intune (formerly called Endpoint Manager), refer to Section 4.2.
1666
7.5 Microsoft Defender for Endpoint
1667
For setup and usage instructions, refer to Section 4.3.
1668
7.6 Microsoft Defender for Cloud Apps
1669
Microsoft Defender for Cloud Apps is a cloud access broker solution that protects cloud applications and
1670
on-premises web applications by monitoring session activity to those applications, ensuring compliance
1671
to defined policy and mitigating detected threats.
1672
1. Login to the portal and activate your Defender for Cloud Apps tenant.
1673
2. Connect your apps to Defender for Cloud Apps. For custom web applications including on-
1674
premises web applications, use the information on connecting a custom app to Defender for
1675
Cloud Apps to integrate your custom web applications.
1676
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 67
3. Use the information on creating and assigning policies to provide security controls to apps,
1677
ensuring compliance and mitigating threats.
1678
4. Deploy Conditional Access App Control, which leverages Azure AD conditional access policies
1679
and enforcement for connected apps.
1680
7.7 Microsoft Azure AD Application Proxy
1681
Azure AD Application Proxy enables users to securely connect to internal applications via the Internet. It
1682
has two components, Application Proxy service and Application Proxy connector, which work together
1683
to provide access to the internal application.
1684
1. Configure Application Proxy deployment prerequisites.
1685
2. Install and register the Application Proxy connectors. Once the application proxy connectors are
1686
successfully installed and registered, the Application Proxy service will be enabled automatically.
1687
3. Add your application to Application Proxy.
1688
7.8 Microsoft Defender for Cloud
1689
Defender for Cloud is a SaaS-based cloud security posture management and cloud workload protection
1690
platform. It enables organizations to monitor their cloud and on-premises resources, determine
1691
differences and security issues based on benchmark and regulations, and provide recommendations to
1692
help remediate the issues. Within Defender for Cloud, benchmarks and regulations encapsulate policies
1693
that are used as baselines to measure how compliant your environment is. This leads to the generation
1694
of a secure score.
1695
1. Enable Defender for Cloud for your subscription.
1696
2. To receive a secure score, which provides a numeric value indicating your point-in-time security
1697
posture, you must ensure that the Azure Security Benchmark initiative or at least one other
1698
listed regulation are selected and applied to your subscription. Azure Security Benchmark should
1699
automatically apply to your subscription. Examples of regulations include PCI/DSS, HIPAA, and
1700
NIST SP 800-53. Azure Security Benchmark is comprised of a set of controls that detect security
1701
misconfigurations based on best practices from common compliance frameworks.
1702
3. Apply regulations to your subscription.
1703
4. Defender for Cloud will list recommendations for your environment to improve the security
1704
posture. Apply the listed security recommendations.
1705
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 68
7.9 Microsoft Sentinel
1706
For setup and usage instructions, refer to Section 4.4.
1707
7.10 Microsoft Office 365
1708
For setup and usage instructions, refer to Section 4.5.
1709
7.11 F5 BIG-IP
1710
For setup and usage instructions, refer to Section 4.6.
1711
7.12 PC Matic Pro
1712
For setup and usage instructions, refer to Section 4.8.
1713
7.13 Tenable.io
1714
For setup and usage instructions, refer to Section 2.10.
1715
7.14 Tenable.ad
1716
For setup and usage instructions, refer to Section 2.11.
1717
7.15 Tenable NNM
1718
For setup and usage instructions, refer to Section 2.12.
1719
7.16 Mandiant Security Validation (MSV)
1720
For setup and usage instructions, refer to Section 2.13.
1721
7.17 Forescout eyeSight
1722
Forescout eyeSight provides asset discovery with both active and passive techniques, and through
1723
integrations with network and security infrastructure.
1724
For installation, configuration, and integration instructions, refer to Section 4.13.
1725
7.18 Forescout eyeControl
1726
Forescout eyeControl enforces and automates network policies across the enterprise.
1727
For Forescout eyeControl installation instructions, visit the Forescout Installation Overview.
1728
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 69
7.18.1 Configuring a policy
1729
1. In the Forescout Console, choose a policy.
1730
5. Select the network segment to which the policy will be applied.
1731
6. Add Conditions to select the attributes of the hosts that the policy will be applied to.
1732
7. Add Actions that will be applied to the selected hosts.
1733
8. Add any additional rules that will be used in the policy.
1734
9. Run the policy.
1735
7.19 Forescout eyeSegment
1736
Forescout eyeSegment accelerates zero trust segmentation through visibility into traffic and transaction
1737
flows.
1738
For Forescout eyeSegment installation instructions, visit the Forescout Installation Overview. After
1739
installation has been completed, visit the eyeSegment Application How-to Guide to configure and use
1740
eyeSegment to analyze your network traffic from a dynamic zone perspective, simplify segmentation
1741
planning, and automate ACL/VLAN assignment.
1742
7.19.1 Access the eyeSegment Dashboard
1743
1. From the Forescout Console, click Dashboards. This will launch a web browser and authenticate
1744
to the Forescout Web Client.
1745
2. At the top of the Forescout Web Client, click Segmentation.
1746
3. The initial dashboard is the eyeSegment Matrix. This dashboard can be used to analyze traffic
1747
and transaction flows between different network hosts, segments, and groups.
1748
4. Open the eyeSegment Policy dashboard, which can be used to apply proposed Zero Trust rules.
1749
The effect of these rules can be seen in the eyeSegment Matrix.
1750
5. Open the eyeSegment Health dashboard, which provides information about Reporting
1751
Appliances, Traffic Sensors, Endpoint Coverage, and the connection to the eyeSegment cloud.
1752
7.20 Forescout eyeExtend
1753
Forescout eyeExtend automates security workflows across disparate products through integration with
1754
other security technologies.
1755
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 70
For Forescout eyeExtend installation instructions, visit the Forescout Installation Overview. Once
1756
installation has been completed, visit the Connect Plugin Configuration Guide, which provides the
1757
capability to build custom integrations with products that are not already provided. However, Forescout
1758
also provides a wide range of integrations at the official Forescout eyeExtend repository.
1759
7.20.1 Integration with Microsoft Endpoint Manager
1760
Integration instructions for Microsoft Endpoint Manager can be found at Forescout’s official GitHub
1761
repository: https://github.com/Forescout/eyeExtend-Connect/tree/master/Intune.
1762
7.21 Palo Alto Next Generation Firewall
1763
For setup and usage instructions, refer to Section 3.5.
1764
7.22 DigiCert CertCentral
1765
For setup and usage instructions, refer to Section 2.14.
1766
7.23 Microsoft Azure IaaS
1767
Azure IaaS provides compute, networking, and storage services that enable the creation of an enterprise
1768
IT infrastructure by subscribers. The following section describes the Azure IaaS components that were
1769
deployed in this build.
1770
1. Virtual Networks (VNETs) are isolated customer networks. They contain subnets and are built in
1771
Azure. We have three VNETs, hub VNET which provides central connectivity for other VNETs,
1772
and two additional VNETs, a GitLab VNET and a WordPress VNET, designed to protect individual
1773
apps and their associated resources. Use the information at Create a VNET to create and
1774
configure a virtual network. To enable communication between the hub and other VNETs,
1775
establish peering between them.
1776
2. Public VNETs are regular VNETs that have hosts with public IP addresses. The GitLab VNET is
1777
configured as public subnet with a public IP address attached to the Application Gateway which
1778
was configured to provide load balancing and protection against common web attacks.
1779
3. Private VNETs are regular VNETs that have hosts with only private IP addresses and are
1780
reachable only by internal users by default. WordPress VNET was configured as a private VNET.
1781
4. Configure Azure Bastion to enable web-based SSH and remote desktop-based access to servers
1782
and virtual machines.
1783
5. Instantiate and configure Azure Firewall in the hub VNET to provide protection for incoming
1784
traffic from both the Internet and the VPN traffic from on-prem clients.
1785
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 71
6. Use network security groups (NSGs) to filter inbound or outbound traffic to or from Azure
1786
resources. Enable only ports that are necessary for appropriate access.
1787
7. Azure App Gateway is a web traffic load balancer that can detect and stop common web attacks.
1788
The Azure App Gateway was configured to protect the GitLab application servers, as the
1789
WordPress servers. Use the information at Application Gateway Quickstart to configure the
1790
Application Gateway.
1791
1792
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 72
Appendix A List of Acronyms
1793
AAD
(Microsoft) Azure Active Directory
AD
Active Directory
AG
(Okta) Access Gateway
API
Application Programming Interface
APM
Access Policy Manager
APNs
Apple Push Notification service
CA
Certificate Authority
CEF
Common Event Format
CRADA
Cooperative Research and Development Agreement
CSR
Certificate Signing Request
DN
Domain Name
DNS
Domain Name System
E1B1
EIG Enterprise 1 Build 1
E1B2
EIG Enterprise 1 Build 2
E2B1
EIG Enterprise 2 Build 1
E3B1
EIG Enterprise 3 Build 1
E3B2
EIG Enterprise 3 Build 2
EDR
Endpoint Detection and Response
EIG
Enhanced Identity Governance
EO
Executive Order
FQDN
Fully Qualified Domain Name
HDAP
High-Availability Directory Access Protocol
HR
Human Resources
IaaS
Infrastructure as a Service
IaC
Infrastructure as Code
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 73
ICAM
Identity, Credential, and Access Management
IdP
Identity Provider
IP
Internet Protocol
IT
Information Technology
ITL
Information Technology Laboratory
LDAP
Lightweight Directory Access Protocol
MAM
Mobile Access Management
MDM
Mobile Device Management
MEM
Microsoft Endpoint Manager
MES
(Lookout) Mobile Endpoint Security
MFA
Multi-Factor Authentication
MSV
Mandiant Security Validation
MTD
Mobile Threat Defense
NCCoE
National Cybersecurity Center of Excellence
NGFW
Next-Generation Firewall
NIST
National Institute of Standards and Technology
NNM
(Tenable) Nessus Network Monitor
NSG
Network Security Group
NTP
Network Time Protocol
OS
Operating System
OU
Organizational Unit
OVA
Okta Verify App, Open Virtual Appliance
PA
Policy Administration
PaaS
Platform as a Service
PDP
Policy Decision Point
PE
Policy Engine
SECOND PRELIMINARY DRAFT
NIST SP 1800-35C: Implementing a Zero Trust Architecture 74
PEP
Policy Enforcement Point
SaaS
Software as a Service
SAML
Security Assertion Markup Language
SIEM
Security Information and Event Management
SOAR
Security Orchestration, Automation, and Response
SP
Special Publication
SSL
Secure Sockets Layer
SSO
Single Sign-On
SSPR
Single Sign-On Password Reset
TLS
Transport Layer Security
UAC
User Account Control
UDP
User Datagram Protocol
UEM
Unified Endpoint Management
URL
Uniform Resource Locator
VLAN
Virtual Local Area Network
VNET
Virtual Network
VPC
Virtual Private Cloud
VPN
Virtual Private Network
ZCC
Zscaler Client Connector
ZIA
Zscaler Internet Access
ZPA
Zscaler Private Access
ZSO
Zero Sign-On
ZTA
Zero Trust Architecture