CYBER SECURITY Class # 8280.1

David Blanco

Application Engineer Automation Solutions, INC.

16055 Space Center Blvd, Suite 450 Houston, TX United State of America

Introduction

As a practical matter, the pressure to monitor and control large numbers of mission critical sites, the wide geographic distribution of these sites, and the environmental exposure of SCADA devices located at the sites, has driven the industry to low cost device solutions. The technological advances and evolving safety needs rapidly transformed Industrial Control Systems (ICS) from chart recorders to satellites and servers. Sites that weren’t even on a map were suddenly mapped on a communication network. While these innovations gave controllers more possibilities for production, they also gave hackers more opportunities for destruction. Once only able to delete and steal information, hackers now have the ability to control and destroy industrial equipment remotely and anonymously. This opportunity is so appealing that countries such as Russia, China, and Iran have created military departments dedicated to exploiting this phenomenon for political and economic leverage. The year 2014 saw 675,186 targeted attacks on Supervisory Control and Data Acquisition (SCADA) systems—more than quadruple from the previous year, which was itself doubled from the year before.1 This issue is so pressing that the United States Government (USG) has become involved. Executive Order 13636 outlines the proactive and reactive steps that the USG will take in order to help industry prevent and mitigate cybersecurity threats.2 This document was quickly followed by action when the Department of Homeland Security (DHS) created several units to implement these policies such as the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) and the National Cybersecurity and Communications Integration Center (NCCIC). 3 What the USG has not done, yet, is mandate security regulations. Some ideas already proposed want to hold manufacturers and controllers legally liable for security, on top of their other responsibilities.4 Therefore industry must use this opportunity to demonstrate its leadership by implementing security solutions for its systems that it creates.

This opportunity has not yet been seized for a number of reasons. First, the relationship between SCADA and Information technology (IT) is examined only from the perspective of operability. As long as measurement data comes in nobody questions the field’s network configuration. The reality is that the connectivity of field devices helps controllers and hackers alike, because the technology used in SCADA networks only utilizes the communication portion of the technology and not the security features. This is not the result of neglect. It’s merely a consequence of deployed technology outpacing policy. Secondly, the possibility of an attack is never explained in terms of probability. The threat of attack is explained in abstract hyperbole without making it relevant to the stakeholders. This creates alarm, but doesn’t help identify the issues that need to be acted on. Third, the technologies that can be used in an effective cybersecurity policy are only explained as principles, not as part of an existing system. This prevents the link between what-is and what-can-be from being established because the relevance to the realities in the field are never explained. The goal of this paper is to address and overcome these issues.

In order to accomplish this, the paper proceeds as follows. First, it discusses the challenges of SCADA security that arise from the disconnect between field assets and modern communication technology. Then, the paper examines the types of threats that the technology-policy gap has exposed SCADA systems to by providing examples of relevant security breaches. Finally, it outlines the most actionable security technologies and techniques for SCADA networks to adopt.

1 2015 Dell Security Annual Threat Report, Dell, 2015, https://software.dell.com/docs/2015-dell-security-annual-threat-report-white-paper-15657.pdf, p. 8. Please note at the time of writing, the 2016 Dell Security Report was not available. Also note, all SCADA attack numbers are self reported, making the stated numbers smaller than they truly are. 2 Executive Order 13636 of February 12, 2013, Improving Critical Infrastructure Cybersecurity, Federal Register, title 3 (2013): Vol.78, No.33, https://www.gpo.gov/fdsys/pkg/FR-2013-02-19/pdf/2013-03915.pdf 3 “Protecting Critical Infrastructure,” The Department of Homeland Security, accessed February 2, 2015, http://www.dhs.gov/topic/protecting-critical-infrastructure 4 Tom Simonite, “Hacking Industrial Systems Turns out to be Easy,” Technology Review, August 1, 2013, https://www.technologyreview.com/s/517731/hacking-industrial-systems-turns-out-to-be-easy/

Challenges of SCADA Security: Function Over Form

