build safe & secure distributed systems - rti huntsville roadshow- 2014 09 25

Your systems. Working as one.

Build Safe & Secure Distributed Systems Meet DoD Open Architecture Requirements and Cyber Security Guidance

Topics

•  IntroducFons •  Open Architecture •  Data DistribuFon Service •  Examples of DDS in OA •  DDS security •  DDS safety •  RTI Connext DDS •  Q&A

2014-‐Sep-‐25 2 © 2014 RTI

Open Architecture

Reality

2014-‐Sep-‐25 © 2014 RTI 5

ImperaFve

•  Affordability

•  “Do more with less”

2014-‐Sep-‐25 © 2014 RTI 6

How

•  Improve reuse •  Reduce maintenance and integraFon Fme

–  Incremental upgrades – New technology inserFon – System of Systems

•  Promote compeFFon – Reduce costs – Foster innovaFon

2014-‐Sep-‐25 © 2014 RTI 7

TradiFonal Approach

2014-‐Sep-‐25 © 2014 RTI 8

TradiFonal Approach

2014-‐Sep-‐25 © 2014 RTI 9

TradiFonal Approach

2014-‐Sep-‐25 © 2014 RTI 10

TradiFonal Approach

•  Hard coded connecFons

•  Up to O(n2) •  Complex •  Hard to maintain, evolve, re-‐use

E.g., sockets, RPC

2014-‐Sep-‐25 © 2014 RTI 11

Result

Time & cost of integraFon, maintenance and upgrades

System Scale and Age

O(n2)

2014-‐Sep-‐25 © 2014 RTI 12

SoluFon: Modularity

2014-‐Sep-‐25 © 2014 RTI 13

Key: Interoperability

Well-‐defined: •  Interfaces •  SemanFcs

2014-‐Sep-‐25 © 2014 RTI 14

Interoperability

Level 0 No Interoperability

Level 6 Conceptual Interoperability

Level 5 Dynamic Interoperability

Level 4 Pragma<c Interoperability

Level 3 Seman<c Interoperability

Level 2 Syntac<c Interoperability

Level 1 Technical Interoperability

Stand alone systems that have no interoperability

Full assump<ons and constraints of meaningful abstrac<on of reality. Fully specified but independent model.

Maintains state changes between systems during run <me. Includes assump<ons and constraints that effect data interchange.

Systems are aware of methods & procedures of other systems. Context is understood by all par<cipa<ng systems.

Meaning of data is exchanged through use of a common informa<on model. The meaning of informa<on is shared and unambiguously defined.

Common structure or common data format for exchanging informa<on. The format of the informa<on exchange is unambiguously defined.

Communica<on protocol for exchanging data. Bits & Bytes are exchanged in an unambiguous manner.

Levels of Conceptual Interoperability Model (LCIM) for Systems Engineering VMASC (Virginia Modeling, Analysis and SimulaFon Center)

2014-‐Sep-‐25 © 2014 RTI 15

ImplementaFon Challenges

•  Demanding technical requirements – Real-‐Fme performance – Reliability, safety, survivability – Dynamic and ad hoc environments

– Unreliable networks • MigraFng exisFng systems

– OA versus other development and funding prioriFes

2014-‐Sep-‐25 © 2014 RTI 17

Data DistribuFon Service

For loose coupling, provides: •  Discovery •  RouFng •  High-‐availability •  QoS enforcement

•  Well-‐define interfaces

•  Standard interoperability Protocol


2014-‐Sep-‐25 © 2014 RTI 19

DDS Standard

•  Interoperability and portability – Data model specificaFon and discovery

– Network protocol – Programming interface

• Managed by Object Management Group (OMG)

Cross-‐vendor source portability!

Cross-‐vendor interoperability!

Standard Protocol

DDS Implementa<on

Standard API Data Model

2014-‐Sep-‐25 © 2014 RTI 20

Peer-‐to-‐Peer CommunicaFon

•  Completely decentralized •  No intermediate servers, message brokers or ESB

•  Low latency •  High scalability •  No single point of failure

DDS-‐RTPS Wire Interoperability Protocol

App or Component

DDS Library

App or Component

DDS Library DDS API

2014-‐Sep-‐25 © 2014 RTI 21

Easy IntegraFon of ExisFng Components

Unmodified App


DDS RouFng Service

Adapter

Unmodified App

DDS RouFng Service

Adapter App or

Component

DDS Library

App or Component

DDS Library

DDS or other protocol

DDS API

New and Updated Applica<ons Exis<ng, Unmodified Applica<ons

2014-‐Sep-‐25 © 2014 RTI 22

