ML25041A017

TLR-RES-DE-2025-001, Implementing Zero Trust for Operational Technology at Nuclear Facilities

ML25041A017
Person / Time
Issue date:	02/10/2025
From:	Kim A, Kim Lawson-Jenkins NRC/NSIR/DPCP, NRC/RES/DE
To:
Anya Kim 301-415-3633
Shared Package
ML24051A073	List: ML24051A074 ML25041A017
References
TLR-RES-DE-2025-001
Download: ML25041A017 (54)

Text

Technical Letter Report TLR-RES-DE-2025-001 Implementing Zero Trust for Operational Technology at Nuclear Facilities Date:

February 2025 Prepared under the Future Focused Research Program 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

i Executive Summary As new reactors adopt emerging technologies such as remote and autonomous monitoring, wireless, drones, and robotics, the current perimeter-based security model and domination of physical controls to address vulnerabilities will not work [3]. The new and novel use of these technologies at nuclear facilities do not neatly fit into the defensive architecture or regulatory guidelines we have today, especially since their risk profile is not yet known. For example, when remote monitoring is introduced, how should the protected area or vital area be defined and defended?

Zero Trust is a paradigm that moves cybersecurity from perimeter defense to focus on users, assets, and communication networks. 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 [1], [2].

In the critical infrastructure sectors, specific requirements must be satisfied. For example, in the nuclear industry, the highest standard is set for safety. The safety, security, and emergency preparedness functions/procedures exist to guarantee the adequate protection of public health and safety, to promote the common defense and security, and to protect the environment. Any function which can hinder or interfere with these procedures must be prohibited. The unique safety requirements of nuclear facilities must be considered and reflected whenever a cybersecurity program is implemented (or cybersecurity controls are selected).

NRC staff performed research on whether Zero Trust architectures (ZTAs)1 can replace or augment the current defensive architecture and reduce security challenges of introducing these technologies while maintaining safety requirements. This research provides the technical and regulatory basis for adopting Zero Trust in nuclear facilities. While the focus of the research is applicable to Operational Technology (OT) for nuclear facilities - in particular, small modular reactors (SMRs) and advanced reactors as they adopt technologies that are not addressed in current regulatory guidelines - the findings are applicable to other OT areas as well. This project was conducted under the US Nuclear Regulatory Commission (NRC)s Office of Research (RES) Future Focused Research (FFR) Program from January 2021 to February 2025. The research was comprised of three tasks, each with an accompanying technical letter report (TLR) describing the outcomes of the task.

Task 1 TLR, Zero Trust for Operational Technology Literature Review surveyed the Zero Trust landscape, developed a high level Zero Trust framework for OT based on insights from review of the literature and careful considerations of OT system characteristics [4]. It proposed the following Zero Trust principles for OT environments at nuclear facilities:

Assume Hostile Environment: this applies to both inside and outside the nuclear power plant (NPP) and implies that initially all users, devices, and networks 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.

1 Per NIST, ZTA is an enterprises cybersecurity plan that uses Zero Trust concepts and encompasses component relationships, workflow planning, and access policies. [3]

ii Scrutinize Explicitly: requests, actions, and behavior are continuously monitored.

A fifth principle was added while working on Task 3:

Security Maintains Safety: the security decisions and enforcement of the decisions must not affect the safety operations of the facility.

Task 2 TLR, ZTAs for Operational Technology at Nuclear Facilities presented a security life cycle model in which to implement Zero Trust and discussed various implementation strategies

[5]. 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 in all phases of the security life cycle.

This document, Task 3 TLR, Implementing Zero Trust for Operating Technology at Nuclear Facilities is the third and final report. This report provides security control guidance for nuclear facilities. Many nuclear facilities have NRC-approved cybersecurity plans (CSPs) based on templates provided in either Nuclear Energy Institute (NEI) 08-09, Cyber Security Plan for Nuclear Power Reactors, [6] or NRC Regulatory Guide (RG) 5.71, Cybersecurity Programs for Nuclear Facilities [7]. The security controls in these CSPs are tailored from NIST SP 800-53 [8]

and NIST SP 800-82 [9] and are applicable to the current nuclear architecture. This paper identifies additional cybersecurity controls that should be included in CSPs that implement Zero Trust in nuclear facilities.

The report also discusses the concepts of trust and trustworthiness in the context of Zero Trust.

To uphold the Zero Trust principles proposed above, continuous verification and strict access control is fundamental. To that end, trust management is one of the most important components used to develop and implement dynamic policies and to support least privilege. This report examines how trust is modeled and implemented in a ZTA. It examines what to consider when developing access control policies and how to describe them. It provides guidance on how to reflect the current defensive architecture used in nuclear power plants in the dynamic trust model. The report describes issues to consider when developing trust algorithms as well as what attributes can be captured when calculating a trust score.

This report also discusses maturity models for implementing Zero Trust in existing facilities.

While the focus of this research is SMRs and advanced reactors, licensee may wish to add a technology - such as wireless, remote monitoring and operation, drones, or artificial intelligence to operating facilities - that may significantly impact the current defensive architecture and increase the attack surfaces of plant assets. This report proposes a four-step risk-based approach to introducing new technologies in operating NPPs: 1) Evaluate new cybersecurity risk, 2) update cybersecurity policies and procedures, 3) implement new mitigating controls, and

4) monitor security controls.

Lastly, the report provides some technologies to consider when implementing a ZTA. For example, when considering how to determine trustworthiness of devices, techniques such hardware root of trust, blockchains, use of Field Programmable Gate Arrays (FPGAs), public key infrastructures and certificates are some technologies that can increase a devices trustworthiness.

iii Acknowledgements This research was supported by the U.S. Nuclear Regulatory Commission, Office of Nuclear Regulatory Researchs Future Focused Research (FFR) Program. Jim Steckel, the FFR Project Manager and the Senior Level Advisors provided valuable guidance and feedback throughout the project.

This project and all the associated reports and conference papers were possible with the significant contributions, expert input, and enthusiastic support from Christopher Cook, Calvin Cheung, Juris Jauntirans, Brian Yip, and Mario Fernandez at the U.S. NRC.

iv This page intentionally left blank.

v Table of Contents Executive Summary..................................................................................................................... i Acknowledgements.................................................................................................................... iii Table of Contents........................................................................................................................ v

1.

Introduction......................................................................................................................... 1 1.1 Zero Trust Framework for OT..................................................................................... 2 1.1.1 Device.................................................................................................................... 3 1.1.2 User........................................................................................................................ 3 1.1.3 Network.................................................................................................................. 4 1.1.4 Cross-cutting Sub-elements.................................................................................... 4 1.2 ZTA Core Concepts.................................................................................................... 5

2.

Security Control Guidance for Zero Trust............................................................................ 8 2.1 Selecting NIST SP 800-53 Security Controls for ZTA................................................. 8 2.1.1 Access Control........................................................................................................ 8 2.1.2 Audit and Accountability.......................................................................................... 9 2.1.3 Assessment, Authorization, and Monitoring...........................................................10 2.1.4 Configuration Management....................................................................................10 2.1.5 Contingency Planning............................................................................................10 2.1.6 Identification and Authentication............................................................................11 2.1.7 Planning................................................................................................................11 2.1.8 Program Management...........................................................................................11 2.1.9 Risk Assessment...................................................................................................12 2.1.10 Systems and Services Acquisition.....................................................................12 2.1.11 System and Communications Protection............................................................13 2.1.12 System and Information Integrity........................................................................14 2.1.13 Supply Chain Risk Management........................................................................14 2.2 Mapping Security Controls to ZTA components.........................................................15

3.

Trust and Access Control in Zero Trust..............................................................................21 3.1 Access Control..........................................................................................................21 3.1.1 Access Control Policies in Zero Trust....................................................................22 3.1.2 Access Control Deployment Models......................................................................24 3.2 The Concept of Trust.................................................................................................27 3.2.1 Trust, Trustworthiness, and Risk............................................................................28 3.2.2 Trust Scores..........................................................................................................29

vi 3.2.3 Trust Algorithms.....................................................................................................30

4.

Maturity Model Considerations...........................................................................................34 4.1 Applying Zero Trust in Operating Nuclear Power Plants............................................34 4.2 Applying Zero Trust in New Nuclear Power Plants.....................................................35

5.

Implementation Considerations..........................................................................................36 5.1 Concepts and Considerations to Establish Trustworthiness.......................................37 5.1.1 Trust Relationship between the PDP and Identity Providers..................................37 5.1.2 Device Inventory Service.......................................................................................37 5.1.3 Microsegmentation................................................................................................37 5.1.4 Access Control Models..........................................................................................37 5.2 Technical Methods for Determining a Devices Trustworthiness................................38 5.2.1 Hardware Roots of Trust........................................................................................38 5.2.2 Blockchain Technology..........................................................................................38 5.2.3 Field Programmable Gate Arrays...........................................................................39 5.2.4 Public Key Infrastructure and Certificates..............................................................39 5.3 Techniques for Understanding the Attack Surface.....................................................39 5.4 Methods for Maintaining Security Posture of the Nuclear Facility...............................40

6.

Conclusion and Future Work..............................................................................................41

7.

Acronyms...........................................................................................................................43

8.

References........................................................................................................................44

1

1. Introduction This technical letter report (TLR) is the third and final report produced as part of an NRC Future Focused Research (FFR) Program on whether 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

[4]. As much of the focus of industry and academia regarding 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 [3], [10], [11] with some insights and adjustments for operating nuclear plants2:

Assume Hostile Environment: this applies to both inside and outside the nuclear power plant (NPP) and implies that initially all users, devices, and networks 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-related and important-to-safety functions 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 ZTA. This TLR provides a roadmap to develop a ZTA for OT in nuclear facilities. As part of the research in Task 1, a Zero Trust Framework for OT was developed that provided ways to integrate these Zero Trust principles into a defensive architecture that supports nuclear requirements as well as Zero Trust concepts.

In the second TLR, the steps to develop a ZTA were described. While it is possible to adopt Zero Trust for existing architectures using a maturity model, the Task 2 report focused on 2 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 applying a ZTA in OT from the start. It discussed how to integrate Zero Trust principles, concepts, and components within a development life cycle. For this purpose, it extended the development life cycle described in Institute of Electrical and Electronics Engineers (IEEE)

Standard 7-4.3.2-2016 [12] and endorsed in RG 1.152 Rev 4 [13], highlighting the phases relevant to security. It also provided an in-depth examination of Zero Trust issues in each phase of the life cycle and discussed considerations for implementing a ZTA within a security development life cycle for nuclear facilities.

While Zero Trust can provide increased cybersecurity, potentially brittle security controls and principles can lead to lack of availability by denying access to legitimate users or limiting their ability to access necessary devices or systems, resulting in increased safety hazards.

Therefore, this research attempts to examine the applicability of Zero Trust for NPPs and other OT environments with safety in mind. This report focuses on the security controls that need to be adopted and the access control policies that need to be addressed. This section provides a brief summary of the work done in Tasks 1 and 2.

