What Happens When Malware Targets Process Safety Systems?
In December 2017 it became clear that process safety systems are not immune to cyber attacks. That’s when we learned that a new form of malware (dubbed Trisis, Triton, or HatMan, depending on who you ask) had made its way into a Triconex safety controller at an oil and gas installation in the Middle East.
Since the incident became public, it has become increasingly clear that the ramifications of this breach extend far beyond a single customer site or a single vendor. In today’s increasingly connected world, concerns about the possibility of attacks on industrial systems are escalating. This issue extends outside the industrial sector to also affect smart cities and the power and utilities infrastructure. On the positive side, the incident opened a whole new dimension and level of discussion around cyber security for SCADA and industrial control systems.
[callToAction ]
The industry has applauded Schneider Electric, the supplier of the affected system in this case, for its transparent and proactive approach in responding to this threat.
Cyber-security vendors like FireEye and Dragos were also helpful in sharing information about Triton with the rest of the industrial and cyber-security community. The incident underscores the importance of simple procedures and management of change practices that can be put into place, typically with very little investment, to avoid this kind of attack in the future.
However, it’s hard to be dismissive of this new form of malware and how it might be used to affect industrial plants. The attack’s sophistication and the attack vector demonstrate that the incident is not unique to Triconex controllers; and could be replicated on any process safety system.
A key step that a threat actor might take would be to reprogram a safety system to no longer respond to an abnormal situation. This would have the potential to result in large-scale damage and possible loss of life. The global industrial process and manufacturing industry must heed this as a warning.
The Attack Unfolds
We know little about the installation, other than it was an end user presumably in the hydrocarbon processing industry located somewhere in the Middle East. The end user involved was the target of a highly sophisticated and prolonged cyber-attack that resulted in a safe plant shut-down in August 2017. While the end user’s ten-year-old safety controller was breached, the Tricon safety system detected an anomaly and behaved as it was supposed to; taking the plant to a safe state via a shutdown.
A potentially serious incident was thus avoided and Schneider Electric responded immediately to the end user’s request for assistance. Since then, all evidence gathered by investigators from Schneider Electric, FireEye (a cyber-security forensics firm), the US Department of Homeland Security, FBI, and other US agencies indicates the breach was enabled through multiple security lapses. This highlights the need for the industry to come together to enable a stronger security culture.
On December 14, following the distribution of a customer advisory from Schneider Electric, FireEye made its Triton report available to the public. FireEye provided a good summary of the attack in a recent blog post, which stated, “The attacker gained remote access to an SIS engineering work-station and deployed the Triton attack framework to reprogram the SIS controllers. During the incident, an SIS controller entered a failed-safe state, which automatically shut down the industrial process and prompted the asset owner to initiate an investigation.”
The attacker gained access to the safety system through the distributed control system (DCS) that was in some manner integrated with the process safety system. Once inside the safety system engineering workstation, the attacker tried to reconfigure the system. This ultimately caused a trip and activated the safety system, initiating a safe shutdown as it was designed to do. It seems clear from the reports from both FireEye and Dragos that this shutdown was accidental on the part of the attacker, who was really trying to reconfigure the safety system logic so the system would respond improperly in the event of an abnormal plant situation.
A Targeted Attack Most Likely from a Nation State
Triton was a highly targeted attack so, in this manner, resembled the Stuxnet attack on the Iranian nuclear centrifuges. Schneider Electric, FireEye, the US Department of Homeland Security, and others conducted a thorough investigation. This revealed that the attacker(s) gained specific knowledge of the safety system installation in order to conduct this attack. Evidence indicates that the attacker(s) exploited multiple security lapses to gain remote connectivity to the safety controller, from which they initiated the attack.
According to cyber-security vendor Dragos, which was also involved in addressing the attack, Triton was really a supporting attack on the ICS cyber security kill chain, which serves as part of a larger mosaic of attacks and intrusions to form a coordinated whole. In other words, this attack was part of a larger scheme. You can download the highly informative Dragos white paper on the attack here. In SANS Institute’s Mike Assante’s blog post, he points to Trisis as being in the “Supporting Attack” phase of stage 2 in the kill chain.
Why Process Safety Systems?
Why attack a process safety system? The primary function of the process safety system is to place the plant or process in a safe state or shut it down if necessary in the event of a process upset. As Mike Assante asserts in his SANS ICS blog post recently, the only two reasons to attack a process safety system would be to initiate a trip, thereby shutting the plant down, or deny the ability of the safety system to shut the process down properly in the event of a process upset or abnormal situation.
However, it’s also pretty easy to cause a plant shutdown by going into the DCS or process controllers, and we already have several documented cases of this happening in various forms, from Stuxnet to Crashoverride. So, if it’s easier to initiate a shutdown via the DCS, why go to all the trouble to attack the safety system? The answer seems more likely to deny the ability of the plant or process to shut down safely.
The safety system is the last line of defense in the world of industrial control systems to safely shut down the process. Deny the capability of a safe shutdown and it makes it possible to wreak all kinds of havoc in the physical world, put human lives in danger, and cause significant environmental and economic damage.
What’s the Immediate Risk?
While there’s no need to panic, this threat should be taken seriously.
TRITON malware should be viewed as one element in the cyber kill chain and, in this case, it seems to be one aspect of a more coordinated attack. Unlike a virus or worm (like Stuxnet) that could be easily spread and propagated, the malware could only be successfully loaded if several conditions are present. TRITON does resemble Stuxnet in that it too was highly targeted not only at a specific facility, but to a specific model of a controller. And like Stuxnet, the TRITON attack was most likely conducted by a source with considerable resources to gather information about this specific installation and launch a highly specialized attack. This points to the possibility of a nation state-sponsored attack.
Cyber-security suppliers like Dragos use the term “tradecraft” to describe the common behaviors that attackers use to cause damage. The fact that the Triton/Trisis “tradecraft” could now potentially be used by others with nefarious intentions to replicate this kind of attack in the future on any process safety system is of extreme concern. If you know these behaviors, you can anticipate what they will do next based upon what you have seen in previous attacks. As Dragos said in its white paper about Trisis, “The tradecraft displayed is now available as a blueprint to other adversaries looking to target SIS and represents an escalation in the type of attacks seen to date as it is specifically designed to target the safety function of the process.” Some tradecraft is common across most attackers, while other actions may be unique to specific attackers. The kill chain describes general trade-craft steps.
TRITON Highlights Need for Better Management of Change and Procedure Management
The Triconex system in question had a physical key that must be switched to “program” mode to allow any programming to be performed. While this should provide one level of protection, in this case, the key switch was left in program mode during plant operation. This highlights the change management problems faced by process automation end users. Under no circumstances should this key have been set to program mode during plant operation. Adequate management of change measures should have been in place to alert appropriate personnel about this problem. In this case, while it’s unclear if the physical key switch alone could have prevented the attack, it appears very likely.
Regardless, this highlights the role of appropriate procedures and work processes in cyber security and process safety. It’s not just a technology issue. An operator probably should have been alerted to the fact that the key switch was in program mode via the safety system HMI. The engineering workstation should not have been connected to the safety system during plant operations.
A key recommendation in the Dragos white paper is for safety system engineering workstations to be isolated in locked cabinets and only connected to the safety network. That white paper also recommends that all methods of mobile data exchange such as USB sticks, CD drives, and so forth should not be allowed on workstations that reside on or interface with the safety network. This is an industry best practice that ARC strongly supports. Laptops used in safety system applications should also be dedicated to that purpose with USB ports locked down, no CD drives, etc.
Revisiting Control and Safety System Architectures
Triton/Trisis represents a wakeup call for industry. In the face of increasingly bold, innovative attacks, perpetrated by malicious actors who have unlimited time, resources and funding, every vendor, end user, third-party provider and systems integrator needs to take part in open conversations and drive new approaches that allow installed and new technology to combat the highest level cyber-attacks.
End users in the process industries need to tighten up their industrial control system (ICS) cyber-security practices, policies, and strategies. Simple steps like locking down the safety system IT infrastructure, key switches, and management of change (MOC) procedures are important, but architecture should also be a consideration.
The trend toward increasing the level of integration between process control systems and process safety systems has really gained traction in the past decade. In many cases, the process automation system and process safety system reside on a common network, which is currently allowed under the existing safety standards, such as IEC 61511 and ISA 84. Considering TRITON, both Dragos and FireEye are recommending that process safety systems be deployed on isolated networks separate from the process control system. FireEye advocates using a unidirectional gateway if communication between the DCS and SIS is required.
Based on these third-party recommendations, it appears obvious that each end user organization must carefully evaluate the criticality of their respective processes; the potential ramifications of safety system security breaches to people, assets, and the environment; and their respective tolerance for risk to determine the appropriate architectures for their individual plants. These could all vary to a significant degree from plant to plant.
Larry O'Brien, Vice President, ARC Advisory Group, joined ARC in 1993 as a junior analyst covering the field device market. Since then, he has covered distributed control systems, fieldbus, automation services, process safety systems, SCADA systems, collaborative process automation systems, and -- more recently -- industrial cybersecurity and smart cities. Larry has served on several ISA committees and a three-year stint as global marketing manager for the Fieldbus Foundation. You can email him at [email protected].
Eric Cosman, Contributing Consultant, ARC Advisory Group, has over 35 years of experience developing, delivering, managing, and supporting operations information technology solutions in the process industries. During his career, Eric's assignments and responsibilities have included process automation systems development, communications network design, functional and technical architecture design, and technology lifecycle management. He recently retired as an Operations IT Consulting Engineer with the Dow Chemical Company. You can email him at [email protected].
