Securing MQTT: Best Practices for a Robust IoT Ecosystem
MQTT is a widely used protocol for connecting IIoT industrial devices, enabling efficient and real-time data exchange. However, it often gets misunderstood for security vulnerabilities, leading to misconceptions about its safety. In this paper, we will discuss essential steps to ensure MQTT security, from edge devices to cloud servers, and how to address denial of service (DoS) attacks effectively.
MQTT Security: Learning from Mistakes
Understanding the common security pitfalls is the first step in strengthening MQTT implementations. One common issue is insufficient authentication and authorization mechanisms. Without proper configuration, the MQTT protocol allows any MQTT client to subscribe to any MQTT server that is available on the Internet. Insecurely configured brokers may allow unauthorized access, leading to potential data breaches.
Another pitfall is the lack of proper access control. Failing to implement Access Control Lists (ACLs) can result in unauthorized entities gaining access to the MQTT broker. This can lead to unauthorized data retrieval or even the injection of malicious data into the system.
The misuse of MQTT via implementation vulnerabilities tarnishes its reputation. Studies have uncovered unsecure MQTT hosts reachable via public-facing IP addresses, unsecure configurations, and a lack of well-defined security strategies. Endpoints with vulnerabilities may be susceptible to denial-of-service (DoS) attacks or exploitation.
An effective way to highlight the need for a secure MQTT configuration is through the analogy of a bank vault with an open door. Just as a bank vault is designed to safeguard valuable assets, an MQTT broker protects sensitive data. However, if the vault door is left open, the entire security infrastructure collapses.
Similarly, an insecurely configured MQTT broker is akin to leaving the vault door wide open. It exposes critical information to unauthorized entities, rendering any security measures ineffective. This analogy underscores the importance of configuring MQTT securely, just as one would secure a bank vault to protect valuable assets.
Organizations must plan for and leverage MQTT’s tools for security. This white paper will discuss the basics of MQTT’s security features, security best practices, how to apply the Purdue Model, and extra security measures and tools available to fortify MQTT-based IIoT deployments.
The Basics: TLS and ACLs
Network security can be divided into three layers that each provide a different level of security. 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 VPN’s to each end device is not practical or cost effective. Implementing TLS ensures encrypted data exchange, preventing unauthorized access to sensitive information. Firewalls can be used at the transport layer to close all TCP/IP ports on the remote devices, and only allow the minimum ports necessary for operation at the central location.
The third layer is Application security where, within our MQTT Servers, we have implemented username / password authentication in conjunction with Access Control Lists (ACL). The combination of these layers will ensure a robust, secure IIoT network.
TLS for Secure MQTT Client Connectivity
Both the MQTT Edge and Enterprise Clients utilize the same security models. Each initiates an outbound connection over the TCP/IP network utilizing TLS with security certificate credentials from Certificate Authority (CA). TLS uses a set of public/private security certificates where the MQTT Clients must establish a connection to the MQTT Server which is “authenticated” by the CA.
Due to the unique network architecture of MQTT topologies, MQTT Edge Clients have ALL INBOUND TCP PORTs over the network disabled. This provides a high level of security by preventing potential attackers on the internet/intranet from simply establishing a connection with the Edge devices. This configuration, while giving the best security, can create challenges for accessing the Edge Client for remote debug and configuration. These challenges can be overcome using a reverse VPN connection.
TLS for MQTT Server Security
The MQTT Servers provide the message delivery mechanism in the Enterprise Services Bus. The MQTT Servers must be 3.1.1 OASIS compliant such as the MQTT Distributor or Chariot MQTT Server supplied by Cirrus Link. For multiple MQTT Server redundancies and a higher number of connected clients, the Chariot MQTT Server is offered for on-premises or cloud-connected applications.
MQTT Servers must be configured with the same TLS Security as used by the MQTT Edge device. MQTT Servers utilize further security measures in the form of MQTT level username, password, and an Access Control List (ACL). 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 on providing further security.
The MQTT Servers should be setup in a DMZ and behind a firewall that only allows two inbound ports for connection: 8883 and 443.
Authentication and Authorization
Ensuring the security of IoT deployments demands a meticulous focus on authenticating and authorizing devices. Bad actors might endeavor to fabricate virtual devices, infiltrate deployments, and propagate malicious data throughout the network. In instances of exploiting vulnerabilities, they could illicitly gain entry to other devices within the deployment, posing a risk of assuming control over pivotal devices like industrial machinery, medical equipment, or smart infrastructure.
As a result, organizations must establish robust authentication and authorization controls to safeguard access to devices and brokers within their IoT deployment. They can employ multi-factor authentication to authenticate users. Proper authentication and authorization mechanisms ensure that only authorized devices can access and interact with MQTT brokers, minimizing the risk of unauthorized access.
Additional security capabilities can be added such as the LDAP Security Service provided by the Chariot MQTT Server which adds an LDAP Realm to use when authenticating and authorizing access via the Chariot UI. Each LDAP Realm uses a simple bind authentication to connect to the LDAP server to search for users and groups. A user that is logging in to the Chariot UI will have their username mapped to the distinguished name (DN) of an LDAP entry using a configure template. Chariot will use simple bind authentication to authenticate the user and will search for group membership to determine the corresponding Chariot Role membership using the configured mapping.
Another added layer of security is offered by implementing secure writes. This is where the credentials of the authorized user to send a command are contained in the MQTT message from the host client. This feature is offered by the Ignition MQTT Engine module. The edge client, MQTT Transmission, validates these credentials prior to executing the write validating a secure chain.
ACL (Access Control List) Management and Least Privilege
Access Control Lists (ACLs) control what topics a given username/password pair is allowed to publish and subscribe on. ACLs should be designed with a Principle of Least Privilege model while also considering device management and maintenance. The Principle of Least Privilege grants each device only as many rights as necessary. For example, gateways and devices in the field should be limited to publishing and subscribing only on the topics for which they should be expected to. The same should be true of ‘consumer’ applications that will be either sending commands to devices in the field or consuming data coming from those devices.
Implementing Access Control Lists (ACLs) and adhering to the Principle of Least Privilege are essential steps in securing MQTT. By limiting open ports and unnecessary access, the MQTT ecosystem becomes less vulnerable to potential threats.
Preventing DOS Attacks
Beyond utilizing MQTT’s basic security features, let’s talk about how to handle Denial of Service (DOS) attacks. DOS attacks are network-related issues, they are not MQTT-specific. Organizations must have robust network infrastructure protection to prevent and mitigate the impact of DoS attacks.
ACLs and user permissions can help reduce the possibilities for attack since organizations can limit the actions authorized devices can perform. In the event of a hacker getting access to an MQTT client, the impact is limited to the restricted capabilities of the device based on its assigned role and permissions.
Organizations should have strategies in place for proactively responding to DoS attacks such as intrusion detection systems, traffic analysis tools, and real-time monitoring to identify and mitigate potential threats before they impact the MQTT ecosystem. A collaborative response framework is an excellent idea, which dictates how network providers, security teams, OT, and IT teams all collaborate on communication protocols such as MQTT, incident response plans, and continuous improvement strategies.
Applying the Purdue Model/ISA 95
The Purdue Model of Computer Integrated Manufacturing was published in 1990 as a reference for enterprise architecture – a hierarchical model for manufacturing automation that defines what type of equipment goes where, what actions are supposed to happen at each level, and how machines and processes interact. Almost a decade later, the International Society of Automation extended the Purdue Model and created ISA 95, an international standard for enterprise-control system integration.
The Purdue Model is built as a stack and defines the following layers as shown in Figure 1. Level 0 is the physical process where the actual equipment resides – sensors, robots, etc. Level 1 includes basic control such as PLCs and controllers. Level 2 is for area supervisory control such as HMIs or a SCADA system. Level 3 includes site operations, where centralized control and operator terminals reside, and where OT systems report up to IT systems. Level 3 systems aggregate lower-level data that needs to be pushed up to higher-level business systems.
In between Layer 3 and 4 is the Industrial Demilitarized Zone, a buffer between the OT and IT zones that enforces security policies. Level 4 is for site business and logistics and includes all the IT systems that support the production process in a facility such as database servers, application servers, etc. At the very top is Level 5, which is the enterprise network of systems that sit at a corporate level, spans multiple facilities, and includes connections to the Internet.
The Purdue Model prescribes security by separating the layers and keeping them isolated from each other to prevent any security breaches between Level 0 and Level 5 or anywhere in between. The Purdue Model ensures that OT systems are isolated from IT so they do not receive non-production data that might cause issues or slow manufacturing processes. The model dictates the flow of data from the bottom-up. Data generated from the process on Level 0 can be collected, normalized, and pushed up through the layers, but layers above cannot talk to layers below. The concept is a critical strategy for most OT operations today.
A Security Case Study: Vessel Control Systems
In this case study, a multinational energy corporation sought to secure its IoT deployments across a fleet of vessels equipped with diverse onboard systems. Facing challenges such as siloed OT systems, redundant data paths, limited VSAT bandwidth, and the security requirements of the Purdue Model, the company implemented a robust security-focused solution.
To address security concerns, the company established clear requirements for the chosen solution. They opted for the Ignition SCADA software with MQTT and Sparkplug modules, prioritizing security features. Ignition served as the main navigation program, offering high availability and a suite of tools, while the Cirrus Link MQTT Modules facilitated secure data transfer from OT to IT. MQTT, known for its lightweight and secure messaging protocol for Industrial IoT, played a crucial role in securely moving data upstream to the cloud.
The implementation of Sparkplug added an additional layer of security, ensuring auto-discovery and contextualization of data. By adhering to Sparkplug B, the company operated safely and securely across different levels on the vessels, maintaining critical safety protocols. Sparkplug, being an open-source software specification, facilitated serving OT data up to applications via MQTT, enhancing security by contextualizing data without compromising sensitive information.
The chosen solution not only met the security goals but also provided a scalable, reliable, and efficient way to share data. It adhered to the Purdue Model’s security requirements, creating a virtual air gap for secure data transit across different vessel levels. The combination of Ignition, MQTT, and Sparkplug allowed the company to establish a single source of truth for data, ensuring security without granting unauthorized access to OT systems.
MQTT Sparkplug Security Features
With the modern demands for data (big data, machine learning, etc.), OT data needs to be served up to multiple subscribers securely without the consumer having any access to the layers below as defined by the Purdue Model.
Sparkplug is an open-source software specification that facilitates serving OT data up to those applications via MQTT with contextualization so any subscriber can learn everything about the device and data immediately without compromising security.
Sparkplug defines a standard MQTT topic namespace, payload, and session state management for the MQTT message, and decouples the data to enable a one-to-many approach for unlimited data consumers. Sparkplug makes tags 100% auto-discoverable and easy to consume and establishes a single source of truth at the edge. Again, Sparkplug accomplishes all of these tasks without giving any other system access to the shop floor. So, multiple consumers can access the data without any security concerns.
Sparkplug pushes the contextualized data up from level 3 to what is commonly referred to as level 3.5, the DMZ zone, as a secure outbound connection. Then, layer 3.5 has self-awareness of what is happening at the edge, so if any changes or modifications are made at levels 2 and 3 – if tags change or new devices are added – the applications using the data are automatically subscribed to all that information.
Once the data comes up to level 3.5, all or a subset of the data can be pushed up to the applications on level 4 or 5. Now you have all your business applications subscribing to the data from the levels below and it’s self-aware and all applications and environments are learning this data. The data is pushed up without any of the layers above connecting to the layers below to meet all the Purdue Model laws and requirements.
Extra Security Measures and Tools
There are some excellent resources for comprehensive MQTT security guidelines. Please consider the following before an MQTT implementation.
The MQTT Standard from Oasis
Introduction to MQTT Security Mechanisms by Steve’s Internet Guide
Securing MQTT Messages by David Greenfield, AutomationWorld
MQTT Enables IIoT Security Best Practices within the Purdue Model by Arlen Nipper, Cirrus Link
MQTT is a powerful protocol for connecting IoT devices, but its security reputation can be misleading. By following best practices, implementing TLS, and adhering to the principle of least privilege, MQTT can be made secure. Collaboration with network infrastructure protection teams is essential for addressing DoS attacks and using frameworks like the Purdue/ISA 95 model can provide robust security layers. Leveraging the Sparkplug protocol and other tools can further enhance MQTT security, ensuring a re