ML22258A200

DG 5061 Revision 1 - NRC Staff Responses to Public Comments

ML22258A200
Person / Time
Issue date:	02/03/2023
From:	Stanley Gardocki NRC/RES/DE/RGDB
To:
Gardocki, S
Shared Package
ML14288A596	List: ML22258A200 ML22258A204 ML22258A271
References
RG-5.071, Rev 1, NRC-2021-0143 DG-5061, Rev 1
Download: ML22258A200 (26)

Text

Response to Public Comments on Draft Regulatory Guide (DG)-5061 Cyber Security Programs for Nuclear Power Reactors Proposed Revision 1 of Regulatory Guide (RG) 5.71 On March 3, 2022, the NRC published a notice in the Federal Register (87 FR 12208) that Revision 1 to Draft Regulatory Guide, DG-5071, Proposed Revision 1 of RG 5.71, was available for public comment, reference Docket ID NRC-2021-0143, The public comment period ended on April 3, 2022. The NRC received comments from the organizations listed below. The NRC has combined the comments and NRC staff responses in the following table:

Comments were received from the following individuals/companies and can be found in Agency Document Access Management Systems (ADAMS):

Comments Ameren-# A. Lowery Ameren - Callaway Energy Center Email: alowry@ameren.com ADAMS Accession No. ML22124A082 Comments Kinectrics-# Gary Locklear Kinectrics Cyber Security Programs for Nuclear Power Reactors Fuquay Varina, NC 27526 gary.locklear@kinectrics.com Phone: 919 306 4946 ADAMS Accession No. ML22124A078 Comments NEI-# Richard Mogavero Senior Project Manager, Nuclear Security & Incident Preparedness Nuclear Energy Institute (NEI) www.nei.org 1201 F Street, NW, Suite 1100 Washington, DC 20004 P: 202.739.8174 rm@nei.org ADAMS Accession No. ML22124A079 (duplicate of ML22124A081)

Comments NuScale-# Director, Regulatory Affairs NuScale Power, LLC, www.nuscalepower.com 1100 NE Circle Blvd., Suite 200 Corvallis, Oregon 97330 Office 541.360-0500 ADAMS Accession No. ML22125A007 Page 1

Commenter Section Specific Comment and Proposed Resolution NRC Resolution Ameren-1 General It is confusing that section C of the Reg Guide body and NRC staff agrees in part and disagrees in part with this Appendix C both have sections numbers that start with C. comment. We agree that clarification is needed when Then, in the template in Appendix A, the C is dropped referring to sections in Section C Staff Regulatory Guidance when referring to guidance from section C of the Reg and sections in Appendix C. Any text within RG 5.71 Guide body. Suggest eliminating the C from the section referring to text in Section C Staff Regulatory Guidance is numbers in the Reg Guide body. written as RG 5.71, Staff Regulatory Guidance, Section

<section number> where section number is the applicable The first part of the Appendix A template basically section number). As an example, RG 5.71, Staff Regulatory requires doing everything in section 3.3 of the main Reg Guidance, Section C.4.1 is used to refer to text in section Guide section C. Following template sections sometimes C.4.1 of the Staff Regulatory Guidance. When referring to repeat the language from the Reg Guide body and text in Appendices A, B, or C the text is written as sometimes refer back to other sections of the body. This Appendix <name>.<section number> where name is A, B, makes it difficult to read through the resulting Cyber or C and section number is the applicable section number.

Security Plan and determine what is being done. It would For example, a reference to Section 3.2 of Appendix C is be necessary to always keep a copy of the Reg Guide in written as Appendix C.3.2. The RG was reviewed to verify hand in order to determine what is required by the Cyber consistency of the text and updated accordingly.

Security Plan if the template is used. Suggest incorporating the Reg Guide language into the Appendix The NRC staff does not agree with the suggestion to A template so that a stand-alone Cyber Security Plan incorporate the Reg Guide text in Appendix A. Not all of the document is created from the template. text in Section C Staff Regulatory Guidance is necessary or useful in the Appendix A which is used by licensees as a template for cybersecurity plans. No change was made in the RG based on this part of the comment.

Ameren-2 Glossary Critical digital Asset (CDA) - This definition is The NRC staff agrees with the comment. The text for the incomplete and would result in any digital device in a definition of CDA has been changed in the RG to use the critical system being considered a CDA. When systems are definition in NEI 08-09, revision 6. This definition is as evaluated, all system functions are examined and if ANY follows -

of these are SSEP functions, then the system is classified as a critical system. There could be stand-alone digital critical digital asset (CDA) A digital computer, devices in this system, however, that only perform non- communication system, or network that is:

SSEP functions. These devices would not be classified as - a component of a critical system (this includes assets that CDAs, even though they are digital components in a perform SSEP functions; provide support to, protect, or provide critical system. a pathway to Critical Systems); or

- a support system asset whose failure or compromise as the The definition needs to include bounding criteria regarding result of a cyberattack would result in an adverse impact to a the digital device performing / supporting / protecting a SSEP Function.

SSEP function.

Page 2

Commenter Section Specific Comment and Proposed Resolution NRC Resolution Ameren-3 Glossary Attack vector and attack pathway - These definitions do NRC staff agrees in part and disagrees in part with this not align with the industry use of these terms. While the comment. The NRC staff agrees, as the commenter noted, NEI term threat / attack vector is used extensively throughout 10-09 was not approved for use by the NRC. NRC staff also several NRC approved NEI documents, the only place agrees with the comment that the text on page 21 was this term has been defined is in NEI 10-09. While this contradictory. It incorrectly stated that attack vector is a document was not approved by the NRC and is generally delivery mechanism or vulnerability/exploit has been corrected not used by the industry, the industry has adopted its to state that an attack vector is a delivery mechanism and terminology for pathways and attack vectors as these vulnerability/exploit.

were not defined elsewhere.

The NRC staff disagrees with the comment that evaluating the This document states: pathway is sufficient in addressing security controls in For the purposes of implementing cyber security plans, accordance with NEI 08-09 section 3.1.6. During the approval pathways that introduce vulnerabilities are associated of Addendum 1 of NEI 08-09 and during NRC inspections, the with the following attack vectors: NRC staff and inspectors have repeatedly clarified that attack

1) Direct Network Connectivity vector and attack pathway are not synonymous and this

2) Wireless Network Capability clarification has been documented in the revised RG released

3) Portable Media and Equipment for public comment in RG 5.71, Staff Regulatory Guidance,

4) Supply Chain Section C.3.3. and Appendix A.3.1.6, and in the attack vector

5) Direct Physical Access and attack vector definitions in the glossary. The original version of RG 5.71 used the word pathway in the context of Licensees have developed their justifications for communication pathway. The original RG 5.71 also used the addressing security controls using this definition. Per NEI terms pathway and attack vector in distinct, different 08-09 section 3.1.6 (and Reg Guide A.3.1.6), not contexts. The original text of RG 5.71, Staff Regulatory implementing a security control may be justified by Guidance, Section C.3.3 and Appendix A.3.1.6 used the term demonstrating the attack vector does not exist. The attack vector to help determine the selection and application of industry understanding is that these justifications are security controls. Pathways can be circumvented so based on evaluating the pathway rather than the method considering only a pathway for mitigating cyberattack can and while the results may typically be the same, this result in insufficient analysis. Therefore, attack vectors analysis could be considered a change in philosophy. The best should be used for applying security controls, not simply solution could be to move away from the attack vector pathway analysis. Licensees must demonstrate that the term and simply focus on evaluating the threat the associated attack vectors (delivery mechanism and security control protects against and determining whether vulnerability/exploit) do not exist.

