build safe & secure distributed systems - rti huntsville roadshow- 2014 09 25
Post on 26-May-2015
143 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
2014-‐Sep-‐25 © 2014 RTI 4
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
Data DistribuFon Service
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-‐RTPS Wire Interoperability Protocol
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
Data DistribuFon Service
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
47 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088
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
48 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088
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
DDS-‐RTPS Wire Interoperability Protocol
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
DDS-‐RTPS Wire Interoperability Protocol
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
2014-‐Sep-‐25 © 2014 RTI 89
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
Example Domain Governance
2014-‐Sep-‐25 © 2014 RTI 95
Example Permissions
2014-‐Sep-‐25 © 2014 RTI 96
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
Security Example: Power Grid
In Partnership with PNNL
© 2014 RTI
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
SCADA Equipment Setup
2014-‐Sep-‐25 © 2014 RTI 102
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
DDS Standard Interoperability
Portability Real-‐Fme QoS
DDS DifferenFaFon
2014-‐Sep-‐25 © 2014 RTI 115
Secure Cert Micro Professional
Connext DDS Product Family
DDS-‐RTPS Wire Interoperability Protocol
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
top related