Description and Analysis of IEC 104 Protocol: Petr Matoušek
Description and Analysis of IEC 104 Protocol: Petr Matoušek
Description and Analysis of IEC 104 Protocol: Petr Matoušek
104 Protocol
Technical Report
Petr Matoušek
December , 2017
© 2017, Brno University of Technology
Abstract
IEC 60870-5-104 protocol (aka IEC 104) is a part of IEC Telecontrol Equipment and Systems
Standard IEC 60870-5 that provides a communication profile for sending basic telecontrol
messages between two systems in electrical engineering and power system automation.
Telecontrol means transmitting supervisory data and data acquisition requests for controlling
power transmission grids.
IEC 104 provides the network access to IEC 60870-5-101 (aka IEC 101) using standard transport
profiles. In simple terms, it delivers IEC 101 messages as application data (L7) over TCP, port 2404.
IEC 104 enables communication between control station and a substation via a standard TCP/IP
network. The communication is based on the client-server model.
In this report we give a short overview of related standards and describe IEC 104 communication
model. The main part of this report is description of the IEC 104 protocol, especially APCI and ASDU
format. As other monitoring protocols, IEC 104 transmits ASDU containing information objects and
information elements which build the basic part of IEC 104 monitoring. The report is a part of
IRONSTONE1 research project focused on security monitoring of IoT networks.
1
IRONSTONE - IoT monitoring and forensics, Technological Agency of the Czech Republic, 2016-2019, no.
TF03000029, see http://www.fit.vutbr.cz/~matousp/grants.php.en?id=1101.
2
© 2017, Brno University of Technology
Table of Contents
3
© 2017, Brno University of Technology
The International Electrotechnical Commission (IEC) defines IEC 60870 standards for telecontrol
(supervisory control and data acquisition) in electrical engineering and power system automation
applications. Part 5 provides a communication profile for sending basic telecontrol messages
between a central telecontrol station and telecontrol outstations, which uses permanent directly
connected data circuits between the central station and individual outstations.
IEC 60870-5 consists of the following parts, under the general title Telecontrol Equipment and
Systems – Part 5: Transmission protocols:
IEC 60870-5-1 Transmission Frame Formats
o This describes the operation of the physical and data link layers. It provides a choice
of four data link frame types FT1.1, FT1.2, FT2 and FT3 with fixed and variable
length.
IEC 60870-5-2 Link Transmission Procedures
o It describes service primitives and transmission procedures: the unbalanced and
balanced transmission. It also describes whether transmission can be initiated only
by a master station, or by any station.
IEC 60870-5-3 General Structure of Application Data
o It specifies the general structure of data at the application level, rules for forming
application data units, etc.
IEC 60870-5-4 Definition and Coding of Application Information Elements
o It provides the definition of information elements and defines a common set of
information elements used in telecontrol applications. These include generic
elements such as signed or unsigned integers, fixed or floating point numbers, bit-
strings, and time elements.
IEC 60870-5-5 Basic Application Functions
o It describes the highest level functions of the transmission protocol that include
station initialization, methods of acquiring data, clock synchronization,
transmission of commands, totalizer counts, and file transfer.
IEC 60870-5-6 Guidelines for conformance testing for the IEC 60870-5 companion
standards
IEC also generated companion standards for basic telecontrol tasks, transmission of integrated
totals, data exchange and network access:
IEC TS 60870-5-7 Security extensions to IEC 60870-5-101 and IEC 60870-5-104 protocols
(applying IEC 62351)
IEC 60870-5-101 (1995) Transmission Protocols - Companion standards for basic
telecontrol tasks
IEC 60870-5-102 (1996) Transmission Protocols - Companion standard for the
transmission of integrated totals in electric power systems
4
© 2017, Brno University of Technology
The IEC 60870-5 protocol stack is based on the reduced reference model called Enhanced
Performance Architecture (EPA) that includes three layers of ISO OSI model: application layer (L7),
link layer (L2), and physical layer (L1), see Table 1.
1.2 Transmission
IEC 60870-5-101 provides a communication profile for sending basic telecontrol messages
between a central telecontrol station (master, controlled station) and telecontrol outstations
(slave, controlling station), which uses permanent directly connected data circuits between the
central station and individual outstations, see Figure 1.
5
© 2017, Brno University of Technology
Master
LAN
Slave Slave
Figure 1: Network topology
The IEC 104 specification combines the application layer of IEC 60870-5-101 and the transport
functions provided by a TCP/IP (Transmission Control Protocol/Internet Protocol).
Figure 2 shows a topology of IEC 104 router connected with 104 SCADA monitoring systems using
IEC 104 protocol over TCP/IP, and IEC 101 sensors communicating via Modbus RTU with the router.
6
© 2017, Brno University of Technology
1.3 Communication
An important concept in understanding addressing under IEC 60870-5 is the difference between
control and monitor directions. It is an assumption that the overall system has a hierarchical
structure involving centralized control. Under the protocol, every station is either a controlling
station or a controlled station.
IEC 101/104 communication is exchanged between the controlled and the controlling station.
Controlled station is monitored or commanded by a master station (RTU)
o It is also called outstation, remote station, RTU, 101-Slave, or 104-Server.
Controlling station is a station where a control of outstations is performed (SCADA)
o Typically, it is a PC with SCADA system, can be also a RTU32.
IEC 60870-5 has information on a set of information objects that are suited to both general SCADA
applications, and electrical system applications in particular. Each different type of data has a
unique type identification number (see Section 2.2 and Appendix C.1). Only one type of data is
included in any one Application Service Data Unit (ASDU). The type is the first field in the ASDU.
The information object types are grouped by direction (monitoring or control direction) and by
the type of information (process info, system info, parameter, file transfer).
An example of process information in monitoring direction is a measured value, e.g., a bit
or an analog. In control direction it can be a command to set a bit or a value.
An example of system information in monitoring direction is initiation flag, in the control
direction it can be interrogation command, reset, etc.
Thus, application data is carried within the ASDU within one or more information objects.
Depending on the variable structure flag (SQ, see Section 2.2) there may be multiple information
objects each containing a defined set of one or more information elements, or there may be just
one information object containing a number of identical information elements. In either case, the
information element is the fundamental component used to convey information under the
protocol.
1.5 Addressing
IEC 101 defines addressing both at the link and at the application level. The link address (or device
address) and ASDU address (or common address) are provided for identification of the end station:
The device address is the identification number of the device.
o The link address field may be 1 or 2 octets for unbalanced, and 0, 1 or 2 octets for
balanced communication. As balanced communication are point-to-point the link
address is redundant, but may be included for security.
o The value range depends on the link address length that can be one byte, i.e., range
1 – 255, or two bytes, i.e. range 1 – 65 535. Typical values are 1 for IEC 101 and 2
for IEC 104.
o The link address FF or FFFF is defined as a broadcast address, and may be used to
address all stations at the link level.
Each device on the communication network has a Common Address of ASDU (COA or ASDU
address). The common address of the ASDU combined with the information object address
contained within the data itself combine to make the unique address for each data
element.
o COA is typically the application address of the client (logical station) that must
match the address defined in the client configuration. This is defined as the address
of the controlling station in the control direction.
8
© 2017, Brno University of Technology
o In the monitoring direction, however, the common address field contains the
address of the station returning the data (controlled station). This is required so
that the data can be uniquely identified and mapped to the right points in system
data images.
o The maximum value depends on the ASDU address length that is one or two bytes
similarly to the device address. Typical values are 1 for IEC 101 and 2 for IEC 104.
The length of COA is fixed per system.
IEC 60870-5-104 Protocol (aka IEC 104) is a standard for telecontrol equipment and systems with
coded bit serial data transmission in TCP/IP based networks for monitoring and controlling
geographically widespread processes. Protocol standard defines the transferred data entities in
the station object as equal to the ones used in the IEC 60870-5-101 protocol. The implementation
of the IEC 104 protocol uses the same as station objects (STA) as the IEC 101 implementation. IEC
104 is designated according to a selection of transport functions given in the TCP/IP Protocol Suite
(RFC 2000). Within TCP/IP various network types can be utilized including X.25, Frame Relay, ATM,
ISDN, Ethernet and serial point-to-point (X.21), see Figure 3.
Each APCI (Application Protocol Control Information) starts with a start byte with value 0x68
followed by the 8-bit length of APDU (Application Protocol Data Unit) and four 8-bit control fields
(CF). APDU contains an APCI or an APCI with ASDU, see Figure 4. Generally, the length of APCI is 6
bytes.
9
© 2017, Brno University of Technology
8 bits
There are packets with fixed length and with variable length containing Application Service Data
Unit (ASDU, also called telegram) [4].
The frame format is determined by the two last bits of the first control field (CF1). The standard
defines three frame formats, see Figure 5.
number of APDUs when it returns the Receiver Sequence Number up to the number whose
APDUs are properly received.
The sending station holds the APDU or APDUs in a buffer until it receives back its own Send
Sequence Number as a Receive Sequence Number which is valid acknowledge for all
numbers less or equal to the received number.
In case of a longer data transmission in one direction only, an S format has to be sent in
the other direction to acknowledge the APDUs before buffer overflow or time out.
The method should be used in both directions. After the establishment of a TCP
connection, the send and receive sequence numbers are set to zero.
The standard case studies of sequence number acknowledgement is shown in Appendix A.
27 26 25 24 23 22 21 20 27 26 25 24 23 22 21 20
Send sequence no. N (S) LSB 0 0 0 0 0 0 1 1 0
MSB Send sequence no. N (S) 0 0 0 0 0 0 0 0
Receive seq. no. N (R) LSB 0 0 0 0 0 0 0 1 0
MSB Receive sequence no. N (R) 0 0 0 0 0 0 0 0
Figure 6: Interpretation of sequence numbers
For example, sequence 0x06 0x00 0x02 0x00 (see above, right table) will be
interpreted as N(S) = 3 and N(R) = 1, e.g., the third APDU sent by the source and
waiting for the first APDU from the destination.
11
© 2017, Brno University of Technology
o The controlling and/or controlled station must regularly check the status of all
established connections to detect any communication problems as soon as
possible. This is done by sending TESTFR frames.
Open connections may be periodically tested in both directions by sending test APDUs
(TESTFR=act) which are confirmed by the receiving station sending TESTFR=con.
Both stations may initiate the test procedure after a specific period of time in which no
data transfer occur (time out).
The ASDU contains two main sections: the data unit identifier (with the fixed length of six bytes),
and the data itself, made up of one or more information objects. The data unit identifier defines
the specific type of data, provides addressing to identify the specific identity of the data, and
includes additional information as cause of transmission. Each ASDU can transmit maximum 127
objects. The format of ASDU is in Fig. 8.
12
© 2017, Brno University of Technology
8 bits
Type identification
SQ Number of objects
T
P/
Caus e of transmission (COT) data
N
unit
Originator address (ORG) identifier
ASDU address fields
(2 bytes)
Time Tag
Type ID Group
1-40 Process information in monitor direction
45-51 Process information in control direction
70 System information in monitor direction
100-106 System information in control direction
110-113 Parameter in control direction
120-126 File transfer
2
Fields and values of ASDU dissector in Wireshark are described in
https://www.wireshark.org/docs/dfref/1/104asdu.html (last access in June 2017).
13
© 2017, Brno University of Technology
o It is important to note that the type identification applies to the whole ASDU,
therefore if there are multiple information objects contained in the ASDU, they are
all of the same type.
o The standard values of TypeID are listed in Appendix C.1.
SQ (Structure Qualifier) bit specifies how information objects or elements are addressed.
o SQ=0 (sequence of information objects): addressing of individual single information
elements or combination of information elements in a number of information
objects (IO) of the same type, see Figure 8.
SQ=0 implies a sequence of information objects where each object has its own
information object address. The number of information objects is given by the
seven-bit value in the date unit identifier (field number of objects, see Figure 7).
Therefore there can be up to 127 information objects in this ASDU. [7]
When SQ=1, the structure contains a sequence information elements within one
information object. All information objects are of the same format, such as a
measured value. There is just one information object address, which is the address
of the first information element.
14
© 2017, Brno University of Technology
Type identification
0 Number of objects = N
P/
T Caus e of transmission (COT)
N Data Unit
Originator address (ORG) Identifier
Type identification
ASDU address fields 1 Number of elements = N
(2 bytes)
P/
T Cause of transmission (COT)
N Data Unit
Information object address Identifier
Originator address (ORG)
Number of objects/elements
o Uses range 0 – 127
o 0 means ASDU contains no information object (IO)
o 1-127 defines no. of information objects or elements
T (test) bit defines ASDUs which were generated during test conditions and not intended
to control the process or change the system state.
o T=0 (no test), T=1 (test)
ASDU Address Field (Common Address of ASDU, COA), see also Section 1.5
o The address is called common address because it is associated with all objects
contained within the ASDU. This is normally interpreted as a station address,
however it can be structured to form a station/sector address where individual
stations are broken up into multiple logical units.
o COA is either one or two octets in length, fixed on a per-system basis.
o The global address is a broadcast address directed to all stations of a specific system
(broadcast address). ASDUs with a broadcast address in control direction have to
be answered in monitor direction by the address that is the specific defined
common address (station address). According to the standard this parameter
consists of 2 octets.
o Value 0 is not used, range 1 – 65 534 means a station address, value 65 535
(0xFFFF) means global address.
o Global address is used when the same application function must be initiated
simultaneously. It is restricted to the following ASDUs:
Type=100 (Interrogation command): reply with particular system data
snapshot at common time
16
© 2017, Brno University of Technology
ASDU transmits information objects within its structure. Each information object is addressed by
Information Object Address (IOA) which identifies the particular data within a defined station. Its
length is 3 bytes for IEC 104. The address is used as destination address in control direction and as
source address in monitor direction.
The third byte of IOA is only used in case of structuring the information object address in order to
define unambiguous addresses within a specific system. In all cases the maximum number of
different object addresses is limited to 65 535 (as for two bytes).
If the information object address is not relevant (not used) in some ASDUs, it is set to zero.
All information objects transmitted by one ASDU must have the same ASDU type (e.g., 5, step
position information, see Appendix C.1). If there are more objects of different types to be
transmitted, they are inserted in several ASDUs.
For each defined ASDU type, the IEC 104 standard defines the format of the information object,
i.e., what information elements form such object and how they are structured.
Figure 10 shows an example of information object Single-point information without time (ASDU
type=1). The object format has two forms: one for SQ=0 and one for SQ=1. Valid COT for this
objects are: 2 (background scan), 3 (spontaneous), 5 (requested), 11, 12 (feedback), 20 +G
(interrogated by station interrogation), see Appendix C.1.
IV NT SB BL 0 0 0 SPI
Figure 10: Example of information object Single-point information without time (type=1)
17
© 2017, Brno University of Technology
Some information objects contain several information elements. For example, Figure 11 shows
information object of type 10 (measured value, normalized with time tag). This object is defined
only for SQ=0 and contains three information elements: normalized value NVA (2 bytes), quality
descriptor (1 byte), and binary timestamp (3 bytes). For this type of object, valid causes of
transmission are spontaneous (code 3) or requested (code 5, see Appendix C.2).
Value NVA
SQ=0
IV NT SB BL OV QDS
CP24Time2a Timestamp
Figure 11: Example of information object Measured normalized value with the timestamp (type=10)
The number of information objects and information elements within the ASDU is the Number of
objects given in the second byte of ASDU header (see also above).
Information elements are building blocks used to transmit information. Format and length of each
information element differs and is given by the standard. The standard also describes how
encoded values are interpreted.
A list of available information elements is given in Appendix C.3. The list also gives the length of
the element and object types where it is used.
The interpretation of values transmitted by an information element is also given by the standard
and can be found in [7]. Figure 11 shows a format of three information elements: SIQ (single point
of information), VTI (value with transient state indication) and SVA (scaled value). SIQ contains a
set quality bits (see interpretation in Appendix C.4), VTI contains a seven-bit value from the range
<-64..+63>. SVA contains a 16-bit value in the range <-32 768..32 767> which represents a fixed
decimal point number. However, the position of the decimal point is not transmitted by the value
but it is set in the system database. For example, a value of 39.5 amps may be transmitted as 395
where the resolution is fixed at 0.1 amp.
18
© 2017, Brno University of Technology
IV NT SB BL 0 0 0 SPI
T Value I7
Value I16
Figure 11: Example of three information elements: SIQ, VTI and SVA
For SQ=1, the number of information elements within the information object is given in the
Number of objects field of the ASDU header. The structure of the information object contains:
Information object address (3 bytes)
A set of information elements of the same type
o The number of the elements is given in the ASDU header.
o The format of the element is given by the standard and depends on the ASDU type.
o The length of information object can be computed using APDU length, e.g.,
information object_length (bytes) = APDU_length – ADPU_control_fields (4 bytes)
– ASDU_header (6 bytes) – IOA (3 bytes) = APDU_length – 13 bytes.
o The length of each information element within this object is given by object_length
/ number_of_objects.
Please, remind that each of the elements belongs to one information objects which IOA is
given by offset from the IOA in the ASDU, e.g., +1 for the second element, +2 for the third
element, etc.
For SQ=0, the number of information objects is given in the Number of objects field of the ASDU
header. The format of the object, e.g., from which elements the object is built, is fixed by the
standard. The structure of ASDU data part is following:
Information object address of object no.1 (3 bytes)
A set of information elements of object no. 1
Information object address of object no.2 (3 bytes)
A set of information elements of object no. 2
…
Information object address of object no.N (3 bytes)
A set of information elements of object no. N
o The number of the objects is given in the ASDU header.
o All of the objects are of the same type and thus have the same length.
19
© 2017, Brno University of Technology
Sample 1:
68 0E 4E 14 7C 00 65 01 0A 00 0C 00 00 00 00 05
20
© 2017, Brno University of Technology
Sample 2:
68 34 5A 14 7C 00 0B 07 03 00 0C 00 10 30 00 BE 09 00 11 30 00 90 09 00 0E 30 00 75 00
00 28 30 00 25 09 00 29 30 00 75 00 00 0F 30 00 0F 0A 00 2E 30 00 AE 05 00
Sample 3:
68 04 01 00 7E 14
21
© 2017, Brno University of Technology
22
© 2017, Brno University of Technology
For security monitoring, it is better to group individual IEC 104 packets into transactions.
Considering master-slave transactions we can divide the communication on transactions as
depicted in the following table:
23
© 2017, Brno University of Technology
The table shows logical transactions exchanged between the master and slave. Arrow represents
direction: master to slave (--->) or slave to master (<---). A transaction usually concerns one
information object with its address (IOA). Only exception is transaction no. 1 which summarizes
initialization of the system. Following transactions are initiated by the master station that sends
activation command (COT=6) which is responded by the slave station using a sequence of
messages with COT=7 (activation confirmation), COT=10 (activation termination) and COT=3
(spontaneous).
In the table, we can noticed some specific features of IEC 104 communication:
Destination is addressed on L7 by common ASDU address (COA) which is 10 in this case
(address of the slave station). Then, each destination contains several objects addressed
by the information object address (IOA). Usually, the controlling station sends or retrieves
data from the specific information object identified by its IOA.
Special destination address 0 does not refer to a specific information object but to the
configuration of the whole slave system. Thus, initialization of the slave is addressed using
IOA=0.
The transaction 1 sends an activation message with the interrogation command which
enforces a sequence of interrogation answers from object 1-4 and 11-14 transmitting the
actual settings of their values.
We can notice that one object with a given IOA can contain several types of information
elements. E.g., object 1 has elements of type SIQ, DIG, step position, bitstring, normalized
value, scaled value, or short floating point.
24
© 2017, Brno University of Technology
Some responses can be divided into several TCP packets, e.g., the response on transaction
no. 4 is sent in two packets: one contains ActCon ASDU, the other ActTerm ASDU and Spon
ASDU. This is different to transaction no. 3, where the response is sent via one TCP packet
that contains three ASDUs: ActCon, ActTerm and Spon.
Some objects (e.g., 11-14) returns values with timestamp, others (1-4) do not use them.
One TCP packet can transmit a sequence of ASDUs of several objects. E.g, the third
response from slave in the transaction 1 transmits ASDUs with objects IOA=1-4 and
IOA=11-14.
We can also see that some ASDUs contain one information element and some a sequence
of information elements. This number is specified in the Number of Objects field in the
ASDU header.
After detailed analysis of the several PCAP sample of IEC 104 communication, we can make the
following observations:
1) One TCP stream transmits several types of IEC format frames: U-frames, S-frames, I-frames.
These frames have different format and usage for IEC communication. From point of view of
network monitoring, it can be useful to keep statistics that include no. of packets, bytes, etc.
for each of the frame formats.
2) It is better to monitor transactions related to objects than individual packets. Each
informational object is addressed by an IP address of the controlled station (on L3), by a
controlled station address on L7 (common ASDU address, COA), and an object address (IOA).
Thus, the transaction can be identified using a target address (COA+IOA) and action (COT,
cause of transmission). Each transaction gets values or sets values of information elements
that are part of the referred object. The standard defines which object type contains what kind
of information elements.
3) Transactions are build by exchanges of ASDU messages between the slave and the controlling
station. There is no transaction ID, thus slave and master have to check transactions based on
COA, COT and OUI. If a message is lost, the loss is detected by L7 via ASDU sequence numbers
and re-sent.
4) One ASDU can transmits several objects, however, these objects must have the same COT.
5) One TCP packet can contain several ASDUs with same or different COTs.
25
© 2017, Brno University of Technology
When analyzing IEC 104, we can notice several similarities with SNMP monitoring. SNMP manager
sends short commands to SNMP agent in order to set variables or retrieve their values. The same
is IEC 104 master station. Unlike SNMP, IEC 104 does not define any security as access passwords
(via community string in SNMPv1 and SNMPv2), authentication (using RSA) or encryption (using
SHA) as supported by SNMPv3.
This forms a serious vulnerability against IEC 104 communication, especially when transmitted
over unsecure IP layer. Possible attacks on IEC 104 communication may include:
changing the value of an ASDU transmitted in the IEC 104 packet,
inserting spoofed ASDU messages into the network,
providing DDoS attacks on IEC 104 master or slave stations,
inserting a rogue control station into the network,
interception of the transmitted data,
etc.
These vulnerabilities and possible attacks are also discussed in [8] and [9]. We can mitigate
possibility of these threats by hardening the access to IEC 104 communication which is sometimes
not feasible, or we can provide security monitoring with anomaly detection. This can be
implemented using Netflow monitoring.
In case of flow monitoring, IEC communication is composed of one IP flow transmitting values and
action related to a range of different objects. Such a large set of useful data can be hardly
incorporated in IP flow records. One solution is to look at IEC communication via transactions
described above rather than classical IP flows. This can be implemented by creating several virtual
flows out of one IP flow with IEC 104 PDUs.
Then, the monitoring can be similar to other request-response communication, for example DNS.
DNS communication sends requests over UDP. A DNS client queries the DNS server which sends a
response in one packet.
IEC 104 has similar behavior: IEC 104 transactions are directed to an information object at the
controlled station using ASDUs. IEC 104 communicates in control mode (master to slave) or
monitoring mode (slave to master). Each transaction has its type (COT, cause of transmission); this
can be parallel to the type of DNS request (A, PTR, etc.). A requested object identified by IOA can
be compared with the requested DNS query (like www.fit.vutbr.cz).
26
© 2017, Brno University of Technology
As flow analysis of DNS combines DNS requests and responses based on the transaction ID, IEC
104 monitoring can combine IEC 104 transactions identified by a sequence of COA, COT and IOA.
For each transaction, we can monitor metadata (e.g., no. of transmitted ASDUs, packets, bytes),
or direct values of information elements transmitted in ASDUs.
The implementation will be part of the further phase of the IRONSTONE project.
27
© 2017, Brno University of Technology
References
1. IEC 60870-5-104:2006(E): Network access for IEC 60870-5-101 using standard transport
profiles, IEC, 2006.
2. ABB: RER620. IEC 60870-5-101/104 Communication Protocol Manual. 2010. Retrieved
from
https://library.e.abb.com/public/7801b90da654ce61c125795d003c7b26/RER620_ANSI_I
EC101-104prot_306892_ENb.pdf in June 2017.
3. ABB: MicroSCADA Pro. IEC 60870-5-104 Master Protocol. 2006. Retrieved from
https://library.e.abb.com/public/5fd0e08edecd7651c1257ab80041c671/SYS600_IEC%20
60870-5-104%20Slave%20Protocol_756654_ENb.pdf in June 2017.
4. Werner Mayer: Manual LIAN 98. IEC 60870-5-104: Telegram structure, 2011. Retrieved
from http://www.mayor.de/lian98/doc.en/html/u_iec104_struct.htm in June 2017.
5. Backhoff Information System: IEC 60870-5-104 telegram structure. Retrieved from
https://infosys.beckhoff.com/english.php?content=../content/1033/tcplclibiec870_5_104
/html/tcplclibiec870_5_104_telegrammstructure.htm&id= in June 2017.
6. Kamjoo Bayat: SCADA Protocols Introduction. Retrieved from
http://www.pbscontrol.com/pdf/SCADAProtocols.pdf in June 2017.
7. G. Clarke, D. Reynders, E. Wright: Practical Modern SCADA Protocols: DNP3, 60870.5 and
Related Systems, Elsevier, 2004.
8. Y. Yang, K. McLaughlin, S. Sezer, Y.B. Yuan, W. Huang, "Stateful intrusion detection for IEC
60870-5-104 SCADA security", PES General Meeting | Conference & Exposition 2014
IEEE, pp. 1-5, 2014.
9. Peter Maynard, Kieran McLaughlin, and Berthold Haberler. 2014. Towards Understanding
Man-In-The-Middle Attacks on IEC 60870-5-104 SCADA Networks. In Proceedings of the
2nd International Symposium on ICS & SCADA Cyber Security Research 2014 (ICS-CSR
2014). BCS, , UK, 30-42. DOI: https://doi.org/10.14236/ewic/ics-csr2014.5
28
© 2017, Brno University of Technology
29
© 2017, Brno University of Technology
30
© 2017, Brno University of Technology
31
© 2017, Brno University of Technology
32
© 2017, Brno University of Technology
33
© 2017, Brno University of Technology
35
© 2017, Brno University of Technology
37
© 2017, Brno University of Technology
38