Outbound Connections

Making outbound connections is the most secure way to access data from a production system.  Any open incoming firewall port constitutes a security exposure.

Unfortunately, most industrial protocols, like OPC, require inbound connections.  They are based on an old server-client model, where the client initiates the connection to request data from a server.

Outbound Connections diagram

In the current climate of cybercrime, these inbound connections constitute a real vulnerability. Port scan attacks are incessant, and it only takes one open firewall port for a hacker to gain entry into your system.

Attacks are directed at applications

The problem is deeper than just the port or protocol.  OPC UA or any other protocol may be secure in itself, but attacks are most often directed at applications that use it. The risk is that the listening application has an exploitable flaw that may or may not be due to the protocol implementation.

For example, an application may perfectly implement OPC UA, yet be vulnerable to flaws in OpenSSL. The application may have no exploitable flaws in OPC UA or SSL, but still have a buffer overrun in a string processing function executed on incoming data. No application is free of bugs. Every open incoming port is an opportunity for an attacker to probe an application for exploitable flaws, and can give instant access to a network if an exploit is discovered.

Best practice – close all inbound firewall ports

The best security practice is to not open any incoming ports at all in the secure network’s firewall. DataHub Tunnel/Mirroring from Skkynet works this way. It can make an outbound TCP connection from the server side to the client side, eliminating the need to open any inbound firewall ports. The result: zero attack surface.

This design approach can be used when segmenting networks with a DMZ. Outbound-only connections are configured from the OT side to the DMZ, as well as from the IT side to the DMZ. The potential attack surface moves to the DMZ, which can then be hardened to manage the security risk.

Security Outbound Connections diagram

Secure networking with SSL

DataHub software uses SSL to provide secure networking for Tunnel/Mirror, MQTT, Web Server, WebView, and Remote Config connections, with the standard SSL-3 encryption cipher, a 256-bit encryption method. SSL encryption on a DataHub instance can be done using the SSL certificate installed with the DataHub program, or you can use your own certificate. Please see SSL Encryption in the Cogent DataHub documentation for details.

MQTT

Another approach to closing all inbound firewall ports is MQTT.  Each MQTT client can act as either a data source or a data receiver, or both, and each makes outbound connections to the MQTT broker.  This capability, along with SSL support, makes MQTT secure, and useful for simple remote data architectures requiring one-hop connections.  However, large-scale, complex IoT or OT-to-IT systems often require more flexible and robust solutions.  In particular, the MQTT protocol does not support connections across a DMZ well.