No Sure Safety Without Security

Wednesday, April 14, 2010 @ 06:04 PM gHale


By Charles Fialkowski and Todd Stauffer

In today’s competitive global economy, manufacturers are driven to continuously reduce costs, improve operational efficiency, and manage risk more effectively. This also applies to the use of safety instrumented systems (SIS), whose job is to mitigate the risk of serious incidents that could lead to personnel injury, damage to equipment or the environment, and disruption of production.

In the past, safety systems were independent and completely isolated from their associated process control systems. Now manufacturers with safety-critical operations evaluate the need to integrate safety and process control systems to reduce the cost of configuration, training, and support, as well as to improve operations.

The industry has raised the criticality of cyber security vulnerabilities because of trends to move away from standalone safety systems toward integrated systems, as well as the adoption of commercial off-the-shelf (COTS) technologies, such as Windows and Ethernet. One study found 80-90% of process control systems connect to the company’s enterprise network, which in turn connects to the Internet. This opens the door to cyber attacks originating from outside the plant ‑ the major source of attacks since 2001.

Because of the growing importance of cyber security, a new industry consortium called Linking the Oil and Gas Industry to Improve Cyber Security (LOGIIC), launched to assess the security implications and characterize the risk of the various approaches to integrating safety and process control systems.

After the 9/11 attack the potential for terrorist damage to our nation’s critical infrastructure became a grim reality. The Homeland Security Presidential Directive 7 (HSPD-7) and the National Infrastructure Protection Plan (NIPP) identified industries that support the critical infrastructure of the U.S. Among these are the Chemical and Energy (Oil & Gas) sectors, which use safety systems to protect plant and personnel, and to comply with international safety standards.

Standard requirements for integration

International safety standards, including IEC 61508, 61511, and S84, provide a framework and specific requirements that address the integration of safety and basic process control systems (BPCS). The ISA84 safety standard currently mentions handling failures involving the operator interface as well as the engineering and communications interfaces. But it does not address security implications. However, the committee is considering including cyber security requirements and recommendations to future versions of the ANSI/ISA S84-2004 (IEC 61511 modified) standard.

Security impacts on safety

The heightened concern for securing safety systems and the potential consequences resulting from cyber security incidents are definitely valid. In a live demonstration performed at the Applied Control Systems Security Conference in August 2008, representatives from Wurldtech showed they were able to hack a TÜV-approved safety controller, putting it into an unsafe state. Real-world incidents are also bringing this reality to light.

Viruses and worms originating from the Internet have directly had an impact on the operation of safety systems. In 2003, the SQL Slammer worm infected the plant network of the Davis Besse Nuclear power plant, disabling the safety parameter display system (HMI) and plant process computer for hours. The following year the Sasser worm took out oil platforms in the Gulf of Mexico when it disabled a panel that monitored crucial safety indicators and caused the plant’s process computer to fail.

In March 2008, the Hatch Nuclear Power Plant in Georgia went into an emergency shutdown for 48 hours. A software update installed on a single computer operating on the plant’s business network and monitoring diagnostic data from the plant’s control systems caused a data dropout to the safety system, which then triggered the automated shutdown. Ironically, in each of these cases, the safety system did its job by shutting down the system and taking the process to a safe state. But when you look at it, unplanned downtime means lost revenue.

Integrating safety, process control

Business benefits abound from integrating safety and process control systems. In the past few years suppliers have introduced safety systems that share a common set of hardware and software (engineering tools) with their process control system. The use of common technology can result in the following cost savings:

  • Eliminates need to implement and support multiple networks
  • Eases integration of components and systems
  • Reduces spare parts on the shelf
  • Simplifies engineering and maintenance of one system over multiple systems
  • Reduces training requirements
  • Improves accessibility and remote support
  • Common HMI means one operator monitors more of the process

Sharing data between SIS and BPCS

Interconnection of safety system, process control system.

Operating a safety system and a process control system can be intertwined. Consequently situations can occur in which manufacturers might share selected signals between a safety system and a process control system. When controlling airflow during a combustion process, the SIS and the BPCS need the air flow signal. Since the flow cannot handle multiple restrictions in series, only a single orifice plate can derive this measurement. Consequently manufacturers in this scenario choose to share the flow measurement between both systems. Rather than installing and wiring two separate sensors (which would restrict flow), sharing safety system data with the process control system can improve control of the process and reduce the cost for wiring and installation.

Similarly manufacturers choose to share data between systems to help optimize the operator’s performance. By propagating safety interlock information up into the process control system HMI, the operator can pinpoint the cause of a trip and determine a safety interlock, such as “drum level too high” or “gas pressure too low” is overriding operation of the process control system. Integrating alarms into a common operator interface also helps the operator better manage process upsets by allowing him to navigate to a soft landing of the downstream process after an emergency shutdown (ESD) trip, and by making it easier to restart the process.

