TRUST for SCADA: A Simulation-based Experimental Platform Andrew Davis, Gabor Karsai, Himanshu Neema Vanderbilt University Annarita Giani, UC Berkeley Bruno Sinopoli, Rohan Chabukswar, Carnegie Mellon University

Outline SCADA Systems and Security The TRUST-SCADA Experimental Testbed A New Implementation Future Directions

Outline SCADA Systems and Security The TRUST-SCADA Experimental Testbed A New Implementation Future Directions

What is SCADA? Supervisory Control And Data Acquisition systems are computer-based monitoring tools that are used to manage and control critical infrastructure functions in real time. Control Gas Utilities, Power Plants, Oil Refineries, Power Utilities, Chemical Plants, Water Management, Traffic Control Systems, etc.

Typical SCADA Hardware Elements SCADA Master Provides overall monitoring and control SCADA system SCADA Network Provides communication between SCADA master and RTUs Remote Terminal Units (RTUs) Local process controllers that are commanded by SCADA masters Can perform simple logic-based or PID control Sensors and Actuators Provide means of measuring infrastructure parameters and adjusting them

Typical SCADA Architectures

SCADA Systems Security Issues SCADA systems have decade-long lifetimes Most were designed without security considerations SCADA systems today are connected to the Internet Network security problems may impact plant operations SCADA systems are difficult to upgrade Adding security features often means downtime Devices contain embedded computing components Networks are customized for specific systems Need flexible, robust solutions that secure legacy SCADA systems and shape the design of the next

Outline SCADA Systems and Security Goals and Requirements for a TRUST-SCADA Experimental Testbed A New Implementation Future Directions

SCADA Testbed Goals To assess vulnerabilities of current SCADA implementations in realistic settings To provide and test solutions to address such vulnerabilities To test innovative architectural and technological solutions for next generation SCADA To provide an open-source design for an affordable, and highly flexible testbed for the TRUST community

SCADA Testbed Requirements Modularity: Must be able to model several SCADA elements Processes (‘plants’) Network architectures Communications topologies, media, and protocols Reconfigurability: Needs to be easily reconfigurable to test new control schemes, attack scenarios, solutions Remote access: Should be available to remote users Accurate modeling: Should be a realistic model of a real world process

Outline SCADA Systems and Security The TRUST-SCADA Experimental Testbed A New Implementation Future Directions

A New Implementation Simulation: An inexpensive and affordable approach for small-scale experimentation and education Allows desktop and portable realization What is simulated? Tool used (example) Plant Simulink/Stateflow Network Omnet++, NS-2, OPNET, … Controller

A Generic Scenario ? Simulation: Controller Model Sensor data stream Matlab/Simulink Simulation: Controller Model ? Sensor data stream Actuator data stream Omnet++ Simulation: Network model Sensor data stream Actuator data stream Simulation: Plant Model Matlab/Simulink

Integration Problems Integrating models Integrating the system Heterogeneous modeling for different domains: plant models, network models, controller models, etc. Needed: an overarching integration model that connects and relates the heterogeneous domain models in a logically coherent framework. Integrating the system Heterogeneous simulators and emulators for different domains: OMNET++, Simulink/Stateflow, EMULAB, etc. Needed: an underlying software infrastructure that connects and relates the heterogeneous simulators in a logically and temporally coherent framework. Key idea: Integration is about interactions across system components. We model the interactions and use these models to facilitate model and system integration.

Data Distribution Network C2WT Demonstration 10/8/08 C2 Wind Tunnel Project*: Challenges for Model and Simulation Integration Organization/Coordination Controller/Vehicle Dynamics Devs Processing (Tracking) Delta3D 3-D Environment (Sensors) CPN SL/SF Adaptive Human Organization Mixed Initiative Controller Context Dep. Command Interpretation Resource Allocation Data Distribution Network Coordination Decision Support HCI Abstract Commands Platform Assigned Status COP Elements Model-Integrated System and Software Laboratory Environment: C2 Windtunnel How can we integrate the models? How can we integrate the simulated heterogeneous system components? How can we integrate the simulation engines? GME Simulation Interaction Simulation Architecture OMNET Network Architecture * Human Centric Design Environments for Command and Control Systems: The C2 Wind Tunnel, AFOSR PRET: VU, GMU, UCB, UA Barksdale AFB

