Ask virtually any security expert to name the most nightmarish scenario related to the manifestation of malware, and the answer will be simple: An attack that invokes life-or-death consequences.
The good news is that for all the dire proclamations of "Cyber Pearl Harbors" or "Digital 9/11s," virtually no fatalities - although it is impossible to know for sure - have been directly attributable to a computer-based attack. Yet such an outcome is imminent, say many officials, and this prospect continues to rattle security professionals, who are well versed in the capabilities of their adversaries.
The most likely expression of such an attack would be a disruption to the computer systems or medical devices belonging to a health care organization, like a hospital. Unable to adequately continue their normal operations, patients could suffer. This possibility came into full focus during the WannaCry ransomware attacks, which affected health facilities in the U.K.. While the motivation of the outbreak appears to have been profit and extortion driven, human beings easily could have been collateral damage.
Generally, though, when officials raise the macabre specter of death and destruction caused by cyber, they are referring to the takedown of critical infrastructure essential to our ability to survive, such as electric grids, water supply or treatment facilities and oil-and-gas pipelines - and also extending to transportation and financial networks. Just recently, we learned of an advanced piece of malware, dubbed "Crash Override," which deliberately caused a power outage during the dead of winter in Ukraine. Experts were startled by the custom-built malware's ingenuity. .
The malware's code targeted supervisory control and data acquisition (SCADA) systems, which are industrial control systems that monitor industrial processes and collect operating data that allows utilities to run more reliably and efficiently. But for cost and convenience reasons, many of these legacy systems have been connected to less secure networks that are not isolated from the internet, driving the risk of an intrusion significantly higher.
Critical infrastructure has largely avoided the ire of hackers for one big reason: Most hackers aren't out to lay waste to humanity - they just want to make money. But the outlook changes when you consider the motivations of nation-state attackers, who may view critical infrastructure as a perfectly reasonable target toward their nationalistic end goals.
This concern here with SCADA systems is nothing new. In fact, the 10th anniversary just passed of a simulated hacker attack, known as Aurora, that was conducted at Idaho National Laboratory and resulted in a turbine exploding. Many credited the experiment with providing a much-needed wake-up call to an industry that was behind the times in terms of budgeting, leadership and knowledge around the cybersecurity risks they face.
But as is typical with security, progress is not linear. While a more-recent simulated attack on the U.S. power grid revealed progress - and government agencies have offered prescriptive guidance for shoring up defenses - concern abounds. Control system vulnerabilities and attempted intrusions have substantially increased in recent years, and SCADA vendors have been slow to patch deficiencies. And some experts fear the worst: that these systems have already been seeded with malware that is lying in wait, awaiting remote commands to activate.
The recently released 2017 Trustwave Global Security Report devoted a section to documenting the risks posed by SCADA systems and offering up eight recommendations. Sachin Deodhar, part of the elite SpiderLabs team at Trustwave and author of the section, is here to re-share those recommendations and provide expanded and exclusive technical insight on how you can help accomplish them.
1) Assess Existing Systems
This is akin to performing a "gap" assessment of your traditional network. In this case, however, there are some critical differences: The infrastructure to be assessed comprises of systems, networks, and specialized components clearly demarcated into three zones: corporate/management network, control network, and remote field network (also known as a physical process network).
While the corporate/management network (and associated controls/security practices) look similar to the networks we are used to evaluating in non-SCADA assessments, the remaining two zones - control and remote field networks - are strikingly different in the sense that they are comprised of specialized equipment, use specialized protocols for communication and are vulnerable to attacks that are similar but not the same as faced by non-SCADA networks.
As such, specialized skills are required for addressing threats to SCADA networks and assessment of the current state of such networks.
2) Document Policies and Procedures
We would expect security policy framework to be similar to non-SCADA environments, with some differences.
The threat perception associated with attacks on SCADA networks is often higher in comparison to non-SCADA environments because cyberattacks on SCADA systems have the potential to have real direct/indirect physical impact on life and property, in contrast to conventional cyberattacks that typically target money or data with little impact on life and physical property/infrastructure (e.g., Stuxnet versus conventional financial cybercrime).
In addition, procedures for protecting infrastructure, data and communication links will be different, as SCADA systems use proprietary protocols TCPIP or serial, RF/Wi-Fi/wireline) for communication; specialized equipment like programmable logic controllers (PLCs), A/D converters and data acquisition and control (DAC) for analog-to-digital conversions; and transducers and actuators for sensing and enacting control inputs. These all require a different approach to hardening and protection.
3) Train Staff and Contractors
Some elements of SCADA security training are similar to what is imparted to people engaged in using, managing and protecting conventional corporate network environments. However, some parts of training for staff and contractors working in a SCADA environment are much different. The differences arise from:
- The specialized nature of equipment.
- Use of proprietary protocols for communication/authentication.
- Need for functional training in SCADA process control.
- Lower tolerances to security threats and the need for more pervasive monitoring of suspicious activity and threats.
- Need for rapid response.
- SCADA environments often need third-party support from vendors and contractors for maintaining and updating control elements such as PLCs and physical process hardware.
- Responsible behavior and the failure to follow strict security guidelines may lead to malware infecting the so-called air-gapped" SCADA network zones, as is what happened with Stuxnet.
Because of these reasons, specialized security awareness and training for such personnel - and those managing them - is necessary.
4) Segment the Control System into Zones
This relates to the first recommendation in this list. A SCADA network is not one monolith network, but rather is comprised of three or four distinct zones, which at a minimum require you to isolate.
- The physical process and process hardware (transducers, actuators, ADC/DAC converters, remote terminal units, aka RTUs).
- The control network, made up of process control elements such as PLCs, distributed control systems (DCSs) and other types of controller hardware; RF transmission links; and network switches and firewalls allowing and controlling communication with the process network.
- The management and supervisory network, consisting of supervisory workstations running human machine interface (HMI) software. Supervisors and managers use these to view the process and controllers in action or to manipulate the process control or process parameters (e.g. set points and thresholds).
5) Control Physical and Logical Access to the SCADA Network
As explained in No. 2 above, because of their higher threat perception, mission-critical SCADA environments need adequate physical and logical safeguards, including access control and verification to prevent a cyber or kinetic attack - or even a cyber-kinetic hybrid attack.
6) Harden the Components
This requires special treatment and needs a significant investment in terms of effort and money to do well. While the National Institute of Standards and Technology (NIST) and similar bodies have published comprehensive guidance to help businesses harden the typical components of a corporate network - and while some of this is relevant to SCADA environments - there is still little known in the public domain about hardening control systems.
Furthermore, SCADA networks and those who operate them are besieged by a lack of security assurance (i.e. the two-fold guarantee that firstly the equipment will do what it is supposed to do, every time, and secondly, that the equipment will never do what it is not supposed to). There is also mistrust in SCADA hardware installed in highly sensitive environments, such as nuclear facilities, aviation and power generation and distribution systems.
Approaches such as fuzzing hardware, software and communication protocols to discover vulnerabilities proactively is often not feasible in all cases and can only provide a limited security assurance.
7) Monitor and Maintain the System
Problem: Many if not all sensitive SCADA installations suffer from the legacy hardware and software problem. Many of these systems were set up a long time ago on outdated, even obsolete platforms like Windows NT and XP, and use software and tools that have not been updated or patched in years.
The OS and hardware is so outdated that modern tools for anti-virus detection, for example, impose unacceptable resource overheads for them to run effectively. Furthermore, such installations are extremely sensitive, and often the operators are reluctant to upgrade the infrastructure in the fear that they may "break" the system.
It becomes a case of If it ain't broke, don't fix it. And a direct consequence of not maintaining such systems is that they are often impacted by malware or other threats that other still-supported systems are patched against. So ironically, it is often the most sensitive systems that are more vulnerable than corporate IT networks that usually have upgraded hardware and up-to-date operating systems and applications.
Despite the legacy nature of hardware and software installed in highly sensitive SCADA environments, it is important to maintain the component systems and have adequate protections against cyberattacks. If direct controls, such as upgrading the hardware, OSes and software to the latest versions to minimize the attack surface is not possible, then you should turn to compensatory controls that detect and react. These include solutions that monitor and alert about suspicious activity, stronger and more restrictive firewall and network segmentation/isolation policies, and more stringent policies regarding the use of such systems.
8) Test and Audit the System
The attack surface for critical infrastructure is enormous. When you are unable to get an adequate level of security assurances from a system that is part of a sensitive SCADA installation, the only other approach is to perform frequent audits and testing to ensure the system behaves in a predictable manner. If you can identify and fix these weaknesses before security issues have had a chance to fully manifest, that will generate a certain level of operational due diligence and process vigilance. You can also consider modern approaches such as threat hunting, which are suitably adapted to addressing cyberthreats on specialized SCADA networks as they are on conventional IT networks.
Dan Kaplan is manager of online content at Trustwave. Sachin Deodhar is an incident response consultant at Trustwave.