ML100490539

Draft Regulatory Guide DG-1249, (Proposed Revision 3 of Regulatory Guide 1.152), Criteria for Use of Computers in Safety Systems of Nuclear Power Plants

ML100490539
Person / Time
Issue date:	06/30/2010
From:	Office of Nuclear Regulatory Research
To:
Ridgely J, RES/DE,301-251-7458
Shared Package
ML100490511	List: ML100490539 ML101320317
References
DG-1249 RG-1.152
Download: ML100490539 (11)

Text

U.S. NUCLEAR REGULATORY COMMISSION June 2010 OFFICE OF NUCLEAR REGULATORY RESEARCH Division 1 DRAFT REGULATORY GUIDE Contacts: Tim Mossman (301) 415-3647 Deanna Zhang (301) 415-1946 This regulatory guide is being issued in draft form to involve the public in the early stages of the development of a regulatory position in this area. It has not received final staff review or approval and does not represent an official NRC final staff position.

Public comments are being solicited on this draft guide (including any implementation schedule) and its associated regulatory analysis or value/impact statement. Comments should be accompanied by appropriate supporting data. Written comments may be submitted to the Rules, Announcements, and Directives Branch, Office of Administration, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; submitted through the NRCs interactive rulemaking Web page at http://www.nrc.gov; or faxed to (301) 492-3446. Copies of comments received may be examined at the NRCs Public Document Room, 11555 Rockville Pike, Rockville, MD. Comments will be most helpful if received by August 20, 2010.

Electronic copies of this draft regulatory guide are available through the NRCs interactive rulemaking Web page (see above); the NRCs public Web site under Draft Regulatory Guides in the Regulatory Guides document collection of the NRCs Electronic Reading Room at http://www.nrc.gov/reading-rm/doc-collections/; and the NRCs Agencywide Documents Access and Management System (ADAMS) at http://www.nrc.gov/reading-rm/adams.html, under Accession No. ML100490539. The regulatory analysis may be found in ADAMS under Accession No. ML101320317.

DRAFT REGULATORY GUIDE DG-1249 (Proposed Revision 3 of Regulatory Guide 1.152, dated March 2010)

CRITERIA FOR USE OF COMPUTERS IN SAFETY SYSTEMS OF NUCLEAR POWER PLANTS A. INTRODUCTION This guide describes a method that the staff of the U.S. Nuclear Regulatory Commission (NRC) considers acceptable to implement Title 10, of the Code of Federal Regulations, Part 50, Domestic Licensing of Production and Utilization Facilities (10 CFR Part 50) (Ref. 1); 10 CFR 50.55a(h); General Design Criterion (GDC) 21, Protection System Reliability and Testability, of Appendix A, General Design Criteria for Nuclear Power Plants, to 10 CFR Part 50; and Criterion III, Design Control, of Appendix B, Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants, to 10 CFR Part 50 with regard to the use of computers in safety systems of nuclear power plants. This guide applies to all types of commercial nuclear power plants.1 This regulatory guide describes a method that the NRC staff deems acceptable for complying with the Commissions regulations for promoting high functional reliability, design quality, and a secure development and operational environment for the use of digital computers in the safety systems of nuclear power plants. In this context, the term computer identifies a system that includes computer hardware, software, firmware, and interfaces.

One of the requirements of GDC 21 of Appendix A to 10 CFR Part 50 is that protection systems (or safety systems) be designed for high functional reliability commensurate with the safety functions to be performed. Criterion III of Appendix B to 10 CFR Part 50 requires, in part, that licensees specify 1 Institute of Electrical and Electronics Engineers (IEEE) Standard (Std.) 7-4.3.2-2003, Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations, and Regulatory Guide 1.152 were not uniquely developed for nonpower reactors; therefore, the applicability of this guide for those facilities should be determined on a case-by-case basis.

DG-1249, Page 2 quality standards and provide design control measures for verifying or checking the adequacy of safety system designs.

The regulation at 10 CFR 50.55a(h)(2) requires that protection systems for plants with construction permits issued after January 1, 1971, but before May 13, 1999, must meet the requirements stated in either the Institute of Electrical and Electronics Engineers (IEEE)2 Std. 279, Criteria for Protection Systems for Nuclear Power Generating Stations, or IEEE Std. 603-1991, Criteria for Safety Systems for Nuclear Power Generating Stations, and the correction sheet dated January 30, 1995. For nuclear power plants with construction permits issued before January 1, 1971, protection systems must be consistent with their licensing basis, or may meet the requirements of IEEE Std. 603-1991 and the correction sheet dated January 30, 1995. Paragraph (h)(3) states that for safety systems, applications filed on or after May 13, 1999, for construction permits and operating licenses under this part, and for design approvals, design certifications, and combined licenses under part 52 of this chapter, must meet the requirements for safety systems in IEEE Std. 603-1991 and the correction sheet dated January 30, 1995.

The NRC issues regulatory guides to describe to the public methods that the staff considers acceptable for use in implementing specific parts of the agencys regulations, to explain techniques that the staff uses in evaluating specific problems or postulated accidents, and to provide guidance to applicants. Regulatory guides are not substitutes for regulations and compliance with them is not required.

This regulatory guide contains information collection requirements covered by 10 CFR Part 50 that the Office of Management and Budget (OMB) approved under OMB control number 3150-0011.

The NRC may neither conduct nor sponsor, and a person is not required to respond to, an information collection request or requirement unless the requesting document displays a currently valid OMB control number.

B. DISCUSSION The regulation at 10 CFR 50.55a(h) requires that protection systems for nuclear power plants meet the requirements of IEEE Std. 603-1991 and the correction sheet dated January 30, 1995. With respect to the use of computers in safety systems, IEEE Std. 7-4.3.2-2003 specifies computer-specific requirements to supplement the criteria and requirements of IEEE Std. 603-1998, Standard Criteria for Safety Systems for Nuclear Power Generating Stations.

Working Group SC 6.4, Application of Programmable Digital Computers to Safety Systems, of the IEEE Nuclear Power Engineering Committee prepared IEEE Std. 7-4.3.2-2003. This standard evolved from IEEE Std. 7-4.3.2-1993 and reflects advances in digital technology. It also represents a continued effort by IEEE to support the specification, design, and implementation of computers in safety systems of nuclear power plants. In addition, IEEE Std. 7-4.3.2-2003 specifies computer-specific requirements to supplement the criteria and requirements of IEEE Std. 603-1998.

Instrumentation and control system designs that use computers in safety systems make extensive use of advanced technology (i.e., equipment and design practices). These designs are expected to be significantly and functionally different from current designs and may include the use of microprocessors, digital systems and displays, fiber optics, multiplexing, and different isolation techniques to achieve sufficient independence and redundancy.

2 Copies of Institute of Electrical and Electronics Engineers (IEEE) standards may be purchased from the IEEE Contact Center, 445 Hoes Lane, Piscataway, NJ 08855-1331; telephone (800) 678 4333. Purchase information is available through the IEEE Web site at http://www.ieee.org.

DG-1249, Page 3 With the introduction of digital systems into plant safety system designs, concerns have emerged about the possibility that a design error in the software in redundant safety system channels could lead to a common-cause failure or common-mode failure of the safety system function. Conditions may exist under which some form of diversity may be necessary to provide additional assurance beyond that provided by the design and quality assurance programs that incorporate software quality assurance and verification and validation. The design techniques of functional diversity, design diversity, diversity in operation, and diversity within the four echelons of defense in depth (provided by the reactor protection, engineered safety features actuation, control, and monitoring instrumentation and control systems) can be applied as defense against common-cause failures. Manual operator actuations of safety and nonsafety systems are acceptable, provided that the necessary diverse controls and indications are available to perform the required function under the associated event conditions and can be completed within the acceptable time.

The justification for equipment diversity or for the diversity of related system software, such as a real-time operating system, must extend to equipment components to ensure that actual diversity exists.

