One of the big differentiators between the worlds of IT and OT is their attitude to “active” network tools – those that actually place traffic “onto the wire”. In all but the most sensitive IT networks, this is almost never an issue. The typical IT network is literally awash with different protocols – DNS, DHCP, SMTP, HTTP; the list goes on. In a large, complex IT environment there could be literally dozens of different protocols flying about. So, introducing a new system, such as a network monitoring tool – PRTG for instance – with its reliance on SNMP, WMI and other protocols, is seldom a big issue.
This contrasts sharply with many ICS environments. For most Engineers tasked with administering OT networks, stability is their overriding concern. They need to completely understand how their systems will respond to any given action or event. For this reason, OT networks have been described as “deterministic, finite-state-machines”. This need for stability and consistency demands a thorough knowledge of, and strict control over, not just which devices connected to the OT network, but also the type and volume of network traffic those devices generate.
Another common reason for restricting traffic ingress onto OT networks is timing. Some manufacturing processes demand control instructions to be issued and acted on with millisecond precision. An unexpected packet, such as a Ping, could disrupt such precision timing, with potentially dire consequences. Of course, this only applies in certain environments – it’s unlikely the system controlling 15m high, 3000 tonne flood defence gates need millisecond precision timing. (Fun fact – it can take up to 90 minutes to close the Thames Barrier).
So how can you limit the traffic entering an OT (or IT) network? There are a couple of ways to do this. The first is to only deploy entirely passive tools. A good example of this would be Rhebo Industrial Protector, an OT anomaly detection and security tool. It relies on switch SPAN / mirror ports, or network taps to “sniff” network traffic and analyse it for anomalous or malicious activity. Connecting to the network this way guarantees there is no possibility that the system can introduce any traffic to the OT environment. The Rhebo management console is presented on a separate network port, connected to a management network.
The second option would be to use a “data-diode” or unidirectional gateway. These are hardware devices that, as the name implies, only allow traffic to leave the network segment they are protecting. Typically, this is achieved by replacing the usual combined “transceiver” type network ports with separate transmit and receive modules. The TX port includes a standard fibre-optic laser, used for transmitting data to the unsecured network. But the RX port only has an optical receiver, with no laser. So even if the network is compromised, and attackers gain remote access to the gateway, its physically impossible for the device to transmit data to the secured network segment. This is why data-diodes are considered to be more secure than traditional firewalls.
By design, PRTG is an active tool – it’s intended to go out and discover devices on the network and retrieve health and performance information from them. It uses a variety of protocols to do this, including SNMP, WMI, HTTP(S) and others. Most of PRTG’s sensors, with a few exceptions, are designed to query devices and “pull” data from them. This obviously requires traffic to be placed onto the network being monitored.
So, how can you use PRTG to monitor an OT network that expressly prohibits the ingress of external traffic? We’ve recently added support for a couple of new protocols to PRTG that make this possible. These new MQTT and OPC UA sensors are designed to query the MQTT Broker or OPC Client collecting information from devices, rather than querying the devices directly. As long as these Brokers / Clients are “dual homed” and can be accessed from a management network, PRTG can collect monitoring data without needing to connect directly to the restricted network segment.
Of course, for environments that don’t need to prohibit traffic flow into the OT network, PRTG can be used in the usual way, either by installing the Core Server directly on the network segment to be monitored; or for more complex or distributed environments, by installing Remote Probes.
Now that we’ve added out-of-the-box sensors for MQTT, OPC UA and Modbus, OT Engineers gain the same insights into the health and performance of their networks that their IT counterparts have been enjoying for years. But what if those OT networks are using other protocols? Not a problem – by deploying the free PRTG Connector for Node-RED, Engineers can quickly and easily pass data into PRTG from any system or protocol supported by Node-RED, of which there are currently almost 3000.