The Data Distribution System (DDS) is an Object Management Group (OMG) standard. Real-Time Innovations (RTI) has been selling DDS systems for a wide range of applications and has developed significant expertise in this area. The DDS Security standard is a new aspect that is now supported by RTI (see “Securing DDS”).
I talked with Gerardo Pardo-Castellote, CTO of RTI, about the DDS Security standard for the Industrial Internet of Things.
Wong: What prompted the need for the DDS Security standard? Who supports the standard?
Pardo-Castellote: Internet of Things (IoT) and industrial Internet of Things (IIoT) applications need to exchange information securely. Many of these systems are being built using DDS because they involve a lot of machine-to-machine and peer-to-peer communications that demand the performance, scalability, and QoS features only provided by DDS. However, prior to the DDS Security standard, there was no multi-vendor interoperable mechanism for DDS applications to communicate securely.
Moreover, the previous approaches to securing these systems involved layering a middleware/protocol on top of a layer 3 (e.g., IPSEC) or layer 4 (e.g., TLS) secure transport. Both approaches have severe limitations for Industrial Internet applications. They either require too much trust between peers or lack enough fine-grain control to limit access to precisely the set of information that needs to be shared.
DDS Security was developed to overcome these limitations. Most importantly, it is standard and interoperable. In addition, it is built on DDS, preserving the scalability, performance, QoS, and peer-to-peer nature of DDS. Finally, it offers fine-grain access control at the data level, which controls the information flows and data objects that are read or updated by a specific application.
Several leading DDS vendors support the DDS Security standard, including RTI, PrismTech, and TwinOaks. It is also supported by many members of the user community, such as MITRE and the U.S. Department of Defense.
Wong: What was the process for building out the standard?
Pardo-Castellote: This specification took around five years to develop.
Over the course of three years, we had many meetings with users. We presented ideas at several OMG-sponsored workshops and even organized a “security experts” panel at one of the workshops to gather the requirements. It resulted in a formal requirements document (RFP in OMG terminology) that scoped the problem, necessary features, and requirements.
Once the RFP was available, multiple companies submitted draft specifications. They were made public to the OMG members, presented at the OMG meetings, and debated extensively over 2.5 years. In parallel, submitters like RTI were giving presentations to many DDS users and domain experts to get their feedback. I personally gave at least a dozen presentations. Consensus eventually started to emerge around the RTI draft submission, which was joined along the way by eProsima, TwinOaks, and PrismTech. RTI also contracted some external security experts from academia to review the security aspects of the specification. In March 2014, the final draft was reviewed and voted on by the OMG task force and OMG Architecture Board, and in turn DDS Security became a standard.
This file type includes high resolution graphics and schematics when applicable.
Wong: What issues came up while building the standard? How were they resolved?
Pardo-Castellote: Technical issues arose, such as finding the right scope. Also, technical approaches were required to balance the need for having a standard that’s simple and works “out-of-the-box,” as well as something that’s flexible and can be tailored to meet the great diversity of requirements in the IoT and IIoT domains.
Equally challenging was working out the different perspectives and priorities coming from the independent companies that need to support and implement the standard.
To resolve these issues, we focused on the technical needs and asked for feedback from the community. Then we could strike the right balance and align on the ultimate goal of developing a solid usable standard.
Wong: What are the specific advantages of this new security standard? Who benefits from them?
Pardo-Castellote: There are several key advantages.
First the security model, and all of the building blocks authentication, access control, encryption, etc., are pluggable with standard APIs. This means that a user community or provider can “plug-in” mechanisms tailored to their specific needs, replacing, for example, how to manage and verify identity, describe permissions, and even what crypto to use. Because the plug-in APIs are standard, these community-developed plug-ins can be used with any compliant DDS Security implementation (see the table).
Second, the security specification supports a complete peer-to-peer deployment, where two peers can perform mutual authentication and communicate securely. Of course, centralized management is also possible if so desired.
Third, the security model is very fine grain and works at an abstraction level meaningful to the application developer. DDS applications communicate via Topics, with each Topic representing a separate independent stream of like information (e.g., the Topic “CarPosition” that can be published by each car to report its own position). The security model allows applications to be granted permissions to read- and/or write-specific Topics and not others. Or even specific objects within the Topic (e.g., concrete cars) and no others.
Fourth, the approach is very high performance and scalable. If multicast is available, DDS Security can use it securely. It is robust to message lost, and supports content filtering, history consolidation, and many other features important to DDS users.
Wong: What is unique about RTI’s approach to the DDS Security standard?
Pardo-Castellote: RTI has been the leading force behind the specification. Over the last two years, we have developed DDS-secure prototypes that were being evaluated by users. We even had some of these undergo “red-team” evaluations for penetration. We provide the most mature product, and bring both application expertise and security expertise to the table (see the figure).
Wong: What trends are you seeing around security and distributed systems?
Pardo-Castellote: In general, security in distributed systems has been around for a long time, but it was mostly limited to enterprise systems or systems that involved users interacting with computers or other users. The trend now is to have machine-to-machine communications without any human intervention. This was not happening in well-controlled and closed networks, but it has since changed.
IIoT and IoT have a huge element of machine-to-machine communications, and the trend is to have these systems and information be accessible. This places huge demands on the security infrastructure, because many of these systems are critical to the operation of the country itself (e.g., power generation and distribution, transportation) as well as people’s health and lives (e.g., medical, machine control).
Wong: How do security issues differ between IoT and IIoT?
Pardo-Castellote: IIoT focuses more on intelligent machines (“brilliant machines” according to GE terminology, which also coined the IIoT term). This includes more industrial systems, complex machinery, energy, medical equipment, and transportation, which are typically more demanding in terms of performance and scalability, and require nonstop operations with serious consequences in case of failure. For example, if the power generation fails, we get a blackout. If the balancing and distribution is wrong, we may overload the grid and cause many failures.
In contrast, general IoT often involves less-critical systems: If the remote monitoring and information collection on my home thermostat fails or is late, I will be inconvenienced but the consequences aren’t dramatic.
This means the security approach for IIoT needs to be the most advanced, robust, and highest performing system available.