C2W Integration Solution Goals to provide an environment to integrate and execute heterogeneous domain specific simulation models or ‘real’ system components to support easy configuration and evaluation of scenarios DoD/HLA was chosen as the base run-time integration platform. Rationale: HLA was designed as a simulation integration platform and it provides services for run-time integration of large simulators. Has sophisticated support for coordination among simulation engines. C2WT additions: Model based integration of domain specific simulation models (Simulink, Omnet++, etc) Data models Integration models Transformation (import, export, code generation) Support for execution of domain specific models Runtime execution engines Key idea: Integration is about interactions across system components. We model the interactions and use these models to facilitate model and system integration.

Models: Integration and Deployment Interactions (message types) Federates (simulators) Experiment Host node

Using the C2W Integration Models Domain specific C2W simulation components configuration C2W integration models (data flow, timing, parameters) OMNET component CPN component Based on C2WT models configuration files are generated for the various simulation components. Configure how the component is connected to the simulation (input-output binding) C2W modeling environment Simulink component Delta3D component C2W Data models (interaction and object models) Domain specific simulation models transformation Omnet models CPN models Federates have to have a common data model to be able to share data. Data model can be imported from domain specific models Domain specific models can be generated from data models Simulink models …

C2WT Integration Platform Domain specific models Reusable C2W integration simulators Simulink Models Dynamic simulator Simulink Integration Federate Integration models Colored Petri Net Models Colored Petri Net Integration Federate HLA Run-Time Infrastructure (RTI) Network models Omnet Discrete Event Simulation Integration Federate Physical world models 3D Visual Sensor Simulator Federate (Delta3D, GoogleEarth)

Simulink model integration (Plant and Controller Dynamics) Original model GME integration model Add input-output bindings Input binding Code generation Output binding Modified model Generated .m Receiver and Sender S-function code + Java code for representing Simulink federate RTI runtime communication Signal flow Signal flow HLA Run-Time Infrastructure (RTI)

Omnet++ integration (Network simulation) Simulates communication network Omnet++, INet packages Omnet is a generic discrete event simulation package (module specification with .ned files, implementation in c++, modular, customizable plug-in architecture) Inet: network protocols for omnet (ip, wireless, etc) Faithful model of the full network protocol stack Probabilistic model for physical layer Challenges of integration Time management (replace Omnet++ scheduler) Scalability (avoid overloading the RTI bus but capture interesting behavior) Provides a set protocols with HLA mapping Heavy message traffic kept inside Omnet++ High level application layer interface provided for HLA (light message traffic) Protocols Reliable message send (tcp) Best effort message send (udp) Streaming (udp, e.g.: video streaming) Network intercepts Configuration Network topology Detailed parameters of full network stack Experimentation modules Attack models (flood, DOS attack) … # uavs **.uav[*].udpAppType="StreamingUDPApp" **.uav[*].udpApp[*].local_port=6000 **.uav[*].udpApp[*].dest_port=6000 **.uav[*].udpApp[*].buffer_size = -1 **.uav[*].udpApp[*].lost_frame_update_rate = 4

Early Results Prototype TRUST SCADA-SIM Testbed that includes: Simulink/Stateflow for plant and controller modeling & simulation Omnet++ for network modeling & simulation Example experiment built using the testbed: Simulink model for chemical process plant (Tennessee Eastman) Simulink model for robust controller Omnet++ model for network and DDOS network attack Process Model Controller Plant

Example: Simulation start

Example: Network attack starts

Example: Network attack stops

Example: Scenario ends

Outline SCADA Systems and Security The TRUST-SCADA Experimental Testbed A New Implementation Future Directions

Future Directions Develop more experiment scenarios and evaluate testbed Develop more security attack models Package TRUST-SCADA/Sim in a distributable form for use by other researchers -- Demo --