Seamless Enterprise-‐Wide ConnecFvity Connect Everything, Everywhere

•  Proximity •  Plajorm •  Language

•  Physical network •  Transport protocol •  Network topology


Seamless data sharing regardless of:

2014-‐Sep-‐25 © 2014 RTI 23

Example: RTI Connext Availability

•  Programming languages and environments

–  C, C++, C#/.NET, Java, Ada –  Lua, Python –  LabVIEW, MATLAB, Simulink, UML –  REST/HTTP

•  OperaFng systems –  Windows, Linux, Unix, Mac OS –  Mobile –  Embedded, real Fme –  Safety criFcal, parFFoned

•  Processor families –  x86, ARM, PowerPC… –  32-‐ and 64-‐bit

•  Transport types –  Shared memory –  LAN (incl. mulFcast) –  WAN / Internet –  Wireless –  Low bandwidth

2014-‐Sep-‐25 © 2014 RTI 24

FoundaFon: Publish/Subscribe

Data Distribution Service

Sensor Data

Control App

Commands

Status

Sensor

Sensor Data

Actuator

Commands

Status

Sensor

Sensor Data

Display App

Sensor Data

Status

2014-‐Sep-‐25 © 2014 RTI 25

Data-‐Centric

As with a database: •  Publishers and subscribers are completely decoupled

–  Require no knowledge of each other –  Adding clients does not affect exisFng applicaFons

•  DDS middleware maintains shared state for system robustness –  ApplicaFons maintain consistent view –  Late joining applicaFons get current snapshot –  Not necessary to persist or reliably deliver all messages

Publish Subscribe

Virtual Global Data Space

Squawk Long Lat Alt 1234 37.4 -122.0 500.0 7654 40.7 -74.0 250.0

Line Flight Dest Arv UA 567 SFO 7:32 AA 432 LAX 9:15 Squawk Line Flight

1234 UA 567 7654 AA 432

2014-‐Sep-‐25 © 2014 RTI 26

Completely Decentralized

Unlike a database: •  ApplicaFons communicate peer-‐to-‐peer •  No central database, server or message broker •  MulFcast for efficient broad data distribuFon •  Event driven •  Data cached locally for instant access

Component

DDS

Component

DDS

Component

DDS

OpFonal Persistence

2014-‐Sep-‐25 © 2014 RTI 27

Support for Mission-‐CriFcal Systems

•  Autonomous operaFon – AutomaFc discovery – No sys admin or centralized infrastructure

•  Non-‐stop: no single point of failure •  QoS control and visibility into real‑Fme behavior, system health

•  Embeddable •  RTI Connext is TRL 9 2014-‐Sep-‐25 © 2014 RTI 28

RPC over DDS

2014 DDS Security

2014 Web-‐Enabled DDS

2013

DDS: Family of SpecificaFons

DDS ImplementaFon

Network / TCP / UDP / IP

App

DDS ImplementaFon

App

DDS ImplementaFon

DDS Spec

2004

DDS Interoperablity

2006

UML Profile for DDS

2008

DDS for Lw CCM

2009

DDS X-‐Types

2010 2012

DDS-‐STD-‐C++ DDS-‐JAVA5

App

2014-‐Sep-‐25 © 2014 RTI 29

RTI Role RTI Role Product Status

Core DDS API DCPS author 1st implementaFon

DDS-‐RTPS Protocol Sole author 1st implementaFon

Based on IEC 61148, which was authored by RTI and Schneider AutomaFon

DDS-‐XTypes Primary author 1st implementaFon Based on prior RTI innovaFon

DDS C++ PSM RFP author; specificaFon co-‐author

EAR available now

DDS Java PSM Sole author Under development

DDS Security Primary author EAR available now

Web-‐enabled DDS

Primary author EAR available now

2014-‐Sep-‐25 © 2014 RTI 30

RTI Role

RTI Role Product Status

UML Profile for DDS

Co-‐submiser

1st implementaFon (3rd-‐parFes) Standard being refined

DDS for lwCCM Co-‐submiser

1st implementaFon (3rd-‐party)

RPC over DDS Primary author

Submission based on current capability

Standard sFll under development

InstrumentaFon RFP author Prototype now

2014-‐Sep-‐25 © 2014 RTI 31

Broad AdopFon and Support

•  RTI Connext alone used by 1,000+ projects •  ~14 implementaFons •  9 vendors have demonstrated interoperability

2014-‐Sep-‐25 © 2014 RTI 32

Interoperability DemonstraFon

OCI ETRI PrismTech IBM RTI Twin Oaks

