You might not be running a utility, but the lessons learned affect your network as well]
by Rik Farrow
In late July 2002, the US House of Representatives passed a bill authorizing life sentences for anyone convicted of attacking a computer system with the intention of harming human life. There has been concern within the US and other countries about threats to the "critical infrastructure" for many years now, and, if anything, it appears that these threats have become more serious over the past five years, rather than being mitigated.
One of the main focuses for such attacks are control systems for utilities, such as gas, electricity, and water. As a security consultant, with friends in the industry, I can tell you that these threats are not in the same class with scuba-diving suicide bombers, or Chicago hoodlums turned nuclear terrorists. Someday, your lights may go out for days or weeks.
You might be wondering what this has to do with your network's security--it will be very secure once the electricity goes out and your UPS fails. Securing the critical infrastructure has parallels for network security, as utilities must use the same or similar technology available to you to secure your networks, and face many of the same problems.
Awareness about vulnerabilities in the control of utitilies is not new. An electric industry article (see Resources) written in 1996 details both possible solutions, as well as existing problems. The report even provides clues as to how an attacker might disable the US electric distribution grid. A 1998 report covers gas distribution systems, and just serves to add awareness of the widely distributed nature of the US power resources.
In each report, you will find references to SCADA, Supervisory Control and Data Acquisition. SCADA provides the means to remotely monitor and control industrial processes, and is commonly used in factories. SCADA is also widely used by utilities, again, for remote monitoring and control. A typical SCADA system at a remote site, say a substation on the electrical grid, consists of a Remote Terminal Unit (RTU) and a set of devices that report or are controlled via the RTU. Imagine, if you will, a not too futuristic system that allows you to turn on your oven remotely, unlock the front door, or monitor your home's temperature and physical security via your computer. Now, instead of attaching a toaster to the Internet, imagine valves on gas pipelines and switches on the electrical grid.
At first glance, a successful attack against a SCADA controlled site seems unlikely. SCADA software is specialized, not like the systems that normally get attacked today. 98% or more of all attacks against Internet-attached systems involve unpatched versions of popular software, and it would seem that SCADA systems would not be included.
Not so, say Marc Maiffret in congressional testimony. Maiffret has studied SCADA software in his lab, and found that a lot of the newer software is based on Windows and vulnerable to attack. For example, the SCADA software may run on Windows NT or Windows CE, and any vulnerabilities in either OS can open up the system to attack (although Windows CE hardly has enough to be terribly vulnerable). Maiffret, during his testing, found that the software used to implement SCADA on Windows platforms was itself vulnerable to buffer overflows. Or, a successful attack on the SCADA system would reveal usernames and passwords useful for controlling other parts of a SCADA network.
Not all SCADA systems run Windows variants. UNIX and real time operating systems, like RTX or VxWorks, are actually more common. Of course, vulnerabiliteis in UNIX systems are well known. And even real time OS' can have security issues, as shown by the recent list of vulnerabilities reported by Ofir Arkin of Atstake in VxWorks-based Internet phones. It turns out that if an attacker can access a SCADA system, they have a good chance of successfully attacking it.
The next problem for any attacker of a SCADA system is to understand actually what the system does, and how to use it, especially how to abuse it. Details of system operations should not be available to outsiders, so disgruntled employees (or ex-employees) are considered the most likely to be successful attackers of SCADA systems.
A thesis published the summer of 2002 studied the impact of an attack against a hypothetical water distribution system. The author of this paper explains that the sample system includes built-in safe guards, designed to prevent unsafe operation of the system. For example, if a water tank reaches a low level threshold, pumps would be activated to refill the tank automatically. Similar systems have been built-into gas distribution networks, for example, to prevent over or underpressure in pipelines.
These control systems, if electronic, are not perfect. If the threshold for some dangerous level gets stored in a computer's memory, it can be altered. In the case of the electrical grid, the threshold might be stored in a device, such as a circuit breaker. By lowering the threshold set in a circuit breaker, it can be set to break at lower than normal levels, disrupting service. Or more catestrophically, be set at higher than normal threshold, resulting in damage to equipment or transmission lines.
SCADA systems do not seem like the type of targets favored by bombers or hijackers. The type of information required for a successful attack is not something that can be learned at a local flight school, or even a university. But a determined group, especially one funded by a nation state, would have the resources to collect this information, and to take advantage of it in a coordinated attack against a country's critical infrastructure.
Some of the defenses suggested in industry papers (see Resources) appear staggeringly obvious. These papers encourage the use of encrypted links, dial-back modems, and authentication to protect communications. But all of these measures have drawbacks. Encryption adds delays to communications, and if a real time system cannot have delays greater than 100 milleseconds, this may in itself cause a problem. Also, the hardware used to implement these devices may not have the memory or processor capabilities to support encryption without replacing the device itself. Dial-back modems have been compromised in the past, simply by using a modem for the attack that does not release the line, but waits for the dial-back modem to finish dialing, then presents the answer tone. Authentication can help, but only if the system was properly designed.
One obvious solution lies in isolation. If the SCADA system and all connected devices can be part of an isolated network, then, as long as the network remains isolated, most of the problems "go away". There can be no remote attacker, as the attacker must be within the isolated network to succeed. In some cases, networks containing SCADA devices are already isolated. Chris Wysopal, of Atstake, explains that in the case of a factory with real time requirements, the factory network gets connected to the company network using a firewall set up as a 'diode', a one-way device. Connections from the company network are always blocked by the firewall, but the firewall does allow the factory network to push out data so that it can be collected and used in company databases or for generating reports.
The diode firewall provides an excellent example of how network architecture designed primarily to support reliably short response times aids in security. As long as the firewall works properly, no external attacker had any chance of affecting the protected network. A diode firewall makes sense for any organization that has systems that do not require input from external networks (such as a company network or the Internet), yet have information that must be shared outside of the secured network. For example, a private network used for currency exchange deals or stock trades should be isolated from other networks.
A working example includes SIPRnet (Secret Internet Protocol Router net), a network used within the US Armed Forces for work on classified data. No access is allowed from any external network, although access is allowed from the secured network to the external networks through application-gateway-like software controls known as pumps. The pumps control the passage of information, and never permit external access to the classified network. The pumps also control what can be "declassified", that is, allowed to be sent over the ordinary Internet.
Total isolation of SCADA networks turns out to be impossible in many cases. One big reasons for the lack of isolation for the electric industry has been changes in regulation. Until electricity generation was deregulated, each utility operated as a monopoly with prices regulated by state agencies. If a utility needed to buy power, they had agreements with neighboring utilities, and made arrangements via informal mechanisms, such as a phone call.
Today, electric generation in the US has been deregulated, and the power distribution grid belonging to private companies or government agencies now must be at the beck-and-call of competing organizations. The ability to send power across transmission lines, power that may be generated by competing agencies, means that utilities must provide equal access to all agencies. Instead of being able to isolate their networks, agencies providing transmission capabilities must have Internet access. The trick then involves isolating their Internet servers, which function as ecommerce sites, from their control networks. If an Internet-based attacker can breach an ecommerce site that feeds into a SCADA control network, all hell could break loose. Or, more simply, the lights will go out.
Again, the situation seen in utilities is not unique to their industry. Banks and businesses that provide Web access must also provide logical isolation between their ecommerce sites and their internal databases that hold customer account information. This logical isolation is not perfect, as shown by the number of times that credit card and customer information have been stolen from Internet connected servers. Often, the problem was as simple as not separating the ecommerce system from the database system, but running both servers on the same system.
The mergers mentioned above have had another effect. With mergers come layoffs, and as the workforce gets reduced, the people remaining take on more responsibilities. In many cases, this means that those in charge of SCADA systems must be able to log on remotely, from home. Again, the danger here is a familiar one, in that if an attacker can install a trojan horse on an employee's PC, that trojan can capture keystrokes, including passwords. Or the trojan could work as a relay, allowing an attacker to use the same encrypted VPN tunnel as the worker. The solution here would be the same as in other industries: the use of up to date anti-virus software and personal firewalls to protect the use of VPN software.
The danger to the critical infrastructure is neither new nor exagerated. Yet, the technology already exists in many cases to protect SCADA networks. And this same technology can be used in your own networks, through implementations of policy that isolate networks, control traffic between networks, as well as protect remote access. In the non-stop world of utitilies, as in the rest of the business world, security requires funding and the will to make it work, rather than new technologies that have yet to be created. What are we waiting for?
Risks of Cyber Attack to Supervisory Control and Data Acquisition for Water: http://www.riskinfo.com/cyberisk/Watersupply/SCADA-thesis.html
Example of Windows CE SCADA product: http://www.edasce.com/pcbasedcontrol.asp
Newer version (Jan 2002) of CE .NET:
http://www.activewin.com/faq/wince_faq.shtml or
http://microsoft.com/windows/Embedded/ce.NET/default.asp
Article posted through InfoSecNews (ISN) about SCADA security: http://www.landfield.com/isn/mail-archive/2002/Apr/0167.html
Gas industry article from 1998 about security and SCADA: http://www.gasindustries.com/articles/gioct98a.htm
Electric industry article (1996) about potential vulnerabilities: http://www.securitymanagement.com/library/iatf.html
Marc Maiffret's Congressional testimony: http://www.eeye.com/html/Research/Papers/DS20020724.html
Ofir Akin's discoveries in the VxWork's based Internet Phone: http://www.atstake.com/research/advisories/2002/a071202-1.txt