that threat exists for the specific CDA. This could then be addressed by eliminating either the method or the Accordingly, understanding the intent of a control is important pathway. In any case, this is an item that needs to be when evaluating if an alternative approach to addressing the addressed. If the NRC position is that the industry needs attack vector will effectively mitigate the threat.

to be specifically evaluating the attack mechanism and Understanding the intent of the control will enable effective not the pathway, then this is a change in philosophy that evaluation of the alternate approach to mitigating the threat Page 3

Commenter Section Specific Comment and Proposed Resolution NRC Resolution needs to be communicated. If the intent is just to evaluate posed by the attack vector.

the threat and it is acceptable to justify that the threat does not exist by elimination of either the pathway or method, then section A.3.1.6 (and the NEI documents) should be revised accordingly. To add further confusion, the second paragraph on page 21 indicates that an attack vector is a delivery mechanism or vulnerability/exploit.

The attack vector definition, on the other hand, only says it is the mechanism and can be used to exploit a vulnerability.

Ameren-4 Page 22 Under the information to collect when following the CDA The NRC staff agrees with this comment. The text in the RG identification process, clarification is needed to explain 5.71, Revision 1, Staff Regulatory Guidance Section C.3.1.3 what is meant by "developmental and evaluation-related was changed (new text is underlined) as follows:

assurance requirements".

• developmental and evaluation-related assurance requirements to be used by licensees for verifying the design, implementation, and testing of security functionality in products received in acquired devices.

Ameren-5 Page 28, A- The language for implementing alternative controls The NRC staff agrees in part and disagrees in part with this 6 when a security control cannot be implemented does not comment.

align with A.3.1.6, which uses more recently agreed upon language also reflected in NEI 08-09 Addendum 1. The NRC staff agrees that the text in RG 5.71, Revision 1, Appendix A.3.1.6 is not identical to text in NEI 08-09, A new bullet was added which states " Apply the security Addendum 1. However, although the language is not identical, controls described in Appendices B and C to this guide, the NRC staff does not believe that the new language in based on the maximum consequences of a successful cyber Appendix A.3.1.6 contradicts the language in NEI 08-09, attack on the CDAs in terms of plant safety and security". Addendum 1.

This terminology is vague and does not seem to align with the methodology used for protecting safety and security The NRC staff agrees that the language quoted by the functions. commenter is new language in RG 5.71, Staff Regulatory Guidance Section C.3.3. Consistent with language in Staff Regulatory Guidance Section C.3.2, a licensee may implement a graded approach for the application of security controls taking into account the consequences resulting from a successful cyber-attack. The NRC staff has added language stating that the application of security controls should be based on the maximum consequences of a successful cyber-attack to address a lesson learned from cybersecurity inspection Page 4

Commenter Section Specific Comment and Proposed Resolution NRC Resolution violations where a cross cutting aspect of conservative bias was used in applying security controls. In some cases, this conservative approach has resulted in a licensee applying security controls that did not address the potential maximum consequences resulting from a successful cyber attack.

The NRC staff does not agree that this new language is vague.

The concept of a graded, consequence-based approach to the application of cybersecurity controls is discussed throughout this RG. The use of the maximum consequence language is to remind licensees that their application of cybersecurity controls should address the most risk-significant consequences resulting from a successful cybersecurity attack. This approach is consistent with the language in Staff Regulatory Guidance Section C.3.2.1. Section C.3.2.1 states:

Functions are protected commensurate with their safety and security significance through the determination and use of appropriate security levels. The security level defines the degree of security needed to protect the function, based on the consequences to plant safety and security from loss or impairment of the function due to cyberattacks. This is an example of a consequence-based, graded approach for risk-informed security. The NRC staff has determined that the language quoted by the commenter should also be added to Appendix A.3.1.6.

Ameren-6 Page 37, A- The final bullet under integrating the cyber security The NRC staff agrees with the comment. The bullet item has 8 program into the physical security program discusses been deleted from RG 5.71, Revision 1, in Staff Regulatory periodically exercising the entire security force using Guidance Section C.4.1 and in Appendix A.3.2.

multiple realistic scenarios combining both physical and cyber simulated attacks. This requirement would better fit in a physical security Reg Guide as the cyber security organization does not have control over exercising the entire security force. Additionally, in physical security drills, it makes more sense to simulate a cyber attack simply as a failed or compromised piece of equipment that should be assumed to be lost. Cyber security incident response drills and physical attack drills typically follow Page 5

Commenter Section Specific Comment and Proposed Resolution NRC Resolution different timelines and use different response teams, making integration into a single drill impractical.

Response to a cyber attack would be integrated with physical security as they are a member of the CSIRT.

However, in a physical attack, security would simply be dealing with lost equipment and their response would likely not be impacted by the relatively longer timeline of the CSIRT determining the cause of a cyber attack and recovering a system. The NRC is currently soliciting input regarding integration of cyber security into Force On Force drills, and this is a more appropriate way to drive this particular item.

Ameren-7 Page 40 In the first paragraph, clarification is needed regarding The NRC staff agrees with this comment. The following the meaning of " This effectiveness analysis should underlined text was added to RG 5.71, Revision 1, Staff provide key information about the results of previous Regulatory Guidance Section C.4.1.2 for clarification -

policy and acquisition decisions".

This effectiveness analysis should provide key information about the results of previous policy and acquisition decisions.

This should include, but is not limited to, information on corrective actions implemented pertaining to the cybersecurity program and the enrollment of newly installed plant equipment in the cybersecurity program.

Ameren-8 Page A-2 Under A.3, the reference to 10 CFR 73 Appendix G The NRC staff agrees that both entries are unnecessary, and the seems unnecessary as the cyber event reporting was following change (strikethrough for deleted text) has been placed in 10 CFR 73.71. Any cyber event causing one of made to the text in RG 5.71, Revision 1, Appendix A.3 -

the criteria in Appendix G to be met would also be included as a reportable event in 10 CFR 73.71. [Licensee/Applicant] will also report any cyberattacks or incidents at [Site] to the NRC, as required by 10 CFR 73.71, Reporting of Safeguards Events. and Appendix G, Reportable Safeguards Events, to 10 CFR Part 73, Physical Protection of Plants and Materials.

Ameren-9 Page A-9 Section A.4.1.1 could be interpreted to require the The NRC agrees in part and disagrees in part with this verification of every security control on every CDA every comment. We agree yearly verification of every control on year. This would be a time consuming and resource every CDA is not necessary. We have communicated with intensive effort that would provide little benefit. licensees that they could use operational and management Discussions with the NRC determined this was not the controls in Appendix C of RG 5.71 with ongoing monitoring of intent and this was meant more as a review of the CDAs employing a consequence-based, graded approach. An effectiveness of the program based controls and to ensure example of ongoing monitoring would be whitelisting Page 6

Commenter Section Specific Comment and Proposed Resolution NRC Resolution ongoing monitoring of CDAs was occurring. This section applications on a CDA that would notify a SIEM when a should be re-worded to clarify the intent, or possibly be change is made on the CDA. Another example is verifying the treated as an introduction section for the following configuration of a CDA in a vital area whenever the CDA is sections or integrated into section A.4.1.2. accessed by maintenance staff. We will add the following clarifying text (new text is underlined) to RG 5.71, Revision 1, Appendix A.4.1.1

[Licensee/Applicant] performs periodic assessments to verify that the security controls implemented for each CDA remain robust, resilient, and effective throughout the life cycle. The CST verifies the status of these security controls [on at least an annual basis] or in accordance with the specific requirements for each security control, as described in Appendices B and C, whichever is more frequent. An example of an acceptable alternate for verification of a security control at a specific periodicity would be whitelisting applications on a CDA that would notify a SIEM when a change is made on the CDA.

