Text

Methodology for the Assessment of Alternate Control Timing Approaches (TLR-RES/DE/ICEEB-2026-003)
	ML26028A152
Person / Time
Issue date:	01/28/2026
From:	Barro B, Bowden J, Michael Brown, Cottrell K, Doug Eskins, Alan Konkal, Kim Lawson-Jenkins, Eric Lee, Marshall T; NRC/RES/DE, Oasis Systems
To:	;
	Kaitlynn Cottrell 4154040
Shared Package
TLR-RES/DE/ICEEB-2026-003	List: ML26028A152;
References
	TLR-RES/DE/ICEEB-2026-003
	Download: ML26028A152 (0)
	v • d • e

i TECHNICAL LETTER REPORT TLR-RES/DE/ICEEB-2026-003 Methodology for the Assessment of Alternate Control Timing Approaches December 2025 Division of Engineering Office of Nuclear Regulatory Research U.S. Nuclear Regulatory Commission Washington, DC 20555-0001 D. Eskins, E. Lee, K. Cottrell, K. Lawson-Jenkins, M. Brown, T. Marshall U.S. Nuclear Regulatory Commission A. Konkal, B. Barro, J. Bowden Oasis Systems, LLC

i This page intentionally left blank.

ii DISCLAIMER This Technical Letter Report (TLR) does not contain or imply legally binding requirements. Nor does this report establish or modify any regulatory guidance or positions of the U.S. Nuclear Regulatory Commission (NRC) and is not binding on the Commission.

This report was prepared as an account of work sponsored by an agency of the United States government. Neither the United States government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States government or any agency thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States government or any agency thereof.

The cybersecurity controls referenced in this TLR are from the NRCs Regulatory Guide (RG) 5.71, Cybersecurity Programs for Nuclear Power Reactors, Rev. 1, dated February 2023. If a control referenced in this TLR is no longer listed in the latest version of RG 5.71, the control was removed in response to Executive Order (EO) 14300, Ordering the Reform of the Nuclear Regulatory Commission. This TLR considers those controls that enhance or strengthen a robust defense-in-depth protective strategy, requirements related to cybersecurity controls and cybersecurity periodicities may be made based on the licensees evaluation in accordance with their cybersecurity plans.

iii This page intentionally left blank.

iv TABLE OF CONTENTS ACKNOWLEDGMENTS............................................................................................................. 1 ACRONYMS.............................................................................................................................. 3

1.

BACKGROUND.............................................................................................................. 5

2.

OBJECTIVES AND SCOPE........................................................................................... 6

3.

ASSUMPTIONS AND LIMITATIONS.............................................................................. 6 3.1 Assumptions................................................................................................................... 6 3.2 Limitations...................................................................................................................... 8

4.

RESEARCH APPROACH............................................................................................... 8 4.1 Establish the Problem Space.......................................................................................... 8 4.2 Identify Use Cases......................................................................................................... 9 4.3 Identify Technical and Regulatory Basis for ACTA.......................................................... 9 4.4 Identify New Technical Basis Needed............................................................................. 9 4.5 Develop Novel Concepts, Terminology, and Domain Model...........................................10 4.6 Develop Tools................................................................................................................10

5.

RESEARCH RESULTS.................................................................................................10 5.1 Novel Terminology and Concepts..................................................................................10 5.1.1 Change Dependance of Cyber Assurance..................................................................... 11 5.1.2 Time Dependance of Cyber Assurance......................................................................... 11 5.1.3 Net Cyber Assurance.....................................................................................................12 5.2 CSP Domain Model (Influence Diagram).......................................................................13 5.2.1 CSP Domain Relationship Levels..................................................................................15 5.2.2 CSP Related Programmatic and Performance Views....................................................15 5.2.3 CSP Domain Characteristics.........................................................................................17 5.3 ACTA Flowchart.............................................................................................................17

6.

RESEARCH INSIGHTS.................................................................................................18

7.

RECOMMENDATIONS FOR ACTION...........................................................................19

8.

RECOMMENDATIONS FOR FUTURE RESEARCH.....................................................19

9.

CONCLUSION..............................................................................................................20 APPENDIX A.

DEFINITION OF TERMS...............................................................................21 APPENDIX B.

REFERENCES..............................................................................................25 APPENDIX C.

ACTA FLOWCHART AND EXAMPLES..........................................................26

v This page intentionally left blank.

1 ACKNOWLEDGMENTS The authors would like to acknowledge the hard work and commitment of all contributors to the research. The authors would also like to thank Sergiu Basturescu, Jim Beardsley, Christopher Cook, Mario Fernandez, and Roy Hardin from the U.S. Nuclear Regulatory Commission and Trace Colman, James Hartman, Michael Shock, Charles Simpson, and Sandra Smith from Oasis Systems, LLC for their support and review of the report.

2 This page intentionally left blank.

3 ACRONYMS ACTA Alternate Control Timing Approach CCCDD Configurations, Conditions, Capabilities, Data, and Documentation CFR Code of Federal Regulations CSP Cybersecurity Plan DBT Design Basis Threat FACT Factors Affecting Control Timing ICS Industrial Control System IDPRR Identify, Protect, Detect, Respond, and Recover NEI Nuclear Energy Institute NIST Nation Institute of Standards and Technology NPP Nuclear Power Plant NRC Nuclear Regulatory Commission PMC Properties, Methods, and Coupling PTOM Physical, Technical, Operational, and Management RG Regulatory Guide SOC Security Operations Center SP Special Publication SSC Structure, System, and Component SSEP Safety-related, important-to-safety, Security, and Emergency Preparedness TLR Technical Letter Report

4 This page intentionally left blank.

5

1. BACKGROUND Nuclear power plant (NPP) facilities, licensed by the U.S. Nuclear Regulatory Commission (NRC), are required to be protected from cyberattacks by Title 10 of the Code of Federal Regulations (CFR) 73.54 Protection of Digital Computer and Communication Systems and Networks. These cyber protection requirements are described in Regulatory Guide (RG) 5.71, Revision 1, Cyber Security Program for Nuclear Reactors, in which a licensee must provide reasonable assurance1 that digital computer and communication systems and networks are adequately protected against cyberattacks, up to and including the Design Basis Threat (DBT),

as described in 10 CFR 73.1, Purpose and Scope.

Consistent with 10 CFR 73.54(a)(1), licensees must protect digital computer and communication systems, and certain support systems and equipment, from cyberattacks, which, if compromised, would adversely impact the safety-related, important to safety, security, and emergency preparedness (SSEP) functions of a nuclear facility. The requirement can be paraphrased with emphasis on key terms: a licensee must provide reasonable assurance of adequate protection of plant equipment against adverse impacts to SSEP functions.

