Safety or security? The confusion that costs an industrial site dearly

This is part 2 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 3, one standard, two regimes.

Picture a safety controller that trips and takes the unit down with it. The instrument technicians check the transmitters, the wiring and the logic solver diagnostics; the vendor’s engineers look at the hardware. A week later the plant is running again, and the event is closed as a mechanical fault. Nobody asked whether someone had done it on purpose. That is, in outline, what happened at the start of the best-documented attack on a safety system to date.

This series looks at the words that cause industrial security programmes to stall. The first article argued that vocabulary is the first point of failure. This one takes the pair of words with the heaviest consequences: safety and security.

In French, sûreté and sécurité are two separate words that many people use interchangeably. In other languages a single everyday word covers both, and international teams often fall back on the English terms to stay precise. Whatever the language, the risk is the same. If two disciplines use one word, they end up applying one set of rules to two different problems.

What safety is

Safety, in the process-industry sense, protects people, the plant and the environment against accidental failure: a valve that sticks, a sensor that drifts, an operator error, a runaway reaction. Its method is well established. A hazard and risk assessment, often a process hazard analysis (PHA) run as a HAZOP, identifies what can go wrong and how bad it would be. A layer of protection analysis (LOPA), one of the methods IEC 61511-3 describes, then checks whether the existing protection layers reduce each scenario’s risk enough, and sets how much extra reduction is still needed.

That extra reduction is often delivered by a safety instrumented function, and its required reliability is expressed as a safety integrity level (SIL). The functions are grouped in a safety instrumented system (SIS): sensors, a logic solver and final elements that bring the process to a safe state when it drifts out of bounds. The governing standards are IEC 61508, the generic functional-safety standard, and IEC 61511, its implementation for the process industry sector.

What security is

Security protects the same installation against intentional acts: malware, an intruder on the network, a misused remote access, a malicious insider. The reference framework for industrial systems is ISA/IEC 62443. It partitions the system into zones and conduits, gives each zone and conduit a target security level, and sets requirements for asset owners, service providers such as integrators, and product suppliers.

The difference is not academic. Safety reasoning assumes failures are random and can be quantified with failure rates. An attacker is not random. They look for the weakest point, can trigger several failures at once, and can defeat a protection layer that probability calculations treated as independent.

The SIS: where the two worlds meet

The SIS is the last automated layer between an abnormal situation and an accident. It is a safety system by design, but it is also a programmable computer, with firmware, an engineering workstation and network interfaces. That makes it a security target.

The process-safety standard has recognised this since its 2016 edition. IEC 61511-1:2016 requires a security risk assessment of the SIS (clause 8.2.4), and requires the SIS design to be resilient against the security risks identified. For the how, the note to that clause points to three guidance documents: ISA TR84.00.09, IEC 62443-2-1 and ISO/IEC 27001. ISA’s technical report on cybersecurity in the safety lifecycle is now in a 2024 edition, published as Part 1 of a series. The earlier article on cybersecurity and functional safety in this journal follows the same bridge from the safety side.

The clearest public illustration is TRITON, also known as TRISIS. In 2017, attackers reached the SIS engineering workstation of a petrochemical plant in the Middle East and deployed a framework built to reprogram its safety controllers, which the FBI identifies as Schneider Electric Triconex. According to an FBI notice of March 2022, coordinated with CISA and the Department of Energy, TRITON “was malware designed to cause physical safety systems to cease operating or to operate in an unsafe manner.” The same notice records that the facility entered a safe state after several controllers detected an anomaly caused by software bugs in the malware, and that the investigation of that shutdown revealed the attacker. On 23 October 2020 the US Treasury sanctioned a Russian government-controlled research institute, the Central Scientific Research Institute of Chemistry and Mechanics (TsNIIKhM), for its connection to the malware.

Failure mode 1: the SIS treated as an ordinary IT asset

The first failure comes from the security side. The SIS appears in an inventory as “a controller” and receives the same treatment as the rest: the same network zone as the basic process control system, a shared engineering workstation, a remote access opened for convenience, a patch or a scan scheduled without involving the safety engineers.

Each of these decisions may be defensible for an office PC. For a SIS, a patch is a modification of a safety system and belongs in management of change, with the vendor and the functional safety team. A remote access path is a way around the last line of defence. After TRITON, the first recommendations published by FireEye’s Mandiant in December 2017 were to segregate safety system networks from process control and information networks where technically feasible, not to dual-home engineering workstations capable of programming SIS controllers, and, on the affected controllers, not to leave the physical key in program mode other than during scheduled programming events.

