- 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.
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.