While SSEP functions are generally well defined by a NPPs technical and regulatory basis, terms such as reasonable assurance, adequate protection, and adverse impacts are not as explicitly quantified. These terms may require significant discussion and judgment among NRC and licensee staff to achieve a common understanding. This Technical Letter Report (TLR) provides a framework for more rigorous and explicit discussion of these terms and introduces the term cybersecurity assurance (or simply cyber assurance) to describe the outcomes relevant to the cyber protection requirement.

Licensees meet the cyber protection requirement by providing, establishing, implementing, and maintaining an NRC-approved cybersecurity plan (CSP). The CSP may detail, among other things, the intents, elements, processes, and outcomes required to establish a licensees cybersecurity program that meets regulatory requirements.

Guidance for industrys development and implementation of a CSP is provided in two primary documents:

NRC RG 5.71, Cyber Security Program for Nuclear Reactors Nuclear Energy Institute (NEI) document 08-09, Cyber Security Plan for Nuclear Power Reactors These documents provide an NRC-acceptable template that can be used by a licensee to develop a site-specific CSP.

Each licensee's CSP contains their commitments to address all the baseline cybersecurity controls. The controls are processes, actions, or measures that safeguard digital assets that affect SSEP functions. Controls must be verified for implementation and effectiveness according to specific criteria outlined in RG 5.71, Appendix B and C or NEI 08-092, Appendix D and E.

Some controls require periodic or event-based activities including activities to verify controls.

1 Throughout the publication of RG 5.71 Revision 1, the term high assurance is used in alignment with Commission policy statements that high assurance is equivalent to reasonable assurance of adequate protection.

2 NEI 08-09, Rev. 6, Addendum 1.

6 These periodic or event-based performance requirements will be collectively referred to in this report as requirements for control timing.

Licensees may modify an existing control, such as altering the configuration or timing of the control, and these changes may constitute implementation of an alternate control. Alternate controls must be developed, documented, analyzed, and implemented such that the alternate control provides at least the same level of cyber assurance as the existing control described in Section 3.1.6, of the licensees approved CSP. When an alternate control involves changes to control timing, the specific methods for developing, analyzing, and implementing these changes will be referred to in this report as Alternate Control Timing Approaches (ACTAs). Ideally an ACTA will:

identify all Factors Affecting (and affected by) Control Timing (FACT) relative to the alternate control; identify the relationships among the FACT and other plant elements; identify, analyze, and quantify the cyber assurance control application; and provide evidence and reasoning that the cyber assurance provided by the ACTA meets the reasonable assurance threshold.

Thus, an ACTA may provide a common framework to facilitate assessment of alternate controls involving control timing changes.

2. OBJECTIVES AND SCOPE The research in this TLR explores the technical basis to support the NRC assessment of an ACTA. Specifically, it develops a domain model, a methodology, criteria, and tools for rigorous and explicit discussion of concepts related to the assessment of 10 CFR 73.54 compliance concerning alternate controls that involve timing changes. The development of these elements focuses on creating a novel ACTA framework for identifying and understanding how control timing changes can affect elements of control implementation, other controls, and overall cyber assurance levels. Additionally, this research illustrates the framework with examples and the pilot tools that were developed for possible use as NRC staff aids.

Considered within the scope of this research are licensee CSPs, the approved guidance documents for developing CSPs (i.e., RG 5.71 and NEI 08-09), 10 CFR 73.54 and its associated requirements for cybersecurity outcomes, controls, and alternate controls that feature elements of control timing, and additionally, operating experience related to these areas.

This research does not propose a regulatory interpretation or guidance. Rather, it proposes a structured means by which NRC and other stakeholders may efficiently and effectively communicate issues related to ACTA.

3. ASSUMPTIONS AND LIMITATIONS 3.1 Assumptions The following assumptions were made when scoping the research for this TLR:

7

1. The relationships among plant elements identified by this research using RG 5.71 and NEI 08-09 will be generally applicable to any licensee cybersecurity program.

2. This research will identify and relate some FACTs, however, other FACTs relevant to desired cybersecurity outcomes may exist and a framework can be developed such that additional FACTs may be added to the framework later.

3. The cybersecurity domain model and FACTs identified by this research will be useful for evaluating ACTAs. Since the program domain model will capture general (e.g., not just timing-related) features, it is possible that the domain model may also be useful for evaluating alternate controls generally.

4. The ACTA screening process developed in this report will only identify FACTs. Other factors that may impact control implementation or effectiveness must be assessed using another process.

5. In accordance with 10 CFR 73.54, licensees are required to provide reasonable assurance that digital computer and communication systems and networks are adequately protected against cyberattacks.3 Currently, quantitative definitions for reasonable assurance, or its equivalent high assurance, are not available, and numerical measures for control implementations and their integrated impacts within cybersecurity programs are not feasible. However, a hybrid qualitative and loosely quantitative (ordinal) approach using influence arrows to map relationships and the influence (positive, negative, or neutral) of changes among CSP elements can provide a useful framework for characterizing cybersecurity assurance (e.g., assurance levels) and evaluating if reasonable assurance is maintained following changes to controls.

6. Control timing, both periodic and event-based, is specified for various controls by the guidance. The inclusion of control timing within the guidance implies that temporal aspects of controls are fundamental to the maintenance of reasonable assurance.

Furthermore, it is reasonable to conclude that the level of cyber assurance may decrease over time when an activity associated with control timing (e.g., a control review and/or update) is performed late or not performed at all.

7. There are a variety of activities associated with control timing, not just control verification, and all such activities must be considered within the scope of control timing impacts on cyber assurance.

8. To effectively characterize controls, multiple elements of the control implementation and the net impacts of the elements in relation to each other within a cybersecurity program must be addressed. A domain model may be a useful tool for identifying and relating the elements of a cybersecurity program.

9. Assessing the characteristics and relationships among control elements is important for evaluating the cyber assurance provided by an individual control and the net cyber assurance provided by an aggregate of controls. Additionally, evaluations of alternate controls must consider each control element and its relationship with other elements (or controls) as applicable to determine if reasonable assurance has been met.

3 10 CFR 73.54 (a)

8 3.2 Limitations The following were the limitations of scope or constraints of the research for this report:

1. The products of this research are referenced to this use case: Assessment of cybersecurity program controls of licensed nuclear facilities operating in the United States.

2. Research was conducted by a team with experience in nuclear cybersecurity research, operations, oversight, and regulatory basis. Insights were based on the teams operating experience, understanding, and interpretation of NRC requirements and the licensee programs used to meet these requirements.

