Critical State Based Intrusion Detection

Università degli Studi dell’Insubria
Dipartimento di Informatica e
Comunicazione
Critical State Based Intrusion

Detection System For
Industrial Communication
Protocols
Supervisors:
Author:
Alberto Trombetta
Michele Guglielmi
Igor Nai Fovino
March 19, 2010

Contents
1 Introduction 5
2 State of the art 7
3 SCADA system architecture 11

3.1 System Components . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Control Network . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Process Network . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 SCADA Reference Architecture . . . . . . . . . . . . . . . . . 18
4 SCADA Protocols and vulnerabilities 21

4.1 MODBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 MODBUS Application Data Unit . . . . . . . . . . . . 22
4.1.2 MODBUS Protocol Data Unit . . . . . . . . . . . . . . 25
4.1.3 MODBUS Transactions . . . . . . . . . . . . . . . . . . 26
4.1.4 MODBUS Data Model . . . . . . . . . . . . . . . . . . 28
4.1.5 MODBUS Function Codes . . . . . . . . . . . . . . . . 28
4.1.6 MODBUS Exception Code . . . . . . . . . . . . . . . . 41
4.1.7 MODBUS Vulnerabilities . . . . . . . . . . . . . . . . . 44
4.2 DNP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 DNP3 Stack . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 DNP3 Data Link Layer . . . . . . . . . . . . . . . . . . 49
4.2.3 DNP3 Pseudo-Transport Layer . . . . . . . . . . . . . 56
4.2.4 DNP3 Application Layer . . . . . . . . . . . . . . . . . 57
4.2.5 Point Indexes . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.6 DNP3 Vulnerabilities . . . . . . . . . . . . . . . . . . . 83
5 State Based Approach 87

5.1 How to represent a SCADA system . . . . . . . . . . . . . . . 88
5.2 SCADA System Modeling Language . . . . . . . . . . . . . . . 93
5.3 Critical State Modeling Language . . . . . . . . . . . . . . . . 96
2
CONTENTS 3
6 Critical State Based IDS Architecture 99

6.1 IDS Technology . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2 IDS General Architecture . . . . . . . . . . . . . . . . . . . . 100
6.3 System Virtual Image . . . . . . . . . . . . . . . . . . . . . . . 106
6.4 Rule Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7 IDS Prototype Implementation 111

7.0.1 Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.1 Scada Protocol Sensor (SPS) . . . . . . . . . . . . . . . . . . . 124
7.2 System Virtual Image (SVI) . . . . . . . . . . . . . . . . . . . 126
7.3 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8 Experiments and tests 131

8.0.1 Packet Capturing Test . . . . . . . . . . . . . . . . . . 131
8.1 Signature-Based Performance Test . . . . . . . . . . . . . . . . 133
8.2 State-Based Performance Test . . . . . . . . . . . . . . . . . . 134
8.3 Virtual System Update Performance Test . . . . . . . . . . . . 135
8.4 Critical State Rules Analyzer Performance Test . . . . . . . . 138
9 Conclusions 141
Chapter 1
Introduction
Industrial facilities and infrastructures such as chemical factories, oil refiner-

ies, power generation plants, and water treatment plants are nowadays highly
dependent on “Industrial Control Systems (ICS)”. Such systems are typically
used in industries to monitor and control remote processes.
The NIST guide to industrial control systems security [4] divides ICS in “Su-
pervisory Control And Data Acquisition (SCADA)” systems, “Distributed
Control Systems (DCS)” and other smaller control systems. This thesis is
focused on SCADA systems which are used to remotely monitor processes,
collect real-time data and then perform analysis on the accumulated data.
The foundation of SCADA dates back to the 1960’s. The old stand-alone
SCADA systems were not linked to other systems and computer networks.
A few years later the second generation of SCADA systems (Intranet-based
SCADA) were connected to corporate networks and became a part of the
Intranet. Nowadays SCADA systems (Internet-based SCADA) have full in-
tegration with corporate IT networks which are interconnected with Internet.
Operators can remotely monitor and control devices over the Internet.
The massive use of IT technologies has improved the efficiency of the opera-
tion, but it has made SCADA systems more vulnerable to security attacks.
The security of SCADA systems is more complicated than in the traditional
IT world for the following reasons: the early conventional SCADA design did
not provide protection against cyber-attacks and these old control systems
are still in use today because they are really difficult to upgrade, therefore it
is necessary to create new ad-hoc protection methods.
The aim of this thesis is to study the vulnerability of SCADA systems and
to try to protect them from external attacks. In the following intrusion de-
tection technology is discussed and some aspects for creating an “Intrusion
Detection System (IDS)” tailored for SCADA systems are defined. An IDS
is an application that monitors network or system activities to identify pos-
5
6 CHAPTER 1. INTRODUCTION
sible malicious intrusions or policy violations. In this thesis a ”State Based

Intrusion Detection System” is presented; it is similar to a traditional Net-
work IDS, but in addition it stores in memory the representation of the real
SCADA system called “System Virtual Image(SVI)”. Our enhanced IDS pro-
vides protection against several kinds of attacks such as the traditional and
the ad-hoc SCADA-tailored attacks.
The thesis is organized as follows: the second chapter provides a brief overview
of the state of the art in the field of SCADA security, while the third chap-
ter provides an overview of the SCADA systems. In the fourth chapter the
details of the most important SCADA protocols, i.e. MODBUS and DNP3,
are presented. In the fifth chapter is described the “Critical State Approach”
used to develop our IDS. In chapters six and seven there is a logic description
of the “State-Based IDS ” and a detailed explanation of its implementation.
In the eighth chapter, after describing our testbed, the experimental results
are presented and discussed.
Chapter 2
State of the art
As discussed in the introduction, when SCADA networks were developed,

security was not a concern. Historically, this is due to the fact that when
they were designed, the world of industrial control systems was completely
isolated from the public networks, and therefore ICT based intrusion scenar-
ios were considered completely negligible. Nowadays SCADA networks are
interconnected with corporate IT networks which are interconnected with
Internet, which requires that several aspects must be improved in order to
“secure” such architectures. Adam and Byres [12] presented an interesting
high level analysis of the possible threats affecting a power plant system, a
categorization of the typical hardware devices involved and some high level
discussion about intrinsic vulnerabilities of the common power plant archi-
tectures. A more detailed work on the topic of SCADA security, is presented
by Chandia, Gonzalez, Kilpatrick, Papa and Shenoi [13]. What is evident in
the mentioned article is that the most evident lack, in SCADA networks, is
the communication protocols used in such systems, (e.g. MODBUS, DNP3
etc.), because they not consider ICT security aspects. There are currently
many types of approaches to improve the security of SCADA networks, but
the most important are:
• Secure SCADA Protocols: this solution employs simple communi-
cation tunnels around SCADA protocols to add security functionality
in a transparent manner.
• Network Monitoring: this solution employs systems that can moni-
tor and interpret SCADA network traffic, in search of complex ad-hoc
SCADA-tailored attacks.
The first approach (i.e. Secure SCADA Protocols) is used in several
works. For example Majdalawieh, Parisi-Presicce and Wijesekera [14] pre-
sented an extension of the DNP3 protocol, called DNPsec, which tries to
7
8 CHAPTER 2. STATE OF THE ART
address some of the known security problems of such Master-slave control

protocols (i.e. integrity of the commands, authentication, non repudiation
etc.). Using the same method, the DNP3 User group proposed a “Secure
DNP3” implementing authentication mechanisms for certain type of com-
mands and packets. This protocol is extremely close to the one adopted in
the IEC 62351-5 standard. Nai, Carcano and Masera [15] presented a secure
implementation of the MODBUS protocol aimed at introducing integrity,
authentication and anti-replay mechanisms in the control flows based on the
Modbus protocol. Similar approaches have been presented also by Heo, Hong,
Ju, Lim, Lee and Hyun [16] while Mander, Navhani and Cheung [17] pre-
sented a proxy filtering solution aiming at identifying and avoiding anomalous
control traffic. The proposed solution is innovative, however it does not pro-
tect the system against two particular scenarios: the first scenario is one in
which an attacker is able to inject malicious packets directly in the network
segment between the proxy and the RTUs and he second scenario is one in
which both the proxy and the master have been corrupted and collaborate
in order to damage the process network. Against these kinds of attacks, Nai,
Carcano and Masera [18] presented an architecture integrating a mesh of dis-
tributed packet filtering mechanisms based on signatures, with cryptography
based integrity mechanisms.
The second approach (i.e. Network Monitoring) is used to monitor the
SCADA network for malicious activities. From the point of view of the IT
security, the most important network monitoring system is the ”Intrusion
Detection System (IDS)” which monitors a network for threats from the out-
side. Intrusion Detection is a well established field of research. The basic idea,
presented in the mid-eighties (see for example [19]), is to search for evidence
indicating that some malicious attack is being developed in a certain time
window. IDS can be classified according to (1) the source of the information
used to detect intrusions and (2) the detection technique used to discriminate
between licit behavior and malicious behavior. Adopting the first parameter
of discrimination it is possible to classify IDS into “Network Based Intrusion
Detection Systems” (i.e. IDS that analyze the network flow of a sub-net in
search of malicious packets) and “Host Based Intrusion Detection Systems”
(IDS that analyze the behavior of an host in search for suspicious behaviors).
Adopting the second parameter of discrimination (technique of detection), it
is possible to classify the IDS into: “Signature Based ” (i.e. Attacks are de-
tected by searching similarities between the information collected and a set
of patterns characterizing known attacks) and “Anomaly Detection Based ”,
where the attacks are identified by inspecting the system under analysis in
search of anomalous deviations from the standard system behavior.
In this work, we concentrate our attention on NIDS techniques, for the follow-
9
ing reason: the main components of a SCADA system are PLCs and RTUs,
which have usually low computational and memory resources. Host based
IDS sensors, conversely, need to be installed on the systems (PLCs, RTUs
in our case) to be analyzed and require a certain amount of memory and
computational power on the host machine. This makes such techniques not
suitable to monitor SCADA devices. On the other hand, NIDS sensors, in
order to perform their work need only to be installed on a machine having
the full access to the network segment to be monitored. In other words, they
are seamlessly integrated with respect to the SCADA system process pro-
file. In a field network in which interferences and performance degradation
might have catastrophic effects (consider for example the SCADA system
of a chemical or nuclear plant), such features of the NIDS make them the
most suitable approach in this context. Typical NIDS architectures are com-
posed of a number of distributed sensors which analyze the traffic flowing
through a network, searching for attack signatures and anomalies. In the
case of SCADA systems, such NIDS are able to understand and analyze in-
dustrial communication protocols like Modbus, DNP3, Profibus etc. In their
current implementations, these protocols (originally conceived for serial com-
munication) have been ported over TCP/IP and embedded into the payload
of a TCP packet. Traditional NIDS, like Snort [5], were unable to understand
such “application level protocols”. Only recently a set of ad-hoc rules [20]
have been released in order to detect some attacks over these protocols. Such
signatures can be clustered into the following categories:
• Unauthorized Modbus Users rules
• Modbus Protocol Errors rules
• Scanning detection rules
A traditional NIDS provided with such rules could be able to identify very
primitive, single packet-based attacks, in which the attacker just sends a for-
bidden packet to a target PLC, or uses rare commands. However, as showed
in [6], SCADA attacks can be extremely complex, and are rarely composed of
just one step (i.e. the exploit of a single vulnerability). Conversely, the trend
is towards attacks consisting of a complex sequence of simpler or atomic
steps. In this case, the system will need to be capable of identifying these
complex and dangerous attacks, by analyzing and correlating a number of dif-
ferent low-risk atomic operations. In the scientific literature on IDS systems
for traditional ICT, there are several examples of the utilization of similar
approaches. In particular, Gross, Parekh and Kaiser [21] have proposed a
mechanism for collaborative intrusion detection (“selecticast”) which uses
10 CHAPTER 2. STATE OF THE ART
a centralized server in order to dispatch among the ID sensors information

about activities coming from suspicious IP addresses. In the same way Yeg-
neswaran, Barford and Jha [22] introduce the concept of Distributed Overlay
for Monitoring InterNet Outbreaks. These approaches are useful in order to
provide a broader picture of the suspicious events happening in the whole
monitored system to each intrusion detection sensor. However, they do not
provide any kind of specific technique allowing identification of high level
and complex malicious actions especially in relation with industrial process
systems. Ning, Cui and Reeves [23] have proposed a model which aims at
identifying causal relationships between alerts on the basis of pre-requisites
and consequences. Similarly, the approach proposed by Cuppens and Miege
in [24] adopts pre and postconditions and includes several analysis phases,
including alert clustering, alert merging and intention recognition. The intent
of this approach is to facilitate the automatic generation of correlation rules.
Unfortunately, this technique, in several situation, can generate a number of
spurious correlation rules that might increase the noise in the ids alerting
system. In each of the presented techniques the correlation is based on the
capability of identifying “malicious actions”. In other words, the alerts re-
lated to such malicious actions are used as feeds in the correlation systems.
However, in industrial system a chain of apparently licit events could bring
the system into an unwanted, critical state. For that reason, we believe that
an IDS for process networks, should be able to correlate also licit events in
search of malicious final states. In chapter 5 we describe the approach we
have adopted to achieve this goal, called “Critical State Approach”.
Chapter 3
SCADA system architecture
SCADA is an acronym for Supervisory Control and Data Acquisition. A

SCADA system is an industrial control system: a computer-based system
monitoring and controlling a process. The processes can be clustered into
the following categories:
• Manufacturing: SCADA systems manage manufacturing, regulate in-

dustrial automation and robots, and monitor process and quality con-
trol.
• Electric utilities: SCADA systems manage generation, transmission

and distribution of electric power.
• Water and sewage: state and municipal water utilities use SCADA
to monitor and regulate water flow, reservoir levels, and pipe pressure.
• Mass transport: transport authorities use SCADA to regulate elec-

tricity to subways and trams; to automate rail systems; to track and
locate trains and buses; and to control railroad-crossing gates.
• Traffic signals: SCADA regulates traffic lights and controls traffic

flow.
• Oil and gas pipelines: Oil and gas operations are located in bad
environment, such as arctic or desert places, therefore is necessary a
remote controller using SCADA systems.
• Chemical Industries: SCADA systems are used to regulate chemical

plants remotely, therefore humans can avoid exposure to dangerous
chemical and toxic environments.
11
12 CHAPTER 3. SCADA SYSTEM ARCHITECTURE
The use of SCADA systems brings many benefits. A properly designed SCADA
system saves time and money. Such systems eliminate the necessity of the
on-going technological process personnel’s presence and drastically reduce
the number of inspection visits for system’s device maintenance.
3.1 System Components

A SCADA system is composed by the elements in figure 3.1:
Process Network
Operator Human Machine Interface (HMI)
Master Terminal Unit (MTU)
Control Network
PLC PLC RTU RTU

Remote Terminal Units (RTUs)
Fan Valve
Pump
Field Network
Figure 3.1: SCADA System Components
• Operator: Human operator who monitors the SCADA system.

3.2. CONTROL NETWORK 13
• Human machine Interface(HMI): the device which presents pro-

cess data to a human operator, and through which the human operator
controls the process.
• Master Station or Master Terminal Unit (MTU): it presents

data to the operator through the HMI interface, gathers data form the
distant site, and transmits control signals to the remote site.
• Slave Station or Remote Terminal Unit (RTU): it gathers data

from field devices (pumps, valves, fans, etc.) and transmits the data to
the MTU.
As showed in figure 3.1 a SCADA system spreads among two networks:
• Control Network: it contains all the RTU and Programmable Logic

Controllers (PLC). It is directly interfaced with the field network, i.e.
the network of actuators and sensors, that physically perform the pro-
cess tasks on the system. Moreover, it sends to the Process Network
the data gather form field devices.
• Process Network: it is composed of the master SCADA servers that

gather the data coming from the Control Network, send commands to
the Control Network and presents data to the operator through the
HMI.
In the following we provide a description of each of these two network.
3.2 Control Network

As mentioned in the previous section, the control network functions control
field devices and provide a ”control interface” to the process network. The
process network is composed by PLC-RTU and network switches:
• PLC and RTU: they are microprocessor controlled electronic devices

which interfaces field objects to the SCADA system by transmitting
telemetry data to the system and/or altering the state of connected
objects based on control messages received from the system. The only
difference is that RTUs are more suitable for wide geographical teleme-
try, while PLCs are more suitable for local area control.
• Network switches: physical media used to send data to the MTU.

The figure 3.2 shows the Control Network components and data flows.
Thin Line: 0-24 V Electric Signal

Process Network
Thick Line: SCADA Protocols
Network Switch
DI
Flow 1
PLC
AI
PLC Flow 3 Network
Switch PLC
CPU
DO
PLC
Flow 2
AO
Field Network
Co-Processor
Field Network
Flow 5
Network Switch PLC
Figure 3.2: Control Network Data Flows
The most important devices in a Control Networks are PLCs which are
composed by: one or more Central Processing Unit (CPU), sets of Digital
Inputs(DI), Analogical Inputs(AI) Digital Output(DO), Analogical Output
(AO) and a set of co-processors.
• Digital and Analogical Inputs(DI,AI): They receive data from the

field devices under the form of electric signals (0-24 V usually). They
send such information, if required, to the PLC CPUs, through a serial
connection using SCADA protocols (like MODBUS, Profibus etc.). The
flows here are unidirectional.
• Digital and Analog Outputs(DO,AO): They receive data from the

PLC CPU through SCADA protocols, then the data are converted into
electric signals and are sent to the field devices.
3.3. PROCESS NETWORK 15
• PLC CPU: It is involved in several data flows:
– Flow 1: The CPU receives data from the Process Network, usually
commands sent by the MTU to the field devices, then sends the
responses to such commands (using SCADA protocols).
– Flow 2: The CPU sends commands to the Co-processor then re-

ceives the responses (using SCADA protocols).
– Flow 3: The CPU sends commands to other PLCs then receives the
responses (using SCADA protocols). Such commands can be the
result of an internal, low level computation, or can be part of the
set of commands received previously from the Process Network.
The CPU, as we described before, receives also data from the Analog
and Digital Inputs and sends commands to the Analog and Digital
Outputs.
• PLC Co-processor: It is a computer processor used to supplement the

functions of the primary processor (the CPU). Usually the Co-processor
has been conceived for a specific communication SCADA protocol and
it is in charge to communicate with other PLCs understanding such
protocol. It is involved in the following data flows:
– Flow 2: The Co-processor receives commands from the CPU then

sends the responses.
– Flow 5: The Co-processor sends commands (received from the

CPU in the Flow 2) to the other PLCs, then receives the re-
sponses (using SCADA protocol for which the co-processor has
been conceived).
3.3 Process Network

The process network usually contains the SCADA Servers which are used to
keep under control the physical devices. From an architectural point of view,
this network hosts the elements in figure 3.3.
Flow 5 Exchange Network

Network Switch
Flow 1 SCADA
Server Flow 2 Network Network
Switch
HMI Switch
Flow 3 Flow 4 Flow 6

Network Switch Network
Network Switch Flo Switch
w Control Network
4
(Intranet)
Network
Switch
Process Network OPC Flow 4 Network

Network Switch Server Switch
BUILDER Flow 4 Network

Network Switch
Server Switch
Figure 3.3: Process Network Data Flows
• SCADA Server: it provides the means by which an operator can

remotely control the entire SCADA system. It is involved in several
data flows:
– Flow 1: The SCADA Server sends commands (or queries about

the system state) to PLCs on the Control Network, then receives
the responses (using SCADA protocols).
– Flow 2: The SCADA Server receives queries from the HMI, then
sends the responses.
– Flow 3: The SCADA Server sends commands to the OPC server,
then receives the responses (using a SCADA protocol embedded
into OPC packets).
3.3. PROCESS NETWORK 17
– Flow 4: The SCADA Server is subjected to the usual network

traffic from the corporate network, due to the classical remote
desktop applications, anti-virus updates and system updates.
– Flow 5: The SCADA Server sends data to Exchange Network.
• OPC Server: An OPC Server is a protocol converter which receives

commands from the SCADA server (using a SCADA protocol embed-
ded into OPC packets) than sends these commands (using OPC pro-
tocol) to OPC PLCs and vice versa for responses. It is also involved in
the Flow 4 used for the classical remote desktop applications, anti-virus
updates and system updates.
• HMI: as mentioned before, there is a ”client-server” data flow between

the HMI and the SCADA Server. It is also involved in the Flow 4 used
for the classical remote desktop applications, anti-virus updates and
system updates.
• Builder Server: it is the server usually used in order to ”program”

the PLCs. it sends data to the PLCs in order to configure them, it
receives acknowledgements from the PLCs. The transmission media
can be Ethernet or a Serial cable. It has to be also connected with the
corporate network, in order to be able to download the control code on
the related PLC. It is also involved in the Flow 4, used for the classical
remote desktop applications, anti-virus updates and system updates.
There is also a data flow 6 between Corporate Network and Exchange Net-
work. The Exchange Network contains usually some servers such as historical
databases called “historians”. All data, reports, configuration, and events etc.
are stored periodically in the historical databases. Nodes in the Corporate
Network can access the data in the “historians” through the flow 6: they can
query the database and receive the answers.
3.4 SCADA Reference Architecture

Figure 3.4 provides an example of how a secure architecture connect SCADA
network to the rest of the world.
Remote Site
Internet
Radius + VPN
Intranet Server
Process Network
Radius + VPN
Server
SCADA SCADA HMI

Server Server
Control Network
Firewall
+ VPN
DMZ Network
PLC PLC PLC
Fan Valve
Pump
Historian Historian
Field Network
Figure 3.4: A firewalling architecture used to separate SCADA network and

external networks.
In the previous section we focused our attention on the SCADA network,

but such networks are not closed system controlled only by trusted elements.
The process network needs to be accessed by external elements for mainte-
nance purposes (e.g. remote operators, vendor support services etc.). In the
real world the process network and the external network are in some way
connected. The best way to protect the process network is a firewall or a
firewalling architecture which keeps the external network and the process
network separated. From networking perspective, it is possible to identify
some major entities:
3.4. SCADA REFERENCE ARCHITECTURE 19
Control Network: it contains all the PLCs. It is directly interfaced with the
field network, i.e. the network interconnecting the sensors, and the actuators
which physically perform the process tasks on the system. Additionally, it
sends to the Process Network the data gather form field devices.
Process Network: it is composed of the master SCADA servers that gather

the data coming from the Control Network, send commands to the Control
Network and presents data to the operator through the HMI.
Demilitarized Zone(DMZ): this area hosts a set of “data exchange” servers

called historians, which receive data from the process network and make them
available to the operators which work in the Corporate Intranet.
Intranet: It is the generic Intranet of the Company that operates the Power
Plant. It is usually based on a classical Windows domain architecture.
Firewall + VPN: it is used to separate the process network and the control
network from the rest of the world. In a similar configuration is important
to define exactly the flow directions allowed as shown in Table 3.1.
Direction Allowed
Intranet → DMZ YES
Intranet → Process network NO
Intranet → Control network NO
DMZ → Intranet No (allowed only replies to flows originally
started from the Intranet)
DMZ → Process network NO (allowed only replies to flows originally
started from the Process Network) in the case
in which the SCADA server is separated from
the historian and is hosted into the process
network
YES if historian and SCADA servers are
hosted all into the DMZ
DMZ → Control network NO
Process network → DMZ YES
Process network → Intranet NO
Process network → Control network YES
Control network it is allowed only the flow with the Process
network(in both direction); all the other flows
are forbidden.
Table 3.1: Firewall allowance table
The firewall act also as VPN server. In order to access the plant networks
(DMZs, process and field networks), the operators hosted into the intranet,
will need to authenticate themselves to the VPN-firewall, which will also al-
low to create an host-to site VPN connection between the PC of the operator
and the firewall. In this way the access to the plant networks is extremely
enforced.
Remote Site: The operators hosted into a remote site can connect them-
selves to the local Intranet through a site to site VPN, showing their creden-
tials to a Radius authentication server.
Chapter 4
SCADA Protocols and

