Text

NEI 15-09, Rev. 1, Cybersecurity Event Notifications
	ML22298A228
Person / Time
Site:	Nuclear Energy Institute
Issue date:	10/25/2022
From:	; Nuclear Energy Institute
To:	; Office of Nuclear Reactor Regulation, Office of Nuclear Security and Incident Response
Shared Package
ML22298A225	List: ML22298A226; ML22298A228;
References
	NEI 15-09
	Download: ML22298A228 (1)
	v • d • e

NEI 15-09 [Revision 1]

October 2022 Cybersecurity event Notifications

[BLANK PAGE]

NEI 15-09 [Revision 1]

Nuclear Energy Institute Cybersecurity event Notifications October 2022

U ACKNOWLEDGMENTS This document was initially prepared by the nuclear power industry for use in commercial nuclear power reactors to comply with United States federal regulations.

Contributors to this manual include:

Matt Coulter, Duke Energy Corporation

Nathan Faith, Constellation

Adam Goodman, Duke Energy Corporation

William Gross, Nuclear Energy Institute

David Neff, Constellation

Heather Pickard, Tennessee Valley Authority

Jay Phelps, STP Nuclear Operating Company

Robin Ritzman, First Energy Corporation

Larry Tremonti, DTE Energy U NOTICE Neither NEI, nor any of its employees, members, supporting organizations, contractors, or consultants make any warranty, expressed or implied, or assume any legal responsibility for the accuracy or completeness of, or assume any liability for damages resulting from any use of, any information apparatus, methods, or process disclosed in this report or that such may not infringe privately owned rights.

NEI 15-09 (Revision 1)

October 2022 U EXECUTIVE

SUMMARY

This document provides guidance for use by nuclear power reactor licensees when categorizing certain cybersecurity events, and the process for conducting notifications and submitting written security follow-up reports to the NRC for cybersecurity events. Regulatory Guide 5.83 (RG 5.83) uses a definition of CYBERATTACK that is different than the definition approved by the NRC for use in the industry Cybersecurity plans. Consequently, the terms and examples in RG 5.83 may be different than those provided in NEI 15-09. This document is based on Regulatory Guide 5.83, rev 0 with incorporation of 1) NEI definition of CYBERATTACK affecting the examples,

2) flowchart for reportability determinations, 3) guidance for determining when the reportability clock starts, 4) guidance for evaluating conditions that could have caused an ADVERSE IMPACT, 5) examples for use in program implementation and training, and 6) a Glossary of terms.

This guidance document was developed to streamline the process for making reportability determinations. The goal is to provide for consistent implementation and to minimize the burden on licensees and the NRC from over reporting events that do not rise to the level of an actual or potential CYBERATTACK, while enabling NRC to inform the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA) and federal intelligence and law enforcement agencies of cybersecurity-related events that could (1) endanger public health and safety or the common defense and security, (2) provide information for threat-assessment processes, or (3) generate public or media inquiries.

Summary of Changes:

Revision 1 Section 2.1.1 (1-hour notifications) was updated to provide clarity for analyzing digital computer and communication systems and networks that must be protected against cyberattacks. Section 2.1.2 (4-hour notifications) was updated to clarify unprotected networks and protected networks. Section 2.2 was updated to clarify guidance on 24-hour Corrective Action Program (CAP) recordable items. Section 2.3.5 was updated to clarify guidance on declaration of emergencies. The flowchart in Appendix A was updated to remove the words, cyber event and incorporate other changes for consistency with the balance of the document. All examples have been moved to Appendix C. Additional editorial changes were made.

NEI 15-09 (Revision 1)

October 2022

[BLANK PAGE]

NEI 15-09 (Revision 1)

October 2022 U TABLE OF CONTENTS EXECUTIVE

SUMMARY

....................................................................................................... i 1 INTRODUCTION .......................................................................................................... 1 1.1 SCOPE 3 1.2 PURPOSE .........................................................................................................................3 1.3 APPLICABLE RULES AND REGULATIONS .......................................................................3 1.4 RELATED GUIDANCE ......................................................................................................4 2 REGULATORY GUIDANCE .......................................................................................... 5 2.1 CYBERSECURITY EVENT NOTIFICATIONS ......................................................................5 2.1.1 One-hour Notifications ...................................................................................5 2.1.2 Four-hour Notifications..................................................................................5 2.1.3 Eight-hour Notifications .................................................................................6 2.2 24-HOUR RECORDABLE EVENTS ....................................................................................7 2.3 NOTIFICATION PROCESS ................................................................................................7 2.3.1 Notifications Containing Safeguards Information ......................................8 2.3.2 Notifications Containing Classified Information .........................................9 2.3.3 Continuous Communications ........................................................................9 2.3.4 Retraction of Notifications ...........................................................................10 2.3.5 Declaration of Emergencies .........................................................................10 2.3.6 Elimination of Duplication ...........................................................................10 2.3.7 Content of Notifications ...............................................................................11 2.3.8 Voluntary Notifications ................................................................................11 2.4 WRITTEN SECURITY FOLLOW-UP REPORTS................................................................12 2.4.1 NRC Form 366 and 366A .............................................................................12 2.4.2 Significant Supplemental Information and Correction of Errors ...........13 2.4.3 Retraction of Previous Written Security Follow-up Reports ...................13 2.4.4 Written Security Follow-up Reports Containing Safeguards Information

........................................................................................................................14 2.4.5 Written Security Follow-up Reports Containing Classified Information

........................................................................................................................14 2.4.6 Content of Written Security Follow-up Reports........................................14 APPENDIX A - REPORTABILITY DECISION FLOWCHART AND INSTRUCTIONS .............. 1 APPENDIX B - GUIDANCE FOR DETERMINING START OF REPORTABILITY CLOCK ....... 1 APPENDIX C - EXAMPLES FOR IMPLEMENTATION AND TRAINING USE ....................... 1 APPENDIX D - GLOSSARY ............................................................................................... 1 REFERENCES .................................................................................................................... 5

NEI 15-09 (Revision 1)

October 2022

[BLANK PAGE]

NEI 15-09 (Revision 1)

October 2022 CYBERSECURITY EVENT NOTIFICATIONS 1 INTRODUCTION This guide addresses cybersecurity event notification (CSEN) requirements. These notification requirements contribute to the NRCs analysis of the reliability and effectiveness of licensees cybersecurity programs. Furthermore, they will play an important role in the NRCs continuing effort to provide high assurance that digital computer communication systems and networks are adequately protected against CYBERATTACKS up to and including the design basis threat.

Prompt notification of a CYBERATTACK could be vital to the NRCs ability to take immediate action in response to a CYBERATTACK and, if necessary, notify other NRC licensees, government agencies and critical infrastructure facilities, to defend against a multiple sector CYBERATTACK. Notifications conducted and written reports submitted by licensees will be used by the NRC to respond to emergencies, monitor ongoing events, assess trends and patterns and identify precursors of more significant events. Timely notifications assist the NRC in achieving its strategic communication mission by enabling NRC to inform the U.S. Department of Homeland Security Cybersecurity and Infrastructure Security Agency (DHS CISA) and federal intelligence and law enforcement agencies of cybersecurity-related events that could (1) endanger public health and safety or the common defense and security, (2) provide information for threat-assessment processes, or (3) generate public or media inquiries.

In accordance with 10 CFR 73.54, licensees cybersecurity programs are required to provide high assurance that digital computer and communication systems and networks are adequately protected against CYBERATTACKS, up to and including the design basis threat of radiological sabotage as described in 10 CFR 73.1. Further, licensees are required to protect digital computer and communication systems and networks associated with safety-related and important-to-safety functions; security functions; emergency preparedness functions, including offsite communications; and support systems and equipment which, if COMPROMISED, would adversely impact safety, security, or emergency preparedness (SSEP) functions.

Additionally, in accordance with 10 CFR 73.54(a)(2), licensees are required to protect the systems and networks associated with SSEP functions against CYBERATTACKS that would ADVERSELY IMPACT the INTEGRITY or confidentiality of data and/or software; deny access to systems, services, and/or data; and ADVERSLEY IMPACT the operation of systems, networks, and associated equipment. Furthermore, in staff requirements memorandum (SRM), COMWCO-10-0001 Regulation of Cybersecurity at Nuclear Power Plants (Ref. 5), the Commission determined that, as a matter of policy, 10 CFR 73.54 should be interpreted to include structures, systems and components (SSC) in the balance of plant (BOP) that have a nexus to radiological health and safety at NRC-licensed nuclear power plants. Therefore, cybersecurity events related to BOP CRITICAL DIGITAL ASSETs (CDAs) are also required to be reported or recorded in accordance with the requirements of 10 CFR 73.77.

NEI 15-09 (Revision 1)

October 2022 The NRC has established notification requirements for certain cybersecurity activities because they may be indicative of preoperational malevolent activities, and malevolent actors have demonstrated the capability to simultaneously attack multiple independent targets. The NRC forwards appropriate reports of these cybersecurity activities to DHS CISA, federal law enforcement agencies and the intelligence community as part of the national threat assessment process as outlined in the National Cyber Incident Response Plan. Analysis of individual cybersecurity events (at separate facilities or activities) may reveal to the NRC, law enforcement authorities, or the intelligence community potential threats or patterns that warrant increasing the security posture for NRC-regulated facilities and activities, other government facilities and activities, and other national critical-infrastructure facilities. The DHS CISA considers licensees to be key resource owners and operators. Licensees can find additional guidance and examples of suspicious events (to include events related to cyber activity) on the U.S. Department of Homeland Securitys website at www.dhs.gov.

Consistent with 10 CFR 73.77, a cybersecurity event must be reported within the time specified in 10 CFR 73.77(a). These timeframes are within specified hours after, for example, discovery of a CYBERATTACK or suspected attack. Refer to Appendix B-Guidance For Determining Start Of Reportability Clock for guidance for CYBER INCIDENT investigations and determining when sufficient information exists for making a reportability determination.

This guidance has been developed based on operating experience with cybersecurity events and interactions between NRC staff and licensees. This guide provides assistance to licensees in evaluating whether a broad range of potential cybersecurity events should be reported or recorded under the provisions of 10 CFR 73.77. The specific cybersecurity events listed in this guide are examples of reportable or recordable cybersecurity events using the definition of CYBERATTACK that is provided in NEI 08-09 Rev. 6 as amended by the NRC in letter dated June 6, 2010 (Reference 11).

Many of the examples have been created from actual cybersecurity events at NRC-regulated facilities or from licensee discussions with NRC staff on whether a particular cybersecurity event was reportable, recordable, or neither. The evaluation of cybersecurity events is very fact specific. Therefore, for virtually every example provided, the addition or subtraction of a single aspect not explicitly detailed in this guide could easily move it into a higher or lower reporting timeframe. Accordingly, licensees should always consider their particular circumstances before determining how to comply with 10 CFR 73.77.

