Securing Your OPC Classic Control System

Independent Techniques for Ensuring Strong Security in Your System

By Thomas Burke and Eric J. Byres

2 of 5 1 | 2 | 3 | 4 | 5 View on one page

•    An OPC platform that contains an OPC server and a Modbus protocol driver
•    A HMI for operator access to the control system

The HMI will need to be able to write the set point in the controller, read the current water level, and monitor the controlled output (the pump) and alarms. If the HMI needs to read a value from the PLC, it sends a request via an OPC API call and the server translates this into a Modbus message for communications to the PLC. When the desired information returns from the PLC to the OPC server, it then translates that back to OPC for transmission to the HMI.

The Security Challenges of OPC Classic
While control system manufacturers, integrators and end users were happily deploying OPC Classic in their plants and factories, security researchers (and the hacking community) were noticing that there were a few serious issues with the standard.

The first issue stems from the fact that the RPC and DCOM protocols were designed before security issues were widely understood. Thus a number of early design decisions were made that make DCOM deployments easy rather than secure. This created one of the most vexing problems in OPC security, namely the problem of dynamic port allocation.

To understand the security risks that dynamic port allocation poses to a control system, it is necessary to understand a bit about TCP (and UDP) ports. These ports are not physical ports like an Ethernet port, but instead are special numbers embedded in every TCP or UDP message to identify the application protocol being carried in the message.  For example, Modbus/TCP uses port 502 and HTTP uses port 80. These numbers are registered under the Internet Assigned Numbers Authority (IANA) and are rarely ever changed.

This port number consistency makes firewall rule creation relatively simple – if you want to block all Modbus traffic through the firewall, simply define a rule that blocks all packets containing 502 in the destination port field.

The problem with OPC Classic is that out-of-the-box OPC servers don't use a fixed port number. Instead they dynamically assign a new TCP port number 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 number they should use for this session.  Then they make a new TCP connection to the server using the new port number.

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 unacceptable practice.  As a result, OPC Classic has been considered by many to be impossible to secure using conventional IT-style firewalls.

The second issue with the use OPC Classic is caused by overly permissive access rights. 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 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.

The final issue (but the one most often quoted in the popular press) is that OPC Classic's underlying protocols, namely DCOM and RPC, can be vulnerable to attack. Over the past half decade, viruses and worms from the IT world have increasingly focused on these protocols, as noted in this attack trends discussion:

"Over the past few months, the two attack vectors that we saw in volume were against the Windows DCOM (Distributed Component Object Model) interface of the RPC (remote procedure call) service … These seem to be the current favorites for virus and worm writers, and we expect this trend to continue."

As operating system testing and patching has improved over the past few years, this has become less of an issue, but plenty of worms are still out there looking for a poorly secured OPC system.

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 provided a clear indication that the hacking community is now focusing specifically on industrial automation 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 was designed specifically to target and infect Siemens' HMI, PCS7 and S7 PLC products. It is capable of stealing process information, modifying PLC logic and hiding the modifications it might make to PLC programs from users trying to examine the PLC logic.

In a less famous incident directly related to OPC Classic, a major refining complex was infected by the virus W32.Sality in 2009 when a contractor remotely connected to a control system to provide maintenance support.  The virus was able to propagate from OPC clients to OPC servers, infecting multiple control 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 difficult to use firewalls to isolate one control system from another.

2 of 5 1 | 2 | 3 | 4 | 5 View on one page

Join the discussion

We welcome your thoughtful comments. Please comply with our Community rules.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments