Five keys to securing the IIoT data pipe
Industrial systems have traditionally had connectivity at least at some level, so why with the dawn of the Industrial Internet (or Industrial Internet of Things (IIoT)) has security now become such a poignant issue?
Well, there are several reasons, but the most notable is that historically the practice of industrial network administrators has been to architect closed or private systems, which although still susceptible to internal attacks via USB stick, for example, allow the network team to get some sleep at night. Today, however, industry is realizing the missed opportunities that have resulted from squandered connections between machine data and analytics in those conventional configurations, and have begun pushing for designs that leverage the Internet and the cloud more heavily. Obviously, opening these networks to the broader Internet comes with inherent security risks, and further complicates the ongoing tradeoff developers must make between performance, reliability, and security; for IIoT applications and devices that are built on the premise of robustness and resilience, sacrificing too much of one or the other of these is often a non starter.
In response, companies are turning to the data distribution service (DDS), a middleware standard governed by the Object Management Group (OMG) that provides a scalable, secure data pipe for Industrial Internet systems. While the DDS standard itself was originally developed by Real-Time Innovations (RTI) and Thales Group in 2001 and approved by the OMG in 2003, vendors of the middleware recently realized the need for more comprehensive definitions of the security model and service plugin interface (SPI) architecture in the standard, and subsequently began work on the DDS Security Specification (DDS-SECURITY) in 2014 (Figure 1). After successfully demonstrating interoperability of DDS-SECURITY at OMG meetings last month, David Barnett, VP of Products and Markets at RTI, agreed to walk me through the five key tenets of the spec.
Five keys to a secure IIoT data pipe
According to the DDS-SECURITY specification, the security model is built on five SPI implementations that “enable out-of-the-box security and interoperability between compliant DDS systems.” When combined the Authentication, Access Control, Cryptography, Logging, and Data Tagging SPIs work to provide information assurance when using DDS, each of which we’ll review individually.
- Authentication – In the DDS-SECURITY spec, authentication is used to verify that every device or user participating in a distributed system is who he, she, or it attests to be. The DDS Authentication SPI provides faculties for performing mutual authentication between participants so that “shared secrets” can be established, and sets the table for Access Control.
- Access Control – Access Control may be the most critical security component of Industrial Internet/IIoT systems, as it defines who can publish or subscribe to a certain type of data or metadata across a DDS network. DDS provides very fine-grained access control, and includes a “discovery” feature that enables applications to be written in such a way that when new sensors are added to a network they can automatically be identified without any additional coding required. The Access Control SPI also gives developers control over the kinds of data/metadata those applications have visibility into, which combined with discovery is key to building and deploying scalable distributed networks.
- Cryptographic – The Cryptographic SPI, in other words encryption, ensures that data moving across DDS networks in private. However, unlike typical forms of encryption, the elegance of cryptography in DDS is that it allows developers to choose what data needs to be encrypted and what doesn’t. While simply encrypting all data traversing the network may seem like the most logical solution, the ability to select only certain data for encryption is important for the resource and bandwidth constraints of industrial systems and networks. For those messages that are not encrypted, the DDS Security Specification also includes provisions for secure digital signatures so that senders can be authenticated without the overhead of encryption itself, which helps protect systems that may be vulnerable to spoofing or man-in-the-middle attacks.
- Logging – Another important feature of the DDS Security specification is logging, which supports auditing of all security-related events on a distributed network. This gives administrators the ability to monitor any attempts to break into the system, including instances when the content of a message doesn’t match its signature, usually an evidence of a man-in-the-middle attack.
- Tagging – Finally, tagging is a feature that allows developers to inject metadata into a message that designates the content’s security level. As an extension of access control, this makes it possible for sensor data from a wind turbine, for example, to be classified by “confidential” or “unrestricted” so that the appropriate data can be mad available only to specific participants in large distributed networks.
RTI provides these DDS-SECURITY SPIs in their out-of-the-box Connext product that uses standard algorithms for encryption and public key infrastructure (PKI) for authentication, and also implements a plug-in approach for organizations that already have already policies and practices in place, or that need to meet the certification requirements of a particular industry. The flexibility of the DDS domain-specific modeling paradigm is one of the elements of the middleware that set it apart from other low-level messaging standards such as MQTT and CoAP, and a major enabler of the five keys to a secure IIoT data pipe.
OMG members expect to approve the DDS-SECURITY specification by the end of the year.
For more information on DDS security, watch the on-demand E-cast “,” or register for the upcoming event, “ .”