For example, different manufacturers might use the same processor or license the same operating system, thereby introducing the possibility of common failure modes. Claims of diversity based only on the use of different manufacturers are insufficient without consideration of the above.

With respect to software diversity, experience indicates that the independence of failure modes may not be achieved in cases in which multiple versions of software are developed from the same software requirements. This experience is documented in a final report by the National Research Council entitled, Digital Instrumentation and Control Systems in Nuclear Power Plants - Safety and Reliability Issues, issued 1997. Other considerations, such as functional and signal diversity, that lead to different software requirements form a stronger basis for diversity. Other NRC staff positions and guidance govern diversity and defense-in-depth issues.

Some safety system designs may use computers that were not specifically designed for nuclear power plant applications. Clause 5.4.2 of IEEE Std. 7-4.3.2-2003 provides general guidance for commercial-grade dedication.

Clause 5.6(a) of IEEE Std. 7-4.3.2-2003 states, Barrier requirements shall be identified to provide adequate confidence that the nonsafety functions cannot interfere with the performance of the safety functions of the software or firmware. The barriers shall be designed in accordance with the requirements of this standard. The nonsafety software is not required to meet these requirements.

However, 10 CFR 50.55a(h) requires that nuclear power plants conform either to IEEE Std. 279-1971 or IEEE Std. 603-1991. Clause 4.7.1, Classification of Equipment, of IEEE Std. 279-1971 requires that any equipment that is used for both protective and control functions shall be classified as part of the protection system. Clause 5.6.3.1, Interconnected Equipment, of IEEE Std. 603-1991 also requires that equipment that is used for both safety and nonsafety functions shall be classified as part of the safety systems. The term equipment includes both the software and hardware components of the digital systems. For this reason, any software providing nonsafety functions that resides on a computer providing a safety function must be classified as a part of the safety system. If a licensee wants a safety-related computer system to perform a nonsafety function, it must classify the software that performs the nonsafety function as safety-related software with all the attendant regulatory requirements for safety software, including communications independence from other nonsafety software.

Clause 5.9, Control of Access, of IEEE Std. 7-4.3.2-2003 refers to the requirements in Clause 5.9 of IEEE Std. 603-1998, which states, The design shall permit the administrative control of access to safety system equipment. These administrative controls shall be supported by provisions within the safety systems, by provision in the generating station design, or by a combination thereof. IEEE

DG-1249, Page 4 Std. 7-4.3.2-2003 does not provide any additional guidance for computer-based system equipment and software systems to address the IEEE-603-1998 access control requirements of Clause 5.9 or the independence requirements of Clause 5.6.3. Consequently, the NRC modified Regulatory Guide 1.152, Revision 2, to include regulatory positions that provide specific guidance concerning the protection of the design and development phases of computer-based safety systems, which is intended to address the criteria within these clauses.3 DG-1249 clarifies that these regulatory positions are specifically concerned with the access controls and protective measures applied to the development of digital safety systems and with the ability of protective features within the system to provide a secure operating environment such that system integrity and reliability are maintained in the event of inadvertent operator actions and undesirable behavior of connected equipment. This guide is not intended to address the ability of those protective features to thwart malicious cyber attacks. The requirements of 10 CFR 73.54 address cyber security of digital safety systems. In addition, the staff has determined that only Regulatory Positions 2.1

- 2.5 apply to licensing reviews and has removed Regulatory Positions 2.6 - 2.9 from this document.

NRC published 10 CFR 73.54, Protection of Digital Computer and Communication Systems and Networks (Ref. 2),

to require licensees to develop cyber-security plans and programs to protect critical digital assets, including digital safety systems, from malicious cyber attacks. Regulatory Guide 5.71, Cyber Security Programs for Nuclear Facilities (Ref. 3), provides guidance to meet the requirements of 10 CFR 73.54. The programmatic cyber security provisions of this new regulation and its associated guidance address Regulatory Positions 2.6 - 2.9 of Revision 2 of Regulatory Guide 1.152, which the NRC has removed from this revision of the guide. For licensees that choose to provide, as part of their license submittal, descriptions of cyber-security design features intended to address the guidance of Regulatory Guide 5.71, the extent of the staffs review of these features is limited to ensuring that these features do not adversely impact or degrade the systems reliability or its capability to perform its safety function.

