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 smallscale 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
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.
• 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
Processing (Tracking)
Controller/Vehicle Dynamics
Organization/Coordination
3-D Environment (Sensors)
SL/SF
CPN
Adaptive
Human
Organization
Mixed
Initiative
Controller
Context Dep.
Command
Interpretation
Adaptive
Resource
Allocation
Devs Delta3D
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?
Abstract
Commands
HCI
COP
Elements
COP
Elements
Assigned
Platform
Commands
Platform
Commands
COP
Elements
Platform
Status
Data Distribution Network
Model-Integrated System and Software Laboratory Environment: C2 Windtunnel
GME
Simulation Interaction
GME
Simulation Architecture
* 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.
– 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
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
C2W modeling environment
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 Data models
(interaction and object 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
Domain specific
C2W simulation components
OMNET
component
CPN
component
Simulink
component
Delta3D
component
Domain specific
simulation models
Omnet
models
CPN
models
Simulink
models
…
C2WT Integration Platform
Domain specific
models
Reusable C2W integration
simulators
Simulink Models
-Dynamic simulator
Simulink
Integration
Federate
Colored Petri Net
Models
Colored Petri Net
Integration
Federate
Network models
Omnet Discrete
Event Simulation
Integration
Federate
Physical world
models
3D Visual Sensor
Simulator
Federate
(Delta3D, GoogleEarth)
HLA Run-Time
Infrastructure
(RTI)
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)
•
•
•
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
•
•
•
•
•
Faithful model of the full network protocol stack
Probabilistic model for physical layer
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
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 --