WHITE PAPER: ENTERPRISE SECURITY

Transcription

1 WHITE PAPER: ENTERPRISE SECURITY Security Incidents and Trends in the SCADA and Process Industries A statistical review of the Industrial Security Incident Database (ISID) Prepared by: Eric Byres David Leversage Nate Kube

2 White Paper: Enterprise Security Security Incidents and Trends in the SCADA and Process Industries Contents Executive summary Introduction Background and motivation The Industrial Security Incident Database The changing landscape A deceiving trend Estimating total incidents in the SCADA and control industries Summary of incident trend rates A changing threat Inside to outside A nastier threat The back door into the control system The impact of cyber incidents Financial impact Operational impact An alternative Cyber-Threat Impact Index Improving the security of industrial control systems The need for comprehensive security programs The need for defense in depth Patch and antivirus management in control systems Layered protection for control devices Summary

3 Executive summary Supervisory Control and Data Acquisition (SCADA) and industrial control systems, with their traditional reliance on proprietary networks and hardware, have long been considered immune to the cyberattacks that have wreaked so much havoc on corporate information systems. Unfortunately, both academic research and in-the-field experience indicate that this complacency is misplaced the move to open standards such as Ethernet, TCP/IP, and Web technologies is letting hackers and virus writers take advantage of the control industry s ignorance. The result is a growing number of unpublicized cyber-based security events that are impacting our critical national infrastructures and manufacturing industries. In support of establishing the case for improving control system security, this report summarizes the incident information collected in the Industrial Security Incident Database (ISID). It describes a number of events that directly impacted process control systems and shows that the number of cyber incidents against SCADA and control systems worldwide has increased significantly since The majority of these incidents are coming from the Internet by way of opportunistic viruses, Trojan horses, and worms, but a surprisingly large number are directed acts of sabotage. In addition, the analysis indicates that many SCADA/process control networks (PCN) have poorly documented points of entry that provide secondary pathways into the system. The analysis highlights several key areas where the average SCADA/PCN system could be better secured. First, the root cause of many of the incidents reported in the ISID is a breakdown in human factors rather than a failure of technology. Thus, it is critical that SCADA owners and operators begin to develop comprehensive control system security management programs that cover all aspects of industrial system security, including cyber and physical security. The Symantec white paper, Effective Practices for Meeting NERC Critical Infrastructure Protection Requirements in the Electric Power Industry, provides guidance on how to create such a security program system by following a simple and holistic five-stage strategy, avoiding the common piecemeal approach to security. Second, the existence of secondary pathways highlights the need for an in-depth defense strategy. This includes better layering of firewall defenses and the hardening of endpoint devices through patch management, antivirus deployment, and distributed security appliances within the SCADA/PCN proper. In summary, the ISID data indicates that organizations that operate SCADA and control systems have good reason to be concerned about cybersecurity. Not only have the number of incidents increased dramatically in the past five years, but the seriousness of these events appears to be growing as well. Furthermore, the cost of an incident can be substantial. Even if 4

4 there is no direct impact on production or revenue, there is cost associated with expenditure of employee time, upgrading/changing of equipment, and the risk to corporate reputation. Failure to adapt to the changing landscape of security threats and vulnerabilities will leave the industrial controls world exposed to increasing numbers of cyber incidents. The result could easily be loss of reputation, environmental impact, production and financial loss, and even human injury. Introduction This report presents evidence in support of a business case for improving security of Supervisory Control and Data Acquisition (SCADA), 1 process control networks (PCN), and manufacturing and industrial automation systems. It is based on an analysis of statistical trends in security incidents as recorded in the Industrial Security Incident Database (ISID), a collection of known cybersecurity events that have occurred against control systems in the manufacturing and critical infrastructure industries. The report is divided into the following sections: Introduction Background and motivation: Summarizes the general changes in the SCADA/process control industries and technologies that have been seen over the last decade. The Industrial Security Incident Database: Provides a background on the ISID and discusses the organization of the data it contains. The changing landscape: Illuminates current incident trends in incident rates via data gathered from ISID. The changing threat: Looks at the driving forces behind many of the incidents recorded in ISID. The back door into the control system: Discusses the pathways that external attacks are employing to reach the SCADA system and plant floor. The impact of cyber incidents: Discusses the impacts of security incidents on the companies operating SCADA and control systems. Conclusions and recommendations for improving the security of industrial control systems: A discussion of possible means of improving the state of SCADA/PCN security. 1 The term SCADA is used in this paper to represent any industrial control system, including Distributed Control Systems (DCS), Programmable Logic Controllers (PLC), Remote Terminal Units (RTU), Emergency Shutdown (ESD) systems, and safety control systems. 5

5 Background and motivation Historically, the industrial control and SCADA systems that are responsible for monitoring and controlling our critical infrastructures and manufacturing processes have operated in isolated environments. These control systems and devices communicated with each other almost exclusively and rarely shared information with systems outside their environment. These SCADA systems were typically composed of proprietary hardware and software components designed specifically for control operations. Knowledge of the applications and protocols was limited to those few people directly involved in system design or operation and was not readily available to the general public. Thus the security of critical control systems was thought to be a trivial problem that could be managed through the use of either traditional IT security efforts or internal safety processes. These beliefs were exemplified in articles such as Debunking the Threat to Water Utilities, which made claims such as Most public utilities rely on a highly customized SCADA system. No two are the same, so hacking them requires specific knowledge. 2 Today, with the vast expansion of business communications systems and the move towards having access to real-time business information from any location, these previously stand-alone control systems are now being connected to the outside world. Business efficiency needs are dictating that production information be readily accessible to business managers, sales staff, engineers, maintenance personnel, and others who are not actually on the plant floor. While rarely directly connected to the Internet, studies show that in a typical corporation, 80 to 90 percent of all control networks are now connected to the enterprise network, 3 which in turn is interconnected to the Internet in myriad ways. Furthermore, in an effort to reduce costs and improve performance, both control system vendors and owners have been transitioning from proprietary technologies to the less expensive technologies prevalent in the IT world, such as Ethernet, TCP/IP, Microsoft Windows, and various web technologies. Unfortunately, many of these popular applications, protocols, and operating systems have a significant number of widely known vulnerabilities, with new ones being reported every day. Exploitation tools, worms, and how-to papers are often readily available shortly after the announcement of a new vulnerability, so rather than requiring specific knowledge, hacking many of the components of a modern SCADA system can be done with a few clicks of a mouse. 2 Scott Berinato; Debunking the Threat to Water Utilities, CIO Magazine, CXO Media Inc., March 15, Paul Dorey; Security Management in Process Control: The 3 Waves of Adoption, PSCF Spring 2006 Conference, Process Control Security Forum 6

6 Even the flaws in SCADA specific technologies have become general knowledge detailed presentations on how to exploit SCADA vulnerabilities have been given at public conferences such as BRUM2600, 4 ToorCon 2005, 5 and Blackhat Federal. 6 As more components of control systems become interconnected with the outside world, the probability and impact of a cyberattack will heighten. In fact, there is increasing concern among both government officials and control systems experts about potential cyberthreats to the control systems that govern our critical infrastructures. What is lacking is good historical data to either back up or dismiss this concern. To help provide guidance on this question, this report will look at the event data collected over the past five years by the Industrial Security Incident Database (ISID). It is hoped that this analysis will provide industry and governments current and relevant statistical data from which intelligent choices regarding industrial cybersecurity can be made. The Industrial Security Incident Database In early 2001 a security research team at the British Columbia Institute of Technology (BCIT) was asked by a major petroleum refining facility to investigate the possibility that their control systems could be impacted by cyber-related events such as hacking or viruses. In the course of this study it became apparent that accurate historical data on cyber impacts was badly lacking in the SCADA or process industries, making accurate risk assessment extremely difficult. To address this shortcoming, two researchers, Eric Byres and David Leversage, founded the Industrial Security Incident Database (ISID) with assistance from Justin Lowe of PA Consulting. Modeled after similar safety-related databases in the process industries, 7 ISID is intended to serve as an industrywide repository for collecting, analyzing, and sharing high-value information regarding cybersecurity incidents that directly affect SCADA, manufacturing, and process control systems. The ISID provides a historical representation of industrial cybersecurity incidents from which industry can gain a realistic understanding of the risks associated with industrial cyberthreats. It also provides ISID members with reliable information support for adapting current security policies to reflect the changing dynamics of industrial cybersecurity. The ISID attempts to addresses questions like: Which industrial cybersecurity incidents are fact and which are urban myth? How urgent is the security risk to control systems? What security vulnerabilities are exploited? 4 We have your water supply, and printers Brumcon report, The Register, October 20, A good example is the Process Safety Incident Database (PSID), operated by the Center for Chemical Process Safety. Details on PSID can be found at 7