3. While some controls have timing requirements that are either periodic or event-based, event-based controls do not typically specify time-based performance requirements for the post-event actions (e.g., how soon after an event an action must be performed).

Thus, the specific impacts of variations in post-event action timing cannot be explicitly considered by this research (though the general timing considerations of such actions can be accommodated as influences mapped in the domain model).

4. Theoretically, a performance-based view of a licensees cybersecurity program would include explicit criteria for assessing and evaluating licensee performance. However, criteria directly linked to measurements of authorized cybersecurity-related outcomes are currently rare in actual programs. Criteria indirectly linked to outcomes, such as verification of procedural compliance, are more common. Thus, plant examples of measurable performance-based criteria as described in this research will be difficult to identify. Where appropriate, indirect criteria may be used as a proxy for direct criteria with the understanding that such programmatic or prescriptive criteria do not directly measure the desired program outcomes.

4. RESEARCH APPROACH To perform the research for this report, an approach and methodology suitable for identifying issues to be addressed and a technical basis for addressing them was developed. The approach defines the problem space of interest and identifies:

use cases within the problem space; identifies the current technical and regulatory basis concerning the use cases; identifies where the new technical basis may be needed; proposes a novel terminology and domain model; and tools supportive of the new technical basis.

4.1 Establish the Problem Space Currently licensees develop and implement controls per commitments in their NRC-approved CSP. A CSP describes the multiple elements needed to implement a cybersecurity program, including controls and changes to CSP elements impacting controls that must be justified by providing a basis for how the changes, in aggregate, will provide the required (e.g., at least the same) cybersecurity outcomes as the existing CSP.

9 Changes to CSP elements can be categorized in multiple ways and changes that impact a controls periodic or event-based performance are categorized as control timing changes. In this research, when a control timing change results in the implementation of one or more alternate controls, then the licensees overall methodology for implementing the alternate control, including the related basis, analysis, and cybersecurity outcomes, will be referred to as an ACTA. Licensee ACTAs, just as any change to a CSP, are evaluated by NRC staff for regulatory compliance. The problem space considered for this report is the set of CSP elements and relationships relevant to the NRC evaluation of ACTA.

4.2 Identify Use Cases The use cases explored within the research problem space are those ACTA that are currently proposed, anticipated, or identified feasible by licensees. The cybersecurity inspection experience of NRC staff and contractors is leveraged to identify use cases related and relevant to ACTA. This approach develops a technical basis, methodology, and tools useful to NRC staff for evaluating the use cases within the ACTA problem space.

4.3 Identify Technical and Regulatory Basis for ACTA The regulatory basis scoped by this research includes the regulations establishing regulatory requirements for licensee cybersecurity programs such as 10 CFR 73.54 and industry guidance documents establishing NRC-approved methods for meeting the regulations such as RG 5.71 and NEI 08-09. For example, a method for a limited scope of ACTA is discussed in NEI 08-09 in Section 3.1.6, Mitigation of Vulnerabilities and Application of Cyber Security Controls4. The section discusses, among other things, a process for implementing alterative controls including alternative controls involving timing changes that mitigate the consequences of threat/attack vectors. The process includes documenting the basis, analysis, implementation, and outcomes for each alternate control.

4.4 Identify New Technical Basis Needed The process for implementing alterative controls specified in NEI 08-09 Section 3.1.6 generally addresses ACTA that mitigate the consequences of the threat/attack vectors of a given control.

In a practical sense, alternative controls should address, wholistically, all the plant elements and relationships among the elements such that overall risk of adverse impacts from a given cyberattack or class of attacks is mitigated. However, a framework supporting such a wholistic analysis does not exist within current guidance documents.

Ideally, the basis and analysis contained within any ACTA will justify an alternate control implementation that provides at least the same degree of cyber assurance (e.g., equivalent cybersecurity outcomes) as the previously implemented control. However, while the NEI guidance identifies elements that should be included in an ACTA, a methodology for identifying and developing the necessary basis, analysis, implementation, and outcomes is not explicitly provided. This gap identifies an opportunity for basis enhancement that decreases the effort for licensee justification and NRC evaluation of ACTA. A novel technical basis is proposed by this report to address this opportunity and provide an explicit, common framework for understanding and assessing ACTA.

4 NEI 08-09, Rev. 6, Appendix A, Section 3, p. A-8.

10 4.5 Develop Novel Concepts, Terminology, and Domain Model The technical basis developed by this report includes a novel terminology and domain model to capture and formalize concepts related to the objectives and outcomes of NRC cybersecurity regulations and guidance, and licensee CSPs. Concepts, such as cyber assurance levels, are made explicit to offer a method and context for linking cybersecurity programs to desired cybersecurity outcomes. The novel terminology will address gaps in existing technical basis by further developing the explicit and implicit ideas and assumptions contained within current technical and regulatory basis.

The domain model identifies, characterizes, and relates the relevant features of a CSP and is created by generalizing features detailed in RG 5.71 and NEI 08-09. The domain model uses multiple viewpoints and levels of abstraction to identify the factors affecting control timing and relate how changes to those factors propagate through the cybersecurity program.

4.6 Develop Tools The novel technical basis is used to inform the development of staff tools supportive of ACTA assessment. Tools include the CSPs domain model and the issue screening flowchart. Overall, the tools are targeted at enhancing staff identification and assessment of information related to ACTA. However, it is the licensees responsibility to ensure that the alternate controls and timings meet the requirements in their CSP.

5. RESEARCH RESULTS This research led to the development of novel terminology, concepts, and analytical tools designed to assess the adequacy of ACTAs. The application of these outcomes, as detailed in this section, enables stakeholders to more effectively evaluate whether ACTAs meet the reasonable assurance thresholds required for compliance with a licensees approved CSP.

5.1 Novel Terminology and Concepts A motherhood requirement for NRC cybersecurity regulations is the requirement to provide reasonable assurance that adverse impacts to SSEP functions from a cyberattack are prevented. The research for this report decomposed and clarified this requirement with the following definitions:

Cybersecurity (Cyber) Assurance: The confidence that a system is protected from successful cyberattacks. Cyber assurance is referenced to the system(s) protected, the attack(s) protected against, and the element(s) providing the protection (e.g., controls).

Thus, the triple (X, Y, Z) can be used to reference the cyber assurance provided by control X for SSEP function Y against attack Z and this concept can be extended to reference combinations of these elements. For example, the triple (X1 Xn, Y1Ym, Z1Zo,) references the cyber assurance provided by the set of n controls X1 through Xn, to the set of m SSEP functions Y1 through Ym, against the set of o attacks Z1 though Zo.