Consistent with 10 CFR 73.77, licensees should report suspected or actual cybersecurity events, including those substantiated by observations by staff or law enforcement personnel, evidence of the presence of unknown personnel, unauthorized access or modification of CDAs, telephone and other electronic contacts, suspicious documents and files, and testimony of CREDIBLE witnesses. Licensees corporate and contractor personnel may also be sources of this information. Licensees should consider obtaining access to the NRCs Protected Web Server (PWS) to obtain routine threat bulletins and analyses the NRC receives from the Federal Bureau of Investigation (FBI) and the DHS CISA on critical national infrastructure and key

NEI 15-09 (Revision 1)

October 2022 resources. Licensees desiring access to the NRCs PWS should make their request through the security staff in their applicable NRC regional office.

Notifications conducted under 10 CFR 73.77 should focus on the occurring or suspected cybersecurity event, not the resolution, final analysis, suspected motivation of any participants, or technical evaluations. While those actions should be considered part of the response function and should eventually be reported, they should not affect the timely notification of the occurring event.

1.1 SCOPE This document provides guidance licensees may use to create procedures and training documents for addressing the reporting requirements of 10CFR73.77, Cybersecurity Event Notifications.

1.2 PURPOSE The purpose of this document is to provide guidance for use by nuclear power reactor licensees when categorizing certain cybersecurity events, and the process for conducting notifications and submitting written security follow-up reports to the NRC for cybersecurity events (See Section 2.4 for more information regarding security follow-up reports). RG 5.83 uses a definition of CYBERATTACK that is different than the definition approved by the NRC for use in the industry cybersecurity plans.

Consequently, the terms and examples in RG 5.83 may be different than those provided in NEI 15-09.

1.3 APPLICABLE RULES AND REGULATIONS The regulations in Title 10, of the Code of Federal Regulations (10 CFR), Part 73, Physical Protection of Plants and Materials, (Ref. 1). Section 73.77, Cyber security event notifications, requires licensees subject to the provisions of 10 CFR 73.54, Protection of Digital Computer and Communication Systems and Networks, to notify the NRC Headquarters Operations Center via the Emergency Notification System (ENS) as described below.

Section 73.77(a)(1) requires licensees to notify the NRC within one hour after discovery of a CYBERATTACK that ADVERSELY IMPACTED safety-related or important-to-safety functions, security functions, or emergency preparedness functions (including offsite communications); or that COMPROMISED support systems and equipment resulting in ADVERSE IMPACTS to safety, security, or emergency preparedness functions within the scope of 10 CFR 73.54.

Section 73.77(a)(2) requires licensees to notify the NRC within four hours:

(i) After discovery of a CYBERATTACK that could have caused an ADVERSE IMPACT to safety- related or important-to-safety functions, security functions, or emergency preparedness functions (including offsite communications); or that could have COMPROMISED support systems and

NEI 15-09 (Revision 1)

October 2022 equipment, which if COMPROMISED, could have ADVERSELY IMPACTED safety, security, or emergency preparedness functions within the scope of 10 CFR 73.54.

(ii) After discovery of a suspected or actual CYBERATTACK initiated by personnel with physical or electronic access to digital computer and communication systems and networks within the scope of 10 CFR 73.54.

(iii) After notification of a local, state, or other federal agency of an event related to implementation of the licensees cybersecurity program for digital computer and communication systems and networks within the scope of 10 CFR 73.54 that does not otherwise meet a notification under 10 CFR 73.77(a).

Section 73.77(a)(3) requires licensees to notify the NRC within eight hours after receipt or collection of information regarding observed behavior, activities, or statements that may indicate intelligence gathering or pre-operational planning related to a CYBERATTACK against digital computer and communication systems and networks within the scope of 10 CFR 73.54.

Section 73.77(b) requires licensees to use their site Corrective Action Program (CAP) to record vulnerabilities, weaknesses, failures and deficiencies in their cybersecurity program as well as record notifications made under paragraph (a) of 10 CFR 73.77 within twenty-four hours of their discovery.

Section 73.77(c) provides the process for conducting cybersecurity event notifications to the NRC.

Section 73.77(d) provides the process for submitting written security follow-up reports to the NRC for cybersecurity event notifications.

Section 73.77(d)(3) requires licensees to prepare written security follow-up reports on NRC Form 366.

Appendix A to 10 CFR Part 73, U.S. Nuclear Regulatory Commission Offices and Classified Mailing Addresses, contains contact information for the NRC Headquarters Operations Center and directions on communicating classified events to the NRC.

1.4 RELATED GUIDANCE

Regulatory Guide 5.69, Guidance for the Application of Radiological Sabotage Design-Basis Threat in the Design, Development and Implementation of a Physical Security Program that Meets 10 CFR 73.55 Requirements (SGI),

provides background on CYBERATTACKS, up to and including the design basis threat (DBT) of radiological sabotage as described in 10 CFR 73.1 (Ref. 3).

NEI 15-09 (Revision 1)

October 2022

Regulatory Guide 5.83, Cyber Security Event Notifications, provides NRC guidance for use by nuclear power reactor licensees when categorizing certain cybersecurity events, and the process for conducting notifications and submitting written security follow-up reports to the NRC for cybersecurity events. RG 5.83 uses a definition of CYBERATTACK that is different than the definition approved by the NRC for use in the industry Cybersecurity plans. Consequently, the terms and examples in RG 5.83 are different than those provided in NEI 15-09.

