iot and m2m safety and security

Data Centric Safety & Security for the Industrial IoT

Stan Schneider, RTI CEOIIC Steering Committee Member

The smart machine era will be the most disruptive in the history of IT-- Gartner 2015

©2015 Real-Time Innovations, Inc.

The IIoT Disruption


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

200+ companies strong

Goal: build and prove a common architecture that spans sensor to cloud, interoperates between vendors, and works across industries

200+ Companies, 27 Countries

RTI’s Role in the IIC

Connectivity Safety TeamArchitecture Team Distr Data Mgmt & Interoperabilty

Use Cases Team

IIC Steering Committee IIC Staff

LegalWorking Group

MarketingWorking Group

MembershipWorking Group

Security Working Group

TechnologyWorking Group

TestbedsWorking Group

Liaisons Team

RTI’s Experience

• Over $1T of IIoT designs– Healthcare– Transportation– Communications– Energy– Industrial– Defense

• 15+ Standards & Consortia Efforts– Interoperability– Multi-vendor ecosystems


RTI Named Most Influential IIoT Company


DDS is Different!

Point-to-Point

TCP Sockets

Publish/Subscribe

JMSFieldbusCANbus

Queuing

AMQPActive MQ

Client/Server

MQTT RESTXMPPOPCCORBA

BrokeredDaemon

Data-Centric

DDS

Shared Data Model

DataBus


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


Shared Global Data Space

DDS DataBus

Patient Hx

Device Identity

Devices

Supe

rviso

ry C

DS

Physiologic State

Nur

sing

Stati

on

Cloud

Offer: Write this 1000x/sec

Reliable for 10 secs

Request: Read this 10x/secIf patient = “Joe”

Contract

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?


2 or 3 Checks?

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


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


Pluggable Security Architecture

App.

Other DDSSystem

Secure DDS middleware

AuthenticationPlugin

Access ControlPlugin Cryptographic

Plugin

Secure Kernel

Crypto Module(e.g. TPM )

Transport (e.g. UDP)

application componentcertificates

?

Datacache

ProtocolEngine

KernelPolicies

DDS Entities

NetworkDriver

?

Network

Encrypted Data

Other DDSSystem

Other DDSSystem

App.App.

LoggingPlugin

DataTaggingPlugin

MAC


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 exchangeAccess 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

topicsCryptography 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


The Need for Software Certification

• Ensure safety of commercial aviation

• Ensure safe integration of UAS into the NAS


Communication, Interoperation and Control

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


Available

Soon

Soon

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 ObjectivesA Catastrophic 71B Hazardous/Severe 69C Major 63D Minor 26E No effect 0


Connext DDS Inherently Well-Suited toSafety-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

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.5Software 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 Requirements3,680 Low-Level Requirements3,400 test files99.88% code coverage testing


Enable Autonomy

• Autonomous vehicles span land, sea, and air

• RTI led the US UAS ground station architecture.

• DDS enables advanced reactive systems in transportation


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


For More Information

• RTI site: www.rti.com• Examples, forum, papers: community.rti.com• IIC website: www.iiconsortium.org• Email: [email protected]• Connect on LinkedIn• Free RTI Connext DDS Pro:

www.rti.com/downloads


http://www.rti.com/

http://community.rti.com/

http://www.iiconsortium.org/

mailto:[email protected]

http://www.rti.com/downloads

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 ProtocolReal-Time Publish-Subscribe

Distribution Fabric

DDS API


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!


DDS Security ModelConcept Unix Filesystem Security Model DDS Security Model

Subject UserProcess executing for a user

DomainParticipantApplication joining a DDS domain

Protected Objects

DirectoriesFiles

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.joinTopic.createTopic.read (includes QoS)Topic.write (includes QoS)Data.createInstanceData.writeInstanceData.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
