Bob McIlvride, Director, Communications
Skkynet Cloud Systems, Inc.
The Industrial IoT (IIoT) is promising to dramatically change the landscape of industrial process control. Managers and executives worldwide are waking up to the value of the data in their production systems, and are demanding access to it to boost efficiency and cut costs. Engineers responsible for devices and equipment at remote locations can use the IIoT to provide this data to users wherever they may need it. However, the question often arises: How to share the data securely?
The Traditional Model
Sharing remote data securely is not as easy as it may seem. Industrial data communication follows a certain standard approach: the client/server model. In this model, the server is connected to the data source, such as a sensor, a pump, a machine, etc., often via an RTU or PLC. The client program might be an HMI, SCADA system, database or historian—any program that requests the data and then passes it along for a machine or person to use.
All commonly used industrial protocols, including OPC UA, follow this client/server model. It specifies that the server is always the authoritative provider of the data, and the client always makes the connection. But what happens when the client is remote from the server, and needs to make the connection into a secured location?
On most industrial systems, the data sources and the server will be on an isolated network, protected by closed firewalls, data diodes, a DMZ, or possibly simply disconnected from all networks. Incoming client connections were never contemplated for these kinds of applications. Here is where the client/server model breaks down. To get its data, the client needs to make an inbound connection to the server. But what happens when the client is not inside the firewall or DMZ? How can a remote client and server be connected securely?
Open a Firewall Port
To accept a client request, one approach is to simply open a port in the firewall. However this is bad practice, particularly when the access is via the Internet. Firewall ports are continually being probed, and an open port will almost certainly be detected and exploited by a hacker. Even with no Internet connection, the risk of an open firewall port into a mission-critical system is so great that most control engineers will simply not allow it.
VPN: False Friend
To overcome this problem, many people today are using VPNs. However, a VPN gives access to the whole network, not just the data. It expands the security perimeter of the facility or device to the client’s system, effectively sharing the network. Anyone who gains access to the VPN then has access to every node on the network. For example, during the power plant hack in Ukraine in December 2015, attackers “used stolen VPN credentials to reach the industrial control systems network, and remote access tools to control the HMIs and pull the breakers,” according to an article published on the DarkReading website, and other reports.
The drawbacks of using a VPN for the IoT are examined in detail by Clemens Vasters, a Microsoft Developer. In a paper titled Internet of Things: Is VPN a False Friend? Vasters said, “VPN provides a virtualized and private (isolated) network space. The secure tunnels are a mechanism to achieve an appropriately protected path into that space, but the space per-se is not secured, at all. It is indeed a feature that the established VPN space is fully transparent to all protocol and traffic above the link layer.”
Outbound Connection Secures the Server Side
Instead of using a VPN or opening a firewall, an alternative is to make an outbound connection from the device or facility to the central location. This can be done with specially-designed middleware that is able to change the connection dynamics.
On the server side, within the secure network, the middleware program makes a connection and receives the data. This middleware is also capable of making an outbound connection to the middleware program running on the client side. On the client side, the middleware program receives the data and makes it available to the client. In this way the client and server make local connections, which are easier to configure and more secure than network connections.
This approach does keep all firewall ports closed on the server side, but it still requires an open firewall port on the client side, which simply moves the attack surface from the server to the client. The security of the system as a whole has not improved.
Outbound Connections for Both Server and Client
The most secure approach is to establish outbound connections from both the server and client sides. This can be done by introducing one more middleware program that can accept incoming connections from both sides and transfer the data between them as needed. To maintain security, the central middleware program would run in a DMZ separate from but accessible to both client and server networks. Now all firewalls are closed, and both networks are invisible to the Internet.
Secure Middleware as a Service
Alternatively, the secure middleware could be part of a cloud service. As with the DMZ approach, this reduces the exposure of the system, while also providing the least costly and most efficient security management.
Further, it should not be necessary to choose between running the central middleware on a DMZ or on a hosted cloud service. A well-designed middleware solution should allow both, simultaneously, as a hybrid cloud. This provides robust local networking via the DMZ server as well as secure, outbound connectivity to the cloud for remote access to the data.
A multi-national automation company specializing in mineral processing recently used this kind of middleware to execute a project in the Middle East from their home offices in France. By leveraging secure, IIoT real-time data collection and distribution, multiple engineers were able to work in parallel using an exact replica of the live plant. This secure remote access cut development time in half.
For all of this to work, the middleware program that connects everything needs to make a fundamental change to the client/server relationship. It must be able to act as the server of the data, while also being the one that initiates the connection. In addition, the outbound connection from the server side must remain the trusted, authoritative source of the data.
By “authoritative” we mean the side of the connection that has the correct data in case of a disconnect/reconnect cycle on the network. When a connection breaks, the client needs to know immediately that the quality of the data is bad. Each link up the communication chain from the client to the server acts in turn as the authority, providing network status information in addition to data values. When the connection is re-established, the correct data values and connection status are passed down this authoritative chain until the client receives the latest, trusted data values.
A New Model
Traditionally, the client always initiated a connection to a server. But to allow secure, remote data communication this model needs to change. Specialized real-time middleware that can make outbound connections from both server and client, while keeping the authority of the data source intact from the source to the user, is the key to providing a secure-by-design architecture upon which a solid IIoT solution can be built.
With this kind of secure access to remote data, managers can be assured of getting accurate information, and engineers can be confident that their systems are operating in the most secure environment possible. All participants benefit from secure access to remote data, without sharing the network.
For more information please visit Skkynet Cloud Systems, Inc. at www.skkynet.com.