vulnerabilities
SCADA protocols are communication protocols designed for the exchange of

commands/information between Masters and Slaves on industrial networks.
They are the core of every SCADA system. Over the past three decades,
several of these protocols have been developed for serial, LAN and WAN
based communications. Currently, the industrial marketplace is dominated
by approximately 10 protocols such as MODBUS, DNP3, PROFIBUS and
Foundation Fieldbus.
SCADA protocols originally designed in the ’70s for serial communication.
The traditional SCADA system was a closed network that contained only
trusted devices with little or no connection to the outside world. As control
networks evolved, the use of TCP/IP and Ethernet became common place
and interfacing to business systems became the norm. The result was that
the closed trust model no longer applied and vulnerabilities in these systems
began to appear. Several vulnerabilities into the SCADA architectures are
due to weaknesses of the SCADA protocols. In order understand them, in the
following we will provide an overview of two SCADA protocols: MODBUS
and DNP3.
21
22 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
4.1 MODBUS
MODBUS is one of the most popular protocols used in the industrial world.
It is an application layer messaging protocol, positioned at level 7 of the OSI
model providing client/server communication between devices connected on
different types of buses or networks.
MODBUS APPLICATION LAYER
Modbus on TCP
TCP
IP
Other MODBUS+ Master / Slave Ethernet II /802.3
EIA/TIA-232 Ethernet
Other Physical layer
EIA/TIA-485 Physical layer
Figure 4.1: MODBUS Communication Stack
As shown in Figure 4.1, MODBUS is currently implemented using several

buses or networks:
• TCP/IP over Ethernet.
• Asynchronous serial transmission over a variety of media (wire : EIA/TIA-

232-E, EIA-422, EIA/TIA-485-A; fiber, radio, etc.).
• MODBUS PLUS, a high speed token passing network.
4.1.1 MODBUS Application Data Unit

The MODBUS protocol specification [1] defines the format of a MODBUS
message which is called Application Data Unit (ADU). Each Application
Data Unit (ADU) is composed by the following fields:
4.1. MODBUS 23
• Protocol Data Unit (PDU): it contains the core information for the
MODBUS protocol and it is independent of the underlying communi-
cation layers.
• Additional fields: they are related to the communication protocol

used by the layers below.
The Figure 4.2 shows a general MODBUS Frame regardless of the underlying
layers.
ADU (Application Data Unit)
Additional address Function code Data Error check
PDU (Protocol Data Unit)
Figure 4.2: General MODBUS Frame
The original MODBUS specification included two possible transmission

modes:
• RTU Mode: is the most common implementation, using binary coding

and CRC error-checking.
• ASCII Mode: is less efficient, uses ASCII coding and uses less effective
LRC error checking.
The two modes are incompatible, so a device configured for ASCII mode
cannot communicate with one using RTU. MODBUS/TCP is a much more
recent development, created to allow MODBUS ASCII/RTU protocol to be
carried over TCP/IP-based networks. MODBUS/TCP embeds MODBUS
messages inside TCP/IP frames.
MODBUS over Serial Line ADU

The MODBUS over Serial Line ADU has the fields in Figure 4.3.
MODBUS SERIAL ADU (256 bytes)

PDU (253 bytes)
Slave ID Function code Data CRC

1 byte 1 byte 252 bytes 2 bytes
0 1 2 253 255
Figure 4.3: Serial Application Data Unit (ADU)
• Slave ID: Slave identificator (1 byte 28 = 256; from 0 to 255).
• Function Code: defines the type of action required (1 byte 28 = 256;

from 0 to 255).
• Data: contains additional information that are used to take the action
defined by the function code. This can include items like discrete and
register addresses, the quantity of items to be handled, and the count
of actual data bytes in the field.
• CRC: the cyclic redundancy check is an error control function.
MODBUS over TCP/IP network ADU

The MODBUS over TCP/IP network ADU has the fields in Figure 4.4.
MODBUS TCP/IP ADU (260 bytes)

PDU (253 bytes)
MBAP Header Function code Data

7 bytes 1 byte 252 bytes
0 6 7 259
Figure 4.4: TCP/IP Application Data Unit (ADU)
The Protocol Data Unit (PDU) is the same as in MODBUS over Serial
Line, but there is an additional header called MODBUS Application Proto-
col header (MBAP header). It contains some useful fields for the TCP/IP
4.1. MODBUS 25
protocol.
The header is 7 bytes long an it has the following structure:
Transaction Protocol Length Unit

Identifier Identifier Identifier
2 bytes 2 bytes 2 bytes 1 byte
Table 4.1: MPAB Header Fields
• Transaction identifier: identification of a MODBUS Request/Re-

sponse transaction. Initialized by the master and recopied by the slave
from the received request.
• Protocol Identifier: 0 = MODBUS protocol. Initialized by the mas-

ter.
• Length: Number of following bytes.
• Unit Identifier: Identification of a remote slave. It is typically used

to communicate to a MODBUS serial line slave through a gateway
between an Ethernet TCP-IP network and a MODBUS serial line.
4.1.2 MODBUS Protocol Data Unit

The Protocol Data Unit (PDU) is the only part that does not change in the
ADU because it is independent of the underlying communication layers. The
MODBUS protocol specification [1] defines three PDUs:
Request Protocol Data Unit
Function Code Request Data

1 byte 252 bytes
Table 4.2: Request Protocol Data Unit
• Function Code: defines the type of action required.
• Data: contains additional information used to take the action defined

by the function code.
Response Protocol Data Unit
Function Code Response Data

1 byte 252 bytes
Table 4.3: Response Protocol Data Unit
• Function Code: the function code corresponding to the request.
• Data: the response specific data.
Exception Response Protocol Data Unit
Exception Function Code Exception Code

1 byte 1 bytes
Table 4.4: Exception Response Protocol Data Unit
• Exception Function Code: the function code corresponding to the

request + 0x80 (128), which means the most significant bit set to 1.
• Data: a code specifying the exception.
These Protocol Data Units (PDUs) are used in different MODBUS transac-
tions as explained in the next section.
4.1.3 MODBUS Transactions

The MODBUS protocol follows a master/slave (client/server) architecture
where a master will request data from the slave. The master can also ask the
server to perform some actions. Only the master can initiate transactions or
queries. The other devices, slaves, respond by supplying the requested data
to the master or by taking the action requested in the query. There are two
kinds of transactions:
4.1. MODBUS 27
MODBUS Transactions (error free)
Master Slave
1. Initiate request
Function code Data Request 3. Receive request
2. Send request 1 byte 252 bytes
4. Perform the action
5. Initiate the response
7. Receive Function code Data Response
6. Send response
1 byte 252 bytes
response
Figure 4.5: MODBUS transaction (error free)
The master node builds the request message, then sends it to the slave. The
slave receives the request than search the requested data or performs the
requested action. After it builds the response message and sends it to the
slave.
MODBUS Transactions (exception response)
Master Slave
1. Initiate request
Function code Data Request
2. Send request 1 byte 252 bytes
3. Receive request
4. Error Detection
5. Initiate the exception
response
7. Receive ExceptionFunction code Exception Code
6. Send exception
1 byte 1 byte
response response
Figure 4.6: MODBUS transaction (exception response)
The master node builds the request message, then sends it to the slave.
The slave receives the request, but an exception occurs while processing the
function code. The slaves will return a function code that is equivalent to
the original function code with the most significant bit set to logic 1 and an
exception function code which specifying the exception occurred.
4.1.4 MODBUS Data Model

MODBUS transactions always perform a set of actions by reading or writing
to a set of four data types. Table 4.5 describes the four data formats used by
the MODBUS application layer.
Primary Table Object Type Type of Comments

Discrete Input Single bit Read-Only can be provided by an
I/O system.
Coils Single bit Read-Write can be alterable by an
application program.
Input Registers 16-bit word Read-Only can be provided by an
I/O system.
Holding Registers 16-bit word Read-Write can be alterable by an
application program.
Table 4.5: MODBUS Data Model
The Table 4.1.4 explains the same data models, but from the point of
view of the I/O system:
Digital Inputs Discrete Inputs 1 bit

Inputs
Analog Inputs Input Registers 16 bits
Digital Outputs Colis 1 bit
Outputs
Analog Outputs Holding Registers 16 bits
4.1.5 MODBUS Function Codes

Function code field in the MODBUS ADU is 1 byte field. The MSB(Most
Significant Bit) is 0 for Request and Response and 1 for Exception Response
so the function codes are 27 = 128 (0-127). There are three categories of
MODBUS Functions codes. They are :
• Public Function Codes(1-65,72-100,110-127): well defined func-

tion codes, validated by the MODBUS-IDA.org community, publicly
documented, have available conformance test.
4.1. MODBUS 29
• User-Defined Function Codes(65-72,100-110): user can select and

implement a function code that is not supported by the specification.
• Reserved Function Codes: function Codes currently used by some

companies for legacy products and that are not available for public use.
The Table 4.6 shows the public function codes and sub-codes:
01 0x01 Read Coils 1 bit

02 0x02 Read Discrete Inputs 1 bit
03 0x03 Read Holding Registers 16 bits
04 0x04 Read Input Registers 16 bits
05 0x05 Write Single Coil 1 bit
06 0x06 Write Single Register 16 bits
07 0x07 Read Exception Status
08 0x08 Diagnostics
00 (0x00) Return Query Data
01 (0x01) Restart Communications Option
02 (0x02) Return Diagnostic Register
03 (0x03) Change ASCII Input Delimiter
04 (0x04) Force Listen Only Mode
10 (0x0A) Clear Counters and Diagnostic Register
11 (0x0B) Return Bus Message Count
12 (0x0C) Return Bus Communication Error Count
13 (0x0D) Return Bus Exception Error Count
14 (0x0E) Return Slave Message Count
15 (0x0F) Return Slave No Response Count
16 (0x10) Return Slave NAK Count
17 (0x11) Return Slave Busy Count
18 (0x12) Return Bus Character Overrun Count
19 (0x14) Clear Overrun Counter and Flag
11 0x0B Get Comm Event Counter
12 0x0C Get Comm Event Log
15 0x0F Write Multiple Coils 1 bits
16 0x10 Write Multiple registers 16 bits
17 0x11 Report Slave ID
20 0x14 Read File Record
21 0x15 Write File Record
22 0x16 Mask Write Register 16 bits
23 0x17 Read/Write Multiple registers 16 bits
24 0x18 Read FIFO Queue 16 bits
43 0x2B Encapsulated Interface Transport
13 (0x0D) CANopen General Reference Req and Resp PDU
14 (0x0E) Device Identification
Table 4.6: MODBUS function codes
In the following are presented some important and illustrative function

codes.
0x01 Read Coils (01)

Reads the ON/OFF status of discrete outputs (coils) in the slave.
Request
Function code 1 byte 0x01 01
Starting Address 2 bytes 0x0000-0xFFFF 00-65535
Quantity of coils 2 bytes 0x0001-0x07D0 1-2000
Response
Byte Count 1 bytes n n
Coil Status n bytes values values
n = Quantity of coils / 8, if the reminder is 6= 0 then n=n+1
Exception Response
Function code 0x81 Function Code + 0x80
Exception code 0x01,02,03,04 Exception code
Read Coils Example:

Read Coils 20-36 example.
Request
Function code 0x01 01
Starting Address 0x0013 19
Quantity of coils 0x0013 17
Response
Byte Count 0x03 3
Coil status(byte 1) 27-20 0xCD 1100 1101
Coil status(byte 2) 35-28 0x6B 0110 1011
Coil status(byte 3) 38-36 0x05 0000 0001
The registers values red by the master are:
27 26 25 24 23 22 21 20
1 1 0 0 1 1 0 1
35 34 33 32 31 30 29 28
0 1 1 0 1 0 1 1
* * * * * * * 36
0 0 0 0 0 0 0 1
4.1. MODBUS 31
The Function Code “0x02 Read Discrete Inputs (02)” has exactly
the same message format.
0x03 Read Holding Registers (03)

Reads the 16-bit values of holding registers in the slave.
Request
Starting Address 2 bytes 0x0000-0xFFFF 00-65535
Quantity of Registers 2 bytes 0x0001-0x007D 1-125
Response
Byte Count 1 bytes n n
Register Status n bytes values values
n = Quantity of Registers * 2
Exception Response
Read Holding Registers Example:

Read Holding Registers 108-110 example.
Request
Starting Address 0x006B 107
Quantity of registers 0x0003 3
Response
Byte Count 0x06 6
Register status(byte 1) 108 HI 0x02
Register status(byte 2) 108 LO 0x2B
Register status(byte 1) 109 LO 0x00
Register status(byte 3) 110 LO 0x64
The registers values red by the master are: HR[108] = 0x022B = 555,
HR[109] = 0x0000 = 0, HR[108] = 0x0064 = 100.
The Function Code “0x04 Read Input Registers (04)” has exactly the
same message format.
0x05 Write Single Coil (05)

Write a single coil to either ON or OFF in the slave.
Request
Output Address 2 bytes 0x0000-0xFFFF 00-65535
Output value 2 bytes 0x0000-0xFF00 0-65280
Response
Output Address 2 bytes 0x0000-0xFFFF 00-65535
Output value 2 bytes 0x0000-0xFF00 0-65280
Exception Response
Write Single Coil Example:

Write coil 173 ON example.
Request
Output Address 0x00AC 172
Output value 0xFF00 ON (0x0000 is OFF)
Response
Output Address 0x00AC 172
Output value 0xFF00 ON (0x0000 is OFF)
0x0F Write Multiple Coils (15)

This function code is used to write each coil in a sequence of coils to either
ON or OFF. The request message specifies the coil references to be written.
The requested ON/OFF states are specified by contents of the request data
4.1. MODBUS 33
field. A logical ’1’ in a bit position of the field requests the corresponding
output to be ON. A logical ’0’ requests it to be OFF. The normal response
returns the function code, starting address, and quantity of coils written.
Request
Function code 1 byte 0x0F 15
Starting Address 2 byte 0x0000 to 0xFFFF
Quantity of Outputs 2 byte 0x0000 to 0x07B0 0-1968
Byte Count 1 byte n
Outputs Value n byte values values
n = Quantity of Outputs / 8, if the reminder is 6= 0 then n=n+1
Response
Function code 1 byte 0x0F 15
Quantity of Outputs 2 byte 0x0000 to 0x07B0
Exception Response
Function code 0x8F Function Code + 0x80
Write Multiple Coil Example:

Request to write a series of 10 coils starting at coil 20.
Request
Function code 1 byte 0x0F 0F
Starting Address 2 bytes 0x0013 19
Quantity of Outputs 2 bytes 0x000A 10
Byte Count 1 bytes 0x02 2
Outputs Value (reg. 27-20) 1 bytes 0xCD 1100 1101
Outputs Value (reg. 29-28) 2 bytes 0x01 0000 0001
Response
Function code 1 byte 0x0F 0F
Quantity of Outputs 2 bytes 0x000A 10
The binary bits correspond to the outputs in the following way:

27 26 25 24 23 22 21 20
1 1 0 0 1 1 0 1
* * * * * 30 29 28
0 0 0 0 0 0 0 1
0x06 Write Single Register (06)
Write a single 16-bit holding register in the slave.
Request
Register Address 2 bytes 0x0000-0xFFFF 00-65535
Register value 2 bytes 0x0000-0xFFFF 0-65535
Response
Register Address 2 bytes 0x0000-0xFFFF 00-65535
Register value 2 bytes 0x0000-0xFFFF 0-65535
Exception Response
Write Single Register Example:
Write the value 0x0003 in the holding register 2.
Request
Register Address 0x0001 1
Register value 0x0003 3
Response
Register Address 0x0001 1
Register value 0x0003 3
4.1. MODBUS 35
0x10 Write Multiple registers (16)

This function code is used to write a block of contiguous registers (1 to 123
registers) in a remote device. The requested written values are specified in
the request data field. Data is packed as two bytes per register. The normal
response returns the function code, starting address, and quantity of registers
written.
Request
Quantity of Registers 2 byte 0x0000 to 0x07B0 0-123
Byte Count 1 byte n n
Registers Value n byte values values
n = Quantity of Registers * 2
Response
Quantity of Registers 2 byte 0x0000 to 0x07B0
Exception Response
Write Multiple registers Example

Here is an example of a request to write two registers starting at 2 to 00 0A
and 01 02 hex.
Request
Quantity of Registers 2 bytes 0x0002 2
Byte Count 1 bytes 0x04 4
Outputs Value (reg. 01) 2 bytes 0x000A
Outputs Value (reg. 02) 2 bytes 0x0102
Response
Quantity of Registers 2 bytes 0x0002 2
0x07 Read Exception Status (07)

This function code is used to read the contents of eight Exception Status
Coils in a remote device. Coils can be programmed by the user to hold in-
formation about the controller’s status, for example, “machine ON/OFF”,
“heads retracted”, “safeties satisfied”, “error conditions exists”, or other user
defined flags. The normal response contains the status of the eight Exception
Status outputs. The outputs are packed into one data byte, with one bit per
output.
Request
Response
Output Data 1 bytes 0x00-0xFF 00-255
Exception Response
Exception code 0x01,04 Exception code
Example:
In the Modicon Controller 484 the 8 status coils are:
257 258-264
Battery Status User defined
The request/response to read the exception status coils is:

Request
Response
Output Data 0x6D 0110 1101
The coils values red by the master are:

264 263 262 261 260 259 258 257
0 1 1 0 1 1 0 1
In this example, coil 257 is ON, indicating that the controller’s battery is
OK.
4.1. MODBUS 37
0x08 Diagnostics (08)
MODBUS function code 08 provides a series of tests for checking the commu-
nication system between a Master device and a Slave, or for checking various
internal error conditions within a slave. The function uses a two bytes sub-
function code field in the query to define the type of test to be performed.
Request
Sub-Function 2 bytes 0x0000-0xFFFF
Data n bytes values values
Response
Sub-Function 2 bytes 0x0000-0xFFFF
Data n bytes values values
Response
Exception code 0x01,03,04 Exception code
Sub-function codes
In the following there are some of the most important sub-function codes.
0x00 Return Query Data (00)
The data passed in the request data field is to be returned (looped back) in
the response. The entire response message should be identical to the request.
Response
Sub-Function 2 bytes 0x0000 0
Data n bytes Any Any
Response
Data N x 2 bytes Echo Request Data Echo Request Data
0x04 Force Listen Only Mode (04) and 0x01 Restart Communica-
tions Option (01)
The function code “Force Listen Only Mode” forces the addressed remote
device to enter into the “Listen Only Mode”. When the remote device en-
ters in Listen Only Mode, all active communication controls are turned off.
While the device is in this mode, any MODBUS messages addressed to it or
broadcast are monitored, but no actions will be taken and no responses will
be sent. The only function that will be processed after the mode is entered
will be the Restart Communications Option function (function code 8, sub-
function 1). The Figure 4.7 shows the two MODBUS operational mode and
how to pass from the normal “on-line mode” to the “Listen Only Mode”.
0x08 / 0x04
Force Listen Only Mode
Online Listen Only

Mode Mode
0x08 / 0x01
Restart Communication Options
Figure 4.7: Listen Only Mode
The remote device could be re-activated by the command “Restart Com-

munications Option”. When such device receives this command it performs
a re-initialization: the remote device port must be initialized and restarted,
and all of its communications event counters are cleared. The successful com-
pletion of the restart will bring the port on-line. This function is the only
one that brings the port out of Listen Only Mode. If the port is currently
in Listen Only Mode, no response is returned, otherwise if the port is not
currently in Listen Only Mode, a normal response is returned. The request
message with the function code “Force Listen Only Mode” has the following
structure and response is not required.
Request
Data 1 byte 0x0000
4.1. MODBUS 39
The request/response message transaction for the function code “Restart

Communications Option” is shown below. A request data field contents of FF
00 hex causes the port’s Communications Event Log to be cleared. Contents
of 00 00 leave the log as it was prior to the restart. The response is only a
request echo.
Request
Data N x 2 bytes 0x0000 or 0xFF00
Response
Data N x 2 bytes Echo Request Data (0x0000 or 0xFF00)
In the MODBUS salve device there is a flag to identify the current mode of
the device. For example in the Modicon 184/384 the 4th bit of the Diagnostic
Register is called “Force Listen Only Mode” and if it is ON the device is in
Listen Only Mode and if it is OFF the device is in On line Mode.
0x02 Return Diagnostic Register (02)
The diagnostic register is used in a MODBUS device to store some diagnostic

information about the device itself. The contents of the remote device’s 16-bit
diagnostic register are returned in the response.
Request
Data 2 byte 0x0000
Response
Data 2 byte Diagnostic Register Content
Return Diagnostic Register Example
The diagnostic register is a normal 16-bit register, but each bit has a special
diagnostic meaning. For example in the Modicon 184/384 the Diagnostic
Register bits have the following meanings:
0 Continue on Error
1 Run Light Failed
2 T-Bus Test Failed
3 Asynchronous Bus Test Failed
4 Force Listen Only Mode
5-6 Not Used
7 ROM Chip 0 Test Failed
8 Continuous ROM Checksum Test in Execution
12 RAM Chip 5000-53FF Test Failed
13 RAM Chip 6000-67FF Test Failed, Even Addresses
14 RAM Chip 6000-67FF Test Failed, Odd Addresses
15 Timer Chip Test Failed
Counter Function Codes 0x0B(11) - 0x12(18)
The sub-function codes from 0x0B(11) to 0x12(18) are used to return the
counter values. Each counter counts a specific kind of messages. In the MOD-
BUS specification [1] are defied eight counters. The Table 4.7 shows a list of
MODBUS counters.
N. Name Sub-fc Meaning

1 Bus Message Counter 0x0B(11) Quantity of messages that the slave
has detected
2 Bus Communication Error 0x0C(12) Quantity of CRC errors that the
Counter slave has detected
3 Bus Exception Error 0x0D(13) Quantity of MODBUS exception re-
Counter sponses that the salve has returned
4 Slave Message Counter 0x0E(14) Quantity of messages that the slave
has processed
5 Slave No Response Counter 0x0F(15) Quantity of messages addressed to
the slave for which it returned no re-
sponse.
6 Slave NAK Counter 0x10(16) Quantity of messages addressed to
the slave for which it returned a Neg-
ative Acknowledge (NAK)
7 Slave Busy Counter 0x11(17) Quantity of messages addressed to
the slave for which it returned a Slave
Device Busy exception response
8 Overrun Counter 0x12(18) Quantity of messages addressed to
the slave that it could not handle due
to a character overrun condition
Table 4.7: MODBUS Counters

4.1. MODBUS 41
Each Sub-function code form 0x0B(11) to 0x12(18) has the same name:
“Return Register Name” and returns to the master the counter 16-bit value.
The request/response transaction is very simple: the response data field re-
turns the quantity of messages that the remote device has detected on the
communication system since its last restart, clear counters operation, or
power up.
Request
Sub-Function 2 bytes 0x000B 12
Data 1 byte 0x0000
Response
Sub-Function 2 bytes 0x000B 12
Data 1 byte Total Message Count
Example Sub-function code

Here is an example of a request to remote device to Return Query Data. This
uses a subfunction code of zero (00 00 hex in the two-byte field). The data
to be returned is sent in the two-byte data field (A5 37 hex).
Request
Sub-function code 2 byte 0x0000 00
Data 2 bytes 0xA537
Response
Sub-function code 2 byte 0x0000 00
Data 2 bytes 0xA537
4.1.6 MODBUS Exception Code

When a master device sends a request to a slave device it expects a normal
response. One of four possible events can occur from the master’s query:
• If the slave device receives the request without a communication error,
and can handle the query normally, it returns a normal response.
• If the slave does not receive the request due to a communication error,
no response is returned. The master program will eventually process a
timeout condition for the request.
• If the slave receives the request, but detects a communication error

