Effective OPC security for control systems - Part 2

Recent security incidents such as the Stuxnet worm that attacked Siemens WinCC and PCS7 systems in Iran and the remote sabotage of a Texas power utility are a wake-up call for the industrial automation industry. We continue our article from last month with a more in-depth look at the concept of ‘defence in depth’.

In Part 1 of this article we looked at how the opening up of network technologies between the plant and the office have improved efficiencies, but introduced new security risks for our mission-critical plant systems. We introduced the idea of layered security with an example of security in a bank as an analogy for the layered defence needed for an industrial control system.

Industrial control system security In our example, the firewall acts like our bank guard, so that specified protocols are either permitted or denied access into the control network. And a more sophisticated SCADA-aware firewall observes the traffic beyond the obvious protocol types and makes additional filtering decisions based on the behaviour and context of the systems using these protocols on the network. Similarly, an OPC server with a robust OPC security implementation ensures that users only get access to the specific sets of data they are supposed to see. Attempts to access others’ data should be blocked and logged, as shown in Figure 1. The firewall providing the network security, and the OPC server providing the application security, work together. A firewall can block a denial of service (DoS) attack, and at the same time, user authentication and authorisation checks can prevent an attacker inside the firewall from accessing process set points in a system and making changes that might risk property or lives. Network-focused security To understand network-focused security, it is important to know that most TCP/IP protocols, such as Modbus TCP, include an internationally recognised number (called a port number) in each message to identify the message as being part of a specific upper-layer protocol. This consistent protocol identification makes it easy for firewalls to block specific protocol messages or to allow them to pass. For example, to block all Modbus/TCP traffic, all a firewall needs to do is search for and then block any message that contains the port number assigned to Modbus/TCP (namely 502) in certain fields.

Figure 1: How OPC-aware firewalls work.

An out-of-the-box OPC server does not use a fixed TCP port number. Instead the server dynamically assigns a new TCP port number to each process that it uses to communicate with OPC clients. The OPC clients must then discover these associated port numbers by connecting to the OPC server and asking what TCP port number they should use for the session. OPC clients then make a new TCP connection to the OPC server using the new port number. OPC servers may use any port numbered between 1024 and 65535 which makes OPC Classic ‘firewall unfriendly’.

On one hand, configuring a traditional IT firewall to leave such a wide range of ports open is like having a sleeping bank security guard watch the front door. On the other hand, insisting on locking down these ports effectively ends up blocking OPC communications. Today, the OPC dynamic port allocation issues are no longer an excuse not to install firewalls in front of OPC servers. New OPC-aware firewalls can now automatically track and manage OPC Classic’s dynamic port problem. These firewalls are designed to be dropped into existing networks without any changes to existing OPC clients and servers.

Figure 2: AN OPC-aware firewall safeguarding OPC clients and servers.

A good example is the Byres Security’s Tofino Security Appliance with the Tofino OPC Enforcer - a security appliance and OPC firewall. Such devices are designed to be installed in a live control network with no network changes and no plant downtime. They are a simple and cost-effective way to create zones of security in a control system, as recommended by ANSI/ISA99, NERC CIP and IEC standards.

Application-focused security

Returning to the bank analogy, once visitors get past the front door and the guard, they approach a teller to take care of their transactions. The teller’s job is to both facilitate transactions and to ensure only those accounts the visitor has access to are affected. The OPC servers of virtually all OPC vendors simply rely on DCOM to address security (the guard at the door) and do not provide specific access control security (the tellers).

Access control security, or application-focused security, must be addressed through OPC-specific security measures and through properly designed OPC architectures. As connectivity continues to expand throughout the enterprise, properly implemented ‘defence in depth’ is crucial. Without it, systems exposed to a growing list of threats may not work within target parameters, potentially causing expensive safety, environmental and production incidents.

While many OPC installations rely on corporate firewalls and proper DCOM configuration for security, assessments show that open firewalls and permissive DCOM access rights remain common vulnerabilities. Even in cases where systems are configured correctly, they still do not offer the granularity of security needed to fully protect the system. What is the problem? Corporate firewalls and general Windows DCOM security are not aware of the OPC context. Only by using security products that are OPC ‘aware’, that support the OPC Security specification, and that properly utilise the information this provides is it possible to provide an effective level of protection.

OPC server security options

Any OPC server or product has the option to implement one of three levels of security: disabled, DCOM or OPC security. Each level offers more security and control over who has access to data within the OPC architecture.

• Disabled security - No security is enforced. Launch and access permissions to the OPC server are given to everyone, and access permissions for clients are set for everyone. The OPC server does not control access to any vendor-specific security functions.
• DCOM security - Only Windows DCOM security is enforced. Launch and access permissions to the OPC server are limited to selected clients, as are the access permissions for client applications. However, the OPC server does not control access to more specific security functions. This is the default security level provided by DCOM.
• OPC security - Supports the OPC Security specification. The OPC server serves as a reference monitor to control access to specific security functions that are exposed by the OPC server. An OPC server may implement OPC security in addition to DCOM security, or implement OPC security alone.

Role and user-focused security

The OPC Security specification focuses on client identification by using trusted credentials to determine access authorisation decisions by the OPC server. It enables OPC products to provide specific security controls on adding, browsing, reading and writing individual OPC items. Within the plant environment different job roles require different types of data access:

• Control system engineers might require full read and write access to all points in the automation system
• Operators might be restricted to only those data points associated with the status and control of machines within their particular plant unit
• Management-level personnel would most certainly only require read access to key performance data items

Applying the most appropriate security access means applications must be able to understand the context in which particular users are accessing information. Security you can bank on The implications of ignoring OPC security will grow rapidly as the demand for OPC connectivity continues to increase. History shows that the root cause behind many publicised security failures has been the result of improper use of, or the complete lack of, IT security safeguards. Control automation professionals who are security aware use a combination of control system-focused network security practices, proper OPC architecture design and OPC-centric security products. Using the right products, the security of existing systems can be greatly enhanced without the need for replacing equipment or in-depth IT experience. The MatrikonOPC Security Gateway and the Tofino OPC Enforcer are examples of off-the-shelf components that can secure OPC-based communications quickly and easily.

Figure 3: MatrikonOPC Security Gateway architecture.

The reality is that security incidents don’t just happen to ‘other people’. Smart companies will prepare for the unexpected by evaluating their OPC security before a costly security incident occurs.

Background: The term OPC Classic refers to all OPC standards prior to the new OPC Unified Architecture (OPC UA) standard. This includes the most popular specifications such as OPC Data Access (OPC DA), OPC Alarms and Events (OPC A&E) and OPC Historical Data Access (OPC HDA). Visit the OPC Foundation website for more information.

By Darek Kominek, Manager, OPC Marketing, MatrikonOPC and
Eric Byres, PEng, ISA Fellow, CTO, Byres Security Inc