To avoid confusion between the coverage of the provisions of this regulatory guide and 10 CFR 73.54, the licensee should note the following:

The establishment of a secure development and operational environment (SDOE) for digital safety systems, in the context of Regulatory Guide 1.152, refers to: (i) measures and controls taken to establish a secure environment for development of the digital safety system against undocumented, unneeded and unwanted modifications and (ii) protective actions taken against a predictable set of undesirable acts (e.g., inadvertent operator actions or the undesirable behavior of connected systems) that could challenge the integrity, reliability, or functionality of a digital safety system during operations. These SDOE actions may include adoption of protective design features into the digital safety system design to preclude inadvertent access to the system and/or protection against undesirable behavior from connected systems when operational.

Cyber security refers to those measures and controls, implemented to comply with 10 CFR 73.54, to protect digital systems against the malicious acts of an intelligent adversary up to and including the design basis threat, as defined by 10 CFR 73.1.

The NRCs intention is that the combination of this regulatory guide and the programmatic provisions under 10 CFR 73.54 should seamlessly address the secure design, development, and operation 3 The design requirements of 10 CFR Part 50, including the need for redundancy, diversity, and defense in depth, are based on the need to ensure reliable system functionality in the face of a wide range of failure modes up to and including the design-basis accidents described in each sites updated final safety analysis report (FSAR) and in the combined operating license and design certification applicants FSARs. The regulations at 10 CFR Part 50 do not require licensees to include cyber-security-related features (hardware or software or both) in safety-related system designs (i.e., features intended to provide protection against malicious cyber attacks).

DG-1249, Page 5 of digital safety systems. Notwithstanding the guidance in this regulatory guide, additional cyber-security restrictions may be imposed based on each nuclear facilitys cyber-security program.

For digital safety systems, establishment of a secure development environment includes the protection of digital computer-based systems throughout the development lifecycle of the system to prevent unauthorized, unintended, and unsafe modifications to the system. Measures should be taken to protect safety systems during development, operation, and maintenance from inadvertent actions that may result in unintended consequences to the system. Establishment of a secure development environment includes the protection of both physical and logical access to the safety system and its data such that controls should be provided to prevent unauthorized changes. Controls should address access via network connections and access via maintenance equipment. Additionally, the design of the plant data communication systems should ensure that the systems do not present an electronic path by which a person can make unauthorized changes to plant safety systems or display erroneous plant status information to the operators.

The regulatory guide provides guidance for designing digital systems (hardware and software) such that they are free from vulnerabilities that could impact the reliability of the system. In the context of this regulatory guide, vulnerabilities are considered to be 1) deficiencies in the design that may allow inadvertent, unintended, or unauthorized access or modifications to the safety system that may degrade the reliability, integrity or functionality of the safety system during operations or 2) an inability of the system to sustain the safety function in the presence of undesired behavior of connected systems. The considerations for hardware access control should include physical access control, configuration of modems, connectivity to external networks, data links, and open ports. The licensee can provide a secure development and operational environment for digital safety systems (1) by designing features that will meet the licensees secure operational environment requirements for the systems, (2) by developing the systems without undocumented codes (e.g., backdoor coding), unwanted functions or applications, and any other coding that could adversely impact the reliable operation of the digital system, and (3) by maintaining a secure operational environment for digital safety systems in accordance with the station administrative procedures and other licensees programs to protect against unwanted and unauthorized access or changes to these systems.

IEEE Std. 7-4.3.2-2003 includes the following seven informative annexes:

1.

Annex A, Mapping of IEEE Std. 603-1998 to IEEE Std. 7-4.3.2-2003, provides a mapping of the criteria of IEEE Std. 603-1998 to any elaborations found in IEEE Std. 7-4.3.2-2003. This particular annex does not contain any new guidance or requirements.