(parity, LRC, CRC, ...), no response is returned. The master program
will eventually process a timeout condition for the request.
• If the slave receives the request without a communication error, but
cannot handle it (for example, if the request is to read a non-existent
output or register), the slave will return an exception response inform-
ing the master of the nature of the error.
The exception response message has two fields that differentiate it from a
normal response:
Function Code Field: In a normal response, the slave echoes the func-
tion code of the original request in the function code field of the response.
All function codes have a most significant bit (MSB) of 0 (their values are all
below 80 hexadecimal). In an exception response, the slave sets the MSB of
the function code to 1. This makes the function code value in an exception
response exactly 80 hexadecimal higher than the value would be for a normal
response. With the function code MSB set, the master’s application program
can recognize the exception response and can examine the data field for the
exception code.
Data Field: In a normal response, the slave may return data or statistics in
the data field. In an exception response, the slave returns an exception code
in the data field. This defines the slave condition that caused the exception.
Exception Code Example:
Response
Function Code 1 byte 0x01(Read Coils) 01
Starting Address 2 byte 04A1 1185
Quantity of colis 1 byte 0x01
Exception Response
Exception code 0x02 Illegal Data Address
The master device sends a function code (01) “Read Coils”. It requests the
status of the output at address 1185 (04A1 hex). If the output address is non-
existent in the server device, the server will return the exception response
with the exception code shown (02). This specifies an illegal data address for
the slave.
4.1. MODBUS 43
The Table 4.8 shows the MODBUS exception codes list.
01 Illegal Function The function code received in the query is not an

allowable action for the slave. This may be because
the function code is not implemented in the unit
selected
02 Illegal Data Address The data address received in the query is not an
allowable address for the slave. More specifically,
the combination of reference number and transfer
length is invalid.
03 Illegal Data Value A value contained in the query data field is not
an allowable value for the slave. This indicates a
fault in the structure of the remainder of a complex
request, such as that the implied length is incorrect.
04 Slave Device Failure An unrecoverable error occurred while the slave
was attempting to perform the requested action.
05 Acknowledge Specialized use in conjunction with programming
commands. The slave has accepted the request and
is processing it, but a long duration of time will
be required to do so. This response is returned to
prevent a timeout error from occurring in the client
(or master). The client (or master) can next issue
a Poll Program Complete message to determine if
processing is completed.
06 Slave Device Busy Specialized use in conjunction with programming
commands. The slave is engaged in processing
a long-duration program command. The master
should retransmit the message later when the slave
is free.
08 Memory Parity Error Specialized use in conjunction with function codes
20 and 21 and reference type 6, to indicate that
the extended file area failed to pass a consistency
check. The slave attempted to read record file, but
detected a parity error in the memory. The master
can retry the request, but service may be required
on the slave device.
0A Gateway Path Unavailable Specialized use in conjunction with gateways, indi-
cates that the gateway was unable to allocate an
internal communication path from the input port
to the output port for processing the request. Usu-
ally means that the gateway is misconfigured or
overloaded.
0B Gateway Target Device Specialized use in conjunction with gateways, indi-
Failed to Respond cates that no response was obtained from the tar-
get device. Usually means that the device is not
present on the network.
Table 4.8: MODBUS Exception Codes

4.1.7 MODBUS Vulnerabilities

The encapsulation of MODBUS messages in TCP/IP payloads has brought
many benefits such as reliable and fast delivery of control packets, which
is very important in a process control environment with strong real-time
constraints; but it provides attackers with new ways to target industrial sys-
tems. TCP MODBUS does not provide any basic IT security principles such
as confidentiality, integrity, authenticity and non-repudiation. In particular,
MODBUS protocol:
• Do not apply any mechanism for checking the integrity of the command
packets sent by a Master to a Slave and vice-versa.
• Do not perform any authentication mechanism between Master and
Slaves, i.e. everyone could claim to be the “Master” and send commands
to the slaves.
• Do not incorporate any anti-repudiation mechanism.
• Do not provide any anti-replay mechanism.
Such a lack of IT security mechanisms can be exploited by malicious users
to perform different kind of attacks:
1. Unauthorized Command Execution: The lack of authentication
between Master and Slave can be used by attackers to forge packets
which can be directly write data to the slave or send commands in
order to damage the SCADA system. The attacker must be able to
access the network that hosts the SCADA servers or the field network
that hosts the slaves to execute this attack. Carcano, et al. [8] show
that the attack can be launched by creating malware that infects the
network and causes malicious messages to be sent automatically to the
slaves.
2. SCADA-DOS: On the basis of the same principle, the attacker pre-
tends to be the master and forge meaningless MODBUS packets in
order to consume the resources of the target PLC.
3. Man-in-the-Middle attacks: The lack of integrity checks enables an
attacker who has access to the production network to implement typical
Man-in-the-Middle (MITM) attacks, modifying the legal packets sent
by the master.
4. Replay-Attacks: The lack of anti-replying mechanisms allows attack-
ers to re-use captured legitimate MODBUS/DNP3 packets.
4.1. MODBUS 45
Additionally, it is possible to use the “Diagnostic” function code to affect

the SCADA system performance. For Example with the following function
codes:
• Force Listen Only Mode: it forces the addressed remote device to

enter into the “Listen Only Mode”. While the device is in this mode,
any MODBUS messages addressed to it or broadcast are monitored,
but no actions will be taken and no responses will be sent. An attacker
may send this command to isolate a slave device from the other devices
in the SCADA system.
• Clear Counters and Diagnostic Register: it clears all counter and

the diagnostic register. An attacker may use this command to clear the
diagnostic information into a slave device.
• Force Listen Only Mode and Restart Communications Option:

a sequence of these two function codes can force a slave device to be
restarted. An attacker may send these commands to restart a slave
device therefore the device would be off-line of a time period.
Firewalls and intrusion/anomaly detection systems should be deployed on the

SCADA systems in order to defend them against external attacks. However,
it is always possible to circumvent these security controls. The best way to
avoid the security threats is to solve them at their origin, i.e. “repair” the
security holes in the MODBUS protocol. Unfortunately such a solution is
difficult to implement because it requires significant changes to the control
system architecture and configuration.
4.2 DNP3
The Distributed Network Protocol Version 3 (DNP3), as well as MODBUS,
Fieldbus or IEC 60870, is one of the protocols that defines the communi-
cation between masters stations, remote terminal units (RTUs) and other
electronic devices in a SCADA network. The benefit of DNP3 (and of the
open protocols in general) is that it provides interoperability between equip-
ment from different manufacturers. DNP3 has the particularity of supporting
many network topologies:
• Master-Slave
• Multidrop from one master
• Hierarchical with intermediate data concentrators
• Multiple master
The Figure 4.8 shows the four DNP3 network topologies.
MASTER-SLAVE MULTIPLE MASTER
DNP3 DNP3 DNP3 DNP3

Master Slave Master Master
DNP3
Slave
MULTIDROP
DNP3 HIERARCHICAL
Master
DNP3
Master
DNP3 DNP3 DNP3

Slave Slave Slave Slave
DNP3
DNP3
Slave
Master
DNP3 DNP3 DNP3

Slave Slave Slave
Figure 4.8: DNP3 topologies
The “Master-Slave” topology is a simple point-to-point link between one

master station and one slave station. In the “Multiple Master ” topology a
4.2. DNP3 47
slave station can be connected with multiple masters. The “Multidrop” topol-
ogy has one master that communicates with multiple slaves. Every slave
receives every request from the master, but each slave only responds to mes-
sages addressed to it. In a “hierarchical ” configuration, a device acts as an
outstation in one segment and a master in another segment;; such a dual-
purpose device.
4.2.1 DNP3 Stack

The DNP3 protocol architecture provides 4 levels: Application, Pseudo-Transport,
Data Link and Physical. In Figure 4.9 a comparison between DNP3 and the
ISO-OSI 7 layer model.
DNP3 Stack ISO-OSI Stack
Application Application
Presentation
Session
Limited-Transport Transport
Pseudo-Transport
Limited-Network Network
Data Link Data Link
Physical Physical
Figure 4.9: DNP3 vs ISO-OSI stacks
The real DNP3 layers are three Application, Data Link and Physical, but
the application level adds some transport functions and the Data Link level
adds some network functions. These functions are often referred to “pseudo-
transport layer ”. Following is a brief description of each layer:
• Physical Layer: The physical layer is the physical media over which
the protocol is transmitted. The actual specification of this layer is
normally a separate standard such as ITU-T X.21 or V.24, EIA RS-
232 or others.
• Data Link Layer: The data link layer provides functions for reliable
transmission of data across the physical medium. Functions provided
by the data link layer include flow control and error detection.
• Pseudo-Transport Layer: This layer is included in DNP3 to allow

the transmission of larger blocks of data. It provides network and trans-
port services, although these are usually simply referred to as pseudo-
transport services: network functions are concerned with routing and
flow control of data packets over networks, while transport functions
provide network transparent end-to-end delivery of whole messages,
including disassembly and reassembly, and error correction.
• Application Layer: The application layer is the level where the data
is generated for sending, or requested to be sent. It is the layer that
interfaces to the lower levels to achieve the result of end-to-end trans-
mission of required information.
In what follows, the buildup of a DNP3 message will be examined. This will
provide an introduction to the overall structure of the DNP3 message. The
Figure 4.10 shows how to the transmitted message is built up in DNP3. Each
layer of the model takes the information passed from the higher layer, and
adds information connected with the services performed by that layer. The
additional information is usually added as a header.
User Application Data
Application
ASDU ASDU
APDU APDU
APCI APCI
Pseudo - TSDV
Transport
TPDU TPDU TPDU

TH TH TH
1 249 1 249 1 249
Data Link
LPDU LPDU LPDU

LH Data CRC LH Data CRC LH Data CRC
10 250 32 10 250 32 10 250 32
Physical
Figure 4.10: DNP3 packet buildup
The message buildup illustrated in the drawing is now briefly described

for each layer:
4.2. DNP3 49
• Application Layer: The user data is the data arising from the user
application. The application layer initially forms the data into man-
ageable sized blocks called Application Service Data Units (ASDUs).
The application layer then creates the Application Protocol Data Unit
(APDU) by combining a header with the ASDU data. The applica-
tion header is referred to as the Application Protocol Control Informa-
tion (APCI). The header is 2 bytes or 4 bytes in length, depending on
whether the message is a request or a response. Depending on the total
size of the data to be transmitted (the size of the ASDU), one or more
APDUs are created.
APDU (2048 bytes max) = APCI (2-4 bytes) + ASDU (2046-2048
bytes max)
• Pseudo-Transport Layer: The APDU from the application layer

may be referred to as the Transport Service Data Unit (TSDU) within
the pseudo-transport layer. The transport layer breaks the TSDU down
into smaller units termed Transport Protocol Data Units (TPDUs).
These are made up of a one byte header, followed by a maximum of
249 bytes of data.
TPDU (250 bytes max) = TH (1 byte) + Data (249 bytes max).
• Data Link Layer: This layer takes the TPDUs from the pseudo-
transport layer and adds a 10 byte header to each. As the data link
layer is also responsible for providing error detection and correction
functions, error checking codes are introduced here. A 16-bit cyclic re-
dundancy code (CRC) is used. Each TPDU is converted to a frame of
up to 292 bytes in length. In this way the data link layer forms the
Link Protocol Data Units (LPDUs).
LPDU (292 bytes) = LH (10 bytes) + Data (250 bytes max) + CRC
(32 bytes).
• Physical Layer: The physical layer converts each frame into a bit
stream over the physical media.
In the following sections we will describe in details the four layers, apart the
physical layer because it belongs to a a separate standard.
4.2.2 DNP3 Data Link Layer

The Data Link Layer provides the following services to the overall protocol:
• Encapsulation and decapsulation of transport segments.

• Error detection. Each transmitted frame contains a Cyclic Redundancy

Check word (CRC).
• Source and destination addressing.
• Optional confirmation of each data link frame.
• Optional detection of lost or repeated data link frame requests.
The Data Link Layer uses transactions for conveying data to the Data Link
Layer in another DNP3 device and to perform link management functions. As
we explained for MODBUS, a transaction consists of one or two messages: a
request message from the device initiating the transaction, called the primary
station and, optionally, a response message from the secondary station back
to the primary station (note that data link layer requests and responses
are distinct from the requests and responses in the Application Layer). The
Data Link Layer in each DNP3 device acts as both a primary and as a
secondary station: The master station is the primary and the slave station is
the secondary in a request and vice versa in a response.
DNP3 Data Link Frame Format

A data link frame has a fixed length header block (block 0) followed by
optional data blocks. Each block ends with a 16-bit CRC.
Header Block (Block 0 ) 10 bytes

Start (2 bytes) Len Ctrl Destination Source CRC
0x05 0x64 (1 byte) (1 byte) (2 byte) (2 byte) (2 byte)
Data Block (Block 1)

CRC
User Data (16 bytes)
(2 byte)
Data Block (Block 2)

CRC
User Data (16 bytes)
(2 byte)
...
Data Block (Block n)
CRC
User Data (1 to 16 bytes)
(2 byte)
Figure 4.11: DNP3 Data Link Frame Format
The header fields consist of six fields:

4.2. DNP3 51
• Start (2 bytes): the first two bytes are always 0x05 and 0x64.
• Length (1 byte): it specifies the count of non-CRC octets which follow

in the header and data blocks. The minimum value for this field is 5,
indicating only the header is present, and the maximum value is 255.
• Control (1 bytes): it contains information about the frame’s direc-

tion, transaction initiator, error and flow control and function. it will
be explained in the follow.
• Destination Address (2 bytes): the address of the station to which

the frame is directed.
• Source Address (2 bytes): the address of the station from where

the frame originates.
• CRC (2 bytes) cyclic redundancy check code.
User data refers to the link user’s data; in other words, the data belonging
to the higher layers that use the Data Link Layer. We present now in details
the most important field, which is the control field.
DNP3 Data Link Control Field
FCB FCV
DIR PRM FUNCTION CODE
RES DFC
7 6 5 4 3 2 1 0
DIR (Direction bit): indicates the physical transmission origin of the data
link frame. DIR = 1 indicates a frame from a Master; DIR = 0 indicates a
frame from an Outstation.
PRM (Primary Message Bit): indicates the direction of the data link
frame with respect to the initiating station. PRM = 1 indicates frame from
primary (initiating station); PRM = 0 indicates frame from secondary (re-
sponding station). This is used directly in interpreting the function code.
There are six valid function codes for primary frames, and five valid function
codes for secondary frames.
FCB (Frame Count Bit): is used to detect losses and duplication in
primary-to-secondary frames. If the received FCB bit in a message does not
match the expected FCB state, the secondary recognizes the message as be-
ing a repeat of a previous message and acts accordingly.
FCV (Frame Count Valid bit): appears in every primary-to-secondary
frame and specifies whether the secondary is to examine the FCB bit.
FCV = 1 indicates the state of the FCB bit is valid and it must be checked.
FCV = 0 indicates the state of the FCB bit is ignored.
In the secondary-to-primary frame the 5-6 bits have a different meaning:

RES (Reserved): reserved for future uses.
DFC (Data Flow Control bit): Set to 1 by secondary station if further
send of user data will cause buffer overflow.
DNP3 Data Link Function Codes

There are different function codes depending on the message direction. They
are shown in Tables 4.9.
Primary to Secondary
Function Codes
CODE DESCRIPTION Secondary to Primary
0 Reset Link Function Codes
2 Test Link CODE DESCRIPTION
3 User Data - Confirm 0 Confirm - ACK
Expected 1 Confirm - NACK
4 User Data - No Con- 11 Respond - Link Status
firm
9 Request Link Status
Table 4.9: DNP3 Data Link Function Codes

4.2. DNP3 53
Primary-To-Secondary Function Codes
00 - Reset Link
A link reset is required to enable communication between a primary and

secondary station. It must be used after a start, restart, or any link failure.
Initiates the primary and secondary stations for further SEND-CONFIRM
transactions. It is used to synchronize the FCB so FCB=1 is expected by the
secondary for the transaction following the reset. The Figure 4.12 shows the
transaction.
Primary
Station
Secondary
Ctrl byte Station
DIR PRM FCB FCV FUNCTION CODE
1 1 X 0 0 (reset)
Ctrl byte
DIR PRM RES DFC FUNCTION CODE
Next FCB Expected FCB
0 0 X 0 0 (confirm-ack)
1 1
Figure 4.12: DNP3 Reset Link Function Code
P → S: The DIR = 1 indicates a frame from a Master. The PRM = 1

indicates frame from primary (initiating station). The FCB is ignored because
FCV = 0.
P ← S: The DIR = 0 indicates a frame from an Outstation. The PRM = 0
indicates frame from secondary (responding station). The DFC = 0 indicates
that the secondary is working correctly. The secondary station will expect
FCB=1 for the transaction following the reset.
03 - User Data - Confirm Expected
This procedure is used for sending frames with user data that require con-
firmation of receipt. The link must be initially reset before the user data
function may be used. The Figure 4.13 shows the transaction.
Primary Secondary
Station Station
Next FCB Ctrl byte

1 DIR PRM FCB FCV FUNCTION CODE Expected FCB
1 1 1 1 3 (user data-ack) 1
Ctrl byte
Next FCB 0 0 X 0 0 (confirm-ack)
0
Ctrl byte Expected FCB
DIR PRM FCB FCV FUNCTION CODE 0
1 1 0 1 3 (user data-ack)
Ctrl byte
0 0 X 0 0 (confirm-ack)
Figure 4.13: DNP3 User Data - Confirm Expected Function Code
P → S: The DIR = 1 indicates a frame from a Master. The PRM = 1

indicates frame from primary (initiating station). The frame count bits are
FCB =1 and the FCV = 1. When the Outstation receives this message, it
checks the value of the FCB bit and compares it against the FCB state it
expects from that primary station. If the FCBs match, the secondary should
send an ACK confirm response frame, pass the user data to the higher layers
and toggle the expected FCB state from that primary. If the FCBs do not
match, the secondary should send an ACK confirm response frame, but it
does not pass the data to the higher layers, and it does not toggle the expected
FCB state from that primary.
P ← S: The DIR = 0 indicates a frame from an Outstation. The PRM = 0
indicates frame from secondary (responding station). The DFC = 0 indicates
that the secondary is working correctly.
04 - User Data - No Confirm

This procedure is used for sending user data without requiring confirmation
from the secondary station. The advantage is that data can be transmitted
at a higher rate, thus providing a more efficient use of bandwidth. However,
the disadvantage is that errors in transmission will result in lost frames. This
is the preferred function code for sending broadcast application data.
4.2. DNP3 55
02 - Test Link
The test procedure is used by the primary station to test the link. If the
FCBs do not match, the secondary station should re-send the last secondary
confirm frame. Upon reception of this function code by a secondary station,
it checks the value of the FCB bit in the primary message and compares
it against the FCB state it expects from that primary station. If the FCBs
match, the secondary should send an ACK confirm response frame and toggle
the expected FCB state from that primary. If the FCBs do not match, then
the secondary station must send a repeat of the most recent ACK or NACK
response frame that it transmitted. If the secondary receives a test link states
request without there having been a previous link reset states request, it must
either not respond or respond with a NACK with DFC = 0.
09 - Request Link Status

The request link status function is utilized to obtain the status of the sec-
ondary Data Link Layer. The primary may send this function at any time.
This function can be used for as a keep-alive messages for knowing that the
other end is still connected or on-line.
Secondary-To-Primary Function Codes

00 - ACK
The secondary station returns an ACK response as a positive confirmation
that the intended request was accepted from the primary.
01 - NACK
The secondary station returns a NACK response as a negative confirmation
that the request is not accepted from the primary for one of these reasons:
• The secondary’s link state is not reset when either a primary-to-secondary

function TEST LINK or CONFIRMED USER DATA frame is received
with the FCV bit set.
• The secondary’s link is busy.
• The secondary’s Data Link Layer receive buffers are full.
• The FCV bit in the request does not match that expected for the
function code in the request.
A NACK response is only applicable to request function codes RESET LINK,

TEST LINK, and CONFIRMED USER DATA.
11 - Respond - Link Status

The link status response must be returned from the secondary when it re-
ceives a request link status message from the primary. It is as an indication
that the secondary did receive the request.
4.2.3 DNP3 Pseudo-Transport Layer

The transport layer takes the user data and breaks it down into one or more
Transport Protocol Data Units (TPDUs) and sends each to the data link
layer for sending. Recalling that the data link frames can be a maximum of
250 bytes of user data, this defines the maximum size of the LPDU (Link
Protocol Data Unit), including any transport layer overheads. The transport
functions are accomplished with a single header byte, leaving 249 bytes for
carrying data. The Figure 4.14 shows this framing.
Data block from application layer.

1 - 2048 Bytes
TPDU
TH TH
1 249 1 249
Figure 4.14: DNP3 Transport layer framing.
The transport functions are accomplished with a single header byte, leav-
ing 249 bytes for carrying data. The single byte transport header contains
two bits that identify the start and end of a sequence of frames (TPDUs),
plus a six-bit sequence counter. It is shown in Figure 4.15
0 1 2 7
FIN FIR SEQ (6 bits)
Figure 4.15: DNP3 Pseudo-Transport Header
If the FIR bit is set, the frame is the first of multiple frames. If the FIN
bit is set, the frame is the final one. Sequence number may be any value 0 -
4.2. DNP3 57
63 for first frame, and must increment for each frame in the sequence.
4.2.4 DNP3 Application Layer

The application layer is the highest level of the protocol, and communicates
directly with the user application program. The messages exchanged at this
layer may contain commands, or requests for provision of data, or they may
perform other functions such as time synchronization. Tasks of application
layer are:
• Form request messages (form master station to outstation).
• Form response messages (form outstation to master station).
• Form unsolicited response messages (form outstation to master sta-

tion).
• Accepts data from user application to send to master or to outstation.
• Breaks user data down into multiple ASDUs (Application Service Data
Units).
• Form APDU (Application Protocol Data Units) = APCI (Applica-

tion Protocol Control Information) + ASDU (Application Service Data
Units)
Application Message Sequences

At the application level, there are 2 basic message types:
• request: message from master station to outstation.
• response: message from outstation to master station (to reply at pre-

visions request message by the master station).
A third possible message type is:
• unsolicited response: message from outstation to master station (to

report an event or process change to the master station).
The request-response message sequences are shown in the following drawing

(Figure 4.16):
Master Outstation
1. Send request 2. Receive request
Confirm (optional) 3. Send Confirm
4. Perform the action
6. Receive 5. Send response

response
7. Send Confirm Confirm (optional)
Figure 4.16: DNP3 request-response message sequences
In the above sequence:
1. the master station sends the “request message” to the outstation.
2. the outstation receives the “request message”.
3. If the master station has set a confirm bit, the outstation will send a
confirm message.
4. the outstation processes the request.

4.2. DNP3 59
5. the outstation sends the “response message” to the master station.
6. If the outstation has set a confirm bit, the master station will send a
confirm message.
The unsolicited response message sequences are shown in Figure 4.17:
Master Outstation
1. Process change
3. Receive or event
unsolicited 2. Send unsolicited
response response
7. Send Confirm Confirm (optional)
Figure 4.17: DNP3 unsolicited response message sequences
In the above sequence:
1. An event or defined process change is detected by the outstation.
2. The outstation generates and sends an “unsolicited message” to the

master station.
3. If the outstation has set a confirm bit, the master station will send a
confirm message.
Application Messages Format

Application messages are of two types, request and response. Every message
is composed by one or more APDU (Application Protocol Data Units). Each
APDU is made up of:
• Header: called APCI (Application Protocol Control Information).
• Data: called ASDU (Application Service Data Units).
The request APDU (Application Protocol Data Units) is shown in Figure

4.18:
APDU (Application Protocol Data Unit)

0 2 2048
APCI ASDU
APCI (Application Protocol Control Information) 2 bytes

