ML24051A074
| ML24051A074 | |
| Person / Time | |
|---|---|
| Issue date: | 11/30/2023 |
| From: | Kim A, Kim Lawson-Jenkins Office of Nuclear Security and Incident Response, NRC/RES/DE |
| To: | |
| Anya Kim 301-415-3633 | |
| Shared Package | |
| ML24051A073 | List: |
| References | |
| TLR-RES-DE-2024-001 | |
| Download: ML24051A074 (39) | |
Text
Technical Letter Report TLR-RES-DE-2024-001 Zero Trust Architectures for Operational Technology at Nuclear Facilities Date:
November 2023 Prepared under the Future Focused Research Initiative, by:
Dr. Anya Kim Computer Scientist RES/DE/ICEEB Kim Lawson-Jenkins Senior Cybersecurity Specialist NSIR/DPCP/CSB Division of Engineering Office of Nuclear Regulatory Research U.S. Nuclear Regulatory Commission Washington, DC 20555-0001
i This page intentionally left blank.
ii Table of Contents Table of Contents........................................................................................................................ ii Executive Summary................................................................................................................... iv
- 1.
Introduction......................................................................................................................... 1 1.1 Zero Trust Framework for OT...................................................................................... 2 1.1.1 User...................................................................................................................... 3 1.1.2 Network................................................................................................................ 4 1.1.3 Cross-cutting Sub-elements.................................................................................. 4
- 2.
Security Development Life Cycle (SDLC)............................................................................ 4 2.1 Product Concept Phase............................................................................................... 6 2.2 Security Architecture Phase......................................................................................... 6 2.2.1 Overview of Applicable Defensive Architectures................................................... 7 2.3 Security Requirements................................................................................................12 2.3.1 Cybersecurity Requirements based on Security Control Families........................12 2.3.2 Defensive Security Architecture Requirements....................................................13 2.3.3 Physical Security Requirements..........................................................................13 2.4 Other System Requirements.......................................................................................14 2.5 System Design Phase.................................................................................................14 2.6 Security in Other Life Cycle Phases............................................................................15
- 3.
Applying Zero Trust to the Security Development Life Cycle..............................................15 3.1 ZTA Overlay for OT Systems......................................................................................15 3.1.1 Zero Trust Architecture Core Components...........................................................15 3.2 Applying Zero Trust at the Product Concept Phase.....................................................18 3.2.1 Essential Features of a Zero Trust Architecture...................................................19 3.3 Zero Trust Functions in the Defensive Security Architecture.......................................21 3.3.1 Placement of the ZTA Core Components.............................................................21 3.3.2 Security Considerations of the ZTA Core Components........................................23 3.3.3 Defensive Architecture Requirements for Nuclear Facilities.................................23 3.4 Incorporating the Zero Trust Framework in Security Requirements.............................24 3.4.1 Zero Trust Security Requirements based on Security Control Families................25 3.4.2 ZT Security Requirements based on Pillars.........................................................26 3.5 Applying Other Requirements to the NRC ZT Framework...........................................27 3.5.1 Safety/Security Interface Requirements...............................................................27 3.5.2 Regulatory Requirements....................................................................................28
iii 3.6 Applying Zero Trust at the Design Phase....................................................................28 3.7 Applying Zero Trust at the Implementation and Testing Phases..................................29
- 4.
Conclusion and Future Work..............................................................................................29 4.1 Guidance Document for Implementing Zero Trust.......................................................30 4.2 Maturity Model Considerations....................................................................................30 4.3 Implementation Considerations...................................................................................31 4.4 Trust, Security Posture, and Risk................................................................................31
- 5.
Glossary and Acronyms.....................................................................................................31
- 6.
References........................................................................................................................33
iv Executive Summary Advanced reactors and small modular reactors (SMRs) may employ emerging technologies such as remote monitoring and operations, wireless, and drones that do not fit into the existing perimeter-based defensive architecture and regulatory guidelines.
Zero Trust is a paradigm that moves cybersecurity from perimeter defense to focus on users, assets, and resources. It is not a specific technology or set of technologies, but rather a security strategy with a set of principles designed to prevent data breaches and limit lateral movements within the network. In a nutshell, it can be characterized by the sentiment never trust, always verify.
NRC staff is performing research on whether Zero Trust architectures (ZTAs) can replace or augment the current defensive architecture and reduce the security challenges of introducing these technologies. While the findings will be applicable to other OT areas, the focus of this research is its applicability to OT for nuclear facilities - in particular, SMRs and advanced reactors - as they adopt technologies that are not addressed in current regulatory guidelines.
This paper is the second deliverable of a multi-tasked research project. The first task developed and presented a high level Zero Trust framework for OT based on insights from the authors review of the literature and careful considerations of OT system characteristics.
This paper provides a roadmap on how to develop a Zero Trust Architecture (ZTA) for OT at nuclear facilities. The approach suggested in this paper is to apply the Zero Trust framework for OT - including principles, pillars, and components to a development life cycle. For this purpose, the paper extends a well-known development life cycle by emphasizing the parts relevant to security to form a secure development life cycle (SDLC). The paper then provides an in-depth examination of zero trust issues in each phase of the SDLC life cycle and discusses considerations for implementing a ZTA within a security development life cycle for nuclear facilities. The paper introduces and discusses the essential features of a Zero Trust architecture, including asset inventory and management, strong authentication, variable trust, least privilege, and dynamic policies. The paper also presents the logical ZTA and its components, and options on how to implement the logical ZTA within the defensive architecture either as centralized authorization authority or a federated model. The paper concludes by laying out future work to be done including providing guidance for implementing Zero Trust, and discussions of trust, security posture, and risk.
1
- 1. Introduction This technical letter report (TLR) is the second report produced as part of an NRC Future Focused Research (FFR) Initiative on whether Zero Trust architectures (ZTAs) can replace or augment the current defensive architecture and reduce the security challenges of introducing emerging technologies such as wireless capabilities and remote monitoring. While the findings will be applicable to other Operational Technology (OT) areas, the focus of this research is its applicability to small modular reactors (SMRs) and advanced reactors as they adopt technologies that are not addressed in current regulatory guidelines. The first TLR of this research, Zero Trust for Operational Technology Literature Review, delivered a literature review of Zero Trust concepts [1]. As much of the focus of industry and academia in regard to Zero Trust has been on Information Technology (IT) systems, the TLR also applied insights from the literature review to propose a Zero Trust framework for OT at nuclear facilities. It identified the challenges of applying Zero Trust to OT and defined principles and pillars suitable for using Zero Trust in nuclear facilities.
In the first TLR, the proposed Zero Trust principles for OT environments at nuclear facilities were adapted from various Zero Trust principles for IT [2]-[4] with some insights and adjustments for operating nuclear plants0F1:
Assume Hostile Environment: this applies to both inside and outside the nuclear power plant (NPP) and implies that initially all users, devices, and network are untrusted.
Presume Breach: assume breach has already occurred in your network.
Never Trust, Always Verify: access is denied by default, each device, user, request is authenticated, and authorization granted based on least privilege and dynamic policies.
Scrutinize Explicitly: requests, actions, and behavior are continuously monitored.
Security Maintains Safety: the security decisions and enforcement of the decisions must not affect the safety operations of the facility.
Implementing each of the above Zero Trust principles would require adjustments to the current practices at operating NPPs. NPP operators tend to assume that devices protected behind data diodes are secure and may underestimate the risk of malicious insiders. Presuming a breach may be the most difficult mind-set challenge for operators of nuclear facilities but is absolutely necessary for Zero Trust. Currently, once access is granted to a security level, reverification is not usually required within the security level. The status quo also includes heavy reliance on insider mitigation programs and less reliance on monitoring using technical security controls.
These zero trust principles are the basis for creating a strategy towards a Zero Trust architecture. This TLR provides a roadmap to develop a Zero Trust architecture (ZTA) for OT in nuclear facilities. The remainder of this section introduces the Zero Trust Framework for OT developed as part of Task 1 of this research. It examines how to integrate these Zero Trust principles into a defensive architecture that supports nuclear requirements as well as ZT concepts.
1 The original Zero Trust principles for OT defined in the first report of this research, Zero Trust for Operational Technology Literature Review, only had 4 principles. The last principle, Security maintains safety has been added in this report to emphasize the role and relationship of safety and security in nuclear facilities and other critical industries.
2 In the next sections, we describe the steps to develop a Zero Trust architecture. While it is possible to adopt Zero Trust for existing architectures, using a maturity model, this document examines applying a ZTA in OT from the start. It discusses how to integrate Zero Trust principles, concepts, and components within a development life cycle. For this purpose, Section 2 extends the development life cycle described in Institute of Electrical and Electronics Engineers (IEEE) Standard 7-4.3.2.1 [5], highlighting the phases relevant to security. Section 3 provides an in-depth examination of zero trust issues in each phase of the SDLC life cycle and discusses considerations for implementing a ZTA within a security development life cycle for nuclear facilities. Section 4 provides a conclusion and discussion of future work.
1.1 Zero Trust Framework for OT The Zero Trust framework consist of the Zero Trust principles discussed above and pillars that uphold these Zero Trust principles. Because this framework is to be used for digital systems associated with operational technology, the authors selected the pillars of Zero Trust for nuclear facilities to be those essential to performing a safety, security, or emergency preparedness (SSEP) function. While Zero Trust principles should extend to every aspect of the architecture, in nuclear power plants it fundamentally begins with knowing what assets are in the plant, and who is interacting with the identified assets. All other characteristics of various Zero Trust frameworks, usually included as pillars in other organizations - such as identity, data, application, analytics - are derived from or are associated with one or more of the proposed pillars of Zero Trust for nuclear security.
In defining the pillars of a Zero Trust framework for nuclear security, the principle of a graded approach will be used. A graded approach based on consequences is intended to account for the differing risk levels within reactor technologies. Also, based on the literature review and our expertise, the authors determined that the foundational basis of any Zero Trust we develop should have complete visibility into the devices, users, and systems in an organization. Lastly, the framework leverages the experience and lessons learned from CSP implementations at operating nuclear power plants. Designers and operators of nuclear power plants must 1) identify devices associated with safety, security, or emergency preparedness functions, 2) identify users who will interact with the devices, 3) identify the network used by users to interact with the devices, and 4) protect the safety, security, and emergency preparedness functions according to NRC regulations (such as 10 Code of Federal Regulations (CFR) 73.54 [6] and 73.55 [7]). Based on this, the authors identified the following pillars for Zero Trust in NPPs -
devices, users, and networks. These pillars are illustrated in Figure 1.
3 Figure 1-Pillars and Cross-cutting elements for Zero Trust for OT A necessary criterion in the definition of a device in the Zero Trust framework for OT is that it is a hardware asset that can connect with a network based on the definition of device in the CISA Zero Trust Maturity Model [4].
Current nuclear security guidance focuses on identifying critical digital assets (CDAs). CDAs are highest-valued assets that, if compromised, could cause adverse impact to the safety and/or security functions of an NPP. OT manages the operation of physical processes and the machinery used to perform functions. For this reason, another necessary criterion for a device in Zero Trust for nuclear facilities will be on devices that perform or are associated with SSEP functions. Identification of the critical safety, security, and emergency preparedness functions should address the special requirements for nuclear facilities. To effectively implement Zero Trust, in addition to identifying CDAs, critical data, applications, and functions associated with the CDAs must be identified. This identification of critical data, (digital) assets, applications, and functions can be referred to by using the acronym DAAF. DAAF is analogous to resources defined in Googles BeyondCorp architecture [8] and NSAs DAAS [9].
In addition to CDAs that may perform an SSEP function, it is necessary to identify devices that can act as a user within the digital system. As an example, an automated process may run on a device that communicates with, monitors, and/or operates a CDA. These devices that can run processes or act as proxies for a human user should be identified.
Devices such as drones can be remote and operate outside of the owner-controlled area.
1.1.1 User Users can be humans or non-person entities as defined in NIST SP 800-207 [3]. Users must be properly identified and authenticated. Users have associated identities, applications, data, and functions/roles.
The relevant users from a Zero Trust perspective are the users that have a relationship with a device that operates within the NPPs owner-controlled area. If a user does not have a
4 relationship with a device that operates within the NPPs owner-controlled area, then the user is not performing or affecting an SSEP function. Therefore, the actions of this user are not relevant within the Zero Trust framework. The concept of user is not limited to onsite users - a user can be remote, such as a human or device in a Security Operations Center outside of the owner-controlled area.
1.1.2 Network Communication networks have associated identities, applications, data, and functions. Physical access is considered a network in this Zero Trust framework. Automation can be used to reorganize communication traffic within a network without human intervention or limited human intervention.
1.1.3 Cross-cutting Sub-elements Identity, data, application, and automation are cross-cutting sub-elements that can be applicable for all three pillars of the Zero Trust framework for OT. Identity is the basis for authentication and authorization, the two main responsibilities of a Zero Trust architecture. It is a cross cutting component in that all devices, users, and networks must have verifiable identities. All applications must be identified and configured for least privilege. Data will be tracked and analyzed for situational awareness and trust algorithms. Automation is applicable for any critical function (e.g., safety, security, or emergency preparedness) at a nuclear facility. Automation is an enabling technology for Zero Trust, enabling dynamic policy updates and enforcement of the policies [10].
Limiting the number of pillars of Zero Trust for nuclear security to these three essential elements will allow the system developers and operators to identify and focus on the most important things - from a risk informed security perspective - first. This scoping criterion is based on lessons learned from the implementation of cybersecurity plans at U.S. nuclear power plants. If the inventory of devices, list of user categories, and networks supported are not accurately captured, it will be difficult to determine the completeness and effectiveness of the implemented Zero Trust. While the literature review from Task 1 Technical Letter Report of this project [1]
highlight the importance of data in a Zero Trust framework, this work, while recognizing the importance of data protection, does not recognize data as a Zero Trust pillar: only data that is associated with a device performing a safety or security function or with a network or user interfacing with the device is relevant for the Zero Trust framework. The relevance of the sub-elements in the Zero Trust framework is due to their association with one or more pillars.
The literature provides guidance on how to adopt Zero Trust in a network through the use of various maturity models, that allow operators/users to gradually transition towards a full scale ZTA while prioritizing implementations within each pillar. However, the costs to apply Zero Trust to existing NPPs poses many challenges. Therefore, this work focuses on developing a ZTA for new and advanced reactors, so that it can be incorporated from the beginning of the security design. Some high level guidance on application of a maturity model for Zero Trust in OT can be found in section 4.2 [11].
- 2. Security Development Life Cycle (SDLC)
Implementing each of the Zero Trust principles in Section 1 will require adjustments to the development life cycle of any nuclear power plant - operating NPPs, advanced reactors, and
5 SMRs in order to address security throughout the entire development life cycle. Using the principles and pillars established in Task 1 of this FFR project (and summarized in Section 1.1 of this report), there was a need to develop the Zero Trust architectural framework. The authors of this paper decided to do this by incorporating Zero Trust into the SDLC for nuclear power plants. The SDLC is a framework used to develop, deploy, and maintain software, applications and/or systems by formalizing the various steps into distinct phases. This approach incorporates security by design1F2 by requiring security to be integrated at all stages of the life cycle. The benefits of security by design include the reduced risk of security vulnerabilities introduced in early phases of the development life cycle, lower maintenance and remediation costs, and more effective protections against cyber attacks.
Since safety concerns are important for the nuclear industry, we adopt/consider the life cycle in IEEE 7-4.3.2-2016 [5] as our basis. While IEEE 603-2018 [12] provides the minimal functional and design criteria of safety systems, IEEE 7-4.3.2 specifically establishes the criteria for programmable digital devices used as components of a safety system. Industry is looking to implement Zero Trust architectures from the design stages can use other life cycle approaches.
This paper selects the life cycle approach in IEE 7-4.3.2 for demonstrative purposes only.
IEEE Std 7-4.3.2-2016 IEEE Standard Criteria for Programmable Digital Devices in Safety Systems of Nuclear Power Generating Stations describes a digital safety systems/equipment development process for addressing potential vulnerabilities in each phase of the digital safety system life cycle. This research task on Zero Trust modifies the IEEE Std 7-4.3.2-2016 digital safety systems development process to place additional emphasis on security by identifying Security Requirements and Security Architecture Development as distinct steps in the life cycle phases as shown in Figure 2. Figure 2 is a notional diagram to support the discussion of the Zero Trust framework: All flows and backflows are not illustrated. Readers are expected to be familiar with the life cycle process. Additional information can be obtained from sections 5.3 and 5.9 of IEEE Std 7-4.3.2-2016 [5].
Figure 2 - Security Development Life Cycle adapted from IEEE Standard 7-4.3.2-2016 2 Security by design is a concept that attempts to reduce the number of exploitable flaws and vulnerabilities by designing security features into the products.
6 2.1 Product Concept Phase According to IEEE Std 7-4.3.2-2016, the licensee and developer shall identify digital safety system features required to establish a secure operation environment for the system during the concept phase. Therefore, many of the decisions made during the product concept phase impact the product and system verification processes that will take place after a system becomes operational. In a manner similar to safety features for advance reactors and SMRs, security features should incorporate characteristics such as dynamic updates, automated processes, and integrated capabilities [4]. The decision to adopt a Zero Trust framework, as well as the Zero Trust principles to adopt and security policy focus areas to incorporate would occur during the concept phase. Security considerations for Zero Trust architectures that take place during the product conception phase should include -
Supply chain risk management to include best practices such as those outlined in NIST SP 800-161 Rev 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations [13].
Tools that will support security functions testing throughout product life cycle (e.g., digital twins to verify operation of plant without obstructing actual operation).
Threat protection capabilities (such as incorporation of Field Programmable Gate Arrays (FPGAs) or Trusted Platform Modules2F3 (TPMs) in devices).
Tools or automated mechanisms that support continuous validation and risk analysis of users, devices, and networks.
Access controls capabilities - such as dynamic and remote - to maintain the security posture of the facility.
The above bulleted items will be used to implement Zero Trust and security requirements in later phases that are discussed in the relevant sections in this document.
The decision to adopt a Zero Trust framework would occur during the concept phase. The Zero Trust framework, principles, and pillars selected will feed into the security requirements phase to generate security requirements that support the Zero Trust properties [14]. The most critical functions required for the safe and security operation of a nuclear facility are located in the most protected areas to withstand physical and cybersecurity attacks.
2.2 Security Architecture Phase Both International Atomic Energy Agency (IAEA) 17-T Rev 1 [15] and NRC Regulatory Guide (RG) 5.71 Rev. 1 [16] discuss development of a cybersecurity defensive architecture that establishes formal communication boundaries in which defensive measures are deployed to detect, prevent, delay, mitigate, and recover from cyberattacks. The plant operator should design and implement a cybersecurity defensive architecture in which all systems performing 3 Trusted Platform Module is a secure processor with a dedicated microcontroller that can securely store artifacts (such as cryptographic keys or passwords) that can be used to authenticate a platform (e.g., a laptop or PC or phone). It can also perform attestation by storing platform measurements that can be used to verify the trustworthiness of the platform.
7 facility functions are assigned to a computer security level and protected according to computer security requirements specified for that level. This section of the document will discuss aspects of IAEA 17-T, RG 5.71 Rev. 1, NIST SP 800-82, and IEC 62443 for developing security architecture requirements that will support a Zero Trust framework implementation for nuclear facilities.
An example of a defensive architecture is one that includes a series of concentric defensive levels of increasing security that conceptually correspond to existing physical security areas at a facility (e.g., In nuclear industry parlance, this would be areas such as the vital area, protected area, owner-controlled area, corporate accessible area, public area). Security levels are a way to indicate the extent and rigor of security considered necessary for different protected assets.
Each level in a graded approach will need a different set of protective security controls to satisfy the security requirements for that level. The most stringent security requirements are applied at the highest security level where the most critical assets are located. It is important to note for this paper that the authors will define security architectures which correspond to physical areas of a nuclear facility under the control of the owner. The security architecture can be extended to areas such as cloud computing centers or security operations centers that are not physically located at the nuclear facility, but these specific implementations of a security architecture will not be addressed in this paper.
A Zero Trust architecture is a logical architecture that identifies and describes the components that support the Zero Trust principles. But the actual physical infrastructure is determined by the defensive security architecture that is composed of specific components such as firewalls and data diodes that provide and implement security controls.
2.2.1 Overview of Applicable Defensive Architectures In this section we briefly examine various defensive architectures, drawing from the literature.
IAEA 17-T Rev. 1 Computer Security Techniques for Nuclear Facilities IAEA 17-T Rev. 1 [15] describes a standard approach to protect systems in a structured way according to a graded approach is to use the concepts of computer security levels and computer security zones as shown in Figure 3.
Figure 3 - IAEA Reference Architecture (adapted for use in U.S. NPPs)
8 A computer security level is a designation that indicates the degree of security protection required for a facility function and consequently for the system that performs that function. Each computer security level is associated with a set of requirements imposed by the operator to ensure that the appropriate level of protection is provided to digital assets assigned to that level using a graded approach. Each computer security level will need different sets of computer security measures to satisfy the computer security requirements for that level.
Computer security zones are logical and/or physical groupings of digital assets that are assigned to the same computer security level and that share common computer security requirements owing to inherent properties of the systems or their connections to other systems (and, if necessary, additional criteria). The use of computer security zones is intended to simplify the administration, communication, and application of computer security measures.
Typically, a nuclear facility zone model consists of many different zones, and several zones may have the same computer security level assigned. Examples of zones include demilitarized zones (DMZs as defined in NIST SP 800-82) for remote access, and zones for devices with wireless capabilities.
An NPP function is a coordinated set of actions and processes that need to be performed at a nuclear facility. Facility functions include functions that are important or related to nuclear security and functions that are important or related to nuclear safety (i.e. safety related functions). Facility functions are assigned to systems (identified as critical systems in NRC RG 5.71), each of which performs one or more of these functions.
The idealized relationships between the concepts of facility function(s), computer security level(s), system(s) and computer security zone(s) are illustrated in Figure 4.
Figure 4-- Relationship between security levels, zones, systems, and functions in IAEA 17-T rev. 1[15]
9 Each of the idealized relationships is labelled in the figure, and the labelled text below describes each relationship:
(a) Each facility function is assigned to a single computer security level.
(b) Each computer security level may be applied to one or more facility functions.
(c) Each facility function is ideally assigned to one system, where possible.
(d) Each system ideally performs one facility function, where possible.
(e) Each computer security level may be applied to one or more security zones.
(f) Each computer security zone is assigned a single computer security level.
(g) Each system is placed within a single computer security zone, where possible.
(h) Each computer security zone may consist of one or more systems.
When applying the relationships listed in (a) - (h) to site-specific security levels, zones, functions, and systems at a nuclear power plant, the result will be a set of architecture requirements (see section 3.3.3 for more details).
IEC 62443 Security for industrial automation and control systems - Part 3-2: Security risk assessment for system design The international standards document, IEC 62443 [17] defines the requirements for defining a system under consideration (SUC) for an industrial automation and control system (IACS);
partitioning the SUC into zones and conduits assessing risk for each zone and conduit; establishing the target security level (SL-T)3F4 for each zone and conduit; The IEC 62443 security standards for IACS are quite similar to IAEA guidance in that both group systems into zones and zones are subsequently allocated to security levels and that in both standards zones consists of groupings of systems and components based on their functional, logical, and physical relationship that share the same cybersecurity requirements.
However, the IEC standards introduce the concept of a conduit. A conduit is a logical grouping of communication channels connecting two or more zones that share common cybersecurity requirements. For wireless communication, a wireless network such as ISA 100.11a [18] or WirelessHART [19] are examples of conduits. IEC 62443 also defines relationships between zones and conduits:
A zone can have sub-zones.
A conduit cannot have sub-conduits.
A zone can have more than one conduit - cyber assets within a zone use one or more conduits to communicate.
A conduit cannot traverse more than one zone.
4 IEC 62443 defines three types of security levels: Target Security Levels (SL-T), Capability Security Levels (SL-C), and Achieved Security Levels (SL-A).
10 A conduit can be used for two or more zones to communicate with each other.
NRC RG 5.71 Revision 1 Cybersecurity Programs for Nuclear Power Reactors RG 5.71 rev. 1 discusses security levels in a defensive security architecture. The guidance does briefly discuss segmentation within a security level, but it makes no specific reference to concepts such as zones or conduits. However, these concepts can be to defensive security architecture defined in RG 5.71 rev 1. As depicted in Figure 5, the defensive security architecture in RG 5.71 rev 1 is used to mitigate cyber attacks via 5 attack pathways - wired communications, portable media, and mobile devices (PMMD), wireless communications, supply chain, and physical access. Physical access restrictions increase as personnel access devices located in higher security levels. Similarly, supply chain requirements for devices are more stringent for devices located at the higher security levels. The security defensive architecture details acceptable information flow and protections between security levels for wired communication and PMMD. Because RG 5.71 and IAEA 17-T Rev. 1 are focused on nuclear security; current versions of both documents restrict usage of wireless and remote access directly with systems and devices allocated to the highest security level.
Figure 5 - Reference Defensive Security Architecture at U.S. NPPs NIST SP 800-82 rev 3 Guide to Operational Technology (OT) Security NIST SP 800-82 rev 3 Guide to Operational Technology (OT) Security discusses security for industrial control systems. When designing a security architecture for an OT environment, is the standard recommends separating the OT network(s) from the corporate network due to the differing nature of traffic on the two networks, the different degree of rigor required for change control procedures between the two networks, and the potential of attackers using the IT side of the network to gain a foothold into the OT network. This approach is also used in RG 5.71 rev. 1 and IAEA 17-1 rev. 1.
Similarly, NIST SP 800-82 also discusses defense-in-depth architecture capabilities to systematically layer security controls (such as people, processes, and technologies) to strengthen their overall cybersecurity defenses.
11 NIST SP 800-82 rev 3 also discusses several factors to consider when designing an OT system, such as safety, control timing requirements, geographic distribution, hierarchy, control complexity, availability, and impact of failures.
NIST SP 800-207 Zero Trust Architecture Per NIST SP 800-207, a Zero Trust architecture is an organizations cybersecurity plan that utilizes Zero Trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a Zero Trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a Zero Trust architecture plan [3].
The major functional areas or logical components of a ZTA are illustrated in Figure 6.
Figure 6 - Generic Zero Trust Reference Architecture The concept of control plane and data plane depicted here are abstract constructs.
The control plane is the plane over which trust is established and ZTA logical components that manage security policies communicate. The two major components that reside in the control plane are the Policy Decision Point (PDP) and the Policy Information Point (PIP) as illustrated in Figure 6.
The PDP is responsible for applying the security policy and transmitting a decision to the PEPs whether a users access to a protected resource is granted, denied, or revoked. The PDP has two distinct responsibilities: 1) the Policy Engine (PE) is responsible for making the actual decision whether to grant an access request and for logging this decision. The PE will consider inputs from various sources (such as the Trust Engine and Policy Stores) to make this determination, 2) the Policy Administrator (PA) is responsible for executing the (policy) decision made by the policy engine (PE). This includes setting up and tearing down communication paths between the user and (protected) resource.
12 The PIP gathers and stores information used by the PDP to make access decisions. PIP activities include Identity, Credential, and Access Management (ICAM), endpoint protection, security analytics, continuous monitoring, data security, and threat intelligence.
The data plane is the plane over which actual application data is communicated. The Policy Enforcement Point (PEP) is in the data plane. Devices that operate as PEPs are responsible for enabling, monitoring, and eventually terminating connections between a user and a resource device in the protected enterprise. Physical devices that operate as PEPs include firewalls, proxies, portable media, and mobile device (PMMD) scanning kiosks, and routers. Users in the control plane will never have direct access to entities in the control plane; they will interact directly only with PEPs.
Since these are logical components, actual implementation may be different from the logical implementation. However, since each component has distinct responsibilities and represent the core functionalities of a ZTA, it is strongly recommended that the systems be isolated and implemented as separate systems [10].
These components will be discussed more thoroughly in Section 3.1.
2.3 Security Requirements During the requirements phase of a security life cycle, the security requirements for the facility are generated. Security requirements for nuclear facilities include requirements for physical security, cybersecurity, nuclear material accounting and control, and sensitive information management. The security requirements form the basis of the security policy of the facility.
2.3.1 Cybersecurity Requirements based on Security Control Families Cybersecurity requirements can be generated as tailored versions of NIST SP 800-53 [20].
Appendices B and C of NRC RG 5.71 revision 1 contains tailored security controls applicable for security policies to be implemented at nuclear facilities [16]. These security controls can be used to generate security requirements that:
will be the basis of policy decisions made by the PDP and enforced by the PEP, will be the basis for developing security procedures to be implemented at the nuclear facility and, can be shared with vendors and suppliers who will manufacture and/or obtain equipment that will conform to the security policies of the nuclear facility.
Security controls in NIST SP 800-53 and NRC RG 5.71 revision 1 are organized into families of security controls. Individual cyber security controls in each family can be used to implement security requirements for ZTA. Again, this demonstrates that the concepts in ZTA are not necessarily new. ZTA reorganizes use of existing security controls with enhanced defensive architectures and strategies to more effectively address evolving cybersecurity threat, attacks, and vulnerabilities. Cybersecurity requirements can be generated based on security controls from the security control families which include -
Access Control Audit and Accountability Assessment, Authorization, and Monitoring
13 Configuration Management Incident Response Identification and Authentication Risk Assessment System and Communications Protection System and Information Integrity Supply chain protection Additional standards such as IEC 62645 Nuclear power plants - Instrumentation, control and electrical power systems - cybersecurity requirements [21] can also be referenced when developing cybersecurity requirements. IEC 62645 security requirements are categorized into program level, architectural level, and system level requirements.
2.3.2 Defensive Security Architecture Requirements In addition to security requirements that are developed by tailoring security controls from guidance such as NIST SP 800-53 and/or NRC RG 5.71, security requirements characterizing the Zero Trust framework and architecture must also be developed. Here are a few examples based on guidance in NIST SP 800-207 of security architecture requirements [3]:
The ZTA should be able to identify what assets are owned or managed by the enterprise and determine a devices current security posture.
The ZTA can observe all network traffic.
Protected resources should not be reachable without accessing a PEP.
The ZTA data plane and control plane are logically separate.
The PEP is the only component of the data plane that accesses the PA.
The infrastructure used to support the ZTA access decision process should be scalable to account for changes in process load.
2.3.3 Physical Security Requirements Physical security system requirements must be designed for the physical protection of nuclear facilities to prevent harm from physical attacks. Physical security requirements should document the capabilities to detect, assess, interdict, and neutralize attacks for the physical protection of the nuclear facility. Physical security and cybersecurity protections often perform complementary and mutually supportive functions. For example, physical security systems often rely on digital computer technology and thus physical security protections can be adversely affected by a cyberattack. Another example of the synergy between physical security and cybersecurity is where decisions made during the concept phase in the development of a nuclear facility to reduce the reliance on security rounds or surveillance performed by humans, The decision may require cybersecurity protections for any digital equipment performing these security functions. In todays hybrid world of human interaction and automated technology, even in the domain of nuclear security, rarely will a security function be performed fully by a human or 100% through automation. For the foreseeable future, physical and cybersecurity requirements should be generated with the goals of providing complementary and supportive functions for the system operator to have full situational awareness and security protections at a nuclear facility.
14 Licensees should refer to physical security regulations [7], [22] and guidance for the generation of physical security requirements.
2.4 Other System Requirements For nuclear facilities, most non-security system requirements will be safety requirements. Safety requirements for nuclear systems are derived from Safety Analysis Reports.
Other System Requirements include:
Functional Requirements - examples are power generation, transportation of nuclear material, fuel waste processing and disposal.
Performance Requirements - how well the software and/or hardware performs so that the implemented system accomplishes certain functions under specific conditions.
Examples include the hardware/softwares speed of response, throughput, execution time and storage capacity. These requirements should contain timing considerations for industrial control systems.
Human Factors Requirements - requirements to enhance system performance and leverage the strengths of humans and machine during the operations and maintenance of the system.
Regulatory Requirements - examples are nuclear, environmental, and power generation.
Testing Requirements - examples are vendor requirements, site acceptance, pre-operational testing.
2.5 System Design Phase The system design phase determines how the design will fulfill the security requirements. The design phase usually requires trade-offs between different requirements and constraints (e.g.
security, performance, fault-tolerance, etc.) as well as general constraints (e.g., costs).
Oftentimes, these requirements and constraints may be in conflict with each other, so that tradeoffs and finding the right balance are required (in the system design phase). For example, the amount and speed of data transmitted from devices for security may require additional resources to manage throughput of the communication links. In addition, vendors may dictate how the security requirements can be satisfied, placing additional constraints on the design.
System design finalizes allocation of systems to security levels and zones, and determines security appliances needed to implement security requirements (e.g., firewalls, data diodes, identification, and authentication mechanisms, SIEMs, etc.)
Constraints on security due to safety requirements are addressed in system design. IEEE Std 7-4.3.2-2016 states Implementation of cyber security features (e.g., intrusion detection software, virus protection software, access control software) shall not adversely impact the performance, effectiveness, reliability, or operation of safety functions. Cyber security features such as intrusion detection systems should be implemented peripherally to the safety systems.
Implementation of cyber security features directly in the safety system should be avoided [5].
15 In the security requirements and/or design phase of the facility, licensees/applicants should allocate security requirements to vendors for equipment that will be purchased and installed.
These security requirements should be verified by the licensee prior to equipment installation in an operational system.
2.6 Security in Other Life Cycle Phases Having adequate and comprehensive requirements and designs are fundamental for security.
However, the expression the devil is in the details is quite applicable for implementation of cybersecurity features. It is extremely unusual that proposed system designs are delivered as built to the customer. After the final design requirements are agreed upon, the equipment - and systems in which they will operate - must be implemented and tested. What follows is a brief summary of the tasks in the other security life cycle phases.
System implementation - obtain equipment from vendors selected earlier in the life cycle that satisfies requirements and design constraints and install the equipment with proper secure configurations. In reality, constraints (financial budget, equipment availability, and delivery dates) may require looping back to design phase.
System validation and verification - validate that the security devices and/or features perform as designed and the verify that the system implementation fulfills the security requirements. Security testing requirements written during the system requirements phase should be verified. Verification and validation of tools to be used for the ongoing monitoring of the operation system - such as proper use and maintenance of a digital twin - should occur before the system becomes operational.
- 3. Applying Zero Trust to the Security Development Life Cycle Having discussed the various aspects of the security development life cycle, this section will start to examine how to apply Zero Trust within the life cycle for systems implemented in a nuclear facility.
3.1 ZTA Overlay for OT Systems NIST SP 1800-35, Implementing a Zero Trust Architecture is a comprehensive set of guides that provide examples of how to build ZTA using commercially available technologies and products in various stages of maturity. Specifically, the implementation examples align to the concepts and principles depicted in NIST SP 800-206, Zero Trust Architecture [3]. NIST SP 1800-35 is comprised of five volumes: 1800-35A to 1800-35E. 1800-35B describes a reference architecture and core Zero Trust Components [23].
3.1.1 Zero Trust Architecture Core Components The core components of a ZTA architecture are responsible for deciding whether a particular request made by a specific identity should be granted/authorized. The components that are responsible for this can be broken down to enforcement, decision-making, and information collection (i.e., data stores) and were briefly presented in Section 2.2.1 of this report. How to divide the functionality among the core components, and what these systems are called can differ from one source to the other. For example, In NIST documentations, the core components are the enforcement and decision-making components, while information collection is
16 considered a supporting component. In NIST 1800-35B [23], the information collection component is called a Policy Information Point while Gilman and Barth refer to them as data stores [10].
The authors feel that the information collection component is a core component rather than a supporting component. The authors viewpoint is that a core component is something that without it, the function would not work. While simple authorization with only the decision-making and enforcement capabilities would work on general systems, such an arrangement would provide static authorization only, defeating the purpose and principles of Zero Trust. The information accumulated by and stored in the PIP is essential, enabling the PDP to maintain a dynamic, holistic, and real time view of the security posture and situational awareness within the system in order to make point-in-time decisions. Hence, the authors consider the PIP part of the core components. Therefore, the core components in this ZTA include the PDP for decision making, the PIP for information collection, and the PEP for enforcement of authorization decisions.
System architects and designers of nuclear facilities generate requirements that focus on facility functions. These facility functions and experience with OT systems were used to select the pillars of ZTA as users, networks, and devices. Overlaying the ZTA OT pillars with the generic ZTA shows that the OT pillars align with entities in the data plane as depicted in Figure 7 where the pillars are highlighted in blue text. In particular, these show that the user attempting to access a resource can be a human or a device, that the resource itself is a protected device that performs or is associated with an SSEP function, and that these requests and all traffic must travel across the network. Implementing ZTA using this methodology allows the system architects and designers of the facility to focus on facility functions and allows them to allocate security requirements to experts in the design and implementation of Zero Trust security functions.
Figure 7 - Zero Trust Reference Architecture in a Nuclear Facility The logical Zero Trust components are located in the control plane and/or the data plane. In the control plane:
17 Policy Decision Point (PDP): the PDP makes authorization decisions. It receives access requests from the PEP, compares them to the applicable policy plus additional attributes to determine whether specific access should be granted to the particular user who issued the request. Within the PDP are the following sub-components:
o The Policy Engine (PE) has the capability to make a policy decision. It compares the incoming access request against the policy and other additional attributes to make this determination. The PE incorporates information from a Trust Engine (TE) for risk analysis.
o The Policy Administrator (PA) receives the policy decision from the PE and transmits the policy enforcement information to PEP(s). It is responsible for executing the PEs decision by sending commands to the PEP to establish or terminate the communication pathway between the user and the device.
The Trust Engine: leverages multiple data sources to compute a risk score (or we can call it a trustworthiness score). Performs risk analysis against a particular request or action. It is responsible for producing a numeric assessment of the riskiness of allowing a particular request/action, which the PDP uses to make an ultimate authorization decision. Score: can be used to protect against unknowns and helps keep policies strong and robust without complicating it with edge cases. It is used by the PDP as an additional component by which an authorization decision can be made. (Googles BeyondCorp is the first to pioneer this technology). Behavioral analysis + configuration and health of the device + overall SP of network + other (day, time, location of subject and resource) + ongoing/continued scrutiny of these factors. The trust engine is a logical component that can be part of the policy engine as a trust algorithm, or a separate component as depicted in Figure 7.
Policy Stores: The access policies define the conditions that must be met to grant each user access to the (protected) devices. They are the mechanisms by which it is guaranteed that authorized users have access to only those devices that they absolutely have a need to access in order to perform their duties. The policies describe the rules, conditions, and actions that govern the behavior or decision under consideration. These dynamic policies are stored in a repository defined here as policy stores.
Policy Information Point (PIP): the information generated by policy or collected by supporting components and used as input by the PDP to make policy decisions are referred to collectively as policy information points (PIPs). This data/information is used to provide a full picture of the situational awareness behind each access request and decision. NIST 1800-35B classifies these sources into 4 major categories:
o Identity, Credential, and Access Management (ICAM): associated with creating, storing, and managing user accounts and identity records. Details such as identity management, access and credential management, federated identity belong in this category.
o Endpoint Security: technologies and solutions to protect endpoints from attacks, as well as protecting the network from managed and unmanaged devices. Host-based firewalls, malware scanning and protection devices, vulnerability, and threat mitigation, as well as host intrusion protection activities all fall under this category.
o Data Security: the policies needed by a nuclear facility for secure access to protected assets, as well as the means to protect data at rest and in transit.
o Security Analytics: the collection of all the threat intelligence feeds and traffic/activity monitoring for a nuclear facility. This includes gathering security and behavior analytics about the current state of enterprise assets and continuously monitoring those assets to actively respond to threats or malicious activity.
18 In the data plane:
Policy Enforcement Point (PEP): The PEP is responsible for protecting the trust zone that hosts the devices and is responsible for enabling, monitoring, and terminating connections between a user and a device. The PEP can manifest as a load balancer, proxy, firewall, or PMMD kiosk.
These concepts, components, and the functionality they provide are not new. However, since access control is at the forefront of Zero Trust, they are given emphasis in any discussion of a Zero Trust architecture. Because these components have distinct responsibilities and are considered the fundamental functions of any Zero Trust security model it is recommended that they are treated as distinct systems. Careful consideration should be given if considering merging (any of) these components into one or more systems [10]. Some considerations can include:
Composition of the PDP itself (separate PA and PE or one entity)
Composition of the PIP: what are the supporting components that act as data sources and how are the comprised: ICAM, endpoint security, data security, security analytics, resource protection, and general categories.
Composition of the PEP has following options:
o an agent component on device and gateway component in front of the resource.
o Still has an agent, but gateway components may not reside on assets or in front of individual resources but instead reside at the boundary of a resource enclave (e.g., on-location data center) o PEP is a single component that acts as a gateway for subject requests. The gateway portal can be for an individual resource or a secure enclave for a collection of resources used for a single business function.
Determine how the Policy Decision Point will operate using a graded, consequence-based security policy to protect critical systems, digital assets, and networks.
The policies that serve as the basis for the PE and PA in the PDP are site-specific cybersecurity plans for the nuclear facility. An example of a template for site-specific cybersecurity plans is found in Appendix A of NRC RG 5.71 rev. 1 [16].
3.2 Applying Zero Trust at the Product Concept Phase This phase is where the decision to adopt a ZTA is made. As more digital equipment is introduced into nuclear facilities, the number of attack pathways for supply chain, wired and wireless communications, and portable media and mobile devices increase. The attacker may not need physical proximity to the NPP to execute an attack that could result in physical damage to a plant and its operation. New equipment can expand the plants digital attack surface with vulnerabilities associated with the new technology. Once the decisions regarding use of enabling technologies are made, the defined pillars and principles need to drive the security requirements for the Zero Trust framework as described in section 3.4. The principles lead to the following essential security features that must be supported within a Zero Trust network. It is useful to start thinking about these features in the concept phase.
19 3.2.1 Essential Features of a Zero Trust Architecture Our original principles for Zero Trust in OT within nuclear facilities are:
Assume Hostile Environment: this applies to both inside and outside the nuclear facility and implies that initially all users, devices, and network are untrusted.
Presume Breach: assume breach has already occurred in your network.
Never Trust, Always Verify: access is denied by default, each device, user, request is authenticated, and authorization granted based on least privilege and dynamic policies.
Scrutinize Explicitly: selected requests, actions, and behavior are continuously monitored.
Security Maintains Safety: the security decisions and enforcement of the decisions must not affect the safety operations of the facility.
For these principles to be realized, the following essential features must be supported in a ZTA:
asset inventory and management, strong authentication, variable trust, least privilege, and dynamic policy.
Asset Inventory and Management While Zero Trust is a new paradigm, it has the same goal of protecting the network and resources on the network. Hence, the first step (the prerequisite for) in achieving Zero Trust is to know what is in (or will be) your environment. - Identifying all the assets and keeping that information up to date is the critical first step in Zero Trust4F5. Without the knowledge of what assets are operating in the environment and are to be protected, the other essential security features cannot be adequately supported. Comprehensive asset management includes the following:
Asset Procurement and Identification - purchase orders, security requirements transmitted to the vendor, validation and verification of security requirements, software bill of materials from the vendor, tagging assets for inventory.
Device security assessments (referred to as CDA assessments in RG 5.71) - understand the minimum capabilities of the technology to support the identified plant functions, securely configure the device to perform the plant functions.
Vulnerability assessments - should be based on the software bill of material from vendors, security threats and advisories related to vulnerabilities.
Asset Maintenance - the security and functional capabilities of devices should be maintained throughout the assets life cycle.
Strong Authentication Strong authentication requires identity management (where identity is a cross cutting element in our model) as its backbone. Entities that require authentication in an OT network include:
Protected Devices that are being accessed by the users.
Users (including both human users and non-human entities).
5 In fact, knowing what you have, i.e., performing and maintaining an accurate inventory of assets should be the first steps regardless of the security strategy selected.
20 Applications (that are on the devices and are defined as a cross-cutting element in this approach).
Variable Trust In traditional network environments, trust is granted once, and statically assigned and maintained. The trust policies in these environments manage trust in a (relatively) static way.
In a Zero Trust environment, it is important to realize that trust is constantly changing, based on current and historical actions of the user (whos trust is being evaluated) as well as their state (e.g., device patch state). This is the concept of trustworthiness. In order to support this dynamic trust model, the trust engine determines/calculates a trust score to represent the users trustworthiness.
In a Zero Trust environment, the policy engine performs a real-time, continuous, policy-driven risk-based assessment to establish and maintain access. As discussed earlier, the decision is made in part by input from the Trust Engine that performs a sort of risk analysis to produce a trust score.
The trust score should be weighed against the potential risk of granting access to the resource, the criticality level of the resource itself, the state of the network and all the associated devices.
This way, an attacker that successfully negotiates/hacks a user with a high trust score cannot have carte blanche in their access. This is how dynamic policies, least privilege, and variable trust all work together.
Least Privilege Regarding least privilege: the principle of least privilege ensures that an entity is granted only the privileges it needs to get its work done for only the time it is needed (just enough, just in time). In general, this is implemented by having users executing actions in low privileged mode most of the time. When elevated privileges are needed (e.g., to perform a sensitive operation),
users will be required to present additional conformation of their identity. However, requiring additional proof of identity (i.e., MFA) when accessing a critical function, or performing a high-risk action may violate the safety policy, or put the system and public in danger. Careful consideration must be given to these situations. Sometimes, risk analysis may be necessary that let provide access to an untrustworthy (or less strictly verified identity) so that safety functions may be performed in a timely manner to protect the public health and safety. For devices, the privilege of the device is tied to the identity of the user - it is what determines the privilege level granted for that device.
Dynamic Policies Privilege in Zero Trust is dynamic - traditional networks (particularly in OT) have relatively static policies (regarding what a user can and cannot do). In a Zero Trust architecture, the PDP will use many attributes of activity on the network to determine the risk level of the access request under scrutiny. These attributes can be of the user/device making the request (e.g., trust score),
the network (e.g., current network health), or the device (e.g., when was it last scanned) being accessed. They can be temporal (e.g. is it outside the normal window of activity for the user),
geographical (e.g., is it coming from a different location than previously), or behavioral (e.g. is the user requesting access to a resource not normally accessed) [10]. The values of these
21 attributes help determine the risk level of the access request, and thus dynamically enable the system to require additional proof of identity. These dynamically adjustable policies enable the network to respond autonomously to known and unknown attacks. Furthermore, dynamic policies allow for flexible and fine-grained access control that can adapt to various conditions on the network.
3.3 Zero Trust Functions in the Defensive Security Architecture The defensive architecture will be based levels and zones, or levels and conduits as discussed in section 2.3.2. Security requirements allow safety-related functions to operate under all conditions; they support the functional requirements of the facility. Requirements for a defensive security architecture should mitigate attacks using a wired communication, wireless communication, physical access, PMMD, and supply chain pathways.
3.3.1 Placement of the ZTA Core Components OT networks must carefully consider where to place the ZTA core components. This is especially true for the nuclear domain where the network is segmented into security levels and zones, and the most critical systems are protected behind a data diode, restricting the data flow.
While there may be several options for placing the ZTA components, this paper presents two most likely options.
The first option is a centralized model where the ZTA core components - with the exception of PEPs - together within a single security level (designated Level ZT) as shown in Figure 8. The PDP will communicate with PEPs such as the firewalls and data diode shown in security levels 0 through 4. The components in Level ZT will act as a centralized authorization authority and have the ability to interact with PEPs in all other security levels. Just as other security levels within the defensive architecture, the ZT security level can contain multiple zones. There will be a special zone within the ZT security level that will have highly restrictive interaction with devices in the highest security level (Level 4) in the traditional nuclear security defensive architecture. Only this special zone within Level ZT will contain a PDP with the capability to communicate with Level 4 assets.
In this option, all access requests to devices at any level need to be sent to the central PDP for access authorization decisions. Since the PEPs act as gateways/sentries that execute the decisions made by the PDP, the PEPs can exist in each level. On the one hand, having PDPs in Level ZT make all the security policy decisions makes it simpler to create, maintain, and update policies. All supporting components that provide information to the PIP can also be managed and one overarching security posture is maintained. However, the centralized PDP can be considered a single point of failure and as such, must be well protected itself with self-monitoring and protection capabilities.
22 Figure 8 - Defensive Architecture with a centralized authorization authority The second option is a federated deployment model in which each level in the defensive architecture has its own set of core ZTA components. The PEP in each level would establish connections to resources within other zones and levels if granted by the PDP. Each PDP would have to maintain its own set of policy rules for the level it belongs to, and the PIP would contain data stores collected from local (i.e., same level) data sources. This is depicted in Figure 9. This localized ZTA federated model would need to make provisions for gaining high level situational awareness. In that sense two things need to be considered: updating the policy to reflect the situation and collection and sharing of data that would provide higher level awareness of the situation. This would require that either: 1) the components periodically share their data with each other, or 2) there is a centralized entity that collects all the data and periodically pushes new security policies to the local ZTA entities. For the latter case, there could be a centralized ZTA on a different level (similar to option 1) that collects data from each PIP and also pushes out new data and updated policies.
23 Figure 9 - Defensive Architecture with ZTA components in each level (Federated Deployment Model) 3.3.2 Security Considerations of the ZTA Core Components There are security issues that may be associated with the architectural relationships of the core components. The detailed security analysis is outside the scope of this paper, but potential users should be aware of and carefully consider the following:
With several components and subcomponents working together, it is important to ensure that each component is secured and/or adequately protected.
Separation of data plane and control plane can result in larger attack surface with more information flow areas that need to be protected. For example, eavesdropping and man-in-the-middle attacks between the PDP and PEP.
The PDP can be a bottleneck and single point of failure that needs to be protected:
o With one PDP overseeing and authorizing requests from multiple PEPs, potential distributed DoS attacks are possible.
Redundant components and resiliency via hot backups can be achieved, but state maintenance and coordination can be expensive.
With many sets of core components, flow rule and policy consistency may be an issue and can potentially create vulnerabilities in the system.
3.3.3 Defensive Architecture Requirements for Nuclear Facilities Traditional Defensive Architecture requirements for nuclear facilities include requirements for the following architecture components and concepts:
Security Levels (owner controlled, external/remote, placement of safety and security functions, OT/IT functions)
Zones (DMZ, most critical systems, wireless, quarantine, Zero Trust functions) o Zones have target security levels. As an example, current practices at operating NPP prohibit the use of wireless for safety-related functions. Therefore, for currently operating NPPs, wireless zones would not have a target security level of 4.
Conduits o Are connections between zones
24 o Have special considerations for traffic monitoring (taps, SPAN ports, data transfer capacity considerations) o Have target security levels Network segmentation and segregation o Each facility function is assigned to a single computer security level.
o Each computer security level may be applied to one or more facility functions.
o Each facility function is ideally assigned to one system, where possible.
o Each system ideally performs one facility function, where possible.
o Each computer security level may be applied to one or more security zones.
o Each computer security zone is assigned a single computer security level.
o Each system is placed within a single computer security zone, where possible.
o Each computer security zone may consist of one or more systems.
o Systems performing OT functions are segmented from systems performing IT functions o Interface and communication requirements between security levels and zones must be defined.
Zero Trust Defensive Architecture Requirements include:
Policy Decision Point and Policy Enforcement Point requirements that will define and implement network segmentation (e.g., security requirements related to security levels and zones) and information flow control requirements A security level or zones representing the Zero Trust control plane with the ability to communicate and control devices, communication networks, and users operating within the traditional defensive architecture Ability to collect network traffic and systems communication, such as managed network infrastructure with switched port analyzer (SPAN) ports or tap infrastructure Ability to go into a defensible cyber position, where enhanced connectivity and devices unnecessary for constrained operations are reduced during heightened situations [24]
DMZs and associated security functions (one associated with the policy enforcement point which will contain devices such as data diodes, firewalls, and IPSs, and one associated with remote access) 3.4 Incorporating the Zero Trust Framework in Security Requirements In the case of functional requirements at a nuclear power plant, the primary functional requirements include safe and secure generation of power from processing nuclear material.
Security requirements can be derived from the pillars:
Assume Hostile Environment authorization and access control requirements, segmentation requirements associated with the security architecture requirements.
Presume Breach detection and recovery requirements.
Never Trust, Always Verify identification and authentication requirements.
Scrutinize Explicitly continuous monitoring requirements.
Security Maintains Safety safety/security interface and coordination requirements.
The Zero Trust framework consists of pillars that uphold Zero Trust principles. Because this framework is to be used for digital systems associated with OT, the authors selected elements
25 deemed as essential to performing an SSEP function [3] as the Zero Trust pillars. The Zero Trust framework fundamentally begins with identifying assets in the network and knowing who or what is interacting with the identified assets. All other characteristics of various Zero Trust frameworks-such as identity, data, application, analytics - are derived from or are associated with one or more of the proposed pillars of Zero Trust for OT.
A different level of rigor is needed for security requirements to implement ZT at nuclear facilities.
While current NPP operators credit many physical protections and administrative security controls as adequate alternatives for technical, operational, or management security controls listed in their cybersecurity plans, expected reductions in personnel operating future nuclear facilities and an increased use of digital technologies will likely require additional implementation of technical security controls for adequate security at future NPPs.
3.4.1 Zero Trust Security Requirements based on Security Control Families Decisions made during the concept phase to reduce resources needed for physical security -
human guards, biometric scanners, x-ray machines, multiple physical entry barriers - will likely result in wider a use of more sophisticated technology for cybersecurity. Such examples of security requirements that align with the Zero Trust framework include:
Access Control o Special considerations for wireless and remote access, which are currently prohibited for use of safety-related and security functions at operating nuclear power plants.
Audit and Accountability o Log collection from systems of value such as host-based log collection on Human Machine Interfaces (HMIs) and engineering workstations, sequence of event logs from supervisory systems, and event and access logs from industrial control equipment that supports logs, such as Syslog from PLCs.
o Automated mechanisms to integrate audit review, analysis, and reporting for security policy violations and the investigation of, and response to, suspicious activities.
Security Assessment and Authorization o Ongoing (not periodic) risk assessments and monitoring of security controls.
o System information exchange monitoring and control.
o Up-to-date security assessments of devices that reflect the current security posture.
Identification and Authentication o Multi-factor authentication o Device identification and authentication System and Communications Protection o Use of Trusted Computing technology for cryptographic functions o Use of FPGAs (translates in Requirements phase to things you must do, imposed on the device: this function needs to be protected so it can do this act, etc.) performing the function.
o Boundary Protection based on NIST 800-53 SC-7 Boundary Protection and/or RG 5.71 rev 1 C.7 Defense-in-Depth Defensive Security Architecture System and Information Integrity
26 o Continuous monitoring for attack detection and verification that the applied security controls remain in effect.
o Malware protection and vulnerability management as asset protection mechanisms Contingency Planning & Incident Response o Resiliency and contingency planning for the nuclear facility, such as ZT zones within a security level may be required to operate autonomously or with reduced functionality for a period of time if communication with the facility Zero Trust security level is disrupted.
o Dynamic reconfiguration o Prioritizing safety functions o Operating with a reduction in functionality in response to a cyber attack o In addition, especially for an OT network that the communication between the PDP and the PEP are critical points that require automation: if policy enforcement cannot be dynamically updated, ZT will be unobtainable [10]
System and Service Acquisition o Require a software bill of materials from vendors/equipment manufacturers.
o Trustworthiness of vendors and suppliers Virtually all of the security control examples listed above are included in approved cybersecurity plans of operating U.S. NPPs.
3.4.2 ZT Security Requirements based on Pillars The following security requirements apply to the attributes of the ZT pillars -
USER Has or is assigned one or more Identities Has Ownership (of data and apps)
Is assigned Roles Is assigned access to functions (least privilege)
Can be a human or a device Can have automation of a device Has a physical and logical location within a defensive architecture (Segmentation and segregation: levels and zones)
Has a security posture (device) or level of trustworthiness (human)
DEVICE Has an identity Is assigned a role (e.g., CDA performing a function, M&TE)
Has a security posture Has associated DAAF (Data, assets, apps, functions)
Has an association with an SSEP function Can contain automated processes Has a physical and logical location within a defensive architecture (segmentation and segregation: levels and zones)
27 If associated with a user, the device assumes the same policy as the user (or application) it is associated with. - maintain least privilege of devices.
NETWORK Has a communication type with attributes (wireless, wired, physical/HMI, PMMD)
Has an endpoint type (CDA with the owner-controlled area, device in a known remote facility, device located in an unknown facility/area)
Has an identity Has a physical and logical location within a defensive architecture (segmentation and segregation: levels and zones)
Has associated DAAF (data, assets, apps, functions)
Has a target security level Has an association with an SSEP function Is capable of automation (automatic reconfiguration, load balancing)
Is assigned a trust level 3.5 Applying Other Requirements to the NRC ZT Framework 3.5.1 Safety/Security Interface Requirements Organizations will want to consider the impact on operations and safety functions. For example, would any adverse impacts occur if the ZTA solution increases the latency to respond to resource requests or if one or more ZTA components become unavailable? Based on this analysis, organizations should consider adjusting the ZTA implementations to minimize latency and ensure adequate redundancy to minimize risks to OT and safety operations. Issues to consider include:
Examine the interface between safety and cybersecurity and how to apply Zero Trust principles without adversely impacting safety.
Study the interface between cyber security and physical security and examine how a ZT implementation can impact the physical security strategy.
IEEE Std 7-4.3.2-2016 Section 5.9.3 Interaction between cybersecurity features and safety functions states that implementation of cybersecurity features shall not adversely impact the performance, effectiveness, reliability, or operation of safety functions. The standard also recommends that safety features are installed peripherally, and not directly in the safety system. Applicants and licensees may be able to claim the use of zones and conduits as a way to support this requirement.
IEEE Std 7-4.3.2-2016 Section 5.9.3 also lists items that need to be addressed at a minimum when implementing cybersecurity features:
o The addition of cybersecurity features shall be justified.
o The failure modes and effects of these cybersecurity features on the systems safety functionality shall be addressed. An error in a cybersecurity feature shall not adversely impact the safety functions.
o Non-intrusive cybersecurity features may be applied (e.g. reporting self-diagnostic data for analysis).
28 o Intrusive cybersecurity features (e.g., virus scanning) shall only be executing when safety systems are out of service.
o If cybersecurity features are implemented in safety system displays and controls, they should not adversely impact the operators ability to maintain the safety of the plant.
o Cybersecurity features included in a safety system shall be developed and qualified to the same level as the safety system.
Additional standards such as IEC 62859 Nuclear power plants - Instrumentation and control systems - Requirements for coordinating safety and cybersecurity [25] can also provide guidance on coordinating safety and cybersecurity. It discusses technical, procedural, and organizational aspects of coordination during the system life cycle.
3.5.2 Regulatory Requirements Nuclear facilities will have to comply with multiple regulatory requirements. In the United States, examples of multiple regulatory authorities that will have regulations for nuclear facilities include the NRC, the Federal Energy Regulatory Commission (FERC) [26], the U.S. Environmental Protection Agency (EPA) [27], and the Occupational Safety and Health Administration (OSHA)
[28].
Many cybersecurity plans are technology neutral. The plans generally dont specify what or how a specific technology (such as FPGAs or artificial intelligence) can be used to meet regulatory security requirements. In the absence of guidance from a regulator regarding use of technology, the security policies implemented by the ZTA should reflect the generally accepted best practices for the technology use and the implementation of these best practices should be verified in the system validation and verification phase.
As previously stated in this document, Zero Trust is simply a new methodology to implement security controls that exist in US guidance and international standards. The same security controls are used to implement cybersecurity defense-in-depth (10 CFR 73.54 (c)(2) - to detect, respond to, and recover from cyber attacks) and risk frameworks such as the NIST Risk Management Framework Core Function (Identify, Protect, Detect, Respond, and Recover) [29].
All of these methodologies are complementary, and the implementations can be tailored to meet site specific security requirements at nuclear facilities.
Toward the end of the security requirements phase, all requirements are allocated to technical design requirements of equipment and/or administrative/managerial requirements of the nuclear facility.
3.6 Applying Zero Trust at the Design Phase As vendors and equipment suppliers are chosen and systems are designed, some security adjustments and trade-off decisions will take place. Data processing and throughput challenges to maintain real-time monitoring capabilities may require modifications to the original security architecture and information flows. Some OT components may not support encrypted protocols or the use of encryption may negatively impact the performance of a safety function. A solution may require additional segmentation and strict information flow control and access control
29 performed by protective devices within the environment. The combined security engineered features of a device, known as the capability security level (SL-C) of a device, alone may not be sufficient to comply with the target security level in which the device will operate [30]. Examples for identifying security controls for risk informed security can be found in Sandia National Lab Christopher Lambs work regarding encryption and Zero Trust [31] and Electric Power Research Institute (EPRI)s Technical Assessment Methodology (TAM)5F6 [32].
3.7 Applying Zero Trust at the Implementation and Testing Phases During these phases of the development life cycle, equipment should be installed and tested, and procedures should be put in place to adequately implement ZT.
System implementation - obtain equipment from vendors related to ZT requirements (e.g. firewalls for PEP, authentication servers for authentication and access control decisions) that satisfy requirements and design constraints and install the equipment with proper secure configurations. Personnel training and procedures on the secure operation and maintenance of equipment should be in place.
System validation and verification - validate that the security devices and/or features perform as designed and the verify that the system implementation fulfill the ZT requirements. The testing should verify the known good6F7 state of the systems and establish the baseline information for the known good state. Verification and validation of tools to be used for the ongoing monitoring of the operation system - such as proper use and maintenance of a digital twin - should occur before the system becomes operational.
- 4. Conclusion and Future Work The Zero Trust principles for OT environments at nuclear facilities proposed in Task 1 formed the foundation of a security life cycle model presented in this report (Task 2). This technical report includes various implementation strategies for each Zero Trust principle and architecture, as well as pros and cons of each. The report explained which of the Zero Trust principles would be adopted or adapted, how would each be realized so that they meet the regulatory requirements, and how to apply Zero Trust principles without adversely impacting safety. The 6 TAM is an engineering process developed to assess and mitigate cyber security vulnerabilities in digital systems. The process develops a baseline system/device configuration that provides the assessment starting point and characterizes the attack surface and identifies exploit sequences. It applies the best control methods based on the methods effectiveness and implementation burden. Consequence and hazard information can be combined with the TAM results to make risk informed cyber security decisions.
7 known good is a concept that defines the expected behavior or state of users, devices, applications, configurations, etc. For example, known good software means software that is known to be free of malware and can be trusted; a known good confirmation is a recovery option the user can rely on when restoring a system from failure.
30 technical report also discussed the interface between cybersecurity and physical security and examined how a ZT implementation can impact the physical security strategy.
In summary, the steps to deploying a Zero Trust architecture (within the framework of an SDLC) are:
Decide to implement Zero Trust principles. (Concept phase)
Determine the defensive architecture by deciding which resources will be protected and where will they be placed. This requires discovery and inventory of resources, and the need to employ tools (determine how to maintain inventory and device discovery for operational phase) (Architecture phase)
Determine how the Policy Decision Point will operate using a graded, consequence-based security policy to protect critical systems, digital assets, and networks (in other words, define the security policy.) (Requirements phase)
Determine the access policies that specify the users allowed to access what resources and under what specific conditions.
Design and implement the ZTA components within the defensive architecture.
Test the protected devices and ZTA components to verify that the security requirements are fulfilled.
Future work for the final task of this FFR is highlighted in sections 4.1 through 4.4.
4.1 Guidance Document for Implementing Zero Trust Many nuclear facilities have cybersecurity plans that implement tailored version of cybersecurity controls found in guidance such as NRC Regulatory Guide (RG) 5.71 rev 1. Cyber Security Programs for Nuclear Facilities [16], NEI 08-09, and IEC 63096 Nuclear power plants -
Instrumentation, control and electrical power systems - Security controls [33]. These tailored selected sets of cybersecurity controls may not include controls listed in general cybersecurity guidance, such as NIST SP 800-53 r5 Security and Privacy Controls for Information Systems and Organizations [19], and consequently are not implemented in the facilities CSP. Examples of NIST SP 800-53 cybersecurity controls needed to implement Zero Trust but may not been included in the current cybersecurity guidance for nuclear facilities include: access control decisions, continuous monitoring, information location, digitally signed software, and adaptive authentication. Future work in Task 3 will identify additional cybersecurity controls to include in cybersecurity plans to implement Zero Trust at nuclear facilities. The work will also address architectural considerations of Zero Trust core components that make them resilient against attacks - for example use of redundant PDPs.
4.2 Maturity Model Considerations Future work in Task 3 will highlight the difference between implementing Zero Trust in an operating NPP versus a new NPP.
For operating NPPs with an existing CSP in place, the licensee may wish to add a technology -
such as wireless, remote monitoring and operations, drones, or artificial intelligence - that may significantly impact the current defensive architecture and attack surfaces of plant assets.
Incorporating Zero Trust concepts to generate requirements and designs, and to implement and test new equipment is one method to install the technology in a risk-tolerant manner. The
31 operating NPP should have a known good security posture. Adding Zero Trust to mitigate security issues with introducing new technologies will help to maintain the known good state of the NPP.
For new NPPs, using Zero Trust will help to establish the known good state of the NPP from initial operation.
4.3 Implementation Considerations Task 3 will leverage the work in this report and provide more details for a development process to be used to actually implement a ZTA. This will include identifying issues that need to be considered and how to pick specific implementations and supporting technologies, such as Techniques for knowing the asset inventory, attack surface, and communication pathways (or will have for a system being designed and developed): electronic scans, continuous monitoring Practical methods for determining the current security posture of the nuclear facility Assessment (Impact)
Dynamic, risk-informed security decisions List of best practices - for wireless, remote operations, autonomous operations, etc.
4.4 Trust, Security Posture, and Risk The concepts of trust and trustworthiness can be challenging to quantify, but in a ZTA, trust is represented by a trust score that is generated by the trust engine. Trustworthiness can be determined by a ZT pillars security posture and calculated based on security controls applied to a user (e.g., training, behavior analysis), network, or device. Tools such as EPRIs TAM can be applied to determine the security posture and associated risk index and establish an initial baseline of trustworthiness.
Additional issues to consider when thinking about trust include:
How to define trust: A trust definition should have the following components: the subject and object of the trust, the trust action, and the trust duration.
Each Zero Trust pillar identified here - users, devices, and networks will have their own trust score.
How trust and security posture can change over time How to delegate trust Future work will examine these concepts and their relationships further.
- 5. Glossary and Acronyms Conduit - logical grouping of communication channels that share common security requirements connecting two or more zones (verbatim from IEC 62443-3-2)
Control Plane - used by logical components of a Zero Trust architecture to communicate.
32 Data Plane - used by applications and physical components of a Zero Trust architecture to communicate/transmit data.
Variable Trust - concept in which a numeric value represents the level of trust in a component.
Security Level - a measure of confidence that the systems, zones, or conduits within logical or physical boundary are free from vulnerabilities and functions in the intended manner (modified from IEC 62443-3-2)
Security Zone - grouping of logical or physical assets based upon risk or other criteria, such as criticality of assets, operational function, physical or logical location, required access (for example, least privilege principles) or responsible organization (verbatim from IEC 62443-3-2)
Acronym Full Form AI Artificial Intelligence CDA Critical digital asset CFR Code of Federal Regulations CSP Cyber Security Plan DAAF Data, assets, apps, functions EPRI Electric Power Research Institute FFR Future Focused Research FPGA Field Programmable Gate Array HMI Human Machine Interface IAEA International Atomic Energy Agency IT Information Technology NIST National Institute of Standards and Technologies NPP Nuclear Power Plant NRC Nuclear Regulatory Commission OT Operational Technology PA Policy Administrator PDP Policy Decision Point PE Policy Enforcement PEP Policy Enforcement Point PIP Policy Information Point PMMD Portable Media and Mobile Devices PLC Programmable Logic Controller RG Regulatory Guide SMR Small Modular Reactor SSEP Safety, Security, and Emergency Preparedness TAM Technical Assessment Methodology TPM Trusted Platform Module ZT Zero Trust ZTA Zero Trust Architecture
33
- 6. References
[1]
A. Kim and K. Lawson-Jenkins, Zero Trust for Operational Technology Literature Review, U.S. Nuclear Regulatory Commission, Washington, DC, Technical Letter Report TLR-RES-DE-2023-001, Nov. 2022.
[2]
Department of Defense (DoD), Department of Defense (DOD) Zero Trust Reference Architecture, v1, Joint Defense Information Systems Agency (DISA) and National Security Agency (NSA) Zero Trust Engineering Team. [Online]. Available:
https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
[3]
NIST, Zero Trust Architecture, National Institute of Standards and Technology, Gaithersburg, MD, NIST Special Publication (SP) 800-207, Aug. 2020. doi:
10.6028/NIST.SP.800-207.
[4]
Cybersecurity and Infrastructure Security Agency (CISA), Zero Trust Maturity Model, Jun.
2021.
[5]
IEEE, IEEE Standard Criteria for Programmable Digital Devices in Safety Systems of Nuclear Power Generating Stations, IEEE Std 7-4.3.2-2016 (Revision of IEEE Std 7-4.3.2-2010), pp. 1-86, Aug. 2016, doi: 10.1109/IEEESTD.2016.7552419.
[6]
U.S. Code of Federal Regulations (CFR), Protection of digital computer and communication systems and networks, Section 54, Part 73, Chapter 1, Title 10, Energy.
[7]
U.S. Code of Federal Regulations (CFR), Requirements for physical protection of licensed activities in nuclear power reactors against radiological sabotage., Section 55, Part 73, Chapter 1, Title 10, Energy.
[8]
B. Osborn, J. McWilliams, B. Beyer, and M. Saltonstall, Beyondcorp: Design to deployment at google, 2016.
[9]
National Security Agency (NSA), Embracing a Zero Trust Security Model, NSA, Fort Meade, MD, U/OO/115131-21, PP-21-0191, Feb. 2021. Accessed: Jun. 10, 2021. [Online].
Available: https://media.defense.gov/2021/Feb/25/2002588479/-1/-
1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF
[10] E. Gilman and D. Barth, Zero trust networks: building secure systems in untrusted networks, First edition. Beijing Boston Farnham Sebastopol Tokyo: OReilly, 2017.
[11] NERC, Zero Trust Security for Electric Operations Technology, North American Electric Reliability Corporation, White Paper, Jun. 2023.
[12] IEEE, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations, IEEE Std 603-2018 (Revision of IEEE Std 603-2009), pp. 1-44, Dec. 2018, doi:
10.1109/IEEESTD.2018.8573235.
[13] NIST, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, National Institute of Standards and Technology, Gaithersburg, MD, NIST Special Publication (SP) 800-161 Rev 1, May 2022.
[14] U.S. Nuclear Regulatory Commission, DG 5061 Revision 1 - NRC Staff Responses to Public Comments, ADAMS Accession No. ML22258A200, Mar. 2022. [Online]. Available:
ADAMS Accession No. ML22258A200
[15] International Atomic Energy Agency (IAEA), Computer Security Techniques for Nuclear Facilities. in IAEA Nuclear Security Series, no. 17-T (Rev. 1). Vienna: IAEA, 2021.
Accessed: Dec. 20, 2021. [Online]. Available:
https://www.iaea.org/publications/14729/computer-security-techniques-for-nuclear-facilities
[16] U.S. Nuclear Regulatory Commission, Cyber Security Programs for Nuclear Facilities, Revision 1, Washington, DC, Regulatory Guide (RG) 5.71, Feb. 2023. [Online]. Available:
ADAMS Accession No. ML22258A204
34
[17] IEC, IEC 62443 Industrial communication networks - Network and system security Part 3-2: Security for Industrial Automation and Control Systems, International Electrotechnical Commission, International Standard IEC 62443-3-2:2020, 2020.
[18] ISA, ISA-100.11a Wireless systems for industrial automation: Process control and related applications, International Society of Automation, ANSI/ISA-100.11a-2011.
[19] IEC, IEC 62591 Industrial networks - Wireless communication network and communication profiles - WirelessHART, International Electrotechnical Commission, IEC 62591:2016.
[20] Joint Task Force, Security and Privacy Controls for Information Systems and Organizations, National Institute of Standards and Technology, Gaithersburg, MD, NIST Special Publication (SP) 800-53, Sep. 2020. Accessed: May 04, 2021. [Online]. Available:
https://doi.org/10.6028/NIST.SP.800-53r5
[21] IEC, IEC 62645 Nuclear Power Plants - Instrumentation, control and electrical power stems - cybersecurity requirements, International Electrotechnical Commission, IEC 62645, edition 2.0 2019-11.
[22] U.S. Code of Federal Regulations (CFR), Requirements for physical protection of licensed activities., Section 50, Part 73, Chapter 1, Title 10, Energy.
[23] NIST, Implementing a Zero Trust Architecture, Volume B: Approach, Architecture, and Security Characteristics, National Institute of Standards and Technology, Gaithersburg, MD, NIST Special Publication (SP) 1800-35B, Jul. 2023.
[24] R. M. Lee and T. Conway, The Five ICS Cybersecurity Critical Controls, SANS, White Paper, Nov. 2022.
[25] IEC, IEC 62859 Nuclear Power Plants - Instrumentation and control systems -
Requirements for coordinating safety and cybersecurity, International Electrotechnical Commission, IEC 62859 2019.
[26] FERC, FERC Homepage. [Online]. Available: https://www.ferc.gov/
[27] US Environmental Protection Agency, US EPA Homepage. [Online]. Available:
[28] OSHA, Occupational Safety and Health Administration Homepage. [Online]. Available:
[29] Joint Task Force, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, National Institute of Standards and Technology, Gaithersburg, MD, NIST Special Publication (SP) 800-37 Rev. 2, Dec. 2018. Accessed: May 04, 2021. [Online]. Available:
https://doi.org/10.6028/NIST.SP.800-37r2
[30] IEC, IEC 62443 Industrial communication networks - Network and system security Part 4-2: Technical security requirements for IACS components, International Electrotechnical Commission, International Standard IEC 62443-4-2:2019, Feb. 2019.
[31] B. Karch, A. Hahn, A. Haddad, and C. Lamb, Application of Zero Trust Architectures for Nuclear Power Plants: Benefits and Challenges to Implementation, presented at the 13th Nuclear Plant Instrumentation, Control & Human-Machine Interface Technologies (NPIC&HMIT 2023), Knoxville, TN, Jul. 2023.
[32] EPRI, Cyber Security Technical Assessment Methodology: Risk Informed Exploit Sequence Identification and Mitigation, Revision 1, Electric Power Research Institute (EPRI), Technical Report 3002012752, Nov. 2018.
[33] IEC, IEC 63096 Nuclear power plants - Instrumentation, control and electrical power systems - Security controls, International Electrotechnical Commission, IEC 63096 Edition 1.0, Oct. 2020.