This sharing of signals manifests most commonly as controller peer-to-peer communication, displaying SIS status information within the process control system HMI.

Analyzing risk, vulnerability

The goal of a safety system is to mitigate the risk of serious incidents that could lead to personnel injury, damage to equipment or the environment, and disruption of production. During the design of safety systems, the safety engineer calculates the likelihood of the safety components to maintain a safe state of the operating equipment. This statistical analysis takes into account the mean time between failure (MTBF) of the hardware and software based on its component design and the potential for random hardware faults. Cyber security vulnerabilities inject a new variable into these calculations. A cyber security incident could unleash systematic software faults that compromise the safety integrity level (SIL) of the safety system and compromise the layers of protection the safety system is counting on. We should consider whether a vulnerability that can cause a BPCS controller fault is capable of simultaneously compromising the compensating safety system.

A risk analysis (HAZOP) can reflect a refinery that was trying to connect its safety system to the process control system as part of a retrofit project. Of greatest concern from a security viewpoint is the safety system’s ability to:

  • Make unauthorized configuration changes to the safety system controller from the engineering station
  • Manipulate safety system inputs and outputs
  • Interfere with the HMI’s ability to represent the status of the SIS (loss of alarms, spoofing the operator, or loss of view entirely)

Connecting safety to process control

We can divide connectivity of process control and safety systems into three levels: interfaced, integrated, and common. Each approach has it own pros and cons from safety and security viewpoints.

Interfaced – The process control system (DCS) and the safety system (SIS) use different control & I/O hardware (typically from different suppliers) and connect through a gateway for exchange of data. The two systems use separate engineering tools and dedicated operator interfaces.

  • Pros: No common-cause failure modes
  • Cons: Higher costs for hardware and installation, higher engineering and maintenance costs, additional training, gateway issues

Integrated – The process control system (DCS) and safety system (SIS) use separate, dedicated control & I/O hardware but share a common network, engineering tools, and operator interface.

  • Pros: Reduced costs for hardware and installation, reduced engineering and maintenance costs, less training required, no gateway issues, fewer spare parts
  • Cons: Reduction of system access control, limited use of diverse technology

Common – The process control system (DCS) and safety system (SIS) are combined into a single system. They use common control and I/O hardware as well as engineering tools and operator interface. Standard and safety-related programs are executed in parallel and independent of each other.

  • Pros: Lower hardware costs, fewer spare parts
  • Cons: Higher false trip rate, common-cause failure modality, management of change, increased system complexity, reduced system access control

Security considerations

A compromise in the sending and receiving sides of the safety system and process control system, or the communication path between them, opens up the potential for a cyber incident. Proper security implementations can ensure compromises do not propagate through the connection but stay isolated on the sending or receiving side.

A typical scenario for a remote, Internet-based attack involves the propagation of malware (such as a virus, worm, or trojan) from PC to PC and from network to network. It can also involve the hacker moving step by step deeper into the network by gaining control of one PC after another. Each PC is a stepping-stone to get closer to the target (control system). If the hacker is able to gain access to the process control network historian, he is in position to attempt to break down the engineering system, compromise the HMI, and modify the controller configuration. Thus it is extremely important to place multiple barriers throughout the architecture (a technique called defense in depth) to make it difficult for a hacker or virus to work its way through the system to its most critical assets.

Standalone safety system

Some people will tell you the only way to ensure the security of a safety system is to keep it isolated by implementing an air gap. The SIS network is not connected to the BPCS or any plant network. The BPCS, on the other hand, we assume to have an indirect connection to the Internet through one or more firewalls (as in plants today). This approach, however, eliminates the potential benefits from the sharing of signals, and results in a higher lifecycle cost (engineering, maintenance, spare parts, and the like). We cannot take security for granted, even in this case. In fact by thinking their SIS is secure because it is isolated, users might let their guard down and take actions that compromise the air gap.

Common scenarios in which an isolated system can become compromised are consistent with documented cases of actual cyber security incidents. If an engineer transports data onto the safety system engineering station by copying files from a USB memory stick (thumb drive), the system could become infected with a worm or virus from the memory stick. This would also nullify the air gap by connecting the safety system to the outside world. If you thought the safety system was secure because it was isolated, you probably would not have virus protection installed on your safety-system engineering station. This actually makes you more vulnerable to viral infection than if you had planned for connectivity. If you install virus protection, then you would need a connection to an outside network in order to keep the virus scanner up to date with the latest virus signatures.

