Effective OPC security for control systems - Part 1

For the past decade, industrial control systems administrators and engineers wanted to believe that ‘air gaps’ truly existed between their systems and the rest of the world. They have also hoped that ‘security by obscurity’ would keep them safe from security threats. Those days are over - 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.

The aggressive and targeted Stuxnet worm attacks shed light on just how vulnerable and exposed automation systems really are. They also give us a glimpse of the future threats to industry. Ultimately they provide a clear warning: secure your control and automation systems or the reliability and safety of your entire operation is at risk.

While the consequences of cyber attacks and malware are no longer in doubt, the question remains: exactly how can an engineer reliably secure their control system?

Systems are changing

Information networks have become the heart of the supervisory control and data acquisition (SCADA) systems companies use to provide centralised management and monitoring capabilities. Traditionally companies constructed distributed control systems (DCS) and SCADA systems that were separated from other corporate systems. Such systems were effectively ‘walled off’ by proprietary equipment or protocols.

Business drivers have led to the convergence of company networks and industrial technologies. For example, the demand for remote access for either data access or support has rendered many control systems accessible through non-SCADA networks. Similarly, many companies are reducing network deployment and management costs through shared hardware, backbones and network support resources. Most important of all, the increased use of commercial-off-the-shelf computer components and office network technologies has transformed the way business is conducted in almost every major industry. These standardisation strategies are enabling companies to operate cost effectively, communicate more efficiently and implement more agile business practices through instant access to data throughout the organisation, including the plant floor.

While companies reap the benefits of these initiatives, many are also discovering the inherent dangers that result from making control networks more accessible to a wider range of users. Linking corporate systems together to provide access to customers, suppliers and other third parties significantly increases the vulnerability of sensitive and proprietary information contained in these systems. It also exposes the systems to external events such as worms, viruses and hackers. This increases the demands on system administrators to balance the need for accessibility with the need to safeguard the integrity and usability of their mission-critical control systems.

Reducing the attack surface

One of the most effective ways to manage the conflict between the demands of efficient access and the demands of effective security is to minimise the variety of interfaces and protocols operating between the control system and the external networks. Having one approved connection solution that serves multiple corporate requirements not only reduces deployment and administration costs, it also reduces the opportunities open to the attacker or worm. This is known as reducing the ‘attack surface’ of a system.

Thus, the first task for an administrator is to select an appropriate communications technology that can be used by the widest variety of control and business systems. While there are a number of possible candidates, including Modbus/TCP or Hyper Text Transfer Protocol (HTTP), OPC is without question one of the easiest and most widespread standards to address the demands of universal data access in the industrial automation world.

Once known as OLE for Process Control and now officially referred to as OPC Classic, it is the world’s most widely used industrial integration standard. It is employed by a broad range of industrial and business applications ranging from interfacing human machine interface (HMI) workstations, safety instrumented systems (SIS) and DCSs on the plant floor, to enterprise databases, enterprise resource planning (ERP) systems and other business-oriented software in the corporate world.

But what about the security demands - can OPC address these? The answer is a definite ‘yes’. By layering defences that are OPC-aware, high-security solutions can be created that meet both the security and access expectations of a company, all without administrative overload on the network or controls team. The result is a standards based solution that has been proven across numerous different control systems.

Layering defences

If reducing the attack surface is the first key to good security, the second is the layering of security defences. Often referred to as ‘defence in depth’, the concept is to manage risk with diverse defensive strategies. Layering defences gives several benefits. The most obvious is that if one layer of defence is compromised, another layer of defence using a different security method presents an additional obstacle which can inhibit further penetration.

A more subtle, but equally powerful benefit is that attacks come in different flavours and each defensive layer can be optimised to deal with a specific range of threats. For example, defending against a standard computer worm needs different techniques compared to defending against a disgruntled employee. Thus a key to enhancing each defence in depth layer is ensuring that each layer of security considers the context of the information or system it is protecting.

Defence in depth: bank example

Security in a bank presents a good analogy for the defence in depth approach to security for control systems. What is it that makes a typical bank more secure than a home or convenience store? The bank employs multiple security measures to maximise the safety and security of its employees, customers and their valuables. Not only are there more layers, each layer is designed to address a specific type of threat at the point where it is employed. For example, just to name a few defences, a typical bank has steel doors, bulletproof windows, security guards, security box keys, safes and security-trained tellers. Bank doors are effective but simple security devices. They are either locked or unlocked. They either grant or deny access to customers on an all-or-nothing basis - regardless of what a visitor looks like or how the visitor behaves.

One layer up is the security guards - they perform access control to ‘clean’ the general flow of people into the bank. They ensure that access to the bank is for people who have a legitimate need to be there and will ‘behave’ within expected norms. They regard each visitor based on specific criteria, such as, not wearing a mask, suspicious behaviour, acting erratically etc. At yet another level, the tellers, security box keys, passwords, etc, keep these pre-screened customers from accessing other accounts or information. Rather than worrying if a visitor should or should not be in the bank, the tellers and passwords present a different layer of security: account security. These measures ‘filter’ what account access individual customers are allowed, based on who they are. Note that the security layers are context specific, which is why banks don’t simply have additional security guards at every level. The security solution must fit the context of the threat expected at that level. Industrial control system security So what does this have to do with security on the plant floor? Well, for industrial communications the roles of the ’bank guard’ and the ‘teller’ are broadly analogous to ‘network security’ and ‘application-focused security’. For example, the firewall acts like the guard, so that specified protocols are either permitted or denied access into the control network. And just like a more experienced bank guard, 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.

Figure 1: How OPC-aware firewalls work.

Similarly, an OPC server with a robust OPC security implementation can act like a well-trained bank teller. After a user successfully connects to an OPC server, the OPC security configuration ensures they only get access to the specific sets of data they are supposed to see. Attempts to access others’ data should be blocked and logged (see Figure 1).

As with the guard and the bank teller example, the firewall providing the network security and the OPC server providing the application security are an essential team. For example, a firewall can block millions of randomly malformed messages directed at a server as part of a denial of service (DoS) attack. 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.

In Part 2

In Part 2 we will look at network-focused and application-focused security in more detail.

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. Examples of recent industrial security incidents: Incident 1 The Stuxnet worm, malware designed specifically to attack Siemens WinCC, PCS7 and S7 PLC projects, enters a control system through infected USB keys (so internet connectivity was a not a requirement for infection). However, once inside it spreads to other computers using protocols for file sharing, printer sharing and SQL database access. Since there were no patches for these attacks when the worm was first discovered, the best defence was to not let those protocols reach critical servers unless absolutely needed. Unfortunately, as noted earlier, old-fashioned OPC solutions would do just the opposite - every protocol possible was free to be sent to the OPC server, whether it was needed for control or not. Incident 2 In a less-famous incident, a major energy complex was infected by a virus in 2009, when a contractor remotely connected to a vibration monitoring system to provide maintenance support. The virus was able to propagate from the monitoring system computers to various DCS servers, causing repeated crashes of key servers and loss of production. At the time, the site used traditional IT firewalls to isolate the various control systems. Unfortunately OPC Classic’s use of dynamic ports resulted in firewalls rules being deployed that were ineffective in stopping the virus.

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