Strategies for OPC Security

OPC Classic is used to interconnect an amazing variety of industrial and business systems. But while integrators and end users were happily deploying OPC in their plants and factories, security researchers (and a few hackers) were noticing that there were serious security issues with OPC.

OPC Classic – The World’s Leading Industrial Integration Standard
No industrial communications standard has achieved the widespread acceptance across so many different verticals, industries and equipment manufacturers as the now ubiquitous OPC. Once known as OLE for Process Control and now officially referred to as OPC Classic, this standard is used to interconnect an amazing variety of industrial and business systems, ranging from Human Machine Interface (HMI) workstations, Safety Instrumented Systems (SIS) and Distributed Control Systems (DCS) on the plant floor to enterprise databases and other business-oriented software in the corporate world.
Unfortunately, while integrators and end users were happily deploying OPC in their plants and factories, security researchers (and a few hackers) were noticing that there were serious security issues with OPC. For anyone with an OPC Classic system somewhere in their plant (and that includes most of us), it is now critical to understand and address these security issues head-on. In this article, I will outline two of the most serious issues (but not all of them) and two possible security solutions.

What is OPC Classic Anyway?
To understand OPC security, it is important to understand a little about the technologies underlying OPC Classic. The term “OPC Classic” refers to all OPC standards prior to the new OPC-Unified Architecture (OPC-UA) standard. This includes the most popular specifications such as OPC Data Access (OPC DA), OPC Alarms and Events (OPC A&E) and OPC Historical Data Access (OPC HDA).
What sets OPC Classic apart from the emerging OPC-UA standards is that OPC Classic is based on Microsoft’s Distributed Component Object Model (DCOM) technology.  DCOM in turn, is the culmination of a number of other technologies including Component Object Model (COM) and Object Linking and Embedding (OLE). All these technologies use a network protocol called Remote Procedure Call (RPC) to connect over a typical Ethernet/TCPIP industrial network.

All OPC technology is based on a client/server architecture where computers run software that makes them either a client or a server (or both in some cases). The OPC server is a software application that gathers information from a device (such as a PLC, DCS or SCADA controller) using that device’s native protocols (such as Modbus or PROFIBUS). The server then provides access to this data via COM objects and method calls, allowing multiple OPC clients to indirectly read and write to the field device via the OPC server.

OPC’s Soft Underbelly
OPC Classic’s core technologies, namely RPC and DCOM, were designed before security was widely understood. As a result, a number of design decisions were made that make DCOM deployments easy rather than secure. In particular, OPC Classic uses a technology called dynamic port number allocation that, until recently, has made it impossible to secure using conventional IT-style firewalls.

Unlike most other network applications (such as a web server or Modbus TCP slave), OPC servers dynamically assign TCP port numbers to each executable process serving objects to clients. The OPC clients then discover the port numbers associated with a particular object by connecting to the server and asking what TCP port they should use.  Because OPC servers are free to use any number between 1024 and 65535, OPC becomes very "firewall unfriendly” - configuring an IT firewall to leave such a wide range of ports open presents a serious security hole and is generally considered unacceptable practice.
The other issue with OPC Classic is caused by overly permissive access rights. Setting up OPC can be a complex process, so a number of major vendors make recommendations that leave the end users’ OPC security configuration wide open. For example, one PLC vendor recommends that all remote access and launch controls be set for Anonymous Logon. These overly permissive settings allow any individual on any network to run arbitrary OPC services on the OPC computer, a major security risk.

Why Security Matters
One might be tempted to wonder if security is even important in a system using OPC, as these systems are rarely connected directly to the Internet. Unfortunately, even if you have a completely isolated system, good security is essential for reliable and safe plant operation.

The Stuxnet worm incidents of July 2010 provides a clear indication that some cyber attacks are now focusing specifically on industrial systems. In the Stuxnet case, a worm propagated through infected USB keys (so Internet connectivity was a not a requirement for infection). Subsequent analysis has shown the worm infected Siemens’ HMI, PCS7 and Step7 PLC products, modifying logic to actually destroy targeted processes equipment.

