IAEA International Atomic Energy Agency

Procurement of

Software and Digital Equipment

Technical Meeting on Procurement Activities and

on Counterfeit, Fraudulent and Substandard Items (CFSIs)

Experiences and Lessons Learned

Vienna, Austria

8-10 September 2014

Michael T. Rowland

Division of Nuclear Security

IAEA

Outline

1. Classification of Systems/I&C Systems

2. Safety and Software Issues

3. Qualification

4. Commercial Grade Dedication

5. Security Considerations

6. Case Studies

7. IAEA Security Guidance

IAEA

Categorization of Systems

• The process to categorize

systems performing

accredited safety or

safety related functions

is detailed in the

IAEA Safety Guides.

• This allows for categorization of most safety or safety

related equipment and systems at the facility.

• Many Nuclear I&C systems are accredited with performing

safety and/or safety related functions within a nuclear

facility.

IAEA 4

I&C System Overview

I&C Systems refers to

• analog and digital control hardware, firmware,

communications, and software that monitor and/or control

physical devices. (multiple definitions exist).

I&C Systems may perform

• simple temperature or flow measurements; OR

• complex control algorithms for reactor control in nuclear

facilities.

Current I&C system design architectures are digitally based

IAEA

Contemporary Digital I&C Systems

IAEA

Software Guidance - IAEA Safety Guide

• The IAEA safety guide for computer based systems indicates that

“software faults may result from either bad or unclear specification of

requirements (which gives rise to errors in the logical design or

implementation) or errors introduced during the implementation phase

or maintenance phase”.

• This indicates the clear need for proper transmission of software

requirements to the supplier during the procurement phase.

IAEA

Software Issues affecting Safety

• The challenge with equipment with software is that verification of

physical attributes is very difficult and in some cases not possible.

• For example access to source code may not be unavailable, making its

direct review impossible.

• Similarly, software version changes can have significant impacts on

item operation and failure modes, neither of which can be observed by

visually inspecting the item.

• Such changes can be introduced unexpectedly by vendors shipping

digital components with “updated” firmware when replacement parts are

ordered.

• As a result, increased emphasis on testing of software under all

representative conditions, and careful control of software changes is

required.

IAEA

Software Qualification – Step 1

Software categorization based on system and

equipment operation:

• Identify software or firmware in the equipment

• Establish software function– safety related,

control, monitoring, annunciation

• Assess impact of software failure

IAEA

Software Qualification – Step 2

Software qualification commensurate with the

categorization

This includes:

• Configuration scope

• Required documentation

• Testing protocols and acceptance criteria

• Version and revisions

IAEA

Example: OPGN Stack Monitoring

• Stack Monitoring System was a real-time system

that provided monitoring of tritium stack releases

as well as digital contact alarms for annunciation to

the operator.

• System classified as OPGN Category III Software

– Safety Related.

• Operator could use information provided by system

for operational decision making.

• No automated control functions

IAEA

Stack Monitoring – Input Documents

• System Design Requirements (Operator)

• Computer System Design Requirements

• Software Design Requirements

• Design Plan

• Test Plans (Integration, V&V, FAT, SAT)

IAEA

Stack Monitoring – Output Documents

• Computer System Design Description

• Software Design Description

• Software Load Media Specification (Record)

• Software Configuration Specification

• Software Maintenance Plan

• Test Reports

• Software Release Note(s)

IAEA

Software Process

Designer Issues New Software Load Media Specfication

QA/V&VTesting

Installation andCommissioning

System AvailableFor ServiceDeclaration

PASS

PASS

System Declared Available for

Service

Accepted

FAIL

FAIL

Input Documents

Output Documents

System Design RequirementsComputer Design Requirements Software Design Requirements

Software Load Media Spec- source code with Checksum/hashes- development environment software

-procedures for software compilation and build

Software Load Media SpecificationQA Test Plans

Object Code/FirmwareTest Reports

Restore Media

Computer Design DescriptionSoftware Design Description

Commissioning PlanCommissioning Report

Software Release NoteSoftware Configuration Specification

Software Maintenance PlanAFS Declaration

Software Maintenance Plan

IAEA

Commercial Grade Dedication

• Commercial-grade dedication is a process by which a

commercial-grade item (CGI) is designated for use as a

basic component.

• This acceptance process is undertaken to provide

reasonable assurance that a CGI to be used as a basic

component will perform its intended safety function and, in

this respect, is deemed equivalent to an item designed

under a specified quality assurance program.

• This assurance is achieved by identifying the critical

characteristics of the item and verifying their acceptability

by inspections, tests, or analyses by the purchaser or third-

party dedicating entity.

Ref: US-NRC

IAEA

CGD – Fuel Handling Computer

• Computer is no longer manufactured by the Original