In the hydrocarbon industry, automation helped increase the productivity, safety, and reliability of field assets. However, without a way to convey the real-time production data that automation creates to decision makers, the benefits of the investment in automation are negated. SCADA systems transmit data in real-time between remote field locations and the office. Figure 1 depicts the typical, or ideal, SCADA system. In such a system, multiple Programmable Logic Controllers (PLC) or Remote Terminal Units (RTU) are deployed to a production site. These sites are usually geographically isolated from one another and from the office. The PLC’s and RTU’s, or field devices, commonly have logic, which interprets and acts on inputs taken from field instruments. As the logic is executed, outputs are created which are pushed back to the instrumentation and also communicated across a network to a central application server in an office. This network, between the field devices and the application server, is known as the field network and is typically standard TCP/IP communication. Once the application server receives the data, it can be retrieved and analyzed by other industrial software using Object Link and Embedding for Process Control (OPC) connectivity. This process is monitored and partially controlled from a controller station running Human Machine Interface (HMI) software. HMI’s receive data from the OPC Server and display it in a format that allows controllers to visualize, process, and react to events in the field in real-time. HMI’s also allow controllers to send commands back to field devices across the field network. In this case, this point is where IT security ends and SCADA security begins. Within the context of this paper, SCADA security does not mean securing the SCADA network that resides in the office. That is IT security. SCADA security refers to the ability of the field network, the link between the devices and the controllers, to guarantee the safety and integrity of its field devices and communications from being successfully attacked.

Figure 1: A Typical SCADA Network

The case for a distinction between SCADA security and IT security doesn’t have to be created; it only has to be recognized. The typical network, as shown in Figure 1, has several firewalls. One protects the SCADA network from the Internet and the business network. Another guards the business network from the Internet and the SCADA network. Occasionally, operators and technicians will open firewall ports, bypass protocols, and leave default settings in place just to get a meter to poll. IT has a similar situation with polling software and Distributed Component Object Model (DCOM). DCOM is a service that allows software on one computer to communicate with software on another computer. DCOM is used in SCADA to allow the OPC Server to communicate with an HMI machine, but in order to make it work, a range of ports must be made available between the two machines. The hustle of the day and the general confusion that comes from implementing IT security on SCADA assets results in firewall settings that are frequently left wide open in order to just get the RTU’s talking.5 This leaves the field and business networks open to attack and gives attackers a route to the field devices through the business network. A census of the internet found 93,793 Modbus TCP/IP devices listening on port 502 visible on the public internet.6 The good news is that the devices are talking. The bad news is that no one knows who else is listening.

When IT networks are breached the damage can be measured in dollars, but a breach in SCADA security could be measured in lives. When IT security is penetrated the goal of the attackers is usually to steal information or

5 Eric Forner & Brian Meixell, “Out of Control: Demonstrating SCADA device exploitation” (presentation and demonstration presented at the Black Hat USA 2013 convention, Las Vegas, Nevada, December 3, 2013) https://www.youtube.com/watch?v=FTzAkEnwx_c 6 Tim Simonite, “Hacking Industrial Systems Turns out to Be Easy,” MIT Technology Review, August 1, 2013. https://www.technologyreview.com/s/517731/hacking-industrial-systems-turns-out-to-be-easy/

money.7 If there’s destruction, it’s usually only of files and reputations. Many of the devices that form a SCADA network bridge the divide between the digital world and the physical world. SCADA’s cyber-physical capabilities let an attacker look for physical vulnerabilities alongside cyber vulnerabilities, often times using cyber vulnerabilities as a gateway to the physical side. When a field device receives a command its actuator translates the electronic signal into kinetic motion. Depending on the device, the resulting action could be as destructive as turning on a pump resulting in a plant tank overflow or increasing the pressure on a pipe beyond its maximum allowable operating pressure. The moral and financial implications of this are obvious. Not only is there a difference in the types and consequences of attacks between SCADA security and IT security, but there is also a difference in how they can respond.

IT security is usually deployed in an office on servers running the latest security software. When an attack is detected, IT admins can quickly (relative to SCADA) quarantine the attack, upgrade the software, reconfigure the network, or even install new hardware. SCADA networks don’t have those capabilities because they weren’t designed with them. Security in general and cybersecurity specifically were not major concerns for early SCADA systems.8 Early SCADA systems used proprietary communication protocols and only considered the physical requirements of security, because the technology to threaten them remotely didn’t exist. Since SCADA equipment is not geographically centralized, repairing, updating, and replacing equipment is physically difficult and financially burdensome. The result is that fields run off of a network of legacy equipment. The design of this purpose built equipment, RTUs, PLCs and other devices; of which there is a huge installed base, has been heavily influenced by cost controls and as a rule the SCADA devices lack hardware with the horsepower, or operating systems with the sophistication, to perform state-of-the-art security measures while simultaneously performing their principal automation mission. There are safety protocols built into field devices, such as ladder logic programs, but these are designed to interpret and act on clean data, not defend against tampering. Such programs are viewed as adding some protection to field units since they’ll theoretically catch malicious commands in their logic though the truth is that nothing protects the programs themselves from attacks. These realities created the networks we have today where legacy equipment is modified to the lowest point of compatibility with modern IT protocols. A testament to this reality is the 93,000 Modbus devices available over public IP addresses on Ethernet port 502.9 This is essentially a case of putting the legacy Modbus protocols into a more modern TCP/IP framework. While SCADA was getting IP addresses, IT networks in the office were installing Virtual Private Networks (VPN), which rely on sophisticated encryption techniques. Since the latest IT security solutions could not be installed on the legacy field devices, SCADA networks were protected using alternative strategies that relied on a lack of technology to work.