Cyber Assurance Level: The (quantified) amount of confidence that a system is protected from successful cyberattacks. To help understand this concept, if cyber assurance is considered a function of (X, Y, Z) then the cyber assurance level is the value of cyber assurance for a specific set of (X, Y, Z).

11 Reasonable Cyber Assurance Level: The level of assurance determined to be sufficient for preventing SSEP function adverse impacts. Reasonable cyber assurance is equivalent to reasonable assurance of the same.

5.1.1 Change Dependance of Cyber Assurance The triple (X, Y, Z) can be considered as a relationship (or function) where each value of (X, Y, Z) maps to a value of cyber assurance, e.g., a cyber assurance level. This concept provides a framework for discussing how a change in a control may impact the cyber assurance provided by that control. More specifically, if assurance is a function of (X, Y, Z), then a change in a control, X, may result in a change in assurance. Similarly, this framework allows us to consider how changes in SSEP functions, Y, and changes in attacks, Z, may also be considered for their impacts on assurance. An alternative control (represented by X with this notation) and can now explicitly be considered and discussed using this framework.

Note: Explicit numerical values for cyber assurance are not currently feasible, so absolute values for assurance will not be specified and changes to cyber assurance levels will be considered in this TLR solely in terms of magnitude and direction (e.g., a large or small negative or positive impact).

5.1.2 Time Dependance of Cyber Assurance Because the concept of time dependence is built into the description of controls (e.g., some controls involve actions that must be performed periodically), the concept of cyber assurance can likewise be clarified to include time dependence. For example, assurance may decrease over time (e.g., password aging) and can be restored to some previous level by the performance of a periodic action (e.g., password reset).

Figure 1, Illustration of Cyber Assurance Over Time, illustrates the concept of cyber assurance as a negative function of time. The colors of the lines in Figure 1 represent the following:

Red line: Represents the instantaneous assurance levels which decrease over time.

Green line: Represents the required reasonable assurance level.

Blue vertical lines: Represents (periodic or event-based) control activities which restore cyber assurance levels to some initial value.

12 Figure 1 Illustration of Cyber Assurance Over Time This concept of time dependence can be added to the assurance notation by extending the triple to a quadruple (X, Y, Z, t) that represents the cyber assurance provided by control X to SSEP function Y against attack Z at time t. Adding time as an explicit component of cyber assurance provides a framework for understanding the impacts of control timing on CSP outcomes and provides a reasoning basis for outcomes that result from changes to control timing.

For example, if a control action must be performed every 7 days, it might be reasoned that the cyber assurance level provided by that control decays at a rate sufficient for it to fall below the reasonable assurance threshold at some point after 7 days. If a licensee proposes to change the controls timing to perform the control action every 31 days, this framework makes it obvious that some reasoning must be provided to justify that the increased time interval between control actions will not result in an unacceptable assurance level. Such reasoning might include actions taken to slow the rate of assurance loss from the control (e.g., a longer and more complex password standard is used) or other controls are put in place such that the net assurance provided by all controls maintains the required assurance level (refer to the next subsection for a discussion on net cyber assurance).

5.1.3 Net Cyber Assurance Net cyber assurance is the cyber assurance provided, in aggregate, by a set of controls. This concept is important for assessing the overall impact to cyber assurance, referencing specific

13 SSEP function(s) and attack(s), when members of the set of controls credited with protection are changed (e.g., if the cyber assurance provided by one control is decreased, the cyber assurance provided by another control must be increased so that the net cyber assurance for the system is at least the same). Controls must overlap to contribute to net assurance. That is, controls must protect the same SSEP function against the same attack. Using our notation, controls (X1, Y, Z, t) and (X2, Y, Z, t) may contribute to the net cyber assurance provided to SSEP Y against attack Z (X1X2, Y, Z, t). This concept can be further expanded to capture various ways in which controls may be combined. For example, net assurance might be additive or highest value bounded. The current state of technology lacks an analytical basis for net assurance, so any determinations of net assurance level values or sufficiency for meeting regulatory requirements will continue to be subject to expert judgement.

CSP net cyber assurance is the net cyber assurance provided, in aggregate, by all CSP controls for all SSEP functions against all attacks. CSP net cyber assurance can be represented in notation as (all X, all Y, all Z, t) where all means the various overlapping relationships among X, Y, and Z.

Using this conceptual framework, the motherhood requirement can be restated as follows: a licensee must ensure that CSP net cyber assurance is maintained with reasonable assurance.

The framework thus enables specific discussion concerning how changes to CSP elements can impact individual control assurance and net assurance with the aim of maintaining CSP net cyber assurance at a high level. While the final regulatory determinations will be made by NRC staff, this framework will provide a structure for the identification and analysis of the cybersecurity outcomes of CSP elements including the impacts of alternative controls involving control timing changes.

5.2 CSP Domain Model (Influence Diagram)

A domain model was constructed to represent the features of a CSP important to regulatory outcomes and ACTA assessment, and the identified basic elements of the domain (e.g.,

requirements, procedures, authorized configurations) and relationships among the elements (e.g., procedures related to the performance of activities, the protection of an SSEP function related to an attack, controls related to the intent of the control) in a compact way. This CSP domain model is a task-centered influence diagram, shown below in Figure 2, CSP Domain Model (Influence Diagram).

The CSP domain model is focused on task performance as the mechanism for achieving cyber assurance outcomes and maps influence relationships among the various domain elements that can impact the outcomes. Influence is quantified in terms of direction (i.e., positive, negative, or neutral) and rough ordinal magnitude (e.g., small, medium, large) and, given the primitive state of cybersecurity analytical methods, is currently sufficient for describing the impact of changes to cyber assurance outcomes. A simple example is the influence of procedures on requirements.

Procedures for implementing CSP controls may influence the fulfillment of CSP programmatic requirements (e.g., this influence is marked in Figure 2, as an influence arrow from procedures to requirements), and an erroneous procedure change may negatively impact meeting those requirements (the change to procedure propagates via the influence arrow as a negative impact on requirements).

14 Figure 2 CSP Domain Model (Influence Diagram)

15 The following sections detail the CSP domain model relationship levels, the related CSP programmatic and performance views created as part of the model, and the CSP domain characteristics.

5.2.1 CSP Domain Relationship Levels The CSP domain model consists of three abstraction Relationship levels:

Intent Level: The most general level is the intent level which includes CSP elements related to a tasks objectives or purpose. Elements at the intent level include requirements and performance criteria and are characterized by their relation to an SSEP function, an attack, and an identify, protect, detect, respond, and recover (IPDRR) purpose.

