ML091260069
| ML091260069 | |
| Person / Time | |
|---|---|
| Site: | Oconee, Wolf Creek  |
| Issue date: | 05/06/2009 |
| From: | Pezeshki J NRC/NRR/DE/EICB |
| To: | |
| dls10 | |
| References | |
| Download: ML091260069 (16) | |
Text
Lessons Learned Using Digital I&C Lessons Learned Using Digital I&C Interim Staff Guidance Workshop Application Of ISG #1 During Wolf Creek And Oconee Reviews Jonah Pezeshki Instrumentation & Controls Branch Office of Nuclear Reactor Regulation
Agenda Overview
- Applicability of ISG#1 to Oconee and Wolf Creek LARs RG 1.152 Regulatory Positions
- Concepts phase Slide 2
- Requirements phase
- Design phase
- Implementation phase
- Test phase Summary
Applicability of ISG#1 The purpose of ISG #1 is to clarify the NRC staffs guidance with regard to the implementation of cyber security measures for nuclear power plant safety systems
- RG 1.152 provides high-level guidance for addressing cyber security during the development lifecycle
- NEI 04-04 was developed by industry to provide guidance regarding the Slide 3 NEI 04 04 was developed by industry to provide guidance regarding the development of a Cyber Security program
- The primary purpose of this Cyber Security program is to satisfy Section 18 of the sites Security Plan
- ISG #1 demonstrates that there is no conflict between conformance to NEI 04-04 and conformance to RG 1.152
- ISG #1 provides a mechanism for correlating the guidance of NEI 04-04 with the criteria specified in RG 1.152
Conformance to ISG#1 To address Cyber Security, both Oconee and Wolf Creek have committed to RG 1.152 for the design of their systems
- By using ISG #1, these licensees were able to determine and explain how their respective systems comply with the criteria of RG 1.152, thus facilitating the approval process Slide 4
- These LARs are only subject to Regulatory Positions 2.1 - 2.5
- Regulatory Positions 2.6 - 2.9 will be inspected by the respective Regions
- The Regions will address the Installation, Checkout, and Acceptance Testing phase (2.6) during the Site Acceptance Test (SAT), with support from NRR
- Cyber Security of the I&C systems will be addressed by the Regions inspection process during the Operations Phase (2.7), Maintenance Phase (2.8) and Retirement Phase (2.9)
Concepts Phase:
Overview In the concepts phase, the licensee and developer should identify safety system security capabilities that should be implemented
- Includes a security assessment to identify potential security vulnerabilities in the relevant phases of the system life cycle Slide 5
- In the case of pre-developed software, this security assessment should identify the cyber vulnerabilities in the software
- The results of this analysis should be used to establish security requirements for the system
Concepts Phase:
Reviews and Lessons Learned Oconee Review:
Since the standard TXS platform was designed prior to the issuance of RG 1.152 rev2, Oconee did not initially provide the details of the concepts phase Through the RAI process, it was made clear that a security assessment needed to be performed on the pre-developed product, in order to determine what cyber vulnerabilities may still exist in the application software A summary of this vulnerability assessment was provided to NRC staff through the RAI process Slide 6 y
y p
g p
This vulnerability assessment focused on both physical and logical access to the system, as well as assurance against post-development tampering with the application software, and was found to be acceptable by NRC staff Wolf Creek Review:
The security assessment was concurrent with the systems concept phase NRC staff determined that this security assessment met Regulatory Position 2.1 Lessons Learned
- A security assessment should always be performed
- For software under development, this assessment should be concurrent with the concept phase
- For pre-developed software, this assessment should identify the cyber vulnerabilities in the software
Requirements Phase:
Overview In the requirements phase, the licensees and developers should define the security functional performance requirements and system configuration and the interfaces external to the system
- This set of requirements is based on the security assessment performed Slide 7 during the concepts phase
- For pre-developed software, these requirements will be used to design a shell around the application
- Specifically, a set of requirements that specifically address the vulnerabilities identified during the concepts phase should be generated during this phase
Requirements Phase:
Reviews and Lessons Learned Oconee Review:
- Since the standard TXS platform was designed prior to the issuance of RG 1.152 Rev2, Oconee did not initially provide the details of the requirements phase
- Through the RAI process, it was made clear that the cyber security requirements should address the vulnerabilities identified during the concepts phase
- These requirements, as stated to NRC staff via the RAI process, address both the physical protection (i.e. location of TXS equipment) connectivity requirements (e.g.
i i i
b f
d f
)
Slide 8 one-way connectivity requirements between safety and non-safety systems)
- This set of requirements was found to be acceptable by NRC staff Wolf Creek Review:
- The development of cyber security requirements were included in the systems requirements phase
- NRC staff determined that the development of these Cyber Security requirements followed the guidance specified in Regulatory Position 2.2 Lessons Learned
- A set of Cyber Security requirements should always be generated
- For software under development, these requirements should be a subset of the system requirements
- For pre-developed software, these requirements may be used to design a shell around the application
Design Phase:
Overview In the design phase, the safety system security requirements (as identified in the requirements phase) should be translated into specific design configuration items Design elements should include:
Slide 9
- Physical and logical access to the system
- Data communication with other systems
Design Phase:
Reviews and Lessons Learned Oconee Review:
Since the standard TXS platform was designed prior to the issuance of RG 1.152 Rev2, the Oconee Design Requirements Specification did not explicitly provide the details of the design phase Through the RAI process, it was made clear that the design phase is comprised of the shell implemented around the TXS application software to limit both physical and logical access to the RPS/ESPS system Includes the use of locked/alarmed cabinets to address physical protection requirements The RPS/ESPS network is completely isolated from all other equipment (except the connection to the plant process computer through the TXS gateway), in support of connectivity requirements Includes the use of the NetOptics port tap to provide physical assurance of 1-way communication in Slide 10 Includes the use of the NetOptics port tap to provide physical assurance of 1-way communication, in support of connectivity requirements NRC staff determined that these design features met the guidance specified in Regulatory Position 2.3 Wolf Creek Review:
Connection requirements were addressed by ensuring that no connections (permanent or temporary) exist between the safety system and other installed plant equipment Physical protection requirements are addressed via physical design (i.e. program modification required the physical removal of the board, which triggers an alarm)
NRC staff determined that these design features met the guidance specified in Regulatory Position 2.3 Lessons Learned
- Connectivity requirements should be physically enforced (e.g. isolation, data diode, etc)
- Locked/alarmed cabinets (and other physical elements of the system) may be credited to address physical protection requirements
Implementation Phase:
Overview During the implementation phase, the system design is transformed into code, database structures, and related machine executable representations
- During this phase, the developer should ensure that the security design configuration item transformations from the system design specification are Slide 11 correct, accurate, and complete.
Implementation Phase:
Reviews and Lessons Learned Oconee Review:
Cyclic redundancy checksum (CRC) checks are performed during the implantation phase to ensure that malicious code cannot be implanted Virus scans are performed on software items prior to their implementation The security controls in place during the development process for the TXS application software help to ensure that undocumented/malicious code has not been injected into the final version of the application software Included access control to development site and the use of CRC checks to ensure version Slide 12 p
traceability NRC staff determined that this implementation process met the guidance specified in Regulatory Position 2.4 Wolf Creek Review Independent V&V activities were used to ensure that the implemented system matched the design NRC staff determined that this implementation process met the guidance specified in Regulatory Position 2.4 Lessons Learned
- The methods used by both licensees to address Regulatory Position 2.4 were found to be acceptable by NRC staff
Testing Phase:
Overview The objective of the Test Phase is to ensure that the system security requirements are validated by execution of integration, system, and acceptance tests, including:
- Tests to detect and isolate unauthorized pathways Slide 13
- Tests to determine and ensure system integrity (e.g. prevention of hidden/malicious code within the developed software)
Testing Phase:
Reviews and Lessons Learned Oconee Review The NetOptics port tap was tested (both experimentally and analytically) to ensure that it effectively ensures 1-way connectivity Experimental testing was conducted during the Factory Acceptance Testing NRC staff determined that this testing did not sufficiently prove that the NetOptics port tap provides physical assurance of 1-way connectivity Through the RAI process, analytical proof was provided, which credited the circuit board layout and the Slide 14 g
p y
p p
y semiconductor physics of the operational amplifier used in the circuit The NRC found this analytical evidence sufficient in proving that the NetOptics port tap provides physical assurance of 1-way connectivity Code inspection of the TXS platform was performed by an independent 3rd party during the development process to ensure the omission of hidden/malicious code The security controls in place during the development process for the Oconee application software was credited in mitigating the need for a full (i.e. deterministic) inspection the final code version of the developed application for the presence of hidden/malicious code NRC staff determined that this combination of testing and protection of the development environment met the intent of Regulatory Position 2.5
Testing Phase:
Reviews and LLd (contd)
Wolf Creek Review
- A line-by-line analysis of the application source code was used to ensure that the application software does not contain hidden/malicious code
- This line-by-line review of the Hardware Description Language (HDL) listings was a part of the design and V&V activities Slide 15
- NRC staff audited these HDL listings to ensure the device programming was traceable to requirements
- NRC staff found that this method met the guidance specified in Regulatory Position 2.5 Lessons Learned
- Line-by-line code review is a method that provides deterministic evidence that the application software does not contain hidden/malicious code
- Strict security controls, in place during the development process, may be credited to mitigate need for a full (i.e. deterministic) inspection the final version of the code
Concluding Remarks ISG #1 demonstrates that there is no conflict between conformance to NEI 04-04 and conformance to RG 1.152
- ISG #1 provides adequate high-level guidance (i.e. licensing criteria) for addressing cyber security during the development lifecycle Slide 16 In both reviews, ISG #1 successfully provided review guidance which the staff was able to use to determine the acceptability of the cyber security measures