Interested in linking to "Getting OPC Security Under Control "?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
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.
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.
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.
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