ML043170314
| ML043170314 | |
| Person / Time | |
|---|---|
| Issue date: | 12/31/2004 |
| From: | Aggarwal S K Office of Nuclear Regulatory Research |
| To: | |
| Aggarwal S K (301)415-6005 | |
| References | |
| DG-1130 RG-1.152, Rev 2 | |
| Download: ML043170314 (15) | |
Text
1For the purposes of this regulatory guide, the term "computer" means a system that includes computerhardware, software, firmware, and interfaces.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 staff review or approval and does not represent an official NRC staff position.Public comments are being solicited on this draft guide (including any implementation schedule) and its associated regulatory analysis orvalue/impact statement. Comments should be accompanied by appropriate supporting data. Written comments may be submitted to t heRules and Directives Branch, Office of Administration, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001. Comments maybe submitted electronically through the NRC's interactive rulemaking Web page at http://www.nrc.gov/what-we-do/regulatory/rulemaking.html
.Copies of comments received may be examined at the NRC Public Document Room, 11555 Rockville Pike, Rockville, MD. Comments will bemost helpful if received by February 11, 2005
.Requests for single copies of draft or active regulatory guides (which may be reproduced) or for placement on an automatic distribution list forsingle copies of future draft guides in specific divisions should be made to the U.S. Nuclear Regulatory Commission, Washington, DC 20555,Attention: Reproduction and Distribution Services Section, or by fax to (301)415-2289; or by email to Distribution@nrc.gov. Electronic copiesof this draft regulatory guide are available through the NRC's interactive rulemaking Web page (see above); the NRC's public Web site underDraft Regulatory Guides in the Regulatory Guides document collection of the NRC's Electronic Reading Room at http://www.nrc.gov/reading-rm/doc-collections/
- and the NRC's Agencywide Documents Access and Management System (ADAMS) at http://www.nrc.gov/reading-rm/adams.html, underAccession No. ML043170314. Note, however, that the NRC has temporarily suspended public access to ADAMS so that the agencycan complete security reviews of publicly available documents and remove potentially sensitive information. Please check the NRC's Web sitefor updates concerning the resumption of public access to ADAMS. U.S. NUCLEAR REGULATORY COMMISSION December 2004OFFICE OF NUCLEAR REGULATORY RESEARCH Division 1 DRAFT REGULATORY GUIDEContact
- Satish K. Aggarwal,(301) 415-6005DRAFT REGULATORY GUIDE DG-1130(Proposed Revision 2 of Regulatory Guide 1.
152)CRITERIA FOR USE OF COMPUTERS IN SAFETY SYSTEMSOF NUCLEAR POWER PLANTSA. INTRODUCTIONThis regulatory guide describes a method that the staff of the U.S. Nuclear Regulatory Commission(NRC) deems acceptable for complying with the NRC's regulations for promoting high functional reliabilityand design quality for the use of computers 1 in safety systems of nuclear plants. Specifically, GeneralDesign Criterion (GDC) 21, "Protection System Reliability and Testability," of Appendix A, "GeneralDesign Criteria for Nuclear Power Plants," to Title 10, Part 50, "Domestic Licensing of Production andUtilization Facilities," of the Code of Federal Regulations (10 CFR Part 50), requires, among otherthings, that protection systems (or safety systems) must be designed for high functional reliabilitycommensurate with the safety functions to be performed. Criterion III, "Design Control," of AppendixB, "Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants," to 10 CFR Part50, requires, among other things, that quality standards must be specified and design controlmeasures must be provided for verifying or checking the adequacy of design.
2IEEE publications may be purchased from the IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08854.
2This regulatory guide also contains the staff's regulatory position on the "Standard Criteria forDigital Computers in Safety Systems of Nuclear Power Generating Stations,"
2which the Nuclear Power Engineering Committee of the Institute of Electrical and Electronics Engineers (IEEE) has promulgated as IEEE Std 7-4.3.2-2003. The NRC staff has collaborated inthe development of IEEE Std 7-4.3.2-2003 to ensure that the guidance providedby the consensus standard is consistent with the NRC's regulations. This standard evolvedfrom IEEE Std 7-4.3.2-1993 and reflects advances in digital technology. It also representsa continued effort by IEEE to support the specification, design, and implementationof computers in safety systems of nuclear power plants. In addition, IEEE Std 7-4.3.2-2003specifies computer-specific requirements to supplement the criteria and requirementsof IEEE Std 603-1998, "Standard Criteria for Safety Systems for Nuclear Power GeneratingStations."Regulatory guides are issued to describe to the public methods that the NRC staffconsiders acceptable for use in implementing specific parts of the agency's 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 regulatory guides is not required. Regulatory guides are issued in draft formto solicit public comment and involve the public in developing the agency's regulatory positions. Draft regulatory guides have not received complete staff review; therefore, they do notrepresent official NRC staff positions.This draft regulatory guide contains information collections that are covered bythe requirements of 10 CFR Part 50, which 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 requirementunless the requesting document displays a currently valid OMB control number.
3B. DISCUSSIONInstrumentation and control (I&C) system designs that use computers in safety systemsmake 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 andredundancy.With the introduction of digital systems into plant safety system designs, concernshave emerged regarding the possibility that a design error in the software in redundant channels ofa safety system could lead to common-cause or common-mode failure of the safety systemfunction. Conditions may exist under which some form of diversity may be necessary toprovide additional assurance beyond that provided by the design and quality assurance (QA)programs that incorporate software QA and verification and validation (V&V). The designtechniques of functional diversity, design diversity, diversity in operation, and diversity withinthe four echelons of defense in depth (provided by the reactor protection, engineered safetyfeatures actuation, control, and monitoring I&C systems) can be applied as defense againstcommon-cause failures. Manual operator actuations of safety and nonsafety systems areacceptable, provided that the necessary diverse controls and indications are available toperform the required function under the associated event conditions and within the acceptabletime.The justification for equipment diversity, or for the diversity of related system softwaresuch as a realtime operating system, must extend to equipment components to ensure thatactual diversity exists. For example, different manufacturers might use the same processor orlicense the same operating system, thereby incorporating common failure modes. Claims fordiversity based only on different manufacturers are insufficient without consideration of theabove.With respect to software diversity, experience indicates that independence of failuremodes may not be achieved in cases where multiple versions of software are developed fromthe same software requirements. Other considerations, such as functional and signaldiversity, that lead to different software requirements form a stronger basis for diversity.Some safety system designs may use computers that were not specifically designedfor nuclear power plant applications. Clause 5.4.2 of IEEE Std 7-4.3.2-2003 provides generalguidance for commercial grade dedication. Annex C to this standard provides usefulinformation on providing confidence that an existing commercial computer is of sufficientlyhigh quality and reliability to be used in a safety system.IEEE Std 7-4.3.2-2003 does not provide guidance regarding security measuresfor computer-based system equipment and software systems. Consequently, the NRC hasmodified this draft regulatory guide to include Regulatory Positions 2.1 - 2.9, which providespecific guidance concerning computer-based (cyber) safety system security.
4Clause 5.9 of IEEE Std 7-4.3.2-2003, "Control of Access," refers to the applicablerequirements in IEEE Std 603-1998 and states, "The design shall permit the administrativecontrol of access to safety system equipment. These administrative controls shall besupported by provisions within the safety systems, by provision in the generating stationdesign, or by a combination thereof." For digital computer-based systems, controls of bothphysical and electronic access to system software and data should be provided to preventchanges by unauthorized personnel. Controls should address access via network connectionsand via maintenance equipment. Additionally, the design of the plant data communicationsystems should ensure that the systems do not present an electronic path by whichunauthorized personnel can change plant software or display erroneous plant status informationto the operators. Annex E to IEEE Std 7-4.3.2-2003 provides useful information for establishingcommunication independence of plant equipment and systems.Computer-based systems must be secure from electronic vulnerabilities, as well asfrom physical vulnerabilities, which have been well addressed. Security of computer-basedsystem software relates to the ability to prevent unauthorized, undesirable, and unsafeintrusions throughout the life cycle of the safety system. Computer-based systems are securefrom electronic vulnerabilities if unauthorized access and use of those systems is prevented. The security of computer-based systems is established through (1) designing the securityfeatures that will meet user security requirements in the systems, (2) developing the systemswithout undocumented codes (e.g., back door coding, viruses, worms, Trojan horses, andbomb codes), and (3) installing and maintaining those systems in accordance with the users'security program.Regulatory Positions 2.1 - 2.9 (presented in Section C of this draft regulatory guide)provide specific guidance concerning safety system security. The effectiveness of the securityfunctions implemented in the software safety system should be confirmed during verificationand validation (V&V) and in the configuration management of the safety system software ineach lifecycle phase.In addition to the aspects discussed in Section C of this draft regulatory guide,IEEE Std 7-4.3.2-2003 includes seven informative annexes. As discussed below, the NRC hasnot endorsed Annexes B - F:(a)Annex A, "Mapping of IEEE Std 603-1998 to IEEE Std 7-4.3.2-2003," does notprovide any guidance or requirements.(b)Annex B, "Diversity Requirements Determination," is not endorsed by the NRC because it provides inadequate guidance. Branch Technical Position (BTP)HICB-19, "Guidance for Evaluation of Defense-in-Depth and Diversityin Digital Computer-Based Instrumentation and Control Systems,"in NUREG-0800, "Standard Review Plan," Section 7, "Instrumentationand Controls," provides additional guidance.(c)Annex C, "Dedication of Existing Commercial Computers," is not endorsedby the NRC because it provides inadequate guidance. Adequate guidanceis available in EPRI TR-106439, "Guideline on Evaluation and Acceptanceof Commercial Grade Digital Equipment for Nuclear Safety Applications," whichthe NRC has endorsed.
5(d)Annex D, "Identification and Resolution of Hazards," provides general informationregarding the use of qualitative or quantitative fault tree analysis (FTA) andfailure modes and effects analysis (FMEA) techniques throughout the systemdevelopment life cycle. The staff agrees that FTA and FMEA are well-knowntechniques for analyzing potential hazards; however, this annex is not endorsedbecause it provides inadequate guidance concerning the use of FTA and FMEA. Guidance is provided in Branch Technical Position HICB-14, "Guidance onSoftware Reviews for Digital Computer-Based Instrumentation and ControlSystems."(e)Annex E, "Communication Independence," is not endorsed by the NRC becauseit provides insufficient guidance. Additional guidance is provided in Appendix7.0-A, "Review Process for Digital Instrumentation and Control Systems,"Appendix 7.1-C, "Guidance for Evaluation of Conformance to IEEE Std 603," andSection 7.9, "Data Communication Systems," in NUREG-0800.(f)Annex F, "Computer Reliability," describes an approach for measuringthe reliability of digital computers used in safety systems. The NRC does notendorse the concept of quantitative reliability goals as a sole means of meetingits regulations for reliability of digital computers used in safety systems. The NRC's acceptance of the reliability of computer systems is based ondeterministic criteria for both hardware and software. Quantitative reliabilitydetermination, using a combination of analysis, testing, and operatingexperience, can provide an added level of confidence in the reliableperformance of the computer systems.(g)Annex G, "Bibliography," provides the references used in the standard. The bibliography provides sufficient detail to enable users to obtainfurther information regarding specific areas of the standard.
6C. REGULATORY POSITION1.Functional and Design RequirementsConformance with the requirements of IEEE Std 7-4.3.2-2003, "Standard Criteriafor Digital Computers in Safety Systems of Nuclear Power Generating Stations," is a methodthat the NRC staff has deemed acceptable for satisfying the NRC's regulations with respect tohigh functional reliability and design requirements for computers used in safety systemsof nuclear power plants, with the exception that the use of barriers, as proposedin Clause 5.6(a) of IEEE Std 7-4.3.2, is not acceptable to the NRC, as a means of ensuringindependence between safety functions and nonsafety functions on the same computer.However, Clause 5.6(b) of IEEE Std 7-4.3.2 requires that, in the absence of using barriers, allsoftware on a safety-related computer must be developed in accordance with IEEE Std 7-4.3.2-2003 and IEEE Std 603. This approach is acceptable to the NRC for meeting its existingregulatory requirements for addressing independence between safety software and nonsafetysoftware residing on the same computer.2.SecurityThis regulatory position uses the waterfall lifecycle phases as a frameworkfor describing specific digital safety system security guidance. Lifecycles other thanthe waterfall lifecycle may be used. The digital safety system development process shouldaddress potential security vulnerabilities in each phase of the digital safety system lifecycle. The typical waterfall lifecycle consists of the following phases:*Concepts*Requirements*Design*Implementation*Test*Installation and Checkout*Operation*Maintenance*RetirementThe lifecycle phase-specific security requirements should be commensurate withthe risk and magnitude of the harm resulting from unauthorized access, use, disclosure,disruption, or destruction of the digital safety system.The user should establish a security quality assurance program and a securityconfiguration management program as part of its security program. The security qualityassurance program and security configuration management program can be incorporatedinto the existing quality assurance and configuration management programs.The Quality Assurance organization should conduct periodic audits to determinethe effectiveness of the digital safety system security program.Regulatory positions 2.1 - 2.9 describe digital safety system security activities andrecommendations for the individual phases of the waterfall lifecycle.
72.1Concepts PhaseIn the concepts phase, the user and developer should delineate safety system securityfeatures that should be implemented to meet the desired system security capabilities. Duringthis activity, the system architecture is selected and the desired safety system securityfunctional capabilities are allocated to hardware, software, and user interface components.The user and developer should perform security risk analyses to identify potentialsecurity vulnerabilities in the relevant phases of the system and software life cycle. The results of the analysis should be used to establish security requirements for the system(hardware and software).Remote access to the safety system software functions or data from outside thetechnical environment of the plant (e.g., from the administrative or engineering buildingsor from outside the plant) that involves a potential security threat to safety functionsshould not be implemented.2.2Requirements Phase2.2.1System FeaturesThe users and developers should define the security functional and performancerequirements; interfaces external to the system; and the requirements for qualification, humanfactors engineering, data definitions, user documentation for the software and hardware,installation and acceptance, user operation and execution, and user maintenance.The security requirements are part of the overall system requirements. Therefore,the V&V process of the overall system should ensure the correctness, completeness, accuracy,testability, and consistency of the system software and hardware system requirements, whichinclude security requirements.Requirements specifying the use of pre-developed software (e.g., reuse softwareand commercial off-the-shelf software) should minimize the vulnerability of the safety system(e.g., by minimizing the number of pre-developed software functions used by the safetysystem to the extent necessary or using existing security functions of the pre-developedsoftware).2.2.2Development ActivitiesThe developer should delineate its security policies to ensure the developed products(hardware and software) do not contain undocumented code (e.g., back door coding),malicious code (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes),and other unwanted and undocumented functions or applications.
82.3Design Phase2.3.1System FeaturesThe safety system software security requirements identified in the system requirementsspecification should be translated into specific design configuration items in the softwaredesign description. The safety system software security design configuration itemsshould address control over (1) access to the software functions, (2) use of safety systemservices, (3) data communication with other systems, and (4) the list of personnelwho may access and use the system.Design configuration items incorporating pre-developed software into the safetysystem should be specified such that vulnerability of the safety system security is minimized.Access control should be based on the results of risk analyses. The results ofthe analyses may require more complex access control, such as a combination of knowledge(e.g., password), property (e.g., key, smart-card) and personal features (e.g., fingerprints),rather than just a password.2.3.2Development ActivitiesThe developer should delineate the standards and procedures that will conformwith the applicable security policies to ensure the system design products (hardware andsoftware) do not contain undocumented code (e.g., back door coding), malicious code(e.g., intrusions, viruses, worms, Trojan horses, or bomb codes), and other unwantedor undocumented functions or applications.2.4Implementation PhaseIn the software implementation phase, the system design is transformed into code,database structures, and related machine executable representations. The implementationactivity addresses software coding and testing, including the incorporation of reused softwareproducts.2.4.1System FeaturesThe developer should ensure that the security design configuration item transformations fromthe system design specification are correct, accurate, and complete.
92.4.2Development ActivitiesThe developer should implement security procedures and standards to ensure againsttampering with the developed software. The developer's standards and procedures shouldinclude testing, including scanning, to ensure against undocumented codes or maliciouscodes that might (1) allow unauthorized access or use of the system or (2) cause systemsto behave beyond the system requirements. There should be provisions againstthe incorporation of hidden functions in the application development software or the systemsoftware that could support potential unauthorized access. If provisions cannotbe implemented for pre-developed software, the use of such software should be justifiedconsidering potential security threats.The user and developer should review the possibility for deliberate modificationof software to cause erroneous behavior of the software triggered by certain timeor data constraints (e.g., viruses, worms, and Trojan horses).2.5Test PhaseThe objective of testing software security functions is to ensure that the softwaresecurity requirements and system security requirements allocated to software are validated byexecution of integration, system, and acceptance tests. Testing includes software testing,software integration testing, software qualification testing, system integration testing, andsystem qualification testing.2.5.1System FeaturesThe security requirements and configuration items are part of the overall systemrequirements and design configuration items. Therefore, testing security design configurationitems is just one element of the overall system testing. The user and developer should testeach system security feature to verify that the implemented system does not increase the riskof security vulnerabilities.2.5.2 Development ActivitiesThe developer should perform testing and scanning to ensure the developed products(i.e., hardware and software) do not contain undocumented code (e.g., back door coding),malicious code (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes), and otherunwanted and undocumented functions or applications. Additionally, the developer shouldaudit the configuration management processes to ensure that the software is developedin accordance with the appropriate configuration management procedures and standards.2.6Installation and Checkout PhaseIn installation and checkout, the safety system is installed and tested in the targetenvironment. The system user should perform an acceptance review and test the safetysystem security features. The objective of installation and checkout security testing is to verifyand validate the correctness of the safety system security features in the target environment.
102.6.1 System FeaturesThe user should ensure that the system features enable the user to perform post-installation testing of the system to verify and validate that the security requirementshave been incorporated into the system appropriately.2.6.2Development ActivitiesA user or licensee should have a comprehensive digital system security program. The security policies, standards, and procedures should ensure that installation of the digitalsystem will not compromise the security of the digital system, other systems, or the plant. This may require the user to perform a security assessment, which includes a risk assessment, toidentify the potential security vulnerabilities caused by installation the digital system. The riskassessment should include an evaluation of new security constraints in the system; anassessment of the proposed system changes and their impact on system security;and an evaluation of operating procedures for correctness and usability. The resultsof this assessment should provide a technical basis for establishing certain security levelsfor the systems and the plant.2.7 Operation PhaseThe operation lifecycle process involves the use of the safety system by the end user inits intended operational environment.The user should monitor and record access and use of the system to ensure thatits digital system security policies are implemented properly. The monitoring should includereal-time monitoring and periodic audits. The type of monitoring is determined by the riskanalyses performed in earlier lifecycle phases. The audit should include the security of anyequipment that is connected to the system for maintenance.The user should evaluate the impact of safety system changes in the operatingenvironment on safety system security; assess the effect on safety system security ofany proposed changes; evaluate operating procedures for compliance with the intended use;and analyze security risks affecting the user and the system. The user should evaluatenew security constraints in the system; assess proposed system changes and their impact onsystem security; and evaluate operating procedures for correctness and usability.
112.8 Maintenance PhaseThe maintenance phase is activated when the user changes the system or associateddocumentation. These changes may be categorized as follows:*Modifications (i.e., corrective, adaptive, or perfective changes)*Migration (i.e., the movement of software to a new operational environment)*Retirement (i.e., the withdrawal of active support by the operation and maintenanceorganization, partial or total replacement by a new system, or installation of anupgraded system)System modifications may be derived from requirements specified to correct errors(corrective), to adapt to a changed operating environment (adaptive), or to respondto additional user requests or enhancements (perfective).2.8.1Maintenance ActivitiesModifications of the safety system should be treated as development processes andshould be verified and validated as described above. Security functions should be assessedas described in the above regulatory positions, and should be revised (as appropriate)to reflect requirements derived from the maintenance process.When migrating software, the user should verify that the migrated software meets thesafety system security requirements. The maintenance process should continue to conform toexisting safety system security requirements unless those requirements are to be changed aspart of the maintenance activity.2.8.2Quality AssuranceIf the safety system security functions were not previously verified and validated usinga level of effort commensurate with the safety system security functional requirements, andappropriate documentation is not available or adequate, the user should determine whetherthe missing or incomplete documentation should be generated. In making this determinationof whether to generate missing documentation, the minimum safety system securityfunctional requirements should be taken into consideration.The user should establish a security configuration management program as part ofits security program. The security configuration program may be incorporated intothe existing configuration management program.2.8.3Incident ResponseThe user should develop an incident response and recovery plan for responding todigital system security incidents(e.g., intrusions, viruses, worms, Trojan horses, or bomb codes). The plan should be developed to address various loss scenarios and undesirable operations ofplant digital systems, including possible interruptions in service due to the loss of systemresources, data, facility, staff, and/or infrastructure. The plan should define contingencies forensuring minimal disruption to critical services in these instances.
122.8.4Audits and AssessmentsThe user should perform periodic computer system security self-assessmentsand audits, which are key components of a good security program. The user shouldassess proposed safety system changes and their impact on safety system security; evaluateanomalies that are discovered during operation; assess migration requirements;and re-perform V&V tasks to ensure that vulnerabilities have not been introduced into the plantenvironment.2.9 Retirement PhaseIn the retirement lifecycle phase, the user should assess the effect of replacingor removing the existing safety system security functions from the operating environment. The user should include in the scope of this assessment the effect on safety and nonsafetysystem interfaces of removing the system security functions. The user should documentthe methods by which a change in the safety system security functions will be mitigated (e.g.,replacement of the security functions, isolation from other safety systems and userinteractions, or retirement of the safety system interfacing functions).3.Referenced StandardsClause 2 of IEEE Std 7-4.3.2-2003 references several industry codes and standards. If areferenced standard has been separately incorporated into the NRC's regulations, licenseesand applicants must comply with the standard as set forth in the regulations. If the referencedstandard has been endorsed by the NRC staff in a regulatory guide, the standard constitutesan acceptable method of meeting a regulatory requirement as described in the regulatoryguide. If a referenced standard has been neither incorporated into the NRC's regulations norendorsed in a regulatory guide, licensees and applicants may consider and use theinformation in the referenced standard, if appropriately justified, consistent with regulatorypractice.
13D. IMPLEMENTATIONThe purpose of this section is to provide information to applicants and licenseesregarding the NRC staff's plans for using this draft regulatory guide. No backfitting is intendedor approved in connection with the issuance of this guide.The NRC has issued this draft guide to encourage public participation in its development. Except when an applicant or licensee proposes or has previously established an acceptablealternative method for complying with specified portions of the NRC's regulations, themethods to be described in the active guide will reflect public comments and will be usedin evaluating (1) submittals in connection with applications for construction permits,design certifications, operating licenses, and combined licenses for use of computers in safetysystems, and (2) submittals from operating reactor licensees who voluntarily propose to initiatesafety system modifications that have a clear nexus with this guidance.REGULATORY ANALYSISBackgroundWith the introduction of computers in safety systems, concerns have arisen overthe possibility that the use of computer software could result in a common-mode failure. Because of these concerns, the NRC staff has placed significant emphasis on defense-in-depthagainst propagation of common-mode failures within and between functions. The two principal factors for defense against common-mode failures are quality and diversity. Each postulated common-mode failure should be analyzed using best-estimate methods toaddress vulnerabilities to common-mode failures. Design qualification and quality assuranceprograms are intended to provide protection against design deficiencies and manufacturingerrors. The guidelines in IEEE Std 603-1998 and IEEE Std 7-4.3.2-2003 should be applied tothe development of digital computer systems for purposes of developing high-qualityhardware and software.1.ProblemIEEE Std 7-4.3.2-1993 was endorsed by Revision 1 of Regulatory Guide 1.152in January 1996. The development processes for computer systems continue to evolve. Therevision of this standard (IEEE Std 7-4.3.2-2003) represents a continued effort by I EEE tosupport the specification, design, and implementation of computers in safety systems. Theregulatory guide should, therefore, be revised to reflect the current state of the technology.2.ObjectiveThe objective of the regulatory action is to update NRC guidance for the useof computers in safety systems and to provide guidance on safety system security.
143.Technical ApproachIssuing a regulatory guide is consistent with the NRC policy of evaluating the latestversions of national consensus standards in terms of their suitability for endorsement byregulatory guides. This regulatory guide endorses the guidance of IEEE Std 7-4.3.2-2003 witha minor exception. As such, this guide provides a standardized approach so that the nuclearindustry and the NRC staff may have a common understanding of the criteria for the useof computers in safety systems.IEEE Std 7-4.3.2-2003 includes the following significant changes:(a)The "Software Quality Metrics" clause was added. The industry practiceis moving toward the use of software quality metrics to assure, monitor,and improve software quality, in addition to the verification and validation (V&V)that has traditionally been applied.(b)The "Qualification of Existing Commercial Computers" clause was expandedto provide additional guidance that addresses the move toward the use of morecommercial hardware and software in safety systems.(c)The "Software Tools" clause was revised to address expanded use of softwaretools and methods.(d)The "Verification and Validation" clause was revised to reference IEEE Std 1012-1998.(e)The "Software Configuration Management" clause was expanded to provideadditional guidance by identifying the key requirements for configurationmanagement for safety system software using the guidance inIEEE Std 828-1998 and IEEE Std 1042-1987.(f)A "Software Project Risk Management" clause was added to provide additionalguidance consistent with IEEE Std 1540-2001 on risk management, andIEEE Std 12207.0-1996 on software lifecycle processes.(g)A "Fault Detection and Self-Diagnostics" clause was added to discuss featuresthat are unique to software and computer systems.(h)The "Identification" clause was expanded to include software-specificrequirements by extending the IEEE Std 603-1998 identification requirements tosoftware.(i)Annex C, "Dedication of Existing Commercial Computers," was updatedto more completely address issues associated with commercial off-the-shelfsoftware (COTS).(j)Annex D, "Identification and Resolution of Hazards," was revised to representcurrent practices and processes for hazards analysis.In addition, the staff has provided guidance specific to computer-based (cyber) safetysystem security.
154.ConclusionThe NRC should revise Regulatory Guide 1.152, since this action should enhance thelicensing process. The staff has concluded that the proposed action will reduce unnecessaryburden on both the NRC and its licensees, and it will result in an improved process for the useof computers in safety systems. Furthermore, the staff sees no adverse effects associatedwith revising Regulatory Guide 1.152. Use of this revision by the licensees of currentlyoperating nuclear power plants is entirely optional and voluntary.BACKFIT ANALYSISAs described in 10 CFR 50.109(c), this draft revision of Regulatory Guide 1.152 does notrequire a backfit analysis because the use of this revision by the licensees of currentlyoperating nuclear power plants is entirely voluntary.