Network Scanning Industrial

Control Systems
A Vulnerability Analysis

Mathias Jore Ljøsne

Master’s Thesis Autumn 2019
Abstract

Every industry is getting increasingly more and more digitalized. Internet

protocol devices are being more used because companies and their man-
agers want the possibility of being remotely connected while working, as
well as the fact that its widely known and low cost. This includes in indus-
tries that are critical for our society, like the energy industry or in water
treatment. Increased digitalization and components that are connected to
networks means there are ways to reach those components from the outside,
potentially with the intent to infiltrate or take down.
This thesis investigates what industrial components in a simulated power
station can handle when it comes to network traffic, and what it takes to
negatively influence them.
The simulated power station was in a lab created and managed by
KraftCERT in cooperation with NSM. The lab uses software and hardware
that actually are in use in power stations in both Norway and abroad. I was
allowed to create a plan of tests and run the tests on the simulated system
they’ve made to witness and log the results.
I managed to both negatively affect and take down components with normal
use of a network scanner and other tools. With this in mind, it’s critical
that the manufacturers fix these problems in future devices, the industry
that uses these devices takes these results into account and think of the pos-
sible consequences when integrating network communication with industrial
components that is now being done more and more.

i
ii
Acknowledgements

I would like to thank my supervisor Audun Jøsang for the guidance and
encouragement throughout this project. Next I would like to thank my ex-
ternal supervisors Janne Merete Hagen from the Norwegian Water Resources
and Energy Directorate (NVE) and Nils Petter Wien from the National Se-
curity Agency (NSM) for their guidance and help. Furthermore, I would
like to thank Lars Erik Smevold from KraftCERT for the guidance and help
he provided when it came to working with the lab.
I also want to thank my family and friends for all their support and encour-
agement during my time at the university and through this master thesis.

iii
iv
Contents

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Research Question . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Relevant Literature 5
2.1 SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 ICS assets . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Network architectures . . . . . . . . . . . . . . . . . . 9
2.1.3 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Control System Operations . . . . . . . . . . . . . . . 11
2.1.5 Control Process Management . . . . . . . . . . . . . . 13
2.1.6 Smart Grid Operations . . . . . . . . . . . . . . . . . 14
2.2 IT sec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 SCADA sec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Vulnerability Analysis of Network Scanning on
SCADA Systems . . . . . . . . . . . . . . . . . . . . . 30
2.4 Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Research Methodology 39
3.1 Technologies used . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.2 Hping3 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.3 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.4 Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.5 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 My setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Results 51
4.1 The ABB system . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Attacks that affected the system . . . . . . . . . . . . 51
4.1.2 Attacks that had no effect . . . . . . . . . . . . . . . . 52
4.2 The Siemens system . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 Attacks that affected the system . . . . . . . . . . . . 53
4.2.2 Attacks that had no effect . . . . . . . . . . . . . . . . 54

v
 4.3 Other tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Discussion 57

6 Conclusion 61
6.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

vi
List of Figures

2.1 A typical industrial network. . . . . . . . . . . . . . . . . . . 6

2.2 The SCADA DMZ . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 A typical smart meter network . . . . . . . . . . . . . . . . . 14
2.4 Graph showing connection between sophistication of threat
and likelihood of attack . . . . . . . . . . . . . . . . . . . . . 17
2.5 How to identify critical assets . . . . . . . . . . . . . . . . . . 18
2.6 A broad attack surface . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Seperating into functional groups reduces the attack surface . 20
2.8 Defense-in-depth . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 Stuxnet’s infection processes . . . . . . . . . . . . . . . . . . . 38

3.1 Diagram of the ABB setup . . . . . . . . . . . . . . . . . . . 45

3.2 Diagram of the Siemens setup . . . . . . . . . . . . . . . . . . 46
3.3 Photo of the Siemens setup . . . . . . . . . . . . . . . . . . . 47
3.4 Photo of the Siemens setup . . . . . . . . . . . . . . . . . . . 47
3.5 Photo of the Siemens setup . . . . . . . . . . . . . . . . . . . 48
3.6 Photo of the Siemens setup . . . . . . . . . . . . . . . . . . . 48
3.7 Photo of the Siemens setup . . . . . . . . . . . . . . . . . . . 49

4.1 Screen capture from some attacks done on the Siemens system 54

vii
viii
Acronyms

ix
x
Chapter 1

Introduction

1.1 Background

The world produces more than 100’000 TWh of power every year. A lot of
critical systems in many different industries rely on power being available
at all times. Attacks directed at industrial control systems could potentially
be devastating for the economy, public safety, industries, or even a country’s
defensive capabilities.

The world around us is getting increasingly more digitalized and connec-

ted. This means that the amount of vulnerabilities and points of weakness
increases and that the need for research and focus on defense and security
increases as well. It’s something that affects every type of business, industry
in the modern world and will only continue to increasingly affect everyone.
Industrial control systems is an area of particular importance. A directed
attack could knock out critical systems at times of extreme importance.

Traditionally, Industrial Control Systems (ICS) were isolated systems run-

ning proprietary control protocols using specialized hardware and software.
Often in physically secure areas and not connected to Information Techno-
logy (IT) or networks. Internet Protocol devices are taking over now because
they are widely known and low cost to use. This, of course, increases the
possibility of cyber incidents. IC systems differ from typical IT systems in
one big way, ICS has a direct effect on the physical world. Some charac-
teristics include significant risk to the health and safety of human lives and
serious damage to the environment, as well as serious financial issues such
as production losses, negative impact to a nation’s economy, compromise of
proprietary information and more. [10]

Three examples of attacks on ICS are the infamous Stuxnet-worm and the
December 2015 and 2016 Ukraine power grid attacks. Stuxnet targeted
SCADA systems and caused damage to Iran’s nuclear weapons program.
The Stuxnet worm targeted centrifuges and made them tear themselves

1
apart. The prior example is considered to be the worlds first known suc-
cessful cyberattack on a power grid. The results were temporarily disrupted
electricity supply to over 200’000 end consumers for 1 to 6 hours.
Just this march, less than a month ago as of writing, United States’ De-
partment of Homeland Security and Federal Bureau of Investigation issued
an alert about Russian government actions targeting U.S. Government en-
tities and organizations in the energy, nuclear, commercial facilities, water,
aviation, and critical manufacturing sectors and their industrial control sys-
tems. This makes it clear that these sorts of threats are ever-present and
growing more serious.

These threats are something most countries should take very seriously, in-
cluding Norway. We need more research done on potential weaknesses, our
defensive capabilities, and where in the digital chain potential security holes
are.

1.2 Motivation

When I have been studying subjects related to industrial computer systems,

or read discussions online, people always claimed industrial hardware can’t
handle network traffic and will crash from just a ping, so it’s very insecure.
When I started researching this I found it was hard to find concrete data
about it. This lead me to thinking that maybe I could incorporate it into
my thesis work and find something that can be practical for future use and
research in industrial systems.

“The analysis of sources within this document suggests that a better un-
derstanding is needed about how network scanners interact with SCADA
networks . . . It is clear that network scanners must be directly tested against
nonoperational SCADA devices in order to report on how the two techno-
logies interact and whether the are compatible” [11].
". . . it is evident that minimal research has been conducted which emphas-
izes the devastating consequences of an active scan and whether it causes
disruption to ICS and SCADA field equipment." [11]

The ports which control the transfer of SCADA/ICS data run on insec-
ure protocols, where even a single unexpected packet could cause a system
overhaul and could stop the normal function of the equipment entirely. As
these devices are the interface between networks and industrial assets such
as pumps, turbines, and sensors, this could have significantly damaging con-
sequences. [11]

Because many industrial network protocols are sensitive to latency and/or

latency variation (jitter), any large amount of introduced network traffic
could cause a failure. Aggressive scans that actively probe many addresses
and ports in rapid succession could overwhelm an industrial network. Like-

2
wise, broad scans that attempt to penetrate through multiple network hops
could unintentionally reach and disrupt a process control system. Because
of this, vulnerability scans should be performed differently depending upon
what the network it is scanning; in a non-production test environment, both
hard and soft scans methods should be used; while in production environ-
ments, only soft scan methods should be used. By subjecting an industrial
system to aggressive scanning techniques in a test environment, it can be
determined if the scan will actually disrupt the network, and if so how. [4]

There is a caveat when scanning industrial networks; because many indus-

trial network protocols are extremely sensitive to latency and/or latency
variation (jitter), a “hard scan” could actually cause the industrial network
to fail. The lesson here is that, if the intention is disruption of services, all
it takes is a simple network scan to achieve your goal. [4]

1.3 Research Question

The purpose of this thesis is to look at how industrial hardware components

react to network traffic.
If there is a difference between how the devices react depending on which
manufacturer made them or their type. If it’s possible to block all traffic,
increase latency, or crash the devices, and what it takes to do each.
The current research question and research area:
• Research aim: Explore if it’s possible and what it takes to negatively
affect industrial components with network traffic as well as map the
differences between manufacturers.
• Can normal use of network scanning tools negatively affect or take
down industrial components? If it’s not possible, what does it take?

1.4 Scope

In this thesis I will be testing on a simulated power station with PLCs and
DCS that are used in real power stations today in Norway. The lab is set
up and maintained by KraftCERT in cooperation with NSM.
Since I’ll be interacting with the industrial components directly, the tests are
not supposed to be simulating an attack coming from outside the network.

1.5 Thesis Structure

In chapter 2 Relevant Literature, I will be going through background in-

3
formation and relevant literature.
In chapter 3 Research Methodology is about what technologies and methods
I have used in the testing, and how the testing platform is set up.
In the 4th chapter Results I go through the results I got through the testing
I did.
In chapter 5 Discussion I discuss the results and my thoughts on them.
In chapter 6 I write my conclusion from the tests and discussion.

4
Chapter 2

Relevant Literature

This chapter presents related background information and research from

relevant literature. First, I give an introduction to what SCADA is and how
it works. Second, I go into classic computer security before finally going
over industrial network security and a very relevant article.

2.1 SCADA

An industrial network is typically made up of several distinct areas. Super-

visory Control and Data Acquisition (SCADA) is one part of an industrial
network, separate from the control systems. ICS (Industrial Control Sys-
tem) is another part of the industrial network and consists of combinations of
control components (electrical, mechanical, hydraulic, pneumatic are some
examples), actors, supervision, that act together to achieve an industrial
objective (e.g. manufacturing, transportation of matter or energy), while
SCADA refers to the supervision and control center system. The ICS can
also be called DCS (Distributed Control System) or PCS (Process Control
System). The two terms are often misunderstood and used interchange-
ably, leading to more inaccuracies and misinformation. SCADA is used as
an interface between humans in the management center and the industrial
equipment, hardware, and machines to control and maintain. It is also used
to monitor and control water, oil and natural gas distribution, including
pipelines, ships, trucks, and rail systems, as well as waste water collection
systems. SCADA Systems are designed to collect information from the field,
transfer it to a central computer facility, and display the information to the
operator graphically or in text, thereby allowing the operator to monitor or
control an entire system from a central location in near real time [10] [4].
Figure from [4] below shows a typical Industrial Network.

Several different protocols for communication are used. Some are developed
specifically to be used in systems provided by the individual supplier, these
are so called proprietary protocols. Standardized protocols are also used,
like the Internet Protocol (IP). A human operator uses a Human-Machine

5
Figure 2.1: A typical industrial network.

6
Interface (HMI) system to monitor and control the industrial components.
The HMI presents a graphical user interface (GUI) that displays the status
of switches, generators, alarms, events, and other relevant information in a
way that’s easy to understand for humans. The system collects data from
sensors and processing unites, processes it and stores it in a server. Critical
servers and components are arranged with backup components providing
redundancy in case of events so the system could be brought back up again
promptly. SCADA systems used to be entirely separated from the adminis-
trative systems, but now it’s common that it’s in its own network and can
communicate with the use of protocols under strict security requirements.
At the customers end, measurement values are sent to the Automated Meas-
uring and Control System (a Norwegian system called AMS) which passes
it on to the distributor. The distributor uses the Distributed Management
System (DMS) to monitor the distribution grid in real-time. The distributor
uses this system to monitor activity in the grid, but they also have software
they can use to disconnect customers. In the future, AMS will be able to
connect with SCADA systems through the DMS. [8]

SCADA systems are usually fault-tolerant with significant redundancy built

into them. Though redundancy may not be a sufficient countermeasure
against a malicious attack. An average SCADA system has 30’000 to 50’000
data collection and control points and because of this, using SCADA systems
is viewed as a necessity for effective energy management. ICCP/TASE.2 is
the primary protocol used to communicate information between the energy
control centers that operate with SCADA systems and between control cen-
ters and power generators. It has also begun to be used for communications
between control centers, remote terminal units, and substations. [13]

