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

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

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

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

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

6. Typical SCADA Architectures

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23. Example: Simulation start

24. Example: Network attack starts

25. Example: Network attack stops

26. Example: Scenario ends

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

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