Securing Industrial Internet of Things Systems

In Episode 5 of The Connext Podcast:

• [2:10] What problems need to be solved with regards to IIoT Security?
• [6:10] Technology alone will not solve security concerns. Why paying attention to the Industrial Internet Consortium (IIC) pays off for you in the end.
• [8:13] Free advice from the IIC! The Industrial Internet Security Framework (IISF) brings a comprehensive approach for all security stakeholders from business managers and technical leaders to vendors and integrators.
• [14:25] Thinking through how to secure your connectivity infrastructure.
• [17:50] DDS is more than just a protocol: DDS Security Specification secures your connectivity in your distributed system without any centralized brokers or single points of vulnerability.
• [21:30] ICE Medical Demo: Connext DDS Secure in action.
• [26:12] How to get a hold of the Industrial Internet Reference Architecture, Industrial Internet Connectivity Framework, Industrial Internet Security Framework, and DDS Security Specification.

Related Content:

• RTI Connext^® DDS Secure
• [Whitepaper] Four Keys to Securing Distributed Control Systems

Podcast Transcription:

Niheer: Hi, and welcome to episode five of the Connext podcast. I am Niheer Patel, and I will be speaking with Dr. Hamed Soroush, the senior security research engineer here at RTI. Hamed's expertise spans into areas including security, privacy, forensics, networking, and critical large-scale distributed systems. He currently co-chairs the security working group for the Industrial Internet Consortium, or IIC, and he has also co-authored the IIC's industrial internet security framework, which provides guidance on assessing and implementing security architectures.

Today, we will be talking about security for industrial internet of things systems through the lens of the Industrial Internet Consortium. We will hear about some of the work that Hamed is doing, and touch on what the market is doing try and solve the problem for IIOT systems. We will dig into the set of publications generated by the IIC, and how IIOT companies can leverage them to assess their security needs and implement their IIOT systems with security in mind. Then we will discuss how the IIC's efforts with security relate to DDS and RTI. And finally, we will tie it all together with a medical example focusing on patient monitoring.

This episode will shed some light on the often enigmatic concepts of security, and provide you with the tools to address security needs in your IIOT system. We hope you find this episode enlightening.

Hey, Hamed. Welcome, how are you doing?

Hamed: Hi, thanks for the introduction, glad to be here.

Niheer: Thank you, and thanks for taking the time to speak with me.

Hamed: Yeah, sure.

Niheer: I could go on and on about a lot of the things that you do and that you have done for RTI, but I wanted to get it directly from you. What kind of things are you working on right now, what kind of things here at RTI and with security in general?

[2:10] What problems need to be solved with regards to IIoT Security?

Hamed: Yeah, sure. Thanks for the kind words, by the way. So I come from a security/networking background. Currently, I'm working on researching security for large-scale distributed systems, which are now basically turning into massive cyber-physical systems, which are also dubbed as internet of things. My focus at RTI has been mostly on the industrial side of the internet of things, so industrial internet of things, where you have systems that are big, old legacy systems, mostly legacy systems that are becoming more and more connected to the internet for a variety of reasons which we could get into.

And that opens up a huge surface for security issues and potential attacks. So understanding that space, and also coming up with solutions that could address or mitigate that sort of security issues is my focus.

Niheer: Okay, great. So we're looking at these legacy systems, and we have to rethink about security for these systems. So what kind of efforts are there in the marketplace that address these concerns?

Hamed: Yeah, I think the industry has been pretty much aware of the potential issues. There are actually known examples of attacks that have already happened on critical infrastructure, within the energy sector, for example. And the industry has been aware of that. There are a consortium and standardization bodies that have tried to come up with approaches to understand the space a little bit better.

RTI is active in quite a number of these standardizations and consortia efforts, and a prominent one is the Industrial Internet Consortium, which is formed by multiple working groups and security has been one of the major groups at the IIC from the start. So we could go deeper into what kind of guidance IIC, as an example, provides.

Niheer: Right. And they had recently published a set of frameworks that guide companies to really think about security and connectivity in general, and as I understand, you're actually co-author on one of these publications.