2014-‐Sep-‐25 © 2014 RTI 33

DDS in OA

Why DistribuFon Middleware?

8.0 Training

5.0 Communications

2.0 Sensors

3.0 Fusion 4.0 BMC2

7.0 Visualization

6.0 Sensor Control

1.0 Common Services

l  Grouping the modules into funcFonal clusters does nothing to change that reality and ease sovware integraFon

UNCLASSIFIED

l  Hawkeye has funcFonally oriented sovware modules

l  Each module talks to many other modules

RIP TRK MSI WAC TDA

ESM SAFE RDR IFF

SEN DSC L4 L16 L11

HMI ACIS

DIA NAV IPCC MCP MUX

FIL TDM

l  Adding new funcFonality cascades integraFon re-‐work across many other modules

CEC

8.0 Training

5.0 Communications

2.0 Sensors

3.0 Fusion 4.0 BMC2

7.0 Visualization

6.0 Sensor Control

1.0 Common Services

RIP TRK CEC MSI WAC RAIDER TDA

DWC

CHAT

ESM SAFE RDR IFF

SEN DSC Distributed Data Fram

ework IPv6 L4 L16 L11

HMI ACIS T4O

DIA NAV IPCC MCP MUX

FIL TDM aADNS TIS

1.0 Common Services

l  Changing the communicaFon between the modules can ease integraFon, when the new ‘Publish Subscribe’ approach is used – each module publishes its output w/o regard to who is receiving it, in contrast to the point-‐to-‐point approach of tradiFonal inter-‐process communicaFon

It’s about an architecture that can assimilate evolving funcFonality, rather than remaining set in Fme

UAS Control Segment (UCS) Architecture

UCS Technical Reference Model

DDS has a number of desirable technical characterisFcs for use in real-‐Fme systems and real-‐Fme control problems. It has demonstrated very low latency or Fme delay and message delivery between DDS nodes. It can also be implemented without the use of intermediate-‐level nodes or servers, which reduces system requirements and complexity. DDS has already been adopted and incorporated into the UAS I‑IPT common grounds control system standard.

46 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088

The FACE approach is a government-industry software standard and business strategy to: •  Acquire affordable software systems •  Rapidly integrate portable capabilities across global defense

programs •  Attract innovation and deploy it quickly and affordably

FACE Approach


Transitioning to Open Interface Architecture

Closed/Proprietary Open

* http://www.forbes.com/sites/darcytravlos/2012/08/22/five-reasons-why-google-android-versus-apple-ios-market-share-numbers-dont-matter/ 2014-Sep-25

© 2014 RTI 47


FACE Architecture - Layered Architecture Example

DDS Benefits for FACE

•  Loose coupling of publish/subscribe •  Flexible communicaFon: 1à1, 1àmany, manyà1, manyàmany

•  Proximity and physical transport independence

•  Easy integraFon with non-‐FACE apps •  FACE TSS is thin layer over DDS

–  Less than 2,000 SLOC –  DDS already supports FACE data model (IDL), serializaFon and deserializaFon

–  ExpediFous path to DO-‐178C cerFficaFon •  Tooling

2014-‐Sep-‐25 © 2014 RTI 49

TSS ConnecFon Mechanism Comparison

RTI D

DS

CORB

A

Sockets

POSIX

Que

ues

Shared

mem

ory

Que

uing

ports

Sampling

ports

Proximity Intra-‐parFFon ● ● ● ● ● ● ●

Inter-‐parFFon ● ● ● ● ●

Inter-‐node ● ● ●

MulFple concurrently ●

DistribuFon One-‐to-‐one ● ● ● ● ● ● ●

One-‐to-‐many ● ● ● ● ●

Many-‐to-‐one ● ● ●

Many-‐to-‐many ● ●

● Unreliable

2014-‐Sep-‐25 © 2014 RTI 50

Airborne System

Airborne System

Flexible IntegraFon Including TSS and Na9ve DDS Apps

FACE UoP

FACE UoP

Local CommunicaFon

TSS Library TSS Library

Rou<ng Service

FACE UoP

FACE UoP

Local CommunicaFon

TSS Library TSS Library

Rou<ng Service

DDS App

DDS App

Local CommunicaFon

DDS Library DDS Library

Rou<ng Service

Ground System

2014-‐Sep-‐25 © 2014 RTI 51

DDS and FACE™ TSS Demo

Android app using DDS to publish data from the

tablet’s sensors

Simulated cockpit display receiving data through FACE

Transport Services Segment (TSS)

2014-‐Sep-‐25 © 2014 RTI 52

Esterel SCADE generated C App Java App