Equipment Manufacturer

• Spare computers are purchased on the aftermarket.

• CGD activities included:

• Hardware Inspection Test

• Software Inventory (including Binary Comparison)

• Execution of V&V test cases

• Additional test cases to ensure critical components have

not degraded to the point where they could no longer

perform their accredited safety function.

IAEA International Atomic Energy Agency

Vendor Security Considerations

I&C System Security

IAEA

Vendors and Security: Why?

IAEA

Early Nuclear Digital I&C

• Custom Systems

• Proprietary Operating

Systems

• Systems Dedicated to

Function

• Isolated Networks

• Legacy Hardware

IAEA

Factors driving Digital I&C evolution

• Industrial value • Equipment is continuously monitored

• Faster diagnostics of failures

• Safety benefits • Data is available in real time

• Data analysis can provide insight on process improvements

• Power Market Operation • near real-time info on every asset availability, output and status

• Corporate • Corporate/Management demand for real time access to process

data for financial or performance reporting

19

IAEA

Factors driving Digital I&C evolution

• Supply Chain/Technology

• Nearly all I&C is digital now, with greater connectivity

• Migration toward more non-proprietary systems

• Remote access

• These devices are designed to “talk” to each other which makes them susceptible to network based cyber attacks.

20

IAEA

Case Study: Vendor Access

Lessons learned: Secure remote (trusted)

access channels Ensure Defense-in-depth

strategies with appropriate procurement requirements

Critical patches need to be applied

Davis Besse NPP

Event: January 25, 2003,

Slammer worm infects plant.

Threat: Inadvertent – IT Worm

Impact: Complete shutdown of digital

portion of Safety Parameter Display

System (SPDS) and Plant Process

Computer (PPC).

Specifics: Worm started at contractors

site then jumped from the corporate to

plant network and found an unpatched

server.

21

IAEA

Software Flaws & Vulnerabilities

• Digital I&C Systems

contain software

• Software contains flaws

that may be exploited by

malicious persons or

organizations

• Flaws that can be exploited

are called security

vulnerabilities

• Exploitation of

vulnerabilities can lead to

consequences

• The increasing complexity and size of

software programs contribute to the growth

in software flaws.

• Windows XP ~ 45 million lines of code,

• Windows 7 ~ a lot of code

• Based on various studies, National

Institute of Standards and Technology

(NIST), based on various studies of code

inspections, most estimates suggest that

there are as many as

20 flaws per thousand lines of software

code.

• While most flaws do not create security

vulnerabilities, the potential for these errors

reflects the difficulty and complexity

involved in delivering trustworthy code.