Hamed: Yes. Actually, I co-chair the security working group in the Industrial Internet Consortium, the IIC, and also was one of the authors of the industrial internet security framework, which is a document, a guidance document, that IIC published a few months ago.

There are other groups at the IIC that focus on connectivity, on test beds, because we just don't want to be publishing documents. We want to apply those guidance in the real world, and testing and validating them. That's actually one of the differentiators of IIC from other consortia, as I could tell. And so far I think there have been two versions of the industrial internet reference architecture that have been published that describes generally how IIOT systems should be architected, or what kind of architectural considerations should be taught about them.

And then there's the IISF, the industrial internet security framework, which talks about general concerns, security issues in IIOT which we'll get into in a bit. And recently, there has also been another document called the IICF, which is industrial internet connectivity framework, and that maps out approaches for providing connectivity and issues there.

Niheer: When we talk about implementing or following some frameworks, there's more than just an implementation aspect, right? So does the IIRA talk about more than just how you should go about implementing or thinking about the technical design of your system?

[6:10] Technology alone will not solve security concerns. Why paying attention to the Industrial Internet Consortium (IIC) pays off for you in the end.

Hamed: That's a great question, and I think an important question, because oftentimes within security, our architectural documents, they only think about technical issues and a technical implementation of a certain design. The problem is, I think, with IIOT systems, the scope is so massive that different aspects of them should be considered in any kind of guidance. So the IIRA and the other documents as well, like the IISF, also take into accounts the business viewpoints, or multiple viewpoints in terms of functional implementation, or the business viewpoints, that different people with different expertise who are involved in building these systems could utilize.

So in that sense, the guidance is not just a technical or architectural guidance, although it includes those aspects. It's also things about the utility, what business people should know, and how they could basically approach or think about these systems. Or, in terms of security, for example, how risks should be communicated to them.

Niheer: So these documents aren't just for technical people, they're for the business people, managers, folks making financial decisions.

Hamed: Absolutely.

Niheer: This is a very comprehensive, it sounds like, approach to thinking about moving from legacy systems to the future, which is IOT and IIOT.

Hamed: Yes, that is correct.

Niheer: I do want to hear more about the IISF, so please.

Hamed: Sure. From a general perspective, the IISF starts off by talking about what distinguishes IIOT from the normal IOT, like the consumer IOT that you hear more about these days. Distinguishing factors of the IIOT then point to different threats and different risks associated with these systems, which are different from traditional distributed systems or "closed" systems. From them, risk framework and a space of understanding risks and threats for these systems is laid out.

Another topic that is talked about in the IISF is the complex trust relationships, or permeation of notions of trust, between different contributors. The value chain of the IIOT. You have, for example, component builders, let's say chip manufacturers. You have system integrators, and you have owners and operators. And each of these groups have different perspectives, views, and associated risks. And they trust and rely on each other for providing services, or getting services, to and from each other. So that basically creates the complexity that the IISF gets into in its earlier chapters.

[8:13] Free advice from the IIC! The Industrial Internet Security Framework (IISF) brings a comprehensive approach for all security stakeholders from business managers and technical leaders to vendors and integrators.

In the functional and implementation viewpoints, we take on basically the questions about, what are the architectural considerations that should be thought of when you design new systems? And also when you want to bridge or interface legacy systems, because as we know, industrial systems are designed to work for a long time. I think the average lifetime of a device, a component of an industrial system, is about 19-20 years. So there will always be a legacy problem with the rapid change that we have in the technology. So those architectural questions form the second part of the IISF.

Niheer: It seems like when we go out and we talk about security, everyone refers to it almost holistically, like, "I need security for my device," or, "I need security for my system." And often they're looking for a silver bullet and when they come to the IISF, they read through it, they'll understand better how to go about assessing their security needs and understand that there is no silver bullet, but rather an approach that could suit their needs.

Hamed: Exactly. And this is again a great point. A lot of people, and an unfortunate mindset that security by non-security people, is often ... They like to think about it as a check. Like, they want to tick a box that says, okay, I'm secure. But with the complexity that you have in the IIOT systems, I think it's more important that we understand that that is not true. That's just way too simplifying. And instead of that, we need to think about the risks, construct threat models that associate or relate to those risks, and then find security solutions that minimize those risks. That way, you end up having a system that is more mature in terms of its security posture.

