Ensuring the safety of their systems is a top priority for organizations operating within Industry 4.0. Anything from heavy-duty machinery in a smart factory to environmental sensors in an energy plant—all are potentially dangerous if they don’t function properly.
A Safety Instrumented System (SIS) consists of hardware and software controls which are used for critical process systems. They are typically the last line of defense against any sort of system malfunction. They are intended to detect dangerous conditions and to return processes to safe levels or shut them down all together.
In the summer of 2017, the SIS controllers at Saudi Arabian oil refineries were targeted by a sophisticated cyberattack, known as Triton. The attackers targeted the Triconex industrial safety technology by Schneider Electric and they were able to halt operations at at least one facility. In a worst case scenario, the attack could have led to the release of toxic hydrogen sulfide gas or caused explosions, putting many lives at risk both in the facilities, as well as in the surrounding areas.
Triton is often compared to the 2009 Stuxnet malware, since both attacks are infamous for targeting industrial facilities. However, Triton differs from Stuxnet in that it was the first attack that was engineered to target critical safety systems with the intent of putting lives at risk.
How the Triton attack was executed
The attackers behind Triton exploited the most common type of software vulnerability, a buffer overflow, to install a Remote Access Trojan (RAT). With the RAT installed, they exploited a zero-day privilege-escalation vulnerability in Schneider Electrics’s Triconex SIS firmware, which elevated the malware code to obtain read, write, and execute privileges. The attackers had then planned to inject further code to manipulate the speed of the components within the system and cause a dangerous explosion.
Luckily, an error in the attacker’s code meant it was not successful and no loss of life or serious damage was done. They were only able to temporarily shut down operations at one facility.
The danger of Triton lies in its potential
Although the attack was unable to achieve its desired result, the implications of Triton are still extremely concerning. When it comes to the safety and security of human lives, we can’t rely on the bad guys to make a mistake.
Attacks on industrial systems are nothing new, but the targeting and attempted disabling of safety systems designed to protect lives had never been the subject of a cyberattack before. It is for this reason that Triton has been described as the world’s most murderous malware.
SIS controllers are used in many different critical process systems, across industries—from oil and gas refineries to electrical grids to transport networks, like high-speed rail systems. The corruption or manipulation of SIS controllers in any of these situations presents a high potential for physical damage and a serious risk to civilian safety.
Although the attackers were unsuccessful in 2017, the malware is still very much active and poses a serious threat to our critical systems. There is even evidence suggesting that the Triton malware has begun to probe the networks of at least 20 US-based power grids. While this does not necessarily indicate an attack is imminent, it proves that the group behind Triton is not only still active, but potentially planning another attack.
Protecting SIS controllers with CoreGuard
When an attack, like Triton, exploits previously unknown vulnerabilities, stopping it requires a cybersecurity approach that is future-proof and can protect against zero-day threats. This is achieved by employing defense mechanisms that protect against the classes of attack, not just known attacks.
Dover’s CoreGuard technology is that solution—it is specifically designed to protect against the most common categories of vulnerabilities, whether known or known.
The Triton attack started with a buffer overflow, just as with the Stuxnet attack of 2009. CoreGuard’s Heap micropolicy, included in our base set, would have stopped it in its tracks because the micropolicy stops 100% of buffer overflow attacks.
For the sake of argument, let’s say the attackers were able to gain access to the system by some other means (not a buffer overflow). In order to take control of the SIS controllers, they then needed to exploit a zero-day vulnerability in the controller firmware to grant read, write, and execute privileges to the malware code. In a defense-in-depth approach, CoreGuard’s RWX micropolicy, also included in the base set, would have stopped the attackers in their tracks again.
The RWX micropolicy uses CoreGuard to provide the functionality of a hardware Memory Protection Unit, but at a much more granular level. Unlike an MPU that can only assign permission and memory attributes to a predefined set of memory regions, the RWX micropolicy can label each word in memory with metadata that indicates whether it is readable, writable, and/or executable. The RWX micropolicy is able to block attacks that try to manipulate data in a way they shouldn’t, just as the Triton attackers did in 2017.
To learn more about the different types of software vulnerabilities that CoreGuard can protect against, request a copy of our Cybersecurity Scorecard here.