2.1.1 ICS assets

An industrial control system can be built up using a wide range of different

assets. Here I’ll give a brief overview over the most common ones. [4]

IEDs
Intelligent Electronic Device. Any device commonly used in control systems,
e.g. sensor, actuator, motor, transformer, circuit breaker, pumps, has small
microprocessor that enables digital communication. Communicates using
fieldbus protocols, as slaves, controlled by either an RTU or a PLC. They
are now growing more advanced, blurring the lines between device types. [4]

RTUs
Remote Terminal Unit. They reside in a substation or other remote location
where it monitors field parameters, transmits data to central monitor sta-
tion which is typically either a Master Terminal Unit (MTU), or a centrally
located PLC, directly to an HMI system. It includes remote communica-

7
tion capabilities consisting of a modem, a cellular data connection, radio, or
another wide area communication capability. They typically use industrial
network protocols like DNP3 to communicate between master and remote
units and DNP, Modbus, Profibus or other fieldbus protocols to commu-
nicate with IEDs. RTUs and PLCs continue to overlap in capability and
functionality with many RTUs integrating programmable logic and control
functions, RTU can be thought of as a remote PLC. [4]

PLCs
Programmable Logic Controller. A PLC is a specialized computer used
to automate functions in industrial networks. They are often materially
hardened so that they are suitable for a production floor, specialized for in-
dustrial uses with multiple specialized inputs and outputs. They don’t run
an OS, but rely on blocks of logic code. This allows PLCs to function auto-
matically to specific inputs with little overhead. The PLCs typically only
control real-time processes since they are designed for efficiency. E.g. when
producing plastic, you may need a catalyst injected into a vat when the
temperature reaches a very specific value. It could be difficult to precisely
time the injections which can result in quality issues if processing overhead
or other latency introduced delay in the execution. [4]

Ladder logic
Often used in PLCs, it’s a simplistic programming language that is well
suited for industrial applications. Based on relay-based logic, it can be
thought of as a set of connections between inputs (contacts) and outputs
(coils). It’s written using software on PC and then programmed onto a PLC
by connecting it to a PC and transferring the code. [4]

HMIs
Human Machine Interface. HMIs are used as operator control panels to
PLCs, RTUs, sometimes IEDs. It replaces manually activated switches, di-
als, and other controls with graphical representations of the control process
and digital controls that influence that process. HMIs allow operators to
start, stop cycles, adjust set points, perform other functions required to
adjust and interact with a control process. They’re software based and re-
place physical wires and controls so they can be adapted and adjusted easily.
They also act as a bridge between operator and the complex logic of PLCs,
allowing the operator to function on the process rather than the underly-
ing complex logic, through graphical representation of the process being
controlled, as well as sensor values, other measurements, representation of
output states (which motors are on, which pumps are activated etc.). [4]

Supervisory workstations
Collects information from assets and presents the information for supervis-
ory purposes. Unlike on an HMI, the information is read-only. A supervisory
workstations typically consists of either an HMI system or a data historian
and can reside within the SCADA DMZ or within the business network. [4]

8
Data historians
Data historians are specialized software systems that collects point values
and other info from industrial devices and stores them in databases. Spe-
cifically designed to collect a running audit trail of control system opera-
tional data. Data points are referred to as “tags” and can represent almost
anything – current frequency of a motor/turbine, rate of airflow through
a heating, ventilation, and air-conditioning system (HVAC), total volume
in mixing tank, specific volumes of injected chemical catalysts in a tank,
etc. Since the information stored within is often used by both industrial
operation and business management, they are often replicated across an in-
dustrial network. They can be a security risk as a data historian in a less
secure zone (i.e. the business network) could be used as an attack vector
into more secure zones like the SCADA DMZ, so data historians should be
isolated and patched regularly. [4]

Business Information Consoles

Extensions of supervisor workstations designed to deliver business intelli-
gence information to upper management. Typically consists of read-only
representations of the same data obtained from HMI or Data Historian sys-
tems. In some cases, it’s a computer display connected to an HMI or His-
torian within the SCADA DMZ, but physically located somewhere else like
an executive office or trading floor. In these cases, the display is remotely
connected using a remote display or secure remote Keyboard Video Mouse
switching system. Any published data should be access controlled and any
open communication path from the SCADA systems to more openly access-
ible workstations or portals should be very carefully controlled, isolated, and
monitored. [4]

Other assets
There are many other assets that may be connected to an industrial network
other than PLCs, RTUs, HMIs, Historians and various workstations. E.g.
printers and print servers may be connected to corporate networks, or may
connect directly to a control loop. Physical access control systems like badge
scanners, biometric readers may be used as well as they may be networked.
It’s important to recognize that every device has a potential security impact
and should be assessed if it’s connected to a network of any kind or capable
of transporting data or files. [4]

2.1.2 Network architectures

The primary requirement of an industrial automation system is real-time op-

eration and reliability while the primary requirement of a business network
might be high bandwidth and low operation costs. These requirements drive
the use of real-time fieldbus protocols within control system processes and
control loops and business networks use fast, low-cost Ethernet networks
and TCP/IP. The SCADA systems sit between these two. SCADA shares

9
 Figure 2.2: The SCADA DMZ

some requirements of the control system – e.g. they need to be able to op-
erate in real time, but must also communicate with business systems over
TCP/IP. Which is why a DMZ is recommended for supervisory systems. A
SCADA DMZ sits between the operational and automation systems they are
supervising and controlling, and the business networks and business inform-
ation systems. A DMZ is protected from both directions, using firewalls,
intrusion detection/prevention system, a data diode, or other perimeter de-
fensive mechanisms to prevent unauthorized traffic from crossing into our
out of the DMZ. This creates three network areas - business, supervisory,
and operations. Like this figure from [4] shows. Operational and automation
systems contain PLCs, RTUs, IEDs, and HMIs. SCADA DMZ also contain
HMI systems, Data Historians, MTUs (connecting to remote facilities), Inter
Control Center Protocol (ICCP) clients and servers for communicating with
peer systems. Business networks contain common computing and business
systems, supervisory workstation, and replicated Data Historians. [4]

2.1.3 Topologies

SCADA and industrial control system networks may utilize bus, ring, star,
and tree topologies depending upon the specific type of control process that
is in operation and the specific protocols that are used. For example, an
automated control process to sanitize water may use a bus topology with
the Modbus protocol, while another control process may use Profibus in a
ring topology to control pumping or filtration systems. The SCADA DMZ
must communicate to both sides, on one side a number of industrial net-
work protocols and on the other side corporate Ethernet TCP/IP networks
making the SCADA DMZ require protocol gateways to translate between
the environments. These can be standalone network devices or they can
be built-in functions of the MTUs, HMIs, PLCs, etc. The specific topology
used has little impact on the security of any particular network. The bound-
ary of a network area is more important, as it will help to determine how an
attacker can migrate between systems, as well as the protocols used within
a network area, which can help determine how a specific network area can
be vulnerable. [4]

10
One area that deserves special consideration when it comes to special topo-
logical considerations is the smart grid. It’s an extensive network providing
advanced metering and communications capabilities to power distribution
so it’s specific to the energy industry, but also a concern for any industrial
network that may be connected to the smart grid as a client of the energy
industry.
In terms of an addressable attack surface, smart grids provide broad and easy
access to a network that ultimately interconnects to our energy transmission
and distribution system, as well as to many interconnected homes and busi-
nesses. It’s a distribution system designed to deliver power universally to
residences, offices, storefronts, and all aspects of urban infrastructure, even
small smart grid deployments create large numbers of nodes and network
interconnections, often in hundreds of thousands or even in millions. The
attack surface grows exponentially larger as you radiate outward from the
energy generation through to the outer reaches of the smart grid.
Scalability is another important role in the development of smart devices.
All devices deployed at such large-scale has to be as efficient to build, deploy,
and operate as possible. Because of the costs and complexity of providing
security assurance and testing in the various supply, design, and manufac-
turing stages of Smart Meter development, this business driver is a real
concern. When the pressure forces costs down, it increases the chance that
some physical or network-based vulnerability will find its way into produc-
tion, and therefore into one of the most easily reachable networks every
built. [4]

2.1.4 Control System Operations

Typical industrial operations are made up of several layers of programmed

logic designed to manipulate mechanical controls in order to automate the
operation. Control loops automate a specific function, multiple control
loops may be combined or stacked together in order to automate larger
processes. [4]

Control loops
Industrial networks are made up of many specific automated processes that
are called control loops. “Loop” derives from the ladder logic that is widely
used in such systems. A controller device, like a PLC, is programmed with
specific logic. The PLC cycles through the inputs, using the logic to adjust
outputs or controls, in the end serving a specific function, which the “loop”
automates.
Closed loops provide automated control, while open loops provide manual
control. In closed loops, the output affects the input, fully automating it.
I.e. a water heater is programmed to heat water to 90 degrees C. An electric
heating coil is turned on to heat the water until the water is measure at 90

11
degrees, which is when it will turn off. This would be a closed loop since
it takes the water temperature as input to check if it’s reached yet. With
an open loop the output of the water heater does not affect the inputs, so
the water heater have to be manually engaged independent of current wa-
ter temperature. Control loops can be very simple. Sometimes they just
use one single input and have one single output. More complex loops can
need multiple inputs, like pressure, volume, flow, and temperature sensors,
and adjust multiple outputs, like valves, pumps, heaters, to perform a more
complex function – in this case, maintaining constant pressure in a dynamic
fluid system. More complex control processes may need multiple control
loops to perform. They may be controlled by a central HMI or they may
be part of a larger control loops, as inputs or outputs into another level of
logic, controlled by a master or central PLC. [4]

Control processes
“Control process” is a general term used to define larger automated process
in an industrial setting. Many control processes could be needed in industrial
processes like manufacturing a product or to generate electricity, and each
of these processes may consist of one or several control loops. Each of the
processes are managed by an HMI. An HMI will typically provide relevant
readings from control loops. Some HMIs may provide readouts of sensors
and other feedback mechanisms as well as the activity of the PLCs, while
others may issue direct control operations and provide controls to adjust
the ongoing control process. Since an HMI may control a process consisting
of several control loops, its network connectivity is typically heterogenous
– connecting over routable protocols like TCP/IP as well as SCADA and
fieldbus protocols etc. to the various PLCs and RTUs that make up the
loops. Because of this, HIMs are a common attack vector between the rout-
able SCADA and business networks. [4]

Feedback loops
The centralized information management of an industrial system is usually
performed by one or several Data Historian systems. The process of extract-
ing data from a real-time environment of an industrial automation process
and storing it continuously over time is called “historizing” the data. Once
that’s done, the information can be analyzed, either from within the Data
Historian or by using an external analysis tool. Because of the heterogenous
nature of many industrial operations, where different processes may utilize
assets by different vendors, there’s a need for a common Data Historian that
historizes all data across systems. All the processes has to be evaluated hol-
istically to manage and fine-tune the overall operations. [4]

Business information management

Operational monitoring and analysis provide valuable information that can
be used by business management to fine-tune and improve operations, effi-
ciencies, minimize costs, and maximize profits. Because of this, there is a
need for replication of the operational process data into the business net-
work. Supervisory data can be accessed using an HMI or a Data Historian,

12
each of which presents its own security challenges. Since HMIs provide both
supervisory and control capabilities, an HMI user with the correct privileges
can adjust parameters of control processes. By placing an HMI outside of
the SCADA DMZ, any firewalls, IDS/IPS, and other security monitoring
devices that are in place will need to be configured to allow the commu-
nication of the HMI into and out of the SCADA DMZ which will in effect
reduce the strength of the security parameter between the SCADA and busi-
ness networks to user authentication only. If a user account is compromised
on the outside HMI system, it can be used to manipulate the control pro-
cesses without further validation from perimeter security devices. Using a
Data Historian for business intelligence management presents a similar con-
cern. The security perimeter must be configured to allow communication
between the Data Historian in the business network and the various sys-
tems within the SCADA DMZ that need to be monitored. Unlike an HMI,
a replicated Data Historian does not allow control of the process, instead,
the Data Historian provides a visual dashboard that can be configured to
mimic the informational qualities and graphical representation of an HMI
so that information about a process can be viewed in a familiar format. [4]

2.1.5 Control Process Management

A control process is initially created through the programming of PLCs to