2.

Annex B, Diversity Requirements Determination, has not received NRC endorsement because it provides inadequate guidance. Additional guidance appears in NUREG-0800, Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants: LWR Edition, Chapter 7, Instrumentation and Controls, Branch Technical Position 7-19, Guidance for Evaluation of Diversity and Defense-in-Depth in Digital Computer-Based Instrumentation and Control Systems.

3.

Annex C, Dedication of Existing Commercial Computers, has not been endorsed by the NRC because it provides inadequate guidance. Adequate guidance is available in Electric Power Research Institute Topical Report (TR)-106439, Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications, which the NRC has endorsed.

DG-1249, Page 6

4.

Annex D, Identification and Resolution of Hazards, provides general information on the use of qualitative or quantitative fault tree analysis (FTA) and failure modes and effects analysis (FMEA) techniques throughout the system development lifecycle. The staff agrees that FTA and FMEA are well-known techniques for analyzing potential hazards; however, the NRC has not endorsed this annex because it provides inadequate guidance concerning the use of the FTA and FMEA techniques.

5.

Annex E, Communication Independence, is not endorsed by the NRC because it provides insufficient guidance. Appendix 7.0-A, Review Process for Digital Instrumentation and Control Systems, Appendix 7.1-C, Guidance for Evaluation of Conformance to IEEE Std. 603, and Section 7.9, Data Communication Systems, of NUREG-0800 provide additional guidance.

6.

Annex F, Computer Reliability, describes an approach for measuring the reliability of digital computers used in safety systems. The NRC does not endorse the concept of quantitative reliability goals as a sole means of meeting its regulations for the reliability of digital computers used in safety systems. The NRCs acceptance of the reliability of computer systems is based on deterministic criteria for both hardware and software. Quantitative reliability determination, using a combination of analysis, testing, and operating experience, can provide an added level of confidence in the reliable performance of the computer systems.

7.

Annex G, Bibliography, provides the references used in the standard. The bibliography provides sufficient detail to enable licensees to obtain further information on specific areas of the standard.

As discussed below, the NRC has not endorsed Annexes B - F. Regulatory Positions 2.1 - 2.5 provide specific guidance concerning the establishment of a SDOE for the protection of digital safety systems against undesirable actions and events that may affect the reliable operation of the system.

C. REGULATORY POSITION

1.

Functional and Design Requirements Conformance with the requirements of IEEE Std. 7-4.3.2-2003 is a method that the NRC staff has deemed acceptable for satisfying the NRCs regulations with respect to high functional reliability and design requirements for computers used in the safety systems of nuclear power plants. As addressed in Section B above, the Annexes B-F of IEEE Standard 7-4.3.2-2003 are not endorsed.

2.

Secure Development and Operational Environment for the Protection of Digital Safety Systems This regulatory position uses the lifecycle phases of the waterfall model only as a framework for describing specific guidance for the protection of digital safety systems and establishment of a secure development and operating environments for those systems. The digital safety system development process should identify and mitigate potential weakness or vulnerabilities in each phase of the digital safety system lifecycle that may degrade the secure development or operational environment or degrade the reliability of the system. The framework for the waterfall lifecycle model consists of the following phases:

(1)

concepts, (2) requirements, (3)

design, (4) implementation,

DG-1249, Page 7 (5)

test, (6) installation, checkout, and acceptance testing, (7) operation, (8) maintenance, and (9) retirement.

The NRC will evaluate the secure development environment controls applied to safety system development through the test phase and any secure operational environment design features intended to ensure reliable system operation included in a submittal as part of its review of a license amendment request, design certification, or combined license application. Cyber-security and other security controls applied to the latter phases of the lifecycle that occur at a licensees site (i.e., site installation, operation, maintenance, and retirement) are not part of the 10 CFR 50 licensing process and fall under the purview of other licensee programs.

Regulatory Positions 2.1 - 2.5 describe digital safety system guidance for establishment of a secure environment during the design and development phases of the lifecycle and are applicable to the review of license amendment requests, design certification, and combined operating license applications.