1.1 Zero Trust Framework for OT The Zero Trust framework consists 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, NRC staff selected pillars for Zero Trust in 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 NPPs it fundamentally begins with knowing what assets are in the plant, and who is interacting with the identified assets. All other characteristics of existing 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 was applied. 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 NRC staff expertise in nuclear security, it was determined that the foundational basis of any Zero Trust developed should have complete visibility into the devices, users, and systems in a nuclear facility. Lastly, the framework leverages the experience and lessons learned from CSP implementations at operating NPPs. Designers and operators of NPPs 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 Title 10 of the Code of Federal Regulations (10 CFR) Section 73.54, Protection of digital computer and communication systems and networks [14] and 10 CFR Section 73.55, Requirements for physical protection of licensed activities in nuclear power reactors against radiological sabotage [15]). 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 1.1.1 Device 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 Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model [11].

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 safety, security, and emergency preparedness (SSEP) functions. Identification of the critical SSEP 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.

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.

Some devices such as drones can be remote and operate outside of the owner-controlled area.

1.1.2 User Users can be humans or non-person entities as defined in the National Institute of Standards and Technology (NIST) Special Publication (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.3 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.4 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 ZTA. It is a cross-cutting component in that all devices, users, and networks must have verifiable identities. Data will be tracked and analyzed for situational awareness and trust algorithms and is transmitted between the users and devices across the network. Applications are used by users and reside on devices. They must be identified and configured for least privilege to minimize the attack surface. Automation could be applicable to any critical function (e.g., safety, security, or emergency preparedness) at a nuclear facility. Automation is an enabling technology for Zero Trust, allowing dynamic policy updates and enforcement of the policies [16].

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 CSPs at U.S. NPPs. 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 architecture.

While the literature review from the Task 1 TLR of this project [4] highlights 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 using 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 pose 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 of this TLR, as well as in the North American Electric Reliability Corporation (NERC) white paper, Zero Trust Security for Electric Operations Technology [17].

5 1.2 ZTA Core Concepts The core components of a ZTA 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). Figure 2 depicts a Zero Trust Reference Architecture based on NIST SP 1800-35B Implementing a Zero Trust Architecture Volume B. Approach, Architecture, and Security Characteristics [18] but extends and refines it to make it more relevant for OT systems and NPPs. The core components in this ZTA include the Policy Decision Point (PDP) for decision making, the Policy Information Point (PIP) for information collection, and the Policy Enforcement Point (PEP) for enforcement of authorization decisions3.

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 2, where the pillars are highlighted in blue text. The figure shows a user attempting to access a protected device (e.g. a CDA) that performs or is associated with an SSEP function; the user can be a human or a device; 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 2 - Zero Trust Reference Architecture in a Nuclear Facility 3 One may consider the Trust Engine and Policy Store as critical components. In fact, some architectural representations consider them as part of the PDP [3], [16]. Here, we have separated them out to be able to discuss them in some detail.

6 The Zero Trust components are located in the control plane and/or the data plane4. The control plane is the part of the system responsible for making access control decisions, while the data plane is used by applications and physical components of a ZTA to execute those decisions and communicate/transmit data. The control plane consists of the following logical components:

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 user who issued the request.

