Downloaded 140 times
![Security Model Example:
UNIX FileSystem (simplified)
• Subjects: Users, specifically processes executing on behalf of a specific userid
• Protected Objects: Files and Directories
• Protected Operations on Objects:
– Directory.list, Directory.createFile, Directory.createDir, Directory.removeFile,
Directory.removeDir, Directory.renameFile
– File.view, File.modify, File.execute
• Access Control Model:
– A subject is given a userId and a set of groupId
– Each object is assigned a OWNER and a GROUP
– Each Object is given a combination of READ, WRITE, EXECUTE permissions
for the assigned OWNER and GROUP
– Each protected operation is mapped to a check, for example
• File.view is allowed if and only if
– File.owner == Subject.userId AND File.permissions(OWNER) includes READ
– OR File.group IS-IN Subject.groupId[] AND File.permissions(GROUP) includes READ
©2016 Real-Time Innovations, Inc.](https://image.slidesharecdn.com/datadistributionservicesecurityandtheindustrialinternetofthings-160115190450/75/Data-Distribution-Service-Security-and-the-Industrial-Internet-of-Things-31-2048.jpg)
Uploaded byReal-Time Innovations (RTI)
Data Distribution Service Security and the Industrial Internet of Things
This document discusses data distribution service (DDS) security for the industrial internet of things (IIoT). It provides background on DDS and the IIoT. It then discusses how DDS security works, including pluggable security architectures, authentication, access control, and message security. The goal of DDS security is to prevent unauthorized access to data in the global data space shared by DDS applications. Built-in security capabilities include X.509 authentication, access control configuration, and encryption/message authentication algorithms.
More Related Content
Similar to Data Distribution Service Security and the Industrial Internet of Things
Data Distribution Service Security and the Industrial Internet of Things
- 1. Data Distribution ServiceSecurity and the Industrial Internet of Things Hamed Soroush, Ph.D Senior Research Security Engineer, IIC Security Working Group Co-Chair
- 2. Outline • Background onIndustrial Internet of Things • Background on Data Distribution Service • Data Distribution Service Security ©2016 Real-Time Innovations, Inc.
- 3. What is theInternet of Things? Industrial Internet of Things (IIoT)Consumer Internet of Things (CIoT) Cyber-Physical Systems (CPS) ©2016 Real-Time Innovations, Inc.
- 4. World Economic Forum2015 • The Industrial Internet will transform many industries, including: – Manufacturing – Oil and gas – Agriculture – Mining – Transportation – Healthcare • …and dwarf the consumer side • Collectively, these account for nearly two-thirds of the world economy ©2016 Real-Time Innovations, Inc.
- 5. ©2016 Real-Time Innovations,Inc. 220+ companies Goal: build and prove a common architecture that interoperates between vendors and across industries
- 6.
- 7. RTI’s Experience • Designedinto over $1 T of IIoT – Healthcare – Transportation – Communications – Energy – Industrial – Defense • 15+ Standards & Consortia Efforts – Interoperability – Multi-vendor ecosystems ©2016 Real-Time Innovations, Inc.
- 8. RTI Named MostInfluential IIoT Company ©2016 Real-Time Innovations, Inc.
- 9. Transformative Applications What Will theIndustrial Internet of Things Do?
- 10. Preventing Medical Errors WhatCan Change This? ECRI Institute identifies alarm hazards as its Top Health Technology Hazard for 2013 Clinicians exposed each day to tens of thousands of alarms Nineteen out of 20 hospitals surveyed rank alarm fatigue as a top patient safety concern Hospital Errors are the Third Leading Cause of Death in U.S., and New Hospital Safety Scores Show Improvements Are Too Slow New research estimates up to 440,000 Americans are dying annually from preventable hospital errors. ©2016 Real-Time Innovations, Inc.
- 11. Example: Patient-Controlled Analgesia PCAis widely used, and considered safe… …but 2-3 patients die every day in the US from opiate overdose from PCA The patient presses a button to receive intravenous pain medication. Monitoring is not typically used due to high false/nuisance alarm rate. ©2016 Real-Time Innovations, Inc.
- 12. Improve Safety byConnecting Devices • The Integrated Clinical Environment (ICE) standard specifies interoperability for medical devices • RTI Connext DDS ties together instruments in real time “RTI Connext DDS met all our needs – whether we’re handling 12 patients, or 200.” -- DocBox Founder, Tracy Rausch “… the anesthesiologist forgot to resume ventilation after separation from cardiopulmonary bypass. The delayed detection was attributed to the fact that the audible alarms for the pulse oximeter and capnograph had been disabled during bypass and had not been reactivated. The patient sustained permanent brain damage.” Every surgical team surveyed has experienced this error! ©2016 Real-Time Innovations, Inc.
- 13. Key to theSuccess of IIoT: Interoperability • Interoperability – Across Systems – Across Vendors – Across Brownfiled & Greenfield Deployments – Across Teams ©2016 Real-Time Innovations, Inc.
- 14.
- 15. Comic from xkcd.com ©2016Real-Time Innovations, Inc.
- 16. Data Centric isDifferent! Point-to-Point TCP Sockets Publish/Subscribe Fieldbus CANbus Queuing AMQP Active MQ Data-Centric DDS Shared Data Model DataBus Client/Server MQTT REST XMPP OPC Broke red ESB Daem on ©2016 Real-Time Innovations, Inc.
- 17. It’s All Aboutthe Data Data centricity enables interoperation, scale, integration Unstructured files Database Data Centricity Data at Rest Messaging middleware DataBus Data Centricity Data in Motion ©2016 Real-Time Innovations, Inc.
- 18. Data Centric isthe Opposite of OO Object Oriented • Encapsulate data • Expose methods Data Centric • Encapsulate methods • Expose data Explicit Shared Data Model ©2016 Real-Time Innovations, Inc.
- 19. RPC over DDS 2014 DDS Security 2014 Web-Enabled DDS 2013 DDS Implementation App DDS Implementation App DDS Implementation DDS Spec 2004 DDS Interoperablity 2006 UMLDDS Profile 2008 DDS for Lw CCM 2009 DDS X-Types 2010 2012 DDS-STD-C++ DDS-JAVA5 OMG Compliant DDS: Data Centric Messaging App Network / TCP / UDP / IP / SharedMem / … ©2016 Real-Time Innovations, Inc.
- 20. DDS Terminology Domain Participant Data Reader Data Writer Data Writer Data Reader Data Reader Data Writer PublisherSubscriber Subscriber GlobalData Space Topic Topic Publisher Domain Participant Domain Participant QoS #1 QoS #2 ©2016 Real-Time Innovations, Inc.
- 21. Data-Centric Model “Global DataSpace” generalizes Subject-Based Addressing • Data objects addressed by Domain ID, Topic and Key • Domains provide a level of isolation • Topic groups homogeneous subjects (same data-type & meaning) • Key is a generalization of subject Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Airline Flight Destination Time SWA 023 PDX 14:05 UA 119 LAX 14:40 Sensor Value Units Location 4535 72 Fahrenheit Bldg. 405 5677 64 Fahrenheit Bldg., 201 Data Writer Domain Topic Instance Key (subject) ©2016 Real-Time Innovations, Inc.
- 22. Quality of Service(QoS) • Aside from the actual data to be delivered, users often need to specify HOW to send it … … reliably (or “send and forget”) … how much data (all data , last 5 samples, every 2 secs) … how long before data is regarded as ‘stale’ and is discarded … how many publishers of the same data are allowed … how to ‘failover’ if an existing publisher stops sending data … how to detect “dead” applications … … • These options are controlled by formally-defined Quality of Service (QoS) ©2016 Real-Time Innovations, Inc.
- 23. Data Centricity EnablesInteroperability • Global Data Space – Automatic discovery – Read & write data in any OS, language, transport – Redundant sources/sinks/nets • Type Aware • No Servers • QoS control – Timing, Reliability, Ownership, Redundancy, Filtering, Security Shared Global Data Space DDS DataBus Patient Hx Device Identity Devices SupervisoryCDS Physiologic State NursingStation Cloud Offer: Write this 1000x/sec Reliable for 10 secs Request: Read this 10x/sec If patient = “Joe” ©2016 Real-Time Innovations, Inc.
- 24. Why Choose DDS? •Reliability: Severe consequences if offline for 5 minutes? • Performance/scale: – Measure in ms or µs? – Or scale > 20+ applications or 10+ teams? – Or 10k+ data values? • Architecture: Code active lifetime >3 yrs? 2 or 3 Checks? ©2016 Real-Time Innovations, Inc.
- 25. This is addressedby DDS Security Security Boundaries • System Boundary • Network Transport – Media access (layer 2) – Network (layer 3) security – Session/Endpoint (layer 4/5) security • Host – Machine/OS/Applications/Files • Data & Information flows ©2016 Real-Time Innovations, Inc.
- 26. Data Security Threats inthe Global Data Space 1. Unauthorized subscription 2. Unauthorized publication 3. Tampering and replay 4. Unauthorized access to data by infrastructure services Alice: Allowed to publish topic ‘T’ Bob: Allowed to subscribe to topic ‘T’ Eve: Non-authorized eavesdropper Trudy: Intruder Mallory: Malicious insider Trent: Trusted infrastructure service Alice Bob Eve Trudy Trent Mallory ©2016 Real-Time Innovations, Inc.
- 27. • Transport LayerSecurity • Fine-grained Data-Centric Security Approaches to Secure DDS ©2016 Real-Time Innovations, Inc.
- 28. Threat & TrustModels for DDS Security • We are protecting against attacks originating over the network • The local machine is in our trust base – To protect against threats in the same machine host- protection techniques should be used • These are outside the scope of DDS security • By securing DDS we mean providing mechanisms for – Confidentiality of the data samples – Integrity of the data samples and the messages that contain them – Authentication of DDS writers & readers – Authorization of DDS writers & readers ©2016 Real-Time Innovations, Inc.
- 29. Data-centric Security forDDS: How is it Done? • Security Model – What to Protect • Security Plugin APIs – How/where to protect – Interchangeability of the plugins • DDS RTPS Wire Protocol – Data encapsulation and discovery interoperability • Default Builtin Plugins – Out-of-box implementation – Interoperable implementations OMG DDS Security Specification RTI Connext™ DDS Implementation ©2016 Real-Time Innovations, Inc.
- 30. Security Model • Asecurity model is defined in terms of: – The subjects (principals) – The objects being protected • The operations that are protected on the objects – Access Control Model • A way to define for each subject – What the objects it can perform operations on are – Which operations are allowed ©2016 Real-Time Innovations, Inc.
- 31. Security Model Example: UNIXFileSystem (simplified) • Subjects: Users, specifically processes executing on behalf of a specific userid • Protected Objects: Files and Directories • Protected Operations on Objects: – Directory.list, Directory.createFile, Directory.createDir, Directory.removeFile, Directory.removeDir, Directory.renameFile – File.view, File.modify, File.execute • Access Control Model: – A subject is given a userId and a set of groupId – Each object is assigned a OWNER and a GROUP – Each Object is given a combination of READ, WRITE, EXECUTE permissions for the assigned OWNER and GROUP – Each protected operation is mapped to a check, for example • File.view is allowed if and only if – File.owner == Subject.userId AND File.permissions(OWNER) includes READ – OR File.group IS-IN Subject.groupId[] AND File.permissions(GROUP) includes READ ©2016 Real-Time Innovations, Inc.
- 32. DDS Security Model 1/15/2016 ©2012 Real-Time Innovations, Inc. - All rights reserved 32 Concept Unix Filesystem Security Model DDS Security Model Subject User Process executing for a user DomainParticipant Application joining a DDS domain Protected Objects Directories Files Domain (by domain_id) Topic (by Topic name) DataObjects (by Instance/Key) Protected Operations Directory.list, Directory.create (File, Dir) Directory.remove (File, Dir) Directory.rename (File, Dir) File.read, File.write, File.execute Domain.join Topic.create Topic.read (includes QoS) Topic.write (includes QoS) Data.createInstance Data.writeInstance Data.deleteInstance Access Control Policy Control Fixed in Kernel Configurable via Plugin Builtin Access Control Mode Per-File/Dir Read/Write/Execute permissions for OWNER, Per-DomainParticipant Permissions : What Domains and Topics it can JOIN/READ/WRITE
- 33. Pluggable Security Architecture App. Other DDS System SecureDDS middleware Authentication Plugin Access Control Plugin Cryptographic Plugin Secure Kernel Crypto Module (e.g. TPM ) Transport (e.g. UDP) application componentcertificates ? Data cache Protocol Engine Kernel Policies DDS Entities Network Driver ? Network Encrypted Data Other DDS System Other DDS System App.App. Logging Plugin DataTagging Plugin MAC ©2016 Real-Time Innovations, Inc.
- 34. Platform Independent InterceptionPts + SPIs 34 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 send 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 to 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 ©2016 Real-Time Innovations, Inc.
- 35. What are theStandard Capabilities (Built-in Plugins) Authentication X.509 Public Key Infrastructure (PKI) with a pre-configured shared Certificate Authority (CA) Digital Signature Algorithm (DSA) with Diffie-Hellman and RSA for authentication and key exchange Access Control Configured by domain using a (shared) Governance file Specified via permissions file signed by shared CA Control over ability to join systems, read or write data topics Cryptography Protected key distribution AES128 and AES256 for encryption HMAC-SHA256 for message authentication and integrity Data Tagging Tags specify security metadata, such as classification level Can be used to determine access privileges (via plugin) Logging Log security events to a file or distribute securely over DDS ©2016 Real-Time Innovations, Inc.
- 36. Overview of WhatHappens Create Domain Participant Authenticate DP? Create Endpoints Discover remote Endpoints Send/Receive data Discover remote DP Authenticate DP? Yes Domain Participant Create Fails No Access OK? Endpoint Create Fails No Authenticate Remote DP? Ignore Remote DP No Yes Access OK? Ignore remote endpoint Message security DP = Domain Participant Endpoint = Reader / Writer No ©2016 Real-Time Innovations, Inc.
- 37. The Big Picture:Authentication • Once discovered & authenticated to the middleware, domain participants are mutually authenticated to each other using a point-to-point public-key based challenge-response handshaking protocol. • After the handshake, participants have learned about: – Each other's identities – Each other's granted access permissions – A shared secret, which is used to derive symmetric keys that enables message security ©2016 Real-Time Innovations, Inc.
- 38. The Big Picture:Access Control • DDS Security allows for configuring & enforcing the privileges of each participant such as – Which domains it can join – What topics it can read/write • It also allows specifying & enforcing policies for the whole domain such as – What topics are discovered using Secure Discovery – Encrypt or Sign for Secure Discovery – What topics have controlled access – Encrypt or Sign for each secure topic • User data and payload • Metadata and routing information – What to do with unauthenticated access requests ©2016 Real-Time Innovations, Inc.
- 39. The Big Picture:Message Security • DDS Security enables message security by allowing for encryption and authentication of DDS messages. – Symmetric encryption keys & MAC keys are generated per data writer – These keys are distributed to authenticated data readers that are authorized. • Distribution of these keys is done using other symmetric keys derived from the shared secret. • The key distribution is transport independent – e.g. it could happen over multicast – These keys are used for encryption and/or message authentication based on the policy defined in the governance document. – different parts of messages can optionally be encrypted per governance policy • headers, complete message, sub-message, discovery data ©2016 Real-Time Innovations, Inc.
- 40. DDS Security, Outsideof the Box ©2016 Real-Time Innovations, Inc.
- 41. Domain Governance Document Identity CA Certificate Permissions CA Certificate P2 Identity Certificate P2Private Key P2 P2 Permissions File P1 Identity Certificate P1 Private Key P1 P1 Permissions File • Keys. Each participant has a pair of public & private keys used in authentication process. • Identity CA that has signed participant public keys. Participants need to have a copy of the CA certificate as well. • Permissions File specifies what domains/partitions the DP can join, what topics it can read/write, what tags are associate with the readers/writers • Domain Governance specifies which domains should be secured and how • Permissions CA that has signed participant permission file as well as the domain governance document. Participants need to have a copy of the permissions CA certificate. Configuring & Deploying Secure DDS ©2016 Real-Time Innovations, Inc.
- 42. Permissions Document • Foreach Participant – Specifies • What Domain IDs it can join • What Topics it can read/write • What Partitions it can join • What Tags are associated with the Readers and Writers ©2016 Real-Time Innovations, Inc.
- 43. A Sample Permissions File 1/15/2016 ©2012 Real-Time Innovations, Inc. - All rights reserved 43
- 44. Domain Governance Document •The domain governance document is an XML document that specifies which DDS domain IDs shall be protected and the details of the protection. • It is signed by the permissions CA. ©2016 Real-Time Innovations, Inc.
- 45. A Sample DomainGovernance File ©2016 Real-Time Innovations, Inc.
- 46. Configuration possibilities • Are“legacy” or un-identified applications allowed in the Domain? Yes or No. – If yes an unauthenticated applications will: • See the “unsecured” discovery Topics • Be allowed to read/write the “unsecured” Topics • Is a particular Topic discovered over protected discovery? – If so it can only be seen by “authenticated applications” • Is access to a particular Topic protected? – If so only authenticated applications with the correct permissions can read/write • Is data on a particular Topic protected? How? – If so data will be sent signed or, encrypted then signed • Are all protocol messages signed? Encrypted? – If so only authenticated applications with right permissions will see anything ©2016 Real-Time Innovations, Inc.
- 47. DDS Security allowsfor configurations that combine interoperability, scalability, and high performance requirements of Industrial IoT Systems with those of security.
- 48. Try out SecureDDS • Current Specification Draft: – http://www.omg.org/spec/DDS-SECURITY/ • Any Questions? – Send e-mail to hamed AT rti DOT com ©2016 Real-Time Innovations, Inc.