The Industrial IoT depends on connectivity and information exchange. Much of the business value derives from the ability to have independent systems share information in order to derive knowledge, make "smart decisions", and offer behavior and functionality never before possible.
Many industrial systems were designed with a focus on reliability and safety at a time were implicit trust of all components and communication was the norm. Restricting physical access is currently the only practical method for protecting this existing critical infrastructure. This includes the electrical power grid, process control, transportation, or manufacturing systems. This is changing with increased connectivity to the Internet and personal computers as well as awareness of malicious insider threats. Many industrial systems are being (or want to be) connected to external networks using standard technologies like Ethernet and the Internet Protocol Suite (TCP/UDP/IP). These technologies make systems more functional and efficient, unfortunately they also open the critical infrastructure to cyber attacks.
New IIoT Systems are being designed with security as a key concern. New systems can leverage a solid set of security technologies and building blocks for Authentication, Cryptography, Integrity, etc. However these security technologies must be used correctly and in ways that do not disrupt the performance or access to the legitimate applications/devices, yet limit legitimate access to just the needed information (to minimize the insider threats) and denies access to all others. Adding to this difficulties the new systems need to co-exist and (securely) exchange information with the already-deployed legacy systems which were built without such security elements.
Secure DDS (a recent standard from the OMG) is a "secure connectivity middleware" technology that can be used to address these three needs: (1) Build modern secure IIoT systems, (2) Secure legacy Industrial systems being connected on the Internet, and (3) Securely bridge between new and legacy systems. Secure DDS extends the proven Data-Distribution Service (DDS) and Real-Time Publish-Subscribe Protocol (DDS-RTPS) standards with enterprise-grade authentication, encryption and fine-grained security controls while maintaining the peer-to-peer, robustness and scalability features (including secure multicast) that have made DDS a clear choice for critical infrastructure systems.
This presentation introduces the DDS Security specification and provide describe several use-cases that exemplify how these standards are deployed in real-world applications.
Using DDS to Secure the Industrial Internet of Things (IIoT)
1. Securing
the
IIoT
with
DDS-‐Security
June
2015
Gerardo
Pardo-‐Castellote,
Ph.D.,
CTO,
Real-‐Time
InnovaEons
(RTI)
Co-‐Chair
OMG
DDS
SIG
www.rE.com
2. The
Industrial
Internet
of
Things
Industrial
Internet
of
Things
(IIoT)
Consumer
Internet
of
Things
(CIoT)
Cyber-‐Physical
Systems
(CPS)
3. The
Industrial
Internet
of
Things
Industrial
Internet
of
Things
(IIoT)
Consumer
Internet
of
Things
(CIoT)
Cyber-‐Physical
Systems
(CPS)
5. Hardly
an
isolated
incident…
• 2013:
ASack
on
Pacific
Gas
&
Electric's
Metcalf
substaEon
California.
– 17
transformers
damaged.
Approx.
$15
Million
in
repairs
[1]
• 2014:
Steel
Mill
aSack
in
Germany
– According
to
German
BSI
mill
suffered
"massive
damage”
[2]
• 2014:
Reports
of
79
Hacking
incidents
at
US
Energy
companies
[3]
• 2018:
Worldwide
spending
on
cyber
security
for
oil
and
gas
10. DocBox
and
Integrated
Clinical
Environment
(ICE)
Standard
• Hospital
error
is
the
6th
leading
cause
of
preventable
death
• DocBox
integrates
devices
to
improve
paEent
safety
11. Unite
Real-‐Time,
Mobile,
and
Cloud
• Largest
EMS
equipment
provider
supplies
ER
equipment
to
60%
of
the
world’s
emergency
vehicles
• Uses
DDS
for
in-‐
vehicle
plalorm,
mobile
device
bus,
cloud
connecEvity
12. Power
CriEcal
Infrastructure
(GC
Dam)
• DDS
controls
the
6.8
GW
GC
Dam
– Largest
power
plant
in
North
America
– Fastest-‐responding
major
power
source
on
the
Western
Grid
– Requires
24x7
operaEon
• DDS
met
the
challenges
– Extreme
availability
– Wide
area
communicaEons
– MulE-‐level
rouEng
– High
security
– 300k
data
values
13. Siemens
Wind
Power
turbine
control
• Siemens
Wind
Power
fields
farms
of
500
turbines
with
100m
blades
• DDS
implements
fast
control
within
turbines
and
gust
control
across
the
array
• DDS
enables
distributed
intelligent
machines
15. DDS:
Data-‐Centric
Qos-‐Aware
Pub-‐Sub
Model
Persistence
Service
Recording
Service
Virtual,
decentralized
global
data
space
CRUD
operaEons
Source
(Key)
Speed Power Phase
WPT1 37.4 122.0 -12.20
WPT2 10.7 74.0 -12.23
WPTN 50.2 150.07 -11.98
16. Is
there
a
Conflict?
• PubSub/DDS
– Create
a
‘global
data
space’
where
informaEon
is
shared
– Publishers
are
unaware
of
subscribers
and
vice-‐versa
• Security…
– Share
informaEon
only
with
authorized
subjects
– Requires
IdenEfying
who
produces
and
consumes
the
informaEon
and
cryptographic
protecEon
of
the
data.
16
A CONFLICT?
17. Is
there
a
Conflict?
• PubSub/DDS
– Create
a
‘global
data
space’
where
informaEon
is
shared
– Publishers
are
unaware
of
subscribers
and
vice-‐versa
• Security…
– Share
informaEon
only
with
authorized
subjects
– Requires
IdenEfying
who
produces
and
consumes
the
informaEon
and
cryptographic
protecEon
of
the
data.
17
NO CONFLICT: Must Use
Data-Centric Security Model!
18. Boundaries
at
which
security
should
be
applied
• System
Boundary
• Network
Transport
– Media
access
(layer
2)
– Network
(layer
3)
security
– Session/Endpoint
(layer
4/5)
security
• Host
– Machine/OS/ApplicaEons/Files
• Data
&
InformaEon
flows
Ul#mately
all
need
to
be
implemented
This
is
addressed
by
DDS
Security
20. DDS
Security
Standard
• DDS
enEEes
are
authenEcated
• DDS
enforces
access
control
for
domains/Topics/…
• DDS
maintains
data
integrity
and
confidenEality
• DDS
enforces
non-‐repudiaEon
• DDS
provides
availability
through
reliable
access
to
data
…while maintaining DDS interoperability & high performance
21. PracEcal
Fine-‐Grain
Security
• Per-‐Topic
Security
– Control
r,w
access
for
each
funcEon
– Ensures
proper
dataflow
operaEon
• Complete
ProtecEon
– Discovery
authenEcaEon
– Data-‐centric
access
control
– Cryptography
– Tagging
&
logging
– Non-‐repudiaEon
– Secure
mulEcast
– 100%
standards
compliant
• No
code
changes!
• Plugin
architecture
for
advanced
uses
CBM
Analysis
PMU
Control
Operator
State
Alarms
SetPoint
Topic
Security
model:
• PMU:
State(w)
• CBM:
State(r);
Alarms(w)
• Control:
State(r),
SetPoint(w)
• Operator:
*(r),
Setpoint(w)
22. DDS
Security
covers
4
related
concerns
Security
Plugin
APIs
&
Behavior
DDS
&
RTPS
support
for
Security
Buil#n
Plugins
Security
Model
23. BuilEn
Plugins
SPI
Buil#n
Plungin
Notes
AuthenEcaEon
DDS:Auth:PKI-‐RSA/DSA-‐DH
Uses
PKI
with
a
pre-‐configured
shared
CerEficate
Authority.
DSA
and
Diffie-‐Hellman
for
authenEcaEon
and
key
exchange
Establishes
shared
secret
AccessControl
DDS:Access:PKI-‐Signed-‐XML-‐
Permissions
Governance
Document
and
Permissions
Document
Each
signed
by
shared
CerEficate
Authority
Cryptography
DDS:Crypto:AES-‐CTR-‐HMAC-‐RSA/DSA-‐
DH
Protected
key
distribuEon
AES128
and
AES256
for
encrypEon
(in
counter
mode)
SHA1
and
SHA256
for
digest
HMAC-‐SHA1
and
HMAC-‐256
for
MAC
DataTagging
Discovered_EndpointTags
Send
Tags
via
Endpoint
Discovery
Logging
DedicatedDDS_LogTopic
24. DDS
Security
Flow
Domain
ParEcipant
Create
Fails
AuthenEcate
DP?
Yes
AuthenEcate
DP?
No
Ignore
Remote
DP
AuthenEcate
Remote
DP?
No
Yes
No
Yes
Access
OK?
Ignore
remote
endpoint
Message
security
Endpoint
Create
Fails
Yes
Access
OK?
No
Create
Domain
ParEcipant
Create
Endpoints
Discover
remote
Endpoints
Send/Receive
data
Discover
remote
DP
Network
Encrypted
Data
MAC
25. ConfiguraEon
PossibiliEes
• Is
the
access
to
a
parEcular
Topic
protected?
– If
so
only
authenEcated
applicaEons
with
the
correct
permissions
can
read/write
• Is
data
on
a
parEcular
Topic
protected?
How?
– If
so
data
will
be
sent
signed
or
encrypted+signed
• Are
all
protocol
messages
signed?
Encrypted?
– If
so
only
authenEcated
applicaEons
with
right
permissions
will
see
anything
26. Domain
Governance
Document
P2
IdenEty
CerEficate
P2
Private
Key
P2
P2
Permissions
File
P1
IdenEty
CerEficate
P1
Private
Key
P1
P1
Permissions
File
• PKI.
Each
parEcipant
has
a
pair
of
public
&
private
keys
used
in
authenEcaEon
process.
• Shared
CA
that
has
signed
parEcipant
public
keys.
ParEcipants
need
to
have
a
copy
of
the
CA
cerEficate
as
well.
• Permissions
File
specifies
what
domains/parEEons
the
DP
can
join,
what
topics
it
can
read/write,
what
tags
are
associate
with
the
readers/writers
• Domain
Governance
specifies
which
domains
should
be
secured
and
how
• Permissions
CA
that
has
signed
parEcipant
permission
file
as
well
as
the
domain
governance
document.
ParEcipants
need
to
have
a
copy
of
the
permissions
CA
cerEficate.
Configuring
&
Deploying
Secure
DDS
IdenEty
CA
Permissions
CA
27. DDS-‐SECURITY
Key
Aspects
• Standard
&
Interoperable
• Complete:
Handles
AuthenEcaEon,
AuthorizaEon,
Key
distribuEon,
EncrypEon,
Integrity,
…
• Scalable:
Supports
mulEcast
• Fine-‐grain:
Access
control
at
Topic
and
QoS
level;
Configure
Encrypt/Sign
per
Topic
• Flexible:
Create
your
own
plugins
• Generic:
Works
over
any
(RTPS)
Transport
• Transparent:
No
changes
to
exisEng
DDS
App
Code!
28. DDS:
The
best
connecEvity
standard
for
the
IIoT
• ReacEve
and
Data-‐Centric
• Scalable,
reliable,
high-‐performance
protocol
• Qos
support
that
meets
the
IIOT
requirements
• Supports
Edge
to
Cloud
deployments
• Built-‐in
data-‐centric
security
DDS
v
1.4
DDSI-‐RTPS
SECURIT
Y
DDS-‐
RPC
XTYPES
ApplicaEon
UDP
TCP
C++
JAVA
C
C#
Custom
IP
IDL
4.0
TLS/DTLS