AC FC
ASDU (Application Service Data Unit) 2046 bytes max
0 1 2
AC (Application Control) 1 byte
FC (Function Code) 1 byte
Figure 4.18: Request APDU (Application Protocol Data Units) format.
The response APDU (Application Protocol Data Units) is shown in Fig-

ure 4.19:

0 4 2048
APCI ASDU

AC FC IIN ASDU (Application Service Data Unit) 2044 bytes max
0 1 2 4
IIN (Internal Indication) 2 bytes
Figure 4.19: Response APDU (Application Protocol Data Units) format.
The request and response headers differ by one field. The response header
includes an additional two-byte field called internal indications (IIN).
Application Control Field (AC)
The application control field is the first byte of the APCI (Application Pro-
tocol Control Information). The structure of the application control field is
shown in the following:
0 4 5 6 7
SEQ CON FIR FIN
4.2. DNP3 61
SEQ Fragment Sequence Number.

0-15 Master station requests or outstation responses (solicited).
16-31 Outstation unsolicited responses.
CON Confirmation Required.
FIR First fragment of multi-fragment message.
FIN Finale fragment of multi-fragment message.
Flow control is implemented using the following rules:
1. If CON = 1 a confirmation must be sent.
2. If a request has the sequence number N, the response has the same
sequence number(N).
3. If a request has the sequence number N, the confirmation message has

the same sequence number(N).
4. If a response has the sequence number N, the confirmation message has

the same sequence number(N).
5. The first fragment of a response has the same sequence number as the
request, or as the last fragment of a multi-fragment request.
6. For a single fragment request re-try, the re-try has the same sequence
number as the original request.
7. For a multi-fragment request re-try, the re-try commences with the

sequence number of the last fragment of the previous request.
8. If two messages are received with the same sequence number, it usually
means that the response message was not received by the other station.
Re-transmit response.
9. If two confirmation messages are received with same sequence number,

ignore the second.
In DNP3 there is the possibility of an outstation sends an unsolicited response

at the same time as a master station request. Special features are provided to
handle the cases of these transactions. The first feature is the use of different
sequence numbers:
• 0-15 for request and response.
• 16-31 for unsolicited response.

A second feature is provided to ensure that data is not lost or duplicated

during an inappropriate sequence of actions. This feature is termed process
mode, for which two modes are defined:
• Immediate mode: is used for all transactions except for a master
station read request to an outstation, when an unsolicited response
transaction is in progress.
• Process after confirm mode: is used when an outstation is waiting

for confirmation for an unsolicited response, it will delay processing a
read request until the confirmation is received.
The rules for unsolicited message transactions are:
1. Master station always processes an unsolicited response immediately,
even if waiting for a response to a previous message.
2. If a confirmation for the unsolicited response is requested it is issued

immediately by master.
3. Outstation will process most requests immediately, even if waiting for a

response to a previous unsolicited response. This is “immediate mode“
4. Outstation will not process a master station Read request if it is waiting

for confirmation of a previous unsolicited response. This is ”process
after confirm mode”
The next field is the Functions Code Field (FC), but it involves a lot of
specific DNP3 terms. For this reason we introduce now a DNP vocabulary
overview.
DNP3 Vocabulary Introduction

Points: a point is a uniquely identifiable physical or logical entity. Example:
A single analog input.
Point Type: a category of points that having related characteristics, similar

functionality and relationship to physical hardware or logical space. Exam-
ple: the analog input point type. Each point type in DNP3 is an independent
array of points. Each point is uniquely identified by its index within the ar-
ray. Figure below illustrates five basic point types within a DNP3 outstation.
Indexes: DNP3 uses index numbers to identify points having the same point
type. Index numbers are equivalent to array element numbers. DNP3 indexes
4.2. DNP3 63
are zero-based. Example: the first 10 analog input points are referenced using
indexes 0 through 9.
Groups: classifies the type or types of data within a message. Each group
number shares a common point type and method of data generation or cre-
ation. Example: for an analog input point type, group numbers are used to
report data as follows:
Group 30 Analog Input current value of the point

Analog Group 31 Frozen Analog Input frozen value of the point
Inputs Group 32 Analog Change Event change of current value event
Group 33 Frozen Analog Event change of frozen value event
Variations: offers a choice of encoding formats for many of the data types.
Every group number has an independent set of variations. Here is a list of
the variations for group 30:
Var 1 32-bit integer value with flag

Var 2 16-bit integer value with flag
Var 3 32-bit integer value
Group 30
Var 4 16-bit integer value
Var 5 32-bit floating point value with flag
Var 6 64-bit floating point value with flag
The flag refers to supplementary data that indicates conditions such as the
source being on-line, the source device having restarted or the value being
outside of the measurement range.
Object: is an encoded representation of data from a point, or other structure,

that is formatted according to its group and variation number for transport
in a message. An example of an object composition is:
Point Type 30-39 Analog Inputs

Group 30 Analog Inputs Value
Variation 3 32-bit integer value
Index 5
A message may contain multiple objects, each representing the value of a

point at a given instant in time or a command to be issued to an output
point. The term instance is sometimes used to distinguish one object from
another. For example, a message with 6 objects holds the current value of 6
analog input points, expressed as a 32-bit integers. Here, the group number is
30, the variation is 3 and there are 6 instances of 32-bit analog input objects.
Static: refers to the point’s current value, which is the most recently mea-
sured, computed or obtained value. Thus, static binary input data refers to
the present on or off condition of a bi-state point. Static analog input data
contains the most recently obtained value of an analog input point. DNP3
allows the possibility to request some or all of the static data from an out-
station device.
Events: are associated with something of significance happening. Examples

are state changes, a measurement whose value crosses some threshold, an
analog input changing by more than its dead-band, a snapshot of data taken
at a particular time, a transient phenomena and some newly available infor-
mation. In many cases, the logic associated with points in an outstation can
generate events, but other entities within an outstation can also cause cre-
ation of events. An outstation stores information about events in proprietary,
vendor-specific structures. Examples of the structured information stored for
each event are:
Type of event binary input, analog input, etc
Value on, off, 387, etc
Point index 1,2,..N
Time when event occurred 18:45:16
Class assignment
A representative object is in transmit buffer true or false
It is important to know the difference between events and the DNP3 objects
that report events. Even though some DNP3 objects are referred to as “event
objects”, they are only a representation of the event, and not the actual
structured information stored in the outstation. The stored event information
may only be deleted from an outstation after an event description has been
transmitted to the master (in a DNP3 object), and the outstation has received
confirmation back from the master acknowledging that it received the event.
Three fundamental principles in DNP3 are:
• The decision as to what constitutes an event is usually a local issue.
• It is not permitted to lose or discard the stored structured event infor-
mation until a representation of the event has been transmitted to and
acknowledged by the master.
• Duplicate reporting of an event should be avoided.
The determination that a point has undergone a significant change may only
be based upon information from that point’s current or past value. Decisions
4.2. DNP3 65
based on information about any other point, directly or indirectly, are ex-
plicitly forbidden. There are DNP3 objects defined for reporting events with
and without time stamps.
Classes: DNP3 uses the concept of classes to organize events and current
values into several categories. Class 0 data refers to static data, or the current
values. When a master requests class 0 data from an outstation, the most
recently measured, computed or obtained values of the different point types
are to be reported in the response. The present values of binary and analog
input points are examples of data that would appear in the response. There
are three event classes, 1, 2 and 3. DNP3 does not assign significance to
these classes. One strategy is to assign the highest priority events to class 1
and lowest priority events to class 3, but other strategies may work better in
specific systems. Equipment manufacturers and persons configuring devices
may decide which strategy is most appropriate for their application. Masters
may request events from one or more of these classes.
Event Buffer: An event buffer is a structure in the outstation used to

temporarily store event information. When an event is generated, software
places information about the event into the buffer where it remains until
relevant facts about the event have been transmitted to the master and their
delivery confirmed. Upon receipt of the confirmation, event information is
permanently removed from the buffer. DNP3 does not specify the numbers
of buffers, the buffers structure, data organization and contents. These are
considered vendor-specific design issues.
Functions Code Field (FC)

The function code byte identifies the purpose of the message. Request mes-
sages from masters use function codes in the range of 1 to 128, and response
messages from outstations use function codes with values ranging from 129
to 255. The Image 4.20 gives a brief description of the function code field.

0 2/4 2048
APCI ASDU
Request Response
AC FC AC FC IIN FC (Function Code) 1 byte
0 1 2 0 1 2 4
Request FC Response FC
CODE GENERAL FUNCTION CODE GENERAL TYPE FUNCTION

TYPE 0 Response Function Confirm
0 Transfer Function Confirm 129 Response Function Read
1 Transfer Function Read 130 Response Function Unsolicited
2 Transfer Function Write
3-6 Control Function
7-12 Freeze Function
13-18 Application Con-
trol Function
19-22 Configuration
Function
23 Time Synchro-
nization
24-128 Reserved
Figure 4.20: Function Code Field
The specific actions required for each function code are included in the
following tables. Many of the functions need to identify specific data on which
they operate. They do this with data object references that are included in
the data within the ASDU, which follows the APCI header.
Transfer Functions
0 Confirm Master sends this to an outstation to confirm the receipt of
an Application Layer fragment. (it’s the same from slave
to master). No response required.
1 Read Outstation should return the data specified by the objects
in the request.
2 Write Outstation should store the data specified by the objects
in the request and responds with status of the operation.
3 Select Outstation should select (or arm) the output points spec-
ified by the objects in the request in preparation for a
subsequent operate command. The outstation should not
activate the outputs until a request with a matching Op-
erate function code is received. The outstation responds
with the status of the selected control points.
4.2. DNP3 67
Control Functions
4 Operate Outstation should activate the output actions on the
points previously selected by the Select function. The out-
station responds with the status of the control points fol-
lowing action.
5 Direct Operate Outstation should immediately actuate the output points
specified by the objects in the request. Outstation re-
sponds with the status of the control points following ac-
tion.
6 Direct Operate no Direct Operate without response message.
ack
The control functions are used to operate or change control points in an

outstation. These may be operated in two way:
• Directly with or without acknowledgment.
• Select Before Operate(SBO)
The select before operate sequence is a security feature that is well known
in the electrical supply industry. It provides an additional level of security to
ensure against mis-operation arising from a corrupted message, or a human
error such as selecting the wrong device from a group of similar devices shown
on an HMI screen. Select before operate sequence requires the following to
occur:
1. Selection of the control points is made.
2. The outstation responds with the identity and status of the selected
points.
3. The outstation starts a select-operate timer.
4. The HMI displays the selected points differently, showing they have
been selected.
5. The operate function is sent for the selected points.
6. The outstation will reject the operate message if the point identities do
not match those of the previously selected points.
7. The outstation will de-select the points if the select-operate timer ex-
pires before the operate function is received.
Freeze Functions
7 Immediate Freeze Outstation should copy the point data values, specified
by the objects in the request, to a separate freeze buffer
(or holding register). Outstation responds with status of
operation. Note that the data themselves are not returned.
8 Immediate Freeze - Immediate Freeze without response message.
No Ack
9 Freeze and Clear Outstation should copy specified objects to a freeze buffer,
then clear the objects. Outstation responds with status of
operation. Note that the data themselves are not returned.
10 Freeze and Clear - Freeze and Clear without response message.
No Ack
11 Freeze with Time Outstation should copy the point data values, specified
by the objects in the request, to a separate freeze buffer
at the time and/or time intervals specified in a special
time data information object. Outstation responds with
status of operation. Note that the data themselves are
not returned.
12 Freeze with Time - Freeze with Time without response message.
No Ack
Freeze functions are typically used for the following:

• Record system-wide state data at a common time (eg midnight).
• Record status or value of specific point at regular intervals (eg for

trending a flow rate).
Application Control Functions

13 Cold Restart Outstation should perform a complete reset of all hard-
ware and software in the device. Outstation responds with
time until its availability following restart.
14 Warm Restart Outstation should reset only portions of the device. Out-
station responds with time until its availability following
restart.
15 Initialize Data to Initialize specified data to initial or default settings. Out-
Defaults station responds with status of operation. (Obsolete - do
not use for new designs).
16 Initialize Applica- Outstation should place the applications, specified by the
tion objects in the request, into the ready to run state. Out-
station responds with status of operation.
17 Start Application Outstation should start running the applications specified
by the objects in the request. Outstation responds with
status of operation.
18 Stop Application Outstation should stop running the applications specified
by the objects in the request. Outstation responds with
status of operation.
4.2. DNP3 69
The application control functions are coded in order of decreasing effect.

The cold restart is a complete restart of the outstation, as if it had been de-
powered and then re-powered up. The warm restart may be used to reset the
DNP3 application, but not necessarily to reset other application programs.
Typically the warm restart is used to initialize its configuration and clear
events stored in its buffers. Once either a cold or warm restart has been
initiated, the master station should not attempt to communicate with the
outstation until the restart time interval returned in the outstation’s response
has elapsed. The initialize data to defaults could for example setup standard
setpoints, and clear counters. The specific data objects to be initialized are
identified in the request, but not the default values themselves. These are
stored locally in the outstation, as fixed read-only data, or as parameters in
non-volatile memory, for example.
Configuration Functions
19 Save Configuration Outstation should store into non-volatile memory the
contents of a configuration file located in volatile mem-
ory. Outstation responds with time outstation availability.
(Deprecated do not use for new designs).
20 Enable Unsolicited Enables outstation to initiate unsolicited responses from
Messages points specified by the objects in the request. Outstation
responds with status of operation.
21 Disable Unsolicited Disables outstation to initiate unsolicited responses from
Messages points specified by the objects in the request. Outstation
responds with status of operation.
22 Assign Class Outstation should assign the events generated by the
points, specified by the objects in the request, to one of
the classes. Outstation responds with status of operation.
The configuration referred to by these functions is the state of the param-

eters and settings that collectively determine the behavior of the outstation.
It does not refer to a complete program or “configuration” download. The
save configuration function allows storing in a specified non-volatile memory
location the settings that define the system’s configuration. The enable and
disable of unsolicited messages allows for a live change to this configuration
aspect. The assign class function allows for live assignment of data objects to
classes. The effect of classes is to provide a broad means of referencing data,
for example by allowing a read of all data in a particular class.
Time Synchronization Functions

23 Delay Measurement Outstation should report the time it takes to process and
initiate the transmission of its response. This allows the
master to compute the propagation delay in the communi-
cation channel. Used for non-LAN time synchronization.
24 Record Current Outstation should save the time when the last octet of
Time this message is received. Used for LAN time synchroniza-
tion. Outstation responds with status (internal indications
bits).
The delay measurement function is used immediately prior to performing

a time setting by writing to the outstation clock. It is used over asynchronous
serial links, for which the message transmission time is significant in com-
parison to the one-millisecond clock resolution. The outstation measures the
time in milliseconds that it takes to turnaround the message, that is, the time
from message receipt to sending the response to the master. The master sta-
tion subtracts this time from the turnaround time it sees, to determine the
time the messages spent in the communication system. It then divides that
time by two to obtain an approximation of the one-way message delay from
master station to outstation. The record current time function is used when
performing a time setting over a LAN. In this case the transmission occurs
essentially instantaneously, so no turnaround time measurement is needed.
Both the master station and the outstation record the current values of their
own clocks at the time this message is sent. Subsequently, the master sends
its recorded time to the outstation, which calculates the time error from the
difference between the recorded values.
File Functions
25 Open File Outstation should open a file. The required file is locked
to prevent use by other processes, and opened.
26 Close File Outstation should close a file and released for use by other
processes.
27 Delete File Outstation should delete a file. If it is open the command
is not executed.
28 Get File Information Outstation should provide file information: Type, Size,
Time of Creation, Permissions.
29 Authenticate File Outstation should return a file authentication key to allow
file change operations.
30 Abort File Outstation should abort a file transfer operation in
progress, and close the associated file without saving.
The file function codes provide for file operations with configuration and
other files in outstation devices. Some devices may implement security fea-
tures to control file access. Where required, these make use of an authentica-
tion step, where the master station submits a user name and password with
4.2. DNP3 71
the authenticate function. The outstation responds with a one-time use key
which is then used by the master in conjunction with file change operations.
The codes from 31 to 128 are reserved.
Response Functions
129 Response Outstation should use this function to respond to a re-
quest sent by the master.
130 Unsolicited Message Master should interpret this fragment as an unsolicited
response from outstation that was not prompted by an
explicit request.
The response function codes apply for all messages from outstations, i.e.
stations that are not designated as master stations. The only response these
messages require (of the master station) is an optional confirmation on receipt
by the master station.
The codes from 131 to 255 are reserved.
Internal indications (IIN)
The internal indications (IIN) field is a two-byte field that follows the function
code in all responses. It is by using the internal indications that the outstation
status is reported to the master following a request.

0 4 2048
APCI ASDU

AC FC IIN ASDU (Application Service Data Unit) 2044 bytes max
0 1 2 4
Each bit in the field has a specific meaning, in accordance with the table. An
outstation would have defined flags within its dynamic memory to correspond
to the IIN field bits. These flags would then be copied in each response
message.
First Byte
0 All station message received Set When an address in the range FFF0 - FFFF
is received cleared after next response. Used to
confirm that a broadcast message is received by
this station.
1 Class 1 Data Available Indicates that data of specified class
2 Class 2 Data Available is available. Master should request
3 Class 3 Data Available this data.
4 Time Synchronization Re- After a restart this will be set. It is cleared during
quired time synchronization or by a direct write to the
outstation II Object.
5 Points in local Set when one or more outstation points are in
local mode and therefore cannot be controlled
remotely.
6 Device Trouble Used when an abnormal condition is present and
this cannot be described by the other two bits.
7 Device Restart Set when the user application restarts. Will be
cleared when the master writes a 0 directly to
this bit of the outstation II Object.
The second byte fields meaning are:

Second Byte
0 Function Code Not Imple- This function code is not available at this out-
mented station.
1 Request Objects Unknown There are no objects as specified or in the spec-
ified class.
2 Parameters Invalid Parameters in the qualifier, range or data fields
are not valid or are out of range.
3 Buffer Overflow Event or other application buffers have over-
flowed.
4 Operation Already in This operation is already executing.
Progress
5 Corrupt Configuration This is a specific problem indication showing
that the master will have to download a new con-
figuration.
6 Reserved (0) Always to return 0
7 Reserved (0) Always to return 0
The Object Header

The ASDU is made up of one or more object header and data object fields,
up to a maxi-mum frame size of 2048 bytes including the frame header (the
APCI). The object header is between 3 and 11 bytes in length, and is made up
of the object, qualifier and range fields. The object field is further subdivided
into two bytes, which are the object group and object variation respectively.
The range is between 0 and 8 bytes. The Figure 4.21 shows the ASDU fields.
4.2. DNP3 73

0 2 2048
APCI ASDU
Object Header Data Object Object Header Data Object
0 2 3 10
Object (2 bytes) Qualifier (1 byte) Range (0-8 bytes)
Object Group Object Variation
Figure 4.21: ASDU (Application Services Data Unit) format.
The object field is made up of the fields in the figure below:
Object Field
0 or Object Variation Request
Object Group
Object Variation Response
The object field is made up of the object group and the object variation
bytes:
• Object Group: specifies the general type of data, such as analog in-
puts.
• Object Variation: specifies the data format of DNP3 objects. For ex-
ample, variations exist for reporting the current value of analog inputs
as 16-bit integers, 32-bit integers, short floating point quantities and
long floating point quantities. When a master station specifies object
variation zero in a request message, this is defined to mean all varia-
tions of that particular object group. This allows the master station to
obtain all object variations without identifying each one.
A list of the object groups is shown in the Table 4.10.

Object Groups
0-9 Binary Input Objects
10-19 Binary Output Objects
20-29 Counter Objects
30-39 Analog Input Objects
40-49 Analog Output Objects
50-59 Time Objects
60-69 Class Objects
70-79 File Objects
80-89 Device Objects
90-99 Application Objects
100+ Alternate Numeric Objects
Table 4.10: DNP3 object groups.
Qualifier and Range fields

The qualifier and range fields follow the object field in the object header.
These fields are used to identify the specific data objects of each object
group and variation that are being referred to.
0 2 3 10
Object (2 bytes) Qualifier (1 byte) Range (0-8 bytes)
Qualifier Code (4-bit) Index Size (3-bit) R

0 3 6 7
Figure 4.22: Qualifier field format
The qualifier field is made up of two sub-fields. These are the qualifier
code (or Q-code) and the index size (or I-size); the R field (Reserved) is
reserved for future use and must always be 0. The primary meaning of the
qualifier field is provided by the qualifier code value. The index size sub-
field provides additional information required for some qualifier code values.
These sub-fields, together with the following range field act to fully identify
the data object that follows each object header.
The qualifier code allows five different referencing modes, or ways of refer-
encing or identifying the data objects contained within messages:
1. Range - Index Mode.
2. Range - Absolute Mode.

4.2. DNP3 75
3. All Object Mode.
4. Non - Ranged Mode.
5. Object Identifier Mode.
The Table 4.11 shows the interpretation and use of qualifier code.
Interpretation of Qualifier Code

Q- Range Referencing Mode Notes
Code Size
0 8-bit The range field contains start and stop
1 16-bit Range - Index Mode indexes. points are I1 to I2. I-size = 0,
2 32-bit or 4-6 for individual obj size prefixes.
3 8-bit The Range field contains start and stop
Range - Absolute
absolute memory addresses in outstation.
Mode
Data are Bytes B1 to B2. I-size = 0, or
4-6 for individual object size prefixes (re-
sponse messages only).
4 16-bit
5 32-bit
6 - All Object Mode Specifies all objects in the referenced
group/variation. Only used for requests.
There is no range field with this mode. I-
size must = 0. Specifies a list of unrelated
points.
7 8-bit Specifies a list of unrelated points. The
Non-Ranged Mode Range field contains the number of points
referenced. I-size = 0: No indexes, points
only; I-size = 1: Indexes are 8 Bit; I-size =
2: Indexes are 16 Bit; I-size = 3: Indexes
are 32 Bit.
8 16-bit
9 32-bit
11 - Object Identifier Mode The Range field contains the number of
Object Identifiers following. Each Object
Identifier is preceded by a “Size” field.
The size of the Size and Range fields de-
pends on I-size: I-size = 1: Fields are 8
Bit; I-size = 2: Fields are 16 Bit; I-size =
3: Fields are 32 Bit.
Table 4.11: Interpretation of qualifier code.
For most of the referencing modes, additional information is provided by

the I-size sub-field. The specific meaning of the sub-field is dependent on
the referencing mode. In each case where the I-size sub-field is used (i.e. is
non-zero), it gives the size of additional fields that are given for each data
object. Depending on the referencing mode, these extra fields contain either
an identifier, an index, or a number giving the object size in bytes. The I-
size codes are shown in Table 4.12. The use of these is demonstrated in the
following sub-sections for each referencing mode.
Index-Size Code
I-Size Size Meaning in Request Meaning in Request or Response
Code with Q-code = 11 containing Data Objects
0 no index No indexing. Objects are packed di-
rectly.
1 8-bit
Objects are prefixed with an index
2 16-bit Identifier Field Size
of this length.
3 32-bit
4 8-bit
Objects are prefixed with an object
5 16-bit
size field of this length.
6 32-bit
Table 4.12: Interpretation of index-size code.
Range-Index Mode
The range-index mode is indicated by Q-codes 0, 1 and 2. In this mode the

range field contains two numbers. These are the start and stop index values
for the data objects.
Example:
Group Variation Q-Code I-Code Range

G V 0 0 I0-I2
In this example the request is:
Group: G.
Variation: V
Q-Code: 0 defining the range-index mode with 8-bit indexes. These can ref-
erence a maximum of 256 data objects.
I-Code: 0 defining no indexing. Objects are packed directly.
Range: I0-I2 this field contains start and stop indexes.
The response is the following:
Group Variation Q-Code I-Code Range DO-0 DO-1 DO-2
G V 0 0 I0-I2 I0 I1 I2
In the response message, the data objects follow the message. The I-Code
field is set to zero, meaning the objects are packed in sequence without size
fields. This is the response with the I-Code field set(1,2,3):
4.2. DNP3 77