Another example of an acceptable alternate is verifying the configuration of a CDA in a vital area whenever the CDA is accessed by maintenance staff.

The staff disagrees with the suggestion to integrate Appendix A.4.1.1 into Appendix A.4.1.2. The purpose of licensee activities in Appendix A.4.1.1 is to periodically verify that the implemented security controls remain in place and function correctly to ensure security against a cyber-attack. The purpose of licensee activities in Appendix A.4.1.2 is to verify that the implemented security controls remain effective in addressing evolving threats and newly identified vulnerabilities.

Ameren-10 Page A-10 In the second paragraph of A.4.2, clarification is needed The NRC staff agrees with this comment. The intent of the to explain the intent of "address safety, reliability, and control is for the licensee to determine what configuration security engineering activities". control activities are applicable for devices when a plant is decommissioned. However, the NRC staff agrees that the text quoted by the commenter is unclear. Accordingly, the NRC staff have revised the text in the second paragraph of RG 5.71, Revision 1, Appendix A.4.2 to state:

During the retirement phase while fuel is onsite, the [design control and configuration management procedures, or other Page 7

Commenter Section Specific Comment and Proposed Resolution NRC Resolution procedural processes] continue to apply to remaining CDAs that affect safety-related and important-to-safety, security, or emergency preparedness functions.

The NRC staff has determined that this revised text provides greater clarity.

Ameren-11 Appendices The addition of the "Control Intent" sections provide The NRC staff agrees with the comment. No changes were B and C useful information regarding the threat the control is made to the RG based on this comment.

intended to protect against which then aids in the development of appropriate alternate controls.

Kinectrics-1 General The use of the terms safety and safety-related does not The NRC staff agrees in part and disagree in part with this reflect a consistent scope. For example, on page 7, second comment. The NRC staff agrees that when referring to SSEP paragraph, 2nd last sentence, the sentence contains functions as defined in 10 CFR 73.54, the first S in SSEP

.maintenance equipment for safety and safety-related represents safety-related and important-to-safety. The text in systems. Since it is referring to 73.54, it can only mean the RG has been updated to consistently use the words safety-related and important-to safety. But in the last safety-related, important-to-safety throughout the RG for paragraph on page 7, 1st sentence, it reads .loss of the first S in SSEP. This includes updating RG text to degradation of safety, security, and emergency replace safety with safety-related and important-to-safety preparedness (SSEP) functions.. In this sentence it must where appropriate in regard to SSEP.

mean safety-related and important-to-safety.

The NRC staff disagrees with the comment regarding the The document needs to reflect a consistent use of terms to definition of adverse impact. The NRC cybersecurity rule avoid user confusion. The industry has expended requires licensees to provide high assurance that digital significant cost implementing 73.54 cyber security computer and communication systems and networks are requirements due to inconsistent use of terms and using adequately protected against a cyber-attack up to and terms without providing a clear understanding of their including the design basis threat for radiological sabotage in meaning and scope. 73.1. Protecting against this DBT would require a licensee to prevent significant core damage and spent fuel sabotage.

The term adverse impact has a similar inconsistent use. Therefore, it is correct to say in Staff Regulatory Guidance The term as used in 3.1.3 1st paragraph, clearly indicates Section C.3.1.3 that one possible consequence of adequately that adverse impact is related to radiological sabotage, i.e., protecting CDAs includes radiological sabotage resulting in significant core damage and therefore has the potential to significant core damage. The NRC staff notes that the adverse impact public health and safety. However, in the definition of adverse impact in the Glossary does reference Definition section, adverse impact makes no mention of radiological sabotage. No change was made to the RG based radiological sabotage or core damage or impact public on this part of the comment.

health and safety. The document text should be corrected to assure that use of the term adverse impact is clearly The NRC staff as a policy does not reference whitepapers in and consistently connected with protecting the health and RGs. The NRC staff may reference NEI guidance documents.

safety of the public. In this RG we have referenced NEI 10-04, Revision 3, Page 8

Commenter Section Specific Comment and Proposed Resolution NRC Resolution Identifying Systems and Assets Subject to the Cyber Important-to-Safety - While the term is used throughout Security Rule.

the RG no guidance is provided that reflects the Important-to-Safety NRC accepted NEI Whitepaper guidance.

Recommend including in this RG CDA scoping discussion.

Kinectrics-2 Section The 2nd sentence of this section should provide the overall It is unclear what the commenter means when stating that this C.3.1 guidance, scope, and concern of this RG. As the document section should provide the overall guidance, scope, and is written, a safety-related DA would be required to be a concern of this RG. The scope of this RG is set forth in RG CDA even though a compromise would NOT adverse 5.71, Section A, Purpose, and the first paragraph of Staff impact the SSEP function. This position is included in the Regulatory Guidance Section C of this RG.

adverse impact definition for support items, but is not allowed for non-support DA. This creates an unnecessary As stated in Staff Regulatory Guidance Section C.3.1, a CDA inconsistency. is, in part, any digital asset that if compromised would adversely impact a safety-related or important-to-safety function. If a digital asset cannot compromise a safety-related or important-to-safety function, it is by definition not a CDA.

Conversely, as the NRC staff understands the term, a safety-related digital asset is by definition a digital asset that if compromised would adversely impact a safety-related or important-to-safety function and therefore must be classified as a CDA. The NRC staff disagrees with the commenters definition of adverse impact. See response to Kinectrics-1 regarding adverse impact. No change was made to the RG based on this comment.

Kinectrics-3 Section The following leads into the identification of critical The NRC staff disagrees with this comment. The purpose of C.3.1.3 systems, i.e. However, it may be difficult for a licensee the sentence quoted by the commenter is merely to to identify CDAs without first conducting a wider acknowledge that licensees may have hundreds of systems and assessment of all the systems within the facility. possibly thousands of digital assets that affect the operation of their plant. Consistent with the language in 10 CFR 73.54 This assumption is unwarranted given that existing (b)(1), a licensee must analyze digital computer and plants have historically identified their safety related communication systems and network to identify those CDAs systems and equipment items. Also, because the NRR has that must be protected against a cyber-attack. One of the an important-to-safety QA inspection program that reasons for this wider assessment is to reduce the potential identifies important-to-safety systems and equipment burden on the licensee by having them identify and only items. New plant designs also identify regulatory related protect CDAs.

equipment items as part of their classification and categorization process. The NRC disagrees that identifying and analyzing critical Page 9

Commenter Section Specific Comment and Proposed Resolution NRC Resolution systems places an unnecessary burden on a licensee. A critical This critical system guidance placed an unnecessary system is either a system that directly supports an SSEP burden on utilities, without providing any value. In many function or supports CDAs that directly supports an SSEP cases it has added additional burden to maintain a CS list. function. These are precisely the types of systems and assets Such a list has no related regulatory requirements, nor is that must be analyzed and protected in accordance with the it needed for an effective CSP, i.e., without having a CS cybersecurity rule. The NRC staff agrees that identifying list does not adversely impact the CSP. Example: a single critical systems is a starting point for identifying CDAs. For CDA in a non-safety-related system, due to interfaces this reason, the NRC does not agree with eliminating the with a safety-related system/function, may cause the non- discussion of critical system from the RG or eliminating or safety-related system on the critical system list. revising Figures 3, 4, and 5. No change was made to the RG based on this comment.

Strongly recommend removing critical systems from this document discussion. If the system starting point guidance remains, recommend that it should be clearly stated that this is a method to grossly identify potential plant systems that may contain CDAs and may be useful for identifying CDAs.

