ML112000482

From kanterella
Jump to navigation Jump to search
Language for Insertion/Replacement in Pilgrim SE
ML112000482
Person / Time
Site: Pilgrim
Issue date: 07/14/2011
From: Bhalchandra Vaidya
Division of Operating Reactor Licensing
To: Monika Coflin
Division of Security Policy
Monika Coflin, NSIR/DSP 301-415-6659
References
Download: ML112000482 (3)


Text

From:

Vaidya, Bhalchandra Sent:

Thursday, July 14, 2011 10:34 AM To:

Coflin, Monika

Subject:

RE: language for insertion in Pilgrim SE Thanks, Just send me the ADAMS ML# when you add the e-mail below to ADAMS.

Bhalchandra.

From: Coflin, Monika Sent: Thursday, July 14, 2011 9:55 AM To: Vaidya, Bhalchandra Cc: Pederson, Perry

Subject:

RE: language for insertion in Pilgrim SE Balchandra, Just a quick follow-upNSIR staff considers the comments below to be insignificant in nature and believe they do not affect the final conclusion of the SE.

Monika From: Coflin, Monika Sent: Wednesday, July 13, 2011 2:55 PM To: Vaidya, Bhalchandra Cc: Pederson, Perry

Subject:

language for insertion in Pilgrim SE Balchandra, As per our conversation this afternoon, please find the language below for insertion/replacement in the Pilgrim SE.

Please feel free to let me know if you have any questions.

Thanks.

Monika Coflin, CISSP Cyber Security Specialist NSIR\\DSP\\DDRS\\ISCPB Nuclear Regulatory Commission 301-415-6659

      • Pilgrim does not deviate from NEI 08-09 in this section. Please replace language in this section with the following:

3.10 Cyber Security Controls The submitted CSP describes how the technical, operational and management cyber security controls contained in Appendices D and E of NEI 08-09 Rev. 6, that are comparable to Appendices B and C in RG 5.71, are evaluated and dispositioned based on site specific conditions during all phases of the Cyber Security Program. The CSP describes that many security controls have actions that are required to be performed on specific frequencies and that the frequency of a security control is satisfied if the action is performed within 1.25 times the frequency specified in the control, as applied, and as measured from the previous performance of the action as described in Section 4.2 of NEI 08-09, Rev. 6. This section is comparable to Appendix A, Section A.3.1.6 in RG 5.71 without deviation.

Based on the above, the NRC staff finds that the CSP adequately describes implementation of cyber security controls.

    • Conclusion statements and clarifying language was added in red.

3.11 Defense-in-Depth Protective Strategies The submitted CSP describes the implementation of defensive strategies that ensure the capability to detect, respond to, and recover from a cyber attack. The CSP specifies that the defensive strategies consist of security controls, defense-in-depth measures, and the defensive architecture. The submitted CSP notes that the defensive architecture establishes the logical and physical boundaries to control the data transfer between these boundaries.

The licensee established defense-in-depth strategies by: implementing and documenting a defensive architecture as described in Section 4.3 of NEI 08-09, Revision 6, which is comparable to Regulatory Position C.3.2 in RG 5.71; a physical security program, including physical barriers; the operational and management controls described in Appendix E of NEI 08-09, Revision 6, which is comparable to Appendix C to RG 5.71; and the technical controls described in Appendix D of NEI 08-09, Revision 6, which is comparable to Appendix B to RG 5.71.

The CSP describes the defense-in-depth architecture as predicated on isolation of CDAs within levels 2, 3, and 4. Furthermore, data flows from lower levels to higher levels are described as being severely curtailed due to the implementation of appropriately configured firewalls, intrusion detection systems, air-gaps, or deterministic one-way isolation devices such as data-diodes or hardware virtual private networks (VPNs). The NRC staffs understanding of the hardware VPN is that it is a device that has security enhancement features, but is vulnerable to unauthorized intrusions in a like manner as traditional VPN software. Since the licensee proposed these devices as equally effective in isolating CDAs and CSs from cyber attack as other deterministic methods, the NRC staff requested further explanation on the characteristics, features and effectiveness of the hardware VPN. The licensee responded by removing hardware VPN as an option from the updated CSP that it submitted on April 4, 2011.

As noted in Section 3.1 above (Scope and Purpose), the licensee substituted Emergency Plan functions for Emergency Preparedness functions (as defined in 10 CFR 73.54(a)(1)) in references to CDAs and CSs that would be protected via the submitted defense-in-depth architecture. On page 12 of the CSP, the licensee describes the implementation model for the

defense-in-depth architecture, and characterizes the several types of CDAs that are protected within the proposed layers. It notes in the third bullet that the CDAs that perform security or support Emergency Plan functions It notes in the fourth bullet that, CDAs that perform or support Emergency Plan Functions The NRC staff requested an explanation of the functions that are comprised under the term Emergency Plan and further requested that the licensee explain how the CDAs and CSs that perform Emergency Preparedness were protected under the submitted defense-in-depth architecture, as required by 10 CFR 73.54(a)(1). The licensee responded by removing references to Emergency Planning and Emergency Plan, replacing these terms with Emergency Preparedness in the submittal of its updated CSP on April 4, 2011. The changes made by the licensee as a result of the conversations with NRC staff results in defense-in-depth protective strategies consistent with Regulatory Position C.3.2 and Appendix A, Section A.3.1.5 in RG 5.71.

On page 12 of the CSP, third bullet, the licensee characterized systems that were not required to be isolated at level 4, including those, that perform safety monitoring, are within level 3.

The term safety monitoring adequately describes functions typically performed by data acquisition systems. Implementation of the defense-in-depth protective strategy in this manner is consistent with RG 5.71, Appendix C, Section C.7, which states that CDAs that provide data acquisition functions are allocated at least defensive Level 3 protection. Therefore, the NRC staff finds this deviation to be acceptable.

Based on the above, the NRC staff finds that the CSP adequately describes implementation of defense-in-depth protective strategies.

4.0 DIFFERENCES FROM NEI 08-09, REVISION 6 The NRC staff notes the following additional differences between the licensees submission and NEI 08-09, Revision 6:

In Section 3.1, Scope and Purpose, the licensee clarified the definition of important-to-safety functions, consistent with SRM-COMWCO-10-0001.

In Section 3.11, Defense-in-Depth Protective Strategies, the licensee used the term Emergency Plan in place of Emergency Preparedness; after discussions with NRC staff, the licensee used the NRC-acceptable term of Emergency Preparedness and removed references to Emergency Plan. Also, the licensee stated that systems that perform safety monitoring would be protected in Level 3.

In Section 3.21, Document Control and Records Retention and Handling, the licensee clarified the definition of records and supporting documentation that will be retained to conform to the requirements of 10 CFR 73.54.

In Section 3.22, Implementation Schedule, the licensee submitted a revised implementation schedule, specifying the interim milestones and the final implementation date, including supporting rationale.

The NRC staff finds all of these deviations to be acceptable as discussed in the respective sections.