The most common cybersecurity strategy for SCADA systems is to place them on their own isolated network. For example, when addressing vulnerabilities in the SIMATIC S7-1200 PLC line, the Siemens Security Advisory recommended SCADA managers “isolate the automation network from all other networks.”10 However, the changes in global communication technology have made the isolation of SCADA systems, as they are currently configured, impossible. As the former director of the National Cybersecurity and Communications Integrations Center at the DHS, Sean McGurk, stated during a congressional hearing, “…in no case have we ever found the operations network, the SCADA system or energy management system separated from the enterprise network. On average, we see 11 direct connections between those networks and in some extreme cases, we have identified up to 250 connections between the actual producing network and the enterprise environment.”11 This signals the failure of trying to enhance the capabilities of SCADA networks by using modern communication technology while simultaneously trying to impede the hyper connectivity that comes with it. Which brings the argument back around to the main point: IT security solutions alone cannot solve SCADA security problems because IT security solutions weren’t developed for SCADA problems.

It is important to note, that the failure of SCADA to have a succinct cybersecurity policy is not the fault of SCADA workers or IT workers. It’s actually the result of each department doing its job correctly. The job of industrial

7 Yulia Cherdantseva , Pete Burnap , Andrew Blyth, Peter Eden, Kevin Jones, Hugh Soulsby, and Kristan Stoddart, “A Review of Cyber Security Risk Assessment Methods for SCADA Systems,” Computers & Security 56 (2016): 1-27. 8 Cherdantseva, “A Review of Cyber Security Risk Assessment Methods for SCADA Systems,” p. 2 9 “Modbus FAQ: About the Protocol,” http://www.modbus.org/faq.php 10 Eric Byres, “The Air Gap: SCADA’s Enduring security Myth,” Privacy and Security, Vol. 56, No. 8, August 2013, p. 29. Note: While the quote is contextual, Siemens has issued more recent statements against air gapping. The quote was only used to illustrate a point about the past. 11 Cybersecurity: Assessing the immediate threat to the United States: Hearing before the subcommittee on National Security, Homeland Defense, and Foreign Operations of the Committee on Oversight and Government Reform, House of Representatives, 112th Congress, 52, (2011) (Statement of Sean McGurk, the director of the National Cybersecurity and Communications Integrations Center at the Department of Homeland Security.) https://www.gpo.gov/fdsys/pkg/CHRG-112hhrg70676/pdf/CHRG-112hhrg70676.pdf

control is to see to it that field devices work safely, that data is reliable, and that the data is transmitting. The job of IT is to keep the business running by facilitating communications while simultaneously providing security to the company’s office networks. Technicians don’t receive angry emails when devices poll too quickly and IT Administrators don’t get pats on the back when a field device’s port is blocked. This dynamic perpetuates the status quo and allows the cracks between SCADA security and IT security to widen over time. These cracks provide hackers and hostile governments with opportunities to disrupt and destroy SCADA networks and the equipment it relies on. Unfortunately for SCADA, recent events have transformed their capacity for destruction from an academic possibility into matter-of-fact probability.

Threats to SCADA Networks: An Axis of Hackers

