Cop

yrig

ht P

rism

Tech

, 201

6

AngeloCorsaro,PhDCTO,ADLINKTech.Inc.Co-Chair,OMGDDS-SIG

angelo.corsaro@adlinktech.com

Building Secure IIoT Systems with Vortex

Cop

yrig

ht P

rism

Tech

, 201

5

The Security Market

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

Cop

yrig

ht P

rism

Tech

, 201

5

Security in IIoT

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

Cop

yrig

ht P

rism

Tech

, 201

5

System Requirements

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”

Cop

yrig

ht P

rism

Tech

, 201

5

System Security Architectures

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

Vortex Security

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

Data-Centric Security Management

&Configuration

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

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

DMZ Security with VortexVortex Gateway can be

used for Internal/External topic transformation

Vortex Fog provides boundary security

Copy

right

Pris

mTe

ch, 2

015

physical deployment

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

Copy

right

Pris

mTe

ch, 2

015

physical deployment

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

015

physical deployment

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