Implementing a Zero Trust Architecture, Volume B: Approach, Architecture, and Security Characteristics

NIST SPECIAL PUBLICATION 1800-35B

Implementing a Zero Trust Architecture

Volume B:

Approach, Architecture, and Security Characteristics

Oliver Borchert

Gema Howell

Alper Kerman

Scott Rose

Murugiah Souppaya

National Institute of

Standards and Technology

Gaithersburg, MD

Jason Ajmo

Yemi Fashina

Parisa Grayeli

Joseph Hunt

Jason Hurlburt

Nedu Irrechukwu

Joshua Klosterman

Oksana Slivina

Susan Symington

Allen Tan

The MITRE Corporation

McLean, VA

Karen Scarfone

Scarfone Cybersecurity

Clifton, VA

Jason Garbis

Peter Gallagher

Appgate

Coral Gables, FL

Adam Cerini

Conrad Fernandes

AWS (Amazon Web Services)

Arlington, VA

Kyle Black

Sunjeet Randhawa

Broadcom Software

San Jose, CA

Peter Romness

Steve Vetter

Cisco

Herndon, VA

Corey Bonnell

Dean Coclin

DigiCert

Lehi, UT

Ryan Johnson

Dung Lam

Seattle, WA

Tim Jones

Tom May

Forescout

San Jose, CA

Tim Knudson

Google Cloud

Mill Valley, CA

Mike Spisak

Harmeet Singh

IBM

Armonk, NY

Corey Lund

Farhan Saifudin

Ivanti

South Jordan, UT

Hashim Khan

Tim LeMaster

Lookout

Reston, VA

Ken Durbin

Earl Matthews

Mandiant

Reston, VA

Clay Taylor

Tarek Dawoud

Microsoft

Redmond, WA

Vinu Panicker

Okta

San Francisco, CA

Sean Morgan

Palo Alto Networks

Santa Clara, CA

Zack Austin

PC Matic

Myrtle Beach, SC

Bryan Rosensteel

Mitchell Lewars

Ping Identity

Denver, CO

Wade Ellery

Deborah McGinn

Radiant Logic

Novato, CA

Frank Briguglio

Ryan Tighe

SailPoint

Austin, TX

Chris Jensen

Joshua Moll

Tenable

Columbia, MD

Jason White

Trellix, Public Sector

Reston, VA

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-35B: Implementing a Zero Trust Architecture ii

DISCLAIMER

Certain commercial entities, equipment, products, or materials may be identified by name or company

logo or other insignia in order to acknowledge their participation in this collaboration or to describe an

experimental procedure or concept adequately. Such identification is not intended to imply special

status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it

intended to imply that the entities, equipment, products, or materials are necessarily the best available

for the purpose.

While NIST and the NCCoE address goals of improving management of cybersecurity and privacy risk

through outreach and application of standards and best practices, it is the stakeholder’s responsibility to

fully perform a risk assessment to include the current threat, vulnerabilities, likelihood of a compromise,

and the impact should the threat be realized before adopting cybersecurity measures such as this

recommendation.

National Institute of Standards and Technology Special Publication 1800-35B, Natl. Inst. Stand. Technol.

Spec. Publ. 1800-35B, 185 pages, (December 2022), CODEN: NSPUE2

FEEDBACK

You can improve this guide by contributing feedback. As you review and adopt this solution for your

own organization, we ask you and your colleagues to share your experience and advice with us.

Comments on this publication may be submitted to: nccoe-[email protected].

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

All comments are subject to release under the Freedom of Information Act.

National Cybersecurity Center of Excellence

National Institute of Standards and Technology

100 Bureau Drive

Mailstop 2002

Gaithersburg, MD 20899

Email: ncc[email protected]

SECOND PRELIMINARY DRAFT

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

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards

and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and

academic institutions work together to address businesses’ most pressing cybersecurity issues. This

public-private partnership enables the creation of practical cybersecurity solutions for specific

industries, as well as for broad, cross-sector technology challenges. Through consortia under

Cooperative Research and Development Agreements (CRADAs), including technology partners—from

Fortune 50 market leaders to smaller companies specializing in information technology security—the

NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity

solutions using commercially available technology. The NCCoE documents these example solutions in

the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework

and details the steps needed for another entity to re-create the example solution. The NCCoE was

established in 2012 by NIST in partnership with the State of Maryland and Montgomery County,

Maryland.

To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit

https://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES

NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity

challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the

adoption of standards-based approaches to cybersecurity. They show members of the information

security community how to implement example solutions that help them align with relevant standards

and best practices, and provide users with the materials lists, configuration files, and other information

they need to implement a similar approach.

The documents in this series describe example implementations of cybersecurity practices that

businesses and other organizations may voluntarily adopt. These documents do not describe regulations

or mandatory practices, nor do they carry statutory authority.

ABSTRACT

A zero trust architecture (ZTA) focuses on protecting data and resources. It enables secure authorized

access to enterprise resources that are distributed across on-premises and multiple cloud environments,

while enabling a hybrid workforce and partners to access resources from anywhere, at any time, from

any device in support of the organization’s mission. Each access request is evaluated by verifying the

context available at access time, including criteria such as the requester’s identity and role, the

requesting device’s health and credentials, the sensitivity of the resource, user location, and user

behavior consistency. If the enterprise’s defined access policy is met, a secure session is created to

protect all information transferred to and from the resource. A real-time and continuous policy-driven,

SECOND PRELIMINARY DRAFT

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

risk-based assessment is performed to establish and maintain the access. In this project, the NCCoE and

its collaborators use commercially available technology to build interoperable, open, standards-based

ZTA implementations that align to the concepts and principles in NIST Special Publication (SP) 800-207,

Zero Trust Architecture. This NIST Cybersecurity Practice Guide explains how commercially available

technology can be integrated and used to build various ZTAs.

KEYWORDS

enhanced identity governance (EIG); identity, credential, and access management (ICAM); zero trust;

zero trust architecture (ZTA).

ACKNOWLEDGMENTS

We are grateful to the following individuals for their generous contributions of expertise and time.

Name

Organization

Quint Van Deman

Amazon Web Services

Aaron Palermo

Appgate

Adam Rose

Appgate

Jonathan Roy

Appgate

Eric Michael

Broadcom Software

Ken Andrews

Cisco

Matthew Hyatt

Cisco

Leo Lebel

Cisco

Tom Oast

Cisco

Aaron Rodriguez

Cisco

Micah Wilson

Cisco

Daniel Cayer

SECOND PRELIMINARY DRAFT

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

Name

Organization

David Clark

Jay Kelley

Yejin Jang

Forescout

Neal Lucier

Forescout

Andrew Campagna

IBM

Adam Frank

IBM

Nalini Kannan

IBM

Priti Patil

IBM

Nikhil Shah

IBM

Krishna Yellepeddy

IBM

Vahid Esfahani

IT Coalition

Ebadullah Siddiqui

IT Coalition

Musumani Woods

IT Coalition

Tyler Croak

Lookout

Madhu Dodda

Lookout

Jeff Gilhool

Lookout

James Elliott

Mandiant

David Pricer

Mandiant

SECOND PRELIMINARY DRAFT

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

Name

Organization

Joey Cruz

Microsoft

Janet Jones

Microsoft

Carmichael Patton

Microsoft

Hemma Prafullchandra

Microsoft

Brandon Stephenson

Microsoft

Sarah Young

Microsoft

Eileen Division

MITRE*

Spike Dog

MITRE

Sallie Edwards

MITRE

Ayayidjin Gabiam

MITRE

Jolene Loveless

MITRE

Karri Meldorf

MITRE

Kenneth Sandlin

MITRE

Lauren Swan

MITRE

Jessica Walton

MITRE

Mike Bartock

NIST

Douglas Montgomery

NIST

Kevin Stine

NIST

SECOND PRELIMINARY DRAFT

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

Name

Organization

Sean Frazier

Okta

Kelsey Nelson

Okta

Shankar Chandrasekhar

Palo Alto Networks

Andrew Keffalas

Palo Alto Networks

Seetal Patel

Palo Alto Networks

Norman Wong

Palo Alto Networks

Shawn Higgins

PC Matic

Andy Tuch

PC Matic

Rob Woodworth

PC Matic

Ivan Anderson

Ping Identity

Bill Baz

Radiant Logic

Don Coltrain

Radiant Logic

Rusty Deaton

Radiant Logic

John Petrutiu

Radiant Logic

Lauren Selby

Radiant Logic

Peter Amaral

SailPoint

Jim Russell

SailPoint

Esteban Soto

SailPoint

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: 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

The Technology Partners/Collaborators who have or will participate in this project’s current or upcoming

builds submitted their capabilities in response to a notice in the Federal Register. Respondents with

relevant capabilities or product components were invited to sign a Cooperative Research and

Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build this

example solution. We are working with the following list of collaborators.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture ix

Technology Collaborators

Appgate

IBM

Ping Identity

AWS

Ivanti

Radiant Logic

Broadcom Software

Lookout

SailPoint

Cisco

Mandiant

Tenable

DigiCert

Microsoft

Trellix

Okta

VMware

Forescout

Palo Alto Networks

Zimperium

Google Cloud

PC Matic

Zscaler

DOCUMENT CONVENTIONS

The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the

publication and from which no deviation is permitted. The terms “should” and “should not” indicate that

among several possibilities, one is recommended as particularly suitable without mentioning or

excluding others, or that a certain course of action is preferred but not necessarily required, or that (in

the negative form) a certain possibility or course of action is discouraged but not prohibited. The terms

“may” and “need not” indicate a course of action permissible within the limits of the publication. The

terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

CALL FOR PATENT CLAIMS

This public review includes a call for information on essential patent claims (claims whose use would be

required for compliance with the guidance or requirements in this Information Technology Laboratory

(ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication

or by reference to another publication. This call also includes disclosure, where known, of the existence

of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant

unexpired U.S. or foreign patents.

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in

written or electronic form, either:

a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not

currently intend holding any essential patent claim(s); or

b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring

to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft

publication either:

1. under reasonable terms and conditions that are demonstrably free of any unfair discrimination;

100

101

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture x

2. without compensation and under reasonable terms and conditions that are demonstrably free

102

of any unfair discrimination.

103

Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its

104

behalf) will include in any documents transferring ownership of patents subject to the assurance,

105

provisions sufficient to ensure that the commitments in the assurance are binding on the transferee,

106

and that the transferee will similarly include appropriate provisions in the event of future transfers with

107

the goal of binding each successor-in-interest.

108

The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of

109

whether such provisions are included in the relevant transfer documents.

110

Such statements should be addressed to: nccoe-zta-[email protected]

111

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture xi

Contents

112

1 Summary ............................................................................................. 1

113

1.1 Challenge ....................................................................................................................... 1

114

1.2 Solution.......................................................................................................................... 2

115

1.3 Benefits .......................................................................................................................... 3

116

2 How to Use This Guide ......................................................................... 4

117

2.1 Typographic Conventions .............................................................................................. 6

118

3 Approach ............................................................................................. 7

119

3.1 Audience ........................................................................................................................ 8

120

3.2 Scope ............................................................................................................................. 9

121

3.3 Assumptions ................................................................................................................ 10

122

3.4 Collaborators and Their Contributions ........................................................................ 10

123

3.4.1 Appgate....................................................................................................................... 11

124

3.4.2 AWS ............................................................................................................................ 12

125

3.4.3 Broadcom Software .................................................................................................... 14

126

3.4.4 Cisco ............................................................................................................................ 17

127

3.4.5 DigiCert ....................................................................................................................... 19

128

3.4.6 F5 ................................................................................................................................ 20

129

3.4.7 Forescout .................................................................................................................... 22

130

3.4.8 Google Cloud .............................................................................................................. 23

131

3.4.9 IBM.............................................................................................................................. 24

132

3.4.10 Ivanti ........................................................................................................................... 26

133

3.4.11 Lookout ....................................................................................................................... 28

134

3.4.12 Mandiant .................................................................................................................... 28

135

3.4.13 Microsoft .................................................................................................................... 29

136

3.4.14 Okta ............................................................................................................................ 33

137

3.4.15 Palo Alto Networks ..................................................................................................... 35

138

3.4.16 PC Matic ...................................................................................................................... 37

139

3.4.17 Ping Identity ................................................................................................................ 37

140

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture xii

3.4.18 Radiant Logic............................................................................................................... 40

141

3.4.19 SailPoint ...................................................................................................................... 42

142

3.4.20 Tenable ....................................................................................................................... 43

143

3.4.21 Trellix .......................................................................................................................... 44

144

3.4.22 VMware ...................................................................................................................... 47

145

3.4.23 Zimperium .................................................................................................................. 47

146

3.4.24 Zscaler ......................................................................................................................... 48

147

4 Architecture ....................................................................................... 49

148

4.1 General ZTA Reference Architecture .......................................................................... 49

149

4.1.1 ZTA Core Components ................................................................................................ 50

150

4.1.2 ZTA Supporting Components ...................................................................................... 51

151

4.1.3 ZTA in Operation ......................................................................................................... 54

152

4.2 EIG Crawl Phase Reference Architecture .................................................................... 59

153

4.3 EIG Run Phase .............................................................................................................. 62

154

4.4 ZTA Laboratory Physical Architecture ......................................................................... 62

155

4.4.1 Enterprise 1................................................................................................................. 64

156

4.4.2 Enterprise 1 Branch Office .......................................................................................... 69

157

4.4.3 Enterprise 2................................................................................................................. 71

158

4.4.4 Enterprise 3................................................................................................................. 71

159

4.4.5 Enterprise 4................................................................................................................. 71

160

4.4.6 Coffee Shop ................................................................................................................ 71

161

4.4.7 Management and Orchestration Domain .................................................................. 71

162

4.4.8 Emulated WAN Service Provider ................................................................................ 72

163

4.4.9 Cloud Services ............................................................................................................. 72

164

5 Functional Demonstration ................................................................. 77

165

6 General Findings ................................................................................ 77

166

6.1 EIG Crawl Phase Findings ............................................................................................ 77

167

6.2 EIG Run Phase Findings ............................................................................................... 78

168

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture xiii

7 Future Build Considerations ............................................................... 80

169

Appendix A List of Acronyms ................................................................. 81

170

Appendix B Glossary .............................................................................. 87

171

Appendix C References .......................................................................... 89

172

Appendix D EIG Enterprise 1 Build 1 (E1B1) ............................................ 90

173

D.1 Technologies ................................................................................................................ 90

174

D.2 Build Architecture........................................................................................................ 94

175

D.2.1 Logical Architecture .................................................................................................... 94

176

D.2.2 ICAM Information Architecture .................................................................................. 95

177

D.2.3 Physical Architecture ................................................................................................ 107

178

D.2.4 Message Flow for a Successful Resource Access Request ....................................... 107

179

Appendix E EIG Enterprise 2 Build 1 (E2B1) .......................................... 111

180

E.1 Technologies .............................................................................................................. 111

181

E.2 Build Architecture...................................................................................................... 115

182

E.2.1 Logical Architecture .................................................................................................. 115

183

E.2.2 ICAM Information Architecture ................................................................................ 116

184

E.2.3 Physical Architecture ................................................................................................ 128

185

E.2.4 Message Flow for a Successful Resource Access Request ....................................... 128

186

Appendix F EIG Enterprise 3 Build 1 (E3B1) .......................................... 131

187

F.1 Technologies .............................................................................................................. 131

188

F.2 Build Architecture...................................................................................................... 135

189

F.2.1 Logical Architecture .................................................................................................. 135

190

F.2.2 Physical Architecture ................................................................................................ 136

191

F.2.3 Message Flows for a Successful Resource Access Request ...................................... 136

192

Appendix G EIG Enterprise 4 Build 1 (E4B1) .......................................... 141

193

Appendix H EIG Enterprise 1 Build 2 (E1B2) .......................................... 142

194

H.1 Technologies .............................................................................................................. 142

195

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture xiv

H.2 Build Architecture...................................................................................................... 146

196

H.2.1 Logical Architecture .................................................................................................. 146

197

H.2.2 ICAM Information Architecture ................................................................................ 147

198

H.2.3 Physical Architecture ................................................................................................ 148

199

H.2.4 Message Flows for Successful Resource Access Requests ....................................... 148

200

Appendix I EIG Enterprise 2 Build 2 (E2B2) .......................................... 155

201

Appendix J EIG Enterprise 3 Build 2 (E3B2) .......................................... 156

202

J.1 Technologies .............................................................................................................. 156

203

J.2 Build Architecture...................................................................................................... 161

204

J.2.1 Logical Architecture .................................................................................................. 161

205

J.2.2 Physical Architecture ................................................................................................ 162

206

J.2.3 Message Flows for a Successful Resource Access Request ...................................... 162

207

List of Figures

208

Figure 4-1 General ZTA Reference Architecture ................................................................................. 50

209

Figure 4-2 EIG Crawl Phase Reference Architecture ........................................................................... 61

210

Figure 4-3 Physical Architecture of ZTA Lab ....................................................................................... 63

211

Figure 4-4 Physical Architecture of Enterprise 1 ................................................................................ 65

212

Figure 4-5 Shared Services Domain of Enterprise 1 ............................................................................ 67

213

Figure 4-6 Physical Architecture of the Enterprise 1 Branch Office ..................................................... 70

214

Figure 4-7 Physical Architecture of the Coffee Shop .......................................................................... 71

215

Figure 4-8 Physical Architecture of the Management and Orchestration Domain ............................... 72

216

Figure 4-9 Physical Architecture of the AWS Infrastructure Used by Enterprise 1 ............................... 74

217

Figure 4-10 Physical Architecture of the Azure Infrastructure Used by Enterprise 3 ............................ 76

218

Figure D-1 Logical Architecture of E1B1 ............................................................................................. 95

219

Figure D-2 E1B1 ICAM Information Architecture – Identity Correlation .............................................. 98

220

Figure D-3 E1B1 ICAM Information Architecture – New User Onboarding ........................................ 101

221

Figure D-4 E1B1 ICAM Information Architecture - User Changes Roles ............................................. 104

222

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture xv

Figure D-5 E1B1 ICAM Information Architecture - User Termination ................................................ 106

223

Figure D-6 Successful Access Request Enforced by Okta, Ivanti, and Zimperium Components ........... 108

224

Figure E-1 Logical Architecture of E2B1 ........................................................................................... 116

225

Figure E-2 E2B1 ICAM Information Architecture – Identity Correlation ............................................. 119

226

Figure E-3 E2B1 ICAM Information Architecture – New User Onboarding ......................................... 122

227

Figure E-4 E2B1 ICAM Information Architecture - User Changes Roles .............................................. 125

228

Figure E-5 E2B1 ICAM Information Architecture - User Termination ................................................. 127

229

Figure E-6 Use Case—E2B1 – Access Enforced by Ping Federate, Cisco Duo, and Radiant Logic .......... 129

230

Figure F-1 Logical Architecture of E3B1 ........................................................................................... 136

231

Figure F-2 Use Case—E3B1 – Access Enforced by Azure AD .............................................................. 138

232

Figure F-3 Use Case—E3B1 – Access Enforced by F5 BIG-IP .............................................................. 139

233

Figure H-1 Logical Architecture of E1B2 ........................................................................................... 147

234

Figure H-2 Access to an Internal Resource is Enforced by Zscaler ZPA and Okta Identity Cloud ......... 150

235

Figure H-3 Access to an Externally-Facing Resource is Enforced by Zscaler ZIA and Okta Identity Cloud

236

...................................................................................................................................................... 152

237

Figure J-1 Logical Architecture of E3B2 ............................................................................................ 162

238

Figure J-2 Use Case— E3B2 – Access to an Internal Resource is Enforced by Azure AD and Azure AD’s

239

Application Proxy ........................................................................................................................... 165

240

Figure J-3 Use Case— E3B2 – Access to an Externally-Facing Resource is Enforced by Azure AD and

241

Microsoft Defender for Cloud Apps ................................................................................................ 167

242

Figure J-4 Use Case—E3B2 – Forescout Discovers a Non-Compliant Endpoint on the Network and

243

Directs the Palo Alto Firewall to Block it ......................................................................................... 169

244

List of Tables

245

Table 3-1 Technology Partners/Collaborators ................................................................................... 11

246

Table 4-1 Mapping of Builds to Architectures and Appendices ........................................................... 64

247

Table D-1 E1B1 Products and Technologies ....................................................................................... 90

248

Table E-1 E2B1 Products and Technologies ...................................................................................... 111

249

Table F-1 E3B1 Products and Technologies ...................................................................................... 131

250

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture xvi

Table H-1 E1B2 Products and Technologies ..................................................................................... 142

251

Table J-1 E3B2 Products and Technologies ...................................................................................... 156

252

SECOND PRELIMINARY DRAFT

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

1 Summary

253

1.1 Challenge

254

Protecting enterprise resources, particularly data, has become increasingly challenging as resources

255

have become distributed across both on-premises environments and multiple clouds. Many users need

256

access from anywhere, at any time, from any device to support the organization’s mission. Data is

257

programmatically stored, transmitted, and processed across different boundaries under the control of

258

different organizations to meet ever-evolving business use cases. It is no longer feasible to simply

259

enforce access controls at the perimeter of the enterprise environment and assume that all subjects

260

(e.g., end users, applications, and other non-human entities that request information from resources)

261

within it can be trusted. A zero-trust architecture (ZTA) addresses this challenge by enforcing granular,

262

secure authorized access near the resources, whether located on-premises or in the cloud, for both

263

remote and onsite workforces and partners based on an organization’s defined access policy.

264

Many organizations would like to address these challenges by migrating to a ZTA, but they have been

265

hindered by several factors, which may include:

266

▪ Lack of adequate asset inventory and management needed to fully understand the business

267

applications, assets, and processes that need to be protected, with no clear understanding of

268

the criticality of these resources

269

▪ Lack of adequate digital definition, management, and tracking of user roles across the

270

organization needed to enforce fine-grained, need-to-know access policy for specific

271

applications and services

272

▪ Ever-increasing complexity of communication flows and distributed IT components across the

273

environments on-premises and in the cloud, making them difficult to manage consistently

274

▪ Lack of visibility of the organization’s communications and usage patterns—limited

275

understanding of the transactions that occur between an organization’s subjects, assets,

276

applications, and services, and absence of the data necessary to identify these communications

277

and their specific flows

278

▪ Lack of awareness regarding everything that encompasses the organization’s entire attack

279

surface. Organizations can usually address threats with traditional security tools in the layers

280

that they currently manage and maintain such as networks and applications, but elements of a

281

As with NIST Special Publication (SP) 800-207 [1], throughout this document subject will be used unless the

section relates directly to a human end user, in which case user will be used instead of the more generic subject.

SECOND PRELIMINARY DRAFT

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

ZTA may extend beyond their normal purview. False assumptions are often made in

282

understanding the health of a device as well as its exposure to supply chain risks.

283

▪ Lack of understanding regarding what interoperability issues may be involved or what additional

284

skills and training administrators, security personnel, operators, end users, and policy decision

285

makers may require; lack of resources to develop necessary policies and a pilot or proof-of-

286

concept implementation needed to inform a transition plan

287

▪ Leveraging existing investments and balancing priorities while making progress toward a ZTA via

288

modernization initiatives

289

▪ Integrating various types of commercially available technologies of varying maturities, assessing

290

capabilities, and identifying technology gaps to build a complete ZTA

291

▪ Concern that ZTA might negatively impact the operation of the environment or end-user

292

experience

293

▪ Lack of a standardized policy to distribute, manage, and enforce security policy, causing

294

organizations to face either a fragmentary policy environment or non-interoperable

295

components

296

▪ Lack of common understanding and language of ZTA across the community and within the

297

organization, gauging the organization’s ZTA maturity, determining which ZTA approach is most

298

suitable for the business, and developing an implementation plan

299

▪ Perception that ZTA is suited only for large organizations and requires significant investment

300

rather than understanding that ZTA is a set of guiding principles suitable for organizations of any

301

size

302

▪ There is not a single ZTA that fits all. ZTAs need to be designed and integrated for each

303

organization based on the organization’s requirements and risk tolerance, as well as its existing

304

invested technologies and environments.

305

1.2 Solution

306

This project is designed to help address the challenges discussed above by building, demonstrating, and

307

documenting several example ZTAs using products and technologies from a variety of different vendors.

308

The example solutions are designed to provide secure authorized access to individual resources by

309

enforcing enterprise security policy dynamically and in near-real-time. They restrict access to

310

authenticated, authorized users and devices while flexibly supporting a complex set of diverse business

311

use cases. These use cases involve legacy enterprise networks; remote workforces; use of the cloud; use

312

of corporate-provided, bring your own device (BYOD), and guest endpoints; collaboration with partners;

313

guest users; and support for contractors and other authorized third parties. The example solutions are

314

also designed to demonstrate having visibility within the various environments as well as recognizing

315

both internal and external attacks and malicious actors. They showcase the ability of ZTA products to

316

SECOND PRELIMINARY DRAFT

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

interoperate with legacy enterprise and cloud technologies to protect resources with minimal impact on

317

end-user experience.

318

The concepts and principles in NIST SP 800-207, Zero Trust Architecture are applied to enterprise

319

networks that are composed of pre-established devices and components and that store critical

320

corporate assets and resources both on-premises and in the cloud. For each data access session

321

requested, ZTA verifies the requester’s identity, role, and authorization to access the requested assets,

322

the requesting device’s health and credentials, and possibly other information. If defined policy is met,

323

ZTA dynamically creates a secure connection to protect all information transferred to and from the

324

accessed resource. ZTA performs real-time, continuous behavioral analysis and risk-based assessment of

325

the access transaction or session.

326

The example solutions, which are based on reference architectures, are built starting with a baseline

327

designed to resemble a notional existing enterprise environment that is assumed to have an identity

328

store and other security components in place. This enables the project to represent how a typical

329

enterprise is expected to evolve toward ZTA, i.e., by starting with their already-existing legacy enterprise

330

environment and gradually adding capabilities. A limited version of the enhanced identity governance

331

(EIG) deployment approach described in NIST SP 800-207 was implemented first, during what we refer

332

to as the EIG crawl phase of the project. The first iteration of ZTA implementations is based on the EIG

333

approach because EIG is a foundational component of the other deployment approaches utilized in

334

today’s hybrid environments. The EIG approach uses the identity of subjects and device health as the

335

main determinants of policy decisions. However, instead of using a separate, dedicated component to

336

serve as a policy decision point (PDP), our crawl phase leveraged the identity, credential, and access

337

management (ICAM) components to serve as the PDP.

338

After completing the example solutions that were implemented as part of the EIG crawl phase of the

339

project, the EIG run phase was begun. In the EIG run phase, an EIG approach that is not limited to using

340

an ICAM component as the PDP is being implemented. After that, additional supporting components

341

and features will be deployed to address an increasing number of the ZTA requirements, progressing the

342

project toward eventual demonstration of the micro-segmentation and software-defined perimeter

343

deployment options.

344

1.3 Benefits

345

The demonstrated approach documented in this practice guide can provide organizations wanting to

346

migrate to ZTA with information and confidence that will help them develop transition plans for

347

integrating ZTA into their own legacy environments, based on the example solutions and using a risk-

348

based approach. Executive Order 14028, Improving the Nation’s Cybersecurity [2], requires all federal

349

agencies to develop plans to implement ZTA. This practice guide can inform agencies in developing their

350

ZTA implementation plans. When integrated into their enterprise environments, ZTA will enable

351

organizations to:

352

SECOND PRELIMINARY DRAFT

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

▪ Support teleworkers by enabling them to securely access corporate resources regardless of

353

their location—on-premises, at home, or on public Wi-Fi at a neighborhood coffee shop.

354

▪ Protect resources and assets regardless of their location—on-premises or in the cloud.

355

▪ Provision healthy devices from vendors that can verify that the device is authentic and free of

356

known exploitable vulnerabilities.

357

▪ Limit the insider threat by rejecting the outdated assumption that any user located within the

358

network boundary should be automatically trusted and by enforcing the principle of least

359

privilege.

360

▪ Limit breaches by reducing an attacker’s ability to move laterally in the network. Access controls

361

can be enforced on an individual resource basis, so an attacker who has access to one resource

362

won’t be able to use it as a springboard for reaching other resources.

363

▪ Improve incident detection, response, and recovery to minimize impact when breaches occur.

364

Limiting breaches reduces the footprint of any compromise and the time to recovery.

365

▪ Protect sensitive corporate data by using strong encryption both while data is in transit and

366

while it is at rest. Grant subjects’ access to a specific resource only after enforcing consistent

367

identification, authentication, and authorization procedures, verifying device health, and

368

performing all other checks specified by enterprise policy.

369

▪ Improve visibility into which users are accessing which resources, when, how, and from where

370

by monitoring and logging every access request within every access session.

371

▪ Perform dynamic, risk-based assessment of resource access through continuous reassessment

372

of all access transactions and sessions, gathering information from periodic reauthentication

373

and reauthorization, ongoing device health and posture verification, behavior analysis, ongoing

374

resource health verification, anomaly detection, and other security analytics.

375

2 How to Use This Guide

376

This NIST Cybersecurity Practice Guide will help users develop a plan for migrating to ZTA. It

377

demonstrates a standards-based ZTA reference design and provides users with the information they

378

need to replicate one or more standards-based ZTA implementations that align to the concepts and

379

principles in NIST SP 800-207, Zero Trust Architecture. This reference design is modular and can be

380

deployed in whole or in part, enabling organizations to incorporate ZTA into their legacy environments

381

gradually, in a process of continuous improvement that brings them closer and closer to achieving the

382

ZTA goals that they have prioritized based on risk, cost, and resources.

383

NIST is adopting an agile process to publish this content. Each volume is being made available as soon as

384

possible rather than delaying release until all volumes are completed. Work continues on implementing

385

the example solutions and developing other parts of the content. As a second preliminary draft, we will

386

publish at least one additional draft of this volume for public comment before it is finalized.

387

SECOND PRELIMINARY DRAFT

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

When complete, this guide will contain five volumes:

388

▪ NIST SP 1800-35A: Executive Summary – why we wrote this guide, the challenge we address,

389

why it could be important to your organization, and our approach to solving this challenge

390

▪ NIST SP 1800-35B: Approach, Architecture, and Security Characteristics – what we built and why

391

(you are here)

392

▪ NIST SP 1800-35C: How-To Guides – instructions for building the example implementations,

393

including all the security-relevant details that would allow you to replicate all or parts of this

394

project

395

▪ NIST SP 1800-35D: Functional Demonstrations – use cases that have been defined to showcase

396

ZTA security capabilities and the results of demonstrating them with each of the example

397

implementations

398

▪ NIST SP 1800-35E: Risk and Compliance Management – risk analysis and mapping of ZTA security

399

characteristics to cybersecurity standards and recommended practices

400

Depending on your role in your organization, you might use this guide in different ways:

401

Business decision makers, including chief security and technology officers, will be interested in the

402

Executive Summary, NIST SP 1800-35A, which describes the following topics:

403

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

404

▪ example solution built at the NCCoE

405

▪ benefits of adopting the example solution

406

Technology or security program managers who are concerned with how to identify, understand, assess,

407

and mitigate risk will be interested in this part of the guide, NIST SP 1800-35B, which describes what we

408

did and why. Also, Section 3 of Risk and Compliance Management, NIST SP 1800-35E, will be of

409

particular interest. Section 3, ZTA Reference Architecture Security Mappings, maps logical components

410

of the general ZTA reference design to security characteristics listed in various cybersecurity guidelines

411

and recommended practices documents, including Framework for Improving Critical Infrastructure

412

Cybersecurity (NIST Cybersecurity Framework), Security and Privacy Controls for Information Systems

413

and Organizations (NIST SP 800-53), and Security Measures for “EO-Critical Software” Use Under

414

Executive Order (EO) 14028.

415

You might share the Executive Summary, NIST SP 1800-35A, with your leadership team members to help

416

them understand the importance of migrating toward standards-based ZTA implementations that align

417

to the concepts and principles in NIST SP 800-207, Zero Trust Architecture.

418

IT professionals who want to implement similar solutions will find the whole practice guide useful. You

419

can use the how-to portion of the guide, NIST SP 1800-35C, to replicate all or parts of the builds created

420

in our lab. The how-to portion of the guide provides specific product installation, configuration, and

421

SECOND PRELIMINARY DRAFT

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

integration instructions for implementing the example solution. We do not re-create the product

422

manufacturers’ documentation, which is generally widely available. Rather, we show how we

423

incorporated the products together in our environment to create an example solution. Also, you can use

424

Functional Demonstrations, NIST SP 1800-35D, which provides the use cases that have been defined to

425

showcase ZTA security capabilities and the results of demonstrating them with each of the example

426

implementations.

427

This guide assumes that IT professionals have experience implementing security products within the

428

enterprise. While we have used a suite of commercial products to address this challenge, this guide does

429

not endorse these particular products. Your organization can adopt this solution or one that adheres to

430

these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing

431

parts of a ZTA. Your organization’s security experts should identify the products that will best integrate

432

with your existing tools and IT system infrastructure. We hope that you will seek products that are

433

congruent with applicable standards and best practices. The example solutions in this guide are not

434

intended to be wholly implemented by most enterprise organizations because each organization’s

435

transition to ZT will depend on the organization’s risk profile and tolerance, among other factors.

436

A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. This is a

437

second preliminary draft guide. As the project progresses, this second preliminary draft will be updated,

438

and additional volumes will also be released for comment. We seek feedback on the publication’s

439

contents and welcome your input. Comments, suggestions, and success stories will improve subsequent

440

versions of this guide. Please contribute your thoughts to ncc[email protected].

441

2.1 Typographic Conventions

442

The following table presents typographic conventions used in this volume.

443

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.

SECOND PRELIMINARY DRAFT

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

3 Approach

444

The NCCoE issued an open invitation to technology providers to participate in demonstrating

445

approaches to deploying ZTA in a typical enterprise network environment. The objective was to use

446

commercially available technology to produce example ZTA implementations that manage secure access

447

to corporate resources hosted on-premises or in the cloud while supporting access from anywhere, at

448

any time, using any device.

449

The NCCoE prepared a Federal Register Notice [3] inviting technology providers to provide products

450

and/or expertise to compose prototype ZTAs. Core components sought included ZTA policy engines,

451

policy administrators, and policy enforcement points. Supporting components supporting data security,

452

endpoint security, identity and access management, and security analytics were also requested. In

453

addition, device and network infrastructure components such as laptops, tablets, and other devices that

454

connect to the enterprise were sought, as were data and compute resources, applications, and services

455

that are hosted and managed on-premises, in the cloud, at the edge, or some combination of these. The

456

NCCoE provided a network infrastructure that was designed to encompass the existing (non-ZTA)

457

network resources that a medium or large enterprise might typically have deployed, and the ZTA core

458

and supporting components and devices were integrated into this.

459

Cooperative Research and Development Agreements (CRADAs) were established with qualified

460

respondents, and build teams were assembled. The build teams fleshed out the initial architectures, and

461

the collaborators’ components have so far been composed into five example implementations (i.e.,

462

builds), with several other builds in progress and additional future builds planned. With twenty-four

463

collaborators participating in the project, the build teams that were assembled sometimes included

464

vendors that offer overlapping capabilities. We made an effort to showcase capabilities from each

465

vendor when possible. In other cases, we worked with the collaborators to have them work out a

466

solution. Each build team documented the architecture and design of its build. As each build progressed,

467

its team documented the steps taken to install and configure each component of the build. The teams

468

then conducted functional demonstrations of the builds, including the ability to securely manage access

469

to resources across a set of use cases that were defined to exercise a wide variety of typical enterprise

470

situations. Use cases for the project include the following:

471

▪ access by employees, privileged third parties, and guests

472

▪ access requested by users who are located at headquarters, a branch office, or teleworking via

473

public Wi-Fi and the internet

474

▪ inter-server access

475

▪ protection of resources that are located both on-premises and in the cloud

476

▪ use of enterprise-managed devices, contractor-managed devices, and personal devices

477

▪ access of both corporate resources and publicly available internet services

478

SECOND PRELIMINARY DRAFT

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

▪ the ability to automatically and dynamically calculate fine-grained confidence levels for resource

479

access requests

480

This project began with a clean laboratory environment that we populated with various applications and

481

services that would be expected in a typical enterprise to create several baseline enterprise

482

architectures. First, we designed and built three implementations of the EIG crawl phase deployment

483

approach using a variety of commercial products. Next, we build two implementations of the EIG run

484

phase deployment approach.

485

Given the importance of discovery to the successful implementation of a ZTA, as part of the baseline

486

environment we deployed tools that could be run to continuously observe the environment and use

487

those observations to audit and validate the documented baseline map on an ongoing basis. Because we

488

had instantiated the baseline environment ourselves, we already had a good initial understanding of it.

489

However, we were able to use the discovery tools to audit and validate what we deployed and

490

provisioned, correlate known data with information reported by the tools, and use the tool outputs to

491

formulate initial ZT policy, ultimately ensuring that observed network flows correlate to static policies.

492

EIG uses the identity of subjects and device health as the main determinants of policy decisions.

493

Depending on the current state of identity management in the enterprise, deploying EIG solutions is an

494

initial key step that will be leveraged to support the micro-segmentation and software-defined

495

perimeter (SDP) deployment approaches, which will be covered in the later phases of the project. Our

496

strategy is to follow an agile implementation methodology to build everything iteratively and

497

incrementally while adding more capabilities to evolve to a complete ZTA. We started with the minimum

498

viable EIG solution that allowed us to achieve some level of ZTA and then we gradually deploy additional

499

supporting components and features to address an increasing number of the ZTA requirements,

500

progressing the project toward eventual demonstration of more robust micro-segmentation and SDP

501

deployment options.

502

3.1 Audience

503

The focus of this project is on medium and large enterprises. Its solution is targeted to address the

504

needs of these enterprises, which are assumed to have a legacy network environment and trained

505

operators and network administrators. These operators and administrators are assumed to have the

506

skills to deploy ZTA components as well as related supporting components for data security, endpoint

507

security, identity and access management, and security analytics. The enterprises are also assumed to

508

have critical resources that require protection, some of which are located on-premises and others of

509

which are in the cloud; and a requirement to provide partners, contractors, guests, and employees, both

510

local and remote, with secure access to these critical resources. The reader is assumed to be familiar

511

with NIST SP 800-207, Zero Trust Architecture.

512

SECOND PRELIMINARY DRAFT

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

3.2 Scope

513

The scope of this project is initially limited to implementing a ZTA for a conventional, general-purpose

514

enterprise information technology (IT) infrastructure that combines users (including employees,

515

partners, contractors, guests, customers, and non-person entities [NPEs]), devices, and enterprise

516

resources. Resources could be hosted and managed—by the corporation itself or a third-party

517

provider—either on-premises or in the cloud, or some combination of these. There may also be branch

518

or partner offices, teleworkers, and support for fully managed BYOD and non-managed (i.e., guest)

519

device usage. While mobile device management (MDM) is used to support these device types,

520

demonstrating the full spectrum of MDM capabilities is beyond the scope of this project. Initially,

521

support for traditional IT resources such as laptops, desktops, servers, and other systems with

522

credentials is within scope. In future phases, the scope may expand to include ZTA support for Internet

523

of Things (IoT) devices. ZTA support for both IPv4 and IPv6 is in scope, as are the three deployment

524

approaches of EIG, micro-segmentation, and SDP, and both agent and agentless implementations.

525

It is important to establish the trustworthiness of ZTA component devices to mitigate the possibility that

526

the ZTA will be vulnerable to compromise through the hardware or software supply chain, but

527

discussion of methods for establishing and maintaining the trustworthiness of the underlying hardware

528

and supporting software comprising the ZTA is outside the scope of this document. Also, this document

529

is only concerned with using the ZTA to protect access to enterprise data. Addressing the risk and policy

530

requirements of discovering and classifying the data is out of scope.

531

This project focuses primarily on various types of user access to enterprise resources sprinkled across a

532

hybrid network environment. More specifically, the focus is on behaviors of enterprise employees,

533

partners, contractors, and guests accessing enterprise resources while connected from the corporate (or

534

enterprise headquarters) network, a branch office, or the public internet. Access requests can occur

535

over both the enterprise-owned part of the infrastructure and the public/non-enterprise-owned part.

536

This requires that all access requests be secure, authorized, and verified before access is enforced,

537

regardless of where the request is initiated or where the resources are located, i.e., whether on-

538

premises or in the cloud. Discovery of resources, assets, communication flows, and other elements is

539

also within scope.

540

ZTAs for industrial control systems and operational technology (OT) environments are explicitly out of

541

scope for this project. However, the project seeks to provide an approach and security principles for a

542

ZTA that could potentially be extended to OT environments. Any such application of ZTA principles to OT

543

environments would be part of a separate project. Please refer to other related NCCoE projects

544

[4][5][6][7]. The project is not concerned with addressing Federal Risk and Authorization Management

545

Program (FedRAMP) or other federal requirements at this time, although doing so could potentially be a

546

follow-on exercise.

547

SECOND PRELIMINARY DRAFT

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

Only implementations of the EIG crawl and EIG run phase deployment approaches are within scope at

548

this time. Builds of more complex ZTAs will be undertaken in later phases of the project.

549

3.3 Assumptions

550

This project is guided by the following assumptions:

551

▪ NIST SP 800-207, Zero Trust Architecture is a definitive source of ZTA concepts and principles.

552

▪ Enterprises that want to migrate gradually to an increasing use of ZTA concepts and principles in

553

their network environments may desire to integrate ZTA with their legacy enterprise and cloud

554

systems.

555

▪ To prepare for a migration to ZTA, enterprises may want to inventory and prioritize all resources

556

that require protection based on risk. They will also need to define policies that determine

557

under what set of conditions subjects will be given access to each resource based on attributes

558

of both the subject and the resource (e.g., location, type of authentication used, user role), as

559

well as other variables such as day and time.

560

▪ Enterprises should use a risk-based approach to set and prioritize milestones for their gradual

561

adoption and integration of ZTA across their enterprise environment.

562

▪ There is no single approach for migrating to ZTA that is best for all enterprises.

563

▪ There is not necessarily a clear point at which an organization can be said to have achieved a

564

state of “full” or 100% ZTA compliance. Continuous improvement is the objective.

565

▪ Devices, applications, and other non-human entities can have different levels of capability:

566

o Neither host-based firewalls nor host-based intrusion prevention systems (IPS) are

567

mandatory components; they are, however, capabilities that can be added when a

568

device is capable of supporting them.

569

o Some limited functionality devices that are not able to host firewall, IPS, and other

570

capabilities on their own may be associated with services that provide these capabilities

571

for them. In this case, both the device and its supporting services can be considered the

572

subject in the ZTA access interaction.

573

o Some devices are bound to users (e.g., desktop, laptop, smartphone); other devices are

574

not bound to users (e.g., servers, applications, services). Both types of devices can be

575

subjects and request access to enterprise resources.

576

▪ ZTA components used in any given enterprise solution should be interoperable regardless of

577

their vendor origin.

578

3.4 Collaborators and Their Contributions

579

Organizations participating in this project submitted their capabilities in response to an open call in the

580

Federal Register for all sources of relevant security capabilities from academia and industry (vendors

581

SECOND PRELIMINARY DRAFT

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

and integrators). The following respondents with relevant capabilities or product components (identified

582

as “Technology Partners/Collaborators” herein) signed a CRADA to collaborate with NIST in a consortium

583

to build example ZTA solutions:

584

Table 3-1 Technology Partners/Collaborators

585

Technology Collaborators

Appgate

IBM

Ping Identity

AWS

Ivanti

Radiant Logic

Broadcom Software

Lookout

SailPoint

Cisco

Mandiant

Tenable

DigiCert

Microsoft

Trellix

Okta

VMware

Forescout

Palo Alto Networks

Zimperium

Google Cloud

PC Matic

Zscaler

Each of these technology partners and collaborators, as well as the relevant products and capabilities

586

they bring to this ZTA effort, are described in the following subsections. The NCCoE does not certify or

587

validate products or services. We demonstrate the capabilities that can be achieved by using

588

participants’ contributed technology.

589

3.4.1 Appgate

590

Appgate is the secure access company. It empowers how people work and connect by providing

591

solutions purpose-built on zero trust security principles. This security approach enables fast, simple, and

592

secure connections from any device and location to workloads across any IT infrastructure in cloud, on-

593

premises, and hybrid environments.

594

3.4.1.1 Appgate SDP

595

The Appgate SDP solution has been designed with the intent to provide all the critical elements of NIST

596

SP 800-207. The Appgate SDP has a controller that offers policy administrator (PA) and policy engine (PE)

597

functionality and gateways that offer policy enforcement point (PEP) functionality. Appgate SDP natively

598

integrates with components via representational state transfer (REST) application programming

599

interfaces (APIs) and metadata. By providing highly performant, scalable, secure, integrated, and

600

cloaked zero trust access, Appgate SDP is able to ensure that the correct device and user (under the

601

appropriate conditions at that moment in time) are connected. For more information about Appgate

602

SDP, see https://www.appgate.com/zero-trust-network-access/how-it-works.

603

SECOND PRELIMINARY DRAFT

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

3.4.2 AWS

604

AWS provides a platform in the cloud that hosts private and public sector agencies in most countries

605

around the world. AWS offers more than 200 services which include compute, storage, networking,

606

database, analytics, application services, deployment, management, developer, mobile, IoT, artificial

607

intelligence (AI), security, and hybrid and enterprise applications. Additionally, AWS provides several

608

security-related services and features such as Identity and Access Management (IAM), Virtual Private

609

Cloud (VPC), PrivateLink, and Security Hub, allowing AWS customers to build and deliver their services

610

worldwide with a high degree of confidence and assurance. AWS’s array of third-party applications

611

provides complementary functionality that further extends the capabilities of the AWS environment. To

612

learn more about security services and compliance on AWS, please visit:

613

https://aws.amazon.com/products/security.

614

The following subsections briefly list some AWS services relevant to ZTA that are being provided in

615

support of this project, organized by category of service.

616

3.4.2.1 Identity

617

IAM: AWS Identity and Access Management (IAM) provides fine-grained access control across all of

618

AWS. With IAM, organizations can specify who can access which services and resources, and under

619

which conditions. With IAM policies, organizations manage permissions to their workforce and systems

620

to ensure least-privilege permissions.

621

Cognito: Amazon Cognito lets organizations add user sign-up, sign-in, and access control to web and

622

mobile apps quickly and easily. Cognito scales to millions of users and supports sign-in with social

623

identity providers, such as Apple, Facebook, Google, and Amazon, and enterprise identity providers via

624

Security Assertion Markup Language (SAML) 2.0 and OpenID Connect.

625

3.4.2.2 Network/Network Security

626

VPC: Amazon Virtual Private Cloud (Amazon VPC) gives organizations full control over their virtual

627

networking environment, including resource placement, connectivity, and security. A couple of key

628

security features found in VPCs are network access control lists (ACLs) that act as firewalls for controlling

629

traffic in and out of subnets, and security groups that act as host-based firewalls for controlling traffic to

630

individual Amazon Elastic Compute Cloud (Amazon EC2) instances.

631

PrivateLink: AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-

632

premises networks without exposing traffic to the public internet. AWS PrivateLink makes it easy to

633

connect services across different accounts and VPCs to significantly simplify network architecture.

634

Network Firewall: AWS Network Firewall is a managed service that makes it easy to deploy essential

635

network protections for all of an organization’s Amazon VPCs.

636

SECOND PRELIMINARY DRAFT

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

Web Application Firewall: AWS WAF is a web application firewall (WAF) that helps protect web

637

applications and APIs against common web exploits and bots that may affect availability, compromise

638

security, or consume excessive resources.

639

Route 53: Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web

640

service. It is designed to give developers and businesses an extremely reliable and cost-effective way to

641

route end users to internet applications. Amazon Route 53 is fully compliant with IPv6 as well. With

642

Route 53 Resolver an organization can filter and regulate outbound DNS traffic for its VPC.

643

3.4.2.3 Compute

644

EC2: Amazon EC2 is a web service that provides secure, resizable compute capacity in the cloud. It is

645

designed to make web-scale cloud computing easier for developers.

646

ECS: Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service

647

that makes it easy to deploy, manage, and scale containerized applications.

648

EKS: Amazon Elastic Kubernetes Service (Amazon EKS) is a managed container service to run and scale

649

Kubernetes applications in the cloud or on-premises.

650

3.4.2.4 Storage

651

EBS: Amazon Elastic Block Store (Amazon EBS) is an easy-to-use, scalable, high-performance block-

652

storage service designed for Amazon EC2.

653

S3: Amazon Simple Storage Service (Amazon S3) is an object storage service that offers scalability, data

654

availability, security, and performance.

655

3.4.2.5 Management/Monitoring

656

Systems Manager: AWS Systems Manager is the operations hub for AWS applications and resources,

657

and it is broken into four core feature groups: Operations Management, Application Management,

658

Change Management, and Node Management.

659

Security Hub: AWS Security Hub is a cloud security posture management service that performs security

660

best practice checks, aggregates alerts, and enables automated remediation.

661

CloudWatch: Amazon CloudWatch is a monitoring and observability service built for DevOps engineers,

662

developers, site reliability engineers (SREs), IT managers, and product owners. CloudWatch provides

663

data and actionable insights to monitor applications, respond to system-wide performance changes, and

664

optimize resource utilization.

665

CloudTrail: AWS CloudTrail monitors and records account activity across AWS infrastructures, giving

666

organizations control over storage, analysis, and remediation actions.

667

SECOND PRELIMINARY DRAFT

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

GuardDuty: Amazon GuardDuty is a threat detection service that continuously monitors AWS accounts

668

and workloads for malicious activity and delivers detailed security findings for visibility and remediation.

669

Firewall Manager: AWS Firewall Manager is a security management service which allows organizations

670

to centrally configure and manage firewall rules across their accounts and applications in AWS

671

Organizations.

672

3.4.3 Broadcom Software

673

Broadcom Software provides business-critical software designed to modernize, optimize, and protect

674

complex hybrid environments. As part of Broadcom Software, the Symantec Enterprise business invests

675

more than 20% of revenue into research and development (R&D), enabling it to innovate across its

676

cybersecurity portfolio and deliver new functionality that delivers both effective zero trust security and

677

an exceptional user experience. With more than 80% of its workforce dedicated to R&D and operations,

678

Broadcom Software’s engineering-centered culture supports a comprehensive portfolio of enterprise

679

software, enabling scalability, agility, and security for organizations. For more information, go to

680

https://software.broadcom.com/.

681

3.4.3.1 Web Security Service with Advanced Malware Analysis

682

Symantec Web Security Service (WSS), built upon secure web gateway (SWG) technology, is a cloud-

683

delivered network security service that offers protection against advanced threats, provides access

684

control, and safeguards critical business information for secure and compliant use of cloud applications

685

and the web.

686

3.4.3.2 Web Isolation

687

Web Isolation enables safe web browsing that protects against malware and phishing threats, even

688

when inadvertently visiting uncategorized and risky websites. Remotely executing web sessions in a

689

secured container stops malware downloads, and read-only browsing defeats phishing attacks. Available

690

as a cloud service or an on-premises virtual appliance, Web Isolation can be standalone or integrated

691

with a proxy or email security solution.

692

3.4.3.3 CASB with Data Loss Prevention (DLP)

693

Cloud Access Security Broker (CASB) identifies all cloud apps in use, enforces cloud application

694

management policies, detects and blocks unusual behavior, and integrates with other Symantec

695

solutions, including ProxySG, Data Loss Prevention (DLP), Validation and ID Protection (VIP)

696

Authentication Service, Secure Access Cloud, and Email Security.cloud, to extend network security

697

policies to the cloud. The integration with DLP consistently extends data compliance policies to over 100

698

Software as a Service (SaaS) cloud apps and automates policy sync with cloud properties. Additional APIs

699

for AWS and Azure also provide visibility and control of the management plane, along with cloud

700

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 15

workload assurance for discovering new cloud deployments and monitoring them for critical

701

misconfigurations.

702

3.4.3.4 Secure Access Cloud

703

Secure Access Cloud is a cloud-delivered service providing highly secure zero trust network access for

704

enterprise applications deployed in Infrastructure as a Service (IaaS) clouds or on-premises data center

705

environments. This SaaS platform eliminates inbound connections to a network, creates a software-

706

defined perimeter between users and corporate applications, and establishes application-level access.

707

This service avoids the management complexity and security limitations of traditional remote access

708

tools, ensuring that all corporate applications and services are completely cloaked—invisible to

709

attackers targeting applications, firewalls, and virtual private networks (VPNs).

710

3.4.3.5 Information Centric Analytics (ICA), part of Data Loss Prevention

711

User and entity behavior analytics is a vital tool to reduce user-based risk. Using it, customers can

712

identify anomalous or suspicious activity to help discover potential insider threats and data exfiltration.

713

It builds behavior profiles of users and entities so high-risk accounts can be investigated. Wider risk

714

context is available when security event telemetry is correlated from many data sources, including DLP,

715

Endpoint Protection, and ProxySG.

716

3.4.3.6 Symantec Endpoint Security Complete, including Endpoint Detection and

717

Response (EDR) and Mobile Security

718

Symantec’s endpoint security offering delivers protection, detection, and response in a single solution.

719

Symantec Endpoint Security Complete addresses threats along the entire attack chain. It protects all

720

endpoints (workstations, servers, iOS and Android mobile phones and tablets) across all major operating

721

systems, is easy to deploy with a single-agent installation, and provides flexible management options

722

(cloud, on-premises, and hybrid).

723

3.4.3.7 VIP Authentication Service

724

VIP is a secure, reliable, and scalable authentication service that provides risk-based and multi-factor

725

authentication (MFA) for all types of users. Risk-based authentication transparently collects data and

726

assesses risk using a variety of attributes such as device identification, geolocation, user behavior, and

727

threat information from the Symantec Global Intelligence Network (GIN). VIP provides MFA using a

728

broad range of authenticators such as push, Short Message Service (SMS) or voice one-time password

729

(OTP), Fast Identity Online (FIDO) Universal 2

Factor (U2F), and fingerprint biometric. This intelligent,

730

layered security approach prevents inappropriate access and online identity fraud without impacting the

731

user experience. VIP also denies access to compromised devices before they can attempt authentication

732

to the network and tracks advanced and persistent threats. An intuitive credential provisioning portal

733

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 16

enables self-service that reduces help desk and administrator costs. An integration with Symantec

734

CloudSOC protects against risky behavior even after application login.

735

3.4.3.8 VIP Authentication Hub

736

Authentication Hub is a highly scalable authentication engine that meets zero trust needs by providing

737

phishing-resistant authentication using FIDO2 as well as other multi-factor options, combined with a

738

highly flexible authentication policy model. It includes risk assessment to enable context-sensitive

739

authentication branching. The microservice architecture is built API-first for broad deployment and

740

integration options, and it integrates out of the box with Broadcom’s IAM portfolio.

741

3.4.3.9 Privileged Access Management

742

Privileged Access Management can minimize the risk of data breaches by continually protecting

743

sensitive administrative credentials, controlling privileged user access, and monitoring and recording

744

privileged user activity.

745

3.4.3.10 Security Analytics

746

Security Analytics is an advanced network traffic analysis (NTA) and forensics solution that performs full-

747

packet capture to provide complete network security visibility, anomaly detection, and real-time

748

content inspection for all network traffic to help detect and resolve security incidents more quickly and

749

thoroughly.

750

3.4.3.11 SiteMinder

751

While providing the convenience of a single sign-on experience, SiteMinder was built from the ground

752

up using zero trust principles. Every individual resource that is accessed via SiteMinder is only reached

753

once SiteMinder determines if the resource is sufficiently protected, if the user is authenticated, and if

754

the user has authorization to the specific resource. This zero trust approach is applied across all resource

755

access methods (e.g., traditional HTTP, SAML, WS-Federation, OpenID Connect [OIDC], Open

756

Authorization [OAuth]). SiteMinder is deployed in extremely high-performance critical-path business

757

environments. It supports a range of authenticators and in combination with VIP offerings (noted above)

758

provides capabilities to meet the most challenging use cases.

759

3.4.3.12 Identity Governance and Administration (IGA)

760

Having a comprehensive ability to manage the lifecycle of user accounts across on-premises and cloud

761

environments is an essential element of a zero trust infrastructure. Symantec IGA delivers

762

comprehensive access governance and management capabilities through an easy-to-use, business-

763

oriented interface. Broad provisioning support for on-premises and cloud apps enables you to automate

764

the granting of new entitlements and removal of unnecessary ones from users throughout the identity

765

life-cycle. Finally, access governance streamlines and simplifies the processes associated with reviewing

766

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 17

and approving entitlements, helping ensure a 360 degree view of user entitlements and improving your

767

adherence to zero trust principles.

768

3.4.4 Cisco

769

Cisco Systems, or Cisco, delivers collaboration, enterprise, and industrial networking and security

770

solutions. The company’s cybersecurity team, Cisco Secure, is one of the largest cloud and network

771

security providers in the world. Cisco’s Talos Intelligence Group, the largest commercial threat

772

intelligence team in the world, is comprised of world-class threat researchers, analysts, and engineers,

773

and supported by unrivaled telemetry and sophisticated systems. The group feeds rapid and actionable

774

threat intelligence to Cisco customers, products, and services to help identify new threats quickly and

775

defend against them. Cisco solutions are built to work together and integrate into your environment,

776

using the “network as a sensor” and “network as an enforcer” approach to both make your team more

777

efficient and keep your enterprise secure. Learn more about Cisco at https://www.cisco.com/go/secure.

778

3.4.4.1 Cisco Secure Access by Duo

779

Duo is a PE, PA, and PEP for users and their devices. It delivers simple, safe access to all applications —

780

on-premises or in the cloud — for any user, device, or location. It makes it easy to effectively implement

781

and enforce security policies and processes, using strong authentication to reduce the risk of data

782

breaches due to compromised credentials and access from unauthorized devices.

783

3.4.4.2 Cisco Identity Services Engine (ISE)

784

Cisco ISE is a network central PDP that includes both the PE and PA to help organizations provide secure

785

access to users, their devices, and the non-user devices in their network environment. It simplifies the

786

delivery of consistent and secure access control to PEPs across wired and wireless multi-vendor

787

networks, as well as remote VPN connections. It controls switches, routers, and other network devices

788

as PEPs, enabling granular control of every connection down to the individual port, delivering a dynamic,

789

granular, and automated approach to policy enforcement that simplifies the delivery of highly secure,

790

micro-segmented network access control. ISE is tightly integrated with and enhances network and

791

security devices, allowing it to transform the network from a simple conduit for data into an intuitive

792

and adaptive security sensor and enforcer that acts to accelerate the time to detection and time to

793

resolution of network threats.

794

3.4.4.3 Cisco Secure Endpoint (formerly AMP)

795

Cisco Secure Endpoint addresses the full life cycle of the advanced malware problem before, during, and

796

after an attack. It uses global threat intelligence to strengthen defenses, antivirus to block known

797

malware, and static and dynamic file analysis to detect emerging malware, continuously monitoring file

798

and system activity for emerging threats. When something new is detected, the solution provides a

799

retrospective alert with the full recorded history of the file back to the point of entry, and the rich

800

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 18

contextual information needed during a potential breach investigation to both prioritize remediation

801

and create response plans.

802

As a policy input point, Secure Endpoint delivers deep visibility, context, and control to rapidly detect,

803

contain, and remediate advanced threats if they evade front-line defenses. It can also eliminate malware

804

with a few clicks and provide a cost-effective security solution without affecting operational efficiency.

805

3.4.4.4 Cisco Firepower Threat Defense (FTD)

806

Cisco FTD is a threat-focused, next-generation firewall with unified management. It provides advanced

807

threat protection before, during, and after attacks. By delivering comprehensive, unified policy

808

management of firewall functions, application control, threat prevention, and advanced malware

809

protection, from network to endpoint, it increases visibility and security posture while reducing risk.

810

3.4.4.5 Cisco Secure Network Analytics (formerly Stealthwatch)

811

Cisco Secure Network Analytics aggregates and analyzes network telemetry — information generated by

812

network devices — to turn the network into a sensor. As a policy input point, it provides enterprise-wide

813

network visibility and applies advanced security analytics to detect and respond to threats in real time. It

814

delivers end-to-end network visibility on-premises, in private clouds, and in public clouds. Secure

815

Network Analytics detects a wide range of network and data center issues ranging from command-and-

816

control (C&C) attacks to ransomware, from distributed denial of service (DDoS) attacks to illicit

817

cryptomining, and from malware to insider threats.

818

Secure Network Analytics can be deployed on-premises as a hardware appliance or virtual machine

819

(VM), or cloud-delivered as a SaaS solution. It works with the entire Cisco router and switch portfolio as

820

well as a wide variety of other security solutions.

821

3.4.4.6 Cisco Encrypted Traffic Analytics (ETA)

822

Cisco ETA helps illuminate the dark corners of encrypted traffic without decryption by using new types

823

of data elements and enhanced NetFlow telemetry independent of protocol details. Cisco ETA can help

824

detect malicious activity in encrypted traffic by applying advanced security analytics. At the same time,

825

the integrity of the encrypted traffic is maintained because there is no need for bulk decryption.

826

3.4.4.7 Cisco SecureX

827

Cisco SecureX is an extended detection and response (XDR) cloud-native integrated threat response

828

platform within the Cisco Secure portfolio. Its open, extensible integrations connect to the

829

infrastructure, providing unified visibility and simplicity in one location. It maximizes operational

830

efficiency to secure the network, users and endpoints, cloud edge, and applications. Cisco SecureX

831

radically reduces the dwell time and human-powered tasks involved with detecting, investigating, and

832

remediating threats to counter attacks, or securing access and managing policy to stay compliant. The

833

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 19

time savings and better collaboration involved with orchestrating and automating security across

834

SecOps, ITOps, and NetOps teams help advance the security maturity level.

835

3.4.4.8 Cisco Endpoint Security Analytics (CESA)

836

Cisco Endpoint Security Analytics (CESA) analyzes endpoint telemetry generated by the Network

837

Visibility Module (NVM), which is built into the Cisco AnyConnect® Secure Mobility Client. CESA feeds

838

Splunk Enterprise software to analyze NVM data provided by endpoints to uncover endpoint-specific

839

security risks and breaches. This data includes information about data loss, unapproved applications and

840

SaaS usage, security evasion, unknown malware, user behavior when not connected to the enterprise,

841

endpoint asset inventory, and destination allowlists and denylists.

842

3.4.4.9 Cisco AnyConnect Secure Mobility Client

843

Cisco AnyConnect Secure Mobility Client is a unified endpoint software client compatible with several of

844

today’s major enterprise mobility platforms. It helps manage the security risks associated with extended

845

networks. Built on foundational VPN technology, it extends beyond remote-access capabilities to offer

846

user-friendly, network-based security including:

847

▪ Simple and context-aware security policy enforcement

848

▪ An uninterrupted, intelligent, always-on security connection to remote devices

849

▪ Visibility into network and device-user behavior

850

▪ Web inspection technology to defend against compromised websites

851

3.4.4.10 Cisco Network Devices

852

Cisco network devices do more than move packets on the network; they provide a platform to improve

853

user experience, unify management, automate tasks, analyze activity, and enhance security across the

854

enterprise. In a zero-trust environment, Cisco switches, routers, and other devices provide continuous

855

visibility using the “network as a sensor” to monitor network activity, reporting 100% of NetFlow and

856

other metadata. These devices act as PEPs utilizing a “network as an enforcer” approach to micro-

857

segment network access control to each port and enable dynamic and automated policy enforcement.

858

This policy enforcement simplifies the delivery of highly secure control across environments.

859

3.4.5 DigiCert

860

DigiCert is a global provider of digital trust, enabling individuals and businesses to engage online with

861

the confidence that their footprint in the digital world is secure. DigiCert® ONE, the platform for digital

862

trust, provides organizations with centralized visibility and control over a broad range of public and

863

private trust needs, securing websites, enterprise access and communication, software, identity,

864

content, and devices. For more information, visit digicert.com.

865

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 20

3.4.5.1 DigiCert CertCentral TLS Manager

866

DigiCert CertCentral is used to provision publicly trusted Transport Layer Security (TLS) server

867

authentication certificates. CertCentral relies on DigiCert’s publicly trusted root certificates with

868

excellent ubiquity to provide the necessary interoperability with the widest range of third-party

869

products.

870

3.4.5.2 DigiCert Enterprise PKI Manager

871

DigiCert Enterprise PKI Manager is a digital certificate management solution for enterprise identity and

872

access public key infrastructure (PKI) use cases. Enterprise PKI Manager simplifies and streamlines

873

certificate lifecycle management for identity and access of users, devices, and applications, supporting a

874

broad array of certificate types with automated workflows, preconfigured templates, multiple

875

enrollment and authentication methods, and a rich ecosystem of integrated technology partners. It is

876

part of the DigiCert family of products delivering digital trust solutions. Enterprise PKI Manager is built

877

on DigiCert ONE’s modern, containerized architecture, delivering scalability capable of serving high

878

volumes of certificates, supporting flexible deployment in cloud, on-premises, or hybrid deployment

879

models, and enabling dynamic and rapid intermediate Certificate Authority (ICA) creation to meet the

880

diverse needs of different business groups.

881

3.4.6 F5

882

F5 empowers its customers to create, secure, and operate applications that deliver extraordinary digital

883

experiences. Fueled by automation and AI-driven insights, these applications will naturally adapt based

884

on their changing environment—so companies can focus on their core business, boost speed to market,

885

improve operations, and build trust with their customers. By enabling these adaptive applications, F5

886

with NGINX and F5 Distributed Cloud Services technologies offers a comprehensive suite of solutions for

887

every digital organization.

888

3.4.6.1 BIG-IP Product Family

889

The BIG-IP product family provides full proxy security, application intelligence, and scalability for

890

application traffic. As the amount of traffic grows or shrinks, BIG-IP can be adjusted or it can request

891

addition or removal of application servers. It provides rich application traffic programmability to further

892

enhance application security and application traffic steering requirements. In addition, BIG-IP’s rich

893

control plane programmability allows for integrations into on-premises orchestration engines, cloud

894

automation/orchestration, and continuous integration/continuous delivery (CI/CD) pipelines, and the

895

ability to deliver application security in a DevSecOps manner. All capabilities can be propagated as

896

common policy throughout the enterprise regardless of whether an organization utilizes F5 hardware or

897

a virtualized on-premises or cloud environment.

898

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 21

BIG-IP modules provide the ability to layer on additional capabilities. The modules being considered for

899

this project are discussed in the subsections below.

900

3.4.6.1.1 BIG-IP Local Traffic Manager (LTM)

901

BIG-IP LTM is an enterprise-class load balancer providing granular layer 7 control, Secure Sockets Layer

902

(SSL) offloading, and acceleration capabilities. It allows for massive scaling of traditional and modern

903

apps across the enterprise and provides visibility into TLS-encrypted streams, TLS security enforcement,

904

and Federal Information Processing Standards (FIPS) certified cryptography [8].

905

3.4.6.1.2 BIG-IP Access Policy Manager (APM)

906

BIG-IP APM integrates and unifies secure user access to ensure the correct people have the correct

907

access to the correct applications—anytime, anywhere, providing the ability to authenticate users into

908

applications allowing for granular application access control and zero trust capabilities across the

909

application landscape. BIG-IP APM sits in front of applications and APIs to enforce application

910

authentication and access control for each user as part of zero trust.

911

3.4.6.1.3 BIG-IP Web Application Firewall (WAF)

912

BIG-IP WAF provides the flexibility to deploy WAF services closer to the apps so they’re protected

913

wherever they reside. It has the ability to virtually patch applications for security vulnerabilities such as

914

the latest Common Vulnerabilities and Exposures (CVE) entry without application code changes. It also

915

reduces unwanted application traffic, allowing the application to be more responsive to its intended

916

users while providing complete visibility into the application traffic. WAF provides API security,

917

protecting against web application security concerns. WAF provides secure communication and vetting

918

of traffic to APIs and applications.

919

3.4.6.2 NGINX Product Family

920

NGINX is a cloud-native, easy-to-use reverse proxy, load balancer, and API gateway. It integrates

921

advanced monitoring, strengthens security controls, and orchestrates Kubernetes containers.

922

3.4.6.2.1 NGINX Ingress Controller

923

NGINX Ingress Controller combines software load balancing with simplified configuration based on

924

standard Kubernetes Ingress resources or custom NGINX Ingress resources to ensure that applications in

925

a Kubernetes cluster are delivered reliably, securely, and at high velocity. It provides security to

926

Kubernetes-based microservices and APIs using API gateway and WAF capabilities. The Ingress

927

Controller protects application and API containers in the Kubernetes environment by enforcing security

928

on all traffic entering the Kubernetes node.

929

3.4.6.2.2 NGINX Plus

930

NGINX Plus is an all-in-one load balancer, web server, content cache, WAF, and API gateway. NGINX Plus

931

is built on NGINX Open Source. It is intended to reduce complexity and simplify management by

932

consolidating several capabilities, including reverse proxy and TLS termination, into a single elastic

933

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 22

ingress/egress tier. It acts as a webserver to server applications that are secured by the system’s zero

934

trust capabilities.

935

3.4.6.2.3 NGINX Service Mesh

936

NGINX Service Mesh scales from open-source projects to a fully supported, secure, and scalable

937

enterprise-grade solution. It provides a turnkey service-to-service solution featuring a unified data plane

938

for ingress and egress Kubernetes management in a single configuration. NGINX Service Mesh provides

939

for mutual TLS authentication (mTLS) enforcement, rate limiting, quality of service (QOS), and an API

940

gateway to enforce security at each pod, securing pods from both north/south (N/S) and east/west

941

(E/W) traffic and allowing for zero trust enforcement for all pod traffic.

942

3.4.7 Forescout

943

Forescout delivers automated cybersecurity across the digital terrain. It empowers its customers to

944

achieve continuous alignment of their security frameworks with their digital realities, across all asset

945

types – IT, IoT, OT, and Internet of Medical Things (IoMT). Forescout enables organizations to manage

946

cyber risk through automation and data-powered insights.

947

The Forescout Continuum Platform provides complete asset visibility of connected devices, continuous

948

compliance, network segmentation, network access control, and a strong foundation for zero trust.

949

Forescout customers gain data-powered intelligence to accurately detect risks and quickly remediate

950

cyberthreats without disruption of critical business assets. https://www.forescout.com/company/

951

3.4.7.1 Forescout eyeSight

952

Forescout eyeSight delivers comprehensive device visibility across an organization’s entire digital terrain

953

– without disrupting critical business processes. It discovers every IP-connected device, auto-classifies it,

954

and assesses its compliance posture and risk the instant the device connects to the network.

955

https://www.forescout.com/products/eyesight/

956

3.4.7.2 Forescout eyeControl

957

Forescout eyeControl provides flexible and frictionless network access control for heterogeneous

958

enterprise networks. It enforces and automates zero trust security policies for least-privilege access on

959

all managed and unmanaged assets across an organization’s digital terrain. Policy-based controls can

960

continuously enforce asset compliance, proactively reduce attack surfaces, and rapidly respond to

961

incidents. https://www.forescout.com/products/eyecontrol/

962

3.4.7.3 Forescout eyeSegment

963

Forescout eyeSegment accelerates zero trust segmentation. It simplifies the design, planning, and

964

deployment of non-disruptive, dynamic segmentation across an organization’s digital terrain to reduce

965

attack surface and regulatory risk. https://www.forescout.com/products/eyesegment/

966

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 23

3.4.7.4 Forescout eyeExtend

967

Forescout eyeExtend automates security workflows across disparate products. It shares device context

968

between the Forescout platform and other IT and security products, automates policy enforcement

969

across disparate tools, and accelerates system-wide response to mitigate risks.

970

https://www.forescout.com/products/eyeextend/

971

3.4.8 Google Cloud

972

Google Cloud brings the best of Google’s innovative products and services to enable enterprises of all

973

sizes to create new user experiences, transform their operations, and operate more efficiently. Google’s

974

mission is to accelerate every organization’s ability to digitally transform its business with the best

975

infrastructure, platform, industry solutions, and expertise. Google Cloud helps customers protect their

976

data using the same infrastructure and security services Google uses for its own operations, defending

977

against the toughest threats. Google pioneered the zero trust model at the core of its services and

978

operations, and it enables its customers to do the same with its broad portfolio of solutions. Learn more

979

about Google Cloud at https://cloud.google.com/.

980

3.4.8.1 BeyondCorp Enterprise (BCE)

981

BeyondCorp Enterprise (BCE) is a zero trust solution, built on the Google platform and global network,

982

which provides customers with simple and secure access to applications and cloud resources and offers

983

integrated threat and data protection. It leverages the Chrome Browser and the Google Cloud platform

984

(GCP) to protect and proxy traffic from an organization’s network. It allows customers to enforce

985

context-aware policies (using factors such as identity, device posturing, and other signal information) to

986

authorize access to SaaS applications and resources hosted on Google Cloud, third-party clouds, or on-

987

premises. This solution is built from Google’s own approach of shifting access controls from the network

988

perimeter to individual users and devices, allowing for secure access without the need for a VPN.

989

BCE key capabilities include:

990

▪ Zero trust access

991

o Context-aware access proxy (identity-aware proxy): Globally deployed proxy built on

992

the GCP that leverages identity, device, and contextual information to apply continuous

993

authorization access decisions to applications and VMs in real-time in the GCP, other

994

clouds, or on-premises data centers.

995

o Browser-based application access: Agentless zero trust access, using Chrome or other

996

browsers, to browser-based apps hosted on the GCP, other clouds (e.g., AWS, Azure), or

997

on-premises data centers.

998

o Legacy client application access (client connector): Extension that enables zero trust

999

access to non-HTTP, thick-client apps hosted in the GCP, other clouds, or on-premises

1000

data centers.

1001

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 24

▪ Protections

1002

o Data protection: Built-in Chrome browser capabilities to detect and prevent sensitive

1003

data loss, stop pasting of protected content in and out of the browser, prevent

1004

accidental and intentional exfiltration of corporate data, and enforce data protection

1005

policies across applications.

1006

o Threat protection: Built-in Chrome browser capabilities to filter and block harmful or

1007

unauthorized URLs in real-time, identify phishing sites and malicious content in real-

1008

time, stop suspicious files and malware transfers, and protect user credentials and

1009

passwords.

1010

▪ Integrations

1011

o BeyondCorp Alliance ecosystem integrations: A collection of integrations from

1012

BeyondCorp Alliance member partners that enable organizations to share signal

1013

information from EDR, MDM, enterprise mobility management (EMM), and other device

1014

or ecosystem endpoints to use in access policy decisions. (Members include Broadcom

1015

Software, Check Point, Citrix, CrowdStrike, Jamf, Lookout, Netskope, Palo Alto

1016

Networks, Tanium, and VMware.)

1017

▪ Network connectivity

1018

o On-premises connector: Private connectivity from Google Cloud to applications outside

1019

of Google Cloud (i.e., hosted by other clouds or on-premises data centers.)

1020

o VPN interconnect: Private connectivity via an Interconnect from Google Cloud to

1021

applications outside of Google Cloud (i.e., hosted by other clouds or on-premises data

1022

centers.)

1023

o App connector: Secure internet-based connectivity from Google Cloud to applications

1024

outside of Google Cloud (i.e., hosted by other clouds or on-premises data centers.)

1025

▪ Platform

1026

o Google Platform: Google’s public cloud computing services including data management,

1027

application development, storage, hybrid & multi-cloud, security, and AI & ML that run

1028

on Google infrastructure.

1029

o Google Network: Google’s global backbone with 146 edge locations in over 200

1030

countries and territories provides low-latency connections, integrated DDoS protection,

1031

elastic scaling, and private transit.

1032

3.4.9 IBM

1033

International Business Machines Corporation (IBM) is an American multinational technology corporation

1034

headquartered in Armonk, New York, with operations in over 171 countries. IBM produces and sells

1035

computer hardware, middleware, and software, and provides hosting and consulting services in areas

1036

ranging from mainframe computers to nanotechnology. IBM is also a major research organization,

1037

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 25

holding the record for most annual U.S. patents generated by a business (as of 2020) for 28 consecutive

1038

years. IBM has a large and diverse portfolio of products and services that range in the categories of

1039

cloud computing, AI, commerce, data and analytics, IoT, IT infrastructure, mobile, digital workplace, and

1040

cybersecurity.

1041

3.4.9.1 IBM Security Trusteer

1042

IBM Security® Trusteer® solutions help detect fraud, authenticate users, and establish identity trust

1043

across a digital user journey. Trusteer uses cloud-based intelligence, AI, and machine learning (ML) to

1044

holistically identify new and existing users while improving the overall user experience by reducing the

1045

friction created with traditional forms of MFA. Within a ZTA, Trusteer acts as a risk engine that improves

1046

the efficacy of policy decisions enforced by various identity and access management solutions.

1047

3.4.9.2 IBM Security QRadar XDR

1048

IBM Security QRadar® XDR suite provides a single unified workflow across an organization’s security

1049

tools. Built on a unified cross-domain security platform, IBM Cloud Pak® for Security, the open

1050

architecture of QRadar XDR suite enables organizations to integrate their EDR, security information and

1051

event management (SIEM), network detection and response (NDR), security orchestration, automation,

1052

and response (SOAR), and threat intelligence solutions in support of a ZTA.

1053

IBM Security QRadar SIEM helps security teams detect, prioritize, and respond to threats across the

1054

enterprise. As an integral part of an organization’s XDR and zero trust strategies, it automatically

1055

aggregates and analyzes log and flow data from thousands of devices, endpoints, and apps across the

1056

network, providing single, prioritized alerts to speed incident analysis and remediation. QRadar SIEM is

1057

available for on-premises and cloud environments.

1058

IBM Security QRadar SOAR is designed to help security teams respond to cyberthreats with confidence,

1059

automate with intelligence, and collaborate with consistency. It guides a team in resolving incidents by

1060

codifying established incident response processes into dynamic playbooks. The open and agnostic

1061

platform helps accelerate and orchestrate response by automating actions with intelligence and

1062

integrating with other security tools.

1063

IBM Security QRadar XDR Connect is a cloud-native, open XDR solution that saves time by connecting

1064

tools, workflows, insights, and people. The solution adapts to a team’s skills and needs, whether the

1065

user is an analyst looking for streamlined visibility and automated investigations or an experienced

1066

threat hunter looking for advanced threat detection. XDR Connect empowers organizations with tools

1067

that strengthen their zero trust model and enable them to be more productive.

1068

3.4.9.3 IBM Security Verify

1069

Modernized, modular IBM Security Verify provides deep, AI-powered context for both consumer and

1070

workforce identity and access management. It protects users and apps, inside and outside the

1071

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 26

enterprise, with a low-friction, cloud-native, SaaS approach that leverages the cloud. Verify delivers

1072

critical features for supporting a zero trust strategy based on least privilege and continuous verification,

1073

including single sign-on (SSO), multi-factor and passwordless authentication, adaptive access, identity

1074

lifecycle management, and identity analytics.

1075

3.4.9.4 IBM Security MaaS360

1076

IBM Security MaaS360® with Watson protects devices, apps, content, and data, which allows

1077

organizations to rapidly scale their hybrid workforce and BYOD initiatives. IBM Security MaaS360 can

1078

help build a zero trust strategy with modern device management. And with Watson, organizations can

1079

take advantage of contextual analytics via AI for actionable insights.

1080

3.4.9.5 IBM Security Guardium

1081

IBM Security Guardium® Insights is a data security hub for the modern data source environment. It

1082

builds and automates compliance policy enforcement, and streams and centralizes data activity across a

1083

multi-cloud ecosystem. It can apply advanced analytics to uncover data risk insights. Guardium Insights

1084

can complement and enhance existing Guardium Data Protection deployments or be installed on its own

1085

to help solve compliance and cloud data activity monitoring challenges. Built on a unified cross-domain

1086

security platform, IBM Cloud Pak for Security, Guardium Insights can deploy and scale in any data

1087

environment — as well as integrate and share insights with major security tools such as IBM Security

1088

QRadar XDR, Splunk, ServiceNow, and more, in support of a ZTA.

1089

3.4.9.6 IBM Cloud Pak for Security

1090

IBM Cloud Pak for Security is a unified cross-domain security platform that integrates existing security

1091

tools to generate insights into threats across hybrid, multi-cloud environments. It provides organizations

1092

with the ability to track, manage, and resolve cybersecurity incidents and create response plans that are

1093

based on industry standards and best practices.

1094

3.4.10 Ivanti

1095

Ivanti finds, heals, manages, and protects devices regardless of location – automatically. It is an

1096

enterprise software company specializing in endpoint management, network security, risk-based

1097

vulnerability management, and service and asset management. The Ivanti solution is able to discover,

1098

manage, secure, and service all endpoints across the enterprise including corporate/government-owned

1099

and BYOD. Ivanti is actively involved with helping to better prepare government and enterprises with

1100

cybersecurity and zero trust best practices. Learn more about Ivanti here: https://www.ivanti.com/. The

1101

Ivanti solution enables an enterprise to centrally manage/monitor endpoints and trigger adaptive

1102

policies to remediate threats, quarantine devices, and maintain compliance.

1103

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 27

3.4.10.1 Ivanti Neurons for Unified Endpoint Management (UEM)

1104

Ivanti Neurons for UEM helps enterprises create a secure workspace on any device with apps,

1105

configurations, and policies for the user based on their role. Users get easy and secure access to the

1106

resources they need for their productivity. For more information, see

1107

https://www.ivanti.com/products/ivanti-neurons-for-mdm.

1108

The Ivanti Neurons for UEM platform provides the fundamental visibility and IT controls needed to

1109

secure, manage, and monitor any corporate or employee-owned mobile device or desktop that accesses

1110

business-critical data. The Neurons for UEM platform allows organizations to secure a vast range of

1111

employee and BYOD devices being used within the organization while managing the entire life cycle of

1112

the device, including:

1113

▪ Policy configuration management and enforcement

1114

▪ Application distribution and management

1115

▪ Script management and distribution for desktop devices

1116

▪ Automated device actions

1117

▪ Continuous access control and MFA

1118

▪ Threat detection and remediation against device, network application, and phishing attacks

1119

3.4.10.2 Ivanti Sentry

1120

Ivanti Sentry is an in-line intelligent gateway that helps secure access to on-premises resources and

1121

provides authentication and authorization to enterprise data. For more information, see

1122

https://www.ivanti.com/products/secure-connectivity/sentry.

1123

3.4.10.3 Ivanti Access ZSO

1124

Ivanti Access Zero Sign-On (ZSO) helps identify the user, device, app, network type, and presence of

1125

threats. The adaptive access control check is the basis of the zero-trust model. Access provides zero

1126

sign-on and security on the cloud and federated enterprise data. The solution is federated with the Okta

1127

Identity Cloud to provide continuous authentication and authorization. For more information, see

1128

https://www.ivanti.com/products/zero-sign-on.

1129

3.4.10.4 Ivanti Mobile Threat Defense

1130

The combination of cloud and mobile threat defense (MTD) protects data on-device and on-the-network

1131

with state-of-the-art encryption and threat monitoring to detect and remediate device, network, app-

1132

level, and phishing attacks. For more information, see https://www.ivanti.com/products/mobile-threat-

1133

defense.

1134

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 28

3.4.11 Lookout

1135

Lookout is a cybersecurity company focused on securing users, devices, and data as users operate in the

1136

cloud. The Lookout platform helps organizations consolidate IT security, get complete visibility across all

1137

cloud services, and protect sensitive data wherever it goes.

1138

3.4.11.1 Lookout Mobile Endpoint Security (MES)

1139

Lookout MES is a SaaS-based MTD solution that protects devices from threats and risks via the Lookout

1140

for Work mobile application. Lookout protects Android and Apple mobile devices from malicious or risky

1141

apps, device threats, network threats, and phishing attacks. Lookout attests to the security posture of

1142

the mobile device, which is provided to the policy engine to determine access to a resource. The mobile

1143

asset is continuously monitored by Lookout for any change to its security posture. Lookout protection

1144

can be deployed to managed or unmanaged devices and works on trusted or untrusted networks.

1145

Lookout has integrations with productivity and collaboration solutions, as well as unified endpoint

1146

management solutions.

1147

3.4.12 Mandiant

1148

Mandiant scales its intelligence and expertise through the Mandiant Advantage SaaS platform to deliver

1149

current intelligence, automation of alert investigation, and prioritization and validation of security

1150

control products from a variety of vendors. (http://www.mandiant.com/)

1151

3.4.12.1 Mandiant Security Validation (MSV)

1152

Mandiant Security Validation (MSV), continuously informed by Mandiant frontline intelligence on the

1153

latest attacker tactics, techniques, and procedures (TTPs), automates a testing program that gives real

1154

data on how security controls are performing. This solution provides visibility and evidence on the status

1155

of security controls’ effectiveness against adversary threats targeting organizations and data to optimize

1156

environment against relevant threats. MSV can provide many benefits to an organization (for example,

1157

identify limitations in current cybersecurity stack, evaluate proposed cybersecurity tools for an

1158

organization, determine overlapping controls, automate assessment actions, and train cybersecurity

1159

operators). To support these use cases, MSV emulates attackers to safely process advanced cyberattack

1160

security content within production environments. It is designed so defenses respond to it as if an attack

1161

is taking place across the most critical areas of the enterprise.

1162

Using the natural design of the Security Validation platform, Mandiant is able to support the project in

1163

testing and documenting the outcome of one of the key tenets of ZTA, “The enterprise monitors and

1164

measures the integrity and security posture of all owned and associated resources.” To do this, the

1165

software produces quantifiable evidence that shows how people, processes, and technologies perform

1166

when specific malicious behaviors are encountered, such as attacks by a specific threat actor or attack

1167

vector.

1168

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 29

The core Validation components of the MSV platform are:

1169

▪ The Director - This is the main component of the platform and provides the following

1170

functionality:

1171

o Acts as the Integration point and content manager for the SIEM and other components

1172

of the security stack

1173

o Hosts the Content Library (Actions, Sequences, Evaluations, and Files) used for testing

1174

security controls

1175

o Manages the Actor assignment during testing

1176

o Aggregates testing results and facilitates report creation

1177

o Maintains connections with the Mandiant Updater and Content Services, allowing

1178

updates to be received automatically for the platform and its content

1179

▪ Actors (also referred to as flex, Endpoint, and Network Actors) - The components that safely

1180

perform tests in production environments. Specifically, use these to verify the configuration and

1181

test the effectiveness of network security controls; Windows, Mac, and Linux endpoint controls;

1182

and email controls.

1183

▪ Cloud controls

1184

▪ Policy compliance

1185

The Director is the component that receives the information from the systems in the environment based

1186

on an integration with a SIEM and/or directly with the security appliance itself. Tests are run between

1187

Actors and not directly on systems in the environment.

1188

3.4.13 Microsoft

1189

Microsoft Security brings together the capabilities of security, compliance, identity, and management to

1190

natively integrate individual layers of protection across clouds, platforms, endpoints, and devices.

1191

Microsoft Security helps reduce the risk of data breaches and compliance violations and improve

1192

productivity by providing the necessary coverage to enable zero trust. Microsoft’s security products give

1193

IT leaders the tools to confidently help their organization digitally transform with Microsoft’s protection

1194

across their entire environment.

1195

3.4.13.1 Azure

1196

Microsoft Azure is Microsoft's public cloud computing platform. It provides a range of cloud services,

1197

including compute, analytics, storage, and networking.

1198

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 30

3.4.13.2 Azure Active Directory (Azure AD)

1199

Azure AD is an IAM/identity as a service (IDaaS) product from Microsoft that performs ICAM

1200

management, authentication (both SSO and MFA), authorization, federation, and governance, and also

1201

functions as a PE, PA, and PEP.

1202

3.4.13.3 Microsoft Intune – Device Management

1203

In Intune, devices are managed using an approach that’s suitable for the organization. For organization-

1204

owned devices, an organization may want full control over the devices, including settings, features, and

1205

security. In this approach, devices and users of these devices “enroll” in Intune. Once enrolled, they

1206

receive the organization’s rules and settings through policies configured in Intune. For example,

1207

organizations can set password and PIN requirements, create a VPN connection, set up threat

1208

protection, and more.

1209

3.4.13.4 Microsoft Intune – Application Management

1210

Microsoft Intune provides mobile application management (MAM), which is designed to protect

1211

organization data at the application level, including custom apps and store apps. App management can

1212

be used on organization-owned devices and personal devices. When apps are managed in Intune,

1213

administrators can:

1214

▪ add and assign mobile apps to user groups and devices, including users in specific groups,

1215

devices in specific groups, and more;

1216

▪ configure apps to start or run with specific settings enabled and update existing apps already on

1217

the device;

1218

▪ see reports on which apps are used and track their usage; and

1219

▪ do a selective wipe by removing only organization data from apps.

1220

3.4.13.5 Microsoft Defender for Endpoint

1221

Microsoft Defender for Endpoint is an enterprise endpoint security platform designed to help enterprise

1222

networks prevent, detect, investigate, and respond to advanced threats.

1223

3.4.13.6 Microsoft Sentinel

1224

Microsoft Sentinel is a scalable, cloud-native solution for SIEM. It was previously known as Azure

1225

Sentinel.

1226

3.4.13.7 Microsoft Defender for Identity

1227

Microsoft Defender for Identity (formerly Azure Advanced Threat Protection, also known as Azure ATP)

1228

is a cloud-based security solution that leverages an organization’s on-premises AD signals to identify,

1229

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 31

detect, and investigate advanced threats, compromised identities, and malicious insider actions directed

1230

at the organization. Defender for Identity enables SecOps analysts and security professionals struggling

1231

to detect advanced attacks in hybrid environments to:

1232

▪ monitor users, entity behavior, and activities with learning-based analytics;

1233

▪ protect user identities and credentials stored in AD;

1234

▪ identify and investigate suspicious user activities and advanced attacks throughout the kill chain;

1235

and

1236

▪ provide clear incident information on a simple timeline for fast triage.

1237

3.4.13.8 Azure AD Identity Protection

1238

Identity Protection, which is part of Azure AD, is a tool that allows organizations to accomplish three key

1239

tasks:

1240

▪ automate the detection and remediation of identity-based risks;

1241

▪ investigate risks using data in the portal; and

1242

▪ export risk detection data to the SIEM.

1243

Identity Protection uses the learnings Microsoft has acquired from its position in organizations with

1244

Azure AD, in the consumer space with Microsoft Accounts, and in gaming with Xbox to protect users.

1245

Microsoft analyses 6.5 trillion signals per day to identify and protect customers from threats.

1246

The signals generated by and fed to Identity Protection can be further fed into tools like Conditional

1247

Access to make access decisions, or fed back to a SIEM tool for further investigation based on an

1248

organization’s enforced policies.

1249

3.4.13.9 Microsoft Defender for Office 365 (for email)

1250

Microsoft Defender for Office 365 (for email) prevents broad, volume-based, known attacks. It protects

1251

email and collaboration from zero-day malware, phishing, and business email compromise. It also adds

1252

post-breach investigation, hunting, and response, as well as automation and simulation (for training).

1253

3.4.13.10 Azure App Proxy & Intune VPN Tunnel

1254

Azure Active Directory Application Proxy provides secure remote access and cloud-scale security to an

1255

organization’s private applications.

1256

Microsoft Tunnel is a VPN gateway solution for Microsoft Intune that runs in a container on Linux and

1257

allows access to on-premises resources from iOS/iPadOS and Android Enterprise devices using modern

1258

authentication and Conditional Access.

1259

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 32

3.4.13.11 Secure Admin Workstation (SAW)

1260

Secure Admin Workstations are limited-use client computers—built on Windows 10—that help protect

1261

high-risk environments from security risks such as malware, phishing, and pass-the-hash attacks. They

1262

provide secure access to restricted environments.

1263

3.4.13.12 Windows 365 for Enterprise and Azure Virtual Desktop

1264

Windows 365 for Enterprise is a cloud-based service that automatically creates a new type of Windows

1265

virtual machine (Cloud PCs) for your end users that provides the productivity, security, and collaboration

1266

benefits of Microsoft 365.

1267

Azure Virtual Desktop is a desktop and app virtualization service that runs on the cloud.

1268

For this project, Microsoft 365 for Enterprise and Azure Virtual Desktop can both be used to show how

1269

to secure virtual desktop infrastructure (VDI).

1270

3.4.13.13 Microsoft Defender for Cloud

1271

Defender for Cloud is a tool for security posture management and threat protection. It strengthens the

1272

security posture of an organization’s cloud resources, and with its integrated Microsoft Defender plans,

1273

Defender for Cloud protects workloads running in Azure, hybrid, and other cloud platforms. Because it’s

1274

natively integrated, deployment of Defender for Cloud is easy, providing an organization with simple

1275

auto provisioning to secure its resources by default.

1276

3.4.13.14 Microsoft Purview

1277

Microsoft Purview is a unified data governance service that helps organizations manage and govern

1278

their on-premises, multi-cloud, and SaaS data. It creates a holistic, up-to-date map of an organization’s

1279

data landscape with automated data discovery, sensitive data classification, and end-to-end data

1280

lineage, enabling data curators to manage and secure the organization’s data estate. It also empowers

1281

data consumers to find valuable, trustworthy data.

1282

3.4.13.15 Microsoft Defender for Cloud Apps

1283

Microsoft Defender for Cloud Apps is a CASB that supports various deployment modes, including log

1284

collection, API connectors, and reverse proxy. It provides rich visibility, control over data travel, and

1285

sophisticated analytics to identify and combat cyberthreats across all of an organization’s Microsoft and

1286

third-party cloud services. Microsoft Defender for Cloud Apps natively integrates with Microsoft

1287

solutions and is designed with security professionals in mind. It provides simple deployment, centralized

1288

management, and innovative automation capabilities.

1289

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 33

3.4.13.16 Microsoft Entra Permissions Management

1290

Microsoft Entra Permissions Management (formerly known as CloudKnox) is a cloud infrastructure

1291

entitlement management (CIEM) solution that provides comprehensive visibility into permissions

1292

assigned to all identities, for example, overprivileged workload and user identities, actions, and

1293

resources across multi-cloud infrastructures in Microsoft Azure, AWS, and GCP.

1294

3.4.14 Okta

1295

Okta is an independent identity provider helping organizations protect the identities of their extended

1296

workforces, partners, and customers. With more than 7,000 pre-built integrations to applications and

1297

infrastructure providers, Okta provides simple and secure access to people and organizations

1298

everywhere, giving them the confidence to reach their full potential. Learn more about Okta here:

1299

Okta.com.

1300

3.4.14.1 Okta Identity Cloud

1301

The Okta Identity Cloud is an independent and neutral platform that securely connects the correct

1302

people to the correct technologies at the appropriate time. The Okta Identity Cloud includes identity and

1303

access management products, integrations, and platform services for extended Workforce Identity and

1304

Customer Identity use cases.

1305

The Okta Identity Cloud provides secure user storage, authentication capabilities (primary and MFA) to

1306

applications and resources (infrastructure, APIs) regardless of location (on-premises, cloud, or hybrid),

1307

as well as automation and orchestration capabilities for identity use cases, such as for automating user

1308

on- and off-boarding or for identifying and acting on inactive user accounts. Products used in this project

1309

include the following.

1310

3.4.14.1.1 Universal Directory

1311

Okta Universal Directory is a cloud metadirectory that is used as a single source of truth to manage all

1312

users (employees, contractors, customers), groups, and devices. These users can be sourced directly

1313

within Okta or from any number of sources including AD, Lightweight Directory Access Protocol (LDAP),

1314

HR systems, and other SaaS applications.

1315

3.4.14.1.2 Single Sign-On (SSO)

1316

Okta SSO delivers seamless and secure access to all cloud and on-premises apps for end users,

1317

centralizing and protecting all user access via Okta’s cloud portal.

1318

Okta FastPass, available as a part of Okta SSO, enables passwordless authentication. Organizations can

1319

use Okta FastPass to minimize end user friction when accessing corporate resources, while still enforcing

1320

Okta’s adaptive policy checks.

1321

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 34

3.4.14.1.3 Adaptive Multi-Factor Authentication (MFA)

1322

Okta Adaptive MFA uses intelligent policies to enable contextual access management, allowing

1323

administrators to set policies based on risk signals native to Okta as well as from third parties, such as

1324

device posture from EDR vendors. Okta Adaptive MFA also enables administrators to choose the

1325

factor(s) that work best for their organization, balancing security and ease of use with options such as

1326

secure authenticator apps, WebAuthn, and biometrics, which many organizations also choose as

1327

passwordless options.

1328

3.4.14.1.4 Okta Access Gateway

1329

Okta Access Gateway is an application access proxy that delivers access management (SSO, MFA, and

1330

URL authorization) to on-premises apps using legacy on-premises protocols – header-based

1331

authentication and Kerberos – without requiring changes in source code. In combination with Okta SSO,

1332

it allows users to access cloud and on-premises apps remotely from a single place and delivers the same

1333

easy and secure login experience for SaaS and on-premises apps.

1334

3.4.14.1.5 Okta Verify

1335

Okta Verify is a lightweight application that is used both as an authenticator option (e.g., OTP or push,

1336

available on macOS, Windows, iOS, and Android) with Okta MFA as well as to register a device to Okta.

1337

Registering a device to Okta enables organizations to deliver secure, seamless, passwordless

1338

authentication to apps, strong device-level security, and more. Okta Verify is FIPS 140-2 validated. [9]

1339

3.4.14.1.6 Okta Integration Network

1340

The Okta Integration Network serves as a conduit to connect thousands of applications and resources

1341

(infrastructure, APIs) to Okta for access management (SSO/MFA) and provisioning (automating on- and

1342

off-boarding of user accounts). This integration network makes it easy for administrators to manage and

1343

control access for all users behind a single pane of glass, and easy for users to get to the tools they need

1344

with a unified access experience.

1345

In addition, the Okta Integration Network also serves as a rich ecosystem to support risk signal sharing

1346

for zero trust security. Okta’s deep integration with partners in the zero trust ecosystem allows the Okta

1347

Identity Cloud to take in risk signals for the purpose of making smarter contextual decisions regarding

1348

access. For example, integrations with EMM or EDR solutions allow the Okta IDaaS platform to know the

1349

managed state of a device or device risk posture and make decisions regarding access accordingly. Okta

1350

can also pass risk signals to third parties such as inline network solutions, which can in turn leverage

1351

Okta’s risk assessment to limit actions within SaaS apps when risk is high (e.g., read-only). Okta’s risk-

1352

based approach to access allows for fine-grained control of user friction and provides organizations with

1353

a truly zero trust PDP to make just-in-time, contextual-based authentication decisions to any resource,

1354

from anywhere.

1355

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 35

3.4.15 Palo Alto Networks

1356

Palo Alto Networks is shaping the cloud-centric future with technology designed to transform the way

1357

people and organizations operate by using the latest breakthroughs in AI, analytics, automation, and

1358

orchestration. By delivering an integrated platform and empowering a growing ecosystem of partners,

1359

Palo Alto Networks security technologies enable organizations to apply consistent security controls

1360

across clouds, networks, endpoints, and mobile devices.

1361

Their core capabilities include the ability to inspect all traffic, including all applications, threats, and

1362

content, and tie that traffic to the user, regardless of location or device type. The user, application, and

1363

content—the elements that run your business—become integral components of your enterprise’s zero

1364

trust security policy.

1365

Towards that end, their Next Generation Firewall (including all hardware-based, VM, and containerized

1366

form factors) and Prisma Access have consistent core capabilities fundamental for zero trust policy

1367

enforcement—including User-ID, App-ID, and Device-ID.

1368

▪ User-ID™ technology enables organizations to identify users in all locations, no matter their

1369

device type or OS. Visibility into application activity—based on users and groups, instead of IP

1370

addresses—safely enables applications by aligning usage with business requirements.

1371

▪ App-ID™ technology enables organizations to accurately identify applications in all traffic

1372

passing through the network, including applications disguised as authorized traffic, using

1373

dynamic ports, or trying to hide under the veil of encryption. App-ID allows organizations to

1374

understand and control applications and their functions, such as video streaming versus chat,

1375

upload versus download, and screen-sharing versus remote device control.

1376

▪ Device-ID™ technology enables organizations to enforce policy rules based on a device,

1377

regardless of changes to its IP address or location. By providing traceability for devices and

1378

associating network events with specific devices, Device-ID allows organizations to gain context

1379

for how events relate to devices and write policies that are associated with devices, instead of

1380

users, locations, or IP addresses, which can change over time.

1381

All NGFW form factors and Prisma Access also include the following cloud-delivered security service

1382

(CDSS) capabilities: Advanced Threat Prevention (ATP), Wildfire (WF) malware analysis, Advanced URL

1383

Filtering (AURL), and DNS Security (DNS). These capabilities are supported by the GlobalProtect (GP)

1384

remote access solution and can all be centrally managed by Panorama.

1385

3.4.15.1 Next-Generation Firewall (NGFW)

1386

The Palo Alto Networks Next-Generation Firewall (NGFW) is an ML-powered network security platform

1387

available in physical, virtual, containerized, and cloud-delivered form factors—all managed centrally via

1388

Panorama. The Palo Alto Networks NGFWs inspect all traffic, including all applications, threats, and

1389

content, and tie that traffic to the user, regardless of location or device type. Built on a single-pass

1390

architecture, the Palo Alto Networks NGFW performs full-stack, single-pass inspection of all traffic

1391

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 36

across all ports, providing complete context around the application, associated content, and user

1392

identity to form the basis for zero trust security policy decisions.

1393

Additional NGFWs, including cloud-delivered, software-based VMs (VM-Series), and container-based

1394

(CN-Series), are anticipated to be used as part of the micro-segmentation deployment model phase of

1395

this project, deployed as PEPs deeper within each enterprise environment. Regardless of form factor,

1396

any NGFW or Prisma Access instance can serve as a PEP, enabled by the core (User-ID, Application-ID,

1397

Device-ID) technologies described above—helping organizations achieve common zero trust use cases

1398

such as data center segmentation, user or application-based segmentation, or cloud transformation.

1399

3.4.15.2 Prisma Access

1400

Prisma Access allows organizations to securely enable remote workforces and branch locations, and will

1401

be more extensively demonstrated during the SDP deployment model phase of the project. The cloud-

1402

native architecture of Prisma Access is designed to ensure on-demand and elastic scaling of

1403

comprehensive networking and security services across a global, high-performance network. Together

1404

with Prisma SD-WAN (software-defined wide area network), Prisma Access provides the foundational

1405

layer for a complete secure access service edge (SASE) solution that delivers networking and security

1406

with a common service delivery model.

1407

Prisma Access combines least-privileged access with deep and ongoing security inspection as well as

1408

enterprise DLP to protect all users, devices, apps, and data. Prisma Access fully inspects all application

1409

traffic bidirectionally—including TLS-encrypted traffic—on all ports, whether communicating with the

1410

internet, the cloud, the data center, or between branches. Additionally, Prisma Access provides more

1411

security coverage consolidating multiple point products into a single converged platform that includes

1412

Firewall as a Service (FWaaS), Zero Trust Network Access (ZTNA), next-generation CASB, cloud SWG,

1413

VPN, and more—all managed through a single console.

1414

Prisma Access connects users and applications with fine-grained access controls, providing behavior-

1415

based continuous trust verification after users connect to dramatically reduce the attack surface.

1416

3.4.15.3 Cortex XDR

1417

Cortex XDR is an XDR tool that natively integrates network, endpoint, and cloud data to stop

1418

sophisticated attacks. Leveraging behavioral analytics, it identifies unknown and highly evasive threats

1419

targeting your environment. ML and AI models uncover threats from multiple sources, including

1420

managed and unmanaged devices. Cortex XDR speeds alert triage and incident response by providing a

1421

comprehensive picture of each threat and revealing the root cause. By stitching different types of data

1422

together and simplifying investigations, Cortex XDR reduces the time and experience required at every

1423

stage of security operations, from triage to threat hunting. Native integration with enforcement points

1424

lets you respond to threats quickly and apply the knowledge gained from investigations to mitigate

1425

future attacks.

1426

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 37

Cortex XDR features Identity Analytics, which detects malicious user activities by applying ML and

1427

behavioral analytics to users, machines, and entities. Using an analytics engine to examine logs and data,

1428

Identity Analytics can understand normal behaviors across your environment and create a baseline so

1429

that it can raise alerts when abnormal activity occurs. With this function, suspicious user activity such as

1430

stolen or misused credentials, lateral movement, credential harvesting, exfiltration, and brute-force

1431

attacks can be detected. This ML-derived insight offers critical identity context specific to each bespoke

1432

environment Cortex XDR is deployed into, allowing for higher fidelity alerts to aid organizations in fine

1433

tuning access granted to critical assets—an imperative for ZTA.

1434

3.4.16 PC Matic

1435

PC Matic is an endpoint protection solution for enterprises of all sizes, utilizing PC Matic’s proactive

1436

application allowlisting technology. Through a series of global and local allowlists, PC Matic’s software

1437

asset management restricts unauthorized programs and processes from accessing resources such as

1438

data or services on a network. Unlike traditional application allowlisting products that solely rely on self-

1439

made local allowlists, PC Matic operates off both the user’s local list and a real-time automated global

1440

allowlist consisting of verified files, processes, digital certificates, and scripts. PC Matic eliminates

1441

governance issues by granting users the ability to create application, digital certificate, directory, or

1442

scripting policies within their local lists. This capability takes immediate effect and can be deployed to

1443

individual endpoints, departments, groups, whole organizations, and all agencies and enterprises

1444

managed across the account.

1445

3.4.16.1 PC Matic Pro

1446

PC Matic Pro’s on-premises endpoint protection provides default-deny protection at the device. PC

1447

Matic Pro monitors for any process that attempts to execute and automatically denies access to any

1448

unauthorized or known malicious entities. When the unauthorized files and/or processes are denied

1449

access, all metadata pertaining to the block is then communicated to the architecture’s SIEM for

1450

prioritizing and further investigation. This integration provides users with increased visibility over their

1451

managed devices and networks. If a block is verified and warranted, the SIEM of choice can utilize the

1452

policy engine from either PC Matic or a third-party vendor to create and enforce the exception, granting

1453

immediate access to the desired deployment. PC Matic’s real-time policy offerings eliminate governance

1454

issues, take immediate effect without delay or issue, and provide users with streamlined management

1455

across their managed architectures. PC Matic’s allow-by-exception approach to prevention enhances the

1456

zero-trust model and minimizes the network’s attack surface by ensuring only authorized processes are

1457

granted privileges to execute and proceed further.

1458

3.4.17 Ping Identity

1459

Ping Identity delivers intelligent identity solutions for the enterprise. Ping enables companies to achieve

1460

zero trust identity-defined security and more personalized, streamlined user experiences. The PingOne

1461

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 38

Cloud Platform provides customers, workforces, and partners with access to cloud, mobile, SaaS, and

1462

on-premises applications across the hybrid enterprise. Over half of the Fortune 100 choose Ping for their

1463

identity expertise, open standards, and partnerships with companies including Microsoft and Amazon.

1464

Ping Identity provides flexible identity solutions that accelerate digital business initiatives and secure the

1465

enterprise through multi-factor authentication, single sign-on, access management, intelligent API

1466

security, and directory and data governance capabilities. For more information, please visit

1467

https://www.pingidentity.com/.

1468

3.4.17.1 PingFederate

1469

PingFederate is an enterprise federation server that enables user authentication and single sign-on. It is

1470

a global authentication authority that allows customers, employees, and partners to access all the

1471

applications they need from any device securely. PingFederate easily integrates with applications across

1472

the enterprise, third-party authentication sources, diverse user directories, and existing IAM systems, all

1473

while supporting current and past versions of identity standards. It will connect everyone to everything.

1474

PingFederate can be deployed within Ping Identity’s SaaS offerings, in a customer cloud, as a traditional

1475

application, and within air-gapped or network segmented environments.

1476

The deployment architecture of PingFederate eliminates the need to maintain redundant copies of

1477

configurations and trust relationships. Supported federation standards include OAuth, OpenID, OpenID

1478

Connect, SAML, WS-Federation, WS-Trust, and System for Cross-Domain Identity Management (SCIM).

1479

3.4.17.2 PingOne DaVinci

1480

PingOne DaVinci is a SaaS platform that enables a flexible and adaptive integration framework, allowing

1481

you to easily create identity journeys via a drag-and-drop interface. Through DaVinci, administrators can

1482

quickly design automated workflows for different identity use cases including authentication, identity

1483

proofing, and fraud detection. DaVinci is an open interface with integrations and connections across

1484

multiple applications and identity ecosystems.

1485

3.4.17.3 PingOne SSO

1486

PingOne SSO is a SaaS federation platform. Using single sign-on (SSO), users can sign on to all their

1487

applications and services with one set of credentials. It gives employees, partners, and customers

1488

secure, one-click access from anywhere, on any device, and it reduces the number of separate accounts

1489

and passwords they need to manage.

1490

SSO is made possible by a centralized authentication service that all apps (even third-party) can use to

1491

confirm a user’s identity. Identity standards like SAML, OAuth, and OpenID Connect allow for encrypted

1492

tokens to be transmitted securely between the server and the apps to indicate that a user has already

1493

been authenticated and has permission to access the additional apps.

1494

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 39

3.4.17.4 PingOne Risk

1495

PingOne Risk is a SaaS platform that enables administrators to configure intelligence-based

1496

authentication policies by combining the results of multiple risk predictors to calculate a single risk

1497

score. Data feeds and inputs roll into set risk predictors. The predictors are assigned different scores and

1498

aggregated into a risk policy to determine if a user poses low, medium, or high risk to the organization

1499

and what level of authentication will be required. Administrators can create multiple risk policies and

1500

apply them in different use cases to meet business requirements.

1501

3.4.17.5 PingOne Verify

1502

PingOne Verify is a SaaS platform that reduces uncertainty during onboarding and prevents fraudulent

1503

registration with convenient identity verification. PingOne Verify enables secure user verification based

1504

on a government-issued document and real-time face capture (a live selfie). The Verify dashboard

1505

summarizes all transactions, which enables you to manage all verifications, exceptions, and rejections

1506

within the PingOne platform.

1507

3.4.17.6 PingOne Authorize

1508

PingOne Authorize is a SaaS platform that leverages real-time data to make authorization decisions for

1509

access to data, services, APIs, and other resources. Organizations increasingly want to codify their

1510

authorization requirements as policies, giving business owners the flexibility to adapt and evolve access

1511

control rules over time. Our solution helps organizations accurately control what users can see and do

1512

within applications and APIs. With an exploding number of applications, regulations, and access control

1513

requirements to manage, abstracting authorization logic to a centralized administrative control plane is

1514

the key to enabling scale and consistency.

1515

3.4.17.7 PingID

1516

PingID is a SaaS platform that provides an MFA solution for the workforce and partners that drastically

1517

improves organizational security posture in minutes. PingID protects applications accessed via SSO and it

1518

integrates seamlessly with Microsoft Azure AD, Active Directory Federation Services (AD FS), and

1519

Windows login, Mac login, and SSH applications.

1520

Supported authentication methods include mobile push, email OTP, SMS OTP, TOTP authenticator apps,

1521

QR codes, FIDO2-bound biometrics, and security keys.

1522

3.4.17.8 PingAccess

1523

PingAccess is a centralized access security solution with a comprehensive policy engine. It provides

1524

secure access to applications and APIs down to the URL level and ensures that only authorized users can

1525

access the resources they need. PingAccess allows organizations to protect web apps, APIs, and other

1526

resources using rules and other authentication criteria.

1527

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 40

PingAccess can be deployed within Ping Identity’s SaaS offerings, in a customer cloud, as a traditional

1528

application, and within air-gapped or network segmented environments.

1529

3.4.17.9 PingDirectory

1530

PingDirectory is a fast, scalable directory used to store identity and rich profile data. Organizations that

1531

need maximum uptime for millions of identities use PingDirectory to securely store and manage

1532

sensitive customer, partner, and employee data. PingDirectory acts as a single source of identity truth.

1533

Users get loaded into PingDirectory through import, API connection, manual entry or bidirectional, real-

1534

time synchronization from LDAP, RDBMS, JDBC, or SCIM data stores. Both structured and unstructured

1535

user data are secured and stored by leveraging encryption, password validators, cryptographic log

1536

signing, and more. Out-of-the-box load balancing, rate limiting, and data transformations with an

1537

integrated proxy ensure maximum server performance and user data availability at scale during peak

1538

usage.

1539

PingDirectory can be deployed within Ping Identity’s SaaS offerings, in a customer cloud, as a traditional

1540

application, and within air-gapped or network segmented environments.

1541

3.4.18 Radiant Logic

1542

Radiant Logic, the enterprise Identity Data Fabric company, helps organizations combat complexity and

1543

improve defenses by making identity data easy to access, manage, use, and protect. With Radiant, it’s

1544

fast and easy to put identity data to work, creating the identity data foundation of the enterprise where

1545

organizations can realize meaningful business value, accelerate innovation, and achieve zero trust. Built

1546

to combat identity sprawl, enterprise technical debt, and interoperability issues, the RadiantOne

1547

platform connects many disparate identity data sources across legacy and cloud infrastructures, without

1548

disruption. It can accelerate the success of initiatives including SSO, M&A integrations, identity

1549

governance and administration, hybrid and multi-cloud environments, customer identity and access

1550

management, and more with an identity data fabric foundation. Visit http://www.radiantlogic.com/ to

1551

learn more.

1552

3.4.18.1 RadiantOne Intelligent Identity Data Platform

1553

The RadiantOne Intelligent Identity Data Platform builds an identity data fabric using federated identity

1554

as the foundation for zero trust. It is the single authoritative source for identity data, enabling critical

1555

initiatives by making identity data and related context available in real time to consumers regardless of

1556

where that data resides. RadiantOne’s Intelligent Identity Data Platform uses patented identity

1557

unification methods to abstract and enrich identity data from multiple sources, build complete global

1558

user profiles, and deliver real-time identity data on-demand to any service or application. Zero trust

1559

relies on evaluating a rich and authoritative granular set of attributes in real time against an access

1560

policy to determine authorization. RadiantOne provides a single authoritative place for all components

1561

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 41

of the ZTA to quickly and easily request the exact data they need in the format, structure, schema, and

1562

protocol each requires. In order to provide the flexibility and scalability that organizations need, the

1563

platform is broken into six distinct modules: Federated Identity Engine; Universal Directory; Global

1564

Synchronization; Directory Migration; Insights, Reports & Administration; and Single Sign-On.

1565

3.4.18.1.1 RadiantOne Federated Identity Engine

1566

The Federated Identity Engine abstracts and unifies identity data from all sources (on-premises or cloud-

1567

based) to form an identity data fabric that is flexible, scalable, and turns identity data into a reusable

1568

resource. The identity data fabric provides a central access point for authoritative identity data to all

1569

applications, and encompasses all subjects, users, and objects (employees, contractors, partners,

1570

customers, members, non-enterprise employees, devices, NPEs, service accounts, bots, IoT, risk scoring,

1571

and data and other assets). RadiantOne gathers, maps, normalizes, and transforms identity data to build

1572

a de-duplicated list of users, enriched with all identity attributes to create a single global profile for each

1573

user. The Federated Identity Engine is schema-agnostic and standards-based, which allows it to build

1574

unlimited and flexible views correlated from all sources of rich and granular identity data, updated in

1575

near-real-time, and delivered at speed in the format required by all the consuming applications in the

1576

ZTA. These views are stored in a highly scalable, modern big data store kept in near-real-time sync with

1577

local identity sources of truth.

1578

3.4.18.1.2 RadiantOne Universal Directory

1579

The RadiantOne Universal Directory provides a modern way of storing and accessing identity

1580

information in a highly scalable, fault-tolerant, containerized solution for distributed identity storage. Its

1581

highly performant cluster architecture scales easily to hundreds of millions of objects, delivers

1582

automation, high availability, and multi-cluster deployments to easily accommodate distributed data

1583

centers. Universal Directory is FIPS 140-2 certified for securing data-in-transit and data-at-rest, and it

1584

provides detailed audit logs and reports [10]. Universal Directory is accessible by all LDAP, SQL, SCIM,

1585

and REST-enabled applications.

1586

3.4.18.1.3 RadiantOne Single Sign On (SSO)

1587

Single Sign On is the gateway between identity stores and applications that support federation

1588

standards—SAML, OIDC, WS-Federation—for connecting users with seamless, secure, and uniform

1589

access to federated applications. SSO enables a secure federated infrastructure, creating one access

1590

point to connect all internal identity and authentication sources for strong authentication. It also

1591

provides a self-service portal for managing passwords and user profiles.

1592

3.4.18.1.4 RadiantOne Global Synchronization

1593

Global Synchronization leverages bi-directional connectors to propagate identity data and keep it

1594

coherent across enterprise systems in near-real-time, regardless of the location of the underlying

1595

identity source data (on-premises, cloud-based, or hybrid). It builds a reliable and highly scalable

1596

infrastructure with a transport layer based on message queuing for guaranteed delivery of changes.

1597

Global Synchronization reduces complexity and administrative burden, simplifies provisioning and

1598

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 42

syncing identity centrally, and ensures consistency and accuracy with real-time change detection to

1599

underlying identity data attributes.

1600

3.4.19 SailPoint

1601

SailPoint offers identity security technologies that automate the identity lifecycle; manage the integrity

1602

of identity attributes; enforce least privilege through dynamic access controls, role-based policies, and

1603

separation of duties (SoD); and continuously assess, govern, and respond to access risks using AI and

1604

ML. SailPoint Identity Security is the cornerstone of an effective zero trust strategy. Discover more at

1605

https://www.sailpoint.com/.

1606

3.4.19.1 IdentityIQ Platform

1607

SailPoint IdentityIQ is an identity and access management software platform custom-built for complex

1608

enterprises. It delivers full lifecycle and compliance management for provisioning, access requests,

1609

access certifications, and SoD. The platform integrates with SailPoint’s extensive library of connectors to

1610

intelligently govern access to today’s essential business applications. Harnessing the power of AI and

1611

ML, SailPoint’s AI Services seamlessly automate access, delivering only the required access to the correct

1612

identities and technology at the appropriate time.

1613

As an identity governance platform, SailPoint provides organizations with a foundation that enables a

1614

compliant and secure infrastructure driven by a zero-trust approach with complete visibility of all access,

1615

frictionless automation of processes, and comprehensive integration across hybrid environments.

1616

SailPoint connects to enterprise resources to aggregate accounts and correlate with authoritative

1617

records to build a foundational identity profile from which all enterprise access is based. Users are

1618

granted birthright access based on dynamic attribute evaluation, and additional access for all integrated

1619

resources is requested and governed through a centralized SailPoint request portal. The SailPoint

1620

governance platform is enriched through its extensible API framework to support integrations with

1621

other identity security tools. The IdentityIQ platform contains two components, IdentityIQ Compliance

1622

Manager and IdentityIQ Lifecycle Manager.

1623

3.4.19.1.1 IdentityIQ Compliance Manager

1624

IdentityIQ Compliance Manager automates access certifications, policy management, and audit

1625

reporting to streamline compliance processes and improve the effectiveness of identity governance.

1626

Access certification ensures least-privileged access by continuously monitoring and removing accounts

1627

and entitlements that are no longer needed.

1628

Separation of duties policies enforce business procedures to detect and prevent inappropriate access or

1629

actions by proactively scanning for violations.

1630

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 43

Audit reporting simplifies the collection the information needed to manage the compliance process and

1631

replaces manual searches for data located in various systems around the enterprise through an

1632

integrated platform.

1633

3.4.19.1.2 IdentityIQ Lifecycle Manager

1634

IdentityIQ Lifecyle Manager enables an organization to manage changes to access through user-friendly

1635

self-service requests and lifecycle events for fast, automated delivery of access to users.

1636

Access requests enable users to request and receive access to enterprise on-premises and SaaS

1637

applications and data while ensuring compliance through policy enforcement and elevating reviews for

1638

privileged access.

1639

Automated provisioning detects and triggers changes to a user’s access based on a user joining, moving

1640

within, or leaving an organization. Direct provisioning reduces risk by automatically changing or

1641

removing accounts and access in an appropriate manner with automated role and attribute-based

1642

access.

1643

3.4.20 Tenable

1644

Tenable®, Inc. is the Cyber Exposure company. Organizations around the globe rely on Tenable to

1645

understand and reduce cyber risk. As the creator of Nessus®, Tenable extended its expertise in

1646

vulnerabilities to see and secure any digital asset on any computing platform.

1647

3.4.20.1 Tenable.io

1648

1649

vulnerability coverage with the ability to predict which security issues to remediate first. Using an

1650

advanced asset identification algorithm, Tenable.io can provide accurate information about dynamic

1651

assets and vulnerabilities in ever-changing environments. As a cloud-delivered solution, its intuitive

1652

dashboard visualizations, comprehensive risk-based prioritization, and seamless integration with third-

1653

party solutions help security teams maximize efficiency and scale for greater productivity.

1654

3.4.20.2 Tenable.ad

1655

Tenable.ad is a software solution that helps organizations harden their AD by finding and fixing AD

1656

weaknesses and vulnerabilities before attacks happen. Tenable.ad Indicators of Exposure discover and

1657

prioritize weaknesses within existing AD domains and reduce exposure by following Tenable.ad step-by-

1658

step remediation guidance. Tenable.ad keeps an AD in this hardened state by continuously monitoring

1659

and alerting in real time of any new misconfigurations, while Tenable.ad Indicators of Attacks enables

1660

detection and response to AD attacks in real time. In addition, Tenable.ad tracks and records all changes

1661

to an AD, helping show the link between AD changes and malicious actions. Tenable.ad can send alerts

1662

using email or through an existing SIEM solution.

1663

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 44

3.4.20.3 Tenable.cs

1664

Tenable.cs is Tenable’s cloud security solution to help organizations programmatically detect and fix

1665

cloud infrastructure security issues in design, build, and runtime phases of the software development

1666

lifecycle (SDLC). Tenable.cs enables organizations to establish guardrails in DevOps processes to prevent

1667

unresolved misconfigurations or vulnerabilities in Infrastructure as Code (IaC) from reaching production

1668

environments. The product monitors cloud resources deployed in AWS, Azure, and GCP to ensure any

1669

runtime changes are compliant with policies, and remediations to address configuration drifts are

1670

automatically propagated back to the IaC. Tenable.cs also provides continuous visibility to assess cloud

1671

hosts and container images for vulnerabilities whether they’re deployed for days or hours, without the

1672

need to manage scan schedules, credentials, or agents. All cloud assets—including ephemeral assets—

1673

are continuously reassessed as new vulnerability detections are added and as new assets are deployed.

1674

This always-on approach allows organizations to spend more time focusing on the highest priority

1675

vulnerabilities and less time on managing scans and software.

1676

3.4.21 Trellix

1677

Trellix is redefining the future of cybersecurity. The company’s open and native XDR platform helps

1678

organizations confronted by today’s most advanced threats gain confidence in the protection and

1679

resilience of their operations. Trellix’s security experts, along with an extensive partner ecosystem,

1680

accelerate technology innovation through ML and automation to empower customers. See more at

1681

https://trellix.com/. Trellix solutions can play a pivotal role in assisting organizations in meeting their

1682

zero trust outcomes through Trellix’s extensive portfolio of enforcement points, rapidly growing partner

1683

ecosystem, and ability to quickly quantify risk and orchestrate responses.

1684

Trellix offers a comprehensive portfolio of tools that align with zero trust objectives and outcomes. The

1685

following subsections discuss the tools from the portfolio currently being included in this NCCoE effort.

1686

3.4.21.1 MVISION Complete Suite

1687

MVISION Complete delivers a comprehensive suite of tools that provide threat and data protection

1688

across endpoints, web, and cloud. Individual products included in the MVISION Complete Suite include

1689

the following.

1690

3.4.21.1.1 Trellix ePO

1691

Trellix ePolicy Orchestrator (ePO) is a centralized management console for deploying, configuring, and

1692

managing Trellix endpoint security solutions including threat prevention, data protection, and EDR. For

1693

more information on Trellix ePO, please visit ePolicy Orchestrator | Trellix.

1694

3.4.21.1.2 Trellix Insights

1695

Trellix Insights is a threat intelligence platform integrated with the Trellix solution portfolio that enables

1696

customers to gain contextual understanding of active global threat campaigns relevant to their vertical.

1697

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 45

Through integrated understanding of compensating controls and detection events, Insights enables

1698

organizations to predictively stay ahead of threats, quickly identify campaign activity within their

1699

environment, and receive the guidance necessary to proactively defend against campaigns. For more

1700

information on Trellix Insights, please visit Trellix Insights | Trellix.

1701

3.4.21.1.3 Trellix Endpoint Security Platform

1702

Trellix Endpoint Security Platform blocks malicious and targeted attacks using traditional and enhanced

1703

detection techniques as part of a layered protection strategy. Techniques include generic malware

1704

detection, behavioral detection, ML, containment, and enhanced remediation. For more information on

1705

Trellix Endpoint Security, please visit Trellix Endpoint Security | Trellix.

1706

3.4.21.1.4 Trellix EDR

1707

Trellix EDR collects and analyzes device trace data using advanced detection techniques in order to

1708

surface suspected threats within an enterprise. Trellix EDR empowers security operations teams to gain

1709

important context about the environment with true real-time enterprise search capabilities and

1710

integrated threat intelligence. Trellix EDR is an asset to resource-starved security operations teams

1711

working to keep up with the ever-growing threat landscape by incorporating integrated AI-assisted

1712

guided investigations. Guided investigations analyze thousands of artifacts beyond the initial detection

1713

event to replicate a traditionally manual playbook process. By automating this process, analysts can

1714

reach conclusions faster, reduce time to detection, and accelerate confident response activities. For

1715

more information on Trellix EDR, please visit Trellix EDR – Endpoint Detection & Response | Trellix.

1716

3.4.21.1.5 Trellix DLP Endpoint

1717

Trellix DLP Endpoint enables organizations to discover, control, and block access to sensitive data on the

1718

endpoint. Trellix DLP Endpoint integrates with identity providers to assign policy based on users’ roles

1719

and groups, and in a ZTA can adjust data protection policy as user trust changes. Additionally, DLP

1720

Endpoint is managed by ePO, and it includes a full case management system for aggregating multiple

1721

DLP incidents and identifying malicious insiders. For more information on Trellix DLP Endpoint, please

1722

visit DLP Endpoint | Trellix.

1723

3.4.21.1.6 Skyhigh Security SSE Platform

1724

Skyhigh Security, once part of Trellix’s foundational company, McAfee Enterprise, has been established

1725

as a separate business entity and sister company to Trellix. Skyhigh Security’s Security Service Edge (SSE)

1726

platform is part of the MVISION Complete Suite, delivered by Skyhigh Security, and offers

1727

comprehensive protection for cloud, web, and data protection. Skyhigh Security integrates a CASB

1728

platform with strong cloud-hosted web security and data protection controls to deliver a highly secure,

1729

highly available platform for protecting hybrid and multi-cloud enterprises. For more information on

1730

Skyhigh Security’s SSE platform please visit What is SSE? | Security Service Edge | Skyhigh Security.

1731

The MVISION Complete Suite aids in the ability to meet zero trust objectives by delivering device-level

1732

protection and alerting, application protection through contextual access controls, user trust through

1733

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 46

user activity monitoring, data security through comprehensive data protection and discovery, and

1734

analytics and intelligence through EDR and Insights.

1735

3.4.21.2 Full Remote Browser Isolation

1736

Remote browser isolation enables organizations to fully contain web applications within a secure

1737

container to prevent malware and data leakage and provide complete control over a browser session.

1738

The Skyhigh SSE solution out of the box offers remote browser isolation for risky websites to ensure no

1739

implicit trust is being granted to web applications prior to trust validation. In some cases, organizations

1740

would choose that no implicit trust is ever extended to web traffic, regardless of known reputation. In

1741

this scenario, full-time browser isolation is required to meet this objective. The Trellix offering, with

1742

sister company Skyhigh Security, includes the ability for full remote browser isolation as an add-on

1743

module. For more information on Remote Browser Isolation, see Remote Browser Isolation | McAfee

1744

Products.

1745

3.4.21.3 Helix (XDR)

1746

To achieve zero trust outcomes, it is necessary to have a common platform that applies AI-driven, real-

1747

time threat intelligence to data collected from devices and security sensors as a mechanism for surfacing

1748

advanced attacks and associated entity risk, and to orchestrate proactive and remediating responses

1749

across native and open security tools. Within many zero trust reference architectures, this platform

1750

could be considered the dynamic access control plane, or the trust algorithm.

1751

Trellix delivers this capability through Helix. Helix is a cloud-hosted, intelligence-driven platform that

1752

collects data from over 600 different sensors and point solutions, analyzes the data against known

1753

threats, behaviors, and campaigns using AI and enhanced detection rules, and powers automated and

1754

manual responses across Trellix native and third-party policy engines. For more information on Trellix

1755

XDR, see Trellix-Platform | Trellix.

1756

3.4.21.4 CloudVisory

1757

It’s no secret that cloud services are now pervasive; many applications have been moved either through

1758

SaaS or cloud services development to cloud data centers. This presents new challenges for many

1759

organizations as they work to gain better visibility and control over IaaS-hosted cloud applications and

1760

the thousands of micro-services that support them. As organizations look to adopt zero trust principles

1761

within the cloud, it will become imperative that proper service configuration, IAM roles, cloud network

1762

traffic, and workloads are fully evaluated for risk and protected. CloudVisory supports these objectives

1763

through:

1764

▪ CI/CD integration to ensure proper service configuration, and continuous posture assessments

1765

to guard against configuration drift

1766

▪ IAM policy inspection

1767

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 47

▪ intelligent network micro-segmentation

1768

▪ intra-cloud and cloud-to-cloud network monitoring

1769

▪ multi-cloud support

1770

For more information on CloudVisory, see ds-cloudvisory.pdf (fireeye.com).

1771

3.4.22 VMware

1772

VMware’s content will be included in the next draft version of this practice guide.

1773

3.4.23 Zimperium

1774

Zimperium secures both mobile devices and applications so they can safely and securely access data.

1775

Patented on-device ML-based security provides visibility and protection against known and zero-day

1776

threats and attacks.

1777

3.4.23.1 Zimperium Mobile Threat Defense

1778

Zimperium Mobile Threat Defense is an advanced MTD solution for enterprises, providing persistent, on-

1779

device protection to both corporate-owned and BYOD devices against modern attack vectors.

1780

Leveraging Zimperium’s patented z9 on-device detection engine, Zimperium MTD detects threats across

1781

the kill chain, including device compromise, network, phishing, and application attacks.

1782

Zimperium’s MTD provides on-device behavior detection via an on-device agent, even when the device

1783

is not connected to a network. Zimperium’s MTD begins protecting devices against all primary attack

1784

vectors immediately after deployment. The Zimperium zConsole provides a management interface used

1785

to configure threat policies, manage device groups/users, and view events and the forensics that are

1786

associated with those events.

1787

Zimperium provides critical mobile security data for organizations, with integrations into multiple,

1788

concurrent enterprise SIEM/SOAR, UEM, XDR, and IAM platforms. Data is securely shared via REST API,

1789

syslog, etc. Zimperium MTD provides comprehensive device attestation enabling a complete picture of

1790

mobile endpoint security and increased visibility into risks such as jailbreak detections. Zimperium MTD

1791

provides continuous protection for mobile devices, providing the risk intelligence and forensic data

1792

necessary for security administrators to raise their mobile security confidence. Zimperium integrates

1793

mobile threat data into security reporting systems and processes. Using Zimperium’s vast integrations

1794

ecosystem, mobile device state, security posture, events, etc. are shared, enabling multimodal

1795

protections to be automatically deployed, including “conditional access” to sensitive information via

1796

MDM/UEMs, SOAR, and IAM, for example. Zimperium MTD protects devices against all primary attack

1797

vectors, including via USB, removable storage, and even when the device is not connected to a network.

1798

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 48

3.4.24 Zscaler

1799

Zscaler provides secure user access to public-facing sites and on- or off-premises private applications via

1800

the Zscaler Zero Trust Exchange, a cloud-delivered security service edge technology. The Zero Trust

1801

Exchange helps IT move away from legacy network infrastructure to achieve modern workforce

1802

enablement, infrastructure modernization, and security transformation.

1803

Zscaler’s role in the ZTA is to provide full visibility and control of context-based, least-privilege access to

1804

internet and SaaS applications as well as private applications in IaaS, PaaS, or internally hosted

1805

environments via the Zero Trust Exchange.

1806

3.4.24.1 Zscaler Zero Trust Exchange

1807

Users accessing the internet or a SaaS application can leverage the Zscaler Internet Access (ZIA)

1808

solution. This solution delivers a comprehensive security stack—including TLS inspection, advanced

1809

firewall, SWG, DLP, virus protection, and sandbox capabilities—for end-users, which follows them no

1810

matter where they are.

1811

Users accessing private applications either locally or in the cloud can leverage the Zscaler Private Access

1812

(ZPA) solution, which also provides a virtual PDP+PEP in the cloud.

1813

The Zscaler Client Connector brokers access for both ZIA and ZPA, offering lightweight single-agent

1814

protection and visibility, as well as optionally gathering telemetry for end-user experience monitoring.

1815

Combining ZIA and ZPA provides a FedRAMP-accredited solution that organizations can integrate into

1816

their unique digital ecosystems today. Moreover, since Zscaler is an integral part of any zero trust

1817

framework, organizations can leverage Zscaler's cloud service provider, EDR, SIEM/SOAR, and SD-WAN

1818

integration partnerships with Microsoft, AWS, Okta, CrowdStrike, and other industry leaders to promote

1819

data visibility and access management.

1820

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 49

4 Architecture

1821

The project architecture is designed to include the core zero trust logical components as depicted in

1822

NIST SP 800-207. In Section 4.1 we present a general ZTA and describe its components and operation.

1823

These components may be operated as either on-premises or cloud-based services.

1824

In Section 4.2 we describe a particular version of this general ZTA that we call the EIG crawl phase

1825

reference architecture. Three of the ZTA builds that are documented in this practice guide are

1826

instantiations of this EIG crawl phase reference architecture. This architecture relies mainly on ICAM and

1827

endpoint protection platform (EPP) components, does not include any components that are specifically

1828

dedicated to providing PE or PA functionality, and is currently limited to protecting on-premises

1829

resources.

1830

In Section 4.3 we describe a second version of the general ZTA that we call the EIG run phase reference

1831

architecture. Two of the ZTA builds that are documented in this practice guide are instantiations of this

1832

EIG run phase reference architecture. Like the EIG crawl phase architecture, the EIG run phase

1833

architecture bases resource access decisions mainly on information provided by ICAM and EPP

1834

components. However, unlike the EIG crawl phase architecture, it may include PA and PE components

1835

that are not furnished by the ICAM provider. The EIG run phase architecture also protects both on-

1836

premises and cloud resources, and it supports device discovery and the establishment of tunnels

1837

between requesting endpoints and resources.

1838

In Section 4.4 we describe the physical architecture of the baseline laboratory environment in which we

1839

implemented all of the builds documented in this guide.

1840

Volume B will be updated throughout the project lifecycle as the architecture evolves to include

1841

additional functionalities, security capabilities, and ZTA deployment models.

1842

4.1 General ZTA Reference Architecture

1843

Figure 4-1 depicts the high-level logical architecture of a general ZTA reference design independent of

1844

deployment models. It consists of three types of core components: PEs, PAs, and PEPs, as well as several

1845

supporting components that assist the policy engine in making its decisions by providing data and policy

1846

rules related to areas such as ICAM, EDR/EPP, security analytics, and data security. Specific capabilities

1847

that fall into each of these supporting component categories are discussed in more detail later in this

1848

section. The various sets of information either generated via policy or collected by the supporting

1849

components and used as input to ZTA policy decisions are referred to as policy information points (PIPs).

1850

Each of the logical components in the reference architecture does not necessarily directly correlate to

1851

physical (hardware or software) components. In fact, although the simplicity of the architecture may

1852

seem to imply that the supporting components are simple plug-ins that respond in real-time to the PDP,

1853

in many cases the ICAM, EDR/EPP, security analytics, and data security PIPs will each represent complex

1854

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 50

infrastructures. Some ZTA logical component functions may be performed by multiple hardware or

1855

software components, or a single software component may perform multiple logical functions.

1856

Subjects (devices, end users, applications, servers, and other non-human entities that request

1857

information from resources) request and receive access to enterprise resources via the ZTA. Human

1858

subjects (i.e., users) are authenticated. Non-human subjects are both authenticated and protected by

1859

endpoint security. Enterprise resources may be located on-premises or in the cloud. Existing enterprise

1860

subjects and resources are not part of the reference architecture itself; however, any changes required

1861

to existing endpoints, such as installing ZTA agents, should be considered part of the reference

1862

architecture.

1863

Figure 4-1 General ZTA Reference Architecture

1864

4.1.1 ZTA Core Components

1865

The types of ZTA core components are:

1866

▪ Policy Engine (PE): The PE handles the ultimate decision to grant, deny, or revoke access to a

1867

resource for a given subject. The PE calculates the trust scores/confidence levels and ultimate

1868

access decisions based on enterprise policy and information from supporting components. The

1869

PE executes its trust algorithm to evaluate each resource request it receives. The PE may be a

1870

single system or a federation of systems (i.e., a “system of systems”) that covers sectors of the

1871

Supporting Components

Policy Information

Points (PIPs)

Data Security

EDR/EPP

ICAM

Security Analytics

S(D). Periodic reauthentication

challenge/response and endpoint

hygiene verification

Data Plane

I(5). Session

I(1). Initial access request

(identity and credentials)

Control Plane

I(2). Info needed

to verify subject

and its endpoint

I(3). Information needed to

approve/deny access request

S(B)/R(B). Information needed

to continually evaluate access

I(4).

Allow/

deny

access

R(1). Authenticate and validate resource

S(C). Continue/revoke/limit

session access

R(C). Revoke/limit resource

access

S(A)/R(A).

Access

requests; info

needed to

periodically

verify subject,

resource, and

endpoints

R(D). Periodic resource reauthentication

challenge/response and endpoint hygiene

verification

I(N): Initial Connection

S(X): Session Management

R(X): Resource Management

Policy Engine(s) (PEs)

Policy Administrator(s)

(PAs)

Policy Decision

Point (PDP)

Policy Enforcement

Point(s) (PEPs)

Subject

User

Endpoint

Resource

On-Prem

Cloud

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 51

ZTA. Each PE in the federation would be responsible for its sector based on the overall set of

1872

enterprise policies.

1873

▪ Policy Administrator (PA): The PA executes the PE’s policy decision by sending commands to the

1874

PEP to establish and terminate the communications path between the subject and the resource.

1875

It generates any session-specific authentication and authorization token or credential used by

1876

the subject to access the enterprise resource.

1877

▪ Policy Enforcement Point (PEP): The PEP guards the trust zone that hosts one or more

1878

enterprise resources. It handles enabling, monitoring, and eventually terminating connections

1879

between subjects and enterprise resources. It operates based on commands that it receives

1880

from the PA.

1881

When combined, the functions of the PE and PA comprise a PDP. The PDP is where the decision as to

1882

whether or not to permit a subject to access a resource is made. The PIPs provide various types of

1883

telemetry and other information needed for the PDP to make informed access decisions. The PEP is the

1884

location at which this access decision is enforced.

1885

Three approaches for how an enterprise can enact a ZTA for workflows can be supported by the

1886

architecture represented in Figure 4-1: use of EIG, micro-segmentation, and SDP. If the micro-

1887

segmentation approach is used, then when the PEP grants a subject access to a resource, it permits the

1888

subject to gain access to the unique network segment on which the resource resides. If the SDP

1889

approach is used, then when the PE decides to grant a subject access to a resource, the PA often acts

1890

like a network controller by setting up a secure channel between the subject and the resource via the

1891

PEP.

1892

4.1.2 ZTA Supporting Components

1893

The various sets of information either generated via policy or collected by the ZTA supporting

1894

components and used as input to ZTA policy decisions are referred to as PIPs.

1895

The ZTA supporting components and policy information points are:

1896

▪ ICAM: The ICAM component includes the strategy, technology, and governance for creating,

1897

storing, and managing subject (e.g., enterprise user) accounts and identity records and their

1898

access to enterprise resources. Aspects of ICAM include:

1899

o Identity management – Creation and management of enterprise user and device

1900

accounts, identity records, role information, and access attributes that form the basis of

1901

access decisions within an organization to ensure the correct subjects have the

1902

appropriate access to the correct resources at the appropriate time. This includes least

1903

privilege management, i.e., ensuring that the subject performing the access is given just

1904

enough privileges at the time they are needed to complete the task at hand and then

1905

removing those privileges to ensure that subjects do not have privileges that are not

1906

required. This concept can be characterized as just enough and just in time access rights.

1907

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 52

o Access and credential management – Use of authentication (e.g., SSO and MFA) to

1908

verify subject identity and authorization to manage access to resources. This includes

1909

continuous access evaluation, i.e., repeatedly authenticating subjects and verifying their

1910

access to resources on an ongoing basis throughout an access session.

1911

o Federated identity – The federated identity component aggregates and correlates all

1912

attributes relating to an identity or object that is being authorized by a ZTA. It enables

1913

users of one domain to securely access data or systems of another domain seamlessly,

1914

and without the need for completely redundant user administration. Federated identity

1915

encompasses the traditional ICAM data, supports identities that may be part of a larger

1916

federated ICAM community, and may include non-enterprise employees. Guidelines for

1917

the use of federated identity are discussed in NIST SP 800-63C, Digital Identity

1918

Guidelines [11].

1919

o Identity governance – Use of policy-based centralized automated processes to manage

1920

user identity and access control functions (e.g., segregation of duties, role management,

1921

logging, access reviews, auditing, analytics, reporting) to ensure compliance with

1922

requirements and regulations

1923

▪ EDR/EPP: The endpoint protection component encompasses the strategy, technology, and

1924

governance to protect endpoints (e.g., servers, desktops, mobile phones, IoT devices and other

1925

non-human devices) and their data from threats and attacks, as well as protect the enterprise

1926

from threats from managed and unmanaged devices. In some cases, extended detection and

1927

response (XDR) solutions may be used that consolidate multiple EDR/EPP, network monitoring,

1928

and other security tools into a unified security solution. Such a unified solution provides

1929

automated monitoring, analysis, detection, and remediation for the purpose of improving

1930

detection accuracy while simultaneously improving efficiency of security operations and

1931

remediation. Some EDR/EPP solutions may depend on EDR/EPP agents being installed on

1932

endpoints while other solutions may be agentless. Aspects of endpoint protection include:

1933

o Continuous diagnostics and mitigation (CDM) – Gathering information about enterprise

1934

assets and their current state and applying updates to configuration and software

1935

components. A CDM system provides information to the policy engine about the asset

1936

making the access request. Guidelines for applying patches and updates are discussed in

1937

NIST SP 1800-31, Improving Enterprise Patching for General IT Systems: Utilizing Existing

1938

Tools and Performing Processes in Better Ways.

1939

o Application protection – Managing and protecting data within an application by

1940

enforcing protection policies that apply to the application

1941

o Device compliance – Ensuring that an endpoint contains the hardware, firmware,

1942

software, and configurations required by enterprise policy and includes nothing

1943

unauthorized by enterprise policy. Guidelines for validating the integrity of computing

1944

devices are discussed in NIST SP 1800-34, Validating the Integrity of Computing Devices.

1945

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 53

o Vulnerability/threat mitigation – Monitoring endpoint software and configurations to

1946

detect known vulnerabilities and, when found, provide alerts that include remediation

1947

and mitigation recommendations, if available

1948

o Host intrusion protection – Monitoring an endpoint for suspicious activity that may

1949

indicate an attempted intrusion, infection, or other malware; stopping malicious activity

1950

on the endpoint, notifying potential victims, logging the suspicious events, and stopping

1951

future traffic from suspicious sources

1952

o Host firewall – Preventing the individual endpoint from receiving traffic that is not

1953

explicitly permitted, thereby helping to protect the endpoint from receiving malware

1954

and other malicious traffic

1955

o Malware protection – Scanning endpoint software for signatures that belong to known

1956

malware or using non-signature-based offerings that may use ML or AI to detect

1957

malicious code; if detected, disabling the malware, quarantining and repairing infected

1958

files if possible, and providing alerts that include any available remediation and

1959

mitigation recommendations

1960

o Data protection enforcement – Ensuring that data stored on the device is protected in

1961

accordance with enterprise policies

1962

o Mobile device management – Managing and administering mobile devices to ensure

1963

that they are secure by provisioning software to the mobile devices in accordance with

1964

enterprise security policies to monitor behavior and critical data on the device, thereby

1965

protecting the device’s applications, data, and content and enabling the device to be

1966

tracked, monitored, troubleshooted, and wiped, if necessary

1967

▪ Data Security: The data security component includes the policies that an enterprise needs to

1968

secure access to enterprise resources, as well as the means to protect data at rest and in transit.

1969

Aspects of data security include:

1970

o Data confidentiality – protecting data from unauthorized disclosure while at rest and in

1971

transit

1972

o Data integrity – protecting data from unauthorized modification while at rest and in

1973

transit

1974

o Data availability – protecting the ability of authorized users to access data in a timely

1975

manner and guarding against unauthorized deletion

1976

o Data access policies – all data access policies and rules needed to secure access to

1977

enterprise information and resources

1978

▪ Security Analytics: The security analytics component encompasses all the threat intelligence

1979

feeds and traffic/activity monitoring for an IT enterprise. It gathers security and behavior

1980

analytics about the current state of enterprise assets and continuously monitors those assets to

1981

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 54

actively respond to threats or malicious activity. This information could feed the policy engine to

1982

help make dynamic access decisions. Aspects of security analytics include:

1983

o SIEM – Collection and consolidation of security information and security event data

1984

from many sources; correlates and analyzes the data to help detect anomalies and

1985

recognize potential threats and vulnerabilities; logs the data to adhere to data

1986

compliance requirements

1987

o Network monitoring and activity logging – Collection and monitoring of metrics

1988

regarding network activity and performance. Collect asset logs, network traffic, resource

1989

access actions, privileged tasks, and other events that provide real-time (or near-real-

1990

time) feedback on the security posture of enterprise information systems.

1991

o Traffic inspection –Interception, examination, and recording of relevant traffic

1992

transmitted on the network. Not all communication may be intercepted and not all

1993

intercepted traffic may be subject to the same level of examination (e.g., deep packet

1994

inspection, only metadata analysis) depending on policy or capability.

1995

o Endpoint monitoring – The discovery of all IP-connected endpoints and continuous

1996

collection, examination, and analysis of software versions, configurations, and other

1997

information regarding hosts (devices or VMs) that are connected to the network

1998

o Threat intelligence – Use of information regarding known existing or emerging

1999

vulnerabilities, attacks, and other menaces to enterprise operations and assets to

2000

inform decisions regarding how to defend against and respond to those threats

2001

o User behavior – Monitoring and analysis of user behavior to detect unusual patterns or

2002

anomalies that might indicate an attack

2003

o Correlation and analytics – Use of data analytics and AI to correlate, compare, and

2004

analyze all information received from ZTA supporting components (e.g., ICAM, endpoint

2005

monitoring, network monitoring, and other related supporting activity) for the purpose

2006

of detecting unusual patterns or anomalies that might indicate an attack

2007

o SOAR – Collection and monitoring of alerts from the SIEM and other security systems

2008

and execution of predefined incident response workflows to automatically analyze the

2009

information and orchestrate the operations required to respond

2010

o Security validation – Continuous validation and measurement of the effectiveness of

2011

cybersecurity controls

2012

o Firmware assurance – Continuous monitoring of IT device firmware

2013

4.1.3 ZTA in Operation

2014

Figure 4-1 depicts the general, high-level ZTA reference architecture. If an enterprise has highly

2015

distributed systems, it may have many PEPs to protect resources in different locations; it may also have

2016

multiple PEPs to support load balancing. For simplicity, Figure 4-1 limits its focus to the interactions

2017

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 55

involving a single PEP, a single subject, and a single resource. The labeled arrows in Figure 4-1 depict the

2018

high-level steps performed in support of the ZTA reference architecture. These steps can be understood

2019

in terms of three separate processes:

2020

▪ Resource Management—R(): Resource management steps ensure that the resource is

2021

authenticated and that its endpoint conforms to enterprise policy. Upon first being brought

2022

online, a resource’s identity is authenticated and its endpoint hygiene (i.e., health) is verified.

2023

The resource is then connected to the PEP. Once connected to the PEP, access to the resource is

2024

granted only through that PEP at the discretion of the PDP. For as long as the resource continues

2025

to be online, resource management steps are performed to periodically reauthenticate the

2026

resource and verify its endpoint hygiene, thereby continually monitoring its health. These steps

2027

are labeled R(1) and R(A) through R(D). Step R(1) occurs first, but the other steps do not

2028

necessarily occur in any specific order with respect to each other, which is why they are labeled

2029

with letters instead of numbers. Their invocation is determined by enterprise policy. For

2030

example, enterprise policy determines how frequently the resource is reauthenticated, what

2031

resource-related information the PDP needs to evaluate each access request and when it needs

2032

it, and what resource-related changes (environmental, security analytics, etc.) would cause the

2033

PDP to decide to revoke or limit access to a particular resource.

2034

▪ Session Establishment Steps—I(): Session establishment steps are a sequence of actions that

2035

culminate in the establishment of the initial session between a subject and the resource to

2036

which it has requested access. These steps are labeled I(1) through I(5) and they occur in

2037

sequential order.

2038

▪ Session Management Steps—S(): Session management steps describe the actions that enable

2039

the PDP to continually evaluate the session once it has been established. These steps begin to

2040

be performed after the session has been established, i.e., after Step I(5), and they continue to

2041

be invoked periodically for as long as the session remains active. These steps are labeled S(A)

2042

through S(D) so that they can be distinguished from each other. However, the letters A through

2043

D in the labels are not meant to imply an ordering. The session management steps do not

2044

necessarily occur in any specific order with respect to each other. Their invocation is determined

2045

by the access requests that are made by the subject in combination with enterprise policy. For

2046

example, enterprise policy determines how frequently the subject is reauthenticated, what

2047

information the PDP needs to evaluate each access request and when it needs it, and what

2048

changes (environmental, security analytics, etc.) would cause the PDP to decide to deny a

2049

particular access request or terminate an established session altogether.

2050

The following additional details describe each of the steps in each of the three processes depicted in

2051

Figure 4-1:

2052

Resource Management

2053

▪ Step R(1). Authenticate and validate resource: In our model, it is assumed that the resource has

2054

already been registered as an authorized resource. Initially, when the resource is brought online,

2055

its identity must be authenticated and its endpoint hygiene must be validated to ensure

2056

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 56

compliance. This authentication and validation could be accomplished by a variety of

2057

mechanisms, such as the ICAM and EPP capabilities, the PEP itself, or a connector. The diagram

2058

is not concerned with depicting how it is authenticated, just that the authentication and

2059

validation are performed.

2060

In some implementations, in order for the resource to communicate with the service provider

2061

where the PEP is located, a connector or proxy may need to be installed to enable that

2062

connection to the service provider. For example, a database in an existing enterprise may not

2063

currently have the capability to interact with a service provider PEP directly. To make this

2064

communication possible, a connector, which behaves like a proxy module, may be installed

2065

between the resource and the PEP. There are multiple possible types of connectors and ways of

2066

connecting. This level of detail (i.e., whether a connector is present and, if so, what type) is not

2067

shown in the figure. Authentication and validation of the resource and connection of the

2068

resource to the PEP must be completed prior to any users requesting access.

2069

▪ Step R(A). Information needed to periodically verify resource and endpoint: Throughout the

2070

lifetime of the session, the PEP will periodically challenge the resource to reauthenticate itself.

2071

After doing so, the PEP will provide the PDP with the identity and credentials that the resource

2072

provided. Similarly, throughout the lifetime of the session, the PEP will request hygiene

2073

information from the resource’s endpoint. After obtaining this hygiene information, the PEP will

2074

provide it to the PDP. The frequency with which the resource should be issued authentication

2075

challenges is determined by enterprise policy, as is the frequency with which the hygiene of its

2076

endpoint should be validated.

2077

▪ Step R(B). Information needed to continually evaluate access: Throughout the course of the

2078

access session, the PDP requests and receives any resource-related information that it needs to

2079

evaluate the resource’s ongoing compliance with enterprise policy. This could include

2080

information such as authentication information provided by the ICAM system, endpoint hygiene

2081

information provided by the EPP, and anomaly detection analysis regarding resource behavior

2082

provided by logging and security analytics functionality.

2083

▪ Step R(C). Revoke/limit resource access: The connection between the PEP and the resource

2084

may be terminated or reconfigured based on changes to the resource or operating environment

2085

that indicate the resource no longer conforms to enterprise policy.

2086

▪ Step R(D). Periodic resource reauthentication challenge/response and endpoint hygiene

2087

verification: The resource undergoes continual reauthentication and hygiene checks to ensure

2088

that its security posture conforms to enterprise policy. These actions are usually taken by the

2089

various systems that may make up the PDP and are performed regardless of any current open

2090

sessions. The frequency with which reauthentication and hygiene checks are performed is

2091

determined by enterprise policy.

2092

Session Establishment

2093

▪ Step I(1). Initial access request (identity and credentials): The subject interacts with the PEP to

2094

request access to the resource and provide its identity and credentials.

2095

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 57

▪ Step I(2). Information needed to verify subject and its endpoint: The PEP forwards the subject’s

2096

identity and credentials to the PE within the PDP.

2097

▪ Step I(3). Information needed to approve/deny access request: The PE requests and receives

2098

any additional information that it needs to determine whether it should approve or deny the

2099

subject’s access request. This includes information provided by the various supporting

2100

components of the ZTA. ICAM-related information is used most heavily, i.e., user and endpoint

2101

identity, authorization (i.e., subject privileges), federation, and identity governance information;

2102

but additional information from other ZTA supporting components, e.g., endpoint compliance,

2103

endpoint monitoring, and threat intelligence, may also be relied upon as specified by enterprise

2104

policy. The PIPs depicted in Figure 4-1 represent the collection of information required by the PE

2105

to decide, in accordance with enterprise policy, whether or not to grant the access request. The

2106

PE authenticates the subject, determines what the subject’s authorizations are, and evaluates

2107

additional information as needed to determine whether to allow or deny the subject access to

2108

the requested resource.

2109

▪ Step I(4). Allow/deny access: The PDP informs the PEP whether to allow or deny the subject

2110

access to the resource.

2111

▪ Step I(5). Session: Assuming the PDP has decided to allow access, the PEP establishes a session

2112

between the subject and the resource through which the subject can access the resource. At the

2113

completion of Step I(5), the session is set up and the session management processes begin being

2114

performed.

2115

Session Management

2116

Once the session has been established, several session management processes are performed

2117

simultaneously on an ongoing basis for the duration of the session. The session management processes

2118

depicted in Figure 4-1 include ongoing evaluation of each of the subject’s access requests, ongoing

2119

continual evaluation of the session, periodic reauthentication of the subject, and periodic verification of

2120

the subject’s endpoint hygiene. These processes are described below.

2121

Ongoing evaluation of the access requests made by the subject: The steps of this process are depicted

2122

by steps S(A), S(B), and S(C) in Figure 4-1.

2123

▪ Step S(A). Access requests: Throughout the course of the access session, the actions that the

2124

subject sends to the resource are monitored by the PEP and sent to the PDP for evaluation as to

2125

whether the access should continue. When TLS or another form of encryption is used to secure

2126

the session between the subject and the resource, it is not possible for a PEP that is situated in

2127

the middle of that connection to have visibility into the messages that the subject is sending

2128

because they are encrypted. The PEP must have access to the necessary unencrypted traffic

2129

needed in order to provide the PDP with the necessary information to make the access decision.

2130

The PEP may have full access to monitor the session traffic or may rely on another system

2131

(including the resource itself) to monitor the session activity. To enable the access session to be

2132

continuously monitored by the PEP, the PEP could be situated adjacent to the subject so it can

2133

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 58

receive unencrypted requests from the subject and send them to the PDP for monitoring before

2134

forwarding them over the encrypted access session to the resource; the PEP could be situated

2135

adjacent to the resource so it can decrypt requests it receives from the subject on the access

2136

session and send them to the PDP for monitoring before forwarding them to the resource; or

2137

the PEP could be located elsewhere and have plaintext requests forwarded to it that it would

2138

then send to the PDP for monitoring. Because there are many possible ways the monitoring

2139

could be accomplished, Figure 4-1 does not attempt to depict where the access session is

2140

terminated with respect to the PEP. It is only meant to convey the fact that the subject’s access

2141

requests are monitored on an ongoing basis and forwarded to the PDP for evaluation.

2142

▪ Step S(B). Information needed to continually evaluate access: Throughout the course of the

2143

access session, the PDP requests and receives any additional information from the PIP that it

2144

needs to evaluate the subject’s ongoing access to determine whether it should continue. This

2145

information is provided by the various ZTA supporting components in the architecture.

2146

Examples of such information include subject identity information provided by ICAM

2147

functionality, subject endpoint hygiene information provided by endpoint security functionality,

2148

and behavioral analysis (e.g., whether the subject has attempted to elevate privileges beyond

2149

what is authorized) and anomaly detection information provided by logging and security

2150

analytics functionality. Evaluation of the access requests is performed in accordance with

2151

enterprise policy.

2152

▪ Step S(C). Continue/revoke/limit session access: If the PDP determines that the access should

2153

continue, it will allow the PEP to forward the access request made in step S(A) to the resource.

2154

However, if the PDP determines that, in light of the information received from the PIP (e.g.,

2155

federated identity, endpoint security information, security analytics), the session should be

2156

terminated or limited, the PDP may inform the PEP not to forward the action to the resource.

2157

Note that in an ideal world, the PEP would wait for the PDP to pass judgement on every request

2158

that is made on a session before forwarding each request to the resource. However, in reality,

2159

the cost of having the PDP evaluate every individual request in real time may be too great. In

2160

most cases the PEP would have a set of rules determining allowed requests and (possibly) a set

2161

of policies on when to require reauthentication or additional checks before forwarding requests

2162

to the resource.

2163

Ongoing continual evaluation of the session: The steps of this process are depicted by steps S(B) and

2164

S(C) in Figure 4-1.

2165

▪ Step S(B). Information needed to continually evaluate access: Throughout the course of the

2166

access session, the information in the PIPs is updated by the various ZTA supporting

2167

components and made available to the PDP so it can dynamically evaluate whether the session

2168

continues to be in accordance with enterprise policy. At any moment, information could

2169

become available that causes the session to be non-compliant. For example, threat intelligence

2170

information could be received regarding vulnerabilities in the endpoint or software used by the

2171

subject, anomalies could be detected in the subject’s behavior (e.g., attempts to elevate access),

2172

or the subject could fail authentication when trying to access a different resource.

2173

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 59

▪ Step S(C). Continue/revoke/limit session access: If the PDP determines that the ongoing access

2174

session continues to be compliant, it will permit it to continue. However, if the PDP determines

2175

that, based on information available from the PIPs (e.g., endpoint security information, threat

2176

intelligence, security analytics), the access session should be limited or revoked, the PDP will

2177

direct the PEP to deny some requests that are made on the session or to disconnect the session

2178

altogether.

2179

Periodic reauthentication of the subject and periodic verification of the hygiene of the subject

2180

endpoint: These are two separate and distinct processes, but they are depicted by the same steps in

2181

Figure 4-1, steps S(A), S(D), and S(C), so we will discuss them together:

2182

▪ Step S(A). Information needed to periodically verify subject and endpoint: Throughout the

2183

lifetime of the session, the PDP will periodically notify the PEP to challenge the subject to

2184

reauthenticate itself. After doing so, the PEP will provide the PDP with the identity and

2185

credentials that the subject provided. Similarly, throughout the lifetime of the session, the PDP

2186

will periodically notify the PEP to request hygiene information from the subject’s endpoint,

2187

operating environment, etc. After obtaining this hygiene information, the PEP will provide it to

2188

the PDP. The frequency with which the subject should be issued authentication challenges is

2189

determined by enterprise policy, as is the frequency with which the hygiene of the subject

2190

endpoint should be validated.

2191

▪ Step S(D). Periodic reauthentication challenge/response and endpoint hygiene verification: As

2192

directed by the PDP in step S(A), the PEP periodically issues reauthentication challenges to the

2193

subject. It also periodically requests and receives endpoint hygiene (software, configuration,

2194

etc.) information. The frequency with which each of these types of information is requested is

2195

specified by enterprise policy.

2196

▪ Step S(C). Continue/revoke/limit session access: Based on the subject identity and credential

2197

information received and/or on the endpoint hygiene information received, the PDP determines

2198

whether to permit the access session to continue. If at any time the reauthentication of the

2199

subject fails or if the subject’s endpoint hygiene cannot be satisfactorily verified (as determined

2200

by policy), the PDP will direct the PEP to disconnect or limit the session.

2201

4.2 EIG Crawl Phase Reference Architecture

2202

The reference architecture depicted in Figure 4-1 is intentionally general and is not meant to describe

2203

any particular ZTA deployment approach. This project plans to implement all three deployment

2204

approaches described in NIST SP 800-207, Zero Trust Architecture, beginning with EIG. The EIG approach

2205

to developing a ZTA uses the identity of subjects as the key component of policy creation. Access

2206

privileges granted to the given subject is the main requirement for resource access. Other factors such

2207

as device used, endpoint hygiene and status, and environmental factors may also impact whether and

2208

what access is authorized.

2209

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 60

Once the EIG approach has been built, additional supporting components and features related to the

2210

micro-segmentation and SDP deployment approaches will be added to create a series of subsequent

2211

builds that support an increasingly rich set of additional ZTA capabilities, ultimately culminating in the

2212

demonstration of a full collection of EIG, micro-segmentation, and SDP-based ZTA functionality.

2213

This section of the practice guide documents the builds that were created in the project’s EIG crawl

2214

phase. The crawl phase uses what we call an EIG crawl phase deployment approach. Figure 4-2 depicts

2215

the reference architecture for this approach. The EIG crawl phase reference architecture, as its name

2216

suggests, uses a subject’s identity and its access privileges as the main determinants for granting

2217

resource access, along with the endpoint used and its hygiene status. Hence, as can be seen in Figure

2218

4-2, the reference architecture for this EIG crawl phase build includes ICAM and endpoint protection

2219

components. In the area of ICAM, it supports capabilities in all the four main areas of identity

2220

management, access and credential management, federated identity, and identity governance.

2221

The labeled steps in Figure 4-2 are the same as those in Figure 4-1. The main difference between the

2222

two figures can be found in the set of supporting components that have been included. The EIG crawl

2223

phase reference architecture depicted in Figure 4-2 is a constrained form of the general ZTA reference

2224

architecture in Figure 4-1. The EIG crawl phase reference architecture relies on the PE and PA

2225

capabilities provided by its ICAM components. Also, the only security analytics functionality that it

2226

includes is a SIEM. It does not include any additional data security or security analytics functionality.

2227

These limitations were intentionally placed on the architecture with the goal of demonstrating the ZTA

2228

functionality that an enterprise with legacy ICAM and endpoint protection solutions deployed will be

2229

able to support without having to add ZTA-specific capabilities.

2230

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 61

Figure 4-2 EIG Crawl Phase Reference Architecture

2231

2232

Three EIG crawl phase builds have been implemented. Each of these EIG crawl phase builds instantiates

2233

the architecture that is depicted in Figure 4-2 in a unique way, depending on the equipment used and

2234

the capabilities supported. The products used in each build were based on having out-of-box

2235

integration. Briefly, the three builds are as follows:

2236

▪ EIG Enterprise 1 Build 1 (E1B1) uses products from Amazon Web Services, IBM, Ivanti,

2237

Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zimperium. Certificates from DigiCert are

2238

also used.

2239

▪ EIG Enterprise 2 Build 1 (E2B1) uses products from Cisco Systems, IBM, Mandiant, Palo Alto

2240

Networks, Ping Identity, Radiant Logic, SailPoint, and Tenable. Certificates from DigiCert are also

2241

used.

2242

▪ EIG Enterprise 3 Build 1 (E3B1) uses products from F5, Forescout, Lookout, Mandiant, Microsoft,

2243

Palo Alto Networks, PC Matic, and Tenable. Certificates from DigiCert are also used.

2244

Each of these builds is described in detail in its own appendix (see Appendix D, Appendix E, and

2245

Appendix F).

2246

S(D). Periodic reauthentication

challenge/response and endpoint

hygiene verification

Data Plane

I(5). Session

I(1). Initial access request

(identity and credentials)

Control Plane

I(2). Info needed

to verify subject

and its endpoint

I(3). Information needed to

approve/deny access request

S(B)/R(B). Information needed

to continually evaluate access

I(4).

Allow/

deny

access

R(1). Authenticate and validate resource

S(C). Continue/revoke/limit

session access

R(C). Revoke/limit resource

access

S(A)/R(A).

Access

requests; info

needed to

periodically

verify subject,

resource, and

endpoints

R(D). Periodic resource reauthentication

challenge/response and endpoint hygiene

verification

I(N): Initial Connection

S(X): Session Management

R(X): Resource Management

ICAM System’s PE

ICAM System’s PA

Policy Decision

Point (PDP)

Policy Enforcement

Point(s) (PEPs)

Subject

User

Endpoint

Resource

On-Prem

Cloud

Policy Information Points

(PIPs)

EDR/EPP

Multi-Factor

Authentication (MFA)

Security Analytics

ICAM System’s PEPs

Other PEPs

Federated Identity

Identity Governance

ICAM

Supporting Components

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 62

4.3 EIG Run Phase

2247

This section of the practice guide documents the builds that have been created in the project’s EIG run

2248

phase. The EIG run phase builds upon the EIG crawl phase architecture. The EIG run phase no longer

2249

imposes the requirement that the PE and PA components are provided by the ICAM products used in

2250

the build. It also adds capabilities to the EIG crawl phase. In addition to protecting access to resources

2251

that are located on-premises, the run phase protects access to some resources that are hosted in the

2252

cloud. The EIG run phase also includes a device discovery capability, which is performed as part of the

2253

baseline. In addition to monitoring and alerting when new devices are detected, enforcement can be

2254

enabled to deny access to devices that are not compliant. The run phase also includes the capability to

2255

establish a tunnel between the requesting endpoint and the resource being accessed over which access

2256

to the resource can be brokered.

2257

Two of the builds implemented so far and discussed in the appendices of this document are EIG run

2258

phase deployments. Each of these EIG run phase builds is unique, based on the equipment used and the

2259

capabilities supported. Briefly, the two builds are as follows:

2260

▪ EIG Enterprise 1 Build 2 (E1B2) uses products from Amazon Web Services, IBM, Ivanti,

2261

Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zscaler. Certificates from DigiCert are also

2262

used.

2263

▪ EIG Enterprise 3 Build 2 (E3B2) uses products from F5, Forescout, Mandiant, Microsoft, Palo

2264

Alto Networks, PC Matic, and Tenable. Certificates from DigiCert are also used.

2265

Each of these builds is described in detail in its own appendix (see Appendix H and Appendix J).

2266

4.4 ZTA Laboratory Physical Architecture

2267

Figure 4-3 depicts the high-level physical architecture of the ZTA laboratory environment, which is

2268

located at the NCCoE site. The NCCoE provides VM resources and physical infrastructure for the ZTA lab.

2269

It also hosts GitLab, which is used as a DevOps platform that stores Terraform and Ansible configuration

2270

information and provides version control for configuration file and change management activities. The

2271

NCCoE hosts all the collaborators’ ZTA-related software for Enterprises 1, 2, 3, and 4. The NCCoE also

2272

provides connectivity from the ZTA lab to the NIST Data Center, which provides connectivity to the

2273

internet and public IP spaces (both IPv4 and IPv6).

2274

Access to and from the ZTA lab from within ITOPS is protected by a Palo Alto Networks Next Generation

2275

Firewall (PA-5250). (The brick box icons in Figure 4-3 represent firewalls.) The ZTA lab network

2276

infrastructure includes four independent enterprises (Enterprises 1, 2, 3, and 4), a branch office used

2277

only by Enterprise 1, a coffee shop that all enterprises can use, a management and orchestration

2278

domain, and an emulated WAN/internet service provider. The emulated WAN service provider provides

2279

connectivity among all the ZTA laboratory networks, i.e., among all the enterprises, the coffee shop, the

2280

branch office, and the management and orchestration domain. Another Palo Alto Networks PA-5250

2281

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 63

firewall that is split into separate virtual systems protects the network perimeters of each of the

2282

enterprises and the branch office. The emulated WAN service provider also connects the ZTA laboratory

2283

network to ITOPS. The ZTA laboratory network has access to cloud services provided by AWS, Azure, and

2284

Google Cloud, as well as connectivity to SaaS services provided by various collaborators, all of which are

2285

available via the internet.

2286

Each enterprise within the NCCoE laboratory environment is protected by a firewall and has both IPv4

2287

and IPv6 (dual stack) configured. Each of the enterprises is equipped with a baseline architecture that is

2288

intended to represent the typical environment of an enterprise before a ZT deployment model is

2289

instantiated.

2290

Figure 4-3 Physical Architecture of ZTA Lab

2291

The details of the baseline physical architecture of enterprise 1, enterprise 1 branch office, enterprises

2292

2, 3, and 4, the management and orchestration domain, and the coffee shop, as well as the baseline

2293

software running on this physical architecture are described in the subsections below. The details of

2294

each of the builds that occupy Enterprises 1, 2, and 3 are provided in the appendices. Table 4-1 maps

2295

each build to the appendix where each is described.

2296

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 64

Table 4-1 Mapping of Builds to Architectures and Appendices

2297

Build

ZTA Architecture Instantiated

Appendix

E1B1

EIG Crawl

Appendix D

E2B1

EIG Crawl

Appendix E

E3B1

EIG Crawl

Appendix F

E1B2

EIG Run

Appendix H

E3B2

EIG Run

Appendix J

4.4.1 Enterprise 1

2298

Figure 4-4 is a close-up of the high-level physical architecture of Enterprise 1 in the NCCoE laboratory

2299

baseline environment. Its components are described in the subsections below.

2300

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 65

Figure 4-4 Physical Architecture of Enterprise 1

2301

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 66

4.4.1.1 Firewall

2302

Enterprise 1, like Enterprise 3, Enterprise 1 Branch Office, and the management and orchestration

2303

domain, is protected by a Palo Alto Networks 5250 firewall. This is one physical firewall that provides

2304

independent virtual firewalls to protect each of the above domains. Each enterprise is configured with

2305

an autonomous ZTA solution set. These virtual firewalls provide firewall and gateway capabilities,

2306

support a site-to-site Internet Protocol Security (IPsec) connection between the Enterprise 1 Branch

2307

Office and Enterprise 1, provide a remote access VPN (Global Protect) to sites, filter traffic among

2308

various internal and external subnets, provide IPv4 and IPv6 routing, and block all inbound traffic unless

2309

explicitly allowed, e.g., for communication with cloud resources. These firewalls are integrated with AD

2310

to leverage the enterprise user directory store for their respective domains.

2311

4.4.1.2 Switch

2312

Enterprise 1 uses a Cisco C9300 multilayer switch to provide internal network connectivity within the

2313

enterprise. It provides layer 2/3 interfaces for each virtual local area network (VLAN) subnetwork with

2314

802.1q trunking. Both IPv4 and IPv6 addresses are assigned. This switch is integrated with the Remote

2315

Authentication Dial-In User Service (RADIUS) networking protocol to provide centralized authentication,

2316

authorization, and accounting (AAA) management for users requesting access to an Enterprise 1

2317

network service. The switch hosts physical wireless access points and allows connections for their virtual

2318

controllers. It also provides wired access for endpoints such as laptops within the lab.

2319

4.4.1.3 ZTA Components Specific to Enterprise 1

2320

Enterprise 1 contains VLANs that pertain specifically to enterprise 1’s ZTA build. See Appendix D for a

2321

detailed description of the ZTA components used in Enterprise 1 Build 1 (E1B1) and Appendix H for a

2322

detailed description of the ZTA components used in Enterprise 1 Build 2 (E1B2).

2323

4.4.1.4 Demilitarized Zone (DMZ) Subnet

2324

Enterprise 1’s demilitarized zone (DMZ) is a virtual subnet that separates the rest of the Enterprise 1

2325

network from the internet. The DMZ includes web applications and other services that Enterprise 1

2326

makes available to users on the public internet. For example, the DMZ subnet includes Jump-box

2327

Remote Desktop Server (RDS) and Secure Shell (SSH) protocol to provide some collaborators with

2328

remote access to Enterprise 1. It also includes applications such as Simple Mail Transfer Protocol (SMTP),

2329

NGINX Plus, and Apache Guacamole.

2330

4.4.1.5 Internal Corporate Subnet

2331

The internal corporate subnet is where applications that support Enterprise 1’s internal services reside.

2332

For example, the internal corporate subnet includes applications such as GitLab.

2333

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 67

4.4.1.6 Corporate User Subnet

2334

The corporate user subnet is where users and devices such as mobile devices (iOS and Android), tablets,

2335

Windows clients, macOS clients, Linux clients, and printers reside. Some of these devices are connected

2336

via wires to the C9300 switch while others are connected via Wi-Fi using the Cisco AP 18321 wireless

2337

access point.

2338

4.4.1.7 Guest Subnet

2339

The guest subnet is where guests reside. Guests are users who don’t have any sort of network ID and are

2340

not authorized to access any enterprise resources. They use their own devices rather than corporate-

2341

owned or corporate-managed devices. Devices on the guest subnet include mobile devices, tablets,

2342

Windows clients, macOS clients, and Linux clients. The guest subnet allows for BYOD access, with all

2343

devices connecting via Wi-Fi using the Cisco AP 18321 wireless access point.

2344

4.4.1.8 Shared Services

2345

A closeup of the shared services domain of Enterprise 1 is depicted in Figure 4-5. The services it includes

2346

are discussed in the following subsections.

2347

Figure 4-5 Shared Services Domain of Enterprise 1

2348

4.4.1.8.1 Certificate Authority (CA)

2349

The CA provides certificate and cryptographic services for the enterprise. It is a Windows 2016 server

2350

using AD certificate services. A two-tier CA architecture is used, with an offline CA and an issuing AD-

2351

connected CA. The CA automatically issues and reissues certificates via AD group policy, and it can

2352

generate and issue certificates to AD domain-connected Windows devices. It issues certificates for both

2353

device authentication and web services using TLS.

2354

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 68

4.4.1.8.2 Active Directory (AD)

2355

AD provides centralized administration of users, computers, and resources. It runs on Windows 2016

2356

servers and uses multiple domain controllers to ensure high availability and redundancy in hot-hot

2357

mode. It also includes a built-in DNS authoritative server and resolver.

2358

4.4.1.8.3 Domain Name Server (DNS)

2359

DNS provides name-to-IP address mappings for internal hosts and answers to DNS queries of external

2360

hosts. It runs on a Windows 2016 server and is the authoritative server for the lab.nccoe.org internal

2361

domain. Internal DNS services are integrated with AD. DNS servers within ITOps are used as forwarders

2362

and to resolve DNS queries from external devices. Two DNS servers are used to ensure high availability

2363

and redundancy in hot-hot mode.

2364

4.4.1.8.4 Dynamic Host Configuration Protocol (DHCP)

2365

The Dynamic Host Configuration Protocol (DHCP) allocates and assigns IP address and configuration

2366

information to hosts. It runs on a Windows 2016 server and is integrated with AD. Two DHCP servers are

2367

used to ensure high availability and redundancy.

2368

4.4.1.8.5 RADIUS

2369

The RADIUS networking protocol is used to provide centralized AAA management services at the switch

2370

for users requesting access to Enterprise 1 network services. It runs on a Windows 2016 network policy

2371

server (NPS) and is integrated with AD.

2372

4.4.1.8.6 Access Point (AP) Controller

2373

The access point controller manages the enterprise’s wireless access points. It runs on a Cisco virtual

2374

wireless controller. It manages two APs: models 1852I and 1832I, one for the corporate user subnet and

2375

one for the guest subnet.

2376

4.4.1.8.7 SSH File Transfer Protocol (SFTP)

2377

SFTP is used to provide secure file transfer services. It runs on a Windows 2016 server.

2378

4.4.1.8.8 Network Time Protocol (NTP)

2379

NTP provides timing and clock synchronization between systems. It runs on a Windows 2019 server.

2380

4.4.1.8.9 Syslog

2381

Syslog is used to collect logs and diagnostic data. It runs on a Linux Ubuntu 20.04 platform.

2382

4.4.1.8.10 Windows Server Update Service (WSUS)

2383

Windows Server Update Service (WSUS) provides downloads and manages updates and patches for

2384

Windows servers. It runs on a Windows 2019 server.

2385

4.4.1.8.11 Server Message Block (SMB)

2386

Server Message Block (SMB) provides Windows file sharing services. It runs on a Windows 2019 server.

2387

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 69

4.4.1.8.12 Collaborator Products

2388

The shared services domain of Enterprise 1 also includes some collaborator products that provide

2389

shared services for the enterprise. The IBM QRadar, Tenable.ad, Tenable scanner, Tenable NNM, and

2390

Mandiant MSV Director are such products.

2391

4.4.1.9 Baseline Applications

2392

The following applications were installed and configured as part of the baseline architecture to

2393

represent the types of applications that would be found in a typical brownfield enterprise environment.

2394

These applications serve as the enterprise resources to which the ZTA is managing access.

2395

4.4.1.9.1 Guacamole

2396

Apache Guacamole is a remote desktop solution that supports a wide range of protocols such as SSH

2397

and Remote Desktop Protocol (RDP).

2398

4.4.1.9.2 GitLab

2399

GitLab is a DevOps tool that allows software developers to develop, test, and operate software in one

2400

application. We used GitLab as an enterprise application being accessed by end users.

2401

4.4.1.9.3 NGINX Plus

2402

NGINX Plus is free and open-source software. It is an HTTP server that can also be used as a reverse

2403

proxy and a load balancer, among other uses.

2404

4.4.2 Enterprise 1 Branch Office

2405

Figure 4-6 is a closeup of the high-level level physical architecture of the Enterprise 1 Branch Office in

2406

the NCCoE laboratory environment. The Enterprise 1 Branch Office has three main components: a

2407

firewall, a switch, and a subnet for corporate users.

2408

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 70

Figure 4-6 Physical Architecture of the Enterprise 1 Branch Office

2409

4.4.2.1 Firewall

2410

One of the independent virtual firewalls provided by the Palo Alto Networks 5250 physical firewall is

2411

used for the Enterprise 1 Branch Office. It provides firewall and gateway capabilities, connecting the

2412

Branch Office to Enterprise 1 via the emulated WAN/internet service provider and supports a site-to-site

2413

VPN IPsec connection from the Branch Office to Enterprise 1. This firewall is integrated with the AD of

2414

Enterprise 1 so it can leverage Enterprise 1’s user directory store.

2415

4.4.2.2 Switch

2416

The Branch Office includes a Cisco C3650 multilayer switch that provides internal network connectivity

2417

within the Branch Office. It is integrated with Enterprise 1’s AAA (RADIUS) server to leverage Enterprise

2418

1’s authentication and authorization services.

2419

4.4.2.3 Corporate Users Subnet

2420

The corporate users subnet at the Branch Office is where users and devices such as mobile devices,

2421

tablets, Windows clients, and printers reside. Some of these devices are connected via wires to the Cisco

2422

3650 switch while others are connected via Wi-Fi using an ASUS RC-AC66U wireless access point.

2423

Printer

Smartphone

Windows

Client

10.151.18.0/24

Enterprise 1

Branch Office

10.151.16.0/20

C3650-48

ASUS

AP RC-AC66U

VLAN: N/A = 1519

10.151.17.0/24

PAN 5250 (2)

VSYS4

Instant Wireless



Link/Act

Power Act Act Ful/Col

Diag Link Link 100

WLAN WLAN

54g 802.11a

LAN

Instant Wireless

Series



Dual-Band Wirele ss A+G

Access Point

Model WAP55AG



2.4

GHz

Instant Wireless

Wireless A+G Access Point

Dual-Band

GHz

54g 802.11a

54g 802. 11a

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 71

4.4.3 Enterprise 2

2424

The high-level physical architecture of Enterprise 2 is the same as that of Enterprise 1, except Enterprise

2425

2 does not have an associated branch office. The baseline network topology, hardware, and software of

2426

Enterprise 2 is configured the same as Enterprise 1’s. Enterprise 2 leverages the same setup as

2427

Enterprise 1 using the Palo Alto Networks NGFW and Cisco switches. It also includes the same setup and

2428

capabilities as Enterprise 1 with respect to its DMZ, internal corporate subnetwork, corporate user

2429

subnetwork, guest subnetwork, shared services, and baseline applications. The only differences

2430

between Enterprise 2 and Enterprise 1 are with respect to the on-premises and cloud-based ZTA

2431

components used in each enterprise. See Appendix E for a detailed description of the ZTA components

2432

used in Enterprise 2.

2433

4.4.4 Enterprise 3

2434

The high-level physical architecture of Enterprise 3 is the same as that of Enterprise 2. The only

2435

differences between Enterprise 3 and Enterprise 2 are with respect to the on-premises and cloud-based

2436

ZTA components used in each enterprise. See Appendix E for a detailed description of the ZTA

2437

components used in Enterprise 3 Build 1 (E3B1) and Appendix J for a detailed description of the ZTA

2438

components used in Enterprise 3 Build 2 (E3B2).

2439

4.4.5 Enterprise 4

2440

Enterprise 4 is not yet being used in this phase of the project.

2441

4.4.6 Coffee Shop

2442

Figure 4-7 is a closeup of the high-level level physical architecture of the coffee shop in the NCCoE

2443

laboratory environment. As shown, the coffee shop provides users and mobile devices (e.g.,

2444

smartphones and laptops) wireless access to the internet via an ASUS RC-AC66U access point.

2445

Figure 4-7 Physical Architecture of the Coffee Shop

2446

2447

4.4.7 Management and Orchestration Domain

2448

The management and orchestration domain, as depicted in Figure 4-8, includes components that

2449

support infrastructure as code (IaC) automation and orchestration across the ZTA lab environment. It

2450

includes Terraform, which is used to automate the setup of VMs across the four enterprises, and

2451

Smartphone

Laptop

Internet

(Coffee Shop)

ASUS

AP RC-AC66U

Instant Wireless



Link/Act

Power Act Act Ful/Col

Diag Link Link 100

WLAN WLAN

54g 802.11a

LAN

Instant Wireless

Series



Dual-Band Wireless A+G

Access Point

ModelWAP55AG



2.4

GHz

Instant Wireless

Wireless A+G Access Point

Dual-Band

GHz

54g 802.11a

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 72

Ansible, which automates the setup of VMs and services such as DHCP, DNS, and AD across all four

2452

enterprises. It also hosts the Mandiant MSV Director and the MSV Protected Theater.

2453

Figure 4-8 Physical Architecture of the Management and Orchestration Domain

2454

4.4.8 Emulated WAN Service Provider

2455

A subnetwork within the ZTA laboratory network is leveraged to emulate a WAN service provider. The

2456

emulated WAN service provider using a Cisco SG550X switch and a Palo Alto 5250 NGFW provides

2457

connectivity among all the ZTA laboratory network domains, i.e., the enterprises, the coffee shop, the

2458

branch office, and the management and orchestration domain. It also connects the ZTA laboratory

2459

network to ITOPS, which provides connectivity to the internet. Via the internet, the emulated WAN

2460

services provide the ZTA lab network with connectivity to cloud services.

2461

4.4.9 Cloud Services

2462

As mentioned, the NCCoE lab environment has access to various cloud services via the internet. The

2463

cloud services that have been set up during the EIG crawl phase are described in Section 4.4.9.1. Cloud

2464

services will be used as part of the EIG run phase.

2465

4.4.9.1 IaaS – Amazon Web Services (AWS)

2466

Figure 4-9 depicts the physical architecture of the AWS infrastructure that has been set up for use by

2467

Enterprise 1. As shown, the NCCoE ZTA lab is connected to AWS via a site-to-site VPN, and work is

2468

underway to set up a direct connection between the NCCoE ZTA lab and AWS as well. Both a production

2469

VPC (labeled Ent 1 Prod VPC) and a management VPC (labeled Ent 1 Mgmt VPC) have been set up within

2470

VLAN 1527

10.131.11.128/25

Infrastructure as Code

Automation & Orchestration

Management & Orchestration

10.130.11.140 & .141/25

PAN 5250 (2)

VSYS4

Ansible Terraform

MSV

Director

MSV

Protected

Theater

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 73

AWS for Enterprise 1 to use. There is a transit gateway (TGW) for routing traffic between the production

2471

and management VPCs, and there is also an NCCoE TGW within AWS. CloudFormation was used to set

2472

up the production and management VPC infrastructure within AWS through the NCCoE and Enterprise

2473

TGWs. The TGW acts as a hub for routing traffic between production and management VPCs and

2474

includes multiple routing tables for secure routing between the VPCs.

2475

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 74

Figure 4-9 Physical Architecture of the AWS Infrastructure Used by Enterprise 1

2476

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 75

The production VPC has both a public subnetwork and three private subnetworks in each availability

2477

zone. The public subnetwork is used for connecting external users to the production VPC. The private

2478

subnetworks have EC2s that can host web, application, and database tiers.

2479

The management VPC also has a public subnetwork and three private subnetworks in each availability

2480

zone. The public subnetwork is used to support software updates and to enable administrators and

2481

other authorized internal staff who are located remotely to SSH into cloud components. The private

2482

subnetworks include a satellite tier, domain controller tier, and security management tier.

2483

Each VPC uses two availability zones for redundancy and high availability. Each availability zone uses

2484

automatic scaling as needed.

2485

4.4.9.2 IaaS – Google

2486

The NCCoE staff is currently working with its collaborators to set up a cloud environment for Enterprise

2487

2488

4.4.9.3 IaaS – Azure

2489

Figure 4-10 depicts the physical architecture of the Azure IaaS that has been set up for use by Enterprise

2490

3. As shown, the NCCoE ZTA lab is connected to Azure IaaS via a site-to-site VPN. If coming from on-

2491

premises through the site-to-site VPN into Azure IaaS, connections go through the hub virtual network

2492

before getting to the application virtual networks for both the public-facing and private applications.

2493

The hub virtual network consists of the gateway subnet, the firewall subnet, and the bastion subnet. The

2494

gateway subnet consists of virtual network gateways in multiple availability zones. The firewall subnet

2495

consists of firewalls in multiple availability zones. The bastion subnet consists of Azure Bastion in

2496

multiple availability zones.

2497

The public application virtual network consists of a gateway subnet, an application subnet, and utility,

2498

web, and data subnets. Each of these subnets is secured by network security group (NSG). The gateway

2499

subnet consists of application gateways in multiple availability zones and web application firewall (WAF)

2500

Policies. The application subnet hosts the virtual machines and the applications, all of which are secured

2501

by application security groups.

2502

The private application virtual network consists of a gateway subnet and an application subnet. Each of

2503

these subnets is secured by NSG. The gateway subnet consists of application gateways in multiple

2504

availability zones and web application firewall (WAF) policies. The application subnet hosts the virtual

2505

machines and the applications, as well as application proxies, all of which are secured by application

2506

security groups. The application proxies are meant to be used by remote users connecting to private

2507

applications through the internet.

2508

Traffic between subnets is allowed only if the NSGs on the subnets allow it. With the zero trust design,

2509

traffic between subnets should not be assumed; it must be explicitly granted.

2510

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 76

Figure 4-10 Physical Architecture of the Azure Infrastructure Used by Enterprise 3

2511

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 77

4.4.9.4 SaaS

2512

The project is also using collaborators’ ZTA SaaS offerings. The SaaS-based ZTA products used are listed

2513

in the appendices describing each build.

2514

5 Functional Demonstration

2515

Functional demonstrations were performed to showcase the security characteristics supported by each

2516

ZTA build. These demonstrations show the extent to which the example solutions meet their security

2517

objectives under a variety of conditions. NIST SP 1800-35D, ZTA Functional Demonstrations will

2518

document each of the demonstration scenarios and use cases that have been designed for this ZTA

2519

project. The results of the demonstrations that have been conducted on each ZTA build will also be

2520

listed in NIST SP 1800-35D.

2521

6 General Findings

2522

When deploying ZTA using the EIG approach, the following capabilities are considered to be

2523

fundamental to determining whether a request to access a resource should be granted and, once

2524

granted, whether the access session should be permitted to persist:

2525

▪ Authentication and periodic reauthentication of the requesting user’s identity

2526

▪ Authentication and periodic reauthentication of the requesting endpoint

2527

▪ Authentication and periodic reauthentication of the endpoint that is hosting the resource being

2528

accessed

2529

In addition, the following capabilities are also considered highly desirable:

2530

▪ Verification and periodic reverification of the requesting endpoint’s health

2531

▪ Verification and periodic reverification of the health of the endpoint that is hosting the resource

2532

being accessed

2533

6.1 EIG Crawl Phase Findings

2534

In the EIG crawl phase, we followed two patterns. First, we leveraged our ICAM solutions to also act as

2535

PDPs. We discovered that many of the vendor solutions used in the EIG crawl phase do not integrate

2536

with each other out-of-the-box in ways that are needed to enable the ICAM solutions to function as

2537

PDPs. Typically, network-level PEPs, such as routers, switches, and firewalls, do not integrate directly

2538

with ICAM solutions. However, network-level PEPs that are identity-aware may integrate with ICAM

2539

solutions. Also, endpoint protection solutions in general do not typically integrate directly with ICAM

2540

solutions. However, some of the endpoint protection solutions considered for use in the builds have

2541

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 78

out-of-the-box integrations with the MDM/UEM solutions used, which provide the endpoint protection

2542

solutions with an indirect integration with the ICAM solutions.

2543

Second, we used out-of-the-box integrations offered by the solution providers rather than performing

2544

custom integrations. These two patterns combined do not support all the desired ZT capabilities.

2545

Both builds E1B1 and E3B1 were capable of authenticating and reauthenticating requesting users and

2546

requesting endpoints, and of verifying and periodically reverifying the health of requesting endpoints,

2547

and both builds were able to base their access decisions on the results of these actions. Access requests

2548

were not granted unless the identities of the requesting user and the requesting endpoint could be

2549

authenticated and the health of the requesting endpoint could be validated; however, no check was

2550

performed to authenticate the identity or verify the health of the endpoint hosting the resource.

2551

Access sessions that are in progress in both builds are periodically reevaluated by reauthenticating the

2552

identities of the requesting user and the requesting endpoint and by verifying the health of the

2553

requesting endpoint. If these periodic reauthentications and verifications cannot be performed

2554

successfully, the access session will eventually be terminated; however, neither the identity nor the

2555

health of the endpoint hosting the resource is verified on an ongoing basis, nor does its identity or

2556

health determine whether it is permitted to be accessed.

2557

Neither build E1B1 nor build E3B1 was able to support resource management as envisioned in the ZTA

2558

logical architecture depicted in Figure 4-1. These builds do not include any ZTA technologies that

2559

perform authentication and reauthentication of resources that host endpoints, nor are these builds

2560

capable of verifying or periodically reverifying the health of the endpoints that host resources. In

2561

addition, when using both builds E1B1 and E3B1, devices (requesting endpoints and endpoints hosting

2562

resources) were initially joined to the network manually. Neither of the two EIG crawl phase builds

2563

include any technologies that provide network-level enforcement of an endpoint’s ability to access the

2564

network. That is, there is no tool in either build that can keep any endpoint (either one that is hosting a

2565

resource or one that is used by a user) from initially joining the network based on its authentication

2566

status. The goal is to try to support resource management in future builds as allowed by the

2567

technologies used.

2568

6.2 EIG Run Phase Findings

2569

The EIG run phase enabled us to demonstrate additional capabilities over the EIG crawl phase, such as:

2570

▪ establishment of secure, direct access tunnels from requesting endpoints to private enterprise

2571

resources, regardless of whether the resources are located on-premises or in the cloud, driven

2572

by policy and enforced by PEPs

2573

▪ use of connectors that act as proxies for internal, private enterprise resources, enabling

2574

resources to be accessed by authenticated, authorized users while ensuring that they are not

2575

discoverable by or visible to others

2576

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 79

▪ protection for private enterprise resources hosted in the cloud that enables authenticated,

2577

authorized remote users to access those resources directly rather than have to hairpin through

2578

the enterprise network

2579

▪ ability to monitor, inspect, and enforce policy controls on traffic being sent to and from

2580

resources in the cloud or on the internet

2581

▪ discovery of new endpoints on the network and the ability to block newly discovered endpoints

2582

that are not compliant with policy

2583

Build E1B2, which uses Zscaler as its PE, PA, and PEP, does not have an EPP because this build does not

2584

include any collaborators with EPP solutions that integrate with Zscaler. Zscaler (e.g., the Zscaler client

2585

connector) has capabilities to enforce policies based on a defined set of endpoint compliance checks to

2586

allow or deny user/endpoint access to a resource. However, it does not perform the functions of an EPP

2587

solution to protect an endpoint. Zscaler integrates with EPP solutions to receive a more robust set of

2588

information about the endpoints in order to make a decision to allow or deny access to a resource.

2589

However, in build E1B2, we do not have a collaborator with an EPP solution that can integrate with

2590

Zscaler.

2591

Because there is no EPP in E1B2, there is no automatic solution to remediate an issue on the endpoint

2592

either.

2593

Build E1B2 also does not have a collaborator with a solution that supports determination of confidence

2594

level/trust scores that can integrate with Zscaler. Due to the absence of a collaborator with this

2595

capability, Build E1B2 does not support the calculation of confidence levels/trust scores.

2596

Build E2B1, which uses Ping Identity as its PE and PA and Ping Identity and Cisco Duo as its PEP, does not

2597

have an EPP. Cisco Duo provides limited device health information, but not the full spectrum that an EPP

2598

would provide. Because there is no official EPP in this build, there is no automatic solution to remediate

2599

an issue on the endpoint. The inclusion of an EPP is planned for a later build phase.

2600

Build E3B2 currently supports one-way integration between Microsoft Intune and Forescout eyeExtend.

2601

If Intune detects an endpoint out of compliance, eyeExtend can become informed of this problem by

2602

pulling information from Intune. However, if one of Forescout’s discovery tools detects a problem with

2603

an endpoint, there is currently no mechanism for this information to be passed from Forescout

2604

eyeExtend to Microsoft Intune. Ideally, future integration of these products would allow Forescout

2605

eyeExtend to inform Microsoft Intune when it detects a non-Azure AD-connected endpoint that is non-

2606

compliant, as this would enable Intune to direct Azure AD to block sign-in from the non-compliant

2607

endpoint. Without a mechanism for enabling Forescout eyeExtend to send endpoint compliance

2608

information to Microsoft Intune, Azure AD does not have a way of knowing that a non-Azure AD-

2609

connected endpoint is not compliant.

2610

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 80

7 Future Build Considerations

2611

At this time, three EIG crawl phase builds are complete (E1B1, E2B1, and E3B1). We are skipping the EIG

2612

walk phase and have proceeded directly to the run phase. Two EIG run phase builds, Enterprise 1 (E1B2)

2613

and Enterprise 3 (E3B2) are also complete. All five of these builds are documented in this guide.

2614

The next phase of the project will focus on the micro-segmentation and SDP deployment models, and a

2615

combination of the two. Efforts will be organized into crawl, walk, and run phases that augment the EIG

2616

capabilities to support an increasingly rich set of functionalities and additional ZTA capabilities.

2617

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 81

Appendix A List of Acronyms

2618

AAA

Authentication, Authorization, and Accounting

ACL

Access Control List

Active Directory

Artificial Intelligence

API

Application Programming Interface

APM

(F5 BIG-IP) Access Policy Manager

ATP

(Microsoft Azure) Advanced Threat Protection, (Palo Alto Networks) Advanced

Threat Prevention

AURL

(Palo Alto Networks) Advanced URL Filtering

AWS

Amazon Web Services

BCE

(Google) BeyondCorp Enterprise

BYOD

Bring Your Own Device

C&C

Command-and-Control

Certificate Authority, (Zscaler) Central Authority

CASB

Cloud Access Security Broker

CDM

Continuous Diagnostics and Mitigation

CDSS

Cloud-Delivered Security Service

CESA

Cisco Endpoint Security Analytics

CI/CD

Continuous Integration/Continuous Delivery

CIEM

Cloud Infrastructure Entitlement Management

CISA

Cybersecurity and Infrastructure Security Agency

CRADA

Cooperative Research and Development Agreement

CVE

Common Vulnerabilities and Exposures

DDoS

Distributed Denial of Service

DHCP

Dynamic Host Configuration Protocol

DLP

Data Loss Prevention

DMZ

Demilitarized Zone

DNS

Domain Name System

DTLS

Datagram Transport Layer Security

EBS

(Amazon) Elastic Block Store

EC2

(Amazon) Elastic Compute Cloud

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 82

ECS

(Amazon) Elastic Container Service

EDR

Endpoint Detection and Response

EIG

Enhanced Identity Governance

EKS

(Amazon) Elastic Kubernetes Service

EMM

Enterprise Mobility Management

Executive Order

ePO

(Trellix) ePolicy Orchestrator

EPP

Endpoint Protection Platform

ETA

(Cisco) Encrypted Traffic Analytics

E/W

East/West

FedRAMP

Federal Risk and Authorization Management Program

FIDO U2F

Fast Identity Online Universal 2

Factor

FIPS

Federal Information Processing Standards

FTD

(Cisco) Firepower Threat Defense

FWaaS

Firewall as a Service

GCP

Google Cloud Platform

GDPR

General Data Protection Regulation

GIN

(Symantec) Global Intelligence Network

(Palo Alto Networks) GlobalProtect

Human Resources

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext Transfer Protocol Secure

IaaS

Infrastructure as a Service

IaC

Infrastructure as Code

IAM

Identity and Access Management

IBM

International Business Machines Corporation

ICA

Intermediate Certificate Authority

ICAM

Identity, Credential, and Access Management

IDaaS

Identity as a Service

IGA

(Symantec) Identity Governance and Administration

IoMT

Internet of Medical Things

IoT

Internet of Things

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 83

Internet Protocol

IPsec

Internet Protocol Security

IPv4

Internet Protocol version 4

IPv6

Internet Protocol Version 6

ISE

(Cisco) Identity Services Engine

Information Technology

ITL

Information Technology Lab

ITOps

Information Technologies Operations

KCD

Kerberos Constrained Delegation

LDAP

Lightweight Directory Access Protocol

LTM

(F5 BIG-IP) Local Traffic Manager

MAM

Mobile Application Management

MDM

Mobile Device Management

MES

(Lookout) Mobile Endpoint Security

MFA

Multi-Factor Authentication

Machine Learning

MSV

Mandiant Security Validation

MTD

Mobile Threat Defense

mTLS

Mutual Transport Layer Security

NCCoE

National Cybersecurity Center of Excellence

NDR

Network Detection and Response

NGFW

Next-Generation Firewall

NIST

National Institute of Standards and Technology

NMM

(Tenable) Nessus Network Monitor

NPE

Non-Person Entity

NPS

Network Policy Server

N/S

North/South

NSG

Network Security Group

NTA

Network Traffic Analysis

NTP

Network Time Protocol

NVM

(Cisco) Network Visibility Module

OIDC

OpenID Connect

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 84

OMB

Office of Management and Budget

Operational Technology

OTP

One-Time Password

Policy Administrator

PAN

Palo Alto Networks

PDP

Policy Decision Point

Policy Engine

PEP

Policy Enforcement Point

PII

Personally Identifiable Information

Personal Identification Number

PIP

Policy Information Point

PKI

Public Key Infrastructure

QOS

Quality of Service

RADIUS

Remote Authentication Dial-In User Service

R&D

Research and Development

RDP

Remote Desktop Protocol

RDS

Remote Desktop Server

REST

Representational State Transfer

(Amazon) Simple Storage Service

SaaS

Software as a Service

SAML

Security Assertion Markup Language

SASE

Secure Access Service Edge

SAW

(Microsoft) Secure Admin Workstation

SCIM

System for Cross-Domain Identity Management

SDLC

Software Development Lifecycle

SDP

Software-Defined Perimeter

SD-WAN

Software-Defined Wide Area Network

SFTP

SSH File Transfer Protocol

SIEM

Security Information and Event Management

SMB

Server Message Block

SMS

Short Message Service

SMTP

Simple Mail Transfer Protocol

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 85

SOAR

Security Orchestration and Response

SoD

Separation of Duties

Special Publication

SQL

Structured Query Language

SRE

Site Reliability Engineer

SSE

(Skyhigh Security) Security Service Edge

SSH

Secure Shell

SSL

Secure Sockets Layer

SSO

Single Sign-On

SWG

Secure Web Gateway

TGW

Transit Gateway

TLS

Transport Layer Security

TTP

Tactics, Techniques, and Procedures

UEM

Unified Endpoint Management

URL

Uniform Resource Locator

USB

Universal Serial Bus

VDI

Virtual Desktop Infrastructure

VIP

(Symantec) Validation and ID Protection

VLAN

Virtual Local Area Network

Virtual Machine

VPC

Virtual Private Cloud

VPN

Virtual Private Network

WAF

Web Application Firewall

(Palo Alto Networks) Wildfire

WSS

(Symantec) Web Security Service

WSUS

(Microsoft) Windows Server Update Service

XDR

Extended Detection and Response

ZCC

Zscaler Client Connector

ZIA

Zscaler Internet Access

ZPA

Zscaler Private Access

ZSO

(Ivanti) Zero Sign-On

Zero Trust

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 86

ZTA

Zero Trust Architecture

ZTNA

Zero Trust Network Access

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 87

Appendix B Glossary

2619

Managed Devices

Personal computers, laptops, mobile devices, virtual machines, and

infrastructure components require management agents, allowing information

technology staff to discover, maintain, and control them. Those with broken or

missing agents cannot be seen or managed by agent-based security products.

[NIST SP 1800-15 Vol. B]

Policy

Statements, rules, or assertions that specify the correct or expected behavior

of an entity. For example, an authorization policy might specify the correct

access control rules for a software component. [NIST SP 800-95 and NIST IR

7621 Rev. 1]

Policy

Administrator (PA)

An access control mechanism component that executes the PE’s policy

decision by sending commands to the PEP to establish and terminate the

communications path between the subject and the resource.

Policy Decision

Point (PDP)

An access control mechanism component that computes access decisions by

evaluating the applicable policies. The functions of the PE and PA comprise a

PDP. [NIST SP 800-162, adapted]

Policy Enforcement

Point (PEP)

An access control mechanism component that enforces access policy decisions

in response to a request from a subject requesting access to a protected

resource. [NIST SP 800-162, adapted]

Policy Engine (PE)

An access control mechanism component that handles the ultimate decision to

grant, deny, or revoke access to a resource for a given subject.

Policy Information

Point (PIP)

An access control mechanism component that provides telemetry and other

information generated by policy or collected by supporting components that

the PDP needs for making policy decisions. [NIST SP 800-162, adapted]

Risk

The net negative impact of the exercise of a vulnerability, considering both the

probability and the impact of occurrence. [NIST SP 1800-15 Vol. B]

Security Control

A safeguard or countermeasure prescribed for an information system or an

organization designed to protect the confidentiality, integrity, and availability

of its information and to meet a set of defined security requirements. [NIST SP

800-53 Rev. 5]

Threat

Any circumstance or event with the potential to adversely impact

organizational operations (including mission, functions, image, or reputation),

organizational assets, or individuals through an information system via

unauthorized access, destruction, disclosure, modification of information,

and/or denial of service. Also, the potential for a threat-source to successfully

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 88

exploit a particular information system vulnerability. [Federal Information

Processing Standards 200]

Vulnerability

Weakness in an information system, system security procedures, internal

controls, or implementation that could be exploited or triggered by a threat

source. [NIST SP 800-37 Rev. 2]

Zero Trust

A cybersecurity paradigm focused on resource protection and the premise that

trust is never granted implicitly but must be continually evaluated. [NIST SP

800-207]

Zero Trust

Architecture (ZTA)

An enterprise cybersecurity architecture that is based on zero trust principles

and designed to prevent data breaches and limit internal lateral movement.

Zero trust architecture is an end-to-end approach to enterprise resource and

data security that encompasses identity (person and non-person entities),

credentials, access management, operations, endpoints, hosting

environments, and the interconnecting infrastructure. [NIST SP 800-207]

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 89

Appendix C References

2620

[1] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, National Institute of

2621

Standards and Technology (NIST) Special Publication (SP) 800-207, Gaithersburg, Md., August

2622

2020, 50 pp. Available: https://csrc.nist.gov/publications/detail/sp/800-207/final.

2623

[2] Executive Order no. 14028, Improving the Nation’s Cybersecurity, Federal Register Vol. 86,

2624

No.93, May 17, 2021. Available: https://www.federalregister.gov/documents/2021/05/17/2021-

2625

10460/improving-the-nations-cybersecurity.

2626

[3] “National Cybersecurity Center of Excellence (NCCoE) Zero Trust Cybersecurity: Implementing a

2627

Zero Trust Architecture,” Federal Register Vol. 85, No. 204, October 21, 2020, pp. 66936-66939.

2628

Available: https://www.federalregister.gov/documents/2020/10/21/2020-23292/national-

2629

cybersecurity-center-of-excellence-nccoe-zero-trust-cybersecurity-implementing-a-zero-trust.

2630

[4] https://www.nccoe.nist.gov/iot

2631

[5] https://www.nccoe.nist.gov/manufacturing

2632

[6] https://www.nccoe.nist.gov/energy

2633

[7] https://www.nccoe.nist.gov/healthcare

2634

[8] https://www.f5.com/company/certifications

2635

[9] https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/3344

2636

[10] https://csrc.nist.gov/Projects/cryptographic-module-validation-program/Certificate/3452

2637

[11] P. Grassi, J. Richer, S. Squire, J. Fenton, E. Nadeau, N. Lefkovitz, J. Danker, Y. Choong, K. Greene,

2638

and M. Theofanos, Digital Identity Guidelines Federation and Assertions, National Institute of

2639

Standards and Technology (NIST) Special Publication (SP) 800-63C, Gaithersburg, Md., June

2640

2017, 40 pp. Available: https://www.nist.gov/identity-access-management/nist-special-

2641

publication-800-63-digital-identity-guidelines.

2642

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 90

Appendix D EIG Enterprise 1 Build 1 (E1B1)

2643

D.1 Technologies

2644

EIG E1B1 uses products from Amazon Web Services, IBM, Ivanti, Mandiant, Okta, Radiant Logic,

2645

SailPoint, Tenable, and Zimperium. Certificates from DigiCert are also used. For more information on

2646

these collaborators and the products and technologies that they contributed to this project overall, see

2647

Section 3.4.

2648

E1B1 components consist of Okta Identity Cloud, Ivanti Access ZSO, Ivanti Sentry, Radiant Logic

2649

RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Okta Verify App, Ivanti Neurons for

2650

UEM, Zimperium MTD, IBM Security QRadar XDR, Tenable.io, Tenable.ad, IBM Cloud Pak for Security,

2651

Mandiant Security Validation (MSV), Ivanti Tunnel, DigiCert CertCentral, and AWS IaaS.

2652

Table D-1 lists all of the technologies used in EIG E1B1. It lists the products used to instantiate each ZTA

2653

component and the security function that each component provides.

2654

Table D-1 E1B1 Products and Technologies

2655

Component

Product

Function

Okta Identity Cloud and

Ivanti Access ZSO

Decides whether to grant, deny, or revoke access to a

resource based on enterprise policy, information from

supporting components, and a trust algorithm.

Okta Identity Cloud and

Ivanti Access ZSO

Executes the PE’s policy decision by sending commands to

a PEP that establishes and shuts down the communication

path between subject and resource.

PEP

Ivanti Sentry

Guards the trust zone that hosts one or more enterprise

resources; establishes, monitors, and terminates the

connection between subject and resource as directed by

the PA; forwards requests to and receives commands from

the PA.

Identity

Management

Okta Identity Cloud

Creates and manages enterprise user and device accounts,

identity records, role information, and access attributes

that form the basis of access decisions within an

organization to ensure the correct subjects have the

appropriate access to the correct resources at the

appropriate time.

Access &

Credential

Management

Okta Identity Cloud

Manages access to resources by performing user and

device authentication (e.g., SSO and MFA) and using

identity, role, and access attributes to determine which

access requests are authorized.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 91

Component

Product

Function

Federated

Identity

Radiant Logic

RadiantOne Intelligent

Identity Data Platform

Aggregates and correlates all attributes relating to an

identity or object that is being authorized by a ZTA. It

enables users of one domain to securely access data or

systems of another domain seamlessly, and without the

need for completely redundant user administration.

Federated identity encompasses the traditional ICAM data,

supports identities that may be part of a larger federated

ICAM community, and may include non-enterprise

employees.

Identity

Governance

SailPoint IdentityIQ

Provides policy-based, centralized, automated processes to

manage user identity and access control functions (e.g.,

ensuring segregation of duties, role management, logging,

access reviews, analytics, reporting) to ensure compliance

with requirements and regulations.

MFA

Okta Verify app

Supports MFA of a user identity by requiring the user to

provide not only something they know (e.g., a password),

but also something they have (e.g., a token).

UEM/MDM

Ivanti Neurons for

Unified Endpoint

Management (UEM)

Platform

Manages and secures enterprise desktop computers,

laptops, and/or mobile devices in accordance with

enterprise policy to protect applications and data; ensure

device compliance; mitigate and remediate vulnerabilities

and threats; monitor for suspicious activity to prevent and

detect intrusions; prevent, detect, and disable malware

and other malicious or unauthorized traffic; repair infected

files when possible; provide alerts and recommend

remediation actions; and encrypt data.

Pushes enterprise applications and updates to devices,

enables users to download enterprise applications that

they are authorized to access, remotely deletes all

applications and data from devices if needed, tracks user

activity on devices, and detects and addresses security

issues on the device.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 92

Component

Product

Function

EPP

Zimperium MTD

Detects and stops threats to endpoints through an

integrated suite of endpoint protection technologies

including antivirus, data encryption, intrusion prevention,

EDR, and DLP. May include mechanisms that are designed

to protect applications and data; ensure device compliance

with policies regarding hardware, firmware, software, and

configuration; monitor endpoints for vulnerabilities,

suspicious activity, intrusion, infection, and malware; block

unauthorized traffic; disable malware and repair

infections; manage and administer software and updates;

monitor behavior and critical data; and enable endpoints

to be tracked, troubleshooted, and wiped, if necessary.

SIEM

IBM Security QRadar

XDR

Collects and consolidates security information and security

event data from many sources; correlates and analyzes the

data to help detect anomalies and recognize potential

threats and vulnerabilities; and logs the data to adhere to

data compliance requirements.

Vulnerability

Scanning and

Assessment

Tenable.io and

Tenable.ad

Scans and assesses the enterprise infrastructure and

resources for security risks, identifies vulnerabilities and

misconfigurations, and provides remediation guidance

regarding investigating and prioritizing responses to

incidents.

Security

Integration

Platform

IBM Cloud Pak for

Security

Integrates the SIEM and other security tools into a single

pane of glass to support generation of insights into threats

and help track, manage, and resolve cybersecurity

incidents.

Executes predefined incident response workflows to

automatically analyze information and orchestrate the

operations required to respond.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 93

Component

Product

Function

Security

Validation

Mandiant MSV

Provides visibility and evidence on the status of the

security controls’ effectiveness in the ZTA. Enables security

capabilities of the enterprise to be monitored and verified

by continuously validating and measuring the

cybersecurity controls; also used to automate the

demonstrations that were performed to showcase ZTA

capabilities. Deployed throughout the project’s laboratory

environment to enable monitoring and verification of

various security aspects of the builds. VMs that are

intended to operate as actors are deployed on each of the

subnetworks in each of the enterprises. These actors can

be used to initiate various actions for the purpose of

verifying that security controls are working to support the

objectives of zero trust.

Remote

Connectivity

Ivanti Tunnel

Enables authorized remote users to securely access the

inside of the enterprise. (Once inside, the ZTA manages the

user’s access to resources.)

Certificate

Management

DigiCert CertCentral TLS

Manager

Provides automated capabilities to issue, install, inspect,

revoke, renew, and otherwise manage TLS certificates.

Cloud IaaS

AWS - GitLab,

WordPress

Provides computing resources, complemented by storage

and networking capabilities, hosted by a cloud service

provider, offered to customers on demand, and exposed

through a GUI and an API.

Cloud SaaS

Digicert CertCentral,

Ivanti Access ZSO, Ivanti

Neurons for UEM, Okta

Identity Cloud, and

Tenable.io, and

Zimperium MTD

Cloud-based software delivered for use by the enterprise.

Application

GitLab

Example enterprise resource to be protected. (In this build,

GitLab is integrated with Okta using SAML, and IBM

Security QRadar XDR pulls logs from GitLab.)

Enterprise-

Managed

Device

Mobile devices (iOS and

Android)

Example endpoints to be protected. All enterprise-

managed devices are running an Ivanti Neurons for UEM

agent and also have the Okta Verify App installed.

BYOD

Mobile devices (iOS and

Android)

Example endpoints to be protected.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 94

D.2 Build Architecture

2656

In this section we present the logical architecture of E1B1 relative to how it instantiates the EIG crawl

2657

phase reference architecture depicted in Figure 4-2. We also describe E1B1’s physical architecture and

2658

present message flow diagrams for some of its processes.

2659

D.2.1 Logical Architecture

2660

Figure D-1 depicts the logical architecture of E1B1. Figure D-1 uses numbered arrows to depict the

2661

general flow of messages needed for a subject to request access to a resource and have that access

2662

request evaluated based on subject identity (both requesting user and requesting endpoint identity),

2663

user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting

2664

periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of

2665

requesting endpoint health, all of which must be performed to continually reevaluate access. The

2666

labeled steps in Figure D-1 have the same meanings as they do in Figure 4-1 and Figure 4-2. However,

2667

while Figure 4-2 depicts generic EIG crawl phase ZTA components, Figure D-1 includes the specific

2668

products that instantiate the architecture of E1B1. Figure D-1 also does not depict any of the resource

2669

management steps found in Figure 4-1 and Figure 4-2 because the ZTA technologies deployed in E1B1

2670

do not support the ability to perform authentication and reauthentication of the resource or periodic

2671

verification of resource health.

2672

E1B1 was designed with a single ICAM system (Okta Identity Cloud) that serves as the identity, access,

2673

and credential manager as well as the ZTA PE and PA. It includes the Ivanti Sentry as its PEP, and it also

2674

delegates some PDP responsibilities to Ivanti Access ZSO. Radiant Logic acts as a PIP for the PDP as it

2675

responds to inquiries and provides identity information on demand in order for Okta to make near-real-

2676

time access decisions. A more detailed depiction of the messages that flow among components to

2677

support a user access request can be found in Appendix D.2.4.

2678

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 95

Figure D-1 Logical Architecture of E1B1

2679

D.2.2 ICAM Information Architecture

2680

How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used

2681

among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture

2682

ensures that when a subject requests access to a resource, the aggregated set of identity information

2683

and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a

2684

basis on which to make the access decision.

2685

In E1B1, Okta, Radiant Logic, and SailPoint integrate with each other as well as with other components

2686

of the ZTA to support the ICAM information architecture. Okta Identity Cloud uses authentication and

2687

authorization to manage access to enterprise resources. SailPoint governs and RadiantOne aggregates

2688

identity information that is available from many sources within the enterprise. Radiant Logic stores,

2689

normalizes, and correlates this aggregation of information and extended attributes and provides

2690

appropriate views of the information in response to queries. RadiantOne monitors each source of truth

2691

for identity and updates changes in near real-time to ensure that Okta is able to enforce access based on

2692

accurate data. SailPoint is responsible for governance of the identity data. It executes automated, policy-

2693

based workflows to manage the lifecycle of user identity information and manage user accounts and

2694

S(D). Periodic reauthentication

challenge/response and endpoint

hygiene verification

Data Plane

I(5). Session

I(1). Initial access request

(identity and credentials)

Control Plane

I(2). Info needed

to verify subject

and its endpoint

I(3). Information needed to

approve/deny access request

S(B). Information needed to

continually evaluate access

I(4).

Allow/

deny

access

S(C). Continue/revoke/limit

session access

S(A). Access

requests; info

needed to

periodically

verify subject

(both user and

endpoint)

I(N): Initial Connection

S(X): Session Management

Okta Identity Cloud

Policy Decision

Point (PDP)

Policy Enforcement

Point(s) (PEPs)

Subject

User

Endpoint

Resource

On-Prem

Supporting Components

Endpoint Security:

• Ivanti Neurons for UEM

• Zimperium MTD

ICAM: Okta Identity Cloud

Federated Identity:

Radiant Logic RadiantOne

Identity Governance:

SailPoint IdentityIQ

Security Analytics:

• IBM Security QRadar XDR

• IBM Cloud Pak for Security

• Tenable.io and Tenable.ad

• Mandiant MSV

Ivanti Sentry

Multi-Factor Authentication:

• Okta IDaaS and Okta Verify App

Ivanti Access ZSO

AWS

Cloud

Policy Information Points

(PIPs)

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 96

permissions, ensuring compliance with requirements and regulations. To perform its identity

2695

aggregation and correlation functions, Radiant Logic connects to all locations within the enterprise

2696

where identity data exists to create a virtualized central identity data repository. SailPoint may also

2697

connect directly to sources of identity data or receive additional normalized identity data from Radiant

2698

Logic in order to perform its governance functions.

2699

Use of these three components to support the ICAM information architecture in Enterprise 1 is intended

2700

to demonstrate how a large enterprise with a complex identity environment might operate—for

2701

example, an enterprise with two ADs and multiple sources of identity information, such as HR platforms,

2702

the back-end database of a risk-scoring application, a credential management application, a learning

2703

management application, on-premises LDAP and databases, etc. Mimicking a large, complex enterprise

2704

enables the project to demonstrate the ability to aggregate identity data from many sources and

2705

provide identity managers with a rich set of attributes on which to base access policy. By aggregating

2706

risk-scoring and training data with more standard identity profile information found in AD, rich user

2707

profiles can be created, enabling enterprise managers to formulate and enforce highly granular access

2708

policies. Information from any number of the identity and attribute sources can be used to make

2709

authentication and authorization decisions. In addition, such aggregation allows identities for users in a

2710

partner organization whose identity information is not in the enterprise AD to be made available to the

2711

enterprise identity manager, so it has the information required to grant or deny partner user access

2712

requests. Policy-based access enforcement is also possible, in which access groups can be dynamically

2713

generated based on attribute values.

2714

Although federated identity and identity governance technologies provide automation to ease the

2715

burden of aggregating identity information and enforcement of identity governance, they are not

2716

required supporting components for implementing a ZTA in situations in which there may only be one or

2717

a few sources of identity data.

2718

The subsections below explain the operations of the ICAM information architecture for E1B1 when

2719

correlating identity information and when a user joins, changes roles, or leaves the enterprise. The

2720

operations depicted support identity correlation, identity management, identity authentication and

2721

authorization, and SIEM notification. It is worth noting that both Okta and SailPoint also support

2722

additional features that we have not deployed at this time, such as the ability to perform just-in-time

2723

provisioning of user accounts and permissions and the ability to remove access permissions or

2724

temporarily disable access authorizations from user accounts in response to alerts triggered by

2725

suspicious user activity.

2726

D.2.2.1 Identity Correlation

2727

Figure D-2 depicts the ICAM information architecture for E1B1 showing the steps involved in correlating

2728

identity information to build a rich global profile that includes not just identity profiles found in AD, but

2729

additional profiles and attributes from other platforms as well. The steps are as follows:

2730

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 97

1. RadiantOne aggregates, correlates, and normalizes identity information from all sources of

2731

identity information in the enterprise. In complex architectures, a ZTA requires an identity data

2732

foundation that bridges legacy systems and cloud technologies, and that extends beyond legacy

2733

AD domains. In our builds, the identity source used is an example human resources (HR)

2734

database that is augmented by extended user profile and attribute information that is

2735

representative of information that could come from a variety of identity sources in a large

2736

enterprise. A credential management database, an LDAP database, and a learning management

2737

application are some examples of such identity sources. These are depicted in the lower left-

2738

hand corner of Figure D-2 in the box labeled “Enhanced Identity Data Sources.”

2739

2. The correlated identity profiles in RadiantOne are consumed by SailPoint.

2740

3. SailPoint provisions identities into AD. Multiple AD instances may be present in the enterprise,

2741

as depicted. However, each of our builds includes only one AD instance.

2742

4. RadiantOne correlates endpoint identities from AD.

2743

5. SailPoint provisions identities into appropriate enterprise resources—e.g., SaaS, IaaS, enterprise

2744

applications, and endpoint protection platforms. (This provisioning may occur directly or via

2745

Okta.)

2746

6. As the new identities appear in the SaaS, IaaS, enterprise application, endpoint protection, and

2747

other components, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes

2748

this new identity information and adds it back into the global identity profile that it is

2749

maintaining. It also updates its HR, authentication, and authorization views to reflect the recent

2750

changes. Okta will eventually query these authentication and authorization information views in

2751

Radiant Logic to determine whether to grant future user access requests.

2752

7. Because Okta is maintaining its own internal identity directory, which is a mirrored version of

2753

the information in Radiant Logic, Okta consumes identities from Radiant Logic RadiantOne

2754

profiles. However, Okta does not store user password information.

2755

8. RadiantOne correlates identities that it gets from Okta.

2756

The identity correlation lifecycle is an ongoing process that occurs continuously as events that affect

2757

user identity information, accounts, and permissions occur, ensuring that the global identity profile is up

2758

to date. Example of such events are depicted in the subsections below.

2759

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 98

Figure D-2 E1B1 ICAM Information Architecture – Identity Correlation

2760

Credential

Mgt

SAP HR

SIEM

Okta

SaaS

IaaS

Enterprise App

Endpoint

Protection

Event Triggers

Incident Enrichment

Identity Metadata

Lifecycle Automation

Joiner, Mover, Leaver,

Entitlement Request

SailPoint

AuthN

/AuthZ

Radiant

Logic

6. RadiantOne correlates

additional sources of identity

data

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premises

LDAP and Db

Learning Mgt

1. Existing

sources of

identity are

correlated in

RadiantOne

2. Identity

profiles are

consumed from

RadiantOne by

SailPoint

3. SailPoint

provisions

identities into

endpoints

4. RadiantOne

correlates

endpoint identity

7. Okta

consumes

identities from

RadiantOne

profiles

8. RadiantOne

correlates Okta

identities

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

5. SAILPOINT provisions

identities into appropriate

enterprise resources

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 99

D.2.2.2 User Joins the Enterprise

2761

Figure D-3 depicts the ICAM information architecture for E1B1 showing the steps required to provision a

2762

new identity and associated access privileges when a new user is onboarded to the enterprise. The steps

2763

are as follows:

2764

1. When a new user joins the enterprise, an authorized HR staff member is assumed to input

2765

information into some sort of enterprise employee onboarding and management HR application

2766

that will ultimately result in a new, active HR record for the employee appearing in the Radiant

2767

Logic human resources record view. In practice, the application that the HR staff member uses

2768

will typically store identity records in backend databases like the ones depicted in the lower left-

2769

hand corner of Figure D-3 that are in the box labeled “Enhanced Identity Data Sources.” As these

2770

databases get updated, Radiant Logic is notified, and it responds by collecting the new

2771

information and using it to dynamically update its HR view.

2772

2. In the course of performing its governance activities, SailPoint detects the new HR record in

2773

Radiant Logic. SailPoint evaluates this new HR record, which triggers a Joiner lifecycle event,

2774

causing SailPoint to execute a policy-driven workflow that includes steps 3, 4, and 5.

2775

3. SailPoint provisions access permissions to specific enterprise resources for this new user. These

2776

access permissions, known as the user’s Birthright Role Access, are automatically determined

2777

according to policy based on factors such as the user’s role, type, group memberships, and

2778

status. These permissions comprise the access entitlements that the employee has on day 1.

2779

SailPoint creates an account for the new user in AD, thereby provisioning appropriate enterprise

2780

resource access for the new user. Also (not labeled in the diagram), Radiant Logic then collects

2781

and correlates this user information from AD into the global identity profile that it is

2782

maintaining.

2783

4. Assuming there are resources for which access is not managed by AD that the new user is

2784

authorized to access according to their Birthright Role, SailPoint also provisions access to these

2785

resources for the new user by creating new accounts for the user, as appropriate, on SaaS, IaaS,

2786

enterprise application, MDM, EPP, and other components. (This provisioning may occur directly

2787

or via Okta.)

2788

5. Once the new identity and its access privileges have been provisioned, SailPoint audits the

2789

identity and provisioning actions that were just performed.

2790

6. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint

2791

protection, and other components, Radiant Logic is notified. Radiant Logic collects, correlates

2792

and virtualizes this new identity information and adds it back into the global identity profile that

2793

it is maintaining. It also updates its HR, authentication, and authorization (AuthN/AuthZ) views

2794

to reflect the recent changes. Okta will eventually query these authentication and authorization

2795

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 100

information views in Radiant Logic to determine whether or not to grant future user access

2796

requests. (Note that Okta will only query these views in Radiant Logic when a user tries to access

2797

a resource; it will not query if there is no action from the user.)

2798

7. In addition, because Okta is maintaining its own internal identity directory, which is a mirrored

2799

version of the information in Radiant Logic, Radiant Logic pushes the new account identity

2800

information into Okta, thereby synchronizing its extended user profile attribute information

2801

with Okta. This provides Okta with additional contextual data regarding users and devices that

2802

Radiant Logic has aggregated from all identity sources, beyond the birthright provisioning

2803

information that SailPoint provided. Also (not labeled in the diagram), Radiant Logic then

2804

collects and correlates identity information from Okta back into the global identity profile that it

2805

is maintaining.

2806

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 101

Figure D-3 E1B1 ICAM Information Architecture – New User Onboarding

2807

Credential

Mgt

SAP HR

SIEM

Okta

SaaS

IaaS

Enterprise App

Endpoint Prot

Event Triggers

Incident Enrichment

Identity Metadata

SailPoint

AuthN

/AuthZ

Radiant

Logic

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premises

LDAP and Db

Learning Mgt

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

1) New, active

HR record

appears in

Radiant Logic HR

view

2) SailPoint detects

new HR record,

which triggers a

Joiner lifecycle event

3) SailPoint

provisions

Birthright

Role access

appropriate

enterprise

resources

4) SailPoint provisions

Birthright Role access to

appropriate enterprise

resources

5) SailPoint audits new

identity and provisioning

actions

6) Radiant Logic updates

the HR and AuthN/AuthZ

views as new enterprise

accounts appear

7) Radiant Logic

provides extended user

profile attribute

synchronization with

Okta

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 102

D.2.2.3 User Changes Roles

2808

Figure D-4 depicts the ICAM information architecture for E1B1, showing the steps required to remove

2809

some access privileges and add other access privileges for a user in response to that user changing roles

2810

within the enterprise. The steps are as follows:

2811

1. When a user changes roles within the enterprise, an authorized HR staff member is assumed to

2812

input information into some sort of enterprise employee management application that will

2813

result in the Radiant Logic HR record for that user indicating that the user has changed roles.

2814

2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR

2815

record, which triggers a Mover lifecycle event, causing SailPoint to execute a policy-driven

2816

workflow that includes steps 3, 4, 5, and 6.

2817

3. SailPoint removes access permissions associated with the user’s prior role (but not with the

2818

user’s new role) from the user’s AD account and removes access from other enterprise

2819

resources (e.g., SaaS, IaaS, enterprise applications, MDM) that the user had been authorized to

2820

access as a result of their prior role, but they are not authorized to access as a result of their

2821

new role. Also (not labeled in the diagram), Radiant Logic then collects and correlates any

2822

changes that were made to the user’s account from AD into the global identity profile that it is

2823

maintaining.

2824

4. Assuming there are enterprise resources that the user’s new role entitles them to access that

2825

are not managed by AD, SailPoint provisions access to these resources for the user by creating

2826

new accounts for the user, as appropriate, in SaaS, IaaS, enterprise application, endpoint

2827

protection, MDM, and other components. (This provisioning may occur directly or via Okta.)

2828

5. SailPoint generates an access review for management to confirm or revoke the changes that

2829

have been made. Such an access review is not strictly necessary. The permission changes could

2830

be executed in a fully automated manner, if desired, and specified by policy. However, having an

2831

access review provides management with the opportunity to exercise some supervisory

2832

discretion to permit the user to temporarily continue to have access to some resources

2833

associated with their former role that may still be needed.

2834

6. Once the access review has been completed and any access privilege changes deemed

2835

necessary have been performed, SailPoint audits the changes.

2836

7. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint

2837

protection, and other components, and as existing account access is removed, Radiant Logic is

2838

notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds

2839

it back into the global identity profile that it is maintaining. It also updates its HR,

2840

authentication, and authorization views to reflect the recent changes. Okta will eventually query

2841

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 103

these authentication and authorization information views in Radiant Logic to determine

2842

whether to grant future user access requests.

2843

8. In addition, because Okta is maintaining its own internal identity directory, which is a mirrored

2844

version of the information in Radiant Logic, Radiant Logic pushes the modified account identity

2845

information into Okta, thereby synchronizing its user profile attribute information with Okta.

2846

Also (not labeled in the diagram), Radiant Logic then collects and correlates identity information

2847

from Okta back into the global identity profile that it is maintaining.

2848

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 104

Figure D-4 E1B1 ICAM Information Architecture - User Changes Roles

2849

Credential

Mgt

SAP HR

SIEM

Okta

SaaS

IaaS

Enterprise App

Endpoint Prot

Event Triggers

Incident Enrichment

Identity Metadata

SailPoint

AuthN

/AuthZ

Radiant

Logic

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premises

LDAP and Db

Learning Mgt

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

1) Radiant Logic

HR record

indicates an

existing user

changes roles

2) SailPoint detects

updated HR record,

which triggers Mover

lifecycle event

3) SailPoint

removes

access

associated

with old role

4) SailPoint provisions

access associated with

new role

5) SailPoint generates

access review for

management to

confirm/revoke change

6) SailPoint audits changes

7) Radiant Logic updates

HR and AuthN/AuthZ

views as account

permissions change

8) RadiantLogic

provides extended user

profile attribute

synchronization with

Okta

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 105

D.2.2.4 User Leaves the Enterprise

2850

Figure D-5 depicts the ICAM information architecture for E1B1 showing the steps required to disable or

2851

delete an identity and remove access privileges in response to a user leaving the enterprise. The steps

2852

are as follows:

2853

1. When a user’s employment is terminated, an authorized HR staff member is assumed to input

2854

information into some sort of enterprise employee management application that will result in

2855

the Radiant Logic HR record for that user indicating that the user has changed from active to

2856

inactive status.

2857

2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR

2858

record, which triggers a Leaver lifecycle event, causing SailPoint to execute a policy-driven

2859

workflow that includes steps 3, 4, 5, and 6.

2860

3. SailPoint removes all access permissions associated with the user identity from AD. Also (not

2861

labeled in the diagram), Radiant Logic then collects and correlates this user access authorization

2862

change from AD into the global identity profile that it is maintaining.

2863

4. SailPoint either disables or deletes all enterprise resource accounts associated with the user

2864

identity, as defined by policy, from components such as SaaS, IaaS, enterprise applications, and

2865

endpoint protection platforms. (SailPoint may perform these actions directly or via Okta.)

2866

5. SailPoint removes the user identity from all governance groups the identity is in.

2867

6. SailPoint audits the changes made as a result of this user termination.

2868

7. As the enterprise accounts associated with the user’s identity are deleted or disabled, Radiant

2869

Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information

2870

and adds it back into the global identity profile that it is maintaining. It also updates its HR,

2871

authentication, and authorization views to reflect the recent changes. Okta will eventually query

2872

these authentication and authorization information views in Radiant Logic to determine

2873

whether or not to grant future user access requests.

2874

8. In addition, because Okta is maintaining its own internal identity directory, which is a mirrored

2875

version of the information in Radiant Logic, Radiant Logic pushes the modified account identity

2876

information into Okta, thereby synchronizing its user profile attribute information with Okta.

2877

Also (not labeled in the diagram), Radiant Logic then collects and correlates identity information

2878

from Okta back into the global identity profile that it is maintaining.

2879

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 106

Figure D-5 E1B1 ICAM Information Architecture - User Termination

2880

Credential

Mgt

SAP HR

SIEM

Okta

SaaS

IaaS

Enterprise App

Endpoint Prot

Event Triggers

Incident Enrichment

Identity Metadata

SailPoint

AuthN

/AuthZ

Radiant

Logic

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premises

LDAP and Db

Learning Mgt

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

1) Radiant Logic

HR record

indicates a status

change from

active to inactive

2) SailPoint

detects updated

HR record which

triggers Leaver

lifecycle event

3) SailPoint

removes

access

associated

with identity

4) SailPoint

disables/deletes

enterprise resource

accounts as defined by

policy

5) SailPoint removes user

from governance groups

6) SailPoint audits

termination

7) Radiant Logic updates

HR and AuthN/AuthZ

views as identity accounts

are disabled/deleted

8) Radiant Logic

provides extended user

profile attribute

synchronization with

Okta

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 107

D.2.3 Physical Architecture

2881

Sections 4.4.1 and 4.4.2 describe and depict the physical architecture of the E1B1 headquarters network

2882

and the E1B1 branch office network, respectively. In addition to what is represented in Section 4.4, E1B1

2883

has a VLAN on which servers hosting IBM Cloud Pak for Security components reside. It also has

2884

MobileIron Connector in its Shared Services VLAN and MobileIron Sentry in its DMZ VLAN.

2885

D.2.4 Message Flow for a Successful Resource Access Request

2886

Figure D-6 shows the high-level message flow for a use case in which a subject who has an enterprise ID,

2887

is located on-premises, and is authorized to access an enterprise resource requests and receives access

2888

to that resource. In the case depicted in the figure, access to the resource is protected by the Ivanti

2889

Sentry gateway, which acts as a PEP; Ivanti Neurons for UEM, which consists of a UEM agent on the

2890

endpoint and a cloud component that work together to authenticate the requesting endpoint and

2891

determine whether or not it is compliant; Ivanti Access ZSO, which acts as a delegated IdP and consults

2892

the Okta Identity Cloud to authenticate the requesting user; and the Okta Verify App, which performs

2893

second-factor user authentication.

2894

The message flow depicted in Figure D-6 shows only the messages that are sent in response to the

2895

access request. However, the authentication process also relies on the following additional background

2896

communications that occur among components on an ongoing basis:

2897

▪ The Ivanti Neurons for UEM agent periodically synchronizes with Ivanti Neurons for UEM to

2898

reauthenticate the requesting endpoint device using a unique certificate that has been

2899

provisioned specifically for that device and send Ivanti Neurons for UEM information about

2900

device attributes.

2901

▪ Zimperium periodically sends mobile defense threat information to Ivanti Neurons for UEM.

2902

▪ Ivanti Neurons for UEM determines device health status based on the above information that it

2903

receives from both the Ivanti Neurons for UEM agent and Zimperium.

2904

▪ Ivanti Neurons for UEM periodically sends device health information to Ivanti Access ZSO.

2905

▪ Ivanti Neurons for UEM also periodically sends device health information to the Ivanti Sentry

2906

gateway.

2907

▪ Okta periodically synchronizes with Ivanti Neurons for UEM and Ivanti Access ZSO to get the

2908

most up-to-date identity information and ensure that the endpoint device is managed by Ivanti

2909

Neurons for UEM.

2910

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 108

Figure D-6 Successful Access Request Enforced by Okta, Ivanti, and Zimperium Components

2911

The message flow depicted in Figure D-6 assumes that a VPN between an app on the user’s endpoint

2912

and the Ivanti Sentry gateway (PEP) has already been set up and connected prior to the user’s access

2913

request. This VPN connection is established automatically as soon as the device is connected to the

2914

network, and it can be configured to be in an “Always On” state. The steps in this message flow, which

2915

depicts a successful resource access, are as follows:

2916

1. The user logs into their device and authenticates themselves according to organization policy as

2917

configured in Ivanti Neurons for UEM. (This login could be accomplished with a fingerprint ID,

2918

face ID, PIN, derived credentials, or any other mechanism that is supported by the device and

2919

permitted by organizational policy as configured in the UEM.)

2920

2. The user requests to access a resource. This request is sent on the VPN from the user’s endpoint

2921

to the Ivanti Sentry gateway, which acts as a PEP.

2922

3. Based on information about the endpoint and user that the Ivanti Sentry gateway has received

2923

in the background from Ivanti Neurons for UEM, the Ivanti Sentry gateway determines that,

2924

Requesting

endpoint

Endpoint

Hosting

Resource

ZTA Components

Ivanti

Sentry

Gateway

Okta Identity Cloud

3. Ivanti Sentry permits the request to go to Okta

Resource

Subject

Ivanti

Neurons for

UEM Agent

Ivanti

Access ZSO

User

2. User makes a request to access the resource. The request

is sent on the Ivanti VPN to Ivanti Sentry (a PEP)

Ivanti Neurons for UEM,

Zimperium Mobile

Threat Defense

15. Resource accepts the token and grants the access request.

The user access session between the endpoint and the resource is secured according to policy

Ivanti

VPN App

7. Ivanti Access ZSO

authenticates the user and

verifies that the request is

compliant with policy

Okta Verify

App

14. Ivanti Sentry permits the token to go to the resource

6. Okta forwards request

to Ivanti Access ZSO

8. Ivanti Access ZSO notifies Okta that

it has approved the access request

11. Okta creates SAML token

and sends it to endpoint

12. Endpoint sends the token to the resource via the Ivanti VPN

13. Ivanti Sentry verifies device health

9. Okta challenges user to provide

second factor authentication via

the Okta Verify App

10. User provides second authentication factor

(biometrics)

1. User logs

into device

4. Okta challenges user to provide

first factor authentication

5. User chooses first authentication factor

(Okta FastPass + Ivanti Certificate)

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 109

according to policy, this request is permitted to be sent to Okta, so it allows the access request

2925

to proceed to the Okta Identity Cloud component.

2926

4. Okta requests the user to provide authentication information by using Okta FastPass. Okta

2927

FastPass allows the user to bypass username and password authentication because Okta trusts

2928

that the user properly authenticated when they initially logged into the device in step 1, and

2929

Okta knows (from background communications with Ivanti Access ZSO) that Ivanti Neurons for

2930

UEM is managing the device.

2931

5. The user provides first-factor authentication information by pressing the Okta FastPass button

2932

displayed on the device.

2933

6. Okta forwards the access request information to Ivanti Access ZSO because Okta will rely on and

2934

trust Ivanti Access ZSO to perform user authentication and verify the request’s attributes to

2935

ensure that they conform with policy. In this instance, Ivanti Access will act as a PDP to

2936

determine whether the access request should be granted.

2937

7. Ivanti Access authenticates the user using the access request information relayed by Okta. Ivanti

2938

Access gets user identities, attributes, and device information from a published certificate that

2939

was provisioned uniquely to the device. The certificate contains user information in a Certificate

2940

Subject Alternative field. Ivanti Neurons for UEM uses Okta as an identity provider and regularly

2941

syncs with Okta to remain up to date. It does not reach back to Okta every time an identity

2942

request comes in. Ivanti Access also verifies that the device complies with its conditional access

2943

policy. If any policy is being violated, device access is blocked, and a remediation page is

2944

presented to the user. Ivanti Access ZSO makes this determination based on information it has

2945

been receiving in the background from Ivanti Neurons for UEM and Zimperium.

2946

8. Ivanti Access ZSO notifies Okta that it has approved the access request by signing an

2947

authentication token using the Ivanti Access ZSO signing certificate.

2948

9. Okta initiates second-factor authentication using the Okta Verify App. Okta requires the user to

2949

present their biometric information to authenticate themselves to the device, and then the Okta

2950

Verify App displays a notification on the device informing the user that they must respond (e.g.,

2951

tap a confirmation button on the display) to prove that they are in possession of the device.

2952

10. The user presents their biometric information and responds to the Okta Verify notification,

2953

thereby providing the second authentication factor.

2954

11. Okta creates a SAML assertion and sends it to the requesting endpoint.

2955

12. The requesting endpoint sends the SAML assertion to the resource via the VPN that connects to

2956

the Ivanti Sentry gateway.

2957

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 110

13. The Ivanti Sentry gateway verifies device health and compliance based on the device

2958

information it has been receiving in the background from Ivanti Neurons for UEM.

2959

14. The Ivanti Sentry gateway permits the SAML assertion to proceed to the resource.

2960

15. The resource accepts the assertion and grants the access request. User traffic to and from the

2961

resource is secured according to policy (e.g., using TLS or HTTPS).

2962

Note that the message flow depicted in Figure D-6 applies to several of the use cases we are

2963

considering. It applies to all cases in which a user with an enterprise ID who can successfully

2964

authenticate themselves and who is using an enterprise-owned endpoint requests and receives access

2965

to an enterprise resource that they are authorized to access. The message flow is the same regardless of

2966

whether the employee is located on-premises at headquarters, on-premises at a branch office, or off-

2967

premises at home or elsewhere. It is also the same regardless of whether the resource is located on-

2968

premises or in the cloud.

2969

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 111

Appendix E EIG Enterprise 2 Build 1 (E2B1)

2970

E.1 Technologies

2971

EIG E2B1 uses products from Cisco Systems, IBM, Mandiant, Palo Alto, Ping Identity, Radiant Logic,

2972

SailPoint, and Tenable. Certificates from DigiCert are also used. For more information on these

2973

collaborators and the products and technologies that they contributed to this project overall, see

2974

Section 3.4.

2975

E2B1 components consist of PingFederate, which is connected to the Ping Identity SaaS offering of

2976

PingOne, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Cisco Duo,

2977

Palo Alto Next Generation Firewall, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable Nessus

2978

Network Monitor (NNM), Mandiant Security Validation (MSV), and DigiCert CertCentral.

2979

Table E-1 lists all of the technologies used in EIG E2B1. It lists the products used to instantiate each ZTA

2980

component and the security function that each component provides.

2981

Table E-1 E2B1 Products and Technologies

2982

Component

Product

Function

Ping Identity

PingFederate

Decides whether to grant, deny, or revoke access to a

resource based on enterprise policy, information from

supporting components, and a trust algorithm.

Ping Identity

PingFederate

Executes the PE’s policy decision by sending commands to a

PEP that establishes and shuts down the communication path

between subject and resource.

PEP

Ping Identity

PingFederate

Cisco Duo

Guards the trust zone that hosts one or more enterprise

resources; establishes, monitors, and terminates the

connection between subject and resource as directed by the

PA; forwards requests to and receives commands from the

PA.

Identity

Management

Ping Identity

PingFederate

Creates and manages enterprise user and device accounts,

identity records, role information, and access attributes that

form the basis of access decisions within an organization to

ensure the correct subjects have the appropriate access to

the correct resources at the appropriate time.

Access &

Credential

Management

Ping Identity

PingFederate

Manages access to resources by performing user and device

authentication (e.g., SSO and MFA) and using identity, role,

and access attributes to determine which access requests are

authorized.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 112

Component

Product

Function

Federated

Identity

Radiant Logic RadiantOne

Intelligent Identity Data

Platform

Aggregates and correlates all attributes relating to an identity

or object that is being authorized by a ZTA. It enables users of

one domain to securely access data or systems of another

domain seamlessly, and without the need for completely

redundant user administration. Federated identity

encompasses the traditional ICAM data, supports identities

that may be part of a larger federated ICAM community, and

may include non-enterprise employees.

Identity

Governance

SailPoint IdentityIQ

Provides policy-based, centralized, automated processes to

manage user identity and access control functions (e.g.,

ensuring segregation of duties, role management, logging,

access reviews, analytics, reporting) to ensure compliance

with requirements and regulations.

MFA

Cisco Duo

Supports MFA of a user identity by requiring the user to

provide not only something they know (e.g., a password), but

also something they have (e.g., a token).

UEM/MDM

None

Manages and secures enterprise desktop computers, laptops,

and/or mobile devices in accordance with enterprise policy to

protect applications and data; ensure device compliance;

mitigate and remediate vulnerabilities and threats; monitor

for suspicious activity to prevent and detect intrusions;

prevent, detect, and disable malware and other malicious or

unauthorized traffic; repair infected files when possible;

provide alerts and recommend remediation actions; and

encrypt data.

Pushes enterprise applications and updates to devices,

enables users to download enterprise applications that they

are authorized to access, remotely deletes all applications and

data from devices if needed, tracks user activity on devices,

and detects and addresses security issues on the device.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 113

Component

Product

Function

EPP

None

Detects and stops threats to endpoints through an integrated

suite of endpoint protection technologies including antivirus,

data encryption, intrusion prevention, EDR, and DLP. May

include mechanisms that are designed to protect applications

and data; ensure device compliance with policies regarding

hardware, firmware, software, and configuration; monitor

endpoints for vulnerabilities, suspicious activity, intrusion,

infection, and malware; block unauthorized traffic; disable

malware and repair infections; manage and administer

software and updates; monitor behavior and critical data; and

enable endpoints to be tracked, troubleshooted, and wiped, if

necessary.

Endpoint

Compliance

Cisco Duo

Performs device health checks by validating specific tools or

services within the endpoint including antivirus, data

encryption, intrusion prevention, EPP, and firewall. If the

device does not pass the health check, Duo fails second-factor

authentication and denies user access.

SIEM

IBM Security QRadar XDR

Collects and consolidates security information and security

event data from many sources; correlates and analyzes the

data to help detect anomalies and recognize potential threats

and vulnerabilities; and logs the data to adhere to data

compliance requirements.

Vulnerability

Scanning and

Assessment

Tenable.io and

Tenable.ad

Scans and assesses the enterprise infrastructure and

resources for security risks, identifies vulnerabilities and

misconfigurations, and provides remediation guidance

regarding investigating and prioritizing responses to incidents.

Network

Discovery

Tenable NNM

Discovers, classifies, and assesses the risk posed by devices

and users on the network.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 114

Component

Product

Function

Security

Validation

Mandiant MSV

Provides visibility and evidence on the status of the security

controls’ effectiveness in the ZTA. Enables security capabilities

of the enterprise to be monitored and verified by

continuously validating and measuring the cybersecurity

controls; also used to automate the demonstrations that

were performed to showcase ZTA capabilities. Deployed

throughout the project’s laboratory environment to enable

monitoring and verification of various security aspects of the

builds. VMs that are intended to operate as actors are

deployed on each of the subnetworks in each of the

enterprises. These actors can be used to initiate various

actions for the purpose of verifying that security controls are

working to support the objectives of zero trust.

Remote

Connectivity

Palo Alto Networks

NGFW

Enables authorized remote users to securely access the inside

of the enterprise. (Once inside, the ZTA manages the user’s

access to resources.)

Certificate

Management

DigiCert CertCentral TLS

Manager

Provides automated capabilities to issue, install, inspect,

revoke, renew, and otherwise manage TLS certificates.

Cloud IaaS

None

Provides computing resources, complemented by storage and

networking capabilities, hosted by a cloud service provider,

offered to customers on demand, and exposed through a GUI

and an API.

Cloud SaaS

Cisco Duo, Digicert

CertCentral Ping Identity

PingOne (PingFederate

service), and Tenable.io

Cloud-based software delivered for use by the enterprise.

Application

GitLab

Example enterprise resource to be protected. (In this build,

GitLab and WordPress are integrated with Okta using SAML,

and IBM Security QRadar XDR pulls logs from GitLab.)

Enterprise-

Managed Device

Windows client, macOS

client, and mobile

devices (iOS and Android)

Example endpoints to be protected. All enterprise-managed

devices are running an Ivanti Neurons for UEM agent and also

have the Okta Verify App installed.

BYOD

Windows client, macOS

client, and mobile

devices (iOS and Android)

Example endpoints to be protected.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 115

E.2 Build Architecture

2983

In this section we present the logical architecture of E2B1 relative to how it instantiates the EIG crawl

2984

phase reference architecture depicted in Figure 4-2. We also describe E2B1’s physical architecture and

2985

present message flow diagrams for some of its processes.

2986

E.2.1 Logical Architecture

2987

Figure E-1 depicts the logical architecture of E2B1. The figure uses numbered arrows to depict the

2988

general flow of messages needed for a subject to request access to a resource and have that access

2989

request evaluated based on subject identity (both requesting user and requesting endpoint identity),

2990

user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting

2991

periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of

2992

requesting endpoint health, all of which must be performed to continually reevaluate access. The

2993

labeled steps in Figure E-1 have the same meanings as they do in Figure 4-1 and Figure 4-2. However,

2994

Figure E-1 includes the specific products that instantiate the architecture of E2B1. Figure E-1 also does

2995

not depict any of the resource management steps found in Figure 4-1 and Figure 4-2 because the ZTA

2996

technologies deployed in E2B1 do not support the ability to perform authentication and

2997

reauthentication of the resource or periodic verification of resource health.

2998

E2B1 was designed with a single ICAM system (Ping Identity PingFederate) that serves as the identity,

2999

access, and credential manager as well as the ZTA PE and PA. PingFederate also serves as its PEP.

3000

Radiant Logic acts as a PIP for the PDP as it responds to inquiries and provides user identity and

3001

authentication information on demand in order for Ping Identity PingFederate to make near-real-time

3002

access decisions. Cisco Duo provides endpoint protection by monitoring the status and configuration of

3003

the endpoint to ensure that its health posture continues to conform with enterprise policy. Duo also

3004

provides second-factor user authentication. Note that both multifactor authentication and directory

3005

services are also available through Ping, but for purposes of this collaborative build, Ping is

3006

demonstrating standards-based interoperability by integrating with Cisco Duo for MFA and Radiant Logic

3007

RadiantOne for federated identity services. A more detailed depiction of the messages that flow among

3008

components to support a user access request can be found in Appendix E.2.4.

3009

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 116

Figure E-1 Logical Architecture of E2B1

3010

E.2.2 ICAM Information Architecture

3011

How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used

3012

among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture

3013

ensures that when a subject requests access to a resource, the aggregated set of identity information

3014

and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a

3015

basis on which to make the access decision.

3016

In E2B1, Ping, Radiant Logic, and SailPoint integrate with each other as well as with other components of

3017

the ZTA to support the ICAM information architecture. Ping Identity PingFederate uses authentication

3018

and authorization to manage access to enterprise resources. SailPoint governs and RadiantOne

3019

aggregates identity information that is available from many sources within the enterprise. Radiant One

3020

stores, normalizes, and correlates this aggregation of information and extended attributes and provides

3021

appropriate views of the information in response to queries. RadiantOne monitors each source of

3022

identity truth and updates changes in near real-time to ensure that Ping is able to enforce access based

3023

on accurate data. SailPoint is responsible for governance of the identity data. It executes automated,

3024

policy-based workflows to manage the lifecycle of user identity information and manage user accounts

3025

S(D). Periodic reauthentication

challenge/response and endpoint

hygiene verification

Data Plane

I(5). Session

I(1). Initial access request

(identity and credentials)

Control Plane

I(2). Info needed

to verify subject

and its endpoint

I(3). Information needed to

approve/deny access request

S(B). Information needed to

continually evaluate access

I(4).

Allow/

deny

access

S(C). Continue/revoke/limit

session access

S(A). Access

requests; info

needed to

periodically

verify subject

(both user and

endpoint)

I(N): Initial Connection

S(X): Session Management

Ping Identity Ping

Federate

Policy Decision

Point (PDP)

Policy Enforcement

Point(s) (PEPs)

Subject

User

Endpoint

Resource

On-Prem

Google

Cloud

Ping Identity Ping Access

Cisco Duo

Supporting Components

Endpoint Security:

• Cisco Duo

ICAM: Ping Identity Ping Federate

Federated Identity:

Radiant Logic RadiantOne

Identity Governance:

SailPoint IdentityIQ

Security Analytics:

• IBM QRadar

• Tenable.io, Tenable.ad, and

Tenable NNM

• Mandiant MSV

Multi-Factor Authentication:

Cisco Duo

Policy Information Points

(PIPs)

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 117

and permissions, ensuring compliance with requirements and regulations. To perform its identity

3026

aggregation and correlation functions, Radiant Logic connects to all locations within the enterprise

3027

where identity data exists to create a virtualized central identity data repository. SailPoint may also

3028

connect directly to sources of identity data or receive additional normalized identity data from Radiant

3029

Logic in order to perform its governance functions.

3030

Use of these three components to support the ICAM information architecture in Enterprise 2 is intended

3031

to demonstrate how a large enterprise with a complex identity environment might operate—for

3032

example, an enterprise with two ADs and multiple sources of identity information, such as HR platforms,

3033

the back-end database of a risk-scoring application, a credential management application, a learning

3034

management application, on-premises LDAP and databases, etc. Mimicking a large, complex enterprise

3035

enables the project to demonstrate the ability to aggregate identity data from many sources and

3036

provide identity managers with a rich set of attributes on which to base access policy. By aggregating

3037

risk-scoring and training data with more standard identity profile information found in AD, rich user

3038

profiles can be created, enabling enterprise managers to formulate and enforce highly granular access

3039

policies. Information from any number of the identity and attribute sources can be used to make

3040

authentication and authorization decisions. In addition, such aggregation allows identities for users in a

3041

partner organization whose identity information is not in the enterprise AD to be made available to the

3042

enterprise identity manager so it has the information required to grant or deny partner user access

3043

requests. Policy-based access enforcement is also possible, in which access groups can be dynamically

3044

generated based on attribute values.

3045

Although federated identity and identity governance technologies provide automation to ease the

3046

burden of aggregating identity information and enforcement of identity governance, they are not

3047

required supporting components for implementing a ZTA in situations in which there may only be one or

3048

a few sources of identity data.

3049

The subsections below explain the operations of the ICAM information architecture for E2B1 when

3050

correlating identity information and when a user joins, changes roles, or leaves the enterprise. The

3051

operations depicted support identity correlation, identity management, identity authentication and

3052

authorization, and SIEM notification. It is worth noting that both Ping Identity and SailPoint also support

3053

additional features that we have not deployed at this time, such as the ability to perform just-in-time

3054

provisioning of user accounts and permissions and the ability to remove access permissions or

3055

temporarily disable access authorizations from user accounts in response to alerts triggered by

3056

suspicious user activity.

3057

E.2.2.1 Identity Correlation

3058

Figure E-2 depicts the ICAM information architecture for E2B1, showing the steps involved in correlating

3059

identity information to build a rich global profile that includes not just identity profiles found in AD, but

3060

additional profiles and attributes from other platforms as well. The steps are as follows:

3061

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 118

1. RadiantOne aggregates, correlates, and normalizes identity information from all sources of

3062

identity information in the enterprise. In complex architectures, a ZTA requires an identity data

3063

foundation that bridges legacy systems and cloud technologies, and that extends beyond legacy

3064

AD domains. In our builds, the identity source used is an example human resources (HR)

3065

database that is augmented by extended user profile and attribute information that is

3066

representative of information that could come from a variety of identity sources in a large

3067

enterprise. A credential management database, an LDAP database, and a learning management

3068

application are some examples of such identity sources. These are depicted in the lower left-

3069

hand corner of Figure E-2 in the box labeled “Enhanced Identity Data Sources.”

3070

2. The correlated identity profiles in RadiantOne are consumed by SailPoint.

3071

3. SailPoint provisions identities into AD. Multiple AD instances may be present in the enterprise,

3072

as depicted. However, each of our builds includes only one AD instance.

3073

4. RadiantOne correlates endpoint identities from AD.

3074

5. SailPoint provisions identities into appropriate enterprise resources—e.g., SaaS, IaaS, enterprise

3075

applications, and endpoint protection platforms. (This provisioning may occur directly or via

3076

Ping.)

3077

6. As the new identities appear in the SaaS, IaaS, enterprise application, endpoint protection, and

3078

other components, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes

3079

this new identity information and adds it back into the global identity profile that it is

3080

maintaining. It also updates its HR, authentication, and authorization views to reflect the recent

3081

changes. Ping will eventually query these authentication and authorization information views in

3082

Radiant Logic to determine whether to grant future user access requests.

3083

Note that in this architecture, persistent storage of personally identifiable information (PII) is

3084

not required within any SaaS service. RadiantOne stores all user identity information, and

3085

RadiantOne has been installed on-premises. Ping does not store any user data. When Ping needs

3086

user identity data, it looks up this information directly from RadiantOne.

3087

The identity correlation lifecycle is an ongoing process that occurs continuously as events that affect

3088

user identity information, accounts, and permissions occur, ensuring that the global identity profile is up

3089

to date. Examples of such events are depicted in the subsections below.

3090

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 119

Figure E-2 E2B1 ICAM Information Architecture – Identity Correlation

3091

Credential

Mgt

SAP HR

SIEM

Ping

SaaS

IaaS

Enterprise App

Endpoint Prot

Event Triggers

Incident Enrichment

Identity Metadata

AuthN

/AuthZ

Lifecycle Automation

Joiner, Mover, Leaver,

Entitlement Request

SailPoint

Radiant

Logic

6. RadiantOne correlates

additional sources of identity

data

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premise

LDAP and Db

Learning Mgt

1. Existing

sources of

identity are

correlated in

RadiantOne

2. Identity

profiles are

consumed from

RadiantOne by

SailPoint

3. SailPoint

provisions

identities into

endpoints

4. RadiantOne

correlates

endpoint identity

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

5) Sailpoint provisions

identities into appropriate

enterprise resources

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 120

E.2.2.2 User Joins the Enterprise

3092

Figure E-3 depicts the ICAM information architecture for E2B1, showing the steps required to provision a

3093

new identity and associated access privileges when a new user is onboarded to the enterprise. The steps

3094

are as follows:

3095

1. When a new user joins the enterprise, an authorized HR staff member is assumed to input

3096

information into some sort of enterprise employee onboarding and management HR application

3097

that will ultimately result in a new, active HR record for the employee appearing in the Radiant

3098

Logic human resources record view. In practice, the application that the HR staff member uses

3099

will typically store identity records in backend databases like the ones depicted in the lower left-

3100

hand corner of Figure D-3 that are in the box labeled “Enhanced Identity Data Sources.” As these

3101

databases get updated, Radiant Logic is notified, and it responds by collecting the new

3102

information and using it to dynamically update its HR view.

3103

2. In the course of performing its governance activities, SailPoint detects the new HR record in

3104

Radiant Logic. SailPoint evaluates this new HR record, which triggers a Joiner lifecycle event,

3105

causing SailPoint to execute a policy-driven workflow that includes steps 3, 4, and 5.

3106

3. SailPoint provisions access permissions to specific enterprise resources for this new user. These

3107

access permissions, known as the user’s Birthright Role Access, are automatically determined

3108

according to policy based on factors such as the user’s role, type, group memberships, and

3109

status. These permissions comprise the access entitlements that the employee has on day 1.

3110

SailPoint creates an account for the new user in AD, thereby provisioning appropriate enterprise

3111

resource access for the new user. Also (not labeled in the diagram), Radiant Logic then collects

3112

and correlates this user information from AD into the global identity profile that it is

3113

maintaining.

3114

4. Assuming there are resources for which access is not managed by AD that the new user is

3115

authorized to access according to their Birthright Role, SailPoint also provisions access to these

3116

resources for the new user by creating new accounts for the user, as appropriate, on SaaS, IaaS,

3117

enterprise application, MDM, EPP, and other components. (This provisioning may occur directly

3118

or via Ping.)

3119

5. Once the new identity and its access privileges have been provisioned, SailPoint audits the

3120

identity and provisioning actions that were just performed.

3121

6. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint

3122

protection, and other components, Radiant Logic is notified. Radiant Logic collects, correlates,

3123

and virtualizes this new identity information and adds it back into the global identity profile that

3124

it is maintaining. It also updates its HR, authentication, and authorization (AuthN/AuthZ) views

3125

to reflect the recent changes. Ping will eventually query these authentication and authorization

3126

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 121

information views in Radiant Logic to determine whether or not to grant future user access

3127

requests. (Note that Ping will only query these views in Radiant Logic when a user tries to access

3128

a resource; it will not query if there is no action from the user. Also, RadiantOne stores all user

3129

identity information; Ping does not store any user data. When Ping needs user identity data, it

3130

looks up this information directly from RadiantOne.)

3131

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 122

Figure E-3 E2B1 ICAM Information Architecture – New User Onboarding

3132

Credential

Mgt

SAP HR

SIEM

Ping

SaaS

IaaS

Enterprise App

Endpoint Prot

Event Triggers

Incident Enrichment

Identity Metadata

AuthN

/AuthZ

SailPoint

Radiant

Logic

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premise

LDAP and Db

Learning Mgt

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

1) New, active

HR record

appears in

RadiantLogic HR

view

2) Sailpoint detects

new HR record,

which triggers Joiner

lifecycle event

3) Sailpoint

provisions

Birthright

Role access

appropriate

enterprise

resources

4) Sailpoint provisions

Birthright Role access to

appropriate enterprise

resources

5) Sailpoint audits new

identity and provisioning

actions

6) RadiantLogic updates

HR and AuthN/AuthZ

views as new enterprise

accounts appear

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 123

E.2.2.3 User Changes Roles

3133

Figure E-4 depicts the ICAM information architecture for E2B1, showing the steps required to remove

3134

some access privileges and add other access privileges for a user in response to that user changing roles

3135

within the enterprise. The steps are as follows:

3136

1. When a user changes roles within the enterprise, an authorized HR staff member is assumed to

3137

input information into some sort of enterprise employee management application that will

3138

result in the Radiant Logic HR record for that user indicating that the user has changed roles.

3139

2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR

3140

record, which triggers a Mover lifecycle event, causing SailPoint to execute a policy-driven

3141

workflow that includes steps 3, 4, 5, and 6.

3142

3. SailPoint removes access permissions associated with the user’s prior role (but not with the

3143

user’s new role) from the user’s AD account and removes access from other enterprise

3144

resources (e.g., SaaS, IaaS, enterprise applications, MDM) that the user had been authorized to

3145

access as a result of their prior role but is not authorized to access as a result of their new role.

3146

Also (not labeled in the diagram), Radiant Logic then collects and correlates any changes that

3147

were made to the user’s account from AD into the global identity profile that it is maintaining.

3148

4. Assuming there are enterprise resources that the user’s new role entitles them to access that

3149

are not managed by AD, SailPoint provisions access to these resources for the user by creating

3150

new accounts for the user, as appropriate, in SaaS, IaaS, enterprise application, endpoint

3151

protection, MDM, and other components. (This provisioning may occur directly or via Ping.)

3152

5. SailPoint generates an access review for management to confirm or revoke the changes that

3153

have been made. Such an access review is not strictly necessary. The permission changes could

3154

be executed in a fully automated manner, if desired, and specified by policy. However, having an

3155

access review provides management with the opportunity to exercise some supervisory

3156

discretion to permit the user to temporarily continue to have access to some resources

3157

associated with their former role that may still be needed.

3158

6. Once the access review has been completed and any access privilege changes deemed

3159

necessary have been performed, SailPoint audits the changes.

3160

7. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint

3161

protection, and other components, and as existing account access is removed, Radiant Logic is

3162

notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds

3163

it back into the global identity profile that it is maintaining. It also updates its HR,

3164

authentication, and authorization views to reflect the recent changes. Ping will eventually query

3165

these authentication and authorization information views in Radiant Logic to determine

3166

whether to grant future user access requests. (RadiantOne stores all user identity information;

3167

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 124

Ping does not store any user data. When Ping needs user identity data, it looks up this

3168

information directly from RadiantOne.)

3169

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 125

Figure E-4 E2B1 ICAM Information Architecture - User Changes Roles

3170

Credential

Mgt

SAP HR

SIEM

Ping

SaaS

IaaS

Enterprise App

Endpoint Prot

Event Triggers

Incident Enrichment

Identity Metadata

AuthN

/AuthZ

SailPoint

Radiant

Logic

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premise

LDAP and Db

Learning Mgt

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

1) RadiantLogic

HR record

indicates an

existing user

changes roles

2) Sailpoint detects

updated HR record

which triggers Mover

lifecycle event

3) Sailpoint

removes

access

associated

with old role

4) Sailpoint provisions

access associated with

new role

5) Sailpoint generates

access review for

management to

confirm/revoke change

6) Sailpoint audits

changes

7) RadiantLogic updates

HR and AuthN/AuthZ

views as account

permissions change

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 126

E.2.2.4 User Leaves the Enterprise

3171

Figure E-5 depicts the ICAM information architecture for E2B1, showing the steps required to disable or

3172

delete an identity and remove access privileges in response to a user leaving the enterprise. The steps

3173

are as follows:

3174

8. When a user’s employment is terminated, an authorized HR staff member is assumed to input

3175

information into some sort of enterprise employee management application that will result in

3176

the Radiant Logic HR record for that user indicating that the user has changed from active to

3177

inactive status.

3178

9. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR

3179

record, which triggers a Leaver lifecycle event, causing SailPoint to execute a policy-driven

3180

workflow that includes steps 3, 4, 5, and 6.

3181

10. SailPoint removes all access permissions associated with the user identity from AD. Also (not

3182

labeled in the diagram), Radiant Logic then collects and correlates this user access authorization

3183

change from AD into the global identity profile that it is maintaining.

3184

11. SailPoint either disables or deletes all enterprise resource accounts associated with the user

3185

identity, as defined by policy, from components such as SaaS, IaaS, enterprise applications, and

3186

endpoint protection platforms. (SailPoint may perform these actions directly or via Ping.)

3187

12. SailPoint removes the user identity from all governance groups the identity is in.

3188

13. SailPoint audits the changes made as a result of this user termination.

3189

14. As the enterprise accounts associated with the user’s identity are deleted or disabled, Radiant

3190

Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information

3191

and adds it back into the global identity profile that it is maintaining. It also updates its HR,

3192

authentication, and authorization views to reflect the recent changes. Ping will eventually query

3193

these authentication and authorization information views in Radiant Logic to determine

3194

whether or not to grant future user access requests. (RadiantOne stores all user identity

3195

information; Ping does not store any user data. When Ping needs user identity data, it looks up

3196

this information directly from RadiantOne.)

3197

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 127

Figure E-5 E2B1 ICAM Information Architecture - User Termination

3198

Credential

Mgt

SAP HR

SIEM

Ping

SaaS

IaaS

Enterprise App

Endpoint Prot

Event Triggers

Incident Enrichment

Identity Metadata

AuthN

/AuthZ

SailPoint

Radiant

Logic

Enhanced Identity Data Sources

Workday

Risk Scoring

On Premise

LDAP and Db

Learning Mgt

Legend

Identity Correlation

Identity Management

Identity AuthN/AuthZ

SIEM Notifications

1) RadiantLogic

HR record

indicates a status

change from

active to inactive

2) Sailpoint

detects updated

HR record which

triggers Leaver

lifecycle event

3) Sailpoint

removes

access

associated

with Identity

4) Sailpoint

disables/deletes

enterprise resource

accounts as defined by

policy

5) Sailpoint removes user

from governance groups

6) Sailpoint audits

termination

7) RadiantLogic updates

HR and AuthN/AuthZ

views as identity accounts

are disabled/deleted

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 128

E.2.3 Physical Architecture

3199

Section 4.4.3 describes the physical architecture of the E2B1 network.

3200

E.2.4 Message Flow for a Successful Resource Access Request

3201

Below is depicted the high-level message flow supporting the use case in which a subject who has an

3202

enterprise ID, who is located on-premises, and who is authorized to access an enterprise resource,

3203

requests and receives access to that resource. In the case depicted here, access to the resource is

3204

protected by PingFederate, which acts as a PDP and an identity provider; Cisco Duo, which consists of an

3205

agent on the endpoint and a cloud component that work together to perform second-factor user

3206

authentication and also to gather device health information to ensure device compliance; and Radiant

3207

Logic, which performs credential validation for authentication and provides granular user-relevant

3208

attributes and groups for authorization at the request of PingFederate.

3209

The message flow depicted in Figure E-6 shows only the messages that are sent in response to the

3210

access request. However, the authentication process also relies on the following additional background

3211

communications that occur among components on an ongoing basis:

3212

▪ The Cisco Duo endpoint agent periodically syncs with the Cisco Duo cloud component to

3213

reauthenticate the requesting endpoint device using a unique certificate that has been

3214

provisioned specifically for that device and sends the cloud component information about

3215

device health (e.g., firewall running, anti-malware software, IoS version).

3216

▪ Cisco Duo is integrated with PingFederate and periodically sends PingFederate assurance that,

3217

based on the device health information collected by Cisco Duo, the device is compliant with

3218

configured policy.

3219

Figure E-6 depicts the message flow for the user’s request to access the resource.

3220

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 129

Figure E-6 Use Case—E2B1 – Access Enforced by Ping Federate, Cisco Duo, and Radiant Logic

3221

The message flow depicted in Figure E-6 consists of the following steps:

3222

1. A user requests to access a resource by typing the resource’s URL into a browser.

3223

2. The resource receives the access request and sends a user authentication request to

3224

PingFederate.

3225

3. PingFederate consults the device health information it has received in the background from

3226

Cisco Duo verifying that the device has been authenticated and is compliant with policy.

3227

4. PingFederate prompts for username and password.

3228

5. The user responds with username and password.

3229

6. PingFederate sends the user’s username and password to the Ping LDAP Gateway to facilitate

3230

communication between the cloud-hosted Ping and the on premises Radiant Logic resources.

3231

7. The LDAP gateway forwards the LDAP authentication request to Radiant Logic.

3232

Requesting

endpoint

Endpoint

Hosting

Resource

ZTA Components

Cisco

Duo

Ping Federate

2. Resource sends user authentication request to Ping Federate

Resource

Subject

Radiant

Logic

User

6. Ping Federate sends the username

and password to the Ping LDAP gateway

4. Ping Federate prompts for username and password

5. User responds with credential

Sailpoint

16. The user access session between the endpoint and the resource is secured according to policy

1. User requests access to resource by entering its fully qualified domain name

Cisco

Duo

Agent

3. Ping Federate verifies device health using

endpoint info it has received from Cisco Duo

15. Ping sends SAML assertion token to the resource

and the user is granted access

LDAP

Gateway

7.LDAP

authentication

request

14. Successful authentication

10. User attributes

12. Cisco Duo challenges user for second factor authentication

13. User provides second authentication factor

9. Successful

authentication

and user

attributes

11. Asks Cisco Duo to perform

second factor authentication

8. Radiant Logic

authenticates

user

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 130

8. Radiant Logic authenticates that the username exists in the master user record and the provided

3233

password (credential) is valid based on credentials stored in Radiant Logic or in another source

3234

of identity credentials federated by Radiant Logic.

3235

9. Radiant Logic replies to the LDAP gateway with a valid BIND indicating a successful user

3236

authentication and all additional user attributes requested by Ping at the time of Authentication

3237

10. The LDAP gateway forwards the response from Radiant Logic to PingFederate with the

3238

successful BIND and applicable user’s attributes.

3239

11. PingFederate requests Cisco Duo to perform second-factor user authentication.

3240

12. Cisco Duo challenges the user to provide the second authentication factor.

3241

13. The user responds with the second authentication factor.

3242

14. Cisco Duo responds to PingFederate, indicating that the user authenticated successfully.

3243

15. PingFederate sends a SAML assertion token to the resource. The resource accepts the assertion

3244

and grants the access request.

3245

16. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).

3246

Note that the message flow depicted in Figure E-6 applies to several of the use cases we are considering.

3247

It applies to all cases in which a user with an enterprise ID who can successfully authenticate themselves

3248

and who is using an enterprise-owned endpoint requests and receives access to an enterprise resource

3249

that they are authorized to access. The message flow is the same regardless of whether the employee is

3250

located on-premises at headquarters, on-premises at a branch office, or off-premises at home or

3251

elsewhere. It is also the same regardless of whether the resource is located on-premises or in the cloud.

3252

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 131

Appendix F EIG Enterprise 3 Build 1 (E3B1)

3253

F.1 Technologies

3254

EIG E3B1 uses products from F5, Forescout, Lookout, Mandiant, Microsoft, Palo Alto Networks, PC

3255

Matic, and Tenable. Certificates from DigiCert are also used. For more information on these

3256

collaborators and the products and technologies that they contributed to this project overall, see

3257

Section 3.4.

3258

E3B1 components consist of Microsoft Azure AD, Microsoft AD, F5 BIG-IP, Microsoft Intune, Microsoft

3259

Defender for Endpoint, Lookout MES, PC Matic Pro, Microsoft Sentinel, Tenable.io, Tenable.ad,

3260

Mandiant MSV, Forescout eyeSight, Palo Alto Networks NGFW, and DigiCert CertCentral.

3261

Table F-1 lists all of the technologies used in E3B1 ZTA. It lists the products used to instantiate each ZTA

3262

component and the security function that the component provides.

3263

Table F-1 E3B1 Products and Technologies

3264

Component

Product

Function

Azue AD

(Conditional

Access)

Decides whether to grant, deny, or revoke access to a resource

based on enterprise policy, information from supporting

components, and a trust algorithm.

Azure AD

(Conditional

Access)

Executes the PE’s policy decision by sending commands to a

PEP that establishes and shuts down the communication path

between subject and resource.

PEP

Azure AD

(Conditional

Access), F5 BIG-IP,

and Lookout MES

Guards the trust zone that hosts one or more enterprise

resources; establishes, monitors, and terminates the

connection between subject and resource as directed by the

PA; forwards requests to and receives commands from the PA.

Identity

Management

Microsoft AD and

Azure AD

Creates and manages enterprise user and device accounts,

identity records, role information, and access attributes that

form the basis of access decisions within an organization to

ensure the correct subjects have the appropriate access to the

correct resources at the appropriate time.

Access &

Credential

Management

Microsoft AD and

Azure AD

Manages access to resources by performing user and device

authentication (e.g., SSO and MFA) and using identity, role,

and access attributes to determine which access requests are

authorized.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 132

Component

Product

Function

Federated

Identity

Microsoft AD and

Azure AD

Aggregates and correlates all attributes relating to an identity

or object that is being authorized by a ZTA. It enables users of

one domain to securely access data or systems of another

domain seamlessly, and without the need for completely

redundant user administration. Federated identity

encompasses the traditional ICAM data, supports identities

that may be part of a larger federated ICAM community, and

may include non-enterprise employees.

Identity

Governance

Microsoft AD and

Azure AD

Provides policy-based, centralized, automated processes to

manage user identity and access control functions (e.g.,

ensuring segregation of duties, role management, logging,

access reviews, analytics, reporting) to ensure compliance with

requirements and regulations.

MFA

Azure AD

(Multifactor

Authentication)

Authenticates user identity by requiring the user to provide

not only something they know (e.g., a password), but also

something they have (e.g., a token).

UEM/MDM

Microsoft Intune

Manages and secures enterprise desktop computers, laptops,

and/or mobile devices in accordance with enterprise policy to

protect applications and data; ensure device compliance;

mitigate and remediate vulnerabilities and threats; monitor for

suspicious activity to prevent and detect intrusions; prevent,

detect, and disable malware and other malicious or

unauthorized traffic; repair infected files when possible;

provide alerts and recommend remediation actions; and

encrypt data.

Pushes enterprise applications and updates to devices, enables

users to download enterprise applications that they are

authorized to access, remotely deletes all applications and

data from devices if needed, tracks user activity on devices,

and detects and addresses security issues on the device.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 133

Component

Product

Function

EPP

Microsoft

Defender for

Endpoint, Lookout

MES, PC Matic Pro

Detects and stops threats to endpoints through an integrated

suite of endpoint protection technologies including antivirus,

data encryption, intrusion prevention, EDR, and DLP. May

include mechanisms that are designed to protect applications

and data; ensure device compliance with policies regarding

hardware, firmware, software, and configuration; monitor

endpoints for vulnerabilities, suspicious activity, intrusion,

infection, and malware; block unauthorized traffic; disable

malware and repair infections; manage and administer

software and updates; monitor behavior and critical data; and

enable endpoints to be tracked, troubleshooted, and wiped, if

necessary.

SIEM

Microsoft Sentinel

Collects and consolidates security information and security

event data from many sources; correlates and analyzes the

data to help detect anomalies and recognize potential threats

and vulnerabilities; and logs the data to adhere to data

compliance requirements.

Vulnerability

Scanning and

Assessment

Tenable.io and

Tenable.ad

Scans and assesses the enterprise infrastructure and resources

for security risks; identifies vulnerabilities and

misconfigurations; and provides remediation guidance

regarding investigating and prioritizing responses to incidents.

Security

Validation

Mandiant MSV

Provides visibility and evidence on the status of the security

controls’ effectiveness in the ZTA. Enables security capabilities

of the enterprise to be monitored and verified by continuously

validating and measuring the cybersecurity controls; also used

to automate the demonstrations that were performed to

showcase ZTA capabilities. Mandiant MSV is deployed

throughout the project’s laboratory environment to enable

monitoring and verification of various security aspects of the

builds. VMs that are intended to operate as actors are

deployed on each of the subnetworks in each of the

enterprises. These actors can be used to initiate various

actions for the purpose of verifying that security controls are

working to support the objectives of zero trust.

Network

Discovery

Forescout

eyeSight

Discovers, classifies, and assesses the risk posed by devices

and users on the network.

Remote

Connectivity

Palo Alto

Networks NGFW

Enables authorized remote users to securely access the inside

of the enterprise. (Once inside, the ZTA manages the user’s

access to resources.)

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 134

Component

Product

Function

Certificate

Management

DigiCert

CertCentral TLS

Manager

Provides automated capabilities to issue, install, inspect,

revoke, renew, and otherwise manage TLS certificates.

Cloud IaaS

Azure

Provides computing resources, complemented by storage and

networking capabilities, hosted by a cloud service provider,

offered to customers on demand, and exposed through a GUI

and an API.

Cloud SaaS

Digicert

CertCentral,

Lookout MES,

Microsoft Azure

AD, Microsoft

Defender for

Endpoint,

Microsoft Intune,

Microsoft Office

365, Microsoft

Sentinel, and

Tenable.io,

Cloud-based software delivered for use by the enterprise.

Application

GitLab

Example enterprise resource to be protected. (In this build,

GitLab is integrated directly with Azure AD using SAML, and

Microsoft Sentinel pulls logs from GitLab.)

Application

Guacamole

Example enterprise resource to be protected. (In this build,

BIG-IP serves as an identity-aware proxy that protects access

to Guacamole, and BIG-IP is integrated with Azure AD using

SAML. Also, Microsoft Sentinel pulls logs from Guacamole.)

Enterprise-

Managed

Device

Windows client,

macOS client, and

mobile devices

(iOS and Android)

Example endpoints to be protected. (In this build, all

enterprise-managed devices are enrolled into Microsoft

Intune.)

BYOD

Windows client,

macOS client, and

mobile devices

(iOS and Android)

Example endpoints to be protected.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 135

F.2 Build Architecture

3265

In this section we present the logical architecture of E3B1 relative to how it instantiates the crawl phase

3266

EIG reference architecture depicted in Figure 4-2. We also describe E3B1’s physical architecture and

3267

present message flow diagrams for some of its processes.

3268

F.2.1 Logical Architecture

3269

Figure F-1 depicts the logical architecture of E3B1. Figure F-1 uses numbered arrows to depict the

3270

general flow of messages needed for a subject to request access to a resource and have that access

3271

request evaluated based on subject identity (both requesting user and requesting endpoint identity),

3272

authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic

3273

reauthentication of the requesting user and the requesting endpoint and periodic verification of

3274

requesting endpoint health, all of which must be performed to continually reevaluate access. The

3275

labeled steps in Figure F-1 have the same meanings as they do in Figure 4-1 and Figure 4-2. However,

3276

while Figure 4-2 depicts generic crawl phase ZTA components, Figure F-1 includes the specific products

3277

that instantiate the architecture of E3B1. Figure F-1 also does not depict any of the resource

3278

management steps found in Figure 4-1 and Figure 4-2 because the ZTA technologies deployed in E3B1

3279

do not support the ability to perform authentication and reauthentication of the resource or periodic

3280

verification of resource health.

3281

E3B1 was designed with a single ICAM system (Microsoft Azure AD) that serves as identity, access, and

3282

credential manager and also serves as the ZTA PE and PA. It includes three PEPs: Microsoft Azure AD, F5

3283

BIG-IP, and Lookout MES. A more detailed depiction of the messages that flow among components to

3284

support user access requests in the two different cases when the resource is being protected by the

3285

Azure AD PEP versus the F5 BIG-IP PEP can be found in Appendices F.2.3.1 and F.2.3.2.

3286

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 136

Figure F-1 Logical Architecture of E3B1

3287

F.2.2 Physical Architecture

3288

Section 4.4.4 describes the physical architecture of the E3B1 network.

3289

F.2.3 Message Flows for a Successful Resource Access Request

3290

This section depicts two high-level message flows, both of which support the use case in which a subject

3291

who has an enterprise ID, is located on-premises, and is authorized to access an enterprise resource,

3292

requests and receives access to that resource.

3293

The two message flows that are supported by Enterprise 3 for this use case depend on whether the

3294

resource being accessed is protected by Azure AD alone (see Appendix F.2.3.1) or by Azure AD in

3295

conjunction with the F5 BIG-IP PEP (see Appendix F.2.3.2).

3296

Regardless of which components are being used to protect the resource, all endpoints are enrolled into

3297

Microsoft Intune, which is an MDM (and a UEM) that can configure and manage devices and can also

3298

retrieve and report on device security settings that can be used to determine compliance, such as

3299

whether the device is running a firewall or anti-malware. Non-Windows devices have an MDM agent

3300

S(D). Periodic reauthentication

challenge/response and endpoint

hygiene verification

Data Plane

I(5). Session

I(1). Initial access request

(identity and credentials)

Control Plane

I(2). Info needed

to verify subject

and its endpoint

I(3). Information needed to

approve/deny access request

S(B). Information needed to

continually evaluate access

I(4).

Allow/

deny

access

S(C). Continue/revoke/limit

session access

S(A). Access

requests; info

needed to

periodically

verify subject

(both user and

endpoint)

I(N): Initial Connection

S(X): Session Management

Microsoft Azure AD

(Conditional Access)

Policy Decision

Point (PDP)

Policy Enforcement

Point(s) (PEPs)

Subject

User

Endpoint

Resource

On-Prem

Azure

Cloud

F5 BIG-IP

Supporting Components

Endpoint Security:

• Microsoft Endpoint Manager

• Microsoft Defender for

Endpoint

• Lookout MES

• PC Matic Pro

ICAM, Federated Identity, and

Identity Governance:

Microsoft AD and Azure AD

Security Analytics:

• Microsoft Sentinel

• Forescout eyeSight

• Tenable.io and Tenable.ad

• Mandiant MSV

Multi-Factor Authentication:

Azure AD

Policy Information Points

(PIPs)

Lookout MES

Microsoft Azure AD

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 137

installed on them to enable them to report compliance information to Microsoft Intune, but Windows

3301

devices do not require a separate agent because Windows has built-in agents that are designed to

3302

communicate with Intune. Intune-enrolled devices check in with Intune periodically, allowing it to

3303

authenticate the requesting endpoint, determine how the endpoint is configured, modify certain

3304

configurations, and collect much of the information it needs to determine whether the endpoint is

3305

compliant. Intune reports the device compliance information that it collects to Azure AD, which will not

3306

permit a device to access any resources unless it is compliant.

3307

For demonstration purposes, one of the criteria that devices are expected to meet to be considered

3308

compliant in our example implementation is that they must have antivirus software updated and

3309

running. In both scenarios below, some requesting endpoints have Microsoft Defender Antivirus running

3310

on them and other requesting endpoints have PC Matic Pro (also antivirus software) running; no

3311

endpoints have both turned on. If a device is running Microsoft Defender Antivirus, the Intune MDM can

3312

sense this and report it to Azure AD. If a device is running PC Matic Pro, however, the device is

3313

configured to notify Windows Security Center that the endpoint has antivirus software installed, and the

3314

Security Center provides this information to Azure AD.

3315

The authentication message flows depicted below show only the messages that are sent in response to

3316

the access request. However, the authentication process also relies on the following additional

3317

background communications that occur among components on an ongoing basis:

3318

▪ Microsoft AD periodically synchronizes with Azure AD to provide it with the most up-to-date

3319

identity information.

3320

▪ Intune-enrolled devices check in with Intune periodically. Checking in allows Intune to

3321

determine how the endpoint is configured and modify certain configurations that have been

3322

previously specified. It also allows Intune to report the compliance of the device to Azure AD.

3323

▪ Microsoft Defender for Endpoint has both a cloud component and built-in sensors that detect

3324

threat signals from Windows endpoints. So not only can it tell that a firewall is disabled or

3325

antivirus is off, but it can tell when certain malicious signals seen elsewhere have also been

3326

observed on your endpoint. It periodically reports this information to its cloud/management

3327

component, which uses it for risk determination. This information can be passed off to Intune to

3328

include in its compliance determination of an endpoint.

3329

▪ Microsoft Defender Antivirus (an endpoint agent) periodically syncs with Microsoft Intune and

3330

Microsoft Defender for Endpoint.

3331

▪ Microsoft Intune periodically sends device health information to Azure AD so that it can be sure

3332

that the device is managed and compliant.

3333

▪ PC Matic periodically syncs with Windows Security Center to inform it that that the endpoint has

3334

antivirus installed and active.

3335

▪ Windows Security Center periodically syncs with Azure AD to provide it with endpoint status

3336

information, e.g., that endpoints have antivirus installed.

3337

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 138

F.2.3.1 Use Case in which Resource Access Is Enforced by Azure AD

3338

Figure F-2 depicts the message flow for the case in which access to the resource is protected by Azure

3339

AD (with the Conditional Access feature), which acts as a PDP; and Microsoft AD, which provides identity

3340

information.

3341

Figure F-2 Use Case—E3B1 – Access Enforced by Azure AD

3342

The message flow depicted in Figure F-2 consists of the following steps:

3343

1. A user requests access to a resource.

3344

2. The resource sends the authentication request to Azure AD.

3345

3. Azure AD prompts for username and password.

3346

4. The user responds with username and password.

3347

5. Azure AD authenticates the user. Azure AD consults the information about the device that it has

3348

received in the background from Microsoft Intune and Defender for Endpoint to authenticate

3349

the device and verify that it is managed and meets compliance requirements. If the device has

3350

PC Matic running on it, Azure AD also consults information about the device that it has received

3351

in the background from Windows Security Center to verify that the device is running antivirus

3352

software.

3353

Requesting

endpoint

Endpoint

Hosting

Resource

ZTA Components

Microsoft AD

Azure AD

(Conditional Access)

Subject

PC Matic

Endpoint Suite

Microsoft Intune and

Defender for Endpoint

User

Microsoft

Defender

Lookout MES

2. Resource sends authentication request to

Azure AD

1. User requests access to resource

3. Azure AD

prompts for username

and password

4. User responds

The user access session between the endpoint and the resource is secured according to policy

5. Azure AD authenticates the user and

verifies device health/compliance

6. Azure AD challenges user for

second factor authentication

7. User provides second authentication factor

8. Azure AD sends SAML assertion

token to the resource

9. The resource accepts the SAML assertion token and grants access

Windows

Security

Center

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 139

6. Azure AD challenges the user to provide the second authentication factor.

3354

7. The user responds with the second authentication factor.

3355

8. Azure AD sends a SAML assertion to the resource.

3356

9. The resource accepts the assertion and grants the access request. User traffic to and from the

3357

resource is secured according to policy (e.g., using TLS or HTTPS).

3358

F.2.3.2 Use Case in which Resource Access Is Enforced by an F5 BIG-IP PEP

3359

Figure F-3 depicts the message flow for the case in which access to the resource is protected by F5 BIG-

3360

IP, which acts as an identity-aware proxy PEP; Microsoft Azure AD, which acts as an ICAM provider and

3361

PDP; and Microsoft AD, which provides identity information.

3362

Figure F-3 Use Case—E3B1 – Access Enforced by F5 BIG-IP

3363

The message flow depicted in Figure F-3 consists of the following steps:

3364

1. A user requests access to a resource.

3365

2. BIG-IP, which is acting as an identity-aware proxy PEP that sits in front of the resource,

3366

intercepts and forwards the request to Azure AD.

3367

3. Azure AD prompts for username and password.

3368

4. The user responds with username and password.

3369

Requesting

endpoint

Endpoint

Hosting

Resource

ZTA Components

F5 BIG-IP

Proxy/PEP

Microsoft AD

Azure AD

(Conditional Access)

Resource

Subject

PC Matic

Endpoint Suite

Microsoft Intune and

Defender for Endpoint

User

Microsoft

Defender

Lookout MES

2. BIG-IP forwards the request to Azure AD

1. User requests access to resource; BIG-IP acts as a PEP and intercepts the request

3. Aure AD prompts for username and password

4. User responds

The user access session between the endpoint and the resource is secured according to policy

5. Azure AD authenticates the user and

verifies device health/compliance

9. BIG-IP permits the access request to proceed to the resource

8. Azure AD sends a SAML assertion to BIG-IP

6. Azure AD challenges user to provide

second factor authentication

7. User provides second authentication factor

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 140

5. Azure AD authenticates the user. Azure AD consults the information about the device that it has

3370

received in the background from Microsoft Intune and Defender for Endpoint to authenticate

3371

the device and verify that it is managed and meets compliance requirements. If the device has

3372

PC Matic running on it, Azure AD also consults information about the device that it has received

3373

in the background from Windows Security Center to verify that the device is running antivirus

3374

software.

3375

6. Azure AD challenges the user to provide the second authentication factor.

3376

7. The user responds with the second authentication factor.

3377

8. Azure AD sends a SAML assertion to BIG-IP which serves as an identity-aware proxy, service

3378

provider, and the PEP protecting the resource.

3379

9. BIG-IP accepts the SAML assertion and permits the access request to proceed to the resource.

3380

User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).

3381

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 141

Appendix G EIG Enterprise 4 Build 1 (E4B1)

3382

This build will be documented in a future version of this publication.

3383

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 142

Appendix H EIG Enterprise 1 Build 2 (E1B2)

3384

H.1 Technologies

3385

EIG E1B2 uses products from Amazon Web Services, IBM, Ivanti, Mandiant, Okta, Radiant Logic,

3386

SailPoint, Tenable, and Zscaler. Certificates from DigiCert are also used. For more information on these

3387

collaborators and the products and technologies that they contributed to this project overall, see

3388

Section 3.4.

3389

E1B2 components consist of Zscaler Admin Portal, Zscaler Central Authority, Zscaler Internet Access

3390

(ZIA) Public Service Edges, Zscaler Private Access (ZPA) Public Service Edges, Okta Identity Cloud, Radiant

3391

Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Okta Verify App, Zscaler Client

3392

Connector, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable NNM, IBM Cloud Pak for Security,

3393

Mandiant Security Validation (MSV), Zscaler Application Connector, DigiCert CertCentral, and AWS IaaS.

3394

Table H-1 lists all of the technologies used in EIG E1B2. It lists the products used to instantiate each ZTA

3395

component and the security function that each component provides.

3396

Table H-1 E1B2 Products and Technologies

3397

Component

Product

Function

Zscaler ZPA

Central Authority

(CA)

Decides whether to grant, deny, or revoke access to a resource

based on enterprise policy, information from supporting

components, and a trust algorithm.

Zscaler ZPA

Admin Portal and

ZPA CA

Executes the PE’s policy decision by sending commands to a PEP

that establishes and shuts down the communication path

between subject and resource.

PEP

Zscaler Public

Service Edges

Guards the trust zone that hosts one or more enterprise

resources; establishes, monitors, and terminates the connection

between subject and resource as directed by the PA; forwards

requests to and receives commands from the PA.

Identity

Management

Okta Identity

Cloud

Creates and manages enterprise user and device accounts,

identity records, role information, and access attributes that form

the basis of access decisions within an organization to ensure the

correct subjects have the appropriate access to the correct

resources at the appropriate time.

Access &

Credential

Management

Okta Identity

Cloud

Manages access to resources by performing user and device

authentication (e.g., SSO and MFA) and using identity, role, and

access attributes to determine which access requests are

authorized.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 143

Component

Product

Function

Federated

Identity

Radiant Logic

RadiantOne

Intelligent

Identity Data

Platform

Aggregates and correlates all attributes relating to an identity or

object that is being authorized by a ZTA. It enables users of one

domain to securely access data or systems of another domain

seamlessly, and without the need for completely redundant user

administration. Federated identity encompasses the traditional

ICAM data, supports identities that may be part of a larger

federated ICAM community, and may include non-enterprise

employees.

Identity

Governance

SailPoint

IdentityIQ

Provides policy-based, centralized, automated processes to

manage user identity and access control functions (e.g., ensuring

segregation of duties, role management, logging, access reviews,

analytics, reporting) to ensure compliance with requirements and

regulations.

MFA

Okta Verify app

Supports MFA of a user identity by requiring the user to provide

not only something they know (e.g., a password), but also

something they have (e.g., a token).

UEM/MDM

Ivanti Neurons

for Unified

Endpoint

Management

(UEM) Platform

Manages and secures enterprise desktop computers, laptops,

and/or mobile devices in accordance with enterprise policy to

protect applications and data; ensure device compliance; mitigate

and remediate vulnerabilities and threats; monitor for suspicious

activity to prevent and detect intrusions; prevent, detect, and

disable malware and other malicious or unauthorized traffic;

repair infected files when possible; provide alerts and

recommend remediation actions; and encrypt data.

Pushes enterprise applications and updates to devices, enables

users to download enterprise applications that they are

authorized to access, remotely deletes all applications and data

from devices if needed, tracks user activity on devices, and

detects and addresses security issues on the device.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 144

Component

Product

Function

EPP

None

Detects and stops threats to endpoints through an integrated

suite of endpoint protection technologies including antivirus, data

encryption, intrusion prevention, EDR, and DLP. May include

mechanisms that are designed to protect applications and data;

ensure device compliance with policies regarding hardware,

firmware, software, and configuration; monitor endpoints for

vulnerabilities, suspicious activity, intrusion, infection, and

malware; block unauthorized traffic; disable malware and repair

infections; manage and administer software and updates;

monitor behavior and critical data; and enable endpoints to be

tracked, troubleshooted, and wiped, if necessary.

Endpoint

Compliance

Zscaler Client

Connector

Has capabilities to enforce policies based on a defined set of

endpoint compliance checks to allow or deny user/endpoint

access to a resource, but does not perform the functions of an

EPP solution to automatically remediate an endpoint.

SIEM

IBM Security

QRadar XDR

Collects and consolidates security information and security event

data from many sources; correlates and analyzes the data to help

detect anomalies and recognize potential threats and

vulnerabilities; and logs the data to adhere to data compliance

requirements.

Vulnerability

Scanning and

Assessment

Tenable.io and

Tenable.ad

Scans and assesses the enterprise infrastructure and resources

for security risks, identifies vulnerabilities and misconfigurations,

and provides remediation guidance regarding investigating and

prioritizing responses to incidents.

Network

Discovery

Tenable NNM

Discovers, classifies, and assesses the risk posed by devices and

users on the network.

Security

Integration

Platform

IBM Cloud Pak

for Security

Integrates the SIEM and other security tools into a single pane of

glass to support generation of insights into threats and help track,

manage, and resolve cybersecurity incidents.

Executes predefined incident response workflows to

automatically analyze information and orchestrate the operations

required to respond.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 145

Component

Product

Function

Security

Validation

Mandiant MSV

Provides visibility and evidence on the status of the security

controls’ effectiveness in the ZTA. Enables security capabilities of

the enterprise to be monitored and verified by continuously

validating and measuring the cybersecurity controls; also used to

automate the demonstrations that were performed to showcase

ZTA capabilities. Deployed throughout the project’s laboratory

environment to enable monitoring and verification of various

security aspects of the builds. VMs that are intended to operate

as actors are deployed on each of the subnetworks in each of the

enterprises. These actors can be used to initiate various actions

for the purpose of verifying that security controls are working to

support the objectives of zero trust.

Remote

Connectivity

Zscaler ZPA

Zscaler ZIA

ZPA is used to provide remote users’ connectivity to on-premises

resources. To support remote users’ connectivity to resources in

IaaS, ZPA is used for private applications and ZIA is used for

public-facing applications.

Application

Connector

Zscaler

Application

Connector

Component that is deployed to be the front-end for an internal

resource (whether located on-premises or in the cloud) and act as

a proxy for it. Requests to access the resource are directed to the

connector, which responds by initiating a secure connection to

the PEP. A connector enables access to a resource to be

controlled without requiring the resource to be visible on the

network.

Certificate

Management

DigiCert

CertCentral TLS

Manager

Provides automated capabilities to issue, install, inspect, revoke,

renew, and otherwise manage TLS certificates.

Cloud IaaS

AWS - GitLab,

WordPress

Provides computing resources, complemented by storage and

networking capabilities, hosted by a cloud service provider,

offered to customers on demand, and exposed through a GUI and

an API. An IPsec tunnel is used to provide a secure connection

from the enterprise to the cloud.

Cloud SaaS

Digicert

CertCentral,

Ivanti Neurons

for UEM, Okta

Identity Cloud,

Tenable.io,

Zscaler ZPA, and

Zscaler ZIA

Cloud-based software delivered for use by the enterprise.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 146

Component

Product

Function

Application

On-premises -

GitLab

Example enterprise resource to be protected. (In this build,

GitLab is integrated with Okta using SAML, and IBM Security

QRadar XDR pulls logs from GitLab.)

Enterprise-

Managed

Device

Mobile devices

(iOS and Android)

and

desktops/laptops

(Windows and

Mac)

Example endpoints to be protected. All enterprise-managed

mobile devices are running an Ivanti Neurons for UEM agent and

also have the Okta Verify App installed. If Ivanti Neurons for UEM

agent is used to push Zscaler Client Connector (ZCC) to the

endpoint, that endpoint is considered to be a managed device.

BYOD

Mobile devices

(iOS and Android)

and

desktops/laptops

(Windows and

Mac)

Example endpoints to be protected.

H.2 Build Architecture

3398

In this section we present the logical architecture of E1B2. We also describe E1B2’s physical architecture

3399

and present message flow diagrams for some of its processes.

3400

H.2.1 Logical Architecture

3401

Figure H-1 depicts the logical architecture of E1B2. Figure H-1 uses numbered arrows to depict the

3402

general flow of messages needed for a subject to request access to a resource and have that access

3403

request evaluated based on subject identity (both requesting user and requesting endpoint identity),

3404

user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting

3405

periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of

3406

requesting endpoint health, all of which must be performed to continually reevaluate access. The

3407

labeled steps in Figure H-1 have the same meanings as they do in Figure 4-1. However, Figure H-1

3408

includes the specific products that instantiate the architecture of E1B2. Figure H-1 also does not depict

3409

any of the resource management steps found in Figure 4-1 because the ZTA technologies deployed in

3410

E1B2 do not support the ability to perform authentication and reauthentication of the resource or

3411

periodic verification of resource health.

3412

E1B2 was designed with Zscaler components that serve as the PE, PA, and PEP, and Okta Identity Cloud

3413

that serves as the identity, access, and credential manager. Radiant Logic acts as a PIP for the PDP as it

3414

responds to inquiries and provides identity information on demand in order for Okta to make near-real-

3415

time access decisions. A more detailed depiction of the messages that flow among components to

3416

support a user access request can be found in Appendix H.2.4.

3417

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 147

Figure H-1 Logical Architecture of E1B2

3418

H.2.2 ICAM Information Architecture

3419

How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used

3420

among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture

3421

ensures that when a subject requests access to a resource, the aggregated set of identity information

3422

and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a

3423

basis on which to make the access decision.

3424

In E1B2, Okta, Radiant Logic, and SailPoint integrate with each other as well as with other components

3425

of the ZTA to support the ICAM information architecture. The ways that these components work

3426

together to correlate identity information and to support actions such as users joining, changing roles,

3427

and leaving the enterprise are the same in E1B2 as they are in E1B1. These interactions are described in

3428

Appendix D.2.2.

3429

S(D). Periodic reauthentication

challenge/response and endpoint

hygiene verification

Data Plane

I(5). Session

I(1). Initial access request

(identity and credentials)

Control Plane

I(2). Info needed

to verify subject

and its endpoint

I(3). Information needed to

approve/deny access request

S(B). Information needed to

continually evaluate access

I(4).

Allow/

deny

access

S(C). Continue/revoke/limit

session access

S(A). Access

requests; info

needed to

periodically

verify subject

(both user and

endpoint)

I(N): Initial Connection

S(X): Session Management

Policy Decision

Point (PDP)

Policy Enforcement

Point(s) (PEPs)

Subject

User

Endpoint

Resource

On-Prem

Supporting Components

Endpoint Security:

• Ivanti Neurons for UEM

• Zscaler Client Connector

ICAM: Okta Identity Cloud

Federated Identity:

Radiant Logic RadiantOne

Identity Governance:

SailPoint IdentityIQ

Security Analytics:

• IBM Security QRadar XDR

• IBM Cloud Pak for Security

• Tenable.io, Tenable.ad, and

Tenable NNM

• Mandiant MSV

Multi-Factor Authentication:

• Okta Verify App

AWS

Cloud

Policy Information Points

(PIPs)

• Zscaler Admin Portal

• Zscaler Central

Authority (CA)

• Zscaler ZPA Public

Service Edges and

• Zscaler ZIA Public

Service Edges

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 148

H.2.3 Physical Architecture

3430

Sections 4.4.1 and 4.4.2 describe and depict the physical architecture of the E1B2 headquarters network

3431

and the E1B2 branch office network, respectively. In addition to what is represented in Section 4.4, E1B2

3432

has Zscaler App Connector in the shared services VLAN.

3433

H.2.4 Message Flows for Successful Resource Access Requests

3434

Below are two high-level message flows, both of which support the use case in which a user who has an

3435

enterprise ID and who is authorized to access a resource requests and receives access to that resource.

3436

The user may be located either on-premises or at a remote location, such as a coffee shop.

3437

In both use cases depicted below, Zscaler platform components are serving as the PDP and PEPs, and

3438

Okta Identity Cloud provides a database of users, groups, permissions, and other identity and

3439

authorization information that Zscaler consumes. The Zscaler platform and Okta have a SAML federation

3440

that provides real-time synchronization of user identity information (to support user authentication) as

3441

well as a SCIM federation that provides real-time synchronization of role and group information (to

3442

support user authorization). These SAML and SCIM integrations are required because Zscaler relies on

3443

Okta to authenticate the identity of users making access requests as well as to help ensure that the user

3444

is authorized to access the requested resource.

3445

The Zscaler Central Authority (CA) is the PDP. A Zscaler Client Connector (ZCC) application is assumed to

3446

have been installed on the endpoint that the user is using to request access. The ZCC enforces policies

3447

that have been configured and applied to the device. When the user requests access to a resource, the

3448

ZCC intercepts the request and sends it to either the Zscaler Private Access (ZPA) Service Edge (PEP) or

3449

the Zscaler Internet Access (ZIA) Service Edge (PEP). Both the ZPA Service Edge and the ZIA Service Edge

3450

perform policy enforcement based on policies that the resource owner is assumed to have already

3451

configured. The choice of which PEP to send the request to depends on whether the resource being

3452

protected is an internal, private resource (e.g., an enterprise application located on the organization’s

3453

internal infrastructure--either in an on-premises data center or in the organization’s virtual private cloud

3454

(VPC) portion of a public cloud infrastructure such as AWS IaaS) or an externally-facing, public resource

3455

(e.g., a Microsoft Office 365 application located in a SaaS cloud or a web server on the internet). ZPA is

3456

used to broker access to an enterprise’s internal resources, while ZIA is used to inspect and secure traffic

3457

sent to and from externally facing and public resources.

3458

H.2.4.1 Use Case in which Access to an Internal Resource is Protected Using ZPA

3459

Figure H-2 depicts the message flow for the case in which ZPA acts as the PEP/PDP. In this use case, the

3460

resource being accessed is an internal, private resource that does not have a public-facing IP address

3461

and may be located either on-premises or in the organization’s VPC of AWS IaaS. To support this use

3462

case, domains (wildcard or exact) are configured as application segments and context-based access

3463

policies must also be configured in the ZPA Administrator Portal (Policy Administrator). ZCC, which is

3464

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 149

installed on the user’s endpoint, validates if a domain accessed is internal based on the Application

3465

Segments in the ZPA Administrator Portal. Once ZCC determines the domain is internal, the ZPA Service

3466

Edge (PEP) will use the access policies as the basis for deciding whether to broker access to the internal

3467

resource. To broker the connection between the ZPA PEP and the internal applications, a ZPA

3468

application connector must have been installed near the resource (either on-premises or in the

3469

enterprise’s VPC in the cloud) and an application segment must have been linked to that connector so

3470

that the connector that is near the resources acts as a proxy to the resource(s) on the application

3471

segment. ZCC provides a secure, authenticated interface between the endpoint and the ZPA service

3472

edge, and the ZPA Application Connector provides a secure, authenticated interface between the

3473

resource(s) and the ZPA service edge.

3474

Once the user has logged into the ZCC on his endpoint, all traffic destined for internal resources (e.g.,

3475

resources within an organization’s domain, which may be physically located either on-premises or in a

3476

VPC) will be sent to the ZPA PEP in the ZPA cloud that is closest to the user. The ZCC authenticates to the

3477

ZPA PEP and then establishes a secure tunnel to it. As a result, user endpoints never connect directly to

3478

internal resources. Instead, requests are sent to the ZPA PEP and if they are permitted by ZPA policy

3479

(i.e., if the user is authenticated, their access to the resource is authorized, and the requesting endpoint

3480

is compliant), then the ZPA PEP brokers access between the user and the application connector for the

3481

resource.

3482

Assuming the access request is permitted by policy, another secure tunnel is created between the ZPA

3483

PEP and the application connector for the resource. For security reasons, connectors do not accept

3484

inbound connections, so the connection that is established between the application connector for the

3485

resource and the ZPA PEP is outbound, from the application connector to the ZPA PEP. The ZPA PEP uses

3486

the TLS control channel (the reverse TLS tunnel) to signal the application connector to build a data

3487

tunnel from the application connector to the ZPA PEP. Then the ZPA PEP stitches together the two TLS

3488

tunnels in the cloud, enabling traffic to be exchanged securely between the user endpoint’s ZCC and the

3489

application connector. If a user connects to multiple resources that are being protected by a single

3490

application connector, there will be one TLS/DTLS tunnel created per resource.

3491

When a user requests access to an internal resource, ZCC intercepts DNS lookup queries for these

3492

domains and dynamically assigns the domains IP addresses within the 100.64.0.0/16 carrier-grade NAT

3493

subnet. Browsers and applications attempting to access the internal resource(s) will route the traffic to

3494

the IP addresses set up by ZCC. Due to this, the user accessing the resource never knows the real IP

3495

address of the resource, only the address of the temporary IP address assigned by ZCC. The user is not

3496

on the network, so connecting to the network via ZPA provides no presumption of access. The only

3497

connection that the user’s endpoint has is with the ZPA PEP. Logically, the ZPA PEP is positioned

3498

between the user endpoint connector and the resource’s connector.

3499

All traffic that is sent between a user and an internal resource must be directed through the application

3500

connector for that resource. So, for optimal performance, if an enterprise has internal resources in

3501

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 150

multiple locations (e.g., both on-premises and in a VPC on AWS), it should deploy application connectors

3502

in each location. Then it should link the respective Application Segment(s) to each location where the

3503

application exists so that the traffic sent from the user to the application can traverse an optimal path

3504

rather than having to be hairpinned through a connector that is not located close to the resource.

3505

Figure H-2 Access to an Internal Resource is Enforced by Zscaler ZPA and Okta Identity Cloud

3506

The message flow depicted in Figure H-2 consists of two parts: steps 1-6 depict the high-level message

3507

flow that occurs when a user logs into Zscaler, and steps 7-14 depict the high-level message flow that

3508

occurs when an authenticated user attempts to access an internal resource. The steps are as follows:

3509

1. The user uses the ZCC to try to log into ZPA, and the access request is received at the ZPA PEP.

3510

2. ZPA PEP provides ZCC with a SAML Request redirect to the Identity Provider.

3511

Requesting

endpoint

GitLab

ZTA Components

Resource

Connector

Internal

Resource

Subject

Okta

Identity

Cloud

User

8. ZCC intercepts request and sends

it through the client connector

to the ZPA Service Edge (PEP)

ZPA Central Authority

(CA) (PDP) and ZPA

Service Edge (PEP)

14. Throughout the course of the user s session with GitLab, the ZPA PEP is receiving traffic from the user on the TLS

tunnel that it has with the ZCC and receiving traffic from GitLab on the TLS tunnel that it has with the GitLab

connector and stitching this traffic, thereby brokering the connection between the user s endpoint and the resource.

Zscaler

Client

Connector

(ZCC)

9. ZPA consults policy to determine if the authenticated user is authorized

to access the resource. It also performs a device health check.

Okta Verify

App

3. ZCC relays SAML request to Okta

11. Send user's access request to GitLab

7.User types GitLab

URL into browser

4. Okta requests and receives login credentials and authenticates and authorizes the user

13. User logs into the GitLab application. (Not depicted in detail.) User is redirected to Okta for login

credentials. Okta authenticates user, verifies that user is authorized to access GitLab, and provides

the user with a SAML assertion for the user to send to GitLab, which then grants the user access.

10. Build a TLS tunnel from the ZCC to ZPA PEP, build

a TLS tunnel from Resource Connector to ZPA PEP,

and stitch the two tunnels together

12. request

1.User tries to log in to ZPA via ZCC

5. Okta generates a SAML assertion and sends it back to ZCC

2. The ZPA PEP provides ZCC a

SAML request redirect to

the identity provider

6. ZCC relays SAML assertion back to

ZPA PEP. User is authenticated and

is now successfully logged in and

able to use ZPA

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 151

3. The ZCC relays the SAML request to Okta, which is the enterprise’s identity provider.

3512

4. Okta requests and receives the user’s credentials (and MFA, if configured) and uses these to

3513

authenticate the user and ensure that the user is authorized to use ZPA.

3514

5. Okta generates a SAML assertion and sends it back to ZCC.

3515

6. ZCC relays the SAML assertion back to ZPA PEP. The user is authenticated and is now

3516

successfully logged in and able to use ZPA.

3517

7. A user requests to access an internal resource by typing the resource URL into their browser.

3518

8. The ZCC intercepts this request, determines if it is an internal resource, and sends it to the ZPA

3519

Service Edge (PEP) if it is. (In this use case, the resource is internal.)

3520

9. The ZPA PEP consults access policy to determine if the user is authorized to access the resource.

3521

The ZPA PEP performs a device health check to determine if the endpoint requesting access is

3522

compliant according to endpoint compliance polices that have been configured in the Zscaler CA

3523

(PDP). Information such as device OS version, patch level, anti-virus version, and whether the

3524

firewall is running has been collected from the device by the ZCC and provided to ZPA. The ZPA

3525

PEP determines if the user is authorized based on username and/or user group.

3526

10. Assuming the user is authorized, the ZPA PEP will broker access to the resource. This is

3527

accomplished by building one TLS tunnel from the ZCC to the ZPA PEP and a second TLS tunnel

3528

from the resource connector to the ZPA PEP. The ZPA PEP then stitches these two tunnels

3529

together in the Zscaler cloud.

3530

11. The ZPA PEP sends the user’s original request to access the resource to the resource connector.

3531

12. The resource connector sends the access request to the resource (GitLab).

3532

13. At this point, the user must still complete their login to the GitLab application, so they will select

3533

“login via Okta” on the GitLab login screen. The user is then redirected to an Okta screen for

3534

3535

and provides the user with a SAML assertion for the user to send to GitLab. Upon receipt of this

3536

SAML assertion, GitLab grants the user access. (These interactions with Okta are not shown in

3537

the flow diagram.)

3538

14. Once the user has logged into GitLab, the access session begins. Throughout the course of the

3539

user’s access session with GitLab, the ZPA PEP brokers the connection between the user’s

3540

endpoint and the resource. The ZPA PEP receives traffic from the user on the tunnel it has with

3541

the ZCC and stitches this traffic to the tunnel it has with the GitLab connector. Similarly, it

3542

receives traffic from GitLab on the tunnel it has with the GitLab connector and stitches this

3543

traffic to the tunnel it has with the ZCC.

3544

H.2.4.2 Use Case in which Access to an Externally-Facing Resource is Protected Using ZIA

3545

Figure H-3 depicts the message flow for the case in which the ZIA Service Edge acts as the PEP. In this

3546

use case, the resource being accessed is externally facing and would typically be located external to the

3547

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 152

enterprise—e.g., either in a SaaS cloud or on the internet. Once the user has logged into the ZCC on his

3548

endpoint, traffic from the user that is destined for external, public resources will be sent to the ZIA

3549

Service Edge (PEP) that is closest to the user. A secure TLS tunnel will be established from the ZCC to this

3550

ZIA PEP and the traffic destined for this externally facing resource will be forwarded through the tunnel

3551

so the ZIA PEP can apply enterprise policies to it.

3552

ZIA PEP is used to determine if access to the resource is permitted at all and, if so, to inspect and secure

3553

traffic sent between the requesting endpoint and this external resource. To support this use case, ZIA is

3554

typically configured with policies which permit or block access to resources. ZIA can also be configured

3555

with traffic inspection policies. The ZIA PEP can inspect all traffic sent between the user and the resource

3556

bidirectionally. For example, it can inspect traffic for malware and enforce security, firewall, and web

3557

compliance policies (e.g., it may be configured to block PDFs from being sent from the enterprise, or

3558

block documents that contain social security numbers). Based on policy, ZIA will either forward the

3559

traffic to its destination or drop it. In either case, all traffic is logged and can be reviewed by an

3560

administrator.

3561

Unlike ZPA, ZIA does not make use of connectors. The ZIA PEP is used to broker the connection between

3562

the user and an externally facing resource. ZIA access policies can be configured based on URLs, URL

3563

categories, cloud applications, user location, time, usernames, and/or groups. Providing that the

3564

requested resource is permitted based on policy, ZIA enables traffic to be sent directly from the

3565

endpoint to the resource (not via a resource connector).

3566

Figure H-3 Access to an Externally-Facing Resource is Enforced by Zscaler ZIA and Okta Identity Cloud

3567

Requesting

endpoint

GitLab

ZTA Components

Externally-

Facing

Resource

Subject

Okta

Identity

Cloud

User

2. ZCC intercepts the access request,

establishes a TLS connection with the

ZIA Service Edge (PEP) and forwards

the request to the ZIA (PEP)

ZIA Service Edge (PEP)

6. Throughout the course of the user s session with GitLab, the ZIA PEP is inspecting the traffic

being transmitted between the Zscaler client connector and GitLab

Zscaler

Client

Connector

(ZCC)

3. The ZIA PEP checks configured policies to determine

whether the access is permissible and, if so, determines

what traffic inspection may be required, if any

Okta Verify

App

4. If permitted, the ZIA PEP sends the user's access request to Gitlab

1.User types GitLab

URL into browser

5. The user logs into the GitLab application. (Not depicted in detail.) User is redirected to Okta for login

credentials. Okta authenticates user, verifies that user is authorized to access GitLab, and provides

the user with a SAML assertion for the user to send to GitLab, which then grants the user access.

A protected connection between the user's endpoint and GitLab is establised.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 153

The message flow depicted in Figure H-3 depicts the message flow for the case in which the ZIA Service

3568

Edge acts as the PEP. In this use case, the resource being accessed is externally facing and would

3569

typically be located external to the enterprise—e.g., either in a SaaS cloud or on the internet. Once the

3570

user has logged into the ZCC on his endpoint, traffic from the user that is destined for external, public

3571

resources will be sent to the ZIA Service Edge (PEP) that is closest to the user. A secure TLS tunnel will be

3572

established from the ZCC to this ZIA PEP and the traffic destined for this externally facing resource will

3573

be forwarded through the tunnel so the ZIA PEP can apply enterprise policies to it.

3574

ZIA PEP is used to determine if access to the resource is permitted at all and, if so, to inspect and secure

3575

traffic sent between the requesting endpoint and this external resource. To support this use case, ZIA is

3576

typically configured with policies which permit or block access to resources. ZIA can also be configured

3577

with traffic inspection policies. The ZIA PEP can inspect all traffic sent between the user and the resource

3578

bidirectionally. For example, it can inspect traffic for malware and enforce security, firewall, and web

3579

compliance policies (e.g., it may be configured to block PDFs from being sent from the enterprise, or

3580

block documents that contain social security numbers). Based on policy, ZIA will either forward the

3581

traffic to its destination or drop it. In either case, all traffic is logged and can be reviewed by an

3582

administrator.

3583

Unlike ZPA, ZIA does not make use of connectors. The ZIA PEP is used to broker the connection between

3584

the user and an externally facing resource. ZIA access policies can be configured based on URLs, URL

3585

categories, cloud applications, user location, time, usernames, and/or groups. Providing that the

3586

requested resource is permitted based on policy, ZIA enables traffic to be sent directly from the

3587

endpoint to the resource (not via a resource connector.

3588

Figure H-3 assumes that the user has already logged into ZCC on their endpoint. The message flow

3589

consists of the following steps:

3590

1. A user requests access to an externally facing resource (GitLab) by typing the resource URL into

3591

their browser.

3592

2. The ZCC intercepts this request, establishes a TLS connection with the ZIA Service Edge (PEP),

3593

and forwards the request to the ZIA PEP through this tunnel.

3594

3. ZIA PEP checks configured policies to determine whether the access is permissible and, if

3595

permissible, determines what traffic inspection may be required, if any.

3596

4. If permitted, ZIA PEP sends the user’s access request to the resource (GitLab)

3597

5. At this point, the user must still complete their login to the GitLab application, so they will select

3598

“login via Okta” on the GitLab login screen. The user is then redirected to an Okta screen for

3599

3600

and provides the user with a SAML assertion for the user to send to GitLab. Upon receipt of this

3601

SAML assertion, GitLab grants the user access. (These interactions with Okta are not shown in

3602

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 154

the flow diagram.) A protected connection between the user’s endpoint and GitLab is

3603

established.

3604

6. Throughout the course of the user’s access session with GitLab, the ZIA PEP can inspect the

3605

traffic being transmitted between GitLab and the user’s endpoint and either forward or drop the

3606

traffic depending upon whether the traffic conforms to the firewall, web, and other security

3607

policies that have been defined.

3608

Although ZIA is typically used to protect access to an externally facing resource that is located either in a

3609

SaaS cloud or on the internet, NCCoE demonstrated the use of ZIA to protect access to an externally

3610

facing resource that is in the NCCoE VPC of AWS IaaS. This resource, GitLab, was placed on a public

3611

subnetwork that was segmented from the private subnetwork within that VPC on which internal

3612

applications reside. Even though the resource was publicly accessible, access to GitLab was still

3613

protected by an identity provider, which in this case is Okta.

3614

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 155

Appendix I EIG Enterprise 2 Build 2 (E2B2)

3615

This build will be documented in a future version of this publication.

3616

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 156

Appendix J EIG Enterprise 3 Build 2 (E3B2)

3617

J.1 Technologies

3618

EIG E3B2 uses products from F5, Forescout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, and

3619

Tenable. Certificates from DigiCert are also used. For more information on these collaborators and the

3620

products and technologies that they contributed to this project overall, see Section 3.4.

3621

E3B2 components consist of F5 BIG-IP, Microsoft AD, Microsoft Azure AD, Microsoft Azure AD

3622

(Conditional Access), Microsoft Intune, Microsoft Defender for Endpoint, Microsoft Defender for Cloud

3623

Apps, PC Matic Pro, Microsoft Sentinel, Microsoft Azure AD Identity Protection, Tenable.io, Tenable.ad,

3624

Tenable NNM, Mandiant MSV, Forescout eyeControl, Forescout eyeExtend, Forescout eyeSight,

3625

Forescout eyeSegment, Palo Alto Networks NGFW, Microsoft Defender for Cloud, Microsoft Azure

3626

(IaaS), Microsoft Office 365 (SaaS), and DigiCert CertCentral.

3627

Table J-1 lists all of the technologies used in E3B2 ZTA. It lists the products used to instantiate each ZTA

3628

component and the security function that each component provides.

3629

Table J-1 E3B2 Products and Technologies

3630

Component

Product

Function

Microsoft Azure AD

(Conditional Access),

Microsoft Intune, Forescout

eyeControl, and

Forescout eyeExtend

Decides whether to grant, deny, or revoke access to a

resource based on enterprise policy, information from

supporting components, and a trust algorithm.

Microsoft Azure AD

(Conditional Access),

Microsoft Intune,

Forescout eyeControl, and

Forescout eyeExtend

Executes the PE’s policy decision by sending

commands to a PEP that establishes and shuts down

the communication path between subject and

resource.

PEP

Microsoft Azure AD

(Conditional Access),

Microsoft Intune,

F5 BIG-IP, and Palo Alto

Networks Next Generation

Firewall (NGFW)

Guards the trust zone that hosts one or more

enterprise resources; establishes, monitors, and

terminates the connection between subject and

resource as directed by the PA; forwards requests to

and receives commands from the PA.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 157

Component

Product

Function

Identity

Management

Microsoft AD and Azure AD

Creates and manages enterprise user and device

accounts, identity records, role information, and

access attributes that form the basis of access

decisions within an organization to ensure the correct

subjects have the appropriate access to the correct

resources at the appropriate time.

Access &

Credential

Management

Microsoft AD and Azure AD

Manages access to resources by performing user and

device authentication (e.g., SSO and MFA) and using

identity, role, and access attributes to determine

which access requests are authorized.

Federated

Identity

Microsoft AD and Azure AD

Aggregates and correlates all attributes relating to an

identity or object that is being authorized by a ZTA. It

enables users of one domain to securely access data or

systems of another domain seamlessly, and without

the need for completely redundant user

administration. Federated identity encompasses the

traditional ICAM data, supports identities that may be

part of a larger federated ICAM community, and may

include non-enterprise employees.

Identity

Governance

Microsoft AD and Azure AD

Identity Governance

Provides policy-based, centralized, automated

processes to manage user identity and access control

functions (e.g., ensuring segregation of duties, role

management, logging, access reviews, analytics,

reporting) to ensure compliance with requirements

and regulations.

MFA

Azure AD (Multifactor

Authentication)

Authenticates user identity by requiring the user to

provide not only something they know (e.g., a

password), but also something they have (e.g., a

token).

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 158

Component

Product

Function

UEM/MDM

Microsoft Intune

Manages and secures enterprise desktop computers,

laptops, and/or mobile devices in accordance with

enterprise policy to protect applications and data;

ensure device compliance; mitigate and remediate

vulnerabilities and threats; monitor for suspicious

activity to prevent and detect intrusions; prevent,

detect, and disable malware and other malicious or

unauthorized traffic; repair infected files when

possible; provide alerts and recommend remediation

actions; and encrypt data.

Pushes enterprise applications and updates to devices,

enables users to download enterprise applications

that they are authorized to access, remotely deletes all

applications and data from devices if needed, tracks

user activity on devices, and detects and addresses

security issues on the device.

EPP

Microsoft Defender for

Endpoint, Forescout

eyeSight, and PC Matic Pro

Detects and stops threats to endpoints through an

integrated suite of endpoint protection technologies

including antivirus, data encryption, intrusion

prevention, EDR, and DLP. May include mechanisms

that are designed to protect applications and data;

ensure device compliance with policies regarding

hardware, firmware, software, and configuration;

monitor endpoints for vulnerabilities, suspicious

activity, intrusion, infection, and malware; block

unauthorized traffic; disable malware and repair

infections; manage and administer software and

updates; monitor behavior and critical data; and

enable endpoints to be tracked, troubleshooted, and

wiped, if necessary.

SIEM

Microsoft Sentinel

Collects and consolidates security information and

security event data from many sources; correlates and

analyzes the data to help detect anomalies and

recognize potential threats and vulnerabilities; and

logs the data to adhere to data compliance

requirements.

Identity

Monitoring

Microsoft Azure AD Identity

Protection

Monitors the identity of subjects to detect and send

alerts for indicators that user accounts or credentials

may be compromised, or to detect sign-in risks for a

particular access session.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 159

Component

Product

Function

Vulnerability

Scanning and

Assessment

Tenable.io, and Tenable.ad

Scans and assesses the enterprise infrastructure and

resources for security risks; identifies vulnerabilities

and misconfigurations; and provides remediation

guidance regarding investigating and prioritizing

responses to incidents.

Network

Discovery

Forescout eyeSight, and

Tenable NNM

Discovers, classifies, and assesses the risk posed by

devices and users on the network.

Validation of

Control

Forescout eyeSegment

Validates the controls implemented through visibility

into network traffic and transaction flows.

Security

Validation

Mandiant MSV

Provides visibility and evidence on the status of the

security controls’ effectiveness in the ZTA. Enable

security capabilities of the enterprise to be monitored

and verified by continuously validating and measuring

the cybersecurity controls; also used to automate the

demonstrations that were performed to showcase ZTA

capabilities. Mandiant MSV is deployed throughout

the project’s laboratory environment to enable

monitoring and verification of various security aspects

of the builds. VMs that are intended to operate as

actors are deployed on each of the subnetworks in

each of the enterprises. These actors can be used to

initiate various actions for the purpose of verifying

that security controls are working to support the

objectives of zero trust.

Security

Analytics and

Access

Monitoring

Microsoft Defender for

Cloud Apps

Monitors cloud resource access sessions for

conformance to policy.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 160

Component

Product

Function

Remote

Connectivity

Azure AD Application Proxy,

Microsoft Defender for

Cloud Apps, and

Palo Alto NGFW

Palo Alto NGFW is used to provide remote users’

connectivity to on-premises resources. Also, two

options are available to support remote users’

connectivity to resources in IaaS:

• The Azure AD Application Proxy can be used to

connect directly to private applications, and

Microsoft Defender for Cloud Apps can be used to

connect to public-facing applications.

• Palo Alto NGFW can be used to reach on-premises

and then the IPsec tunnel can be used to connect

from on-premises to IaaS.

Certificate

Management

DigiCert CertCentral TLS

Manager

Provides automated capabilities to issue, install,

inspect, revoke, renew, and otherwise manage TLS

certificates.

Cloud

Workload

Protection

Microsoft Defender for

Cloud

Secures cloud workloads to protect them from known

security risks and provides alerts to enable real-time

reaction to prevent security events from developing.

Monitors traffic to and from cloud and web

applications and provides session control to prevents

sensitive information from leaving.

Cloud

Security

Posture

Management

Microsoft Defender for

Cloud

Continually assesses the security posture of cloud

resources.

Cloud IaaS

Azure – GitLab and

Wordpress

Provides computing resources, complemented by

storage and networking capabilities, hosted by a cloud

service provider, offered to customers on demand,

and exposed through a GUI and an API.

Cloud SaaS

Digicert CertCentral,

Microsoft Azure AD,

Microsoft Defender for

Endpoint, Microsoft

Defender for Cloud,

Microsoft Defender for

Cloud Apps, Microsoft

Identity Governance,

Microsoft Intune, Microsoft

Office 365, Microsoft

Sentinel, and Tenable.io

Cloud-based software delivered for use by the

enterprise.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 161

Component

Product

Function

Application

GitLab

Example enterprise resource to be protected. (In this

build, GitLab is integrated directly with Azure AD using

SAML, and Microsoft Sentinel pulls logs from GitLab.)

Application

Guacamole

Example enterprise resource to be protected. (In this

build, BIG-IP serves as an identity-aware proxy that

protects access to Guacamole, and BIG-IP is integrated

with Azure AD using SAML. Also, Microsoft Sentinel

pulls logs from Guacamole.)

Enterprise-

Managed

Device

Windows client, macOS

client, and mobile devices

(iOS and Android)

Example endpoints to be protected. (In this build, all

enterprise-managed devices are enrolled into

Microsoft Intune.)

BYOD

Windows client, macOS

client, and mobile devices

(iOS and Android)

Example endpoints to be protected.

J.2 Build Architecture

3631

In this section we present the logical architecture of E3B2. We also describe E3B2’s physical architecture

3632

and present message flow diagrams for some of its processes.

3633

J.2.1 Logical Architecture

3634

Figure J-1 depicts the logical architecture of E3B2. Figure J-1 uses numbered arrows to depict the

3635

general flow of messages needed for a subject to request access to a resource and have that access

3636

request evaluated based on subject identity (both requesting user and requesting endpoint identity),

3637

authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic

3638

reauthentication of the requesting user and the requesting endpoint and periodic verification of

3639

requesting endpoint health, all of which must be performed to continually reevaluate access. The

3640

labeled steps in Figure J-1 have the same meanings as they do in Figure 4-1. However, Figure J-1 includes

3641

the specific products that instantiate the architecture of E3B2. Figure J-1 also does not depict any of the

3642

resource management steps found in Figure 4-1 because the ZTA technologies deployed in E3B2 do not

3643

support the ability to perform authentication and reauthentication of the resource or periodic

3644

verification of resource health.

3645

E3B2 was designed with Microsoft Azure AD (Conditional Access), Microsoft Intune, Forescout eyesight,

3646

and Forescout eyeExtend as the ZTA PEs and PAs, and Microsoft AD and Azure AD providing ICAM

3647

support. It includes four PEPs: Microsoft Azure AD (Conditional Access), Microsoft Intune, F5 BIG-IP, and

3648

Palo Alto NGFW. A more detailed depiction of the messages that flow among components to support

3649

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 162

user access requests in the case in which a new endpoint is detected on the network and checked for

3650

compliance can be found in Appendix J.2.3.

3651

Figure J-1 Logical Architecture of E3B2

3652

J.2.2 Physical Architecture

3653

Section 4.4.4 describes the physical architecture of the E3B2 network.

3654

J.2.3 Message Flows for a Successful Resource Access Request

3655

The two message flows for E3B1 that are described in Appendix F.2.3 both still apply to E3B2 for cases in

3656

which the resource being accessed is located on-premises. Those message flows depict the use cases in

3657

which an on-premises resource being accessed is protected by Azure AD alone (see Appendix F.2.3.1),

3658

and in which an on-premises resource being accessed is protected by Azure AD in conjunction with the

3659

F5 BIG-IP PEP (see Appendix F.2.3.2).

3660

This section depicts three additional high-level message flows. The first two new message flows support

3661

the use case in which a user who has an enterprise ID and who is authorized to access a cloud-based

3662

resource requests and receives access to that resource. The user may be located on-premises or at a

3663

remote location, such as a coffee shop. In the first of these two new use cases, the resource accessed is

3664

S(D). Periodic reauthentication

challenge/response and

endpoint hygiene verification

Data Plane

I(5). Session

I(1). Initial access request

(identity and credentials)

Control Plane

I(2). Info needed

to verify subject

and its endpoint

I(3). Information needed to

approve/deny access request

S(B). Information needed to

continually evaluate access

I(4).

Allow/

deny

access

S(C). Continue/revoke/limit

session access

S(A). Access

requests; info

needed to

periodically

verify subject

(both user and

endpoint)

I(N): Initial Connection

S(X): Session Management

Microsoft Azure AD

(Conditional Access)

Microsoft Intune

Policy Decision

Point (PDP)

Subject

User

Endpoint

Resource

On-Prem

Azure

Cloud

F5 BIG-IP

Supporting Components

Endpoint Security:

• Microsoft Intune

• Microsoft Defender for Endpoint

• Forescout eyeSight

• PC Matic Pro

ICAM, Federated Identity, and Identity

Governance: Microsoft AD and Azure AD

MFA: Microsoft Azure AD

Policy Information Points (PIPs)

Lookout MES

Microsoft Azure AD

(Conditional Access)

Microsoft Intune

Palo Alto NGFW

Cloud Security: Microsoft Defender for Cloud

Forescout eyeControl

Forescout eyeExtend

Security Analytics:

• Microsoft Sentinel

• Microsoft Azure AD Identity Protection

• Tenable.io, Tenable.ad and Tenable NNM

• Forescout eyeSight

• Forescout eyeSegment

• Mandiant MSV

• Microsoft Defender for Cloud Apps

Policy Enforcement

Point(s) (PEPs)

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 163

an internal resource. In the second of these new use cases, the resource is externally facing. The third

3665

new message flow presented in this section depicts the use case in which a new endpoint is discovered

3666

on the network, found to be non-compliant with enterprise policy, and blocked from accessing all

3667

resources.

3668

In both of the cloud-based resource access use cases depicted below, all endpoints are enrolled into

3669

Microsoft Intune, which is an MDM that can configure and manage devices, and it can also retrieve and

3670

report on device security settings that can be used to determine compliance, such as whether the device

3671

is running a firewall or anti-malware. Non-Windows devices have an MDM Agent installed on them to

3672

enable them to report compliance information to Microsoft Intune, but Windows devices do not require

3673

a separate agent because Windows has built-in agents that are designed to communicate with Intune.

3674

Intune-enrolled devices check in with Intune periodically, allowing Intune to authenticate the requesting

3675

endpoint, determine how the endpoint is configured, modify certain configurations, and collect much of

3676

the information it needs to determine whether or not the endpoint is compliant. Intune reports the

3677

device compliance information that it collects to Azure AD, which will not permit a device to access any

3678

resources unless it meets configured access policies.

3679

One of the criteria that devices must meet to be considered compliant is that they must have anti-virus

3680

software updated and running. Some requesting endpoints have Microsoft Defender Antivirus running

3681

on them and other requesting endpoints have PC Matic Pro (also antivirus software) running; no

3682

endpoints have both turned on. If a device is running Microsoft Defender Antivirus, the Intune MDM can

3683

sense this and report it to Azure AD. If a device is running PC Matic Pro, however, the device is

3684

configured to notify Windows Security Center that the endpoint has anti-virus software installed, and

3685

the Security Center provides this information to Azure AD.

3686

The authentication message flows depicted below show only the messages that are sent in response to

3687

the access request. However, the authentication process also relies on the following additional

3688

background communications that occur among components on an ongoing basis:

3689

▪ Microsoft AD periodically synchronizes with Azure AD to provide it with the most up-to-date

3690

identity information.

3691

▪ Intune-enrolled devices check in with Intune periodically. Checking in allows Intune to

3692

determine how the endpoint is configured and modify certain configurations that have been

3693

previously specified. It also allows Intune to report the compliance of the device to Azure AD.

3694

▪ Microsoft Defender for Endpoint has both a cloud component and built-in sensors that detect

3695

threats on Windows endpoints. So not only can it tell that a firewall is off or antivirus is off, but

3696

it can tell when certain malicious signals seen elsewhere have also been observed on the

3697

endpoint. It periodically reports this information to its cloud/management component, which

3698

uses it for risk determination. This information can be passed off to Intune to include in its

3699

compliance determination of an endpoint.

3700

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 164

▪ Microsoft Defender Antivirus (an endpoint agent) periodically syncs with Microsoft Intune MDM

3701

and Microsoft Defender for Endpoint.

3702

▪ Microsoft Intune periodically sends device health information to Azure AD so that it can be sure

3703

that the device is managed and compliant.

3704

▪ PC Matic periodically syncs with Windows Security Center to inform it that the endpoint has

3705

anti-virus installed and active.

3706

▪ Windows Security Center periodically syncs with Azure AD to provide it with endpoint status

3707

information, i.e., that endpoints have anti-virus installed.

3708

J.2.3.1 Use Case in which Access to a Private Cloud Resource is Enforced by Azure AD and

3709

Azure AD’s Application Proxy

3710

Figure J-2 depicts the message flow for the use case in which Azure AD’s Application Proxy acts as the

3711

PEP and Azure AD serves as identity manager. In this use case, the resource being accessed is an

3712

internal, private resource that does not have a publicly facing IP address and may be located either on-

3713

premises at the owning organization or in a private portion of Azure IaaS or another public cloud that

3714

the organization controls. Application Proxy includes both the Application Proxy service, which runs in

3715

the cloud as part of Azure AD, and the Application Proxy connector, which is a software agent that runs

3716

on a server inside the enterprise’s network (either on-premises or in the enterprise’s private portion of

3717

the cloud) and sits in front of the application being protected to manage communication between the

3718

Application Proxy service and the application. The Application Proxy connector uses only outbound

3719

HTTPS connections, so there is no need for the enterprise to open inbound ports. The connector can

3720

also perform “Kerberos Constrained Delegation (KCD)” in the case of enterprise Kerberos apps, which

3721

means that the user authenticating to the cloud can get SSO to Kerberos apps on-premises without re-

3722

authentication. For KCD to work, the Application Proxy connector would also need to have a path to an

3723

enterprise domain controller.

3724

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 165

Figure J-2 Use Case— E3B2 – Access to an Internal Resource is Enforced by Azure AD and Azure AD’s

3725

Application Proxy

3726

Prior to the flow above, the administrator configures both the Application Proxy connector and the

3727

application. This provides the administrator with an internet-facing URL they can give users who are

3728

coming off the internet (by default it would be something like app-contoso.msappprox.net, but they can

3729

customize the DNS URL with an SSL certificate). The message flow depicted in Figure J-2 consists of the

3730

following steps:

3731

1. A user requests to access an internal resource in the cloud by typing in the external URL

3732

provided by the App Proxy service for that resource. This access request is directed to the

3733

Microsoft AD sign-in page.

3734

2. Azure AD prompts the user for credentials (e.g., username + password, certificate auth, FIDO2

3735

keys).

3736

3. The user responds with credentials.

3737

Requesting

endpoint

ZTA Components

Azure AD

Application

Proxy

Service

Azure AD

(Conditional

Access)

Internal

Resource

Subject

PC Matic

Endpoint Suite

Microsoft

Endpoint

Manager and

Defender for

Endpoint

User

Microsoft

Defender

Lookout

MES

1. User requests access to the resource and

is directed to the Azure AD sign-in page

2. Azure AD prompts for

username and password

3. User responds

5. Azure AD sends OAuth assertion

token to the endpoint and

redirects the user acces request

to the Application Proxy service

6. Endpoint sends token to

the Application Proxy service

Azure AD

Application

Proxy

Connector

Cloud-

Hosted

Application

8. Connector

sends request

to application

and user is

granted access

10. Connector tunnels content to the

Application Proxy Service

Windows

Security

Center

Microsoft

4. Azure AD authenticates the user, possibly challenging

the user for second factor authentication if required by

policy, and verifies device health/compliance

7. Application Proxy service retrieves user

principal name and security principal name

from the token and sends the request to

the Application Proxy connector

All traffic exchanged between the user and the resource on the access session flows through the connector

9.Response is

sent to

connector

11. Application Proxy Service serves the content

back to the user endpoint and browser

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 166

4. If required by policy, Azure AD also prompts the user for second-factor authentication. Azure AD

3738

Conditional Access can enforce these additional controls (e.g., MFA, device trust, user risk).

3739

Azure AD consults the information about the device that it has received in the background from

3740

Microsoft Intune and Defender for Endpoint to authenticate the device and verify that it is

3741

managed and meets compliance requirements. If the device has PC Matic running on it, Azure

3742

AD also consults information about the device that it has received in the background from

3743

Windows Security Center to verify that the device is running anti-virus software.

3744

5. Azure AD sends an OAuth token to the user’s browser to return to the App Proxy service (SAML

3745

can also be configured) and redirects the user access request to Azure AD Application Proxy

3746

Service.

3747

6. The endpoint sends the access request and OAuth token to Azure AD Application Proxy Service.

3748

7. The Application Proxy service retrieves the user principal name and security principal name from

3749

the token and sends the request to the Application Proxy connector. If KCD was configured (see

3750

above), the Proxy Connector reaches out to the domain controller to acquire a Kerberos ticket

3751

on behalf of the user identified in the OAuth token for the intended on-premises resource.

3752

Alternatively, the Proxy Connector can be configured to inject authentication headers if the

3753

application on-premises requests headers. (This KCD-related step is not depicted in the figure

3754

because it was not configured in the NCCoE demonstration.)

3755

8. The Application Proxy connector sends the request to the resource (optionally with a Kerberos

3756

ticket or headers) and the resource grants the user access.

3757

9. The resource returns content to the Application Proxy connector.

3758

10. The Application Proxy connector tunnels the content to the App Proxy service.

3759

11. The Application Proxy Service serves the content back to the user’s end point and browser.

3760

Once the access session is established, all traffic exchanged between the user and the resource flows

3761

through the Application Proxy connector.

3762

J.2.3.2 Use Case in which Access to an Externally Facing Cloud Resource is Enforced by

3763

Azure AD and Monitored by Microsoft Defender for Cloud Apps

3764

Figure J-3 depicts the message flow for the case in which access to the resource is protected by Azure

3765

AD (with the Conditional Access feature), which acts as a PDP; Microsoft AD, which provides identity

3766

information, and Microsoft Defender for Cloud Apps, which monitors cloud resource access sessions for

3767

conformance to policy. In this use case, the resource being accessed is externally facing, meaning that it

3768

has a publicly reachable IP address. Even though the application is externally facing, because the

3769

application is in the part of the cloud that is under the organization’s control (i.e., configured for SSO

3770

with the organization’s Identity Provider through SAML or OAuth), it is still protected by the

3771

organization’s identity provider, Azure AD, which requires the user to authenticate and then verifies that

3772

the user is authorized to access the resource and that the resource is compliant before granting access.

3773

Once the access session has been established, Microsoft Defender for Cloud Apps monitors all traffic

3774

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 167

that is exchanged between the user and the resource (see here for a detailed flow explanation).

3775

Microsoft Defender for Cloud Apps is therefore able to provide user behavior analytics functionality and

3776

prevent harmful or malicious actions within the resource. For example, it can block download of

3777

corporate data onto unmanaged devices, or block upload of data onto cloud storage services that

3778

contains PII or credit card numbers.

3779

Figure J-3 Use Case— E3B2 – Access to an Externally-Facing Resource is Enforced by Azure AD and

3780

Microsoft Defender for Cloud Apps

3781

The message flow depicted in Figure J-3 consists of the following steps:

3782

1. A user requests to access an externally facing, cloud-hosted resource, e.g., a SaaS application

3783

that has a publicly reachable IP address. For example, app.saas.com.

3784

2. The resource sends the authentication request to Azure AD.

3785

Requesting

endpoint

ZTA Components

Microsoft

Azure AD

(Conditional

Access)

Externally-

Facing

Resource

Subject

PC Matic

Endpoint Suite

Microsoft

Endpoint

Manager and

Defender for

Endpoint

User

Microsoft

Defender

Lookout

MES

2. Resource sends authentication request to

Azure AD

1. User requests access to resource

3. Azure AD prompts for

username and password

4. User responds

Microsoft Defender for Cloud Apps inline proxy inspects all traffic exchanged on the access session for conformance to policy

5. Azure AD authenticates the user and

verifies device health/compliance

6. Azure AD challenges user for

second factor authentication

7. User provides second authentication factor

8. Azure AD sends SAML assertion

token to the endpoint and redirects

the user access request to a

uniquely-generated URL

that is run by Microsoft Defender

for Cloud Apps inline proxy

9. Endpoint sends request and SAML assertion token to the uniquely-generated

URL that is run by Microsoft Defender for Cloud Apps inline proxy

Microsoft

Defender for

Cloud Apps

Cloud-

Hosted

Application

10. Forward request

and SAML

assertion and user

is granted access

Windows

Security

Center

11. Receive and

parse response

12. Microsoft Defender for Cloud Apps streams content back to the user's

endpoint, first rewriting any URLs as necessary.

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 168

3. Azure AD prompts for credentials.

3786

4. The user responds with credentials.

3787

5. Azure AD authenticates the user. Azure AD consults the information about the device that it has

3788

received in the background from Microsoft Intune and Defender for Endpoint to authenticate

3789

the device and verify that it is managed and meets compliance requirements. If the device has

3790

PC Matic running on it, Azure AD also consults information about the device that it has received

3791

in the background from Windows Security Center to verify that the device is running anti-virus

3792

software.

3793

6. Azure AD challenges the user to provide the second authentication factor or any other controls.

3794

7. The user responds with the second authentication factor.

3795

8. Azure AD sends a SAML assertion token back to the user’s browser/endpoint but does not

3796

redirect the user to the resource’s original redirect URL configured in the SAML setup (e.g.,

3797

app.saas.com/saml) and instead redirects the user to a uniquely generated URL that is run by

3798

Microsoft Defender for Cloud Apps inline proxy (e.g., app.saml.com.cas.com).

3799

9. The endpoint sends the access request and SAML assertion to Microsoft Defender for Cloud

3800

Apps’ generated URL.

3801

10. The Microsoft Defender for Cloud Apps inline proxy forwards the request and SAML assertion to

3802

the resource’s original URL.

3803

11. Microsoft Defender for Cloud Apps receives and parses the response.

3804

12. Before streaming the content back to the user’s endpoint, Microsoft Defender for Cloud Apps

3805

re-writes any saas.com URLs to be saas.com.cas.com URLs.

3806

The user receives the resulting content from the SaaS app and as they click on any link in the page, they

3807

submit their requests back to the Defender for Cloud Apps-generated URL. Defender for Cloud Apps

3808

inspects the action and the payload and enforces any DLP or other policies configured. If the action is

3809

allowed, Defender for Cloud Apps passes the request on to app.saas.com and, once again, rewrites the

3810

URLs of the response before delivery back to the user.

3811

In this manner, for the remainder of the access session, Microsoft Defender for Cloud Apps inline proxy

3812

monitors all traffic that is exchanged between the requesting endpoint and the resource endpoint to

3813

ensure that is permitted according to enterprise policy. For example, it can inspect the traffic that is sent

3814

to and from the cloud for PII or other prohibited content. Microsoft Defender for Cloud Apps inline

3815

proxy is integrated with Azure AD Conditional Access, enabling Azure AD to apply its controls to

3816

Microsoft Defender for Cloud Apps-governed applications. Furthermore, Defender for Cloud Apps can

3817

discover users and endpoints accessing resources, understand and report the risk posture of resources,

3818

and identify malicious activity either targeting or sourced from resources, as well as apply DLP policies

3819

that mitigate the risk of malicious data exfiltration.

3820

SECOND PRELIMINARY DRAFT

NIST SP 1800-35B: Implementing a Zero Trust Architecture 169

J.2.3.3 Use Case in which a Non-Compliant Endpoint is Discovered on the Network and

3821

Blocked from Accessing Resources

3822

Figure J-4 depicts a high-level message flow that supports the use case in which Forescout discovers a

3823

non-compliant endpoint on the network and directs the Palo Alto NGFW to block traffic to and from that

3824

device.

3825

Figure J-4 Use Case—E3B2 – Forescout Discovers a Non-Compliant Endpoint on the Network and

3826

Directs the Palo Alto Firewall to Block it

3827

The message flow depicted in Figure J-4 depicts a high-level message flow that supports the use case in

3828

which Forescout discovers a non-compliant endpoint on the network and directs the Palo Alto NGFW to

3829

block traffic to and from that device.

3830

Figure J-4 consists of the following steps:

3831

1. Forescout discovers a new endpoint on the network.

3832

2. Forescout determines what other resources the endpoint is communicating with and then

3833

determines whether or not the endpoint is conformant with policy. (In this use case example,

3834

the endpoint is found to be non-conformant.)

3835

3. Forescout direct the Palo Alto NGFW to block traffic to and from this device.

3836

4. When the endpoint attempts to access a resource that is beyond the NGFW, the NGFW blocks

3837

the endpoint’s traffic.

3838

Discovered Endpoint

ZTA Components

ForeScout

(PDP)

Resource

Subject

User

1. Forescout discovers an

endpoint on the network

3. Forescout directs the PEP to block traffic from

the newly-discovered, non-conformant endpoint

2. Forescout Identifies what the endpoint is communicating

with and then determines whether or not the endpoint is

conformant with policy. In this case, the endpoint is found

to be non-conformant.

4. The endpoint's attempts to access a resource beyond the PEP are blocked

Palo Alto

NGFW

(PEP)

Application