Even when the vulnerabilities of SCADA networks are understood, the threats to them are not. This happens because there are misunderstandings about who hackers are, what hackers can do, and what can be hacked. Part of this stems from the belief that SCADA systems simply won’t be hacked. Hackers are viewed as individuals or small groups of people who are only after money, so they’d have no motivation to hack SCADA. Even if a hacker penetrated the IT networks or field networks, there’s a perception that they would not be able to control such specialized equipment since it would require “skillsets that have nothing to do with hacking.”12 Too much faith is put into embedded safety logic being able stop them, since the idea that hackers would have the capabilities to compromise the PLC’s themselves is never considered. These opinions effectively shut down the discussion of SCADA cybersecurity since, if the discussion about SCADA security never gets around to discussing the capabilities of hackers then it won’t be able to address what can be done to stop them. Because companies are only required to report data breaches that involve personal or payment information, SCADA attacks often go unreported.13 Although this helps protect companies from financial and public relations fallout, it does a disservice to the industry at large by concealing the true extent of the threat. However, it is evident that SCADA attacks are on the rise. Worldwide SCADA attacks went from 91,000 in 2012, to 163,000 in 2013, to 675,000 in 2014.14 The roots of this trend can be traced back to the Stuxnet virus that hit Iran’s nuclear facilities in 2009. Stuxnet was the first confirmed attack to cross the cyber-physical barrier and damage equipment on a SCADA system.15 Stuxnet was carried to the Iranian facilities, which were isolated from the Internet, via USB. Once an infected USB stick was plugged into a controller computer it searched for PLC configuration software and infected the PLC itself. While operating on the PLC, Stuxnet recorded normal data in order to play it back to controllers when it was executing an attack. Using these tactics, Stuxnet was able to cause hardware used in enriching uranium to break at such a rate that the many of the facilities were closed as a result. Even in light of the damage that Stuxnet wrought upon the Iranian nuclear program, attacks on SCADA are still seen as “targeted” and therefore brushed off as something not likely to happen often.16 This thinking is dangerous as it assumes that the hackers wont have the time or resources to spend researching a target’s vulnerabilities. When coupled with the gaps in security inherent in current SCADA network configurations, hackers are basically given all the time they need to plan an attack and they do not spend that time idly. The advantages of destroying an enemy’s infrastructure are obvious and the capability of doing so without the fear of retribution is an opportunity that most countries cannot overlook. Currently, about 140 countries are thought to have offensive cyber programs, including Russia, China, and Iran. Using Stuxnet as a touchstone and the kinds of resources only available to governments, countries are now able to anonymously conduct cyber sabotage on American companies’ SCADA networks. This fact undercuts the argument that hackers wont have the skillset necessary to control field devices once they have access to them. Hacker governments can easily retrain individuals or form teams with the skillsets necessary to make an attack possible. This dynamic essentially pits the IT and SCADA departments of an individual company against the cyber-attack capabilities of a military. A typical David vs. Goliath story, except Goliath has stones too. But, US companies are not completely alone. The USG does have some policies, such as the Industrial Control Systems Cyber Emergency Response Team. This organization researches SCADA vulnerabilities and helps contain attacks when they occur, but such actions only mitigate the damage. Because countries have more time, money, and resources than traditional hackers, they are able to transform attacks against SCADA networks from novice intrusion attempts to weapons of cyberwarfare.

12 Kelly Jackson Higgins, “Anatomy of a ‘Cyber-Physical’ Attack,” Dark Reading, January 14, 2015, http://www.darkreading.com/vulnerabilities---threats/anatomy-of-a-cyber-physical-attack-/d/d-id/1318624 13 2015 Dell Security Annual Threat Report, https://software.dell.com/docs/2015-dell-security-annual-threat-report-white-paper-15657.pdf, p. 9 14 2015 Dell Security Annual Threat Report, https://software.dell.com/docs/2015-dell-security-annual-threat-report-white-paper-15657.pdf, p. 7 15 “The Meaning of Stuxnet,” The Economist, September 30, 2010, http://www.economist.com/node/17147862 16 “Stuxnet Timeline Shows Correlation Among Events,” Wired, Jul 7, 2011, http://www.wired.com/2011/07/stuxnet-timeline/