Demo Stack

RTI Connext DDS Micro

RTI implementa<on of FACE TSS


ARM CPU PowerPC CPU

Wind River VxWorks 653 OS

RTI Connext DDS Professional

Android OS

2014-‐Sep-‐25 © 2014 RTI 53

Esterel SCADE generated C App Java App

Interoperability at MulFple Layers All Applica9on Transparent

RTI Connext DDS Micro

RTI implementa<on of FACE TSS


ARM CPU PowerPC CPU

Wind River VxWorks 653 OS

RTI Connext DDS Professional

Android OS

Java ↔ C

DDS API ↔ FACE TSS API

Android ↔ VxWorks 653

ARM ↔ PowerPC

2014-‐Sep-‐25 © 2014 RTI 54

UK MOD Generic Vehicle Architecture

2014-‐Sep-‐25 © 2014 RTI 55

GVA Key Principles

1.  Take account of previous MOD investment; 2.  Be applicable to current and future systems; 3.  Use open, modular and scaleable architectures and systems; 4.  Facilitate technology inserFon (upgrade, update, replace, repair,

remove and addiFon); 5.  Not needlessly implement in hardware any funcFonality that can

be implemented in sovware; 6.  Take a ‘whole plajorm’ systems view, though life (including cost); 7.  Be done in conjuncFon with industry and all relevant MOD

stakeholders; 8.  Be MOD owned and maintained; 9.  Specify the minimum necessary to achieve MOD's desired benefits

avoiding unnecessary constraint in implementaFon. 2014-‐Sep-‐25 © 2014 RTI 56

Generic Vehicle Architecture (GVA)

2014-‐Sep-‐25 © 2014 RTI 57

Future Interoperability of Camp ProtecFon Systems Project (FICAPS)

2014-‐Sep-‐25 © 2014 RTI 58

FICAPS Enables:

•  Real-‐Fme informaFon exchange between Camp ProtecFon Systems (CPS) of different naFons (also via SatCom)

•  Interoperability of CPS equipment to allow easy and quick replacement of equipment (plug-‐and-‐play)

• MulFnaFonal use of a naFonal system due to a mulFlingual Human machine interface

•  Enhancement of CPS capabiliFes by adding new equipment

2014-‐Sep-‐25 © 2014 RTI 59

FICAPS Architecture

2014-‐Sep-‐25 © 2014 RTI 60

EUROCONTROL Flight Object Interoperability EUROCAE ED-‐133

2014-‐Sep-‐25 © 2014 RTI 61

GE Healthcare

RevoluFon®

"GE Healthcare chose the DDS standard because it can handle many classes of intelligent machines. RTI Connext DDS saFsfies the demanding requirements of our devices, and RTI has the depth and experience necessary to partner with us in order to meet our stringent standards. AddiFonally, RTI's Connext DDS allows us to standardize on a single communicaFons plajorm across product lines." -‐-‐ J Gustavo Perez, General Manager for

MI&CT Engineering

2014-‐Sep-‐25 © 2014 RTI 62

Audi: Modular HIL Bus

CHALLENGES AND APPROACH

The previous ECU-centric system architecture with its point-to-point com-munication infrastructure is no longer an effi cient design approach. Automo-tive electronic systems are becoming truly distributed to achieve increased system functionality by tightly coupling ECUs. These changes encourage a signi-fi cantly revised approach to automotive system test. This shift in system design is refl ected in the evolution of ISO26262 [1], derived from IEC61508 [2], with its focus on functional safety assurance. It has a huge impact on automotive test platforms, Hardware-in-the-loop(HiL) simulation, test platform provider. Audi is responding to these challenges by radically re-thinking the architecture of the HiL test platform and defi ning a next generation approach.

The new approach introduces the con-cept of a HiL-Bus to integrate the functio-nality of multiple existing HiL sub-sys-tems and meet the needs of a function-centric test environment.

FUNCTIONALITY THROUGH DISTRIBUTED ECUS

We need to start by describing the shift towards function-centric testing from the perspective of automotive design. Here are a few examples: : A simple “air bag computer” fi res the

air bags at the time of a crash. This ECU now becomes an integral element of a complex safety sub-system with more safety functions. The safety computer has to have an automatic crash detec-tion capability (“Audi pre-sense”) and it has to perform fully automated braking support, deploy the air bags, tension the

AUTHORS

CONSTANTIN BRÜCKNERis working in the Department

Hardware-in-the-Loop Functional Test at Audi AG in Ingolstadt (Germany).

BETTINA SWYNNERTONis Technical Manager EMEA at Real-Time

