Tag Archive for: OPC UA

Note: This article was originally published on the Automation.com website.

OPC UA was designed to be secure in an industrial environment, and it does a good job of it. In the world of Operations Technology (OT) you need reliable and secure data communications to run mission-critical systems. OPC UA provides robust connectivity, allowing your devices and machines to communicate, yet keeping them secure and locked down. But today’s OT world is expanding, being propelled into the larger, corporate world of IT, and beyond that, into the Industrial Internet of Things (IIoT) and Industrie 4.0. When connecting to IT and the IIoT, making OPC UA secure requires a new approach to meet new and different threats to security.

Securing an industrial system requires at the very least securing the perimeter against unauthorized access. Whether or not anything in the plant is connected to IT or the IIoT, this perimeter must remain intact for optimal security. In the past, perimeter protection was often accomplished by air-gapping, where the industrial network was physically isolated from any other network connection. Until recently, this approach or similar solutions like DMZs were sufficient. But these make it difficult if not impossible to share OT data with the company’s own IT department, much less on the IIoT. The challenge is to fully protect the perimeter, and yet still provide access to the data from OPC UA servers inside.

Are VPNs secure enough?

Accessing OPC UA servers or any other industrial system from the IIoT should be done through a secure network connection. The typical approach, one that many take for granted, is to use a VPN (Virtual Private Network). VPN technology is well known, having been used for decades in the IT world. In essence, a VPN provides an outside user with a log-in to the network, and establishes a secure tunnel through the Internet to allow access to the system―the entire system. And that can lead to problems.

While OPC UA can work over a VPN, that doesn’t guarantee robust security. VPNs were not designed for use with industrial process control systems. In fact, they can open vulnerabilities even in the IT world. The attack on Target stores in North America that cost the company millions of dollars was perpetrated through a VPN. Hackers got hold of a user name and password, and gained access to the system. Once in, they quickly found their way to customer records and credit card numbers, and had a field day. The problem with using a VPN to access an industrial system is not only that every VPN user account is a potential access point, but that once someone is inside the perimeter they gain access to the whole system.

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.”

Using Reverse Proxies

Forward-thinking people who are working on the IIoT recognize this inherent risk in using VPNs. Many IT departments now require reverse proxies for OT systems to mask all internal servers and expose just one server to the Internet. But this approach does not secure OPC UA for the IIoT.

OPC UA clients can connect through reverse proxies using HTTP, but not HTTPS due to certificate handling. The proxy will either require opening a new firewall port, or effectively create a path to the control system that could easily be overlooked in the future. Either way an attack surface gets opened in the corporate perimeter. Furthermore, even if the message itself is encrypted, the message headers are exposed to outside observers. The only alternatives involve effectively tunneling through the proxy directly to the control system, which is what the proxy is trying to prevent.

The bottom line is that a reverse proxy is an improvement over a VPN, but it still requires a point of access into the control system from the Internet or IT network. Any point of access is an attack surface, and even if the server code is bulletproof it is still a candidate for a spear-phishing compromise.

Push Instead of Pull

The best way to completely close the plant perimeter is to eliminate all inbound connections, allowing only outbound connections. This is a good idea in principle, as it does not expose the plant to attack. The system presents zero attack surface, becoming invisible to hackers who cannot attack what they cannot see.

However, outbound connections run afoul of traditional design expectations. Effectively they turn the paradigm of industrial data communications on its head. Most client/server architectures, including OPC UA, assume that the server holds the data and the client initiates a connection to interact with it. The server is the authority on the data set, while the client is the non-authoritative user. Thus, in the OPC UA world-view the server must be situated with the primary data source, inside the control system.

To make a push design work in the IIoT, the server/client relationship must be reversed. The client must be the authority (inside the control system), and the server must be a non-authoritative receiver of the data. The client must be able to construct the data set on the server on the fly, based on its knowledge of the control system. This reversal of the client/server roles is something that OPC UA cannot accomplish on its own, but can be added through appropriate gateway software.

Using Forward Proxies

Using a push mechanism allows both OT and IT to completely close the network perimeter. If there is no way to make a connection from outside the network then there is no attack surface to exploit and there is no user to fool into revealing his password.

But even a closed perimeter is not sufficient. Best practice in IT networks is to route outgoing web traffic through a forward proxy, and to deny all other network traffic to the Internet. This substantially improves security by effectively shielding the internal network from a direct Internet connection. To be robust and IT-compliant the outbound IIoT connection must be able to pass through a standard forward proxy. Although OPC UA doesn’t inherently support forward proxies, appropriate gateway software can once again add this capability.

Secure by Design

The Chatham House Report, Cyber Security at Civil Nuclear Facilities Understanding the Risks, points out an alarming lack of security at some of the most critical infrastructure installations in the world, and makes a number of design recommendations. At one point it states, “Many industrial control systems are insecure by design, since cyber security measures were not designed in from the beginning.” And this does not just apply to nuclear facilities. Indeed, the “many industrial systems” may well include those which now or soon might incorporate OPC UA. And they require a new approach, a new design for security on the IIoT.

The new design approach must allow OPC UA clients from any location to connect and acquire data from OPC UA servers within the plant perimeter, to eliminate the need for reverse proxies and VPNs and to avoid opening any inbound firewall ports. At the same time, to fully support OPC UA’s real-time data access, the design must support bi-directional data communication between OT and IT systems and across the Internet at speeds very close to network propagation times. Secure-by-design for the IIoT should take a no-compromise approach, offering the best possible combination of speed, security, and convenience.

With this level of security, and near-real-time speeds, there is one more design consideration: practicality. To gain traction among users, the design should be convenient to implement. It should, for example, allow for seamless integration with legacy installations using OPC Classic and other industrial protocols, as well as newer OPC UA-enabled systems. It should provide a loose coupling to the IIoT, one that allows remote, authorized and secure access the data, optionally including supervisory control, but that has no impact on the primary control system if it gets disconnected. And it should be easy enough to implement that it doesn’t overly tax the time or resources of the system integrator or plant engineer who is implementing it.

This is the kind of design that is needed to secure the IIoT, and make it compatible with today’s factory or process. OPC UA is the industrial protocol of the present, and of the future. It has the ability to integrate plant data from virtually any machine or device, large or small, as well as to bring the disparate worlds of OT and IT together. When OPC UA is wedded to the appropriate, secure-by-design IoT technology, it will play a key role in Industrie 4.0 and IIoT applications.