Trends in IIoT and OT Security

© Siemens AG 2018, Unrestricted
siemens.com© Siemens AG 2018, Unrestricted
Trends in lIoT and OT Security
Hochschule Augsburg - June 06, 2018
Oliver Pfaff, Siemens AG

The Industrial Internet-of-Things (IIoT) as well as Operational Technologies (OT) provide distributed
systems that serve critical processes and resources in the real world.
Just as in case of Information Technologies (IT), they demand security. But for a number of reasons
well-know IT-security mechanisms don’t always do the trick for IIoT and OT.
This lecture identifies the status quo in security for IIoT and OT. The characteristics of IIoT and OT
systems that demand new approaches in security get highlighted. Emerging solutions for IIoT and OT
security are investigated and assessed.
Abstract

1. Getting Started
 Considered Systems and Use Cases
 Security Objectives
2. IIoT Security
 Characteristics and Differentiators
 Security Status Quo and Trends
3. OT Security
 Characteristics and Differentiators
 Security Status Quo and Trends
4. Wrap-Up, Takeaways and Outlook
Contents

Stacks:IP-based
IoT
Internet-of-Things
Things
Stacks:IP-based
IT
Information Technology
Services
User
agents
Users
Greenfield IoT System Model
Real
world
Physical resources,
processes
Things

Stacks:IP-based
IT
Information Technology
Services
User
agents
Users
Stacks:IP-based
IoT
Internet-of-Things
Edge
gateway
Brownfield IoT System Model
OT
Operational Technology
Engineering
system
Real
world
Physical resources,
processes
DevicesDevices
Stacks:miscfieldbusses
Controllers
Field devices
Controllers

• Thing as a provider of data:
 Data collected from real world processes/resources
passing through
 public networks, designated to
 own or 3rd-party components and services
• Thing as a receiver of instructions:
 Real world resources/assets controlled through
 public-facing endpoints by means of
 general-purpose application protocols on top of IP-
stacks
Main Use Cases
Service/
thing/app
Thing
Service/
thing/app
Thing

• The need for security in IoT is self-evident to avoid unwanted behavior of system components such as:
 Talks-to-anybody
 Executes-instructions-from-anybody
• It happens to be undisputed too  no more arguments needed
Motivation for Security

• Entity authentication = who is this?
Actors (=callers, originators) make claims about themselves (identifiers, properties etc.)
in network messages – false claims have to be detected/prevented
• Authorization = is it allowed?
Daemons (=unattended callees) receive instructions/input over the network –
acceptance/rejection has to be decidedX
• Message encryption = how to hide its contents?
Actors (=callers, originators) send information over a network – eavesdropping has to
be prevented
• Message authentication = who said that? Was it manipulated/replayed/faked…?
Actors (=callers, originators) send information over a network –
manipulations/replay/fake has to be detected
Main Objectives in Distributed System Security

Building Blocks for Distributed System Security
• Cryptographic algorithms: maths to crunch data
 Sign/verify
 Encrypt/decrypt
• Cryptographic objects: structures to represent crunched data
 Signed data
 Encrypted data
• Security protocols: embeddings of crunched data into exchanges across networks
 Two/multi-party exchanges
 Synchronous/asynchronous
• Security infrastructure: helper components for security tasks
 Inline/online/offline trusted third parties (TTPs)
 Conditionally/unconditionally trusted

• In the following, the security protocol family (D)TLS and SSL is
assumed to be well-known (see: RFC 5246, RFC 6101, RFC
6347). They comprise:
 A preparation phase during which keys (e.g. CA certificates,
own key pair/certificates) and configuration settings (e.g.
cipher suite preferences) are set-up locally
 An operation phase during which (D)TLS and SSL-defined
messages are exchanged according distinct sub-phases:
o (D)TLS and SSL-module internal housekeeping
exchanges: Handshake/ChangeCipherSpec/Alert
messages wrapped into Record messages
o Application exchanges: Record messages containing
application data e.g. HTTP requests/responses
• What will happen next?
 The IIoT security section will examine the fitness of
