Originally presented on October 21, 2015. Watch replay: http://ecast.opensystemsmedia.com/549

1. Data Centric Safety & Security for the Industrial IoT
Stan Schneider, RTI CEO
IIC Steering Committee Member

2. The smart machine era will be the most disruptive in the history of IT
-- Gartner 2015
©2015 Real-Time Innovations, Inc.

3. The IIoT Disruption
©2015 Real-Time Innovations, Inc.
The real value is a common architecture that
connects sensor to cloud, interoperates
between vendors, and spans industries
Common technology that spans
industries brings bold new approaches
and enables fast change

4. 200+ companies strong
Goal: build and prove a common
architecture that spans sensor to
cloud, interoperates between
vendors, and works across industries

5. 200+ Companies, 27 Countries

6. RTI’s Role in the IIC
Connectivity Safety TeamArchitecture Team
Distr Data Mgmt
& Interoperabilty
Use Cases Team
IIC Steering Committee IIC Staff
Legal
Working Group
Marketing
Working Group
Membership
Working Group
Security
Working Group
Technology
Working Group
Testbeds
Working Group
Liaisons Team

7. RTI’s Experience
• Over $1T of IIoT designs
– Healthcare
– Transportation
– Communications
– Energy
– Industrial
– Defense
• 15+ Standards & Consortia
Efforts
– Interoperability
– Multi-vendor ecosystems
©2015 Real-Time Innovations, Inc.

8. RTI Named Most Influential IIoT Company
©2015 Real-Time Innovations, Inc.

9. DDS is Different!
Point-to-Point
TCP
Sockets
Publish/Subscribe
JMS
Fieldbus
CANbus
Queuing
AMQP
Active
MQ
Client/Server
MQTT
REST
XMPP
OPC
CORBA
Brokered
Daemon
Data-Centric
DDS
Shared Data Model
DataBus
©2015 Real-Time Innovations, Inc.

10. Data Centricity Directly Controls Flow
• Global Data Space
– Automatic
discovery
– Read & write data
in any OS,
language, transport
– Type Aware
– Redundant
sources/sinks/nets
• No Servers!
• QoS control
– Timing, Reliability,
Redundancy,
Ordering, Filtering,
Security
©2015 Real-Time Innovations, Inc.
Shared Global Data Space
DDS DataBus
Patient Hx
Device
Identity
Devices
SupervisoryCDS
Physiologic
State
NursingStation
Clou
d
Offer: Write this
1000x/sec
Reliable for 10 secs
Request: Read this 10x/sec
If patient = “Joe”

11. Why Choose DDS?
• Reliability: Severe consequences if offline for 5
minutes?
• Performance/scale:
– Measure in ms or µs?
– Or scale > 20+ applications or 10+ teams?
– Or 10k+ data values?
• Architecture: Code active lifetime >3 yrs?
©2015 Real-Time Innovations, Inc.
2 or 3 Checks?

12. Disruptor: Dataflow-Level Security
• Dataflow-Level Security
– Control r,w access to each
data item for each function
– Ensures proper dataflow
operation
• Complete Protection
– Discovery authentication
– Data-centric access control
– Cryptography
– Tagging & logging
– Non-repudiation
– Secure multicast
• No code changes!
• Plugin architecture for
advanced uses
• Topic Security model:
– PMU: State(w)
– CBM: State(r); Alarms(w)
– Control: State(r), SetPoint(w)
– Operator: *(r), Setpoint(w)
CBM AnalysisPMU Control Operator
State Alarms SetPoint
©2015 Real-Time Innovations, Inc.

13. Demanding Use Cases
• The USS SECURE
cybersecurity test bed is a
collaboration between:
– The National Security Agency
– Department of Defense
Information Assurance Range
Quantico
– Combat Systems Direction
Activity Dam Neck
– NSWCDD
– NSWC Carderock/Philadelphia
– Office of Naval Research
– Johns Hopkins University
Applied Physics Lab
– Real Time Innovations, Inc.
• Objectives
– Immunize against cyberattack
and to rapidly recover when
impacted
– Determine the best
cyberdefense technologies
without impacting real time
deadline scheduled
performance
http://www.navy.mil/submit/display.asp?story_id=79228
©2015 Real-Time Innovations, Inc.

14. Pluggable Security Architecture
App.
Other
DDS
System
Secure DDS
middleware
Authentication
Plugin
Access Control
Plugin Cryptographic
Plugin
Secure Kernel
Crypto
Module
(e.g. TPM )
Transport (e.g. UDP)
application componentcertificates
?
Data
cache
Protocol
Engine
Kernel
Policies
DDS Entities
Network
Driver
?
Network
Encrypted Data
Other
DDS
System
Other
DDS
System
App.App.
Logging
Plugin
DataTagging
Plugin
MAC
©2015 Real-Time Innovations, Inc.