So the IISF actually talks about how you should be thinking about risks, because the risks in industrial systems are going to be different from the IOT systems, for example, because there are safety concerns and human lives could be at stake, and also there are regulatory concerns, for example. And that lays down the foundation for what kind of security mechanisms you should apply that best suit, and implementing mechanisms that address threats from those risks.

Niheer: Great, thanks. And I know we can talk about different aspects of security in depth over several of these podcasts, but maybe this is a good opportunity for us to turn and focus on security for the connectivity portion of a networked system or distributed system, especially since we are here at RTI. It'd be interesting to share with the audience how the IISF relates to data distribution services, security. What's the connection there?

Hamed: Sure. I need to step back a little bit and then come back to that question. When talking about functional and implementation viewpoints in the IISF, which targets mostly system designers and architects, and maybe security engineers, let's say ... The IISF describes three broad categories. There are security endpoints. This is where, for example, security at your circuit level or chips, or protecting devices in different ways, or protecting secret keys, or the software running on the host that runs different applications would come in.

So we have a whole chapter on that, and then there's security of communication between these endpoints. And then there is this other aspect of security that relates to configuration and management of various operations, including security operations. Configuration management and monitoring. Each of these aspects, by the way, have their own chapters, separate chapters at the IISF. And chapter nine in the IISF particularly relates to the question you asked, and that is about, what are the different ways of protecting communications within the IIOT systems?

Now, that protection, first and foremost, relates and depends upon protecting endpoints and the other activities related to monitoring and configuration management. But assuming that you have that, you would need certain features in your communication protocols or your communication infrastructure that help you mitigate certain security threats.

So broadly speaking, there are two different aspects within that security communication that we target. One is a communication base that utilizes newer protocols that utilize cryptographic operations, for example, for ensuring about message authenticity or confidentiality, or protocols that are resilient and provide better availability of communications. And the other approach is for basically protecting the infrastructure so that access control policies are enforced in the best way. For example, talking about proper ways of doing segmentation and isolation of networks.

Traditionally, the OT, operational technology systems that are not connected to the IT, to make the IIOT, focus on the second part. Mostly if you talk to OT folks, network segmentation and isolation is a huge thing for them. But with these networks, for example, they wanted to make sure that control systems and safety-critical networks, the messages are going over separate networks entirely, so if one network is compromised, that doesn't impact the other.

With the marrying of IT and OT, this will open up attack surfaces, which requires a combination of approaches that deal with both segmentation and proper isolation of systems, as well as utilizing the best and greatest cryptographic-based protocols that exist today. So one of those protocols that we care about a lot at RTI is data distribution service. It is an IIOT protocol. Apart from security, it has a lot of other features that make it a suitable core connectivity protocol for the industrial internet, and so its security features are also an add-on to why it should be considered.

[14:25] Thinking through how to secure your connectivity infrastructure.

Niheer: That sounds like data distribution service is a great way to manage your connectivity, manage your messaging. Maybe it'd be worthwhile sharing what DDS security specifications specifically spells out, because DDS is actually more than just the messaging protocol. It's a set of specifications and standards, quality of service, and basically a messaging framework for your IIOT systems, right?

Hamed: Yes.

Niheer: And with that, it's really important for us to consider the security aspects, and the fact that you need to be able to message reliably with performance, without sacrificing that security. So you need those trade-offs. So what does DDS security offer us on top of just the message publishing that we might do with the standard DDS?

Hamed: That's a good question. First of all for the audience, if they want to know what kind of requirements they need to consider for a proper messaging protocol for their IIOT applications, they can look at the IIC connectivity framework. The authors have laid down requirements that certain core protocols have, or should have, for being a proper candidate for IIOT messaging.

In terms of looking at the existing protocols that meet those requirements, DDS is one of the protocols that meets those requirements, and security is one important aspect of it. So as you know, the data distribution service is kind of a publish-subscribe protocol that doesn't rely on the existence of brokers. So in that sense, it is more resilient. There are no central points of failures.

