Power Grid Identity Management addressed with NIST 1-800

NIST CYBERSECURITY PRACTICE GUIDE ENERGY
IDENTITY AND ACCESS
MANAGEMENT FOR
ELECTRIC UTILITIES
Approach, Architecture, and Security Characteristics
For CIOs, CISOs, and Security Managers
Jim McCarthy Don Faatz Harry Perper
Chris Peloquin John Wiltberger
Leah Kauffman, Editor-in-Chief
NIST SPECIAL PUBLICATION 1800-2b
DRAFT

NIST Special Publication 1800-2b
IDENTITY AND ACCESS
MANAGEMENT FOR
ELECTRIC UTILITIES
Energy
Draft
Jim McCarthy
National Cybersecurity Center of Excellence
Information Technology Laboratory
Don Faatz
Harry Perper
Chris Peloquin
John Wiltberger
The MITRE Corporation
McLean, VA
Leah Kauffman, Editor-in-Chief
Information Technology Laboratory
August 2015
U.S. Department of Commerce
Penny Pritzker, Secretary
National Institute of Standards and Technology
Willie May, Under Secretary of Commerce for Standards and Technology and Director

DRAFT
i | NIST Cybersecurity Practice Guide SP 1800-2b
DISCLAIMER
Certain commercial entities, equipment, or materials may be identified in this document in
order to describe an experimental procedure or concept adequately. Such identification is not
intended to imply recommendation or endorsement by NIST or NCCoE, nor is it intended to
imply that the entities, materials, or equipment are necessarily the best available for the
purpose.
National Institute of Standards and Technology Special Publication 1800-2b
Natl. Inst. Stand. Technol. Spec. Publ. 1800-2b, 98 pages (August 2015)
CODEN: NSPUE2
Organizations are encouraged to review all draft publications during public comment periods
and provide feedback. All publications from NIST’s National Cybersecurity Center of Excellence
are available at http://nccoe.nist.gov.
Comments on this publication may be submitted to: Energy_NCCoE@nist.gov
Public comment period: August 25, 2015 through October 23, 2015
National Institute of Standards and Technology
9600 Gudelsky Drive (Mail Stop 2002), Rockville, MD 20850
Email: Energy_NCCoE@nist.gov

DRAFT
iii | NIST Cybersecurity Practice Guide SP 1800-2b
NATIONAL CYBERSECURITY CENTER OF EXCELLENCE
The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards
and Technology (NIST) addresses businesses’ most pressing cybersecurity problems with
practical, standards-based solutions using commercially available technologies. The NCCoE
collaborates with industry, academic, and government experts to build modular, open, end-to-
end reference designs that are broadly applicable and repeatable. The center’s work results in
publically available NIST Cybersecurity Practice Guides, Special Publication Series 1800, that
provide users with the materials lists, configuration files, and other information they need to
adopt a similar approach.
To learn more about the NCCoE, visit http://nccoe.nist.gov. To learn more about NIST, visit
http://www.nist.gov.
NIST CYBERSECURITY PRACTICE GUIDES
NIST Cybersecurity Practice Guides (Special Publication Series 1800) 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 more easily with relevant standards and best practices.
The documents in this series describe example implementations of cybersecurity practices that
businesses and other organizations may voluntarily adopt. The documents in this series do not
describe regulations or mandatory practices, nor do they carry statutory authority.
ABSTRACT
To protect power generation, transmission, and distribution, energy companies need to control
physical and logical access to their resources, including buildings, equipment, information
technology, and industrial control systems. They must authenticate authorized individuals to
the devices and facilities to which they are giving access rights with a high degree of certainty.
In addition, they need to enforce access control policies (e.g., allow, deny, inquire further)
consistently, uniformly, and quickly across all of their resources. This project resulted from
direct dialogue among NCCoE staff and members of the electricity subsector, mainly from
electric power companies and those who provide equipment and/or services to them. The goal
of this project is to demonstrate a centralized, standards-based technical approach that unifies
identity and access management (IdAM) functions across operational technology (OT)
networks, physical access control systems (PACS), and information technology systems (IT).
These networks often operate independently, which can result in identity and access
information disparity, increased costs, inefficiencies, and loss of capacity and service delivery
capability. This guide describes our collaborative efforts with technology providers and electric
company stakeholders to address the security challenges energy providers face in the core
function of IdAM. It offers a technical approach to meeting the challenge, and also incorporates
a business value mind-set by identifying the strategic considerations involved in implementing
new technologies. This NIST Cybersecurity Practice Guide provides a modular, open, end-to-end

DRAFT
iv | NIST Cybersecurity Practice Guide SP 1800-2b
example solution that can be tailored and implemented by energy providers of varying sizes
and sophistication. It shows energy providers how we met the challenge using open source and
commercially available tools and technologies that are consistent with cybersecurity standards.
The use case scenario is based on a normal day-to-day business operational scenario that
provides the underlying impetus for the functionality presented in the guide. While the
reference solution was demonstrated with a certain suite of products, the guide does not
endorse these products in particular. Instead, it presents the characteristics and capabilities
that an organization’s security experts can use to identify similar standards-based products that
can be integrated quickly and cost-effectively with an energy provider’s existing tools and
infrastructure.
KEYWORDS
Cyber, physical, and operational security; cyber security; electricity subsector; energy sector;
identity and access management; information technology
Acknowledgments
The NCCoE wishes to acknowledge the special contributions of Nadya Bartol, Senior
Cybersecurity Strategist, Utilities Telecom Council; Jonathan Margulies, formerly with NCCoE
and now with Qmulos; and Victoria Pillitteri of NIST, who were instrumental in the initial
definition and development of the Identity and Access Management use case. Paul Timmel,
formerly detailed to NCCoE from the National Security Agency, helped with these stages and
also helped to get the project build started.
We gratefully acknowledge the contributions of the following individuals and organizations for
their generous contributions of expertise, time, and products.
Name Organization
Jasvir Gill AlertEnterprise
Srini Kakkera AlertEnterprise
Srinivas Adepu AlertEnterprise
Pan Kamal AlertEnterprise
Mike Dullea CA Technologies
Ted Short CA Technologies
Alan Zhu CA Technologies
Peter Romness Cisco Systems

DRAFT
v | NIST Cybersecurity Practice Guide SP 1800-2b
Lila Kee GlobalSign
Sid Desai GlobalSign
Paul Townsend Mount Airey Group (MAG)
Joe Lloyd Mount Airey Group (MAG)
Ayal Vogel Radiflow
Dario Lobozzo Radiflow
Steve Schmalz RSA
Tony Kroukamp (The SCE Group) RSA
Kala Kinyon (The SCE Group) RSA
Dave Barnard RS2 Technologies
David Bensky RS2 Technologies
Rich Gillespie (IACS Inc.) RS2 Technologies
George Wrenn Schneider Electric
Michael Pyle Schneider Electric
Bill Johnson TDi Technologies
Pam Johnson TDi Technologies
Clyde Poole TDi Technologies
Danny Vital XTec
Mari Devitte XTec
David Hellbock XTec
John Schiefer XTec

DRAFT
vi | NIST Cybersecurity Practice Guide SP 1800-2b
Table of Contents
Disclaimer.......................................................................................................................................i
National Cybersecurity Center of Excellence...............................................................................iii
NIST Cybersecurity Practice Guides.............................................................................................iii
Abstract........................................................................................................................................iii
Keywords......................................................................................................................................iv
List of Figures ..............................................................................................................................vii
List of Tables ..............................................................................................................................viii
1 Summary.......................................................................................................................... 9
1.1 The Challenge......................................................................................................... 9
1.2 The Solution......................................................................................................... 10
1.3 Risks ..................................................................................................................... 11
1.4 Benefits ................................................................................................................ 12
1.5 Technology Partners ............................................................................................ 12
1.6 Feedback.............................................................................................................. 13
2 How to Use This Guide................................................................................................... 14
3 Introduction ................................................................................................................... 15
4 Approach........................................................................................................................ 16
4.1 Audience .............................................................................................................. 16
4.2 Scope.................................................................................................................... 16
4.3 Risk Assessment and Mitigation .......................................................................... 18
4.4 Technologies ........................................................................................................ 25
5 Architecture ................................................................................................................... 29
5.1 Example Solution Description.............................................................................. 29
5.2 Example Solution Relationship to Use Case ........................................................ 36
5.3 Core Components of the Reference Architecture............................................... 37
5.4 Supporting Components of the Reference Architecture..................................... 42
5.5 Build #3 - An Alternative Core Component Build of the Example Solution......... 45
5.6 Build Implementation Description....................................................................... 46
5.7 Data...................................................................................................................... 64
5.8 Security Characteristics Related to NERC-CIP...................................................... 65
5.9 Evaluation of Security Characteristics ................................................................. 66

DRAFT
vii | NIST Cybersecurity Practice Guide SP 1800-2b
6 Functional Evaluation .................................................................................................... 79
6.1 IdAM Functional Test Plan................................................................................... 80
6.2 IdAM Use Case Requirements ............................................................................. 81
6.3 Test Case: IdAM-1................................................................................................ 83
6.4 Test Case IdAM-2 ................................................................................................. 86
6.5 Test Case IdAM-3 ................................................................................................. 88
Appendix A: Acronyms............................................................................................................... 91
Appendix B: References............................................................................................................. 92
Appendix C: Mount Airey Group, Inc. Personal Profile Applications Demonstration Application94
Search Results: ....................................................................................................................... 96
LIST OF FIGURES
Figure 1. IdAM capabilities.................................................................................................................. 29
Figure 2. IdAM example solution........................................................................................................ 31
Figure 3. Notional PACS architecture.................................................................................................. 34
Figure 4. Notional OT silo architecture ............................................................................................... 35
Figure 5. Notional IT silo architecture................................................................................................. 36
Figure 6. Build #1 ................................................................................................................................ 38
Figure 7. Build #2 ................................................................................................................................ 40
Figure 8. Supporting components....................................................................................................... 44
Figure 9. Build #3 ................................................................................................................................ 45
Figure 10. Management and production networks............................................................................ 50
Figure 11. IdAM build architecture production network.................................................................... 51
Figure 12. OT network......................................................................................................................... 53
Figure 13. IT network .......................................................................................................................... 54
Figure 14. PACS network..................................................................................................................... 55
Figure 15. Central IdAM network, Build #1......................................................................................... 56
Figure 16. Central IdAM network, Build #2......................................................................................... 58

DRAFT
viii | NIST Cybersecurity Practice Guide SP 1800-2b
Figure 17. Access and authorization information flow for OT ICS/SCADA devices............................. 60
Figure 18. Access and authorization information flow for the PACS network, Build #1..................... 62
Figure 19. Access and authorization information flow for the PACS network, Build #2..................... 63
Figure 20. Access and authorization information flow for the IT network......................................... 64
Figure 21. Example process for determining the security standards-based attributes for the
example solution........................................................................................................................... 70
LIST OF TABLES
Table 1. Use Case Security Characteristics Mapped to Relevant Standards and Controls.................. 21
Table 2. Products and Technologies Used to Satisfy Security Control Requirements ........................ 25
Table 3. Build Architecture Component List ....................................................................................... 47
Table 4. NERC-CIP Requirements ........................................................................................................ 65
Table 5. IdAM Components and Security Capability Mapping ........................................................... 68
Table 6. Test Case Fields...................................................................................................................... 80
Table 7. IdAM Functional Requirements............................................................................................. 81
Table 8. Test Case ID: IdAM-1.............................................................................................................. 83
Table 9. Test Case ID: IdAM-2.............................................................................................................. 86
Table 10. Test Case ID: IdAM-3............................................................................................................ 88

DRAFT
9 | NIST Cybersecurity Practice Guide SP 1800-2b
1 SUMMARY1
When the National Cybersecurity Center of Excellence (NCCoE) met with electricity subsector2
stakeholders, they told us they need a more secure and efficient way to protect access to3
networked devices and facilities. The NCCoE developed an example solution to this problem4
using commercially available products.5
The NCCoE’s approach provides a centralized access management system that reduces risk of6
disruption of service by reducing opportunities for cyberattack or human error.7
This example solution is packaged as a “How To” guide that demonstrates how to implement8
standards-based cybersecurity technologies in the real world, based on risk analysis and9
regulatory requirements. The guide helps organizations gain efficiencies in identity and access10
management, while saving them research and proof of concept costs.11
1.1 The Challenge12
The electric power industry is upgrading older, outdated infrastructure to take advantage of13
emerging technologies that will create “a platform [that] efficiently [integrates] new energy14
resources, new technologies, and new devices into the system.”1
The ever greater numbers of15
technologies, devices, and systems connected to utilities’ grid networks need protection from16
physical and cybersecurity attacks.2
17
IdAM implementations in the electricity subsector are often decentralized and controlled by18
numerous departments within an energy company. Several negative outcomes can result from19
this: an increased risk of attack and service disruption, inability to identify potential sources of a20
problem or attack, and a lack of overall traceability and accountability regarding who has access21
to both critical and noncritical assets.22
To better protect power generation, transmission, and distribution, energy companies need to23
be able to control physical and logical access to their networked resources, including buildings,24
equipment, information technology, and industrial control systems (ICS)—all of which have25
unique technical and political challenges.3
Identity and access management (IdAM) systems for26
these assets often exist in silos, and employees who manage access to these systems lack27
methods to effectively coordinate access to devices and facilities in these silos. This drives28
inefficiency and creates security risks, according to our electric utility stakeholders.29
We considered a scenario in which a utility technician has access to several physical substations30
and remote terminal units connected to the company’s network in those substations. Personal31
1
Thought Leaders Speak Out: The Evolving Electric Power Industry, The Edison Foundation Institute, June 2015.
2
State of the Electric Utility 2015, Utility Dive, January 2015.
3
Protect Critical Infrastructure, McAfee, 2012.

DRAFT
matters require the technician to move out of the region, so she terminates her employment at32
the company. Without a centralized IdAM system, managing routine events like this one can33
become cumbersome and time-consuming. How can energy companies be confident that34
access to the appropriate physical and technological resources across the enterprise is granted35
or revoked correctly, and in a timely fashion?36
As this scenario shows, energy companies need to be able to authenticate the individuals and37
systems to which they are giving access rights with a high degree of certainty. In addition,38
energy companies need to be able to enforce access control policies (e.g., allow, deny, inquire39
further) consistently, uniformly and quickly across resources.40
1.2 The Solution41
The example solution we propose demonstrates the following capabilities:42
• centrally assigns and provisions access privileges to users based on a set of programmed43
business rules for IT, OT, and physical resources44
• creates, activates, and deactivates users for IT, OT, and physical resources45
• provides a view of all user accounts within the enterprise and the access rights they have46
been granted47
• can change an existing user’s access to one or more resources48
We accomplished this solution through deployment of a single centralized IdAM platform that49
implements:50
• an IdAM workflow to manage the overall process and to require explicit approval of51
requests to access certain resources52
• an identity store, which is the authoritative source for digital identities and their53
associated access rights to resources54
• a provisioning capability to populate information from the workflow and identity store55
into the run-time capabilities56
These combined capabilities can greatly reduce the time to update access to IT, OT, and57
physical resources. They reduce opportunities for attack or error and lower the impact of58
identity and access incidents on energy delivery, thereby lowering overall business risk. They59
also improve a company’s security posture by integrating all the IdAM-related audit logs into60
one, greatly improving visibility into authentication and authorization activities. Another benefit61
of this example solution is that it supports use of multiple digital identities by a single person. A62
current employee is likely to have several distinct digital identities because of independent63
management of digital identities across IT, OT, and physical resources.64
The guide:65
• maps security characteristics to guidance and best practices from standards66
organizations, including the North American Electric Reliability Corporation’s (NERC)67

DRAFT
Critical Infrastructure Protection (CIP) standards and NIST SP 800-53, Rev.4, ” Security68
and Privacy Controls for Federal Information Systems and Organizations ”69
• provides a70
o detailed example solution and capabilities that address security controls71
o demonstrated approach using multiple products to achieve the same result72
o how-to for implementers and security engineers with instructions on how the73
example solution can be integrated and configured into their enterprises in a74
manner that achieves security goals, with minimum impact on operational75
efficiency and expense76
Commercial, standards-based products, like the ones we used, are readily available and77
interoperable with existing information technology infrastructure and investments. While our78
simulated environment may be most similar in breadth and diversity to the widely distributed79
networks of large organizations, this guide is modular and provides guidance on80
implementation of unified IdAM capabilities to organizations of all sizes. These include, but are81
not limited to, corporate and regional business offices, power generation plants, and82
substations.83
This guide lists all the necessary components and provides installation, configuration, and84
integration information so that an energy company can replicate what we have built. While we85
have used a suite of commercial products to address this challenge, this guide does not endorse86
these particular products. Your utility’s security experts should identify the standards-based87
products that will best integrate with your existing tools and IT system infrastructure. Your88
company can adopt this solution or one that adheres to these guidelines in whole, or you can89
use this guide as a starting point for tailoring and implementing parts of a solution.90
1.3 Risks91
While risk is addressed in current industry standards, such as NERC CIP, our sector partners told92
us about additional risk considerations at both the operational and strategic levels.93
Operationally, a lack of a centralized IdAM platform can increase the risk of people gaining94
unauthorized access to critical infrastructure components. Once unauthorized access is gained,95
the risk surface increases and the opportunity for introduction of additional threats to the96
environment, such as malware and denial of service (especially oriented towards OT) is97
realized.98
At the strategic level, you might consider the cost of mitigating these risks and the potential99
return on your investment in implementing a product (or multiple products). You may also100
want to assess if a centralized IdAM system can help enhance the productivity of employees101
and speed delivery of services, and explore if it can help support oversight of resources,102
including information technology, personnel, and data. This example solution addresses103
imminent operational security risks and incorporates strategic risk considerations, too.104