G V 0 4 I0-I2
Size-0 DO-0 Size-1 DO-1 Size-2 DO-2
S-I0 I0 S-I1 I1 S-I2 I2
In the response message only, it is possible to prefix each data object returned
with an object size identifier. When this is desired, the I-Code field is used
to specify the size of the object size fields. This would only be required if the
object sizes were variable within an object variation group.
Range-Absolute Mode
The range-absolute mode is indicated by Q-codes 3, 4 and 5. This mode
is similar to the range-index mode in that the range field contains start
and stop values. However, these values represent absolute memory addresses
rather than index numbers. This mode is intended for use as a diagnostic
tool during manufacturing. This is because use of this mode requires detailed
knowledge of the memory structure to interpret the information returned.
Example:

G V 4 0 A0-A2
Group: G.
Variation: V
Q-Code: 4 defining the absolute-index mode with 16-bit indexes. These can
reference a maximum of 65.536 data objects (LSB-MSB).
I-Code: 0 defining no indexing. Objects are packed directly.
Range: A0-A2 this field contains start and stop addresses.
Group Variation Q-Code I-Code Range DO-0 DO-1 DO-2
G V 4 0 A0-A2 A0 A1 A2
In the response message, the data objects follow the message. As for the
range-index mode, it is also possible to use object size prefixes in the re-
sponse message. To do this the I-Code is set to 4, 5 or 6 to select 6-bit, 16-bit
or 32-bit object size prefixes. These have not been illustrated, because the
concept has already been demonstrated for the range-index mode.
All Object Mode

The range-absolute mode is indicated by Q-code 6. This mode specifies all
data objects of the referenced group and variation. No range field is used
with this mode as no additional information is required.
Example:
Group Variation Q-Code I-Code

G V 6 0
It is important to note that this mode is only valid with requests. Clearly
when the data objects are returned in a response message, they must carry
identifiers to let the system know which points they represent. Therefore one
of the other data object referencing modes is used in the response to an all-
object request.
Non-Ranged Mode
The non-ranged mode is indicated by Q-codes 7, 8 and 9. This mode may

be used to identify a number of non-consecutive data objects. For these data
objects, it is not possible to simply provide start and stop indexes to identify
a range. If the data objects do require identification, then this is done using
indexes. there is an index giving a one-to-one correspondence between values
of the index (indexes), and the actual locations within the device memory
of the data objects. In a request message, values of the index are given only,
and these are used at the outstation to find the actual data points.
Example:
Group Variation Q-Code I-Code Range I1 I2 I3

G V 8 1 3 14 37 107
Group: G.
Variation: V
Q-Code: 8 defining the non-ranged mode with 16 range value.
I-Code: 1 defining 8-bit index size.
Range: 3 this field contains the object count. So there are 3 indexes: I1, I2,
I3.
G V 8 1 2
I1 D1 I2 D2 I3 D3
14 37 107
For a response message, the index value for each data object is included with
the data. In the response, each index value is included immediately in front
of its data object. In the non-ranged mode, the size of the indexes is specified
by the index size qualifier sub-field. The valid values for this mode are 0, 1,
2 and 3. The meanings of these are summarized for convenience in the table
4.2. DNP3 79
below.
Index-Size Code for non index-mode

I-Size Size in bits Meaning in Request or Response containing Data
Code Objects
0 no index No indexing. Objects are packed directly.
1 8
Objects are prefixed with an index
2 16
of this length.
3 32
The application of the non-ranged mode differs depending on whether the
I-size code is zero or non-zero. For I-size = 0, the specified number of objects
are called for, or provided. This method is useful for requesting or responding
with a limited amount of data at one time, perhaps if the outstation could
provide more information than could be handled at once by the master sta-
tion. For I-size = 1, 2 or 3 a list of specific data objects is provided. This
is used when particular data objects, or points, are required rather than a
whole range of data objects.
Example:

G V 7 0 3
Group: G.
Variation: V
Q-Code: 7 defining the non-ranged mode with 8-bit range value.
I-Code: 0 defining no indexing size.
Range: 3 this field contains the object count. So in the response there will
3 objects.
Group Variation Q-Code I-Code Range D1 D2 D3
G V 8 1 2
Object Identifier Mode
The object identifier mode is indicated by Q-code 11. This mode provides for
free-format object identifiers that are not interpreted in any particular way
by the DNP3 application. This mode can be used when the other modes of
referencing are unable to uniquely specify the data objects involved. In this
mode the range field contains a one-byte number which specifies the num-
ber of object identifiers. This method is useful for reading file objects, and is
the only way to request a data object that is larger than one fragment in size.
Example:

G V 11 5 2
SizeID-1 Object-ID SizeID-2 Object-ID
S1 1 S2 2
Group: G.
Variation: V
Q-Code: 11 defining the object identifier mode.
I-Code: 5 defining size ID fields are 16 bit.
Range: 2 this field contains the object count. So there are 2 object requests.
G V 11 5 2
SizeID-1 Object-ID D1 SizeID-2 Object-ID D2
S1 1 S2 2
The object identifier mode is the only mode to handle multi-fragment size
data objects. The data must be broken down into pieces that will fit into
fragments. Each piece needs an object identifier:

G V 11 5 =1
SizeID-1 Object-ID DATA FOR PIECE 1
S1 1

G V 11 5 =1
SizeID-2 Object-ID DATA FOR PIECE 12
S2 2
4.2.5 Point Indexes

In the previous sub-sections, reference has been made to the point indexes, or
simply indexes, that identify each particular object within an object group.
The point indexes are assigned by the manufacturer of a device for each of the
points provided by the device. These may be associated directly with physical
inputs or outputs, or with internal points such as registers. The following
general rules apply to the assignment of point indexes by manufacturers:
• Point indexes within each object group begin at zero and are assigned
4.2. DNP3 81
in a continuous sequence.
• There may be gaps in the sequence, but these should be small.

The advantage of using point indexes in sequence is that higher efficiency is
obtained in data transfers. This arises because data points can be identified
in ranges rather than by requiring addresses for each point. Also, in many
cases there will be less than 256 points in an object group, and if indexes
start from zero then these will require only 8-bit range values. It is noted
that some manufacturers devices may contain point indexes that are unique
across object groups rather than just within object groups. For example,
binary inputs may have the numbers 0199, binary outputs 200399 etc.
Data Object Library

There are 90 data objects described in the DNP3 Basic Four documenta-
tion. Each object is denoted by a group number and a variation number.
DNP3 represents the group and variation numbers each with 8-bit fields.
There are a number of general types of objects, and these are organized
into decade ranges. There are usually more than one specific group type
within each range. For each group, there are usually a number of variations.
Object Groups
0-9 Binary Input Objects
10-19 Binary Output Objects
20-29 Counter Objects
30-39 Analog Input Objects
40-49 Analog Output Objects
50-59 Time Objects
60-69 Class Objects
70-79 File Objects
80-89 Device Objects
90-99 Application Objects
100+ Alternate Numeric Objects
The objects are two kinds of objects:
• 0-50: are closely related to physical data monitoring and control points.
• 50-100+: represents non-physical things, for example file objects rep-

resent software, and class objects represent an attribute that may be
assigned to other objects.
In a few cases, there are objects defined that have no data attached to them
at all. Their function is performed merely by the transmission of the object
identifier. For example, the class object is used in a request message only to
identify the class attribute of objects that are being requested.
Within each object group there may be defined a number of variations. It is

important to note that each variation is normally just a different representa-
tion of the same underlying data point. It may have more or less information
than other variations, but the same point is being represented by the object.
For the objects that are related to physical points, the type of data is clas-
sified into four different types. These are shown in the following table. Each
physical point will generally be able to be represented by each of the four
types, which are defined as different variations for each object group.
• Static Data Type: refers to the current value of any point at the time
the information is transmitted. This might be the current value of a
binary input or output, the most recently converted value of an analog
input, the value of a register, or the value of a counter. Static values are
associated directly with physical inputs and outputs, or with internal
registers and counters. There is a one-to-one relationship between these
devices and the static points, so therefore there are as many static
points as there are physical devices, registers, or counters.
• Event Data Type: is generated on the occurrence of a particular

event, such as a change in state of a binary point. If a physical device
such as a binary input has an event variation configured for it, then
whenever it changes an event data object will be generated for that
input-change. In the case of analog inputs, events are generated when
the change in the value reaches a configured dead-band value. The event
object generated would typically be buffered in an event buffer for sub-
sequent transmission to the master station. It should be noted that
any number of event objects can be created for the one input, one for
each change. Normally changes would be held in the buffer until they
have been transmitted successfully to the master station. The typical
use of event data in DNP3 is in a report-by-exception (RBE) operat-
ing mode. In this mode, the master station database is maintained by
transmission of changes in field states rather than through transmission
of static data. By transmitting only changes in field states, the amount
of communication traffic can be significantly reduced. Another use of
event data types is for reporting alarm events. These are events that
may require the attention of the operator and so are presented to the
operator on the screen at the master station.
• Frozen Data Types: are applicable to analog values and counters. A

frozen static value is simply the value in a freeze buffer that is associ-
ated with an analog or counter. The buffer holds a copy of the analog
or counter, taken at a previous time when a “freeze” operation was
4.2. DNP3 83
performed. This might be in response to a master station command,

or alternatively the freeze may be generated by local logic at the de-
vice or RTU. It may be noted that a physical point, such as a counter,
will typically have only one freeze buffer associated with it, and there
will be only one frozen static data object associated with that point.
The frozen event data type is, like the event data type, a data object
that is created on the occurrence of a particular event. As for the event
data type, there can be multiple frozen event data objects created and
buffered for any one point. An example of where this type of object
might be used is where snapshots of system power flows may be taken
on specific trigger events. By defining these as frozen events, multiple
time-tagged snapshots can be taken and stored for the point.
4.2.6 DNP3 Vulnerabilities

This section shows some examples of possible DNP3 vulnerabilities. DNP3 is
a communication protocol extremely articulated. For that reason we analyze
in this section its vulnerabilities considering the different layers composing
the DNP3 specification.
Data-Link Vulnerabilities
The data link layer provides a reliable link between devices for transferring
message frames. As we claimed before, the data link layer header is 10 bytes
long, and the its structure is shown in Table 4.13.
start len ctrl destination source CRC

2 bytes 1 byte 1 byte 2 bytes 2 bytes 2 bytes
Table 4.13: DNP3 Data Link Header
The lack of mechanisms for authentication, authorization, and encryption

enables attackers to intercept messages, modify values, and send them again
on the control network. A simple example could be to insert an incorrect value
in the length field in order to affect the correct processing of the message.
Another possible attack could be executed by changing the destination ad-
dress. An attacker can intercept messages and change destination addresses,
causing unexpected results. Moreover, an attacker can use the broadcast ad-
dress 0xFFFF, sending erroneous request messages to all the outstations.
Moreover, broadcast messages do not require any result massage by default,
making this attack more difficult to be detected. Many other attacks could
involve the “ctrl” field.
FCB FCV
DIR PRM FUNCTION CODE
RES DFC
7 6 5 4 3 2 1 0
We have already explained the meaning of each bit. The possible attacks
to the control field are:
• DFC flag: This flag indicates that an outstation cannot receive further
user data. This means that any request to the outstation should be
resent at a later time. Setting the DFC flag make an outstation appears
busy to the master station even if it is not.
• Reset Function Code: Function Code 1 indicates a user process re-
set request. Sending a frame with this function code makes the target
station restart, making it unavailable for a certain amount of time.
Moreover, the target station may be restored to a state inconsistent
with the rest of the system.
• Unavailable Function Code: Function Code 14 and 15 are requests
sent from secondary stations (responding stations). Function Code 14
indicates that a link service is not functioning and Function Code 15
indicates that a link service is not used or implemented. An attacker
can send a message with these two function codes to the master, making
it believe that the service requested is unavailable, causing the master
not to send requests to the targeted outstation anymore.
Pseudo-Transport Layer Vulnerabilities

The pseudo-transport layer takes user data coming from the above applica-
tion layer and disassembles it into one or more transport protocol data units,
depending on the length of user data. The header attached to each unit al-
lows the receiver to reassemble the whole message. The Table below shows
the structure of the header.
0 4 5 6 7
SEQ CON FIR FIN
As we already described, the FIN flag indicates that the frame is the first
one of the fragmented message. Analogously, the FIR flag indicates that the
frame is the last one. The sequence number field is incremented for successive
frames, and allows to reassemble the message in the proper order. Even if
this layer is very simple, some attacks can exploit its functionalities. We show
some examples.
4.2. DNP3 85
• Message Interruption: When a frame with the FIR flag set arrives,
the receiver believes it is the first frame of the message, discarding any
frame of and incomplete sequence previously received. An attacker can
send a frame with the FIR flag set after the beginning of the transmis-
sion of a fragmented message in order to disrupt the reassembly of the
message. Similarly, sending a frame with the FIN flag terminates the
message reassembly. Sending a frame with the FIN flag enables and
attacker to terminate the message reconstruction early, causing data
corruption.
• Sequence Number Modification: An attacker can intercept frame

transmission and easily predict the value of the sequence number field
of the next frame. In this way, it is easy to send a properly fabricated
frame either for injecting arbitrary data or for causing data corruption.
Application Layer Vulnerabilities

Figure 4.2.6 shows the structure of the header of application layer messages.
The application control field is the first byte, which provide control function-
alities. The function code field indicates the purpose of the message.

0 2/4 2048
APCI ASDU
Request Response
AC FC AC FC IIN FC (Function Code) 1 byte
0 1 2 0 1 2 4
We show now some attack examples.
• Outstation Write Function Code: Function Code 2 allows to store

specified data object in an outstation. Storing arbitrary data objects
enables an attacker to cause errors or overflows.
• Clear Object Function Code: Freeze functions provide a way to

store an object of an outstation in a buffer called freeze buffer. Function
Code 9 and 10 are used to copy a specified object to a freeze buffer. An
attacker may leverage this functionality to clear critical data or make

an outstation devise crash or malfunction. Moreover, while Function
Code 9 needs a status of operation response, Function Code does not
require any response. Thus, an attack exploiting Function Code 10 is
more difficult to be detected.
• Outstation Data Reset: Function Code 15 initializes specific data

to initial or default settings. An attacker may use this function code
to reinitialize an outstation data object to values inconsistent with the
state of the system.
• Outstation Application Termination: Function Code 18 is used

to stop specific application running on outstations. An attack based
on this function code may cause the outstation to be unresponsive to
requests from the master.
• Configuration Capture: The fifth bit in the second byte of the In-
ternal Indications field (IIN) indicates that the configuration file of the
targeted outstation is corrupted. Transmitting a message with this flag
to the master makes it believe that the outstation needs a new config-
uration file and send it to the outstation. Moreover, an attacker can
modify and upload the configuration file to the outstation.
We took into account only vulnerabilities related to the specification of the

DNP3 protocols. Several others vulnerabilities related to specific implemen-
tation of the protocol can be discovered and used. Vulnerabilities specific of
the protocol are easy to deduct from the analysis of the protocol specification,
due to the lack of security mechanisms, and represent value information for
any attacker. On the other hand, vulnerabilities due to bugs in manufacturer
implementations are more difficult to discover, and it is easier to keep this
knowledge confidential.
Chapter 5
State Based Approach
As we discussed in the introduction, the aim of this thesis is to create an

”Intrusion Detection System (IDS)” tailored for SCADA systems. Such IDS
is called ”State Based Intrusion Detection System”. The “State-Based Ap-
proach” is not based on packet signatures techniques, as a classic IDS, but
it is based on a representation of the state of the SCADA system. This ap-
proach relies on the assumption that the ultimate scope of an attacker is to
put the target system into a critical state, therefore by looking at the sys-
tem evolution and by detecting the occurrence of critical states, it would be
possible to automatically detect an attack. Using this approach, the focus
is primarily on known variables (the system behavior), rather than on un-
known variables (the attacker behavior), which eliminates the risks of false
positives and detecting also unknown attacks. This approach is possible in
the context of industrial settings, since the “system behavior space” is fully
known and finite. In order to achieve this goal, we have formally defined how
to represent a SCADA system. The representation of the system is useful for
the creation and update of the System Virtual Image (SVI). The image is a
software copy of a real system and evolves in parallel with the real system.
The SVI is able to match his status with a list of critical states in order
to recognize potential threats to the system. For these reasons two kind of
representation are necessary into the IDS:
• A representation of the entire SCADA system status.
• A representation of the critical states in which the SCADA system

might be if something goes wrong.
87
88 CHAPTER 5. STATE BASED APPROACH
Critical State
In order to better understand what is a critical state we consider the following
example [7]: we have a system with a pipe P1 in which flows high pressure
steam. The pressure is regulated by two valves: the valve VIN controls the
pipe incoming steam and the valve VOU T controls the pipe outcoming steam.
The valve VIN is controlled by the P LC1 and the valve VOU T is controlled by
the P LC2 . The Figure 5.1 shows such scenario.
VOUT
P1
PLC 2
V IN
PLC 1
Figure 5.1: Critical State Example
A critical state could be generated by an attacker. For example he is

able to send packets on the process network and sends a command to the
P LC2 controlling the valve VOU T in order to force its complete closure, and
a command to the P LC1 controlling the valve VIN in order to maximize the
incoming steam. This is a critical state because the pressure in the pipe P1
may became too high soon and the pipe could explode.
5.1 How to represent a SCADA system

A SCADA system, as we described in the chapter 3, is composed by an oper-
ator, a Human machine Interface (HMI), one or more Master Terminal Unit
(MTU) and some Remote Terminal Units (RTUs) or PLCs. The intention
is to represent a SCADA system, i.e. to create a virtual image of the real
system. The image of the entire SCADA system consists of the image of each
single component such as SCADA Masters or MTUs and SCADA Slaves or
PLCs. Representation of the operator and the HMI are of less importance,
5.1. HOW TO REPRESENT A SCADA SYSTEM 89
given the nature of the types of threats the system is intended to protect
against (i.e. external attacks). More formally, the system image is a set of
images:
SY ST EMimage = {M asterimage , P LC 1image , ..., P LC nimage }
. The representation of each PLC or Master station must contain:
• The architecture of the item: it is important to represent the infor-
mation to identify the item, i.e. the IP address and the TCP port, and
the information about the item architecture, i.e. numbers and type of
registers.
• The current status of the item: the status of a SCADA Slave is the
current value of each register. SCADA Masters don’t need information
about the status.
In the following we present an example of a SCADA system, which uses the
MODBUS protocol as communication protocol between masters and slaves.
MODBUS SCADA System Example

Imagine to have the scenario shown in Figure 5.2 with one SCADA Master
and three PLCs or SCADA Slaves.
Master
Address: 10.0.0.254
Port: 502
Address: 10.0.0.2
Address: 10.0.0.1 Address: 10.0.0.3
Port: 502
Port: 502 Port: 502
ID: 2
ID: 1 ID: 3
PLC 1 PLC 2 PLC 3
DI 100 DI 200 DI 300

CO 100 CO 200 CO 300
IR 100 IR 200 IR 300
HR 100 HR 200 HR 300
Figure 5.2: MODBUS SCADA System Example

The shown system contains one SCADA Master with the IP address
10.0.0.254 and TCP port 502 (MODBUS default port according to the mod-
bus TCP specification [2]) and three SCADA Slaves:
• The P LC1 with the IP address 10.0.0.1, TCP port 502 and ID = 1.
According to the MODBUS specification [1] each PLC contains Discrete In-
puts (DI), Coils (CO), Input Registers (IR) and Holding Registers (HR). In
the previous scenario there are 100 DI, CO, IR, HR in the P LC1 , 200 in the
P LC2 and 300 in the P LC3 .
In a MODBUS SCADA Slave, as described in 4.1, there are also other regis-
ters and coils: the “Exception Status Coils”, the “Diagnostic Register ” and
some “Counters”, which are used for diagnostic functions. In light of these
consideration a possible representation of the SCADA system in figure 5.2 is
shown in the UML diagram in Figure 5.3.
int : 32-bit number

short : 16-bit number Master
byte : 8-bit number -address : string = 10.0.0.254
-port : int = 502
PLC 1 PLC 2 PLC 3

-address : string = 10.0.0.1 -address : string = 10.0.0.2 -address : string = 10.0.0.3
-port : int = 502 -port : int = 502 -port : int = 502
-id : byte = 1 -id : byte = 2 -id : byte = 3
-discrete inputs : bool [100] -discrete inputs : bool [200] -discrete inputs : bool [300]
-coils : bool [100] -coils : bool [200] -coils : bool [300]
-input registers : short [100] -input registers : short [200] -input registers : short [300]
-holding registers : short [100] -holding registers : short [200] -holding registers : short [300]
-exception status coils : bool [8] -exception status coils : bool [8] -exception status coils : bool [8]
-diagnostic register : bool [16] -diagnostic register : bool [16] -diagnostic register : bool [16]
-counters : short [9] -counters : short [9] -counters : short [9]
Figure 5.3: Representation of the previous system.
The UML diagram above could be implemented in an object oriented

language such as C++, C#, Java etc. Each entity in the diagram could be
implemented with an object. The object which represents the Master contains
only two attributes: a string which represents the IP address and an integer
5.1. HOW TO REPRESENT A SCADA SYSTEM 91
that represents the TCP port number. The other objects represent the Slaves
contain many attributes as shown in the Table 5.1
Slave Identification
address a string which contains the Slave IP Address
port a 32-bit number which contains the Slave TCP Port
id a 8-bit number which contains the Slave id
Registers and Coils
discrete inputs an array of boolean values which contains the value
of each discrete input
coils an array of boolean values which contains the value
of each coil
input registers an array of 16-bit numbers which contains the value
of each input register
holding registers an array of 16-bit numbers which contains the value
of each holding register
Diagnostic
exception status an array of boolean values which contains the value
coils of each exception status coil
diagnostic register a 16-bit number which contains the diagnostic reg-
ister value
counters an array of 16-bit numbers which contains the value
of each counter
Table 5.1: MODBUS Slave Representation fields
With the structure shown in Table 5.1 is possible to represent the ar-
chitecture of a SCADA MODBUS Slave and also the current status of the
device. The architecture is represented by the slave identification attributes
(i.e. address, port and id), the numbers of coils and registers (i.e. array sizes)
and the current status is stored in each array cell.
MODBUS Critical State Example
In the following is considered the previous scenario where the system consists
of one master and three PLCs. In such scenario two valves and a pipe are
added, in order to create the critical state example explained in the beginning
of this chapter. This would result in a situation similar to that shown in
Figure 5.4.
Master
Address: 10.0.0.254
Port: 502
Address: 10.0.0.2
Port: 502
Port: 502 Port: 502
ID: 2
ID: 1 ID: 3
PLC 1 PLC 2 PLC 3
HR[1] 50 HR[2] 50
VOUT VIN
P1
Figure 5.4: SCADA System plus Critical State Situation.
In this architecture we have added the pipe P1 in which flows steam,

the valve VIN , which controls the pipe incoming steam and the valve VOU T ,
which controls the pipe outcoming steam. In such an example the valves are
connected to the SCADA system in the following way:
• VIN (input steam): is connected to PLC 10.0.0.1 and the holding

register HR[1] contains a value which represents how much the valve
is open, i.e. if HR[1] = 100 then VIN is completely open, if HR[1] = 0
then VIN is completely closed, if, like in the picture, HR[1] = 50 then
VIN is half closed.
• VOU T (output steam):: is connected to PLC 10.0.0.2 and the holding

