Annals of Nuclear Energy 38 (2011) 2174–2179

Contents lists available at ScienceDirect

Annals of Nuclear Energy

journal homepage: www.elsevier.com/locate/anucene

Secure Software Configuration Management Processes for nuclear safety

software development environment
I.-Hsin Chou ⇑
Institute of Nuclear Energy Research, Atomic Energy Council, P.O. Box 3-11, Lung-Tan, 32525 Tao-Yuan, Taiwan, ROC

a r t i c l e i n f o a b s t r a c t

Article history: The main difference between nuclear and generic software is that the risk factor is infinitely greater in
Received 6 October 2010 nuclear software – if there is a malfunction in the safety system, it can result in significant economic loss,
Received in revised form 11 June 2011 physical damage or threat to human life. However, secure software development environment have often
Accepted 18 June 2011
been ignored in the nuclear industry. In response to the terrorist attacks on September 11, 2001, the US
Available online 13 July 2011
Nuclear Regulatory Commission (USNRC) revised the Regulatory Guide (RG 1.152-2006) ‘‘Criteria for use
of computers in safety systems of nuclear power plants’’ to provide specific security guidance throughout
Keywords:
the software development life cycle. Software Configuration Management (SCM) is an essential discipline
Nuclear safety software development
environment
in the software development environment. SCM involves identifying configuration items, controlling
Software Configuration Management changes to those items, and maintaining integrity and traceability of them. For securing the nuclear
Security requirement safety software, this paper proposes a Secure SCM Processes (S2CMP) which infuses regulatory security
requirements into proposed SCM processes. Furthermore, a Process Flow Diagram (PFD) is adopted to
describe S2CMP, which is intended to enhance the communication between regulators and developers.
Ó 2011 Elsevier Ltd. All rights reserved.

1. Introduction faults produced unanticipated transients or equipment responses;

Software Configuration Management (SCM) is concerned with
the control of the evolution of complex software systems. SCM is
a process that involves identifying configuration items (CIs), con-
trolling changes to the configuration items, and maintaining integ-
rity and traceability of the CIs throughout the software
development life cycle (SDLC). The CIs include software work prod-
ucts delivered to customers and items required to create the soft-
ware work products such as software design document, test
document, test data, and compiler. The importance of SCM is also
addressed by software process improvement models, such as Capa-
bility Maturity Model (CMM), Capability Maturity Model Integra-
tion (CMMI) and Software Process Improvement and Capability
Determination (SPICE), in which SCM processes play a major role
in achieving an initial level of maturity (Krikhaar, 2007).
During the past decade, more and more nuclear safety systems
have been upgraded from hardware-wire systems to software-
based systems. Although there are many advantages offered by
the new software-based design, there are still a few disadvantages.
One of the disadvantages is the issue of CIs control coming from
the development or operation environment. According to the
report of Institute of Nuclear Power Operation (INPO) in 2008:
Over the last five years, 17 NPP screams occurred and more than
1.6 million MW-hours of generation were lost when software
⇑ Tel.: +886 3 4711400x6368; fax: +886 3 4711415.
E-mail address: ihsin@iner.gov.tw
36% of the software events are related to SCM (Institute of Nuclear
Power Operations, 2008). International Atomic Energy Agency
(IAEA) Incident Reporting System (IRS) also shows that on average
25% of NPP recorded events were caused by configuration errors or
deficiencies (International Atomic Energy Agency, 2003). There are
a few SCM-related Code of Federal Regulations (CFR) and Regula-
tory Guide (RG) for nuclear safety system, such as 10CFR 55,
10CFR 21.51, 10CFR 50 Appendix A, 10CFR 50 Appendix B, RG
1.168, RG 1.173 and RG 1.169. However, these regulations do not
specify detailed instructions and steps. Fortunately, RG 1.169-
‘‘Configuration management plans for digital computer software
used in safety systems of nuclear power plants’’ declares to
endorse IEEE 828-‘‘IEEE Standard for Software Configuration
Management Plans’’ and IEEE 1042-‘‘IEEE Standard for Software
Configuration Management’’. In Chou’s (Chou and Fan, 2006) arti-
cle, functional requirements and non-functional requirements of
SCM were identified from the three nuclear regulatory resources:
Configuration Management (CM) process area of CMMI, safety-
related regulations and SCM-related IEEE standards. The more de-
tailed descriptions will be discussed in Section 2.1.
On the other hand, the move to using Information Technology (IT)
products such as pre-developed software, Commercial Off-The-
Shelf (COTS) products, and open standards such as Ethernet and
TCP/IP allows malicious insiders to take advantage of the ignorance
in the industry. The result is a growing number of security incidents
that affect the safety of Nuclear Power Plant (NPP) and the progress
of nuclear-related industries. Few security events against NPP have