15. Standard Capabilities (Built-in Plugins)
Authentication  X.509 Public Key Infrastructure (PKI) with a pre-configured
shared Certificate Authority (CA)
 Digital Signature Algorithm (DSA) with Diffie-Hellman and
RSA for authentication and key exchange
Access Control  Configured by domain using a (shared) Governance file
 Specified via permissions file signed by shared CA
 Control over ability to join systems, read or write data
topics
Cryptography  Protected key distribution
 AES128 and AES256 for encryption
 HMAC-SHA1 and HMAC-SHA256 for message
authentication and integrity
Data Tagging  Tags specify security metadata, such as classification level
 Can be used to determine access privileges (via plugin)
Logging  Log security events to a file or distribute securely over
Connext DDS
©2015 Real-Time Innovations, Inc.

16. The Need for Software Certification
• Ensure safety of commercial aviation
• Ensure safe integration of UAS into the NAS
©2015 Real-Time Innovations, Inc.
Communication, Interoperation and Control

17. Disruptor: Safety-Critical Components
• Connext DDS Micro Cert
– Stringent SWaP requirements
– Complete certification
evidence
– Full interoperability with DDS
product line
• DO-178C Level A
– Flight management systems
• ISO 26262
– Road vehicle functional safety
• IEC 60601 class 3
– Medical devices
©2015 Real-Time Innovations, Inc.
Available
Soon
Soon

18. RTCA DO-178C / EUROCAE ED-12C
• Software Considerations in Airborne Systems and
Equipment Certification
• Used by FAA, EASA, Transport Canada and others
Level Failure Condition Process Objectives
A Catastrophic 71
B Hazardous/Severe 69
C Major 63
D Minor 26
E No effect 0
©2015 Real-Time Innovations, Inc.

19. Connext DDS Inherently Well-Suited to
Safety-Critical Systems
• Non-stop availability
– Decentralized architecture
– No single point of failure
– Support for redundant networks
– Automatic failover between redundant publishers
– Dynamic upgrades
• No central server or services
• Version-independent interoperability protocol
• Control over real-time Quality of Service
• Visibility into missed deadlines and presence
• Proven in thousands of mission critical systems
©2015 Real-Time Innovations, Inc. 19

20. Software Development Folder (electronic form)
(SDF)
NOTE: This information is provided as a set of
files on a DVD. They are not maintained as a
folder; instead, additional files are generated
which allow these materials to be grouped by
requirements. The information is presented in
a browseable format so that the information
may be viewed as a software development
folder based on requirement identification.
The Software Development Folder (SDF) includes at
a minimum:
 Reference to the applicable requirements.
 Reference to the implementation (Design
& Code).
 Evidence of reviews for the requirements,
design, code, test procedures, test results,
and structural coverage analyses.
 Software test procedures.
 Software test results.
 White Papers.
 Artifact Change history (CM System).
 Applicable problem reports.
 SQA Audit Reports.
 Internal Software Conformity Review