Because Stuxnet was initially targeted at Iranian infrastructure, Iran learned a particularly bitter lesson from the experience. In 2011, Iran invested $1 billion to develop its own cyber weapons capabilities.17 This program trains Iranian hackers on how to steal information and how to infiltrate SCADA systems in order to control them.18 The program is rather efficient, as seen by how effective and numerous Iranian attacks against US SCADA systems are. Comodo, DigiNotar, Shamoon, Operation Ababil, NMCI, Saffron Rose, Newscaster, and Operation Cleaver are just a few of the attacks Iran has launched since 2011.19 All of these attacks either disrupted operations or gathered intelligence on systems that would be useful in causing malfunctions in SCADA systems. For example, Shamoon disabled 30,000 windows based machines belong to Saudi Aramco by replacing every file on them with a jpeg of a burning American flag.20 This resulted in the loss of production data and ended up spreading to another energy firm called RasGas using a connection which was not accounted for. Operation Cleaver managed to embed Iranian hackers into hundreds of systems belonging to dozens of companies for over two years. This allowed them to penetrate a number of IT and SCADA networks belonging to airports, power grids, and energy companies enabling them to steal engineering documents which were labeled “mission critical.”21 The Iranians were able to do this because of tools like TinyzBot, which takes screenshots and logs keystrokes when controllers access ICS. Unfortunately, Iran is not alone in this. Proof of China’s enhanced hacking capabilities came in 2012, when a Chinese hacking group with ties to the Chinese army was caught infiltrating a decoy water plant. The plant was setup to mimic the configuration of a water plant in a small town. The attacks “displayed a high level of knowledge about industrial control systems, using techniques to meddle with specific communication protocols used to control industrial hardware.”22 The fact that the Chinese were able to find the decoy plant is proof that SCADA systems are being aggressively targeted. It also proves that an attacker doesn’t have to go through the IT network to infiltrate a SCADA network. In this case, the Chinese hackers just used the Internet to find the decoy plant’s IP address, which was configured to receive traffic on industry standard ports. The implication for this is that the field network worked exactly as it was intended to, it received the proper commands on the proper communication channels. The problem is that the Chinese knew these protocols. The parallel between the decoy plant’s setup and hydrocarbon SCADA networks is unsettling. Also important to note is that the remote site had no means of verifying who was accessing it. Without any means of authentication the decoy plant assumed that whoever is communicating with it is the rightful controller because it was setup with the assumption that only the controllers would know exactly where to send the commands. Not to be outdone, Russia is suspected of infecting several European energy companies with the Havex worm. Havex was based off Stuxnet and was specifically designed to sabotage SCADA and ICS systems by gaining system access to control devices through OPC communications.23 Once again, this demonstrates that governments are more than capable of finding the right combination of hacking and SCADA skills in their employees. Although Havex was discovered before it could inflict physical damage, not all hacks get detected in time to prevent them from wreaking havoc. For example, Russia is suspected of being behind an attack on a Ukrainian power grid, which penetrated the SCADA network and cut power to 80,000 people.24 Hackers from an unknown country who possessed “advance knowledge of ICS” manipulated and disrupted operations at a steel mill such that operators were unable to shutdown a blast furnace in time to prevent “massive” damage.25 All the

17 Ilan Berman, “The Iranian Cyber Threat,” Statement before the US House of Representatives Committee on Homeland Security Subcommittee on Cybersecurity, Infrastructure Protection, and Security Technologies, House of Representative, March 20,2013, http://docs.house.gov/meetings/HM/HM08/20130320/100523/HHRG-113-HM08-Wstate-BermanI-20130320.pdf, p. 3 18 Natasha Bertrand, “Iran is Building a Non-Nuclear Threat Faster Than Experts ‘Would Have Ever imagined,’” Business Insider, March 27,2015, http://www.businessinsider.com/irans-cyber-army-2015-3 19 “Operation Cleaver,” Cylance, December 2, 2014. https://cdn2.hubspot.net/hubfs/270968/assets/Cleaver/Cylance_Operation_Cleaver_Report.pdf, p. 7 20 Christopher Bronk, “The Cyber Attack on Saudi Aramco,” International Institute for Strategic Studies, April 2013, https://www.iiss.org/en/publications/survival/sections/2013-94b0/survival--global-politics-and-strategy-april-may-2013-b2cc/55-2-08-bronk-and-tikk-ringas-e272 21 Garance Burke and Jonathan Fahey, “investigation: US Power Grid Vulnerable to Foreign Attack,” PHYS.ORG, December 21, 2015, http://phys.org/news/2015-12-power-grid-vulnerable-foreign-hacks.html 22 Tim Simonite, “Chinese Hacking Team Caught Taking Over Decoy Water Plant,” MIT Technology Review, August 2, 2013. https://www.technologyreview.com/s/517786/chinese-hacking-team-caught-taking-over-decoy-water-plant/ 23 Swati Khandelwal, “Stuxnet like ‘Havex’ Malware Strikes European SCADA Systems,” The Hacker News, June 26, 2014. https://thehackernews.com/2014/06/stuxnet-like-havex-malware-strikes.html 24 Jim Finkle, “US Utilities Worry About Cyber Cover After Ukraine Grid Attack,” Reuters, Jan 28, 2016, http://uk.reuters.com/article/us-cyber-insurance-utilities-idUKKCN0V628N 25 Kim Zetter, “ A Cyberattack Has Caused Confirmed Physical Damage for the Second Time Ever,” Wired, January 8, 2015, http://www.wired.com/2015/01/german-steel-mill-hack-destruction/