Another common scenario that would violate the air gap and lead to problems is the temporary connection of a laptop or another network to the safety system’s isolated network. This often occurs so plant personnel or a contractor can perform maintenance and engineering. In several cases the temporary connection allowed a virus onto the network. In another case, network communication was interrupted when the laptop’s IP address turned out to be identical to one that was already used on the safety system network. Finally, in numerous cases, a temporary network connection addition bypassed existing firewalls and IT security mechanisms; the connection stayed in place. One reason for this could be to download new patches from Microsoft or access product documentation from a supplier’s website.

An air gap can be an effective method for securing a safety system only if operating procedures ensure there is never a connection to an outside network or device. In a perfect world this approach would be ideal, but reality dictates this might not be practical. Worse yet is the case in which no security mechanisms are in place because operators thought the system was isolated when in fact it really wasn’t.

Interfaced safety, process systems

Creating an interface or gateway between a safety system and process control system allows sharing of I/O signals between the two systems. This can reduce installation costs (less instrumentation and wiring) as well as improve operator performance by integrating information on the SIS status within the process control system HMI.  The two most common methods for sharing signals between the two systems (particularly disparate systems from different suppliers) are using Modbus or object link embedding (OLE) for process control (OPC). In the past, proprietary gateways also saw use for this purpose.

For quite a few years, Modbus has been the primary communication protocol for sharing data between different systems. We can implement connectivity at different levels of the architecture. Modbus serial communication occurs at the lower levels of the system over a dedicated wire using RS232 or RS422/485. Since most cyber attacks originate from the corporate intranet/Internet, a potential hacker or virus would have to penetrate deep into the system before it could intercept this communication. Therefore using Modbus serial communication can be a secure method for data exchange. It does however have significant performance and technical limitations. Modbus has low bandwidth, is not interference-free, has a high configuration cost, and does not support safety-certified communication.

Modbus TCP/IP allows the Modbus data packets to transport over Ethernet using the TCP/IP protocol. In recent years this method has become more popular for communicating between PLCs and RTUs, as well as for connecting safety systems to process control systems. Without additional security precautions, such as special firewalls, Modbus TCP communication can be compromised. In 2002, the control system of a major Venezuelan oil company was hit by an Internet-based attack. A hacker was able to access the corporate network from the Internet. Once on the network he was able to see PLCs were communicating via Modbus TCP. The attacker then created and sent his own Modbus TCP commands to the PLCs, which erased their programs and took down the operation.

OPC is another protocol to use for communicating data between a safety system and a control system. The vulnerabilities of OPC, and a technology it relies on called DCOM, have been well documented and are well known within the hacker community. These include difficulty in setting up a secure firewall (because OPC does not use specific TCP ports, a firewall may need to be wide open in order to pass data), lack of security on the datastream (messages are not encrypted), and lack of OPC’s ability to control which tags a user may access (thus any access becomes full read/write access for all tags). Carefully consider using OPC for communication, and supplement it by adding security measures, such as IPSec, VPN, or similar encrypted tunneling.

“Clearly the problems of classic OPC were all about the limitations and the fact there were problems preventing safe and secure systems being deployed across firewalls,” said Thomas Burke, president and executive director of the OPC Foundation. “But with the advancement of the technology and the requirements for safe, secure systems the OPC Unified Architecture (OPC UA) was specifically designed to provide complete mechanisms built into the architecture including access level security at the tag level. Although there were problems with classic OPC across the DCOM channel and having to open up the doors for security; many vendors took the opportunity to provide products and tunneling solutions to address security flaws.”

Integrated systems

The use of integrated systems based on common technology opens up additional possibilities for creating safe and secure connectivity. In an integrated but separate system, the safety system and process control system use the same type of hardware (from the same supplier) but have separate and distinct components for the HMI, for engineering, and for control and I/O. In this modern architecture, safety fieldbus communication creates a secure communication path.

One option is the use of a safety fieldbus as the medium for sharing data. Use a fieldbus coupler as the gateway between the two systems. In this architecture, I/O signals originating from the safety system I/O (such as a low-flow signal) can communicate in parallel to both systems. The soft I/O brought into the BPCS controller can see use for control or interlocking. Or you can propagate it up to the BPCS HMI to reflect the status of the SIS to the operator. This method of communication would be very secure from a remote attack. It would, however, underscore the need to control access to the fieldbus network, which might run throughout the plant.

Another option is to use a safety-certified communication over Ethernet to connect the SIS and BPCS controllers. Some systems allow the addition of a safety-certified communication capability to the BPCS controller, which is key to enabling safe and secure data exchange between the systems. You can set up communication over a dedicated network (recommended) or route it through a firewall connecting the SIS and BPCS Ethernet networks. Most firewalls would not be able to analyze or inspect safety-certified message packets, thus we prefer a dedicated network.

