Advice from the Triton cybersecurity incident

Cybersecurity incident: Human errors enabled it, but the Triconex safety controller shut down the plant as designed, say experts with Schneider Electric and ARC Advisory Group. But it’s still a call to action for industry. Have you implemented changes since then?

By Mark T. Hoske, CFE Media April 18, 2018

Breach of an industrial, triple-redundant safety controller should dispel any thought hackers might not care about industrial facilities or that process controls are low-risk cybersecurity targets. All facilities, even if already heeding advice from Schneider Electric and ARC Advisory Group, need to have a response plan in place. The Aug. 4, 2017, cyberattack on a on a Triconex safety system that included the first instance of process safety system-specific malware, dubbed TRITON, was described in a media and analyst lunch on Feb. 13. That triple-redundant safety controller brand is part of the Schneider Electric EcoStruxure Triconex safety instrumented system (SIS). A summary of advice from each expert follows. 

Collaborative cybersecurity effort

The industry has a problem; hackers can reach instrumentation. Peter G. Martin, vice president, innovation, Schneider Electric, said a cybersecurity incident that resulted in attackers injecting malware into a safety controller is a call to action for the industry because it heralds a new geopolitical climate where malicious actors have specialized knowledge, as well as unlimited resources, to carry out their cyberattacks. These attacks can reach the instruments in a control system, especially if organizations are not compliant with industry standards, best practices and cybersecurity procedures. That means industry end users, standards bodies, vendors, and government agencies need to come together to combat the threat. The industry shouldn’t think there’s no problem because the equipment performed as it was supposed to by safely shutting down the targeted plant.

There is a problem because cybersecurity best practices were not followed; more work is needed in collaboration with end users, vendors, and government to lower the risk of other cybersecurity incidents from happening. 

Cybersecurity wake-up call

Multiple cybersecurity lapses allowed a safety controller breach. Gary Williams, senior director, technology, cybersecurity and communications, Schneider Electric, said this is an industry call to action. A Triconex controller model 3008, brought to market in 2001 and installed as part of a large automation project in 2007, was affected by a security breach. When the controller picked up an anomaly in the malware the attackers injected into its code, the controller reacted as it was intended: It safely brought the plant to a safe state via a shutdown on Aug. 4, 2017.

Upon being notified of the shutdown, Schneider Electric worked closely with the end user, independent cybersecurity organizations and the U.S. Department of Homeland Security/ICS-CERT and others to investigate the incident. The evidence they gathered indicates multiple security lapses allowed the breach to occur.

A remote attacker, through a corporate system, logged onto a machine and was playing with code. An individual made an error not specific to the controller and exposed it to remote access through Microsoft XP [no longer supported] software. Practices outlined in controller documentation, and in the IEC 62443 series of standards on industrial automation and control systems (IACS) from the ISA99 Industrial Automation and Control Systems Security committee, if followed, would have prevented the breach.

Don’t panic; assess risks

Reconsider cybersecurity processes, procedures, and training. Larry O’Brien, vice president research for process automation, ARC Advisory Group, said the industry shouldn’t panic, but it should reconsider best practices regarding processes, procedures, and people. There are ways to execute a response to and defend against a systemic, multiphase attack.

In this same incident, the attack(s) breached another vendor’s distributed control system (DCS); so while the shutdown was initiated as designed, it’s better not to suffer a breach and shut down a process.

Other human errors on site, including leaving the controller’s keyswitch in program mode while it was in operation and leaving the controller cabinets unlocked, added significant risk for a cybersecurity attack. To lower the risks of such incidents, customers should continue to apply cybersecurity best practices across their operations, as well as always implement the instructions vendors provide within their systems documentation. For example, a recommended practice is to dedicate a laptop for use with the DCS and not let anyone else or anything connect to it.

Schneider Electric’s open and helpful response to this incident has been applauded and should be a blueprint for other vendors’ responses because this won’t be the last incident.

What’s the attraction for hackers? By reprograming the DCS and the safety system, attackers can push the plant into an unsafe state without those at the plant and the safety system realizing it. That means if an incident occurred, the expected result, i.e., the safety system shutting down the plant, wouldn’t happen. Idaho National Labs demonstrated such a DCS spoofing event at least 10 years ago. 

Program mode, cybersecurity standards

Have any of your controllers been left in program mode?

Eric Cosman, contributing consultant, ARC Advisory Group and co-chair of ISA99 Industrial Automation and Control Systems Security committee, said the Triton attack was not unprecedented. He advised we shouldn’t underestimate the hazards posed by human denial. Cosman, who worked for Dow Chemical most of his career, said leaving a controller key in program position is inexcusable. The ISA99 committee produced the IEC 62443, which addresses people, processes, and technologies. Risk assessment is part of that. End users don’t have time to read a 1,000-page standard; practices and case studies are available along with sanitized examples of actual incidents. 

Frequent cybersecurity education

Cybersecurity isn’t a destination; it’s a journey and a continuing process. Gary Freburger, president, process automation, Schneider Electric, said cybersecurity, like safety, isn’t something that can be done and finished; it’s a continuing process. This is counter-intuitive to the view not to touch a system if it’s doing what it’s supposed to be doing.

Breaches will happen, and cybersecurity is everyone’s job, at individual and organizational levels with a commitment to industry, standards, and transparency. Three best practices follow.

1. Commit to educate and address people, processes, and technologies with a relentless drive to publish and standardize best practices and share information.

2. Use common standards across all equipment and across multiple providers, with feedback and guidance from those involved.

3. Ensure collaboration through transparency. Don’t say or believe anything is secure. A lot of people are trying to get into these systems. Everyone needs to respond correctly knowing what was done before, to know how to correct it.

In this case, Freburger said Schneider Electric experts were on site within four hours of being notified. End users struggle in cybersecurity incidents, he said, and vendors can use their expertise to help.

Mark T. Hoske is content manager, Control Engineering, CFE Media,

KEYWORDS Cybersecurity, process safety

Hackers can reach instrumentation.

Outdated software is a cybersecurity risk.

Reconsider cybersecurity training.

Consider this

How did people in your company improve cybersecurity today? 

ONLINE extra

Schneider Electric offers a cybersecurity portal

ARC Advisory Group has a Cybersecurity Advisory Service.

Connect to related Control Engineering cybersecurity coverage in the articles below and on a dedicated cybersecurity page. 

Live hacking into your process (in 2005)