Securing Mr. Roboto: Cybersecurity in ICS Environments
The February 5, 2021 attack on the Oldsmar, Florida water supply brought the cybersecurity of industrial control systems (ICS) to the front of national attention in the United States. As is often the case with cyberattacks, the Oldsmar attack neither exploited a novel vulnerability nor did it expose a new risk to cybersecurity professionals. The attack did make more concrete for many Americans a type of cyberattack that may be difficult to understand or that may appear to be relegated to science fiction. Ultimately, the Oldsmar attack was unsuccessful in its attempt to poison the Oldsmar water supply and will likely push forward efforts to buttress cybersecurity controls in critical industrial controls environments, but it exposed just how ill-prepared these critical systems remain despite existing efforts to secure them and how much more work remains before cybersecurity matures to adequate levels in critical ICS environments. This post summarizes the events of the Oldsmar attack, discusses cybersecurity-related trends in ICS technologies, and recommends strategies to build cybersecurity maturity in critical ICS environments.
According to FBI Private Industry Notification (PIN) 20210209-001, the Oldsmar attacker gained access to the water supply’s ICS environment through the Team Viewer software installed on a Windows 7 workstation. The FBI determined that the attacker likely exploited the obsolete Windows 7 software to gain local access, then accessed the Team Viewer software to access ICS devices on the network. With access to ICS devices, the attacker was able to raise the level of sodium hydroxide to be dumped into the water supply by 100 times (Gooden, 2021; Krebs, 2021). The water supply was not ultimately impacted by this attack because it was discovered and stopped by an alert operator at the plant (Krebs, 2021; Fixler & Montgomery, 2021 (The Hill). Despite having a computer that connected both to the ICS environment and the Internet without a firewall, running an obsolete operating system on that computer, and implementing very poor password practices on that computer’s Team Viewer software, the attack did not succeed because of (albeit very thin) layered defenses – or in cybersecurity jargon, defense in depth.
The network configuration described in Oldsmar is representative of an overall trend toward interconnection of IT and ICS, or operational technology (OT), systems and the evolution of OT systems controllers to more standard, commercial-off-the-shelf (COTS) systems. The Oldsmar attack illustrates some of the ways in which these trends can be harmful to security. By opening a closed ICS system by connecting it to other intranets or the Internet, administrators risk exposing ICS networks to a variety of new threats. Though successful exploitation of vulnerabilities in IT networks can build into a “crisis” situation, few such crises would rise to the level of killing thousands of people, which could have very plausibly resulted had the Oldsmar attack succeeded. Unpatched software is a significant source of vulnerabilities in any network and amplifies risks of network and device exploitation when unpatched systems are exposed to other intranets and the Internet. When COTS systems are left unpatched and connected to the Internet, the risk of malicious compromise is high. In this way, the trending transition away from proprietary control languages and technologies increases risk of compromise because attackers tend to best understand the most common Windows and Linux operating systems. The STUXNET attack designed to disable Iranian nuclear centrifuges illustrates this point. Though successful, the attackers needed to create highly specialized code that exploited Siemens Step 7 software. These exploits were relatively expensive to develop and pointed to a well-resourced attacker. Conversely, attacks on an unpatched Windows 7 system can be readily downloaded from the Internet and implemented by someone with very little knowledge of computing or cybersecurity.
Trends toward increasing interconnectivity and increasing use of COTS technologies also provide opportunities for increased security. By connecting ICS systems to IT systems, cybersecurity practitioners have increased access to monitor and support ICS networks. If ICS systems are connected to well-monitored IT networks, the ICS network can benefit from additional eyes on it. The additional eyes, especially if trained in cybersecurity, may be able to detect problems on the ICS network more quickly and may also be able to understand certain causes of ICS problems in more depth than plant employees. Specialized technical support, often vital to contemporary ICS devices, is more readily available when vendors can access systems remotely via the Internet. Remote support was the reason given for the remote access configuration exploited in Oldsmar. When properly designed and implemented, interconnectivity can provide significant benefits to an ICS network while minimizing cybersecurity risk. One imperative to proper implementation of interconnectivity is the provisioning of security-prioritized systems on the ICS network. Use of COTS systems for ICS control where the COTS system can automate and otherwise simplify security updates to firmware and operating software increase the security of those devices. However, where functions of devices controlled by COTS systems require specialized functions not native to the COTS system, vendors make modifications to the COTS systems in support of the controlled device(s) then deny local network administrators the access necessary to secure the modified COTS system on the network. Doing so mitigates the security advantages of using COTS software over proprietary software as the COTS system has been made a proprietary software. The security of interconnected, contemporary ICS networks depends on the same principles of cybersecurity that we rely on to secure IT networks, even if principles are implemented somewhat differently.
The ground-level recommendation of this post is to guide cybersecurity efforts on ICS networks using the same concepts and principles that you’ve applied to your IT network. If the security posture of your IT network keeps you up at night, solve that problem before you hook in your ICS network. If your IT network is well secured, you can consider allowing some connectivity between and among ICS and IT networks – but start at the beginning. Design secure connectivity when making these connections. Consider security gaps. NIST Special Publication 800-82, “Guide to Industrial Control Systems (ICS) Security” will help frame key differences between securing ICS and IT networks. Build security into devices and network connections across your ICS network and monitor those networks in real-time. Where failures of ICS devices, malicious or otherwise, could injure or kill people or cause large-scale damage, you can’t afford failure to go unnoticed. Monitoring should be performed manually by personnel at the plant, as well as through technology. Finally, create disaster recovery plans that incorporate ICS device or network failures. Test those plans regularly and ensure that manual backup controls are in place where an ICS failure could cause “disaster”. Though interconnectedness and more standardized COTS infrastructure in ICS networks can bring significant benefits to operations, success depends on a higher level of maturity of your cybersecurity posture because of the potential ramifications of failure. In ICS networks, your success depends more than ever on leading with security.