The Kaspersky Report: It's Not Really About OPC UA |

The Kaspersky Report: It's Not Really About OPC UA

The Kaspersky Report: It's Not Really About OPC UA

By Bob McIlvride, Director, Communications, Skkynet Cloud Systems

The industrial automation community has been buzzing about a new report from Kaspersky Labs that OPC UA, and products that incorporate it, have security issues.  Kaspersky Labs used common exploit-discovery techniques to identify 17 critical security flaws in the OPC UA software they were testing.  There is no reason to doubt their methodology, but we all need to be careful about the conclusions that we reach.

OPC UA is a protocol intended to allow client/server networking for industrial communication.  The flaws that Kaspersky identified were visible on an OPC UA server that, by definition, is listening for network connections from OPC UA clients.  Any application that listens for connections on a network can equally be a point of attack for a malicious hacker.  This is not unique to OPC UA – it is a fact of the design of TCP/IP networks.  Period.

You don't believe it?  Read the report.  How did they discover the vulnerabilities in OPC UA and related products?  Using a technique called "fuzzing", they used a specially-constructed client application to send a rapid-fire barrage of messages at the UA server, each of which was slightly altered, or "mutated", in some way from a standard message.  Sooner or later one of these messages would crash the server or uncover an exploitable vulnerability.  This technique can be used on any network-connected server, like a web server, VPN server, RDP server or vendor-supplied remote access server.

What the report does not say, and indeed it is so obvious that we might overlook it, is that this kind of attack can only succeed if the intruder has access to the server in the first place.  All software has bugs.  Any program exposed to the Internet is fair game.  However, as long as your servers are running on a trusted network and you keep all inbound firewall ports closed, you don't run the risk of an attack from outside, no matter how persistent or devious the attacker may be.


The Real Problem

The real problem is that the standard approach to industrial data communications is not suitable for untrusted networks like the Internet.  We are used to a client on the user side connecting into a server at the data source―after all that’s the classic server-client architecture.  But for Industrial IoT this approach poses a serious risk because the client is often outside the trusted plant network.  It needs an open firewall port into the plant to connect.  This design itself is the fundamental reason for the security problem.  Rather than expecting protocols or software to be bug-free and invulnerable to attack, it makes more sense to find a more secure design approach altogether. 

Inbound connections require open firewall ports, allowing intruders to enter.


A Better Solution

A better solution is not to allow any inbound connections at all.  The whole Kaspersky Lab scenario was built on repeated client connections into the server network.  What if the server (over which the attacker has no control) connects out to the client?  If you can establish only outbound connections from a data source to a data user, then the entire threat vector is eliminated.  With all inbound firewall ports closed, the plant network and all of its OPC UA servers become invisible.  And you can't attack something that you can't see.

Using only outbound connections keeps all inbound firewall ports closed.

Is this possible?  Yes.  It is being done today.  The OPC Foundation is monitoring the effort for this future. This approach to industrial data communication is running in production systems worldwide, and it is fully compatible with OPC UA.  By keeping OPC UA servers within the trusted network, and keeping all firewall ports closed, this approach enables secure Industrial IoT connectivity, while still reaping the benefits of OPC UA in the plant.

About the Author

Bob McIlvride is Director of Communications at Skkynet Cloud Systems, Inc., a provider of real-time data information systems. He has been working as a professional technical writer in the industrial process control sector for over 15 years, and can be reached at [email protected]


Did you Enjoy this Article?

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

Subscribe Now