build a control loop. In a fully automated loop, the process is controlled
through the comparison of established set points against various inputs.
In a water heater for example, a set point might be used to establish the
high-temperature range of 90 C and an input would take the temperature
measurements from a sensor within the water heater tank. The PLCs logic
would then compared the input to the set point to determine whether the
condition as been met or not, and in this example disengaging or engaging
the heater element. When an operator manages a control process, he uses
real-time information about the state of the process from an HMI to determ-
ine whether manual intervention is required (open loop) or adjustments to
established set points are required (closed loop). The HMI facilitates both,
by providing software controls to adjust the various set points of a control
loop while also (typically) providing controls to directly affect the loop.
If an attacker is able to successfully compromise the HMI, fully automated
systems can be permanently altered through the manipulation of set points.
For example, by changing the high-temperature set point to 100 C, the wa-
ter in a water heater thank could boil, potentially increasing the pressure
enough to rupture the tank. Direct changes to a process loop’s output con-
trols can also be forced by an attacker. In this example, the water heater’s
coil could be engaged manually by the attacker. [4]

13
 Figure 2.3: A typical smart meter network

2.1.6 Smart Grid Operations

Smart grid operations consist of several overlapping functions that are

intercommunicating and interacting with each other. Included here are
Customer Information systems, Billing Systems, Demand Response systems,
Meter Data Management Systems, and Distribution management systems.
These systems communicate with an Advanced Metering Infrastructure
(AMI) headend, which feeds local distribution and metering. The AMI
headend will typically connect to a large number of Smart Meters, serving a
neighborhood or urban district, which in turn connect to home or business
networks. Shown here on a model from [4].

The Customer Information system supports the business relationship

between the utility and the customer and may connect to both the customer
premise via customer service portals as well as the utility back-end systems.
Meter Data Management systems store data, including usage statistics,
energy generation fed back into the grid, Smart Meter device logs, and
other meter information, from the Smart Meter. Demand Response systems
connect to Distribution Management systems and Customer Information
systems as well as the AMI headend to manage system load based on
customer demand and other factors. Smart grid deployments consist of
multiple AMI headends, which may interconnect via a mesh network (where
all headends connect to all other headends) or a hierarchical network (where
multiple headends aggregate back to a common headend), and may support
hundreds of thousands or even millions of meters. All of this represents a
very large and distributed network of intelligent end nodes that ultimately
connects back to energy transmission and distribution. The benefits of this
allow for intelligent command and control of energy usage, distribution and
billing. The disadvantage of such a system is that the same end-to-end
command and control pathways could be exploited to attack one, any, or all
of the connected systems.
A list of specific threats concerning smart grids, from [4]:
• Bill Manipulation/Energy Theft – an attack by an energy consumer

14
 with the goal of manipulating billing information to obtain free energy
• Unauthorized Access from Customer End Point – use of an intelligent
AMI end node (a Smart Meter or other connected device) to gain
unauthorized access to the AMI communications network
• Interference with Utility Telecommunications – use of unauthorized
access to exploit AMI system interconnections in order to penetrate
the bulk electric generation, transmission, and distribution system
• Mass Load Manipulation – the use of mass command and control to
manipulate bulk power use, with the goal of adversely affecting the
bulk electric grid
• Denial of Service – using intelligent nodes to communicate to other
nodes in a storm condition, with the goal of saturating communications
channels and preventing the AMI from functioning as designed
The AMI headend is a prime target due to its central position in the smart
grid: all end nodes, business systems, operational systems, and distributed
control systems connect to (or through) the headend. Compromise of the
AMI headend would provide a vector of attack to many systems. Similarly,
if any other connected system were compromised the next hop would likely
be to the headend. Therefore, all inbound and outbound communications
at the headend should be carefully monitored and controlled.

2.2 IT sec

Confidentiality, integrity and availability, also known as the CIA triad, is

a model designed to guide policies for information security within an or-
ganization. The elements of the triad are considered the three most crucial
components of security. In this context, confidentiality is a set of rules that
limits access to information, integrity is the assurance that the information
is trustworthy and accurate, and availability is a guarantee of reliable access
to the information by authorized people.
Confidentiality is roughly equivalent to privacy. Measures undertaken to
ensure confidentiality are designed to prevent sensitive information from
reaching the wrong people, while making sure that the right people can in
fact get it. Access must be restricted to those authorized to view the data
in question. It is common, as well, for data to be categorized according to
the amount and type of damage that could be done should it fall into unin-
tended hands. More or less stringent measures can then be implemented to
those categories.

Integrity involves maintaining the consistency, accuracy, and trustworthi-

ness of data over its entire life cycle. Data must not be changed in transit
and steps must be taken to ensure that data cannot be altered by unau-
thorized people. These measures include file permissions and user access

15
controls. Version control may be used to prevent erroneous changes or ac-
cidental deletion by authorized users becoming a problem. In addition,
some means must be in place to detect any changes in data that might
occur as a result of non-human-cause events such as electromagnetic pulse
or server crashes. Some data might include checksums, even cryptographic
checksums, for verification of integrity. Backups or redundancies must be
available to restore the affected data to its correct state.

Availability is best ensured by rigorously maintaining all hardware, perform-

ing hardware repairs immediately when needed and maintaining a correctly
functioning operation system environment that is free of software conflicts.
It’s also important to keep current with necessary system upgrades. Provid-
ing adequate communication bandwidth and preventing the occurrence of
bottlenecks are equally important. Redundancy, failover, RAID even high-
availability clusters can mitigate serious consequences when hardware issues
do occur. Fast and adaptive disaster recovery is essential for the worst
case scenarios; that capacity is reliant on the existence of a comprehens-
ive disaster recovery plan. Safeguards against data loss or interruptions in
connections must include unpredictable events such as natural disasters and
fire. To prevent data loss from such occurrences, a backup copy may be
store in a geographically-isolated location, perhaps even in a fireproof, wa-
terproof safe. Extra security equipment or software such as firewalls and
proxy servers can guard against downtime and unreachable data due to ma-
licious actions such as denial-of-service attacks and network intrusions.

2.3 SCADA sec

[4] defines critical infrastructure as public utilities like water, gas, and oil,
as well was bulk electric energy, nuclear energy, chemical manufacturing,
agricultural and pharmaceutical manufacturing and distribution, and some
aspects of banking and finance. Basically, anything whose disruption could
impact a nation. Bulk electric energy is split in energy generation and distri-
bution. Generation concerns the safe production of energy while distribution
concerns the safe distribution of the product. They are highly intertwined,
but they each have their own nuances and special security requirements. All
other industries rely upon power and energy to operate, so the security of
the energy infrastructure impacts everything else.
The use of the smart grid is spreading around the world. It’s the use of
digital communications for metering and intelligent use of electricity, which
raises several new security concerns. Because of the given danger in both
the fueling and operation of nuclear facilities as well as the national security
implications of the raw materials that are used, unique safety and security
challenges present themselves. This and the possible consequences of an at-
tack makes nuclear facilities a prime target for cyber attacks. This goes for

16
Figure 2.4: Graph showing connection between sophistication of threat and
likelihood of attack

chemical facilities as well. They need to keep their intellectual property safe
as well as their control systems. Their product itself has value, both finan-
cially and as a weapon. A disruption at a pharmaceutical could be used as a
social attack by impacting the production of a specific vaccine or antibody,
or the theft of hazardous chemical can be used directly as weapons or to
fuel illegal chemical weapons research or manufacture so there also must be
focus on securing the storage and transportation of it. [4]

The likelihood of an attack happening decreases with the sophistication of

the threat, but the consequences grow. [4] has modelled this in a figure.
It’s important to implement security to lessen the chance of serious, though
uncommon, attacks happening and to avoid the devastating consequences.
INS:2 mentions several relevant standards and organizations, but most of
them only cover America. Both ANSI/ISA 62443, formerly called ISA-99,
and ISO27002 come from international organizations so their use is spread
worldwide. It was created by the International Society for Automation
(ISA), but publicly released by the American National Standards Institute.
ANSI/ISA 62443 is a series of standards, technical reports and related in-
formation that define procedures for implementing secure industrial auto-
mation and control systems. It works by attempting to classify functional
areas of an industrial system into specific security levels and then provides
recommendations for separating these areas into zones. ISO27002 is pub-
lished by the International Standards Organization (ISO) and the Inter-
national Electrotechnical Commission (IEC) and is a collection of security
recommendations. It’s not specific to industrial network security as it defines
“Information technology – Security techniques – Code of practice for inform-

17
 Figure 2.5: How to identify critical assets

ation security management”. ISO standards are widely used internationally

and covers a big range of topics and areas. [4]

Many of the security practices and principles that are required or recom-
mended by national and international organizations are consistent and very
alike each other so [4] have grouped the most common and most important
recommendations into a short list. They consist of the following steps:

• Identifying what systems need to be protected

Identifying what assets that need to be secured and identifying
individual importance for the operation of the system is necessary
because it tells you what should be monitored, how closely it should
be monitored, how to logically segment the network into high-level
security sectors and it helps to indicate where the point security
devices, such as firewalls and IDS/IPS systems, should be placed.
As an example, they’ve shown a process diagram made by the U.S.
Nuclear Regulatory Commission on how to identify critical assets.
However, they note that in larger operations the shown method may
be over simplified and that there may be need for different levels of
“criticality”.

• Separating the systems logically into functional groups

Separating parts of the system allows more control and is an easy
way of reducing the attack surface. By simply disallowing all traffic
on unnecessary ports and services, you eliminate the chance of those
services being exploited through known or unknown vulnerabilities.
If several services are behind a single common firewall, it may be
necessary to allow several different traffic profiles through the firewall.
An attack focusing on a weakness in a single service may end
up compromising a variety of services. If each service is grouped
by function and separated from other services, the firewall can be
configured to only allow the necessary data for the service. Since
there are many distinct functional groups within an industrial network
that should not be communicating outside the established boundaries.

18
 Figure 2.6: A broad attack surface

Industrial network protocols like Modbus are specific for ICS and
SCADA systems so they should never be used within the business
network. Likewise, internet services like HTTP, FTP should never
be used within control network areas. [4] have used two models to
showcase this.
• Implementing a defense-in-depth strategy around each system
All standards organizations and regulations recommend that a defense-
in-depth strategy should be implemented. [4] used a figure to illustrate
a common defense-in-depth model that maps logical defensive levels
to common tools and techniques.
• Controlling access into and between each group
By strictly controlling access privileges and services available to
users, it becomes more difficult for an attacker to gain access and
exploiting systems. Implementing access control successfully can be
quite challenging because of the complexity of managing users, their
roles, and mapping that to specific services and rights related to their
responsibilities. The more layers of complexity used in the rules of
authentication and access, the more difficult it will be for an attacker.
Some examples of advanced access control include the following:
– Only allow a user to log in to an HMI if the user has successfully
badged in to the control room (user credentials combined with
physical access controls)
– Only allow a user to operate a given control from a specific
controller (user credentials limited within a security enclave)

19
Figure 2.7: Seperating into functional groups reduces the attack surface

20
Figure 2.8: Defense-in-depth

21
 – Only allow a user to authenticate during that user’s shift (user
credentials combined with personnel management)

[4]

The big difference between ICS and IT systems is that ICS control processes
in the physical world, but IT systems manage digital data. [10]. ICS include
risks to the health and safety of human lives, potential damage to the
environment, financial issues like production losses and negative impact to
a nation’s economy or security. ICS and IT have different performance and
reliability requirements because of what the operations entail. There is a
heavy focus on system and data integrity and availability from the CIA triad
during normal operations as well as during attacks. It’s more important to
keep an IC system running properly and available than to keep the data
secret in these systems.
The different groups of attackers that target IC systems range from "script
kids" to state sponsored hackers. Each have different motivations and levels
of competence. A list, from [1] follows.

• State hackers In 2009 McAfee reported that over 120 countries had
or was in the process of creating cyber warfare capabilities. The huge
amount of funding available from governments mean they can hire
the best hackers and large investments can be made into research
and finding new zero-day exploits. Governments can potentially
stockpile zero-day exploits for when they need them. Only one publicly
documented attack on SCADA systems has happened by state agents
and that is Stuxnet. It was developed to attack Iran’s nuclear program.
State sponsored hackers are the biggest threat to SCADA systems
because of their near limitless resources.

• Terrorists Though there haven’t been any distinctive SCADA

cyber terrorism attack yet, there is evidence that suggests they are
interested. In the early 2000s FBI discovered intrusions in government
websites originating in the Middle East and South Asia. At a later
time U.S. intelligence officials found more evidence of surveillance of
American infrastructure on seized Al Qaeda systems. Furthermore
it has been suggested that terrorists are interested in attacking
infrastructure digitally, but don’t have the necessary skills yet.

• Organized crime Organized crime is motivated by money so holding