hackers had to do to create physical damage was use the features of a control device in the right way but at the wrong time. When SCADA networks get hacked, the devices themselves are rarely the targets. Hackers want what the devices are controlling, which was the case with the blast furnace. How will companies respond? Will the manufacturer of the blast furnace issue security updates quickly? As of the writing of this paper, there are 35 known security vulnerabilities for SCADA field equipment from nine unique vendors some of which are years old.26 This touches back to a SCADA security challenge mentioned earlier that SCADA networks don’t have the luxury of easy updates or replacements. In fact, one of the PLC’s hacked during the Stuxnet attacks didn’t have the vulnerability used by Stuxnet patched until two years after the attack.27 What an open SCADA network does is make the initial connection point the gateway to all the devices behind it. This effectively forces an–every-man-for-himself defense strategy as each individual device now has to prepare against attacks. A device designed to be affordable and efficient can’t also be expected to implement processor-intensive defense software programs. As these cases demonstrate, current strategies are not sustainable. These attacks also demonstrate a willingness to target ICS, a competence to carry out attacks, and a dedication to finding even the most mundane of targets. Even at this point, a dedicated critic would argue that these attacks are not indicative of a threat to the SCADA networks of the hydrocarbon industry. While this effectively ignores the implications of the cases that were just mentioned, it does create an opportunity to delve further into the topic by examining tests that the hydrocarbon industry runs on itself. During the Black Hat convention in 2013, Brian Meixell and Eric Forner hacked into a demo SCADA system and were able to force a release on the pipe and cause a tank to overflow. Their setup consisted of a pump that pushed water through a pipe that was controlled for safety by a valve to a tank with a level indicator. All of these devices were attached to an RTU that communicated to a Human Machine Interface (HMI). They were able to gain access to the HMI and use that to route themselves to the application server handling the RTU traffic. Then, they used an engineering workstation to modify the safety logic on the control valve. This allowed them to bypass the safety checks that are so often relied on as network security. When the pump was activated using a standard Dbus command nothing stopped the tank from overflowing. Even if there had been a controller watching the HMI, no one would have noticed that anything was awry. Since the HMI and RTU were compromised, Brian and Eric were able to spoof data going back to the controller. So while the tank was overflowing, the controller’s screen told him the tank was actually emptying. 28 But the most alarming part of this example is that they did not have to do anything but use the equipment. The commands they sent to the pump to turn it on, were standard Modbus commands put into an open IP framework. The program they used to modify the safety valve was the valve’s own configuration software. All they did was apply industry knowledge to a vulnerable system. Securing SCADA Networks: A Riddle Wrapped in an Enigma

Creators of SCADA security policies should understand that it is not statistically, philosophically, or practically possible to envision all forms of attack that could be mounted against a SCADA system. Defense is more of a matter of how-will-they than it is what-if-they. Only by working with the probable can policymakers achieve the doable. While the strategies mentioned in this paper are by no means the only possible solutions for SCADA security, they are the solutions most effectively implemented by stakeholders of SCADA assets while also being the most effective against modern cybersecurity threats. As this paper has discussed, the main security issue facing SCADA networks is the exposure of the assets in the field. The field is the most vulnerable, the most important, and the most targeted part of SCADA networks. Consequently, the best way to secure SCADA networks is to establish a defense in depth posture that utilizes elements of encryption and field deployed firewalls. 29

26 “Internet Security Threat Report”, Symantec, Vol. 20, April 2015, p. 62 27Ralph Langner, “To Kill a Centrifuge: A Technical Analysis of What Stuxnet’s Creators Tried to Achieve,” Langner, November 2013, http://www.langner.com/en/wp-content/uploads/2013/11/To-kill-a-centrifuge.pdf, p. 22 28 Brian Meixell and Eric Forner, “Out of Control: Demonstrating SCADA Device Exploitation,” Black Hat USA, August 2013, https://www.youtube.com/watch?v=FTzAkEnwx_c, 34:34 29 “21 Steps to Improve Cyber Security of SCADA networks,” The President’s Critical Infrastructure Protection Board: Department of Energy, http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/21_Steps_-_SCADA.pdf, p. 6