DRAFT
Adopting any new technology can introduce new risks to your enterprise. We understand that105
this example solution to mitigate the risks of decentralized IdAM may, in turn, introduce new106
risks. By centralizing IdAM functions, we decrease the risk that multiple IdAM platforms can be107
infiltrated to gain unauthorized access to networked devices. We recognize, however, that108
centralizing IdAM functions may provide a point of single infiltration of multiple critical systems109
(OT, PACS, and IT). We address this key risk in detail in Section 5.9.5.1 Threats, Vulnerabilities110
and Assumptions, and provide a comprehensive list of mitigations in Section 5.9.6, Security111
Recommendations.112
1.4 Benefits113
The example solution described in this guide has the following benefits:114
• products and capabilities can be adopted on a component-by-component basis, or as a115
whole116
• minimizes impact to the enterprise and existing infrastructure117
• reduces opportunities for attack or error, and impact of identity and access incidents on118
energy delivery, thereby lowering overall business risk119
• allows rapid provisioning and de-provisioning of access from a centralized platform, so IT120
personnel can spend more time on other critical tasks121
• improves situational awareness: proper access and authorization can be confirmed via122
the use of a single, centralized solution123
• improves security posture by tracking and auditing access requests and other IdAM124
activity across all networks125
1.5 Technology Partners126
The technology vendors who participated in this build submitted their capabilities in response127
to a notice in the Federal Register. Companies with relevant products were invited to sign a128
Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to129
participate in a consortium to build this example solution. We worked with:130
• AlertEnterprise131
• CA Technologies132
• Cisco Systems, Inc.133
• GlobalSign134
• Mount Airey Group135
• RS2 Technologies136
• RSA Security, LLC137
• RADiFlow138

DRAFT
• Schneider Electric139
• TDi Technologies140
• XTec, Inc.141
1.6 Feedback142
You can improve this guide by contributing feedback. As you review and adopt this solution for143
your own organization, we ask you and your colleagues to share your experience and advice144
with us.145
• email energy_nccoe@nist.gov146
• participate in our forums at http://nccoe.nist.gov/forums/energy147
Or learn more by arranging a demonstration of this example solution by contacting us at148
energy_nccoe@nist.gov.149
150

DRAFT
2 HOW TO USE THIS GUIDE151
This NIST Cybersecurity Practice Guide demonstrates a standards-based example solution and152
provides users with the information they need to replicate this approach to identity and access153
management. The example solution is modular and can be deployed in whole or in part.154
This guide contains three volumes:155
• NIST SP 1800-2a: Executive Summary156
• NIST SP 1800-2b: Approach, Architecture, and157
Security Characteristics – what we built and why158
• NIST SP 1800-2c: How To Guides – instructions for building the example solution159
Depending on your role in your organization, you might use this guide in different ways:160
Energy utility leaders, including chief security and technology officers will be interested in the161
Executive Summary (NIST SP 1800-2a), which describes the:162
• challenges electricity subsector organizations face in implementing and using IdAM163
systems164
• example solution built at the NCCoE165
• benefits of adopting a secure, centralized IdAM system, and the risks of isolated,166
decentralized systems167
Technology or security program managers who are concerned with how to identify,168
understand, assess, and mitigate risk, will be interested in this part of the guide, NIST SP1800-169
2b, which describes what we did and why. The following sections will be of particular interest:170
• Section 4.3, Risk Assessment and Mitigation, provides a detailed description of two171
types of risk analysis we performed172
• Table 1, Use Case Security Characteristics Mapped to Relevant Standards and Controls, in173
Section 4.3, Risk Assessment and Mitigation, maps the security characteristics of this174
example solution to cybersecurity standards and best practices, including NERC-CIP v.3175
and v.5176
IT professionals who want to implement an approach this like this will find the whole practice177
guide useful. You can use the How-To portion of the guide, NIST Special Publication Series 1800-178
2c, to replicate all or parts of the build created in our lab. The How-To guide provides specific179
product installation, configuration, and integration instructions for implementing the example180
solution. We do not recreate the product manufacturers’ documentation, which is widely181
available. Rather, we show how we incorporated the products together in our environment to182
create an example solution.183
This guide assumes that IT professionals have experience implementing security products in184
energy industry organizations. While we have used a suite of commercial products to address185
YOU ARE HERE

DRAFT
this challenge, this guide does not endorse these particular products.4
Your organization’s186
security experts should identify the standards-based products that will best integrate with your187
existing tools and IT system infrastructure. Your organization can adopt this solution or one that188
adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring189
and implementing parts of a solution for operational technology systems (OT), physical access190
control systems (PACS), and IT systems (IT). If you use other products, we hope you will seek191
those that are congruent with applicable standards and best practices.192
A NIST Cybersecurity Practice Guide does not describe “the” solution, but a possible solution.193
This is a draft guide. We seek feedback on its contents and welcome your input. Comments,194
suggestions, and success stories will improve subsequent versions of this guide. Please195
contribute your thoughts to energy_nccoe@nist.gov, and join the discussion at196
http://nccoe.nist.gov/forums/energy.197
3 INTRODUCTION198
The NCCoE initiated this project because IT security leaders in the electricity subsector told us199
that IdAM was a concern to them. As we developed the original problem statement, or use200
case, on which this project is based, we consulted with electric company chief information201
officers, chief information security officers, security management personnel, and others with202
financial decision-making responsibility (particularly for security).203
The individuals we consulted told us that they need to control physical and logical access to204
their resources, including buildings, equipment, IT, and industrial control systems. They need to205
authenticate only designated individuals and devices to which they are giving access rights with206
a high degree of certainty. In addition, they need to enforce access control policies (e.g., allow,207
deny, inquire further) consistently, uniformly, and quickly across all of their resources. Current208
IdAM implementations are often not centralized and are controlled by numerous departments209
within an energy company. Several negative outcomes can result from this situation: an210
increased risk of attack and service disruption, inability to identify potential sources of a211
problem or attack, and a lack of overall traceability and accountability regarding who has access212
to both critical and noncritical assets. Another key consideration is the need for companies to213
demonstrate compliance with industry standards and/or government regulations.214
We constructed two versions of an end-to-end identity management solution that provides215
access control capabilities across the OT, PACS, and IT networks. We used the same approach216
for each build in that we only interchanged two core products that contained the same217
4
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept. Such identification is not intended to imply recommendation or endorsement
by NIST or the NCCoE, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.

DRAFT
functionality and capability. Sections 5.3.1 and 5.3.2 detail these two example solutions. The218
end result is that a user’s access to facilities and devices can be provisioned from a single219
console. Access privileges can be modified by adding new users and assigning access for the220
first time, modifying existing user access privileges, or disabling user access privileges. Our goal221
was to provide the electricity subsector with a solution that addresses the key tenet of222
cybersecurity—access management/rights—based on the principle of least privilege.5
223
4 APPROACH224
4.1 Audience225
This guide is intended for individuals responsible for implementing IT security solutions in226
electricity subsector organizations.227
4.2 Scope228
This project began with a detailed discussion between NCCoE and members of the electricity229
subsector community of their main security challenges. The risk of unauthorized access to230
facilities and devices and the inability to verify if user access had been properly established,231
modified, or revoked quickly became the focus.232
In response, the NCCoE drafted a use case that identified numerous desired solution233
characteristics. After an open call in the Federal Register, we chose technology partners on the234
basis of their ability to provide these characteristics. We initially thought it would be feasible to235
include federation of identity management6
services in the scope. As we progressed through236
the initial stages of solution development, we realized that access, authentication, and237
authorization through federated identity means would vastly increase the amount of time238
needed to complete a build. We narrowed the scope to providing identity management of239
energy company employees including a centralized provisioning capability to the OT, PACS, and240
IT networks. The scope became successful execution of the following provisioning functions:241
1. enabling access for a new employee242
2. modifying access for an existing employee243
3. disabling access for a former employee244
The objective is to perform all three actions from a single interface that can serve as the245
authoritative source for all access managed within an energy provider’s facilities, networks, and246
systems.247
5
J. Saltzer, Protection and the control of information sharing in multics, Communication of the ACM, 17 (7), 388-
402 (1974)
6
“Federated identity management (FIM) is an arrangement that can be made among multiple enterprises that lets
subscribers use the same identification data to obtain access to the networks of all enterprises in the group.”
http://searchsecurity.techtarget.com/definition/federated-identity-management

DRAFT
Assumptions4.2.1248
4.2.1.1 Security249
All network and system changes have the potential to increase the attack surface within an250
enterprise. In Section 4.3, Risk Assessment and Mitigation, we provide detailed251
recommendations on how to secure this reference solution.252
4.2.1.2 Modularity253
This example solution is made of many commercially available parts. You might swap one of the254
products we used for one that is better suited for your environment. We also assume that you255
already have some IdAM solutions in place. A combination of some of the components256
described here, or a single component, can improve your identity and access/authorization257
functions, without requiring you to remove or replace your existing infrastructure. This guide258
provides both a complete end-to-end solution and options you can implement based on your259
needs.260
4.2.1.3 Human Resources Database/Identity Vetting261
This build is based on a simulated environment. Rather than recreate a human resources (HR)262
database and the entire identity vetting process in our lab, we assumed that your organization263
has the processes, databases, and other components necessary to establish a valid identity.264
4.2.1.4 Identity Federation265
We initially intended to work with energy providers to demonstrate a means for sharing266
selected identity information across organizational boundaries. While we assumed the NCCoE267
could implement some type of identity federation mechanism to authenticate and authorize268
individuals both internal and external to the organization, this capability exceeded the scope of269
the build.270
4.2.1.5 Technical Implementation271
The guide is written from a “how-to” perspective. Its foremost purpose is to provide details on272
how to install, configure, and integrate components. We assume that an energy provider has273
the technical resources to implement all or parts of the build, or has access to companies that274
can perform the implementation on its behalf.275
4.2.1.6 Limited Scalability Testing276
We experienced a major constraint in terms of replicating the user base size that would be277
found at medium and large energy providers. We do not identify scalability thresholds in our278
builds, as those depend on the type and size of the implementation and are particular to the279
individual enterprise.280
4.2.1.7 Replication of Enterprise Network281
We were able to replicate the three silos: 1) physical access control systems, 2) information282
technology or corporate networks, and 3) the operational technology network, in a limited283

DRAFT
manner. The goal was to demonstrate both logically and physically that provisioning functions284
could be performed from a centralized IdAM system regardless of its location in the enterprise.285
In a real-world environment, the interconnections between the OT, PACS, and IT silos depend286
on the business needs and compliance requirements of the enterprise. We did not attempt to287
replicate these interconnections. Rather, we acknowledge that implementing our build or its288
components creates new interfaces across silos. We focused on providing general information289
on how to remain within the bounds of compliance should you adopt this example solution. In290
addition, we provide guidance on how to mitigate any new risks introduced to the291
environment.292
4.3 Risk Assessment and Mitigation293
We performed two types of risk assessment: the initial analysis of the risk posed to the294
electricity subsector as a whole, which led to the creation of the use case and the desired295
security characteristics, and an analysis to show users how to manage the risk to the296
components introduced by adoption of the solution.297
Assessing Risk Posture4.3.1298
According to NIST Special Publication (SP) 800-30, Risk Management Guide for Information299
Technology Systems,7
“Risk is the net negative impact of the exercise of a vulnerability,300
considering both the probability and the impact of occurrence. Risk management is the process301
of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.” The302
NCCoE recommends that any discussion of risk management, particularly at the enterprise303
level, begin with a comprehensive review of the Risk Management Framework (RMF)8
material304
available to the public.305
Using the guidance in NIST’s series of publications concerning the RMF, we performed two key306
activities to identify the most compelling risks encountered by energy providers. The first was a307
face-to-face meeting with members of the energy community to define the main security risks308
to business operations. This meeting identified a primary risk concern—the lack of centralized309
IdAM services, particularly on OT networks. We then identified the core risk area, IdAM, and310
established the core operational risks encountered daily in this area. We deemed these the311
tactical risks:312
• lack of authentication, authorization, and access control requirements for all OT in the313
electricity subsector314
• inability to manage and log authentication, authorization, and access control315
information for all OT using centralized or federated controls316
7
Guide for Conducting Risk Assessments, National Institute of Standards and Technology Special Publication 800-
30, Rev. 1, September 2012, http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf
8
National Institute of Standards and Technology (NIST), Risk Management Framework (RMF)
http://csrc.nist.gov/groups/SMA/fisma/Risk-Management-Framework/

DRAFT
• inability to centrally monitor authorized and unauthorized use of all OT and user317
accounts318
• inability to provision, modify, or revoke access throughout the enterprise (including OT)319
in a timely manner320
Our second key activity was conducting phone interviews with members of the electricity321
subsector. These interviews gave us a better understanding of the actual business risks as they322
relate to the potential cost and business value. NIST SP 800-39, Managing Information Security323
Risk,9
focuses particularly on the business aspect of risk, namely at the enterprise level. This324
foundation is essential for any further risk analysis, risk response/mitigation, and risk325
monitoring activities. Below is a summary of the strategic risks:326
• impact on service delivery327
• cost of implementation328
• budget expenditure as they relate to investment in security technologies329
• projected cost savings and operational efficiencies to be gained as a result of new330
investment in security331
• compliance with existing industry standards332
• high-quality reputation or public image333
• risk of alternative or no action334
• successful precedents335
Undertaking these activities in accordance with the NIST RMF guidance yielded the necessary336
operational and strategic risk information, which we subsequently translated to security337
characteristics. We mapped these characteristics to NIST’s SP 800-53 Rev.410
controls where338
applicable, along with other applicable industry and mainstream security standards.339
Managing IdAM Risk4.3.2340
A foundation of cybersecurity is the principle of least privilege, defined as providing the least341
amount of access (to systems) necessary for the user to complete his or her job.11
To enforce342
this principle, the access control system needs to know the appropriate privileges for each user343
and system. An analysis of the IdAM solution reveals two components that need to be344
protected from both external and internal threat actors: the central identity and authorization345
9
Security and Privacy Controls for Federal Information Systems and Organizations, National Institute of Standards
and Technology Special Publication 800-53, Rev. 4, April 2013, http://dx.doi.org/10.6028/NIST.SP.800-53r4
10
Managing Information Security Risk, National Institute of Standards and Technology Special Publication 800-39,
March 2011, http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf
11
J. Saltzer, Protection and the control of information sharing in multics, Communication of the ACM, 17 (7), 388-
402 (1974)

DRAFT
store, and the authorization workflow management system. The authorization workflow346
management system is trusted to make changes to the central identity and authorization store.347
Therefore, any inappropriate or unauthorized use of these systems could change authorization348
levels for anyone in the enterprise. If that occurred, the enterprise would experience a lack of349
integrity of the identity and authentication stores. The central identity and authorization store350
is the authoritative source for the enterprise and holds the hash for each user password, as well351
as the authorizations associated with each user. Access to this information would enable an352
unauthorized user to impersonate anyone in the organization. In this situation, the enterprise353
would lose the confidentiality of its users.12
354
To protect the build components, we implemented the following requirements in our lab355
environment: access control, data security, and protective technology. Section 5.9, Evaluation356
of Security Characteristics, provides a security evaluation of the example solution and a list of357
the security characteristics. Please note that we addressed only the core requirements358
appropriate for the IdAM build.359
Security Characteristics and Controls Mapping4.3.3360
As explained in Section 4.3.1, we derived the security characteristics through a risk analysis361
process conducted in collaboration with our electricity subsector stakeholders. This is a critical362
first step in acquiring or developing the capability necessary to mitigate the risks as identified363
by our stakeholders. Table 1 maps the desired security characteristics and example capabilities364
of the use case to the Framework for Improving Critical Infrastructure Cybersecurity, relevant365
NIST standards, industry standards, and controls and best practices.366
12
Section 5.9.5.1.1 describes the security controls in place to mitigate this risk.

DRAFT
Table 1. Use Case Security Characteristics Mapped to Relevant Standards and Controls367
Example Characteristic Cybersecurity Standards and Best Practices
Specific
Related and
Best Practices
Security
Characteristics
Example
Capability
CSF
Function
CSF
Category
CSF Subcategory
NIST
800-53
rev4
IEC/ISO27001
SANS
CAG20
NERC CIP
v3/513
Authentication
for OT
Authentication
mechanisms Protect
Access
Control
PR.AC-1: Identities
and credentials
are managed for
authorized devices
and users
AC-2, IA
Family
ISO/IEC
27001:2013
A.9.2.1, A.9.2.2,
A.9.2.4, A.9.3.1,
A.9.4.2, A.9.4.3
CSC 3-3,
CSC 12-
1, CSC
12-
10,CSC
16-12
CIP-003-5 R1,
CIP-004-5 R4,
CIP-004-5 R5,
CIP-005-5 R1,
CIP-005-5 R2,
CIP-007-5 R2,
CIP-007-5 R5
13
The relationship of NERC CIP requirements to the Security Characteristics is derived from a mapping between NIST 800-53 rev4 security controls and NERC
CIP requirements. It is provided for reference only. Please consult your NERC CIP compliance authority for any questions on NERC CIP compliance.

