Robert M. Lee is a man no one listens to. And that gets him really frustrated.
The frustration boiled over when he made a presentation on his specialty—control-system cybersecurity—to a technology team “that should have known better,” he says. “They came to me [afterwards] and said let us know when you have a non-technical version because we didn't understand.” Problem was, Lee's talk was the non-technical version.
Really, it shouldn't be that hard.
So Lee, a US Air Force Cyberspace Operations Officer and adjunct professor at Utica College, decided to help us all out by writing a book. The result, SCADA and Me, is in comic-book form. Lee hopes that will make his subject as accessible to everyone else as it was to the president of Estonia, who made his whole staff read it.
SCADA stands for “Supervisory Control and Data Acquisition,” a linguistic mouthful that's all but guaranteed to set the layperson's mind wandering. The acronym remains unfamiliar to most of the general public.
That, however, is poised to change, because it's so intimately involved with so many aspects of our daily lives. And, as Robert Lee wants us to understand, if it were a person, it'd have a very large bull's-eye on its back.
One of the problems is that SCADA doesn't fit a set definition. It is not a particular technology. It's a general term denoting any application that gathers data about a large, usually industrial system of some kind, in order to provide feedback to measure and control that system or elements within it. In general, this means a network of intelligent devices that interfaces with the system through sensors and control outputs.
A SCADA system generally features a number of subsystems, such as:
- A human-machine interface or HMI—the apparatus or device which presents processed data to a human operator and by which the operator monitors and controls the process
- A supervisory computer system, which gathers data on the process and sends commands to it
- Remote terminal units (RTUs) connecting to sensors in the process—these convert sensor signals to digital data and send that to the supervisory computer
- Programmable logic controllers (PLCs), which may be used as field devices because they are more economical, versatile, flexible, and configurable than special-purpose RTUs; both PLCs and RTUs may be “smart,” i.e., capable of taking action on their own without consulting with the supervisory system
- A communications infrastructure, connecting the supervisory system to the remote terminal units
- And an alarm system, which either alerts the human operator to a problem or takes automatic action in an emergency
The best way to grasp the idea is to look at some familiar examples of SCADA at work:
- Electric utilities use SCADA to detect current flow and line voltage, to monitor the operation of circuit breakers, and to take sections of the power grid online or offline
- State and municipal water utilities use SCADA to monitor and regulate water flow, reservoir levels, pipe pressure, and other factors
- Oil and gas pipelines use SCADA to monitor flows, pressure buildups, and potential leaks
- Building managers use SCADA to control HVAC, refrigeration units, lighting, and entry systems
- Industrial facilities use SCADA to manage parts inventories for just-in-time manufacturing, regulate automation and robots, and monitor process and quality control
- Transit authorities use SCADA to regulate electricity to subways, trams, and trolley buses; to automate traffic signals for rail systems; to track and locate trains and buses; and to control railroad crossing gates
- SCADA regulates traffic lights, controls traffic flow, and detects out-of-order signals
That's just an extremely brief list. With almost any industry or public infrastructure project, SCADA will be there to increase efficiency and/or safety. This schematic shows how SCADA uses PLCs to control the flow of coolant through an industrial process:
Some of these applications are obviously so critical they must continue to function under less-than-ideal conditions. The SCADA system's hardware must be made as resistant as possible to fluctuations in temperature, vibration, voltage, or any other potential cause of failure. Redundant hardware and communications channels can also be important, possibly to the point of requiring multiple, independent control centers.
These sorts of precautions primarily relate to damaging events from the natural world or accidental internal systems malfunctions.
But what about deliberate, malicious intrusions?
That question jumped into the headlines in June 2010, in the wake of the discovery of Stuxnet, a computer worm that infected the software of at least 14 Iranian industrial sites, including a uranium-enrichment plant. The intent was to deal a crippling blow to that country's nuclear weapons development program.
International cyberspying has a long history, about which we are learning more almost by the day. In just the past week, there have been revelations that a British military base in Cyprus is being used to eavesdrop on communications to and from Israel, Syria, and other Middle Eastern countries, and that the NSA has been tapping into the private links that connect Google and Yahoo data centers around the world.
But these kinds of activities involve only listening in on other people's electronic conversations. Stuxnet, however, brought something new and more deadly to the table: the first use (so far as we know) of lines of code as an actual weapon of war. The worm was a streamlined yet highly sophisticated bit of computer malware that was unique in that it specifically targeted SCADA systems. It probably took years to develop and test, and ultimately did its dirty work in several stages.
First, it had to be introduced into the target system, probably via a USB stick. Then it proceeded to infect all interconnected machines. Next it searched for the target, high-speed centrifuges that help enrich nuclear fuel. Having found them, it compromised their SCADA PLCs, gathering crucial information about the centrifuges' normal modes of operation and vulnerabilities. Finally, it used that knowledge to eventually take control and cause the centrifuges to spin themselves to a violent failure.
One of the most ingenious features of Stuxnet was that it was able to provide false feedback to the SCADA system's human controllers, making it appear to an observer that everything was actually A-OK. Thus the operator stationed at the HMI didn't know there was something going wrong until it was too late to do anything about it.
Though the whole operation was shrouded in secrecy and though the Iranians have never publicly commented on it, Stuxnet is widely credited with having knocked out about 20% of Iran's centrifuges.
The Stuxnet worm was so cleverly designed that it likely would never have been discovered at all if it had not accidentally escaped Iran and gotten on the Internet, where it could be picked up and reverse engineered by anyone with the requisite skillset. And that's not good. A dangerous weapon capable of infiltrating established SCADA systems is now out there for the taking. Which means it could be activated not only by hostile governments, but also by small terrorist cells intent on disrupting or damaging key infrastructure, or even by cybercriminals bent on blackmail.
Indeed, in late 2012 a worm suspected to be of Iranian origin hit Saudi Arabia's Aramco oil company and Qatar's natural gas producer, RasGas. It collectively disabled 30,000 computers entirely, leaving behind an image of a burning American flag in place of the files that allowed the controlling computer to function.
So how at-risk are we?
Quite a bit. In theory, at least, a dedicated and techno-savvy enemy could cause such catastrophic events as a massive power blackout, an oil refinery explosion, disruption of a gas pipeline, contamination of a drinking water supply, a dangerous release of water from a dam, or confusion in air traffic control.
Security-conscious planners got a small taste of what might be in store as far back as early 2000, when a disgruntled former employee staged a SCADA cyberattack on the Maroochy Shire Council's sewage control system in Queensland, Australia. Suddenly, system components began to function erratically. Pumps did not run when needed, and alarms were not reported. More critically, sewage flooded a nearby park, contaminated an open surface-water drainage ditch, and flowed 500 meters to a tidal canal. The SCADA system was directing sewage valves to open when the design protocol should have kept them closed.
That incident is not likely to be the last of its kind. Throughout the developed world, many vital SCADA systems are aging. Moreover, their original intents were to promote simplicity of use and save money. They were designed to be open, robust, and easily operated and repaired—but not necessarily secure.
As SCADA evolved, systems also tended to move from proprietary technologies to more standardized and open solutions. That, taken together with the increased number of connections between SCADA systems, office networks, and the Internet, has made them more vulnerable to the types of network intrusions that are relatively common across the spectrum of computer security.
Some systems are believed to be safe from infection because they are detached from the Internet or use a VPN (virtual private network). But the fact is that even a network with no Internet exposure can be compromised by employees, either deliberately or because they are tricked into introducing malware via a disc or USB stick. Once a worm or virus is loose in the system, it can spread across the network without further intervention.
Others are thought safe because they are believed to be unconnected to the Internet, when in fact they are.
Earlier this year, two researchers from the consultancy InfraCritical studied the problem. To identify vulnerable sites, they ran a search engine called “Shodan,” which was created for the purpose of finding servers, routers, and other network devices that sit online. Users can filter searches to find specific equipment by manufacturer, function, and even where they're located geographically. The availability of Shodan greatly reduces the resources an attacker would need to find these privately owned assets.
The InfraCritical researchers built a suite of scripts that included 600 search terms for equipment built and managed by nearly seven dozen manufacturers of SCADA equipment and support systems for SCADA. That yielded an initial list of some 500,000 devices, involved in everything from critical infrastructure such as energy, water, and other utilities to more mundane applications like HVAC systems and red-light cameras. The scan for these devices didn't attempt to test the logins or how accessible they were; it just verified that they were Internet-facing. Most appeared to be for remote administration purposes that were, perhaps mistakenly, presumed secure.
After consultation with the Department of Homeland Security (DHS), which was keenly interested, the list was whittled to 7,200, many of them containing online login interfaces with little more than a default password standing between an attacker and potential havoc. DHS has initiated outreach to the affected asset owners, and progress, albeit slow, has been made in remedying some of those weaknesses.
That's just the tip of the iceberg. The future viability of our infrastructure may well depend on the speed and skill with which government cybersleuths and private-sector security specialists can move to shore up the system.
The vulnerability of SCADA systems to electronic sabotage is just one aspect of the cyberwar that is raging, unseen, all around us, 24/7. That conflict is covered in great detail in a special report on the subject that we'll be releasing shortly. In it, you'll learn about the many varieties of cybercrime, as well as how to protect yourself against it.
In the end, we can hope that SCADA becomes a more familiar acronym because we're listening to Robert Lee and learning more about how our infrastructure works—and not because a system comes under attack.