Properly protect control systems

Integrated digital field networks are increasingly popular but pose particular safety and security risks. Fortunately, a number of parallel activities are underway to make integration between automation and business systems effective, safe and secure.

By Ian Verhappen, MTL Instruments

Share Print Related RSS

Today’s chemical plants increasingly rely on digital communications not only for control at the field level but throughout the automation system and beyond. Such communications can provide tighter and better control of the process and enable increased integration between automation and business systems. Fortunately a number of parallel activities are underway to make this integration effective, safe and secure.

Figure 1, which is similar to the model used by the ISA-95 committee, shows the various layers of a typical facility. This article will  specifically examine safety and security for Levels 0 and 1, the field layers of the automation system. Levels 2 and above mostly include computer systems similar to those found in the IT or office environment and generally use the same forms of security as those — with the added requirement of high reliability and increased redundancy versus what’s expected in the Level 4 business system.

Figure 1. Most chemical plants use an architecture that contains five layers.

Figure 1. Most chemical plants use an architecture that contains five layers.

Each layer of the system is protected from the other by the use of firewalls, at least for the Ethernet-based communications systems. Fortunately, to date there haven’t been any documented attempts to compromise the Level 0 fieldbus networks. Therefore, the “only” concern here is keeping the network safe and reliable.

Reliability is paramount in automation systems. This means they must be safe, secure, fault tolerant and easy to maintain. Control engineers are familiar with designing systems to be reliable and easy to maintain — usually through redundancy and specifications that result in industrially hardened equipment that can operate in the presence of hazardous and corrosive gases across broad temperature ranges (typically -40°F to 180°F). What they’re not as familiar with is digital communications — fieldbus and Ethernet. Let’s start at the bottom with Level 0 fieldbus communications.

Fieldbus features

Fieldbus systems have built-in features to ensure the reliability and integrity of the communications. However, because they involve networks rather than single wire pairs, such systems require a variety of new tools. Both handheld maintenance units as well as continuous fieldbus-network analyzers are now available to help check the health of a system.

The field-level diagnostic tools monitor parameters unique to the relatively harsh environment in which the networks reside. Typical parameters include:

Voltage. There must be sufficient energy to power the field devices and ensure that the signals are detectable above background/environmental noise that may be induced on the cables.

Average and peak noise. This indicates the system is being affected by external noise signals such as EMI, (electromagnetic interference) RFI (radio frequency interference) and crosstalk between cables.

Short circuits. When these network faults occur, they will lead to the loss of one or more signals. Continuous monitoring will help in troubleshooting what may appear to be “random” failures by one or more devices.

Device retransmissions. An increase in how often signals aren’t getting through on the network often provides the first sign of impending larger problems.

Number of devices recognized on the bus. This can confirm that all devices are connected to the network and can track if devices are tending to drop, then reconnect and pin down the reason, whether due to a faulty device or other possible electrical problems.

A handheld diagnostic tool can help when a problem is happening. Continuous diagnostic systems capture the information on an ongoing basis and also provide a record of how the system changes over time. This is even more important than knowing what’s happening at a single point in time because it can indicate when a possible failure is imminent.

Fortunately these tools are now available for a variety of fieldbus networks.

Connectivity issues

In the past, most control systems used proprietary protocols, which as a result afforded a measure of security. Today, though, automation vendors have largely switched to open systems, which are much more susceptible to attack.

For instance, connectivity, especially at Levels 2 and 3, now generally involves OPC. This software-based tool to connect across protocols and systems presently heavily relies on Windows COM and DCOM. One of the security challenges associated with this is that it’s very difficult to secure the multiple ports required to open and close as part of the communications. Fortunately, there are some options. Proprietary solutions use various forms of “tunneling” similar to creating a Virtual Private Network (VPN) between the client and the server, but this is done differently by each manufacturer. A second option being groomed by the OPC Foundation is OPC UA (Unified Architecture), which during its development included security considerations. The OPC UA specifications are nearing completion and developers are now preparing the appropriate code, so expect the initial production releases of this version around the end of the year and demonstrations at ISA this fall. Interoperability testing should begin in early 2008.

Most fieldbus protocols now have gateways to convert their field-level signal to an Ethernet-based system, normally at Level 1; as a result this makes them susceptible to being compromised in the same way as the office environment, which also is based on Ethernet. Now, almost all the protocols are open and supported by not-for-profit organizations. Many of the details on the protocols can be found on the Internet. For example, the most widely used protocol, Modbus, is available from www.modbus.org without the need for any form of registration. Therefore, like the office environment, the solution in the automation arena is now “defense in depth.”

