Last year, a mysterious cyberattacker group launched a malware campaign, which has since come to be known as Triton or Trisis, to sabotage the safety shutdown system at a facility in the Middle East. The Triton malware, discovered by cybersecurity firm Dragos in mid-November 2017, could have caused catastrophic damage — potentially causing loss of life and widescale pollution. The malware, however, didn’t achieve its objective, as it inadvertently triggered the Triconex safety system’s emergency system shutdown procedure it sought to suppress, helping lead to its discovery.
Triton thus became a tangible warning of the cybersecurity threats facing modern industrial organizations. The hacker collective behind the attack, which Dragos dubs Xenotime, will likely continue “to cause a potential, future disruptive — or even destructive — event,” according to a Dragos article. The cyber firm states it has “moderate confidence” in this possibility, while also noting that the attack provides other cybercriminals with a blueprint for targeting safety instrumented systems at large.
While some manufacturers whose equipment has been breached by hackers have dismissed, downplayed or even sought to hide such attacks from the public, Schneider Electric took an opposite approach. “We knew there was a level of transparency that was going to be required,” said Andrew Kling, the director of cybersecurity and system architecture at the company. “Once the true nature of the attack was understood, we realized the unique nature of this and the seriousness of this kind of attack. We definitely knew that this was going to be a call to action for the entire industry,” said Kling, who recently penned an article titled One Year After Triton: Building Ongoing, Industry-Wide Cyber Resilience.
[IoT Security Summit is the conference where you learn to secure the full IoT stack, from cloud to the edge to hardware. Get your ticket now.]
What sets Triton apart from most malware is that it is one of a handful of malware types specifically targeting industrial control systems, and the first known malware targeting safety instrumented systems. “This wasn’t just a one-time thing where an older legacy version of a product was attacked but this was a kind of attack where somebody felt that attacking a safety system was necessary to achieve their goal,” Kling said. “And trying to bury our head in the sand just simply wasn’t going to be an acceptable behavior.”
To what extent do you think people in the industry are aware of Triton malware and the broader threat of attacks on industrial safety systems?
Andrew Kling: That's a great question. As a cybersecurity professional, I think it should be 100 percent and absolute. Everybody should be sitting up immediately and taking action to address the situation.
We’ve been running a malware detection service for our customers of the Triconex product line. We know how many how many of these Triconex safety controllers we’ve produced. We know how to detect if this malware is present in these devices. And we’ve offered this service to all of our customers. We've had a lot of customers now engage with us to detect if malware is present in their devices, and there are no additional indicators of compromise with any other sites. But we will continue to run the program because we believe this is an important service for our customers. I would point out that it’s also unique. As I know, this is the first service to detect malware in a safety device like this directly.
What role do you see Schneider Electric playing in helping educate the industry about this threat?
Kling: This is a call to action, not just to our customers to stand up and say: “Hey, we have to pay attention to our safety system as much as we pay attention to our process control systems and business systems.” But it’s a call to action to service providers, network providers and to OEMs like ourselves.
I’m on standards committees where I interact with my peers at other companies and they agree this is something that is relevant for them. Schneider Electric was targeted because we happen to be the safety system that was on-site when this customer was attacked, but it could have just as easily been one of our competitors. They appreciate the fact that we’re transparent and we’re explaining how the attack took place and what skills they used against this particular customer in this attack.
How much do we know at this point about the attackers behind the attack?
Kling: You probably know as much as I do.
As far as attribution goes, we know very little about who it can be. There’s been lots of speculation and press about nation states. Recently, there’s been one malware company that has speculated that perhaps the skills are less than was originally thought. While I don’t know who the attackers are, I do know there were certain skills that were required that were non-trivial. The attacker would have to understand how a safety system like this works and the processor and protocols involved. In this attack, the distributed control system was compromised as was the process control system. These are all skills that you don’t find in a common way. Somebody had to have significant motivation to acquire these skills to carry out this attack.
So it’s likely that the attackers had narrow experience with this kind of machinery?
Yes, or they had broad intelligence and were able to adapt quickly.
This is speculation, but it’s likely they had some equipment. But their malware had multiple bugs in it — bugs by the way that we had to fix to actually figure out what the malware was supposed to do. When one of those bugs was encountered, it tripped the safety system. The system did what it was supposed to do and was an indicator that they maybe didn't have as much equipment as we might have thought they would have had. And they were using the site to develop the malware
We know that the malware was a RAT installed into memory. They had read-write-execute capabilities, but we never actually recovered what final payload would be to install into that RAT?
What advice do you have for industrial organizations that are worried about cyberrisk to their facilities, but uncertain about what their top priorities should be in defending them?
That’s a question by the way that I’ve been asked by governments around the world to customers to now press.
And I have an answer: As a member of the ISA99 working group, we produce the IEC 62443 cybersecurity standard. This is a family of parts that explains just what a secure process control system is: from the components to the network to the system to the delivery of the system to the maintenance of the system. So if you are a customer who is trying to say, “I’m putting a bid out to purchase a new safety system or a new process control system for my plant,” you should start by saying in their bids specification. Your product should be certified to this standard. There are hundreds of man-years from professionals around the planet that have been poured into this standard to define what security means for the industrial automation control systems space. You should leverage all the work that’s been done there and look for products that comply with that standard. They should look for products to comply with it and systems that comply with it and delivery organizations that comply with it. And this is how they can they can avoid having to become Ph.D.s in cybersecurity to understand the field. Instead, they can leverage the Ph.D.s who have poured their hearts and souls into the standard.
There are also documents the U.S. government is producing out of NCCIC/ICS-CERT. We collaborate with those people on standards. The OT cybersecurity community is a tightknit community. We know each other and work with each other on a regular basis
