TRUST for SCADA: A Simulation-based Experimental Platform

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

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

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

15. C2 Wind Tunnel Project*:Challenges for Model and Simulation Integration Processing (Tracking) 3-D Environment (Sensors) Adaptive Human Organization Mixed Initiative Controller Context Dep. Command Interpretation Adaptive Resource Allocation Controller/Vehicle Dynamics Organization/Coordination Assigned Platform Commands HCI Platform Commands Abstract Commands CPN Devs Coordination Decision Support SL/SF Platform Status COP Elements COP Elements COP Elements How can we integrate the models? How can we integrate the simulated heterogeneous system components? How can we integrate the simulation engines? Data Distribution Network Model-Integrated System and Software Laboratory Environment: C2 Windtunnel GME Delta3D GME Simulation Interaction Simulation Architecture OMNET * Human Centric Design Environments for Command and Control Systems: The C2 Wind Tunnel, AFOSR PRET: VU, GMU, UCB, UA Network Architecture

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) CPN component OMNET 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 CPN models Omnet 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. 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) Omnet++ integration(Network simulation) … # 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 --