established (D)TLS and SSL preparation practices for IIoT
 The OT security section will examine the fitness of (D)TLS
and SSL message exchanges for OT
Outlook
Client Server
CA certificates
etc.
Own certificate,
private key etc.
ClientHello
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
Application data
*: optional, situation-dependent messages

Industrial IoT
• IIoT employs IoT technologies and solutions for industrial applications and processes in building
automation, energy/traffic management, manufacturing etc.
• IIoT aims at facilitating new use cases such as analytics and predictive maintenance
• Main flavors:
 Greenfield: uses edge components which directly interact with physical resources and processes
 Brownfield: uses edge components (aka edge gateways) that rely on other (already existing)
systems for this purpose
Services
e.g. time
series
Edge
components
Physical resources,
processes
OTIP-based stacks,
Internet

Characteristics and Differentiators for IIoT
• Real world resources and processes; physical goods
• Greenfield and brownfield deployments
• Misc. scenarios: thing-to-service, service-to-thing and/or thing-to-thing
• Severely constrained components (power supply, CPU/memory capacity, IO means, external interfaces…)
• IP-based protocol stacks
• Public network infrastructure
• Long system lifecycle (years..decades)
• Unattended operation, no human users

• At 10.000 feet strong commonalities can be found:
 Thing as a provider of data:
o Authorization: a to-do on side of the services component as resource provider
o Entity authentication: things need to be authenticated by service components and vice versa
o Message authentication/encryption: things and service components need to transform exchanged
information in an agreed/coordinated manner (which makes sure that 3rd parties can not interfere)
 Thing as a receiver of instructions: differentiate according the communication paradigm
o Instruction pull (Hollywood Principle: don’t call us, we call you): same as above
o Instruction push: authorization becomes a to-do on side of the thing, same as above for the others
• Despite these commonalities, the following is frequently encountered in IIoT security:
 Handiwork: manual procedures during the onboarding of a component to a site esp. its credentialing
 Silos: vendor-specific, proprietary security solutions, making it difficult to assemble a site with products
and services from different vendors and providers
 Ad-hoc’s: straight-forward and sometimes even naive adoptions of IT-security approaches, e.g. there is
nobody to enter passwords and replacing the person by software for this purpose creates question-marks
Security Status Quo for IIoT

• Bootstrapping a thing with site-specific credentials concerns
following objects:
 For asymmetric cryptography: own public/private key pair,
public keys resp. certificates of the peers
 For symmetric cryptography: secret keys shared with the peers
• Linearization: the usage of TTPs allows to reduce the number of
relations that have to be managed from O(n2) to O(n) in a site with
#n things/services that shall be able to interact with another
• Dimension: whether handiwork is acceptable for the remaining
complexity depends on the magnitude of #n
 Assume 1 hour manual work at 100 EUR would be needed to
bootstrap initial site credentials at one component. Then 1-100
components may be uncritical, 100-1000 components start to
be worrisome and 1000+ components will be critical
 In e.g. building automation such numbers are easily reached
(e.g. 200 or more rooms with 5 or more things per room)
 Automated bootstrapping of site credentials is a need in IIoT
Automated Bootstrapping of Site Credentials in IIoT
O(n) initial keys per component
O(n2) initial keys in the system
C1
C2
C3
S1
S2
S3
S1
S2
S3
O(1) initial keys per component
O(n) initial keys in the system
C1
C2
C3
TTP

• Server credentials comprise a X.509 server certificate
chain and a corresponding private key
• Server credentials facilitate server authentication. This
happens when https://... resources are accessed (using
TLS resp. SSL underneath HTTP, RFC 2818)
• Server authentication requires following preparation tasks:
 Server-side: key pair and CSR generation, selection of
CA, server certificate acquisition from this CA
 Client-side: import of CA certificate(s)
• End-users remain fully unaware of these preparation tasks:
 Server-side: administrators are in charge of this task
 Client-side: Web browser/app developers perform