7 What are the threat sources? How serious are the consequences? Incidents are obtained from either organizations voluntarily submitting an ISID reporting form to ISID investigators or from ISID staff harvesting reports from public sources such as the Internet, discussions at SCADA/industrial cybersecurity conferences, and relevant industrial publications. Examples of the latter include the Slammer Worm infiltration of an Ohio nuclear plant and several power utilities 8, 9 and the wireless attack on a sewage SCADA system in Queensland, Australia. 10 The ISID was designed with the capability to capture as many standard incident characteristics as possible. The database comprises various entry fields that require the submitter to provide a statistical description of the reported incident, including event date, affected industry, location, and affected network or device. The ISID also includes descriptive categories such as incident type (accidental/deliberate), intent (malicious/accidental), as well as type classifications such as external hacks, denial of service (DoS) attacks, and virus/worm infiltrations in order to extract the most information possible from the data. Figure 1 shows some typical data input screens for the ISID application. When an event is either submitted by an ISID member or noted in a public forum, it is first reviewed and verified by the ISID researchers. To protect the confidentiality of the ISID contributors, any information that may identify the source of the incident (such as the contributor s name, event location, or company details) are removed. The ISID researchers then attempt to ascertain the reliability of the report by verifying its details using standard investigative techniques. Each incident is then assigned one of four reliability ratings: 1. Confirmed 2. Likely but Unconfirmed 3. Unknown or Unlikely 4. Known Hoax/Urban Legend 8 NRC Information Notice : Potential Vulnerability of Plant Computer Network to Worm Infection, United States Nuclear Regulatory Commission, Washington DC, August 29, SQL Slammer Worm Lessons Learned For Consideration By The Electricity Sector, North American Electric Reliability Council, Princeton NJ, June 20, R vs. Boden [2002] QCA 164 Appeal against Conviction and Sentence, Supreme Court of Queensland, May 10,

8 Figure 1. Typical ISID data entry screens The degree to which the incident details can be verified determines the reliability rating the ISID researcher gives to the incident. For example, those events where the contributor is a reliable and firsthand witness or where there are official documents available (such as U.S. Nuclear Regulatory Commission reports or court documents) are considered Confirmed incidents. In contrast, incidents with secondhand data with limited detail, that have unknown sources, or that appear to the researcher to be improbable are given the rating of Unknown or Unlikely. As of June 30, 2006, there are 116 incidents that have been investigated and logged in the ISID database, with 12 incidents pending investigation and entry. Of these 116 records in the database, the 9 with a reliability of Unknown or Unlikely and the 1 with the reliability of Hoax/Urban Legend were excluded from analysis. An additional incident was also excluded because it had null data in the event date field and could not be used to obtain trend data. This left 105 records that were used for the analysis presented in the remainder of this report. The changing landscape The first question typically asked is whether or not the number of security incidents against SCADA and control systems is increasing or decreasing. To help answer this, Figure 2(a) graphs the frequency distribution of incident event dates. There are 14 categories of years ranging from 1982, the earliest incident event date in the database, to June