The U.S. Department of Homeland Security Cyber and Infrastructure Security Agency website has information related to cybersecurity and cybersecurity event reporting (https://www.cisa.gov/report).

2 REGULATORY GUIDANCE 2.1 CYBERSECURITY EVENT NOTIFICATIONS Licensees subject to the provisions of 10 CFR 73.54 are required to notify the NRC Headquarters Operations Center of the below events via the ENS in accordance with the requirements of 10 CFR 73.77(c).

2.1.1 One-hour Notifications As stated in 10 CFR 73.77(a)(1), licensees are required to notify the NRC within one hour after discovery of a CYBERATTACK that ADVERSELY IMPACTED safety-related or important-to-safety functions, security functions, or emergency preparedness functions (including offsite communications); or that COMPROMISED support systems and equipment resulting in ADVERSE IMPACTS to safety, security, or emergency preparedness functions within the scope of 10 CFR 73.54. As required by 10 CFR 73.54(b)(1), licensees are required to analyze digital computer and communication systems and networks and identify those assets that must be protected against CYBERATTACKS to satisfy 10 CFR 73.54(a)(1). Therefore, it is the CDAs identified by the licensees Cybersecurity plan that are subject to the reporting requirements in 10 CFR 73.77(a)(1) (note NEI 10-04, Identifying Systems and Assets Subject to the Cybersecurity rule, provides additional guidance in this area). Cybersecurity incidents evaluated for reportability for one-hour notifications under 10 CFR 73.77(a)(1) should also be evaluated, by the appropriate departments, for reportability under other applicable regulatory requirements (e.g.,10 CFR 50.72, 73.71).

Licensees should evaluate events that are not reportable under this requirement for reporting or recording under the other provisions of 10 CFR 73.77.

One-hour Notification Examples - Refer to Appendix C 2.1.2 Four-hour Notifications As stated in 10 CFR 73.77(a)(2)(i), licensees are required to notify the NRC within four hours after discovery of a CYBERATTACK that could have caused an ADVERSE IMPACT to safety-related or important-to-safety functions, security functions, or emergency preparedness functions (including offsite communications); or that could have

NEI 15-09 (Revision 1)

October 2022 COMPROMISED support systems and equipment, which if COMPROMISED, could have ADVERSELY IMPACTED safety, security, or emergency preparedness functions within the scope of § 73.54. These could be attacks that exploit a CDA, CRITICAL SYSTEM (CS) or a higher security level network (e.g., a network that is isolated (air gapped) or behind a data diode that contains one or more CDAs), that could have but did not cause an ADVERSE IMPACT to SSEP functions. Only one (1) plausible assumption needs to be considered when evaluating if the CYBERATTACK could have caused an ADVERSE IMPACT (Refer to Appendix C, Examples for Implementation and Training Use, examples involving could have caused). For example, activity logs, antivirus protection or an intrusion detection system indicated the presence of MALWARE or unauthorized access/activity occurred on a CDA, CS or higher security level network. For CYBERATTACKS that reach lower security level networks containing CDAs, but boundaries or security controls were in place that prevented the attack from exploiting the CDAs (e.g., business LAN attack where protections or segmentation prevented the attack from spreading to the CDAs residing on the network), notification to the NRC would not be needed under 10 CFR 73.77(a)(2)(i).

As stated in 10 CFR 73.77(a)(2)(ii), licensees are required to notify the NRC within four hours after discovery of a suspected or actual CYBERATTACK initiated by personnel with physical or electronic access to digital computer and communication systems and networks within the scope of 10 CFR 73.54. These are attacks that are initiated by employees, contractors, or vendors that have physical or electronic access to a CDA, CS or a higher security level network. This could include corporate Information Technology (IT) personnel that may not have unescorted access to the plant, but do have electronic access to digital computer and communication systems and networks within the scope of 10 CFR 73.54. It could also include personnel that do have unescorted access to the plant, but may not have electronic access to digital computer and communication systems and networks within the scope of 10 CFR 73.54. These attacks should be reported within four hours regardless of their impact on SSEP functions.

As stated in 10 CFR 73.77(a)(2)(iii), licensees are required to notify the NRC within four hours after notification of a local, state, or other federal agency (e.g., law enforcement, Federal Bureau of Investigation) of an event related to the licensees implementation of their cybersecurity program for digital computer and communication systems and networks within the scope of 10 CFR 73.54 that does not otherwise require a notification under other applicable regulatory requirements.

Licensees should evaluate events that are not reportable under this requirement for reporting or recording under the other provisions of 10 CFR 73.77.

Four-hour Notification Examples - Refer to Appendix C 2.1.3 Eight-hour Notifications As stated in 10 CFR 73.77(a)(3), licensees are required to notify the NRC within eight hours after receipt or collection of information regarding observed behavior, activities, or statements that may indicate intelligence gathering or pre-operational planning related to

NEI 15-09 (Revision 1)

October 2022 a CYBERATTACK against digital computer, and communication systems and networks that fall within the scope of 10 CFR 73.54.

Generally, eight-hour notifications should include behavior, activities, or statements that are coordinated and/or targeted. This may include targeted malicious activities against devices residing on the same network as a CDA, or on devices which support CDAs, such as monitoring and alerting functions or portable media scanning kiosks. Only information deemed to be CREDIBLE by security should be considered for this reportability criterion.

Additionally, licensees should evaluate events that are not reportable under this requirement for reporting or recording under the other provisions of 10 CFR 73.77.

Eight-hour Notification Examples - Refer to Appendix C 2.2 24-HOUR RECORDABLE EVENTS As stated in 10 CFR 73.77(b), licensees are required to use their site CAP (Corrective Action Program) to record vulnerabilities, weaknesses, failures and deficiencies in their 10 CFR 73.54 cybersecurity program as well as record notifications made under paragraph (a) of 10 CFR 73.77 within twenty-four hours of their discovery.

This includes items or events such as: (1) when a cybersecurity control for a system, component or program has been reduced to the degree that it is rendered ineffective for the intended purpose (e.g., cessation of proper functioning); (2) a defect in equipment, personnel, or procedure that degrades the function or performance of the cybersecurity program necessary to meet the requirements of 10 CFR 73.54; (3) a feature or attribute in a systems design, implementation, operation, or management that could render a CDA open to exploitation, or an SSEP function susceptible to ADVERSE IMPACT. However, some licensees may choose to use their site CAP to capture other Cybersecurity plan issues in which the 24-hour recordable event requirement is not applicable. This would include things such as (1) minor procedural errors, and (2) issues that do not reduce the effectiveness of the Cybersecurity program in any way.

Licensees should utilize the site CAP to perform periodic evaluations to identify any noticeable trends and/or increases in failures and deficiencies in their cybersecurity program (e.g., equipment vulnerabilities and failures, procedural and/or training weaknesses and deficiencies) to assist in identifying and developing program improvements.

24-hour Recordable Event Examples - Refer to Appendix C 2.3 NOTIFICATION PROCESS As stated in 10 CFR 73.77(c), each licensee is required to make notifications required by 10 CFR 73.77(a) to the NRC Headquarters Operations Center via the ENS. If the ENS is inoperative or unavailable, the licensee shall make the notification via commercial telephone service or other dedicated telephonic system or any other methods that will

NEI 15-09 (Revision 1)

October 2022 ensure a report is received by the NRC Headquarters Operations Center within the specified timeframe. Commercial telephone numbers for the NRC Headquarters Operations Center are specified in appendix A to Part 73, U.S. Nuclear Regulatory Commission Offices and Classified Mailing Addresses. Notifications can be annotated on an Event Notification Worksheet (NRC Form 361). Licensees may obtain an event number and time during notifications. If an LER (Licensee Event Report) is required, the licensee may include this information in the LER to provide a cross-reference to the notification, making the event easier to trace.

The individual responsible for conducting the notification should be properly trained and sufficiently knowledgeable of the event to report it correctly.

The NRC records all conversations with the NRC Operations Center. The recordings are saved for one month in case there is a public or private inquiry.

Additionally, if needed, licensees should conduct additional notifications describing substantive changes, additions, or modifications to the initial notification in a timely manner after taking immediate actions to protect the facility or stabilize operations, in accordance with emergency and contingency response procedures.

More than one event can be reported in a single ENS or LER if (1) the events are related (i.e., they have the same general cause or consequence) and (2) they occurred as a single activity over a reasonably short time (e.g., within four or eight hours for ENS notifications, or within 60 days for an LER). Generally, an LER is intended to address a specific event and unrelated events should not be reported in one LER. However, multiple notifications may be addressed in a single telephone call.

Discussion of an event requiring notification under 10 CFR 73.77 with the NRC staff (e.g., resident inspector) does not constitute the required notification to the NRC Headquarters Operations Center. Nor does identification or discovery of events by the NRC staff relieve a licensee from the requirements to notify the NRC Headquarters Operations Center within the timeframes specified in 10 CFR 73.77(a).

2.3.1 Notifications Containing Safeguards Information Under 10 CFR 73.22(f)(3), licensees may make notifications of cybersecurity events specified in 10 CFR 73.77, which are considered to be extraordinary conditions, containing Safeguards Information to the NRC Headquarters Operations Center without using a secure communications system. Licensees should not delay notification of such events beyond one hour after discovery to wait for secure communications. However, if available, a licensee should use a secure communications system to make the notification and protect the Safeguards Information contained in the report from unintentional or inadvertent disclosure. Additionally, licensees should apply this exception to actual events only. As such, it should not be applied to simulated events communicated as part of a drill or exercise, or to routine events (e.g., the retraction of a previous security report as invalid).

NEI 15-09 (Revision 1)

October 2022 2.3.2 Notifications Containing Classified Information Licensees making notifications under 10 CFR 73.77 that contain classified National Security Information (NSI) or Restricted Data (RD) should notify the NRC Headquarters Operations Center using a secure communications system equivalent (at a minimum) to the classification level of the notification. Licensees making classified notifications should contact the NRC Headquarters Operations Center at the commercial telephone numbers specified in appendix A to Part 73 and request a number to a secure telephone.

If the licensees secure communications capability is unavailable (e.g., because of the nature of the event), the licensee should provide as much information to the NRC as is required by 10 CFR 73.77, without revealing or discussing any classified information.

The licensee should also indicate to the NRC at the beginning of the notification that its secure communications capability is unavailable, in order to prevent the inadvertent disclosure of classified information.

If the nature of the cybersecurity event warrants, NRC Emergency Response Management may direct the licensee to use any available non-secure communications method to immediately communicate classified information to the NRC (regarding cybersecurity event notifications required by 10 CFR 73.77). If so directed, the licensee should provide the classified information to the NRC over the best available non-secure system (e.g., the NRC staff considers using an available non-secure land-line as preferable to using an available non-secure cellular or satellite system).

In the written security follow-up report for the classified cybersecurity event notification over non-secure communications, the licensee should document the direction given by the NRC, the reason for the unavailability of a secure communications capability, and the specific classified information that was communicated to or from the NRC over the non-secure communications. The written security follow-up report should be appropriately marked and classified by the licensee. The NRC will use the information in the written security follow-up report to assess the level of impact of the COMPROMISE of classified information communicated by the licensee, or the NRC over non-secure communications, in accordance with Executive Order 13526, Classified National Security Information (Ref. 6).

2.3.3 Continuous Communications For some cybersecurity events notifications conducted under 10 CFR 73.77(a)(1), the NRC may request that the licensee maintain an open and continuous communication channel with the NRC Headquarters Operation Center. Human-to-human communication may be beneficial in order to provide for follow-up questions and clarifications, requests for information or actions, and to facilitate NRC response activities. Note: Because notifications have specified timeframes and are based on after discovery of an event, the NRC realizes that the initial notification may be conducted by an individual not knowledgeable about cyber-related activities. However, a cybersecurity event requiring notification to the NRC should prompt activation of an investigation to determine appropriate immediate and corrective actions (e.g., a Cybersecurity Incident Handler (IH) or the Cybersecurity Incident Response Team (CSIRT)). After ensuring safe and secure

NEI 15-09 (Revision 1)

October 2022 operations of the plant, a member of the investigation (e.g., the IH of CSIRT member)

(i.e., knowledgeable about cyber-related activities as well as the current cybersecurity event) should follow-up the initial notification if there are any additions or modifications to the initial notification.

2.3.4 Retraction of Notifications Licensees desiring to retract a previous cybersecurity event notification that they have determined (through analysis or investigation) to be non-reportable (i.e., does not meet the threshold of a one-, four- or eight-hour notification) must notify the NRC Headquarters Operations Center by telephone, in accordance with 10 CFR 73.77(c)(5),

and indicate the notification being retracted and the basis for the retraction.

Cybersecurity events may be retracted at any time following the notification to the NRC.

However, if a written security follow-up report has already been submitted licensees should refer to the additional guidance in Section 2.4.3 below on documenting retractions.

2.3.5 Declaration of Emergencies Licensees reporting cybersecurity events under 10 CFR 73.77 that also involve the declaration of an Emergency Classification (e.g., Notification of Unusual Event (NOUE),

Alert, Site Area Emergency, or General Emergency), in accordance with their NRC-approved Emergency Plan, should follow the appropriate regulations regarding the declaration of an emergency. In other words, emergency declarations have primacy over cybersecurity event notifications. Consequently, to reduce unnecessary burden and duplication, licensees should make a single report of the events that are subject to both emergency declaration and cybersecurity event notifications if it is known at the time of the Emergency Classification that a cyberattack was in direct association with the event.

The more likely scenario is that a cyberattack caused the event resulting in an Emergency Classification. In this scenario, determination that the event was caused by a cyberattack could come significantly later due to the investigative nature of the verification. A licensee is still required to make notification under 10 CFR 73.77 upon verification of the cyberattack regardless of how much time has elapsed since the Emergency Classification was declared. Licensees should indicate in their notification all the applicable reporting requirements for the event. However, a licensee may need to report additional information regarding a cybersecurity event that would not be included in an emergency declaration notification.

2.3.6 Elimination of Duplication Licensees are not required to make separate notifications for cybersecurity events that also result in the declaration of an emergency. In such circumstances, licensees should make the emergency notifications in accordance with existing regulations (e.g., 10 CFR 50.72). Duplicate notifications are not required for other types of events (e.g., notification of a local, state or other federal agency) that meet the threshold of more than one of NRCs reporting regulations. However, when making such a notification, the licensee

NEI 15-09 (Revision 1)

October 2022 should indicate to the NRC that the notification is also to report a cybersecurity event under a specific paragraph of 10 CFR 73.77.

2.3.7 Content of Notifications Licensees should be prepared to provide the following information, if available at the time of the notification:

1. caller name and callback number,

2. facility name and location,

3. emergency classification (if declared),

4. current event status (e.g., in progress, recovered),

5. event date and time (discovery of, and actual occurrence if known),

6. event description including the following information if available or known:

a. cybersecurity controls involved/affected (if any)

b. system(s) involved/affected (SSEP functions, BOP functions, CDAs, CS)

c. method used to identify the event (e.g., security controls, audit, failed equipment)

d. what occurred during the event

e. why the event occurred, if known

f. how the event occurred, if known

7. safety, security, EP responses and corrective actions taken,

8. offsite assistance (e.g., requested or not requested, arrived, status),

9. media interest, if any, including licensee issued press releases,

10. source of information (e.g., U.S. Computer Emergency Readiness Team, law enforcement) if a law enforcement agency, provide contact telephone number.

2.3.8 Voluntary Notifications Licensees are permitted and encouraged to report any cyber-related event or condition that does not meet the criteria for required reporting, if the licensee believes that the event or condition might be of safety or security significance or of generic interest or concern to the NRC or other licensees. Assurance of safe operation of all plants depends on accurate and complete reporting by each licensee and of all events having potential safety/security significance. For example, a cyber-related event or condition identified

NEI 15-09 (Revision 1)

October 2022 and mitigated outside the plant network with no impact on SSEP functions may be indicative of a recently identified or known cyber threat. Such activities should be voluntarily reported to the NRC to support Federal situational awareness activities.

Licensees may make voluntary ENS notifications about cyber-related events or conditions that the licensee believes might be of interest to the NRC. The NRC responds to any voluntary notification of an event or condition as its safety or security significance warrants, regardless of the licensees classification of the reporting requirement. If it is determined later that the event is reportable, the licensee can change the ENS notification to a required notification under the appropriate 10 CFR 73.77 reporting criterion without adverse consequences as long as the voluntary report met the appropriate timeframe and information required of the required notification. Voluntary notifications do not require a written security follow-up report unless later it is determined the event was reportable under 10 CFR 73.77 reporting criteria.

2.4 WRITTEN FOLLOW-UP REPORTS Telephonic notifications to the NRC Headquarters Operations Center for cybersecurity events specified in paragraphs (a)(1), (a)(2)(i) and (a)(2)(ii) of 10 CFR 73.77 require submission of a written security follow-up report to the NRC within 60 days of the notification in accordance with 10 CFR 73.77(d). Licensees should follow the procedures set forth in 10 CFR 73.4 when submitting their follow-up report. The NRC does not require licensees who have made a notification to the NRC Headquarters Operations Center for cybersecurity events specified in 10 CFR 73.77(a)(2)(iii), and (a)(3) to submit written security follow-up reports. In addition, cybersecurity events recorded in the site CAP under 10 CFR 73.77(b) do not require written security follow-up reports.

Written security follow-up reports submitted should be of a format and quality to allow legible reproduction and processing. The written security follow-up reports should contain sufficient details, information, and analysis to allow a knowledgeable individual to understand what occurred during the event. For example, whether any administrative or technical errors occurred, what equipment was involved and/or malfunctioned, what CDAs and/or SSEP functions were affected, if the event involved new hardware and/or software being installed to include PATCHES and updates, or from changes in system settings or configuration. Additionally, the licensee should indicate whether any immediate corrective actions were taken (to include compensatory measures if applicable) and any long-term corrective actions that are planned to prevent recurrence.

In accordance with 10 CFR 73.77(d)(12), licensees must retain a copy of any written security follow-up reports submitted to the NRC for at least three years or until the termination of the license, whichever comes first.

2.4.1 NRC Form 366 and 366A Nuclear power reactor licensees should submit any written security follow-up reports to the NRC required by 10 CFR 73.77 using NRC Form 366, Licensee Event Report (LER), and NRC Form 366A, Licensee Event Report Continuation Sheet, if additional pages are needed.

NEI 15-09 (Revision 1)

October 2022 For licensees utilizing the NRC Form 366, items 1 through 15 should be completed as labeled (if known or applicable). For example, for the first item, 1. Facility Name, enter the name of the facility (e.g., Indian Point, Unit 1) at which the event occurred. For item 11, check the block that indicates the appropriate requirement (e.g., 10 CFR 73.77(a)(1)).

If it is a voluntary LER, check the Other block and indicate voluntary report in the space below. For item 16, Abstract, provide a brief description of the cyber event including any failures or degradations that contributed to the event (e.g., user error, procedure violation, cybersecurity controls) include any CDAs and/or SSEP functions that were impacted by the occurrence and to what extent (e.g., temporarily lost remote (digital) control of the Protected Area Active Vehicle Barrier System due to bad firmware update, barriers were in the up position, and were controlled manually until previous firmware was re-loaded, no unauthorized accesses occurred during this event.).

The NRC Form 366A should be used to provide additional details about the cybersecurity event to include the content requested from Section 2.4.6 below.

Generally, licensee submitted LERs will be made publicly available by the NRC.

However, information that is designated by the licensee as, for example, proprietary, safeguards, or classified information, will be withheld (redacted) from the public, as appropriate. Licensees should create, store, mark, label, handle and transmit LERs in accordance with applicable NRC regulations (e.g., 10 CFR 2.390, 73.21, 73.22, part 95).

When designated information (e.g., proprietary, safeguards, classified) is included with the LER it should only be entered in item 17, Narrative, of NRC Form 366A and not included on the NRC Form 366. In addition, the text should clearly indicate what information is designated as proprietary, safeguards, classified, etc.

2.4.2 Significant Supplemental Information and Correction of Errors Licensees who discover significant supplemental information after the submission of a written security follow-up report to the NRC should submit a revised written report, in accordance with the same process as used to submit the initial written report.

Additionally, licensees who discover errors in a written report previously submitted to the NRC should submit a revised written report, in accordance with the same process as used to submit the initial written report. A revised written report should replace the previous written report (i.e., the updated report should be complete and should not be limited to only the supplementary or revised information). The revised report should indicate the revision number with revision bars to assist the reader.

2.4.3 Retraction of Previous Written Security Follow-up Reports If a licensee subsequently retracts a notification made under 10 CFR 73.77 and has not yet submitted the written security follow-up report required by 10 CFR 73.77(d), the NRC does not require the licensee to submit the written security follow-up report.

However, if the licensee has already submitted a written security follow-up report to the NRC before it retracts the notification, the licensee should then submit a revised written report to the NRC indicating the initial event has been retracted and the basis for that conclusion. This supplemental written security follow-up report is necessary because

NEI 15-09 (Revision 1)

October 2022 without the supplemental report (retracting the notification), the only official agency record on the notification would be the initial written security follow-up report, which would not include the retraction.

2.4.4 Written Security Follow-up Reports Containing Safeguards Information Licensees who submit written security follow-up reports to the NRC containing Safeguards Information should create, store, mark, label, handle, and transmit these written reports in accordance with the requirements in 10 CFR 73.21 and 73.22.

Licensees should perform a safeguards designation of such reports. Written security follow-up reports should be portion marked to indicate the designation level of the reports information.

2.4.5 Written Security Follow-up Reports Containing Classified Information Licensees who submit written security follow-up reports to the NRC containing classified NSI or RD should create, store, mark, label, handle, and transmit these reports in accordance with the requirements of 10 CFR Part 95, Facility Security Clearance and Safeguarding of National Security Information and Restricted Data (Ref. 7). Licensees should perform a derivative classification of such reports in accordance with the classification guide(s) applicable to their facility or activity. Written security follow-up reports should be portion marked to indicate the classification level of the reports information. If the written security follow-up report requires an original classification determination, then the licensee should make a provisional classification decision; mark, handle, store, and transmit the document according to that provisional decision; and forward the document to the NRC for an original classification determination.

2.4.6 Content of Written Security Follow-up Reports Licensees preparing written security follow-up reports should include sufficient information for the NRC to analyze the cybersecurity event. The NRC staff recommends that written security follow-up reports contain, at a minimum, the following information, as applicable:

1. date and time of the event, including chronological timeline, if applicable,

2. date and time of notification to the NRC, and/or local, state and federal agencies,

3. the reactors operating mode at time of event (e.g., shut down, operating),

4. SSEP functions directly or indirectly affected by the event (e.g., COMPROMISED, failed, degraded),

5. support systems or equipment directly or indirectly affected that could have COMPROMISED SSEP functions (e.g., COMPROMISED, failed, degraded),

6. CDAs and/or CS affected by the event (COMPROMISED, failed, degraded),

NEI 15-09 (Revision 1)

October 2022

7. security controls involved in the event (e.g., COMPROMISED, performed as intended),

8. personnel involved or contacted, such as contractors; security personnel; visitors; plant staff; perpetrators or attackers; NRC personnel; local, state, or federal responders; and other personnel (specify),

9. method of discovery of the event, or information, such as routine patrol or inspection, test, maintenance, alarm annunciation, audit, communicated threat, unusual circumstances (include details),

10. immediate actions taken in response to the event and any compensatory measures established,

11. description of media interest and press releases,

12. indications or records of previous similar events,

13. procedural or human errors or equipment failures, as applicable,

14. cause of the event, or the licensees analysis of the event (including a brief summary in the report and references to any ongoing or completed detailed investigations, assessments, analyses, or evaluations),

15. corrective actions taken or planned, including dates of completion,

16. name and phone number of a licensees point of contact,

17. For failures, degradations, or discovered vulnerabilities of the cybersecurity program, licensees should also provide the following information, as applicable, in addition to items a. through f. above:

a. description of failed, degraded, or vulnerable equipment, systems or controls (e.g., manufacturer and model number, procedure number),

b. unusual conditions that may have contributed to the failures, degradations, or discovered vulnerabilities of the equipment, systems or controls (e.g., environmental conditions, plant outage, software update),

c. security settings/configuration of the components, systems or controls that failed, or became degraded or vulnerable,

d. apparent cause of component, system or control failure, degradation, or vulnerability.

e. Training of Non-security Staff on Reporting and Recording Requirements The discovery or identification of reportable or recordable events is not limited to members of the licensees security organization. Employees, contractors, and vendors

NEI 15-09 (Revision 1)

October 2022 with physical or electronic access to digital computer and communications systems and networks within the scope of 10 CFR 73.54 should receive training on cybersecurity event notifications. This training fosters awareness and understanding of their responsibility to immediately notify site-security or management personnel of anomalies, failures, degradations, or vulnerabilities in the cybersecurity program. This includes activities that may indicate intelligence gathering or preoperational planning related to CYBERATTACKS. Licensees may provide this training during general plant training and periodic refresher training. The NRC staff notes that some licensees have also found it beneficial to include training tips or elements of the training program in recurring plant publications, such as newsletters, electronic signs, or other organizational reminders.

NEI 15-09 (Revision 1)

October 2022

[BLANK PAGE]

NEI 15-09 (Revision 1)

October 2022 APPENDIX A - REPORTABILITY DECISION FLOWCHART AND INSTRUCTIONS

NEI 15-09 (Revision 1)

October 2022

[BLANK PAGE]

NEI 15-09 (Revision 1)

October 2022 Step 1 BEGIN: Undesired Condition/Event Undesired condition or event exists.

An Undesired Condition includes behavior, practice or event that warranted generation of condition report.

Step 2 Identification Personnel identify the condition. The method by which adverse conditions may be identified varies greatly and may include, but is not limited to:

An observed component failure, malfunction, deficiency, deviation, defect or an operational disturbance.

Receipt or collection of information regarding observed behavior, activities, or statements that may indicate intelligence gathering or pre-operational planning related to a CYBERATTACK against digital computer and communication systems and networks Step 3 Communication of Issue - Immediate Security/Safety Concern?

Plant Personnel communicates issue commensurate with the safety significance.

Step 3a Condition or issue is entered into CAP.

Step 3b/c Contact STA or SM / Notify Security Officer If there is a known immediate security/safety concern, Plant Personnel notifies security and/or contacts the Shift Technical Advisor (STA) or Shift Manager (SM). The undesired condition is subsequently entered into CAP.

Physical Security may be contacted to report Security related issues. Per logic block 3c, the Security organization should notify the Operations Shift Technical Advisor or Shift Manager so that proper individuals are included in the investigation, which may lead to the initiation of an investigation team (e.g., cybersecurity Incident Handler (IH) or cybersecurity incident response team (CSIRT). The CSIRT is used for the remainder of the flowchart instructions). If Security has other processes that are followed when an incident is reported to them, make sure to review the process and identify any steps that could bypass the necessary steps to involve personnel that would evaluate the incident for cyber reporting.

Step 4 CAP Review Regulatory Affairs and Operations reviews shift CAP entries for unidentified, potential reportability issues.

Step 5 Troubleshoot - Caused by or Impacts Digital or Cyber Element?

Operations and/or involved Plant Personnel evaluate the plant issue to determine the cause.

If it is immediately apparent that the cause of the plant issue is the result of, or has a known impact to, a digital system, digital component or an element of the Cybersecurity program, the issue must be screened to determine if an NRC Event Notification is required.

When the immediate cause of the issue is unknown, Operations and/or involved Plant Personnel may utilize standard processes to further investigate or troubleshoot the issue (e.g., troubleshooting procedures, field investigation, Failure Investigation Process, Operability Determinations, cause evaluation, etc.). If at any point it is determined that the cause of the plant issue is the result of, or has a known impact to, a digital system, digital component or an element of the Cybersecurity program, the issue must be screened to determine if an NRC Event Notification is required.

Step 5a Contact CSIRT Duty Analyst Operations should contact the Cybersecurity Incident Response Team (CSIRT) Duty Analyst if assistance is needed to determine the questions posed in Step 5.

Step 5 and 5a in the flow chart represents the troubleshooting/evaluation that occurs when responding to an undesired condition/event. As described in the flow chart explanation, various departments and

NEI 15-09 (Revision 1)

October 2022 associated personnel will troubleshoot the issue using standard processes to determine the scope of the event, potential cause, extent of condition, magnitude of impact, etc. Logic block 5 is ultimately intended to determine whether the incident involves digital equipment or elements of the cybersecurity program that may require a report under 10 CFR 73.77. This step is not asking whether cyber is the cause of the event, but rather if digital equipment or cyber program elements are involved in the event to ensure the right personnel are contacted for investigation. As part of responding to the undesired condition/event, personnel should consider two things:

1) Consider whether the undesired condition/event involves digital assets or digital systems, including digital support equipment.