this task
• So the current bootstrapping practices in Web security are:
 Server-side: handiwork (accepted since: number of
servers<<clients; scripting also reliefs some pain)
 Client-side: hiding
Recap: Bootstrapping of Credentials for
Web Servers
Client Server
CA certificates Own certificate,
private key
Access https://...
ClientHello
ServerHello
Certificate
ServerHelloDone*
Validate server certificate chain
ClientKeyExchange
[ChangeCipherSpec]
Finished*
[ChangeCipherSpec]
Finished
Validate PoP for server certificate
HTTP exchanges
*: some simplifications, wlog

• In most cases user credentials are static/one-time
passwords
• User credentials facilitate user authentication. This is
enforced by Web servers when protected resources are
accessed. It uses the HTTP application level in most cases
• User authentication depends on following preparation tasks
(here: focusing on the consumer space):
 Server-side: supply a Web UI-based registration
component accepting self-asserted information and
checking it according a policy (liberal..strict - depending
on application, its resources, applicable legislations)
 Client-side: end-users need to perform registration (once
per provider e.g. google.com, not once per application
e.g. gmail.com, youtube.com)
• So the current bootstrapping practices in Web security are:
 Server-side: automated
 Client-side: handiwork (accepted since: contents are
king; federation also helps to relief some pain)
Recap: Bootstrapping of Credentials for Web Users
Client Server
User id/
password*
Req w/o
user creds
User
User id/
password
Access protected
resource via https://...
See above
Resp with
challenge
Trigger user
interaction
Enter user id/
password Req with
user creds
Resp with
resource
Validate user id/password
*: scrambled e.g. salted hash
Check authorization

• Automated bootstrapping and credentialing in a site is
a need in IIoT, as soon as IIoT deployments exceed
small scenarios such as few edge gateways calling
few services
• Even when assuming the best practice protocols in
Web security to do the trick for IIoT (here: operation
phase), the best practice setup procedures not do the
trick for IIoT (here: preparation phase)
 Additional/new approaches for the preparation