Within the PDP are the following sub-components (while they could be considered together, the separate functions make sense to think about in terms of different 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 (TE): The TE leverages multiple data sources to compute a trust score weighing this against a particular request or action. This trust score can be thought of as an assessment5 of the trustworthiness of allowing a particular request/action (or in other words the associated risk of allowing the action), which the PDP uses to make an ultimate authorization decision. The PDP uses the trust score produced by the TE as an additional component by which an authorization decision can be made.6 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 2. Trust, trustworthiness, trust algorithms and trust scores will be covered in more detail in Section 3.

Policy Stores: The policy store is a (centralized) repository where all access control policies based on the Zero Trust security model are stored, allowing for consistent and granular7 management of who can access what resources and what verification is required, enabling storage of access policies. 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 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 Points (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. These 4 In networking terminology, the control plane refers to the part of the network that manages policies and makes routing decisions, while the data plan is the part of the network that is responsible for moving the data according to the rules specified by the control plane.

5 Generally numeric but does not have to be.

6 Googles BeyondCorp is the first to pioneer this technology [19], [20]

7 Policies can be described at very detailed levels such as access based on user identity, types of identity verification, device posture, user location, access request time, and other contextual factors, enabling fine-grained access control as necessary.

7 sources can be classified into the following categories, extended from NIST SP 1800-35B to include categories appropriate for the OT environment:

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 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 - including communication paths and networks - and continuously monitoring those assets and networks to actively respond to threats or malicious activity.

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 Resource Protection: This category includes components that do not necessarily fit into the other categories. They can include components that serve as proxies for a resource or otherwise protect the resource through monitoring and control.

o User, Device, and Network Inventory: Having an accurate asset inventory is a necessary aspect for any security framework, including Zero Trust. However, categorization of the assets from a consequence-based safety perspective is critical for applying ZTA using a graded approach described in nuclear safety and security specifications and guidance.

This component is NRC staffs addition to the framework. It addresses the need to know if the device is a safety, important-to-safety or security device. This is not addressed significantly in any other Zero Trust reference yet is very important for nuclear security.

Understanding the safety or security function performed by protected devices is required for performing a criticality analysis needed to apply adequate protection (e.g.,

vulnerability management and continuous monitoring). This PIP component aids in answering the knowing what you have question, aligns with the Identify function of the NIST Cybersecurity Framework [21], and ties with the pillars of Zero Trust in OT [4].

The data plane has the following logical components:

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 Portable Media and Mobile Devices kiosk. However, the difference between a PEP and, for example, a traditional firewall is that it should have automated integration with the PDP so that it can respond quickly to any policy changes [16].

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 ZTA. Because these components have distinct responsibilities and are considered the fundamental functions of any ZTA, it is recommended that they are treated as distinct systems

[16]. A more detailed discussion of the access control framework in Zero Trust and its associated concepts are presented in Section 3.

8

2. Security Control Guidance for Zero Trust Many nuclear facilities have CSPs that implement tailored version of cybersecurity controls found in guidance such as NRC RG 5.71 [7] or NEI 08-09 [6] and IEC 63096 Nuclear power plants - Instrumentation, control and electrical power systems - Security controls [22]. These tailored selected sets of cybersecurity controls may not include controls listed in general cybersecurity guidance, such as NIST SP 800-53 Security and Privacy Controls for Information Systems and Organizations [19] and consequently are not implemented in the licensees CSP.

Examples of NIST SP 800-53 cybersecurity controls needed to implement Zero Trust but may not have been included in the current cybersecurity guidance for nuclear facilities include:

access control decisions, continuous monitoring, information location, digitally signed software, and adaptive authentication. This section of the report will identify additional cybersecurity controls to include in CSPs to implement Zero Trust at nuclear facilities.

2.1 Selecting NIST SP 800-53 Security Controls for ZTA The security controls in NIST SP 800-53 are organized into families. Families of controls contain base controls and control enhancements, which are directly related to their base controls.

Control enhancements either add functionality or specificity to a base control or increase the strength of a base control. Control enhancements are used in systems and environments of operation that require greater protection than the protection provided by the base control.

The security controls in NIST SP 800-53 are particularly suitable for tailoring for ZTA at nuclear facilities because this NIST guidance document is updated every 3-4 years, which is more frequently than other security standards and guidance documents, and thus the controls in NIST SP 800-53 are timely and can be used to implement the most current, best security practices.

RG 5.71 contains a tailored set of NIST SP 800-53 security controls to be used in a CSP to protect nuclear facilities from cyberattacks. The base controls and/or control enhancements listed in the current version of NIST SP 800-53 can be added to CSPs based on RG 5.71 or similar guidance for nuclear facilities to implement features of ZTAs at nuclear facilities. The following sub-sections list the new base controls or control enhancements from NIST SP 800-53 that can be incorporated in CSPs to implement features of ZTA at nuclear facilities. The following controls from NIST SP 800-53 were selected based on their applicability to specific capabilities to ZTA core concepts and functions. This highlighted controls in this section are not all-inclusive. There may be other cybersecurity requirements for nuclear facilities - such as security controls for incident response and contingency planning - that may be required in a CSP but are not directly related to security features of ZTA. Therefore, the following listed controls should be considered as only a subset of the security controls captured in a CSP.

2.1.1 Access Control The basic controls and control enhancements in this family can be used to implement the ZTA principle of 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.

9 Dynamic privilege management (AC-2 (6))8 Support dynamic approaches for runtime access control decisions, such as attribute-based access control. This security control supports the dynamic policies in a ZTA.

Dynamic access management (AC-2 (8)) Includes the creation, activation, and deactivation of system accounts by establishing trust relationships, rules, and mechanisms with appropriate authorities to validate related authorizations and privileges.

Account monitoring for atypical usage (AC-2 (12)) May reveal rogue behavior by individuals or an attack in progress.

Disable accounts for high-risk individuals (AC-2 (13))

Assert and enforce application access (AC-3 (12))

Revocation of access authorization (AC-3 (8)) Enforces the revocation of access authorizations resulting from changes to the security attributes of subjects and objects Restrict access to specific information types (AC-3 (11)) Restricts access to specific information is intended to provide flexibility regarding access control of specific information types within a system. Examples include restricting access to cryptographic keys, authentication information, and selected system information.

Dynamic information flow control (AC-4 (3))

Security policy filters (AC-4 (8)) Block; Strip; Modify; Quarantine data Domain authentication (AC-4 (17)) For attribution; the ability to identify source and destination points for information flowing within systems allows the forensic reconstruction of events and encourages policy compliance by attributing policy violations to specific organizations or individuals.

Remote Access (AC-17) Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed Managed Remote Access Points (AC-17 (3)) Route remote accesses through authorized and managed network access control points since limiting the number of access control points for remote access reduces attack surfaces.

Wireless Access (AC-18) Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and authorize each type of wireless access to the system prior to allowing such connections.

Access Control Decisions (AC-24) Mechanisms to ensure access control decisions are applied to each access request prior to access enforcement.

2.1.2 Audit and Accountability The basic controls and control enhancements in this family can be used to implement the ZTA principle of Scrutinize Explicitly: requests, actions, and behavior are continuously monitored.

Audit Record Review, Analysis, and Report (AU-6) Includes adjusting the level of audit record review, analysis, and reporting within the system when there is a change in risk 8 Following the format in NIST SP 800-53, each control is given a unique designation of XX-number where XX denotes the control family and number is the unique identifier of that control within the family.

Additionally, if the control has enhancements, it is given as (plus enhancements). For example, AC-2(6) refers to the enhancement, Dynamic Privilege Management, for specific control Account Management (AC-2) in the Access Control (AC) Family.

10 based on law enforcement information, intelligence information, or other credible sources of information.

Cross-Organizational Audit Logging (AU-16) Employ methods for coordinating audit information among external organizations when audit information is transmitted across organizational boundaries.

2.1.3 Assessment, Authorization, and Monitoring The basic controls and control enhancements in this family can be used to implement the ZTA principle of Scrutinize Explicitly: requests, actions, and behavior are continuously monitored.

Information Exchange (CA-3) Approve and manage the exchange of information between the system and other systems Continuous Monitoring (CA-7) Continuously monitor users, networks, and devices to detect potential cybersecurity events [23].

o Trend Analysis o Risk Monitoring o Consistency Analysis 2.1.4 Configuration Management The basic controls and control enhancements in this family can be used to implement the ZTA principle of Scrutinize Explicitly: requests, actions, and behavior are continuously monitored.

Automation Support for Accuracy and Currency (CM-2 (2))

Access Restrictions for Changes (CM-5) Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system Least Functionality (CM-7)

System Component Inventory (CM-8)

Data Action Mapping (CM-13) Develop and document a map of system data actions.

NIST uses this for personally identifiable information (PII), but it can be used for OT data and data related to nuclear material Signed Components (CM-14) 2.1.5 Contingency Planning The basic controls and control enhancements in this family can be used to implement the ZTA principle of Security Maintains Safety: the security decisions and enforcement of the decisions must not affect the safety-related and important-to-safety functions of the facility.

Safe Mode (CP-12) Can be activated either automatically or manually, restricts the operations that systems can execute when those conditions are encountered. Restriction includes allowing only selected functions to execute that can be carried out under limited power or with reduced communications bandwidth. An analogous control would be secure mode, which restricts the operations that can take place based on security conditions.

Alternative Security Mechanisms (CP-13) Employ alternative or supplemental security mechanisms for satisfying security functions when the primary means of implementing the security function is unavailable or compromised. Or, for Zero Trust, when the trust level changes.

11 2.1.6 Identification and Authentication The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principles of Scrutinize Explicitly: requests, actions, and behavior are continuously monitored; and 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.

Device Identification and Authentication (IA-3)

Identifier Management (IA-4) Applies to individual, group, role, service, or device Authenticator Management (IA-5) Used to verify the identity of the individual, group, role, service, or device Service Identification and Authentication (IA-9)

Adaptive Authentication (IA-10)

Identity Proofing (IA-12) o Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines o Resolve user identities to a unique individual; and o Collect, validate, and verify identity evidence 2.1.7 Planning The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principles of 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; and Security Maintains Safety: the security decisions and enforcement of the decisions must not affect the safety-related and important-to-safety functions of the facility.

What actions are needed to establish trust as part of the defensive architecture and defensive security strategy?

System Security Plans (PL-2) Scoped to the system and system components within the defined authorization boundary and contain an overview of the security requirements for the system and the controls selected to satisfy the requirements.

Rules of Behavior (PL-4) Represents a type of access agreement for organizational users.

Concept of Operations (PL-7) Developed for the protected systems describing how the organization intends to operate the system from the perspective of security.

Security Architectures (PL-8)

Central Management (PL-9) 2.1.8 Program Management The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principles of 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; and Presume Breach: assume breach has already occurred in your network. How is the security posture of the protected networks and devices assessed?

12 System Inventory (PM-5)

Measure of Performance (PM-6) Develop, monitor, and report on the results of outcome-based metrics of security performance and the effectiveness of the security program.

Insider Threat Program (PM-12)

Threat Awareness Program (PM-16)

Continuous Monitoring Strategy (PM-31) 2.1.9 Risk Assessment The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principle of Security Maintains Safety: the security decisions and enforcement of the decisions must not affect the safety-related and important-to-safety functions of the facility.

Security Categorization (RA-2)

Risk Assessment (RA-3)

Criticality Analysis (RA-9) Identify critical system components and functions by performing a criticality analysis 2.1.10 Systems and Services Acquisition The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principle of Assume Hostile Environment: this applies to both inside and outside the nuclear power plant (NPP) and implies that initially all users, devices, and networks are untrusted. What are the actions needed to establish trust levels? The following are enhancements for the Security Engineering Principle (SA-8) that are significant for ZTA:

Trusted Components (SA-8 (9)) The principle of trusted components states that a component is trustworthy to at least a level commensurate with the security dependencies it supports (i.e., how much it is trusted to perform its security functions by other components).

Hierarchical Trust (SA-8 (10)) The principle of hierarchical trust for components builds on the principle of trusted components and states that the security dependencies in a system will form a partial ordering if they preserve the principle of trusted components.

Inverse Modification Threshold (SA-8 (11)) The principle of inverse modification threshold builds on the principle of trusted components and the principle of hierarchical trust and states that the degree of protection provided to a component is commensurate with its trustworthiness. As the trust placed on a component increases, the protection against unauthorized modification of the component also increases to the same degree.

Protection from unauthorized modification can come in the form of the components own self-protection and innate trustworthiness, or it can come from the protections afforded to the component from other elements or attributes of the security architecture (to include protections in the environment of operation).

Minimized Security Elements (SA-8 (13)) The principle of minimized security elements states that the system does not have extraneous trusted components. The principle of minimized security elements has two aspects: the overall cost of security analysis and the complexity of security analysis. Trusted components are generally costlier to construct and implement, owing to the increased rigor of development processes.

Trusted components require greater security analysis to qualify their trustworthiness.

13 Thus, to reduce the cost and decrease the complexity of the security analysis, a system contains as few trustworthy components as possible. The analysis of the interaction of trusted components with other components of the system is one of the most important aspects of system security verification. If the interactions between components are unnecessarily complex, the security of the system will also be more difficult to ascertain than one whose internal trust relationships are simple and elegantly constructed. In general, fewer trusted components result in fewer internal trust relationships and a simpler system.

Predicate Permission (SA-8 (15)) The principle of predicate permission states that system designers consider requiring multiple authorized entities to provide consent before a highly critical operation or access to highly sensitive data, information, or resources is allowed to proceed.

Trusted Communication Channels (SA-8 (18))

Continuous Protection (SA-8 (19))

Self-Analysis (SA-8 (21)) The principle of self-analysis states that a system component is able to assess its internal state and functionality to a limited extent at various stages of execution, and that this self-analysis capability is commensurate with the level of trustworthiness invested in the system.

Accountability and Traceability (SA-8 (23))

2.1.11 System and Communications Protection The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principles of 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; and Presume Breach: assume breach has already occurred in your network.

Boundary Protection (SC-7 basic control) o Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system.

o Implement subnetworks for publicly accessible system components that are

[Selection: physically; logically] separated from internal organizational networks; and o Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.

o Deny by Default, allow by exception (SC-7 (5))

o Dynamic isolation and segmentation (SC-7 (12)) The capability to dynamically isolate certain internal system components. It is useful when it is necessary to partition or separate system components of questionable origin from components that possess greater trustworthiness. Component isolation reduces the attack surface of organizational systems. Isolating selected system components can also limit the damage from successful attacks when such attacks occur.

o Fail secure (SC-7 (18))

Trusted Path (SC-11)

Transmission of Security Attributes (SC-16)

Protection of Data at Rest (SC-28)

External Malicious Code Identification (SC-35) System components that proactively seek to identify network-based malicious code or malicious websites

14 Operations Security (SC-38) Highlights the OPSEC process that involves five steps:

identification of critical information, analysis of threats, analysis of vulnerabilities, assessment of risks, and the application of appropriate countermeasures.

Wireless Link Protection (SC-40)

Port and I/O Device Access (SC-41) Disabling or removing connection ports and I/O devices helps prevent the exfiltration of information from systems and the introduction of malicious code from those ports or devices. Physically disabling or removing ports and/or devices is the stronger action.

Sensor Capability and Data (SC-42) Applies to types of systems or system components characterized as mobile devices, such as cellular telephones, smart phones, and tablets.

Usage Restrictions (SC-43)

Sensor Relocation (SC-48 basic control)

Hardware-Enforced Separation and Policy Enforcement (SC-49)

Software-Enforced Separation and Policy Enforcement (SC-50)

Hardware-Based Protection (SC-51) 2.1.12 System and Information Integrity The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principles of 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; and Presume Breach: assume breach has already occurred in your network.

System Monitoring (SI-4) All control enhancements should be implemented Integrity Checks (SI-7 (1))

Automated Response to Integrity Violations (SI-7 (5))

Cryptographic Protections (SI-7 control enhancement)

Auditing Capability for Significant Events (SI-7 (6))

Verifying Boot Process (SI-7 (9))

Protection of Boot Firmware (SI-7 (10))

Code Authentication (SI-7 control (15))

Runtime Application Self-Protection (SI-7 (17))

2.1.13 Supply Chain Risk Management The highlighted basic controls and control enhancements in this family can be used to implement the ZTA principle of 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. What are the actions needed to establish trust levels?

Provenance (SR-4) Document, monitor, and maintain valid provenance of organization-defined systems, system components, and associated data Tamper Resistance and Detection (SR-9) Anti-tamper technologies, tools, and techniques provide a level of protection for systems, system components, and services against many threats, including reverse engineering, modification, and substitution

15 2.2 Mapping Security Controls to ZTA components All controls should be incorporated into a part of the Zero Trust Reference Architecture, and no access control policy in the policy store should conflict with the controls implemented by the CSP.

Table 1 maps the security controls identified in section 2.2 to applicable ZTA components identified in section 2.1.

Table 1 - ZTA Components for Implementing Security Controls NIST Control PEP PDP TE Policy Information Points AC-2(6) Dynamic Privilege Management X

ICAM AC-2(8) Dynamic Account Management X

X ICAM AC-2(12) Atypical Usage X

Security Analytics AC-2(13) Disable account for high-risk individuals X

X Security Analytics AC-3(8)

Revocation of Access Authorizations X

X ICAM, Data Security AC-3(11) Restrict Access to Specific Information Types X

ICAM, Data Security AC-3(12) Assert and enforce application access X

X ICAM AC-4(3) Dynamic information flow control X

X X

Resource Protection, Security Analytics AC-4 (8) Security policy filters X

Data Security

16 NIST Control PEP PDP TE Policy Information Points AC-4 (17) Domain authentication X

ICAM, Endpoint Security, User Device Network Inventory AC-17 (3)

Managed Remote Access Points X

X User Device Network Inventory AC-18 Wireless Access X

X User Device Network Inventory AC-24 Access Control Decisions X

ICAM AU-6 Audit Record Review, Analysis, and Report Security Analytics AU-16 Cross-Organizational Audit Logging Security Analytics CA-3 Information Exchange X

Data Security CA-7 (3) Trend Analysis X

Security Analytics CA-7 (4) Risk Monitoring X

Security Analytics CA-7 (5)

Consistency Analysis X

X Security Analytics CM-2 (2)

Automation Support for Accuracy and Currency Endpoint Security, User Device Network Inventory CM-5 Access Restrictions for Changes X

X Endpoint Security CM-7 Least Functionality Endpoint Security, User Device Network Inventory CM-8 System Component Inventory User Device Network Inventory

17 NIST Control PEP PDP TE Policy Information Points CM-13 Data Action Mapping Data Security CM-14 Signed Components Endpoint Security, Data Security CP-12 Safe Mode X

Security Analytics, User Device Network Inventory CP-13 Alternative Security Mechanisms X

X Security Analytics, User Device Network Inventory IA-3 Device Identification and Authentication X

ICAM IA-4 Identifier Management X

ICAM IA-5 Authenticator Management X

ICAM IA-9 Service Identification and Authentication ICAM, Endpoint Security IA-10 Adaptive Authentication X

X ICAM, Security Analytics IA-12 Identity Proofing ICAM PL-2 System Security Plans X

PL-4 Rules of Behavior X

PL-7 Concept of Operations X

PL-8 Security Architectures X

PL-9 Central Management X

ICAM PM-5 System Inventory User Device Network Inventory

18 NIST Control PEP PDP TE Policy Information Points PM-6 Measure of Performance Security Analytics PM-12 Insider Threat Program Security Analytics, User Device Network Inventory PM-16 Threat Awareness Program Security Analytics PM-31 Continuous Monitoring Strategy Security Analytics RA-2 Security Categorization User Device Network Inventory RA-3 Risk Assessment X

User Device Network Inventory RA-9 Criticality Analysis X

User Device Network Inventory SA-8 (9) Trusted Components X

User Device Network Inventory SA-8 (10)

Hierarchical Trust X

SA-8 (11) Inverse Modification Threshold X

SA-8 (13)

Minimized Security Elements X

User Device Network Inventory SA-8 (15)

Predicate Permission X

X SA-8 (18) Trusted Communication Channels X

SA-8 (19)

Continuous Protection X

Endpoint Security, Data Security SA-8 (21) Self Analysis X

Endpoint Security

19 NIST Control PEP PDP TE Policy Information Points SA-8 (22)

Accountability and Traceability X

SC-7 Boundary Protection X

X Security Analytics, Resource Protection, User, Device, and Network Inventory SC-7 (5) Deny by Default X

X ICAM SC-7 (12) Dynamic isolation and segmentation X

X X

Security Analytics SC-7 (18) Fail Secure Endpoint Security, Data Security SC-11 Trusted Path X

X User, Device, and Network Inventory SC-16 Transmission of Security Attributes X

Data Security SC-28 Protection of Data at Rest X

Data Security; User, Device, and Network Inventory SC-35 External Malicious Code Identification X

Resource Protection, Security Analytics SC-38 Operations Security X

Security Analytics SC-40 Wireless Link Protection X

User, Device, and Network Inventory; Data Security SC-41 Port and I/O Device Access X

Endpoint Security SC-42 Sensor Capability and Data Endpoint Security; User, Device, and Network Inventory SC-43 Usage Restrictions X

Security Analytics SC-48 Sensor Relocation X

Security Analytics, Resource Protection SC-49 Hardware-Enforced X

Resource Protection

20 NIST Control PEP PDP TE Policy Information Points Separation and Policy Enforcement SC-50 Software-Enforced Separation and Policy Enforcement X

Resource Protection SC-51 Hardware-Based Protection X

Endpoint Security SI-4 System Monitoring X

Security Analytics SI-7 (1) Integrity Checks X

Endpoint Security, Resource Protection SI-7 (5) Automated Response to Integrity Violations X

Security Analytics SI-7 (6)

Cryptographic Protections X

Data Security, Endpoint Security SI-7 (8) Auditing Capability for Significant Events X

Security Analytics SI-7 (9) Verifying Boot Process X

Endpoint Security, Resource Protection SI-7 (10) Protection of Boot Firmware X

Endpoint Security, Resource Protection SI-7 (15) Code Authentication X

Endpoint Security, Resource Protection SI-7 (17) Runtime Application Self-Protection X

Endpoint Security, Resource Protection SR-4 Provenance X

Endpoint Security, Resource Protection SR-9 Tamper Resistance and Detection X

Endpoint Security, Resource Protection

21

3. Trust and Access Control in Zero Trust In a ZTA, especially one that is based on the Reference Architecture depicted in Figure 2, a trust score is used to make authorization decisions associated with a resource access request.

The trust score reflects the potential risk associated with granting the request [24], [25].

This section examines how trust scores are used in access control and policy decisions. It then ventures into the area of the concept of trust and related concepts. From there, this section examines the trust algorithm that is used to calculate a trust score and discusses what should be considered when calculating trust scores.

3.1 Access Control Access control is a key component in Zero Trust, requiring the application of least privilege and strict authentication. All power reactor licensees are required to create and abide by their NRC-approved CSP. The CSP describes how the licensees cybersecurity program meets the NRCs requirements to protect its digital computer and communication systems and networks against cyber-attacks, including those associated with SSEP functions. Therefore, any access control rules created by the licensees to grant permission to resources should not conflict with anything in the CSP.

When developing access control rules for the ZTA, the access control requirements in the CSP (Security Control Family B.1 in RG 5.71 [7] or Security Control Family D.1 in NEI 08-09 [6]) and also those described in section 2.1.1 of this paper, should be addressed. In other words, the CSP defensive architecture governs the overarching security policy, and Zero Trust access control policies are just a subset (e.g., specific implementation of a security requirement).

In section 1.2 we reviewed the core concepts in a ZTA and the Zero Trust Reference Architecture in a Nuclear Facility (Figure 2) from previous work documented in Task 2 [5]. In this section, we focus on how the components in the ZTA work together to make an access control decision.

The access request would flow as follows (Figure 3):

1. Initial access request from the user to access the protected device (identify and credentials provided with request) is directed to the PEP

2. The PEP forwards the request to the PE with the needed credentials to verify subject and resource

3. The PE requests and receives information needed to determine whether to approve or deny the request from the following sources:

a. Policy store: retrieve the policy for accessing this resource

b. Trust Engine: trust score for requesting user and device 3.b.i The Trust Engine gets information from various PIP sources needed to calculate the trust score (more details on the trust score in section 3.3)

c. PIPs: to determine specific conditions and circumstances that may affect policy decision.

22

4. After receiving information from step 3 and authenticating the subject, determining what the subjects authorizations are, evaluating all the information, the PE decides whether to approve the request (to allow or deny the subject access to the requested resource).

5. The PA gets the access authorization decision from the PE and informs the PEP of the decision, so that the PEP can establish a session between the subject and resource if access has been granted. The PA will also provide instructions and requirements for session setup/teardown

6. Enable access (if allowed from above decision)

Figure 3. ZTA Reference Architecture with Access Control Flow All these requests should be logged (for proper incident response and forensic analysis as needed, as well as to update dynamic trust scores of the devices and users) including the access decisions made (and the associated device identifier and user identity associated with the request). Furthermore, these logs may be captured in the PIPs and used in subsequent access control decisions.

3.1.1 Access Control Policies in Zero Trust As seen above, access control decisions are based on frameworks and rules that determine who can access what and under what conditions. An access control policy, or just policy, is a set of high-level rules and requirements that dictate who can perform an action on (i.e. access) an organizations data, systems, and/or applications, how they can access them, and under what circumstances they can be accessed [24], [25], [26]. In access control parlance, permissions are concepts that allow or disallow access to a particular resource. The entities requesting the action are called the subject9 and can be human, system, application or a combination. The object that the subject is requesting access to is referred to as the resource 9 Sometimes also called the principal.

23 and the specific activity they are requesting to perform is called the action. The circumstances and restrictions under which the subject is allowed to access the resource is called the condition.

Mapping these concepts to the Zero Trust Reference Architecture in Figure 2, the (access control) subjects are the users (both human and non-human devices), and the resources are the protected devices.

A policy statement is a formal description of a single permission. A general (high level) syntax of policy statements may look like:

Allow <subject> <action> to <resource>

Allow <subject> <action> to <resource> with <conditions>

Deny <subject> <action> to <resource >

Deny <subject> <action> to <resource > with <conditions>

For example, if a nuclear power plant had a policy that explicitly denies access to a certain group of people: people in the management department cannot write to the programmable logic controller (PLC) and grants access to another group, it may look like:

Deny <users in Management> <read_access> to <PLC device Schneider Electric BMX P34 20302 v2.6 >

Allow <users in Operations department> <write_access> to <PLC device>

A policy is a collection of one or more policy statements [25], [27]. In a Zero Trust model, a typical policy requires that both the user and the device have a specified minimum combined trust score to gain access to a critical digital asset (i.e., the protected resource). This minimum trust score requirement can be stated in the form of the <condition>. Access is granted based on the calculated "trust score," which reflects the combined trustworthiness of both the user and the device attempting to access the resource. Whether the trust scores are computed separately and then combined, or a separate trust score threshold is specified for the device and user is implementation dependent. In this way, the policy ensures that only those who meet or exceed a certain threshold of trust are permitted access. Such a policy may be expressed as such:

Allow read access to the resource if the user is an engineer and the users trust score is greater than or equal to 80.

Allow <user in Engineer group> <read_access> to <resource> if

<trust score >= 80>

A Zero Trust system must be able to describe and enforce identity and context-sensitive dynamic policies [25]. When developing policies for implementation in a ZTA, the following properties should be considered [24], [28]:

Level of granularity: the level of granularity will vary based on the maturity of the network and the security requirements, but the policy that is scoped as close to the individual

24 resource being secured. This is similar to the concept of segmenting the network to decrease the attack surface [16].

Separation of policy and implementation details: when developing the policy, keep in mind that the policy needs to be divorced from implementation details and the specific technical methods used to execute it. Essentially, the intent of the policy should not be tied down to any single implementation strategy. This enables flexibility of the execution method without having to change the intent of the policy. For example, if the policy requires that user identities need to be verified, the implementation details could range from verifying through a challenge-response, a password, or biometric or a combination of these.

Use of trust scores in the policy: Zero Trust supports policies with dynamic trust. Trust scores can represent trust of the user. By defining policy with a trust score component, facilities are able to mitigate risk that otherwise cannot be captured without enumerating every possible circumstance. The considerations of creating a trust score itself will be considered in section 3.2.2.

Policies and CSP: any access control policies created by the licensees to grant permission to resources should not conflict with anything in their NRC-approved CSP.

The policy statements should reflect the defensive architecture and defense-in-depth protective strategy employed by the licensee as well as the different access control deployment models that are described in section 3.1.2.

3.1.2 Access Control Deployment Models Per 10 CFR 73.54(c)(2), the licensee must design its cybersecurity program to apply and maintain integrated defense-in-depth protective strategies to ensure the capability to detect, prevent, respond to, mitigate, and recover from cyberattacks [14]. An acceptable defense-in-depth protective strategy comprises a defensive architecture and a defensive strategy that employs multiple, diverse, and mutually supporting tools, technologies, and processes to effectively perform timely detection of, protection against, and response to a cyberattack.

Figure 4 shows an example of an acceptable cybersecurity defensive architecture from RG 5.71

[7]. This defensive architecture includes five concentric cybersecurity defensive levels separated by security boundaries, such as firewalls and diodes, at which digital communications are monitored and restricted. Systems requiring the greatest degree of security are located within the most secure level of the defensive architecture. When one-way communication is required in the defensive architecture, hardware characteristics that enforce unidirectional communication feature(s) (e.g., the use of a unidirectional/non-software-based link that is connected to a transmitter in the higher security level and a receiver in the lower security level) are the preferred means of implementation. The logical model shown below does not always correspond directly with the physical locations such as the vital, protected, or owner-controlled areas.

25 Figure 4. Simplified cybersecurity defensive architecture In the Task 2 TLR, where to place the ZTA core components within this defensive architecture was discussed. The report suggested two options: a centralized deployment model and a federated deployment model [5].

In the centralized model, the ZTA core components - with the exception of PEPs - are within a single security level (designated Level ZT) as shown in Figure 5. 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.

26 Figure 5. Centralized Deployment Model In the federated deployment model, 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 6.

Figure 6. Federated Deployment Model 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

27 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.

The access control policy needs to reflect the defensive architecture, and the implementation of a centralized or federated deployment model for the ZTA components. We can incorporate the cybersecurity defensive architecture into the policies by incorporating the levels into the policy statements. For example, blanket statements such as all devices in level 1 can read data from level 2 and all devices in level 2 can read data from level 2 can describe permissions on a per-level basis. However, more granular policies may describe permissions per device and per resource: the PLC in Level 2 can read data from the Yokogawa recorder (a CDA) in Level 3.

3.2 The Concept of Trust Trust is a very complex concept and difficult to define. For the scope of this research, trust is the certainty level and assurance that an entity assigns to another entity (devices, users, systems, data and processes) to act as they are required/expected [29], [30]. Users must be able to trust that their data is secure, and that systems will function as intended.

The following properties should be considered when implementing trust [28]:

Subjective: the level of trust that one associates with another is not the same for each entity. This is particularly applicable to trust of a personal nature where Bob may trust Alice, but Carol may trust Alice less.

Asymmetric: To trust is not the same as to be trusted: just because a resource is trusted to behave as expected, it does not mean that the resource will trust a device trying to connect to it in the same way10.

Dynamic: trust generally has to be earned, and once earned it is not static. It is rare that the trust level of an entity remains the same: trust can be increased as an entity continues to behave as expected or can be diminished if it does not. Trust relationships can also be established only for a specified time period. After that period, devices may need to re-establish themselves by providing their password or other form of identification.

Context dependent: The type of trust we assign to an entity must be clearly specified.

For example, if set up properly, we may expect/trust a wireless access point (WAP) to allow verified wireless-capable devices to connect to the network, but we would not trust it to provide antivirus capabilities - that would be expected of a device with anti-virus software, such as a component in a Security Information and Event Management (SIEM). Sometimes, the context may be influenced by external sources. For example, we may trust a WAP to enable secure wireless connections in normal circumstances, but our confidence in that trust may be affected if we are aware of several zero-day attacks associated with WAPs.

Full trust: it is not possible to wholly trust an entity to function as intended (or behave as expected) all the time, and under any circumstances. This is one of the reasons to implement a defense-in-depth strategy for cybersecurity.

10 In other contexts, such as sociology, the asymmetry of trust can refer to the principle that trust is hard to create but easy to destroy.

28 Transitive: this means that trust can be extended to flow between domains. A common example of this is single sign-on (SSO). With SSO, when a user authenticates on one system within a trusted domain, they can automatically access other systems within that same domain without needing to re-enter their credentials. This is because transitive trust relationships are assigned. Supply chain protections is another area where transitive trust relationships may exist.

In an implementation of ZTA, whether to adopt these properties and how to implement them should be considered in the context of the cybersecurity program. For example, whether to adopt and implement the transitive property (and any of these properties) should be decided with caution and for each circumstance. For example, an organization may characterize trust as transitive within their supply chain but may not support transitive trust between different trust domains within the organization.

3.2.1 Trust, Trustworthiness, and Risk Trustworthiness refers to the quality of being reliable and deserving of trust [29]. In cybersecurity, a systems trustworthiness is often assessed through its design, implementation, and operational practices. Factors such as security protocols, transparency, and user feedback contribute to an entitys perceived trustworthiness. NIST defines trustworthiness as the degree to which an information system (including the IT components that are used to build the system) can be expected to preserve the confidentiality, integrity, and availability of the information being processed, stored, or transmitted by the system across the full range of threats [8]. A trustworthy information system is believed to operate within defined levels of risk despite the environmental disruptions, human errors, structural failures, and purposeful attacks that are expected to occur in its environment of operation.

Others define trustworthiness as well-founded assessment of the extent to which a given system, network, or component will satisfy its specified requirements, and particularly those requirements that are critical to an enterprise, mission, system, network, or other entity.

Trustworthiness is meaningful only with respect to those expectations]. [30]

The relationship between trust and trustworthiness is inherently reciprocal yet nuanced. Trust is built upon the perception of trustworthiness. If a system or entity is deemed trustworthy, users are more likely to engage with it. Conversely, if a system fails to demonstrate trustworthiness (e.g., through security breaches), trust diminishes. However, while trustworthiness is a constant thing, the level of trust one associates to a trustworthy entity may be different.

Risk in cybersecurity is often defined as the potential for loss or damage when a threat exploits a vulnerability. It encompasses the likelihood of an event occurring and the impact of that event on information assets. Understanding risk is essential for making informed decisions about security measures.

Risk is associated with the ability to meet a set of requirements or to successfully accomplish a mission. Regarding cybersecurity and nuclear security, the requirement is to adequately protect digital computers and communication systems associated with safety, security, and emergency preparedness functions from a cyber-attack. There may be a change in the risk determination due to allowing or prohibiting access by a user or device to a protected device or system. The trustworthiness of users, devices, and networks impacts the nuclear facility operators ability to maintain a known good security posture for the facility. Qualitatively, a decrease in trust scores

29 increases the risk that adequate security cannot be maintained. Conversely, increasing the trust scores of users, devices, and networks implies a decrease of the associated risk and provides more assurance that adequate security can be maintained. A system that demonstrates high trustworthiness through strong security protocols, compliance with regulations, and transparent practices can reduce the perceived risk among users. For instance, regular security audits and certifications can enhance a systems trustworthiness, thereby lowering user concerns about potential risks.

Risk always exists, but trust must be earned and awarded. For example, within an NPP there may be an obsolete computer that perform a monitoring function on analog OT equipment. A licensee may assert that there is no need to apply security controls and make the equipment more trustworthy because there is no risk in the licensees ability to protect the equipment from a cyber-attack. However, risk does exist for attacks via various pathways - such as physical and wired connections - and sufficient security controls must be applied to achieve a sufficient trust score for the protections.

3.2.2 Trust Scores The trust score represents the level of trust assigned to a user, entity or piece of information. In the context of Zero Trust, it is a value calculated for the entities (human and non-human) that attempt to access resources. Calculation of the trust score is done by a trust algorithm which analyzes various factors (i.e. trust attributes) such as past behavior, scan results of the devices, and other relevant metrics to determine the level of trust to associate to that entity.

In a ZTA, trust is represented by a trust score that is generated by the trust engine.

Trustworthiness can be determined by the security posture and calculated based on security controls applied to a user (e.g., training, behavior analysis), network (e.g., access requests to questionable websites), or device. The trustworthiness of users, devices, and networks impacts the nuclear facility operators ability to maintain a known good security posture for the facility.

Qualitatively, a decrease in trust scores increases the risk that adequate security cannot be maintained. Conversely, increasing the trust scores of users, devices, and networks decreases the risk and provides more assurance that adequate security can be maintained.

In Zero Trust, trust is dynamic: it can change from one day to another, or in this case, from one access request to another, depending on how the trust score is calculated.

The following are some examples of how trust scores can be used in policy statements.

Policy Example 1: separate calculation of user and device trust scores Grant Access to <Protected Device (resource) e.g. a PLC identified as a CDA>: If (User Trust Score >= 80 AND Device Trust Score >= 80) Else Deny Access.

Policy Example 2: based on combined calculation of user and device trust score Grant Access to <CDA> If ((User and Device Combined) Trust Score >=

80) Else Deny Access.

Policy Example 3: More granular description of types of access

30 Grant READ Access to <CDA> If ((User and Device Combined) Trust Score

>= 80) Else Deny Access.

Policy Example 4: requesting additional information (in this example, the policy requests the user to provide additional information about their identity. Implementation details may recalculate the trust score based on this additional information and determine access at that time Grant Access to <CDA> If ((User and Device Combined) Trust Score >=

80) Else Request <additional identity verification> from User.

3.2.3 Trust Algorithms According to NIST, the trust algorithm is the process used by the policy engine to ultimately grant or deny access to a resource [3]. The trust algorithm is a set of rules and calculations used to continuously evaluate the trustworthiness of every user, device, and application attempting to access resources. The algorithm evaluates the trustworthiness of these user/devices/apps in real-time to produce a trust score. Trust engine is sometimes used synonymous with trust algorithm [25], [28], [31].

3.2.3.1 Classification of Trust Algorithms NIST provides different ways to implement a trust algorithm based on how the factors are evaluated (criteria vs score) and whether it takes into account the subject history when making the evaluation (contextual vs. singular) [3].

Criteria vs. Score-based trust algorithms Criteria-based trust algorithms assess a set of attributes/criteria that are defined ahead of time and must be met before access to a resource is granted, or an action (e.g. read, write or execute) is allowed. Access is only granted if every specified criterion is met. For example, for a user to access the Yokogawa recorder in level 3, the criteria may be that the user device meet a set of performance metrics, the device has been scanned within the past month and meets security compliance requirements, and there are no active attacks on the network. These criteria must be independently configured for every resource and the criteria that has to be met may be different for every user making the request or the type of request. Instead of generating a single score, this approach involves evaluating and comparing different criteria individually to make a decision about trust - trustworthiness of an entity is not distilled into a single score but is evaluated against a checklist of relevant factors that can also be weighted according to their importance.

Score-based trust algorithms compute a confidence level based on values for every data source and enterprise-configured weights. If the score is greater than or equal to the configured threshold value for the resource, access is granted, or the action is performed. This is the trust score discussed in section 3.3.1. In this case, the criteria listed in the previous example could all be incorporated as factors (data sources) for the algorithm. In a score-based trust algorithm, the weights would have to be decided upon - does each data source have equal importance, or does one contribute more to the trustworthiness of an entity? If so, how much more does it contribute?

31 Compared to score-based trust algorithms that condense all relevant factors into one score, criteria-based trust algorithms provide more richness and detail that helps show why a user is considered trustworthy or not. However, they may be more difficult to set up, since the criteria that needs to be met needs to be pre-determined for every case. In addition, this approach may require more input from operators, particularly in setting the criteria and adjusting them over time.

Contextual vs. Singular trust algorithms Singular Trust algorithms treat each request individually and do not take the subject history into consideration when making its evaluation.

Contextual Trust algorithms take the subject or network agents recent history into consideration when evaluating access requests.

Contextual trust algorithms allow for better dynamic trust assessments but may require more complexity as they rely on continuous monitoring and logging to support history and past behavior.

Regardless of what type of trust algorithm, when developing a trust algorithm, some things to consider are:

Which factors to include and how to weigh them How the factors are evaluated: is each factor evaluated as a binary decision or weighted as part of the whole score Most of the trust attributes will be collected from the PIP. The algorithm should determine what constitutes sufficient level of evidence for trustworthiness - for example, how many pieces of evidence are required for identity verification? If the minimum is not met, then the trust score will not be as high as possible.

How are requests from one subject evaluated in relation to other requests by the same subject, application or device.

Will there be a combined trust score for human user + device, or a separate trust score for each.

Some common score-based trust algorithm approaches are [26], [27], [32]:

Weighted Sum: this method is one of the simplest and most intuitive methods for trust evaluation. It calculates a composite trust score by summing individual factors that influence trust, where each factor is assigned a specific weight based on its (perceived) importance. The final trust score is the sum of these weighted values, providing an aggregated trust level.

Bayesian inference: a probabilistic approach that allows systems to update their beliefs about an entitys trustworthiness based on new evidence. This is done using Bayes' Theorem, which combines prior trust beliefs (based on previous interactions) with new data (such as successful or failed interactions). The result is a posterior probability, which provides an updated measure of trust. For example, a users trust score may increase after a series of successful access requests. Bayesian Inference enables the system to continuously refine its trust values over time as more evidence is accumulated. The strength of Bayesian models lies in their ability to manage uncertainty

32 and adapt trust assessments dynamically, making them ideal for systems where trustworthiness is subject to change.

Fuzzy logic: fuzzy logic can be used when trust values are uncertain, imprecise, or difficult to quantify. For example, in one system, trust may depend on factors like reputation and behavior, which can be vague or subjective. Using fuzzy logic, these can be transformed into fuzzy sets, and rules can be defined to combine them into a final trust score. The ability to deal with vagueness and imprecision makes fuzzy logic particularly useful in real-world systems where trust assessments are not always clear-cut.

Machine Learning : In supervised learning, algorithms are trained on labeled data (e.g.,

successful and unsuccessful interactions) to predict future trust values for entities based on various features [16], [28]. Unsupervised learning approaches, such as clustering, can group entities into different levels of trust without pre-labeled data. Moreover, reinforcement learning techniques can also be employed, where the trust engine learns to adjust the trust model based on rewards/penalties that results from the access control decision. While the acquisition and correct labeling of training data is important in machine learning models, the main advantage of these approaches is their adaptabilitymodels continuously improve as they receive more data, making them ideal for environments that evolve over time.

Biba and Bell-LaPadula: These are access control models, primarily used in security-focused systems to ensure data integrity and confidentiality, respectively. These models define rules that indirectly influence trust relationships by ensuring that sensitive data is protected against unauthorized disclosure or tampering.

o The Biba Model focuses on data integrity and enforces "no write up" (a subject cannot write data to a higher integrity level) and "no read down" (a subject cannot read data at a lower integrity level). Trust in this model is based on ensuring that data is not modified by untrusted or lower-level subjects.

o The Bell-LaPadula Model focuses on confidentiality and enforces two key policies:

"no read up" (a subject cannot access data at a higher security level) and "no write down" (a subject cannot write data to a lower security level). This model maintains trust by ensuring that sensitive information does not leak to lower levels of clearance.

3.2.3.2 Trust Attributes This section briefly provides a list of some factors that developers may want to consider when developing their own trust algorithms [24], [26], [32]. This is not an exhaustive list - other factors may also be considered, and some users may not include all the factors listed here in their implementations.

(Human) User Attributes o Strength of the authentication method o Normalcy of authentication behavior pattern (considers history): including things such as day, time, geolocation of subject making the request, access frequency, and determining if this is normal for the user.

o Trusted behavior (past experiences, especially if using a context-aware trust algorithm) o General user profiling: Some of this may be a bit futuristic - mapping whether a user is on vacation or leave, if they had several consecutive failed logon

33 attempts, just reset their password, if their input behavior (e.g. typing speed) is unusual, etc.

o Association of device to user: Is this a common device that the user is associated with or one they are using for the firs time (i.e., not recognized by the system)

(Non-Human) User Attributes o Device compliance:

Operating System Version: does the device have an up-to-date operating system with security patches applied System patch level Software patch level: how up to date is the software on this device Antivirus status: is antivirus software installed, active, and up to date Encryption: is the hard drive encrypted Device security status: can use endpoint detection and response (EDR) tools to assess there are no active threats and no exploited vulnerabilities on the device Device fingerprint: this is a unique identifier for a device that can be used to detect if its a new device or seen before, providing identity for the device itself Vulnerability scan: when was the last one, what are its results o Device Type: laptop, smartphone, other type of OT device; managed device, etc.

o Device authentication method Password, token, certificate, etc.

o Overall device health measures the current hardware conditions, such as CPU load, response time, etc.

o Trust history (past behavior, contextual): has this device ever been associated with known threats, vulnerabilities, did it ever have malware installed on it.

Resource Attributes: While resource information would be used for determining what the threshold trust score should be in the policy statement, and not for determining the trust score of a user, it is shown here just for consideration of overall policy.

o Criticality of the resource: From a nuclear standpoint, is it a critical digital asset (CDA)? What type of critical asset is it (direct, indirect, Balance of Plant); does it support the function of a CDA or critical system?

o Access request type: whether access request is read, write, or gain administrative privileges. Elevated privileges may be a sign of suspicious behavior and may conflict with the least privilege concept closely associated with Zero Trust.

Network Attributes o Security of the network: determined via security event logs o Security incident history: how often is the network (or devices on the network) a target of outside attackers.

o Security of the communication channel: if applicable, encryption algorithm being used o Current cybersecurity posture of the network (health) o External info:

Real-time threat intelligence: known bad actors, attacks on similar targets across the nation, etc.

34

4. Maturity Model Considerations 4.1 Applying Zero Trust in Operating Nuclear Power Plants 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 increase the 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-informed manner. The operating NPP should have a known good security posture. Adding Zero Trust to mitigate security issues with introducing new or novel use of technologies will help to maintain the known good state of the NPP. In addition, operating NPPs may have experience using certain security features of Zero Trust - such as multi-factor authentication, managed remote access points, and continuous monitoring of users, devices, and networks - that may not be employed in their OT networks but are employed in their business networks or at non-nuclear energy generating plants. The lessons learned from use of these security features will assist in adapting the features in OT networks. Cross functional teams consisting of IT engineers and OT engineers designing and implementing Zero Trust features in OT systems will be crucial for the successful implementation of Zero Trust. Figure 7 illustrates a four-step process for evaluating and managing risk when implementing new technologies.

Figure 7-Risk Management Cycle for Introducing New Technologies Step 1. Evaluate new cybersecurity risks. The risks introduced by the new technology (e.g.,

drones, wireless monitoring or access, AI) should be evaluated by assessing the vulnerabilities associated with devices, networks, and new plant procedures to implement the technology. For example, information obtained by plant surveillance drones should be protected. Data confidentiality, access control, and data integrity of the surveillance information must be addressed. Common vulnerabilities associated with access and configuration management of new devices should also be explored, including a devices ability to detect vulnerabilities or the insertion of malware or viruses. The plant operator should determine how use of the new

35 technology would affect the current security defensive strategy and architecture, and whether aspects ZTA - such as wireless or remote operation - would be needed to securely implement the technology.

Step 2. Update cybersecurity policies and processes. Plant operators should evaluate their cybersecurity policies and processes to identify ambiguity for use of the new technology (e.g.,

Industrial Internet of Things (IIoT), drones, or AI). Because these devices are most likely obtained from suppliers, NPP owners may need to enhance their existing supply chain risk management program to vet the supplier and the devices before procuring and deploying the devices. Establishing the trustworthiness of devices begins at this step. If ZTA will be established or updated with regards to the new technology, determine which aspects of the ZTA will be used to securely implement the technology. For example, implementation of wireless technology would likely require implementation of a wireless intrusion detection system which would implement the PEP and some PIP functions. The NPPs supply chain security should implement risk management best practices for the delivery of the technology (hardware, software, and firmware), such as vetting the suppliers cybersecurity practices and determining whether the device incorporates cyber security into its design (e.g., ability to manage device configurations and access, ability to identify emerging vulnerabilities, malware protection and detection).

Step 3. Implement new mitigating controls. After identifying vulnerabilities of devices, additional security measures can be implemented to mitigate risks and new threat vectors. Risk mitigation strategies include protection of data, software, firmware, and wired or wireless communication that are needed for the emerging technology device to function. The NPP should implement its existing methods to manage accounts, access, and authorizations for these devices, including encryption methods to protect data and communications. Downloading software patches and testing these devices should also be done in a separate network (sandbox) to reduce the possibility of adversely impacting the NPPs operation and network. If mitigation cannot be addressed by implementing security controls directly on the device itself, operators may also decide to implement security features within the plant environment to mitigate the risk of deploying the emerging technology.

Step 4. Monitor Security Controls. New security measures that have been implemented for the devices should be monitored for effectiveness to identify new risks. Equipment or applications to monitor specialized communications, such as IIoT and wireless, or to scan devices using emergent technologies may be needed for the secure maintenance of the technology. These are examples of security controls to establish and maintain the trustworthiness of the devices.

4.2 Applying Zero Trust in New Nuclear Power Plants For new NPPs, using Zero Trust will help to establish the known good state of the NPP from initial operation and incorporating Security by Design in the early phases of a NPP development life cycle. This research task on Zero Trust modifies the digital safety systems development process in IEEE Std 7-4.3.2-2016 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 8. Figure 8 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 [12].

36 Figure 8 - Security Development Life Cycle adapted from IEEE Standard 7-4.3.2-2016 Usually during the Product or Feature Concept phase (for example if remote operation is considered an essential feature) or during the Security Architecture Development phase, a decision should be made whether to implement ZTA. Based on this decision, a selected set of ZTA security requirements (noted as security controls in 2.1 of this report) are established.

Equipment is procured during the System Design phase.

It is during the Product or Feature Concept, Security Requirements, Other System Requirements, and System Design phases that tradeoffs will be made between security, safety, and performance requirements. OT and safety systems have high availability and reliability requirements. The complexity of the features used to implement systems - such as wireless technology, remote access, and automation or AI - would require different security measures to achieve sufficient trustworthiness. Adequate security measures may conflict with OT operational requirements and therefore, additional risk analyses and tradeoffs may be necessary to select features and design a system that meet security, safety, and performance requirements.

The ZTA security requirements should be tested and verified during the System Validation and Verification phase. For more information about actual devices and use case implementations of ZTA, refer to NIST SP 1800-35 Implementing a ZTA: High-Level Document [33].

5. Implementation Considerations This section provides more details for a development process to implement a ZTA. This includes identifying issues that need to be considered and how to pick specific implementations and supporting technologies, such as logical/conceptual and technical methods for establishing and determining a devices trustworthiness, techniques for determining a devices attack surface and vulnerabilities, and practical methods for maintaining the security posture of the nuclear facility.

37 5.1 Concepts and Considerations to Establish Trustworthiness During the security architecture development phase, logical processes and services must be designed to support the ZTA concepts. This section lists a few examples:

5.1.1 Trust Relationship between the PDP and Identity Providers The PDP must be able to trust the credential related information it receives from the various identity providers. For nuclear security, this is particularly relevant for the access authorization process used to grant individuals access to nuclear facilities.

5.1.2 Device Inventory Service The Device Inventory Service is responsible for managing all the devices in the system. It continuously collects, processes, and publishes changes about the state of known devices as well as the ability to provide the latest known state of these devices. The continuous monitoring is imperative as an adversary may gain control of a device after a connection is established.

The state of the device is determined by processing a variety of data sources, such as vendor security alerts and Cybersecurity Advisories for CISA. This data is sent to the Trust Engine, which indicates whether the given device is trusted or not, by assigning a trust score. For this to work, each device must have a consistent, non-cloneable identifier, while information about the software, users and location of the device must also be integrated into the inventory database.

5.1.3 Microsegmentation Microsegmentation is a technique that enables fine-grained security polices to be assigned to data center applications, down to the workload level as well as devices. This means that security polices can be synchronized with a virtual network, virtual machine, operating system or other virtual security targets.

The potential difference from the Purdue model [34] is that groups, devices and resources are segregated, as opposed to segregation of levels in a hierarchical fashion. The hybrid solution in this research is to maintain segregation of security levels but provide additional segregation within each level (e.g. zones) among devices and resources, as is demonstrated in IAEA security guidance, Nuclear Security Series No. 17-T (Rev. 1), Computer Security Techniques for Nuclear Facilities [35]. This is especially important when introducing new or novel use of technologies within a security level. Effective implementation of segmentation can facilitate incident response and recovery and limit exposure of protected assets during attacks that exploited vulnerabilities of novel technologies.

5.1.4 Access Control Models When determining access control rules and policies, the developer should decide what aspect of the subject should be used in granting permission to access resources. In general, there are three types of ways to do this, each with its own set of pros and cons. Identity-based access control focuses on granting permission based on a users identity - e.g., Alice Wonderland can read Project Development Documentation. It focuses on verifying a users identity before granting access. Role-based access control (RBAC) grants permissions based on a users predefined role within an organization - e.g., Developers can read, write and execute files in the

38 Companys Central Code Repository. Attribute-based access control (ABAC) provides more granular control by considering various (user) attributes such as location, time security clearance in determining whether to grant permission - e.g., Tactical mobile unit team lead can access terrain maps if they are within striking distance of target and time to attack is less than 5 hours5.787037e-5 days <br />0.00139 hours <br />8.267196e-6 weeks <br />1.9025e-6 months <br />.

5.2 Technical Methods for Determining a Devices Trustworthiness 5.2.1 Hardware Roots of Trust A Root of Trust (RoT) is a foundational security component that provides a set of trustworthy functions that the rest of the device or system can use to establish strong levels of security. In NIST SP 800-164, Guidelines on Hardware-Rooted Security in Mobile Devices, NIST acknowledges the risk with software and software-based security [36]. Integrated as a chip in hardware, using a RoT gives devices a trusted source that can be relied upon within any cryptographic system. Trusted Platform Modules (TPMs) are components available on modern computing systems and facilitate several cryptographic, protected storage, and integrity capabilities. Secure implementation of use cases using TPMs include asset management, hardware supply chain security, boot integrity measurement, software supply chain auditing, runtime integrity measurement, and authentication and provisioning [37].

Device Identifier Composition Engine (DICE) is a hardware RoT used to protect the devices and components where a TPM would be impractical or infeasible. When a TPM is present, DICE is used to protect communication with the TPM and provides the Root of Trust for Measurement (RTM) for the platform. DICE was designed to close critical gaps in infrastructure and help to establish safeguarding measures for devices. The DICE RoT can also be easily integrated into existing infrastructure, with the architecture being flexible and interoperable with existing security standards. There are three key use cases for DICE [38]:

As the security architecture for resource constrained devices that dont contain a TPM, e.g., in IIOT and Edge devices As the hardware root of trust for components In more complex security architectures working together with TPM An example of where DICE is more suitable than a TPM is in smaller chips, such as a solid-state drive (SSD). DICE will securely generate cryptographic keys inside the SSD and provide strong device authentication to protect against supply chain attacks, as well as attestation to prevent any firmware tampering.

5.2.2 Blockchain Technology Blockchain technology uses a distributed digital ledger of cryptographically signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one after validation and undergoing a consensus decision. This technology can be used for manufacturing supply chain traceability and integrity [39], [40].

Particularly relevant for nuclear security, an ecosystem perspective of the manufacturing supply chain could be used to define provable traceability for a subset (an ecosystem) of the manufacturing supply chain stakeholders (e.g., suppliers, critical infrastructure operators), and

39 to share and store applicable product traceability data records (e.g., pedigree, provenance).

Traceability requirements and their means of implementation will be unique for each ecosystem (e.g., microelectronics, operational technology, critical infrastructure).

5.2.3 Field Programmable Gate Arrays Field Programmable Gate Arrays (FPGAs) are integrated circuits (ICs) containing programmable logic components that can be reconfigured to implement logic functions [41].

They have recently been used in various safety and non-safety systems in nuclear power plants. Applicants for SMRs and advanced reactors have also proposed incorporating FPGAs as an element of their engineering designed features for cybersecurity protections. The nuclear industry has made claims that FPGAs have a much smaller attack surface than microprocessor-based systems and has done work in this area [42].

5.2.4 Public Key Infrastructure and Certificates Public Key Infrastructure (PKI) is defined as the architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a certificate-based public key cryptographic system. This framework establishes the policies for issuing, maintaining, and revoking public key certificates. Unlike private key cryptosystems that rely on a secret private key, public key cryptography relies on key pairs - one publicly known key for encryption and one private key for decryption - where is computationally infeasible to generate one key from the other. PKI is the technology used to issue digital certificates.

Digital certificates are issued and digitally signed by a certification authority (CA). The process of proving identity when issuing the certificates, auditing the certification authorities, and the cryptographic protections of the digital signatures establish the basis of trust for digital certificates.

Four core capabilities of PKI are [43]:

Trust with government agencies and industry Support for technical non-repudiation Authentication and encryption Digital signatures These four capabilities are necessary for basic security functions such as facilities access, network and user authentication, digital document sharing, and encrypted digital communications.

5.3 Techniques for Understanding the Attack Surface System hardening involves configuring a protected device to provide only essential functions needed to operate within the facility. The determination of the essential functions should take place during the protected device and/or network security assessment, and the documented security assessments should reflect the system hardening measures. Benefits provided by system hardening include a smaller attack surface - which would minimize vulnerabilities that an attacker could exploit - and a reduction in the amount of data that needs to be monitored and

40 analyzed when assessing the security posture of the protected asset or system. An electronic scan of a digital device can be performed to determine an accurate baseline of components within a digital device. After a device has been hardened, the device can be enrolled in an automated configuration management and vulnerability management program prior to using it in an operational environment. The hardened devices and communications should be continuously monitored to ensure that the security controls remain effective, and that the cybersecurity policy is being enforced. A well-tuned SIEM should be used to generate, detect, analyze, and report adherence to or violation of the cybersecurity policy. In addition to continuous monitoring, on-going identification, evaluation, and mitigation of newly discovered vulnerabilities and threats should be performed. More discussion of a methodology to evaluate risk, attack surfaces and vulnerabilities, and mitigations can be found in section 4 of this technical report.

System developers and operators should use the best practices for evolving and novel use of technologies such as wireless, remote operations, and autonomous operations as these technologies are more widely introduced in OT systems.

5.4 Methods for Maintaining Security Posture of the Nuclear Facility The first step to maintaining the security posture of a nuclear facility is to have an accurate inventory of the protected assets required to execute the SSEP functions of the facility.

Understanding vulnerabilities that can affect the security posture of these protected assets is essential for the protection of the assets. The identification and prioritization of vulnerabilities can be challenging. At a minimum, known and exploited vulnerabilities should be addressed, and ongoing threat intelligence can be used to help prioritize what vulnerabilities should be addressed.

Test beds and digital twins of critical systems can be used to verify the effectiveness of security controls against evolving cyber-attacks and exploited vulnerabilities. The outcome of such testing should be stored in one or more of the components of the PIP and transmitted to the Trust Engine for generation of trust scores.

The change in trust scores of assets that are used to protect other assets (such as firewalls for segmentation or SIEMs for attack detection) should be especially noteworthy because the potential compromise of such protective devices would have significant impact on the security posture of the facility and affect the system operators ability to adequately protect the SSEP functions during a cyber-attack.

System operators should make use of any engineered design security features of a device that will not adversely impact an SSEP function. Designers and developers of digital devices have the best insight into what it takes to secure the device; any security features they engineered into the product should be prioritized by system operators and incorporated into the overall defensive security strategy of the nuclear facility. An example would be a feature where a device would report the result of security tests that are run periodically or on-request. The report results would be stored in one or more of the components of the PIP and transmitted to the Trust Engine for generation of trust scores.

41

6. Conclusion and Future Work This report is a culmination of the work performed as part of the RES FFR initiative. This project provided three TLR as deliverables:

Task 1 TLR provided a literature review of Zero Trust. It revealed the lack of focus on Zero Trust for an OT environment and identified the need to examine it separately, due to the unique nature of OT environments. The report described the Zero Trust principles for OT environments at nuclear facilities. It defined the principles and defined pillars which were restated in Section 1 of this report.

Task 2 TLR build upon the principles identified in Task 1 to form the foundation of a security life cycle model. 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, how each would be realized so that they meet the regulatory requirements, and how to apply Zero Trust principles without adversely impacting safety. The technical report also discussed the interface between cybersecurity and physical security and examined how a Zero Trust implementation can impact the physical security strategy.

The Task 2 report also provided the steps to deploying a ZTA (within the framework of an SDLC):

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.

This Task 3 TLR provides guidance on how to implement a ZTA in an OT environment.

Specifically, it focuses on the security controls that need to be addressed. It examines the trust algorithm and considerations in developing a methodology and utilizing trust scores with ZTA. In addition, this report discusses the important linkage between trustworthiness of a device or system and the risk associated with the nuclear facilitys ability to successfully protect SSEP functions from a cyber-attack. This report also highlights some logical and technical methods for implementing certain portions of the ZTA.

Future work for this research could be the development of risk scores which are tied to the consequence for failed SSEP functions and the trustworthiness of devices, users, and networks/systems. A methodology to develop risk scoring will be useful for 10 CFR Part 53, Risk-Informed, Technology-Inclusive Regulatory Framework for Advanced Reactors [44], [45].

42 Several technologies have been identified as being potentially beneficial in realizing a ZTA.

These are homomorphic encryption and quantum communications technologies [46].

Homomorphic encryption technologies allow computations to be performed on encrypted data without having to decrypt it first. This allows data to remain secure and confidential while being processed. Research in quantum computing has made significant progress in ways to use quantum technologies for secure information storage and communication, such as the use of quantum key distribution to securely share encryption keys. These technologies may support ZTAs by providing robust encryption where secure communication channels (e.g. encrypted links) are required and may be able to assist with network segmentation. Future work can examine whether technologies with potential high-intensity processing requirements, increased hardware complexity, or computational overhead can be adopted in nuclear facilities.

43

7. Acronyms Acronym Full Form AI Artificial Intelligence CA Certificate Authority CDA Critical digital asset CFR Code of Federal Regulations CSP Cybersecurity Plan DAAF Data, Assets, Apps, Functions DICE Device Identifier Composition Engine FFR Future Focused Research FPGA Field Programmable Gate Array HMI Human Machine Interface IAEA International Atomic Energy Agency ICAM Identity, Credential, and Access Management IIoT Industrial Internet of Things 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 PKI Public Key Infrastructure PMMD Portable Media and Mobile Devices PLC Programmable Logic Controller RG Regulatory Guide RoT Root of Trust RTM Root of Trust for Measurement SIEM Security Incident and Event Management SMR Small Modular Reactor SSEP Safety, Security, and Emergency Preparedness SSO Single Sign On TE Trust Engine TLR Technical Letter Report TPM Trusted Platform Module WAP Wireless Access Point ZTA Zero Trust Architecture

44

8. References

[1]

ACT-IAC, Zero Trust Cybersecurity Current Trends, American Council for Technology-Industry Advisory Council (ACT-IAC), Apr. 2019. Accessed: Jun. 14, 2021. [Online].

Available: https://www.actiac.org/zero-trust-cybersecurity-current-trends

[2]

A. Kerman, Zero Trust Cybersecurity: Never Trust, Always Verify, Blog: NIST Taking Measure. Accessed: Aug. 01, 2022. [Online]. Available: https://www.nist.gov/blogs/taking-measure/zero-trust-cybersecurity-never-trust-always-verify

[3]

NIST, NIST Special Publication (SP) 800-207, Zero Trust Architecture, National Institute of Standards and Technology, Gaithersburg, MD, Aug. 2020. doi: 10.6028/NIST.SP.800-207.

[4]

A. Kim and K. Lawson-Jenkins, Technical Letter Report TLR-RES-DE-2023-001, Zero Trust for Operational Technology Literature Review, U.S. Nuclear Regulatory Commission, Washington, DC, Nov. 2022.(ADAMS Accession No. ML22333A895)

[5]

A. Kim and K. Lawson-Jenkins, Technical Letter Report TLR-RES-DE-2024-001, Zero Trust Architecture for Operational Technology at Nuclear Facilities, U.S. Nuclear Regulatory Commission, Washington, DC, Nov. 2023. (ML24051A074)

[6]

NEI, NEI 08-09, Revision 6, Cyber Security Plan for Nuclear Power Reactors, Nuclear Energy Institute (NEI), Washington DC, Apr. 2010.

[7]

U.S. Nuclear Regulatory Commission (NRC), Regulatory Guide (RG) 5.71, Revision 1, Cybersecurity Programs for Nuclear Power Reactors, Washington, DC, Feb. 2023.

(ML22258A204)

[8]

NIST, NIST SP 800-53, Rev. 5, Security and Privacy Controls for Information Systems and Organizations, National Institute of Standards and Technology, Gaithersburg, MD, Sept. 2020. [Online]. Available: https://doi.org/10.6028/NIST.SP.800-53r5

[9]

NIST, NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, National Institute of Standards and Technology, Gaithersburg, MD, Sep. 2023. [Online]. Available:

https://doi.org/10.6028/NIST.SP.800-82r3

[10] 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

[11] Cybersecurity and Infrastructure Security Agency (CISA), Zero Trust Maturity Model, Jun.

2021.

[12] IEEE, IEEE Std 7-4.3.2-2016 Standard Criteria for Programmable Digital Devices in Safety Systems of Nuclear Power Generating Stations, (Revision of IEEE Std 7-4.3.2-2010), pp. 1-86, Aug. 2016, doi: 10.1109/IEEESTD.2016.7552419.

[13] NRC, RG 1.152 Revision 4, Criteria for Programmable Digital Devices in Safety-Related Systems of Nuclear Power Plants, Washington, DC, Jul. 2023. (ML23054A463)

[14] 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.

[15] CFR, Requirements for physical protection of licensed activities in nuclear power reactors against radiological sabotage., Section 55, Part 73, Chapter 1, Title 10, Energy.

[16] E. Gilman and D. Barth, Zero trust networks: building secure systems in untrusted networks, First edition. Beijing Boston Farnham Sebastopol Tokyo: OReilly, 2017.

[17] NERC, Zero Trust Security for Electric Operations Technology, North American Electric Reliability Corporation, White Paper, Jun. 2023.

[18] NIST, NIST SP 1800-35B, Implementing a Zero Trust Architecture, Volume B: Approach, Architecture, and Security Characteristics, National Institute of Standards and Technology, Gaithersburg, MD, Jul. 2023.

[19] R. Ward and B. Beyer, Beyondcorp: A new approach to enterprise security, 2014.

45

[20] B. Osborn, J. McWilliams, B. Beyer, and M. Saltonstall, Beyondcorp: Design to deployment at google, 2016.

[21] NIST, Cybersecurity Framework 2.0. [Online]. Available:

https://doi.org/10.6028/NIST.CSWP.29

[22] IEC, IEC 63096 Edition 1.0, Nuclear power plants - Instrumentation, control and electrical power systems - Security controls, International Electrotechnical Commission, Oct. 2020.

[23] NIST, NIST SP 1800-10, Protecting Information and System Integrity in Industrial Control System Environments, National Institute of Standards and Technology, Gaithersburg, MD, Mar. 2022.

[24] T. Lukaseder, M. Halter, and F. Kargl, Context-based access control and trust scores in zero trust campus networks, presented at the SICHERHEIT 2020, Gesellschaft für Informatik eV, 2020, pp. 53-66.

[25] J. Garbis and J. Chapman, Zero Trust Security An Enterprise Guide, 1st ed. Apress, 2021.

[26] L. Bradatsch, O. Miroshkin, N. Trkulja, and F. Kargl, Zero Trust Score-based Network-level Access Control in Enterprise Networks, presented at the 2023 IEEE 22nd International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), IEEE, 2023, pp. 1422-1429.

[27] E. S. Hosney, I. T. A. Halim, and A. H. Yousef, An artificial intelligence approach for deploying zero trust architecture (zta), presented at the 2022 5th International Conference on Computing and Informatics (ICCI), IEEE, 2022, pp. 343-350.

[28] W. Najib and S. Sulistyo, Survey on trust calculation methods in Internet of Things, Procedia Computer Science, vol. 161, pp. 1300-1307, 2019.

[29] M. Winstead, Trustworthiness and Assurance, presented at the 26th Annual NDIA Systems & Mission Engineering Conference, Norfolk, VA, Oct. 2023.

[30] P. G. Neumann, Achieving Principled Assuredly Trustworthy Composable Systems and Networks., presented at the DISCEX (2), 2003, pp. 182-187.

[31] C. Buck, C. Olenberger, A. Schweizer, F. Vlter, and T. Eymann, Never trust, always verify: A multivocal literature review on current knowledge and research gaps of zero-trust, Computers & Security, vol. 110, p. 102436, 2021.

[32] Y. He, D. Huang, L. Chen, Y. Ni, and X. Ma, A survey on zero trust architecture:

Challenges and future trends, Wireless Communications and Mobile Computing, vol.

2022, no. 1, p. 6476274, 2022.

[33] NIST, NIST SP 1800-35, Implementing a Zero Trust Architecture: High-Level Document, National Institute of Standards and Technology, Gaithersburg, MD, Dec. 2024.

[34] M. J. Assante and R. M. Lee, The industrial control system cyber kill chain, SANS Institute InfoSec Reading Room, vol. 1, no. 1, p. 2, 2015.

[35] 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

[36] NIST, NIST SP 800-164, Guidelines on Hardware-Rooted Security in Mobile Devices (draft), National Institute of Standards and Technology, Gaithersburg, MD, Oct. 2012.

Accessed: Apr. 01, 2024. [Online]. Available:

https://csrc.nist.gov/publications/search?keywords-lg=800-164

[37] National Security Agency (NSA), Trusted Platform Module (TPM) Use Cases, ver. 1, NSA, Fort Meade, MD, U/OO/237306-24 l PP-24-4228, Nov. 2024. 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

[38] Trusted Computing Group, What is a Device Identifier Composition Engine (DICE).

Accessed: Dec. 10, 2024. [Online]. Available: https://trustedcomputinggroup.org/what-is-a-device-identifier-composition-engine-dice/

46

[39] NIST, Interagency/Internal Report NIST IR 8419, Blockchain and Related Technologies to Support Manufacturing Supply Chain Traceability: Needs and Industry Perspectives, NIST, Gaithersburg, MD, Apr. 2022. [Online]. Available:

https://doi.org/10.6028/NIST.IR.8419

[40] L. Alevizos, V. T. Ta, and M. Hashem Eiza, Augmenting zero trust architecture to endpoints using blockchain: A stateoftheart review, Security and Privacy, vol. 5, no. 1, Art. no. 1, 2022.

[41] Committee on National Security Systems, Committee on National Security Systems (CNSS) Glossary, Committee on National Security Systems, Fort Meade, MD, Unclassified CNSSI No. 4009, Apr. 2015.

[42] Benjamin Karch, Titus Gray, and Michael T. Rowland, SAND2024-14666R, Field Programmable Gate Array-Based Reactor Protection Systems and Potential for Inclusion of Secure Elements to Improve Cybersecurity, Sandia National Laboratories, Sep. 2024.

[43] Federal Public Key Infrastructure 101, ID Management. Accessed: Dec. 10, 2024.

[Online]. Available: https://www.idmanagement.gov/university/fpki/

[44] NRC, Rulemaking Plan on Risk Informed, Technology-Inclusive Regulatory Framework for Advanced Reactors (RIN-3150-AK31; NRC-2019-0062), Commission Report SECY-20-0032, Apr. 2020. [Online]. (ML19340A056)

[45] NRC Staff, Proposed Rule: Risk-Informed, Technology-Inclusive Regulatory Framework for Advanced Reactors, SECY-23-0021, Mar. 2023.

[46] CISA, Space Systems Security and Resilience Landscape: Zero Trust in the Space Environment, U.S. Cybersecurity and Infrastructure Security Agency (CISA), Apr. 2024.