Securing Your OPC Classic Control System

The other good news for users of OPC Classic is that new technologies have been developed in the past few years that make OPC security much simpler than it was in earlier years. Using the ANSI/ISA-99 security standards as a framework, we will outline two solutions that should be considered in securing OPC systems. Each solution can be implemented independently of the other, so we have listed them below simply in order of ease of deployment.

Creating Zone-Based Defenses with OPC-Aware Firewalls
One of the core concepts in the ANSI/ISA-99 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 single computer that the contractor infected, rather than impacting systems throughout the entire facility.

Until recently, 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.

This issue was partially addressed in 2007 when Microsoft revealed a technique to modify the Windows Registry settings in OPC servers to limit the range of port numbers that are dynamically allocated. This technique is described in detail in the US-CERT Recommended Practices Guide - Hardening Guidelines for OPC Hosts and in a Tofino Security white paper. Unfortunately, this solution can add configuration complexity for the system administrator because each OPC host needs to have its Windows registry adjusted. Furthermore, subsequent testing has indicated that the technique does not work for some poorly behaved OPC Server products.

A simpler solution is to use the OPC-aware firewalls now on the market. Invensys Operations Management, MTL Instruments and Hirschmann/Belden 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 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. 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.

Figure 2: OPC-Aware Firewall Rules Allowing Two Clients to Connect to a Server

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

Managing OPC Accounts and Permissions
When Microsoft released Windows XP/SP2 and Windows Server 2003/SP1, it included a number of improvements for managing DCOM services. By adjusting some DCOM options in a computer‘s Component Services application 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

Below we will provide a summary of the steps needed to secure an OPC sever that is running on Windows XP SP2, Windows Server 2003, Windows Server 2008, Windows Vista or Windows 7. Additional details are available in the US-CERT Recommended Practices document, "OPC Security White Paper #3–Hardening Guidelines for OPC Hosts" listed in the References section.

It is important to note that these settings are more complex than the ones noted in the earlier section on firewalls and can negatively impact OPC operations for some products. Thus we highly recommend that you test them in a non-production environment such as a lab or simulator first.

Launching Component Services
There are two main objectives in managing accounts and permissions in an OPC Server. First, we only want to give as much permission as is required, and ideally we want to do that on a per DCOM application basis. For example, if a computer is running three OPC servers, but only one needs to be accessed remotely, only allowing remote access to that one server is the preferred solution.  Similarly, if all OPC servers and clients are on a single host, then disable remote access and allowing only local access significantly improves overall security.

Figure 3: Component Services (DCOM) Configuration Tool

Second, we need to create and use different level user accounts for OPC's Launch and Access permissions. In most control environments, the day-to-day operation of OPC-based applications does not require a highly privileged account. On the other hand, the configuration of OPC applications often does. Unfortunately, in many systems we see the highly privileged account settings being the norm, exposing the system to numerous security issues.

To address this, we recommend OPC administrators create two accounts, one for day-to-day operations and one for configuration. First, an account (or better yet an account group) should be created called "opcadmin" that is the only user account used to launch or configure OPC servers. A second account (or account group) called the "opcuser" account can be created and used by users who need only to connect and access running OPC servers.