Critical State Based Intrusion Detection
Critical State Based Intrusion Detection
Critical State Based Intrusion Detection
Dipartimento di Informatica e
Comunicazione
Supervisors:
Author:
Alberto Trombetta
Michele Guglielmi
Igor Nai Fovino
1 Introduction 5
2
CONTENTS 3
9 Conclusions 141
Chapter 1
Introduction
5
6 CHAPTER 1. INTRODUCTION
7
8 CHAPTER 2. STATE OF THE ART
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:
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
• Water and sewage: state and municipal water utilities use SCADA
to monitor and regulate water flow, reservoir levels, and pipe pressure.
• 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.
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.
Control Network
Fan Valve
Pump
Field Network
The figure 3.2 shows the Control Network components and data flows.
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
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.
– 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 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.
Flow 1 SCADA
Server Flow 2 Network Network
Switch
HMI Switch
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.
18 CHAPTER 3. SCADA SYSTEM ARCHITECTURE
Remote Site
Internet
Radius + VPN
Intranet Server
Process Network
Radius + VPN
Server
Control Network
Firewall
+ VPN
DMZ Network
PLC PLC PLC
Fan Valve
Pump
Historian Historian
Field Network
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.
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.
The firewall act also as VPN server. In order to access the plant networks
20 CHAPTER 3. SCADA SYSTEM ARCHITECTURE
(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
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 on TCP
TCP
IP
EIA/TIA-232 Ethernet
Other Physical layer
EIA/TIA-485 Physical layer
• Protocol Data Unit (PDU): it contains the core information for the
MODBUS protocol and it is independent of the underlying communi-
cation layers.
The Figure 4.2 shows a general MODBUS Frame regardless of the underlying
layers.
• 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.
24 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
• 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.
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:
These Protocol Data Units (PDUs) are used in different MODBUS transac-
tions as explained in the next section.
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
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.
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
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
28 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
the original function code with the most significant bit set to logic 1 and an
exception function code which specifying the exception occurred.
The Table 4.1.4 explains the same data models, but from the point of
view of the I/O system:
The Table 4.6 shows the public function codes and sub-codes:
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
Function code 1 byte 0x01 01
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
Request
Function code 0x01 01
Starting Address 0x0013 19
Quantity of coils 0x0013 17
Response
Function code 0x01 01
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
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.
Request
Function code 1 byte 0x03 03
Starting Address 2 bytes 0x0000-0xFFFF 00-65535
Quantity of Registers 2 bytes 0x0001-0x007D 1-125
Response
Function code 1 byte 0x03 03
Byte Count 1 bytes n n
Register Status n bytes values values
n = Quantity of Registers * 2
Exception Response
Function code 0x83 Function Code + 0x80
Exception code 0x01,02,03,04 Exception code
Request
Function code 0x03 03
Starting Address 0x006B 107
Quantity of registers 0x0003 3
Response
Function code 0x03 03
Byte Count 0x06 6
Register status(byte 1) 108 HI 0x02
Register status(byte 2) 108 LO 0x2B
Register status(byte 3) 109 HI 0x00
Register status(byte 1) 109 LO 0x00
Register status(byte 2) 110 HI 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.
32 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
The Function Code “0x04 Read Input Registers (04)” has exactly the
same message format.
Request
Function code 1 byte 0x05 05
Output Address 2 bytes 0x0000-0xFFFF 00-65535
Output value 2 bytes 0x0000-0xFF00 0-65280
Response
Function code 1 byte 0x05 05
Output Address 2 bytes 0x0000-0xFFFF 00-65535
Output value 2 bytes 0x0000-0xFF00 0-65280
Exception Response
Function code 0x85 Function Code + 0x80
Exception code 0x01,02,03,04 Exception code
Request
Function code 0x05 05
Output Address 0x00AC 172
Output value 0xFF00 ON (0x0000 is OFF)
Response
Function code 0x05 05
Output Address 0x00AC 172
Output value 0xFF00 ON (0x0000 is OFF)
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
Starting Address 2 byte 0x0000 to 0xFFFF
Quantity of Outputs 2 byte 0x0000 to 0x07B0
Exception Response
Function code 0x8F Function Code + 0x80
Exception code 0x01,02,03,04 Exception code
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
Starting Address 2 bytes 0x0013 19
Quantity of Outputs 2 bytes 0x000A 10
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
Request
Function code 1 byte 0x06 06
Register Address 2 bytes 0x0000-0xFFFF 00-65535
Register value 2 bytes 0x0000-0xFFFF 0-65535
Response
Function code 1 byte 0x05 05
Register Address 2 bytes 0x0000-0xFFFF 00-65535
Register value 2 bytes 0x0000-0xFFFF 0-65535
Exception Response
Function code 0x86 Function Code + 0x80
Exception code 0x01,02,03,04 Exception code
Request
Function code 0x06 06
Register Address 0x0001 1
Register value 0x0003 3
Response
Function code 0x06 06
Register Address 0x0001 1
Register value 0x0003 3
4.1. MODBUS 35
Request
Function code 1 byte 0x10 16
Starting Address 2 byte 0x0000 to 0xFFFF
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
Function code 1 byte 0x10 16
Starting Address 2 byte 0x0000 to 0xFFFF
Quantity of Registers 2 byte 0x0000 to 0x07B0
Exception Response
Function code 0x90 Function Code + 0x80
Exception code 0x01,02,03,04 Exception code
Request
Function code 1 byte 0x10 16
Starting Address 2 bytes 0x0001 1
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
Function code 1 byte 0x10 16
Starting Address 2 bytes 0x0001 1
Quantity of Registers 2 bytes 0x0002 2
36 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
Response
Function code 1 byte 0x07 07
Output Data 1 bytes 0x00-0xFF 00-255
Exception Response
Function code 0x87 Function Code + 0x80
Exception code 0x01,04 Exception code
Example:
In the Modicon Controller 484 the 8 status coils are:
257 258-264
Battery Status User defined
Response
Function code 0x07 07
Output Data 0x6D 0110 1101
In this example, coil 257 is ON, indicating that the controller’s battery is
OK.
4.1. MODBUS 37
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
Function code 1 byte 0x08 08
Sub-Function 2 bytes 0x0000-0xFFFF
Data n bytes values values
Response
Function code 1 byte 0x08 08
Sub-Function 2 bytes 0x0000-0xFFFF
Data n bytes values values
Response
Function code 0x88 Function Code + 0x80
Exception code 0x01,03,04 Exception code
Sub-function codes
In the following there are some of the most important sub-function codes.
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
Sub-Function 2 bytes 0x0000 0
Data N x 2 bytes Echo Request Data Echo Request Data
38 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
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
0x08 / 0x01
Restart Communication Options
Request
Sub-Function 2 bytes 0x0004 04
Data 1 byte 0x0000
4.1. MODBUS 39
Request
Sub-Function 2 bytes 0x0001 01
Data N x 2 bytes 0x0000 or 0xFF00
Response
Sub-Function 2 bytes 0x0001 01
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.
Request
Sub-Function 2 bytes 0x0002 02
Data 2 byte 0x0000
Response
Sub-Function 2 bytes 0x0002 02
Data 2 byte Diagnostic Register Content
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:
40 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
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
9 ROM Chip 1 Test Failed
10 ROM Chip 2 Test Failed
11 ROM Chip 3 Test Failed
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
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.
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
Request
Function code 1 byte 0x08 08
Sub-function code 2 byte 0x0000 00
Data 2 bytes 0xA537
Response
Function code 1 byte 0x08 08
Sub-function code 2 byte 0x0000 00
Data 2 bytes 0xA537
• 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.
42 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
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.
Response
Function Code 1 byte 0x01(Read Coils) 01
Starting Address 2 byte 04A1 1185
Quantity of colis 1 byte 0x01
Exception Response
Function code 0x81 Function Code + 0x80
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
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.
DNP3
Slave
MULTIDROP
DNP3 HIERARCHICAL
Master
DNP3
Master
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.
Application Application
Presentation
Session
Limited-Transport Transport
Pseudo-Transport
Limited-Network Network
Physical Physical
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.
48 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
• 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.
Application
ASDU ASDU
APDU APDU
APCI APCI
Pseudo - TSDV
Transport
• 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)
• 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.
...
Data Block (Block n)
CRC
User Data (1 to 16 bytes)
(2 byte)
• Start (2 bytes): the first two bytes are always 0x05 and 0x64.
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.
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
52 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
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.
00 - Reset Link
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
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.
54 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
Primary Secondary
Station Station
Ctrl byte
DIR PRM RES DFC FUNCTION CODE
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
DIR PRM RES DFC FUNCTION CODE
0 0 X 0 0 (confirm-ack)
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.
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 FCV bit in the request does not match that expected for the
function code in the request.
56 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
TPDU
TH TH
1 249 1 249
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)
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.
• Breaks user data down into multiple ASDUs (Application Service Data
Units).
Master Outstation
3. If the master station has set a confirm bit, the outstation will send a
confirm message.
6. If the outstation has set a confirm bit, the master station will send a
confirm message.
Master Outstation
1. Process change
3. Receive or event
unsolicited 2. Send unsolicited
response response
7. Send Confirm Confirm (optional)
3. If the outstation has set a confirm bit, the master station will send a
confirm message.
The request and response headers differ by one field. The response header
includes an additional two-byte field called internal indications (IIN).
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
2. If a request has the sequence number N, the response 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.
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.
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:
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:
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.
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.
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.
0 2/4 2048
APCI ASDU
Request Response
AC (Application Control) 1 byte
AC FC AC FC IIN FC (Function Code) 1 byte
0 1 2 0 1 2 4
IIN (Internal Indication) 2 bytes
Request FC Response FC
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 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:
2. The outstation responds with the identity and status of the selected
points.
4. The HMI displays the selected points differently, showing they have
been selected.
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.
68 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
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
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 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.
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.
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.
72 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
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.
0 2 2048
APCI ASDU
0 2 3 10
Object (2 bytes) Qualifier (1 byte) Range (0-8 bytes)
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.
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
0 2 3 10
Object (2 bytes) Qualifier (1 byte) Range (0-8 bytes)
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.
The Table 4.11 shows the interpretation and use of qualifier code.
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
Range-Index Mode
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:
Example:
Non-Ranged Mode
below.
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.
80 CHAPTER 4. SCADA PROTOCOLS AND VULNERABILITIES
Example:
• Point indexes within each object group begin at zero and are assigned
4.2. DNP3 81
in a continuous sequence.
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.
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.
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.
0 2/4 2048
APCI ASDU
Request Response
AC (Application Control) 1 byte
AC FC AC FC IIN FC (Function Code) 1 byte
0 1 2 0 1 2 4
IIN (Internal Indication) 2 bytes
• 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.
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
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.
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
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.
• The P LC2 with the IP address 10.0.0.2, TCP port 502 and ID = 2.
• The P LC3 with the IP address 10.0.0.3, TCP port 502 and ID = 3.
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.
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
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.
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.
92 CHAPTER 5. STATE BASED APPROACH
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
HR[1] 50 HR[2] 50
VOUT VIN
P1
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:
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.
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:
94 CHAPTER 5. STATE BASED APPROACH
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).
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:
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
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
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.
96 CHAPTER 5. STATE BASED APPROACH
• The system status with the status of each register in every slave device.
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
HR[1] 50 HR[2] 50
VOUT VIN
P1
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
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.
99
100 CHAPTER 6. CRITICAL STATE BASED IDS ARCHITECTURE
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:
By the use of the ”State Based Detection“ is possible to detect many kinds
of attacks against SCADA systems.
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:
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.
6.2. IDS GENERAL ARCHITECTURE 103
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
Protocol
Builder
System Virtual
Image (SVI)
Update System
Manager
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
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)
104 CHAPTER 6. CRITICAL STATE BASED IDS ARCHITECTURE
Analyzer
It performs the “Signature Based Detection” and the “State Based Detec-
tion”. It contains two functional components:
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.
106 CHAPTER 6. CRITICAL STATE BASED IDS ARCHITECTURE
<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
<plc address="10.0.0.2" port="502" id="2" >
-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 <discrete_inputs numbers="200" />
-id : byte = 1
-discrete inputs : bool [100]
-id : byte = 2
-discrete inputs : bool [200]
-id : byte = 3
-discrete inputs : bool [300]
...
-coils : bool [100] -coils : bool [200] -coils : bool [300] <holding_registers numbers="200" />
-input registers : short [100] -input registers : short [200] -input registers : short [300]
-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>
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
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
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
108 CHAPTER 6. CRITICAL STATE BASED IDS ARCHITECTURE
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.
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
Address: 10.0.0.1 Address: 10.0.0.3
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
IR 0 0 .. 0 IR 0 8 .. 0 IR 0 0 .. 0
HR 0 0 .. 0 HR 0 0 .. 0 HR 0 7 .. 0
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
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
Raise an Alert
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
110 CHAPTER 6. CRITICAL STATE BASED IDS ARCHITECTURE
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
• Loader
• Analyzer
111
112 CHAPTER 7. IDS PROTOTYPE IMPLEMENTATION
Protocol
Builder
System Virtual
Image (SVI)
Update System
Manager
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
7.0.1 Loader
The loader module is in charge to read the XML configuration files and to
initialize the whole system.
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,
114 CHAPTER 7. IDS PROTOTYPE IMPLEMENTATION
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
The XML Virtual System File Descriptor for such scenario is the following:
<infrastructure>
<master address="10.0.0.254" port="502" />
<plc address="10.0.0.1" port="502" id="1" >
<discrete inputs numbers="100" def value="false" />
...
<holding registers numbers="100" def value="0"/>
</plc>
<plc address="10.0.0.2" port="502" id="2" >
<discrete inputs numbers="200" def value="false" />
...
<holding registers numbers="200" def value="0" />
</plc>
<plc address="10.0.0.3" port="502" id="3" >
<discrete inputs numbers="300" def value="false" />
...
<holding registers numbers="300" def value="0" />
</plc>
</infrastructure>
For Example the system presented above generates the following data
structure (Figure 7.3).
Master
-address : string = 10.0.0.254
-port : int = 502
In order to better understand the BDT data structure, let’s consider the
following condition:
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
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
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.
118 CHAPTER 7. IDS PROTOTYPE IMPLEMENTATION
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 “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:
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.
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 )
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.
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.
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
throw new Exception();
return node;
}
if (expression[i].getType() == BoolTypes.AND)
{
op = new AndBoolNode();
i++;
}
else if (expression[i].getType() == BoolTypes.OR)
{
op = new OrBoolNode();
i++;
}
else
throw new Exception();
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 )
left = createNode(expression, inout i);
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;
left = createNode(expression, inout i);
int i = 0;
if(left== null)
left = createNode(expression, inout i);
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.
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.
Message::Request Request::Response
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)
Moreover, the “Protocol Builder” checks the message function code and parse
the Request or the Response in the right way.
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
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);
}
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
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.
The method reads the function code contained in the response object and
130 CHAPTER 7. IDS PROTOTYPE IMPLEMENTATION
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.
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
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:
131
132 CHAPTER 8. EXPERIMENTS AND TESTS
IDS
Sensor
Switch
Request
Response
Outstation
Master
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 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 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
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.
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.
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.
136 CHAPTER 8. EXPERIMENTS AND TESTS
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”.
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.
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
The reason for this linear growth is obviously guessed watching the “up-
dateSVI ” method code (See Section 7.2):
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.
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
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.
140 CHAPTER 8. EXPERIMENTS AND TESTS
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
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
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
[9] www.winpcap.org
143
144 BIBLIOGRAPHY
[20] http://www.digitalbond.com/index.php/research/ids-
signatures/modbus-tcp-ids-signatures/, April 9, 2009
[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.