0306-4549/$ - see front matter Ó 2011 Elsevier Ltd. All rights reserved.
doi:10.1016/j.anucene.2011.06.016
 I.-H. Chou / Annals of Nuclear Energy 38 (2011) 2174–2179
been publicly reported. A complex computer worm-‘‘Stuxnet’’ has
infected the personal computers of staff at Iran’s first nuclear power
station, reported by the official IRNA news agency (BCC news, 2010).
At South Carolina’s Oconee NPP (November 2008), a transmitted
time signal message with out of range data resulted in the failure
of a digital system that had not anticipated receiving a time message
flawed in that manner. In March 2008, inadvertent access by plant
personnel to a digital system via a two-way LAN connection caused
the Hatch NPP Unit 2’s system to behave unexpectedly (David,
2010). Moreover, the International Atomic Energy Agency (IAEA)
also announced in a statement that it was developing new guide-
lines aiming at combating the danger of computerized attacks by
outside intruders or corrupt insiders (Kevin, 2004). However, the
above incident reports did not clearly stated security impacts di-
rectly on software development environment.
Although the public NPP security reports are insufficient to ana-
lyze the security impacts on SCM, security threats also might come
from insiders or outsiders within software development environ-
ment. There are three potential threats were identified from the
SCM perspective (David, 2005):
(1) Outsiders without privileges: An outsider (not a developer or
administrator) may try to read or modify assets (software
source code or history information) when they are not autho-
rized to do so. Software development environment systems
should support authorization (like login systems), and define
of what unauthorized users can do. Moreover, unauthorized
users should not be allowed to modify a source repository.
(2) Non-malicious developers with privileges: The software
development environment should support protected logins
(e.g., if it uses passwords, it should protect passwords during
transit and while they are stored). Once users are authenti-
cated, an SCM should be able to limit what users can do
based on the authorization that is granted. Limiting writing
of specific files inside a project can be much more useful for
non-malicious developers.
(3) Malicious developers with privileges: A malicious developer
may intentionally insert Trojan horses into software pro-
grams. It is not easy to distinguish between an authorized
developer and an attacker who is acquired an authorized
developer’s credentials. A malicious developer might even
try to make it appear that some other developer has done a
malicious deed. They might try to modify the data or insert
malicious code so that it looks like someone else made the
change. There are some SCM mechanisms which can be used
against them; such as making sure all developer actions can
be easily reviewed later, supporting automated checking
before acceptance, including detection of suspicious/mali-
cious changes, recording change and require other devel-
oper’s reviews.
This paper is organized as follows. Section 2 introduces the rel-
evant nuclear regulations and regulatory guides of SCM and soft-
ware security. In Section 3, a Secure Software Configuration
Management Processes (S2CMP) is proposed to secure the software
development environment. A Process Flow Diagram (PFD) is em-
ployed to present S2CMP in Section 4. Finally, some conclusions
and future work are given in Section 5.
2. Related nuclear regulatory requirements
2.1. Nuclear regulations and regulatory guidelines for SCM
The nuclear power industry developed and implemented a
quality assurance program for all aspects of the design, manufac-
2175
ture, construction, documentation, and operation of safety-related
systems and components. The ASME NQA-1-1989 provides the
overall quality assurance program requirement and SCM require-
ments are part of the overall quality assurance. In 10 CFR Part
50, ‘‘Domestic Licensing of Production and Utilization Facilities,’’
paragraph 55a(a)(1) requires, in part, that systems and compo-
nents be designed, tested, and inspected to quality standards com-
mensurate with the safety function to be performed. Criterion 1,
‘‘Quality Standards and Records,’’ of Appendix A, ‘‘General Design
Criteria for Nuclear Power Plants,’’ of 10 CFR Part 50 requires, in
part,1 that appropriate records of the design and testing of systems
and components important to safety be maintained by or under the
control of the nuclear power unit licensee throughout the life of
the unit. 10CFR 50 Appendix B, ‘‘Quality Assurance Criteria for Nu-
clear Power Plants and Fuel Reprocessing Plants,’’ to 10 CFR Part 50
describes criteria that must be met by a quality assurance program
for systems and components that prevent or mitigate the conse-
quences of postulated accidents. Moreover, RG 1.169-‘‘Configura-
tion management plans’’ also endorse industry standards such as
IEEE 828-1998‘‘IEEE Standard for Software Configuration Manage-
ment Plans’’ and IEEE 1042-‘‘IEEE Standard for Software Configura-
tion Management’’ (IEEE Std, 1987). In Chou’s previous work (Chou
and Fan, 2006), each specific items of regulatory SCM specification
were mapped to functional or nonfunctional features. Functional
features include the basic SCM functions, such as configuration
identification, configuration control, status accounting, audit and
review, workflow management and web graphic interface. Non-
functional features include traceability, consistency maintenance
and information integration.
2.2. Nuclear regulations and regulatory guidelines for software
security
The regulation at 10 CFR 50.55a (h) requires that protection sys-
tems 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 (IEEE Std, 2003) specifies computer-specific require-
ments to supplement the criteria and requirements of IEEE Std.
603-1998, ‘‘Standard Criteria for Safety Systems for Nuclear Power
Generating Stations.’’ 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 administra-
tive control of access to safety system equipment. However, IEEE
Std. 7-4.3.2-2003 does not provide any additional guidance for
computer-based system equipment and software systems to ad-
dress the IEEE-603-1998 access control requirements of Clause
5.9 or the independence requirements of Clause 5.6.3. Conse-
quently, the USNRC modified Regulatory Guide 1.152 ‘‘Criteria for
use of computers in safety systems of nuclear power plants’’, Revi-
sion 2, to include regulatory positions that provide specific guid-
ance concerning the protection of the design and development
phases of computer-based safety systems, which is intended to ad-
dress the criteria within these clauses (RG 1.152, 2006). RG1.152-
2006 uses the waterfall life cycle phases as a framework to de-
scribe system security guidance. The framework consists of nine
phases from Sections 2.1 to 2.9 which include concepts, require-
ments, design, implementation, test, installation/checkout/accep-
tance testing, operation, maintenance and retirement phase.
Chou and Fan (2010) proposed ten security activities, which are
grouped into three stages: planning stage, development stage
and application stage. Ten security activities consists of security
planning, requirement analysis, security design, security imple-
mentation, installation test, security maintenance, security opera-
tion, security decommissioning and quality assurance. Each
2176 I.-H. Chou / Annals of Nuclear Energy 38 (2011) 2174–2179
security activity corresponds to each phase of the software devel-
opment phases.
3. Secure Software Configuration Management Processes
(S2CMP)
Based on the above nuclear regulatory requirements, this paper
proposes a Secure SCM Process (S2CMP) to secure software devel-
opment environment. As it is described in Fig. 1, there are two
main parts in S2CMP: SCM Processes (SCMP) and Security Activities
(SA). SCMP (the left side of Fig. 1) represents a proposed SCM life
cycle with five phases include: institutionalized, planning, baseline
maintenance (BM), change management (CM) and audit &
accounting (AA) phase. Moreover, an iterative change control pro-
cess is made up of BM phase, AA phase and CM phase. Each phase
contains a few SCM and security activities which reference to the
above nuclear regulatory requirements. On the other hand, SA
(the right side of Fig. 1) contains three groups with seven security
activities to support SCMP. The detailed descriptions of SCMP and
SA are described as below.
3.1. Institutionalized phase
3.1.1. SCM activities
Institutionalized phase is used for supporting SCM activities,
which include task and group assignment, environment construc-
tion and team training tasks need to be performed.
(1) Task and group assignment: In this activity, SCM/SCCB Team
representatives are identified from both SCM Team and Soft-
ware Configuration Control Board (SCCB Team). In other
word, SCM Team and SCCB Team should work together.
For example, the SCM Team representatives are responsible
for managing and controlling the status of a change request.
Any updates to change requests and software baselines are
performed under authority of the SCCB Team. Any raised
change requests must be documented and sent to the
SCM/SCCB Team. The SCM/SCCB Team works with the SCCB
for a change request assessment.
(2) Environment construction: A SCM development environ-
ment should be constructed, such as SCM tools, consistency
checking software, impact analyzer and SCM repository.
(3) Team training: All SCM/SCCB Team members should be
assigned to attend training courses.
Fig. 1. Overview of Secure Software Configuration Management Processes.
3.1.2. Security activities
(1) Security Team assignment: Security Team is responsible for
security maintenance, which assesses the effect of any pro-
posed changes, evaluates operating procedures for compli-
ance with the intended use, and analyzes security risks
affecting the licensee and the system. The change of data
and the introduction into the security mechanism must be
carried out under control of the software maintenance
environment.
(2) Security assessment: The main purpose of security assess-
ment is to identify potential security vulnerabilities in the
relevant phases of the software life cycle. These processes
of security assessment are similar to RAMCAP (Risk Analysis
and Management for Critical Asset Protection): asset charac-
terization, threat characterization, consequence analysis,
vulnerability analysis, threat assessment, risk assessment
and risk management. RAMCAP is a framework for analyzing
and managing the risks associated with terrorist attacks
against critical infrastructure assets such as transportation,
telecommunications, electric power, water supply and so
on. The nuclear industry was also selected as one of the initial
Risk Analysis and Management for Critical Asset Protection
(RAMCAP) sectors (David et al., 2007). However, the security
assessment activity of this paper focuses on securing nuclear
software development environment. There is a similar to
RAMCAP approach for nuclear power plant; readers can find
the more detailed descriptions in Regulatory Guide 5.71:
Cyber security program for nuclear facilities (RG 5.71, 2010).
(3) Team training: All Security Team members should be
assigned to attend training courses.
3.2. Planning phase
3.2.1. SCM activities
In this phase, a SCM plan and a SCM procedure should be
product
(1) SCM plan preparation: A SCM plan should includes contents
as follows:
 Identifies SCM related regulations.
 Identifies the responsibilities and authorities for manag-