register HR[2] contains a value which represents how much the valve is
open; it works in the same way as the valve VIN .
The system is in a critical state when the valve VOU T is too far closed and the
valve VIN is too far open, because in a such situation the amount of steam
5.2. SCADA SYSTEM MODELING LANGUAGE 93
entering the pipe exceeds the amount being released, leading to an increase
in pipe pressure and an increased chance of a pipe explosion. If we define
“too far closed ” as a value of 20% for the valve VOU T and “too far open”
as a value of 70% for the valve VIN , then we can represent the system in a
“critical state” using the following boolean expression:
IF (PLC[ 10.0.0.1 ].HR[1] < 20 AND

PLC[ 10.0.0.2 ].HR[2] > 70 ) THEN
“the system is in a critical state”
5.2 SCADA System Modeling Language

As we described before, a SCADA system image is a set of PLCs and Masters
images:
SY ST EMimage = {M asterimage , P LC 1image , ..., P LC nimage }
We represent the system image with a formal language called “SCADA Sys-
tem Modeling Language (SSML)”. The SSML is specified using a standard
EBNF notation. In the current version, this language supports SCADA sys-
tems that use the MODBUS protocol, but it can be easily extended in order
to support different industrial protocols. A SCADA system is composed by
many devices, each device is a SCADA Master or a SCADA Slave.
A SCADA Master is identified by a couple of attributes, i.e. IP Address and
TCP Port. A SCADA Slave is identified by IP Address, TCP Port and slave
ID, in addition, for a SCADA slave is important to represent the registers
status.
<system> ::= <device> | <device>,<system>

<device> ::= <master> | <slave>
<master> ::= MASTER[ <address>:<port> ]
<slave> ::= SLAVE[ <address>:<port>:<id> ].<reg status>
<address> ::= <byte>.<byte>.<byte>.<byte>
<byte> ::= 0|1|..|255
<port> ::= 0|1|..|65535
<id> ::= <byte>
This is the first part of the language, which is enough to represent Master
ans Slave devices. For example a SCADA master and a SCADA slave from
the scenario in Figure 5.2 are represented by the following expressions:
• MASTER[ 10.0.0.254 : 502 ]
• SLAVE[ 10.0.0.1 : 502 : 1]
We now present the part of the language used to describe a Slave register
status. The status is the register value, i.e. the value of a Discrete Input
(DI), a Coil (CO), an Input Register (IR) or an Holding Register (HR) or
a diagnostic register such as an Exception Status Coil (EX), a Diagnostic
Register (DR) or a Counter (CTR).
<reg status> ::= <reg>|<exc>|<dia>|<ctr>

<reg> ::= CO[<reg index>]<rel><bit>|
DI[<reg index>]<rel><bit>|
IR[<reg index>]<rel><word>|
HR[<reg index>]<rel><word>|
EX[<exc index>]<rel><bit>|
DR[<dia index>]<rel><bit>|
CTR[<ctr index>]<rel><word>
<reg index> ::= 0|1|..|65535
<exc index> ::= 0 | 1 | . . | 7
<dia index> ::= 0|1|..|15
<ctr index> ::= 0 | 1 | . . | 8
<bit> ::= 0|1
<word> ::= 0|1|..|65535
<rel> ::= =
Each register is identified by an index and a value. There are different indexes
for the normal registers and the diagnostic registers, because normal registers
have indexes from 0 to maximum 65535 and diagnostic registers have the
following indexes: from 0 to 7 for the Exception Status Coils (EX), form 0
to 15 for the Diagnostic Register (DR) and form 0 to 8 for the Counters
(CTR). There are also different kinds of values for each register: 1-bit or
16-bit depending on the register type. For example a coil status could be
represented by the following expression:
• SLAVE[ 10.0.0.1 : 502 : 1].CO[1] = 0
Such expression can be translated as “at this moment the value of the coil
with index 1 is set to off ”.
5.2. SCADA SYSTEM MODELING LANGUAGE 95
With this language it is possible to formally describe SCADA systems such as

the system presented in the previous section. Below is shown the system and
its representation with the “SCADA System Modeling Language (SSML)”.
Master
Address: 10.0.0.254
Port: 502
Address: 10.0.0.2
Port: 502
Port: 502 Port: 502
ID: 2
ID: 1 ID: 3
PLC 1 PLC 2 PLC 3
DI 100 DI 200 DI 300

CO 100 CO 200 CO 300
IR 100 IR 200 IR 300
HR 100 HR 200 HR 300
system = { MASTER[ 10.0.0.254:502 ] ,

SLAVE[ 10.0.0.1:502:1 ].DI[0] = 1,
...
SLAVE[ 10.0.0.1:502:1 ].HR[100] = 11,
SLAVE[ 10.0.0.2:502:2 ].DI[0] = 0,
...
SLAVE[ 10.0.0.2:502:2 ].HR[200] = 22,
SLAVE[ 10.0.0.3:502:3 ].DI[0] = 1,
...
SLAVE[ 10.0.0.3:502:3 ].HR[300] = 33,
}
The SCADA System above is fully represented by the “SCADA System Mod-
eling Language (SSML)”, in fact the SSML is able to describe:
• The system architecture with one master and three slaves and their
identification attributes.
• The system status with the status of each register in every slave device.
In order to represent Critical States, we have to extend this language with

another one called “Critical State Modeling Language (CSML)”.
5.3 Critical State Modeling Language

The “Critical State Modeling Language (CSML)” is similar to the SSML, but
with some extensions. These extensions are useful for representing critical
state complex conditions using boolean operators and comparison operators.
<critical state> ::= IF <cond> THEN CRITICAL STATE

<cond> ::= <pred>|<cond><op><cond>|NOT<cond>|(<cond>)
<op> ::= AND | OR
<pred> ::= SLAVE[ <address>:<port>:<id> ].<reg status>
<reg status> ::= <reg>|<exc>|<dia>|<ctr>
<reg> ::= CO[<reg index>]<rel><bit>|
DI[<reg index>]<rel><bit>|
IR[<reg index>]<rel><word>|
HR[<reg index>]<rel><word>|
EX[<exc index>]<rel><bit>|
DR[<dia index>]<rel><bit>|
CTR[<ctr index>]<rel><word>
<reg index> ::= 0|1|..|65535
<exc index> ::= 0 | 1 | . . | 7
<dia index> ::= 0|1|..|15
<ctr index> ::= 0 | 1 | . . | 8
<bit> ::= 0|1
<word> ::= 0|1|..|65535
<rel> ::= <= | >= | < | > | =
The extensions added to the SSML language are:
• the possibility to create boolean predicates with multiple conditions

linked by boolean operators (AND,OR,NOT).
• the possibility to compare the register value with many comparison

operators (<, ≤, >, ≥, =) .
5.3. CRITICAL STATE MODELING LANGUAGE 97
With this language it is possible to formally describe SCADA critical states

such as the example presented in the beginning of this chapter. Below is
shown the critical state picture and its representation with the “Critical
State Modeling Language (CSML)”.
Master
Address: 10.0.0.254
Port: 502
Address: 10.0.0.2
Port: 502
Port: 502 Port: 502
ID: 2
ID: 1 ID: 3
PLC 1 PLC 2 PLC 3
HR[1] 50 HR[2] 50
VOUT VIN
P1
IF PLC[ 10.0.0.1 : 502 : 1 ].HR[1] > 70 AND

PLC[ 10.0.0.2 : 502 : 2 ].HR[2] < 20 THEN
CRITICAL STATE
The SCADA critical state above is fully represented by the “Critical State
Modeling Language (CSML)”, in fact the condition expressed with the CSML
can be translated into “if the valve VOU T it too far open (i.e. more than 70%
open) and the valve VIN is too far closed (i.e. less than 20% open) then the
steam pressure in pipe P1 will be too high, therefore the system is in a critical
state”.
The formal SSML and CSML language and the logic behind them are a basic
part of the ”State Based Intrusion Detection System” described in the next
chapter. These formal languages have been implemented in an object oriented
language and they allow the IDS to store the system status in memory and
to represent critical states.
Chapter 6
Critical State Based IDS

Architecture
This chapter presents the “State Based Intrusion Detection System”. Our IDS
have been implemented following the new approach to intrusion detection for
SCADA systems, based on the concept of system knowledge and system state
analysis. Before starting with the IDS description a brief overview of the IDS
technology is provided.
6.1 IDS Technology

An Intrusion Detection System is a device (or application) that monitors
network and/or system activities for potential intrusions and reporting them
accurately to the proper authority. An IDS monitors the events occurring
in a computer system or network and analyzes them for signs of possible
incidents, which are violations or imminent threats of violation of system
security policies. There are two main types of IDS’s: network-based and host-
based IDS.
• Network-Based IDS (NIDS): It is an independent platform, called

sensor, that identifies intrusions by examining network traffic and moni-
tors multiple hosts. The sensor captures all network traffic and analyzes
the content of individual packets for malicious traffic. NIDS gain access
to network traffic by connecting to a hub or a network switch configured
for port mirroring. An example of a NIDS is Snort [10].
• Host-Based IDS (HIDS): in HIDS systems, the sensor usually con-

sists of a software agent, which monitors all activity of the host on
which it is installed, including file system, logs and the kernel in order
99
100 CHAPTER 6. CRITICAL STATE BASED IDS ARCHITECTURE
to find malicious software activities. An example of a HIDS is OSSEC

[11].
IDS technologies can be divided into two categories: passive and active sys-
tems. In a passive system, the IDS sensor detects a potential security breach,
logs the information and signals an alert to the console. In a reactive system,
also known as Intrusion Prevention System (IPS), the sensor responds to the
suspicious activity by resetting the connection or by reprogramming the fire-
wall to block network traffic from the suspected malicious source. This can
happen automatically or at the command of an operator. The term IDPS is
commonly used to refer to hybrid security systems that both “detect” and
“prevent” malicious traffic. Another important IDS feature is the detection
technique. There are two generally accepted categories of intrusion detection
techniques:
• Signature Based Detection: network traffic is examined in search of

preconfigured and predetermined attack patterns known as signatures.
The IDSs that use this technique perform a pattern matching between
network traffic captured and attack signature. If the matching succeeds,
then the system generates an alarm.
• Anomaly Detection: it flags observed activities that deviate signif-

icantly from the established normal usage profiles as anomalies. The
construction of such detector starts by creating a model of what con-
stitutes normal for the observed network, and then deciding on what
percentage an activity must be flagged as abnormal.
The main advantage of signature detection paradigm is that it can accurately

and efficiently detect instances of known attacks. The main disadvantage is
that it lacks the ability to detect the newly invented attacks, which is the
main advantage of anomaly detection. The disadvantage of anomaly detection
is that it may not be able to describe what an attack is and may have high
false positive rate.
6.2 IDS General Architecture

The “State Based Intrusion Detection System” can be classified as a Network-
Based IDS (NIDS) with two detection systems: the Signature Based Detec-
tion and the State Based Detection.
• Signature Based Detection: it is a normal signature detection, but

it is tailored for SCADA protocols.
6.2. IDS GENERAL ARCHITECTURE 101
• State Based Detection: it is similar to an anomaly detection, because

it is able to detect the newly invented attacks. The anomaly detection is
based on “a model which represents the normal behavior of the system”,
whereas the state based detection is based on “a model which represents
the abnormal behavior of the system”. The “abnormal behavior ” is
what we have defined as ”Critical State“ in the Chapter 5. If the system
is entering into a critical state, the IDS raises an alert.
By the use of the ”State Based Detection“ is possible to detect many kinds
of attacks against SCADA systems.
• Single packet-based attacks: in which the attacker just sends a

forbidden packet to a target PLC, or uses rare commands. The IDS is
able to identify these kind of attacks by the signature based detection
module.
• Complex multiple packet-based attacks: in which the attacker

sends allowed packet in order to bring the system from a secure state
to a critical state. The IDS can identify these attacks by the state based
detection module.
• Unknown attacks: it is possible to detect unknown attacks because

the ”State Based Detection“ is based on known variables (the system
behavior), rather than on unknown variables (the attacker behavior).
The traditional IDS, like Snort [10] are able to identify single packet-based
attacks, but only a “State Based IDS ” is able to identify the complex multiple
packet-based attacks.
The “State Based Intrusion Detection System” is composed by five logical
element:
• SCADA Protocol Sensor (SPS): it is basically the equivalent of

a NIDS sensor, with the advantage of being able to directly support
commonly used SCADA protocols, like Modbus and DNP3. It receives
the mirror of all the traffic to and from the field network directly from
the SPAN port of the field network switch, it builds up the SCADA
protocol flow and analyzes it in search of matching within the Single
Packet Rules DB. Moreover, it uses the information retrieved in order
to keep updated the system state.
• Single packet rules DB (SPDB): It contains all the signatures of

the known single packet-based attacks on SCADA protocols.
• System Virtual Image (SVI): It contains the representation of the

state of the system under analysis. The SVI is a collection of data
structures representing the different PLCs and RTUs of the monitored
system, with their memory registers, coils, inputs and outputs.
• State Validator & Inspector (SVAL): It checks the consistency of

the System Virtual Image and eventually queries the field devices to
keep synchronized the SVI with the physical system state. Moreover, it
verifies, according to the rules stored into the Critical State Rules DB,
if the system is entering into a critical state, and in that case, raises
an alert, notifying the pool of packets which have contributed to bring
the system in such critical state as well.
• Critical State Rules DB (CSRDB): it contains the rules describing

all the critical states of the system.
From an operational point of view, the SPS analyzes all the traffic flowing
through the field network, re-constructs the SCADA protocol flows and ac-
cording to the rules specified into SPDB, identifies the low level malicious
packets raising an alert if it’s the case. Moreover, it sends all the recon-
structed, operative commands to SVAL, in order to update the virtual image
of the system. The SVAL simultaneously performs two operations: (a) it
updates the SVI using the packets received from the SPS, and performing
periodical queries to the field devices in order to check their state and guar-
antee the SVI consistency; (b) Every time a new packet is received from the
SPS, it verifies the state of the system according to the rules stored into the
CSRDB and it raises an alert if the process has entered into a critical state.
The Figure 6.1 shows the “State Based IDS ” architecture. It is composed by
five modules and several functional components.
SCADA Protocol
Sensor (SPS)
State Validator & Inspector (SVAL) Network
Capture
Analyzing
Module
Basic Critical State Protocol

Analyzer Analyzer Discover
Protocol
Builder
System Virtual
Image (SVI)
Update System
Manager
Real System Database

Synchronizer
DB Sender
Loader
Real System
Single Basic
packet rules Rules
Virtual DB (SPDB)
System File
PLC 1 PLC 2 Loader
Critical State Critical
Rules DB State
(CSRDB) Rules
PLC n
File
Virtual
System
Descriptor
File
Figure 6.1: “State Based Intrusion Detection System”Architecture
Loader
It is in charge of the initialization of the whole system. By means of three
different XML files, LS creates respectively a System Virtual Image (SVI)
and two rules repositories.
• Single packet rules DB (SPDB): It contains all the signatures of

the known single packet-based attacks on SCADA protocols. Each sig-
nature express the contents of target malicious commands.
• Critical State Rules DB (CSRDB): It contains all the rules that

represents the “critical state” by using the CSML described in Section
5.3.
• Virtual System Loader: It parse the “XML Virtual System Descrip-

tor File” and it initializes the System Virtual Image (SVI). The XML
file contains all the basic system information required for the descrip-
tion of the virtual system. Each node in such XML file represents a
SCADA Master or a SCADA slave by using the SSML described in
Section 5.2.
SCADA Protocol Sensor (SPS)

The sensor captures SCADA network traffic and analyzes the content of each
packet. It contains three functional components:
• Network Capture Module: it captures the traffic directly from the

network card in promiscuous mode.
• Protocol Discover: it keeps SCADA packet and discards the non-

SCADA. In addition it is able to discriminate MODBUS packets and
DNP3 packets and to send the packet to the right parser.
• Protocol Parser: it is in charge of extracting the information from

MODBUS or DNP3 packets.
System Virtual Image (SVI)

It contains the virtual representation of the real system under analysis. It
contains two functional components:
• Update System Manager: it keeps the System Virtual Image (SVI)

updated taking as input the command flows captured by the SPS.
• Real System Synchronizer: it keeps the SVI updated by querying

periodically the real system.
Analyzer
It performs the “Signature Based Detection” and the “State Based Detec-
tion”. It contains two functional components:
• Basic Analyzer: it receives in input the packets captured by the SPS,

then it analyzes each packet and if a packet matches with a signature
in the SPDB, then it raises an alert.
• Critical State Analyzer: it receives in input the packets captured

by the SPS, then it updates the SVI with the information contained in
the packets, moreover if the SVI status match with a “Critical State”
contained in the CSRDB it raises an alert. In addition when the “Real
System Synchronizer ” performs a SVI update, it checks again the Vir-
tual System in order to find “Critical States”.
DB Sender
It manages the database used to store the alerts coming from the Analyzer.
In our prototype we used MySQL database.
In the next two section we describe in details the most important parts in
the “State Based Intrusion Detection System” architecture, i.e. the System
Virtual Image and the Analyzer.
6.3 System Virtual Image

The “System Virtual Image (SVI)” is the virtual representation of the system
under analysis. The SVI is created by the IDS from the “XML Virtual System
Descriptor File” as shown in Figure 6.2.
Real System Master SSML Representation

Address: 10.0.0.254
Port: 502 MASTER[ 10.0.0.254:502 ] ,
SLAVE[ 10.0.0.1:502:1 ].DI[0] = 1,

...
SLAVE[ 10.0.0.1:502:1 ].HR[100] = 11,
SLAVE[ 10.0.0.2:502:2 ].DI[0] = 0,

Address: 10.0.0.2
Address: 10.0.0.1
Port: 502
Address: 10.0.0.3 ...
Port: 502 Port: 502
ID: 1
ID: 2
ID: 3
SLAVE[ 10.0.0.2:502:2 ].HR[200] = 22,
PLC 1 PLC 2 PLC 3 SLAVE[ 10.0.0.3:502:3 ].DI[0] = 1,

...
DI 100 DI 200 DI 300
SLAVE[ 10.0.0.3:502:3 ].HR[300] = 33,
CO 100 CO 200 CO 300
IR 100 IR 200 IR 300
HR 100 HR 200 HR 300
XML Virtual System Descriptor File
<infrastructure>
Objects Stored in IDS memory <master address="10.0.0.254" port="502" />
<plc address="10.0.0.1" port="502" id="1" >
Master
<discrete_inputs numbers="100" />
-address : string = 10.0.0.254
-port : int = 502 ...
<holding_registers numbers="100" />
</plc>
PLC 1 PLC 2 PLC 3
-port : int = 502 -port : int = 502 -port : int = 502 <discrete_inputs numbers="200" />
-id : byte = 1
-discrete inputs : bool [100]
-id : byte = 2
-id : byte = 3
...
-coils : bool [100] -coils : bool [200] -coils : bool [300] <holding_registers numbers="200" />
-holding registers : short [100] -holding registers : short [200] -holding registers : short [300] </plc>
-exception status coils : bool [8] -exception status coils : bool [8] -exception status coils : bool [8] <plc address="10.0.0.3" port="502" id="3" >
-diagnostic register : short -diagnostic register : short -diagnostic register : short
-counters : short [9] -counters : short [9] -counters : short [9] <discrete_inputs numbers="300" />
...
<holding_registers numbers="300" />
</plc>
</infrastructure>
Figure 6.2: “System Virtual Image (SVI)” Creation
In Figure 6.2 is shown how the real system is represented through the
“SCADA System Modeling Language (SSML)”, the XML Virtual System De-
scriptor File and how it is stored in the IDS memory. The IDS administrator
checks the architecture of the real system and writes the corresponding XML
file following the SSML rules. The IDS provides a useful tool called “Critical
Infrastructure Creator” to help the administrator to design the XML Virtual
System Descriptor File. The IDS parses the XML file and stores in memory
the objects used to represent the Virtual Image. Such representation allows
the IDS to keep the Virtual System updated and synchronized with the Real
System as described in the following.
6.3. SYSTEM VIRTUAL IMAGE 107
Virtual System Update

As we described, the IDS creates the SVI, but it is also in charge of keep
updated the system state. It receives the mirror of all the traffic to and from
the field network directly from the SPAN port of the field network switch, it
builds up the SCADA protocol flow and it uses the information retrieved in
order to keep updated the system state. The Figure 6.3 shows an example
with a MODBUS message and the consequent SVI update.
Source Destination Function Code Address Value

10.0.0.254 10.0.0.1 Write Coil (05) 1 1
Virtual System
PLC 10.0.0.1 PLC 10.0.0.2 PLC 10.0.0.3

0 1 99 0 1 199 0 1 299
DI 0 0 .. 0 DI 0 0 .. 0 DI 0 0 .. 0
CO 0 1 .. 0 CO 0 0 .. 0 CO 0 0 .. 0
IR 0 0 .. 0 IR 0 0 .. 0 IR 0 0 .. 0
HR 0 0 .. 0 HR 0 0 .. 0 HR 0 0 .. 0
Figure 6.3: “System Virtual Image (SVI)” Update
In Picture 6.3, the IDS captures a MODBUS packet with the following
information: the recipient is the PLC “10.0.0.1”, the function code is “0x05
Write Single Coil”, the coil address is “1” and the value to write is “1”. The
IDS updates the SVI by changing the value of the coil 1 in PLC 10.0.0.1 and
putting it to 1 (PLC[10.0.0.1].CO[1]=1).
The “Virtual System Update” operation, sometimes is not enough to keep
the SVI really synchronized with the real system. For example, if there is a
temperature sensor in a SCADA system, but the master requires very rarely
its value (every two minutes); in this case is possible that the temperature
change very much between a master request and the next one, therefore the
SVI is not updated, because it will detect the temperature change after two
minutes. In such cases the “Virtual System Update” is not enough, for this
reason the IDS performs another task called “Virtual System Synchroniza-
tion” which is a periodically query to the real system devices in other to have
a better real time update.
Virtual System Synchronization

The Figure 6.4 shows an example of a “Virtual System Synchronization”
with the SVI representation before and after the update.
Virtual System Before
PLC 10.0.0.1 PLC 10.0.0.2 PLC 10.0.0.3

0 1 99 0 1 199 0 1 299
Master
Address: 10.0.0.254 DI 0 0 .. 0 DI 0 0 .. 0 DI 0 0 .. 0
Port: 502
CO 0 0 .. 0 CO 0 0 .. 0 CO 0 0 .. 0
IR 0 0 .. 0 IR 0 0 .. 0 IR 0 0 .. 0
Query Field
Devices HR 0 0 .. 0 HR 0 0 .. 0 HR 0 0 .. 0
Address: 10.0.0.2
Port: 502
Port: 502 Port: 502
ID: 2
ID: 1 ID: 3
System
Update
PLC 1
PLC 2 PLC 3
0 1 99 0 1 199 0 1 299
DI 0 1 .. 0 DI 0 0 .. 0 DI 0 0 .. 0 Virtual System After
CO 0 1 .. 0 CO 0 0 .. 0 PLC 10.0.0.1 PLC 10.0.0.2 PLC 10.0.0.3

CO 0 0 .. 1
0 1 99 0 1 199 0 1 299
IR 0 0 .. 0 IR 0 8 .. 0 IR 0 0 .. 0 DI 0 1 .. 0 DI 0 0 .. 0 DI 0 0 .. 0
HR 0 0 .. 0 HR 0 0 .. 0 HR 0 7 .. 0 CO 0 1 .. 0 CO 0 0 .. 0 CO 0 0 .. 1
IR 0 0 .. 0 IR 0 8 .. 0 IR 0 0 .. 0
HR 0 0 .. 0 HR 0 0 .. 0 HR 0 7 .. 0
Figure 6.4: “System Virtual Image (SVI)” Synchronization
The synchronization is described by the picture in three steps:
1. The SVI image before the synchronization is completely cleared (all

registers are zero).
2. The IDS queries all the three devices in the SCADA system and asks
all the registers and coils values.
3. The IDS updates the SVI with the information gathered from the field
devices.
In this case the IDS checks five differences between the real system and the
SVI; they are highlighted in red.
6.4. RULE CHECK 109
6.4 Rule Check