DRAFT
Specific
Related and
Best Practices
Security
Characteristics
Example
Capability
CSF
Function
CSF
Category
CSF Subcategory
NIST
800-53
rev4
IEC/ISO27001
SANS
CAG20
NERC CIP
v3/513
Access Control
for OT
Access control
mechanisms Protect
Access
Control
and
Protective
Technology
PR.AC-2: Physical
access to assets is
managed and
protected
PR.AC-3: Remote
access is managed
PR.PT-3: Access to
systems and
assets is
controlled,
incorporating the
principle of least
functionality
AC-3,
AC-17,
AC-19,
AC-20,
CM-7,
PE-2,
PE-3,
PE-4,
PE5, PE-
6, PE-9
ISO/IEC
27001:2013
A.6.2.2, A.9.1.2A,
11.1.1,A.11.1.2,
A.11.1.4, A.11.1.6,
A.11.2.3, A.13.1.1,
A.13.2.1
CSC 3-3,
CSC 12-
1, CSC
12-10,
CSC 16-
4, CSC
16-12
CIP-003-5 R1,
CIP-004-5 R2,
CIP-004-5 R4,
CIP-004-5 R5,
CIP-005-5 R1,
CIP-005-5 R2,
CIP-006-5 R1,
CIP-006-5 R2,
CIP-007-5 R1,
Authorization
(provisioning)
OT
Access policy
management
mechanisms Protect
Access
Control
PR.AC-4 Access
Permissions are
managed,
incorporating
principles of least
privilege and
separation of
duties.
AC-2,
AC-3,
AC-5,
AC-6,
AC-16
ISO/IEC
27001:2013
A.6.1.2, A.9.1.2,
A.9.2.3, A.9.4.1,
A.9.4.4
CSC 3-3,
CSC 12-
1, CSC
12-10,
CSC 16-
4, CSC
16-12
CIP-003-5 R1,
CIP-004-5 R4,
CIP-004-5 R5,
CIP-005-5 R1,
CIP-005-5 R2,
CIP-006-5 R1,
CIP-007-5 R5

DRAFT
Specific
Related and
Best Practices
Security
Characteristics
Example
Capability
CSF
Function
CSF
Category
CSF Subcategory
NIST
800-53
rev4
IEC/ISO27001
SANS
CAG20
NERC CIP
v3/513
Centrally
monitor use of
accounts
Log account
activity
Detect,
Protect
Continuous
Monitoring
&
Protective
Technology
DE.CM-3:
Personnel activity
is monitored to
detect potential
cybersecurity
events
PR.PT-1: Audit/log
records are
determined,
documented,
implemented…
AC-2,
AU-12,
AU-13,
CA-7,
CM-10,
CM-11
AU
family
ISO/IEC
27001:2013
A.12.4.1, A.12.4.2,
A.12.4.3, A.12.4.4,
A.12.7.1
CSC 4-
2,CSC
12-1,
CSC 12-
10, CSC
14-2,
CSC 14-
3,
CIP-003-5 R1,
CIP-004-5 R4,
CIP-004-5 R5,
CIP-005-5 R1,
CIP-005-5 R2,
CIP-006-5 R1,
CIP-006-5 R2
CIP-007-5 R4,
CIP-007-5 R5,
CIP-008-5 R2,
CIP-010-5 R1,
CIP-011-5 R2
Protect
exchange of
identity and
access
information Encryption Protect
Data
Security
PR.DS-1: Data-at-
rest is protected
PR.DS-2: Data-in-
transit is
protected
SC-8, SC-
28
ISO/IEC
27001:2013 A.8.2,
A.13.1.1, A.13.2.1,
A.13.2.3, A.14.1.2,
A.14.1.3
CSC 16-
16, CSC
17-7 CIP-011-5 R1

DRAFT
Specific
Related and
Best Practices
Security
Characteristics
Example
Capability
CSF
Function
CSF
Category
CSF Subcategory
NIST
800-53
rev4
IEC/ISO27001
SANS
CAG20
NERC CIP
v3/513
Provision,
modify or
revoke access
throughout all
federated
entities
Mechanisms for
centrally
managed
provisioning of
access Protect
Access
Control
PR.AC-1: Identities
and credentials
are managed for
authorized devices
and users
PR.AC-4 : Access
permissions are
managed,
incorporating the
principles of least
privilege and
separation of
duties
AC-2,
AC-3,
AC-5,
AC-6,
AC-16,
IA
Family
ISO/IEC
27001:2013
A.6.1.2, A.9.1.2,
A.9.2.1, A.9.2.2,
A.9.2.3, A.9.2.4,
A.9.3.1, A.9.4.1,
A.9.4.2, A.9.4.3
,A.9.4.4
CSC 3-3,
CSC 12-
1, CSC
12-10,
CSC 16-
4, CSC
16-12
CIP-003-5 R1,
CIP-004-5 R4,
CIP-004-5 R5,
CIP-005-5 R1,
CIP-005-5 R2,
CIP-006-5 R1,
CIP-007-5 R4,
CIP-007-5 R5

DRAFT
368
4.4 Technologies369
Table 2 provides information about the products and technologies that we implemented in order to satisfy the security control370
requirements.14
371
Table 2. Products and Technologies Used to Satisfy Security Control Requirements372
Security
Characteristics
Example
Capability
CSF
Subcategory
Application Company Product Version Use
Authentication
for OT
Authentication
mechanisms
PR.AC-1:
Identities and
credentials are
managed for
authorized
devices and
users
Identity
Management
Platform
CA
Identity
Manager
R12.0
SP14 Build
9140
Implements workflows for
creating digital identities
and authorizing them
access to physical and
logical resources, including
authoritative source
RSA
IMG15
Governance
Lifecycle
6.9.74968
Implements workflows for
creating digital identities
and authorizing them
access to physical and
logical resources.
Provision,
modify or
revoke access
throughout all
Mechanisms for
centrally
managed
provisioning of
Virtual Directory
Adaptive
Directory
7.1.5
R29692
Authoritative source for
digital identities and
authorized access to
resources.
14
This table describes only the product capabilities used in our builds. Many of the products have significant additional security capabilities that were not used
in our builds. The product column of the table contains links to vendor product information that describes the full capabilities.
15
RSA IMG is now known as RSA VIA Governance and RSA VIA Lifecycle

DRAFT
Security
Characteristics
Example
Capability
CSF
Subcategory
federated
entities
access
Credential
Management
GlobalSign Enterprise PKI N/A
Provides NAESB-compliant
X.509 certificates to OT
personnel.
Credential
Management /
Physical Access
Control
XTec
Credential
Issuance
Solutions
N/A
Provides PIV-I smartcard
credentials and physical
access control capability
using the smartcard.
Access Control
for OT
Access control
mechanisms
PR.AC-2:
Physical access
to assets is
managed and
protected
Credential
Management /
Physical Access
Control
XTec
Physical
Access Control
Logical Access
Control
Authentication
and Validation
N/A
Provides PIV-I smartcard
credentials and physical
access control capability
using the smartcard.
Physical Access
Control
Enforcement
RS2
Technologies
AccessIT! 4.1.15
Controls physical access to
power facilities, buildings,
etc.
Authorization
(provisioning)
OT
Access policy
management
mechanisms
PR.AC-4: Access
permissions are
managed,
incorporating
the principles
of least
privilege and
separation of
duties
Provisioning AlertEnterprise Guardian
4.0 SP04
HF3
Provisions access
authorizations from the
IdAM workflow to Access It
Universal
Provision,
modify or
revoke access
throughout all
federated
entities
Mechanisms for
centrally
managed
provisioning of
access

DRAFT
Security
Characteristics
Example
Capability
CSF
Subcategory
Authorization
(provisioning)
OT
Access policy
management
mechanisms
Identity
Management
Platform
CA
Identity
Manager
R12.0
SP14 Build
9140
Provisions identities and
authorizations to Active
Directory.
Provision,
modify or
revoke access
throughout all
federated
entities
Mechanisms for
centrally
managed
provisioning of
access
RSA IMG16
6.9.74968
Secure Attribute
Management
Mount Airey
Group
Ozone Console
and Ozone
Authority
Secure
Attribute
Management
Public Key
Enablement
Ozone Mobile
Ozone
Authority
4.0.1,
Ozone
Server
2.1.301,
Ozone
Envoy
4.1.0,
Ozone
Console
2.0.2
Manages attributes that
control access to high-
value transactions.
Centrally
monitor use of
accounts
Log account
activity
PR.PT-1:
Audit/log
records are
determined,
documented,
implemented,
and reviewed
in accordance
with policy
Industrial
Control System
(ICS) User
Access
Management
TDi
Technologies
Console Works 4.9-0u0
Controls access to
industrial control system
(ICS) devices by people (ICS
engineers and technicians).
16
RSA IMG is now known as RSA VIA Governance and RSA VIA Lifecycle

DRAFT
Security
Characteristics
Example
Capability
CSF
Subcategory
Access Control
for OT
Access control
mechanisms
PR.PT-3: Access
to systems and
assets is
controlled,
incorporating
the principle of
least
functionality
Industrial
Control System
(ICS) User
Access
Management
TDi
Technologies
Console Works 4.9-0u0
Creates an audit trail of
access to ICS devices by
people.
ICS Device-to-
Device Access
Management
Radiflow
Industrial
Control
System
Firewall and
iSIM Software
OT Security
Substation
Security
iSIM
3.6.07
Controls communication
among ICS devices.
Access Gateway Cisco
Identity
Service Engine
(ISE)
1.4.0.253
Controls access to
resources in OT by users in
IT based on both user
identity and device
identity.
Access Gateway
Schneider
Electric
ConneXium
Tofino
Ethernet
Firewall
2.10
Controls access to devices
in the ICS/SCADA network

DRAFT
5 ARCHITECTURE373
5.1 Example Solution Description374
IdAM is the discipline of managing the relationship between a person and the resources the375
person needs to access to perform a job. It encompasses the processes and technologies by376
which individuals are identified, vetted, credentialed, and authorized access to and held377
accountable for their use of resources. These processes and technologies create digital identity378
representations of people, bind those identities to credentials, and use those credentials to379
control access to resources. IdAM is composed of the capabilities illustrated in Figure 1.380
381
382
Figure 1. IdAM capabilities383
1. User registration determines that a reason exists to give a person access to resources,384
verifies the person’s identity, and creates one or more digital identities for the person.385
2. Credential issuance and management17
provides life-cycle management of credentials386
such as employee badges or digital certificates.387
3. Access rights management determines the resources a digital identity is allowed to use.388
4. Provisioning populates digital identity, credential, and access rights information for use389
in authentication, access control, and audit.390
5. Authentication establishes confidence in a person’s digital identity.391
6. Access control18
allows or denies a digital identity access to a resource.392
7. Audit maintains a record of resource access attempts by a digital identity.393
The top three capabilities are administrative capabilities in that they involve human actions or394
are used infrequently. For example, verifying identity typically involves physically reviewing395
documents such as a driver’s license or passport. Credential issuance and management is396
17
NIST SP 800-63-2, Electronic Authentication Guideline, provides additional information on credential issuance
and management, as well as authentication.
18
NIST IR 7316, Assessment of Access Control Systems, explains commonly used access control policies, models,
and mechanisms.

DRAFT
invoked when an employee is hired, changes jobs, leaves the company, loses a credential, or397
when a credential expires.398
The bottom three capabilities are “run-time” capabilities in that they happen whenever a399
person accesses a resource. Authentication, access control, and audit are typically automated400
activities that occur every time a person enters a facility using a badge, or logs into a computer401
system. A directory, such as Microsoft Active Directory (AD), is often used in the402
implementation of run-time functions.403
Provisioning is the “glue” that connects the administrative activities to the run-time activities by404
providing the run-time capabilities with the information needed from the administrative405
activities.406
In the electricity subsector today, all of these IdAM capabilities are frequently replicated at407
least three times—once for a person’s access to OT, again for access to PACS, and then to408
access IT. Additionally, these capabilities may be independently replicated for each system409
within OT or IT. This replication makes it difficult to ensure that employees have access to the410
resources they need to perform their jobs, and only those resources. Newly hired employees411
may not have access to all the resources they need. Employees who change jobs may retain412
access to resources they no longer need. Terminated employees may retain access long after413
they have left. Further, multiple, independent IdAM processes make it difficult to periodically414
review who has access to what resources.415
The example solution described here addresses these problems by centralizing some of the416
administrative capabilities into a core IdAM capability used across OT, PACS, and IT, while417
leaving the run-time capabilities replicated and distributed. Figure 2 illustrates the example418
solution.419

DRAFT
420
Figure 2. IdAM example solution421
The centralized IdAM capability implements:422
• an IdAM workflow to manage the overall process423
• an identity store, which is the authoritative source for digital identities and their424
associated access rights to resources425
• a provisioning capability to populate information from the workflow and identity store426
into the run-time capabilities427
The combined capabilities can reduce the time to update access in the OT, PACS, and IT systems428
from days to minutes. They also improve the audit trail capture by integrating the three audit429
logs into one. Provisioning may also verify that authorizations stored locally in the run-time430
capabilities are consistent with those in the identity store. If locally stored authorizations are431
inconsistent with authoritative values in the identity store, provisioning may raise an alarm or432
change locally stored authorizations to be consistent with the identity store.433
The example solution implements three basic transactions:434
• creating all required credentials, authorizing access, and provisioning access for a new435
employee436
• updating credentials and access for an existing employee who is changing jobs or437
requires a temporary access change438

DRAFT
• destroying credentials and removing accesses for a terminated employee439
The IdAM workflow receives information about employees and their jobs from the HR system.440
For a new employee, HR is responsible for performing initial identity verification. Based on a441
new employee’s assigned job, the IdAM workflow creates one or more digital identities and442
determines the credentials and resource accesses required. The workflow triggers credential443
management capabilities to create physical identification badges, physical access cards, and any444
logical access credentials such as X.509 public key certificates that may be needed. The445
workflow records information about these credentials in the identity store.446
The example solution does not assume that each person will have a single digital identity. A447
current employee is likely to have several distinct digital identities because of independent448
management of digital identities in physical security, business systems, and operational449
systems. Requiring a single digital identity would create a significant challenge to adoption of450
the example solution.451
Instead, the identity store associates all of an employee’s digital identifiers so all of that452
person’s accesses can be managed together. Once the example solution is in place, an453
organization can continue issuing multiple digital identifiers to new employees or can assign a454
single digital identifier that is common to physical security, business systems, and operational455
systems.456
The workflow automatically authorizes some physical and logical accesses that either are457
needed by all employees or for an employee’s job. The workflow stores information about458
credentials and authorized accesses in the identity store. The workflow can then invoke459
provisioning to populate run-time functions with credential information and access460
authorizations. This allows the employee to access facilities and systems.461
Access to some resources, both logical and physical, will require explicit approval before being462
authorized. For these, the workflow notifies one or more access approvers for each such463
resource and waits for responses. When the workflow receives approvals, it stores the464
authorized accesses in the identity store and provisions them to the run-time functions. All465
information about approved, pending,19
and provisioned physical and logical access466
authorizations is maintained in the identity store.467
When the HR system notifies the workflow that an employee is changing jobs, the workflow468
performs similar actions. First, it identifies resource accesses and credentials associated only469
with the employee’s former job. It revokes those resource accesses in the identity store and de-470
provisions them from the run-time functions. It directs that associated credentials be471
invalidated and destroyed. It removes information about those credentials from the identity472
19
Pending access authorizations may be either authorizations that have been approved but not yet provisioned or
time-bounded authorizations to be provisioned/deprovisioned at a future time.

DRAFT
store and de-provisions credential information from the run-time functions.20
It then identifies473
resource accesses needed for the employee’s new job, authorizes them in the identity store,474
and provisions them to the run-time functions. The workflow identifies any new credentials475
that will be needed in the new job, triggers creation and issuance of those credentials, waits for476
them to be created, updates the identity store, and provisions new credential information to477
the run-time functions.478
When the HR system notifies the workflow that an employee has been terminated, the479
workflow removes all the employee’s resource accesses from the identity store and de-480
provisions them from the run-time functions. It triggers invalidation and destruction of the481
employee’s credentials, removes credential information from the identity store, and de-482
provisions credential information from the run-time functions.483
In addition to input from the HR system to process personnel actions, the workflow can provide484
a portal for employees to request access to resources, which can be reviewed and approved.485
Also, systems other than HR can be integrated with the workflow to initiate resource access486
requests. These capabilities reduce overhead and administrative downtime.487
The Physical Access Control System Silo5.1.1488
The PACS silo hosts both access control and badging systems. The badging systems implement a489
credential issuance capability that creates the badges employees use to gain access to facilities490
and other physical resources. The access control systems read information from badges and491
check authorization information provided by the centralized IdAM capability to determine if a492
person should be allowed access. If access is allowed, the access control system unlocks a door,493
allowing the person to enter the facility.494
Figure 3 shows the architecture of the PACS silo.495
20
Workflow actions are programmable and can be customized to meet organization-specific needs.

DRAFT
An instance of Microsoft Active Directory contains identities and access control information for496
the people who operate the badging systems and the people who manage the access control497
systems. This access control information is provisioned into the PACS Active Directory instance498
from the centralized IdAM system.499
The PACS Active Directory instance may also store authorized physical access information used500
by the access control systems. If the access control systems are integrated with Active501
Directory, then the IdAM system will provision authorization information to PACS Active502
Directory. If the access control systems are not integrated with Active Directory, then503
authorization information will be provisioned directly to the access control system.21
504
5.1.2 The Operational Technology Silo505
The OT silo is composed of two types of systems—operational management systems that506
operators and engineers use to monitor and manage the generation and delivery electric507
energy to customers, and industrial control systems (ICSs) and supervisory control and data508
acquisition (SCADA) systems that provide real-time and near real-time control of the equipment509
that produces and delivers electric energy.510
Figure 4 shows the notional architecture of the OT silo.511
21
Build #1 provisions directly to the access control system. Build #2 provisions to the PACS AD.
Figure 3. Notional PACS architecture