Recommend not providing a term to describe these plant systems, i.e., Critical System, after that paragraph but focus on the remainder of the CSP apart from systems reference. This is consistent with the need to focus on performing and protecting SSEP functions. Additionally, many areas of 73.54 are NOT plant systems, e.g., ATWS, SBO, EP, BOP, and DAs included strictly due to interfaces, etc.

Recommend deleting Figures 3 & 4 and related discussion and change some labels on Figure 5, e.g.,

upper left box becomes Licensees Systems.

Kinectrics-4 Glossary Adverse Impact - See previous discussion on Use of The NRC staff disagrees with this comment. This comment is Adverse Impact. identical to portions of the comment in Kinectrics-1 above discussing adverse impact. The NRC staff reiterates the relevant portion of its response to the comment in Kinectrics-1 addressing adverse impact. No change was made to the RG based on this comment.

Kinectrics-6 Glossary Critical digital asset (CDA) - A component of a critical The NRC staff agrees with the comment. See response to system that consists of or contains a digital device. Ameren-2. The NRC staff has adopted the definition of CDA Page 10

Commenter Section Specific Comment and Proposed Resolution NRC Resolution The definition is inconsistent since it implies that a DA in NEI 08-09, Revision 6.

in a critical system, (see other discussion on Critical System), makes it a CDA. This definition adds confusion to the use of Critical Systems and is reflected in how the industrys addresses Critical Systems.

Recommend a different definition that includes the DA function and potential adverse impact. See Section C.3.1, 1st paragraph, 2nd sentence for CDA recommended text.

Kinectrics-7 Glossary Defense-in-Depth - Only applies to components. Doesnt The NRC agrees with this comment. The word function was it also apply to the function(s) to be performed? added to the definition. The definition with the revised (underlined text is added) text is -

Defense-in-depth An approach to security in which multiple levels of security and methods are deployed to guard against failure of one component, function, or level.

Kinectrics-8 Glossary Balance of Plant - Does not agree with the BOP scope It is not clear to the NRC staff what is meant by this comment.

added to the original cyber rule via the SECY letter under The NRC staff understands that the commenter does not agree the affects reactivity umbrella and addressed in the NEI with including balance of plant within the scope of the BOP NRC accepted White paper. Recommend including cybersecurity rule. The NRC Commission as a matter of policy in this RG scoping section. has determined that digital systems within the balance of plant are within the scope of the rule. Associated with this decision, the NRC has determined that NEI 10-04, Revision 3, Identifying Systems and Assets Subject to the Cyber Security Rule, is acceptable for use for addressing balance of plant issues for implementing the cybersecurity rule. It is not clear to the NRC staff what change the commenter wants made to this RGs scoping section. No change was made to the RG text based on this comment.

NEI-1 General Based on the significant changes proposed in NEI 10-04, The NRC agrees with this comment. NRC RG 5.71, Revision Revision 3 and NEI 13-10, Revision 7, the NRC should 1, cites NEI 10-04, Revision 3 and NEI 13-10, Revision 7 consider delaying issuance of RG 5.71 until the NRC throughout the RG and lists the revised NEI documents in the completes the review and approval of both NEI References section.

documents.

NEI-2 General The document uses safety and safety-related The NRC agrees with this comment that safety and safety-interchangeably throughout document; the industry related were used interchangeably throughout document. See recommends revising RG 5.71 for consistency with the response to Kinectrics-1 for the RG change made to address NRC-approved NEI White Paper focused on the this issue identified in this comment.

Page 11

Commenter Section Specific Comment and Proposed Resolution NRC Resolution identification and protection of digital assets associated with Safety-Related (SR) and Important-to-Safety (ITS) functions.

NEI-3 Applicability There is a comma at the end of the sentence causing The NRC staff agrees with this comment. The comma at the confusion to the reader. Did the NRC intend on providing end of the sentence has been replaced with a period.

additional information? Or should this be a period?

NEI-4 7 RG 5.71, Revision 1 should note that NEI 08-09 and the The NRC staff agrees with this comment. Section B, associated Addendums have been found to be acceptable Background, of this RG has been updated to state that NEI 08-for use by the NRC. 09 and the associated addendums have been found acceptable for use by the NRC.

NEI-5 The comment letter submitted by the commenter did not No response is required.

contain a comment number 5.

NEI-6 7 Although noted later in document, the Background Section The NRC staff agrees with this comment. A sentence has been should state that NEI 13-10 has been found to be added in the Background section that NEI 13-10 has been acceptable for use by the NRC. found acceptable for use by the NRC.

NEI-7 General NEI 08-09, Addendum 1, contained changes based on The NRC staff agrees with the comment that changes made in nuclear plants being in a production environment, these NEI 08-09, Addendum 1, based on nuclear plants being in a changes do not appear to be captured in this revision of production environment are not reflected in RG 5.71, RG 5.71. Revision 1. The text in NEI 08-09, Addendum 1, specifically addresses concerns performing vulnerability scans in a production environment. The NRC also agrees that vulnerability scans should not be performed if the scan could have an adverse impact on the operation of the plant. In such a case, the NRC recommends that the vulnerability scan be performed prior to the CDA being put into a production environment or during a plant outage.

The text in RG 5.71, Revision 0, always allowed for vulnerability scans or assessments to be performed throughout the life cycle of a CDAs use in a plant. This includes prior to placing the CDA in a production environment and during plant outages. The original text also takes into account potential technology changes in the future that may allow certain types of vulnerability scans to be performed that will not affect the performance of the CDA. The NRC has determined that the existing language in RG 5.71, Revision 0, adequately addressed the comments concern about conducting vulnerability scans in a production environment. Therefore, the corresponding text in Page 12

Commenter Section Specific Comment and Proposed Resolution NRC Resolution RG 5.71, Revision 1, was not changed based on this comment.

NEI-8 14 Bullet should read characterization of threats to the The NRC staff agrees with the comment, but notes that the facility as specified in RG 5.69 with applicable commenter incorrectly references RG 5.60 instead of the reference to the guide. correct RG 5.69. The NRC staff has modified the text of the second bullet in RG 5.71, Revision 1, Staff Regulatory To the second bullet in the final set of bullets in Section Guidance Section C.3.1 as follows (new text is underlined)

C.3 just prior to Section C.3.1, add as specified in RG 5.60

• characterization of threats to the facility, as specified in NRC RG 5.69 NRC RG 5.69 has been added to the Reference section of the RG 5.71.

NEI-9 19 This revision of RG 5.71 does not address that the The NRC staff agrees with the comment and has made the Federal Energy Regulatory Commissions (FERC) has suggested change in RG 5.71, Revision 1, Staff Regulatory incorporated a graded approach to cyber security and has Guidance Section C.3.1.3 based on the latest version of NEI revised needed cyber security controls for generators 10-04. RG 5.71 Staff Regulatory Guidance Section C.3.1.3 is accordingly. This should be addressed within the Balance where the NRC provides guidance on balance of plant.

of Plant (BOP) sections within the document. This would also include discussing the 15-minute shutdown guidance The NRC agrees that FERC has developed a graded approach in the NRC approved NEI White Paper focused on the to cybersecurity and has established cybersecurity controls for identification and protection of digital assets associated generators of electricity to the grid. NRC licensees are subject with Balance of Plant functions. to the cybersecurity rule. Therefore, the NRC did feel it was necessary to address or provide guidance on FERCs actions that are unrelated to the NRCs cybersecurity rule.

NEI-10 19 Page 19 and Figures 4 and 5, as well as other parts of the The NRC staff agrees with the comment but changes in Figures document, state BOP criteria as and and or. This 4 and 5 have made the comment moot. The NRC staff has should be consistent throughout Document revised the language in RG 5.71, Revision 1, Staff Regulatory Guidance Section C.3.1.3, and elsewhere in the RG as Should be and appropriate to state that identification of CDAs include BOP digital assets that if compromised could affect reactivity and result in an unplanned reactor shutdown or transient.