ing and accomplishing the planned SCM activities.
 Identifies all activities to be performed in applying to the
project.
 I.-H. Chou / Annals of Nuclear Energy 38 (2011) 2174–2179
 Identifies the required coordination of SCM activities
with the other activities in the project.
 Identifies tools and physical and human resources
required for execution of the plan.
 Identifies how the plan will be kept current while in
effect.
(2) SCM procedure preparation: Based on the SCM plan, a SCM
procedure addresses more detailed steps for software
change control, such as change request, change review,
assessment process, change status, change verification and
audit & accounting report.
3.2.2. Security activities
Security items identification: The result of security assessment
is used to identify security items, such as the network interfaces,
architecture constraint, software configuration and security func-
tional performance. In nuclear industry, safety system performs
the safety functions such as reactor trip, engineered safety or other
auxiliary supporting features. It should be separated from non-
safety functions. Any attack or failure from the non-safety system,
communications system, or data transmitted by the non-safety
system should not influence the independent safety determination.
Therefore, there are a few network interfaces (or pathways) of
safety-related network are identified as security items, which
including enterprise network, IP-based controller network, Pro-
grammable Logic Controller network (PLC) and so on. Moreover,
remote point-of-entry is another example of security item for
architecture constraint design. Its main goal is to avoid outside
intruders from other external communication network. Besides,
this activity is designed to support the preparation task of SCM
plan and SCM procedure. Therefore, the security items also should
be defined into SCM plan and SCM procedure.
3.3. Baseline maintenance phase
3.3.1. SCM activities
Baseline maintenance: In this activity, baselines will be created
and defined. A SCM repository also will be constructed for the base-
lines storage. The area of baseline repository might be divided into
two parts: document library and source library. Before each baseline
creation, a baseline report should be published. The SCM/SCCB Team
members review the baseline report to ensure the accuracy of the
base-line contents and to check if the contents are satisfied the base-
line purpose before baseline creation. According to CIs listed in base-
line reports as planned schedule, a baseline will be created. In each
baseline creation, SCM/SCCB Team creates baselines of documents
and source code. The baseline of documents is an archive or set of ap-
proved documents that is satisfied the baseline purpose. Therefore,
this activity can support software design, implementation, testing
and final release within the software development environment.
3.3.2. Security activities
Security design verification: For ensuring security configuration
items had been considered into the software specification, Security
Team is designed to support the baseline maintenance of SCM pro-
cess. However, the baseline maintenance also is assigned to sup-
port the software design. In another word, this security active
support software design indirectly.
3.4. Change management phase
3.4.1. SCM activities
(1) Software change review: SCM procedure is the most impor-
tant for this phase. Any software change should follow SCM
procedure and perform change review by SCM/SCCB Team.
2177
The SCM/SCCB Team can identify a specialist to assess and
to give comments on the request. The assessment result
such as reject, accept, or pending will be recorded as the
change request status, and returned to the owner of the
change request and to the project team by the SCM/SCCB
Team. Impact analysis should include data flow diagram
analysis, dependency analysis and interface analysis. If any
change requests about safety-related, a safety analysis
report should be preview before change.
(2) Software change verification: After the change requested
was approved, the developer starts to modify software
design into code, database structures, and related machine
executable representations. Then, SCM/SCCB Team should
verify modified software to ensure the change of design is
correct, accurate, and complete.
3.4.2. Security activities
(1) Security change review: This activity is designed to support
the software change review of SCM process. The Security
Team focuses on the review and change control of security
configuration item. In other words, Security Team should
support SCM/SCCB Team to evaluate the impact of security
changes. Therefore, the evaluate method for security
changes is based on the impact analysis of software change
view (see Section 3.4.1). In addition, independent code
review may also be used to achieve more secure.
(2) Security implementation verification: The development
team transformed software design into code, database struc-
tures, and related machine executable representations. They
may need static analysis tools to detect common vulnerabil-
ities, implementation flaws and source code bugs. In this
activity, the Security Team is assigned to ensure that the
design transformation is correct, accurate, and complete.
Security Team should apply static analysis tools to detect
common vulnerabilities, implementation flaws and source
code bugs. At the same time, the result of verification also
is used to support the SCM process (i.e. software change ver-
ification). The Security Team will support the software inte-
gration test and factory acceptance test. Besides, they should
also ensure the correctness of the safety physical and logical
software security features in the target environment.
3.5. Audit and accounting phase
3.5.1. SCM activities
Audit and accounting: Generally, there are two audit task should
be performed (IEEE Std, 1987): Physical Configuration Audit (PCA)
and Functional Configuration Audit (FCA). The PCA portion of the
audit consists of determining that all items identified as being part
of the configuration are present in the baseline. The audit must also
establish that the correct version and revision of each part are in-
cluded in the product baseline and that they correspond to informa-
tion contained in the baseline’s configuration status report. The FCA
portion is similar, in that someone acknowledges having inspected
or tested each item to determine that it satisfies the functions de-
fined in the specifications or contract(s) for which it was developed.
The objectives of a PCA/FCA are for the developers to provide notice
that contractual obligations are nearing completion, and to provide
sufficient evidence for the clients or user organization to accept the
product and initiate the transition into operational usage. A base-
line is considered as approved for further used after the SCM/SCCB
Team considers that the baseline audit report is completed. In addi-
tion, SCM/SCCB Team periodically produces SCM reports to inform
updated SCM activities to project members, the SCM/SCCB Team
and the affected groups. Any defects of software change are found
2178 I.-H. Chou / Annals of Nuclear Energy 38 (2011) 2174–2179
that should be resubmit to baseline maintenance phase (Section
3.3) and change management phase (Section 3.4).
3.5.2. Security activities
Security audit and accounting: In this activity, the Security
Team should support the security function test. They should make
ensure the correctness of software security features. Besides, the
Security Team should support the audit and accounting task of
SCM. Its main goal is to ensure that internal and external vulnera-
bilities have not been introduced into software from modifications.
Finally, Security Team periodically submits security change statis-
tics to SCM/SCCB Team for the software change accounting report.
The problems are found in this activity should be re-entered base-
line maintenance phase (Section 3.3) and change management
phase (Section 3.4).
4. Roles and Process Flow Diagram (PFD) for Secure Software
Configuration Management Processes
A good SCM program not only needs to provide software change
processes but also should support security activities to ensure the
quality of the software development environment. The roles de-
fined here constitute a supplement to the roles in existing software
Fig. 2. Process Flow Diagram (PFD) for Secure Software Configuration Management Processes.
management (project management). The difference is that those
roles are more specifically focused on security activities.
In fact, there are three roles in S2CMP (see the top of Fig. 2):
Developer, SCM/SCCB Team and Security Team. Each column repre-
sents the activities of role in S2CMP. For example, the first column
represents the software development phases from concept design
to software release; the second column represents nine SCM/SCCB
Team activities in SCMP from the institutionalized phase to the audit
& accounting phase; the third column represents Security team with
seven security activities to support SCM/SCCB Team. The association
represents the relationships between these activities. Change re-
quest and workflow are used to express the software change request
process and the sequence of activities. For example, the ‘‘Security
item identification’’ of security activities supports the ‘‘SCM plan
preparation’’ of SCM activities and the ‘‘SCM plan preparation’’ is
also designed to support the ‘‘requirement analysis’’ in software
development phases. After the software change request is proposed
by the developer, both SCM/SCCB Team and Security Team will sup-
port software change review and security review respectively.
5. Conclusion and future work
Historically, the security is rarely considered by software engi-
neers as an essential discipline in the software development envi-
 I.-H. Chou / Annals of Nuclear Energy 38 (2011) 2174–2179