phase are needed in IIoT security
Automated Bootstrapping of Site Credentials in IIoT
Reality Check
Server credentials User credentials
Own
Handiwork
(with a reason:
#servers << #clients)
Handiwork
(with a reason:
contents are king)
Peer
Hiding
(with a reason:
John Doe does not
understand PKI)
Automated
Current credentialing practices in Web security:
A match on buzzword-level, a no-show on contents-level:
most solutions provide password credentials and
depend on human attention at the other end

Recap: Types of Credentials
Passwords
Symmetric
Shared
secrets
Asymmetric
Raw key pairs
Public key
certificates
X.509 public
key certificates
Cryptographic
keys
Others

• For X.509 certificate objects: automated bootstrapping
of own, site-specific credentials was kicked-off by IEEE
802.1AR (2009). It is elaborated with HTTP resp. CoAP
bindings in RFC 7030 (2013) resp. draft-ietf-ace-coap-
est-00 (2018, work-in-progress). This happens
according following recipe:
 IDevID: a globally significant, eternal component
identifier, expressed in form of X.509 public key
certificates, issued by a manufacturer CA,
assigned during the production of the IIoT
component
 LDevID: a locally significant, time-limited
component identifier owned/controlled by the site,
expressed in form of X.509 public key certificates,
automatically issued by a site CA, assigned during
the commissioning of the component
• For other credential types: n.a.
Bootstrapping Own Credentials in IIoT Sites
IDevID credentials
(own)
Site CA certificate
(see below for its acquisition)
Generate pub/priv key pair and CSR
Generate EST request
Check EST request
Issue thing@site certificate
HTTP-over-TLS (mutually authn) EST response
(with PKCS#7 incl. own site certificate)
Accept this thing@site?
LDevID credentials
(own)
Manufacturer CA certificate
IIoT component
(pledge)
Site service
(domain registrar)
HTTP-over-TLS (mutually authn with own
IDevID and peer LDevID creds): EST request (Post)
LDevID credentials
(own)

HTTP-over-TLS (client authn with IDevID creds,
provisional accept of server cert) voucher request (Post)
• For X.509 certificate objects: automated bootstrapping
of peer, site-specific credentials is addressed with
HTTP bindings in draft-ietf-anima-bootstrapping-
keyinfra-15 (2018, work-in-progress) and RFC 8366
(2018) i.e. still is in incubation. This uses following:
 Voucher request: an IDevID-signed request
object identifying the site, created by the IIoT
component and indirectly sent to its manufacturer
 Voucher response: a manufacturer-signed object
containing the site CA certificate created by the
manufacturer and sent to the IIoT component
 This introduces some complications:
o Depends on a special mode of handling
server certificates called “PROVISIONAL
accept of server cert”
o Voucher request contains info obtained from
TLS exchange; can not be produced upfront
• For other credential types: n.a.
Bootstrapping Peer Credentials in IIoT Sites
IDevID credentials
(own)
LDevID credentials
(own)
Manufacturer CA certificate
IIoT component
(pledge)
Site service
(domain registrar)
Site CA certificate
Manufacturer
service (MASA)
IDevID credentials
(own)
Check voucher request
Accept this thing@site?
Issue voucher
Check voucher request
HTTP-over-TLS (mutually authn
with own LDevID and peer IDevID
creds) MASA request (Post)
Verify voucher, provisional cert
Site CA certificate
HTTP-over-TLS (mutually authn)
MASA response (with voucher object)
HTTP-over-TLS (provisionally authn)
MASA response (with voucher object)

• Landing page: https://brski-test.siemens-bt.net:8443/
• The interop system incarnates the domain registrar
component and allows to test following endpoints:
 EST-defined endpoints (RFC 7030):
o CA certificate exchange
o Simple enrollment
o Simple reenrollment
 BRSKI-defined endpoints (draft-ietf-anima-
bootstrapping-keyinfra-15 and RFC 8366):
o Request voucher exchange
 These endpoints can be accessed by means of
HTTP-over-TLS and CoAP-over-DTLS
• This interop system is provided by Siemens Building
Technologies. Siemens is first to expose a domain
registrar on the Internet for interop testing (Fairhair
Alliance)
Demo for Bootstrapping Site Credentials in IIoT

Engineering
sytem
Controllers
Field
devices
Sensors Actuators
Operational Technology
On-site
Off-site
• OT comprises “…hardware and software that detects or
causes a change through the direct monitoring and/or control
of physical devices, processes and events…” (Gartner)
 Used for process automation since the 70/80s
 Originally not using IP-based stacks
• Main system components:
 Off-site components
o Engineering systems
 On-site components
o Controllers
o Field devices: sensors, actuators

• For on-site components (controllers and field devices):
 Severely constrained components (CPU/memory capacity, IO means, external interfaces…)
 Unattended operation, no human users
 Realtime exchanges with hard time boundaries
 Lack of synchronized time
 Domain-specific protocols stacks, not (only) based on IP
 Many server components (field devices), few(er) clients (controllers)
• Overall:
 Long system lifecycle (years..decades)
 Planned/projected set-up - no ad-hoc systems
 On-site components can not assume to have online interaction with engineering systems
 Off-site components may be unavailable when on-site component maintenance is needed (use case:
unplanned field device replacements)
Characteristics and Differentiators for OT

• System level: “secure island” deployment model with
system isolation, network segregation
 Traditional approach to OT security
 Well-known
 Widely used/established
• Protocol level: tbd
 Not yet established/used, at least not widely
 Implying: syntactically good instructions sent over
the network get executed
Security Status Quo in OT

• The introduction of protocol security presents the main security challenge in OT
• OT security on protocol level requires to architect security solutions that keep a balance between
 Security objectives (authorization, entity authentication, message authentication/encryption) AND
 OT system constraints (see above)
• The fulfillment of security objectives AND system constraints matters:
 Finding solutions that meet the security objectives is quite trivial, nowadays
 Finding solutions that meet security objectives AND constraints of OT systems is not trivial
• Following OT properties are considered to illuminate this:
 Realtime exchanges with hard time boundaries
 Lack of synchronized time
 Unplanned field device replacements
Protocol Security for OT

• (D)TLS and SSL depend on house-keeping tasks:
 Establishment and switching of relationship keys
(master_secret, keys that process application data)
 Mechanism (aka CipherSuite) negotiation
• This demands protocol exchanges between (D)TLS resp. SSL
modules on client and server side
• These exchanges are specified in form of sub-protocols
(Handshake, ChangeCipherSpec, Alert). This introduces
additional network roundtrips:
 Full handshake (no formerly established relationship key
resp. no re-use of such keys): 2 roundtrips
 Resumed handshake (re-uses formerly established
relationship key): 1.5 roundtrips
• The housekeeping exchanges are multiplexed into the same
channel that does the protected exchange of application data
(reason: users will not recognize the added msec’s)
• They happen at the beginning resp. before application
exchanges and meanwhile (long-lasting) application sessions
Recap: Housekeeping Tasks in (D)TLS and SSL
TCP/IP
stack
Client
(D)TLS
TCP/IP
stack
Server
(D)TLS
Application
data
Handshake,
ChangeCipherSpec
data

• Realtime exchanges in PROFINET: controllers
send/receive1 frame with application data from/to field
device per update cycle (with each device). The update
cycle depends on the site/deployment and is ca. 250
µsec – 2 msec. These exchanges are critical for keeping
the automated production process up and running
• Clearly housekeeping tasks will be needed for protocol
security in OT. They will also demand protocol
exchanges between controllers and field devices.
• The actual question is: is multiplexing housekeeping
exchanges into the same channel as the application
(here: realtime) data exchanges a good idea for OT?
• Employing a security protocol that performs mechanism
negotiation, key establishment/update and switching of
security parameters in-band manner would severely
affect production-critical application exchanges by
adding alien sources of non-deterministic behavior
Realtime Exchanges with Hard Time Boundaries
802.xx
LAN/WLAN
Controller
802.xx
LAN/WLAN
Field device
Cycle#n Cycle#n+1 ……
Acceptable additions
(if done with care):
or (tbd)
Rejected additions:

• The utilization of TTPs (offline/online/inline, unconditionally/functionally trusted) is common in IT-security
• TTP-issued security objects used in IT-security ubiquitously use time markers. Important examples:
 X.509 CAs: notBefore/notAfter markers in X.509 public key certificates
 Kerberos KDCs: authtime/starttime/endtime/renew-till markers in Kerberos tickets
 SAML IdPs: NotBefore/NotAfter markers in SAML assertions
 OIDC IdPs: iat/nbf/exp markers in JSON Web tokens
• This is done with following rationale:
 Interacting with TTPs comes at cost: there is a benefit when TTP-issued objects can be re-used
 Re-use makes TTP-issued objects forward-looking: asserting properties checked just now for some time
into the future. That could become invalid in future
 Time markers allow to control the period of re-use
• It requires producers and consumers of TTP-issued objects to have clock synchronization - at a certain level
of accuracy
• In networks that are based on the IP-stack this translates to the utilization of NTP by the system
components. NTPv4 (RFC 5905) provides timestamps relative to 1900-01-01 00:00 and in form of
128/64/32-bit unsigned integer values with an accuracy in the interval [tens of microseconds, seconds]
Recap: Time Markers in IT-Security Objects

• PROFINET conformance classes A/B:
 Controllers and field devices have an own, local
perception of elapsed time (between two events)
 Controllers and field devices have no time
synchronization with other system components
• PROFINET conformance class C:
 Controllers and field devices have a synchronized
time but this is a deployment-local time (no world
time such as GMT/UTC)
• PROFINET conformance class A presents the
baseline. Classes B and C are specializations. A
majority of deployments belong to classes A/B
Lack of Synchronized Time

• (D)TLS and SSL support various entity authentication modes:
 Mutual: server and client authentication
 Unilateral: server but no client authentication
 Anonymous: no client authentication, no server authentication
• Web security defaults to the unilateral mode:
 Server authentication happens. This is done on (D)TLS and
SSL layer 5 and uses X.509 server certificates
 Client authentication is optional and done on application layer 7
• Authentication of Web servers is specified in RFC 2818. It happens
by comparing the hostname expected by layer 7 software (browser,
app) with actual hostname asserted on layer 5 ((D)TLS or SSL) in
form of valid X.509v3 certificates
• It requires to identify the server by its DNS name or IP address and
imprint this value into the X.509 server certificate. This can use:
 subjectAltName extension of type dNSName (default)
 A commonName field in the subject name (allowed, rarely
encountered)
Recap: Server Authentication in (D)TLS and SSL
Expected hostname on layer 7
Claimed/proven hostname(s) on layer 5
Match

• Controllers and field devices may break in an unplanned way. Such events disturb the production:
 Controller replacements are a major task that can not be done in an ad-hoc fashion
 Field device replacements need to be done in ad-hoc fashion – in the middle of the night, on public
holidays. For this purpose sites maintain a backup storage with spare devices of the same component
type. Replacement requires to find a field device of the same component type in the store, remove the
defect instance and deploy the spare instance from backup store
• Equipping devices with server credentials in style that bind the identifiers DNS name or IP address would
introduce pain-points:
 A posteriori credentialing - happening when a replacement component is put into production:
o Unplanned device replacement can not assume any configuration or provisioning task for the
replacement component done by an operator in charge of doing the replacement
 A priori credentialing - happening when a replacement component is put into backup storage:
o DNS names do not exit in all OT protocols. If domain-specific identifiers (e.g. PROFINET name in
PROFINET) are imprinted spec-related issues appear. More important: the stockpiling approach
would change: a replacement component can not replace any instance of the same type anymore
o Ditto for imprinting IP addresses
Unplanned Device Replacements

Wrap-Up
• IIoT and OT provide distributed systems. Both require security on protocol level:
 IIoT because of its use of public network infrastructure and IP-based stacks for exposing real world resources
and processes
 OT to overcome system isolation and get ready for new use cases in Digitalization and I4.0
• Distributed system security dates back to the 60/70ies  there is lots of prior art in protocol security for
distributed systems. But the prior art addresses other domains, mainly:
 IT and esp. Web-based applications
 Human users as callers, IT and Web applications as callees
• Widely agreed standards for securing IIoT and OT according the needs of a domain/industry do not yet exist:
 Important because sites typically mix components from different vendors
 Corresponding work happens right now
 Do not expect one-size-fits-all security solutions in IIoT or OT: use cases and constraints vary significantly
across industries and sub-domains e.g. real-time and time synchronization properties, system planning
approaches

Takeaway#1: Build Workload Distribution Is Unequal


!
!
• Cryptographic algorithms: rather straight-forward
 Pick lightweight algorithms, many (>1000) to choose from
 Consider cryptographic algorithm aging and agility
• Cryptographic objects: pretty straight-forward
 Pick lightweight syntaxes, few (<10) to choose from
• Security protocols: not straight-forward
 More attention needed
• Security infrastructure: not straight-forward
 More attention needed

Takeaway#2: The One-Fits-All Security Protocol
Is an Illusion • No one-fits-all: there is no universally correct allocation
of cryptographic algorithms/objects in a protocol stack.
The IT-domain provides evidence:
 Mail security: S/MIME, PGP (layer 7b)
 Web security: HTTP headers/payload (7a/b) and (!)
TLS (5) in conjunction
 Network security: TLS (5), IPSec (3) and IKE (7),
802.1AE/X or 802.11WEP/WPA (2)
• Not always single: there is no guarantee that a single
allocation does the trick. Web security practices provide
evidence: Web security happens on layers 5 AND 7a/b
• Lesson: each domain has to find its own sweet-
spot(s) for adding security. As a rule-of-thumb:
 Going up the stack: increased E2E span, improved
granularity, awareness of application-level objects
 Going down the stack: re-use of 3rd party artifacts
e.g. specs, software
Protocol layers IIoT and OT stacks
7b
Application
7a
6 Presentation
5 Session
4 Transport
3 Network
2 Data link
1 Physical Wire, air, optical media
?

• IIoT security:
 Protocol security does exist for an obvious reason: On the Internet, Nobody Knows You Are a Dog!
 Everybody does something - often in an ad-hoc fashion - leading to a scattered IIoT security
landscape as of today
 Mainlines still have to be found, cultivated and adopted
• OT security:
 Protocol security does not yet exist (reason: got neglected by OT’s heritage as enclosed systems)
 It is now about to become added to OT stacks and field busses
 This process is in its incubation: research and development results exist/are elaborated, some demos
done, not yet covered in most OT stack and field bus standards, not yet available off-the-shelf
Outlook#1: Trends

• IIoT security:
 Fairhair Alliance: security for IoT usages in the building and lightning domain
 IETF:
o ACE: security mechanisms for CoAP with application (OSCORE) and session layer (DTLS)
bindings
o Anima: automated bootstrapping of site-specific credentials in multi-vendor environments
o Core: security mechanisms for CoAP exchanges (OSCORE)
o OAuth: security mechanisms for HTTP exchanges (inherited by ACE)
 OPC: OPC-UA PubSub security
 W3C: WoT interest/working group
 …
• OT security:
 ODVA: security for the Common Industrial Protocol
 PNO: security for PROFINET
 …
Outlook#2: Initiatives to Watch

Abbreviations
ACE Authentication and authorization for Constrained
Environments (IETF WG)
Anima Autonomic Networking Integrated Model and
Approach (IETF WG)
BRSKI Bootstrapping Remote Secure Key Infrastructures
CA Certification Authority
CoAP Constrained Application Protocol
CORE Constrained RESTful Environments (IETF WG)
CPU Central Processing Unit
CSR Certificate Signing Request
(D)TLS TLS and/or DTLS
DTLS Datagram TLS
E2E End-to-End
EST Enrollment over Secure Transport
HTTP Hypertext Transfer Protocol
I4.0 Industrie 4.0
IDevID Initial Device IDentifier
IdP Identity Provider
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IIoT Industrial IoT
IKE Internet Key Exchange
IO Input/Output
IoT Internet-of-Things
IP Internet Protocol
IPSec IP Security
IT information Technology
JSON JavaScript Object Notation
KDC Key Distribution Center
LDevID Locally significant Device Identifier
MASA Manufacturer Authorized Signing Authority
NTP Network Time Protocol
OAuth Open Authorization (IETF WG)
ODVA Open DeviceNet Vendors Association
OPC Open Platform Communications
OPC-UA OPC Unified Architecture
OSCORE Object Security for CORE
OT Operational Technology
PoP Proof of Possession
PKCS Public Key Cryptography Standards
PKI Public Key Infrastructure
PNO PROFINET Organization
PROFINETPROcess FIeld NETwork
SSL Secure Sockets Layer
TLS Transport Layer Security
TTP Trusted Third Party
UI User Interface
W3C World-Wide Web Consortium
WG Working Group
WoT Web-of-Things

References
Fairhair Alliance: Security Architecture for the Internet of Things (IoT) in Commercial Buildings. March 2018
IEEE: Standard for Local and Metropolitan Area Networks – Secure Device Identity.
IEEE 802.1AR-2009
IETF: Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-
to-Implement Algorithms. RFC 7696
INCIBE: Protocols and network security in ICS infrastructures. May 2015
NIST: Guide to Industrial Control Systems (ICS) Security. SP800-82, May 2015
ODVA: CIP Security Phase 1 Secure Transport for EtherNet/IP. Oct. 2015

Author
Oliver Pfaff; Principal, IT-Security
Siemens AG; CT RDA ITS
E-mail: oliver.pfaff@siemens.com
siemens.com

Trends in IIoT and OT Security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Trends in IIoT and OT Security

Similar to Trends in IIoT and OT Security (20)

More from Oliver Pfaff

More from Oliver Pfaff (17)

Recently uploaded

Recently uploaded (20)

Trends in IIoT and OT Security