Secure Data Connections to the Cloud

Secure Data Connections to the Cloud
Secure Data Connections to the Cloud

There has never been a time when process data was more in demand, and never a time when the cybersecurity threats to infrastructure and mission-critical systems have been so great. Secure data connections from operational technology (OT) to the cloud are critically important. The most secure system is one that exposes zero attack surface to outside networks and the Internet.

There are currently two software technologies that can provide this level of protection: MQTT and tunnel/mirroring. MQTT is more widely known but has a few drawbacks. A good tunnel/mirroring implementation with a unified namespace provides the same level of protection while addressing those issues. Complementing these, data diode hardware can be used instead of a software firewall.
 

Closing inbound connections

The key to maintaining a zero-attack surface is closing all inbound connections (Figure 1), using a data diode, or closing all inbound firewall ports. Unfortunately, most industrial protocols follow a client-server model where the client must make an inbound connection to the server.

MQTT solves this problem by making outbound connections to an MQTT broker, typically run by a cloud service. Tunnel/mirroring uses a software component on the production side that connects to the data source and makes an outbound tunnel connection to a similar component on the cloud server.

Figure 1: Closing inbound connections.

 

Overcoming MQTT drawbacks

Despite its ability to make outbound connections through a firewall, MQTT has some drawbacks that must be addressed if it is to be useful for large-scale OT/IT [information technology] or industrial Internet of Things (IoT) applications. For example:

  • MQTT brokers do not preserve time order among data values on different topics. This means that events in the physical system could be delivered out of order. This may not always be important, but sometimes it’s critical.
  • MQTT’s quality of service (QoS) levels are inadequate for complex scenarios and are unable to guarantee eventual consistency.
  • MQTT struggles with overload situations, risking inconsistencies between the data producer and consumer.

Tunnel/mirror technology does not suffer from these disadvantages.

  • Time order among data values on different topics is preserved.
  • Data quality information is mirrored across the tunnel, which keeps clients immediately informed of any disconnections or bad data quality.
  • There is guaranteed consistency that ensures clients are always updated with the most recent value, even when the system is temporarily overloaded.


Network segmentation using a DMZ

In addition to keeping firewalls closed, best practice for networking industrial data is to segregate networks, typically using a demilitarized zone (DMZ) (Figure 2). This ensures there are no direct connections to corporate networks, and that only known and authenticated actors can enter the system at all.

Implementing a DMZ in an industrial IoT environment is problematic for MQTT. Getting data out of a plant through a DMZ typically requires two or more servers linked together. MQTT can be chained, but it requires each node in the chain to be aware that it is part of the chain, and to be individually configured. The QoS guarantees in MQTT cannot propagate through the chain, so daisy chaining makes data at the ends unreliable.

Figure 2: Best practice for networking industrial data is to segregate networks, typically using a DMZ.
 
A secure tunnelling implementation can support daisy-chained servers across a DMZ as it can mirror the full data set at each node. Implemented properly, it can provide access to the data both to qualified clients, as well as the next node in the chain. The tunnel/mirror software used should be able to guarantee consistency so that any client or intermediate point in the chain will be consistent with the original source. A data diode can be implemented at just the plant location, or possibly on the DMZ as well.
 

Securing the connection

Whether you use MQTT or tunnel/mirroring—with or without a data diode—security best practices should be implemented in the connection itself.

  • SSL encryption is essential, preferably with support for the most recent versions such as TLS 1.2 and TLS 1.3. The system should use and enforce server certificates.
  • User authentication is best applied on a per-connection basis. When each client program connects, it should be required to transmit a username and password, an access token or a client certificate to authenticate.
  • Any potential connection over plain-text transports should be avoided. This is because when data (possibly including passwords) is transmitted across the network, it is transmitted unencrypted over the connection transport layer and could be retrieved with a network packet capture program.

Given the unprecedented demand for process data alongside unheard-of levels of cyberattacks on critical infrastructure, demand for secure connectivity between OT and cloud systems has never been greater. System integrators and automation experts who understand the relative strengths of MQTT, tunnel/mirror and data diode technologies are well prepared for the challenges of securely accessing industrial data and connecting it to the cloud.

This feature originally appeared in the May 2025 edition of Automation.com Monthly.

About The Author


Xavier Mesrobian is sales and marketing vice president at Skkynet, a global leader in industrial data connectivity. With more than 25 years in the industry, Skkynet software and services are used in more than 27,000 installations in 86 countries, including the top 10 automation providers worldwide.

Download the May 2025 issue of Automation.com Monthly

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..

Subscribe