Defense in Depth: Using MQTT to Reduce Cybersecurity Risks
Author’s Note: Our Defense In Depth series will demonstrate how over the past several years Corso Systems has helped companies implement security. The series includes relatively easy best practices like ensuring your systems are secured with user accounts, network segmentation with Firewalls to reduce the flow of traffic to only what is necessary to move between each part of your operation. We will also discuss more complex technologies such as threat detection, and backups/disaster recovery so you can get back up and running even in the worst case scenarios.
Most manufacturing and critical infrastructure systems (utilities, wastewater treatment, communications, dams, and many more) need to get data to and from PLCs, SCADA systems and other devices. MQTT is a very popular communication protocol being deployed across projects in every industry imaginable.
Since the data used in manufacturing and critical infrastructure facilities is highly sensitive and valuable, securing this data from bad actors is extremely important. Compared to many other industrial communication protocols, MQTT provides some built in security features to help you secure your data as it flows across your network.
You will still need to consider how you will be securing your PLCs, SCADA Systems, databases, and your overall network, because you are only as protected as your weakest link. Adding MQTT to the mix will help you leverage your overall cybersecurity infrastructure in a modern way that’s impossible with tools like Modbus. Cirrus Link, the makers of the Ignition MQTT Modules has a great, albeit brief write up on overall MQTT Security Best Practices. We will cover all of the topics included there, plus more in this post.
This post will focus on using the security options available to with MQTT.
MQTT Network Architecture
The overall architecture of an MQTT network brings your field devices into MQTT Gateways, PLCs, or other software tools which communicate with an MQTT Broker. Once data is in the MQTT broker, it is available to any other devices or software you choose. The image below is from our book, Unified Namespace: The Ultimate Guide.
Using an MQTT broker is inherently more secure than a standard industrial network because your devices and software tools no longer need to communicate directly with each other. This approach reduces the overall number of nodes on your network, and thus limits your attack surface.
A much simpler network architecture showing only one device, taken from the Cirrus Link MQTT Best Practices Security Guide is shown below:
In the example above is a field device, usually a PLC or Ignition Edge gateway behind a firewall. This is connected through another firewall to an MQTT Broker. One key item to note is that the Edge Network firewall doesn’t require any ports to be open, because the Edge Devices initiate the connection to the MQTT broker. This means anyone trying to get into the Edge device is effectively locked out from communicating with it unless they get into the MQTT broker directly.
The firewall protecting the MQTT broker only has the ports required for MQTT communication open, again limiting what anyone can see on that network even if they have access to that network.
The MQTT broker also uses username/password authentication and access control lists to limit which devices and users have access to specific data in the broker.
The “TLS Connection” indicator means certificates are used between the Edge devices and the MQTT broker to encrypt traffic between them making it extremely difficult for anyone to see the data is flowing over the network connection.
As discussed in our Defense In Depth: Securing IT and OT Networks post, locking down any unused ports on your network is an easy and extremely important tool in your cybersecurity arsenal to prevent people from getting into portions of your network they shouldn’t access.
Authentication
Even if you don’t take advantage of any other security features of MQTT, you should always use username/password authentication.
You can set up as many users on your MQTT broker as you need, adding those credentials to your device and software tools to authenticate their connections to the broker. Similar to default database users as covered in Defense In Depth: Securing Databases, you should move away from the default username/password combination in your broker as soon as you can after you initial set up.
Depending on the broker you are using these default credentials may be publicly available giving attackers easy access to your system if you haven’t changed the defaults.
Using different username/password combinations for each device and user will also help you shut off access to contractors at the end of a project, or to anyone or anything that no longer needs access to your data.
Certificates and HTTPS Connections
Beyond username/password authentication, you can set up certificates for your MQTT brokers to enable secure communication over HTTPS. This encrypts your data as it moves across the network, making it extremely difficult for anyone with access to the network connected to your broker to see what data is flowing.
Using certificates is vitally important for systems using a cloud-based MQTT broker where you are sending data across the internet. Certificates act as another layer of security on top of basic username/password authentication and are an important part of an overall cybersecurity strategy for your OT and IT networks.
If you are using Corso Systems’ incredible partner Opto 22’s groov hardware, setting up these certificates is simple. If you aren’t using hardware like the groov EPIC and groov RIO, you will likely need to work with IT to set up certificates, or you can reach out to Corso Systems and we can help you get everything squared away.
Access Control Lists
Access control lists (ACLs) provide you with a detailed method of limiting what users, devices, and software have access to in your MQTT broker.
If you don’t use access control lists, you are effectively giving anyone with a connection to your MQTT broker full access to all of the data in it. This might be okay with you if you are the only entity using the data in your MQTT broker and you aren’t worried about different users having access to all of the available data.
When to Use Access Control Lists:
If you have multiple vendors working on your systems
When you need to limit who can write to certain MQTT topics or if they only need read-only access
Have data set up for a Unified Namespace
When you have data that other companies need to use
If you simply want to keep some of your data hidden from anyone connected to your broker
The specifics of Access Control Lists for each MQTT broker on the market could have their own post so we will cover the basics here.
Configurations to Consider for ACLs:
Topic Access - Specific Topics or all Topics with a # Wildcard
Allowed Operations - Publish, Subscribe, or both
Quality of Service Level - 0, 1, 2, or all levels
Topic Access
With ACLs, you can define which MQTT topics any user has access to. You can enable access to all topics using # as a wildcard character for all levels of the topic structure, or a + as a wildcard at a single level of the topic structure. HiveMQ, a popular cloud-based MQTT Broker, has a great write up on topic structures and wildcards we recommend checking out.
As a basic example in a manufacturing facility if you have a number of production lines you can set up an ACL with the topic structure CorsoSystems/ProductionLines/# and this will give the user access to all of the data for any production line. If you wanted to lock it down to only Line 1’s data it could look like CorsoSystems/ProductionLines/Line1/#. If instead you wanted to lock down only to the conveyor system data on any production line you could use CorsoSystems/ProductionLines/+/conveyors/#.
Allowed Operations
You can also set up the allowed operations for your ACLs giving users the ability to Publish, or write data to the broker, Subscribe, or read data from the broker or both.
Typically this would give your system more granular control over who can write data to the system if you have multiple edge devices that might write values to your MQTT broker. Setting only a particular user or device with publish access will mean it will be the source of truth for the data. Anyone who needs to read the data but not write to it can be set to subscribe only, and if you have a system that needs to do both you can set this up accordingly.
Quality of Service
Typically Quality of Service is set up as a system wide configuration, however you can also configure it with an ACL if desired. We will leave those particulars out of the scope of this post, and if you need more information on QoS in general, we recommend checking out the QoS post from HiveMQ.
Wrapping Up
MQTT is a powerful tool, especially from a cybersecurity perspective. It reduces the overall network attack exposure by limiting device to device communication, routing everything through an MQTT broker. It also reduces the number of ports you need to keep open for communication across your network (as compared to other communication protocols).
One limitation of MQTT is that many PLC vendors do not support it out of the box, so you may need additional hardware like MQTT Gateways, or other software tools like Ignition along with the MQTT Modules from Cirrus Link to convert from the PLC supported protocols to MQTT. As MQTT adoption has grown seemingly exponentially over the last few years this isn’t necessarily a difficult proposition, it is simply something to be aware of when adding MQTT into your overall communications architecture.
We really like how MQTT enables security out of the box, and in many cases has made the transition to a more cohesive cybersecurity strategy much easier once customers begin using it. When you add the power of MQTT’s security features to an existing system, it is easy to see where the weakest link is beyond MQTT and start focusing your security hardening efforts in those areas.
Please take this post to heart and make sure you have everything you need in case disaster strikes, wherever it may come from.
If you have questions on how to implement MQTT for your manufacturing or critical infrastructure systems please reach out and we can help get them answered and work with you on your overall cybersecurity strategy!
