The story goes that a valve manufacturer wanted to have their networked smart valves certified for use in a nuclear reactor plant. The smart valve could report all sorts of critical data points to a database system and also be controlled by that SCADA system in the plant. But to get it certified for use, the smart valve had to undergo a rigorous security audit by the information technology (IT) department at the plant.
After a week of tests, the IT guys gave up and said to the valve manufacturer, “Your smart valve is broken. We can’t communicate to it. There are no open ports at all. It can’t be working, because it won’t respond.”
The smart valve manufacturer simply replied, “Exactly.”
Since there were no network ports open on the smart valve, there was no way to reach the valve over the network. But once the manufacturer explained, the IT guys approved the valve for use in the plant.
So, how did the smart valve manufacturer pass muster with IT? And how did the smart valve report its data and accept commands from the SCADA system without any open ports?
The trick is that every bit of data the valve communicated to other systems was device originated. That is to say, data communications originated from the smart valve (the client) and went through the valve’s device firewall and out to the designated service (the server, or database in this example).
Let’s quickly summarize our last blog on firewalls (if you haven't read it yet, be sure to check it out). Put simply, firewalls block all incoming connection requests. But firewalls typically permit outbound connections from services that originate from behind the firewall, and keep track of those connections to allow returning data to be passed back through to the originating service.
If you’re thinking that means our firewalled device can only send data and not receive data, keep reading. This is where a data communications method like MQTT comes in, and it’s pretty cool.
We have a great series of instructional videos on the topic of MQTT, including what it is, how it works, what role an MQTT broker plays, and more. So I won’t repeat all of that here.
It’s enough to say that MQTT is a publish/subscribe protocol a supported device can use to publish real-time values to a central broker over an authenticated, encrypted, persistent connection. And while that connection is active, the device can subscribe to any new values or commands that the broker received from other devices or services.
The way it works is that our MQTT-enabled device securely connects over the network to an MQTT broker using TLS encryption, along with a username and password to log into the broker.
Then, once the connection is established and active, the device issues a device-originating data packet that says, “I’m alive (state), here are my newly changed values (report-by-exception data), and please reply with any new messages for me (new commands or values).”
The broker accepts the data packet and responds by sending our device any data it is subscribed to receive, which could include commands from other devices or services, over that same active connection. The broker also securely forwards our device’s data to authenticated devices or services that subscribed to receive it over their active connections.
Meanwhile, the device continues sending a small 2-byte "heartbeat" at a scheduled interval, keeping the secure, encrypted network connection active and keeping the broker notified of its state.
Because the transmission of the heartbeat and new data originates from our device behind the firewall, the firewall allows return communication with any new commands or values from other devices and services. Thus with zero open ports on the firewall, our device can both report values and receive commands. It is two-way communications out and then back in on the same port, a port that is closed from the outside.
Pretty cool, right?
MQTT with groov EPIC
Of course, Opto 22's device isn’t a smart valve; it’s the groov EPIC edge programmable industrial controller. groov EPIC is protected by its own device firewall, and the same principles apply. These outbound, device-originating MQTT communications can be transmitted from the EPIC on either network interface, and no firewall ports have to be opened to allow data flow.
Think about this for a moment. If there are no configured open ports on the groov EPIC’s firewall for a given interface (say, ETH1, the untrusted network), a bad actor running a port scan on your groov EPIC on ETH1 would not find a single port open to exploit.
But because the MQTT data flow is device originating, and the firewall allows the data to go out, communications will occur. The EPIC’s firewall keeps track of the session status, and when the packets of data coming back from the broker arrive, they are allowed to pass back through.
Device-originating communications are a very powerful method of ensuring network security, again because there’s no need to open ports on the device for data to flow.
To be clear, MQTT is not the only option for this method; you can also use HTTP(S) GET and POST, since they also originate from the device. The message goes from the host and passes through the firewall. A packet of data is returned from the service and is allowed to return back through the firewall because it has the same session ID/header. But compared to HTTP(S) GET and POST, MQTT is generally much easier to implement and manage.
You’re in control
Keep in mind that you are in control of the device firewall in the groov EPIC. You can open ports for services or you can close them. If you choose to use device-originating communications exclusively, you can configure your groov EPIC to have no firewall ports open at all.
And then smile as your IT department says, “Your EPIC is broken; it won’t respond to our port tests.”
One point to make: as part of best practices, all outbound communications should be encrypted with Transport Layer Security, or TLS, even if they're not MQTT traffic. Otherwise, your API keys, usernames, passwords, and data could be susceptible to “man-in-the-middle” attacks, where a bad actor can view and intercept data on the wire. You don’t want that. So use encryption on all outbound traffic. (Look for a future blog post about user authentication, encryption, and certificates.)
The other major security advantage of this architecture is that all device usernames and passwords (or accounts) are stored in the broker. That means all attempts to connect to the broker are managed at the broker through these device accounts (Access Control Lists, or ACLs). This dramatically simplifies the security management of the MQTT architecture, because there’s just one place to manage who or what gets access to your data.
In closing, even if your device, application, or machine is not headed for a nuclear power plant, you should strongly consider the benefits of using device-originating communication methods—like MQTT—for all your device data communication needs, whether in your plant or from far-flung assets, wherever they may be.
Till next time.
Cheers, Mate.
Want to learn more about security with groov EPIC? Read our technical note, groov EPIC Security Design and Best Practices.