A Testbed for Secure and Robust SCADA systems Annarita Giani*, Gabor Karsai^, Tanya Roosta*, Aakash...
-
Upload
bertram-jonas-banks -
Category
Documents
-
view
219 -
download
0
Transcript of A Testbed for Secure and Robust SCADA systems Annarita Giani*, Gabor Karsai^, Tanya Roosta*, Aakash...
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