The benefits of implementing an Industrial Internet of Things (IIoT) strategy are indisputable. Cloud computing, big data, remote sensors and converged networks are continuing to help industrial facilities work smarter. However, in recent years it has become apparent that the cybersecurity of these environments has been somewhat of an afterthought. That is a big problem, especially when you consider the ramifications of an attacker taking remote control of Safety Instrumented Systems (SIS).
SIS are the last line of defense against critical failure in Industrial Control Systems (ICS). Their use is critical in hazardous environments, such as nuclear, chemical and oil and gas facilities. They are the failsafe devices which monitor process outputs looking for signs of danger and step in to prevent catastrophic incidents such as a reactor overheating, or a major explosion. If an attacker gains control of an SIS within one of these facilities, the impact may not only be decreased productivity and therefore monetary losses, but it could result in severe environmental damage, mass panic among a nation’s’ citizens, and the loss of human life.
Traditionally, heavy industry has relied on hardwired, manual failsafes that acted independently of the Basic Process Control System (BPCS). Today’s ICS environment, however, is increasingly reliant on networked systems for both safety and efficiency purposes. The reason for this is that deploying smart sensors and allowing remote access to BCPS can yield results through greater operational awareness and analytics, which is convenient and useful.
The problem is that the balance has shifted too far from security. The network-first approach to system design often leads to sharing some element of a network between SIS and BPCS, using standardised and open technologies. As BPCS operators and engineers often work in Windows or Linux environments, this creates the potential for an attacker to target common platforms and SIS, with potentially devastating consequences.
The attack surface isn’t limited to engineering workstations either. If the SIS isn’t fully segregated from other networks, every device becomes a risk. I’ve seen many examples of field devices deployed with no cybersecurity built in, on networks where SIS are no longer fully segmented. This threat is now a reality, which was made all the more clear in the closing months of 2017 when researchers discovered a specific case in which attackers infected a dedicated SIS workstation connected to a Schneider Electric Triconex controller.
The rise of TRITON
The malware, dubbed TRITON, was extremely capable. It was discovered after it triggered an emergency shutdown in an unnamed facility in Saudi Arabia, but the researchers believed it was being used to probe the network for something else. Its actual purpose is still unknown, it could have been looking for ways to take further control of the SIS or learning how to manipulate the system in order to carry out a major coordinated attack. It also may simply have been harvesting high-value data from networked sensors that the SIS was monitoring.
What is known about TRITON is that it gave attackers remote control of a critical SIS, and the fallout from its use could have been much worse than it was. The attacks design suggests that it was created with the kind of resources only available to nation-states, underlining just how important security for SIS is.
Make no mistake, while TRITON made use of zero-day issues in the Triconex operating system, this is not an issue which is isolated to a single brand of controller in a single organisation. There are a great many SISs that are not being deployed and operated with optimum cybersecurity in mind, and a great many industrial firms who do not know the extent to which their environment is at risk.
What should industry be doing now?
The solutions are straightforward: SIS controllers must be deployed with full network segregation from the BCPS environment wherever possible. Safety and control systems must be separated in order to avoid leaving a back door open in the last line of defense. The challenge is that it’s very hard to retrofit that kind of network segregation, it must be part of a system architecture and design. This segregation becomes much harder to achieve once a system has been deployed.
Secure by design must be our mantra in the networked world. If we leave an opportunity open for cyberattack, it’s a matter of when, not if, somebody finds it. Manufacturers must also share the responsibility for securing SIS products. There is no excuse for passing the buck to end customers. Attacks on SIS put us all at risk and we all need to ensure systems are secure by design from the outset.
Furthermore, there must be robust policies in place to maintain security. Significant investment needs to be made in training, not just around security for the SIS but, for all elements of the ICS. Staff must understand how to detect an attack, effectively react to attacks already underway and engage in continuous assessments against the latest risks.
For SIS specifically, proactive monitoring of SIS networks and the deployment of anomaly detection and whitelisting solutions are a must. Owners should also perform a full risk and vulnerability assessment to determine whether they share a network with BPCSs. Understanding where SIS sit on the network is paramount to understanding how to protect them, and equally important is identifying risks in downstream components, especially off-the-shelf sensors running proprietary operating systems.
This should not be a one-off exercise either. The need for ongoing, repeated network testing and monitoring for anomalous behavior – along with the tools to do so – is well defined in the IEC 62443 security standards. It’s important for operators to understand that even though they may be compliant, they must test, test and then test again. In our experience, SIS are regularly tested to ensure they meet functional safety requirements; the same regime should be applied to their network security.