A Testbed for Secure and Robust
SCADA systems
Annarita Giani*, Gabor Karsai^, Tanya Roosta*,
Aakash Shah†, Bruno Sinopoli†, Janos Stipanovitz^,
Jon Wiley^
*UC Berkeley
^Vanderbilt University
†Carnegie Mellon University
Outline






SCADA systems
Vulnerabilities
Motivation
Testbed plan
Current status
Future directions
What is SCADA?



Supervisory Control And Data Acquisition
(SCADA) systems are computer-based monitoring
tools that are used to manage and control critical
infrastructure functions, such as the transmission and
distribution of electricity, pressure and proper flow of
gas pipelines, water treatment and distribution,
wastewater collection, chemical processing and
railway transportation systems control, in real time.
Used by utilities such as electric, gas, water, oil and
waste water
Monitor and control remote field devices
–
–

e.g. sensors for pressure, flow, temperature
e.g. valves, breakers
Considered critical infrastructure
Typical SCADA System
SCADA Architecture
SCADA Security Trends

SCADA networks increasingly being connected to corporate
infrastructure
–





In some cases, directly connected to Internet
Simpler attack vectors for attacker
Malware – SCADA systems are vulnerable to various forms of malware,
including worms, viruses, Trojans and spyware.
Insider – This internal threat can be accidental or intentional; however,
the latter is the greater threat and is commonly referred to as the
“disgruntled employee” scenario, where a knowledgeable insider may
be motivated to damage or corrupt the system.
Hacker – This is the outsider who is interested in probing and breaking
into a SCADA system because of the challenge it presents.
Cyber Terrorists – A SCADA system is a very appealing attack target
for a well-funded terrorist group that seeks to cause widespread
damage to a large portion of the population.
Security attacks on SCADA

Spring 2000:
–

December 2000
–

Electric Power Servers are Hijacked to Host and Play Games
June 2001
–

A former employee of an Australian industrial software
company used a radio transmitter to remotely hack into the
controls of a sewage treatment system at Maroochy Shire,
Queensland, and release approximately 264,000 gallons of
raw sewage into nearby rivers.
Cal-ISO is Attacked and Compromised for 17 Days
January 2003
–
First Energy hit by Slammer Worm:
the Slammer worm penetrated a private computer network at
Ohio's Davis-Besse nuclear power plant in January and
disabled a safety monitoring system for nearly five hours
SCADA Physical Security

SCADA Master located at secure facility
–
–
–

Remote devices much less secure
–

Secure office building
Barbed wire perimeter
Guards
In most cases, just a padlock
Communications links are unprotected
–
–
Leased lines, dialup, radio, private WAN, satellite
…
Outside of utility control
SCADA Communications Security

Poor
–
–

Communications in the clear (including passwords)
Nonexistent or poor authentication
Instead, relies on:
–
–
–
–
Obscurity of communications protocol
Difficulty of tapping a private leased line
Secrecy of dial-up ports
Use of licensed and/or spread spectrum
SCADA Operating Environment

SCADA systems
–
–
–
–

are environmentally hardened and have significant
lifetimes
have software and hardware designed without
security in mind
have limited resources (memory and processing
power)
constitute a significant investment on the part of
utilities
Need solutions that secure legacy SCADA
systems and shape the design of the next
generation
A SCADA Testbed: Motivation




Assess vulnerabilities of current SCADA
implementations
Provide and test solutions to address such
vulnerabilities
Test innovative architectural and technological
solutions for next generation SCADA
Provide a common testbed for TRUST
researchers
SCADA Testbed Requirements

Modularity:
–
Must be able to model several SCADA




Reconfigurability:
–

Needs to be easily reconfigurable to test new
attack scenarios, solutions
Remote access:
–

Processes
Network architectures
Communications topologies and media
Should be available to remote users
Accurate modeling:
–
Should be a realistic model of a real world process
SCADA Testbed Requirements

Simulate large network with few hardware
devices
–
e.g. simulate 100 RTUs in software


When testing the attack always connect to real hardware
Software
–
–
Need representative software to model the master
control station appropriately
Need integrated development environments to
reprogram RTUs
SCADA Testbed Requirements

Hardware
–
Need representative hardware for control center
devices and RTUs

–
–
–
May need duplicate equipment to model a distributed
infrastructure including backup topologies
Need various communications equipment to model
various communications media
Need standard networking equipment such as
routers, switches etc.
Need servers to model corporate infrastructure
Notional SCADA
Architecture
Corporate Infrastructure
SCADA Master
SCADA Master
Communication
infrastructure
Network
RTU
Sensor
Actuator
RTU
Sensor
Actuator
Plant
Supervisory
control layer
RTU
Sensor
Actuator
Signal management,
local control loops
Physical plant with
sensors and actuators
SCADA Architecture Testbed
Implementation variants
Corporate Infrastructure
Wired/Wireless (802.11/802.15.4)
SCADA Master
SCADA Master
Standard Desktop
Software: Commercial,
Simulink, Ptolemy II
Ethernet/Wi-Fi/Radio
Real/Simulated/Emulated
ns-2, Omnet++, Emulab
Network
Ethernet/Wi-Fi/Radio
RTU
RTU
RTU
MicroSys/Gumstix/Honeywell/GE
Wired/Wireless (802.11/802.15.4)
Sensor
Actuator
Sensor
Actuator
Plant
Sensor
Actuator
MICAz/Firefly/Robostix
Physical/Simulated
Development Phases
Homogeneous
Simulation
Heterogeneous
Simulation
• Pure Simulink
• Integration
through HLA
‘Real’
Hardware
HLA (High Level Architecture)


Provides an interface specification for
simulators
Simulators with HLA interfaces can interact
through the RTI (Run-Time Infrastructure),
allowing for federated simulation
SCADA Testbed Implemented in Hardware
Reference Architecture
Hardware Implementation
Physical modeling

Chemical Plant modeling (Simulink)
RTU and Sensor/Actuator Emulation in Hardware
Implementation

Vertex processors run the ‘SCADA code’

Gumstix emulate the RTUs

Real RTUs

Wireless Sensor Networks
(Firefly nodes)
Status of the project




Proposal submitted to TRUST for FY 2008
Development of Simulink modules
Building HW/SW architecture
Developing software-based schemes to
guarantee trustworthiness of software
Software Based Attestation


External, trusted verifier knows expected
memory content of device
Verifier sends challenge to untrusted device
–

Assumption: attacker has full control over device’s
memory before check
Device returns memory checksum, assures
verifier of memory correctness
Challenge
`
External
Verifier
Checksum of memory
Embedded
device
Device
memory
Software Based Schemes


Goal: provide security guarantees on legacy device without
any trusted hardware
Projects
– SWATT: Software-based attestation, with Arvind
Seshadri, Leendert van Doorn, and Pradeep Khosla
[IEEE S&P 2004]
– SCUBA: Secure Code Update By Attestation in Sensor
Networks, with Arvind Seshadri, Mark Luk, Adrian
Perrig, Leendert van Doorn and Pradeep Khosla [WiSe
‘06]
– Pioneer: Untampered code execution on legacy hosts,
with Arvind Seshadri, Mark Luk, Elaine Shi, Leendert
van Doorn, and Pradeep Khosla [SOSP 2005]
Conclusions and Future Work





Modular SCADA testbed development
Expose the vulnerabilities of current SCADA
Test solutions to address current
vulnerabilities
Test new architectural solutions
Engage with the wider TRUST community