A Testbed for Secure and Robust SCADA systems

1. 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

2. Outline • SCADA systems • Vulnerabilities • Motivation • Testbed plan • Current status • Future directions

3. 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

4. Typical SCADA System

5. SCADA Architecture

6. 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.

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. Notional SCADA Architecture Corporate Infrastructure SCADA Master SCADA Master Supervisory control layer Communication infrastructure Network Signal management, local control loops RTU RTU RTU Sensor Actuator Sensor Actuator Sensor Actuator Physical plant with sensors and actuators Plant

16. 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 Network Real/Simulated/Emulated ns-2, Omnet++, Emulab Ethernet/Wi-Fi/Radio RTU RTU RTU MicroSys/Gumstix/Honeywell/GE Wired/Wireless (802.11/802.15.4) Sensor Actuator Sensor Actuator Sensor Actuator MICAz/Firefly/Robostix Plant Physical/Simulated

17. Development Phases

18. 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

19. SCADA Testbed Implemented in Hardware Reference Architecture Hardware Implementation

20. Physical modeling • Chemical Plant modeling (Simulink)

21. 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)

22. 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

23. Software Based Attestation Challenge Checksum of memory • 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 Embedded device External Verifier Device memory

24. 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]

25. 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