Post on 14-Dec-2015
transcript
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
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
Outline
• SCADA Systems and Security• The TRUST-SCADA Experimental Testbed• A New Implementation• Future Directions