Securing MQTT Messages

A key aspect of MQTT’s (message queueing telemetry transport) architecture involves the use of an intermediary server to collect data, as it changes, from the devices it is connected to. It then publishes those data points to other systems or applications that subscribe to those specific data feeds collected by the server. Because the subscribing systems or applications do not directly connect to the device they are monitoring, some levels of security are inherently supplied by the MQTT messaging structure.

Like any security measure, however, this decoupling of devices and the systems that subscribe to them does not address every potential cybersecurity angle. Beyond the direct disconnect offered by the server, MQTT infrastructures support several options that use widely adopted internet security methods, such as those used in online banking and recommended by NIST (National Institute of Standards and Technology).

MQTT infrastructure

To understand MQTT’s various security measures, it helps to first understand the building blocks of MQTT’s IIoT (Industrial Internet of Things) infrastructure:

MQTT edge clients – These are remotely distributed devices and/or gateways in the plant or field connected to your process to gather data.
MQTT enterprise clients – This can be any centralized or remote application that needs to subscribe to an MQTT server to receive or send information in the IIoT infrastructure.
MQTT server(s) – These are centralized servers that the edge and enterprise client applications connect with to send and receive data.

Arlen Nipper, president and chief technology officer at Cirrus Link and co-creator of MQTT, explains that both the MQTT edge and enterprise clients use the same security models. “Each initiate an outbound connection over the TCP/IP network utilizing transport layer security (TLS) with security certificate credentials from a certificate authority (CA),” he said.

TLS uses a set of public/private security certificates where the MQTT clients must establish a connection to the MQTT server that is authenticated by the CA. This is the same level of security used in banking systems today and is considered best practice by NIST.

This illustration depicts MQTT edge client connectivity. Source: Cirrus Link.

The network architecture of MQTT topologies requires that MQTT edge clients have all inbound TCP ports over the network disabled, explained Nipper. “This provides a high level of security by preventing potential attackers on the internet/intranet from simply establishing a connection with the edge devices.”

While this configuration provides solid security, Nipper notes that it can create challenges for accessing the edge client for remote debugging and configuration. “These challenges can be overcome using a reverse VPN connection,” he said.

Read this story on what the publish/subscribe communication paradigm means for industrial networks.

Server security

The configuration of the TLS used with the edge device is also used with the MQTT servers. “MQTT servers utilize further security measures in the form of MQTT level username, password, and an access control list (ACL),” said Nipper. “The ACL limits which devices will be allowed to connect into the MQTT server. The ACL also controls what topics a given username/password pair can publish and subscribe to, providing further security.”

Nipper added that the MQTT servers should be setup in a DMZ and behind a firewall that only allows two inbound ports for connection: 8883 and 443.

This illustration depicts MQTT enterprise client connectivity. Source: Cirrus Link.

As the MQTT servers provide the message delivery mechanism in the enterprise services bus, Nipper noted that the MQTT servers “must be 3.1.1 OASIS-compliant.” Cirrus Link supplies an MQTT Distributor and Chariot MQTT Server for this purpose. The company also supplies the Chariot MQTT Server for multiple MQTT server redundancies and a higher number of connected clients for on-premises or cloud-connected applications.

Protection overview

To reiterate the security recommendations made above, Nipper suggests applying the following security measures at the transport and application levels:

Physical network/VPN for ultimate security;
TLS with certificate credentials from CA for all connections;
All inbound ports should be disabled at MQTT edge clients;
Only two TCP/IP ports (8883 and 443) should be open at the MQTT server;
Use MQTT client username/password at MQTT servers; and
ACLs should be used to limit MQTT client access to the topic levels they can either publish or subscribe to.

Security layers
Nipper pointed out that network security can be divided into three layers—each of which provide a different level of security against cyber-attacks:

The physical layer provides the highest level of security where the network is isolated from any outside connection or is completely encapsulated in a virtual private network (VPN).
The transport layer uses transport layer security (TLS) with security certificate credentials from a certificate authority (CA) to secure infrastructures that use public networks, where setting up discrete VPNs to each end device is not practical or cost effective. Firewalls can also be used at the transport layer to close all TCP/IP ports on the remote devices, and only the minimum ports necessary for operation at the central location should be allowed.
The third layer is application security where, within Cirrus Link MQTT Servers, username/password authentication is applied with access control lists (ACL).

“The combination of these layers ensure a robust secure IIoT network,” said Nipper.