The NRC has revised both Figures 4 and 5 of the RG to remove the words affects reactivity or and replaced those words with BOP causes a plant trip.

As a practical matter all reactor trips affect reactivity.

Reactivity is affected when power is affected. Therefore, if a BOP CDA causes a reactor trip, the reactor trip will affect Page 13

Commenter Section Specific Comment and Proposed Resolution NRC Resolution reactivity. Accordingly, including the phrase affects reactivity is redundant. The text changes in Figures 4 and 5 eliminated the need to change the word or to and in the figures.

NEI-11 18 Figure 3, BOP and ITS should not be under safety systems, The NRC staff agrees with this comment and modified Figure this should be at a higher level. 3 to place BOP and ITS on the same level as the other systems in the figure.

NEI-12 21 There is no guidance in DG-5061 that discusses how this The NRC staff disagrees with the comment. There is text on Figure 5 decision block should be interpreted. It appears to be page 21 that discusses adversely affect SSEP functions or CSs redundant with the Performs and Supports or CDAs that perform SSEP functions and provide a pathway decision blocks. to a CS or CDA that could be used to compromise, attack, or degrade an SSEP function. The new text and addition to Remove bubble Affects Critical Assets, Functions Figure 5 were based on lessons learned during discussion with and/or Pathways. licensees who made a distinction between devices that could affect critical assets, functions and/or pathways and devices that supported CDA and critical systems. If the effect could manifest in one of the conditions identified in 10 CFR 73.54 (a)(2) then the device that caused the effect should be identified as a CDA. No change was made in the RG based on this comment.

NEI-13 40 Section C.4.1.2 added a discussion on metrics; the NRC The NRC staff disagrees with this comment. The current text in should consider clarifying that metrics are not required to RG 5.71, Revision 1, states: It is possible for licensees to address the control and are optional. provide evidence of the effectiveness of their cyber security program without implementing cyber security metrics, and therefore, this guidance is presented as an option. This sentence has been moved to the beginning of the discussion on metrics to make clear that their use is optional.

NEI-14 Appendices B NEI recommends the NRC eliminate Appendices B and The NRC staff disagrees with this comment. Regulatory guides and C C. Licensees should be free to use security control sets by provide one acceptable method licensees may use to comply NIST, NERC, IAES, ISO, IEE, IEC, or other credible with NRC regulatory requirements. Licensees are free to use external organizations. This will reduce prescriptiveness any security control sets in the development of their and increase efficiency in overall implementation. cybersecurity plan. The NRC will review the security control sets to determine if the plan meets the requirements of 10 CFR Remove Appendix B and Appendix C 73.54 and adequately protects against a cybersecurity attack.

Use of the security control sets in Appendices B and C in the RG is one acceptable way of implementing the requirements in 10 CFR 73.54. No change was made in the RG for to this comment.

Page 14

Commenter Section Specific Comment and Proposed Resolution NRC Resolution NEI-15 The NRC should consider removing the prohibition for The NRC staff disagrees with this comment. Cybersecurity wireless communication associated with Safety- Related programs in compliance with 10 CFR 73.54 must analyze, and Important-to-Safety systems and allow its use with protect, and monitor computer systems. The defensive appropriate cyber security controls. architecture in RG 5.71 uses a graded approach that establishes formal communication boundaries (or security levels) in which defensive measures are deployed to detect, prevent, delay, mitigate, and recover from cyber attacks and systems requiring the greatest degree of security are located within the most secure level of the defensive architecture. To simplify and assure adequate implementation of the defensive architecture presented in RG 5.71, wireless communication associated with Safety- Related and Important-to-Safety systems is prohibited. Extensive and significant changes to the defensive architecture and cybersecurity plans would be needed to fulfill the requirement of adequate protection of safety-related and important-to-safety systems if wireless communication is permitted for these systems. The current version of the RG does not support these changes. No change was made to the RG based on this comment.

NEI-16 General The term Intent of Control - was added to all controls. The NRC agrees that it added the section Intent of Control Where was this definition derived? The industry is for each control to RG 5.71, Revision 1. A discussion of the concerned that this added wording will now create intent of each control was added as a result of lessons learned inspection concerns and unnecessary discussions between from the cybersecurity inspections. These inspections indicated the Control Intent and the licensees cyber security that licensees did not understand the intent of the original program documents and procedures. controls when alternate controls were selected for implementation. Not understanding the intent of the original control resulted in the selection of alternate controls that did not adequately address attacks and threat vectors addressed by the original control. Some stakeholders recognize the value of including the Intent of Control section in the RG (see, e.g.,

Comment Ameren-11). The NRC has determined that understanding the intent underlying the use of a particular security control is an essential and useful element in determining if the security control adequately addresses the threat it is being used to protect against. The information in the Intent of Control sections of the RG is derived from information in various NIST and IEC cybersecurity documents.

The NRC has determined that including information on the Page 15

Commenter Section Specific Comment and Proposed Resolution NRC Resolution intent of a control aids in the development of appropriate alternate controls. No change is made to the RG based on this comment.

NEI-17 Glossary Many definitions were added to this document, examples The NRC agrees with the comment. The new definitions were being: added to the document to clarify terms used in the RG. The

• Attack Pathway definitions for Portable Media, Attack Pathway, and Attack

• Attack Surface Vector were terms used in the original version of RG 5.71.

• Attack Vector Portable Media is a tailored version of the definitions for

• Portable Media removable media and portable storage device from the Where did the definitions come from? document Committee on National Security Systems (CNSS)

Glossary (CNSSI 4009). The definitions for Attack Pathway and Attack Vector were generated by NRC staff. The definition for Attack Surface came from the NIST Computer Security Resource Center Glossary https://csrc.nist.gov/glossary/term/attack_surface. No change was made to the RG based on this comment.

NEI-18 Glossary The definition of cyber attack changed; there are now The NRC agrees that the definition of cyberattack in RG 5.71, three definitions, Rev 0, Rev 1, and NEI 08- Revision 0, RG 5.71, Revision 1, and NEI 08-09 are not

09. The industry recommends using one consistent identical. The NRC revised the definition of cyberattack in definition, that being the NEI 08-09 definition. Revision 1 to include the term adverse impact. Including this term directly ties the Revision 1 definition to 10 CFR 73.54.

The NRC has not elected include the NEI 08-09 definition in the RG 5.71, Revision 1, because the NEI 08-09 definition does not include the term adverse impact consistent with the cybersecurity rule language. The NRC notes the two definitions are substantially the same. No change was made to the RG based on this comment.

NEI-19 Glossary The definition of support system should note the change The NRC disagrees with this comment. The RG cites NEI 10-in the NRC approved NEI White Paper focused on the 04 revision 3 Identifying Systems and Assets Subject to the identification and protection of digital assets associated Cyber Security Rule, and NEI 13-10, Revision 7, Cyber with Safety-Related (SR) and Important-to-Safety (ITS) Security Control Assessments. These documents, which functions. supersede NEI White Paper focused on the identification and protection of digital assets associated with Safety-Related (SR) and Important-to-Safety (ITS) functions, do not contain changes for identification and protection of support systems for SR and ITS functions. No change was made to the RG based on this comment.

NEI-20 5. B. A revision log should be added to RG 5.71, Revision 1 The NRC disagrees with this comment. A revision log is not a Page 16