Task Level: The central abstraction level is the task level that includes the action types, including control actions, used to meet the CSP intents and establish the desired system properties at the object level. Elements at the task level include procedures and their corresponding activities, and are characterized by their relation to physical, technical, operational, and management (PTOM) tasks. In general, each PTOM task accomplishes a measurement and/or control function.

Object Level: The most granular level of abstraction is the object level that includes the system states intended by the CSP and established by CSP tasks. Elements at the object level include configurations, data, conditions, performance behaviors and outcomes, and are characterized by their relation to the object properties, methods, and coupling (PMC) state. Properties represent what an element is, methods represent what an element can do, and coupling represents what an element is connected to.

The PMC states can be further classified into physical and logical types. A physical state is physically measurable feature (e.g., locked cabinet and connected wires) and a logical state is determined by measuring the logical or information features of the object (e.g.,

memory states and software configurations).

5.2.2 CSP Related Programmatic and Performance Views The CSP domain model also features two related views of CSP elements: programmatic and performance. The programmatic view focuses on the prescriptive aspects of the CSP such as written requirements and procedural completeness. The performance view focuses on those CSP aspects that are measurable and performance-based, such as performance criteria and outcomes. Both views present different ways of understanding a CSP:

A programmatic view lends itself to programs focused on deterministic requirements (e.g., all baseline controls must be implemented as written).

Regulations and Requirements: This element identifies the requirement to perform the control. These are driven primarily by 10 CFR 73.54, RG 5.71, and/or NEI 08-09.

Procedures: This element documents the means, methods, and results of an activity developed by the licensee to direct the performance of tasks.

CCCDD: This element details factors of the control requirement.

16 Configurations: Equipment settings/design prescribed by regulation/procedure.

Conditions: The state of the asset and/or control as prescribed by the regulation/procedure.

Capabilities: The ability to perform a function as specified by regulation/procedure.

Data: Information required to be considered as required by regulation/procedure.

Documentation: Documents required to satisfy the regulation/procedure requirement.

A performance view lends itself to programs focused on measurable performance criteria and outcomes (e.g., 99.9% of attacks do not result in adverse SSEP impacts).

Criteria: This element consists of measurable standards by which the achievement of requirements may be evaluated.

Activities: This element involves the performance of activities directed by procedures, regulations, and/or requirements.

Outcomes and Behaviors: This element consists of either the result of performing or failure to perform an activity, or the way an asset or system responds to the performance of or failure to perform an activity, or both.

Current CSPs are highly weighted toward deterministic requirements, so the programmatic view of the domain model will be of most use among operating reactor CSPs. However, performance-based programs are allowed by the NRC, and CSPs in the future and among advanced reactors may feature more performance-based approaches. For such CSPs, the performance view of the domain model may find greater application.

The domain model uses this combination of abstraction levels and views to classify CSP elements according to their impact on and relationship to CSP cyber assurance. The relationships among the levels and views are illustrated with influence arrows that indicate how changes within the domain are propagated. For the scope of this research, each domain model class (e.g., an oval in the graphic) is equivalent to a FACT class and the cyber assurance provided by one or multiple overlapping controls may be considered using this domain model by grouping CSP features related to that control according to these classes. Note: The domain model may have application beyond ACTA assessment (e.g., general control assessment) but the discussion here will be limited to that purpose.

The following is an example of how the domain model may propagate CSP changes:

1. A CSP requirement is changed to replace control Xs periodic timing task from 7 days to 31 days (e.g., implement an alternative control).

2. That change requires a written task procedure change.

3. The procedure change may impact the activity used to perform the task.

4. The changed activity may impact important cybersecurity outcomes.

5. The changed outcomes may impact the cyber assurance provided by control X.

17 Assessment of the change should consider at least these five items listed above, and any other domain categories related to these items. In this way, the CSP domain model can be used to identify and relate information needed to assess the alternative control.

5.2.3 CSP Domain Characteristics The characteristics portion of the CSP domain model is intended to identify attributes of the elements, depending on the control being addressed. The characteristics listed in Figure 2, CSP Domain Model (Influence Diagram), are examples, but are not limited to, commonly identified characteristics of the controls as prescribed by RG 5.71 or NEI 08-09.

5.3 ACTA Flowchart The ACTA Flowchart (refer to Appendix C, ACTA Flowchart and Examples) was developed as a tool to apply technical basis (e.g., novel terminology, domain model) of this research to support an ACTA assessment. Using the flowchart instructions (Appendix C), NRC staff can apply the tool to help identify, collect, and analyze information important to an ACTA assessment.

The flowchart assists the NRC staff in determining if the intent of the original control is met by the alterative control. An assessment is performed according to existing regulations and guidance. The flowchart helps NRC staff to gather and organize information to support the assessment. The flowchart provides pathways for various outcomes, including:

an ACTA meeting for the control intent and considered acceptable; an ACTA not meeting the control and not considered acceptable; and an alternate approach not being applicable to control timing and therefore not applicable to this methodology.

The flowchart is designed to be easy to use and guides users step-by-step via simple yes or no questions to gather information about an ACTA leveraging the structure provided with the domain model. It also provides prompts for the user to note important details that may be useful for determining if an ACTA is acceptable. The user will also be directed to evaluate related controls if applicable. Each view, programmatic and performance, and its associated characteristics, are applied from increasing to decreasing levels of abstraction, determining how the assessed ACTA impacts each element of the control. The flowchart has two exits for failing to meet the control:

1. The prescribed control timing is not being met, and no alternate timing has been established.

2. When NRC staff determines that the credited ACTA does not provide sufficient cyber assurance.

Given the research focus on control timing, the flowchart will help NRC staff determine if a controls timing aligns with prescribed requirements or if an alternative controls timing is equal to or exceeds the original control's periodicity. If the timing aspect of the control has been met as prescribed or occurs more often than required, the NRC staff exits the flowchart because there is no need for further assessment. It is important to note that even if the timing requirement of the control is satisfied, any alternate measures taken for the control not related to timing must

18 still be evaluated for effectiveness, providing equal or greater assurance than the prescribed control. Such a screening tool for other than ACTA control assessments is left for future work.

The flowchart can also be used to help NRC staff assess an ACTA using a performance view (e.g., by assessing the performance of the control itself). If it is determined that an ACTA would not provide acceptable cyber assurance by measuring its achievement of required cybersecurity outcomes, the ACTA fails to meet the control and is not acceptable. If all applicable elements are assessed to provide acceptable cyber assurance, the NRC staff shall review all applicable information and determine if, overall, the ACTA meets the control intent. If so, the ACTA is considered an acceptable alternate control.