When the IDS performs the “Virtual System Update” operation, it checks
also the Critical State Rules DB (CSRDB) in search of matching between
a critical state and the SVI current state. In Figure 6.5 a simple check rule
example is shown.
Source Destination Function Code Address Value

10.0.0.254 10.0.0.1 Write Coil (05) 1 1
Virtual System Update

Virtual System
PLC 10.0.0.1 PLC 10.0.0.2 PLC 10.0.0.3

0 1 99 0 1 199 0 1 299
DI 0 0 .. 0 DI 0 0 .. 0 DI 0 0 .. 0
CO 0 1 .. 0 CO 0 0 .. 0 CO 0 0 .. 0
IR 0 0 .. 0 IR 0 0 .. 0 IR 0 0 .. 0
HR 0 0 .. 0 HR 0 0 .. 0 HR 0 0 .. 0
Check Rules DB
CSRDB
IF ( PLC[10.0.0.1].CO[1] == 1 ) THEN ALERT
Raise an Alert
Figure 6.5: “Critical State Rules DB ” checking
The scenario is the same described before: the IDS captures a MODBUS
packet with recipient PLC “10.0.0.1”, function code “0x05 Write Single Coil”,
coil address “1” and value to write “1”. The IDS updates the SVI by writing
“PLC[10.0.0.1].CO[1]=1”. In addition the IDS checks the the Critical State
Rules DB (CSRDB). In such example the CSRDB contains the rule “IF (
PLC[10.0.0.1].CO[1] == 1 ) THEN ALERT ”. Such rule matches with the
SVI state because the coil 1 in the PLC 10.0.0.1 has the value 1, so the IDS
raises an alert.
In this chapter we have given a brief overview of the IDS architecture and how
it works. In the next chapter we will go into details of the IDS implementation
explaining each single module structure.
Chapter 7
IDS Prototype Implementation
We present in this chapter a detailed explanation about how the ”State

Based Intrusion Detection System” works. The IDS prototype has been im-
plemented in C# (MS.NET framework version 3.5) in an MS-Windows envi-
ronment. From the architectural point of view, it was implemented according
to a modular approach. There are five big modules:
• Loader
• Scada Protocol Sensor (SPS)
• System Virtual Image (SVI)
• Analyzer
Each module is divided into many sub-modules with different functions. In

what follow we will explain in details all the modules and sub-modules and
their functions.
111
112 CHAPTER 7. IDS PROTOTYPE IMPLEMENTATION
The Figure 7.1 shows a diagram of the IDS architecture.

SCADA Protocol
Sensor (SPS)
Network
Capture
Analyzer
Module
Basic Critical State Protocol

Analyzer Analyzer Discover
Protocol
Builder
System Virtual
Image (SVI)
Update System
Manager
Real System Database

Synchronizer
DB Sender
Loader
Real System
Single Basic
packet rules Rules
Virtual DB (SPDB)
System File
PLC 1 PLC 2 Loader
Critical State Critical
Rules DB State
(CSRDB) Rules
PLC n
File
Virtual
System
Descriptor
File
Figure 7.1: “State Based IDS ” Architecture
We have already shown some aspects of this architecture, but in this

section we will explain in detail how they were implemented.
7.0.1 Loader
The loader module is in charge to read the XML configuration files and to
initialize the whole system.
Virtual System Loader

The “Virtual System Loader ” reads the XML Virtual System File Descriptor
and creates the data structure to represent the SCADA system. The XML
file is written by the IDS administrator following the SSML language rules
(See Section 5.2) and it describes the architecture of the real system. The
113
IDS administrator can write the XML file manually or using an IDS tool
called “Critical Infrastructure Creator ”. The structure of the XML Virtual
System File Descriptor is described by the following XML Schema:
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="infrastructure">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element name="master" type="masterType"/>
<xsd:element name="plc" type="plcType"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="masterType">
<xsd:attribute name="address" type="xsd:string"/>
<xsd:attribute name="port" type="xsd:unsignedInt"/>
</xsd:complexType>
<xsd:complexType name="plcType">
<xsd:attribute name="address" type="xsd:string"/>
<xsd:attribute name="port" type="xsd:unsignedInt"/>
<xsd:attribute name="id" type="xsd:unsignedByte"/>
<xsd:sequence>
<xsd:element name="discrete inputs" type="coilType"/>
<xsd:element name="coils" type="coilType"/>
<xsd:element name="input registers" type="regType"/>
<xsd:element name="holding registers" type="regType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="regType">
<xsd:attribute name="numbers" type="xsd:unsignedShort"/>
<xsd:attribute name="def value" type="xsd:unsignedShort"/>
</xsd:complexType>
<xsd:complexType name="coilType">
<xsd:attribute name="numbers" type="xsd:unsignedShort"/>
<xsd:attribute name="def value" type="xsd:boolean"/>
</xsd:complexType>
</xsd:schema>
The XML Schema contains a root node called “infrastructure”. The root
node contains a sequence of sub-nodes, each sub-node could be a “master”
or a “plc” node. A “master node” has two attributes, address and port, while
a “plc node” has address, port, id and four child nodes, i.e. discrete inputs,
coils, input registers and holding registers. In order to better understand,
let’s consider the example in Figure 7.2.
Master
Address: 10.0.0.254
Port: 502
Address: 10.0.0.2
Port: 502
Port: 502 Port: 502
ID: 2
ID: 1 ID: 3
PLC 1 PLC 2 PLC 3
DI 100 DI 200 DI 300

CO 100 CO 200 CO 300
IR 100 IR 200 IR 300
HR 100 HR 200 HR 300
Figure 7.2: MODBUS SCADA System Example
The XML Virtual System File Descriptor for such scenario is the following:
<infrastructure>
<master address="10.0.0.254" port="502" />
<discrete inputs numbers="100" def value="false" />
...
<holding registers numbers="100" def value="0"/>
</plc>
...
<holding registers numbers="200" def value="0" />
</plc>
...
<holding registers numbers="300" def value="0" />
</plc>
</infrastructure>
The “Virtual System Loader ” is an XML parser, which takes in input an

XML file and creates the data structure which represents the “Virtual System
Image”.
115
For Example the system presented above generates the following data
structure (Figure 7.3).
Master
-address : string = 10.0.0.254
-port : int = 502
PLC 1 PLC 2 PLC 3

-port : int = 502 -port : int = 502 -port : int = 502
-id : byte = 1 -id : byte = 2 -id : byte = 3
-discrete inputs : bool [100] -discrete inputs : bool [200] -discrete inputs : bool [300]
-coils : bool [100] -coils : bool [200] -coils : bool [300]
-holding registers : short [100] -holding registers : short [200] -holding registers : short [300]
-exception status coils : bool [8] -exception status coils : bool [8] -exception status coils : bool [8]
-diagnostic register : short -diagnostic register : short -diagnostic register : short
-counters : short [9] -counters : short [9] -counters : short [9]
Figure 7.3: SVI Stored in IDS Memory
The previous XML Virtual System File Descriptor generates a Virtual

System with one “master object” and three “plc objects”. The master class
has only two attributes: address and port, while the plc class has address,
port, id and four arrays to store the values of discrete inputs, coils, input
registers and holding registers. Moreover the plc class contains arrays with
pre-fixed size for exception status coils, counters and the diagnostic register
attribute.
Critical State Rule Loader

The “Critical State Rule Loader ” reads the Critical State Rules File and
creates the data structure to store the rules in IDS memory. As specified in
Chapter 5 a critical state rule is a boolean expression such as:
IF (P LC[10.0.0.2].CO[1] == 0)T HEN ALERT
The data structure used to represent boolean expression in memory is a sort

of “Binary Decision Tree (BDT)”. In such kind of BDT there are two types
of nodes:
• Boolean Operator Node: it represents a boolean operator such as

AND, OR, NOT.
• Condition Node: it represents a condition like “PLC[10.0.0.2].CO[1]

== 0” expressed whit the CSRL (See Section 5.3).
In order to better understand the BDT data structure, let’s consider the
following condition:
IF ((P LC[10.0.0.1].HR[1] > 70 OR P LC[10.0.0.1].HR[2] < 20)AN D
(P LC[10.0.0.2].CO[0] = 0 OR P LC[10.0.0.2].CO[1] = 1))T HEN ALERT

The figure 7.4 shows such boolean expression and the corresponding “Binary
Decision Tree (BDT)”.
IF ( ( PLC[10.0.0.1].HR[1] > 70 OR PLC[10.0.0.1].HR[2] < 20 ) AND
( PLC[10.0.0.2].CO[0] = 0 OR NOT PLC[10.0.0.2].CO[1] = 1 ) ) THEN ALERT
AND
OR OR
NOT
PLC[10.0.0.1].HR[1] > 70 PLC[10.0.0.1].HR[2] < 20 PLC[10.0.0.2].CO[0] = 0
PLC[10.0.0.2].CO[1] = 1
Figure 7.4: A CSRL condition and its BDT representation
The data structure is a binary tree in which the internal nodes are only
“Boolean Operator Node” and the leaves are only “Condition Node”.
117
The UML diagram in Figure 7.5 shows the classes involved in the “Binary
Decision Tree (BDT)” implementation.
Figure 7.5: The “Binary Decision Tree (BDT)” data structure UML diagram
BoolNode: this interface represents a general description of a tree node with

a left and a right child and two methods: “addChild” to add a child to the
node and “eval” for the evaluation of the node, i.e. it returns the boolean
value of the node (true or false). Each node in the tree has to implement the
interface “Bool Node”.
AbstractBoolNode: this abstract class contains fields, properties and meth-

ods common to each kind of node. For example every node has a left and
right child and the methods “addChild” and “ToString” are common method
for any type of node.
AndBoolNode: this class represent the logic operator AND. The most im-
portant method in this class is the “eval” for the evaluation of the and node.
The pseudo-code of such method is:

bool eval()
{
bool v1 = left.eval();
if (!v1)
return false;
else
{
bool v2 = right.eval();
if (!v2)
return false;
else
return true;
}
}
The method recursively calls the eval function on the left child. If the value
returned by the left child is false, is useless to check the right child and the
function return false. If the value returned by the left child is true, the method
recursively calls the eval function on the right child. If the value returned is
false the method return false, otherwise the method return true.
OrBoolNode: this class represent the logic operator OR. The “eval” method
is similar to the AndBoolNode eval, but with the opposite optimization logic:
if the left child eval method returns true, than the right child is not evaluated.
NotBoolNode: this class represent the logic operator NOT. The “eval”
method is very simple, in fact the pseudo-code is:
bool eval()
{
if (left!=null)
return !left.eval();
else
throw new Exception();
}
ConditionBoolNode: this class represent a condition expressed with the
CSRL. The eval method is completely different:
bool eval()
{
bool ret;
switch (condition type)
{
case equal:
ret = (reg val == comp val);
119
break;
case lt:
ret = (reg val < comp val);
break;
case gt:
ret = (reg val > comp val);
break;
case lte:
ret = (reg val <= comp val);
break;
case gte:
ret = (reg val >= comp val);
break;
case neq:
ret = (reg val != comp val);
break;
}
return ret;
}
The method, depending on the type of condition, performs a comparison

rather than another one between the value in the registry and the value to
be compared.
The “Binary Decision Tree (BDT)” data structure, which we have already
presented is used to store in memory each rule in the Critical State Rules
File. The “Critical State Rule Loader ” performs such task in two steps:
BoolToken [] tokens = tokenizeString(expression);

BoolNode expression tree = initTree(tokens);
First of all, the loader divides the boolean expression in an array of BoolTo-
ken, then it creates the “Binary Decision Tree (BDT)”. The method “tok-
enizeString” works as shown in Figure 7.6.
IF ( ( PLC[10.0.0.1].HR[1] > 70 OR PLC[10.0.0.1].HR[2] < 20 ) AND
( PLC[10.0.0.2].CO[0] = 0 OR NOT PLC[10.0.0.2].CO[1] = 1 ) ) THEN ALERT
0 LPAREN (
1 VAR PLC[10.0.0.1].HR[1] > 70
2 OR OR
3 VAR PLC[10.0.0.1].HR[2] < 20
4 RPAREN )
5 AND AND
6 LPAREN (
7 VAR PLC[10.0.0.2].CO[0] = 0
8 OR OR
9 NOT NOT
10 VAR PLC[10.0.0.2].CO[1] = 1
11 RPAREN )
Figure 7.6: tokenizeString
Each “BoolToken” has a “BoolType” and a content, the types are: OR,
AND, NOT, VAR, LPAREN, RPAREN. The second step of the “Critical
State Rule Loader ” is performed by the method initTree which takes the
tokenized boolean expression as parameter and creates the BDT.
BoolNode initTree(BoolToken[] expression)

{
BoolNode left = null;
BoolNode right = null;
BoolNode op = null;
int i = 0;
left = createNode(expression, inout i);

op = createOperatorNode(expression, inout i);
right = createNode(expression, inout i);
op.addChild(left);
op.addChild(right);
return op;
}
121
The function is really simple, it creates three BoolNodes: left node, operator
and right node then it builds the tree: the father node is the operator and the
two children nodes are the left and the right node. The method is difficult
to understand without showing the function called “createNode”, its pseudo-
code is the following.
BoolNode createNode(BoolToken[] expression, inout int i)

{
BoolNode node;
BoolNode not;
BoolToken[] sub expression;
if (expression[i].getType() == BoolTypes.LPAREN)
{
sub expression = findSubExpression(expression, i);
node = initTree(sub expression);
i+= (sub expression.Length + 2);
}
else if (expression[i].getType() == BoolTypes.VAR)
{
node = new ConditionBoolNode(expression[i++]);
}
else if (expression[i].getType() == BoolTypes.NOT)
{
not = new NotBoolNode();
i++;
node = createNode(expression, inout i);
not.addChild(node);
node = not;
}
else
return node;
}
The method “createNode” is called by the “initTree” to analyze the left or

the right part of a boolean expression. For example take into consideration
the left part; such part of a boolean expression could begin with:
• A left parenthesis: it means that the left part is another sub expres-
sion, therefore the method find the sub expression with the function
“findSubExpression” and creates the node recursively calling the func-
tion “initTree”.
• A variable or condition: it means a condition expressed in the CSRL.
In this case the method creates a new “ConditionBoolNode”.
• A not operator followed by a boolean expression: in this case

the method creates a new “NotBoolNode”, then creates the node re-
cursively calling the function “createNode”, then add such node to the
“NotBoolNode”.
The other method called “createOperatorNode” simply creates an “And-

BoolNode” or an “OrBoolNode” depending on the BoolType of the operator.
The pseudo-code is the following.
BoolNode createOperatorNode(BoolToken[] expression, inout int i)

{
BoolNode op;
if (expression[i].getType() == BoolTypes.AND)
{
op = new AndBoolNode();
i++;
}
else if (expression[i].getType() == BoolTypes.OR)
{
op = new OrBoolNode();
i++;
}
else
return op;
}
123
The figure 7.7 shows how the “initTree” function works to build the “Bi-
nary Decision Tree (BDT)”, which represents the rule shown in the beginning
of this section.
0 LPAREN (
1 VAR PLC[10.0.0.1].HR[1] > 70
2 OR OR
initTree(expression); 3 VAR PLC[10.0.0.1].HR[2] < 20
i = 0; 4 RPAREN )
5 AND AND
if (expression[i].getType() == BoolTypes.LPAREN) 6 LPAREN (
{ 7 VAR PLC[10.0.0.2].CO[0] = 0
sub_expression = findSubExpression(expression, i);
// sub_expression = "PLC[10.0.0.1].HR[1] > 70 8 OR OR
// OR PLC[10.0.0.1].HR[2] < 20"
9 NOT NOT
node = initTree(sub_expression);
10 VAR PLC[10.0.0.2].CO[1] = 1
initTree(expression); 11 RPAREN )
i = 0;
else if (expression[i].getType() == BoolTypes.VAR)

{
node = new ConditionBoolNode(expression[i++]); AND
//node = PLC[10.0.0.1].HR[1] > 70 , i = 1
}
return node;
OR
//op = "OR" , i = 2
//right = "PLC[10.0.0.1].HR[2] < 20" i = 3 PLC[10.0.0.1].HR[1] > 70 PLC[10.0.0.1].HR[2] < 20 OR
op .addChild( left );
op .addChild( right );
return op;
i+= (sub_expression.Length + 2);

//i = 5
}
return node; NOT
PLC[10.0.0.2].CO[0] = 0
//op = "AND" , i = 6
= createNode(expression, inout i);
right
//right = "PLC[10.0.0.2].CO[0] = 0 OR NOT PLC[10.0.0.2].CO[1] =
1
PLC[10.0.0.2].CO[1] = 1
op .addChild( left );
op .addChild( right );
Figure 7.7: “initTree” Function Example
The “initTree” function we have presented is enough to represent boolean