For the purpose of this guidance, digital equipment includes, but is not limited to:

Digital assets (e.g., HMI, digital flow transmitter, PLC, network switch, digital chart recorder, etc.)

Digital support system (e.g., digital HVAC controls, digital power controller, digital fire protection equipment, etc.)

Portable Media and Mobile Devices (PMMDs) (e.g., thumb drive, laptop, HART communicator, CD/DVD, etc.)

The involvement of digital equipment (directly or indirectly) in the event may indicate that a COMPROMISE of the digital equipment led to the cause of the event and further investigation by cybersecurity point of contact is necessary to further determine if a cybersecurity report is required per 10 CFR 73.77.

2) What is referred to as a cyber element?

A cyber element refers to any cybersecurity controls, tools, or personnel behaviors that are associated with the cybersecurity program or outlined in the site Cybersecurity plan. If there is indication that someone or something has negatively impacted the cyber program, caused elements of the program to become less effective, or there is indication of intelligence gathering or pre-operational planning related to a CYBERATTACK, this may warrant a cybersecurity report and further investigation is needed.

For example:

Cybersecurity Control Impact -

a) System owner was called on by Operations to respond to a DCS alarm; the engineer immediately noticed a rogue connection that was a bypass of the defensive architecture per CSP 4.3.

b) During a walk-down of the turbine control system, an unauthorized thumb drive was found unattended and connected to the HMI. This situation would be considered traversing the protections of the PMMD program and requires further investigation and may require a cybersecurity report.

