Using Application Layer Metrics to Detect Advanced SCADA Attacks
Peter Maynard, Kieran McLaughlin and Sakir Sezer
Centre for Secure Information Technologies, Queen’s University Belfast, BT3 9DT, Belfast, U.K.
Keywords:
ICS, IDS, Network, SCADA, Security, SIEM.
Abstract:
Current state-of-the-art intrusion detection and network monitoring systems have a tendency to focus on the
‘Five-Tuple’ features (protocol, IP src/dst and port src/dest). As a result there is a gap in visibility of security
at an application level. We propose a collection of network application layer metrics to provide a greater
insight into SCADA communications. These metrics are devised from an analysis of the industrial control
system (ICS) threat landscape and the current state-of-the-art detection systems. Our metrics are able to detect
a range of adversary capabilities which goes beyond previous literature in the SCADA domain.
1 INTRODUCTION
The problem with state-of-the-art network intrusion
detection systems (IDS) is the lack of ICS-specific
insight. Many solutions focus on extracting statis-
tics based on the traditional 5-tuple of flow features.
However, this misses potentially valuable information
in the SCADA application layer, which may be used
to develop more detailed metrics, regarding the secu-
rity status and performance of the underlying physical
system.
The trend in the current state-of-the-art research
is to use machine learning methods to discover ma-
licious actions on the network. A common method
is to take low level packet captures and analyse them
for anomalous activity. e.g. (Terai et al., 2017) who
use packet inter-arrival time. We propose the use of
application layer packet analysis within the Process
Control enclave, and use that data to provide an ana-
lyst with deeper insight into the security status of the
ICS facility. These metrics can be used for different
applications ranging from intrusion detection, foren-
sics, or verifying compliance with security standards
and legislation. Legislation, such as the GDPR and
NIS Directive require active monitoring and historic
measurable indicators of progress. We have derived
a set of metrics loosely based on IEC 60870-5-104,
which can also be used on other field bus protocols.
Contributions: (i) An analysis of industrial threat
actors and their capabilities. (ii) Review the current
state-of-the-art metrics for ICS. (iii) Proposed novel
metrics that enable deeper insight into SCADA net-
works, and allow for detecting anomalies within an
ICS system. (iv) Finally, we compare the current
state-of-the-art ICS intrusion detection systems with
the proposed metrics to show a much improved cov-
erage of attack activities in reconnaissance, interfer-
ence, DoS and covert communications. The paper is
structured as follows. Section 2 and 3, detail the ICS
threat landscape. Section 4 highlights related work
and ICS metrics. Section 5 details the proposed met-
rics drawing comparison between state-of-the-art IDS
proposals and our contributions.
2 ICS ENVIRONMENT
A high-level overview of an ICS network typically
can be broken down to three enclaves. 1. Busi-
ness 2. SCADA and 3. Process Control. Histor-
ically, SCADA enclaves were air-gapped, however,
in recent years it is common to find one-way traffic
from SCADA to the business enclave. A SCADA net-
work may contain a data historian, human machine
interface (HMI), and remote devices such as pro-
grammable logic controllers (PLC). The business en-
clave facilitates traditional systems used for account-
ing, human resources and analysing productivity of
the plant. The business network is the main entry
point for an adversary, typically communicating with
the SCADA network, requesting data used within per-
formance reports. The SCADA enclave contains HMI
software and monitoring equipment. Similar to the
business enclave, as vendors move towards open stan-
dards, the hardware requirements are becoming less
proprietary, allowing for the use of common off the
shelf software (Adobe Flash, Microsoft Windows and
418
Maynard, P., McLaughlin, K. and Sezer, S.
Using Application Layer Metrics to Detect Advanced SCADA Attacks.
DOI: 10.5220/0006656204180425
In Proceedings of the 4th International Conference on Information Systems Security and Privacy (ICISSP 2018), pages 418-425
ISBN: 978-989-758-282-0
Copyright © 2018 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
Physical
Domain
PLC
HMI
Data
Historian
RTU
Enterprise
Workstations
Reporting
Process Control Enclave
SCADA Enclave
Business Enclave
Figure 1: High-level view of an ICS network.
*Unix). The SCADA enclave communicates with the
process control enclave, issuing commands and re-
ceiving state information from the physical systems.
The process control enclave contains devices that
communicate using specialised field bus protocols i.e.
IEC104, Modbus-TCP, DNP-3 etc. The process con-
trol enclave can potentially span a large physical area.
On the other hand, this physically large enclave is of-
ten not segregated, and is configured as a single flat
LAN. Such networks range from on-premises, to re-
mote locations such as autonomous substations. This
is a mission critical network which is sensitive to la-
tency. For example, if this were an electrical sub-
station there may be various meters providing power
readings that are collected by an RTU or IED and
transmitted up to the SCADA network. Alternatively,
an operator might need to issue a command to shut
down a system, which needs to be completed in a
timely and reliable manor.
Figure 1 shows the high-level of separation and re-
lationships between the four enclaves. This segmen-
tation works well with (Shostack, 2014) suggestion of
using ‘Trust Boundaries’ to identify where a risk may
initiate. Once the SCADA encalve has been breached,
any data received from the process control enclave
can not be trusted. This paper focuses on the com-
munications between the SCADA and Process control
enclave because of the restricted types of protocols
which should be seen between these networks. The
aim is to enable detection of malicious events affect-
ing the most critical systems as a priority to counter
system risks.
3 INDUSTRIAL THREAT MODEL
Typical threat modelling processes are asset/software-
centric. While this provides valuable insight into at-
tack paths and vulnerabilities within software, it fails
to highlight possible methods to detect network intru-
sions. ICS networks are well understood, but the lack
of information about the threat actors limits develop-
ment of defence systems. As such, the authors pro-
pose to perform an adversary/attack-centric approach
to modelling potential threats. The aim is to better
align detection metrics at the application layer with
the characteristics of realistic threats to the process
network.
Without understanding adversaries’ capabilities, it
will be difficult to know where to place active de-
fences such as network security monitoring. This sec-
tion will deconstruct and model known adversaries of
industrial systems in order to highlight possible types
of attacks. NIST SP-800-82 (Stouffer et al., 2015)
defined four primary adversary actors as Individual,
Group, Organisation, Nation-State. Each of these
have their own characteristics and capabilities. Stouf-
fer’s work aligns well with (Robinson, 2013), which
performed a comprehensive analysis of the SCADA
threat landscape. The proposed approach therefore
begins by aligning adversaries with attacks identified
from the state-of-the-art detection literature. Table 1
shows different attack capabilities which can be per-
formed by each threat actor. Depending on a per-
ceived threat model (e.g., a high risk of being attacked
by a group or organisation), defences can be prepared
against certain types of attacks.
Different classes of adversaries are now briefly de-
fined. An individual is a single person working alone.
Insiders which can range from on-site employees, re-
mote contractors or partner companies. The scope
of damage which these individuals could cause de-
pends on their level of privilege within the system.
The likely person could be a disgruntled employee or
script kiddie. Types of attacks from individuals can
range from port and device scanning to insider com-
promise resulting in significant damage.
A group is one or more persons working together.
The amount of technical and domain knowledge is po-
tentially moderate to high. Groups can fall into two
categories, ad-hoc and established. An ad-hoc group
is likely to be performing basic incoherent attacks. An
established group would have more resources to at-
tract individuals with domain expertise. Their motiva-
tion would likely be political and fall into the ‘Hack-
tivist’ definition. Types of attacks which might be per-
formed are spear-phising, custom malware and noisy
reconnaissance.
Organisations, not unlike groups, consist of more
than one person, but have more domain knowledge
and technical abilities. They may be industrial com-
petitors, suppliers, partners, or customers. Their in-
tention may be corporate espionage or financial gain,
an organisation would be able to perform advanced
reconnaissance as well as targeted malware for well
known devices. Nation-states have similar features
Using Application Layer Metrics to Detect Advanced SCADA Attacks
419
Table 1: Comparison of actors and capabilities.
Attack Stages
Individual
Group
Organisation
Nation-State
Reconnaissance
Network Scan
Device/Protocol Scan
-
Report Server Information
- -
Read Device Identification
- -
Interference
Command Replay
-
Command Injection
-
Unauthorised Write
- -
Unauthorised Read
-
Clear Counter/Diagnostic
Registers
-
Rouge Device
- -
Firmware Tampering
- -
Denial of Service
TCP/UDP Spam
Remote Restart
- -
Force PLC into Listen
Mode
- -
Covert
Covert Comms.
- - -
Stealthy Deception Attack
- - -
Malicious Firmware
- -
to the organisation threat actor, but have considerably
more capabilities than the others. A nation-state’s in-
tentions may be espionage and warfare. Typically,
they would use advanced methods such as the attacks
detailed by (Kleinmann et al., 2017), in which they
propose a stealthy attack on a SCADA system that is
protocol and process aware. A nation-state might use
covert channels within the SCADA enclave, such as
the one proposed by (Lemay et al., 2016), used for
command and control. Examples of such nation-state
attacks are the Ukrainian power outages of 2015/16,
and the Stuxnet malware.
4 RELATED WORK ON METRICS
Measurements provide a single-point-in-time view of
specific, discrete factors, while metrics are derived by
comparing a baseline to two or more measurements
over time. Measurements are made by counting, met-
rics are made from analysis. Another way of think-
ing is that measurements are objective raw data and
metrics are either objective or subjective human in-
terpretations of those data (Payne, 2006). A metric
should communicate useful information and be con-
sistent and cheap to produce. For a metric to be used
in further analysis it should be quantifiable, repeat-
able and specific to the context where it is applied.
(Rathbun and Homsher, 2009) (Pendleton et al., 2016)
reviewed the current state-of-the-art security metrics,
which can be broken down into four categories: 1)
Attack; 2) System Vulnerabilities; 3) Situational; and,
4) Defences. They discuss the use of intrusion detec-
tion metrics with a focus on the effectiveness of an
IDS. This can be used to compare detection systems.
For actual attack measurements, they focus on zero-
day vulnerabilities which provides a measurement of
the attack consequences in retrospect. They propose
measurements which allow for monitoring a botnet’s
applicability and how resourced it is, which can be
used in developing and deploying mitigation strate-
gies e.g. sink holes. (Zhang et al., 2016) have mod-
elled network diversity as a security metric to evalu-
ate network robustness against zero-day vulnerabili-
ties. They measured the number of distinct resources
within the network such as hosts, and host connec-
tivity, resources and any similarities. They designed
a probabilistic model which identifies a path of least
resistance to compromise an asset.
Building on these concepts, the following sections
present and analyse existing work on the development
of metrics specific to ICS, focusing on three main
areas: 1) generic network metrics i.e. packet tim-
ing/length; 2) Physical metrics using data from the
physical domain; and 3) the SCADA application layer
as a source for deriving indicators of compromise.
4.1 Generic Network Metrics
(Terai et al., 2017), propose the use of Support Vector
Machines (SVM) to identify attacks on an ICS net-
work. However the SVM was trained on generic net-
work traffic and would thus be unable to detect spe-
cific intrusions like SCADA based covert communi-
cation channels, which disguise command and control
(C2) within genuine ICS traffic. (Rudman and Irwin,
2016) developed a framework to automatically iden-
tify network indicators of compromise (IOC) from
packet captures. By running the Dridex malware in
a dynamic sandbox they identified basic high-level
IOCs such as IP address ranges of control server and
frequently used protocols and ports. This is valuable
data which can be used to analyse the behaviour of
specific malware variants. However, it fails to gener-
ate any ICS specific IOCs.
(Wang et al., 2014), propose that by modelling
network connectivity along with policies and configu-
rations of a host, they can predict the number of zero-
day compromises needed to disrupt a critical asset.
The higher the number, the less likely the asset is to
be compromised. The model depends on the existence
of network connectivity which is not always available.
ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy
420
(Lemaire et al., 2017) have used machine reasoning to
identify vulnerabilities in an industrial system based
on NIST and ICS-CERT. They use the Systems Mod-
elling Language (SysML) to model the system and
perform an analysis. With this design, they are lim-
ited by the vulnerability database which is a) based
on known exploits and b) manually updated, which
can cause delays in detection.
(Zhang et al., 2015) have expanded on the model
of ‘mean-time-to-compromise’ (MTTC), used to es-
timate the time it takes for an adversary to compro-
mise an asset. Using Bayesian network attack graphs,
Zhang et.al are able to identify potential attack steps
and quantify various attack scenarios. The first attack
graph is used to determine the probabilities of suc-
cessful exploitation of a vulnerability in the SCADA
enclave to gain root access. This is calculated by con-
sidering the ratio of exploits via CVE/CVSS scores.
The second is used to evaluate the probability of
successful compromise of the communication links
between the SCADA and process enclaves. They
decompose a man-in-the-middle (MITM) attack and
counter-measures are included within the model.
(Vasilomanolakis et al., 2016) developed a honey-
pot that emulates an ICS system, whereby they are
able to generate IDS rules automatically from the
results. They have emulated a range of ICS pro-
cesses, and able to detect different classes of attacks:
Single-Protocol Level Detection (SPLD); Multi-Stage
Level Detection (MSLD); and Payload Level Detec-
tion (PLD). However, they are restricted by collec-
tion biases, because the types of attacks that honey-
pots typically detect are automated scanning of well
known attacks.
4.2 Physical Metrics
(Urbina et al., 2016), model the physical state of the
system and compare the predicted values to actual
readings. The attacks they can detect are MITM-type
scenarios where the adversary is sending false sen-
sor data to the PLC. As they noted this is a noisy ap-
proach and easily detectable. They propose a sophis-
ticated stealthy attack, in which they monitor a spe-
cific value within the system and track it for changes.
They proposed a stateful and stateless method to de-
tect changes of the physical system to determine if an
attack had occurred. (Luchs and Doerr, 2017) pro-
posed IDS monitoring in remote field devices, with
the intention to gain more visibility into the process
control enclave. They proposed additional monitor-
ing vectors such as acoustic levels, to identify com-
plex attacks such as Stuxnet. Luchs and Doerr mon-
itored the status of field devices independently from
the HMI/PLC readings allowing for additional vali-
dation. This was used to confirm whether the device
is operating within the manufacture’s specification,
which is another vector for detecting anomalous ac-
tivity. While the proposed IDS does provide superior
insights into the process control enclave over tradi-
tional vectors, it would be unlikely to be adopted by
ICS operators in its current state, due to the complex-
ity of deployment. This is unlike traditional network
IDS, which can be quickly deployed and integrated
with existing systems with out bespoke configuration.
4.3 SCADA Metrics
(Almalawi et al., 2016), have proposed a novel data-
driven clustering approach, based on the contents of
SCADA protocols. They are able to identify a set of
working states which represent the SCADA system.
From there, it is possible to cluster the states into
normal and abnormal. The states are derived from
data extracted from the Modbus-TCP protocol, i.e:
a) water flow pressure, demand and level; b) Com-
mand value status and setting; and c) Pump status and
speed. A MITM attack was simulated and false water
readings were reported, which would cause the tanks
to empty. Traffic is legitimate Modbus-TCP so no
alerts are generated. A possible solution to detect this
would be to monitor all the tanks and their respective
water levels, instead of individually.
(Gonzalez and Papa, 2007), developed a system
to passively monitor Modbus-TCP communications
and extract data relating to RTUs, e.g. device status
and network topology. They developed three compo-
nents: 1) Network Scanner; 2) Transaction Checker
consisting of: pairs that match sets of messages which
are passed on to the 3) Incremental network map-
per, which maintains a dynamic data structure stor-
ing the network topology and device status infor-
mation. (Nivethan and Papa, 2016), reviewed open
source firewalls with regards to industrial control us-
age. They choose to use iptables due to its ability
to perform application layer inspection. They identi-
fied some Modbus-TCP fields for use in their exper-
iments, primarily focusing on the function code and
the data field. They were able to prevent the follow-
ing attacks and enumeration known to work on the
ModBus-TCP protocol: a) Unauthorised Write; b)
Unauthorised Read; c) Clear counters and diagnos-
tic registers; d) Remote restart; e) Force PLC into
listen-only mode; f) Report Server information; and
g) Read device identification. This is a typical pre-
vention mechanism which needs to be placed between
the PLC and the HMI, so it would only be put into
production if it is absolutely certain the blocked ac-
Using Application Layer Metrics to Detect Advanced SCADA Attacks
421
tions will not be needed in an emergency. Rather than
filtering traffic which meets the criteria, real system
operators are more likely to log the data for future
analysis.
(Jardine et al., 2016), built a non-invasive IDS,
which focuses on the legacy Siemens S7 protocol.
They extract data from packet captures, such as read,
write and logic code downloads. Additional traffic
such as TCP/ARP/UDP are classed as ‘Other’. They
are able to identify intrusions using the following
heuristics: a) Quantity; b) Temporal; c) IP (Commu-
nication between the PLC and others); and d) PLC
Logic code download. A baseline was built on a net-
work capture of a few hours, features are then ver-
ified by a domain expert. Their system is limited
to one PLC per instance of the IDS, which needs to
be configured to that specific PLC. (Hadziosmanovic
et al., 2012), performed an analysis of network and
host-based data to determine what is viable for use
in detecting network anomalies. They focused on the
results of the network analysis and analysed the ap-
plication payload along with basic TCP/IP features.
They mapped common communication patterns of an
ICS network by extracting TCP flows and perform-
ing a coarse payload analysis. This was followed by
extracting activity patterns for each device and proto-
col. As with other related work they used 5-tuple and
Modbus function code. We have chosen six proposed
systems discussed above to perform an analysis of our
proposed metrics. They were chosen to specifically
cover the three categories, generic network, physical,
and SCADA specific. They are all able to detect their
targeted threat, yet not one is able to detect the full
range of threats.
5 NETWORK BASED METRICS
FOR ICS PROTOCOLS
This section will discuss the use of advanced appli-
cation layer metrics and how they are able to iden-
tify anomalies within both SCADA and process con-
trol enclaves. Section 4 highlighted common forms of
network metrics that are able to detect IT related at-
tacks. Many metrics do not consider the communica-
tion context. Focusing only on basic network charac-
teristics, 5-tuple, offers less insight into the process of
the underlying system and its security status. An ad-
vanced adversary (e.g. with high skill, resources, and
domain knowledge) when infiltrating a network will
attempt to conceal their actions. A common method is
to disguise their communications to appear as if they
are normal operation. With generic network metrics,
this would not be detected. To address these short-
comings, a range of metrics will now be presented
that take the communication context into account.
Table 2 contains the proposed network metrics for
use in SCADA and process control enclaves. The
metrics are broken down into three columns. Met-
ric: this is a short hand for the specific measurement
which is used as a reference to the issue. Metric Com-
putation: is the formula used to the measure the spe-
cific metric. Purpose: this provides a concise descrip-
tion of the types of threats the metric could indicate.
Not included in the table is direction of the traffic;
either from the supervisory enclave or to the process
control. It is possible to measure in a single direction
or both. Enforcing this can identify breach of the trust
boundaries.
5.1 Comparison of Proposed Metrics
Table 3 compares the current state-of-the-art detec-
tion methods against the proposed metrics. The com-
parison is subdivided into four groupings: A) a single
metric; B) two metrics; C) three metrics; and D) four
or more metrics. Each grouping inherits the previ-
ous grouping, thus allowing for a more comprehen-
sive analysis of the traffic. For example, detecting a
network scan (group A) can be done using only M0.
Where as, detecting an unauthorised read (group B)
would need M3 and M4, and since it is in group B, it
will inherit group As M0 which is also needed for the
attack detection. We now discuss the groups in more
detail.
Group A: Due to the consistently predictable na-
ture of the process control network, it is easy to iden-
tify non-targeting scanning and obtrusive communi-
cation by using simple metrics such as distinct proto-
cols, ports, IP addresses, and date timestamps.
Group B: By monitoring commands which get/set
values of remote devices, we are able to detect abnor-
mal values from legitimate (or illegitimate) devices.
This can indicate an adversary attempting to deter-
mine the status of the current system to escalate privi-
lege. By analysing the number of commands accepted
or rejected along with the values, we are able to detect
these actions.
Group C: The advantage of measuring the access
of each device at a protocol level allows for greater
insight into activities within the system which di-
rectly affect the SCADA domain, rather than basic
TCP/IP communication patterns. By understanding
the everyday operations at this level an analyst (or al-
gorithm) could identify anomalous activities. Mon-
itoring the command type and response at both the
source (SCADA) and destination (Process Control)
will enable better monitoring for replay and injection
ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy
422
Table 2: Proposed application layer metrics.
Metric
Metric
Computation
Purpose
M0: Generic
Protocol
Count the number of
distinct protocols
Detect any non-SCADA
specific communication,
this could be a result of
network probing.
M1: Firmware
update
Count the number of
update firmware
commands
Detect any unexpected
alteration of the behaviour
of devices which might
produce unwanted and
unpredictable results.
M2: Set value
Count the number of
set or update value
commands
Detect any unexpected
alteration of the behaviour
of devices which might
produce unwanted and
unpredictable results.
M3: Get value
Count the number of
get value commands
Detect an increase in
monitoring commands
which could result in a
denial of service of the
device.
M4: Accepted
Command
Count the number of
accepted commands
Detect an increase in
accepted commands which
could identify unexpected
behaviour within the
network.
M5: Rejected
Command
Count the number of
rejected commands
Detect an increase in
rejected commands which
could identify unexpected
behaviour within the
network.
M6: Command
Type
Count the number of
distinct command
types
Detect any unexpected
commands which could
alter the behaviour of
devices, or indicate
unauthorised access on the
network.
M7: Response
Type
Count the number of
distinct response
types
Detect any unexpected
responses which could
indicate strange devices
behaviour, or indicate
unauthorised access on the
network.
M8: Device
Address
Count the number of
distinct common
address (Link
Address)
Detect any unexpected
devices on the network and
identify most
communicating devices
which could indicate
misconfigurations.
M9:
Application
Address
Count the number of
distinct information
object addresses
(Application
Address)
Detect any unexpected
application addresses on the
network which could
identify misconfiguration of
a device.
M10: Address
Count the number of
distinct addresses
(Link and
Application)
Detect any unexpected
addresses on the network
which could identify
misconfiguration of a
device.
M11: Cause of
transmission
Count the distinct
CoT
Detect an unexpected CoT
which could indicate
abnormal behaviour within
the network.
M12: Avg.
Information
Objects
Count the average
number of
Information Objects
Detect a large amount of
data being transmitted
to/from a device. Which
could result in abnormal
behaviour within the
network.
Table 3: Comparison of proposed metrics and SoA detec-
tion methods.
Attack Stages
(Vasilomanolakis et al., 2016)
(Terai et al., 2017)
(Nivethan and Papa, 2016)
(Gonzalez and Papa, 2007)
(Jardine et al., 2016)
(Luchs and Doerr, 2017)
Proposed Metrics
Grouping
Reconnaissance
Network Scan - - M0 A
Device/Protocol Scan - - M3,6,7 C
Report Server Information - - - M3,6,7 C
Read Device Identification - - M7,12 B
Interference
Command Replay - - - - M4,5,7 C
Command Injection - - - - - M4,5,7 C
Unauthorised Write - - - M2,4 B
Unauthorised Read - - - M3,4 B
Remotely Clear Registers - - - - M6,7 B
Rouge Device - - - - M8,9,10 C
Firmware Tampering - - - M0,1 B
Denial of Service
TCP/UDP Spam - - M0 A
Remote Restart - - - - M4,6,7 C
Force PLC into Listen
Mode
- - - - - M4,6,7,11 D
Covert
Covert Comms. - - - - - M6,7,11,12 D
Stealthy Deception Attack - - - - M2,3,4,6,7 D
Malicious Firmware - - - - M0,1,5,6, D
7,9,10,11 D
attempts.
Group D: These metrics are dependent on the pro-
tocol used. Because of this, we are able to measure
the cause of a transmission (whether the packet is rou-
tine, manual, or as a reaction to an event). This can
provide an indication of the desired effect an attacker
is attempting to achieve, e.g. an intruder perform-
ing a DoS by initiating packets designed to cause the
remote device to operate in diagnostic or other non-
standard modes.
In the case of the stealthy deception attack (Klein-
mann et al., 2017), it would be a matter of placing
measuring sensors at multiple points across the net-
work. Using a combination of all the metrics, it is pos-
sible to highlight this attack. Covert command chan-
nel proposed by (Lemay et al., 2016) would be de-
tected by monitoring the values within the command’s
request and response (M6-7), along with the number
information objects and cause of transmissions (M11-
12). Malicious firmware where a self-propagating
worm was developed to run within the CPU of the
PLC such as (Spenneberg et al., 2016), would be de-
tected by monitoring the device addresses (M9-10),
firmware upload requests (M1) and command types
used (M4-7). Unavoidable variations in these metrics
caused by this attack will allow this attack pattern to
Using Application Layer Metrics to Detect Advanced SCADA Attacks
423
be discerned from the normal operations of the sys-
tem.
6 CONCLUSION
This paper highlights the threat actors that exist and
their capabilities in regards to an ICS network. This
is important when choosing what defences to de-
ploy. This work has expanded on (Gonzalez and Papa,
2007), and proposes novel metrics which are able to
detect a wider range of threats. This work also ad-
dresses a gap in the existing state-of-the-art and com-
mercial systems. In particular, (Terai et al., 2017;
Zhang et al., 2015) and (Vasilomanolakis et al., 2016)
are unable to detect adversaries which disguise their
activities within the application layer. The proposed
metrics can detect such intrusions. The metrics were
developed with the intention of providing a classifi-
cation system with deeper insight into a SCADA net-
work. (Nivethan and Papa, 2016) and (Jardine et al.,
2016), consider the application layer, but they are lim-
ited to a single host with limited visibility to the ap-
plication. Without encoding knowledge of the sys-
tem into a detection system it will require a user with
domain knowledge to act on the results. As a next
step we intend to apply the metrics to real world ex-
periments to confirm their effectiveness. This can be
validated by inputting the data into a SIEM and per-
forming baseline comparison with known normal op-
erations, as well as attack patterns. Finally, we plan
to experiment with one class SVMs to discover ma-
licious actions on the network. In conclusion, we
show that by creating and analysing metrics at the ap-
plication layer, it allows the detection of a multitude
of realistic threat types, which provides more com-
prehensive detection capabilities compared to exist-
ing state-of-the-art methods. It allows for lightweight
analysis which is suitable for multiple purposes, such
as forensics, SIEM integration, features for enhanced
machine learning approaches, and complying with le-
gal requirements.
ACKNOWLEDGEMENTS
This work was funded by EPSRC project ADAMA,
reference EP/N022866/1.
REFERENCES
Almalawi, A., Fahad, A., Tari, Z., Alamri, A., AlGhamdi,
R., and Zomaya, A. Y. (2016). An Efficient Data-
Driven Clustering Technique to Detect Attacks in
SCADA Systems. IEEE Transactions on Information
Forensics and Security.
Gonzalez, J. and Papa, M. (2007). Passive scanning in Mod-
bus networks. Critical Infrastructure Protection.
Hadziosmanovic, D., Bolzoni, D., Etalle, S., and Hartel,
P. H. (2012). Challenges and opportunities in securing
industrial control systems. In Proceedings of the IEEE
Workshop on Complexity in Engineering. IEEE.
Jardine, W., Frey, S., Green, B., and Rashid, A. (2016).
SENAMI: Selective Non-Invasive Active Monitoring
for ICS Intrusion Detection. In Proceedings of the
2Nd ACM Workshop on Cyber-Physical Systems Se-
curity and Privacy.
Kleinmann, A., Amichay, O., Wool, A., Tenenbaum, D.,
Bar, O., and Lev, L. (2017). Stealthy Deception At-
tacks Against SCADA Systems. In arXiv CS.CR.
Lemaire, L., Vossaert, J., Jansen, J., and Naessens, V.
(2017). A logic-based framework for the security
analysis of Industrial Control Systems. Automatic
Control and Computer Sciences.
Lemay, A., Fernandez, J. M., and Knight, S. (2016). A
Modbus command and control channel. In IEEE Sys-
tems Conference.
Luchs, M. and Doerr, C. (2017). Last Line of Defense: A
Novel IDS Approach Against Advanced Threats in In-
dustrial Control Systems. In International Conference
on Detection of Intrusions and Malware & Vulnerabil-
ity Assessment.
Nivethan, J. and Papa, M. (2016). On the Use of Open-
source Firewalls in ICS/SCADA Systems. Inf. Sec. J.:
A Global Perspective.
Payne, S. C. (2006). A guide to security metrics. SANS
institute.
Pendleton, M., Garcia-Lebron, R., Cho, J.-H., and Xu, S.
(2016). A Survey on Systems Security Metrics. ACM
Computing Surveys.
Rathbun, D. and Homsher, L. (2009). Gathering security
metrics and reaping the rewards. SANS Institute, Oct.
Robinson, M. (2013). The SCADA Threat Landscape. In
ICS-CSR.
Rudman, L. and Irwin, B. (2016). Dridex: Analysis of the
traffic and automatic generation of IOCs. In Informa-
tion Security for South Africa.
Shostack, A. (2014). Threat modeling: designing for secu-
rity. Wiley.
Spenneberg, R., Brggemann, M., and Schwartke, H. (2016).
Plc-blaster: A worm living solely in the plc. Black Hat
Asia, Marina Bay Sands, Singapore.
Stouffer, K., Pillitteri, V., Lightman, S., Abrams, M., and
Hahn, A. (2015). Guide to Industrial Control Systems
(ICS) Security. Technical Report NIST SP 800-82r2,
National Institute of Standards and Technology.
Terai, A., Abe, S., Kojima, S., Takano, Y., and Koshijima,
I. (2017). Cyber-Attack Detection for Industrial Con-
trol System Monitoring with Support Vector Machine
Based on Communication Profile. IEEE European
Symposium on Security and Privacy Workshops.
Urbina, D., Cardenas, A., Tippenhauer, N. O., Valente, J.,
Faisal, M., Ruths, J., Candell, R., and Sandberg, H.
ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy
424
(2016). Limiting The Impact of Stealthy Attacks on
Industrial Control Systems. In NIST.
Vasilomanolakis, E., Srinivasa, S., Cordero, C. G., and
Mhlhuser, M. (2016). Multi-stage attack detec-
tion and signature generation with ICS honeypots.
In IEEE/IFIP Network Operations and Management
Symposium.
Wang, L., Jajodia, S., Singhal, A., Cheng, P., and Noel, S.
(2014). k-Zero Day Safety: A Network Security Met-
ric for Measuring the Risk of Unknown Vulnerabili-
ties. IEEE Transactions on Dependable and Secure
Computing.
Zhang, M., Wang, L., Jajodia, S., Singhal, A., and Al-
banese, M. (2016). Network Diversity: A Secu-
rity Metric for Evaluating the Resilience of Networks
Against Zero-Day Attacks. IEEE Transactions on In-
formation Forensics and Security.
Zhang, Y., Wang, L., Xiang, Y., and Ten, C. W. (2015).
Power System Reliability Evaluation With SCADA
Cybersecurity Considerations. IEEE Transactions on
Smart Grid.
Using Application Layer Metrics to Detect Advanced SCADA Attacks
425