DRAFT
512
513
Figure 4. Notional OT silo architecture514
The operations and management network within the OT silo has an Active Directory instance515
that contains identities and access authorizations for operational management systems. These516
identities and authorizations are provisioned from the centralized IdAM system. A cross-silo517
access control capability allows some access to operational management systems from the IT518
silo. The centralized IdAM system provisions authorizations to access OT resources from the IT519
silo into the OT Active Directory.520
An electronic access control and monitoring system (EACMS) controls access to ICS/SCADA521
devices on the ICS/SCADA network from the operations management network. The EACMS522
allows operators and engineers terminal access to the programmable logic controllers (PLCs)523
and remote terminal units (RTUs) that provide real-time control of energy production and524
delivery. Authorizations allowing access via the EACMS may be provisioned into the OT Active525
Directory instance or directly into the EACMS by the centralized IdAM system. The centralized526
IdAM system can provide time-bounded authorizations that will allow access during a limited527
time period. When the period expires, a workflow is triggered that revokes the authorization in528
the identity store and de-provisions the authorization from the OT Active Directory instance.529
An ICS/SCADA firewall controls communication among ICS/SCADA devices. The centralized530
IdAM system does not currently manage or provision authorizations that control device-to-531
device communication. Authorizations for device-to-device communications are either learned532
by the firewall in training mode, or configured using a vendor-supplied application. This533
capability could be added in a future version of the centralized IdAM system.534
OT
ICS/SCADA Network
Supervisory Control and
Data Acquisition
(SCADA) System
RTU
Remote
Terminal
Unit (RTU)
RTU
Energy Management
Systems (EMS)
Operations
Management
Network
Programmable
Logic Controller
(PLC)
Human
Machine
Interface (HMI)
OT
AD
Operator
WorkstationOperator
Engineer
Workstation
Engineer
ICS Firewall
Cross-Silo Access Control
[Electronic Access Point (EAP) /
EACMS]
From IT
Electronic
Access Control
and Monitoring
System (EACMS)
Electronic Security Perimeter (ESP)

DRAFT
The Information Technology Silo5.1.3535
The IT silo hosts business systems. These systems consist of user workstations and business536
applications running on Microsoft Windows or Linux servers. An IT Active Directory instance537
contains identities and access authorizations for both business system users and system538
administrators who manage the applications and servers. These authorizations are provisioned539
from the centralized IdAM system. Applications that are not integrated with Active Directory540
can be provisioned directly by the centralized IdAM system.541
Figure 5 shows the notional architecture of the IT silo.542
543
Figure 5. Notional IT silo architecture544
5.2 Example Solution Relationship to Use Case545
When we first defined this challenge22
in collaboration with industry members, we wrote the546
following scenario:547
“An energy company technician attempts to enter a substation. She is challenged to prove her548
identity in a way that provides a high degree of confidence and is not onerous (i.e., does not549
require a significant behavior change). Her attempt at entry initiates an authentication request550
that, if possible, connects to the company’s authentication and authorization services to551
validate her identity, ensure that she is authorized to access the substation, and confirm that a552
work order is on file for that substation and that worker at that time.553
Once she gains access to the substation, she focuses on the reason for her visit: She needs to554
diagnose a remote terminal unit (RTU) that has lost its network connectivity. She identifies the555
cause of the failure as a frayed Ethernet cable and replaces the cable with a spare. She then556
22
http://nccoe.nist.gov/sites/default/files/nccoe/NCCoE_ES_Identity_Access_Management.pdf

DRAFT
uses her company-issued mobile device, along with the same electronic credential she used for557
physical access, to log into the RTU’s Web interface to test connectivity. The RTU queries the558
central authentication service to ensure the authenticity and authority of both the technician559
and her device, then logs the login attempt, the successful authentication, and the commands560
the technician sends during her session.”561
The first portion of the scenario deals with physical access to a substation. Unlike the562
description in this scenario, the example solution provides centralized management of563
identities and authorizations, but assumes the decision to allow a particular technician access564
to a particular facility at a particular time may be distributed. Distributing the access decision-565
making capability helps ensure that access control continues to function in the event of566
communication failures. Utilities have indicated that communication failures with substations567
are common. Therefore, authorization to allow the technician access to the substation will be568
created centrally by the IdAM workflow, placed in the identity store, and then provisioned to569
the PACS responsible for the substation. Accomplishing this requires integrating the work order570
management system with the IdAM workflow. Assigning the technician a work order that571
requires access to a substation triggers actions within the IdAM workflow to authorize access to572
the substation and provision that authorization to the substation PACS. When the technician573
presents her physical access credential at the substation, the PACS uses the provisioned574
authorization to determine if she should be allowed access. Likewise, while not explicitly stated575
in the example, completion of the work order triggers the IdAM workflow to remove the576
technician’s substation access authorization and de-provision it from the substation PACS.577
The second portion of the scenario deals with logical access to ICS/SCADA devices within the578
substation. Again, unlike the description in the scenario, the example solution centralizes579
management of identities and authorizations but assumes that run-time functions such as580
authenticating a user and granting her access to specific ICS/SCADA devices are distributed581
functions. In this case, the example solution assumes that the substation contains an EACMS to582
which the technician connects her mobile device. The EACMS authenticates the technician and583
controls her access to ICS/SCADA devices within the substation. Assigning the technician to this584
work order triggers an IdAM workflow that authorizes her access to ICS/SCADA devices in the585
substation, stores these authorizations in the identity store, and provisions both the586
authorizations and any needed authentication credentials to the substation’s EACMS.587
Completion of the work order triggers removal of the access authorization and de-provisioning588
of authorizations and credentials from the substation EACMS.589
5.3 Core Components of the Reference Architecture590
To verify the modularity of the example solution and to demonstrate alternative provisioning591
methods, we created two builds of the centralized IdAM capability. Both builds used the592
following products:593
• AlertEnterprise Guardian implements provisioning to an RS2 Technologies (RS2)594
AccessIT! Physical Access Control System (PACS).595

DRAFT
• TDi Technologies ConsoleWorks and a Schneider Electric Tofino firewall serve as an596
EACMS.597
• A RADiFlow ICS/SCADA firewall controls interactions between two Modbus-speaking598
RTUs—a Schweitzer Engineering Laboratories (SEL) RTU and an RTU emulated by a599
Raspberry Pi single-board computer.600
Build #1 used CA Technologies (CA) Identity Manager to implement the IdAM workflow and601
aspects of provisioning, and CA Directory to implement the identity store. Build #2 used the RSA602
Identity Management and Governance (IMG) [now known as RSA VIA Governance and RSA VIA603
Lifecycle] to implement the IdAM workflow and the RSA Adaptive Directory to implement the604
identity store and aspects of provisioning.605
Build #15.3.1606
Figure 6 illustrates Build #1.607
608
609
Figure 6. Build #1610
CA Identity Manager implements the IdAM workflow. It receives input from an HR system in the611
form of comma-separated value (.csv) files. We simulated the HR system using manually612
produced .csv files. Identity Manager also provisions information to Microsoft Active Directory613

DRAFT
instances in business systems (IT), and the operational system (OT). No relationship among614
these Active Directory instances is assumed.615
IT applications are assumed to be integrated with Active Directory and use credential616
information and authorization information in the IT Active Directory instance. If there are IT617
applications that are not integrated with Active Directory, the provisioning capabilities of CA618
Identity Manager would be used to directly provision the applications.619
AlertEnterprise Guardian23
provisions physical access authorizations into the RS2 PACS. CA620
Identity Minder supports call-outs within a workflow that can be used to invoke external621
programs. A call-out is used to connect with AlertEnterprise Guardian and provide information622
to be provisioned to the RS2 PACS.623
An instance of TDi Technologies ConsoleWorks is installed in the OT silo and integrated with the624
OT Active Directory instance. Identity Manager provisions ICS/SCADA access authorizations in625
the OT Active Directory instance. ConsoleWorks uses the access authorizations in OT Active626
Directory to control user access to ICS/SCADA devices. Console Works also captures an audit627
trail of all user access to the ICS/SCADA network.628
A Schneider Electric Tofino firewall is installed between Console Works and the ICS/SCADA629
network. The firewall determines which IP addresses within the ICS/SCADA network are630
accessible through ConsoleWorks and which network protocols can be used when accessing631
those addresses. The combination of Console Works and the Tofino firewall implement an632
Electronic Access Control and Monitoring System (EACMS) between the Energy Management633
System / Operations Management Network and the ICS/SCADA network.634
Build #25.3.2635
Figure 7 illustrates Build #2.636
23
Guardian is also capable of implementing workflow and provisioning ICS devices. However, those capabilities
were not used in this build.

DRAFT
637
638
RSA IMG implements the IdAM workflow. It receives input from an HR system in the form of640
.csv files. RSA IMG also has the capability to provision information to systems. In Build #2, RSA641
IMG stores information in RSA Adaptive Directory, which subsequently provisions the642
information to its associated Active Directory instances.643
RSA Adaptive Directory implements the identity store and provisioning portions of the example644
solution. RSA Adaptive Directory is a virtual directory that acts as a proxy in front of multiple645
back-end directories. The build assumes that each silo—OT, PACS, and IT—hosts a Microsoft646
Active Directory instance. No relationship among these Active Directory instances is assumed.647
When an IMG workflow stores information in Adaptive Directory, that information is actually648
stored in one or more of the underlying Active Directory instances. In this way, storing649
information in Adaptive Directory provisions that information into one or more Active Directory650
instances.651

DRAFT
AlertEnterprise Guardian provisions physical access authorizations into the RS2 PACS. RSA IMG652
writes these authorizations into Adaptive Directory, which stores them in the PACS Active653
Directory instance. AlertEnterprise Guardian monitors the Active Directory PACS instance for654
updates such as changed physical access authorizations for an existing user, addition of a new655
user with physical access authorizations, or removal of an existing user and associated access656
authorizations. When changes are detected, Guardian provisions them into the RS2 PACS.657
As in Build #1, TDi Technologies ConsoleWorks and a Schneider Electric Tofino firewall are used658
is used in the OT silo to provide an EACMS between the EMS/Operations Management Network659
and the ICS/SCADA network. ConsoleWorks utilizes the OT Active Directory for authorization of660
users in this build as well.661
Implementation of the Use Case Illustrative Scenario5.3.3662
This section explains how each of the two builds implements the scenario in Section 5.2663
A work order management system assigns a technician to resolve an issue with an RTU at a664
substation. The system initiates a workflow in either CA Identity Manager or RSA IMG that665
authorizes the technician physical access to the substation. In Build #1, this authorization is sent666
to AlertEnterprise Guardian via a call-out in the workflow in CA Identity Manager. Guardian667
provisions the authorization into the RS2 PACS. The authorization is also stored in the CA668
directory. In Build #2, this authorization is written to Adaptive Directory and stored in the PACS669
Active Directory instance. AlertEnterprise Guardian detects the authorization change for the670
technician and provisions it to RS2. When the technician arrives at the substation and scans her671
credentials at the door, RS2 allows her entry.672
The workflow also authorizes access to ICS/SCADA devices in the substation. In Build #1,673
Identity Manger stores this authorization in the CA directory and provisions it to the OT Active674
Directory instance. In Build #2, IMG writes this authorization to Adaptive Directory, which675
stores it in the OT Active Directory instance. When the technician connects her mobile device to676
ConsoleWorks in the substation, she is authenticated, and ConsoleWorks checks the OT Active677
Directory instance, sees that she is authorized, and allows her to access the ICS/SCADA devices678
in the substation.679
When the work order is closed, the work order management system triggers another workflow680
that removes the technician’s access authorizations. In Build #1, the authorizations are681
removed from the CA directory. Substation physical access is de-provisioned from RS2 via a call-682
out from the workflow to AlertEnterprise Guardian. Identity Manager de-provisions ICS/SCADA683
access from the OT Active Directory. ConsoleWorks detects the change in the OT Active684
Directory instance and de-provisions the technician’s access to the RTU.685
In Build #2, IMG removes the authorizations from Adaptive Directory. This removes the686
authorizations from the PACS and OT Active Directory instances. AlertEnterprise Guardian687
detects the change in the PACS Active Directory instance and de-provisions the technician’s688
substation physical access. ConsoleWorks detects the change in the OT Active Directory689
instance and de-provisions the technician’s access to the RTU.690

DRAFT
Without an active assigned work order, the technician has no physical or logical access to the691
substation.24
692
5.4 Supporting Components of the Reference Architecture693
In addition to the products used to build an instance of the core example solution (the build),694
several products provide supporting components to the build as show in Figure 8. These695
products implement IdAM capabilities that, while necessary to completely implement IdAM696
within an organization, are not an integral part of the centralized IdAM capability.697
XTec AuthentX and GlobalSign demonstrate outsourcing some credential issuance and698
management capabilities. XTec AuthentX also demonstrates outsourcing of some physical699
access control capabilities.700
XTec AuthentX Identity and Credential Management System25
provides a personal identity701
verification interoperable (PIV-I) smartcard credential based on NIST standards that can be used702
for logical and physical access. AuthentX demonstrates outsourcing of some aspects of user703
registration, credential issuance and management, authentication, and access control704
capabilities. These capabilities are provided using a cloud-hosted solution with identity vetting705
workflows, credential issuance stations, and full life-cycle maintenance tools. AuthentX706
produces Homeland Security Presidential Directive 12-compliant smart cards that are707
interoperable with and trusted by federal counterparts.708
XTec demonstrates a cloud-based implementation of the XTec physical access control (PACS)709
product. The components of the XTec solution in our lab included XNode, card readers, and710
compliant PIV-I cards. The XTec product places the XNode, an IP addressable RS232/RS485711
controller within close range of the reader and door strike, as opposed to a typical central712
control panel deployment. The XNode can also control SCADA devices and send them713
encrypted instructions.714
AuthentX IDMS/CMS can also provide a Web-based implementation of the IdAM workflow in715
the example solution, as well as credential management and provisioning. AuthentX IDMS/CMS716
can control, log, and account for identity vetting, credential issuance, and credential usage with717
AuthentX PACS and logical access controls, as well as control credential revocation to all718
interoperable resources immediately.719
24
The reference architecture requires substations to have power and communications to receive provisioned
authorizations. The reference architecture does not address crisis / emergency situations where this requirement
is not met. The reference architecture assumes existing energy company procedures for crisis / emergency
response will be used / updated to address this challenge.
25
The description of the XTec product and its role supporting the implementation of the example solution was
provided to NCCoE by XTec.

DRAFT
GlobalSign operates a North American Energy Standards Board (NAESB)-accredited Software as720
a Service Certificate Authority. It illustrates an outsourced credential issuance and management721
capability that provides NAESB-compliant X.509 digital certificates. NAESB-compliant digital722
certificates are required credentials for authenticating Open Access Same-Time Information723
Systems (OASIS) transactions and access to the Electronic Industry Registry—the central724
repository for information related to energy scheduling and management activities in North725
America.26
726
Mount Airey Group (MAG) Ozone and Cisco Identity Services Engine (ISE) demonstrate access727
control decision and enforcement capabilities that the centralized IdAM capability can728
provision. MAG Ozone can also provide authorization management capabilities.729
The MAG Ozone product provides a high-assurance attribute-based access control27
(ABAC)730
implementation. ABAC controls access to resources by evaluating access rules using attributes731
associated with the resource being accessed, the person accessing the resource, and the732
environment. Ozone Authority provides a high-assurance attribute store. Attributes stored in733
Ozone Authority are managed using Ozone Console. Ozone manages attributes that control734
access to high-value transactions such as high-dollar-value financial transactions.735
Ozone Authority pulls attributes either from Adaptive Directory in Build #2 or from an AD736
instance in Build #1. Once Ozone Authority pulls the attributes, their values are managed737
through Ozone Console.738
26
https://www.GlobalSign.com/en/digital-certificates-for-naesb/
27
NIST Special Publication 800-162, Guide to Attributed Based Access Control (ABAC) Definition and
Considerations.

DRAFT
739
Figure 8. Supporting components740
Ozone Server uses these attributes, in either the OT or IT silo, to decide if a user is allowed to741
perform a transaction. Ozone Server provides its decision to the policy enforcement point742
associated with the application.743
MAG provided an application for the IT silo to demonstrate some of Ozone’s capabilities. The744
application is described in Appendix C.28
745
Cisco ISE controls the ability of devices to connect over the network. ISE expands on basic746
network address-based control to include the identity of the person using a device. ISE is used747
in the builds to provide a gateway function between OT and IT, limiting which users and devices748
are allowed to connect from IT to resources in OT.749
28
Other than the MAG demonstration application, a full ABAC capability was not included in the architecture. A
separate NCCoE project is creating an ABAC building block that could be used in IT or OT.
http://nccoe.nist.gov/content/attribute-based-access-control

DRAFT
5.5 Build #3 - An Alternative Core Component Build of the Example Solution750
RSA, CA, and AlertEnterprise all provide products that can implement the IdAM workflow,751
identity store, and provisioning. Our initial builds of the example solution used RSA and CA752
products to implement the IdAM workflow, the identity store, and Active Directory753
provisioning. AlertEnterprise Guardian was used to provision the RS2 PACS; however, Guardian754
can also implement the IdAM workflow, identity store, and both OT and IT provisioning. To755
illustrate Guardian’s full capabilities, AlertEnterprise created this independent build of the756
example solution in their labs using the Guardian product.757
758
AlertEnterprise Guardian implements the IdAM workflow. It receives input from an HR system760
in the form of comma-separated value (.csv) files. We simulated the HR system using manually761
produced .csv files. Guardian provisions information to Microsoft Active Directory instances in762
OT and IT. No relationship among these Active Directory instances is assumed.763
IT applications are assumed to be integrated with Active Directory and use credential764
information and authorization information in the IT Active Directory instance. If there are IT765

