TRUST for SCADA:A Simulation-based Experimental

PlatformAndrew Davis, Gabor Karsai, Himanshu Neema

Vanderbilt UniversityAnnarita 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 RequirementsModularity:

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, solutionsRemote access:

Should be available to remote usersAccurate 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 Simulink/Stateflow

A Generic Scenario

Simulation: Plant Model

Simulation: Network model

Actuator data stream

Simulation: Controller Model

Omnet++

Sensor data stream

Matlab/Simulink

Matlab/Simulink

Actuator data stream

Sensor data stream

?

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.

Adaptive Human

Organization

MixedInitiative

Controller

Context Dep.Command

Interpretation

AdaptiveResourceAllocation

Data Distribution Network

Coordination Decision Support

HCI AbstractCommands

PlatformCommands

AssignedPlatform

Commands

PlatformStatus

COPElements

COPElements

COPElements

Model-Integrated System and Software Laboratory Environment: C2 Windtunnel

CPN

Organization/Coordination Controller/Vehicle Dynamics

Devs

Processing (Tracking)

Delta3D

3-D Environment (Sensors)

GME GMESimulation Interaction Simulation Architecture

OMNETNetwork Architecture

SL/SF

How can we integrate the models?How can we integrate the simulated heterogeneous system components?How can we integrate the simulation engines?

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

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

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

C2W Data models(interaction and object models)

Omnetmodels

Domain specific simulation models

CPN models

Simulink models …

transformation

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

C2W integration models(data flow, timing, parameters)

Domain specific C2W simulation componentsconfiguration

OMNETcomponent

CPN component

Simulink component

Delta3Dcomponent

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 m

odeling environment

HLA Run-Time Infrastructure

(RTI)

Simulink Integration

Federate

Colored Petri Net Integration

Federate

Omnet Discrete Event Simulation

Integration Federate

3D Visual SensorSimulatorFederate

(Delta3D, GoogleEarth)

Simulink Models- Dynamic simulator

Colored Petri Net Models

Network models

Physical worldmodels

Domain specific models

Reusable C2W integrationsimulators

Integration models

C2WT Integration Platform

Simulink model integration (Plant and Controller Dynamics)

Original model

Modified model

Add input-output bindings

GME integration model

Generated .m Receiver and SenderS-function code

+Java code for representing

Simulink federate

HLA Run-Time Infrastructure (RTI)

Code generation

RTI runtime communication

Output bindingInput binding

Signal flow Signal flow

Omnet++ integration(Network simulation)

NetworkSim

sender

receiver

frame_rate

frame_size

sending

playing

delay

frame_loss

last_received_f

Stream

Send

reilable_send : boolean

Receive

send_interaction_id : int

• 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

C o n t r o l l e r

P l a n t

P r o c e s s M o d e l

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