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 SCADA Network
Provides overall monitoring and control SCADA system
Provides communication between SCADA master and RTUs Local process controllers that are commanded by SCADA masters Can perform simple logic-based or PID control Provide means of measuring infrastructure parameters and adjusting them

Remote Terminal Units (RTUs)

Sensors and Actuators

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:
Remote access:

Needs to be easily reconfigurable to test new control schemes, attack scenarios, solutions

Accurate modeling:

Should be available to remote users

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 smallscale experimentation and education Allows desktop and portable realization
What is simulated? Plant Network Controller Tool used (example) Simulink/Stateflow Omnet++, NS-2, OPNET, Simulink/Stateflow

A Generic Scenario
Matlab/Simulink

Simulation: Controller Model Sensor data stream

Omnet++

Actuator data stream

Simulation: Network model

Sensor data stream

Actuator data stream

Simulation: Plant Model

Matlab/Simulink

Integration Problems
Integrating models
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.

C2 Wind Tunnel Project*: Challenges for Model and Simulation Integration

Organization/Coordination Controller/Vehicle Dynamics Processing (Tracking) 3-D Environment (Sensors)

SL/SF CPN
Adaptive Human Organization Mixed Initiative Controller Context Dep. Command Interpretation Adaptive Resource Allocation
HCI Abstract Commands Platform Commands

Devs Delta3D
Assigned Platform Commands

How can we integrate the models? How can we integrate the simulated heterogeneous system components? Decision Coordination Support How can we integrate the simulation engines?
COP Elements COP Elements COP Elements Platform Status

Data Distribution Network Model-Integrated System and Software Laboratory Environment: C2 Windtunnel

GME
Simulation Interaction Simulation Architecture

GME

* Human Centric Design Environments for Command and Control Systems: The C2 Wind Tunnel, AFOSR PRET: VU, GMU, UCB, UA

OMNET
Network Architecture

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 Key idea: Integration is about interactions across system components. We model the interactions and use these models to facilitate model and system integration.

DoD/HLA was chosen as the base run-time integration platform. C2WT additions:

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.

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

Models: Integration and Deployment

Interactions (message types)

Federates (simulators)

Experiment

Host node

Using the C2W Integration Models

C2W integration models (data flow, timing, parameters) configuration
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)

Domain specific C2W simulation components OMNET component Simulink component CPN component Delta3D component

C2W modeling environment

C2W Data models (interaction and object models) transformation

Domain specific simulation 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

Omnet models
Simulink models

CPN models

C2WT Integration Platform

Domain specific models
Simulink Models -Dynamic simulator

Reusable C2W integration simulators

Simulink Integration Federate

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 Output binding

Code generation

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

Challenges of integration
Time management (replace Omnet++ scheduler) Scalability (avoid overloading the RTI bus but capture interesting behavior) 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

Provides a set protocols with HLA mapping

Configuration
Network topology Detailed parameters of full network stack Experimentation modules
Attack models (flood, DOS attack)

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

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