Supervisory Control and Data Acquisition (SCADA)
From Blindside
Contents |
[edit] What is it
SCADA systems (sometimes classed alongside Distributed Control Systems and Process Control Systems) collect distributed data for management and control by a centralised computer. Typically, these systems are used in many and varied ways in factories, plants, and other locations which may be widely distributed (over a range of miles). Industries that use SCADA systems include waste management, electric power, traffic signalling, mass transit, and environmental control, as well as manufacturing.
SCADA systems run on top of a real-time control system and manage processes external to them. They are therefore not critical components of the processes themselves.
SCADA systems are made up of many hardware, software, and communications pieces typically sourced from multiple vendors. They generally depend on proprietary protocols and interfaces.
Summary
Systems invented in a different era that did not need to be overly concerned with security were and may still be vulnerable to intrusion and attack. However, the need to upgrade security for SCADA systems has been well-publicised for years, and best practice information is readily available. Many large UK firms are participants in the forum established to deal with these issues. The merger of separate UK government bodies into the CPNI provides a single source of information, and has a wealth of information available. The question is how to push that information out to relevant parties.
Policy options for UK government range from compelling participation in the CPNI, the existing PCSF group (or a UK-based equivalent), turning some best practice into legislated norms, or more outbound communications leading to the establishment of an ongoing dialogue between affected organisations. The attractiveness of any of these options may depend on the prevalence of similar security issues in process control systems and distributed control systems.
[edit] Impact & Maturity assessment
We assign SCADA an impact level of 3, based on the potential disruption caused by catastrophic failure of a SCADA system in any one of a variety of applications, ranging from nuclear power plants to utility grids. We assign SCADA a maturity level of 3, as it would appear this is the peak period of vulnerability, where problems have been identified and publicised, but solutions are still in development or have not been universally adopted.
[edit] Information Assurance issues
Update Octobder 2007: Chrismith
Further on the issue that SCADA systems have long in service times (25+ years?) implies that that many were designed and built years ago and often using proprietary components and architectures. The support of these is becoming very difficult. The dilemma is that they are inherently robust but if they go wrong options are limited. Perversely if they are replaced by modern technology it invariably uses open architectures which for complex and bespoke solutions do not have a good track record of reliability. They are also, because they are open, vulnerable to hacking, viruses, worms etc
Update September 2007: A Blindside contributor adds:
The PLCs are very low powered (in computing terms) devices which has led to highly efficient but low security code being developed. Also makes deploying network level encryption very hard.
PLCs have system lifecycles of up to 25 years meaning noone is getting replacements any time soon.
To patch a PLC for many of them requires physically visiting them and replacing the firmware with custom written code over a serial link, not feasible in estates with 10s of thousands of PLCs across large campuses or distributed around the country.
The PLCs were originally serial, the move to Ethernet (Or a variant of) generally meant wrapping a serial protocol up in an ethernet frame. The move to IP has meant wrapping those up again in an IP packet. No consideration was given in the protocol design to the threats in an IP environment.
There are no good security testing tools for the legacy SCADA protocols in the public domain. I know some end users are scanning PLCs with standard IT vulnerability scanners like nessus and assuming that tells them something about the state of their systems. We need ModBus network fuzzers and the like. These already exist in private.
Those PLCs that have had IP stacks and web servers added are generally used for monitoring rather than control (although this is changing). In general there is a good bet that the custom IP stack will have a flaw allowing at a minimum for denial of service and the web server will be using vanilla HTTP without authentication.
Somewhere along the line the SCADA industry decided to standardise on Microsoft DCOM as the transport for their interoperable control protocol OPC. Anyone from the more technical end of security would know thats like building a malaria hospital in a swamp. Just look at the number of OPC tunneling products that have been created to get OPC past corporate firewalls or the fact that the complexity of getting DCOM based authentication working across different domains/ADs means most deployments allow anonymous or unauthenticated access for simplicity. Then look at the number of DCOM vulnerabilities found in the early 2000s and remember the OPC clients/servers haven’t had that level of scrutiny applied yet.
There are plenty of other problems but imagine the SCADA/PLC world is where the Internet was 10 years ago, many the same sorts of problems will be found and need to be fixed and at the moment there is no way to deploy those fixes or a way to deploy new versions with the built in as part of the system refresh cycle.
Previous entry:
There is concern about the security of SCADA systems, especially as some of the industries in which they are used are potentially important targets for terrorists. SCADA systems are often not designed with security in mind and may lack authentication. Several flawed assumptions contribute to the security risks of these systems. IT managers may erroneously assume, for example, that these systems are inaccessible from the outside, when in fact they are often bridged to corporate networks. The access controls are therefore often inadequate. Finally, the industry relies more than it should on security-by-obscurity, believing that the knowledge of how to attack these networks is too difficult for outsiders to gain.
Because SCADA systems are used in key infrastructure industries such as power, attacks on them could be massively damaging to people, markets, or physical plants. Some efforts are being made to study these risks and address them.
However, vendors of security solutions have worked vigorously at flagging up cyber-threats that their solutions would protect against. One principal question is whether they have over-egged, or even hijacked, the issue of information security in SCADA (and by extension, PCS and DCS) networks.
“Few besides a company's own employees possess the specific technical know-how required to run a specialized SCADA system. The most commonly cited example of SCADA exploitation bears this out. Two years ago, an Australian man used an Internet connection to release a million gallons of raw sewage along Queensland's Sunshine Coast after being turned down for a government job. When police arrested him, they discovered that he'd worked for the company that designed the sewage treatment plant's control software. This is true of most serious cybersecurity breaches--they tend to come from insiders. It was Robert Hanssen's familiarity with the FBI's computer system that allowed him to exploit it despite its security. In both cases, the perpetrators weren't terrorists but rogue employees with specialized knowledge difficult, if not impossible, for outsiders to acquire--a security concern, but not one attributable to cyberterrorism.”(The Myth of CyberTerrorism, Washington Monthly, April 2002). The article goes on to state, “Of course, it's conceivable that a computer-literate terrorist truly intent on wreaking havoc could hack into computers at a dam or power company. But once inside, it would be far more difficult for him to cause significant damage than most people realize. "It's not the difficulty of doing it," says RAND's Libicki. "It's the difficulty of doing it and having any real consequence." "No one explains precisely the how, whys, and wherefores of these apocalyptic scenarios," says George Smith, the editor of Crypt Newsletter, which covers computer security issues. "You always just get the assumption that chemical plants can be made to explode, that the water supply can be polluted--things that are even hard to do physically are suddenly assumed to be elementary because of the prominence of the Internet." But in January 2003, a nuclear power plant was penetrated by the Slammer Worm, as were some other facilities and utilities. Fortunately, the nuclear power plant was offline at the time. As news of this filtered into the security community, calls for robust action increased. However, the worm had entered the power plant via a subcontractor’s laptop computer, and the updating of operating systems was suspect, and there was no anti-virus protection employed as defence. So robust action might at that time have been merely adopting good hygiene rules already existing in organisations. Nonetheless, two special interest groups were formed in 2005, the Process Control System Requirements Forum and the Process Control Systems Forum. Reading through the CPNI, PCSF and PCSRF websites leaves the Blindside team with the very strong impression that an active and engaged participant would have access to sufficient best practice information to enable secure performance of SCADA systems. The real questions are a) whether or not all who should be involved actually are and b) whether best practice as promulgated is actually adopted. The CPNI runs a CERT programme that may address the second issue.
A variety of UK companies and organisations (including the CPNI) are members of one or both of these interest groups, and are therefore at least exposed to ongoing issues regarding the security of not only SCADA, but also PCS and DCS systems. UK participants include BAE Systems, BP and British Nuclear Group, just from the B’s. However, some large UK firms are not participants, and merger and acquisition activity in affected industries have brought new players into the field that may not have the same level of awareness of SCADA activities. The CPNI website also has a wealth of information regarding best practice for SCADA systems, however it is unclear how this information is pushed out to industry. On the 24th of July, CPNI announced a new mechanism for advisory distribution and security incident reporting, which essentially is the introduction of a feed for CSIRTUK advisories replacing email broadcasts. The CPNI website states that, “If you are a business or organisation which either owns or operates services or assets within the national infrastructure (NI), it is likely that you will already be receiving advice directly from CPNI.” The CPNI has copious links and publishes feeds, but there does not seem to be an outbound communications programme, definitions of what the national infrastructure consists of and which organisations fall under its remit, nor any ‘graceful’ way for a laggard company (or the CPNI itself, in case of error) to bring new partners into the fold. Essentially, the CPNI doesn’t seem to recruit.
[edit] Implications for UK Government
SCADA systems are heavily customised, hence a prescriptive policy is unlikely to address the information assurance issues effectively. Nonetheless, a self-assessment form should be available to commercial operators that includes awareness of risk and liability for operators of SCADA networks, as well as references to sources for help in upgrading such systems. Best practice case studies should be published.
Government may consider the possible usefulness of certification of commercial SCADA solutions, although again, due to the customization of SCADA for individual clients, certifying vendors might be more practical.
Perhaps the best line of entry would be via insurers.
[edit] Timescale
SCADA as a technology has been around since the 1960s. The impact of its security issues is being felt, understood and debated now.
[edit] Examples
America's Hackable Backbone, _Forbes_ (August 22, 2007). Slashdot discussion of same, with additional examples
SCADA Implementation for power companies in Egypt (PDF)
Safety monitoring system disabled for nearly five hours by the Slammer worm when it penetrated a private computer network at Ohio's Davis-Besse nuclear power plant in January 2003.
Terrorism investigators are examining computer tampering and a bomb threat (PDF) that led to a lengthy evacuation of the headquarters of an agency that controls most of California’s electric transmission system.
[edit] Comments (attributed)
“The guys who are setting up these systems are not security professionals. And many of the systems that are running SCADA applications were not designed to be secure – it's a hacker's playground.” – Jonathan Pollet, vice president and founder, PlantData Technologies, a division of Verano.
[edit] Organisations
The Center for SCADA Security at Sandia National Laboratories
[edit] Documents & research papers
Understanding SCADA System Security Vulnerabilities (PDF), Riptech, 2001.
Cyber Security Procurement Language for Control Systems Version 1.6 (PDF), prepared by Idaho National Laboratory for the U.S. Department of Homeland Security, National Cyber Security Division, June 2007.
Concerns about intrusions into remotely accessible substation controllers and SCADA systems (PDF)
The Use of Attack Trees in Assessing Vulnerabilities in SCADA Systems (PDF)
The Myth of Cyberterrorism, by Joshua Green, Washington Monthly, November 2002.
Control Systems Cybersecurity Awareness (PDF), Department of Homeland Security, 2005
Industrial Security Incident Knowledge Base, British Columbia Institute of Technoology ]
[edit] Experts (academic, practitioner)
Michael Assante, Infrastructure Protection Strategist for Idaho National Laboratory