Innovations Inc. in Sunnyvale (USA).

A NEW ARCHITECTURE FOR AUTOMOTIVE HARDWARE-IN-THE-LOOP TESTAs automotive electronic system design evolves, so must the HiL testbench and automotive test platforms. The

fundamental functional design approach has been modular and ECU-centric, but the ECU count has steadily

increased. The next big shift is to achieve functionality through the integration of multiple ECUs. Audi is responding

to these challenges by radically re-thinking the architecture of the HiL test platform and defi ning a next generation

approach. The new approach introduces the concept of a HiL-Bus to integrate the functionality of multiple existing

HiL sub-systems and meet the needs of a modular best-in-class test ecosystem. By using a data orientedapproach

the complexity of the testbench is reduced making it easier to integrate hardware and software products from

different vendors. One of the enabling technologies (Connext DDS) is developed by Real Time Innovations Inc.

DEVELOPMENT HARDWARE-IN-THE-LOOP

40

Hardware-in-the-Loop

2014-‐Sep-‐25 © 2014 RTI 63

Medical Device Interoperability

•  100,000 to 200,000 annual preventable deaths in US hospitals

–  Hospital error is 6th leading cause of preventable death

•  $30b in wasted cost •  Lack of clinical decision support

–  No “smart alarms” •  CorrelaFon/fusion of data from

mulFple devices –  Alarm faFgue

•  OR: 70% of anesthesiologists disable clinical alarms

•  ICU: 86% false alarms –  Unsynchronized clocks

•  Manually device configuraFon is error prone (e.g., ORàICU)

2014-‐Sep-‐25 © 2014 RTI 71

Integrated Clinical Environment (ICE) Standard (ASTM F2761)

•  Developed by Medical Device "Plug-‐and-‐Play" Interoperability Program (MPnP)

•  Specifies interoperability for medical devices

•  Encompasses all ICU & operaFng room devices –  From blood pressure cuffs to

intravenous pumps to venFlators

–  Complete logging –  AutomaFc error detecFon –  Beser care

•  OpenICE reference implementaFon built on RTI Connext DDS

2014-‐Sep-‐25 © 2014 RTI 72

DDS Security

Q4 2013 Reported Cyber Incidents to U.S. CriFcal Infrastructure

hsp://ics-‐cert.us-‐cert.gov/monitors/ICS-‐MM201312

2014-‐Sep-‐25 © 2014 RTI 75

Threats

2014-‐Sep-‐25 © 2014 RTI 76

Threats Alice: Allowed to publish topic T Bob: Allowed to subscribe to topic T Eve: Non-‐authorized eavesdropper Trudy: Intruder Trent: Trusted infrastructure service Mallory: Malicious insider

1.  Unauthorized subscripFon 2.  Unauthorized publicaFon 3.  Tampering and replay 4.  Unauthorized access to data by

infrastructure services

2014-‐Sep-‐25 © 2014 RTI 77

Security Terms: a Safe-‐Deposit Box

•  AuthenFcaFon: The bank knows who you are. You must show ID.

•  Access Control: The bank only lets those on an access list into your box.

•  ConfidenFality: You are alone in the room. Nobody can see the contents of the box.

•  Integrity: The box is sealed. If anybody touches it you will know.

•  Non repudiaFon: You sign when you come in and out so you can’t claim that you weren’t there.

•  Availability: The bank is always open. 2014-‐Sep-‐25 © 2014 RTI 78

Security Boundaries

System Boundary Transport Data

2014-‐Sep-‐25 © 2014 RTI 79

System Boundary

•  Across security domains •  Independent of how data is secured within a system

System 1

•  Diode •  Filter •  Downgrade

System 2 Cross-‐Domain Guard

2014-‐Sep-‐25 © 2014 RTI 80

Transport Layer ExisFng App

TCP/IP Capable Network

DDS RouFng Service

Adapter

ExisFng App

DDS RouFng Service

Adapter

NaFve DDS App

DDS Library

NaFve DDS APP

DDS Library

Secure Transport

Secure Transport

Secure Transport

Secure Transport

Typically SSL, TLS or DTLS

2014-‐Sep-‐25 © 2014 RTI 81

Secure Data Transfer

1.  AuthenFcate – Verify idenFty

2.  Securely exchange cryptographic keys 3.  Use keys to:

– Encrypt data – Add a message authenFcaFon code

App 1

App 2

2014-‐Sep-‐25 © 2014 RTI 82

Secure Channel for Cross-‐Network Bridging

System 1 LAN

RouFng Service

System 2 LAN

RouFng Service

TLS WAN/ Internet