9 1982 to % 2002 to % (a) (b) Figure 2. Incident events by date from 1982 to June 1, 2006: (a) graphed as a frequency distribution; (b) charted as a percentage (105 records) Clearly, cybersecurity incidents impacting control systems is not a new problem as noted above, the earliest incident recorded in ISID occurred in 1982, almost a quarter of a century ago. However, these early incidents were sporadic, and the period of continuous annual incidents (i.e., where there is no year without a reported incident) didn t begin until The first year to see a significant increase in the frequency of cybersecurity incidents being recorded in the ISID as compared to earlier years was Notice that there is a striking increase in the annual incident rate starting in late As figure 2(b) indicates, even though the four and one-half year period from 2002 to June 2006 represents less than 20 percent of the total time scale, it contains almost 75 percent of reported incidents. While it is possible that some of this increase is due to the fact that the database was started in early 2001, we believe that the bulk of the increase is not. We have found the event dates of incidents have a low correlation with the submit date, indicating that companies will report incidents long after they have actually occurred. Thus if more incidents had occurred prior to 2002, we would still expect to see a few of them being submitted as late as Since this is not happening, it appears that sometime between 2001 and 2002 there was a significant shift in incident occurrence rates. As we have noted in earlier papers on ISID 11 (and will elaborate on in later sections of this report), it appears that the time period between 2001 and 2002 marks a significant watershed for SCADA and controls security and is a natural partition for analyzing trend data in more detail. 11 Eric Byres and Justin Lowe; The Myths and Facts Behind Cyber Security Risks for Industrial Control Systems,VDE Congress, Berlin, October

10 A deceiving trend On first reading of the early indicators for 2006, it might appear that there is a now a marked decrease in the frequency of cyberattacks against the SCADA and Process Control industry as compared to the 2003/2004 period. However, based on our experience in previous years, this is unlikely to be the case the time lag between the occurrence of an incident and when it is logged into the database (a mean delay of 13 months) is likely masking the true incident rates for 2005 and For example, at this point in 2005 only 10 incidents had been reported for 2004 and 15 for 2003; a year later that number had climbed to 23 and 29 respectively. Thus with eight incidents currently reported for 2005, we can assume that by 2007 the incident numbers for 2005 will be of the same magnitude as 2003 and Figure 3 shows the predicted incident rates from 1994 to 2005 along with a moving average trend line. Projected Actual Figure 3. Actual and predicted ISID incidents from 1994 to 2005 The good news is that while events have increased significantly since 2001, the rate appears to have leveled off in the past few years and may actually have decreased slightly in 2005/2006. It is likely that the trends in the critical infrastructure industries are following similar trends found in the overall IT world. According to a report written by IBM s Global Security Intelligence team, the global IT threat landscape is going through a fundamental shift, or evolution, in cyber crime from pervasive global outbreaks to smaller, stealthier attacks targeted at specific organizations. 12 As IT networks are becoming increasingly more secure, it is anticipated that many of these attacks will target the most vulnerable access point within a company or organization, which could easily be the SCADA or process control system. 12 Surge in criminal-driven cyber attacks anticipated in 2006, IBM Global Business Security Index Report, December

11 Estimating total incidents in the SCADA and control industries Discussions with operators of traditional business crime reporting databases indicate that the typical incident database collects no better than one in ten of the actual events occurring. Twentynine incidents were collected for 2003 and twenty-three for 2004, so it is likely that industry is experiencing at least 200 incidents per year at the present time. However, this number is probably several orders of magnitude low, due to the fact that of the 197 companies listed in the Fortune 500 with significant manufacturing or critical infrastructure operations, only 14 currently report to ISID and several of these are rather sporadic in their reporting. Thus it is probable that 2,000 to 3,000 industrial cybersecurity incidents are occurring per year to Fortune 500 companies alone. If this estimate is accurate, then it also indicates that even given the increasing acceptance of ISID, companies are still reluctant to provide information about security breaches. Intuitively one can expect that companies do not want to disclose that they have had problems with their network. This is also consistent with research conducted by Katherine Campbell et al 13 that found reports of security breaches can adversely affect a firm s stock price. Finally, the companies that do report to ISID tend to be on the leading edge of industrial cybersecurity preparedness and thus are likely experiencing lower incident rates as compared to the other companies. If nothing else, one conclusion we can draw from these statistics is that there is an ongoing security incident problem, and it may be more widespread than most control systems professionals believe. Summary of incident trend rates The overall trend data collected in the ISID, while limited in scope, appears to indicate two primary developments since the start of the millennium. First, the number of incidents affecting SCADA and control systems started to increase dramatically sometime in late This jump occurred within a short window of under six months. Second, this overall increase has now reached a plateau and has leveled out somewhere just below 2003 levels, a trend consistent with observations in the IT world. In the next section of this report, we will look at the possibility that while attacks may decrease slightly across the globe in volume, they are likely to increase significantly in severity, malicious intent, and associated negative consequences. 13 Katherine Campbell, Lawrence A. Gordon, Martin P.Loeb and Lei Zhou; The Economic Cost of Publicly Announced Information Security Breaches: Empirical Evidence from the Stock Market, Journal of Computer Security, Vol. 11, No. 3, 2003, pp

