Download as PDF, PPTX
Uploaded byReal-Time Innovations (RTI)
Build Safe & Secure Distributed Systems - RTI Huntsville Roadshow- 2014 09 25
The document discusses the use of the Data Distribution Service (DDS) and DDS middleware to implement open architecture requirements for distributed systems. DDS provides a publish-subscribe communication model that loosely couples applications and supports interoperability, real-time performance, reliability, and flexibility to integrate new components. The presentation provides examples of how DDS has been used in defense and aerospace systems to meet open architecture mandates.
More Related Content
Similar to Build Safe & Secure Distributed Systems - RTI Huntsville Roadshow- 2014 09 25
More from Real-Time Innovations (RTI)
Build Safe & Secure Distributed Systems - RTI Huntsville Roadshow- 2014 09 25
- 1. Your systems. Working as one. Build Safe & Secure Distributed Systems Meet DoD Open Architecture Requirements and Cyber Security Guidance
- 2. Topics • IntroducFons • Open Architecture • Data DistribuFon Service • Examples of DDS in OA • DDS security • DDS safety • RTI Connext DDS • Q&A 2014-‐Sep-‐25 © 2014 RTI 2
- 3.
- 4. 2014-‐Sep-‐25 © 2014 RTI 4
- 5. Reality 2014-‐Sep-‐25 © 2014 RTI 5
- 6. ImperaFve • Affordability • “Do more with less” 2014-‐Sep-‐25 © 2014 RTI 6
- 7. 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
- 8. TradiFonal Approach 2014-‐Sep-‐25 © 2014 RTI 8
- 9. TradiFonal Approach 2014-‐Sep-‐25 © 2014 RTI 9
- 10. TradiFonal Approach 2014-‐Sep-‐25 © 2014 RTI 10
- 11. 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
- 12. Result Time & cost of integraFon, maintenance and upgrades System Scale and Age O(n2) 2014-‐Sep-‐25 © 2014 RTI 12
- 13. SoluFon: Modularity 2014-‐Sep-‐25 © 2014 RTI 13
- 14. Key: Interoperability Well-‐defined: • Interfaces • SemanFcs 2014-‐Sep-‐25 © 2014 RTI 14
- 15. 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 Level 0 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. Stand alone systems that have no interoperability Levels of Conceptual Interoperability Model (LCIM) for Systems Engineering VMASC (Virginia Modeling, Analysis and SimulaFon Center) 2014-‐Sep-‐25 © 2014 RTI 15
- 17. 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
- 18.
- 19. 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
- 20. DDS Standard •Interoperability and portability – Data model specificaFon and discovery – Network protocol – Programming interface • Managed by Object Management Group (OMG) Cross-‐vendor source portability! Standard API Data Model DDS Implementa<on Standard Protocol Cross-‐vendor interoperability! 2014-‐Sep-‐25 © 2014 RTI 20
- 21. Peer-‐to-‐Peer CommunicaFon App or Component DDS Library • Completely App or Component DDS Library decentralized • No intermediate servers, message brokers or ESB • Low latency • High scalability • No single point of failure DDS-‐RTPS Wire Interoperability Protocol DDS API 2014-‐Sep-‐25 © 2014 RTI 21
- 22. Easy IntegraFon of ExisFng Components Unmodified App Adapter DDS RouFng Service DDS-‐RTPS Wire Interoperability Protocol Unmodified App Adapter DDS RouFng Service 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
- 23. Seamless Enterprise-‐Wide ConnecFvity Connect Everything, Everywhere Data DistribuFon Service Seamless data sharing regardless of: • Proximity • Plajorm • Language • Physical network • Transport protocol • Network topology 2014-‐Sep-‐25 © 2014 RTI 23
- 24. 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
- 25. FoundaFon: Publish/Subscribe DataDistribution Service Data Sensor Commands Status Control App Sensor Data Sensor Commands Status Actuator Sensor Data Sensor Data Sensor Status Display App 2014-‐Sep-‐25 © 2014 RTI 25
- 26. Data-‐Centric Publish As with a database: • Publishers Line Flight Dest Arv UA 567 SFO 7:32 AA 432 LAX 9:15 Squawk Line Flight Squawk Long Lat Alt 1234 37.4 -122.0 500.0 7654 40.7 -74.0 250.0 1234 UA 567 7654 AA 432 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 Subscribe Virtual Global Data Space 2014-‐Sep-‐25 © 2014 RTI 26
- 27. Completely Decentralized Component DDS Component DDS Unlike a database: • ApplicaFons Component DDS 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 OpFonal Persistence 2014-‐Sep-‐25 © 2014 RTI 27
- 28. 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
- 29. 2014 RPC over DDS 2014 DDS Security DDS: Family of SpecificaFons 2013 Web-‐Enabled DDS DDS 2008 2009 ImplementaFon Network / TCP / UDP / IP App DDS ImplementaFon App DDS ImplementaFon 2010 DDS Spec 2004 DDS 2006 Interoperablity UML Profile for DDS DDS for Lw CCM DDS X-‐Types 2012 DDS-‐STD-‐C++ DDS-‐JAVA5 App 2014-‐Sep-‐25 © 2014 RTI 29
- 30. 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
- 31. 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
- 32. 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
- 33. Interoperability DemonstraFon OCI ETRI PrismTech IBM RTI Twin Oaks 2014-‐Sep-‐25 © 2014 RTI 33
- 34.
- 36. Why DistribuFon Middleware? 1.0 Common Services 1.0 Common Services MUX MUX DWC 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 RDR IFF ESM SAFE L4 L11 L16 SEN DSC HMI ACIS DIA NAV MCP IPCC 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 RIP CEC TRK MSI WAC TDA RAIDER CHAT RDR IFF ESM SAFE SEN DSC Distributed Data Framework L4 L11 L16 IPv6 HMI ACIS T4O DIA NAV MCP IPCC FIL TDM aADNS TIS 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
- 42. UAS Control Segment (UCS) Architecture
- 43. UCS Technical Reference Model
- 44. 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. FACE Approach TheFACE 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 46 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088
- 47. Transitioning to Open Interface Architecture Closed/Proprietary Open © 2014 RTI * 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 47 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088 47
- 48. FACE Architecture -Layered Architecture Example 48 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088
- 49. 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
- 50. TSS ConnecFon Mechanism Comparison RTI DDS CORBA Sockets POSIX Queues Shared memory Queuing 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
- 51. Airborne System Flexible IntegraFon Including TSS and Na9ve DDS Apps Airborne System FACE UoP FACE UoP TSS Library TSS Library Local CommunicaFon Rou<ng Service FACE UoP FACE UoP TSS Library TSS Library Local CommunicaFon Rou<ng Service DDS App DDS App DDS Library DDS Library Local CommunicaFon Rou<ng Service Ground System 2014-‐Sep-‐25 © 2014 RTI 51
- 52. 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
- 53. Esterel SCADE Java App generated C App Demo Stack RTI Connext DDS Micro RTI implementa<on of FACE TSS RTI Connext DDS Professional Wind River VxWorks 653 OS DDS-‐RTPS Wire Interoperability Protocol ARM CPU PowerPC CPU Android OS 2014-‐Sep-‐25 © 2014 RTI 53
- 54. Esterel SCADE Java App generated C App Interoperability at MulFple Layers All Applica9on Transparent RTI Connext DDS Micro RTI implementa<on of FACE TSS RTI Connext DDS Professional Wind River VxWorks 653 OS DDS-‐RTPS Wire Interoperability Protocol ARM CPU PowerPC CPU Android OS Java ↔ C DDS API ↔ FACE TSS API Android ↔ VxWorks 653 ARM ↔ PowerPC 2014-‐Sep-‐25 © 2014 RTI 54
- 55. UK MOD Generic Vehicle Architecture 2014-‐Sep-‐25 © 2014 RTI 55
- 56. 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
- 57. Generic Vehicle Architecture (GVA) 2014-‐Sep-‐25 © 2014 RTI 57
- 58. Future Interoperability of Camp ProtecFon Systems Project (FICAPS) 2014-‐Sep-‐25 © 2014 RTI 58
- 59. 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
- 60. FICAPS Architecture 2014-‐Sep-‐25 © 2014 RTI 60
- 61. EUROCONTROL Flight Object Interoperability EUROCAE ED-‐133 2014-‐Sep-‐25 © 2014 RTI 61
- 62. 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
- 63. Audi: Modular HIL Bus DEVELOPMENT HARDWARE-IN-THE-LOOP Hardware-in-the-Loop A NEW ARCHITECTURE FOR AUTOMOTIVE HARDWARE-IN-THE-LOOP TEST As 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 2014-‐Sep-‐25 © 2014 RTI 63
- 71. 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
- 72. 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
- 73.
- 75. 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
- 76. Threats 2014-‐Sep-‐25 © 2014 RTI 76
- 77. 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
- 78. 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
- 79. Security Boundaries System Boundary Transport Data 2014-‐Sep-‐25 © 2014 RTI 79
- 80. 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
- 81. Transport Layer ExisFng App Adapter DDS RouFng Service TCP/IP Capable Network ExisFng App Adapter DDS RouFng Service 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
- 82. 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
- 83. 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
- 84. 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
- 85. 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 App Device App App Message Broker Device Device • Poor performance and scalability • Single point of failure/failover 2014-‐Sep-‐25 © 2014 RTI 85
- 86. 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
- 87. Introducing DDS Security First security standard to address performance, safety and security requirements of mission‑criFcal and real-‐Fme systems HMI/UI Secure DDS Streaming AnalyFcs & Control IT, Cloud & SoS ConnecFvity Sensors Actuators 2014-‐Sep-‐25 © 2014 RTI 87
- 88. 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
- 89. 2014-‐Sep-‐25 © 2014 RTI 89
- 90. Service Plugin PurposeInteractions 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
- 91. 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
- 92. Security Flow Domain ParFcipant Create Fails AuthenFcate AuthenFcate Yes DP? 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 DP Discover remote Endpoints Send/ Receive data 2014-‐Sep-‐25 © 2014 RTI 92
- 93. 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
- 94. 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
- 95. Example Domain Governance 2014-‐Sep-‐25 © 2014 RTI 95
- 96. Example Permissions 2014-‐Sep-‐25 © 2014 RTI 96
- 97. 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
- 98. 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
- 99. Security Example: Power Grid In Partnership with PNNL © 2014 RTI
- 100. 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 X X traffic Physical Security Data X X X Engineering maintenance X Source: www.sxc.hu 2014-‐Sep-‐25 © 2014 RTI 100
- 101. 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
- 102. SCADA Equipment Setup 2014-‐Sep-‐25 © 2014 RTI 102
- 103. RTI and PNNL Grid Security Retrofit Control StaFon DNP3 Master Device Transmission SubstaFon DNP3 Slave Device RTI RouFng Service Gateway RTI RouFng Service ComProcessor 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 Asack Detector Scada Converter Anomaly Detector Display Secure DDS over UDP EffecFve DNP3 connecFon Details at hsp://blogs.rF.com 2014-‐Sep-‐25 © 2014 RTI 103
- 104. Support for Safety CriFcal Systems
- 105. 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
- 106. 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
- 107. 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
- 108. 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
- 109. Tenets Of Safety-‐CriFcal Sovware • Reduce code size • Consider testability in design • Design code to be determinisFc 2014-‐Sep-‐25 © 2014 RTI 109
- 110. 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
- 111. 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
- 112. 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
- 113. 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
- 114.
- 115. DDS DifferenFaFon DDS Standard Interoperability Portability Real-‐Fme QoS 2014-‐Sep-‐25 © 2014 RTI 115
- 116. Secure Professional Micro Cert 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
- 117. ApplicaFon Code Data Types Dynamically defined (API) Custom Pre-‐defined DDS: C, C++, C#, Java, Ada JMS Data-‐Centric Publish/Subscribe AutomaFc Discovery History Cache Monitoring Local API & remote 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 Memory UDPv4 ucast & mcast TCP TLS & DTLS (SSL) UDPv6 ucast & mcast Custom Pluggable Transport Interface Generated APIs – event-‐driven, polled & SQL query Reliability • DDS-‐RTPS Wire Protocol <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
- 118.
- 119. 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
- 120. 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