Commenter Section Specific Comment and Proposed Resolution NRC Resolution identifying the significant changes, additions, and part of the template used by the NRC for the revision of the deletions made to Revision 0 of RG 5.71. The section RG. Additionally, licensees of currently operating nuclear Reason for Revision provides a very high-level power plants are not required to make changes based on the summary of the RG update but does not identify the changes in this revised RG. Therefore, the NRC has determined specific revisions. NIST SP800-53, Rev 4 provides a that including a revision log would not serve any useful good example of such a log listing significant revisions. purpose. the need for a detailed log beyond the information provided in the Reason for Revision section is minimal. No changes were made to the RG based on this comment.

NuScale-1. C.3.1.3, The phrase directly or indirectly affect the reactivity of The NRC staff agrees in principle with this comment but has pg. 19 an NPP is overly broad. not adopted the suggested language. The following sentence, which adopts language from NEI 10-04, was added to the RG Consider using the guidance in NEI 10- 04 Loss of 5.71, Revision 1, in Staff Regulatory Guidance Section C.3.1.3:

electrical output or reactor shutdown within 15 minutes.

The broad guidance of directly or indirectly affects An unplanned reactor shutdown or transient consistent with reactivity is not quantitative as even minor changes in the definitions in NERCs CIP Reliability Standards, is defined secondary plant parameters (loss of a 5th or 6th point as an event that results in the generated megawatts being heater, etc.) while affecting reactivity have little or no reduced to zero within 15 minutes.

impact on plant operation or on the electrical output of the plant. This broad definition has caused uncertainty and has led to expansion of assets defined as CDAs beyond what is required to ensure safety, security, and emergency preparedness (SSEP) functions or protection of the Bulk Electrical Supply (BES). This should be applied wherever reactivity or transient are used throughout the document. This will align with the text on page 20 and the revision of NEI 10-04 referenced on page 20 should be issued by the time this document is issued.

NuScale-2. C.3.1.3, The word transient in could result in an unplanned The NRC agrees in principle with this comment but has not pg. 19 reactor shutdown or transient is unquantified and the adopted the suggested language. This comment is similar to the recommendation for reactivity affect in Comment 1 NuScale-1 comment. Accordingly, the NRC reiterates its should be applied. response to the NuScale-1 comment.

Quantify transient similarly to reactivity change in Comment 1, using guidance similar to that in NEI 10-04 Loss of electrical output or reactor shutdown within 15 minutes to prevent overly broad classification of assets that do not have an impact on SSEP functions or the BES.

Page 17

Commenter Section Specific Comment and Proposed Resolution NRC Resolution NuScale-3. C 3.1.3, The phrase However, such systems are still vulnerable The NRC agrees in principle with this comment but has not pg. 21 to cyber attack originating from internal sources does adopted the suggested language. The phrase supply chain has not include the risk from malicious software or firmware been added to the following underlined text in RG 5.71, inserted via the supply chain. Revision 1, Staff Regulatory Guidance Section C.3.1.3 -

Change wording to However, such systems are still However, such systems are still vulnerable to cyberattack vulnerable to cyber attack originating from internal originating from internal sources, such as inserting media into a sources, or insertion from the supply chain. system that has malicious code on it, supply chain, diagnostic systems, and other offline connections and access.

NuScale-4. C 3.1.3, The phrase In addition, because of the abundance of The NRC staff disagrees with this comment. The cited sentence pg. 21 off-the-shelf devices and peripherals that support in the RG mentions no specific examples and is technology communications technology should include wireless neutral. No change was made to the RG based on this and Internet of Things. comment.

Change wording to In addition, because of the abundance of off-the-shelf devices and peripherals that support communications technology including wireless and Internet of Things (IoT)

NuScale-5. Pg. 55 Add SIEM to the list of Acronyms as it is used in the The NRC staff agrees in part and disagrees in part with this document. comment. The staff had added SIEM - Security Incident and Event Management. to the Acronyms section of RG 5.71, Add SIEM (Security incident and event monitor). Revision 1. The acronym defined in the Acronym list is taken from the NIST on-line Computer Security Resource Center Glossary. Accordingly, the NRC has not adopted the commenters suggested language for defining what the acronym SIEM means.

NuScale-6. A.3.1.3, Phrase [Licensee/Applicant]s CST identified and The NRC staff agrees with the comment and has used the pg. 62 documented CDAs that have a direct, supporting, or suggested text in the RG 5.71, Revision 1, Appendix A.3.1.3.

indirect role in the proper functioning of CSs is overly broad and includes digital equipment that may not support an SSEP function in a CS.

Change to [Licensee/Applicant]s CST identified and documented CDAs that have a direct, supporting, or indirect role in the proper functioning of a CSs SSEP function.

NuScale-7. A.3.1.6, The application of controls does not allow for a The NRC staff disagrees with this comment. This RG does not pg. 64 quantitative risk- based approach to control assignment. utilize a specific assessment methodology for selecting and Page 18

Commenter Section Specific Comment and Proposed Resolution NRC Resolution applying security controls. Appendix A is a template to be used This comment assumes NRC acceptance of EPRI TAM by licensees to describe their CSPs and the guidance is one or similar assessment mechanism as a method of control acceptable method for implementing a CSP. If a licensee assignment. This reflects current cyber security best chooses to use another method for applying security controls, practice vs application of controls regardless of the licensee can update Section 3.1.6 of their CSP with their effectiveness. chosen method. No change was made to the RG based on this comment.

Add a new bullet point:

With respect to technical security controls,

[Licensee/Applicant] used the following for each CDA:

• Apply an NRC-approved quantitative risk-based analysis of the CDA to apply the controls in Appendix B to RG 5.71 to CDAs, OR;

• (New 1st bullet point) implementing all of the security NuScale-8. A.4.1.3, Vulnerability scanning is of limited use in detecting The NRC staff partly agrees and partly disagrees with the pg. 67 attacks. Add real time monitoring to this section. This is comment. The NRC staff agrees that additional clarifying text supported by monitoring requirements throughout this identified in this comment should be added in the RG 5.71, revision of RG 5.71. Revision 1 but the NRC staff disagrees with the section of the RG suggested for the change. The new text is more suitable Change section title to (or add new section that performs under section Staff Regulatory Guidance Section C.4.1 the same function) Vulnerability Assessments, Scans Continuous Monitoring and Assessment. The NRC staff and Monitoring. disagrees with the actual wording of the new text. Some of the Add [Licensee/Applicant] Employs real time suggested text is too prescriptive for this RG however the monitoring of all CSs network traffic events and logs in following bulleted text has been added to Staff Regulatory real-time to analyze for changes in network Guidance Section C.4.1:

communications or identified characteristics of a cyber-attack and maintains a current library of attack profiles.

• automated collection and analysis of network traffic, CDA Automated collection and analysis of network traffic, events, and logs to provide notification to licensee in real time CDA events and logs by a SIEM to provide notification of security events and provide for incident response and to licensee in real time of security events and provide for forensic analysis; incident response and forensic analysis.

NuScale-9. A.4.2.4, The section does not address changes to the cyber risk The NRC staff disagrees with this comment. The section pg. 70 environment. already includes language that addresses changes to the overall cyber security program and plan implementation, which Add bullet point: changes to the risk environment as includes implementation of security controls to address Page 19

Commenter Section Specific Comment and Proposed Resolution NRC Resolution documented in reports, alerts, and notices from the changes in the cyber risk environment. No change was made to Critical Infrastructure Security Agency (CISA), CDA the RG due to this comment.

vendors or credible sources.

NuScale-10. B.1.1, pg. B-1 To follow current best practice, access control policy The NRC staff disagrees with this comment. The NRC is should establish a Zero Trust architecture where currently engaged in a long-term effort exploring how a Zero practicable per NIST SP 800-207. This will drive the Trust architecture could be applied in nuclear security.