12 The changing threat Inside to outside As we noted in the previous section, the number of cyber incidents occurring against the SCADA and manufacturing systems took a significant jump in late This begs the question, Did the nature of these events change as well? To help answer this, the ISID data was analyzed for incident type to get an idea of the threat sources. First, the period up to and including the year 2001 was investigated. Figure 4(a) shows the breakdown of 27 incidents between the years 1982 and Note that accidents, inappropriate employee activity, and disgruntled employees accounted for 74 percent of the problems, indicating that most of the threat, malicious or otherwise, was coming from within the company boundaries. These statistics correlate well with the numbers being expressed by security researchers in the IT world at the time. For example, this statistic was widely quoted in 2001: A study by the FBI and the Computer Security Institute on Cybercrime, released in 2000, found that 71% of security breaches were carried out by insiders. 14 The ISID study team then produced the same graph for 78 incidents during the period 2002 to 2006, as shown in Figure 4(b). In this time period externally generated incidents account for 60 percent of all events, indicating a surprising and significant change in threat source. Adult or other 7% Accidental 31% External 26% Accidental 52% External 60% Internal 15% Internal 4% Adult or other 5% (a) (b) Figure 4. (a) Incident types charted as a percentage from 1982 to 2001 (27 records); (b) Incident types charted as a percentage from 2002 to June 1, 2006 (78 records) 14 Tony Stephanou; Assessing and Exploiting the Internal Security of an Organization, The SANS Institute, March 13,

13 Interestingly, the IT world appeared to experience the same shift. For example: Deloitte & Touche s 2003 Global Security Survey, examining 80 Fortune 500 financial companies, finds that 90% of security breaches originate from outside the company, rather than from rogue employees. For as many years as I can remember, internal attacks have always been higher than external, said Simon Owen, Deloitte & Touche partner responsible for technology risk in financial services. 60 to 70 per cent used to be internally sourced. But most attacks are now coming from external forces and that's a marked change. 15 Although there is no definite answer as to why this dramatic change took place in late 2001, there are a few possible explanations. First, as we noted earlier in this report, control systems have historically operated in an isolated environment where control devices typically did not communicate with outside systems. The move to integrated business communications systems and the widespread use of commercial off-the-shelf (COTS) technologies like Ethernet and TCP/IP have meant this isolation has broken down, especially since 2000, when the Y2K crisis drove massive upgrading of many systems. Second, the emergence of automated non- worm attacks starting with Code Red 16 in July 19, 2001, has meant that many of the intrusions have become nondirected and automated, and the control system may have become just a target of opportunity. Since control systems rarely use or allow Simple Mail Transfer Protocol (SMTP) traffic, earlier malware that used as a vector were unlikely to penetrate the plant floor. On the other hand, protocols such as Remote Procedure Call (RPC) and Structured Query Language (SQL) are ubiquitous in control environments, allowing the worms using these vectors easy access. This second interpretation seems to be supported by a closer look at the external incidents between 2002 and 2006, of which 78 percent (Figure 5) were the result of common viruses, Trojan horses, or worms. Particularly interesting is the fact that of these 36 malware attacks, only one (a Sobig-driven incident) used SMTP as its sole propagation technique. Three worms (Slammer, Blaster, and Sasser) accounted for over 50 percent of the incidents and these utilize the SQL Server Resolution Service (UDP Port 1443), the RPC Service (TCP Port 135) and the Microsoft-DS service (TCP port 445) respectively, to propagate to new victims. On last item worth noting is that the majority of these worm events occurred months or years after the worm was widely known in the IT world and patches were available and proven for control systems. This indicates to us a lapse in security policy rather than technology, a point we will revisit in later sections. 15 Nash, Emma; Hackers bigger threat than rogue staff, VNU Publications, May 15, 2003, 16 While Code Red was not the first non- based automated worm, it appears to be the first to have had significant penetration into industrial systems. 14