In some architectures, separate and distinct controllers see use for the safety system and the process control system. They are able to share I/O signals between the two systems by using safety communication over fieldbus or Ethernet. A set of common HMIs can display SIS and BPCS data together along with a dedicated HMI for display of SIS data only. A common engineering station would configure both the SIS and BPCS applications.

The key to keeping this architecture secure is to prevent the likelihood of a remote attack originating from the Internet or corporate network. If a remote attacker could gain access to the SIS/BPCS Ethernet network, he could possibly disable the HMIs, causing the operator to lose his view into the process and safety system. For quite a few operations, loss of HMI for the safety system requires executing an emergency shutdown.

Once on the network the attacker could also try to gain control of the engineering station, which leads to possibly modifying the controller configuration or manipulating inputs and outputs in the SIS. Several SISs require additional authentication and use passwords to help prevent unauthorized configuration changes to the safety controller. Some SIS controllers come with a physical safety switch on the hardware itself, which prevents all downloads from the engineering station until the position of the switch moves (which you cannot do remotely).  Safety systems incorporate significant error and discrepancy checking. If a hacker were to attempt to manually force I/O points, the system would detect the discrepancy and put the I/O in its fail-safe state (thus protecting the plant from disaster).

To prevent cyber attacks in an integrated architecture, you must enable and use available security and access control features for engineering of the SIS (such as separate passwords). With the greatly simplified Ethernet network in place, focus on effectively securing the SIS/BPCS network from the outside. We recommend firewalls, intrusion detection, and implementation of network topologies using demilitarized zones (DMZ).

Safety-certified means  security

Safety-certified communication protocols can improve security and provide safety functionality. A protocol such as PROFIsafe uses a software layer on top of standard PROFIBUS and Ethernet communication. Special measures are in place so communication partners can recognize and compensate for transmission errors, such as delays, incorrect sequences, faulty addressing, or data falsification/corruption. These same mechanisms, built-in to achieve a TÜV-certified safety level of SIL 3, also enhance the security of the communication.

Measures such as CRC checking improve the security of the data exchange by making it more difficult to send corrupted data. The measures for message timing and acknowledgment, as well as the identification of transmitter and receiver also help prevent man-in-the-middle cyber attacks. Communication is one way using master/slave. Thus the safety system as the master would specifically request date from the slave (BPCS controller). It would not accept random, unexpected messages from other sources (such as a hacker) and would disregard any response not received in the expected time.

Common, but one

In an architecture in which a safety and process control system share common hardware and software, a single controller performs SIS and traditional BPCS control functions. Standard and safety related programs execute parallel and independent of each other. I/O signals from the SIS and BPCS are readily available for use within the control strategy and for propagation up to the HMI. A set of common HMIs would display SIS and BPCS data and a dedicated HMI would likely display only SIS data.

The security vulnerabilities and considerations for the Common architecture are similar to those for the integrated architecture (Level 2) with common HMI and engineering. The use of a single controller for safety and process control creates the potential for a common-cause security failure. Consequently, pay significant attention to protecting the engineering station from unauthorized access.

Behind the byline
Charles Fialkowski, CFSE, is a national process safety manager at Siemens Industry Inc. His email is charles.fialkowski@siemens.com. Todd Stauffer is director of alarm management services at exida. His email is tstauffer@exida.com.



One Response to “No Sure Safety Without Security”

  1. Eric Byres says:

    Excellent article, this nicely summarized the current state of the safety/SIS/Security issue.

    Two comments though – First you state that a potential hacker or virus would have to penetrate deep into the system before it could intercept Modbus serial communication and thus using Modbus serial communication can be a secure method for data exchange. Ten years ago, this might have been true, but for systems today, I have to disagree.

    In nearly every new Modbus installation for SIS I have seen in the past few years, Modbus serial to Ethernet gateways are involved in some way, either at the BPCS or at the SIS (or both). These immediately expose the MODBUS traffic to all the issue of LAN connectivity. The only way to address this is through some sort of Modbus deep packet inspection DPI firewall, as you suggested in your article.

    Second, you state that “because of the difficulty in setting up a secure firewall (because OPC does not use specific TCP ports, a firewall may need to be wide open in order to pass data)” you should “suppliment it by adding security measures, such as IPSec, VPN, or similar encrypted tunneling.”

    I agree that adding security measures is neccessary for OPC, but there are a number of simpler options besides the ones you suggest. For example, Triconex, a major SIS supplier, offers a OPC-Aware firewall specifically designed to manage the DCOM port issue and both Triconex and Matrikon offer solutions specifically designed to control which tags a user may access. In Triconex’s case, this fin grained control is integrated into their communications module configuration, while in Matrikon’s case it is offered as a Security Gateway application.

    Other than these two minor points, this is a great article.


Leave a Reply

You must be logged in to post a comment.