DRAFT
applications that are not integrated with Active Directory, the provisioning capabilities of766
Guardian would be used to directly provision the applications.767
Guardian provisions physical access authorizations into the RS2 PACS. Physical Access and768
Cardholder life cycle functions are supported through Guardian workflow to ensure right level769
of access is granted to the right people based on training, compliance and security770
requirements.771
An instance of TDi Technologies ConsoleWorks and a Schneider Electric Tofino firewall are772
installed in the OT silo to implement an EACMS between the EMS/Operations Management773
network and the ICS/SCADA network. ConsoleWorks is integrated with the OT Active Directory774
instance. Guardian provisions ICS/SCADA access authorizations in the OT Active Directory775
instance. ConsoleWorks uses the access authorizations in OT Active Directory to control user776
access to ICS/SCADA devices.777
Additional information about Build #3 is available from the AlertEnterprise Web site at778
http://www.alertenterprise.com/resources-standards-nistcoe.php .779
5.6 Build Implementation Description780
The infrastructure was built on Dell model PowerEdge R620 server hardware. The server781
operating system was VMware vSphere virtualization operating environment. In addition, we782
used a 6-terabyte Dell EqualLogic network attached storage (NAS) product, and Dell model783
PowerConnect 7024, and Cisco 3650 physical switches to interconnect the server hardware,784
external network components, and the NAS.785
The NCCoE built two instantiations of the example solution to illustrate the modularity of the786
technologies. Build #1 uses the CA Technologies Identity Manager product. Build #2 uses the787
RSA Identity Management and Governance (IMG) [now known as RSA VIA Governance and RSA788
VIA Lifecycle] and RSA Adaptive Directory products.789
The lab network is connected to the public Internet via a virtual private network (VPN)790
appliance and firewall to enable secure Internet and remote access. The lab network is not791
connected to the NIST enterprise network. Table 3 lists the software and hardware components792
we used in the build, as well the specific function each component contributes.793
794

DRAFT
Table 3. Build Architecture Component List795
Product Vendor Component Name Function
Dell PowerEdge R620 Physical server hardware
Dell PowerConnect 7024 Physical network switch
Dell EqualLogic Network attached storage
VMware vSphere vCenter Server
version 5.5
Virtual server and
workstation environment
Microsoft Windows Server 2012 r2
Active Directory Server
Authentication and authority
Microsoft Windows 7 Information management
Windows Windows Server 2012 r2
DNS Server
Domain name system
Windows SQL Server Database
AlertEnterprise Enterprise Guardian Interface and translation
between IdAM central store
and the PACS management
server
CA Technologies Identity Manager
Rel 12.6.05 Build 06109.28
Identity and access
automation management
application, IdAM
provisioning
Cisco ISE Network Server 3415 Network access controller
Cisco Catalyst Model 3650 TrustSec-enabled physical
network switch
GlobalSign Digital Certificates Cloud certificate authority
Mount Airey Group Ozone Authority Central attribute
management system
Mount Airey Group Ozone Console Ozone administrative
management console

DRAFT
Product Vendor Component Name Function
Mount Airey Group Ozone Envoy Enterprise identity store
interface
Mount Airey Group Ozone Server Ozone centralized attribute
based authorization server
RADiFlow (iSIM) Industrial Service
Management Tool
Supervisory control and data
acquisition (SCADA) router
management application
RADiFlow SCADA Router
RF-3180S
Router/firewall for SCADA
network
RSA Adaptive Directory
Version 7.1.5
Central identity store, IdAM
provisioning
RSA IMG
Version 6.9
Build 74968
Central IdAM system
(workflow management)
TDi Technologies ConsoleWorks Privileged user access
controller, monitor, and
logging system
RS2 Technologies AccessIT! Universal
Release 4.1.15
Physical access control
components
Configures and monitors the
PACS devices (e.g., card
readers, keypads, etc.)
Schweitzer Electronics
Laboratory
SEL-2411 Programmable automation
controller
Schneider Electric Tofino Firewall model
number TCSEFEA23F3F20
Industrial Ethernet firewall
XTEC XNode Remote access control and
management
796
Build Architecture Components Overview5.6.1797
The build architecture consists of multiple networks that mirror the infrastructure of a typical798
energy industry corporation. The networks are a management network and a production799

DRAFT
network (Figure 10). The management network was implemented to facilitate the800
implementation, configuration, and management of the underlying infrastructure, including the801
physical servers, vSphere infrastructure, and monitoring. The production network, Figure 11802
consists of:803
• the demilitarized zone (DMZ)804
• IdAM805
• OT—ICS/SCADA industrial control system and energy management system (EMS)806
• PACS—physical access control system network807
• IT—business management systems808
These networks were implemented separately to match a typical electricity subsector809
enterprise infrastructure. Firewalls block all traffic except required internetwork810
communications. The primary internetwork communications are the user access and811
authorization updates from the central IdAM systems between the directories and OT, PACS,812
and IT networks.813
814

DRAFT
815
Figure 10. Management and production networks816

DRAFT
817
818
Figure 11. IdAM build architecture production network819
The IdAM network represents the proposed centralized/converged IdAM network/system. This820
network was separated into OT, PACS, and IT to highlight the unique IdAM components821
proposed to address the use case requirements.822
The IT network represents the business management network that typically supports corporate823
email, file sharing, printing, and Internet access for general business-purpose computing and824
communications.825
The OT network represents the network used to support the EMSs and ICS/SCADA systems.826
Typically, this network is either not connected to the enterprise IT network or is connected with827
a data diode (a one-way communication device from the OT network to the IT network). Two-828
way traffic is allowed per NERC-CIP and is enabled via the OT firewall only for specific ports and829
protocols between specific systems identified by IP address.830
The PACS network represents the network that supports the physical access control systems831
across the enterprise. Typically, this network uses the enterprise IT network and is segmented832
from the user networks by virtual local area networks (VLANs). In our architecture, a firewall833

DRAFT
allows limited access to and from the PACS network to facilitate the communication of access834
and authorization information. Technically, this communication consists of user role and835
responsibility directory updates originating in the IdAM system.836
Build Network Components5.6.2837
Internet – The public Internet is accessible by the lab environment to facilitate both cloud838
services and access for vendors and NCCoE administrators.839
VPN Firewall – The VPN firewall is the access control point for vendors to support the840
installation and configuration of their components of the architecture. We used this access to841
facilitate product training and implementation support. This firewall also blocks unauthorized842
traffic from the public Internet to the production networks. We used additional firewalls to843
secure the multiple domain networks (OT, PACS, IT, and IdAM).844
Switching and Routing – Switching in the architecture is executed using a series of physical and845
hypervisor soft switches. VLANs are implemented to segment the networks shown in Figures 9846
and 10. VLAN switching functions are handled by physical Dell switches and the virtual847
environment. Routing was accomplished using the firewall.848
Demilitarized Zone – The DMZ provides a protected neutral network space that the other849
networks of the production network can use to route traffic to/from the Internet or each other.850
Operational Technology Network5.6.3851
The builds include the following OT network components:852
• directory instance853
• OT management workstation854
• RTU with IP interface855
• RTU with serial interface856
• ICS/SCADA router857
• router management workstation858
• ICS/SCADA gateway/access control system859
This network emulates an energy enterprise OT network and systems. The specific vendor860
products used in this network are identified in Table 3 and Figure 12. OT network.861

DRAFT
862
863
Figure 12. OT network864
In the OT network, the RADiFlow router performs the ICS/SCADA network firewall function. The865
ConsoleWorks product provides the access control/gateway function. The build used the866
gateway function to manage access to the OT router and RTU management/console interface.867
The interface can be used to configure the RTU as well as issue real-time function commands868
(e.g., open/close relays). The access control/gateway uses the OT directory to obtain access869
authority for each user requesting access to an RTU.870
Information Technology Network5.6.4871
The builds include the following IT network components:872
• Active Directory873
• Cisco ISE874
• TrustSec switch875
• workstation876
A typical enterprise includes information-sharing systems, email, and application servers. We877
did not include these systems in the architecture because they are not needed to demonstrate878

DRAFT
the effectiveness of the IdAM example solution. The specific vendor products used in this879
network are identified in Table 3 and Figure 13.880
881
Figure 13. IT network882
Physical Access and Control System Network5.6.5883
The builds include the following PACS network components:884
• Active Directory885
• PACS control server – Access IT!886
• integrated access control unit (including a card reader, keypad, and door strike)—RS2887
Technologies888
• workstation889
This network emulates a typical enterprise PACS. The specific vendor products used in this890
network are identified in Table 3 and Figure 14.891

DRAFT
892
Figure 14. PACS network893
Two technologies are demonstrated in the PACS network: XTEC XNode and RS2 Technologies894
AccessIT!. XTEC XNode is a physical access system using smart card readers, pin pads, and an895
Internet cloud-based authorization service. The cloud service can federate (interoperate) with896
corporate identity and access stores or can be operated as a fully outsourced PACS IdAM897
solution. The RS2 Technologies system includes card readers, pin pads, and the AccessIT! local898
management server. The local management server is integrated with the central identity and899
access store via the AlertEnterprise Guardian product. In Build #1, Guardian receives IdAM data900
directly from Identity Manager. Once the information is received, Guardian provisions the901
information to the PACS management server. In Build #2, Guardian monitors the PACS directory902
for IdAM changes. Once changes are identified, Guardian collects the information and903
provisions the IdAM information to the PACS management server.904
Identity and Access Management Network5.6.6905
5.6.6.1 Build #1906
Build #1 includes the following IdAM network components:907

DRAFT
• central IdAM system908
• PACS IdAM interface system909
• Structured Query Language (SQL) server910
• MAG Ozone components911
The IdAM was separated to highlight the unique IdAM components proposed to address the912
use case requirements. The implementation is not a recommendation to separate IdAM913
functions on their own network. The products used in this build are identified in Table 3 and914
Figure 15. Central IdAM network.915
916
917
Figure 15. Central IdAM network, Build #1918
The central IdAM system is the authoritative central store for identity and access authorization919
data. CA Identity Manager provides central identity and access store as well as workflow920
management capability in Build #1 (see Figure 15). The central IdAM system takes over control921
of the directory instances in each silo. The control is implemented by providing an922
administrative account credential for each managed directory to the IdAM system. This is an923
important aspect of the implementation. When the administrative credential is issued, the924
organization must limit access to the managed directories of the IdAM system to a reduced925

DRAFT
number of administrative users. The security of the solution partially depends on limited access926
to the managed directories, as discussed in Section 5.9.6, Security Recommendations.927
In this build, the OT, PACS, and IT directories synchronize (sync) with the central IdAM system928
using Lightweight Directory Access Protocol Secure (LDAPS). This synchronization is set up to929
sync changes immediately from the IdAM system to each directory. In addition, an automated930
sync function can be implemented to check for unauthorized changes in each directory to931
increase the security of the implementation. Automated sync was not implemented in this932
build.933
AlertEnterprise Guardian integrates the IdAM central store with the PACS access management934
system (AccessIT!). Guardian includes integration and translation capabilities to transfer the935
IdAM data to the AccessIT! management server database. In this build, Guardian is integrated936
with Identity Manager for IdAM synchronization.937
5.6.6.2 Build #2938
The IdAM network components include a central IdAM system, PACS IdAM interface system,939
and the MAG Ozone components. The IdAM network represents the proposed940
centralized/converged identity and access management network/system. This network was941
separated to highlight the unique IdAM components proposed to address the use case942
requirements. The implementation is not a recommendation to separate IdAM functions own943
their own network. The products used in this build are identified in Table 3 and Figure 16.944
Central IdAM network, Build #2.945

DRAFT
946
Figure 16. Central IdAM network, Build #2947
The central IdAM systems are the authoritative central store for identity and access948
authorization data. RSA IdAM products and AlertEnterprise provide central identity and access949
stores as well as workflow management capability. The central IdAM system takes over control950
of the directory instances in each silo. The control is implemented by providing an951
administrative account credential for each managed directory to the IdAM system. This is an952
important aspect of the implementation. When the administrative credential is issued, the953
organization must limit the access to the managed directories of the IdAM system to a reduced954
number of administrative users. The security of the solution partially depends on limited access955
to the managed directories, as discussed in Sections 5.9.6956
In this build, the OT, PACS, and IT directories sync with the central IdAM system using LDAPS.957
This synchronization is set up to sync changes immediately from the IdAM system to each958
directory. The IdAM system automatically syncs with each directory to check for unauthorized959
changes to increase the security of the implementation.960
In this build, Guardian was used to integrate the IdAM system with the PACS access961
management system (AccessIT!). Guardian includes integration and translation capabilities to962
transfer the IdAM data to AccessIT! Guardian monitors the PACS directory for IdAM updates.963

DRAFT
The MAG Ozone product provides secure attribute distribution within the enterprise. Section964
5.4 describes its use.965
Access Authorization Information Flow and Control Points5.6.7966
The access and authorization for each user is based on the business and security rules967
implemented in workflows within the central IdAM system products (RSA IMG, CA Identity968
Manager). The workflows include management approval chains as well as approval/denial data969
logging. Once the central IdAM system has processed the access and authority request, the970
updated user access and authorization data is pushed to the central ID store. The central ID971
store contains the distribution mechanism for updating the various downstream (synchronized)972
directories with user access and authorization data. This process applies to new users,973
terminated users (disabled or deleted users), and any changes to a user profile. Changes include974
promotions, job responsibility changes, and anything else that would affect the systems a user975
needs to access.976
5.6.7.1 OT Access and Authorization Information Flow977
This section describes the OT ICS/SCADA access and authorization information flow for both978
builds.979

DRAFT
Figure 17. Access and authorization information flow for OT ICS/SCADA devices

DRAFT
Figure 17 depicts the access and authorization information flow for OT ICS/SCADA devices. The1004
red lines indicate the access and authorization data exchanges. The black lines depict the data1005
paths of two OT ICS/SCADA technicians accessing RTUs in the SCADA network (one from the IT1006
network and one from the OT network). Note that all data routed between networks flows1007
through the DMZ and network firewalls.1008
In the OT network, ConsoleWorks controls access to the OT ICS/SCADA devices. ConsoleWorks1009
uses the OT directory to determine which users are authorized to access OT ICS/SCADA devices.1010
It is the control point for users accessing OT network devices. ConsoleWorks stores profiles for1011
groups and specific users. The profiles define which OT devices each user is authorized to1012
access. In addition, ConsoleWorks monitors and logs each user session. This feature allows an1013
organization to monitor user activity, block undesired activities, and generate alerts for1014
suspicious or undesired activities.1015
In the IT network, a TrustSec switch controls which users have access to the OT network. ISE1016
controls the TrustSec switch. This meets the NERC CIP-005 requirement to maintain an1017
electronic security perimeter between the ICS/SCADA network and the rest of the corporate1018
networks. ISE uses the IT directory identity store to determine user access authority and limit1019
access to the ICS/SCADA network to authorized users. This capability enhances the enterprise’s1020
ability to follow NERC CIP-005. ConsoleWorks also authorizes users to access OT devices.1021
5.6.7.2 PACS Access and Authorization Information Flow1022
The PACS access and authorization information flows in each build are described below.1023
1024

DRAFT
Build #11025
1026
Figure 18. Access and authorization information flow for the PACS network, Build #11027
The PACS network includes devices such as door locks and keypads. In Figure 18, the red lines1028
indicate the access and authorization data exchanges. Note that all data routed between1029
networks flows through the DMZ and network firewalls.1030
In the PACS network, the AccessIT! management server controls physical access to facilities,1031
rooms, and the like. AccessIT! updates the PACS devices as needed. The devices also report/log1032
user accesses to this server for logging/auditing purposes. In most environments, the PACS1033
network is segregated from other networks, typically using VLANs. Guardian provides the1034
access and authorization data that it collects from the Identity Manager provisioning server to1035
AccessIT!.1036
1037

DRAFT
Build #21038
1039
1040
Figure 19. Access and authorization information flow for the PACS network, Build #21041
The red lines in Figure 19 indicate the access and authorization data exchanges or PACS access1042
in Build #2. In this build, IMG provisions all PACS IdAM data to the PACS directory.1043
AlertEnterprise provides the access and authorization data that it collects from the PACS1044
directory to AccessIT!.1045

DRAFT
5.6.7.3 IT Access and Authorization Information Flow1046
1047
1048
Figure 20. Access and authorization information flow for the IT network1049
The red lines in Figure 20 indicate the access and authorization data exchanges in both builds.1050
Note that all data is routed among the OT, PACS, IT, and IdAM networks through the DMZ. In1051
the IT network, the hosts and other systems access the IT directory to determine which users1052
are authorized to access devices on the IT network. Active Directory provides the typical1053
identity store function of storing the access permissions.1054
5.7 Data1055
The builds required a user dataset to populate the central IdAM system. In both builds, the1056
IdAM system was initially populated with user data from a synthetic dataset. The dataset was1057
designed to mirror a typical HR system dataset export file. A .csv file was used, which is a typical1058
HR system export file type. The data included user names, titles, access assignments, unique1059
identifiers, and other details required to complete valid directory entries. Once the set of user1060
data was loaded into the IdAM system, each silo directory was provisioned with the appropriate1061
user data. Each silo directory was pre-configured with the group and attribute fields needed to1062
support the builds. For example, the OT network directory had user groups corresponding to1063
the ConsoleWorks user groups. The details are included in the How-To guide.1064