While most CSPs are not designed to be performance-based, a small set of performance-based criteria may exist if the licensee credits tracking performance metrics for meeting their CSP requirements. Performance criteria may also be applicable in future revisions of guidance documents that support performance-based approaches in operating and advanced reactors.

This may be especially true for novel CSPs developed under new Part 535 programs intended to enable performance-based approaches. Thus, performance criteria are included in the flowchart tool to provide the NRC staff with a pathway to assess current or future performance criteria.

Note: Currently the lack of criteria measurements would not result in the failure to meet a control unless such measures are explicitly credited for meeting CSP requirements.

Multiple examples were developed (Appendix C) to illustrate the use of the flowchart, applying various scenarios of commonly seen ACTAs. The examples provide context on the use of the flowchart and explain why determinations were made for each step, including the overall screening of an ACTA as not applicable, acceptable, or not acceptable.

6. RESEARCH INSIGHTS Insights were developed by analyzing existing regulatory and technical basis, artifacts related to the implementation of controls, alternative controls, existing CSP approaches, operational and inspection experiences, and input from NRC stakeholders. Insights developed by the research included frameworks for general discussions of cyber assurance and specific assessment of ACTAs. The following are some specific insights:

1. Developing novel terminology and concepts related to cyber assurance is useful for clarifying and focusing discussions related to regulatory activities associated with ACTA.

However, care must be taken to ensure such concepts can be harmonized and are supportive of existing regulatory activities and terminology and do not appear to propose new regulatory requirements or guidance.

2. Regulatory guidance is a useful exemplar of industry programs that can represent the features and requirements of such programs for analysis without requiring access to licensee-controlled information.

3. The usefulness of the technical basis is enhanced by the development of tools allowing understanding and simple application of the basis to practical problems.

4. A wholistic view of cyber assurance (i.e., one that includes the intent, operations, maintenance, and relationships with a control) is necessary to fully understand the 5 SECY-23-0021, Proposed Rule: Risk-Informed, Technology-Inclusive Regulatory Framework for Advanced Reactors, March 1, 2023 (ML21162A095).

19 integrated impacts of control changes on CSP outcomes and a domain model is useful for identifying and relating the elements of such a view.

5. While there is no explicit mention of what length of time is acceptable when considering alternate periodicities for controls, the methodology presented in this TLR provides insight into what may be considered when evaluating those periodicities and what factors may impact the assurance provided by the control throughout the alternate timeframe.

7. RECOMMENDATIONS FOR ACTION The results of the research for this TLR provide support for efficient discussions concerning assessments of ACTAs. The actions below are recommended to help disseminate these results and maintain the products from this research for NRC staff.

1. Publish the results of this research as a NUREG or another publicly available document to disseminate the novel elements of the technical basis and facilitate comment and discussion with NRC stakeholders.

2. Provide the technical basis developed by this report to NRC staff to introduce them to concepts such as cyber assurance and CSP domain models to support regulatory certainty, consistency, and efficiency.

3. Provide the tools developed by this report to NRC staff to aid ACTA assessment and seek periodic feedback on ways to improve the tools.

4. Continue to maintain and develop both the technical basis and tools produced by this research by seeking customer and stakeholder feedback.

8. RECOMMENDATIONS FOR FUTURE RESEARCH The following are recommendations for follow-on research.

1. Pilot the tools developed and analyze for usefulness to NRC staff and develop an appropriate maintenance framework for the tools to ensure continued usefulness.

2. Analyze the domain model for application to an alternative control assessment other than ACTA and update the model to reflect a more general-purpose domain model.

3. The current domain model is mostly focused on the impact of a single control. While the impacts of combined or overlapping controls might be inferred within the model, research to expand the model to explicitly include and map the elements and influences among multiple controls would be an obvious next step.

4. There is not a clearly established standard for assessing timeliness of actions taken in response to event-based timing requirements (e.g., how long after an event is it acceptable to wait before completing an action). Further research to explicitly consider and assess this type of timing is needed to fully assess ACTA.

5. Develop a screening flowchart using the domain model to assess the implementation of a control as written to ensure the implementation truly meets the as written requirements and intent.

20

6. Develop additional technical basis clarifying and expanding the concepts introduced in this research. Additionally, research is needed to operationalize this information to achieve greater regulatory certainty, consistency, and efficiency.

7. Pilot the approaches developed in this research against a plant performance-based CSP, preferably within the context of advanced reactors and Part 53.

8. Use the concepts and frameworks developed to enable explicit and quantitative measures of both CSP outcomes and influences within a cybersecurity program. For example, can cyber assurance decay be further characterized and perhaps nominally quantified?

9. Further research into current technology, attack methods, defense methods, etc. can provide insights to assess the adequacy of current timing requirements. Extensions of this work may be used to assess changes to existing CSP requirements such as adjustments to control timing based on current trends, methodologies, and developments in technology.

In general, further development of the concepts introduced here will support more analytical approaches to licensee CSPs and prepare the NRC to assess ACTA in a consistent and efficient manner. The concepts may also improve communication with and reduce regulatory uncertainty for licensees concerning ACTA.

9. CONCLUSION Current licensee CSPs require actions associated with controls to be performed periodically and/or in response to an event. These actions are represented by two types of control timing:

periodic or event based. In addition, the following applies:

ACTA: A licensee may change a controls timing when implementing an alternative control and the licensees overall methodology for implementing the alternate control, including the related basis, analysis, and cybersecurity outcomes.

FACT: The various factors that impact or are impacted by changes to control timing.

The products of this research provide improved clarity on the role that timing-based controls play in the licensees CSP and how changes to control timing may impact regulatory cybersecurity outcomes. These products also provide NRC staff with tools to understand control relationships and assess how controls provide cyber assurance.

Current guidance for ACTAs is limited and aids for NRC staff assessment of ACTAs may improve regulatory efficiency and certainty. This research developed technical basis and tools to assist NRC staff in the assessment of ACTAs. The technical basis includes novel terminology to explicitly capture concepts useful for assessment, such as ACTA, FACT, and cyber assurance.

The domain model clarifies the elements and relationships within a licensee cybersecurity program important for ACTA assessment. The FACT screening flowchart was developed to provide NRC staff with a consistent, repeatable tool to assess ACTAs based on those relationships and control elements identified in the CSP domain model.

Further developments of these tools, and recommendations for other research were identified to further refine the NRCs ability to provide objective and efficient evaluations of alternate control timing approaches.

21 APPENDIX A.

DEFINITION OF TERMS The definitions listed below are based on operational experience and technical knowledge.

These definitions are used for the purposes of this research only and are not endorsed by the NRC, nor are they intended for use when interpreting regulation.