ronment. Therefore, software engineers are typically not aware of
security vulnerabilities and the techniques to guard against
threats. As a result, defective software causes several billions of
US dollars’ worth of financial losses every year across the globe
(Robert, 2005). In the same way, as digital technology has been
adopted to develop nuclear safety systems, security also has be-
come an important issue for the nuclear industry.
Facing new security challenges, USNRC issued the new version
of RG 1.152-2006, which provides specific system features and
development activities guidance concerning computer based (cy-
ber) safety system security. However, there is still no clear road-
map to induce security requirements into the existing SCM. This
paper proposes a S2CMP which is intended to merge regulation
security activities into the proposed SCM processes. The contribu-
tions of this paper are shown below:
(1) S2CMP is a hybrid process based both on the nuclear SCM-
related regulations as well as security-related regulations
to support the development environment of nuclear safety
software.
(2) The proposed S2CMP emphasizes platform-independent
security processes – it is suitable for application to heteroge-
neous platforms and environments. In addition, it provides a
five-phase SCM process with seven security activities which
are merged into the existing software development
environment.
(3) Detailed descriptions and PFD of S2CMP are useful for
2software developers and licensees to better understand
the regulatory requirements. They also enhance the commu-
nication between regulator and developers.
Further work is also needed to provide a computer-aided tool
which supports S2CMP, as well as a refinement of the theoretical
approach by proving S2CMP with a real case study. In addition, a
CC_SSE_CMM-based (Lee et al., 2003; ISO/IEC_JTC1/SC27, 2005)
2179
evaluation model is being considered to measure S2CMP’s perfor-
mance and engineering processes in the further research.
References
BCC news, 2010. Middle East, 26 September 2010, BCC news website. <http://
www.bbc.co.uk/news/world-middle-east-11414483>.
Chou, I.H., Fan, C.F., 2010. Regulatory-based development processes for software
security in nuclear safety systems. Progress in Nuclear Energy 52 (4),
395–402.
Chou, I.H., Fan, C.F., 2006. Regulatory software configuration management system
design, Lecture Notes in Computer Science (LNCS). In: The 25th International
Conference on Computer Safety, Security and Reliability (SAFECOMP 2006), pp.
99–112.
David, R., 2010. Review of digital safety system secure development and operation.
In: Digital I&C workshop, September 7–9, Taipei, Taiwan.
David, A.W., 2005. Software Configuration Management (SCM). <http://www.
dwheeler.com/essays/scm-security.html>.
David, A.M., Brad, F., Michael, H., William, J., 2007. Development of a security
vulnerability assessment process for the RAMCAP chemical sector. J. Hazard.
Mater. 142, 689–694.
IEEE Std 1042, 1987. IEEE Guide for Software Configuration Management.
IEEE Std 7-4.3.2-2003, 2003. Standard Criteria for Digital Computers in Safety
Systems of Nuclear Power Generating Stations.
Institute of Nuclear Power Operations, 2008. Topical Report Software Events TR8-
63. Institute of Nuclear Power Operations website. <http://gamma1.aec.gov.tw/
fcma/english/waste_2.asp>.
International Atomic Energy Agency, 2003. Configuration Management in Nuclear
Power Plants, IAEA-TECDOC-1335, Vienna.
ISO/IEC_JTC1/SC27, 2005. Information Technology Security Techniques Evaluation
Criteria for IT Security. ISO/IEC 15408:2005 (Common Criteria v3.0).
Kevin, P.U.N., 2004. Warns of Nuclear Cyber Attack Risk. <http://www.
securityfocus.com/print/news/9592>.
Krikhaar, R., 2007. Software configuration management. Sci. Comput Program 65,
215–221.
Lee, J., Lee, S., Choi, B., 2003. A CC-based security engineering process evaluation
model. In: Proc 27th Annual International Computer Software and Applications
Conference (COMPSAC’03), pp. 130–137.
RG 1.152, Jan, 2006. Regulatory Guide 1.152: Criteria for Use of Computers in Safety
Systems of Nuclear Power Plants. US Nuclear Regulatory Commission.
RG 5.71, Jan, 2010. Regulatory Guide 5.71: Cyber Security Program for Nuclear
Facilities. US Nuclear Regulatory Commission.
Robert, N.C., 2005. Why Software Fails. IEEE spectrum (September), 42–49.