Pairing a Data Diode with Tunnel/Mirroring for Secure Data Access

Summary

Industrial engineers and corporate executives face a pressing problem. On the one hand, they need access to process data for artificial intelligence (AI) and other applications. On the other hand, cybersecurity exploits targeting industrial systems have been increasing day by day. There has never been a time when making secure remote connections to industrial data has been more critical.

To meet this challenge, many companies are looking into data diode technology. A data diode is a hardware component that enforces one-way data flow. It allows data to pass out of the plant network and prevents any data whatsoever from entering back in. Not one inbound TCP packet can cross a data diode. For applications where even a closed firewall is deemed insufficient, a data diode can provide an extra layer of security.












A data diode is a hardware component that enforces one-way data flow. It can be useful for securing remote communications.

However, a data diode is not the ideal solution for every remote data access project. Adopting this technology can be challenging, costly, and in some cases, impractical. For example, some remote data connectivity scenarios require bidirectional data flow. What’s more, SSL cannot be used with a data diode. For this reason, system designers may benefit by combining data diode and secure tunneling technologies.

Here is an overview of four data-connectivity scenarios.

Client-server: The first scenario is a typical client-server connection, like OPC UA. Although it provides SSL support, a client-server connection requires opening at least one inbound firewall port, exposing the server to an external attack, either directly or through a compromised client. There is no protection against malformed SSL packets—they all get processed. The inherent insecurity of the client-server model makes it an unacceptable choice for remote access to industrial networks.

Tunnel/mirror: A second scenario is tunnel/mirror technology that makes outbound connections through a firewall. This essentially reverses the role of client-server, because in this case, the data source connects outbound to the data user. Tunneling/mirroring can support SSL and it blocks external attacks on the data source. However, because the data flow is bidirectional, and malformed TCP packets are processed, a compromised program on the data user side could attack the data source.

Choosing a tunnel/mirror software package that supports multiple protocols like OPC UA, OPC Classic, MQTT, and Modbus, and provides a unified namespace, gives this option a distinct advantage when you need to integrate legacy systems or diverse data sources.

Tunnel/mirror in data diode mode: A third scenario is a tunnel/mirror implementation running in data diode mode. In addition to making outbound connections and supporting a unified namespace, this approach includes software emulation of a data diode at the data source that discards all incoming TCP control packets and SSL protocol packets. All application data is discarded without being processed, so a compromised data user cannot attack the data source. The only thing exposed to attack is the SSL implementation, if SSL is being used. Since all application data is discarded, data flow over this connection is strictly unidirectional.

Tunnel/mirror with hardware data diode: The fourth scenario is a hardware data diode supported by tunnel/mirror software. The data diode blocks all external attacks, as well as any attacks that may come via a compromised data user because all TCP packets are simply not delivered. This solution can be used with or without a firewall and may also support multiple data protocols. The one drawback to this approach is that SSL is not available when connecting through a hardware data diode. Since all incoming packets are discarded, data flow over this connection is strictly unidirectional.

Which of these four is the best? It depends on your needs. If you are not connecting outside the plant at all, the client-server scenario has worked well for decades and should be sufficient. If you are connecting remotely to a trusted network and need two-way data flow, then tunneling/mirroring would be your best option.

If you are already using tunneling/mirroring, and want to enhance protection on a specific connection, you might consider configuring one or more additional tunnels to run in data diode mode. This would allow you to keep your SSL implementations while enjoying the benefits of a data diode.

And of course, should you truly require a hardware data diode, there are many on the market to choose from. Using one that is compatible with tunnel/mirror software can enhance your connectivity options, especially if you gain multiple protocol support over a unified namespace. Shutting down all incoming data packets should not restrict your choice of the protocol of the data feed you want to access, or the client that receives it.

_{This column originally appeared in AUTOMATION 2024: 1st Annual OT Cybersecurity Trends Report.}