Cybersecurity Tools - TAMPERING with or a COMPROMISE of the PMMD scanning station or whitelisting network.

Cybersecurity Behaviors - Indication that someone is organizing or intelligence gathering for conducting a CYBERATTACK. These behaviors should be reported to Security for proper investigation.

During the response to a plant event, if either a digital asset or Cyber Element are suspected to be associated with the event, then the CSIRT duty analyst shall be contacted to further investigate and work with the appropriate organizations to determine if a cybersecurity notification is required. If it is evident that the event has nothing to do with digital equipment or the cybersecurity program, a cybersecurity notification is not required at this time.

NEI 15-09 (Revision 1)

October 2022 Step 6 Enter Reportability Determination Process Where the identified condition or issue merits further investigation, as required by Step 5, to verify that a cybersecurity reportable event has occurred, Operations enters the reportability determination process and contacts the appropriate support personnel to initiate an evaluation using the following guidance:

Step 7a Contact CSIRT Duty Analyst If not already done so in support of Step 5, Operations should Contact the CSIRT Duty Analyst to coordinate obtaining the necessary technical resources for evaluating the issue and to assist in the reportability determination.

The Duty Analyst is contacted by Operations if there is reason to believe that the undesired condition/event is related to the characteristics described in logic block 5. This person is defined in the Incident Response procedure. The Duty Analyst is a member of the Digital Process Systems (DPS)

Engineering team. The CSIRT Manager is the Manager of this DPS group. The Duty Analyst shall contact his/her Manager to keep them abreast of the issue reported to them. At some point, the CSIRT Manager may be required to obtain additional resources to respond to the plant event to help determine if cyber is the potential cause.

Step 7b Contact Regulatory Affairs and Security CSIRT and Operations should ensure that the appropriate Regulatory Affairs and Security personnel are aware of the issue and the ongoing evaluation and to solicit input/support in determining if the condition requires an NRC report.

Step 8 Actual or Suspected CYBERATTACK Identified?

CSIRT will perform an initial evaluation to determine if an actual or suspected CYBERATTACK has occurred.

This step in the flowchart helps distinguish between attempts to infiltrate the nuclear environment versus successful entry that could cause an ADVERSE IMPACT. During this step, members of the incident response team will need to convene in order to determine whether there is enough evidence (indication) that would lead to a cybersecurity notification. As part of evaluating the event, the clock starts for the notification once there is indication that one of the three report types is required.

The evaluation of the event needs to consider malicious intent of actions related to the ADVERSE IMPACT on a CDA or SSEP function to determine if the event involved a CYBERATTACK.

Step 8a CSIRT Manager Activates CSIRT If signs of a CYBERATTACK are not obvious, or there is no indication of a CYBERATTACK, but further investigation is needed, a preliminary assessment may be required to rule out other common degradations or failures. In such situations, the CSIRT Manager will activate the CSIRT.

Step 8b CSIRT Investigates for Verification of CYBERATTACK CSIRT performs the necessary investigation to verify that a Cybersecurity Attack has occurred.

Step 9 CYBERATTACK Caused ADVERSE IMPACT to SSEP Functions?

CSIRT and supporting organizations determine if a one-hour report is required per 10 CFR 73.77(a)(1):

o A one-hour report is required in accordance with 10 CFR 73.77(a)(1) when the CYBERATTACK ADVERSELY IMPACTED safety related or important-to-safety functions, security functions, or emergency preparedness functions (SSEP) (including offsite communications); or COMPROMISED support systems and equipment resulting in ADVERSE IMPACTS to safety, security, or emergency preparedness functions within the scope of § 73.54.

NEI 15-09 (Revision 1)

October 2022 Step 10 CYBERATTACK Could have caused ADVERSE IMPACT to SSEP Functions?

CSIRT and supporting organizations determine if a four-hour report is required per 10 CFR 73.77(a)(2)(i):

o A four-hour report is required in accordance with 10 CFR 73.77(a)(2)(i) when the CYBERATTACK could have caused an ADVERSE IMPACT to SSEP functions (including offsite communications); or that could have COMPROMISED support systems and equipment, which if COMPROMISED, could have ADVERSELY IMPACTED SSEP functions within the scope of § 73.54.

Only one (1) plausible assumption needs to be considered when evaluating if the CYBERATTACK could have caused an ADVERSE IMPACT. If the answer to this question is not immediately apparent, consider if a four-hour report is already required under 10 CFR 73.77(a)(2)(ii) (Step 11).

Step 11 CYBERATTACK Initiated by Personnel with Access?

Where Step 9 or 10 does not result in a report, CSIRT and supporting organizations determine if a four report is required per 10 CFR 73.77(a)(2)(ii):

o A four-hour report is required in accordance with 10 CFR 73.77(a)(2)(ii) when a suspected or actual CYBERATTACK was initiated by personnel with physical or electronic (i.e., logical) access to digital computer and communication systems and networks within the scope of

§ 73.54.

Step 12 Local, State or Federal Agency Contacted?

CSIRT and supporting organizations determine if a four report is required per 10 CFR 73.77(a)(2)(iii):

o A four-hour report is required in accordance with 10 CFR 73.77(a)(2)(iii) after notification of a local, state, or other federal agency (e.g., law enforcement, FBI, etc.) of an event related to the licensees implementation of their cybersecurity program for digital computer and communication systems and networks within the scope of § 73.54 that does not otherwise require a notification under paragraph (a) of this section.

Step 13 Pre-CYBERATTACK Intelligence or Preoperational Planning?

CSIRT and supporting organizations determine if an eight report is required per 10 CFR 73.77(a)(3):

o An eight-hour report is required in accordance with 10 CFR 73.77(a)(3) after receipt or collection of information regarding observed behavior, activities, or statements that may indicate intelligence gathering or pre-operational planning related to a CYBERATTACK against digital computer and communication systems and networks within the scope of § 73.54.

Step 14 CS Program Vulnerability, Weakness, Failure?

CSIRT and supporting organizations determine if the issue constitutes a vulnerability, weakness, failure or deficiency of the Cybersecurity program.

Step 14a 73.77(b) CAP Recordable Ensure any such issues are recorded in the site corrective action program within twenty-four hours of their discovery.