A.1 Existing Terms Adverse Impact: A direct deleterious effect on SSEP functions; or the operation of systems, networks, and associated equipment; or the integrity and confidentiality of data and software. Examples include:

loss or impairment of function; reduction in reliability; reduction in ability to detect, delay, assess or respond to malevolent activities; reduction of ability to call for or communicate with offsite assistance; or reduction in emergency response ability to implement appropriate protective measures in the event of a radiological emergency.

If the direct or indirect compromise of a support system causes a SSEP system or support system to actuate or fail safe and not result in radiological sabotage (i.e.,

causes the system to actuate properly in response to established parameters and thresholds), this is not considered to be an adverse impact, as defined by 10 CFR 73.54(a)(2).

Cyberattack: Any event in which there is reason to believe that an adversary has committed or caused, or has attempted to commit or cause, an adverse impact on a SSEP function.

IPDRR

Purpose:

Five core functions of the Nation Institute of Standards and Technology (NIST) Cybersecurity Framework6 applied to 10 CFR 73.54 requirements used to identify the function of the control and further refine the intent:

1. Identify: Identify assets that fall within the cybersecurity program and their potential attack pathways.

2. Protect: Implement required controls to reduce asset exposure and mitigate attack pathways.

3. Detect: Implement methods to detect attacks in real-time to allow for rapid response.

4. Respond: Implement controls to minimize the impact of an attack and stop the attack from occurring.

5. Recover: Implement controls to maintain the most recent trusted configuration and rapidly restore impacted systems after failure or attack.

6The NIST Cybersecurity Framework (CSF), v2.0.

22 A.2 Shared Terms Adequate Protection: Actions or measures that prevent (any) adverse impact to a SSEP function per the provisions of 10 CFR 73.54.

Adverse Impact: A direct deleterious effect on SSEP; or the operation of systems, networks, and associated equipment; or the integrity and confidentiality of data and software. Examples include loss or impairment of function; reduction in reliability; reduction in ability to detect, delay, assess or respond to malevolent activities; reduction of ability to call for or communicate with offsite assistance; or the reduction in emergency response ability to implement appropriate protective measures in the event of a radiological emergency. If the direct or indirect compromise of a support system causes a SSEP system or support system to actuate or fail safe and not result in radiological sabotage (i.e., causes the system to actuate properly in response to established parameters and thresholds), this is not considered to be an adverse impact, as defined by 10 CFR 73.54(a)(2).

Behaviors: The way an asset or system responds to the performance of an activity.

Control: The technical, operational, or management process or device used to provide assurance.

Logical: Information state of object such as a digital configuration of a control, memory contents, or firmware version.

Outcomes: The result of performing or failure to perform an activity.

Physical: Tangible setting or implementation of a control.

Timing: Determines when/how often something occurs. Means both periodic & event-based performance.

A.3 Novel Terms Activities: The performance of requirements prescribed by policy and procedures.

Alternate Control Timing Approaches (ACTAs): When an alternate control is implemented by adjusting control timing, the specific methods for justifying and implementing these changes.

Assurance Relationship: A function, dependency, or other means by which the assurance provided by one plant element is influenced by another plant element.

Assurance Scope: The plant elements for which assurance is provided. These plant elements may control the processes, actions, or measures used to provide cyber assurance.

Attack: The means by which an attacker attempts to impact a SSEP function.

CCCDD:

Configurations: Equipment settings/design prescribed by regulation/procedure.

Conditions: The state of the asset and/or control as prescribed by the regulation/procedure.

Capabilities: The ability to perform a function as specified by regulation/procedure.

23

Data: Information required to be considered as required by regulation/procedure.

Documentation: Documents required to satisfy the regulation/procedure requirement.

Characteristics: Specific attributes of the intent, task, and object level views that determine the control purpose and how it is implemented.

Common Assurance: An assurance scope that includes multiple plant elements.

Control Assurance Scope: The set of plant elements for which a control provides assurance.

Control Task: The procedure driven activity that is required to accomplish the control intent.

Control Timing: Periodic or event-based performance requirements.

Coupling: What an object is connected to.

Criteria: Measurable standards by which the achievement of requirements may be evaluated.

CSP Element: Any part of the NPP's CSP.

CSP Model Domain (Influence Diagram): A multidirectional diagram illustrating loose (not explicitly defined) relationships among CSP elements viewed according to programmatic, performance, and feature characteristics at various levels of abstraction.

CSP View: An alternate way of representing related CSP elements.

Cyber Assurance: A measure of confidence of applied protection against cyberattacks with reference to specific assurance scope/SSEP functions, cyberattacks, and controls.

The measurement of cyber assurance for a control is used to determine if reasonable assurance is met.

Cybersecurity Controls: Processes, actions, or measures that safeguard digital assets that affect SSEP functions.

Indirect Element that affects FACT(s): This applies to elements not explicitly stated in the CSP, but that may provide a supporting role or be used to meet the intent of the plan.

Examples: SIEM, Security Operations Center (SOC) monitoring, infrastructure monitoring (WhatsUP Gold).

Intent Relationship Level: Highest level of abstraction capturing the purpose, objectives, and success criteria of a control.

Measurement Task: Means by which an objects state is estimated.

Methods: What an object "does" such as object functions.

Object Relationship Level: Lowest level of abstraction capturing the authorized states of plant elements.

Overlapping Assurance: One or more assurance scopes that include the same plant element.

Performance View: View of the administration of a control.

24 Plant Element: Plant structure, system, and component (SSC) within the purview or consideration of the CSP.

Procedures: Documentation of the means, methods, and results of an activity.

Programmatic View: View of requirements that dictate how a control is administered.

Properties: What an object "is", such as a description of the object characteristics.

PTOM Type: Primary means by which a task/control is performed.

Requirements: Regulatory, CSP, NPP, or other programmatic elements that are necessary for compliance.

Task Relationship Level: Center level abstraction focusing on the processes by which a control is implemented.

25 APPENDIX B.

REFERENCES Title 10 CFR 73.54 Protection of Digital Computer and Communication Systems and Networks.

NIST Special Publication (SP) 800-53, Security and Privacy Controls for Information Systems and Organizations, Rev. 5, September 2020.

NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security, Rev. 2, May 2015 The NIST Cybersecurity Framework (CSF) 2.0, February 26, 2024.

NEI 08-09, Cyber Security Plan for Nuclear Power Reactors, Rev. 6, Addendum 1 Markup, March 2017. (ADAMS Accession No. ML17079A423).

NEI, Cyber Security Plan for Nuclear Power Reactors, NEI 08-09, Revision 6, April 2010.