• (Ref: National Institute for Standards and Technology, Procedures

for Handling Security Patches: Recommendations of the National

Institute of Standards and Technology, NIST Special Publication 800-

40 (Gaithersburg, MD: August 2002).

IAEA

CIA Consequence

• Consequences Fall into Three Categories:

• Loss of Confidentiality

• Theft of data, plans and other information

• Compromise of Administrator credentials

• Loss of Integrity

• System is operational but you cannot

trust the data

• Loss of Availability

• Denial of service attack

• System becomes inoperative or ineffective

23

IAEA

Security - Qualification

• Qualification testing limited to

safety considerations may not

consider security risks.

• Hard-coded passwords (e.g.

Backdoors) may be perceived

as a benefit or feature easing

administrative tasks.

• The use of hard-coded

passwords increases the

susceptibility of these

systems to cyber attack.

Ref: Kim Zetter, http://www.wired.com/2012/04/ruggedcom-backdoor/

IAEA

Security - CGD

• Over 50% of counterfeit incidents occurred when

product was obsolete and no longer manufactured by

the OEM.

• Security requirements should be included during the

hardware inspection tests and software inventory

(binary comparisons)

IAEA

Common ICS Vulnerabilities

Poor Network Protocol

Implementations, 26%

Information Disclosure, 21%

Weak Authentication, 18%

Poor Patch Management, 8%

Network Component Configuration

(Implementatin) Vulnerabilities, 8%

Poor Code Quality, 7%

Vulnerabe Web Services, 4%

Least User Privilege Violation, 4%

Network Design Vulnerabilities, 4%

Source: DHS Control System Security Program

http://www.us-cert.gov/control_systems/pdf/DHS_Common_Vulnerabilities_R1_08-

14750_Final_7-1-09.pdf 26

IAEA

Security Requirements - Hardening

• Security Requirements should ensure that the

implementation process includes the “hardening” of

systems.

• System Hardening nominally involves removal of

unnecessary services from the asset’s operating systems

and applications.

IAEA

Hardware Hardening

Hardware Hardening activities may also include:

• Vetting of Vendors, including independent inspections to

ensure computer security processes and procedures are

carried out as required.

• Disabling all wireless capabilities

• Disabling of USB ports

• Disabling writing capabilities on removable media

(floppy/CD/DVD drives)

• Limit the ability to read data from removable media

IAEA

Software Hardening

Software Hardening activities may include:

• Software to be obtained from “Trusted Suppliers”

• Unessential software should be removed

• Adequate access control measures (strong, secure log-

in passwords that are changed on periodic basis)

• Software to detect/prevent infection of the system with

malicious software

• Event logging to record anomalies (errors, malicious

software detection, attempts to bypass access controls,

etc.)

• Restrictions on accessing or downloading of software

from the internet

IAEA

Watering Hole Attack on ICS - Dragonfly

Energy Sector and ICS –

Europe/USA (2013/4)

Event: Compromise of update

site for several (3 known) ICS

Software producers.

Threat: Group III

Impact: Reconnaissance and

Privileged Remote Access.

Facilitation of future attacks.

30 Source: Symantec Security Response – Dragonfly: Cyberespionage Attacks Against Energy Suppliers –Version 1.21 July 7,2014

IAEA

NSS 17 Technical Guidance

• Currently only dedicated international consensus document on

Computer Security for Nuclear Facilities.

• The objective of the document is to provide guidelines to personnel

designing, implementing, and managing Instrumentation and Control

(I&C) and Information systems and networks at nuclear facilities.

• The guidance addresses prevention and detection of potential attacks

through reference to best practices in architecture, assurance and

management of security information and I&C systems.

• Initial concept development – 2003

• Final publication – 2011

• 8 years to publication – IAEA working towards

increasing responsiveness.

31

IAEA

NSS 17 – Procurement Guidance

• Nuclear Security Series No 17 – Computer Security at Nuclear Facilities

states

• During the original design and development of many of the existing

process control and industrial control systems and instrumentation,

computer security was not a major consideration.

• The recent drive for system and interprocess connectivity, the

integration of commercial off the shelf computer systems, and the

rise in malicious computer activity (i.e. hacking) has driven the need

to consider computer security as a core requirement in the

procurement of new equipment.

IAEA

NSS 17 – Vendor Access Control

• It is essential that the level of security of any third party and vendors is taken

into account. It is paramount that the security department works closely with the

contracts department to ensure that the security provisions are incorporated in

each contract.

• Contracts are often awarded to external entities by organizations in the nuclear

industry; some of these contracts will entail the contracting companies holding

protectively marked information or assets on their own premises. Unless the

award of such a contract and its subsequent management follow stringent rules,

the protectively marked information and assets associated with the contract

could risk compromise or unauthorized disclosure.

• In view of the above factors, it is important that the responsible management of

each site/organization in the nuclear industry maintain a close working

relationship with the contracting company in order to ensure that essential

security aspects are addressed throughout the development and

implementation of the contract, and during final handover.

IAEA

NST036 – I&C Technical Guidance

• Nuclear I&C designers have robust processes in place to

ensure systems provide for safe, reliable, and deterministic

behavior.

• NST036 aims to overlay security

considerations on top of these

processes to meet safety and

security objectives.

• Developed in tandem with

DS-431 IAEA Safety Guide for

I&C Systems.

34

IAEA

NST036 – Guidance for I&C Vendors

i. Vendor and sub-vendor organizations should have robust and verifiable computer

security processes.

ii. Computer security requirements and controls should be met and applied respectively by

vendors including support provided on site, at the vendor’s workplace, and during any

transit or storage of purchased goods.

iii. The vendor should have a computer security management process.

iv. The applicable requirements for computer security at sites where a vendor performs

activities with I&C systems should be clearly and contractually specified based on

security level by the operator.

v. A process should exist between the facility (i.e. operators) and vendor for either

organization to report vulnerabilities and to coordinate response and mitigation efforts.

vi. The vendor should demonstrate that they have a credible mechanism for receiving

reports of vulnerabilities, assessing them and reporting them to the nuclear facility during

the entire period of their contractual service. This may extend beyond any normal

warranty period to support the life cycle of the installed equipment.

vii. Audits and assessment of vendors responsible for I&C design, development, integration,

and maintenance should be conducted and the results reported to the operator.

IAEA

Lifecycle Considerations

• ~200 Considerations

divided amongst all

lifecycle phases.

• High level statements

that allow for flexibility

in implementation.

• ~50 considerations are

applicable directly to

vendors or

procurement of I&C

systems

IAEA

Questions?

37

Michael T. Rowland

Nuclear Security Information Officer

International Atomic Energy Agency

Vienna International Centre

A-1400 Wien

Austria

Tel: +43 (1) 2600-26073

Fax: +43 (1) 2600-29299

Email: M.T.Rowland@iaea.org