companies for ransom by targeting and attacking their SCADA system
is possible. They are also likely to have access to funding so hiring
skilled hackers, buying attack tools or zero-day exploits from the
underground markets are possible.

• Disgruntled employees or inside attackers The most common

internal perpetrator is as with many other systems, the disgruntled
employee. Since inside attackers already have authorized access to the
system they effectively bypass the perimeter defences like firewalls and
traffic analysis of inbound and outbound data.

22
 • Hobbyists Hobbyists usually look for a thrill or a challenge, or
sometimes their intentions could seem harmless and claim they’re
just exploring. A hobbyists inquisitive nature could end up being
destructive to critical infrastructure, e.g. when a Polish boy hacked
into a tram system and made a remote control which ended up with
several derailed vehicles. This shows that low capability actors driven
by curiosity can cause significant damage to systems or infrastructure
if safeguards are not in place.
• Script kids The difference between script kids and hackers is that
script kids use already made tools and free scripts that requires little
configuration, usually found on the internet, to conduct attacks that
irritate other PC users. Like taking down certain websites, services, or
video game servers. Several SCADA-based attack tools and methods
have been developed for The Metasploit Project which is a very simple
to use platform for launching ready-made attacks.
• Hacktivists Activist hackers. In the past, several physical protests
have happened at numerous nuclear power plants by activists and
government website defacement attacks have been done for political
reasons by hacker activists. Similar attacks happening to SCADA
systems for political purposes is a realistic threat.
• Legitimate penetration testers The perpetrators who do it for
legitimate reasons. Companies or governments hire professional teams
to hack their system and find the weaknesses in them. The teams
report their findings and the employers patch the holes that’s been
found. These intrusions are purely for the benefit of the SCADA
system and SCADA security.
NEXT PART
Because of the difference between IC systems and IT systems there are also
certain considerations regarding the security systems and approaches that
must differ. Some of them have been mentioned in "Guide to Industrial
Control Systems (ICS) Security" by Stouffer, Pillitteri, Lightman, Abrams,
and Hahn. [10]

• Timeliness and performance requirements ICS are generally

time critical. Individual installations have criteria for acceptable levels
of delay and jitter. Certain systems require reliable and deterministic
responses. IT systems typically require high throughput and can often
tolerate some level of delay and jitter. Some ICS have strict demands
for automated response time or system response to human interaction.
• Availability requirements Many ICS processes and systems are
continuous in nature which makes unexpected outages of the systems
that control them unacceptable. Exhaustive pre-deployment testing
of patches and updates is necessary to ensure high availability and
reliability. ICS can’t usually be easily stopped and started again so
typical IT strategies like rebooting a component is not an acceptable

23
 solution due to adverse impact on the requirements for availability,
reliability, and maintainability. Some ICS use redundancy, often
running in parallel, to provide continuity when primary components
are unavailable.
• Risk management requirements Data confidentiality and integrity
are the main concerns in regular IT systems. Human safety, fault
tolerance, to prevent loss of life, or endangerment of public health
or confidence, loss of equipment, loss of intellectual property, lost
or damaged products, are primary concerns. Personnel operating,
securing, and maintaining ICS must understand the important link
between safety and security. Security measures that impairs safety is
not acceptable.
• Physical effects Since ICS are directly responsible for controlling
physical processes they can have very complex interactions and
consequences that can manifest in physical events. To understand
these potential physical effects it’s often needed communication
between experts in control systems and in the particular physical
domain.
• System operation Operating systems and control networks are often
quite different from IT counterparts. They require different skill sets,
experience and levels, area of expertise which is why the control
networks are typically managed by control engineers instead of IT
personnel. Assuming that the differences between IT systems and
ICS systems are not significant can have disastrous results on system
operations.
• Resource constraints ICS and the real time OSs they use
are often resource-constrained systems that do not include typical
contemporary IT security capabilities. Legacy systems are often
lacking resources common on modern IT systems and desired
features including encryption capabilities, error logging, and password
protection. Indiscriminate use of IT security practices in ICS may
cause availability and timing disruptions in ICS. The ICS components
may not have the computing resources available to retrofit these
systems with current security capabilities either so adding resources
or features may not be possible.
• Communications The communication protocols and media used by
IC systems for field device control and intra-processor communication
are typically different from most IT systems and may be proprietary.
• Change management Change management is one of the most
important aspects of maintaining the integrity of both IT systems
and ICS. Unpatched software is one of the greatest vulnerabilities to
a system. Software updates like security patches etc., are typically
applied in a timely fashion based on appropriate security policy and
procedures and are often automated in IT systems. Software updates
for ICS need to be thoroughly tested by both the vendor of the

24
 industrial control application and the end user of the application before
being implemented so the updates cannot always be implemented on a
timely basis. The ICS owner must plan and schedule ICS outages days
or weeks in advance. Many ICS use older versions of operating systems
that are no longer supported by the vendor so available patches may
not be applicable. The change management process in ICS requires
careful assessment by ICS experts like control engineers working in
conjunction with security and IT personnel.
• Managed support Typical IT systems allow for diversified support
styles, perhaps supporting different but interconnected technology
architectures. For IC systems, service support is sometimes via
a single vendor, which may not have diversified and interoperable
support solutions from another vendor. In some instances, third-
party security solutions are not allowed due to ICS vendor license
and service agreements, and loss of service support can occur if third
party applications are installed without vendor acknowledgement or
approval.
• Component lifetime IT systems usually have a lifetime of around
3 to 5 years because of the quick evolution of technology. Because
the technology in ICS often has been developed for a specific use and
implementation, its lifetime is in the order of 10 to 15 years, sometimes
longer.
• Component location While common IT systems usually are located
in business or commercial facilities physically accessible by local
transportation, ICS components may be isolated, remote, and require
extensive transportation effort to reach.
So as can be seen there are some notable differences when considering se-
curity for ICS compared to for IT systems. Preferably, a cross-functional
team of experts from both domains need to work together closely to un-
derstand the limitations of the system, the operation and maintenance of
security solutions together with control system operation, and the reliability
impacts of information security technologies before deployment.

From [13], a list of key vulnerabilites in SCADA and ICCP

• Intruders could get unauthorized access to the control center network
through overlooked access points such as via dial-up remote network
access, connections to partner networks that are not secured, or access
via unsecured networks in the relatively rare instances in which they
are used for ICCP.
• Disgruntled employees could pose a wide range of threats, e.g.
authorization violations, in which an authorized user gains access to
the control center and SCADA networks via the corporate network for
unauthorized purpose.
• A malicious agent could initiate a DoS (denial-of-service) attack by

25
 sending repeated information requests that "lock up" an ICCP server,
preventing it from handling legitimate requests and users.

• Viruses or worms could infect the ICCP server or other devices and
perform malicious activities such as emailing critical information to
another host for retrieval by a hacker.

• Packet sniffing at end points of communication, such as the ISP or

carrier, could enable packet modification and crafting with malicious
intent.

Although securing an industrial network is in many ways similar to a tra-

ditional business network, it presents many unique challenges. Industrial
systems are built with reliability and longevity in mind. They’re expected
to be able to operate for months without pause and the life expectancy can
be decades. If a system needs to be taken offline for updating or patching,
it might have to be planned months in advance and everything will have to
be tested to run smoothly and without fail. Attackers, on the other hand,
have easy access to new tools and exploits. [4]

The importance of securing industrial networks cannot be overstated. Many

industrial systems are built on legacy devices and with legacy protocols
evolved to work in routable networks. The systems were built for reliability
and they were made at the time when physical security was a concern. The
system were air-gapped so they didn’t concern themselvse with information
security. Systems are impossible to air-gap now because of the need for real
time information, so now there’s always a path into critical systems. [4]

Consequences can range from disrupting the operation (taking a facility

offline), alteration of an operational process (changing the formula of a
chemical process or recipe), to deliberate acts of sabotage with intent to
cause harm. E.g. manipulating the feedback loop of a process could cause
pressure within a boiler to build beyond safe operating parameters. Sabot-
age like this could lead to injury or loss of life, loss of critical services, or
catastrophic explosions. [4]

INS:3 provided a table with an overview of potential impacts of success-

ful cyber attacks.

26
 Incident type Potential impact
Change in system, operating Introduction of command and control
system, or application config- schannels into otherwise secure system
uration Suppression of alarms and reports to hide
malicious activity
Alteration of expected behaviour to pro-
duce unwanted and unpredictable results
Change in programmable lo- Damage to equipment and/or facilities
gic in PLCs, RTUs, or other Malfunction of the process (shutdown)
controllers Disabling control over a process
Misinformation reported to Causing inappropriate actions in response
operators to misinformation that could result in a
change in programmable logic
Hiding or obfuscating malicious activity,
including the incident itself or injection
code (i.e a rootkit)
Tampering with safety sys- Preventing expected operations, fail safes,
tems or other controls and other safeguards with potentially
damaging consequences
Malicious software (malware) May initiate additional incident scenarios
infection May impact production, or force assets
to be taken offline for forensic analysis,
cleaning, and/or replacement
May open assets up to further attacks,
information theft, alteration or infection
Information theft Sensitive information such as a recipe or
chemical formula are stolen
Information alteration Sensitive information such as a recipe or
chemical formula is altered in order to
adversely affect the manufactured product
reheally

In 2007, the Aurora Project, an experiment by Idaho National Laborator-

ies was completed. The experiment demonstrated that a process controller
could be destroyed by a hacker. They successfully opened and close breakers
on a diesel generator, forcing it out of synch, resulting in explosive failure.
Operation Aurora demonstrated the existence of the Advanced Persistent
Threat. [4]

The APT (Advanced Persistent Threat) is all about directed attacks and
focuses on determining specifics about a target network. It wants to spread
and learn, and exfiltrate information through cover communication. It often
relies upon outside commands, but certain ones like Stuxnet can operate in
isolation. They attempt to remain hidden, spread within a network and
become persistent. The wanted end result of its relentless, layered approach
is deliberate exfiltration of data.
The attacks themselves are usually straight forward and uses OSINT (open-
source intelligence), spear phishing, malicious attachments, USB drives, as

27
well as malicious websites. Once the network is infected, the APT tries to
operate covertly and may attempt to deactivate or circumvent anti-malware,
establish backdoors, and open holes in firewalls. The advanced side of APT
is its often deep knowledge of its target, both information about the target
and the targets associations. This can lead to highly effective spear phish-
ing. The “Advanced” moniker comes from the behavior of the threat after
infection. The primary goal of an APT is to use the information it gains
to develop a more weaponized piece of malware. It’s a logical precursor to
cyber war, but whereas cyber war’s focus is on destruction, APTs focus is
on profit. [4]

Whereas in APT the methods of infection usually are simple exploits, meth-
ods used in cyber war trend towards more advanced delivery mechanisms
and payloads. Higher in both sophistication and consequence as its focus is
on destruction. [4]

A discussion of vulnerabilities needs great consideration as industrial net-

works are sensitive to traditional scanning techniques, and by their nature
difficult to patch and reconfigure in order to minimize vulnerability. There-
fore, it is important to understand where attacks may originate from, the
paths or vectors that may be used, the targets, and their specific vulnerab-
ilities. [4]

There are many tools available to facilitate network scanning, including tools
like the popular Nmap scanner, a free network scanning tool that combines
ping sweeps, port scans, operating system detection, and service detection
and service version detection. Nmap is widely used and available on all
major and many minor operating systems. Metasploit is another popular
penetration testing tool that includes network scanning modules. I will use
both of these in the experiments. [4]

A network scan can identify hosts as well as the ports and services those
hosts are using. In industrial networks, network scanning works in much the
same way. The results of the scan can quickly identify SCADA and DCS
communications, which allows the attacker to focus on these items. For ex-
ample, a device found using port 502 is known to be using Modbus and is
therefore very likely and HMI system or some supervisory workstation that
is communicating with the HMI. [4]

This source also mentions this:

There is a caveat when scanning industrial networks; because many indus-
trial network protocols are extremely sensitive to latency and/or latency
variation (jitter), a “hard scan” could actually cause the industrial network
to fail. The lesson here is that, if the intention is disruption of services, all it
takes is a simple network scan to achieve your goal. It is easy enough to scan
through a firewall, meaning that if real-time protocols are only protected by
a firewall, they are highly prone to DOS attacks using very basic hacking