security architecture to current best practice while However, RG 5.71 currently illustrates a defensive architecture decreasing burden for password management, portable with security levels and boundary protection devices. Licensees device, and media control. can augment or completely replace the defensive architecture illustrated in RG 5.71, Revision 1, with a Zero Trust Add as initial control element: establishes a Zero Trust architecture. However, the accompanying CSP (Site specific Architecture in CSs and CDAs to the extent practicable. Appendix A) and the set of security controls supporting the For CSs and CDAs where Zero Trust is not achievable the defensive architecture would have to be tailored. A future policy will; revision of RG 5.71 may include sufficient information -

perhaps as an Appendix - to implement a Zero Trust architecture applicable for nuclear facilities but no changes were made to this RG based on the comment.

NuScale-11. B.1.17, Missing section number as articulated in RG 5.71; The NRC staff agrees with the comment and added the section pg.B-9 Section numbers should be listed wherever RG 5.71 is number to the identified text of the RG for clarity.

referenced for clarity.

Add section number: as articulated in RG 5.71, C.3.2

, employ throughout document for clarity.

NuScale-12. B.3.1, pg. B- This control intent does not add information to the reader The NRC staff disagrees with the comment. The intent of this 17 beyond the title. control is for licensees to have policies and procedures that address the requirements of CDAs and communication Change control intent to read: The intent of this control is protection controls. The NRC has determined that the to ensure the development, documentation, and suggested additional text would incorrectly limit the policy to deployment of policies and associated implementing requirements of CDAs and communication protection controls procedures to address requirements of CDAs and that establish network segmentation and boundary protection communication protection controls that establish network and cryptographic rules. For example, the new suggested text segmentation and boundary protection and cryptographic would not be applicable for the control Appendix B.3.22 Fail in rules. a Known State. No change was made to the RG based on this comment.

NuScale-13. B.3.2, pg. B- Add real-time CDA monitoring as alternate control. The NRC disagrees with this comment. The NRC has 18 determined that real-time CDA monitoring is not required in Add following as alternate control: Employ real-time this specific control, particularly given existing controls in RG CDA configuration monitoring and blocking of 5.71, Revision 1. In Appendix C, security controls C.11.6, Page 20

Commenter Section Specific Comment and Proposed Resolution NRC Resolution modifications using an active cyber security monitoring Access Restrictions for Change, and C.11.7, Configuration system. Settings, contain text for automated monitoring of configuration changes. No changes were made to the RG based on this comment.

NuScale-14. B.3.3, pg. B- The control intent assumes the licensee uses the same The NRC staff agrees in part and disagrees in part with this 19 security level numbering format as RG 5.71 : Levels 3 comment. The NRC staff agrees that clarifying text should be and 4 from all other levels. added to the security control, but the staff disagrees with the location for making the update. The following underlined text Add reference in RG: Levels 3 and 4 from all other is added to the Licensee/Applicant Activities section of the levels as shown in RG control instead of the Control Intent section of Appendix B.3.3.

5.71 Figure 6.

• using physically separate network devices to create and maintain logical separation of Levels 3 and 4 from each other and from all other levels as shown in RG 5.71 Figure 6.

NuScale-15. B.3.4, pg. B- Last bullet does not specify real time DOS monitoring. The NRC staff disagrees with this comment. The purpose of 19 the last bullet is to detect indicators of DoS attacks and to take Add real-time monitoring to control language for last defensive actions before the attack is fully launched. The NRC bullet: employing monitoring tools to detect indicators of has determined that adding the words real-time provides no denial-of-service attacks against CDAs in real time. additional clarity to the existing language of this bullet. No changes were made to the RG based on this comment.

NuScale-16. B.3.6, pg. B- Control element: Employ cryptographic mechanisms to The NRC staff disagrees with this comment. Nowhere in the 20 recognize changes to information during transmission and RG is it implied or explicitly stated that the security controls in upon receipt, unless otherwise protected by alternate Appendix B apply only to ICS protocols. The controls are physical measures does not reflect control system applied to CDAs that perform or support SSEP functions. If an protocols and communications. Internal ICS ICS protocol now or in the future can support cryptographic communications are in general not encrypted and mechanisms without negatively impacting SSEP functions, encryption decryption within control systems cannot be then the security control is applicable. Otherwise, an alternate easily performed except in systems with advanced control should be used as is done today in many operating controllers. Either delete the control element or specify NPPs. No changes were made to the RG based on this when practicable. comment.

If the control element is intended for non ICS internal data, the control should specify this.

Change control element to read Employ cryptographic mechanisms to recognize changes to information during transmission over insecure networks and upon receipt from insecure networks where practicable, unless otherwise protected by alternate physical measures.

Page 21

Commenter Section Specific Comment and Proposed Resolution NRC Resolution NuScale-17. B.3.7, pg. B- Confidentiality is in general not a protected characteristic The NRC staff disagrees with this comment. The concern of 20 of ICS systems beyond Identifiers and authenticators this control is not confidentiality of PII. The concern is (first bullet control element) since ICS systems rarely confidentiality of transmitted data that might be intercepted and contain PII this control should specify security data. used by an adversary in a cyberattack. This may or may not be security data. For example, it may be configuration Reword Control Intent to read: The intent of this control information for a CDA. No change was made to the RG based is to ensure that the confidentiality of security and on this comment.

personal identifying information data is maintained as the data is passed to or from CDAs.

NuScale-18. B.3.15, pg. B- ICS systems rarely use DNS data or Name Services; this The NRC staff disagrees with this comment. While critical 23 control should specify that DNS services be removed or systems containing industrial control technology rarely, if ever, disabled except where required. use DNS, other systems at NPPs within the scope of 10 CFR 73.54 may use this service. This may be especially true of External DNS requests should be rejected. emerging technologies and systems. If CDAs do not require DNS, then the services should be removed based on security See NIST SP 800-82 Rev 2. controls B.5.1 Removal of Unnecessary Services and Programs and C.11.8 Least Functionality in Appendices B Change Control Intent and control to specify only for and C in the RG. No changes were made to the RG based on systems that use DNS. Change Control Intent to For this comment.

CDAs that use domain name services, ensure implementation and control of DNS services. Disable or remove DNS services in CDAs that do not use name resolution.

Change Control to add control elements:

• Disable DNS services or remove where practicable in CDAs that do not use name services.

DNS services where required are configured to reject DNS queries to external domains.

NuScale-19. B.3.21, pg. B- Remove control, except for safety systems (these are The NRC staff disagrees with this comment. While certainly 25 covered in other standards). Diversity is difficult to there are tradeoffs (negative and positive) in using diversity for obtain and is rarely implemented for non-safety systems security purposes, implementation of this security control is not

/ CDAs, while decreasing common vulnerabilities the limited to industrial control systems. It can be used for IT inherent difficulties of implementing diverse control systems that support safety-related, important-to-safety, and systems within a system make this control impractical security systems. Licensees have an option to implement an and addition of control system architectures can add adequate alternate for this control. No change was made to the Page 22

Commenter Section Specific Comment and Proposed Resolution NRC Resolution attack surfaces and exploit sequences. Remove control. RG based on this comment.

Delete control.

NuScale-20. B.4 This entire section does not use best practice in current The NRC staff disagrees with this comment and has not adopted cyber security. Add Zero Trust as a new control with the the suggested language. This comment is similar to the NuScale-remainder of the controls in B.4 to be applied when a 10 comment. Accordingly, the NRC reiterates its response to the Zero Trust architecture cannot be achieved. New ICS NuScale-10 comment. No change was made to the RG based on upgrades and installations will often be able to select a this comment.

Zero Trust architecture vastly increasing the security of the entire system, addition of this control will drive licensees to current best practice.