(provided separate from the certification
data package).
CC1 11.9
11.10
11.13
11.14
11.17
11.18
11.19
Full Evidence
Product Name Product Description Control Category DO-178C
Reference
Plan for Software Aspects of Certification (PSAC) Provides the certification (approval) authorities an
overview of the means of compliance, and insight into
the planning aspects for delivery of the product specific
to Connext DDS Cert.
CC1 11.1
Software Quality Assurance Plan (SQAP) Defines the SQA process and activities. CC1 11.5
Software Configuration Management Plan (SCMP) Defines the CM and change control processes. CC1 11.4
Software Development Plan (SDP)
Software Requirements Standard (SRStd)
Software Design Standard (SDStd)
Software Coding Standard (SCStd)
Defines the processes used for requirements analysis,
development, and test for the software product.
Includes the standards for requirements, design, and
code.
CC1 11.2
11.6
11.7
11.8
Software Verification Plan (SVP) Defines the test philosophy, test methods, and approach
used to verify the software product.
CC1 11.3
Software Test Plan (STP) Documents the project-specific approach to verifying
Connext DDS Cert.
CC1 11.3
Tool Qualification Plan Identifies the tools to be qualified under the current
project.
CC2 12.2.2
DO-330
10.1.2
Software Requirements Specification (SRS) Defines the software requirements applicable to Connext
DDS Cert.
CC1 11.9
Software Vulnerability Analysis (SVA) Identifies potential failure conditions in the software,
their potential impact, and proposed mitigation for
Connext DDS Cert.
CC1 N/A
Design Components, in Program Design Language
(PDL)
Describes the design of Connext DDS Cert. CC1 11.10
Software Configuration Index (SCI)
Software Configuration Index (SCI) Tables
Identifies the software components for Connext DDS Cert
with version information necessary to support
regeneration of the product. Also includes the
documents comprising the data package.
CC1 11.16
Software Life Cycle Environment Configuration Index
(SECI)
Identifies the tools used to build and test the software for
Connext DDS Cert.
CC1 11.15
Technical White Paper:
- Control-Coupling Verification With
VerOLink (VerOLinkWP.pdf)
-
Single topic technical paper providing additional
information to the certification authorities and users.
CC2 N/A
Requirements Traceability Document (RTD) Provides traceability from the requirements to all
related certification life cycle artifacts including design,
code, and test materials for the delivered software
product.
CC1 11.9
11.21
Software Accomplishment Summary (SAS) Documents the actual versus planned (per PSAC)
activities and results for the project. Provides a
summary of the means of compliance used for the
software. Justifies any deviations from the plans.
CC1 11.20
Sources Provides the Source files for:
- Connext DDS Cert
- Test procedures.
- Build and test scripts.
CC1 11.11
Results Documents the results of the functional and structural
coverage analysis. This includes the actual results and
any applicable analyses performed including coverage
analysis.
CC1 11.14
11.21
11.22
Libraries Linkable versions of the “as tested” product libraries. CC1 11.12
Verification tools Verification tools are identified and described in the Tool
Qualification Plan for Connext DDS Cert.
CC2 12.2
940 High-Level Requirements
3,680 Low-Level Requirements
3,400 test files
99.88% code coverage testing
©2015 Real-Time Innovations, Inc.

21. Enable Autonomy
• Autonomous
vehicles span land,
sea, and air
• RTI led the US UAS
ground station
architecture.
• DDS enables
advanced reactive
systems in
transportation
©2015 Real-Time Innovations, Inc.

22. The Network is the Future
• The IIoT will soon be as well defined as The Internet is today
• Common technology will replace special solutions
• The IIoT will inspire entire ecosystems
©2015 Real-Time Innovations, Inc.

23. For More Information
• RTI site: www.rti.com
• Examples, forum, papers: community.rti.com
• IIC website: www.iiconsortium.org
• Email: stan@rti.com
• Connect on LinkedIn
• Free RTI Connext DDS Pro:
www.rti.com/downloads
©2015 Real-Time Innovations, Inc.

24. The DDS Data-Centric Standard for the IIoT
• OMG’s Data Distribution Service is
the Proven Data Connectivity
Standard for the IoT
• OMG: world’s largest systems
software standards org
– UML, DDS, Industrial Internet
Consortium
• DDS: open & cross-vendor
– Open Standard & Open Source
– 12 implementations
Interoperability between source
written for different vendors
Interoperability between applications
running on different implementations
DDS-RTPS Protocol
Real-Time Publish-Subscribe
Distribution Fabric
DDS API
©2015 Real-Time Innovations, Inc.

25. This is addressed by DDS Security
Security Boundaries
• System Boundary
• Network Transport
– Media access (layer 2)
– Network (layer 3) security
– Session/Endpoint (layer 4/5) security
• Host
– Machine/OS/Applications/Files
• Data & Information flows
Ultimately, you need to implement all!
©2015 Real-Time Innovations, Inc.

26. DDS Security Model
Concept Unix Filesystem Security Model DDS Security Model
Subject User
Process executing for a user
DomainParticipant
Application joining a DDS domain
Protected
Objects
Directories
Files
Domain (by domain_id)
Topic (by Topic name)
DataObjects (by Instance/Key)
Protected
Operations
Directory.list,
Directory.create (File, Dir)
Directory.remove (File, Dir)
Directory.rename (File, Dir)
File.read,
File.write,
File.execute
Domain.join
Topic.create
Topic.read (includes QoS)
Topic.write (includes QoS)
Data.createInstance
Data.writeInstance
Data.deleteInstance
Access Control
Policy Control
Fixed in Kernel Configurable via Plugin
Builtin Access
Control Mode
Per-File/Dir Read/Write/Execute
permissions for OWNER, GROUP,
USERS
Per-DomainParticipant Permissions :
What Domains and Topics it can
JOIN/READ/WRITE
©2015 Real-Time Innovations, Inc.