For SCADA cybersecurity, “prevention is everything.”30As the blast furnace incident and Black Hat demonstration exhibited, hackers only need to execute normal functions of field devices in order to cause destruction. Unlike hacks on IT, when a field site is hacked there is a possibility that after the attack it will no longer physically exist. Companies have one way to keep field sites safe and that is to stop attackers from accessing the devices in the first place. One of the most efficient ways to defend against unwanted commands being accepted by field devices is to prevent all unauthorized access to the devices. One way to prevent unauthorized SCADA communications is to encrypt the messages being sent between the field devices and the controllers. Encryption is the process of using mathematical equations to encode a message in such a way that only authorized entities are able to read, or decrypt, the message. Basically a very large number is entered into an equation that scrambles messages and the only way to make the messages readable is to know the right number to use for the decryption equation.31 There are two types of encryption: symmetric and asymmetric. In symmetric encryption the large number used for scrambling the message is known as a “secret-key.” The secret-key is unique and is shared between the communicating entities, thus allowing them to encrypt and decrypt messages between them. The sender and receiver are using a copy of the same secret-key, hence the term symmetric. To use SCADA as an example, if a controller wanted to send a symmetrically encrypted message to the field his machine and the target field device would each have a copy of the same secret-key. When the controller sends the message it is scrambled using the key. The field device would then apply its identical key to the message, decrypt it, and execute the command. A symmetric key is not limited to a single pair. An infinite number of devices can use the same key to communicate. This means that the key must be securely stored, because all it would take for a message to be read is obtaining the secret-key. Asymmetric encryption uses four large numbers to generate four unique keys. These keys are created as two pairs. In each pair of keys, the keys are mathematically related to each other in order to establish a relationship. For example, the first pair would be marked as A1 and A2, while the second pair would be marked as B1 and B2. In each pair, one key becomes a “private-key” and another a “public-key.” The private-key is only given to one entity and is used to decrypt messages encrypted with the corresponding public-key. The public-key can be distributed to one or multiple entities and is used solely to encrypt messages sent to the device with the private-key. This establishes a unilateral direction of communication that is more secure than a symmetric key since the only way these messages can be decrypted is with the private-key, which would be harder to steal because it would not be distributed more than one time. In order for two devices to communicate using asymmetric encryption, the sender and receiver would each have a copy of their own private-key and each other’s public key. For example, to send a command to a field device, the controller’s machine would encrypt its message using the target device’s public key, allowing only the target device to decrypt it. Reciprocally, when the field device sends data back to the controller, the field device encrypts its messages using the controller’s public key allowing only the controllers to decrypt and read it. Deploying encryption to field devices would prevent hackers from being able to interpret messages sent to the field devices and would protect the devices from processing commands from unauthorized sources. Since encryption essentially garbles the message so no one but the intended recipient is able to understand it, hackers would no longer have the capability to understand intercepted communications. While this may not seem important, being able to read all traffic from one site would allow hackers to determine what assets are at the site without having to spend the time to manually penetrate every device at the site. Hackers could also record the traffic in order to play it back to the office in order to provide cover for an attack, exactly like what happened in the Black hat demonstration and, in principle, during Stuxnet’s attacks. Even in cases where a particular RTU has a unique register set that does not conform to the company or industry standard, a hacker with enough time could map the registers base on their values and take control of the site. The way SCADA networks are currently setup, field devices generally process all of the commands that successfully navigate to its address. As the German blast furnace demonstrated this is not good policy. Encryption would provide field devices the ability to determine if a command was sent from an entity authorized to access the network. This authentication, would allow the field devices to ignore commands sent by hackers because only the messages encrypted with the appropriate key

30 “Operation Cleaver,” Cylance, December 2, 2014. https://cdn2.hubspot.net/hubfs/270968/assets/Cleaver/Cylance_Operation_Cleaver_Report.pdf, p. 66 31 A sample of an encryption key may be found at the following citation. The number was too large to print. “RSA Numbers,” Wikipedia, https://en.wikipedia.org/wiki/RSA_numbers#RSA-768