28
techniques. If the goal of the attacker is more complex, network scans need
to be performed more sensitively. This means using a “soft scan” versus
large sweeps – for example, inspecting router tables or even sniffing traffic
passively. Successful scan results can quickly map known SCADA and DCS
systems by filtering on the known ports services. [4]
Scanning an industrial network can effectively act as a DOS attack. Because
many industrial protocols are real time, and the processes tightly synchron-
ized, the introduction of additional packets into a real-time network can be
disruptive. This means that an attacker who does not want to immediately
disrupt an industrial network may scan quietly: performing low-and-slow
scan, or using the “scan and spread” methodology of Stuxnet, where the
malware crawls invasively but quietly through the network examining its
surroundings as it goes in order to find target systems, rather than perform-
ing fast and loud sweeps.
Simply scanning an industrial network can be enough to disrupt it; many
of the industrial protocols are sensitive enough that the introduction of a
significant amount of unexpected traffic will result in protocol failure and
an effective DOS condition. This is a significant concern since it’s possible
to perform a network scan through a firewall, and even easier to packet-
flood through an open port on a firewall. By identifying what traffic is
allowed through the firewall, the attacker can then use allowed traffic to
scan through the firewall, using a soft scan for true reconnaissance or a hard
scan for disruption of service. If the firewall is well configured, a scan may
not be possible, but all firewalls will allow some traffic through. By spoofing
legitimate communications, abnormal amounts of traffic can be injected into
a control network, causing a DOS. [4]

This is part of what I will be testing during the experiments later.

Weak firewall rules and access control provide a primary entry point from
the business network into the SCADA DMZ. Legitimate reasons for allowing
communications through the firewall exist, and these can introduce entry
points into industrial network enclaves via the business network. How-
ever, [4] provides a list of inbound entry paths that lead directly into the
supervisory enclaves, bypassing the business network:

• Inter-control center communications over ICCP

• Remote access connections to field stations
• Connections to the control system
• Diagnostic access to SCADA devices via dial-up or remote access
If the business network is “contested ground” and the SCADA DMZ is
“middle ground” then the control system is “sacred ground”. Within the
context of industrial network security, the control system represents the ul-
timate target; the devices and systems that actually control the industrial
process which needs to be protected. Theoretically, the control system has

29
very limited access, but in practice there are multiple points of entry. These
include not only the obvious path from the SCADA DMZ, but also direct
entry paths from wireless and diagnostic systems.
While many vulnerabilities are derived from software bugs in applications or
network protocol stacks, other vulnerabilities are derived from weak secur-
ity practices and policies, poor network design, and other easily addressable
factors. Some of these vulnerabilities, including poor firewall configurations,
weak authentication, unmanaged and/or insecure network access, and re-
mote access vulnerabilities, can be addressed easily. [4]
The smart grid represents new inbound attack vectors into industrial sys-
tems. The nature of smart metering technology and its close marriage to
power transmission and distribution essentially turn the entire T&D infra-
structure into a potential entry point into the utility’s network. These entry
points are numerous. They include access via the T&D communications in-
frastructure, via customer service and billing apps within the business net-
work, via generation and usage applications within the SCADA networks,
and so on. Almost every physical system, network, and application is tied
in some way to the smart grid, requiring strong security on these systems
to prevent an attacker using them as an inbound vector. [4]

2.3.1 Vulnerability Analysis of Network Scanning on

SCADA Systems

This is the newest article or source I could find on the subject and it was
published in 2018. The experiments done here are very relevant to what I
will be doing making it a good source for me to take from.

For many years, SCADA and ICS networks were a completely independ-
ent sector of any business or agency, where the field devices and industrial
mechanisms which interacted with physical assets were separate from the
corporate networks or intranet. As internet technologies became ever more
integrated into modern society, and as corporations began to grow expo-
nentially around the globe, the demand for remote auditing and control of
industrial systems increased. This resulted in the merging of Internet Pro-
tocol (IP) and SCADA/ICS technologies, which in turn exposed the older
field devices to a new set of attack vectors, leading to unprecedented vul-
nerabilities when integrated with IP. In an age where threats from the cyber
domain are ever evolving, the tools used to perform security audits and pen-
etration tests against IP systems are subsequently being used on the older
SCADA/ICS networks. These tools, without the correct configuration or
use, could cause substantial damage to the SCADA devices connected to a
business’s infrastructure, rather than helping to protect and audit them. [11]

Unlike the IP networks in abundance today, SCADA systems are threatened

not only by hackers wishing to exploit vulnerabilities in software or firmware,

30
but also by the tools commonly associated with monitoring, auditing, and
securing networks. Using tools which have not been configured to inter-
act with the bespoke devices that reside on SCADA networks could cause
the devices to become unresponsive or alter the data being received by the
device or being stored on the device. In such events, field devices including
water pumps, electricity generators, or pneumatic instruments could either
stop functioning or begin to behave erratically, causing damage to either the
devices themselves, the products they interact with, or the customers who
use their facilities. [11]

| A ping sweep being used to gain information about the devices connected
to the network caused a robotic arm to move 180 degrees, despite being in
a standby state before the sweet was initiated. A similar ping sweep was
conducted on a PCS network causing a circuit fabrication machine to hang
on operation, resulting in 50k GBP worth of damage to the production line.
Lastly, a penetration test was conducted on a SCADA system responsible
for gas utility. As a result of using penetration testing equipment, the sys-
tem froze, meaning no gas could be distributed outside of the plant, causing
a loss of service to the customers of the plant for 4 hours. [11]

Wiberg also references the lack of standardization within the automation

manufacturing industry and implies that this may also be a significant reason
why SCADA devices are vulnerable. A significant issue identified by Wiberg
is that using active network scanners, such as Nmap, presents a weakness
when attempting port recognition or service detection on SCADA devices.
Wiberg states that active tools such as Nmap can use unusual TCP segment
data to try and find available ports. Furthermore, they can open a massive
amount of connections with a specific SCADA device but then fail to close
them gracefully. [11]

"... stating that “simple” port scans (of 200-300) ports did cause some
devices and applications to become unresponsive." [11]
"... With this taken into consideration, the sources highlighted the signific-
ant threat of using reconnaissance tools on these types of systems as they
cannot be tested in the current environment.” [11]

The research shows that Ethernet and traditional TCP/IP protocols focus
on embedding data within the payload of multiple frames so that Internet
technologies such as routers, web servers, proxies, and email servers can cor-
rectly send, receive, and utilize that data. DNP3 and Modbus have very
few data abstractions mechanisms as they are strictly master/slave commu-
nications channels. This means that Ethernet packets are far larger and
more sophisticated than the SCADA/ICS protocols discussed above. Scans
targeted at SCADA must be a lot more specific to the technologies present
on those types of network, meaning the data being sent across the wire must
be the same length, the same data structure, and the same frequency as the

31
existing traffic. The commands within each message must be adapted to
match each specific slave device which resides on the network in order to
gain valid responses or successful data transfer. [11]

As ethernet frames are the underlining mechanism used by network scan-

ners, any device with an ethernet interface should experience little to no
changes when being scanned, unless the data being received is too great for
the processing power of that device. As SCADA devices are often set up
on older, legacy systems, the rate at which ethernet packets are processed
may be too great for SCADA and ICS devices. The most crucial aspect of
these protocols is the way that they distinguish between individual packets.
Whereas ethernet uses a block of data to separate packets, Modbus uses
physical breaks in time in order to achieve the same result. If connected to
a Modbus RTU network, the ethernet delimiter will not be valid. Therefore,
if the traffic from the scan is received directly after a legitimate Modbus
message, the receiving device may drop the data packet or continue to try
and process the data as if it is a continuation of the last packet received.
This could result in bottlenecks being formed at specific parts of the net-
work, meaning none of the data destined for the SCADA devices will be
received and the data flowing from multiple devices or subnets could be dis-
rupted. [11]

The most notable discoveries made from the protocols and networks research
can be summarized as follows:

• (i) The data held within the different protocols may not correspond
with the instruction-set of the recipient device. Although an
ethernet packet may successfully reach a modbus or dnp3 device,
the information present within each packet may not solicit a correct
response from the SCADA device. This means that any information
transmitted back to the scanning device may not be useful in managing
assets or diagnosing security vulnerabilities on the network.

• (ii) The differences between how Ethernet, Modbus and DNP3

synchronize and delimit the data traveling across the network could
impact the operation of SCADA devices. If the data being received is
too large or is being received too quickly, the on-board CPUs within
SCADA equipment may struggle to parse the incoming data, meaning
less time is spent performing their original, logical tasks.

• (iii) The data being transmitted by the scanning tool may not be able
to travel through that particular medium being used by the network.
Although this may not have an impact on the devices themselves,
the scan will return with no results. If used incorrectly, executing
IP scanners on serial networks could either cause a denial of service,
connection disruption, or false negative scan results.

32
As the main underlying technology of TCP/IP is ethernet, either this could
cause the SCADA devices to become overloaded with foreign traffic or the
serial system may drop or freeze because of the inability to process the Eth-
ernet traffic.

"... This implies that if a SCADA device has been configured to use ethernet
but does not offer any of the services used within the IP experiments, the
device may not be able to parse the data correctly or elicit a valid response.
This could potentially cause the SCADA device to crash or behave unexpec-
tedly, not because of the unfamiliar traffic that its receiving but from being
unable to process unfamiliar requests for services it does not provide." [11]

The results yielded from the Nmap scans showed that both of the PLCs
used within these experiments remained stable during a TCP-SYN scan.
However, the network traffic captured from the host machine during that
scan shows that Nmap does not use the same method of asset detection as
shown within the IP experiments. The differences are that when conducting
the scan against both the Siemens and ABB PLCs, Nmap utilized the APR
protocol in order to determine which hosts were active, rather than sending
TCP-SYN packets to common services ports such as web server ports (80)
or SSL ports (443). Although this method of scan proved to be successful
against this SCADA environment, it cannot be stated that the same level
of success would be achieved on other SCADA devices or networks. The
first reason for this is that both of the PLCs used within these experiments
communicated with the host machine via an ethernet connection. As a res-
ult of this, each interface has a MAC address. ... Executing Nmap’s service
detection scan against both the Siemens and ABB PLCs did not alter the
behavior of the SCADA system. [11]

The UDP scan appeared to provide more in-depth data about the Siemens
PLC than the previously executed TCP scans. However, replicating the
same UDP scans on the ABB machine yielded different results. The UDP
scan was unable to reveal the same information, such as CPU model and
firmware version, as gained from scanning the Siemens PLC. This means
that, as a result of the scan being able to execute and complete without
altering the behavior of the SCADA system, service detection scans must
be specifically tailored to facilitate the unique setup of each individual PLC
in order to gain specific details about the device.

[11] says that on attempting to run an ICMP ping sweep against both the
Siemens and the ABB PLCs, the packets were unable to reach their intended
destinations and no safe conclusions can be made about the impact ICMP
packets may have on SCADA systems.
From the results of the TCP, UDP, and ICMP scans, it was evident that run-
ning active tools against the SCADA networks did not have an impact on the
operation of either the PLCs or field devices used within these experiments.

33
When comparing these results to the outcomes of the IP experiments, there
appears to be little difference between scanning on a SCADA network.
The PLC devices were able to respond to a range of scans as well as able
to maintain normal operation throughout the entire duration of the scan.
The information displayed within the literature review suggests that these
results do not correspond with previous cases involving network scanners
and SCADA equipment.
The creator of [11] created a Python script to send a higher volume of net-
work traffic to each port on the target PLCs. On execution the Siemens
PLC remained stable and continued to function as normal. However, on
executing the same script against the ABB PLC, the connection between
the host HMI and the PLC was prematurely terminated.
Although retesting the ABB PLC with the Python script supports the claim
that SCADA devices may alter when congested with massive amounts of net-
work traffic, the Python UDP scanner does not represent a usable network
scanner. The tool was created in order to send a large amount of UDP
data across a network, whereas network scanners use a variety of protocols
to gain information about the devices connected to a network. Therefore,
the results of this scan prove that SCADA systems can be affected by mass
amount of data flooding the network, and it does not prove that the same
result could be achieved with any of the aforementioned network scanners.
Furthermore, the Python script was only successful against one of the two
PLCs tested. Therefore, the data from these experiments cannot suggest
that running the same scans or scripts on a variety of other SCADA devices
would yield the same results.
... although network scanners may be a viable option on some types of
SCADA systems or devices, there is no universal solution to performing as-
set discovery or service detection on SCADA systems. Every device and
network are unique; therefore scanning technology must be adapted to facil-
itate the configuration of each unique device. Performing a network scan on
a SCADA system with an all-purpose tool such as Nmap or Zmap is not feas-
ible. However, conducting research into all SCADA devices and how they
function would allow for a tool or framework which could provide a solution
to the issue of bespoke technologies and the uniqueness of devices. [11]

"... an asset-discovery scan or service detection scan against an Ethernet-