The guidance is specifically intended to ensure reliable operation of digital safety systems.

2.1 Concepts Phase In the concepts phase, the licensee and developer should identify digital safety system design features that should be implemented to establish a secure operational environment for the system. A licensee should describe these design features as part of its application.

The licensee and developer should perform an assessment to identify the digital safety systems potential susceptibility to inadvertent access and undesirable behavior from connected systems over the course of the systems lifecycle that could degrade the systems reliable operation. This assessment should identify the potential challenges to maintain a secure operational environment for the digital safety system and the challenges to maintaining a secure development environment for the systems development lifecycle phases. The results of the analysis should be used to establish design feature requirements (for both hardware and software) to establish a secure operational environment and protective measures that are required to maintain a secure development environment.

The licensee should not implement remote access to the safety system. For the purposes of this guidance, remote access is defined to be the ability to access a computer, node, or network resource that performs a safety function or that can impact the safety function from a computer or node that is located in an area with less physical security (e.g., outside the protected area) than the safety system.

Other NRC staff positions and guidance govern unidirectional and bidirectional data communications between safety and nonsafety digital systems.

2.2 2.2.1 System Features Requirements Phase The licensee and developer should define the secure operational environment functional performance requirements and system configuration; interfaces external to the system; and the requirements for qualification, human factors engineering, data definitions, documentation for the software and hardware, installation and acceptance, operation and execution, and maintenance.

DG-1249, Page 8 The design feature requirements intended to maintain a secure operating environment and ensure reliable system operation should be part of the overall system requirements. Therefore, the verification and validation process of the overall system should ensure the correctness, completeness, accuracy, testability, and consistency of the system secure operational environment design feature requirements.

Requirements specifying the use of predeveloped software and systems (e.g., reused software and commercial off-the-shelf (COTS) systems) should address the reliability of the safety system (e.g., by using predeveloped software functions that have been tested and are supported by operating experience).

2.2.2 Development Activities During the development of requirements, measures should be taken to ensure that the requirements development processes and documentation are secure such that the system does not contain undocumented code (e.g., backdoor coding and dead code), unwanted functions or applications, and any other coding that could adversely impact the integrity or reliability of the digital safety system.

2.3 Design Phase 2.3.1 System Features The safety system secure operational environment design features identified in the system requirements specification should be translated into specific design configuration items in the system design description.

The safety system secure operational environment design configuration items intended to ensure reliable system operation should address control over (1) physical and logical access to the system functions, (2) use of safety system services, and (3) data communication with other systems. Design configuration items that incorporate predeveloped software into the safety system should address how the predeveloped software will not challenge the secure operational environment for the safety system.

Physical and logical access control features should be based on the results of the assessment performed in the concepts phase of the lifecycle. The results of this assessment may identify the need for more complex access control measures, such as a combination of knowledge (e.g., password), property (e.g., key and smart card), or personal features (e.g., fingerprints), rather than just a password.

2.3.2 Development Activities The developer should delineate the standards and procedures that will conform with applicable design controls to ensure that the system design products (hardware and software) do not contain undocumented code (e.g., backdoor coding), unwanted functions or applications, and any other coding that could adversely impact the reliable operation of the digital safety system.

2.4 Implementation Phase In the system (integrated hardware and software) implementation phase, the system design is transformed into code, database structures, and related machine executable representations.

The implementation activity addresses hardware configuration and setup, software coding and testing, and communication configuration and setup (including the incorporation of reused software and COTS products).

DG-1249, Page 9 2.4.1 System Features The developer should ensure that the transformation of the secure operational environment design configuration items from the system design specification is correct, accurate, and complete.

2.4.2 Development Activities The developer should implement secure operational environment procedures and standards to minimize and mitigate any inadvertent or inappropriate alterations of the developed system. The developers standards and procedures should include testing, (such as scanning), as appropriate, to address undocumented codes or functions that might (1) allow unauthorized access or use of the system or (2) cause systems to behave outside of the system requirements or in an unreliable manner.