Can be used with or without

a firewall

2014-‐Sep-‐25 © 2014 RTI 83

ConnecFng Clients Across a WAN

•  Remote access to cloud or data center –  Clients communicate with parFcipants in data center or cloud LAN, not with each other

–  Clients behind firewalls – Only one public address required

•  Example: Exposing a service to end-‐user clients

Remote App

RouFng Service

Remote App

Remote App

TLS

2014-‐Sep-‐25 © 2014 RTI 84

LimitaFons of Transport Security: No Inherent Access Control

•  You’re authenFcated or you’re not •  Less an issue for centralized systems

– E.g.: non-‐real-‐Fme IT and consumer IoT systems – Broker centrally manages access control

Device

App App App

Device Device

Message Broker

•  Poor performance and scalability

•  Single point of failure/failover

2014-‐Sep-‐25 © 2014 RTI 85

LimitaFons of Transport Security: Overall Poor Performance and Scalability

•  No mulFcast support (even with DTLS over UDP) –  Broad data distribuFon is very inefficient

•  Usually runs over TCP: poor latency and jiser •  Requires a network robust enough to support IP and TCP

•  All data treated as reliable –  Even fast changing data that could be “best effort”

•  Always encrypts all data, metadata and protocol headers –  Even if some data does not have to be private

•  Security is at a very gross level

2014-‐Sep-‐25 © 2014 RTI 86

Introducing DDS Security

First security standard to address performance, safety and security requirements of mission‑criFcal and real-‐Fme systems

Secure DDS

Sensors Actuators

Streaming AnalyFcs & Control

HMI/UI IT, Cloud & SoS ConnecFvity

2014-‐Sep-‐25 © 2014 RTI 87

DDS Security

•  Security extensions to DDS standard •  Requires trivial or no change to exisFng DDS apps and adapters

•  Runs over any transport –  Including low bandwidth, unreliable –  Does not require TCP or IP –  MulFcast for scalability, low latency

•  Plugin architecture –  Built-‐in defaults –  Customizable via standard API

•  Completely decentralized –  High performance and scalability –  No single point of failure

Secure DDS library

AuthenFcaFon

Access Control

EncrypFon

Data Tagging

Logging

ApplicaFon

Any Transport (e.g., TCP, UDP, mulFcast,

shared memory, )

2014-‐Sep-‐25 © 2014 RTI 88

Service Plugin Purpose Interactions Authentication Authenticate the principal that is

joining a DDS Domain.

Handshake and establish shared secret between participants

The principal may be an application/process or the user associated with that application or process. Participants may messages to do mutual authentication and establish shared secret

Access Control Decide whether a principal is allowed to perform a protected operation.

Protected operations include joining a specific DDS domain, creating a Topic, reading a Topic, writing a Topic, etc.

Cryptography Perform the encryption and decryption operations. Create & Exchange Keys. Compute digests, compute and verify Message Authentication Codes. Sign and verify signatures of messages.

Invoked by DDS middleware to encrypt data, compute and verify MAC, compute & verify Digital Signatures

Logging Log all security relevant events Invoked by middleware to log

Data Tagging Add a data tag for each data sample

Standard CapabiliFes

AuthenFcaFon •  X.509 Public Key Infrastructure (PKI) with a pre-‐configured shared CerFficate Authority (CA)

•  Digital Signature Algorithm (DSA) with Diffie-‐Hellman and RSA for authenFcaFon and key exchange

Access Control •  Specified via permissions file signed by shared CA •  Control over ability to join systems, read or write data

topics Cryptography •  Protected key distribuFon

•  AES128 and AES256 for encrypFon •  HMAC-‐SHA1 and HMAC-‐SHA256 for message authenFcaFon

and integrity Data Tagging •  Tags specify security metadata, such as classificaFon level

•  Can be used to determine access privileges (via plugin) Logging •  Log security events to a file or distribute securely over

Connext DDS

2014-‐Sep-‐25 © 2014 RTI 91

Security Flow Domain

ParFcipant Create Fails

AuthenFcate DP? Yes

AuthenFcate DP?

No

Ignore Remote DP

AuthenFcate Remote DP?

No

Yes

No

Yes

Access OK? Ignore remote endpoint

Message security

Endpoint Create Fails

Yes Access OK?

No

Create Domain

ParFcipant

Create Endpoints

Discover remote

Endpoints

Send/Receive data

Discover remote DP

2014-‐Sep-‐25 © 2014 RTI 92

ProtecFons

Protected Objects

Domain (by domain_id) Topic (by Topic name) DataObjects (by Instance/Key)

Protected OperaFons