In a less famous incident directly related to OPC Classic, a major refining complex was infected by the virus W32.Sality when a contractor remotely connected to a control system to provide maintenance support.  The virus then propagated from OPC clients to OPC servers, infecting multiple systems in the facility and causing repeated crashes of key servers. OPC Classic’s dynamic port allocation issues complicated the problem, as it made it almost impossible to use firewalls to isolate one control system from another.

Making OPC Secure
So what is the user of OPC to do? The good news is that new technologies have been developed in the past few years that make OPC security much simpler than it used to be. Two of these technologies are OPC-aware firewalls and the improvements to the Windows operating systems, made when XP SP2 was released.

One of the core concepts in the ANSI/ISA-99 security standards (and in the soon-to-be-released IEC 62443-2-1 standards) is the use of security zones. Like watertight bulkheads in a ship, dividing a control system into security zones prevents issues in one area from migrating to another area. Between the zones are “conduits” (typically firewalls) that carefully manage all the inter-zone network traffic. For example, if zones had been in place in the refinery noted earlier, the virus would have been contained to the one computer that the contractor infected, rather than impacting systems throughout the entire facility.

As we noted earlier, in previous years OPC Classic’s dynamic port allocation problem made deploying ANSI/ISA-99 zones almost impossible. Since the OPC server might use any port number between 1024 and 65535, any firewall between clients and servers must also have all those ports open, effectively making the firewall useless.

Today a proven solution is to use the OPC-aware firewalls now on the market. Invensys Operations Management, MTL Instruments and Hirschmann/Belden and my company, Byres Security (Figure 1) have all released firewalls that can automatically track and manage OPC Classic’s dynamic port problem. These units are designed to be dropped into an existing network carrying OPC DA, HDA or A&E traffic, and require no changes to the existing OPC clients and servers.

In the Invensys case, the firewall is preconfigured to work with Triconex safety products. In the MTL and Hirschmann cases, the firewall is configured using a simple drag-and-drop editor to select permitted clients and servers. Figure 2 below shows the simple rule configuration process, where the icons representing three OPC clients have been dropped onto the firewall table for the OPC Server. In this example, two of the clients are permitted to communicate with the server, but one (HMI 2) has been denied.

In all cases where OPC-aware firewalls are used, the control network appears closed to all but well-formed OPC traffic from the approved clients and servers. All the open firewall ports typically required in a system using OPC Classic are gone, significantly improving overall system security with very little effort.

Fiddling with Windows
The other option is a result of improvements that Microsoft made to the DCOM services when it released Windows XP/SP2 and Windows Server 2003/SP1. By adjusting some DCOM options in a computer‘s Component Services you can:
1.    Control authentication levels for various OPC actions;
2.    Control the location of various OPC actions;
3.    Manage the DCOM permissions;
4.    Limit protocols used by DCOM/RPC
It is important to note that making the changes in a server is more complex than using the OPC-aware firewall solution.  In addition, these changes can negatively impact the operation of some poorly behaved OPC products. Thus we highly recommend that you test the account permission changes in a non-production environment such as a lab or simulator first.

Looking Forward - OPC-UA
Over the past few years, the OPC Foundation has developed a new version of OPC called OPC-UA, which is based on protocols other than DCOM. Once most OPC applications make this migration from the DCOM-based architecture, the industry will have a significant opportunity for better security when it comes to OPC.
If your company is like most, it will be a while before you can rid your plant of all traces of OPC Classic. With the world facing new cyber threats, some directed specifically at industrial control systems, all companies need to take a serious look at improving the security of their OPC systems. The techniques and technologies for better OPC security are available and proven. As many companies have discovered, not using them can be costly.


Edited by: Constanze Schmitz