DRAFT
5.8 Security Characteristics Related to NERC-CIP1065
The example solution both impacts and is impacted by the requirement to conform to NERC-CIP1066
standards.29
1067
Because the example solution uses routed protocols, by definition, it falls within the security1068
perimeter of the adopting electricity subsector organization.30
According to NERC-CIP, there1069
must be a well-defined process for controlling access to all components within the1070
organization’s security perimeter.31
So, access to the IdAM network must be controlled.1071
The example solution is informed by NERC-CIP requirements and may contribute to CIP-aligned1072
implementations by providing mechanisms for centralizing logging and auditing of all IdAM1073
activity efficiently and cost-effectively.32
With this solution in place, information regarding1074
which users have access to what components is easily available via the central identity store.1075
Without the solution, this information would have to be gathered separately from each of the1076
IT, OT, and PACS network access control/directory components.1077
Table 4 describes how the centralized IdAM solution relates to NERC-CIP requirements.1078
Table 4. NERC-CIP Requirements1079
NERC-CIP Requirement IdAM Role
CIP 004-3a Maintain a list of individuals with
logical or unescorted physical access to
Critical Cyber Assets.
IdAM maintains, in the identity store, a
record of all logical and physical access to
resources. If critical cyber assets are
identified as such, IdAM inherently maintains
such a list.
CIP 004-3a Conduct a cybersecurity training
program for individuals with logical or
unescorted physical access to Critical Cyber
Assets.
The IdAM workflow can be configured to
check a training system before granting
access to critical cyber assets.
CIP 004-3a Conduct personnel risk The IdAM workflow can be configured to
29
The North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity
standards provide specific requirements that apply to the bulk power system and were used as a reference by the
development team. The proposed solution is designed to be CIP-informed. This document attempts to capture
some of the key areas where CIP standards are relevant to elements of the solution and its implementation, for
reference purposes. Please consult your NERC-CIP compliance authority for any questions on NERC-CIP
compliance.
30
NERC Standard CIP-002-3 Cyber Security – Critical Cyber Asset Identification, Requirements section R3.
31
NERC Standard CIP-005-3a Cyber Security – Electronic Security Perimeter(s), Requirements section R2.
32
NERC Standard CIP-007-3a Cyber Security – Systems Security Management, Requirements section R6.

DRAFT
NERC-CIP Requirement IdAM Role
assessment. Individuals must have an
acceptable risk assessment before being
granted access to Critical Cyber Assets.
verify that individuals have an acceptable risk
assessment before granting access to critical
cyber assets.
CIP 004-3a A list of all personnel with logical
or unescorted physical access to Critical
Cyber Assets must be maintained.
The identity store maintains authoritative
information on all logical and physical access
to resources. The identity store is a list of all
personnel with logical or unescorted physical
access to critical cyber assets.
CIP 004-3a Personnel with logical of physical
access to Critical Cyber Assets must have
that access removed within 24 hours if
terminated for cause and within 7 days
otherwise.
The IdAM workflow receives information
from the HR system on terminations and can
immediately de-provision access for
terminated employees. Information from the
HR system will need to be provided to the
IdAM workflow at least daily to meet the 24-
hour constraint.
CIP 005-3 requires documentation of the
process for authorizing access in accordance
with NERC CIP 004-3.
The IdAM workflow is the process for
authorizing access. The workflow design and
implementation documents the process.
1080
NERC CIP 005-3 requires cyber assets used in access control and/or monitoring of an electronic1081
security perimeter to be protected per CIP requirements. In both builds, the IdAM workflow,1082
the identity store, and the provisioning capability control the information used to make access1083
control decisions. They are considered inside the electronic security perimeter and must be1084
protected according to NERC-CIP requirements. Connections from the IdAM components to IT,1085
OT, and PACS must be considered access points to the electronic security perimeter.1086
5.9 Evaluation of Security Characteristics1087
The security characteristic evaluation seeks to understand the extent to which the IdAM1088
example solution provides a more secure, centralized, uniform, and efficient solution for1089
managing authentication and authorization services and access control across three1090
independent electricity subsector networks. In addition, it seeks to understand the security1091
benefits and drawbacks of the example solution.1092
Scope5.9.11093
The evaluation included analysis of the example solution to identify weaknesses, discuss1094
mitigations, and understand benefits and trade-offs.1095

DRAFT
We considered the following elements of the IdAM example solution:1096
• security functionality of components depicted within the OT, PACS, IT, and IdAM1097
networks in Figure 2, and their interactions with each other, with the exception of the1098
XTEC stand-alone access control system1099
• analysis of the capabilities and overall workflow process for centralizing the1100
management of authentication and authorization services on and access control to the1101
IT, OT, and PACS networks, including assumptions, threats, vulnerabilities, mitigations,1102
benefits, drawbacks, trade-offs, and risks related to the following characteristics:1103
o centralization1104
o automation1105
o audit (accountability and tracking)1106
o authentication1107
o authorization1108
o access control1109
o provisioning1110
• new “cross-silo” attacks that would not have been possible without the centralized IdAM1111
capability1112
• how the example solution addresses the security characteristics listed in the use case1113
description https://nccoe.nist.gov/content/energy1114
• security recommendations that should be addressed when deploying the IdAM design in1115
a real-world, operational environment1116
• hands-on evaluation of the laboratory build as appropriate to support analysis and1117
demonstrate value1118
• security-related aspects of the OT, PACS, and IT networks as they potentially impact the1119
solution posed by the example solution1120
The following elements of the example solution were not considered:1121
• evaluation of any specific vendor product or its implementation1122
• considerations regarding how to secure direct access to each of the three energy1123
networks (OT, PACS, and IT)1124
• aspects of the build that are specific to the laboratory setting in which the build is1125
implemented1126
Security Characteristics Evaluation Assumptions and Limitations5.9.21127
This security characteristic evaluation has the following limitations:1128

DRAFT
• The evaluation examines the security claims made by the example solution; however, it1129
is not a comprehensive test of all security components.1130
• The evaluation cannot identify all weaknesses. Its purpose is to verify that the example1131
solution meets its security claims, and to understand the trade-offs involved in doing so.1132
• This is not a red team exercise. The intent was to verify the security claims, not to break1133
hardware or software involved in the example solution.1134
• The lab routers and firewalls were not included in the evaluation. It is assumed that they1135
are hardened. Testing these devices would reveal only weaknesses in implementation1136
that would not be of value to those adopting this example solution.1137
Example Solution Analysis5.9.31138
Table 5 lists the example solution components, their functions, and the security characteristics1139
they provide. This analysis focuses on these security capabilities rather than on the vendor-1140
specific components. In theory, any number of commercially available components can provide1141
these security capabilities. Some of these components are in Build #1 of the IdAM example1142
solution and others are in Build #2. We discuss them as generic components providing a specific1143
security functionality rather than as vendor products. One vendor product could be substituted1144
for another that provides the same security functionality without affecting the results of the1145
evaluation.1146
Table 5. IdAM Components and Security Capability Mapping1147
Component Specific Product Function
Security
Characteristic
Identity,
Authorization, and
Workflow Manager
RSA IMG
Or
CA Identity Manager
IdAM workflow engine; manages
identities, credentials, and
authorization for all other network
components in the use case.
Enforces workflows to ensure that
access control policies are enforced.
Authentication and
authorization
Identity Store RSA Adaptive Directory
(identity Store), which is
used with RSA IMG
Or
Windows SQL 2012,
which is used with CA
Identity Manager
Database of user identities Authentication and
authorization
High Assurance
Attribute Service
(AAS)
MAG Ozone System Access control solution with ABAC
architecture; provides increased
assurance by signing attributes with
private key infrastructure (PKI) and
requiring users to authenticate with
PKI