would be processed. The only way hackers would be able to successfully send commands to the field devices would be to steal keys, which, while difficult, is not impossible. As this paper mentioned earlier, one of the serious challenges faced by SCADA security is the inability to have the devices in the field rapidly react to hackers. However, encryption gives companies the ability to react to attacks quickly, remotely, and efficiently. One of the reasons encryption is so powerful is because of its ability to be integrated into a Public Key Infrastructure (PKI). A PKI is essentially a way to create and control a series of asymmetric keys. PKI’s use one algorithm in order to create certificates with unique pairs of public and private keys. These certificates can be password protected so that the keys cannot be installed and messages cannot be sent or received unless both the password and certificate were obtained. Each certificate generated can have a unique password, which allows PKI managers to individualize certificates. This individualization adds another layer of authentication to the network. The underlying assumption of forcing a password for certificate installation is that only the individuals with authorization to communicate to field devices will receive one. In order to manage this process PKI’s use a Certificate Revocation List (CRL), which is a list of certificates that no longer have communication privileges. If a machine with a PKI certificate is compromised and that intrusion is detected, a company can add the compromised certificate to the CRL. This effectively isolates the compromised station from the SCADA network and allows SCADA managers to react to threats from their offices. If PKI’s were deployed on the decoy water station mentioned earlier, then the Chinese would have been unable to send commands to the devices. It should be noted, that encryption only protects messages and provides methods of authentication. It does not hide devices. Attempts at securing SCADA networks have failed up to now because they’ve only focused on SCADA’s weaknesses while ignoring its strengths. One of SCADA networks greatest strengths is actually its geography. Because sites are usually remote, it is impossible to have every device connect directly to the office. All communication at a site travels to one device, which then connects to the field network. If that one point of entry can be hidden and protected then the job of hackers is made exponentially more difficult. As Brian Meixell and Eric Forner of Black Hat fame, Symantec, Dell, and the USG stated, the best way to do this is by installing a firewall ”at the device level.”32 Even today SCADA systems owners have difficulty weighing the heavy cost of security measures in terms of systems and manpower overhead versus risk to property and personnel. The fact that it is recommended so often and by so many authorities on SCADA security should weigh heavily in its favor. A firewall at the device level can be configured to only allow traffic through from specific IP addresses, giving the controller’s station more secure control of the field network by blocking out all other possible communication partners. Because a firewall is essentially a more powerful router, it is able to assign new and unique IP addresses to the field device it protects by giving the device a new IP address. Basically, the firewall would take the place of the public IP address and would route traffic from the field network, to a local network that exists only behind the firewall and contains only the field devices. If a hacker wanted to attack an RTU behind a firewall, he would have to now obtain the device’s new IP as well. A firewall can also filter the contents of messages in order to only allow normal site traffic to pass through and block messages that may contain a virus. Without a firewall, a field site is the Achilles’ heel of a company and the country. But with a firewall, each remote location is a veritable Thermopylae, holding back the hordes of hackers.

Conclusion

SCADA and IT teams have created phenomenal networks that are capable of overcoming all of the challenges that physics, meteorology, and accounting bureaucracy place in their way. But today’s problems stem from yesterday’s solutions. The trend of increased SCADA connectivity is mirrored by a trend of frequent hacking attacks. Russia, China, Iran, and the millions of other copycat hackers are scrambling to take advantage of the security gap created by the unsuccessful attempt at applying IT security solutions to SCADA problems. Mitigating these threats will require SCADA security policymakers to focus on the probable in order to achieve the doable. Applying a layered defense to SCADA networks is the best to way combat attackers who come in waves. However, applying the defenses directly to the field would defend the assets at the very points that they are being attacked at. Encryption would protect SCADA networks by adding authentication to the network and preventing hackers from being able to intercept or spoof messages. Firewalls would build off of that, by preventing restricting what messages are able to make it to the field devices.

32 Brian Meixell and Eric Forner ,“Out of Control: Demonstrating SCADA Device Exploitation,” https://www.youtube.com/watch?v=FTzAkEnwx_c, 30:31

Considering what has been discussed and provided by this paper, these recommendations cannot be dismissed as irrelevant to a particular system or impractical for reasons of complexity. Security is not simplicity; it is safety. The tricks and tools used by hackers to attack one type of industry’s network or one particular company’s SCADA are not lost after an attack. Instead the tricks are turned into methods and the tools into weapons. To think that it cant happen to a particular system is to implicitly admit that the system is not SCADA. Therefore, the security recommendations made in this paper must become part of a network before it can truly be considered SCADA. After all, if there’s no safe supervision and no reliable data then all that’s left is control. Then the real question is who is really in control?