connected Siemens S7-1200 or ABB PM564 PLC using Nmap, the traffic
generated by the scan does not have a negative effect on the operation of
any of the SCADA devices present on the network. ... " [11]

... Although the Python script had not been designed to gather inform-
ation about networked devices, it demonstrated that SCADA networks can
suffer a DoS attack from one host running a single Python script. Not only
does this emphasize the idea drawn from the revisited literature review, but
these results also suggest that if configured incorrectly, or if there are mul-
tiple remote users scanning the same network, active scanning tools could
possibly replicate the same results as the Python script.

34
As only two different types and manufacturers of SCADA equipment were
tested during the course of these experiments, the data obtained from this
research cannot suggest that it is feasible to scan a SCADA system with any
of the active tools which were tested, despite the successes and failures of
certain tests.
... this means that there is not a universal solution which can facilitate the
requirements of every SCADA system being used within modern society.
Further research would be needed to in order to detect similarities between
bespoke SCADA protocols and manufacturers in order to fully understand
the most effective way of conducting remote scans without compromising
the integrity of the system.
The experiments conducted against the SCADA systems provided a set of
results which identified that, using the network scanning tools and SCADA
devices selected for these experiments, executing an active scan against a
SCADA system does not affect the normal operation of the system. This
suggests that, for the devices used within these experiments, it would be
feasible to run all of the asset discovery and service detection scans against
SCADA devices. The results obtained from conducting these experiments
did not answer a range of questions which still apply to the use of scanners
on SCADA networks. [11]

... Having the opportunity to experiment on a larger, more complex net-

works would be beneficial towards validating the results and conclusions
drawn this research. [11]

2.4 Consequences

CONSEQUENCES
Anyone (government or private companies) that uses a SCADA system are
exposed to a large amount of risk. The consequences of an attack on an
ICS could be far reaching and very damaging. SCADA systems manipulate
physical objects so the result of an attack could have serious physical effects
like loss of property, damage to the environment, brand damage, loss of rev-
enue, share price reduction, personal injury or loss of life in severe cases. A
company can lose brand image if they fail to secure a critical system such
as a SCADA system. The brand damage may end up with the company
that provided the SCADA system, though it’s more likely the company that
has implemented the system gets blamed for problems they have. It could
have an economic effect through hindering system operations which in turn
inflict an economic loss on the facility or the company. On a larger scale
it could affect the local, regional, national or even global economy. For ex-
ample, in 2003 the North East US had a blackout because of a flaw in the
SCADA system that cost an estimated $6bn. Companies can also expect a
reduction in share value if an attack should happen successfully against the
SCADA system. The shareholders and public can lose faith in the company

35
which can lessen the value of the shares. It could even have a social impact
through the national or public confidence in an organization. Social impacts
may lead to depressed public confidence or in extreme cases the rise of pop-
ular extremism. [9] [1]

The first and most known attack on Ukraine’s power grid took place on 23rd
of December 2015 and is considered to be the first confirmed successful cyber
attack on a power grid. Three power distribution companies were targeted,
namely Prykarpattyaoblenergo, Chernivtsioblenergo, and Kyivoblenergo. In
total over 230’000 consumers lost their electricity for 1 to 6 hours and 30
substations were switched off. Because the power company only used single-
factor authentication to connect to their SCADA systems through a VPN,
the attackers got access and used it against them. The attackers used the
BLACKENERGY 3 malware to gain access to the corporate networks of the
power companies, then through to the SCADA network. They performed
reconnaissance and eventually used the grids systems against itself. After
studying and learning the operations, they used the legitimate functional-
ity of distribution management systems to disconnect substations from the
grid. They followed that up with wiping the Windows systems with the
KillDisk malware and destruction of serial-to-Ethernet devices through ma-
licious firmware updates so the Ukrainian grid operators were without their
SCADA environment and could not use the automated control functions,
for upwards to a year in some locations. [7]

A second attack happened December 2016. The attackers struck an electric

transmission station north of Kiev causing a blackout in portions of the cap-
ital equivalent to a fifth of its total power capacity. Whereas in the 2015 at-
tack the attackers turned off power to substations manually, the 2016 attack
was fully automated. Both attacks are believed to be linked to Sandworm,
which is a Russian hacker group that’s been targeting Ukraine the last few
years. [6] The second attack was done with the malware called Industroyer.
The malware self-references as "crash" leading to some calling it Crash Over-
ride. It is capable of controlling electricity substation switches and circuit
breakers directly because it uses the protocols the way they were made to
be used in ICS. These protocols are used worldwide in several industries
and were designed decades ago without security in mind because they were
meant to be isolated from the outside world. Industroyers core component
is a backdoor used by the attackers to manage the attack. It installs and
controls other components, connects to a remote server to receive commands
from and to report to the attackers. [3] Industroyer is highly customizable
malware and was customized to target ICS specifically. While it can be
used to attack any ICS using some of the targeted communication proto-
cols, some of the components were designed to target specific hardware. The
wiper component and one of the payload components were tailored for sys-
tems using certain industrial power control products by ABB, and the DoS
component was customized to counter the Siemens SIPROTECT devices. [3]

Stuxnet was the first ICS-tailored malware used against targets and the first

36
to be designed and deployed to disrupt physical industrial processes and re-
program industrial control systems. [7] It was uncovered first in 2010, but
it’s believed that it was deployed in 2005. It targets programmable logic
controllers (PLCs) which allow the automation of electromechanical pro-
cesses such as those used to control machinery in centrifuges that separates
nuclear material. Its final goal was to reprogram IC systems by modifying
code on programmable logic controllers to make them work in a manner
the attacker intended and to hide those changes from the operator of the
equipment. To achieve this goal the creators uses included four zero-day
exploits, a Windows rootkit, the first ever PCL rootkit, antivirus evasion
techniques, complex process injection and hooking code, network infection
routines, peer-to-peer updates, and a command and control interface. The
target was an Iranian facility enriching uranium to slow down their nuc-
lear weapons program. Reportedly, it ruined almost a fifth of Iran’s nuclear
centrifuges. Stuxnet collected information on industrial systems and caused
the fast-spinning centrifuges to tear themselves apart. The design and ar-
chitecture of Stuxnet are not domain-specific and it could be modified as a
platform for attacking modern SCADA and IC systems. The worm ended
up infecting over 200’000 computers worldwide and caused 1’000 machines
to physically degrade. [14] [12]
A list of some of Stuxnets features, from symantecs dossier [12]
• Self-replicates through removable drives exploiting a vulnerability
allowing auto-execution.
• Spreads in a LAN through a vulnerability in the Windows Print
Spooler.
• Spreads through SMB by exploiting the Microsoft Windows Server
Service RPC Handling Remote Code Execution Vulnerability.
• Copies and executes itself on remote computers through network
shares.
• Copies and executes itself on remote computers running a WinCC
database server.
• Copies itself into Step7 projects in such a way that it automatically
executes when the Step7 project is loaded.
• Updates itself through a peer-to-peer mechanism within a LAN.
• Exploits a total of four unpatched Microsoft vulnerabilities, two of
which are previously mentioned vulnerabilities for self-replication and
the other two are escalation of privilege vulnerabilities that have yet
to be disclosed.
• Contacts a command and control server that allows the hacker
to download and execute code, including updated versions of the
malware.
• Contains a Windows rootkit that hide its binaries.

37
 Figure 2.9: Stuxnet’s infection processes

• Attempts to bypass security products.

• Fingerprints a specific ICS and modifies code on the Siemens PLCs to
potentially sabotage the system.
• Hides modified code on PLCs, essentially a rootkit for PLCs

38
Chapter 3

Research Methodology

In this chapter I describe the research methodologies and methods I’ve

chosen to use in this thesis. I will describe the research perspective and
paradigm, as well as methods used in the experiments and research data
collection and analysis of this data.

3.1 Technologies used

3.1.1 Nmap

Nmap (“Network Mapper”) is an open source tool for network and explora-
tion and security auditing. It was designed to rapidly scan large networks,
although it works fine against single hosts. Nmap uses raw IP packets in
novel ways to determine what hosts are available on the network, what
services (application name and version) those hosts are offering, what op-
erating systems (and OS versions) they are running, what type of packet
filters/firewalls are in use, and dozens of other characteristics. While Nmap
is commonly used for security audits, many systems and network adminis-
trators find it useful for routine tasks such as network inventory, managing
service upgrade schedules, and monitoring host or service uptime. Other
features are host discovery, port scanning, version detection, OS detection,
scriptable interaction with the target.
The output from Nmap is a list of scanned targets, with supplemental in-
formation on each depending on the options used. Key among that inform-
ation is the “interesting ports table”. That table lists the port number and
protocol, service name, and state. The state is either open, filtered, closed, or
unfiltered. Open means that an application on the target machine is listen-
ing for connections/packets on that port. Filtered means that a firewall,
filter, or other network obstacle is blocking the port so that Nmap cannot
tell whether it is open or closed. Closed ports have no application listening
on them, though they could open up at any time. Ports are classified as
unfiltered when they are responsive to Nmap’s probes, but Nmap cannot

39
determine whether they are open or closed. Nmap reports the state com-
binations open|filtered and closed|filtered when it cannot determine which
of the two states describe a port. The port table may also include software
version details when version detection has been requested. When an IP pro-
tocol scan is requested (-sO), Nmap provides information on supported IP
protocols rather than listening ports. In addition to the interesting ports
table, Nmap can provide further information on targets, including reverse
DNS names, operating system guesses, device types, and MAC addresses.
In [11] it is written: "Again it is evident that there is little understanding as
to how probes such as Nmap impact the ordinary functions of SCADA and
ICS networks".

Here are some descriptions for the modes I’ve used in the practical part of
the thesis
-sn
This option tells Nmap not to do a port scan after host discovery, and only
print out the available hosts that responded to the host discovery probes.
This is often known as a “ping scan”, but you can also request that traceroute
and NSE host scripts be run. This is by default one step more intrusive
than the list scan, and can often be used for the same purposes. It allows
light reconnaissance of a target network without attracting much attention.
Knowing how many hosts are up is more valuable to attackers than the list
provided by list scan of every single IP and host name.
Systems administrators often find this option valuable as well. It can easily
be used to count available machines on a network or monitor server availab-
ility. This is often called a ping sweep, and is more reliable than pinging the
broadcast address because many hosts do not reply to broadcast queries.
The default host discovery done with -sn consists of an ICMP echo request,
TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp re-
quest by default. When executed by an unprivileged user, only SYN packets
are sent (using a connect call) to ports 80 and 443 on the target. When a
privileged user tries to scan targets on a local ethernet network, ARP re-
quests are used unless –send-ip was specified. The -sn option can be com-
bined with any of the discovery probe types (the -P* options, excluding -Pn)
for greater flexibility. If any of those probe type and port number options
are used, the default probes are overridden. When strict firewalls are in
place between the source host running Nmap and the target network, us-
ing those advanced techniques is recommended. Otherwise hosts could be
missed when the firewall drops probes or their responses.
-sP
In previous releases of Nmap, -sn was known as -sP, though this command
still works.
-p / -p-
This is used to specify what ports to target. -p- means all possible ports
-v
This is used to get verbose output for more information.
-sT

40
TCP connect scan is the default TCP scan type when SYN scan is not an
option. This is the case when a user does not have raw packet privileges.
Instead of writing raw packets as most other scan types do, Nmap asks the
underlying operating system to establish a connection with the target ma-
chine and port by issuing the connect system call. This is the same high-level
system call that web browsers, P2P clients, and most other network-enabled
applications use to establish a connection. It is part of a programming in-
terface known as the Berkeley Sockets API. Rather than read raw packet
responses off the wire, Nmap uses this API to obtain status information on
each connection attempt.
When SYN scan is available, it is usually a better choice. Nmap has less
control over the high level connect call than with raw packets, making it
less efficient. The system call completes connections to open target ports
rather than performing the half-open reset that SYN scan does. Not only
does this take longer and require more packets to obtain the same inform-
ation, but target machines are more likely to log the connection. A decent
IDS will catch either, but most machines have no such alarm system. Many
services on your average Unix system will add a note to syslog, and some-
times a cryptic error message, when Nmap connects and then closes the
connection without sending data. Truly pathetic services crash when this
happens, though that is uncommon. An administrator who sees a bunch of
connection attempts in her logs from a single system should know that she
has been connect scanned.
-sS
SYN scan is the default and most popular scan option for good reasons. It
can be performed quickly, scanning thousands of ports per second on a fast
network not hampered by restrictive firewalls. It is also relatively unobtrus-
ive and stealthy since it never completes TCP connections. SYN scan works
against any compliant TCP stack rather than depending on idiosyncrasies
of specific platforms as Nmap’s FIN/NULL/Xmas, Maimon and idle scans
do. It also allows clear, reliable differentiation between the open, closed,
and filtered states.
This technique is often referred to as half-open scanning, because you don’t
open a full TCP connection. You send a SYN packet, as if you are go-
ing to open a real connection and then wait for a response. A SYN/ACK
indicates the port is listening (open), while a RST (reset) is indicative of
a non-listener. If no response is received after several retransmissions, the
port is marked as filtered. The port is also marked filtered if an ICMP un-
reachable error (type 3, code 0, 1, 2, 3, 9, 10, or 13) is received. The port is
also considered open if a SYN packet (without the ACK flag) is received in
response.
-O
Nmap’s remote OS detection uses TCP/IP stack fingerprinting. Nmap sends
a series of TCP and UDP packets to the remote host and examines prac-
tically every bit in the responses. After performing dozens of tests such as
TCP ISN sampling, TCP options support and ordering, IP ID sampling, and
the initial window size check, Nmap compares the results to its nmap-os-db
database of more than 2,600 known OS fingerprints and prints out the OS

