Success-Plan Services
Hamed Soroush
**Please note that with the April 2024 release of Connext Professional 7.3 LTS, the functionalities formerly comprising Connext Secure are now available as an optional component to Connext Professional, named Security Extensions.
“Security should be built in, not bolted on.” True. You’ve heard it. I’ve heard it too. In fact, with the IIoT quickly becoming a reality, this phrase is being repeated so many times that I’m worried about it becoming a cliche that creates a sense of urgency without real potency. But why is security often bolted on to begin with? Will understanding the reasons help us avoid it? I hope so. There are many reasons, ranging from economic ones to regulatory, educational, and technical ones, which I cannot get into in this blog post in detail (see the IISF for additional details).
In some cases, threat landscape, associated risks and security considerations have not been well thought out during the development of system architecture. In other cases, existing systems are re-purposed to operate under entirely different conditions with entirely different threats. Security analysts are often dismissive of such efforts and understandably so. Higher-level management, however, is typically driven to make decisions by market forces, giving higher priority to efficiency and high-performance functionality. Perhaps security is an overhead that you can worry about once you get the basic system going. Or perhaps you think your system will be “air gapped.” But it is likely too late at that point to consider security due to the cost of re-architecting the system. So, one would try to do their best by adding security on later after getting the basic system running. In many cases, the process of how to add security later is not well defined or, in cases where there are known best practices, not followed properly. Why then should we be surprised about the disappointing status of security in the IIoT?
Part of the challenge of security engineering is in devising architectures that provide acceptable protection against security threats that stem from errors, mischance or malice while making minimal overhead on business function and performance of the system. This sounds easy, but is quite difficult to achieve in practice – especially as systems become more complex and interdependent and as larger, more diverse groups of people work on realizing them. For IIoT systems in particular, security measures should be thought about within the broader constraints of interoperability, performance, scalability, resilience, safety and compliance, in environments where security threats and associated risks change quite rapidly. These considerations have been lively discussed and considered in the development of the DDS Security Specification and RTI’s Connext® DDS Secure.
If you are already a DDS user or are evaluating DDS to become one, you should definitely consider RTI Connext DDS Secure. In the following, I’ll discuss how Connext DDS Secure allows for security configurations that allow architects and engineers to find the right balance of security and performance, based on security risks and performance requirements. I will also provide an example of a research project that aims at securely integrating clinical environments to significantly improve patient outcome.
Is DDS Security the Right Fit for Your Use Case?
RTI engineers typically use a rule of thumb to see if architecting a customer’s system based on DDS really makes sense, or whether they are better off using another connectivity framework (see IICF for a detailed, technical discussion on this subject). In general, if the answer to at least three of the following five questions is a “yes”, DDS would be the most suitable framework for the system among other existing connectivity frameworks:
- Is it a big problem if your system stops working for a short time?
- Have you said either "millisecond" or "microsecond" in the last two weeks?
- Do you have more than 10 software engineers?
- Are you sending data to many places, as opposed to just one (for example, to the cloud or a database)?
- Are you implementing a new IIoT architecture?
If your answer to question 1 is yes, you have stringent availability and fault tolerance requirements. DDS already provides features that greatly help with these requirements, including fully peer-to-peer operation (thus lacking any single points of failure), and several relevant parameters including Ownership, Durability, Liveliness and Deadline QoS policies. In addition, DDS Security allows for segregation of DDS domains, authentication of DDS participants, authorizing them to publish or subscribe to DDS topics and authentication of DDS messages before data is passed up from the middleware to higher-level applications. These features allow for prevention and/or significant mitigation of the impact of some classes of Denial-of-Service (DOS) attacks. These features, in conjunction with proper access control measures at network, OS, and application levels would provide greater protection against potential DoS attacks in DDS-based systems.
If your answer to question 2 is yes, chances are that you have significant real-time requirements. For such cases, you would want to fine-tune security of your DDS system based on both risk and performance requirements. For example, you may not care that a temperature reading from a sensor in a public space is encrypted and transmitted confidentially, but you likely care about the authenticity of those readings. DDS Security allows you to define and enforce such configurations, without introducing any changes to your application code.
A positive answer to question 3 likely means that you want to minimize the cost of interoperability between software development teams each working on different aspects of a rather large software project. The data-centric design of DDS allows for software teams to agree on what data (i.e., types and topics) should be distributed and how (i.e., with what QoS settings), without the need to necessarily expose data processing APIs. Similarly, DDS Security configurations for built-in plugins (e.g., domain governance and participant permission files) allow for defining security policies for data distribution. These explicit policies are created based on your data models and how you would like to protect DDS domains. These policies can be independently reviewed by security engineers and system architects, and be readjusted based on risk analysis and performance requirements without introducing changes to the application code.
A positive answer to question 4 likely means that you want to make the best use of multicast for much more efficient data delivery. Unlike popular transport-level solutions such as TLS/DTLS that cannot utilize benefits of multicast, DDS Security comes built-in with multicast support allowing a more optimized data delivery performance.
If your answer to question 5 is positive, you have the chance to build in security without worrying too much about having to deal with legacy code. At the same time, you likely have scalability, interoperability and avoiding vendor lock-in on your list of requirements. DDS is one of the core connectivity technologies for the IIoT (see IICF for more details) and is based on a publicly available set of specifications. Moreover, DDS Security utilizes a pluggable architecture with standardized APIs for authentication, authorization, cryptography, data tagging and logging. These features, together with supporting explicit and granular security policies for data distribution, make DDS a strong candidate for next-gen IIoT systems allowing for designing security in, not bolting it onto, your system architecture.
This all sounds interesting, but is anybody using DDS Security? The answer is a strong yes. RTI Connext DDS Secure has already been evaluated and used by a number of our commercial and government customers. We have reflected the feedback that we have received from these early adopters into our product line. In cases where further clarification or updates have been necessary to the DDS Security Specification, we have brought up the issues to the DDS community to further improve the standard.
Example: DDS Security for Secure Medical Device Interoperability
An interesting example that shows benefits of DDS and DDS Security shows up in the context of Integrated Clinical Environments (ICE). The ICE framework, as defined by the ASTM F2761-09 standard provides an approach for integrating heterogeneous medical devices and coordinating their activities to automate clinical workflows. From a high-level perspective, the idea behind ICE is to allow medical devices that conform to the ICE standard, either natively or using an aftermarket adapter, to interoperate with other ICE-compliant devices regardless of the manufacturer. If done correctly, this approach has the promise of enabling dramatic improvements to patient safety. Known examples include patient transfers from the Operating Room (OR) to Intensive Care Units (ICU) or reducing false alarms in Patient-Controlled Analgesia (PCA) systems. In both of these examples, cross-vendor inter-device communications significantly reduces preventable medical errors. OpenICE is an open source reference implementation of the ICE platform that uses DDS as its underlying connectivity mechanism.
OpenICE – Developed by MD PnP Lab, it enables connectivity between various types of medical devices.
Without deployment of explicit security measures, a medical IIoT platform such as ICE is susceptible to security attacks that could endanger patients’ safety and privacy. An example of an attack can be viewed in the following video wherein the attacker acts as a man-in-the-middle. She masks readings from an actual oximeter device and fabricates false oximeter readings with the malicious intent of hiding away the potentially critical condition of the patient from the nursing station.
Is transport-level security sufficient for protecting connectivity in ICE?
As described in a more detailed attack scenario in this paper, even though all communication is encrypted and authenticated with transport-level security (e.g., TLS/DTLS), a compromised insider device can still cause system-wide damage, simply because what it can or cannot publish is not enforceable without granular access control. DDS Security allows for fine-grained access control per device, mitigating the impact of this significant type of insider attack to a large extent.
In addition, being able to fine-tune security measures based on risk is especially important for resource-constrained devices or large-scale ICE or medical IoT systems with bandwidth or delay-sensitive applications. Further, such fine-tuning should ideally happen with minimal, if any, changes to the code base, as the code may not be available for modification or be too costly to modify. As mentioned above, lack of multicast support, which has proven extremely useful for efficient and scalable discovery and information exchange, is an addition to these shortcomings.
Of course, this is not to say that TLS/DTLS based solutions should not be used at all. RTI already has customers who use our customized TLS or DTLS transports with DDS because they are a better fit for their specific use-cases. At RTI, we are happy to help you make an informed decision about making such choices based on risk and performance requirements during our Architecture Studies.
Conclusion and References
We strongly advise considering RTI Connext DDS Secure and the standard it is based on, OMG DDS Security, especially if you are developing applications for critical infrastructure. You may find the following references useful: