The world's most capable, rugged and secure
industrial control system...
Introducing Bedrock OSA® Remote
- Intrinsically-secure PLC and RTU control
- 10 or 20 channels of universal I/O
- Free IEC 61131-3 engineering software
- -40ºC to +80ºC temperature range
- Rugged, all-metal case 5.4 in x 8.9 in x 2.3 in
Securing MQTT – Absolutely, Positively
January 27, 2022 | Robert Bergman
The Message Queuing Telemetry Transport (MQTT) protocol is kind of like the FedEx of electronic communications. Just as FedEx revolutionized package delivery by routing everything to a central hub — regardless of distance — MQTT provides a digital clearinghouse that synchronizes message exchange among multiple automation devices, applications, and services.
MQTT was developed primarily to monitor oil pipelines within a SCADA environment. The developers were seeking a messaging protocol that was bandwidth-efficient, lightweight, and power-efficient. In a recent presentation, Kudzai Manditereza explains why this was necessary for SCADA.
“SCADA systems traditionally employ a polling mechanism to acquire process data, whereby the SCADA communication engine has to actively poll all sensors and devices representing the current process state, one after the other to get new data. And in most cases, this is done using point-to-point protocols. No doubt about it, such an architecture is prone to communication failures due to application blocking, cannot easily scale because of bandwidth limitations, and is so tightly coupled that participants have to know a great deal about each other’s implementation,” Manditereza writes.
Instead, he says, in an MQTT implementation, devices themselves package the data into topics and publish it to a centralized broker only when there is a need to communicate. Any other services, applications, or devices that use that data would be subscribed to the same topics on the MQTT broker, which would push data to them as it becomes available, for example whenever there is a change in the key production variable.
According to IBM Vice President for Software Standards Angel Dias, who was involved in the advancement of MQTT, removal of the limitation on point-to-point or end-to-end connections between network nodes, opens the door to defining more sophisticated interactions among edge and enterprise clients.
“… as you start to look at the type of analytics, the type of rules, the type of processes, the things that you can do now with that information that’s being shipped around the Internet, you can start to just imagine applications that actually focus more on the business processes themselves, not just the connectivity,” said Dias, in an interview early in the development of MQTT.
Requirements for Big Data Analysis
Even though MQTT initially targeted industrial applications, it was developed at a time when most industrial automation systems were proprietary and when big data analysis for real-time industrial operations was still vaporware.
“Big data applications cannot use proprietary data types as defined in Operational Technologies (OT) but rather need data objects as it sees in Information Technology (IT). OT uses cryptic protocols from many different market segments, each with different data types and mechanisms for operations. MQTT needed a way to define the information that comes from OT and deliver it to IT,” said Arlen Nipper, CEO, and CTO at Cirrus Link and co-creator of MQTT, commenting on the need for an industrial specification for MQTT.
Cirrus Link met this need in 2017 with the creation of the MQTT Sparkplug specification, which Nipper defines as an “open-source software specification that helps clients seamlessly integrate data between their sensors, devices or gateways and applications within an MQTT infrastructure.”
Sparkplug did for MQTT what EtherNet/IP did to create an industrial protocol Ethernet. It defined namespace requirements so that no two data-producing or consuming nodes could have the same name or address. It managed the connection state so that the network would know the difference between whether a network node is offline or just idle awaiting a variable change. And it defined payload format conventions, enforcing a common structure for all data in the channel.
Securing the communications
With a robust messaging exchange and message definition in place, one more thing was necessary for critical industrial communications: cyber security. While Sparkplug B, an MQTT specification that defines how data is sent and received, did have some configuration options that improved security, perhaps its most significant contribution was enabling the structural consistency to implement an important security standard, Transport Layer Security (TLS) on its edge and enterprise clients.
Deploying TLS with MQTT involves public/private security certificates that require MQTT edge or enterprise clients to establish a connection to an MQTT broker that is authenticated by a Certificate Authority (CA), the same level of security that is considered best practice in banking systems today. Only clients holding thusly-authenticated electronic certificates can subscribe to data that the MQTT server would publish. The server will send data upstream to enterprise clients but will not let them communicate back to the OT or engage in remote management.
How Bedrock Simplifies MQTT Security – by Default
Deploying TLS in an OT environment can be complicated and error-prone, which leads to increased cost risk. However, Bedrock Automation’s latest software platform embeds an MQTT client along with its managed public key infrastructure into its firmware, enabling the creation of MQTT applications that are secure by default. Bedrock manages the PKI and TLS implementation so developers can focus on their applications rather than a complicated certificate and TLS connection management. Developers configure tags using the symbol configurator that is in its free IEC 61131 IDE. This brings us one giant step closer to industrial operations that are absolutely, positively secure.
For more info on Bedrock Automation’s MQTT Sparkplug B implementation see: New Software Release from Bedrock Brings More Open Secure Automation (OSA®) Process Functionality and Diagnostics into Bedrock Systems
For the latest specification of MQTT Sparkplug B visit the Eclipse website.