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: – 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.

December 2000– Electric Power Servers are Hijacked to Host and Play Games

June 2001– 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– Secure office building– Barbed wire perimeter– Guards

Remote devices much less secure– 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

Processes Network architectures Communications topologies and media

Reconfigurability:– Needs to be easily reconfigurable to test new

attack scenarios, solutions Remote access:

– 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

Corporate Infrastructure

Plant

Actuator Sensor Actuator ActuatorSensorSensor

RTU RTU RTU

Network

SCADA Master SCADA Master

Notional SCADA Architecture

Physical plant with sensors and actuators

Signal management, local control loops

Communication infrastructure

Supervisory control layer

Corporate Infrastructure

Plant

Actuator Sensor Actuator ActuatorSensorSensor

RTU RTU RTU

Network

SCADA Master SCADA Master

Wired/Wireless (802.11/802.15.4)

Ethernet/Wi-Fi/Radio

Ethernet/Wi-Fi/Radio

Wired/Wireless (802.11/802.15.4)

Physical/Simulated

MicroSys/Gumstix/Honeywell/GE

MICAz/Firefly/Robostix

Real/Simulated/Emulatedns-2, Omnet++, Emulab

Standard DesktopSoftware: Commercial, Simulink, Ptolemy II

SCADA Architecture TestbedImplementation variants

Development Phases

Homogeneous Simulation• Pure

Simulink

Heterogeneous Simulation• 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

ExternalVerifier

Embeddeddevice

Challenge

Checksum of memory Devicememory

`

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