The DDS security specification specifies how these different flows that happen between these loosely coupled publishers and subscribers of data, how those flows should be protected. Perhaps the best way to think about it is what kind of requirements should there be? So first of all, the security solution of DDS, which DDS security meets, shouldn't basically violate the niceties of DDS. For example, introduction of newer central points of failure is not a desirable factor, and DDS security meets that.

In addition to that, it shouldn't violate anything related to interoperability or scalability or flexibility of utilizing different technologies. And DDS security is architecturally designed in a way that is extensible, it supports a pluggable architecture that allows for these sort of features to exist.

Niheer: Okay. So really extending on the DDS core values, decentralized systems, flexibility, extensibility and customization by the implementer of that framework.

Hamed: Exactly.

Niheer: Maybe we can take this and make it a little bit more tangible. I know you've worked on some medical device demos in your research. Could you tell us a little bit about that, and maybe see how some of the capabilities of security apply there?

Hamed: Yeah, sure. That's actually a good example of a project that we at RTI research have been working on with a mass General Hospital and Harvard University, the Summit Center there. And it's really about protecting an architecture of medical internet of things. When I talk about medical internet of things, the audience may think about different sort of applications, anything ranging from Fitbits to home healthcare type of use cases.

[17:50] DDS is more than just a protocol: DDS Security Specification secures your connectivity in your distributed system without any centralized brokers or single points of vulnerability.

The specific use case that we target is more on the patient's side, that side, kind of a network, where you have multiple devices around the patient, maybe in an operating or maybe in the emergency room, or as the patient is being transferred from one to the other. There are all these sort of devices attached to the patient that caregivers use for monitoring the patient or understanding their status, or prescribing drugs or infusing drugs, and things like that.

Before I talk about the security aspect, it's perhaps useful to talk about the real value here of why an IIOT system would make sense for this sort of setting.

Niheer: Sure.

Hamed: So one of the biggest problems that exist today for medical caregiving in a medical practice is preventable medical errors. There are stats that show that its the third cause of death after cancer and heart disease. A big problem there in terms of preventable medical errors is the alarm fatigue problem. The fact that these devices that are attached to the patient do not communicate results in ... Today, they do not communicate a lot. So that results into a problem of uncoordinated alarms going on and off. The nurses or caregivers, as a result of that, have become insensitive to an alarm going off, and that could result into issues.

So if you talk with medical practitioners, there are actually conferences and a huge number of discussions about alarm fatigue and how to address it. So one of the ways is to have these multiple devices that are connected coordinate with each other in a way that, if an alarm is raised, it's raised in a semantically meaningful context, reducing the number of false alarms.

And an interesting initiative that has this as one use case, and there are other use cases which we don't need to get into now, is the integrated clinical environment, or ICE initiative, led by the MDPNP program at Harvard. So they actually have defined a standard that is about how different devices could be basically communicating with each other, and it's sort of a plug and play type of system. And they have created a prototype that uses DDS underneath.

So in our research project, we looked into what kind of security issues may be there. Whether an attacker could exploit the fact that these devices are communicated with each other to, let's say, infuse a drug to a patient in order to cause harm to the patient, for example. And we found that there's indeed a way to do that with the current design of the ICE standard. But utilizing DDS security would mitigate those sort of problems to a great extent.

Niheer: Okay. So these commands, even if it's an automated command that goes to, let's say some sort of insulin pump or whatever medicine pump, you might be able to force authentication on that particular command, so you know that it's coming from another trusted device. Whether it came from another vendor altogether, or it's the same vendor as the pump, you can trust that command.

Hamed: Yes, that is exactly one use case. Now the more security-aware people among the audience may ask, okay, that is achievable with normal, traditional security protocols like TLS or DTLS, that have been in use for a long time.

Niheer: Sure.

Hamed: Well, that is true that a certain number of attacks could be mitigated by using those sort of transports, but there are a few issues there with those protocols that DDS security doesn't have, and that makes it maybe a more attractive solution. First is that with DDS security, in addition to all the message authentication, confidentiality, availability access that you get, you also get granular access control over the data stream. So you could basically fine-tune which parts of the message or which type of messages or which part of each type of the message you would like to protect and how.

[21:30] ICE Medical Demo: Connext DDS Secure in action.