41
details if there is a match. [5]
-sTV
Version detection interrogates the ports to determine more about what is
actually running. The nmap-service-probes database contains probes for
querying various services and match expressions to recognize and parse re-
sponses. Nmap tries to determine the service protocol, the version number,
hostname, device, the OS family. With banner grabbing completely exact
version numbers can be retrieved. [5]
-Tx (-T1, -T2, -T3, -T4, -T5)
Nmap offers a simple approach to timing controls with six timing templates.
You can specify them with the -T option and their number (0–5) or their
name. The template names are paranoid (0), sneaky (1), polite (2), normal
(3), aggressive (4), and insane (5). The first two are for IDS evasion. Po-
lite mode slows down the scan to use less bandwidth and target machine
resources. Normal mode is the default and so -T3 does nothing. Aggressive
mode speeds scans up by making the assumption that you are on a reason-
ably fast and reliable network. Finally insane mode assumes that you are
on an extraordinarily fast network or are willing to sacrifice some accuracy
for speed.
These templates allow the user to specify how aggressive they wish to be,
while leaving Nmap to pick the exact timing values. The templates also
make some minor speed adjustments for which fine-grained control options
do not currently exist. For example, -T4 prohibits the dynamic scan delay
from exceeding 10 ms for TCP ports and -T5 caps that value at 5 ms.
Templates can be used in combination with fine-grained controls, and the
fine-grained controls that you specify will take precedence over the timing
template default for that parameter.

3.1.2 Hping3

Hping3 is a network tool able to send custom TCP/IP packets and to dis-
play target replies like the ping program does with ICMP replies. Hping3
can handle fragmentation, arbitrary packets body and size and can be used
in order to transfer files encapsulated under supported protocols. Features
include firewall testing, advanced port scanning, network testing using differ-
ent protocols, TOS, fragmentation, manual path MTU discovery, advanced
traceroute under all supported protocols, remote OS fingerprinting, remote
uptime guessing, TCP/IP stacks auditing.
–flood: send packets as fast as possible, don’t show replies
-V: verbose mode
-c: packet count
-d: data size
-S: set SYN flag
-p: destination port
-s: base source port

42
3.1.3 Wireshark

Wireshark is the world’s foremost and widely-used network protocol

analyzer. It lets you see what’s happening on your network at a
microscopic level and is the de facto (and often de jure) standard across
many commercial and non-profit enterprises, government agencies, and
educational institutions. Wireshark development thrives thanks to the
volunteer contributions of networking experts around the globe and is the
continuation of a project started by Gerald Combs in 1998.
Features include:
• Deep inspection of hundreds of protocols, with more being added all
the time
• Live capture and offline analysis
• Standard three-pane packet browser
• Captured network data can be browsed via a GUI, or via the TTY-
mode TShark utility
• The most powerful display filters in the industry
• Rich VoIP analysis
• Read/write many different capture file formats
• Capture files compressed with gzip can be decompressed on the fly
• Live data can be read from Ethernet, IEEE 802.11, PPP/HDLC, ATM,
Bluetooth, USB, Token Ring, Frame Relay, FDDI, and others
• Decryption support for many protocols, including IPsec, ISAKMP,
Kerberos, SNMPv3, SSL/TLS, WEP, and WPA/WPA2

3.1.4 Metasploit

The Metasploit Framework is an open source penetration testing and devel-

opment platform that provides you with access to the latest exploit code for
various applications, operating systems, and platforms. You can leverage
the power of the Metasploit Framework to create additional custom security
tools or write your own exploit code for new vulnerabilities. Since it’s so
easy to set up and use it’s been known as the go-to tool for script kiddies,
but in the right hands it can be quite powerful. The modular approach that
allows you to combine any exploit with any payload is the major advantage
of the Framework. It facilitates the tasks of attackers, exploit writers, and
payload writers.

43
3.1.5 Nessus

Nessus is a professional vulnerability assessment tool made by Tenable. It

uses the Common Vulnerabilities and Exposure architecture for easy cross-
linking between compliant security tools. It has a modular architecture
consisting of centralized servers that conduct scanning, and remote clients
that allow for administrator interaction. Administrators can include Nessus
Attack Scripting Language descriptions of all suspended vulnerabilities to
develop customized scans. Significant capabilities of Nessus include:
• Compatibility with computers and servers of all sizes
• Detection of security holes in local or remote hosts
• Detection of missing security updates and patches
• Simulated attacks to pinpoint vulnerabilities
• Execution of security tests in a contained environment
• Scheduled security audits

3.2 My setup

I used my own privately owned laptop as the attacker. It runs the Win-
dows 10 operating system, with Kali Linux running in a VirtualBox virtual-
machine environment on top.
Specs and details:

• Asus GL552JX
• Windows 10 64-bit
• Oracle VM VirtualBox 5.2.0 r118431
• VB running Kali-Linux-2018.2-vbox-amd64
• Wireshark 2.4.5 running on Kali
There was two different test environments I ran tests on. Both were made
to be simulating components running in a live power station. Unfortunately,
we weren’t able to get simulated data running through the system, but they
can still be tested to see how much traffic they can handle.

The first of the two systems was from ABB and the second one was from
Siemens.
The ABB system included the following:

44
 Figure 3.1: Diagram of the ABB setup

• Windows 7 Pro workstation

• ABB 800xA DCS
• ABB AC800M controller
• Wired network router
And software
• System 800xA Engineering Workplace
• ABB Engineering Station
• OPC Server
• ABB Maintenance
Figure 3.1 shows a diagram of the setup.

The Siemens systems included the following:

• Windows 8 Pro workstation

• Siemens PLC S7-1500
• Siemens PLC S7-314
• Siemens PLC S7-1200
• Siemens Switch X208
• Siemens Firewall S6XX
And the following software
• Siemens TIA Portal

45
 Figure 3.2: Diagram of the Siemens setup

• Siemens WinCC
Figure 3.2 a diagram of the setup and some photos of the system.

The experiments were ran a bit different in the two systems. On the ABB
system I had Wireshark running on both my own laptop that acted as the
attacker, and the engineering station. I ran it on the engineering station as
well so I had the possibility to analyze the network logs and see if the tests
I ran had any effect on the communication between the engineering station
and the industrial equipment communicating with it.
However, this was not possible to do in the Siemens system as installation
of Wireshark on the engineering station lead to its network settings chan-
ging. This caused the connection between the engineering station and the
industrial equipment to terminate and we were not able to reconnect them
without uninstalling Wireshark first.

In summary, this is how I ran the tests on the two systems:

• The ABB system
I would send data from the attacker laptop towards the controller
component and record the network traffic with Wireshark on the
attacker laptop. I would also record the network traffic on the
engineering station with Wireshark. To see if the connection between
the engineering station and the controller component was live and
stable I’d run a continuous ping from the engineering station to the
controller component.
• The Siemens system
Like in the ABB system, I ran Wireshark on the attacking laptop while
I was sending traffic to the PLC components, as well as the continuous

46
Figure 3.3: Photo of the Siemens setup

Figure 3.4: Photo of the Siemens setup

47
Figure 3.5: Photo of the Siemens setup

Figure 3.6: Photo of the Siemens setup

48
 Figure 3.7: Photo of the Siemens setup

ping from the engineering station to the PLC components.

49
50
Chapter 4

Results

In this chapter I present the results from the testing I described in the
methodology chapter.

4.1 The ABB system

In general, the PLCs in both systems were able to handle normal scans
without serious effects. I managed to crash or make a component unable
to communicate in both systems, but mostly with parameters or options
that are not usually used in most scans. This could be argued goes under
"normal use" of the tools though. It was different programs or methods that
were used to take down the ABB component and the Siemens component.
In one it took a lot of traffic in a short amount of time, in the other it was
about the data size in a ping.

System overview:
Kali 172.16.4.30
Engineering station 172.16.4.11
ABB AC800 172.16.4.20
ABB PCU400 172.16.4.5

4.1.1 Attacks that affected the system

Here is a list of attacks done that affected the communications:

• sudo nmap -v -sTV .20

The continuous ping from the engineering station to the PLC timed
out when doing this scan, meaning this scan was blocking the traffic,
effectively being a DOS attack.

51
 • sudo nmap -v -sTV -T5 .20
The same happened with this scan.
• sudo nmap -v -sT -p- .20
The PLC crashed. A crash did not occur every time I tried it. If I ran
it just after a restart of the PLC it timed out the continuous ping, but
if I tried it again, the PLC crashed.
• sudo nmap -v -sT -p- -T4 .20
A crash happened during this scan as well.
• sudo nmap -v -sT -p- -T5 .20
This made the PLC crash, too. It wasn’t able to withstand the amount
of data coming in.
• sudo nmap -v -sS -p- -T4 .20
A SYN-scan that lead to a crash.
• sudo nmap -v -sS -p- -T5 .20
This scan also lead to a crash.
• sudo nmap -v -sS -p- .20
The PLC didn’t crash, but the continuous ping from the engineering
station timed out. I ran this scan again, immediately after the first
one, which caused the PLC to crash.
• hping3 -V -c 1000000 -d 120 -S -p 445 -s 445 –flood 172.16.4.20
This attack with hping3 also crashed the PLC.

4.1.2 Attacks that had no effect

These attacks had no effect on communications, except maybe a jump in

a couple of ms on the continuous ping. All the attacks were targeted at
the AC800, except the one I’ve specified to be targeted at the PCU400,
172.16.4.5.

• sudo nmap -sP 0/24

• sudo nmap -sn 0/24
• sudo ping .20
• sudo ping .5
• sudo ping -s 60
• sudo ping -s 600
• sudo ping -s 6000
• sudo ping -s 60000
• sudo nmap -v -sT

52
 • sudo nmap -v -sS
• sudo nmap -v -sS -T4
• sudo nmap -v -sS -T5
• sudo nmap -v -O
• sudo nmap -v -sT -p- -T2

4.2 The Siemens system

System overview:
Kali 192.168.88.100
Engineering station 192.168.88.40
Switch siemens X208 .50
Firewall Siemens S6XX .51
Wireless Siemens W740 .52
Wireless Siemens W788 .53
PLC Siemens S7-1500 .60
PLC Siemens S7-314 .61
PLC Siemens S7-1200 .62

4.2.1 Attacks that affected the system

Attacks done:

• sudo ping -s 6000 .60

This command made all 3 PLCs unable to respond.
• sudo ping -s 60000 .60
This command crashed the PLC.
• sudo ping -s 60000 .61
This command crashed the PLC.
• sudo ping -s 60000 .62
This command crashed the PLC.
• sudo nmap -v -sS -p- -T5 .50
This caused a lot of variation in the ping response time. It jumped
from 1 ms to 116 ms when the scan started and stayed at that level.
• sudo hping3 -V -c 1000000 -d 120 -S -p 445 -s 445 –flood .50
A lot of requests timed out on the continuous ping, and the response
time went from 1 ms to 557 ms when the scan started. It avereged out
at around 93 ms.

53
Figure 4.1: Screen capture from some attacks done on the Siemens system

• sudo hping3 -V -c 1000000 -d 120 -S -p 445 -s 445 –flood .62

This caused an effective DOS. A lot of requests timed out and
destination host unreachable on the pings.

4.2.2 Attacks that had no effect

• sudo nmap -sP 0/24

