Cop
yrig
ht P
rism
Tech
, 201
6
AngeloCorsaro,PhDCTO,ADLINKTech.Inc.Co-Chair,OMGDDS-SIG
Building Secure IIoT Systems with Vortex
Copy
right
Pris
mTe
ch, 2
015Security Bugs are source
of revenues through white, grey and black
market
Security Market
Source: HPE Cyber Risk Report 2016
Copy
right
Pris
mTe
ch, 2
015
With sufficient time and funding, there are few things that today
cannot be hacked.
Latest example of remote hacking of high value “connected things”are
BMW Connected Drive, Tesla Model S and JEEP
Based on security research from HP Fortify 80% of lower value connected
devices, such as home appliances, are insufficiently secure or
completely unsecured
Security Status
Copy
right
Pris
mTe
ch, 2
015
Device & System security
External Network / Untrusted
External Network / Untrusted
Internal Network / Trusted
Copy
right
Pris
mTe
ch, 2
015
In many instances, Security in IIoT is a bit different than
consumer IoT
Often it is easier to draw a boundary between what is trusted and was is not that
can help making the security solution more manageable.
Security in IIOT
Smart Factory
Copy
right
Pris
mTe
ch, 2
015
The IIRA decomposes an Industrial Internet System (IIS) in five functional
domains: Control, Operation, Information, Application and Business
Data flows and control flows take place in and between these functional
domains.
Security applies to Information as well as actions, i.e. who can access which
data and how (r|w) and who can perform a given action
IIRA
Imagefrom:“IndustrialInternetConsortiumReferenceImplementationv1.7”
Functional Domains
The Industrie 4.0 Reference Architecture (RAMI) is three dimensional and organises
the life-cycle/value streams and the manufacturing
hierarchy levels across the six layers of the IT
representation of Industrie 4.0
RAMI 4.0
Imagefrom:“ReferenceArchitectureModelIndustrie4.0”
The ability to virtualise physical entities and make information available is key
to RAMI4.0 and captured as part of the I4.0 Component
Security applies to Data (Virtual Representation) as well as
Technical Functions, i.e. who can access which data and how (r|w)
and who can perform a given action
I4.0 Component
Imagefrom:“ReferenceArchitectureModelIndustrie4.0”
Boundary Security
Boundary security is concerned with securing the interconnection
of a system with an untrusted network.
The system network, is considered trusted. In any case
security within the system is addressed using traditional LAN-
level security techniques
DMZ is a common way of implementing boundary security
De-Militarised Zone (DMZ)Semi-Trusted
Internal Network (IN)Trusted
External Network (EN) Untrusted
Firewall
Firewall
DMZ Security
DMZ assumes that anything within the Internal Network (IN) is trusted — the IN defines the boundary of
trust.
The DMZ is considered as a semi-trusted and the communication with
the trusted zone is often restricted by allowing only (1) TCP/IP from IN to
DMZ, (2) Connections from the IN to DMZ but not vice-versa
DMZ Security
The nature of the External Network (EN) may be
different across deployments and business
domains.
In some deployments the EN is not the Internet but a
WAN with some level of trust.
De-Militarised Zone (DMZ)Semi-Trusted
Internal Network (IN)Trusted
External Network (EN) Untrusted
Firewall
Firewall
DMZ Security
Please be aware that there are different ways of
implementing boundary security with a DMZ
To make the scope manageable we consider
the relatively standard double-firewall architecture, but several variations on the
theme exist.
De-Militarised Zone (DMZ)Semi-Trusted
Internal Network (IN)Trusted
External Network (EN) Untrusted
Firewall
Firewall
Secure
Data-Level security with
Pluggable Authentication Access
Control and Crypto
Device-2-DeviceDevice-2-Cloud
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infra
structure
sdk
Default Plug-ins
X.509 Public Key Infrastructure (PKI)
based authentication
Device-2-DeviceDevice-2-Cloud
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infra
structure
sdk
Default Plug-ins
Access Control List available at a trusted/
authenticated URI
Device-2-DeviceDevice-2-Cloud
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infra
structure
sdk
Default Plug-ins
Crypto based on TLS Cipher Suite
Device-2-DeviceDevice-2-Cloud
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infra
structure
sdk
Secure
Data-Security as opposed to simply Transport-Level
security
Arthur Dent
Arthur Dent
Ford Prefect
Zaphod Beeblebrox
Marvin
Trillian
left/A(r,w), left/B(r)
left/A(r,w), left/B(r,w), left/X(r)
left/*(r,w)
left/*(r), right/(w)
left/A(r,w), left/B(r,w), right/C(r,w)
Ford Prefect
Zaphod Beeblebrox
Trillian
Marvin
A
B
A,BX
*
*
A,B,C
Identity Access RightsSessions are authenticated and communication is encrypted
Only the Topic included as part of the access rights are visible and accessible
Secure
Fine-grained access control over Partition/
Topic regular expressions
Arthur Dent
Arthur Dent
Ford Prefect
Zaphod Beeblebrox
Marvin
Trillian
left/A(r,w), left/B(r)
left/A(r,w), left/B(r,w), left/X(r)
left/*(r,w)
left/*(r), right/(w)
left/A(r,w), left/B(r,w), right/C(r,w)
Ford Prefect
Zaphod Beeblebrox
Trillian
Marvin
A
B
A,BX
*
*
A,B,C
Identity Access RightsSessions are authenticated and communication is encrypted
Only the Topic included as part of the access rights are visible and accessible
Boundary Security
Boundary security support is enabled by Vortex-Fog
Device-to-Cloud Communication
Peer-to-Peer (Broker-less)
Device-to-Device Communication
Fog Computing Fog ComputingFog Computing
TLS
TLS
Access Control
Boundary SecuritySeparates security concerns
at different scales and controls what information is
exposed
Device-to-Cloud Communication
Peer-to-Peer (Broker-less)
Device-to-Device Communication
Fog Computing Fog ComputingFog Computing
TLS
TLS
Access Control
Certificate Management
Certificate Authority (CA) hierarchies are
supported to facilitate certificate management
Certificate/Key Management
ToolEases the creation of Certificate Authorities hierarchies as well as
service and device certificates
Device-to-Cloud Communication
Peer-to-Peer (Broker-less)
Device-to-Device Communication
Fog Computing Fog ComputingFog Computing
TLS
TLS
Applications belonging to the same Fog subsystem
share the same identity and the same access rights
Access Control
Fog Access Control
Device-to-Cloud Communication
Peer-to-Peer (Broker-less)
Device-to-Device Communication
Fog Computing Fog ComputingFog Computing
TLS
TLS
So long as the Fog CA is trusted the Fog instance will be trusted to join the Vortex
infrastructure.
Access Control
Fog Access Control
Access control for an entire Fog can be easily
controlled by defining rules for either a “Cluster
Subject Name” or a “Cluster Id”
Fog Access Control
Peer-to-Peer (Broker-less)
Device-to-Device Communication
Fog Computing Fog ComputingFog Computing
TLS
TLS
Each device can have its own identity or identities
can be shared per “security-level”
Access Control
Device-to-Cloud Communication
Device Access Control
Peer-to-Peer (Broker-less)
Device-to-Device Communication
Fog Computing Fog ComputingFog Computing
TLS
TLS
So long as the device’s CA is trusted the device
will be trusted.
Access Control
Device-to-Cloud Communication
Device Access Control
Devices access control can be defined using a
specific certificate name or a regular expression
on the subject name
Device Access Control
DMZ Security with DDS
IN Topic representation may be different from EN
representation
Application-level validation may be required before
injecting data from EN into IN
DMZ Security with DDS
Different domains can be used to separate IN and
OUT data
Guards decide what data is allowed to flow IN/
OUT
DMZ Security with DDS
Different domains can be used to separate IN and
OUT data
Guards decide what data is allowed to flow IN/OUT
using some communication mechanism different from
DDS to allow for certification/accreditation
DMZ Security with VortexVortex Gateway can be
used for Internal/External topic transformation
Vortex Fog provides boundary security
DMZ Security with Vortex
If applications-level validation of data is
required, then the DMZ is organised as two separate
domains
Applications take care of forwarding valid data
between domains
DMZ Security with Vortex
If the infrastructure is not trusted then you can use
two guards communicating over a
custom mean
Copy
right
Pris
mTe
ch, 2
015Security is a key concern in IIoT
IIoT security can often be made more manageable by implementing it as boundary security
DMZ is a sound approach to implement boundary security
Vortex Security provides a very good support to implement boundary security, and specifically DMZ-based boundary security
Concluding Remarks