Threats to Software Security Integrated with the Safety

Download Report

Transcript Threats to Software Security Integrated with the Safety

Threats to Software Security
Integrated with the Safety Planning
Process
Phil Cooke
Battlespace Management - Safety Policy
Royal Air Force
Contents
•
•
•
•
•
•
•
Introduction
Stuxnet – the first of many
Latest ‘Mask’ Malware
A Need to Do More
Safety vs Security, Failure vs Attack
Attack Trees and Guide Words
Simple Case Studies
Safety in the Traditional Sense
• FSSE – Nature of accidents
– Flixborough 1974
• Health and Safety at Work etc Act 1974
Safety in the Traditional Sense
• FSSE – Nature of accidents
– Challenger 1986
• Leakage issue on previous flights
Safety in the Traditional Sense
• FSSE – Nature of accidents
– Bexley 1997
• Maintenance issues,
Overloading wagons and excess
speed
Background and Motivation
• Pervious working environment
• Stuxnet Virus 2009/2010
• Interest in Supervisory Control and Data Acquisition
(SCADA) systems including Programmable Logic
Controllers (PLCs)
• New Role working in ATM environment
• Desire to combine knowledge of Security and Safety as
little exists on this subject
Stuxnet – The First (?) of Many (?)
• Virus discovered in Jun 2010, origin back in Jun 09
• Targets a very specific hardware/software configuration
at Natanz, Iran – Uranium reprocessing facility
• Executes by re-programming the PLC out of specified
boundaries
• Virus deployed via USB pen drive on maintenance laptop
• Duqu discovered in Sep 11 thought to be connected to
Stuxnet
• Flame discovered in May 2012 thought to be connected
to Stuxnet
Stuxnet 0.5
• Stuxnet 1.0 discovered in Jun 2010
• Variants later discovered but traced back as early as Nov
2007 and development as early as 2005
• Similar attack vector but closed valves instead of
changing the rotation speed of centrifuges
• More versions known to exist but code has never been
recovered
• Many other SCADA systems vulnerable to attack
RAS Gas computer
systems taken off line
days after a similar attack
on Aramco (Aug 12)
Saudi Arabia’s national oil
company was attacked by
the Shamoon virus, which
targets energy sector
infrastructure (Aug 12)
Mask Malware
• Aimed at Gov’ts and Finance Firms
• Probably created by a Nation State
• Reported by Kaspersky/BBC
Technology website on 11 Feb 2014
• Involved in cyber espionage
operations since at least 2007
• Ahead of Duqu in terms of
sophistication
• Is this just the tip of the Iceberg?
How Skilled Do You Need To Be?
A Need to Do More
• Security and Safety need to be considered as a unity of
specialisations and not just bolt-on’s to each other.
• Similarities with Safety a number of years ago?
• Develop a methodology to integrate security aspects into
the safety analysis process
• Cross domain applicability
• Ability to apply at any stage of the safety lifecycle to
capture legacy projects
Safety vs Security, Failure vs Attack
• Systems need to operate in a safe manner
• Systems need to be maintainable by many different and
disparate parties
• Systems need to fail safe
• Systems need to be resilient and resistant to attack
What Previously Existed
• Security Processes or Tools
– Casals et al, 2012
– 6 Step Process
• 1st 3 Steps considered and
developed
– Context establishment
– Preliminary Risk Assessment
– Vulnerability Assessment
What Previously Existed
• Attack Trees
– Schneier, 1999
– Used within the US DoD Defense Acquisition Guidebook (US
DoD 2012)
• Simple example is an activity such as trying to open or
break into a safe.
• Helpful to have Guide Words to assist in the process
Open safe
Pick lock
Learn
combination
Find written
combination
Threaten
Cut open safe
Install
improperly
Get
combination
from target
Blackmail
Eavesdrop
Listen to
conversation
Get target to
state
combination
Bribe
Log in to UNIX
account
No password
required
Learn
password
Find written
password
Threaten
Guess
password
Use widely
known
passwords
Get password
from target
Blackmail
Steal
Install
keyboard
sniffer
Bribe
Obtain sniffer
output file
Log in to UNIX
account
Open safe
Pick lock
Learn
combination
Find written
combination
Threaten
Cut open safe
Install
improperly
Get
combination
from target
Blackmail
Learn
password
Find written
password
Eavesdrop
Listen to
conversation
No password
required
Get target to
state
combination
Bribe
Threaten
Guess
password
Use widely
known
passwords
Get password
from target
Blackmail
Steal
Install
keyboard
sniffer
Bribe
Obtain sniffer
output file
Guide (Threat) Words
• Prof McDermott
– Art rather than a Science
• Opdahl and Sindre
– Brainstorming activity
• Use process similar to FHA
– SHARD guidewords – Omission. Commission, Early, Late,
Value
• Look for Threat Words rather than Guide Words
– Configuration, Authentication, Jamming, Replay, Lifecycle
(learning)
Methodology Development
• Context Establishment
Obtain Preliminary
System FTA
Define Threat
Words
Define Initial
Security Context
Develop Attack
Trees to enable
further Context
establishment
• Preliminary Risk Assessment
Identify Primary
Assets
Identify
Threats to
Security
Define Scenarios
affecting Safety
Establish
Likelihood of
Occurrence
• Vulnerability Assessment
Identify Vulnerable
Assets
Identify
Vulnerabilities
Develop
Vulnerabilities
using Attack Trees
Define Severity
of Outcome
Case Study 1 – Implantable Medical
Device
• Devices able to administer medication at varying rates
• Read patients state and report back to a physician
• Remote diagnostic/treatment
– Implantable Cardiac Defibrillators (ICDs)
– Drug Delivery Systems (eg Insulin Pumps)
– Neurostimulators (eg for Parkinson’s Disease)
Context Establishment
• Considers IMDs in general, no FTA
• Threat words:
– Access
– Identification or Privacy
– Configuration
– Authorisation
– Availability
– Distance
– Frequency
– Safety
Context Establishment
• Define Initial Security Context
– Passive or active or coordinated adversaries, Insider attack.
• Active Adversary Attack Tree
Active adversary
interferes with
communications
Has capability to
receive and decode
signals
Passive
adversary
eavesdrops on
signals
Has capability to
transmit signals
Can transmit
correctly encoded
signals
Can transmit
incorrectly encoded
signals
Attempting
malicious
attack
Attempting
DDoS
attack
Preliminary Risk Assessment
• Identify Primary Assets
– IMD, programming devices, management devices
• Identify Threats to Security
– From research, encryption is not used between IMDs and
supporting equipment, however the signalling format could be
spoofed allowing unauthorised transmissions to be sent.
– Devices transmit when a magnet is placed nearby
– Device programmable or readable 24hrs per day?
• Define Scenarios Affecting Safety
– Patient entering a treatment room in a non-local environment
– Important or influential figure fitted with IMD
– Organised Crime gangs seeking to steal device
Preliminary Risk Assessment
• Patient in a non-local environment
IMD requires
authorisation or
authentication
Medical Staff aware,
but unable to
communicate
correctly with IMD
Patient requires
emergency treatment
in a foreign location
Foreign denotes away
from their normal
medical staff
Patient incapacitated
or unable to
communicate
presence of IMD
Medical staff
unaware of IMD
constraints or special
requirements
Medical Staff unable
to get patient history
Medical staff unable
to deactivate IMD to
allow other surgical
procedure
Medical Staff need to
know to scan for
device
Medical staff treat
patient without
knowledge of IMD
Patient harmed by
medication or by IMD
working against
medication
IMD damaged by
medical treatment
Authentication
or encryption prevents
access to IMD
Authentication
or encryption prevents
access to IMD
IMD should
emit tone or vibration
when magnet is placed
nearby
Treatment
could be contra to
IMD medication
requirements
Authentication
or encryption prevents
access to IMD
Authentication
or encryption prevents
access to IMD
Preliminary Risk Assessment
• Establish Likelihood of Occurrence
– As of 2012, no evidence could be found regarding attacks on
IMDs
– Kramer et al, 2012, states “there are no known case reports of
malevolent interference that specifically target medical device
function”
Preliminary Risk Assessment
• Severity of Outcome
– Worst case is death
– Least is possible early failure of device
• Most devices are 5-7 years so replacement is always assumed
necessary at some future point
Vulnerability Assessment
• Identify Vulnerable Assets
– IMD and supporting equipment
• Identify Vulnerabilities
– Replay Attack
– Electromagnetic interference
– Malware on supporting PC
– DoS attack
• Develop Attacks using Attack Trees
Evaluation and Further Work
• IMD use and proliferation is growing
• Technology is outpacing Security, not Safety
– Possibly security through ambiguity
– Stuxnet was directed at 2 specific targets worldwide
• IMDs must have high security but ease of access
• Consider a dual approach – threat in one direction,
vulnerability in the other
Case Study 2 – European Railway Traffic
Management System - ERTMS
• The ERTMS aims to replace the many different national
train control and command systems in Europe with a
standardised system.
• System relies upon the GSM networks.
• A full and complete security audit was performed on the
ERTMS and in précis was:
– The specs from a safety perspective were considered and
safety requirements for technical interoperations were derived
– Consideration of the context in which ERTMS operates and
its trust relationships with other systems
– Both top down and bottom up approaches investigated
– Attack scenarios devised and graded
Context Establishment
• System description available from ERTMS web page
Context Establishment
• Define Threat Words:
– Location
• Balise position
• Cuttings, tunnels, shadowing by other trains
• GPS used as a backup when GSM is lost?
– Access
• Data - system uses cryptography and all users have same key
• Data – GSM-R: Handsets authenticate with the network but not vice
versa
• Physical – some data is entered locally
– Identification
• Each train has a unique identity – spoofing?
• Balises are not physically protected
• GSM repeater could be spoofed and information extracted
Context Establishment
• Define Threat Words:
– Authorisation
• Can the driver override some or all aspects? How is this recorded?
• If GSM-R is the sole source of authorisation, what happens in an
outage?
– Jamming
• Passenger using small GSM jamming device – what effect to ERTMS?
• What precedence is given to GSM-R traffic?
– Etc etc
Context Establishment
• Define Initial Security Context
– What could be gained from attacking the system
– How could the system be attacked?
– What capabilities would the attacker need?
Context Establishment
• Develop Attack Trees
ERTMS open to
security attack
compromising safety
Balise attack
Linked Balise
Position error
Information erorr
Radio Block Centre
attack
Unlinked Balise
Position error
Information erorr
ECTS attack
GSM-R attack
Crypto attack
Network attack
Signal jamming
attack
Software radio attack
Preliminary Risk Assessment
• Identify Primary Assets
– European Train Control System – ETCS
– GSM-R – railway specific system built upon GSM standards
• ETCS
– Onboard
– Trackside
• Balises
• Radio Comms System (GSM-R)
• Radio Block Centres – issue movement authorisations to trains
Preliminary Risk Assessment
• Identify Threats to Security
– 93 page report written on the “ERTMS Specification Security
Audit Analysis of Attack Scenarios” 29 July 2011
– Balise location considered for the remainder of the case study
– Uses standard transmission protocol
– Position or positional data could be affected
– Metallic structures affecting balise signal performance
Preliminary Risk Assessment
• Define Scenarios Affecting Safety
– Reputational/financial attack by an active aggressor but with
limited technical knowledge of the system
– Balise is moved closer to or further away from neighbour thus
changing the reported position of the train or causing an error
signal to be generated
• Establish Likelihood of Occurrence
– Hard to estimate without greater technical knowledge of the
system
Preliminary Risk Assessment
• Define Severity of Outcome
– Also hard to estimate without greater system knowledge
– Train movements would be scheduled to allow for greatest
traffic flow but with sufficient time in-between trains for safety
reasons similar to airport arrival and departure traffic.
– Positional errors would need to be evaluated for different areas.
Busy junctions (Clapham junction) would work with a smaller
error than a remote location with a low density of points
Preliminary Risk Assessment
Non-technological
attacker seeks to
damage reputation or
finances of company
Attack route chosen
is via the balises
Physical access
required to the
trackside and balise
Reprogram
balise
discounted due
to technology
required
Place new balise
Disrupt balise
communications
Obtain balise
from another
area or track
Place conductor
or metallic object
near balise
Reduce distance
between balises
Un-noticed access to
the trackside and
balise
Move balise
Remove balise
completely
Attack performed at
night or during dawn/
dusk periods
Increase
distance
between balises
Mount attack in
tunnel or railway
cutting
Vulnerability Assessment
• Identify Vulnerable Assets
– Large proportion of the system relies on assets outside the
control or standards of the ERTMS
– GSM-R may be adaptable but GSM unlikely
– Balise and programming device
– Driver (always has positive control)
– Network infrastructure
• Remember O2 outage in 2012 where some users affected but not
others?
– Identify Vulnerabilities
• Network Outages
Vulnerability Assessment
• GSM_R Outage Vulnerability
ETRMS susceptible
to Network Outages
Partial Network
outage
Non affected
trains continue to
operate
Network jammed or
intercepted
Total network outage
Attack using
software radio and
software
All
trains using
ERTMS in same
situation
Affected trains
use ‘fail-safe’ and
stop
Evaluation and Further Work
• 3 Aspects considered in Context evaluation
– Why, How, What
• Full Set
– Why, How, What, Where, When, Who
• Generation of a threat word taxonomy
• External systems are vital to operation of the system yet
limited control or authority available
• Partial failures must be considered (O2 Outage)
References
•
•
•
•
•
•
•
•
•
•
ANONYMISED (2010). Information security audit of ERTMS, Technical report. This report is currently not
publicly available; however, copies of the report may be made available on request, subject to approval
from the relevant stakeholders.
ANONYMISED (2011). ERTMS specification security audit – Analysis of attack scenarios, Technical report. This
report is currently not publicly available; however, copies of the report may be made available on request,
subject to approval from the relevant stakeholders.
Casals, S., Owezarski, P. and Descargues, G. (2012). Risk assessment for airworthiness security. Safecomp 2012
[Online]. Available at: http://hal.archives-ouvertes.fr/docs/00/69/85/23/PDF/
Risk_Assessment_for_Airworthiness_Security_8p_.pdf [Accessed 12 June 2012].
Falliere, N., O Murchu, L. and Chien, E. (2011). W32.Stuxnet dossier. [Online] Symantec Security Response.
February 2011. Available at: http://www.symantec.com/content/en/us/enterprise/ media
/security_response/whitepapers/w32_stuxnet_dossier.pdf [Accessed 22 February 2012].
Kramer, D., Baker, M., Ransford, B., Molina-Markham, A., Stewart, Q., Fu, K and Reynolds, M. (2012). Security
and privacy qualities of medical devices: An analysis of FDA postmarket surveillance. PLoS One, 7(7), e40200.
doi:10.1371/journal.pone.0040200
McDermott, J. (2000). Attack net penetration testing. New Security Paradigms Workshop 2000.
McDonald, G., Murchu, L., Doherty, S., Chien, E., (2013). Stuxnet 0.5: The Missing Link. [Online] Symantec
Security Response. February 2013. Available at: http://www.symantec.com/content/en/us/enterprise/media/
security_response/whitepapers/stuxnet_0_5_the_missing_link.pdf [Accessed 20 February 2014].
Opdahl, A. and Sindre, G. (2008). Experimental comparison of attack trees and misuse cases for security threat
identification. Information and Software Technology, 51(5), 916-932.
Schneier, B. Attack Trees. [Online]. Dr Dobbs Journal, December 1999. Available at:
http://www.schneier.com/paper-attacktrees-ddj-ft.html [Accessed 1 July 2012].
US DoD (2012). Defense Acquisition Guidebook. [Online]. Available at: http://at.dod.mil/docs/
DefenseAcquisitionGuidebook.pdf [Accessed 1 July 2012].