Add new B.4 control as first control B.4.1 and renumber the rest with the addition of B.4.x: Where Zero Trust cannot be achievedrest of control B.4.1 implement a Zero Trust architecture as described in NIST SP 800-207.

If control is added, update references to include NIST SP 800-207.

NuScale-21. B.4.2, pg. B- Add passphrases to second control element. The NRC staff disagrees with this comment. A password is a 25 string of characters an individual uses to authenticate their Change second control element to read: passphrases and identity. This control is applicable also for specifically passwords have length and complexity commensurate formatted passwords such as passphrases and PINs. No change with the required security. was made to the RG based on this comment.

NuScale-22. B.4.3, pg. B- Change password change requirement to reflect The NRC staff disagrees with this comment. The current text of 28 current best practice of not changing non- RG 5.71, Revision 1, already allows licensees to utilize best compromised sufficient passwords. Change of practices when implementing their CSP. The NRC has passwords that have sufficient complexity and have determined that the proposed language is overly prescriptive not been compromised does not add security and and unnecessary. When this control cannot be implemented on increases burden. a CDA, licensees have an option to implement an adequate alternate for this control. No change was made to the RG based Add the statement: Passwords of insufficient complexity on this comment.

and lengths for required security due to operational or technical limitations are changed every [describe the periods for each class of system; for example, 30 days for workstations, 3 months for CDAs in the vital area],

passwords should be updated whenever a valid threat indicates risk of compromise.

Page 23

Commenter Section Specific Comment and Proposed Resolution NRC Resolution NuScale-23. B.4.2, pg. B- Insert new control element for passphrases. The NRC staff disagrees with this comment. The recommended 28 change is too prescriptive. RG 5.71, Revision 1, provides New control element to read: passphrases should licensees with the discretion to formulate adequate passwords contain four words separated by spaces or characters that comply with security requirements. No change was made and are used in preference to passwords where to the RG based on this comment.

practicable.

NuScale-24. B.5.2, pg. B- This control is incomplete, as a host-based intrusion- The NRC staff disagrees with this comment. Security control 32 detection system (HIDS) will only detect changes to the B.5.2 was written specifically for a HIDS. Security functions Host (Server or PC that it runs on). This control should typically performed by NIDSs and SIEMs are addressed in be expanded to include Network Intrusion Detection security control C.3.4 Monitoring Tools and Techniques in (NIDS) and Security Incident and Event Monitoring Appendix C of the RG. No change was made to the RG based (SIEM). These are standard components of a cyber- on this comment.

security monitoring system and allow for detection of anomalous network traffic and attacks that a server especially a compromised one will not detect or alert on.

Add separate control B.5.3 to describe proper SIEM setup to include monitoring of all network traffic via the NIDS with compensating physical controls. Where not possible renumber controls to reflect.

NuScale-25. B.5.4, pg.B- Control does not reflect current best practice. Add Zero The NRC staff disagrees with the comment. The NRC 33 Trust. disagrees and has not adopted the suggested language. This comment is similar to the NuScale-10 comment. Accordingly, Add new control element to emplace Zero Trust on CDAs the NRC reiterates its response to the NuScale-10 comment.

and CDs where feasible. No change was made to the RG based on this comment.

NuScale-26. C.1.2, Control does not reflect current best practice. The NRC staff disagrees with the comment and has not pg.C-2 Establishment of Zero Trust provides for media protection adopted the suggested language. This comment is similar to the and control. NuScale-10 comment. Accordingly, the NRC reiterates its response to the NuScale-10 comment. No change was made to Add new control element to emplace Zero Trust on CDAs the RG based on this comment.

and CDs where feasible.

NuScale-27. C.3.3, pg. C-6 Control does not provide for continuous monitoring. The NRC disagrees with this comment. Guidance on Continuous monitoring of network communications, logs continuous monitoring is covered in security control C.3.4 and events will provide for additional protection (detect) Monitoring Tools and Techniques in Appendix C of the RG.

against malicious software (and firmware / hardware). No change was made to the RG based on this comment.

Page 24

Commenter Section Specific Comment and Proposed Resolution NRC Resolution Add, as first control element: Maintains a continuous monitoring system for CS and CDAs that provides for real-time analysis.

NuScale-28. C.8, pg. C- 22 Add forensics and evidence retention to control elements. The NRC staff agrees with this comment and has added the suggested text to Appendix C.8 of the RG.

Add control element: Containment and eradication efforts to the extent practicable preserve forensic evidence of the attack, including but not limited to; data in memory, changes to software and firmware and storage media and preserve network information to analyze the attack.

NuScale-29. C.8.4, pg. C- Add forensics and evidence collection and handling. The NRC staff agrees with this comment and has added the 26 suggested text to Appendix C.8.4 of the RG.

Add control element: Cyber security forensics and evidence retention - This includes knowledge of computer forensic and evidence gathering and retention, legal requirements for handling and transmission of evidence.

NuScale-30. C.8.6, pg. C- Add reporting Cyber Security Incidents to CISA (this is The NRC staff disagrees with this comment. The NRC does 27 now required by regulation). not have a regulatory requirement that licensees report cybersecurity incidents to CISA. The scope of this RG pertains Add control element for licensee to inform CISA of cyber to compliance with NRC regulations, not the requirements of security attacks as required and consistent with site security another government agency. No change was made to the RG program. based on this comment.

NuScale-31. C.10.4, pg. C- Add gathering and handling of evidence. The NRC staff agrees in part and disagrees in part with this 36 comment. The NRC staff agrees that clarifying text regarding Add gathering, retention, and handling of evidence to the gathering and handling of evidence should be added to RG first control element. 5.71, Revision 1. The NRC staff disagrees that this clarifying text should be added to Appendix C.10.4. The NRC staff has determined that the clarifying text should be added to Appendix C.10.10, Roles and Responsibilities of the Cyber Security Specialist. The text in section Appendix C.10.10 in the RG was updated (new text is underlined) as follows:

• gathers, handles, and preserves evidence collected during cyber security investigations to prevent loss of evidentiary value; NuScale-32. C.11.3, pg. C- Quarterly audits of baseline configurations are The NRC staff disagrees with this comment. The text in 41 impractical and would be highly resource intensive (the question is in square brackets. The NRC has used square Page 25

Commenter Section Specific Comment and Proposed Resolution NRC Resolution audit would likely not finish before the next quarter brackets in RG 5.71 to indicate that licenses are allowed to starts) recommend changing to semi-annually. While insert site-specific review periodicities for this control.

feasible for the larger CSs the control does not establish Accordingly, licensees already have the ability to conduct the scope of the audits. quarterly audits of baseline configurations semi-annually or at other periodicities. Additionally, some licensees have Change audit frequency to semi- annually. implemented alternates - such as continuous monitoring for configuration changes - based on the impact of unauthorized configuration changes for some CDAs. No change was made to the RG based on this comment.

NuScale-33. C.12.2, pg. C- The changing landscape of threats to ICS systems The NRC staff agrees in part and disagrees in part with this 46 increasingly shifts to supply chain attacks from comment. The NRC staff agrees to add NIST SP 800-161 to sophisticated adversaries. Recommend a robust supply RG 5.71, Revision 1. The document has been added to chain risk management plan as described in NIST SP 800- Reference section of the RG. The NRC staff does not agree 161. with adding guidance on establishing a supply chain risk management program in RG 5.71, Appendix C.12.2. Instead, Add as C12.2.1 Establishes a Cyber Security Supply the NRC staff has revised RG 5.71, Revision 1, Staff Chain Risk Management Program as reflected in NIST Regulatory Guidance, Section C: 3.3.3.1, System and Service SP 800-161. Acquisition, to include the following language:

• establishment of a cybersecurity supply chain risk management program based on the guidance found in NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations Page 26