(ADAMS Accession No. ML101180437).

NRC RG 5.71, Cybersecurity Programs for Nuclear Power Reactors, Rev. 1, February 2023.

(ADAMS Accession No. ML22258A204).

SECY-23-0021, Proposed Rule: Risk-Informed, Technology-Inclusive Regulatory Framework for Advanced Reactors, March 1, 2023 (ML21162A095).

APPENDIX C. ACTA FLOWCHART AND EXAMPLES ACTA Flowchart Instructions

- - Important*** The intended use of this "owchart is to determine if alternate timing applied to controls provides adequate cybersecurity assurance and is acceptable as an alternate to the prescribed timing. If an alternate control is used with the prescribed timing or more frequent than prescribed, the alternate must still be assessed for eectiveness.

Steps marked in green or red are stopping points for acceptable and unacceptable control approaches.

Initial Review 1.

Determine and document the regulation/requirement that is being evaluated.

2.

Determine and document the control intent and characteristics.

3.

Determine if the control timing is satis"ed as written in the regulation/requirement. If so, no further action is necessary as the timing is acceptable.

4.

If timing is not applied as prescribed by the regulation/requirement, determine if alternate control timing is used. If no alternate timing is applied, the licensee has failed to meet the intent of the control.

Note: Determine if the implementation of the control being assessed has an impact on other controls.

5.

Determine if the timing is event-based or periodic. Periodic controls occur at prede"ned intervals, while event-based controls occur when a speci"c event occurs or within a certain amount of time after a speci"c event occurs.

6.

If event-based, are required actions performed as prescribed in regulations/requirements? If so, the control timing is acceptable. The alternate control must still be analyzed for eectiveness to meet the control intent.

7.

If periodic, is the alternate control timing as frequent or more frequent than prescribed in the regulation/requirement? If so, the control timing is acceptable. The alternate control must still be analyzed for eectiveness to meet the control intent.

Programmatic Review 1.

Determine and document if any procedures are used to perform the control.

2.

Determine and document if any Conditions, Con"gurations, Capabilities, Data, and/or Documentation are required.

Performance Review Note: Cybersecurity Assurance is the amount of assurance provided by the implementation of the control in question. Adequate Cybersecurity Assurance is a level of assurance provided by the control implementation that meets the reasonable/high assurance benchmark.

1.

Determine if measurable criteria are used for performance of the control.

a.

If measurable criteria are not used, continue to next step.

b.

If measurable criteria are used, document the measurable criteria.

26

i.

Determine if the alternate control provides measurable criteria that provides adequate cybersecurity assurance. If the alternate control does not provide measurable criteria that ensures adequate cybersecurity assurance the licensee failed to meet the intent of the control and/or their procedure.

2.

Determine and document the required activities and activity characteristics required address the control.

a.

Determine if the alternate control activity provides adequate cybersecurity assurance. If the alternate control activities do not provide adequate cybersecurity assurance, the licensee failed to meet the intent of the control and/or their procedure.

3.

Determine and document the authorized outcomes and behaviors that occur as a result of the control implementation.

a.

Determine if the alternate control outcome/behavior provides adequate cybersecurity assurance. If the alternate control outcome/behavior does not provide adequate cybersecurity assurance, the licensee failed to meet the intent of the control and/or their procedure.

4.

Using the information gathered determine if the alternate control meets the intent of the prescribed control from the regulation/requirement and if the alternate control provides cybersecurity assurance.

a.

If the alternate control does not meet the intent and/or provide cybersecurity assurance, the licensee failed to meet the intent of the control and/or their procedure.

b.

If the alternate control does meet the intent of the prescribed control AND provides cybersecurity assurance, the alternate control is acceptable.

27

Acronyms ACTA - Alternate Control Timing Approaches: When an alternate control is implemented by adjusting control timing; the speci"c methods for justifying and implementing these changes.

CCCDD - Capabilities, Conditions, Con"gurations, Data, Documentation.

Capabilities: The ability to perform a function as speci"ed by regulation/procedure.

Conditions: The state of the asset and/or control as prescribed by the regulation/procedure.

Con"gurations: Equipment settings/design prescribed by regulation/procedure.

Data: Information required to be considered as required by regulation/procedure.

Documentation: Documents required to satisfy the regulation/procedure requirement.

IPDRR - Five core functions of the NIST Cybersecurity Framework (CSF) applied to 10 CFR 73.54, Protection of Digital Computer and Communication Systems and Networks, requirements. Used to identify the function of the control and further re"ne the intent.

Identify: Identify assets that fall within the cybersecurity program and their potential attack pathways.

Protect: Implement required controls to reduce asset exposure and mitigate attack pathways.

Detect: Implement methods to detect attacks in real-time to allow for rapid response.

Recover: Implement controls to maintain the most recent trusted configuration and rapidly restore impacted systems after failure or attack."

Respond: Implement controls minimize the impact of an attack and stop the attack from occurring.

FACT - Factors Aecting Control Timing 28

Start Is the control timing satisfied as written?

No further action necessary Is an alternate control timing used?

Failed to meet control Determine Regulation/

Requirement Document the Regulation/

Requirement as a FACT Is there a procedure to perform control action?

Document Procedure as a FACT Do the regulations

/requirements/

procedure specify CCCDD?

STEP 2: PROGRAMMATIC VIEW STEP 3: PERFORMANCE VIEW Document any Conditions/

Configurations/

Capabilities / Data /

Documentation as a FACT Determine required activities and activity characteristics (i.e.

Measure or Control).

Determine authorized outcomes and behaviors from activities.

Does alternate criteria provide adequate cybersecurity assurance?

Document the measurable criteria as a FACT Document the activity as a FACT Does the alternate activity(s) provide adequate cybersecurity assurance?

Does alternate outcome provide adequate cybersecurity assurance?

Yes No No Yes Yes Yes Yes No No No Does the alternate have a frequency that is as frequent or more frequent than the requirement?

Control timing is acceptable. Alternate Control must still be analyzed for effectiveness to meet the control intent.

STEP 1: INITIAL REVIEW ACTA Flowchart This flowchart is a tool to help determine if alternate timing of a control is acceptable.

Determine the control intent and characteristics Document the control intent and intent characteristics as a FACT Yes No Does the alternate meet the intent?

Acceptable Alternate Yes Yes No No Document the Activity authorized outcomes and behaviors as a FACT Failed to meet control Is measurable criteria used?

Yes No Is the control timing event-based?

Yes Yes Do event-based actions occur as prescribed?

Yes No No Determine related controls that may require evaluation No 29

ACTA Flowchart Guidance 30