Domain.join Topic.create Topic.read (includes QoS) Topic.write (includes QoS) Data.createInstance Data.writeInstance Data.deleteInstance

2014-‐Sep-‐25 © 2014 RTI 93

Control over EncrypFon

•  Scope – Discovery data – Metadata – Data

•  For each: – Encrypt – Sign

•  OpFmizes performance by only encrypFng data that must be private

2014-‐Sep-‐25 © 2014 RTI 94

DDS Security Status

•  SpecificaFon adopted March 2014 –  Considered “Beta” for 1 year –  RTI chairing FinalizaFon Task Force

•  SpecificaFon provides a framework for securing DDS systems –  Built-‐in plugins provide a common approach for applicaFons without specialized requirements

–  Custom plugins can be developed to match more specialized deployments and integrate with exisFng infrastructure and hardware

•  Early Access Release available now from RTI

2014-‐Sep-‐25 © 2014 RTI 97

SpecificaFon Reviewers Include:

•  GE •  Intel •  Siemens •  Technicolor •  NSWC •  General Dynamics

•  THALES •  SAAB •  Cassidian •  QineFQ & UK MOD •  Lockheed •  Raytheon

•  None found any show stoppers •  Several contacted OMG to urge adopFon

2014-‐Sep-‐25 © 2014 RTI 98

Data Security Requirements

Data Item Authen<ca-‐<on

Access Control

Integrity Non-‐repudia<on

Confiden<ality

Control traffic X X X X X

Data Telemetry traffic

X X

Physical Security Data

X X X

Engineering maintenance

X

Source: www.sxc.hu

2014-‐Sep-‐25 © 2014 RTI 100

Test Environment

•  Real World Environment –  Transmission switching substaFon

–  Real substaFon equipment

•  PNNL powerNET Testbed –  Remote connecFvity –  Local control room demonstraFon environment

– Dynamically reconfigurable

2014-‐Sep-‐25 © 2014 RTI 101

Control StaFon

DNP3 Master Device

Transmission SubstaFon

DNP3 Slave Device

RTI and PNNL Grid Security Retrofit

RTI RouFng Service

ComProcessor

RTI RouFng Service Gateway

DNP3 Slave Device

DNP3 over RS232/485

DNP3 over Ethernet DNP3 over DDS

RTI RouFng Service Gateway

DDS LAN

DDS LAN

RTI RouFng Service

ComProcessor

IP Router

IP Router

DDS over WAN

Secure DDS

over UDP

Asack Detector

Display

Scada Converter

Anomaly Detector

EffecFve DNP3 connecFon

Details at hsp://blogs.rF.com

2014-‐Sep-‐25 © 2014 RTI 103

Support for Safety CriFcal Systems

DDS Inherently Well-‐Suited to Safety CriFcal Systems

•  Non-‐stop availability – No single point of failure – …including run-‐Fme services – Support for redundant networks – AutomaFc failover between redundant publishers – Dynamic upgrades

•  Visibility into missed deadlines and presence •  Proven in hundreds of mission criFcal systems •  Used in US DoD TRL 9 systems 2014-‐Sep-‐25 © 2014 RTI 105

High-‐Assurance Security: DO-‐178C

•  Guideline •  Used by FAA as basis for cerFficaFon – Aircrav are “cerFfied” – Sovware code developed under DO-‐178 provides “cerFficaFon evidence”

•  Increasingly adopted for military aircrav •  Likely required for UAS integraFon into NAS 2014-‐Sep-‐25 © 2014 RTI 106

DO-‐178 Safety Levels

Level Failure Condi<on Typical % of avionics code

A Catastrophic (may be total loss of aircrav) 15%

B Hazardous/Severe (serious injuries) 35%

C Major (minor injuries) 30%

D Minor (inconvenience) 15%

E No effect 5%

2014-‐Sep-‐25 © 2014 RTI 107

CerFficaFon Costs

•  GeneraFon of DO-‐178C evidence typically costs $50-‐$100 per ELOC

•  Process objecFves must be met

•  All must be documented •  Code must be clean

–  Testable –  No dead code –  DeterminisFc

Level Process Objec<ves

Code Coverage

A 71 Level B and 100% of MCDC

B 69 Level C plus 100% of DC

C 62 Level D plus 100% of SC

D 26 100% of Requirements

E 0 None

2014-‐Sep-‐25 © 2014 RTI 108

Tenets Of Safety-‐CriFcal Sovware

•  Reduce code size •  Consider testability in design •  Design code to be determinisFc

2014-‐Sep-‐25 © 2014 RTI 109