Step 15 Organizational Concurrence If at any point the Cybersecurity incident lead determines that one or more of the reporting criteria was met, CSIRT should brief the issue to the appropriate stakeholders (e.g., Operations, Regulatory Affairs, Security and Emergency Preparedness (where applicable) and gain organizational concurrence on the details and the appropriate reporting requirements.

Step 16 END:

Make Necessary ENS Telephone Call to NRC. Where no CSEN report is required, exit process.

NEI 15-09 (Revision 1)

October 2022

[BLANK PAGE]

NEI 15-09 (Revision 1)

October 2022 APPENDIX B - GUIDANCE FOR DETERMINING START OF REPORTABILITY CLOCK Guidance for evaluating whether cyber is the cause of the event and for when sufficient information exists starting the reportability notification clock.

Time of discovery for reportability purposes begins when the Cybersecurity incident lead (e.g., Incident Handler (IH) or Cybersecurity Incident Response Team (CSIRT)) determines that one or more of the reporting criteria was met. Time of discovery does not start when a digital component (CDA) is found to be in a failed or COMPROMISED state. The discovery of a failed or COMPROMISED state does require a decision as to whether the failure was caused by a CYBERATTACK or some other failure mechanism. The timeliness of the investigation needs to be commensurate with the safety significance of the issue (Reference 12). The investigations of the technical impact and the malicious intent aspect are both needed in the determination of reportability and should be pursued expeditiously. The outputs from these investigations come together in decision blocks 8 through 14 in Appendix A, Reportability Decision Flowchart And Instructions. Each reporting criterion is discussed below:

1 hour1.157407e-5 days 2.777778e-4 hours 1.653439e-6 weeks 3.805e-7 months notification - required by 10 CFR 73.77(a)(1) if a CYBERATTACK ADVERSELY IMPACTED SSEP functions or COMPROMISED support systems and equipment resulting in ADVERSE IMPACTS to SSEP functions. This reporting criterion is triggered ONLY if ADVERSE IMPACT to SSEP functions occurs and it is determined by the Shift Manager or IH or CSIRT that there is reason to believe the cause of the ADVERSE IMPACT is or is likely to be a CYBERATTACK as defined in the Cybersecurity plan. A CYBERATTACK is any event in which there is reason to believe that an ADVERSARY has committed or caused, or attempted to commit or cause, or has made a CREDIBLE threat to commit or cause malicious exploitation of a CDA. In the context of a 1-hour notification, the ADVERSARY has to have successfully caused ADVERSE IMPACT to one or more SSEP functions that resulted in an ADVERSE IMPACT.

4-hour notification - required by 10 CFR 73.77(a)(2)(i) if a CYBERATTACK could have ADVERSELY IMPACTED SSEP functions or could have COMPROMISED support systems and equipment resulting in ADVERSE IMPACTS to SSEP functions. This reporting criterion is triggered ONLY if it is determined by the Shift Manager or IH or CSIRT that an actual, unsuccessful, CYBERATTACK as defined in the Cybersecurity plan occurred. A CYBERATTACK is any event in which there is reason to believe that an ADVERSARY has committed or caused, or attempted to commit or cause, or has made a CREDIBLE threat to commit or cause malicious exploitation of a CDA. In the context of this 4-hour notification, the ADVERSARY has to have attempted to cause ADVERSE IMPACT to one or more SSEP functions that, if successful, would have resulted in an ADVERSE IMPACT to one or more SSEP functions.

4-hour notification - required by 10 CFR 73.77(a)(2)(ii) if a CYBERATTACK was initiated by personnel with physical or electronic access to digital computer and communication systems and networks within the scope of 10 CFR 73.54. This reporting criterion is triggered if it is determined by the Shift Manager or IH or CSIRT that there is reason to believe that an actual

NEI 15-09 (Revision 1)

October 2022 attack was initiated by personnel with physical or electronic access. It is also triggered if the IH or CSIRT suspects, but cannot absolutely confirm, that an actual attack was initiated by personnel with physical or electronic access. In the context of this 4-hour notification, the key is the initiation, or attempt by personnel with physical or electronic access. The attack does not have to be successful, nor does it have been carried out to completion - it only has to be initiated.

4-hour notification - required by 10 CFR 73.77(a)(2)(iii) if any local, state, or federal agency is notified of an event related to the implementation of the cybersecurity program. For this criterion, making a notification, related to the cybersecurity program, to another government agency triggers the reporting criteria, and starts the clock as time of discovery. This is similar to four-hour reporting under 10CFR50.72(b)(2)(xi) for notifications made to other governmental agencies.

8-hour notification - required by 10 CFR 73.77(a)(3) after receipt or collection of information regarding observed behavior, activities, or statements that may indicate intelligence gathering or pre-operational planning related to a CYBERATTACK. This information could either be received from an outside organization, such as the FBI, or collected by the site. In the event that the site is contacted from a governmental organization with CREDIBLE information regarding intelligence gathering or pre-operational planning related to a CYBERATTACK, time of discovery would be the receipt of the CREDIBLE information. If the genesis of the information is the on-site collection of information, time of discovery is when the Security Manager or IH or CSIRT reviews the collected information and determines that it is indicative of intelligence gathering or pre-operational planning related to a CYBERATTACK.

NEI 15-09 (Revision 1)

October 2022 APPENDIX C - EXAMPLES FOR IMPLEMENTATION AND TRAINING USE

1-hour notification - CYBERATTACK that ADVERSELY IMPACTED an SSEP function:

C.1.1 A CYBERATTACK that ADVERSELY IMPACTED (e.g., interruption) the normal operation of the facility through the unauthorized use of, or TAMPERING with, digital computer and communication systems and networks.

C.1.2 A CYBERATTACK that ADVERSELY IMPACTED the capability to shut down the reactor and maintain it in a safe shutdown condition, remove residual heat, control the release of radioactive material or mitigate the consequences of an accident, even if the affected system was not required to perform its function during the period of impact.

C.1.3 A CYBERATTACK that ADVERSELY IMPACTED the capability to detect, delay, assess, or respond to malevolent activities. For example, a CYBER INCIDENT involving an intentional act resulting in an ADVERSE IMPACT on a CDA that disrupts a security function responsible for the implementation of the sites physical protection program and/or protective strategy such as, an intrusion detection and assessment system, a physical barrier (e.g., active vehicle barrier, delay barrier), an access control system, an alarm station, or a communication system.

C.1.4 A CYBERATTACK that ADVERSELY IMPACTED an EP-related CDA and the capability to call for, or communicate with, offsite assistance.

C.1.5 A CYBERATTACK that ADVERSELY IMPACTED an EP-related CDA and emergency response capabilities to implement appropriate protective measures in the event of a radiological emergency.

C.1.6 After an unplanned outage, the vendor was brought in to work on the automatic voltage regulator (AVR) personal computer. The vendors escort turned his back to take a phone call and the vendor made some changes to the system. Later, the AVR trips the unit causing another unplanned outage, due to the changes the vendor made while the escorts back was turned. A 1-hour notification reportability clock starts if it is determined that there is reason to believe there was malicious human intervention that intended to cause the malfunction.

C.1.7 The hand geometry readers deny access to authorized plant workers. All the hand geometry units at the protected area entrance, except the service door, were in alarm status. Troubleshooting discovered that a parameter on the security computer was not valid. Site personnel are unsure how the parameter got changed, but it is known that only someone with elevated privileges can make this change.

Since the security system is air-gapped, the only places the change could have taken place would have been in the CAS or SAS. An interview with the involved individuals is necessary to determine if there was malicious intent involved in the configuration change. A CYBERATTACK may have been involved but an

NEI 15-09 (Revision 1)

October 2022 unintentional mistake is also plausible. The change to the parameter would have to have been initiated by someone with physical or logical access within the Protected Area (PA). A 1-hour notification reportability clock starts if the interview or investigation determines there is reason to believe that the officer intentionally changed the parameter due to some malicious intent.

C.1.8 At the time of a maintenance service outage of the backup phone system that provides communication to the Emergency Operations Facility (EOF), the primary phone system experiences a distributed denial of service (DDOS) attack from the internet. The EP function is lost. A 1-hour notification reportability clock starts if it is determined that both phone systems are out of service since there was a malicious intent and an ADVERSE IMPACT to the SSEP function.

C.1.9 A security officer plugs his smartphone into the USB port on the security computer to charge it. The smartphone introduces MALWARE on the network which COMPROMISEs the badging database and causes a denial of service to the security system. Alarms will no longer clear on the security computer, the video feed from the security cameras appears jumpy, and certain vital area doors no longer require badge access to be opened. The antivirus software on the backup security server alerts on the virus and notifies the officer. A 1-hour notification is required because the MALWARE infection resulted in a CYBERATTACK that COMPROMISED an SSEP function. The origination of the malicious intent does not need to be known. A 1-hour notification reportability clock starts if it is determined that that the SSEP function was adversely affected by the MALWARE. If later the event was determined to not involve a malicious attempt to exploit a CDA, the notification may be retracted.

C.1.10 A maintenance worker misreads a procedure and fails to scan a PMD prior to planned maintenance and connects the PMD to each metal detector in the security main access detectors. A post work scan reveals the PMD contains a virus.

Troubleshooting is immediately initiated and reveals the virus is on all of the metal detectors and the sensitivity of the detectors has been adversely affected. A 1-hour notification reportability clock starts if it is determined that the MALWARE infection resulted in COMPROMISE of an SSEP function. While the maintenance worker did not deliberately infect the metal detectors, there was reason to believe there was malicious intent and an ADVERSARY behind the source of the virus.

1-hour notification - CYBERATTACK that COMPROMISED support systems and equipment resulting in ADVERSE IMPACT of an SSEP function:

C.1.11 A CYBERATTACK that ADVERSELY IMPACTED a system providing a support function for a CDA, even if the affected system was not required to perform its function during the period of impact.

C.1.12 Someone tampered with digital HVAC controls that supply cooling to electrical equipment. The problem cannot be corrected, and temperature rises quickly

NEI 15-09 (Revision 1)

October 2022 causing the electrical equipment to shut off on high temperatures. Electrical components (switchgear, circuitry, and/or logic) are negatively affected by rising temperatures, and SSEP equipment is ADVERSELY IMPACTED as a result. A 1-hour notification reportability clock starts if it is determined that someone tampered with the digital controls and the SSEP function of the equipment was COMPROMISED.

C.1.13 The discovery of an intentional unauthorized change of the control setpoint on the Technical Support Center (TSC) HVAC system digital temperature control module that resulted in excessively high temperatures in the TSC making the TSC facility uninhabitable. A 1-hour notification is required once the ADVERSE IMPACT and the control setpoint change are determined.

C.1.14 A CYBERATTACK on the onsite fiber optics system that operates the breakers in the switchyard that supply offsite power to the ESF (Engineered Safety Features) and non-ESF busses. If the CYBERATTACK was to the licensees fiber optic network, then a CDA is adversely affected and reportability under 10 CFR 73.77 is involved. If the CYBERATTACK resulted in ADVERSE IMPACT on an SSEP function (e.g., loss of power to the safeguards power bus resulting in Emergency Diesel Generator (EDG) start), then a 1-hour notification is required. A 1-hour notification reportability clock starts if the investigation reveals that some form of a CYBERATTACK occurred (was not a mechanical equipment failure or was not an accidental trip).

NEI 15-09 (Revision 1)

October 2022

4-hour notification - CYBERATTACK that could have caused an ADVERSE IMPACT to an SSEP function:

C.4.1 A CDA that was isolated or on a higher security level network was found to be connected to a lower security level network (wired or wireless) and cybersecurity controls (e.g., activity logs, antivirus protection, an intrusion detection system, etc.) indicated the pathway had been exploited as evidenced by the presence of MALWARE or unauthorized access/activity had occurred.

C.4.2 An unauthorized transmitter (e.g., wireless router, modem) or unauthorized portable media (e.g., memory stick, smart phone) was attached or connected to a CDA, and cybersecurity controls (e.g., activity logs, antivirus protection, an intrusion detection system, etc.) indicated the pathway had been exploited as evidenced by the presence of MALWARE or unauthorized access/activity had occurred.

C.4.3 The degradation or failure of a CDA or of the cybersecurity controls that protect CDAs that is indicative of unauthorized and malicious activity (e.g., CYBERATTACK, physical tampering), and could have but does not have an immediate or ADVERSE IMPACT on SSEP functions because, for example, the CDA has an analog backup. This does not include common degradations or failures such as mechanical or electrical.

C.4.4 A CYBERATTACK, (e.g., virus or worm logic bomb initiated by an intentional and malicious act) on a CDA, CS or higher security level network, that could have, but did not cause an ADVERSE IMPACT to SSEP functions or that could have compromised support systems and equipment, which if COMPROMISED, could have ADVERSELY IMPACTED SSEP functions.

C.4.5 A CYBERATTACK that caused an ADVERSE IMPACT to a CDAs and/or CSs confidentiality, INTEGRITY or availability, could have but did not cause an ADVERSE IMPACT to SSEP functions or that could have COMPROMISED support systems and equipment, which if COMPROMISED, could have ADVERSELY IMPACTED SSEP functions. For example, if a remote digital control to an active vehicle barrier has been disabled (e.g., loss of communications due to an intentional and malicious act), but the barrier is in the denial position and has not and will not allow unauthorized access as a result of the CYBERATTACK.

C.4.6 A security officer notices an unmarked and believed to be an unauthorized cable run around a cabinet door, connecting a CDA behind the data diode (or air gap) to a network switch on the business network. No signs of actual COMPROMISE exist on the CDA side of the data diode, and the cable is removed before any COMPROMISE occurred, however the cable was installed outside an authorized process. A 4-hour notification reportability clock starts if the investigation determines there is reason to believe that the cable was installed with malicious intent to the CDA. A 4-hour notification is required because, while there was no

NEI 15-09 (Revision 1)

October 2022 actual ADVERSE IMPACT to the SSEP function, there could have been if the pathway was used for COMPROMISE. Escalated to 1 hour1.157407e-5 days 2.777778e-4 hours 1.653439e-6 weeks 3.805e-7 months notification if it is determined there was a COMPROMISE to a SSEP function due to the pathway.

The assumption is that the individual who installed the rogue cable could have used the bypass to COMPROMISE CDAs and adversely impact an SSEP function.

C.4.7 Investigation of an alarm reveals a malicious MALWARE virus on a Feedwater system computer control system. Investigation revealed the virus had the capability of modifying the control system software. The assumption is that the MALWARE could have also COMPROMISED CDAs and ADVERSELY IMPACTED an SSEP function. A 4-hour notification is required if it is determined that that virus had the capability of modifying the software.

C.4.8 With the backup phone system available to provide communication to the EOF, the primary phone system experiences a DDOS attack from the internet. The EP function is maintained by the adequately independent alternative capability. There is a malicious intent and there could be an ADVERSE IMPACT to the SSEP function assuming the backup capability became degraded. A 4-hour notification reportability clock starts if it is determined that the primary phone system went out of service due to the DDOS attack.

C.4.9 During a refueling outage, the polar crane was observed moving without an operator present. The crane controls were in their storage locations and were not in use. In the first instance, the crane raised the now secure reactor head up 3 feet in 4 seconds before immediately changing direction and lowering the head back down. Then, the crane moved the reactor head to the left approximately 10 feet before an operator pressed the emergency stop button. The head came to rest over no safety equipment, but was within 5 feet of a safety related pump. While investigating, it was determined that several of the cranes configuration parameters had been changed. Then, a suspicious box was found in a high radiation area. When security investigated the box, it was determined to be a transmitter with electronic controls and an antenna that could control the crane remotely. A 4-hour notification reportability clock starts if it is determined that a CYBERATTACK had an ADVERSE IMPACT on the crane, but no SSEP functions were impacted. The assumption is that the crane could have moved further and released the reactor head on top of safety related equipment, causing an ADVERSE IMPACT to the SSEP function.

C.4.10 During review of a CSEN event reported by another licensee, a vulnerability scan with an updated scanning engine reveals a similar malicious virus with an unexpired timer is installed on several CDAs in the plant. A 4-hour notification is then required because there was no actual ADVERSE IMPACT to the SSEP function, but there could have been assuming the virus had been activated and resulted in an ADVERSE IMPACT on an SSEP function.

NEI 15-09 (Revision 1)

October 2022

4-hour notification - CYBERATTACK that could have COMPROMISED support systems and equipment, which if COMPROMISED, could have ADVERSELY IMPACTED an SSEP function:

C.4.11 A 4-hour notification is required upon discovery of an unlocked cabinet containing CDAs or CS equipment that is required to be locked and tampering of the locking device(s) is determined to have occurred. The assumption is that the individual who opened the cabinet with malicious intent attempted to COMPROMISE CDAs within the cabinet and adversely impact an SSEP function.

4-hour notification - suspected or actual CYBERATTACK initiated by personnel with physical or electronic access to digital computer and communication systems and networks (and not reportable as a 1-hour event):

C.4.12 Control of a mobile or portable media device (PMD) is lost or misplaced and there are signs of malicious exploitation. For example, a PMD used for maintenance and testing is misplaced or lost, if the PMD is recovered and shows signs of malicious TAMPERING (e.g., physical tampering, MALWARE installed, etc.) or PMDs that are maintained and tested by the lost or misplaced PMD show signs of malicious exploitation (MALWARE, unauthorized access/activity, etc.).

C.4.13 An I&C worker changes a few of the parameters on a digital temperature indicating controller. Alarms go off in the main control room and an Aux Operator is dispatched to investigate. There is no ADVERSE IMPACT to the SSEP function of the device. The impact would only be to local temperatures.

Device cannot be changed without human interaction at the HMI. This was not an equipment malfunction. It is suspected that human interaction was involved.

Interview with the I&C worker revealed the worker was attempting to trip the affected system; therefore, a 4-hour notification is required. The event could escalate to a 1-hour notification if the condition was not corrected before an ADVERSE IMPACT to the SSEP function occurred.

C.4.14 A single hand geometry unit at the protected area entrance is in alarm status (i.e., the security function is degraded but still available). Troubleshooting discovered that a parameter on the security computer was not valid. Site is unsure how the parameter got changed, but it is known that only someone with elevated privileges can make this change. Since the security system is air-gapped, the only places the change could have taken place would have been in the CAS or SAS.

An interview with the involved individuals is necessary to determine if there was malicious intent involved in the configuration change. A CYBERATTACK is suspected, but not confirmed, and the CYBERATTACK would have to have been initiated by someone with physical or logical access within the PA. A 4-hour notification is required if the interview determines that there is reason to believe there was malicious intent to cause ADVERSE IMPACT on a CDA.

NEI 15-09 (Revision 1)

October 2022

4-hour notification - notification to a local, state, or other federal agency (e.g., law enforcement, FBI, etc.). of an event related to the licensees implementation of their Cybersecurity program for digital computer and communication systems and networks (and not otherwise reportable as a 1- or 4-hour notification):

C.4.15 CSIRT identifies the need to interview a previously employed worker as part of an event investigation involving the discovery of a malicious virus on a CDA in the plant. The individual makes threats during a phone conversation. The Shift Manager and Security Manager are contacted who contact the local police to investigate the threat.

8-hour notification - information obtained regarding observed behavior, activities, or statements that may indicate intelligence gathering or pre-operational planning related to a cybersecurity attack against digital computer and communication systems and networks:

C.8.1 Personnel or persons with an uncommon level of interest or making abnormal inquiries related to specific attributes of the licensees cybersecurity program (e.g., CDAs, CSs, cybersecurity controls) or vulnerabilities associated with the cybersecurity program. Such interests or inquiries could occur onsite or offsite (e.g., cybersecurity symposium) by personnel, vendors, or contractors, or non-employees that do not have a need-to-know (e.g., are not part of, or support, the licensees cybersecurity program). This does not include generic public or media inquiries related to plant operations, safety, etc. (i.e., these inquiries are targeted).

C.8.2 Unauthorized personnel in a static position in vicinity of the plant (protected area) that are in possession and operating equipment (e.g., laptop, Yagi antenna) capable of scanning for wireless networks. This does not include devices such as personal electronic devices (e.g., smartphones) carried by visitors that are configured to search or join wireless networks (i.e., these activities are targeted).

C.8.3 The recognition of the theft or suspicious loss of smart cards, tokens, or other two factor authentication devices required for accessing a CDA or CS.

C.8.4 The detection of forged or fabricated smart cards, tokens or other two factor authentication devices required for accessing a CDA/CS or performing authorization activities.

C.8.5 The detection of falsified identification badges, key cards, or other access-control devices that allow unauthorized individuals access to a CDA or CS.

C.8.6 A targeted spear phishing email (payload) followed-up with a telephone call to the targeted individual attempting to trigger the spear phishing email (SOCIAL ENGINEERING) with intent to adversely impact an SSEP function. Investigation reveals the attempt is CREDIBLE and involves or has the potential to involve digital computer, computer communication system or network under the scope of the Cybersecurity rule.

NEI 15-09 (Revision 1)

October 2022 C.8.7 A website posting or notification indicating a planned CYBERATTACK against the plant.

C.8.8 A security officer overhears two maintenance workers talking in the cafeteria.

They are complaining about having too much work to do and being under appreciated by the company. One says he is tasked with maintenance on the digital main feedwater controls tomorrow and suggests TAMPERING with the controls to teach the utility a lesson. The other agrees and says hell be glad to help. Therefore, an 8-hour notification is required for pre-operational planning related to a cybersecurity threat.

C.8.9 Malicious activity is observed on a digital asset residing on the same network as a CDA. The malicious activity provides credible evidence, indicating intelligence gathering or pre-operational planning activity that could affect those CDAs.

C.8.10 Malicious activity is observed on a device from which a CDA inherits security controls, such as a portable media scanning kiosk. This observed behavior, provides credible evidence, indicating intelligence gathering or pre-operational planning activity related to a cyberattack against digital computer and communication systems.

24-hour CAP entry - identification of vulnerability, weakness, failures and deficiencies in cybersecurity program:

C.24.1 CS program implementation deficiencies identified by worker, supervisor, Licensee Self-Assessment, Nuclear Oversight, INPO, NRC.

C.24.2 Missing USB port blocker - Escalates to 1 hour1.157407e-5 days 2.777778e-4 hours 1.653439e-6 weeks 3.805e-7 months or 4-hour notification (dependent on ADVERSE IMPACT) if there is evidence that the CDA and SSEP function were COMPROMISED through the open port or could have been COMPROMISED had an ADVERSARY exploited the vulnerability.

C.24.3 Portable Media Inventory identifies unaccounted for PMD due to an administrative error with PMD found.

C.24.4 Portable Media Inventory identifies unaccounted for PMD due to PMD not immediately found. (potential path to a 4 hour4.62963e-5 days 0.00111 hours 6.613757e-6 weeks 1.522e-6 months event) Escalation to 4 hour4.62963e-5 days 0.00111 hours 6.613757e-6 weeks 1.522e-6 months notification if, once found, you determine it was COMPROMISED and used on CDA and could have adversely affected a SSEP function.

C.24.5 Portable Media used but not scanned at KIOSK before or after use. Escalates to 1 hour1.157407e-5 days 2.777778e-4 hours 1.653439e-6 weeks 3.805e-7 months or 4 hour4.62963e-5 days 0.00111 hours 6.613757e-6 weeks 1.522e-6 months notification (dependent on ADVERSE IMPACT) if MALWARE on the PMD reached a CDA and either did or could have caused ADVERSE IMPACT of an SSEP function.

C.24.6 A CDA cabinet is accidentally left unlocked after approved work, and there is no sign of TAMPERING or COMPROMISE.

NEI 15-09 (Revision 1)

October 2022 C.24.7 A cyber vulnerability assessment that was not performed within the period specified in the licensees Cybersecurity plan (e.g., quarterly).

C.24.8 Improper usage of digital computer and communication systems and networks associated with SSEP functions; or support systems and equipment, which if COMPROMISED, could ADVERSELY IMPACT SSEP functions. This could include non-administratively-related training and procedure deficiencies involving a CDA, cybersecurity controls or SSEP functions without an ADVERSE IMPACT to their function (e.g., connection of unauthorized portable media to a CDA which resulted in no exploitation (e.g., no MALWARE transferred, no unauthorized activity/access occurred).

C.24.9 A design flaw or vulnerability in an implemented cybersecurity control that could have allowed unauthorized access to a CDA, or substantively eliminated or significantly reduced the licensees response capabilities. This is not intended to capture vendor discovered issues that are immediately fixed/PATCHED/corrected. However, flaws or vulnerabilities discovered by a licensee should be recorded (e.g., a licensee scan discovers a vulnerability in cybersecurity hardware or software that has not been previously identified). Note:

If a licensee believes the vulnerability or design flaw could pose an industry-wide risk the licensee should consider immediate notification using the voluntary notification process so the NRC can notify other licensees of the vulnerability or design flaw.

C.24.10 A cybersecurity event that could have allowed undetected or unauthorized access or modification to a CDA, but was not exploited in an attack. For example, a cybersecurity control or alarm was temporarily disabled or accessed for maintenance and not enabled or secured immediately upon completion of the activity

Events not reportable:

C.NR.1 Phishing email on a business network (e.g., email with a request to click on a link)

C.NR.2 The initial scan of a PMD at a scanning station identifies a virus before the PMD is authorized for use on a CDA.

C.NR.3 Security Information and Event Management (SIEM) or intrusion detection system identifies an occurrence that is determined to be a false positive.

C.NR.4 The hand geometry readers deny access to authorized plant workers. All the hand geometry units at the protected area entrance, except the service door were in alarm status. Troubleshooting discovered that a parameter on the security computer was not valid. Site is unsure how the parameter got changed, but it is known that only someone with elevated privileges can make this change. Since the security system is air-gapped, the only places the change could have taken place would have been in the CAS or SAS. An interview with the involved

NEI 15-09 (Revision 1)

October 2022 individuals is necessary to determine if there was malicious intent involved in the configuration change. A CYBERATTACK is suspected, but not confirmed, and the CYBERATTACK would have to have been initiated by someone with physical or logical access within the PA. No notification is required if the interview results in an admittance of human error or accidental keystrokes that led to the issue because a CYBERATTACK has been ruled out.

C.NR.5 Someone hacked into the offsite fiber optics system that operates non-CDA equipment. If the hack occurred on a device outside the licensees ownership (i.e., outside the NRC/NERC bright-line for the station), then the devices are not CDAs and no reporting requirement would apply. These SSCs are outside the licensee's control and include electrical distribution equipment past the first inter-tie with the licensees equipment and the offsite distribution system. A NERC and/or a DOE report may be required, but is outside the scope of this guidance.

NEI 15-09 (Revision 1)

October 2022 APPENDIX D - GLOSSARY This glossary is intended to aid the reader in implementing this guide to meet the requirements set forth in 10 CFR 73.77. Definitions for certain security terms are also found in 10 CFR 73.2, Definitions. The glossary defines only those terms that are specific to their usage in CSEN.

Other terms should be referenced in the following order of preference.

Defined terms appear in all capital letters (i.e., ALL CAPS) and, along with their definitions, are listed below.

1. Specific terms defined in Rules. (10 CFR 73.2, Definitions)

2. Licensee Cybersecurity plan

3. NEI 08-09

4. NIST IR 7298 Glossary of Key Information Security Terms.

5. National Information Assurance (IA) Glossary CNSSI No. 4009

6. NRC RG 5.76, Physical Protection Programs at Nuclear Power Reactors

7. NRC RG 5.83 July 2015

8. NRC RG 5.71 Rev. 0, January 2010

NEI 15-09 (Revision 1)

October 2022 ACCESS CONTROL The control of entry or use, to all or part, of any physical, functional, or logical component of a CDA.

ADVERSE IMPACT A direct deleterious effect on a CDA (e.g., loss or impairment of function, reduction in reliability, reduction in the ability to detect, delay, assess or respond to malevolent activities, reduction of ability to call for or communicate with offsite assistance, and the reduction in emergency response ability to implement appropriate protective measures in the event of a radiological emergency). In the case where the direct or indirect COMPROMISE of a support system causes a safety-related, important-to-safety, security or emergency preparedness 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 in the context of 10 CFR 73.54(a).

ADVERSARY Individual, group or organization that has ADVERSELY IMPACTED or is attempting to adversely impact a CDA. [NEI 08-09]

ATTEMPTS TO Efforts to accomplish a threat, even though it has not occurred or has CAUSE not been completed because it was interrupted, stopped before completion, or may occur in more than two hours, as established through reliable and substantive information. [RG 5.76 Physical Protection Programs at Nuclear Power Reactors [U))

COMPROMISE Loss of confidentiality, INTEGRITY, or availability of data or system function.

CREDIBLE Information received from a source determined to be reliable (e.g., law enforcement, government agency, etc.) or has been verified to be true. A threat can be verified to be true or considered CREDIBLE when: Physical evidence supporting the threat exists, Information independent from the actual threat message exists that supports the threat, or a specific known group or organization claims responsibility for the threat.

[RG 5.76 Physical Protection Programs at Nuclear Power Reactors

[U))

NEI 15-09 (Revision 1)

October 2022 CRITICAL A digital computer, communication system, or network that has been DIGITAL ASSET identified through site-specific analysis required 10 CFR 73.54(b)(1)

(CDA) as requiring protection against a CYBERATTACK. A CDA may be:

a component of a CRITICAL SYSTEM (this includes assets that perform SSEP functions; provide support to, protect, or provide a pathway to Critical Systems); or

a support system asset whose failure or COMPROMISE as the result of a CYBERATTACK would result in an ADVERSE IMPACT to an SSEP Function.

CRITICAL A system that is associated with or provides safety-related functions; SYSTEM (CS) important-to-safety functions; security functions; emergency preparedness functions, including offsite communications; or support systems and equipment which, if COMPROMISED, would adversely impact safety, security, or emergency preparedness functions.

CYBERATTACK Any event in which there is reason to believe that an ADVERSARY has committed or caused, or attempted to commit or cause, or has made a CREDIBLE threat to commit or cause malicious exploitation of a CDA. [Reference 10 and 11]

CYBER INCIDENT A digitally related adverse condition.

INTEGRITY Quality of a system reflecting the logical correctness and reliability of the operation of the system; the logical completeness of the hardware and software implementing the protection mechanisms; and the consistency of the data structures and occurrence of the stored data.

Additionally, INTEGRITY includes protection against unauthorized modification or destruction of information.

INTERRUPTION OF A departure from normal operations or conditions that, if NORMAL accomplished, would result in a challenge to the facilitys safety, OPERATION security, or emergency response systems. This may also include an event that causes a significant redistribution of security, safety, or emergency response resources. This could include intentional TAMPERING with systems or equipment that is normally in a standby mode, but would need to operate if called upon in an abnormal or emergency situation. Section 236 of the AEA (42 U.S.C.

Section 2284) treats as sabotage the knowing INTERRUPTION OF NORMAL OPERATION of any such facility through the unauthorized use of, or TAMPERING with, the machinery, components, or controls of any such facility, or attempting or conspiring to carry out such an act.

NEI 15-09 (Revision 1)

October 2022 MALWARE Malicious software designed to infiltrate or damage a CDA, CS or protected network without licensee consent. MALWARE includes computer viruses, worms, Trojan horses, Root kits, spyware, adware and other potentially unwanted programs.

MOBILE CODE Programs or parts of programs obtained from remote control systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient.

PATCH A fix for a CDA or software program where the actual binary executable and related files are modified.

RECOVERY Steps taken to restore a system, function, or device to its original state of operation following a catastrophic or partial loss of functionality or when an original state of operation is challenged by either an event (such as a CYBERATTACK) or anomaly (behavior not expected from normal operation).

SOCIAL Attempts by unauthorized individuals to gain physical or electronic ENGINEERING (e.g., password) access to systems via impersonation of authorized TECHNIQUES functions or personnel.

TAMPERING Altering, disabling, or damaging digital computer and (CYBER) communications systems and networks or cybersecurity controls for improper purposes or in an improper manner.

NEI 15-09 (Revision 1)

October 2022 REFERENCES 1 0F

1. U.S Code of Federal Regulations (CFR), Physical Protection of Plants and Materials, Part 73, Chapter 1, Title 10, Energy.

2. CFR, Domestic Licensing of Production and Utilization Facilities, Part 50, Chapter 1, Title 10, Energy.

3. NRC, Regulatory Guide (RG) 5.69, Guidance for the Application of Radiological Sabotage Design-Basis Threat in the Design, Development and Implementation of a Physical Security Program that Meets 10 CFR 73.55 Requirements, Washington, DC.

4. U.S. Homeland Securitys website at www.dhs.gov,.

5. NRC, SRM-10-0001, "Regulation of Cybersecurity at Nuclear Power Plants,"

Washington, DC, October 21, 2010. (ADAMS No. ML102940009).

6. Executive Order 13526, Classified National Security Information, dated December 29, 2009, published December 29, 2009. (75 FR 707).

7. CFR, Facility Security Clearance and Safeguarding of National Security Information and Restricted Data, Part 95, Chapter 1, Title 10, Energy.

8. U.S. Nuclear Regulatory Commission, "Backfitting Guidelines," NUREG-1409, Washington, DC, June 1990. (ADAMS No. ML032230247).

9. NRC Management Directive 8.4, "Management of Facility Specific Backfitting and Information Collection," U.S. Nuclear Regulatory Commission, Washington, DC.

10. NEI 08-09, Rev 6, "Cybersecurity plan for Nuclear Reactors."

11. NRC letter to NEI, Nuclear Energy Institute 08-09, Cybersecurity plan Template, Rev.

6, dated June 6, 2010 (ML101550052) providing endorsement of definition of Cyberattack.

12. NUREG-1022, Event Report Guidelines 10 CFR 50.72(b)(3)(xiii), Revision 3, Supplement 1.

1 Publicly available NRC published documents are available electronically through the NRC Library on the NRCs public Web site at http://www.nrc.gov/reading-rm/doc-collections/ and through the NRCs Agencywide Documents Access and Management System (ADAMS) at http://www.nrc.gov/reading-rm/adams.html The documents can also be viewed online or printed for a fee in the NRCs Public Document Room (PDR) at 11555 Rockville Pike, Rockville, MD. For problems with ADAMS, contact the PDR staff at 301-415-4737 or (800) 397-4209; fax (301) 415-3548; or e- mail pdr.resource@nrc.gov.

ML22298A228

Text

SUMMARY

SUMMARY

Navigation menu

Search