1. 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/

2. 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/

3. 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

4. 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/

5. 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/

6. 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
27
Ralph 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

7. 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

8. 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

9. 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?