Connext DDS Cert

•  Small footprint, cerFfiable DDS –  ~25K ELOC –  No dynamic memory allocaFon –  StaFc endpoint discovery only

•  Follows OMG DDS specificaFon –  C and C++ APIs –  Subset of minimum profile

•  ApplicaFon portability and interoperability with full DDS –  Including RouFng Service

•  CompaFble with RTI’s FACE interface •  DO-‐178C Level A cerFficaFon available 1H 2015

2014-‐Sep-‐25 © 2014 RTI 110

DO-‐178C Level A CerFficaFon Evidence

•  Plan for Sovware Aspects of CerFficaFon (PSAC)

•  Sovware Development Plan (SDP) –  Requirements standards –  Design standards –  Code standards

•  Sovware VerificaFon Plan (SVP) •  Sovware ConfiguraFon

Management Plan (SCM) •  Sovware Quality Assurance Plan

•  Sovware Requirements Data •  Design DescripFon •  Traceability •  SQA Records •  SCM Records •  Sovware ConfiguraFon Index •  Sovware VerificaFon Cases and

Procedures •  Sovware VerificaFon Results •  Sovware Accomplishment

Summary

CerFficaFon evidence can be re-‐used across programs 2014-‐Sep-‐25 © 2014 RTI 111

Savings from DDS CerFficaFon Evidence

30,000 ELOC 20,000 ELOC 10,000 ELOC

Level A $3,000,000 $2,000,000 $1,000,000

Level B $2,550,000 $1,700,000 $850,000

Level C $1,800,000 $1,200,000 $600,000

•  DDS cerFficaFon evidence available at fracFon of cost

•  Availability at start of project also reduces risk

2014-‐Sep-‐25 © 2014 RTI 112

Summary

•  CerFfiable DDS designed for safety-‐criFcal applicaFons now available – Connext DDS Cert – Standards compliant – Small footprint

•  Code is cerFfiable to DO-‐178 Level A – Minimal lines of code – DeterminisFc

•  CerFficaFon evidence is reusable 2014-‐Sep-‐25 © 2014 RTI 113

RTI Connext DDS

Secure Cert Micro Professional

Connext DDS Product Family


Full DDS Libraries

RouFng Service Database

IntegraFon

DDS Subset

DDS Subset

DO-‐178C CerFfiable

Admin Console

Monitoring

Microsov Excel

Recording

Replay

Wireshark

Persistence

Logging

Prototyper

General Purpose & Real-‐Time Apps

Remote Apps ExisFng Apps and Devices

Adapter

Small Footprint Apps

High Assurance Apps

JMS API

Security Plugins

2014-‐Sep-‐25 © 2014 RTI 116

ApplicaFon Code

Data Types

Data-‐Centric Publish/Subscribe

AutomaFc Discovery

History Cache

Monitoring

Local API & rem

ote

Quality of Svc API &

file-‐based

OperaFng System and Network Stack Windows, Linux, Unix, embedded, RTOS

Interface Compiler

Interface DefiniFons •  IDL •  XML / XSD •  WSDL

Shared M

emory

UDPv4

ucast & m

cast

TCP

TLS & DTLS

(SSL)

UDPv6

ucast & m

cast

Custom

Pluggable Transport Interface

JMS DDS: C, C++, C#, Java, Ada

Generated

APIs – event-‐driven, polled & SQL query

Reliability • DDS-‐RTPS Wire Protocol

Dynamically defined (API) Custom Pre-‐defined

<XML>

Pluggable Discovery Peer-‐to-‐peer File-‐based Custom

WAN

<XML>

Request/reply, Guaranteed Messaging

Security

Security

AuthenFcaFon EncrypFon

Access Control Tagging Logging

2014-‐Sep-‐25 © 2014 RTI 117

Q&A and Discussion

Next Steps – Learn More

•  Contact RTI –  Demo, Q&A

•  Download sovware –  www.rF.com/downloads –  Free trial with comprehensive tutorial –  RTI Shapes Demo

•  Watch videos & webinars, read whitepapers –  www.rF.com/resources –  www.youtube.com/realFmeinnovaFons

2014-‐Sep-‐25 © 2014 RTI 119

Summary

•  AdopFon of OA is essenFal – Affordability –  CompeFFveness

•  DDS is well-‐suited for OA –  Loose coupling – Meets real-‐Fme, mission-‐criFcal requirements –  Leading-‐edge security and safety –  Proven foundaFon –  Eases exisFng system migraFon/modernizaFon

•  RTI Connext provides a robust DDS soluFon

2014-‐Sep-‐25 © 2014 RTI 120