expression with binary operator. The CSRL is also able to represent boolean
expression by using n-ary operators. For example :
IF (P LC[10.0.0.1 : 502].HR[1] > 70 AN D (P LC[10.0.0.1 : 502].HR[2] < 20
AN D P LC[10.0.0.2 : 502].CO[0] == 0)T HEN ALERT

This rule contain a condition with a triple AND operator. The previous
“initTree” function is not enough to analyze this expression. The modified
version of the function is shown in the following pseudo-code.
BoolNode initTreeMod(BoolToken[] expression, BoolNode left)

{
BoolNode right = null;
BoolNode op = null;
int i = 0;
if(left== null)

op.addChild(left);
op.addChild(right);
if (i < expression.Length)
{
sub expression = cutSubExpression(expression, i);
op = initTreeMod(sub expression, op);
}
return op;
}
The “initTreeMod” function has one parameter more than the previous one.
The function body is the same but, if the expression contains a n-ary operator
the last “if” becomes true and the rest of the expression becomes the new sub
expression and the analyzed expression part becomes the left part in the new
“initTreeMod” call. The call is in fact “initTreeMod(sub expression, op)”
than in such call the left parameter is not null and the new sub expression
will be added to previous one.
7.1 Scada Protocol Sensor (SPS)

The SCADA Protocol Sensor (SPS) is basically the equivalent of a normal
network IDS sensor, with the advantage of being able to directly support
commonly used SCADA protocols.
Network Capture Module

It receives the mirror of all the traffic to and from the field network directly
from the SPAN port of the field network switch. The traffic capture is pre-
7.1. SCADA PROTOCOL SENSOR (SPS) 125
formed by using the WinPcap [9] library. It allows applications to capture

network packets bypassing the protocol stack.
Protocol Discover
The packets captured by the “Network Capture Module” are analyzed by the
“Protocol Discover” which is able to analyze the application level payload
of the packet and to recognize if it is a SCADA packet (only MODBUS and
DNP are now supported by the IDS) or another packet. If the packet is
a SCADA protocol one, the protocol discover will sent it to the “Protocol
Builder” otherwise it will be discarded.
Protocol Builder
The “Protocol Builder” receives only the SCADA traffic from the “Protocol
Discover” and analyzes each packets in order to recognize the packet type
and to store the packet information in a the proper object. As we claimed in
the MODBUS section 4.1, there are two kind of MODBUS packets: requests
and responses.
int : 32-bit number Message

short : 16-bit number
byte : 8-bit number -transactionID : short
-protocol : short
-length : short
-id : byte
-function_code : byte
-sub_function_code : short
-starting_address : short
-quantity : short
-short_values : [ ] short
-bool_values : [ ] bool
+buildMessage() : [ ] byte
+parseMessage(in frame : [ ] byte)
Message::Request Request::Response
+buildMessage() : [ ] byte +buildMessage() : [ ] byte

+parseMessage(in frame : [ ] byte) +parseMessage(in frame : [ ] byte)
Figure 7.8: MODBUS Messages objects
The Message class contains all the attributes of a MODBUS message,

which are common in request and response. The only difference between the
two classes Request and Responses are the two methods “buildMessage” and
“parseMessage” because each request and response has a different structure.
There are also different constructors for every kind of request and response:
for example the “Read Coils” request is built with the constructor:
public Request(short tID, short protocol, short length, byte id,
byte function code, short starting address, short quantity)
While the “Read Exception Status Coils” request uses the constructor:
public Request(short tID, short protocol, short length, byte id,
byte function code, short sub function code)
When the “Protocol Builder” receives a MODBUS packet, it checks if the

message is a request or a response, then it checks the function code to parse
the message in the correct way. It recognizes the type of message using the
TCP source address and the information stored in the System Virtual Image
(SVI):
• If the TCP source address is the address of a Master Station (according

to the SVI information) then the message is a request.
• If the TCP source address is the address of a Slave Station (according

to the SVI information) then the message is a response.
Moreover, the “Protocol Builder” checks the message function code and parse
the Request or the Response in the right way.
7.2 System Virtual Image (SVI)

The System Virtual Image (SVI) contains the representation of the state of
the system under analysis. We have already explained in Section 6.3 how the
SVI is build and how it works ,therefore we will not enter into details.
Real System Synchronizer
The SVI is updated by periodically querying the real system. The “Real
System Synchronizer” contains a SCADA Master simulator which is able to
forge MODBUS requests and to parse the responses, then to update the SVI
with the information contained in the responses. In the XML Virtual System
File Descriptor is possible to specify, for each PLC the update time, e.g.
each five seconds. The “Real System Synchronizer” queries the PLC every 5
seconds, asking all the discrete inputs, coils, input registers, holding register,
diagnostic register, exception status coils and counters values. Each query
is optimized to store much information as possible. For example, if a PLC
has 4000 coils, the “Real System Synchronizer” will perform two request: the
first for the coils from 0 to 2000 (maximum value allowed for a “Read Coils”
request according to the modbus specification [1]) and the second from 2000
to 4000.
7.2. SYSTEM VIRTUAL IMAGE (SVI) 127
Update System Manager

The “Update System Manager” is composed by two buffer and three thread.
There are a Request and a Response buffers and the following three thread:
• Add Packet Thread: it receives the request or response packets from

the “Protocol Builder” and put them into the right buffer (request or
response buffer).
• System Update and Thread: it extracts the first request in the

“RequestBuffer ” and tries to find the corresponding response in the
“ResponseBuffer ”; if it has found the response then it updates the
System Virtual Image (SVI) and checks if the system is in a critical
state.
• Check Critical States Thread: it checks periodically if the SVI

match with one or more critical states in the Critical State Rules DB
(CSRDB).
The “RequestBuffer” is a simple list of request objects, while the “Respon-

seBuffer” is an hash table that maps the response object to associated keys.
The keys used to uniquely identify a response object are strings composed
by:
key = source address + ":" + source port + ":" + transaction id;
For example a response key could be:

key = "10.0.0.1:502:99";
The transaction id is not enough to uniquely identify a response object be-

cause the IDS captures the traffic from different PLCs, so it is possible that
two PLCs are using the same transaction id at the same time. The “Add
Packet Thread ” is in charge only to puts the incoming packets in the right
buffer so it is really simple, but the “System Update” and the “Check Critical
States” threads need a detailed explanation;.
For example take into consideration the scenario in Figure 7.9
Requests Buffer Responses Buffer

List<Request> requests; HashTable<string, Response> responses;
Request Response
10.0.0.1:502:3 10.0.0.1:502:3
Request Response
10.0.0.1:502:2 10.0.0.1:502:2
Request Response
10.0.0.1:502:1 10.0.0.1:502:1
request = requests.get();
key = Request.getId();
if (responses.ContainsKey(key))
{
response = responses[key];
requests.delete(request);
responses.delete(response);
}
Figure 7.9: Request/Response Buffers
In the example above, when the “System Update Thread ” takes control
there are three packets in the RequestBuffer and three in the ResponseBuffer.
The thread gets the first packet from the RequestBuffer and reads the key
calling the method getId(). Such method return the following key:
key = dest address + ":" + dest port + ":" + transaction id;
The key is build in a different way than in the ResponseBuffer because the
destination address in a request packet is equal to the source address in
the corresponding response packet. When the “System Update Thread ” has
obtained the key it checks if the ResponseBuffer contains such key. If it is
true the thread gets the proper response and delete the two messages form
their respective buffers.
Moreover the “System Update Thread ” has to find and update the MODBUS
slave or PLC involved in the request/response transaction. The list of the
MODBUS slaves is stored again ad an hash table. The keys used to uniquely
identify a slave object are strings composed by:
key = slave address + ":" + slave port + ":" + slave id;
The “System Update Thread ” finds and updates the slave object as shown in
the example in Figure 7.10
7.2. SYSTEM VIRTUAL IMAGE (SVI) 129
Slaves
HashTable<string, Slave> slaves;
Slave
slave_id = request.dest_address + ":" + 10.0.0.1:502:1
request.dest_port + request.id;
if (slaves.ContainsKey(slave_id)) Slave
{ 10.0.0.2:502:2
slave = slaves[slave_id];
updateSVI(request, response, slave); Slave
} 10.0.0.3:502:3
Figure 7.10: Slave Update
The “System Update Thread ” builds the key of the slave involved in the
request/response transaction using the following information contained in
the request packet:
key = request.dest address + ":" + request.dest port + request.id;
When the “System Update Thread ” has built the slave key it checks if the
Slave hash table contains such key. If it is true the thread gets the proper slave
object and executes the updateSVI and the checkCriticalStates methods. The
updateSVI method uses the information in the request/response objects to
update the SVI. A part of the pseudo-code of this methods is shown below.
void updateSVI(Request req, Response res, ModbusSlave slave)

{
switch (res.function code)
{
case read coils:
short st = req.starting address;
for (int i = 0; i < res.bool values.Length; i++)
slave.coil[i + st] = res.bool values[i];
break;
case read discrete inputs:
...
break;
...
}
}
The method reads the function code contained in the response object and
executes the correct part of code. For example if the function code is “01 Read
Coils” the method reads the starting address and the quantity of coils from
the request and the values to updates from the response then perform the
proper update into the target slave. The “Check Critical States Thread ” is a
part of the Analyzer Module, therefore it will be described in the following.
7.3 Analyzer
As discussed in Section 6.2, the “Analyzer ” performs the “Signature Based
Detection” and the “State Based Detection”.
Basic Analyzer
The ‘‘Basic Analyzer ” is very similar to a normal NIDS analyzer. It receives
in input the captured packets, then it analyzes the packet and if it match
with a signature in the Single packet rules DB (SPDB) it raises an alert.
Critical State Analyzer

The “Crtical State Analyzer ” checks periodically the Virtual System, if the
SVI status match with a “Critical State” contained in the Critical State
Rules DB (CSRDB) it raises an alert. The “Crtical State Analyzer ” is an
object which contains an array of rules. Each element in this array is a
reference to the root node of a “Binary Decision Tree (BDT)”. The most
important method in the “Crtical State Analyzer ” is the checkCriticalStates
which control if SVI status matches with the critical state rules. The pseudo
code of such method is really simple because it uses the recursive function
“eval ” that we have already explained in section 7.0.1.
void checkCriticalStates()
{
for (int i = 0; i < rules.Count; i++)
if (rules[i].eval())
raiseAlert();
}
The method simply calls the eval function on each rule in the rules array. If
the eval function returns true it means that the system is in a critical state,
so the method raises an alert.
Chapter 8
Experiments and tests
In order to verify the efficiency and validity of our SCADA IDS, we have
performed several comparative intrusion detection tests in a protected en-
vironment configured in our laboratory. These tests were developed in col-
laboration with a power company, which entirely reproduces the network,
hardware and software environment of the control systems of a typical power
plant. We have tested the main modules described in the section 4 in order
to show the performance and the delay introduced by any single feature of
our IDS:
1. The Packet Capturing
2. Single Signature analysis
3. Virtual System Update
4. Critical State Rules Analyzer
8.0.1 Packet Capturing Test

As explained in Section 7.2, when a packet is captured, the IDS main thread
put it into a buffer, then another thread will extract the packet from the
buffer and will analyze it. Using buffer and threads makes the packet loss
difficult. Such loss would be possible only in case of network congestion, but
it is improbable in a SCADA network. We test the performance of Packet
Capturing by sending a high number of packets with a very high bit rate.
131
132 CHAPTER 8. EXPERIMENTS AND TESTS
The test scenario is shown in Figure 8.1.
IDS
Sensor
Switch
Request
Response
Outstation
Master
Figure 8.1: Test Scenario
In Figure 8.1 there are 3 entities: a Master Station, a Slave Station and the
IDS:
• The Master Station sends to the slave a big Request packet of 260 bytes
(maximum value allowed according to the MODBUS specification [1]).
• The Slave Station responds with a Big Response packet of 260 byte.
• The IDS captures the request and response packet.
Measurement: packet loss.

The request/response transaction is repeated 100.000 times in order to gen-
erate a big amount of network traffic. Table 8.1 shows the results.
Request Sent 100.000

Response Sent 100.000
Size Request 315 byte *
Size Response 315 byte *
Request rate 1 request sent each 1 ms
Rate 615,2 kbytes/s
Packet Loss 0
Table 8.1: Packet Capturing Performance Test

*Packet size is 260 + 20 (head TCP) + 20 (head IP) + 15 (head Ethernet) = 315 bytes
8.1. SIGNATURE-BASED PERFORMANCE TEST 133
Such scenario, with a burst of 100.000 consecutively sent packets with a

rate of 615,2 kbytes/s, is practically impossible in a real SCADA network,
so the IDS is very strong and reliable, because it has lost 0 packets out of
200.000. For the IDS it would be very difficult to lose a packet in a real
SCADA Infrastructure.
8.1 Signature-Based Performance Test

The signature-based part of the IDS performs the following steps using two
threads:
• The first thread captures packets and put them into a message buffer.
• The second thread extract packets from the message buffer and checks
if they are malformed of illegal according to the rules in the SPDB.
The Signature-Based Analyzer performances depend on the number of rules.

In order to test the rule check performance we made the following experiment:
the Master Station sends a generic Request and the Slave Station responds
with the appropriate Response, the IDS captures the messages and checks
if they are licit, according to a rules file which contains n-rules. We made
the test with 6 different n-values equals to 10, 50, 100, 500, 1000, 2000. The
results are shown in Table 8.2.
Num Rules Average Time in ms (on 1000 pkts)

10 0.0412618 ms
50 0.1495607 ms
100 0.2486327 ms
500 1.1152725 ms
1000 2.1427072 ms
2000 4.1623632 ms
Table 8.2: Signature-Based Performance Test Results

The elapsed time increases with the number of rules and the growth is linear
as shown in Graph 8.2.
rules time
4.5
1 0.02
10 0.04
4 50 0.15
100 0.25
500 1.12
1000
3.5 2.14
2000 4.16
2.5
Time in ms
1.5
0.5
0
0 500 1000 1500 2000 2500
Number of rules
Figure 8.2: Signature-Based Performance Test Graph
8.2 State-Based Performance Test

The state-based part of the IDS has the greatest impact on the real-time
performance of our IDS, therefore it needs a more accurate control. For this
reason we made various tests, one for each step necessary to check the critical
states of the system. The steps performed by the IDS to analyze a packet,
update the System Image and check the Critical States are the following:
1. The IDS captures a request packet and puts it into a requests buffer.
2. The IDS captures a response packet and puts it into a responses buffer.
3. The IDS analyzes the request/response couple of messages.
4. The IDS updates the System Virtual Image (SVI) with the information
in the request/response messages.
5. The IDS checks if the system is now in a critical state according to the
rules in the Critical State Rules Data Base (CSRDB).
8.3. VIRTUAL SYSTEM UPDATE PERFORMANCE TEST 135
These steps are performed by using three thread in order to enhance the
performance. The thread’s tasks are:
• The first thread is the main one and it is in charge only to capture
packets and put them into the right buffer (request or response buffer).
This action takes a short time, so the packet loss is really difficult.
• The second thread is in charge to find the request/response matches in

the two buffers and to update the Virtual System.
• The third thread is in charge to check if the system is actually in a

Critical State according to the rules in the CSRDB.
By using of these three separate threads, the slow tasks (like the Virtual
System Update and the Critical States rules check) don’t have a great impact
on the IDS performance, because they are run simultaneously with the other
ones. Such division makes the testing part longer, because we need to test
the Virtual System update and the Critical State rules analyzer performance
in order to have a complete performance test.
8.3 Virtual System Update Performance Test

The IDS updates the System Virtual Image (SVI) in two steps:
1. it finds the PLC involved by the content of the packet.
2. it updates the Virtual Object which represents the PLC.
The first step is not relevant for the performance of the IDS, because the list
of PLC is implemented with a Hash Table, so the time to find a PLC is the
same with a table of 1 or 1000 PLCs. This time is around 0,0042 ms.
The second step takes longer, especially if it involves several registers or coils.
We made a speed tests for the PLC update in the worst case. The worst case
happened when the IDS has been received a packet with the Function Code
01 Read Coils and the Quantity of Coils to read equals to 2000 (maximum
value allowed according to the MODBUS specification [1]). It means that the
IDS has to update the values of 2000 coils. The test is the following:
• The Master Station sends a Request with the command “Read n-coils”.
• The Slave Station responds with a Response which contains the n-

values.
• The IDS captures the request/response transaction and updates the

n-values in the Virtual PLC.
Measurement: the time spent by the IDS to update the n-values in the
Virtual PLC.
The request/response transaction is repeated 1000 times in order to obtain
an average PLC update time.
We made the test with 6 different n-values equal to 1, 50, 100, 500, 1000,
2000. Table 8.3 shows the results.
Num Coils Average Time in ms (on 1000 pkts)

1 0,0012168 ms
50 0,0030485 ms
100 0,0044824 ms
500 0,0173109 ms
1000 0,0334344 ms
2000 0,0624535 ms
Table 8.3: Virtual System Update Performance Test

8.3. VIRTUAL SYSTEM UPDATE PERFORMANCE TEST 137
The elapsed time increases with the number of updated coils and the growth
is linear as shown in Graph 8.3.
0.07
0.06
0.05
0.04
Time in ms
0.03
0.02
0.01
0
0 500 1000 1500 2000 2500
Coils Number
Figure 8.3: Virtual System Update Performance Test
The reason for this linear growth is obviously guessed watching the “up-
dateSVI ” method code (See Section 7.2):
void updateSVI(Request req, Response res, ModbusSlave slave)

{
switch (res.function code)
{
case read coils:
short st = req.starting address;
for (int i = 0; i < res.bool values.Length; i++)
slave.coil[i + st] = res.bool values[i];
break;
case read discrete inputs: ...
break; ...
}
}
The method body is composed only by a “switch” and a “for loop”, so it is

obviously a linear function.
8.4 Critical State Rules Analyzer Performance

Test
The Critical State Rules Analyzer performances depend on two factors:
• The size of each rule (number of conditions).
• The number of rules.
For the first factor (rule size) we made the following speed test: the Master
Station sends a generic Request and the Slave Station responds with the
appropriate Response, the IDS captures the request/response transaction and
checks if the Virtual System is entering in a Critical State, according to a rules
file which contains only one rule with n-conditions. The request/response
transaction is repeated 1000 times in order to obtain an average rules checking
time. We made the test with 10 different n-conditions equal to 2, 4, 8, 16,
32, 64, 128, 256, 512, 1024. Table 8.4 shows the results.
Num Conditions Average Time in ms (on 1000 pkts)

2 0,0204746 ms
4 0,0217611 ms
8 0,0244149 ms
16 0,0301169 ms
32 0,0370071 ms
64 0,0550301 ms
128 0,1206957 ms
256 0,2127598 ms
512 0,4226185 ms
1024 1,0706136 ms
Table 8.4: Critical State Rule Analyzer Performance Test 1

8.4. CRITICAL STATE RULES ANALYZER PERFORMANCE TEST139
The elapsed time increases in a linear fashion with the number of conditions
as shown Graph 8.4.
1.2
0.8
Time in ms
0.6
0.4
0.2
0
0 200 400 600 800 1000 1200
Numbers of Conditions
Figure 8.4: Critical State Rule Analyzer Performance Test 1
It is important to note that the time elapsed is under one millisecond with
a number of conditions < 512. This is a very good result because in a real
rules DB, it is really difficult to have rules with 512 conditions, therefore the
performance of the “Binary Decision Tree (BDT)” data structure are really
high.
For the second factor (number of rules) we made the same test as the previous
one, but in this case we used n-rules, each one composed by two conditions.
We made the test with 6 different n-values equals to 10, 50, 100, 500, 1000,
2000.
The results are shown in Table 8.5.
Num Rules Average Time in ms (on 1000 pkts)

10 0,1123061 ms
50 0,5153591 ms
100 1,0248889 ms
500 2,6010271 ms
1000 5,0175991 ms
2000 9,9285867 ms
Table 8.5: Critical State Rule Analyzer Performance Test 2
The elapsed time increases with the number of rules and the growth is
linear. The Graph 8.5 shows the results.
12
1.2
10
1
8
0.8
ms
in ms
6
0.6
Time in
Time
0.4
4
0.2
2
0
0
0
0 200500 400 1000 600 1500 800 20001000 1200
2500
Numbers
Numberof Conditions
of rules
Figure 8.5: Critical State Rule Analyzer Performance Test 2
The last test shows that the bottle neck of the IDS is the rules analyzer,
because it takes the longest time in the real time IDS control. However, the
time elapsed is under ten millisecond with a number of rules < 2000, therefore
the performance are good also with a high numbers of rules.
Chapter 9
Conclusions
In recent years, “critical infrastructure” has begun utilizing public networks,

which exposed critical installations to new sources of potential threats. There
is an urgent need for a new generation of security techniques tailored for
such systems. In this thesis we have presented a first prototype of IDS specif-
ically designed for SCADA architecture. We called “State-Based ” such new
approach to Intrusion Detection in industrial settings. The “State-Based Ap-
proach” is focused on the state of the system instead of working on techniques
based on packet signatures. This approach relies on the assumption that the
intention of an attacker is to put the target system into a critical state, there-
fore by looking at the system evolution and by detecting the occurrence of
critical states, it would be possible to automatically detect an attack. Us-
ing this approach, the focus is primarily on known variables (the system
behavior), rather than on unknown variables (the attacker behavior), which
eliminates the risks of false positives and detecting also unknown attacks. In
order to achieve this goal, we have formally defined new languages allowing
description of “SCADA systems” and “process critical states”. In addition
we have defined an event correlation mechanism based on the concept of vir-
tual system monitor, allowing the IDS to correlate licit SCADA commands
by keeping track of the evolution of the real system under control. Moreover,
we have developed an IDS prototype called “State Based Intrusion Detec-
tion System” that implements the techniques that we designed. Our IDS is
able to detect the same single packet based attacks of a general NIDS, while
completely overpass normal NIDS capabilities in detecting complex attack
scenarios based on licit packet chains. Finally, we presented the experimental
results. We have performed several tests on each IDS operation: packet cap-
turing, virtual system update and rules checking. The packet capturing test
shows how is difficult to have packet loss. The virtual system update test is
optimal because the IDS is able to keep updated a complex SVI in less than
141
142 CHAPTER 9. CONCLUSIONS
one millisecond. The rule checking is performed in a linear fashion and the
time elapsed is good also for a large rule database. The IDS performance are
important because SCADA systems are used to real-time processes monitor-
ing, therefore there are strict time constraints to respect. In conclusion the
developed IDS is able to detect each kind of described SCADA attacks and
it is enough fast to be used in a real time environment. As future work, we
plan to test this approach on a real production system. Moreover, we plan
to introduce into the approach the capability of “critical state prediction”,
able to anticipate the evolution of the system into one of the known critical
states on the basis of what the sensors observe.
Bibliography
[1] Modbus-IDA, Modbus Application Protocol Specification v1.1b,

http://www.modbus.org, December 28, 2006
[2] Modbus-IDA, MODBUS Messaging on TCP/IP Implementation Guide

V1.0b, http://www.modbus.org, October 24, 2006
[3] MODICON Inc. Industrial Automation Systems, Modicon Modbus Pro-

tocol Refernce Guide PI-MBUS-300 Rev. J, June 1996
[4] K. Stouffer, J. Falco, K. Kent, “Guide to Supervisory Control and Data

Acquisition (SCADA) and Industrial Control Systems Security”, NIST,
September 2006
[5] N. Cai, J. Wang, X. Yu, “SCADA System Security: Complexity, His-

tory and New Developments”, INDIN (IEEE International Conference
on Industrial Informatics), July 2008
[6] I. Nai Fovino, M. Masera, R. Leszczyna, ICT Security Assessment of a

Power Plant, a Case Study, in Proceeding of the Second Int. Conference
on Critical Infrastructure Protection, Arlington, USA, March 2008
[7] I. Nai Fovino, A. Carcano, M. Masera and T. de Lacheze Murel, Mod-

bus/DNP3 State-based Intrusion Detection System, in Proceeding of
ANIA 2010 - the IEEE 24th International Conference on Advanced In-
formation Networking and Application, Perth, Australia, April 2010
[8] Scada Malware a proof of concept.
[9] www.winpcap.org
[10] The Snort Project, SNORT Users Manual 2.8.5, http://www.snort.org,

October 22, 2009
[11] Daniel B. Cid, OSSEC Manual 2.3, http://www.ossec.net, November

23, 2009
143
144 BIBLIOGRAPHY
[12] A. A. Creery, E. J. Byres, Industrial Cybersecurity for power system

and SCADA networks, IEE Industry Apllication Magazine, July-August
2007.
[13] R. Chandia, J. Gonzalez, T. Kilpatrick, M. Papa and S. Shenoi, Security

Strategies for Scada Networks, in Proceeding of the First Int. Conference
on Critical Infrastructure Protection, Hanover, NH., USA, March 19 -
21, 2007.
[14] M. Majdalawieh, F. Parisi-Presicce, D. Wijesekera, Distributed Network

Protocol Security (DNPSec) security framework, in proceedings of the
21st Annual Computer Security Applications Conference, December 5-
9,2005, Tucson, Arizona.
[15] I. Nai Fovino, A. Carcano and M. Masera, Secure Modbus Protocol, a

proof of concept, in proceedings of the 3rd IFIP Int. Conf. on Critical
Infrastructure Protection, Hanover, NH., USA, 2009.
[16] J. H. C. S. Hong, S. Ho Ju, Y. H. Lim, B. S. Lee, D. H. Hyun, A

Security Mechanism for Automation Control in PLC-based Networks, in
proceedings of the ISPLC ’07. IEEE International Symposium on Power
Line Communications and Its Applications 26-28 March 2007, pp 466-
470, Pisa, Italy
[17] T. Mander, F. Nabhani, L. Wang, R. Cheung, Data Object Based Secu-

rity for DNP3 Over TCP/IP for Increased Utility Commercial Aspects
Security, in proceedings of the Power Engineering Society General Meet-
ing, 2007. IEEE 24-28 June 2007, pp 1-8, Tampa, FL, USA.
[18] I. Nai Fovino, A. Carcano, M. Masera, A secure and Survivable Archi-

tecture for SCADA Systems, in proceedings of The Second International
Conference on Dependability, DEPEND 2009, June 18-23, 2009 - Athen-
s/Vouliagmeni, Greece.
[19] D.E. Denning, An Intrusion-Detection Model, IEEE Trans. on Software

Eng. Feb. 1987, Vol. SE-13, Issue 2, pp. 222- 232, ISSN 0098-5589.
[20] http://www.digitalbond.com/index.php/research/ids-
signatures/modbus-tcp-ids-signatures/, April 9, 2009
[21] P.Gross, J. Parekh and G. Kaiser, “Secure Selecticast for collaborative

Intrusion Detection systems” in proceedings of the International Work-
shops on DEBS, 2004.
BIBLIOGRAPHY 145
[22] V. Yegneswaran, P. Barford and S. Jha, Global Intrusion Detection in the

Domino Overlay System, in proceedings of the 11th ANDSSS Conference
2004.
[23] P. Ning, Y. Cui, and D.S. Reeves, Constructing Attack Scenarios through
Correlation of Intrusion Alerts, in proceedings of the ACM Conference
on Computer and Communications Security, pages 245-254, Washington,
D.C., November 2002.
[24] F. Cuppens, A.Miege, Alert correlation in a cooperative intrusion detec-

tion framework, in proceedings of Security and Privacy 2002.
[25] T. Mander, F. Nabhani, L. Wang, R. Cheung, Data Object Based Secu-

rity for DNP3 Over TCP/IP for Increased Utility Commercial Aspects
Security, in proceedings of the Power Engineering Society General Meet-
ing, 2007. IEEE 24-28 June 2007, pp 1-8, Tampa, FL, USA.

Critical State Based Intrusion Detection

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Critical State Based Intrusion Detection

Uploaded by

Copyright:

Available Formats

Università degli Studi dell’Insubria

Critical State Based Intrusion

March 19, 2010

2 State of the art 7

3 SCADA system architecture 11

4 SCADA Protocols and vulnerabilities 21

5 State Based Approach 87

6 Critical State Based IDS Architecture 99

7 IDS Prototype Implementation 111

8 Experiments and tests 131

Industrial facilities and infrastructures such as chemical factories, oil refiner-

sible malicious intrusions or policy violations. In this thesis a ”State Based

State of the art

As discussed in the introduction, when SCADA networks were developed,

address some of the known security problems of such Master-slave control

• Unauthorized Modbus Users rules

• Modbus Protocol Errors rules

• Scanning detection rules

a centralized server in order to dispatch among the ID sensors information

SCADA system architecture

SCADA is an acronym for Supervisory Control and Data Acquisition. A

• Manufacturing: SCADA systems manage manufacturing, regulate in-

• Electric utilities: SCADA systems manage generation, transmission

• Mass transport: transport authorities use SCADA to regulate elec-

• Traffic signals: SCADA regulates traffic lights and controls traffic

• Chemical Industries: SCADA systems are used to regulate chemical

3.1 System Components

Operator Human Machine Interface (HMI)

Master Terminal Unit (MTU)

PLC PLC RTU RTU

Figure 3.1: SCADA System Components

• Operator: Human operator who monitors the SCADA system.

• Human machine Interface(HMI): the device which presents pro-

• Master Station or Master Terminal Unit (MTU): it presents

• Slave Station or Remote Terminal Unit (RTU): it gathers data

As showed in figure 3.1 a SCADA system spreads among two networks:

• Control Network: it contains all the RTU and Programmable Logic

• Process Network: it is composed of the master SCADA servers that

In the following we provide a description of each of these two network.

3.2 Control Network

• PLC and RTU: they are microprocessor controlled electronic devices

• Network switches: physical media used to send data to the MTU.

Thin Line: 0-24 V Electric Signal

Network Switch PLC

Figure 3.2: Control Network Data Flows

• Digital and Analogical Inputs(DI,AI): They receive data from the

• Digital and Analog Outputs(DO,AO): They receive data from the

• PLC CPU: It is involved in several data flows:

– Flow 2: The CPU sends commands to the Co-processor then re-

• PLC Co-processor: It is a computer processor used to supplement the

– Flow 2: The Co-processor receives commands from the CPU then

– Flow 5: The Co-processor sends commands (received from the

3.3 Process Network

Flow 5 Exchange Network

Flow 3 Flow 4 Flow 6

Process Network OPC Flow 4 Network

BUILDER Flow 4 Network

Figure 3.3: Process Network Data Flows

• SCADA Server: it provides the means by which an operator can

– Flow 1: The SCADA Server sends commands (or queries about

– Flow 4: The SCADA Server is subjected to the usual network

• OPC Server: An OPC Server is a protocol converter which receives

• HMI: as mentioned before, there is a ”client-server” data flow between