ISA/IEC 62443-3-2 makes the principle explicit: requirement ZCR 3.3 asks for safety-related assets to be separated when the system is partitioned into zones. EUCALEX recommends placing the SIS in its own zone, distinct from control, with its own conduit, and in most cases giving it the highest target security level on the site.

Failure mode 2: the cyber alert lost in the safety channel

The second failure runs the other way. An unexplained trip, a logic change nobody recognises, a diagnostic error on a safety controller: these events land naturally in the safety incident process. It is well organised, and it asks well-trained questions about instruments, wiring and process conditions. It rarely asks whether someone did this on purpose.

TRITON again shows the cost. According to the US Department of Energy’s CyOTE case study (June 2022), the malware accidentally shut down one SIS controller on 2 June 2017; engineers determined that the shutdown was a mechanical error, and the refinery resumed operations after seven days. The attackers then had “another two months of unimpeded access to the network”, until six controllers tripped on 4 August. A cyber event filed only as a safety incident follows the wrong investigation, reaches the wrong people and may be closed before anyone looks at the network.

Routing alerts and incidents

Merging the two processes would bury one under the other. Connect them instead, at a few defined points, so that neither team decides alone what kind of event it is facing.

Behind the table sit three decisions a site should write down in advance: who is the named recipient of OT security alerts, who in the first hour decides whether production must stop, and how the OT incident procedure hands over to the safety channels and back. The procedure should be tested in an exercise that includes both teams.

Security is now a precondition of safety

In IT, the classic order of priorities is confidentiality, integrity, availability. NIST SP 800-82 is more precise: OT security objectives typically prioritise integrity and availability, followed by confidentiality, with safety as an overarching priority. That ordering is sometimes used to argue that security is a secondary concern on the plant floor. It points the other way. A SIS that can be reprogrammed from the network no longer provides the risk reduction its SIL calculation assumed. The LOPA is still on file, but it no longer describes the plant.

Where to start

At the next site review, look for three things: the SIS in its own zone with no dual-homed engineering workstation, a route by which an unexplained trip reaches someone able to check for a cyber cause, and the SIS security risk assessment IEC 61511-1 has required since 2016. In our experience the third is the one most often missing, or sitting in a security folder the functional safety team has never opened. The steps below take them in order.

1. Draw the SIS boundary. List the logic solvers, their engineering workstation, every network interface and every link to the control system, including the ones added for convenience during commissioning.
2. Check the key switches and the workstation. Where the controllers have a physical key, record its position; check that the engineering workstation has no second network card leading elsewhere.
3. Find or commission the SIS security risk assessment, and file it with the functional safety documentation so that the next revalidation sees it.
4. Add one line to the trip investigation form: “cyber cause ruled out by”, with a name from OT security.
5. Run a one-hour tabletop exercise with process safety, operations and OT security on an unexplained SIS trip, and write down who called whom.

Five common mistakes

• The SIS in the control zone. Sharing a zone with the basic process control system means sharing its exposure.
• A shared, dual-homed engineering workstation. One machine that programs both the SIS and the process controllers is a bridge over the last line of defence.
• The key left in program mode. A controller that accepts program changes at any time accepts them from anyone who reaches it.
• A trip investigation with no cyber question. A fault that looks mechanical is closed as mechanical unless someone is asked to rule out the other cause.
• Merging the two processes instead of connecting them. One team deciding alone, in either direction, is the failure the routing table exists to prevent.

Safety and security remain two disciplines with their own methods and experts. They share one asset, and keeping the words apart is what lets the two teams work on it together.

References

• IEC 61511-1:2016, Functional safety – Safety instrumented systems for the process industry sector – Part 1. webstore.iec.ch
• IEC 62443-3-2:2020, Security risk assessment for system design (ZCR 3.3, separate safety-related assets). webstore.iec.ch
• FBI Private Industry Notification 20220324-001, TRITON malware remains threat to global critical infrastructure industrial control systems, March 2022. ic3.gov
• US Department of the Treasury, Treasury sanctions Russian government research institution connected to the Triton malware, 23 October 2020. home.treasury.gov
• Mandiant, Attackers deploy new ICS attack framework “TRITON” and cause operational disruption to critical infrastructure, 14 December 2017. cloud.google.com
• US Department of Energy, CyOTE programme (Idaho National Laboratory), case study on the Triton malware attack, 30 June 2022. cyote.inl.gov