Defense in depth means using multiple layers of protection, so that attackers need to bypass or overcome several firewalls or similar products before they reach the control layer and can cause havoc with plant operation. Defense in depth could be deployed with, as a minimum, a firewall between each layer of the enterprise and a data historian system as a buffer on Level 3 between the control system and the business LAN. Level 3 is often referred to as a “Demilitarized Zone” or “DMZ” and is where all the information transferred between the control and business systems is accessed. The business system can only poll for data from the historian and not write commands directly to the control networks; similarly, any information that the control system requires, such as accounting, laboratory and ERP data, is stored on this system and then forwarded to the appropriate application on the supervisory control system.

Unfortunately, the DMZ, though an excellent tool, isn’t sufficient to provide all the protection required. This is in part because there are many “back doors” to the typical control system — from the dial-up modem or in some cases direct Internet connection for technical support to the wireless networks that for some reason do not recognize site boundary limits. (See sidebar.) Therefore, the defense in depth must continue through to the field layer and the products to go in that environment must also be able to operate in what regularly is a Zone 2 (Division 2) classified area.

Of course, the solution to the problem must not be more difficult than the problem itself. What’s required is a simple modular solution that’s easy to install and configure using techniques with which control engineers are familiar.

A number of manufacturers have released industrially hardened firewalls that require the system administrator to understand System Network Management Protocol (SNMP) and other associated command sets (remember DOS text string commands?) to properly configure each network node. This form of product is manually intensive to maintain, so the firewall manufacturers are now making “front ends” to assist in the configuration. One vendor is designing a new concept from the ground up to be both electrician and control-engineer friendly to the extent that, if desired, the system for the entire company can be remotely managed from a central location.

Figure 2. Besides firewalls between each level, such arrangements usually include a demilitarized zone.

Figure 2. Besides firewalls between each level, such arrangements usually include a demilitarized zone.

Compelling drivers

There are many incentives to improve the degree of protection of your industrial network system, including:

  • Chemical plants deemed “high risk” by the U.S. Department of Homeland Security now for the first time must take specific steps to ensure security (See the June cover story).
  • Data from the Industrial Security Incident Database [1] describes a number of events that directly impacted process control systems and shows that the amount of cyber incidents against SCADA and control systems worldwide has increased significantly since 2001 (Figure 3).

Figure 3. The number of cyber incidents has sharply increased in recent years. Source: Reference 1.

Figure 3. The number of cyber incidents has sharply increased in recent years. Source: Reference 1.
  • Studies show that in a typical corporation 80% to 90% of all control networks are now connected to the enterprise network — so, although the automation systems themselves rarely are directly connected to the Internet, they wind up interconnected to the Internet in myriad ways [2]. This, combined with the increased use of Commercial Off The Shelf (COTS) technology, raises the vulnerability of a control system to attack.

As Jim Wells recently noted [3], “They (IT) have the responsibility to make sure this portion of the network is safe and secure. Control system engineers have the same responsibility to make sure these control networks are sound and secure. …A well managed admin network employs tools like Active Directory, automatic virus scans [which require considerable processor overhead, sometimes increasing processor utilization 60% to 80%] and patches. …Conversely, a well managed control network has no unnecessary overhead, no unauthorized external influence, delivers critical information in guaranteed time slots and is fault tolerant or redundant. Therefore with noble and best intentions both groups head in different directions.”

One other difference between IT and control networks is that the goal of the IT group is to protect the core of servers, if necessary by sacrificing one or two remote desktops. Those responsible for control systems, on the other hand, must first and foremost look after the edge devices, such as PLCs and remote I/O, that are directly connected to and controlling the process — because if something goes wrong there process stability and hence plant safety and reliability are at risk.

Modern digital integrated control systems offer significant benefits — but at the price of a possible increase in risk. Our role as engineers is to manage and minimize that risk.

References

  1. Byers, E., D. Leversage and N. Kube, “Security incidents and trends in the SCADA and process industries: A statistical review of the Industrial Security Incident Database,” Symantec Corp., Cupertino, Calif. (2007). Available online at http://www.controlglobal.com/whitepapers/2007/010.html.
  2. Dorey, P., “Security management in process control: The 3 waves of adoption,” presented at Spring 2006 Conference, Process Control Security Forum, Falls Church, Va.
  3. Wells, J., “The great IT divide: good intentions separated by common objectives,” Industrial Ethernet Book (Feb. 2007). http://ethernet.industrial-networking.com/articles/articledisplay.asp?id=1588.

Ian Verhappen is director, industrial networks, for MTL Instrument Group, and is based in Edmonton, Alta. E-mail him at iverhappen@mtl-inst.com.

Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

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