By Eric Byres, Chief Technology Officer, Byres Security
There is no question OPC Classic, formerly known as OLE for Process Control, has provided a tremendous benefit to the automation and controls industry. OLE for Process Control (OPC), which stands for Object Linking and Embedding (OLE) for Process Control, is the original name for a set of specifications developed in 1996 for industrial automation integration. OPC Classic refers to all versions of OPC prior to the more recent OPC Unified Architecture (OPC-UA).
Back in the 1980s, when I was a young engineer integrating control systems (usually with serial connections), I prayed for an easy way to get two different vendors' devices to communicate. Usually it involved writing costly serial drivers, soldering cables, and a lot of luck. It was anything but easy.
Then OPC came along and answered my prayers. Integrating multiple systems was a breeze. My first major project for an aluminum company, which required the integration of three different types of PLCs, two different DCS and eight Windows applications. Previously, it would have taken months to complete. Instead, another engineer and I did it in a week using OPC.
You Use OPC for What?
I wasn't the only engineer to be amazed at the power of OPC. Very soon, OPC became the world's leading industrial integration protocol. And very quickly, it started to be used in ways never foreseen by its original designers.
In 2007, in partnership with ISA, I conducted a survey on where and how OPC is actually used. (A copy of the full report can be downloaded from tofinosecurity.com/understanding-opc). The first question asked was "How does your company use OPC in its operations?" Most users responded that they used OPC for data transfer to historians, data aggregation in HMIs and supervisory control.
What was surprising was that 30% of the end users reported employing OPC for data sharing to third parties, such as their business partners and suppliers. Since most third parties are likely located remotely from users' production facilities, this meant that many companies were using OPC for data transfer far beyond the plant floor.
The next question asked respondents to indicate what impact the loss of OPC would have on their operations and what percent of the OPC systems deployed would have this impact. Over one quarter of the sites reported tha losing OPC would result in a loss of production. Also interesting was that more systems would experience a loss of view by the operators than not.
While some users said they deliberately structured their systems to minimize safety and operational effects on loss of OPC-based information, others stated the opposite: "We control the motor drives by OPC with the DCS. If we lose the OPC we stop the production!"
Clearly OPC was not just being used for data management purposes, but was a critical component of many production systems.
A Little Cloud Called "Security"
At the same time use of OPC was exploding, a little cloud appeared on its horizon. Unknown to most of us, OPC Classic was built on a security house of cards—Microsoft's COM/DCOM technology, which in turn is based on an earlier protocol called Remote Procedure Call (RPC). These two technologies were designed before network security issues were widely understood. As a result, OPC Classic acquired a number of very insecure characteristics.
There isn't space in this article to describe all of OPC's security issues, but three stand out. First, OPC is very "firewall unfriendly." Unlike most other network applications, OPC servers dynamically assign TCP ports to each executable process serving objects to clients. The OPC clients then discover the ports 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 port 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 an unacceptable practice.
The second issue is that DCOM and RPC are extremely complex protocols. This complexity in turn translates into bugs, which translate into real opportunities for hackers and viruses.
Over the years, I have seen numerous badly designed OPC products that are open invitations to being hacked—or broken by well-meaning staff. For example, one major OPC software package has a vulnerability where a simple server browse of any system with a large variable pool results in a complete crash.
This has serious consequences. In one case, an accidental OPC item browse by a well-meaning employee resulted in the shutdown of a major food processing plant. (For a detailed analysis of OPC security issues see "OPC Exposed" at www.tofinosecurity.com/opc-exposed.)
Finally, because setting up OPC can be a complex process, a number of major vendors make recommendations that leave the end users' OPC security configuration wide open. For example, one major PLC vendor recommends that all remote access and launch controls be set for Anonymous Logon. These settings allow any individual on any network to run arbitrary OPC services on the OPC computer. This is a serious security risk.
Fiddling with Windows
So what is the user of OPC to do? The good news is that two of these vulnerabilities, namely excessively open firewalls and overly permissive access rights, are now within the control of the knowledgeable OPC end user. In an analysis I did with Matt Franz and Dale Peterson in 2008, we showed that if either vulnerability is addressed, then the chance of a security breach is significantly reduced.
First, there were a number of improvements that Microsoft made to the DCOM services when it released Windows XP/SP2 and Windows Server 2003/SP1. By adjusting some Windows registry settings and modifying the DCOM options in a computer‘s Component Services you can
- Control authentication levels for various OPC actions;
- Control the location of various OPC actions;
- Manage the DCOM permissions;
- Limit protocols used by DCOM/RPC;
- Restrict TCP port ranges for RPC.
- Full details on these steps are available in the US-CERT Recommended Practices document, "OPC Security White Paper #3–Hardening Guidelines for OPC Hosts" (www.tofinosecurity.com/opc-hardening).
Unfortunately, making these changes to each OPC server or client does add additional configuration complexity for the system administrator, and does not work for some poorly behaved OPC Server products.
Another solution is to use one of the products designed to tunnel OPC/DCOM traffic over a single TCP port. These were originally designed to address a different OPC issue, namely, how OPC deals with network address translation. However today many companies also propose them as a security solution. The downside is that these OPC tunnellers often require an intermediary personal computer (PC) to supply the OPC tunneller services. Maintaining this PC can be expensive for an end user over the long term, as the PC will need patching and anti-virus updates applied on a continuous basis if it is to be secure.
OPC-Aware Firewalls
A simpler solution is the use of the new OPC-aware firewalls. In the past few months, Invensys (http://iom.invensys.com), MTL (www.mtl-inst.com) and Hirschmann (http://hus.hirschmann.com) have all announced firewalls that can automatically track and manage OPC Classic's nasty dynamic port problem. [Note: in the interests of full disclosure, the team at Byres Security provided technical assistance and software to these companies to make this possible.]
These units are designed to be dropped into an existing network carrying OPC DA, HAD or A&E traffic, and require no changes to the existing OPC clients and servers. In the Invensys case, the firewall is completely 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. In both cases, the result is the control network appears closed to all but well-formed OPC traffic from user- approved clients and servers. All the open firewall ports typically required in a system using OPC are gone, improving security significantly with very little effort.
Into the Future – OPC-UA and OPC-XI
The good news for the future is that the OPC Foundation (www.opcfoundation.org) has recently developed two new versions of OPC called OPC-UA and OPC-XI, which are based on protocols other than DCOM. Once most OPC applications make this migration from the DCOM-based architecture to .NET-based architecture, then industry will have a significant opportunity for better security when it comes to OPC.
If you have already converted to OPC-UA or XI, good for you. However, if your company is like most, it will be a while before you can rid your plant of all traces of the DCOM-based OPC. So, until that day, you need to take a serious look at improving the security of your OPC. The techniques and technologies for better OPC security are available and proven. Not using them can be costly.