• sudo nmap -sn 0/24
• sudo ping
• sudo ping -s 60
• sudo ping -s 600
• sudo nmap -v -sT
• sudo nmap -v -sS
• sudo nmap -v -O
• sudo nmap -v -sTV
• sudo nmap -v -sS -T5
• sudo nmap -v -sS -T5 -p-, except at .50
• sudo hping3 -V -c 1000000 -d 120 -S -p 445 -s 445 –flood .51, .60, and
.61
As well as these, I tested how the hping3 flood would affect open versus
closed ports on the PLCs.
hping3 -V -c 1000000 -d 120 -S -w 64 -p 102 –flood
In .60 there was no difference whether I targeted open ports or closed ports.

54
In .61 the response time on the continuous ping incrased. It went from 1
ms to 115 ms maximum, with an average of 57. On the closed port it went
from 1 ms to 25 ms with an average of 16, which is not significant. On
.62 it blocked the continuous ping from the engineering station to the PLC
completely. Both on the open port and the closed port.

4.3 Other tests

I ran a few tests with Nessus on the Siemens system. The basic network
scan, the advanced scan, and the web app scan. None of these had any effect
on the components.

With the help of Metasploit, I checked the engineering stations in both

systems for the EternalBlue exploit. Both systems were exploitable.

55
56
Chapter 5

Discussion

This chapter presents a discussion of the findings I got from the tests, linked
to the related research and research questions of the thesis.

The ABB System

From the tests I ran, it’s apparent that network scanning industrial networks
can in fact negatively affect them, both purposely and acceidentally. The
ABB system and the Siemens system reacted quite differently to the tests
done.
If we look at what caused components to crash first, I notice that in the ABB
system it’s always because of a large number of packets sent. The first time
it crashed was with the nmap -v -sT -p- command. This scanned all possible
ports on the target, meaning 65535 ports. It did not crash if I ran it just
after a restart, only if I ran it twice or it had filled up internal storage with
other data during communications. When it didn’t crash the component, it
did sporadically block the continuous ping from the engineering station to
the component.
According to [2], it has an inbuilt Network Storm Protection. When it de-
tects excessive network traffic the corresponding network port is disabled
for a few minutes. If there’s still excessive traffic when it opens again, it
repeats the process. Though this is followed up by the possibility that the
amount traffic may be so intense and cause so high CPU load that the storm
protection function itself is not able to execute, and can’t guarantee it will
manage to protect the controller from shutting down. This might be what
have happened here.
The PLC also crashed when speeding up the same type of scan. The second
time was with nmap -v -sT -p- -T4, and then -T5.
The next two scans that lead to crashes were nmap -v -sS -p- -T4 and an-
other one with the -T5 parameter. These lead to crashes for the same reason
as the earlier scans.
The last scan that crashed the DCS was the hping3 flood DOS style attack.
This attack is meant to throw as much data as possible at the target and if
something was going to work, it would be this.

57
To only block communication to and from the component, not as much was
needed. The nmap -v -sTV scan to look for services and service versions
running on the target, blocked all communication to and from the compon-
ent. Unsuprisingly, the same happened when I sped the scan up with the
-T5 parameter.
The SYN-scan, nmap -v -sS -p- without the -T4 parameter to increase the
scan speed, blocked all communication on the component if I ran it a single
time. If I ran the scan twice in a row, the target component crashed.

The majority of the tests I ran against the ABB system had no affect on its
communication. The pings I sent had no effect, which wasn’t that surprising
as modern technology can handle it.
The host discovery scans, nmap -sP 0/24 and nmap -sn 0/24, had no effect
on communications either. These commands are to discover live hosts on
the network. They didn’t always report that the industrial components were
live. To specify, by 0/24 I mean 172.16.4.0/24.
The TCP and SYN scans, nmap -sT and nmap -sS, didn’t affect the com-
ponents. Based on [11], this did not surprise me. Though I sped the scans,
nmap -sS and nmap -sT, up with -T4 and -T5 it didn’t affect communica-
tions either. This did surprise me because it shows it needs a bigger amount
of traffic, not just sent at a faster rate.
The operating system detection scan had no effect on the communications.

The Siemens system

The Siemens system and components reacted quite differently than the ABB
system. The nmap scans I ran neither crashed nor affected the communic-
ations in any severe way. The only thing to crash the Siemens PLCs were
the pings with a big enough packet size.
The command ping -s 6000 made all 3 Siemens PLCs unable to communic-
ate, it blocked the continuous ping going from the engineering station to the
PLC in question effectively DOSing it.
When I increased the packet size tenfold, to ping -s 60000, it crashed all 3
Siemens PLCs. There might be a case of the ping of death happening. The
problem is when the target receives and reassembles the packet, a buffer
overflow can occur, which causes a system crash.
A sped up SYN scan targeting all possible ports, nmap -sS -p- -T5, slowed
down the communication of the switch. The same happened with a hping3
flood.
An hping3 flood, hping3 -c 1000000 -d 120 -S -p 445 -s 445 –flood, caused
the Siemens S7-1200 to be unresponsive to communication. The continuous
ping going to this component from the engineering station got timed out
and destination host unreachable when trying to ping the PLC.
None of the nmap scans had any effect at all on the Siemens PLCs, and the
hping3 flood had no effect on the S7-1500 or the S7-314.

It is now clear that industrial components like PLCs and DCSs will re-
act differently depending on the type and the manufacturer. It seems the

58
ABB components reacted to big amount of data in the sense that the nmap
scan sent a lot of requests, very fast. It was scanning every port possible.
The Siemens PLCs reacted negatively to big sized packets in ping. Any IPv4
packets may be that big.
This is, of course, a problem for everyone who uses them. Now that in-
dustrial networks are more and more intertwined with classic computer net-
works, industrial components will only be more accessible to network traffic,
which in turn means they will be more vulnerable. Not only to attackers
with hostile intentions, but it may stop hired penetration testers from test-
ing on their live systems. The consequences could be too large if someone
unintentionally crashed a component while the system was live.
The manufacturers have to have this in mind going forward with the next
generations of industrial hardware and the industries that use these types
of components must be aware of the potential consequences if they don’t
maintain adequate security.

Adversaries are getting smarter. They are growing in their ability to learn
industrial processes and scale that knowledge. It is crucial defenders also
grow and adapt to these threats. There are many different standards and
guidelines in the subject of information security for industrial use. The use
of ISO27001 and ISO27002 is prevalent in the EU. ISO/IEC TR 27019:2013
(Information technology - Security techniques - Information security man-
agement guidelines based on ISO/IEC 27002 for process control systems
specific to the energy utility industry) builds on ISO/IEC 27002 (Inform-
ation security management) for use in process controllers and automation
technology and it assists energy companies in introducing a management
system for information security in accordance with ISO27001. Control sys-
tems for smart homes and telecommunications components are covered by
ISO/IEC 27011:2008. European Union Agency for Network and Informa-
tion Security (ENISA) have released two recommendations when it comes
to securing Information and communications technology (ICT) and SCADA
systems. [8]

• ENISA have developed a framework to assess the maturity level in ICS

and SCADA security. The framework makes it possible to classify the
security of SCADA systems in four different maturity levels of security.
Numerous countries do not have any set of rules in use and fall low on
the maturity scale.

• ENISA recommends coordination of SCADA security with national

ICT security strategies. They also recommend developing good
practices for protection of process control systems, standardize
information sharing across industry sectors and countries, strengthen
the knowledge of the enterprises, invest in education and research,
and certification of competence for operators that work with process

59
 controllers. [8]
The Swedish Civil Contingencies Agency (MSB) have released four basic
advice for security in SCADA
• Increase the awareness throughout the organization about the need for
security in ICS.
• Conduct basic education on security in ICS.
• Actively work with the security architecture in ICS and connected IT
systems.
• Set security requirements with the supplier and in service agreements.
[8]
In Norwegian businesses the guidelines from the Norwegian Data Protec-
tion Authority (Datatilsynet), National Security Authority (NSM), and the
Agency for Public Management and eGovernment (Difi) seems to be the
most used.

• Difi’s guidelines for internal control apply to all businesses in the

public sector, but can also be used by anyone in the private sector.
The guidelines are based on ISO27001, but attempts to meet the
requirements regarding Norwegian privacy laws.
• NSM’s security guidelines for technical system security apply to
all businesses that are subject to the Norwegian security law
(Sikkerhetsloven). [8]

60
Chapter 6

Conclusion

This section provides a summary of the discussion to answer the research

questions and finally provide suggestions for future work. This thesis have
presented my work related to testing industrial components behaviour when
targeted with hostile network traffic.
Through the tests and experiments I have run on ABB and Siemens
hardware, it is clear they are not secure when it comes to handling hostile
network traffic. This includes network scanning, big IPv4 packets, and flood
DOS attacks. The two hardware manufacturers are vulnerable to different
attacks or traffic. The ABB hardware crashed when it was targeted with a
big number of ports scanned, while the Siemens hardware crashed when it
received big packets in ping requests. Industrial hardware is not ready to
be more connected with computer networks, but demand for the possibility
to remotely connect will push network features into this area. Given how
easy it is to interfere in the communication between this hardware or take it
completely down, it’s crucial the companies who uses this type of hardware
secures them against any outside or internal manipulation that’s either done
by purpose or by accident.

6.1 Future work

Unfortunately neither the ABB system or the Siemens system used simu-
lated data when I ran the tests. This should be done in the future to see
if the attacks can affect the behaviour of the industrial components. [11]
mentions a source that claims in one case a robotic arm started to move
despite being in standby mode, and a circuit fabrication machine hang on
operation because of ping sweeps that were ran on the systems [11]. This is
something that should be looked deeper at with simulated data so output
values can be compared with expected values while or after network scans
and attacks are done.

The data I’ve found can be used to develop a network scanner made for

61
industrial network use. One that can be used without being afraid of ac-
cidentally crashing vital components in live networks. A big amount of
research needs to be done before such a thing is developed, to be sure its
functionality will not negatively interfere with or crash industrial devices.

62
Bibliography

[1] S. Dyer T. Patel H. Janicke A. Nicholson, S. Webber. Scada security

in the light of cyber-warfare. URL: https://www.sciencedirect.com/
science/article/pii/S0167404812000429.

[2] ABB. System 800xa network configuration. URL: https://library.e.abb.

com/public/9c8b6c0dc8bdfe16c1257b400026feb3/3BSE034463-510_E_
en_System_800xA_5.1_Network_Configuration.pdf.

[3] Robert Lipovsky Anton Cherepanov. Industroyer:

Biggest threat to industrial control systems since
stuxnet. URL: https://www.welivesecurity.com/2017/06/12/
industroyer-biggest-threat-industrial-control-systems-since-stuxnet/.

[4] Peter Babington. Industrial Network Security. Syngress, 2 edition,

2011.

[5] Laszlo Erdödi. Nf5290 lecture 3 network reconnaissance. URL:

https://www.uio.no/studier/emner/matnat/ifi/IN5290/h18/lectures/
inf5290-2018-l03-network_reconnaissance.pdf.

[6] Andy Greenberg. Crash override: The malware that took down a power
grid. URL: https://www.wired.com/story/crash-override-malware/.

[7] Dragos Inc. Crashoverride analysis of the threat to electric grid opera-
tions. URL: https://dragos.com/wp-content/uploads/CrashOverride-01.
pdf.

[8] Øyvind Toftegård Jon-Martin Pettersen Roger Steen Synnøve

Lill Paulen Janne Hagen, Ola Hermansen. Nve. regulering av ikt- sik-
kerhet. URL: http://publikasjoner.nve.no/rapport/2017/rapport2017_
26.pdf.

[9] Willian Young Jennifer DePoy Jason Stamp, John Dillinger. Common
vulnerabilities in critical infrastructure control systems. URL: https:
//energy.sandia.gov/wp-content//gallery/uploads/031172C.pdf.

[10] Suzanne Lightman Marshall Abrams Adam Hahn Keith Stouffer,

Victoria Pillitteri. Guide to industrial control systems (ics) secur-
ity. URL: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.
800-82r2.pdf.

63
[11] Leandros Maglaras Helge Janicke Kyle Coffey, Richard Smith. Vul-
nerability analysis of network scanning on scada systems. URL: https:
//www.hindawi.com/journals/scn/2018/3794603/.
[12] Eric Chien Nicolas Falliere, Liam O Murchu. W32.stuxnet
dossier. URL: https://www.symantec.com/content/en/us/enterprise/
media/security_response/whitepapers/w32_stuxnet_dossier.pdf.
[13] symantec. Best practices for securing scada networks and systems in
the electric power industry. URL: http://www.hoffmanmarcom.com/
dev/wp-content/docs/Symantec_SCADA_security_white_paper.pdf.
[14] WikiPedia. Stuxnet wikipedia article. URL: https://en.wikipedia.org/
wiki/Stuxnet.

64