Of Safety Systems and ICS Cybersecurity

This is an excerpt from the ARC Insight article on TRITON/TRISIS/HatMan malware and its impact on ICS cybersecurity.  ARC clients can get access to the full document here.  

New Malware Targets Process Safety Systems: What Does It Mean for ICS Cybersecurity?

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.  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.

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 utility infrastructure. On the positive side, the incident opened a whole new dimension and level of discussion around cybersecurity for SCADA and industrial control systems.

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. Here are some key thoughts regarding this new threat:

• Don't panic! This is a wake-up call.  Not the end of the world.
• This was part of a systemic and multiphase attack. A supporting attack on the ICS cyber kill chain. 
• Because of the systemic and multiphase nature (DCS was also involved), this required considerable resources and was most likely a nation-state sponsored attack. 
• The intent was not merely to trip the safety system, the intent was to reprogram safety system so it would not do its job when called upon to do so. Fortunately, the safety system did its job and shut the plant down safely.
• Many process and procedural errors occurred in the plant relative to the safety system may or may not have contributed to the attack. For example, the Triconex key switch was left in "Program" mode during plant operation.  This highlights the fact that users need to do more to secure and lock down their ICS infrastructure.  
• The Schneider response was largely applauded by the industry for being transparent, quick, and above board. 
• This incident has interesting implications for integrated control and safety systems, in that we need to rethink integrating control and safety systems.  That's an overly simplistic statement, but current safety system standards like IEC 61511 and ISA 84 allow for integration of control and process safety systems.  In light of this attack, we need to rethink how we integrate these systems and what we can do to secure them if they are already integrated. 
• This is not a new concept. Proof of concept for a safety system malware attack happened 10 years ago and was demonstrated by INL. 
• This may have been the first attack in the wild, but it won't be the last and will not be limited only to Triconex. The tradecraft of this attack can be replicated in other systems. 
• The Schneider response can provide elements of a  blueprint for future responses.  Users must make sure their procedures, work processes and procedures are solid, and they're safe.