TRUST for SCADA:

homuskratΔίκτυα και Επικοινωνίες

20 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

98 εμφανίσεις

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?


S
upervisory
C
ontrol
A
nd
D
ata
A
cquisition
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 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

Mixed

Initiative

Controller

Context Dep.

Command

Interpretation

Adaptive

Resource

Allocation

Data Distribution Network

Coordination

Decision

Support

HCI

Abstract

Commands

Platform

Commands

Assigned

Platform

Commands

Platform

Status

COP

Elements

COP

Elements

COP

Elements

Model
-
Integrated System and Software Laboratory Environment:
C2 Windtunnel



CPN

Organization/Coordination

Controller/Vehicle Dynamics

Devs

Processing (Tracking)

Delta3D

3
-
D Environment (Sensors)

GME

GME

Simulation Interaction

Simulation Architecture

OMNET

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

Omnet

models

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 components

configuration

OMNET

component

CPN


component

Simulink


component

Delta3D

component

Based on C2W
T

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

HLA Run
-
Time

Infrastructure

(RTI)

Simulink

Integration

Federate

Colored Petri Net

Integration

Federate

Omnet Discrete

Event Simulation

Integration

Federate

3D Visual Sensor

Simulator

Federate

(Delta3D, GoogleEarth)

Simulink Models

-
Dynamic
simulator

Colored Petri Net

Models

Network models

Physical world

models

Domain specific

models

Reusable C2W integration

simulators

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 Sender

S
-
function code

+

Java code
for representing

Simulink federate

HLA Run
-
Time Infrastructure (RTI)

Code generation

RTI runtime
communication

Output binding

Input binding

Signal flow

Signal flow

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



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