Understanding RTI Connext DDS Secure

Our Connext DDS Secure product is generating unprecedented interest. We rarely see so much demand for, and curiosity about, a product. It's especially unusual because the product is still in Beta yet customers are nonetheless planning to ship it asap. I thought I'd answer a few of the most common questions.

First, the new DDS Security standard specifies a security architecture and model. The Beta standard was adopted in March by OMG. We (RTI) chair the finalization committee; it should be final next year. RTI is first with support for the new standard. I'm sure other DDS vendors will also implement it, but nobody else has a product yet.

DDS Security is unique in the middleware space for several reasons. First, it addresses security more completely than other standards. The specification covers authentication, access control, confidentiality, integrity, non-repudiation, and logging. Second, it has a "plug in" design. The spec defines a set of standard plug-in components and an interoperable wire spec. But, you can define your own algorithms for the plugins. Finally, it protects DDS "topics," not nodes or connections. So, it offers fine-grain control and can adapt to the unique Industrial Internet of Things (IIoT) requirements. It's the first security standard that targets IIoT device-to-device and device-to-cloud networks rather than human or server-centric architectures.

Perhaps an example will make this more clear. Consider this (very) simple system:

DDS Security

Here, "PMU" represents a sensor (a phase measurement unit, common in power control). The "CBM" (condition-based maintenance) analysis component is monitoring the system and looking for system health issues. The simple operation of this system: the PMU sensor writes the state, the control reads that state and writes a set point. The CBM reads the state and writes alarms. The operator can monitor the system.

In DDS, this system is easily set up as data flow between topics. Of course, DDS specifies data rates, reliability requirements, and more.

To secure this system with Connext DDS Secure, you would create a configuration file that conveyed this:

PMU: State(w)
CBM: State(r); Alarms(w)
Control: State(r), SetPoint(w)
Operator: *(r), Setpoint(w)

This says, simply, that PMU can only write State. Control can only read State and write SetPoint. CBM can only read State and set Alarms. And the operator can read anything and write the SetPoint (perhaps to turn off the system). Connext DDS Secure directly enforces these very logical system constraints.

It really is that conceptually simple. Of course, you still have to distribute certificates and the configuration file. But, this "topic based" security is much more intuitive for IIoT systems than designs based on locking out protocols, or isolating nodes, or restricting access based on user roles. Connext DDS Secure acts on the dataflow itself, directly and simply.

Importantly, our Connext DDS Secure product also doesn't require any application code changes. You configure it & go. Connext DDS Secure offers practical, intuitive protection for existing systems.

Of course, no security protection is foolproof. So, most all practical security systems combine protection (stopping bad things) with detection (finding and isolating breaches). This is the reason, for instance, that your laptop has both a firewall (protection) and a virus scanner (detection). Together, protection and detection provide much more secure systems.

DDS, being a software "DataBus", also allows easy monitoring. We used that with PNNL to implement a "retrofit" security test for the power grid, replacing an old DNP3 line with a secure DDS line, thus implementing protection. By tapping into the DataBus traffic and meta-traffic flow, we could then add a scripting capability (we have a slick Lua component). Simple scripts could then detect many potential attacks, including compromised systems, man-in-the-middle attacks, etc. 

Built a Secure Industrial Control System with Connext DDS »

So, DDS lets you combine protection (the standard) with detection (through the DataBus). Both are relatively simple to implement.

Our product is currently in early access release. However, it is already undergoing fire testing. Here is one very extensive test activity:

The USS SECURE cybersecurity test bed is a collaboration between the National Security Agency, Department of Defense Information Assurance Range Quantico, Combat Systems Direction Activity Dam Neck, NSWCDD, NSWC Carderock/Philadelphia, Office of Naval Research, Johns Hopkins University Applied Physics Lab, and Real Time Innovations Inc. USS SECURE's test bed determines the best combination of cyberdefense technologies to secure a naval combatant without impacting real time deadline scheduled performance requirements.

As you can see, our security product expects some really demanding customers. We can't tell you much about these tests for obvious reasons. However, I can say that I am very proud of our Connext DDS Secure product. At this, and many other sites, it is proving extremely effective.

RTI Connext DDS Secure will be generally available next year. If you have questions, please ask your local rep...