Is Your Security Tail Wagging Your Architecture Dog? 4

tail wagging the dog

Recently, as a leader in the IIoT, I seem to get a lot of questions from insurance company executives. Their common question: where is the risk in the IIoT? Their theme seems to be: connecting things is just too risky. We don’t understand the security or safety risks, so It Can’t Be Good.

I disagree.

I do agree that the IoT is a brave new world in general, and for risk management in particular. There are all sorts of new opportunities for mischief if a machine is compromised. The hack that caused a Jeep to go off the road by getting into the tire pressure monitoring system is a classic example.

That said, intelligent machines also have more opportunity to protect themselves. The sad truth today is that most systems are very poorly protected (like that Jeep). Security gets orders of magnitude more attention today than only a short time ago. Most industrial systems didn’t even consider anything beyond “eggshell” firewalls or “air gap” offline designs until recently. That has changed 100% today; everyone is thinking security, security, security. And progress is exhilarating. Put another way, I think that everyone is installing cyber “burglar alarms” much faster than the increase in burglars. Bottom line: despite the rise in connected systems, the “likely real” risk is going down in most cases.

My insurance contacts consider this an overly optimistic view of the future. I counter that they hold a too-optimistic view of the present. You see, I claim that the situation today is unacceptably, intolerably, unbelievably high risk. Entire industries run without a whit of security. It seems scarier in the future only because the risk you don’t know seems worse than the risk you do know. That’s human nature. But anyone who looks will see that the current risks are very high, and the new designs are much better.

That said, my real optimism stems from the opportunity to change. In my experience (and this may shock security wonks), security is not a change driver. By that, I mean that industrial systems are usually not willing to implement a new architecture (just) to improve security. The power industry is my favorite example. The industry has been screaming for 20 years that security is a problem. And, imho, they will go right on screaming…unless something else drives the change.

The good news: the IIoT is that change driver. And security today is absolutely a change gate. Every application insists on security when they do implement a new architecture for other reasons. Since the IIoT is motivating many, many industrial applications to redo their architectures, security is getting better. Of course, implementing a new architecture for a major industrial application, or for that matter an entire industry, is daunting. But this is the magic of the sweeping changes offered by the IIoT. The IIoT is compelling. Change is coming, and it’s coming fast.

While we’re on the topic of change, let’s not discount improvements in technology to enable that gate. For instance, many potential IIoT systems primarily face scalability and system integration challenges. With a little thought, the architects figure out that IIoT systems are all about the data, and then that they really have a high-performance data flow and data transparency challenge. The best way to provide transparent flow is a “peer to peer” or “publish subscribe” design. This is the architecture “dog”: systems need the simplicity and performance of a communications pattern that simply sends the data where it’s needed, right now. That data transparency makes the huge future IIoT system manageable.

Of course, although data transparency is an integration dream, it’s a security nightmare.

The “dog” side of the dialog goes something like this:

Hey! Let’s just send the data right where we need it. Pervasive data availability makes systems fast, reliable, and scalable. And look how much simpler the code is!

But, then comes the security “tail”:

We can’t maintain thousands of independent secure sessions! How do we keep such a system secure?

Only last year, that was a damn good question. It blocked adoption of IIoT technologies where they are really needed. But then, the DDS standard developed a security architecture that exactly matches its data-centric data flow design. The result? The data-centric dog wags its perfectly-matched data-centric security tail. Security works seamlessly without clouding data transparency. Advances like this—that span industries—will make future IIoT systems much more secure than today’s ad-hoc industry-specific quagmire of afterthought security hacks. Security that matches the architecture is elegant and functional.

This argument leaves my insurance correspondents searching for Tao in their actuarial tables. So, I can’t resist adding that it’s not really what they should worry about.

Safety engineering will be a much bigger impact on insurance. For instance, I expect the $200b auto insurance industry to disappear in the next 10-20 yrs as ADAS and autonomous cars eliminate 90+% of accidents. Most hospital errors can also be prevented (hospital error is currently the 3rd leading cause of death in the US). In factories, and plants, and oil rigs, and mining systems, and many more applications, automated systems (somewhat obviously) don’t have humans around, thus removing a significant current risk today. Accidents, in general, are mostly the result of human folly. Machines will soon check or eliminate the opportunity for folly. I see this as an extremely positive increase in the quality and preservation of life. Insurance execs see it as an existential threat.

I tell them not to feel bad; most industries will be greatly disrupted by smart machines. Navigating that transition well will make or break companies. Insurers certainly understand that losses are easier to grasp than gains; that principal underwrites their industry. But, that perception is not reality. The IIoT’s impact on the economy as a whole will be hugely positive; the analysts measure it in multiple trillions of dollars in only a few years. So, there will be many, many places to seek and achieve growth. The challenge to find those paths is no less or greater for insurance than for any other industry. But, fundamentally, the IIoT will drive a greener, safer, better future. It Is Good.

To learn more about our security solutions, visit

Understanding RTI Connext DDS Secure Reply

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:


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. See

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…