DRAFT
Component Specific Product Function
Security
Characteristic
Translator between
Active Directory and
PACS and OT
Access Management
Systems (AMS)
AlertEnterprise Guardian Translates from RSA/CA IdAM
stores on IdAM network to OT and
PACS access management
systems, enabling access
management devices in the OT and
PACS networks to be provisioned
from the IdAM network
Authorization, access
control
Directory Service MS Active Directory (for
IT devices)
Or
RS2 PACS Server (for
PACS devices)
Database of PACS or IT resource
and user identifiers and their
associated security policies
Authentication and
authorization
SCADA Router and
Remote Manager
(RM) of SCADA
Router
RADiFlow IP-addressable industrial control
system gateway that enables remote
control of physical devices:
Management workstation enables
remote management of physical SCADA
router; SCADA router serves as firewall,
terminal server, IP-to-serial
connectivity
Access control
Network Access
Control (AC) and
Policy Enforcement
System (PES)
Cisco ISE Allows access policies for network
endpoints to be controlled centrally
Network security
Stand-alone
Smartcard
Provisioning (SP)
and Access System
(AS)
XTEC Smartcard-based physical access
control
Authentication,
authorization, access
control
1148
Security Characteristics Addressed5.9.41149
One aspect of our security evaluation involved assessing how well the IdAM example solution1150
addresses the security characteristics that it was intended to support. These security1151
characteristics are listed in a security control map published in the appendix of the IdAM use1152
case description1153
(http://nccoe.nist.gov/sites/default/files/nccoe/NCCoE_ES_Identity_Access_Management.pdf).1154
Six security characteristics are listed, each of which is further classified by the Cybersecurity1155
Framework (CSF) categories and subcategories to which they map. The CSF subcategories1156
further map to specific sections of each standard and best practice cited in the CSF in reference1157
to that subcategory. Figure 21 depicts an example of the process.1158

DRAFT
1159
Figure 21. Example process for determining the security standards-based attributes for the example solution1160
We used the CSF subcategories to provide structure to the security assessment by consulting1161
the specific sections of each standard that are cited in reference to that subcategory. The cited1162
sections provide example solution validation points by listing specific traits that a solution that1163
supports the desired security characteristics should exhibit. Using the CSF subcategories as a1164
basis for organizing our analysis and consulting the specific sections of the security standards1165
that are cited with respect to each subcategory allowed us to systematically consider how well1166
the example solution supports the security characteristics identified in the use case description.1167
The remainder of this subsection discusses how the example solution addresses the six desired1168
security characteristics that are listed in the use case description appendix:33
1169
• authentication for OT1170
• access control for OT1171
• authorization (provisioning) OT1172
• centrally monitor use of accounts1173
• protect exchange of identity and access information1174
• provision, modify or revoke access throughout all federated entities1175
This section also discusses how the authentication, access control, and authorization1176
(provisioning) security characteristics are addressed for PACS.1177
33
http://nccoe.nist.gov/sites/default/files/nccoe/NCCoE_ES_Identity_Access_Management.pdf

DRAFT
5.9.4.1 Authentication, Access Control, and Authorization for OT1178
The implementation includes the capabilities that support these security characteristics. Section1179
5.6.7.1 describes the information flows for supporting authentication, access control, and1180
authorization (provisioning) on the OT network.1181
5.9.4.2 Centrally Monitor Use of Accounts1182
The example solution supports centralized accountability and tracking of user accounts, with1183
the IdAM identity, authorization, and workflow manager acting as the locus of this capability.1184
On the OT network, the console access manager, which acts as the gatekeeper to all ICS/SCADA1185
devices, monitors and logs all ICS/SCADA access requests and responses, as well as all user1186
interactions with the ICS/SCADA OT devices. These logs should be centrally monitored along1187
with other ICS/SCADA OT monitoring within the enterprise.1188
The network access control component also logs all access requests and responses received at1189
and generated by the IT network switch that controls access to the OT network from the IT1190
network. These logs should be centrally monitored along with other ICS/SCADA OT monitoring1191
within the enterprise.1192
On the PACS network, the PACS devices also report/log user access requests and responses to1193
the PACS server. These logs should be centrally monitored along with other ICS/SCADA OT1194
monitoring within the enterprise. In addition, the IdAM identity, authorization, and workflow1195
manager and the translator component log the PACS access change (add, delete, or change)1196
requests.1197
5.9.4.3 Protect Exchange of Identity and Access Information1198
All IdAM-related information exchange between IdAM components (as shown by the red lines1199
in Figures 17 – 20) should be performed in protected mode. In other words, at the least,1200
integrity checking mechanisms are performed on this communication so that tampering can be1201
detected. Preferably, these communications are encrypted. In particular, the following should1202
be in protected mode:1203
• all information exchange to/from the directory services in the IT, OT, and PACS networks1204
• all information exchanges between the console access manager (e.g., the ConsoleWorks1205
component in Figure 17) and the OT directory service1206
• all information exchange between the PACS server and the PACS translator component1207
(e.g., the AlertEnterprise component in Figures 18 and 19)1208
Because of time constraints, the laboratory builds of the example solution did not include1209
encryption or integrity assurance for every IdAM information exchange. Nevertheless, such1210
protection is strongly recommended when deploying the example solution.1211

DRAFT
5.9.4.4 Provision, Modify, or Revoke Access1212
User authorizations for use of all IT, OT, and PACS network account assets, for ICS/SCADA1213
devices, and for physical access to rooms, facilities, and the like are provisioned, modified, and1214
revoked by modifying user authorization information in the central IdAM identity,1215
authorization, and workflow manager (CA Identity Manager or RSA IMG). These components, in1216
turn, propagate the changes to all entities used to make local authorization and access1217
determinations. Such information propagation ensures that all attempts to access IT, OT, and1218
PACS network assets, SCADA devices, and rooms and facilities are handled uniformly because1219
they are subject to the same updated access and authorization information when the silo1220
directory, console manager, PACS server, or other IdAM device is consulted in response to the1221
access attempt.1222
Assessment of Reference Architecture5.9.51223
The IdAM example solution is not intended to encompass all aspects of electricity subsector1224
organization operations. It was designed to centralize management of authorization and access1225
in three disparate IdAM silos. Thus, our assessment considers the solution itself, not the1226
broader problem of providing general security to all aspects of electricity subsector1227
organization operations.1228
The example solution includes three network silos (OT, PACS, and IT,), plus an IdAM network1229
with numerous components that provide centralization, uniformity, and efficiency through the1230
use of IdAM workflows. All threats and vulnerabilities that are present on the IT, OT, and PACS1231
networks are also present in the example solution, so they will need to be addressed during1232
solution deployment. This evaluation assumes that the OT, PACS, and IT, networks are already1233
protected using physical access control and network security components such as firewalls and1234
intrusion detection devices that are configured according to best practices.1235
5.9.5.1 Threats, Vulnerabilities, and Assumptions1236
This evaluation concerns the IdAM network itself, its components, and their interaction with1237
IdAM components on the IT, OT, and PACS networks, which both provide the benefits afforded1238
by the example solution and introduce new attack surfaces and potential threats. For example,1239
each of the IT, OT, and PACS networks has directory services components that must be secured.1240
If the information in these directories is not safeguarded against tampering, the organization is1241
at risk. These directories must be safeguarded in both the existing three-silo architecture and1242
the example solution. The example solution, however, includes additional, related directory1243
components that must also be protected.34
1244
The identity, authorization, and workflow manager and the identity store on the IdAM network1245
must be protected from unauthorized access and their information safeguarded. All of the data1246
34
Section 5.6 describes the components and products in each build of the reference solution.

DRAFT
in the directory service components in the OT, PACS, and IT networks is accessible by the1247
identity, authorization, and workflow manager and the identity store. The ability to propagate1248
data from the IdAM network to the OT, PACS, and IT networks is the main strength as well as1249
the greatest vulnerability of the example solution. If the IdAM identity store or the identity,1250
authorization, and workflow manager that has access to it were compromised, this would1251
equate to a compromise of each of the directory services in the IT, OT, and PACS networks. As a1252
result, controlling access to the IdAM network, controlling access to each IdAM component,1253
and securing communications among IdAM components is essential to securing the example1254
solution. Therefore, analysis of the security of the IdAM network, its components, and the1255
communications among IdAM components is central to the evaluation of the IdAM example1256
solution.1257
5.9.5.1.1. Controlling Access to the Identity, Authorization, and Workflow Manager35
1258
The identity, authorization, and workflow manager on the IdAM network contains information1259
regarding actual users and accounts for the OT, PACS, and IT. It manages the identities and1260
credentials for the rest of the use case, but it does not manage them for itself. In other words,1261
the identity, authorization, and workflow manager component itself does not control user1262
access to the identity, authorization, and workflow manager. It has a separate set of user1263
accounts and passwords that are specific to this component and that IdAM administrators use1264
to log into it. This access must be strictly controlled so that only authorized IdAM1265
administrators can log into the identity, authorization, and workflow manager. Users or1266
authorized systems (such as HR or a work order management system) must log into the1267
identity, authorization, and workflow manager to provision all electricity subsector systems1268
(i.e., add identity information and authorization rules for new users, delete information for1269
former users, and modify information as user authorizations change).1270
There is no Active Directory running on the IdAM network. In the builds, access to the identity,1271
authorization, and workflow manager and to all other components of the IdAM network is1272
granted by the use of username and credential, presented either via Web interface or via each1273
machine’s operating system (OS) console. An organization deploying the example solution1274
operationally would of course be free to implement alternative access control mechanisms.1275
While both privileged and unprivileged users may access the identity, authorization, and1276
workflow manager and other IdAM components, only highly privileged users should be1277
permitted to create, delete, or modify accounts. Monitoring, logging, and auditing all activity1278
performed directly on IdAM components such as the identity, authorization, and workflow1279
manager or the identity store is essential to ensure that authorized users are not performing1280
unauthorized activities.1281
35
Section 4.3.2 describes the risks associated with access to the IdAM workflow.

DRAFT
5.9.5.1.2. Logging Activity on IdAM Components1282
Logging all activity performed on IdAM components is crucial for securing the example solution.1283
Ideally, access to all components on the IdAM network should be logged for the purpose of1284
auditing and accountability. The example solution is designed to allow logging of all user activity1285
on IdAM systems (e.g., identity, access, and authorization changes). The example solution1286
should also log all activity performed by administrators so that no activity is exempt from1287
monitoring, logging, and audit. Here is a closer look at three different types of IdAM system1288
users (in terms of the amount of privilege they have) and whether or not their activity should1289
be logged.1290
Unprivileged users, by definition, are not authorized to interact with any IdAM system. They1291
cannot create an account on the identity, authorization, and workflow manager or modify the1292
privileges of a user who already has an account. A user who works for HR, for example, who1293
needs to add a user identity or modify a user’s authorizations, would have an account on the1294
identity, authorization, and workflow manager (that was set up by a privileged user) that allows1295
him/her to add to or modify the information in the identity, authorization, and workflow1296
manager component via Web interface. Such a user would never be able to access the identity,1297
authorization, and workflow manager via its machine’s OS console. Console access would1298
enable the user to manage the operating system on which the component is running. All the1299
unprivileged user needs is the ability to use his/her own, unprivileged, user-level account on1300
the identity, authorization, and workflow manager’s machine. Because the example solution is1301
designed to monitor and log all activity that occurs over a Web interface, it will log all1302
unprivileged user activity.1303
Administrators, by definition, can access OS consoles and create user accounts on IdAM1304
machines such as the identity, authorization, and workflow manager. However, they are not1305
authorized to change the access control policies within the console access manager. As a result,1306
when administrators access the consoles of an IdAM system operating system, they must do so1307
via the console access manager. The console access manager will log and monitor all1308
administrator activity at any OS console.1309
Super-administrators, by definition, can not only access machine consoles and create user1310
accounts on IdAM machine operating systems; they can change the access control policies1311
within the console access manager. Therefore, the example solution cannot force them to use1312
the console access manager when accessing the consoles of IdAM system machine operating1313
systems. If super-administrators do access the consoles of IdAM system’s OS without doing so1314
via the console manager, their activity will not be logged or monitored. So, while super-1315
administrators should be strongly encouraged by policy to use the console access manager,1316
IdAM does not provide a technical mechanism to ensure that they will.1317
Access to the identity store on the IdAM network must also be strictly controlled, and the1318
identity store should be configured so that it will only perform addition, modification, and1319
deletion requests received from the identity, authorization, and workflow manager. If the1320
identity store were to accept updates or edits from another entity, the result could be1321
catastrophic. Any updates made by an administrator would have to be made via machine1322

DRAFT
console, so at least these would be logged. Updates made by a super-administrator could1323
escape detection if the super-administrator were to defy organization policy and access the1324
identity store console without going through the console access manager. We acknowledge1325
insider threats but feel that mitigating the risk of insider threats presently relies more on1326
organizational policy decisions rather than technology. Therefore, addressing insider threat is1327
outside the scope of this project.1328
5.9.5.1.3. Unauthorized Modification of Access and Authorization Information1329
User identity and credential information is input into the identity, authorization, and workflow1330
manager and then propagated to other IdAM components. If this information were deleted,1331
modified, or falsified while in transit between components or while stored in a component, the1332
result could be catastrophic. It is essential to protect access to each IdAM component so that1333
adversaries cannot modify IdAM information stored in the components, and so IdAM1334
information has at least its integrity and ideally its confidentiality protected when in transit1335
between IdAM components.1336
5.9.5.2 Mitigations: Essentials for Securing the IdAM Example Solution1337
Based on the information flows for supporting OT authentication, OT access control, and OT1338
authorization described in Section 5.6.7 securing the part of the IdAM example solution that1339
supports OT access control requires:1340
• securing access to the1341
o identity, authorization, and workflow manager, identity store, and network1342
access control components on the IdAM network (i.e., ensuring that only1343
authorized users can access and add, modify, or delete information on these1344
components)1345
o directory service and console access manager components on the OT network1346
(i.e., ensuring that only authorized users can access and add, modify, or delete1347
information on these components)1348
o IT network access control switch that serves as a gateway to the OT network1349
from the IT network1350
• protecting the integrity of the information exchanged between the1351
o identity manager and the identity stores1352
o identity store and the directory service on the OT network1353
o directory service and the console access manager components on the OT1354
network, as well as the network access control and policy enforcement system1355
within the IT network1356
o network access control component identity stores1357
o network access control component on the IT network and the IT network access1358
control switch that serves as a gateway to the OT network1359

DRAFT
Based on the information flows for supporting PACS authentication, PACS access control, and1360
PACS authorization described in Section 5.6.7 securing the part of the IdAM example solution1361
that supports PACS access control requires:1362
• securing access to the1363
o identity, authorization, and workflow manager; identity store; and IdAM1364
translator components on the IdAM network (i.e., ensuring that only authorized1365
users can access and add, modify, or delete information on these components)1366
o IdAM identity store and PACS directory service components on the PACS network1367
(i.e., ensuring that only authorized users can access and add, modify, or delete1368
information on these components)1369
• protecting the integrity of the information exchanged between the1370
o identity manager and identity stores1371
o identity store on the IdAM network and the PACS directory service on the PACS1372
network1373
o IdAM translator component on the IdAM network and the IdAM directory service1374
on the PACS network1375
o IdAM translator component on the IdAM network and the PACS management1376
server on the PACS network1377
5.9.5.3 Trade-offs1378
As mentioned earlier, the very characteristics that are the main objectives of the example1379
solution, namely centralization and uniformity of the management of authorization and access,1380
are also its main vulnerabilities. A successful attack on the IdAM network or its components1381
could result in a compromise of one or all of the OT, PACS, and IT networks. Organizations that1382
implement the example solution may incur additional costs to secure the IdAM network and its1383
components.1384
5.9.5.3.1 Benefits1385
The benefits of the IdAM example solution include consolidated management of identity and1386
access audit data; documented and repeatable business and security access decision processes1387
(workflows); approval/denial data logging; rapid provisioning and de-provisioning using1388
consistent, efficient, and automated processes; and better situational awareness through the1389
ability to track and audit all access requests and other IdAM activity across all four networks.1390
Other important benefits include greatly reduced time to implement access control changes1391
and highly automated identity synchronization across silos. For example, an OT, PACS, and/or IT1392
access change request can be implemented in minutes. These benefits directly reduce the cost1393
of the regulatory audit requirements imposed on the energy industry. They enable IdAM1394
processes to be handled efficiently, and with more granular, prompt, and cost-effective control.1395

DRAFT
Security Recommendations5.9.61396
While the example solution provides a centralized IdAM security solution, the solution itself1397
provides a single attack vector that, if compromised, could have devastating consequences.1398
Therefore, an organization that implements the example solution must take great care to1399
secure the IdAM example solution itself. When deploying their own implementations,1400
organizations should adhere to the following security recommendations:1401
• Conduct their own evaluations of their example solution implementation.1402
• Deploy all components on securely configured operating systems that use multifactor1403
authentication and are configured according to best practices.36
1404
• Ensure that all operating systems on which example solution implementation1405
components are running are hardened, maintained, and kept up-to-date in terms of1406
patching, version control, and virus and malware detection.1407
• Put into place a security infrastructure that will protect the example solution itself and1408
secure the communications among the components on the IdAM network and between1409
these components and the IdAM components on the other three networks, as described1410
in Section 5.9.5.2. Many of the remaining recommendations relate to providing such a1411
security infrastructure.1412
• Design the authorization and workflow policies that are enforced by the identity,1413
authorization, and workflow manager component to enforce the principle of least1414
privilege and separation of duties.1415
• Design the authorization and access control policies that govern user access to the IdAM1416
components themselves to enforce the principle of least privilege and separation of1417
duties.1418
• Segregate IdAM components onto their own network, either physically or using private1419
VLANs and port-based authentication or similar mechanisms.37
1420
• Deploy a security infrastructure to secure the IdAM network and the IdAM platforms1421
themselves. This infrastructure must consist of a holistic set of components that work1422
together to prevent the IdAM network, components, and workflow from being used as1423
an attack vector.1424
• Protect the IdAM network using security components such as firewalls and intrusion1425
detection devices that are configured according to best practices.1426
36
The laboratory instantiation of the example solution builds did not implement every rule or guide in the STIGs
upon which the builds installations were based. Exceptions were made to allow for only the needed operation of
the solution. See the How-To section for details.
37
IEEE 802.1X is a standard for Port-based Network Access Control that provides an authentication mechanism to
devices that are to be attached to a local area network.

DRAFT
• Protect each of the OT, PACS, and IT, networks using security components such as1427
firewalls and intrusion detection devices that are configured according to best practices.1428
• Strictly control physical access to the OT, PACS, IT, and IdAM networks.1429
• Configure firewalls to limit connections between the IdAM network and the production1430
(IT, OT, and PACS) networks, except for connections needed to support required1431
internetwork communications to specific IP address and port combinations in certain1432
directions. The primary required, authorized internetwork communications are user1433
authorization updates from the identity, authorization, and workflow manager1434
component to the directory services on the production networks, the OT console access1435
manager, and the PACS server, and logging information in the reverse direction.1436
Firewalls should block all incoming connections from the Internet and to limit outgoing1437
connections to the Internet, if any, to specific systems and required ports.1438
• Perform all IdAM-related information exchanged between IdAM components (as shown1439
by the red lines in Figures 17 - 20) in protected mode, meaning that, at the least,1440
integrity checking mechanisms are performed on this communication so that tampering1441
can be detected. Preferably, these communications should be encrypted. In particular:1442
o Perform all information exchange to/from the directory services in each of the1443
OT, PACS, and IT, networks in protected mode.1444
o Perform all information exchange between the console access manager (i.e., the1445
ConsoleWorks component in Figure 17) and the OT directory service in protected1446
mode.1447
o Perform all information exchange between the network access control manager1448
(i.e., the Cisco ISE component in Figure 17) and the switch in the IT network that1449
controls access to the OT network in protected mode.1450
o Perform all information exchange between the PACS server and the PACS1451
translator component (e.g., the AlertEnterprise component in Figure 18 and 191452
in protected mode.1453
In the case of IdAM exchanges with the silo directories, protected mode is defined as1454
the use of Start Transport Layer Security (TLS) (RFC 2830) rather than LDAPS, which uses1455
Secure Socket Layer and has been deprecated in favor of Start TLS.1456
• Install, configure, and use each component of the example solution (e.g., the identity,1457
authorization, and workflow manager or the PAC server) according to the security1458
guidance provided by the component vendor.1459
• Configure all IdAM components on the IdAM network so that it is impossible to access1460
them remotely.1461
• Log all IdAM activity, for example direct access to IdAM components on the IdAM1462
network and all messages exchanged between IdAM components. Limit the number of1463
users able to control whether or not activity performed is logged.1464
• Require super-administrators (i.e., users who are authorized to change the access1465
control policies within the console access manager) to use a console access manager1466

DRAFT
when accessing the console of all devices on the IdAM network and never to access any1467
console directly. Use of a console access manger ensures that all activity performed via1468
the console is logged.1469
• Configure the console access manager to have an always-on connection to all devices on1470
the IdAM network so that it can monitor each device’s console port. This configuration1471
ensures that all activity performed over the console port will be logged. Configure the1472
console access manager to generate an alert if the always-on connection to any device is1473
disconnected. This configuration ensures that security auditors can be aware of any1474
times during which the console port of a device may have been accessed without the1475
activity being logged or monitored.1476
• Configure all devices on the IdAM network so that they have only one console port (the1477
port to which the console access manager has an always-on connection). Alternatively1478
(where applicable), configure the devices on the IdAM network to allow only one1479
console connection or login at a time. This will ensure that the console access manager1480
will log all activity performed via the console of any of these devices.1481
Security Characteristics Evaluation Summary5.9.71482
Overall, the example solution and the workflow processes that it enforces succeed in1483
centralizing IdAM functions across the OT, PACS, and IT networks to provide an efficient,1484
uniform, and secure solution for authenticating and authorizing access across all systems and1485
facilities. The solution enables access control policies across all three networks to be enforced1486
consistently, quickly, and with a high degree of granularity, so that users are granted only1487
enough privilege necessary to complete their work for only the necessary amount of time. It1488
also enables a centralized, simplified audit capability for accountability and tracking. Such1489
benefits come with a cost. This cost is the requirement to secure and log all access to the IdAM1490
network, its components, and the information exchanged between these components and1491
IdAM components on the OT, PACS, and IT, networks.1492
6 FUNCTIONAL EVALUATION1493
We conducted a functional evaluation of the IdAM example solution to verify that several1494
common key provisioning functions of the example solution, as implemented in our laboratory1495
build, worked as expected. The IdAM workflow capability demonstrated the ability to centrally1496
• assign and provision access privileges to users based on a set of programmed business1497
rules in the OT, PACS, and IT, networks and systems1498
• create, activate, and deactivate users in the OT, PACS, and IT, networks and systems1499
• change an existing user’s access to the various networks and systems1500
Section 6.1 explains the functional test plan in more detail and lists the procedures used for1501
each of the functional tests.1502

DRAFT
6.1 IdAM Functional Test Plan1503
This test plan includes the test cases necessary to conduct the functional evaluation of the1504
IdAM use case. The IdAM implementation is currently deployed in a lab at the NCCoE. Section 51505
describes the test environment.1506
Each test case consists of multiple fields that collectively identify the goal of the test, the1507
specifics required to implement the test, and how to assess the results of the test. Table 61508
provides a template of a test case, including a description of each field in the test case.1509
Table 6. Test Case Fields1510
Test Case Field Description
Parent requirement Identifies the top-level requirement or the series of top-level
requirements leading to the testable requirement.
Testable
requirement
Drives the definition of the remainder of the test case fields. Specifies
the capability to be evaluated.
Associated Security
Controls
The NIST SP 800-53 rev 4 controls addressed by the test case.
Description Describes the objective of the test case.
Associated test
cases
In some instances a test case may be based on the outcome of another
test case(s). For example, analysis-based test cases produce a result
that is verifiable through various means such as log entries, reports,
and alerts.
Preconditions The starting state of the test case. Preconditions indicate various
starting state items, such as a specific capability configuration required
or specific protocol and content
Procedure The step-by-step actions required to implement the test case. A
procedure may consist of a single sequence of steps or multiple
sequences of steps (with delineation) to indicate variations in the test
procedure.
Expected results The specific expected results for each variation in the test procedure.
Actual results The actual observed results in comparison with the documented
expected results.

DRAFT
Overall result The overall result of the test as pass/fail. In some test case instances,
the determination of the overall result may be more involved, such as
determining pass/fail based on a percentage of errors identified.
1511
6.2 IdAM Use Case Requirements1512
This section identifies the ES IdAM functional evaluation requirements that are addressed using1513
this test plan. Table 7 lists those requirements and associated test cases.1514
Table 7. IdAM Functional Requirements1515
Capability
Requirement
(CR) ID
Parent Requirement Sub-
requirement
1
Sub-
requirement
2
Test Case
CR 1 The IdAM system shall include an IdAM workflow
capability that assigns and provisions access
privileges to users based on a set of programmed
business rules in the following networks:
CR 1.a IT
CR 1.a.1 Allow access IdAM-1
CR 1.a.2 Deny access IdAM-1
CR 1.b OT
CR 1.b.1 Allow access IdAM-1
CR 1.b.2 Deny access IdAM-1
CR 1.c PACS
CR 1.c.1 Allow access IdAM-1
CR 1.c.2 Deny access IdAM-1
capability that can create and activate new users in
the following networks and systems:
CR 2.a IT IdAM-2
CR 2.b OT IdAM-2
CR 2.c PACS IdAM-2

DRAFT
capability that can de-activate users in the following
networks and systems:
CR 3.a IT IdAM-2
CR 3.b OT IdAM-2
CR 3.c PACS IdAM-2
CR 4 The IdAM system shall include a workflow capability
that can change an existing user access to the
various networks and systems.
CR 4.a IT
CR 4.a.1 Allow to deny IdAM-3
CR 4.a.2 Deny to allow IdAM-3
CR 4.b OT
CR 4.b.1 Allow to deny IdAM-3
CR 4.b.2 Deny to allow IdAM-3
CR 4.c PACS
CR 4.c.1 Allow to deny IdAM-3
CR 4.c.2 Deny to allow IdAM-3
1516
1517

DRAFT
6.3 Test Case: IdAM-11518
Table 8. Test Case ID: IdAM-11519
Parent
requirement
(CR 1) The IdAM system shall include an IdAM workflow capability that
assigns and provisions access privileges to users based on a set of
programmed business rules in the following networks and systems:
(CR 1.a) IT, (CR 1.b) OT, (CR 1.c) PACS
Testable
requirement
(CR 1.a.1-2) IT, (CR 1.b.1-2) OT, (CR 1.c.1-2) PACS
Description Show that the IdAM solution can assign and provision access in the OT and IT
networks as well as in the PACS network and system, including allowing and
denying access.
Associated test
cases
Associated Security
Controls
AC-2, AC-3, IA-2, PE-2, PE-3
Preconditions
1. HR representative .csv file is available.
2. IdAM example solution is implemented and operational in the lab
environment
3. Standard and privileged user sets are known to the testers.
4. A PACS system with a card reader and simulated door access
demonstration system is operational in the lab.
5. A simulated OT network with an RTU and RTU emulator (Raspberry Pi) is
implemented in the lab.
Procedure
1. Activate IdAM workflow engine and run command to ingest the HR
.csv file.
2. At a workstation on the IT network, attempt to log in as a user known
to have access in the IT network.
3. At a workstation on the IT network, attempt to log in as a user known
to be denied in the IT network.
4. At a workstation on the OT network, attempt to log in as a user
known to have access in the OT network.
5. At a workstation on the IT network, attempt to access the Schweitzer
Engineering Laboratories (SEL) RTU administrative interface as a user

DRAFT
known to have access to the SEL RTU.
6. At a workstation on the OT network, attempt to access the RTU
emulator administrative interface as a user known to have access to
the RTU emulator.
7. At a workstation on the IT network, attempt to access the SEL RTU
administrative interface as a user known to be denied access to the
SEL RTU.
emulator administrative interface as a user known to be denied
access to the RTU emulator.
9. At a workstation on the OT network, attempt to log in as a user
known to be denied access in the OT network.
10. At the demonstration PACS card reader, attempt an “access” with a
card for a user known to have access allowed.
11. At the demonstration PACS card reader, attempt an “access” with a
card for a user known to not have access allowed.
Expected results
(pass)
Network Access Allowed
Users with allowed access are able to log into a workstation on the IT
network.
Users with allowed access are able to log into a workstation on the OT
network as well as the SEL RTU and RTU emulator.
Users with allowed access are able to log into a workstation on the PACS
network.
Users with allowed access are authorized and allowed access by the PACS
card reader and door access demonstration system.
Network Access Denied
Users who are denied access to the IT network are unable to log into a
workstation on the IT network.
Users who are denied access to the OT network are unable to log into a
workstation on the OT network as well as the SEL RTU and RTU emulator.
Users who are denied access PACS network are unable to log into a
workstation on the PACS network.
Users without access are not authorized and not allowed access by the PACS

DRAFT
card reader and door access demonstration system.
Actual results This test functioned appropriately and provided the expected results. User
that were denied access were unable to login to the OT and IT networks, and
denied access to PACS. Users granted access to each system were able to
access the OT and IT networks and granted access via PACS.
Overall result Pass
1520
1521

DRAFT
6.4 Test Case IdAM-21522
Parent
requirement
(CR 2) The IdAM system shall include an IdAM workflow capability that can
create and activate new users in the following networks and systems: (OT,
PACS, IT,)
(CR 3) The IdAM system shall include an IdAM workflow capability that can
de-activate users in the following networks and systems: (IT, OT, PACS)
Testable
requirement
Description Show that the IdAM solution can create new users, assign access based on
business rules, and provision those users to the appropriate network and
system access control systems. New users are users without entries in the
authoritative identity store.
Associated test
cases
CR 1
Associated security
controls
AC-2, AC-3, AC-5, AC-16, AU-12, IA-2, IA-4, IA-5, IA-6, PE-2, PE-3, PE-6
Preconditions New HR .csv file created with new users included.
Procedure
1. Demonstrate that the new users in the HR .csv file do not have access in
the OT, PACS, or IT, networks or systems using Test Case IdAM-1.
2. Perform procedure 1 of CR 1 with the new HR .csv file.
3. At a workstation on the IT network, attempt to log in as a new user
known to have access in the IT network.
4. At a workstation on the OT network, attempt to log in as a new user
known to have access in the OT network.
administrative interface as a new user known to have access to the SEL
RTU.
6. At a workstation on the IT network, attempt to access the RADiFlow
router administrative interface as a new user known to have access to
the RADiFlow router administrative interface.
7. At a workstation on the PACS network and system, attempt to log in as a
new user known to have access in the PACS network and demonstration

DRAFT
system.
8. At a PACS card reader, attempt an “access” with a card for a new user
known to have access allowed.
9. Using the IdAM system, deactivate access for one or more users with
access to the OT, PACS, and IT, networks and systems. If one user has
access to all three, deactivating that user is sufficient.
10. At a workstation on the IT network, attempt to log in as a recently
deactivated user known to previously have access in the IT network.
11. At a workstation on the OT network, attempt to log in as a recently
deactivated user known to previously have access in the OT network.
administrative interface as a user known to previously have access to
the SEL RTU.
emulator administrative interface as a user known to previously have
access to the RTU emulator.
Expected results
(pass)
(CR 2) Create and activate a new user.
New users are created and access to the three networks and systems is
confirmed.
(CR 2.a) IT
(CR 2.b) OT network, SEL RTU and RTU emulator
(CR 2.c) PACS network and demonstration card reader access system
(CR 3) Deactivate a user.
User is deactivated and access is denied to the network(s) and systems that
the user previously had allowed access.
(CR 3.a) IT
(CR 3.b) OT network, SEL TRU, and RTU emulator
(CR 3.c) PACS network and demonstration card reader access system
Actual results This test was conducted with the expected results received. A CSV file with
users was successfully uploaded. Upon approval of the user access stated in
the file, the user accounts successfully logged into OT, PACS, and IT. User

DRAFT
access was deactivated and the deactivation approved. The users were no
longer able to access the OT, PACS, or IT.
Overall result Pass
6.5 Test Case IdAM-31524
Parent
requirement
(CR 4) The IdAM system shall include a workflow capability that can change
an existing user’s access to the various networks and systems.
Testable
requirement
(CR 4.a.1, CR 4.b.1, CR 4.c.1) Allow to deny
(CR 4.a.2, CR 4.b.2, CR 4.c.2) Deny to allow
Description Show that the IdAM solution can change user access for any network or
system.
Associated test
cases
CR 2
Associated security
controls
AC-2, AC-3, AC-5, AC-6, AC-16, AU-12, CM-7, IA-2, IA-4, IA-5, IA-6, PE-2, PE-3,
PE-6
Preconditions Reuse IdAM system in the state after IdAM-2 is completed.
Procedure
1. Choose a set of users with known access and a set of users without
access for each of the OT, PACS, and IT networks and systems.
2. Use the IdAM workflow to deny access for the set of users with known
access chosen in 1 above.
3. Use the IdAM workflow to allow access for the set of users without
access chosen in 1 above.
4. At a workstation on the IT network, attempt to log in as a user whose
access had been changed from “allowed” to “denied”.
5. At a workstation on the IT network, attempt to log in as a user whose
access had been changed from denied to allowed.
6. At a workstation on the OT network, attempt to log in as a user whose
access had been changed from allowed to denied.
7. At a workstation on the OT network, attempt to log in as a user whose

DRAFT
8. At a workstation on the PACS network, attempt to log in as a user whose
access had been changed from allowed to denied.
9. At a workstation on the PACS network, attempt to log in as a user whose
10. At a PACS card reader, attempt an “access” with a card for a user whose
access had been changed from allowed to denied (card access denied in
the demo system).
11. At a PACS card reader, attempt an “access” with a card for a user whose
access had been changed from denied to allowed (card access allowed in
the demo system).
router administrative interface as a user whose access had been changed
from allowed to denied.
router administrative interface as a user whose access had been changed
from denied to allowed.
14. At a workstation on the OT network, attempt to access the SEL RTU
administrative interface as a user whose access had been changed from
allowed to denied.
15. At a workstation on the OT network, attempt to access the SEL RTU
denied to allowed.
16. At a workstation on the OT network, attempt to access the RTU emulator
allowed to denied.
17. At a workstation on the OT network, attempt to access the RTU emulator
denied to allowed.
Expected results
(pass)
(CR 4.) Change user access.
(CR 4.a) IT
(CR 4.a.1) Allow-to-deny changes are successfully provisioned.
(CR 4.a.2) Deny-to-allow changes are successfully provisioned.
(CR 4.b) OT

DRAFT
(CR 4.b.1) Allow-to-deny changes are successfully provisioned.
(CR 4.b.2) Deny-to-allow changes are successfully provisioned.
(CR 4.c) PACS
(CR 4.c.1) Allow-to-deny changes are successfully provisioned.
(CR 4.c.2) Deny-to-allow changes are successfully provisioned.
Actual results The test provided the expected results with the impact of changes to user
access (allow to deny, deny to allow) and privilege levels (privileged to non-
privileged, non-privileged to privileged) verified.
Overall result Pass
1526
1527

DRAFT
APPENDIX A: ACRONYMS1528
Acronym Literal Translation
ABAC Attribute-Based Access Control
AD Active Directory
CA CA Technologies
CIP Critical Infrastructure Protection
CR Capability Requirement
CSF Cybersecurity Framework
.csv Comma-Separated Value
DMZ Demilitarized Zone
EACMS Electronic Access Control and Monitoring System
EAP Electronic Access Point
EMS Energy Management System
ESP Electronic Security Perimeter
HR Human Resources
ICS Industrial Control System
ID Identity
IdAM Identity and Access Management
IDS Intrusion Detection System
IMG Identity Management and Governance
IP Internet Protocol
ISE Identity Services Engine
LDAPS Lightweight Directory Access Protocol Secure
MAG Mount Airey Group

DRAFT
Acronym Literal Translation
NAESB North American Energy Standards Board
NAS Network Attached Storage
NCCoE National Cybersecurity Center of Excellence
NERC North American Electric Reliability Corporation
NIST National Institute of Standards and Technology
OS Operating System
OT Operational Technology
PACS Physical Access Control System
PIV-I Personal Identity Verification Interoperable
PKI Private Key Infrastructure
RTU Remote Terminal Unit
SCADA Supervisory Control and Data Acquisition
SQL Structured Query Language
SSL Secure Socket Layer
STIG Security Technical Implementation Guideline
TLS Transport Layer Security
VLAN Virtual Local Area Network
VPN Virtual Private Network
APPENDIX B: REFERENCES1529
[1] Cybersecurity Framework, National Institute of Standards and Technology [Web
site], http://www.nist.gov/cyberframework/ [accessed 2/25/14].
[2] Designation of Public Trust Positions and Investigative Requirements, 5 C.F.R. §
731.106 (2013). http://www.gpo.gov/fdsys/granule/CFR-2012-title5-vol2/CFR-
2012-title5-vol2-sec731-106/content-detail.html.

DRAFT
[3] Office of Management and Budget (OMB), E-Authentication Guidance for Federal
Agencies, OMB Memorandum 04-04, December 16, 2003.
http://www.whitehouse.gov/sites/default/files/omb/assets/omb/memoranda/fy0
4/m04-04.pdf [accessed 2/20/14].
[4] E-Government Act of 2002, Pub. L. 107-347, 116 Stat 2899.
http://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf.
[5] “Establishment of NIST Smart Grid Advisory Committee and Solicitation of
Nominations for Members,” 75 Federal Register 7 (January 12, 2010), pp. 1595-
1596. https://federalregister.gov/a/2010-344.
[6] Federal Information Security Management Act of 2002, Pub. L. 107-347 (Title III),
116 Stat 2946. http://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-
107publ347.pdf.
[7] J. Boyar, M. Find, and R. Peralta, “Four Measures of Nonlinearity,” Eighth
International Conference on Algorithms and Complexity (CIAC 2013), Barcelona,
Spain, May 22-24, 2013, Lecture Notes in Computer Science 7878, pp. 61-72.
http://dx.doi.org/10.1007/978-3-642-38233-8_6.
[8] NISTIR 7298 Revision 2, Glossary of Key Information Security Terms, Richard Kissel,
Editor.
[9] V. C. Hu and K. Scarfone, Guidelines for Access Control System Evaluation Metrics,
NISTIR 7874, National Institute of Standards and Technology, Gaithersburg,
Maryland, September 2012, 48pp. http://dx.doi.org/10.6028/NIST.IR.7874.
[10] M. Souppaya and K. Scarfone, Guidelines for Managing the Security of Mobile
Devices in the Enterprise, NIST Special Publication (SP) 800-124 Revision 1,
National Institute of Standards and Technology, Gaithersburg, Maryland, June
2013, 29pp. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-
124r1.pdf [accessed 2/25/14].
[11] Executive Order no. 13636, Improving Critical Infrastructure Cybersecurity, DCPD-
201300091, February 12, 2013. http://www.gpo.gov/fdsys/pkg/FR-2013-02-
19/pdf/2013-03915.pdf
[12] International Organization for Standardization/International Electrotechnical
Commission, Information technology – Security techniques – Information security
risk management, ISO/IEC 27005:2011, 2011.
http://www.iso.org/iso/catalogue_detail?csnumber=56742 [accessed 2/25/14].
[13] Internet Engineering Task Force (IETF) Network Working Group Request for
Comments (RFC) 5280, May 2008 http://www.ietf.org/rfc/rfc5280.txt [accessed

DRAFT
2/20/14].
[14] Internet Security Threat Report 2013, Volume 18, Symantec Corporation, Mountain
View, CA, 2013, 58pp.
http://www.symantec.com/content/en/us/enterprise/other_resources/b-
istr_main_report_v18_2012_21291018.en-us.pdf [accessed 2/25/14].
[15] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, Internet
X.509 Public Key Infrastructure Certification and Certificate Revocation List (CRL)
Profile,
[16] U.S. Department of Commerce. Personal Identity Verification (PIV) of Federal
Employees and Contractors, Federal Information Processing Standards (FIPS)
Publication 201-2, August 2013, 87pp.
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-2.pdf [accessed 2/25/14].
1530
APPENDIX C: MOUNT AIREY GROUP, INC. PERSONAL PROFILE APPLICATIONS1531
DEMONSTRATION APPLICATION1532
The Personal Profile Application (PPA) was developed by Mount Airey Group, Inc. in order to1533
demonstrate the functionality of the Ozone® Suite of products.1534
Ozone® implements atomic authorization for the protection of critical resources by1535
cryptographically binding credentials to specific authorizations, access rights, and/or explicit1536
privileges; as well as provides a privacy protecting mechanism that allows these authorizations1537
to be distributed across the enterprise – as close to the protected resource as necessary –1538
without concern for tampering, data mining, or compromise; and is meant to protect an1539
organizations most sensitive or highest risk resources. If an application relies on PKI-based1540
smart cards and/or biometrics for authentication, then that system should implement the1541
congruent security for the authorization of users for access to that resource as is provided by1542
Ozone®.1543
In support of the National Cybersecurity Center of Excellence (NCCoE) Electricity Subsector1544
Identity & Access Management (IDAM) Use Case, the PPA was configured to incorporate digital1545
certificates that were generated by GlobalSign, Inc., to be compliant with the North American1546
Energy Standards Board (NAESB) certificate profile. Each certificate was provisioned within1547
Ozone® to have specific authorizations related to the PPA demonstration application.1548
This application has three main information groups for which actions can be authorized:1549
Personal Information, Credit Reports, and Criminal History. Based on the authorizations1550
associated with a credential, results pages are dynamically populated.1551
In order to bring up the demonstration application, the user must present a digital certificate to1552
the application. Upon inspection of the authorizations provisioned within Ozone® for the1553

DRAFT
selected certificate, the application dynamically populates the table at the bottom of the first1554
screen with the results of the authorization queries. If the certificate has been authorized for a1555
specific action, then the results table will display “true” for that specific action. The information1556
identifying the certificate that was selected is also displayed above the table.1557
At that point, the user may either enter a name to search for in the search box on the right, or1558
simply hit the search button to display the Search Results page of the application. The search1559
will return a list of names as well as links to additional information about the people listed. The1560
links listed will vary depending upon the authorizations for which the user was authorized at1561
logon to the PPA. The available authorizations are:1562
• View Personal Information – View the personal information of the selected person.1563
• Edit Personal Information – Add or edit the personal information of people in the1564
application.1565
• View Criminal History – View the criminal history of the selected person.1566
• Edit Criminal History – Add or edit the criminal history of people in the application.1567
• View Credit Report – View the credit report of the selected person.1568
• Request a New Credit Report – Request an updated credit report for the selected1569
person.1570
Sample First Page Table:1571
Authorizations for: C=US, O=Blue Corp, OU=People, CN=Criminal History Editor1572
PPA Proof Authorized
Edit Criminal History true
Edit Personal Information false
Request Credit Report false
View Credit Report false
View Criminal History true
View Personal Information false
1573
Sample Search Results Page Table:1574

DRAFT
Search Results:1575
Name
View
CH
Add
CH
View
CR
Request
CR
Hicks, Chick View Add View Request
McQueen, Lightning View Add View Request
Sullivan, James P View Add View Request
Waternoose, Henry J View Add View Request
Add a new entry...editPI.jsp
1576
For the NCCoE Electricity Subsector IDAM Use Case, the following authorizations have been1577
configured for the NAESB certificates:1578
Jim McCarthy1579
Email Address = james.mccarthy@nist.gov, CN = James McCarthy, OU = GSUS, OU = NCCoE NIST1580
Energy IdAM test account, O = GMO GlobalSign Inc., L = Portsmouth, ST = NH, C = US1581
View Personal
Information
Edit Personal Information
View Criminal History
Edit Criminal History
View Credit Report
Request Credit Report
1582
Donald Faatz1583
Email Address = donald.faatz@nist.gov, CN = Donald Faatz, OU = GSUS, OU = NCCoE NIST1584
Edit Criminal History
1586

DRAFT
Harry Perper1587
Email Address = harry.perper@nist.gov, CN = Harry Perper, OU = GSUS, OU = NCCoE NIST1588
View Personal
Information
Edit Personal Information
View Credit Report
1590
John Wiltberger1591
Email Address = jwiltberger@mitre.org, CN=Johnathan Wiltberger, OU = GSUS, OU = NCCoE1592
NIST Energy IdAM test account, O = GMO GlobalSign Inc., L = Portsmouth, ST = NH, C = US1593
View Personal
Information
View Credit Report
Request Credit Report
1594
1595

Power Grid Identity Management addressed with NIST 1-800

More Related Content

What's hot (20)

Similar to Power Grid Identity Management addressed with NIST 1-800 (20)

More from David Sweigert (20)

Recently uploaded (20)

Power Grid Identity Management addressed with NIST 1-800