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 into and out of PLCs, SCADA systems and other devices. MQTT is a very popular communication protocol being deployed across projects in every industry imaginable.
Due to the highly sensitive and valuable nature of the data used in manufacturing and critical infrastructure facilities securing this data from people with malicious motives 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 still need to take into consideration how you are 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 not possible with tools like Modbus. Cirrus Link, the makers of the Ignition MQTT Modules has a great, albeit brief writeup on overall MQTT Security Best Practices. We will cover all of the topics included there plus more in this post.
This post focuses on to take advantage of the various security options available to you when using MQTT.
MQTT Network Architecture
The overall architecture of an MQTT network brings all of your fields devices into MQTT Gateways, PLCs, or other software tools you can use to communicate to an MQTT Broker. Once data is in the MQTT broker it is available to any other devices or software. The image below is taken 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 one another. This reduces the overall number of nodes on your network, limiting 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 this example we see 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 notice is the Edge Network firewall doesn’t require any ports to be open because the Edge Devices will 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 it.
The MQTT Broker also uses username/password authentication and Access Control Lists to limit what devices and users have access to what data in the broker.
The other major piece of the puzzle is the “TLS Connection” indicator which 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 what 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 have access to.
Authentication
Even if you don’t take advantage of any of the other security features of MQTT one you should use no matter what is username/password authentication.
This lets you 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 when setting things up initially.
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 of your system will also help you shut off access to contractors at the end of a project, or to anyone or anything no longer needing access to your data.
Certificates and https Connections
Beyond username/password authentication you can set up certificates for your MQTT Brokers enabling 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 connecting 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 easy. If you aren’t using hardware like the groov EPIC and groov RIO you will likely need to work with IT to get certificates set up, 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 what 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 the Broker. 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.
If you have multiple vendors working on your systems, want to limit who can write to certain MQTT topics if they only need read-only access, have data set up for a Unified Namespace other companies may use to integrate with, or simply want to keep some of your data hidden from anyone connected to your broker Access Control Lists are the way to go.
The specifics of Access Control Lists could make up their own post for each MQTT Broker on the market so we will cover the basics here.
The following are the items you need 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 Using ACLs
Topic access lets you define what MQTT topics any user has access to. You can enable access to all topics using a # as a wildcard character for all levels of the topic structure, or a + sign for 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 Using ACLs
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 be used to give your system more granularity on 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 Using ACLs
Typically Quality of Service will be set up as a system wide configuration, however you can set it up using ACLs 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 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 amount of ports you need to have open to enable communication across your network compared to other communication protocols.
One limitation of MQTT is that there are a lot of PLC vendors that do not support it out of the box so you may run into cases where you need to add in some additional hardware like MQTT Gateways, or other software tools like Ignition along with the MQTT Modules from Cirrus Link to convert from 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 communication architecture.
We really like how MQTT enables security out of the box, and in a lot of 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!