The developer should account for hidden functions and vulnerable features embedded in the code, their purpose and their impact on the integrity and reliability of the safety system. These functions should be removed or (as a minimum) addressed (e.g., as part of the failure modes and effects analysis of the application code) to prevent any unauthorized access or impact the reliability of the safety system.

COTS systems are likely to be proprietary and generally unavailable for review. In addition, a reliable method may not exist for use in determining the complete set of system behavior inherent in a given operating system (e.g., operating system suppliers often do not provide access to the source code for operating systems and callable code libraries). In such cases, unless the application developer can modify such systems, the development activity should ensure that the features within the operating system do not compromise the required secure operational environment design features of the system in such a manner that the reliability of the digital safety system would be degraded.

2.5 Test Phase The objective of testing secure operational environment design features is to ensure that the system design requirements intended to ensure system reliability are validated by the execution of integration, system, and acceptance tests where practical and necessary.

Testing includes system hardware configuration (including all connectivity to other systems, including external systems), software integration testing, software qualification testing, system integration testing, system qualification testing, and system factory acceptance testing.

2.5.1 System Features The secure operational environment design requirements and configuration items intended to ensure reliable system operation should be part of the validation effort for the overall system requirements and design configuration items. Therefore, secure operational environment design configuration items are just one element of the overall system validation. Each system secure operational environment design feature should be validated to verify that the implemented feature achieves its intended function to protect against inadvertent access and/or the effects of undesirable behavior of connected systems and does not degrade the safety systems reliability.

2.5.2 Development Activities The developer should configure and enable the secure operational environment design features correctly. The developer should also test the system hardware architecture, external communication

DG-1249, Page 10 devices, and configurations for unauthorized pathways and system integrity. Attention should be focused on built-in original equipment manufacturer features.

3.

Referenced Standards Clause 2 of IEEE Std. 7-4.3.2-2003 references several industry codes and standards. If the NRC has incorporated a referenced standard into its regulations, licensees and applicants must comply with the standard as set forth in those regulations. If the NRC staff has endorsed the referenced standard in a regulatory guide, the standard constitutes an acceptable method for use in meeting a regulatory requirement as described in the regulatory guide. If the NRC has neither incorporated a referenced standard into its regulations nor endorsed the standard in a regulatory guide, licensees and applicants may consider and use the information in the referenced standard, if appropriately justified, consistent with regulatory practice.

D. IMPLEMENTATION The purpose of this section is to provide information to applicants and licensees regarding the NRCs plans for using this draft regulatory guide. The NRC does not intend or approve any imposition or backfit in connection with its issuance.

The NRC has issued this draft guide to encourage public participation in its development. The NRC will consider all public comments received in development of the final guidance document. In some cases, applicants or licensees may propose an alternative or use a previously established acceptable alternative method for complying with specified portions of the NRCs regulations. Otherwise, the methods described in this guide will be used in evaluating compliance with the applicable regulations for license applications, license amendment applications, and amendment requests.

DG-1249, Page 11 REFERENCES4

1.

10 CFR Part 50, Domestic Licensing of Production and Utilization Facilities, U.S. Nuclear Regulatory Commission, Washington, DC.

2.

10 CFR Part 73, Physical Protection of Plants and Materials, U.S. Nuclear Regulatory Commission, Washington, DC.

3.

Regulatory Guide 5.71, Cyber Security Programs for Nuclear Facilities, U.S. Nuclear Regulatory Commission, Washington, DC.

4 Publicly available NRC published documents such as Regulations, Regulatory Guides, NUREGs, and Generic Letters listed herein are available electronically through the Electronic Reading room on the NRCs public Web site at:

http://www.nrc.gov/reading-rm/doc-collections/. Copies are also available for inspection or copying for a fee from the NRCs Public Document Room (PDR) at 11555 Rockville Pike, Rockville, MD; the mailing address is USNRC PDR, Washington, DC 20555; telephone 301-415-4737 or (800) 397-4209; fax (301) 415-3548; and e-mail PDR.Resource@nrc.gov.