TUG: Safety System Attack ‘Slow Burn’

Wednesday, October 17, 2018 @ 03:10 PM gHale

By Gregory Hale
Only three entities know all the facts about the Triton attack affecting the Schneider Electric Triconex safety system: The victim, the attacker and the forensics team, and that means most everyone else is working on speculation or unverified facts.

Schneider is a perfect case of showing how a company not only pays for a cyber attack on their equipment, but it is also paying in secondary, or “slow burn” factors as Gary Williams, cybersecurity services offer leader discussed during his session Tuesday at the Triconex User Group (TUG) conference in Galveston, TX.

RELATED STORIES
Lessons Learned One Year After Triton
Black Hat: Breaking Down Safety System Attack
Black Hat: Get to Root Cause
Forget Hyperbole: Stay True to Security Message

In this seminal event in the manufacturing automation sector, a Saudi Arabian gas refinery suffered a shutdown of its facility in August 2017 and the controllers of a targeted Schneider Triconex safety system failed safe.

During an initial investigation security professionals noticed there were some suspicious things going on and that is when they found malware. The safety instrumented system (SIS) engineering workstation was compromised and had the Triton (also called Trisis and HatMan) malware deployed on it. The distributed control system (DCS) was also compromised.

The attacker had the ability to manipulate the DCS while reprogramming the SIS controllers.

“This attack could have happened to anyone,” said Steve Elliott, senior director at Schneider Electric, who joined Williams in the talk.

In one part of the attack, it was learned the Tricon workstation comes with a memory protect mode so there is a switch on the front panel that allows you to protect the memory from being written to. One of the precursors to this attack is the fact the key switch has to be in program mode. In this case, the user had it in program mode.

Attack Forensics
When the incident occurred, the “perpetrator was working on code on the engineering workstation,” Williams said. In addition, this was a remote attack nowhere near Saudi Arabia, he added.

As the engineering workstation was a key factor in the attack, Williams said there were three forensic elements they had to do to learn more about the safety system incident:
1. Isolate
2. Identify
3. Mitigate

“When you arrive on the site, you don’t turn off the affected machine,” Williams said. “Remove the cables, but don’t turn it off.” Turning it off will remove important forensic information.

“How did we identify it? We looked at the workstation after we isolated it and we took an image of the workstation and took an image of a virgin system and compared,” Williams said.

They were then able to mitigate the issue after they found the differences between the two systems.

The owner pushed out an advisory out to all of the sites after the fact. Attack was against a target, not the safety system.

One thing Schneider does is when there is an issue or a fix to any system, they will send out an advisory talking about the vulnerability and the fix. Advisories had gone out about the affected Triconex system over the years. In this case, Elliott said five people at the victim site registered to receive the advisory, but four never logged in and one person did log in one month before the incident.

In an interesting side note, Schneider offered all users of the affected system, which they estimated to be in the thousands, to send it in and they would check them out free of charge. After the offer, 475 users sent in their system, and Schneider did not find one system affected.

More Questions
How long ago did the attack start? When did the malware end up injected into the system?

While no one knows those answers yet, what is known is two years before the August 7, 2017, cyber incident, the Saudi refinery underwent a major maintenance shut down. Over 25,000 contractors set foot in the refinery working on various projects.

The industry is beginning to wake up to the fact these attacks are happening. DCSes and safety systems are not immune. Attackers can and do have the ability to effectively take them over.

While this was a targeted attack and the victim was going to get hit no matter what, this type of attack could have been avoided, Elliott said.

“This is an industry challenge,” Elliott said. “This is applicable to all systems. We have to work together to defeat the attackers.”



Leave a Reply

You must be logged in to post a comment.