Skkynet’s Approach Calms Recent Security Concerns
Eyebrows were raised among the industrial automation community last week when the well-known Kaspersky Labs issued a report titled OPC UA Security Analysis that lists 17 security issues in the OPC UA protocol and products. While we see no reason to doubt their methodology, we take a different approach to the question.
As we see it, the real issue is not the OPC UA protocol itself. OPC UA was created 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.
Think about it. How did Kaspersky Labs 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.
We would argue that Kaspersky Labs was searching for symptoms while overlooking the cause. What the report does not address, and indeed it is so obvious that it is easily overlooked, 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.
A Better Approach
A better approach 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.
This is Skkynet’s approach. It 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, Skkynet’s approach enables secure Industrial IoT connectivity, while still reaping the benefits of OPC UA in the plant.
Note: A version of this article was recently published on the Automation.com website.
