DMZ Support
The most secure way to connect OT and IT networks is to segregate networks by using a DMZ (“demilitarized zone”). The NIS 2 Directive from the European Commission and NIST CSF 2.0, mandate higher security for networking data between the production and corporate levels of a company, and encourage DMZ support.
A reference document for both directives, NIST SP-800-82, sums up zero-trust OT network segmentation like this: “The most secure, manageable, and scalable control network and corporate network segregation architectures are typically based on a system with at least three zones, incorporating one or more DMZs.”
These three zones are the control zone (OT), the corporate zone (IT), and the DMZ itself. Using a DMZ ensures that there is no direct link between corporate networks and control networks, and that only known and authenticated actors can enter the system at all. The SP-800-82 document describes the value and use of firewalls to separate these zones, and to ensure that only the correct data passes from one to the other.
DMZ support problematic for OPC UA and MQTT
Implementing DMZ support is problematic for both OPC UA and MQTT. Getting data out of a plant and to a user through a DMZ typically requires two or more servers, chained together one after the other.
The OPC UA protocol is simply too complex to reproduce well in a daisy chain like this. Information will be lost in the first hop. The synchronous multi-hop interactions needed to pass data across a DMZ would be fragile on all but the most reliable networks, and would result in high latencies. And there would be no access to the data at each node in the chain.
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, making data at the ends of the chain unreliable.
For example, a network break between the process and the DMZ would not get communicated reliably down the chain. Data users at the end will not realize that their data is stale, and could make errors in judgement or wrong decisions.
DataHub tunnel/mirror ideal for DMZ connections
DataHub tunnel/mirroring, on the other hand, can support daisy-chained servers across a DMZ because it mirrors the full data set at each node. Each DataHub instance provides access to the data, both for qualified clients as well as the next node in the chain. It guarantees consistency, so that any client or intermediate point in the chain will be consistent with the original source.
In the same example, if the network connection to the DMZ drops for a tunnel/mirror connection, the data quality will change to Disconnected in the DataHub instance on the DMZ, as well as all other downstream DataHub instances. All data users will get the message immediately.
And when the connection is restored, the data quality changes back to Good right away for every user at every link in the chain.
