procurement of software and digital equipment international atomic energy agency procurement of...
TRANSCRIPT
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: [email protected]