14 Denial of service 4% System penetration 9% Sabotage 9% Virus/worm/trojan 78% Figure 5. The percent total of each external incident type category, 2002 to 2006 A nastier threat If attack trends in the financial and IT sectors are any indication, total attacks in the next few years may decrease slightly in volume, but are likely to increase significantly in severity, malicious intent, and associated negative consequences. As noted security expert Bruce Schneier points out: Hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with a goal of money. Hackers can sell unknown vulnerabilities zero-day exploits on the black market to criminals who use them to break into computers. Hackers with networks of hacked machines can make money by selling them to spammers or phishers. They can use them to attack networks. We have started seeing criminal extortion over the Internet: hackers with networks of hacked machines threatening to launch DoS attacks against companies. Most of these attacks are against fringe industries online gambling, online computer gaming, online pornography and against offshore networks. The more these extortions are successful, the more emboldened the criminals will become. 17 A number of government and industry reports 18,19 have confirmed Schneier s observations. For example, Al Berg of Liquidnet predicts the following patterns for mainstream IT systems over next few years 20 : 1. Cybercriminals will continue using viruses and worms as tools. In the past, attackers released malware primarily to watch their code propagate globally and to wreak havoc on end users. However, members of organized crime have now realized the potential of these technologies as a means to carry out identity theft, espionage, and other cybercrime. 17 Bruce Schneier, Attack Trends, QUEUE Magazine, Association of Computing Machinery, June Ibid, IBM Global Business Security Index Report 19 NISCC Briefing: Targeted Trojan Attacks, National Infrastructure Security Coordination Centre, London, UK, June Al Berg, "Seven trends to expect from virus and worm authors in 2006," Threat Monitor, January 4, 2006 ( 15

15 2. Malware production pace will increase and quality will improve. As more criminal organizations become malware consumers, writers will be offered additional rewards for developing malicious code. These rewards will lead to the evolution of more sophisticated code, an introduction of new variants, and more attention paid to evading detection. Additionally, 2007 will bring about a trend towards threat customization. 3. Viruses and worms will become increasingly targeted. Rather than sending out mass to infect large numbers of random targets, authors will begin to craft their code to target specific user populations. 4. Coordinated attacks will reduce the distinctions between these types of threats. As attackers continue to combine virus/worms, Trojan horses, spyware, and phishing methods into increasingly more potent blended threats, the need for a unified antimalware strategy combining antivirus, antispyware, antispam and antiphishing solutions will be a major theme. We believe t hat these trends are likely to apply to the industrial controls world as well. In other words, attacks will be more specifically focused and, when successful against a SCADA or process control network, potentially far more damaging than in previous years. In fact, one statistic that stood out as a surprise to us was that 9 percent of all external incidents from 2002 to 2006 were the result of deliberate sabotage (Figure 5). This would seem to indicate that directed attacks are more prevalent than one might expect. Supporting this possibility is the fact that a number of the reports coming into ISID for 2005 and 2006 indicate a directed and commercial motivation for attackers. For example, in 2005, a confirmed report was provided of a complex and wide-reaching malware-based attack against the manufacturing lab systems of a major electronics manufacturer. The intent of this attack appeared to be industrial espionage. Nine months later, according to Japanese media reports, sensitive security information about a thermoelectric power plant run by the Chubu Electric Power Company was leaked onto the Internet following a virus infection. 21 Probably most ominously, in May 2006 the SANS Institute reported, Two SCADA systems have been penetrated for criminal (extortion) activity. 22 While these last two reports are yet to be confirmed, if true they send a chilling indication of the focused nature of future threats to control systems. 21 John Leyden, Japanese power plant secrets leaked by virus, The Register, May 17, SANS NewsBites, Vol. 8, Num. 42, May 26,

16 The back door into the control system One of the enduring beliefs held in the SCADA and control systems world is that control systems are secure because they are simply never connected to the Internet. But if this is the case, then how are all these viruses getting to the plant floor and infecting SCADA systems? To answer this question, the study team decided to look more closely at the category of events reporting a remote point of entry. The data set was reduced to the 47 incidents that occurred between 2002 and 2006 and had Remote in the point-of-entry field. Figure 6 graphs the frequency distribution of each of the nine remote point-of-entry categories: Internet, Corporate WAN, Corporate Business LAN, Wireless System, Trusted Third Party, Virtual Private Network (VPN) Connection, Public Telecommunications Network, and Dial-Up Modem. Via business network 19% Internet 13% Dial-up modem 11% Corporate WAN 19% Wireless system 9% Other 13% Telco Network 4% VRN connection 6% Trusted third-party 6% Figure 6. Remote points of entry charted as a percentage from 2002 to 2006 (47 records) The results clearly show that while the business network (either LAN or WAN) was a major source, it was certainly not the only source. Secondary pathways such as dial-up connections, wireless systems, public telecommunications networks, VPNs, and third-party connections were all significant contributors. While shocking to some, the large number of and variety of pathways common in automation systems is corroborated both by the keynote presentation at the 2006 Process Control Security Forum (PCSF) and a recent ARC Advisory Group survey. 23 The PCSF paper reported that at one representative large energy company, 80 to 90 percent of all control networks were shown to be connected to the enterprise network, 24 which in turn, is interconnected to the Internet. In the case of the ARC survey, control engineers were asked about the types of connections that their automation networks had to the outside world. The summary results were as follows: 23 Bob Mick; Manufacturing Security Status & Strategies, ARC Advisory Group, October Ibid; Paul Dorey 17

17 47.5% Company Intranet/Business Network 42.5% Internet Directly 35% Direct Dial-up 20% Wireless Modems 17.5% No Connection 8.0% Other Connections Notice that the percentages in the ARC study do not add up to 100 percent, indicating that many automation networks had multiple connections. Both the research team s experience in conducting site security audits on control systems and the results in Figure 6 indicate that most facilities have not just one pathway, but rather multiple pathways into their control system. For example, one survey in 2004 uncovered 17 different pathways, while site management believed there was only one control system to business network data historian link. The use of older technologies such as dial-up modems for remote support and the integration of new technologies such as VPN access, laptops, and IEEE wireless present many pathways for attackers to gain access into the SCADA and process control networks. These include: Modems: Both leased-line and dial-up modems have been in use for decades to allow the remote support of control systems and are still widespread, especially on control devices that use serial communications or are located in remote locations. For example, the connection of maintenance modems to protection relays substations is a largely accepted practice throughout the North American power industry. Unfortunately, many of these modem/device pairs have been shown to have either no password or trivial passwords. Some are even so old as to not allow passwords at all. Wireless: There are many ways SCADA control systems companies utilize wireless technology. Traditionally, SCADA networks over large physical areas utilized licensed-band radio systems to allow remote nodes to communicate with a centralized management host. More recently, the large-scale deployment of Wireless Ethernet (IEEE ) has created countless opportunities for intrusion and information theft. Third-party connections: Generally used for remote support by control systems vendors or product transfer by raw materials suppliers, these connections interconnect the control system to an outside network that may not follow the same security policies. Dial-up, long-haul serial, unencrypted wide area network, radio frequency, and VPN style connections are all used. 18

18 Virtual private networks: Often deployed as part of a third-party connection, these deploy encryption technologies such as SSL and IPsec to tunnel so-called secured communications across insecure networks (such as the Internet) and into the control network. Since the traffic is encrypted, it is commonly believed to be secure, but as noted in ISA-SP-99 Technical Report #1, 25 VPNs do not protect the network and workstations against most data-driven attacks (i.e., viruses) when the end nodes or networks are not also secured. As well, these connections can often bypass firewall rules because data is received in an encrypted format and cannot be checked by the firewall. Mobile devices: Mobile devices such as laptops, Personal Digital Assistants (PDAs), and flash drives are often used in a variety of environments, each with different security policies and practices. This allows the spillover of security issues from one system to the other. For example, if laptops are used both in the plant environment and in a less secure home environment, malware obtained in one setting may be unwittingly transferred to the other. Internet: While commonly denied, both the ARC Study and a number of the incidents in the ISID show that control systems do get connected directly to the Internet. Reasons for this include a desire to download system patches or antivirus updates from vendor Web sites, as well as a misguided desire to conduct typical office activities (such as ) from the plant floor. Figure 7 illustrates a few of the locations of possible pathways into organizations that employ segregated process control/scada networks, and all of them have been points of entry for at least one ISID incident. For example, database records show that the Slammer Worm had at least four different infiltration paths in the control systems it impacted: 1. The Davis-Besse nuclear power plant process computer and safety parameter display systems via a contractor s T1 line 2. A power SCADA system via a VPN 3. A petroleum control system via a laptop 4. A paper machine HMI via a dial-up modem The bottom line is that security designs that assume all traffic into the control system will flow through a single choke point may be making a dangerous assumption. Focusing a single solution (such as the Internet firewall) on a single connection point is likely to miss many possible entry points into the control system and leave the system open to attack. 25 ISA-TR , Security Technologies for Manufacturing and Control Systems, Instrumentation, Systems and Automation Society (ISA),

19 Business/corporate network To Internet ISP link or leased line Main firewall VPN Hub/switch Wireless access point Industrial network HMI or server Industrial firewall VPN Hub/switch Laptop Process control nodes Figure 7. Typical entry points in control network structure The impact of cyber incidents In this section we will analyze the empirical data on incident financial costs of cyber events against control systems. As well, we will present a theoretical approach that seeks to overcome the absence of reliable and comprehensive financial statistics. Financial impact Since the inception of the ISID, obtaining reliable financial impact information has proven to be one of the most difficult challenges for the researchers. Even incident contributors that provide detailed data on the technical aspects of an event are often unable to provide even an approximate estimate of the cost impact. Thus for most of the incidents reported in the database, the contributors have been unable (or unwilling) to provide a financial measure of the impact of 20

20 the industrial cyberattack in fact only 46 of the 116 incidents have such an estimate. Figure 8 (a) shows the impact cost charted as a percentage of incident events from 1982 to 2001, and (b) from 2002 to $100,000 to $1,000,000 20% $10,000 to $100,000 13% $1,000,000 to $10,000,000 3% $100,000 to $1,000,000 10% $10,000 to $100,000 6% $1,000,000 to $10,000,000 20% Greater than $10,000,000 20% Less than $10,000 46% SO 29% Less than $10,000 27% Greater than $10,000,000 6% (a) (b) Figure 8. Impact Cost: (a) charted 1982 to 2001 (15 records); (b) charted from 2002 to 2006 (31 records) Of the 10 incidents that reported a financial impact greater than $1,000,000, it s interesting to note that four were attributed to sabotage and the remaining six were as a result of accidental equipment failure. Only one of the four incidents involving sabotage was the result of an opportunistic attack. Although the sample data set is not large, it does suggest that a target of choice will incur a significantly larger financial impact compared with a target of opportunity. Operational impact Assessing the consequences of an industrial cyberattack is not simply a case of assigning a financial value to an incident. Although there are obvious direct impacts which may be easily quantifiable financially (e.g., loss of production or damage to plant), other consequences may be less obvious. For most companies the impact on reputation is probably far more significant than the cost of a production outage. The impacts of health, safety, or environmental incidents could be highly detrimental to a company s brand image. Even impacts such as minor regulatory contraventions may affect a company s reputation and threaten their license to operate. Potentially more significant is the nature of the impacts of the attacks. Forty-one percent reported loss of production while 29 percent reported a loss of ability to view or control the plant. Fortunately, human impacts have been small, with only one unconfirmed (and possibly unreliable) report of loss of life. Overall, the reported incidents clearly show that the most likely consequences of industrial cyberattacks are loss of view and the ability to control the process or system. 21