So to give you a concrete example, maybe encrypting the value of a temperature in a room that's coming out of a temperature sensor is not so critical, because after all, temperature can be felt by many people in the room.

Niheer: Just walk in with a thermostat, right, and take it yourself.

Hamed: Yeah, exactly. So doing that encryption may not matter. It's actually extra work by the temperature sensor. But what matters more, perhaps, is the authenticity of the temperature reading. You don't want an attacker to be messing around with the value of the temperature causing an alarm. So using DDS security, you could basically fine-tune what sort of protection you like, whether you want to encrypt a MAC, for example, or only MAC. MAC is standing for message authentication codes. Or even which part of a message, which part of a data structure that relates to the temperature, or maybe a combined reading coming off of a sensor, you would want to protect.

And this granular protection is something you wouldn't get with protocols like TLS or DTLS, because to use an analogy, they're really protecting the pipe. One size fits all, there's no granularity. So that sort of trading off security and performance based on risk is arguably absent there.

Niheer: Okay. So again, right, extending that concept of flexibility, right, and even with something like TLS, you would need some sort of broker if you really want to leverage access control to protect against inside attackers. So it sounds like we’re really extending that core DDS concept there.

Hamed: Yes, that is true. So there are also notions of governance. So what DDS security has is, it allows you to define specific consistent policies for governing a DDS system and how you should interface with the existing legacy systems. Whether to ignore them, whether to interoperate with them to some extent. And so on and so forth. So you can define these governance policies and permissions for each of the participants in a very granular way, which is also nice.

Niheer: Thank you. And as we start to wrap this up, I want to actually tie this back to what we were talking about at the beginning with the IIC and the IISF. So if we take our medical device, our clinical environment, we have multiple machines from multiple vendors, and it sounds like the IIC, the IIRA, the IISF, and the IICF can all help these several vendors coalesce around a particular framework so that they can maintain interoperability, they can apply security and really come up with a solution that is suitable for this new IIOT industry or marketplace that is evolving quite rapidly. Can you talk a little bit more about that?

Hamed: Yeah, exactly. Actually, one of the challenges that we have in realizing IIOT is, it's some sort of a language barrier. There are OT folks and IT folks, and architects and business folks, they all use different language and different jargon, and they have different viewpoints about the same issue. They're basically touching different parts of the elephant.

So the usefulness of frameworks like the IISF or the IIRA or the IICF is to basically create this shared wisdom and shared vision that would help people to use the same language to talk about these things. And that is hugely important when you talk about interoperability. For security, it's also important that we make sure everybody has the same understanding of the risks, and communicating the risks from a nerdy engineer to the high-level executive who may not understand security very well is a challenging task.

And ultimately, for security, that matters a lot, because you have expertise on one end, and the power to allocate resources on the other. And without a shared understanding, that becomes very difficult. And I think it's very critical to have frameworks like this, which form a foundation of standardization efforts that will come after them.

Niheer: Thanks, Hamed. Really trying to bring everyone together around the table, right?

Hamed: Yeah.

Niheer: So that's about all the time we have for today, but before you leave, are there any last words about maybe where folks can go to get some of this information?

[26:12] How to get a hold of the Industrial Internet Reference Architecture, Industrial Internet Connectivity Framework, Industrial Internet Security Framework, and DDS Security Specification.

Hamed: Yeah, sure. The documents from the IIC are public, so I think the best way would be to just Google industrial internet security framework, or industrial internet connectivity framework, or the industrial internet reference architecture document. You can find them on the IIC's website, www.iiconsortium.org, I think.

And so in terms of DDS also, the DDS security specification is also public. RTI is also going to have a product based on that that people could also try. If you want to take a look at the specification, you can look into the DDS website on object management groups. You can just find that, and they're always looking for feedback, both in terms of the IISF or any of IIC's documents, as well as the DDS security specifications.

Niheer: Great. Thanks, Hamed.

Lacey Trebaeol: Thanks for listening to this episode of the Connext podcast. We hope you enjoyed it. If you have any questions or suggestions for future interviews, please be sure to hit us up over on social media, and you can also reach out to us at podcast@rti.com. Thanks and have a great day.