On the Detection of Replay Attacks in Industrial Automation Networks

Operated with Proﬁnet IO

Steffen Pfrang and David Meier

Fraunhofer IOSB, Fraunhoferstr. 1, 76131 Karlsruhe, Germany

Keywords:

Industrial Networks, Replay Attacks, Port Stealing, DCP Reconﬁguration, Intrusion Detection, Attack

Detection Modeling.

Abstract:

Modern industrial facilities consist of controllers, actuators and sensors that are connected via traditional IT

equipment. The ongoing integration of these systems into the communication network yields to new threats

and attack possibilities. In industrial networks, often distinct communication protocols like Proﬁnet IO (PNIO)

are used. These protocols are often not supported by typical network security tools. In this paper, we present

two attack techniques that allow to take over the control of a PNIO device, enabling an attacker to replay

formerly recorded trafﬁc. We model attack detection rules and propose an intrusion detection system (IDS)

for industrial networks which is capable of detecting those replay attacks by correlating alerts from traditional

IT IDS with speciﬁc PNIO alarms. Thereafter, we evaluate our IDS in a physical demonstrator and compare it

with another IDS dedicated to securing PNIO networks.

1 INTRODUCTION

Automation systems play a key role in modern indus-

trial facilities and are therefore an important part of

our economy. New technology tries to maximize the

efﬁciency of such systems by simplifying the instal-

lation of automation systems, as well as providing the

available data to the business level. In recent years,

this was achieved more and more by the introduc-

tion of well-known IT technology into areas where

in the past dedicated and incompatible technologies

were used. While automation and control systems

still have certain requirements, new standards aim to

provide these requirements using standard IT tech-

nology. One such standard is Proﬁnet IO (PNIO), as

speciﬁed in (IEC 61158-6-10, 2007). This Industrial

Ethernet standard has the possibility to connect vari-

ous automation systems and provide them with real-

time communication. PNIO, as most new automation

standards, is mostly concerned with providing reli-

able services and does not provide any distinct secu-

rity mechanisms.

This situation, combined with the already men-

tioned process of networks getting connected to more

and more services, renders the threat of cyberattacks

into a realistic scenario. Even if there are no inherent

security controls in PNIO

, it is crucial to be able to

detect attacks targeting PNIO devices. Because such

attacks require little to no knowledge about the in-

dustrial process being run and are easy to adopt, this

makes them a rewarding target for any attacker.

In this work, we will show how the missing se-

curity in automation protocols can facilitate the abil-

ity to successfully attack control system equipment by

using a replay attack method on PNIO. We will then

show how it is possible to detect these attacks, taking

multiple information sources as an input for an intru-

sion detection system (IDS). To be able to understand

the attack and proposed detection model, this work

also includes a brief overview of the relevant details

of PNIO.

2 BACKGROUND AND RELATED

WORK

In this section, we will give background information

on the relevance of PNIO and the protocol speciﬁca-

tions which are important in our study. The second

This means that such a PNIO network should be op-

erated in a completely separated environment without any

link to the outside.

Pfrang, S. and Meier, D.

On the Detection of Replay Attacks in Industrial Automation Networks Operated with Proﬁnet IO.

DOI: 10.5220/0006288106830693

In Proceedings of the 3rd International Conference on Information Systems Security and Privacy (ICISSP 2017), pages 683-693

ISBN: 978-989-758-209-7

683

part of this section is dedicated to related work avail-

able in the area of control system security and on the

security of PNIO.

2.1 Background

According to a recent study (HMS Industrial Net-

works, 2016b), Ethernet-based ﬁeldbuses have a mar-

ket share of 38% within industrial automation sys-

tems, while classic ﬁeldbuses have 58% and wireless

variants 4%. The annual growth of Ethernet-based

ﬁeldbuses is estimated with 20%, whereas Siemens

is the market leader in Europe and China with its

“Proﬁbus family” including PNIO (HMS Industrial

Networks, 2016a). In total, 21% of the sold Ethernet-

based automation systems are running PNIO.

In the following, we will provide technical details

about the PNIO protocol behaviour relevant to the

presented scenario: A programmable logic controller

(PLC) controlling a PNIO device (a stepping motor).

Starting with the discovery and conﬁguration proto-

col DCP and the context management protocol CM,

we describe the startup phase of a PNIO network like

it happens when the power returns after an outage.

The last subsection covers the alarm management of

PNIO devices.

2.1.1 PNIO Discovery and Conﬁguration

DCP (Discovery and Conﬁguration Protocol) is an

Ethernet-based protocol within the PNIO protocol

suite. Using the DCP Set Request, a controller is

able to conﬁgure a PNIO device. Such a request can

contain multiple conﬁguration blocks, for example to

set the name and the IP address using only a sin-

gle packet. The request is then answered by a DCP

Set Response that signals what conﬁguration options

were tried to be set and if the request could executed.

It does not contain the actual values from the DCP Set

Request.

2.1.2 PNIO Context Management

CM (Context Management) is a UDP-based PNIO

protocol to setup the application relation (AR) be-

tween PNIO controllers and devices. The controller

is sending a CM ConnReq request, specifying vari-

ous properties of the communication channel, includ-

ing its communication relations (CR). These can be

data inputs and outputs (IO), as well as properties

for alarm handling. The properties of IO CR include

values for the DataHoldFactor, SendClockFactor and

ReductionRatio. From these values, the DataHold-

Time of the respective CR is calculated, as shown in

equation 1.

DataHoldTime = DataHoldFactor

× SendClockFactor

× ReductionRatio

× 31.25µs

(1)

A watchdog timer of that duration is set every time

data is received for the respective CR. When this timer

expires, it will trigger an PN-RT alarm frame with an

appropriate error message.

The PNIO device replies to the CM ConnReq with

a CM ConnResp response. This response can ac-

knowledge the request or deny it, for example if there

are no resources left for a new AR. In case of a suc-

cessful connection request, the already established

CRs will start exchanging data and the controller can

proceed establishing further CMs. When all desired

CMs are established, the controller will send a CM

Control Req request signaling the end of parameter

transmission, that will again be acknowledged by the

PNIO device through an CM Control Resp. After-

wards, the device is sending a CM Control Req sig-

naling application readiness. After the controller has

acknowledged this request, the communication estab-

lishment is complete.

2.1.3 PNIO Startup

When an industrial setup operated with PNIO starts

up, the sequence of network packets shown in Figure

1 can be discovered. We will focus on the connec-

tion establishment between the PLC (as PNIO con-

troller) and the motor (as PNIO device). Additionally,

we consider the case that all the components are con-

ﬁgured for operation. That means, that the process

is already running which is a reasonable assumption

when dealing with real production environments.

From the Proﬁnet protocol suite, there are three

protocols involved: DCP, CM and RT (Real Time).

Additionally, PNIO makes use of ARP (Address Res-

olution Protocol). CM is an UDP-based protocol,

while the other protocols are operating directly on the

MAC layer (Ethernet).

The startup process is initiated by the PNIO con-

troller. It asks with a multicast DCP Ident Request for

a device with the PNIO name that has been conﬁg-

ured initially in the PLC program. The PNIO device

with that particular name replies to that request with

an unicast DCP Ident OK that is directed to the PLC.

The Ident OK message includes, amongst other infor-

mation, the IP address conﬁguration of that device.

Subsequently, the controller starts an ARP request

for the IP address given by the PNIO device. If the

device is not yet conﬁgured with that IP address, the

controller sends a DCP Set Request, setting the IP ad-

dress conﬁguration of the PNIO device in order to be

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

684

PLC

IP MAC

Motor

IPMAC

DCP IdentReq D

Name

DCP IdentOk D

Name

ARP Who has?

ARP Is at ...!

CM ConnReq

CM ConnResp

CM Control Req

CM Control Resp

CM Control Req

CM Control Resp

Figure 1: The regular startup process of a PNIO network at

the example of a PLC and a motor.

able to communicate with it using UDP for the next

step, the PNIO-CM.

2.1.4 PNIO Alarm Management

The signaling of errors and warnings is also an inte-

gral part of PNIO. On the network level, this signal-

ing is achieved by the usage of special alarm frames.

There are multiple alarm types, depending on the ori-

gin and cause of the alarm. For example, process

alarms are originating from the executed process on

a ﬁeld device, while diagnosis alarms are originating

from the ﬁeld device itself (Popp, 2014). Only pro-

cess alarms have their priority set to HIGH, while all

other type have a LOW priority. Alarms are queued into

a buffer according to their priority and only removed

from the buffer once they are acknowledged. Every

alarm is therefore assigned a sequence number which

also needs to be part of the acknowledgment of the

communication partner, i.e. the PNIO controller or

device. This means other alarms of the same prior-

ity are not reported until all alarms prior to them are

removed from the queue buffer. The alarm buffer is

cleared when the application relation (AR) between

controller and device is terminated, for example by a

new connection request.

The PNIO standard holds a predeﬁned list of

alarm messages that can be extended by manufacturer

speciﬁc messages. Alarms are sent within an acyclic

PN-RT frame, the alarm frame (PN-AL), specifying

the alarm type, alarm origin and structure of the alarm

message.

2.2 Related Work

A broad overview of the state of the art in indus-

trial control system security has already been given

(McLaughlin et al., 2016). This work promotes the

idea of using industrial control system (ICS) testbeds

for helping to identify, exploiting and mitigating cy-

bersecurity vulnerabilities. It follows a security as-

sessment approach to analyze the ICS architecture

and identify vulnerabilities. The authors identify

the attacks on controllers and sensors as two attack

classes in the current ICS threat landscape and the

false data injection (FDI) as one of the emerging

threats in this domain.

A compact overview of the system architecture of

PNIO and its functionality can be found in (Popp,

2014). More details about the alarm management in

PNIO networks are being described in (Ferrari et al.,

2006). However, this work focuses mainly on the per-

formance aspects of a PNIO system.

Replay attacks in the control system domain have

been studied in (Mo and Sinopoli, 2009). Here, the

authors are assuming an attacker trying to disrupt the

operation of a control system by injecting control in-

puts without being detected. The main contribution of

this work is a new problem formulation providing in-

formation on the feasibility of replay attacks on con-

trol systems.

The vulnerability of PNIO to Man-in-the-middle

(MitM) attacks when using PNIO conformance class

A has already been addressed (Baud and Felser,

2006). For this conformance class, classical net-

work infrastructure components, like standard Ether-

net switches, are allowed and do not need to be cer-

tiﬁed for the usage in a PNIO network. In this work,

the authors describe the communication setup process

and possible errors that can occur during the setup,

like the duplicate assignment of station names or IP

addresses. By using open-source tools like ettercap,

the authors tried a MitM approach that was not suc-

cessful because of the PNIO cycle speeds, as sug-

gested.

The security of PNIO was also explored in

(

Akerberg and Bj

orkman, 2009b). Here, the authors

followed two attack scenarios. In the ﬁrst scenario,

the systems are using a shared medium for their com-

munication, while in the second one, the systems are

On the Detection of Replay Attacks in Industrial Automation Networks Operated with Proﬁnet IO

685

communicating via a packet switched network. In the

shared media scenario the attack method is to inject

PNIO frames so that they will reach the target before

the correct frame which is requiring highly accurate

timing and sound understanding of the protocol. In

the packet switched scenario, a MitM attack is used

to intercept and alter PNIO frames. This is a far more

simple approach than in the ﬁrst scenario, as the at-

tacker only has to wait for frames to arrive and for-

ward them after they are altered without the need to

know any details about the AR between PNIO con-

troller and device. While being successful in imple-

menting the attack, the author noticed a certain un-

reliability due to the fact that their PC-based attack

system is partially delaying the frame processing.

Two attack types, the Denial-of-service (DoS) and

the MitM attack, and corresponding attacks on PNIO

have also been studied by (Paul et al., 2013). The at-

tack on the DCP protocol relies on fabricated DCP

Ident Requests frames preventing the successful as-

signment of a device name. Similar to that, the IP

address assignment can also be prevented by send-

ing malicious DCP or ARP frames. Both of these at-

tacks will result in a DoS. The presented MitM attacks

are divided into attacks during the startup process and

during the operational stage. The MitM attacks rely

on the port stealing method which is manipulating the

switch to be able to capture the trafﬁc between PNIO

controller and device. In this work, the authors also

investigate the setup of an intrusion detection system

for ICS based on anomaly detection and show that this

IDS is able to detect the described DoS and MitM

attacks. The proposed anomaly detection is thereby

only using the sequence of DCP frames to determine

abnormal behavior, without incorporating indicators

from the PNIO protocol or using means to detect the

port stealing itself. In section 4.1, we will use this

work for a comparative evaluation of our proposed so-

lution.

There have been further efforts to study the se-

curity of PNIO. The security of PROFIsafe (an

additional layer on top of PNIO dealing with

safety aspects) has been examined in (

Akerberg and

orkman, 2009a). Recommendations on the en-

hancement of PNIO in terms of security have also

already been given by (

Akerberg and Bj

orkman,

2009c), where PNIO is recommended to be extended

by the introduction of security modules based on the

concept of the safety proﬁle in PROFIsafe. This ex-

tension should be comprised of an additional layer

ensuring authenticity, integrity and conﬁdentiality for

PNIO process data. Currently, no such extension was

introduced in the PNIO standard.

3 ATTACK CASE STUDY

This section is divided in three main sections: The

environment setup, the attack selection and execution,

and the attack detection.

3.1 Environment Setup

The scenario for this paper is implemented in an

industrial IT security laboratory. This lab consists

of both a physical part and a virtualization environ-

ment. (Reference removed for anonymity reasons.)

Within the physical part, real industrial components

like PLCs, sensors and actors, switches etc. are con-

nected to each other using typical industrial protocols

like PNIO, Siemens S7 and OPC UA.

In the virtualization environment (in the follow-

ing, we will call it “cloud”), different networks have

been set up using virtual switches as well as vir-

tual ﬁrewalls. Virtual machines connected to these

networks provide components of automation systems

(e.g. PLC programming stations, SCADA servers),

management tools as well as different attack and de-

tection tools.

This scenario (see Figure 2) makes use of a

Siemens PLC (S7-300), a stepping motor (Schnei-

der Electric mdrive), a human machine inter-

face (Siemens KTP-700) and an industrial switch

(Hirschmann RS-20) in the physical part. The switch

is connected to the virtualization environment provid-

ing data exchange as well as a mirror stream of the

network trafﬁc within the physical part to be used by

the detection tools.

The physical process implemented in the scenario

turns a disk which is mounted on the motor shaft

clockwise from one position to the next with a pause

of 2 seconds. The real industrial process from which

our demonstration setup was derived, consists addi-

tionally of a driller which drills a hole in a workpiece

if and only if a workpiece was transported by the disk

to the drilling position.

3.2 Attack Selection and Execution

In order to steer the stepping motor, we focus on re-

playing network trafﬁc. This a very general attack

which can be performed even without having knowl-

edge about the process that is implemented, only the

ability and time for watching and recording the traf-

ﬁc that is ﬂowing through the network is needed. A

limitation of that approach is that you can only record

For obvious reasons, attacks causing irreversible dam-

ages and possibly injuring people are not allowed to be per-

formed in our lab.

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

686

Detection tools

HMI

PLC

Motor

Physical part

Figure 2: The base scenario is set up using a PLC with a

HMI and a motor in a star topology with a switch that con-

nects the local network to a cloud network which hosts the

detection tools.

actions that occur while you are watching the trafﬁc.

But we don’t consider this as a major drawback be-

cause most industrial processes rely on a very correct

timing

, so you can harm the system even by trigger-

ing valid actions in an invalid time slot. For exam-

ple, see the drilling example from above with a driller

drilling a hole into the disk instead of the workpiece.

3.2.1 Taking Over Control

Replaying trafﬁc in order to attack a speciﬁc PNIO

device requires the attacker to take over control of at

least one connection to it. For that, we selected two

types of attacks which turned out to be suitable. The

ﬁrst one is a classical way to attack Ethernet-based

protocols: Using port stealing.

Usually, a network switch learns which device is

connected to which hardware port by maintaining a

lookup table. If it receives an Ethernet packet with the

source MAC address M

from its port P

, it learns that

packets with the destination MAC address M

have to

be delivered to port P

. Former entries with the same

MAC address get lost. This standard mechanism is

useful because it adapts itself when new devices are

added to the switch or when the topology changes.

The port stealing attack exploits this behaviour as

follows: The device to be attacked has the MAC ad-

dress M

victim

and is attached to port P

victim

. The at-

tacker is attached to port P

attacker

and sends any kind

PNIO supports up to 5ms cycle time (1ms in the

isochronous real-time class).

of Ethernet-based packets with the source MAC ad-

dress M

victim

. The switch now learns that packets for

victim

have to be delivered to P

attacker

. If the victim

sends itself a network packet, the switch will recover

the original relation of M

victim

on port P

victim

, but the

attacker sends its port stealing packets in such a high

frequency that these changes won’t last for a longer

period of time.

In our work, the PLC acted as the victim for the

port stealing attack. Figure 3 illustrates the attack se-

quence with the corresponding network communica-

tion. When the motor sends packets to the PLC, they

will not arrive at the PLC anymore but at the switch

port of the attacker. Meanwhile, the attacker is able

to send packets directly to the motor. The real PLC

would be able to send packets to the motor as well,

but that does not pose as a problem for the attacker,

because the PNIO standard speciﬁes, that if there is

no real-time response from the communication part-

ner, an existing connection has to be closed.

Attacker

IP MAC

PLC

IP MAC

Motor

IPMAC

PN-AL ”expired”

Port steal

Figure 3: The attacker performs a port stealing attack tar-

geting the PLC via the hardware switch. This results in the

attacker taking over the RT connection to the motor from

the PLC.

The second attack type is speciﬁc for PNIO op-

erated devices: A reconﬁguration attack using DCP.

Caused by the design of this protocol without any au-

thentication measures, each device that is located in

the same subnet is able to reconﬁgure a PNIO device.

There are two options available: Set IP and Set Name.

Since the identiﬁer of a PNIO device is its name, we

chose that option for the attack.

In Figure 4, the sequence diagram of the DCP re-

conﬁguration attack is shown. There are three devices

involved with both their IP and MAC interface: The

On the Detection of Replay Attacks in Industrial Automation Networks Operated with Proﬁnet IO

687

Attacker

IP MAC

PLC

IP MAC

Motor

IP MAC

DCP SetReq D

new

PN-AL ”station name ch”

PN-AL ”alarm”

DCP Set OK

DCP IdentReq D

old

Figure 4: The attacker reconﬁgures the motor using DCP.

In consequence, the real-time communication between the

PLC and the motor will be terminated.

PLC, the motor with its original device name D

old

and

the attacker. Before the attack happens, PLC and mo-

tor exchange real-time data (RT).

The attacker asks the motor to change its name to

new

by sending a DCP Set Request. The motor emits

a PNIO alarm frame “device name changed” to its

Proﬁnet communication partner, the PLC. The PLC

acknowledges the alarm frame, and the connection

between the PLC and the motor will be terminated.

As a last step, the motor acknowledges the DCP Set

Request by sending a DCP Set Response to the at-

tacker. On a regular basis, the PLC keeps on asking

for a device with the name D

old

which is still conﬁg-

ured in its setup, but will not receive any response, as

no device is conﬁgured to react on that name now.

3.2.2 Replaying Trafﬁc

Replaying trafﬁc successfully in a PNIO operated sys-

tem requires, besides a communication connection,

the application relation (AR) as mentioned before

(section 2.1.2). Once a PNIO device like the stepping

motor has established an application relation with its

PLC, it refuses each further communication request,

responding with an error reply. Hence, the existing

communication relation between the PLC and the mo-

tor has to be interrupted before continuing the replay.

Fortunately, both types of attacks described in sec-

tion 3.2.1 ensure that the original communication re-

lation gets interrupted: In the port stealing case, the

PLC does not receive real-time data from the motor

anymore, because this data is now redirected to the

attacker. After the DataHoldTime, as described in

section 2.1.2, has passed without any message from

the motor, it terminates the connection and sends an

alarm frame. As a consequence, the motor will also

stop receiving real-time data from the PLC and will

terminate its communication in the same way. In the

case of the DCP reconﬁguration attack, the connec-

tions gets lost immediately.

Once the motor isn’t involved in a communica-

tion relation anymore, the attacker is able to setup

a new connection with the motor. The attacker now

starts with CM Connect Request that is answered by

the motor with a CM Connect Response. After that,

the attacker sends a CM Control Request, which is an-

swered with a CM Control Response by the motor. In

the original trafﬁc, the motor proceeds by sending a

CM Control Request, but the attacker does not have

to reply to that request and can directly start replay-

ing the PNIO real-time packets. As a side note, the

attacker does not even need to process or react on the

replies of the motor.

3.3 Attack Detection

In this section, we will start with a model for detecting

the attacks being described in the previous sections.

In a second part, we explain how we implemented or

plan to implement this using our existing open-source

based intrusion detection framework.

3.3.1 Model for Attack Detection

In the case of the port stealing based replay attack,

there is the evidence of the packets used for the port

stealing. So in general, one could be suspicious if

such unusual trafﬁc can be observed in the network.

Since the port stealing approach is based on the at-

tacker sending forged packets in a limited period of

time

between a correct packet from the device under

attack and the response to this packet, the attacker has

to produce lots of packets in time. A method to de-

tect this huge amount of trafﬁc is by using ﬂow-based

intrusion detection systems. Those systems aggregate

single packets by considering source and destination

as well as some other conﬁgurable keys to ﬂows of

packets. Another method for detection would be a

switch conﬁguration that emits alerts when MAC ad-

dresses change from one interface to another. We will

call that evidence h port-stealing i and the tool per-

forming that analysis Port stealing detector.

Additionally, there will appear two PNIO alarm

frames of the type “AR consumer DHT/WDT expired

(RTA ERR ABORT)” at the network: The ﬁrst one

from the PLC that does not receive cyclic data from

the motor anymore (h al-plc-expired i), and a second

one from the motor complaining about the PLC stop-

ping to send cyclic data (h al-motor-expired i).

In tests, we discovered answer times less than 1 ms.

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

688

Detecting the DCP reconﬁguration attack is very

different because there will not be any packets present

that are unusual for the speciﬁc networks. Neverthe-

less, industrial networks tend to be very stable and are

run for a long time. So reconﬁguring devices isn’t part

of the daily work and for that reason, detecting DCP

packets that change the name of a device seems to be

reasonable

. We will call that packet h dcp-setname i.

In order to reﬁne the detection, a PNIO alarm

frame “station name changed” will appear on the

network if the exchange of name was success-

fully completed (h al-station-name-changed i). This

alarm gets acknowledged by the PLC with an alarm

(h al-generic i). And further on, the PLC will send

regularly DCP Ident Requests asking for the initial

name of the motor (h dcp-ident-req-oldname i).

Summarizing, the port stealing attack can be dis-

covered using the following evidence:

h port-stealing i AND

h al-plc-expired i AND

h al-motor-expired i

In case of the DCP reconﬁguration attack, we ex-

perience the following evidence:

h dcp-setname i AND

h al-station-name-changed i AND

h al-generic i AND

h dcp-ident-req-oldname i (repeated)

It has to be noted that not each evidence of the

AND clauses is really needed for assuming that there

is an attack ongoing: In the ﬁrst case, it would

be sufﬁcient if you discover h port-stealing i and

one of h al-plc-expired i or h al-motor-expired i be-

cause you are able to infer that when one partner

of the communication quits, the other one will fol-

low soon. In the second case, h al-generic i and

h dcp-ident-req-oldname i only improve the accuracy

of the detection. This is an important notice because

in some topological constellations, not every packet is

visible for the IDS (see section 4).

3.3.2 Attack Detection Implementation

Figure 5 depicts a schema of the attack detection sys-

tems. It has to be noted that parts of the implemen-

tation are still work in progress. The mirroring of the

network trafﬁc in the physical environment is ensured

by the hardware switch which monitors the speciﬁc

ports of the PLC and the motor. Since the distributed

IDS resides in the virtual part of the laboratory, the

In order to eliminate false positives, we expect the op-

erator receiving alerts from the IDS will be aware of any

maintenance work.

mirrored trafﬁc has to be forwarded using a generic

routing encapsulation (GRE) tunnel into the cloud.

Mirror stream

Port

stealing

detector

Correlator

PNIO

detector

Physical network

GRE tunnel

Alert

Alert Alert

Distributed IDS

Figure 5: Schema of the implementation comprising attack

detection tools in the cloud being fed by a mirror stream

from the physical part of the network where the attacks take

place.

On the one hand, the PNIO detector receives the

network packets from the mirror stream. In our

case, it consists of a Python script, running in back-

ground and employing the “Network packet and pcap

ﬁle crafting/snifﬁng/manipulation/visualization secu-

rity tool” Scapy (Biondi, 2010). It ﬁlters the Ether-

type 0x8892 of PNIO and generates an alert when it

receives either a speciﬁc PNIO alarm frame (see sec-

tion 2.1.4) or a DCP packet (see section 2.1.1). The

reason for not using a standard network-based IDS

like Snort (Roesch et al., 1999) is that those tools are

based on IP trafﬁc, while PNIO is based on Ethernet.

On the other hand, the Port stealing detector sniffs

the packets from the mirror stream. The open IP-

FIX standard (Internet Protocol Flow Information Ex-

port, (Claise, 2015)) speciﬁes ﬂow keys for layer 2

communication like MAC source and destination ad-

dresses. Unfortunately, the current implementations

of the common open-source ﬂow-based IDS Flow-

tools (Fullmer and Romig, 2000), Silk (McHugh,

2004) and nfdump (Haag, 2005) do not support those

keys, as they are limited to layer 3 communication.

For that reason, we are currently not able to use a

ﬂow-based IDS as a port stealing detector.

As an alternative solution for implementing the

port stealing detector, we have set up the switch con-

necting the physical components to send alerts to the

correlator when MAC addresses change from one in-

terface to another. The great advantage of this solu-

tion is that it is available. The drawback is the fact

that it needs reconﬁguration of the switches which is

not feasible in every production environment.

The Correlator receives alerts from both the PNIO

detector and the port stealing detector. It is able to

On the Detection of Replay Attacks in Industrial Automation Networks Operated with Proﬁnet IO

689

aggregate the alerts and generate new alerts which can

be sent to the operator.

4 EVALUATION

In this section, we will evaluate our approach to de-

tect the two replay attacks dedicated to PNIO net-

works described in section 3.2. For that reason, we

performed and recorded several tests in different se-

tups. We will conclude this section with a compara-

tive evaluation of our solution.

Figure 6: The demonstrator with a stepping motor turning a

disk used for performing the replay attacks.

Figure 6 depicts the base setup with the PLC (up-

per middle) and the motor (on the left) in a star topol-

ogy connected by a switch (lower middle). In the up-

per right resides an embedded PC which is connected

both to the mirror port of the switch and a cloud up-

link. An HMI, reﬂecting the status of the system, is

placed in the lower right.

Table 1 enumerates the scenarios considered in

our evaluation. The ﬁrst column represents the identi-

ﬁcator of the scenario. The second column describes

the topology of the demonstrator: In case of the “star”

topology, both PLC and motor are connected to the

switch. In the “line” case, the motor is attached di-

rectly to the second Ethernet port of the PLC.

The attacks can be performed either by using a

laptop that gets connected to the switch on a port that

is conﬁgured with the same VLAN as the PLC and

the motor, or from the cloud using the same VLAN

as well. This distinction is related to the effort an at-

tacker has to make: In the local case, an attacker has

to gain physical access to the switch, whereas in the

cloud case, an attack even from remote may succeed.

This is being represented by the column “Origin”.

The column “Action” tells which type of action

has been performed in the speciﬁc scenario: Mainly

the two types of attacks, but additionally, two cases

have been considered in which we expected PNIO

alarm frames similar to the ones being observed in

the attack case. On the one hand, this is the removal

of either the plug of the PLC or the plug of the mo-

tor from the switch. On the other hand, this is the

substitution of the PNIO name by the respective pro-

gramming station: In case of the PLC the Siemens

TIA portal, in case of the motor, the Lexium Software

Suite.

In the column “Evidence”, we have listed abbre-

viations of the evidence being described in section

3.3.1: PS stands for h port-stealing i. The different

PNIO alarm frames are preﬁxed with their origin: P

stands for an alarm that has been issued by the PLC,

M for one that has been sent by the motor. The index

denotes the type of alarm: ex for h al-

plc

motor

-expired i,

snc for h al-station-name-changed i and gen for

h al-generic i. There are also abbreviations for sev-

eral DCP packets: SET stands for h dcp-setname i,

while ID stands for h dcp-ident-req-oldname i.

The next column “Detection” bares witness of the

fact whether our proposed IDS detected an attack or

not.

In our evaluation, we considered 14 different sce-

narios. The ﬁrst eight cases arise from the topology

permutation of the demonstrator, the origin and the

type of the attack. Case #9 up to #12 reﬂect the per-

mutation of the location where the cable has been un-

plugged and the topology, while the last two cases de-

scribe the interaction of both the PLC and the motor

with their repective management stations located only

in the cloud.

First of all, it has to be noted that both types of

replay attacks succeed in the case of a star topology.

However, if the physical components are connected in

a line topology, replaying does not succeed using the

port stealing attack, but it still does when employing

the DCP reconﬁguration attack.

The proposed detection works in case of an at-

tacker that sends the replay packets from the cloud.

In case of a line topology, the port stealing attack

fails (case #7), but the DCP reconﬁguration attack

succeeds (case #5) with a false negative. The reason

for not detecting the attack in that case is that PNIO

alarms do not protrude the connection between the

PLC and the motor. To overcome this issue, it is nec-

essary to place a network tap in between both physical

components and forward these packets also to the mir-

roring stream. The drawback of this solution is that

it does not scale with larger installations. Neverthe-

less, we consider attacks from the cloud more proba-

ble than those where the attacker has to gain physical

access to the switch.

In the case of the DCP reconﬁguration attacks in

the line topology (cases #6 and #8), only the DCP

packets can be discovered. Nevertheless, it is not im-

possible to derive from the observed DCP Set Request

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

690

Table 1: The different setups examined in the evaluation of the Replay attacks.

# Topology Origin Action Evidence Detection Remarks

1 star local port stealing PS, P

, M

yes

2 star local DCP reconﬁg SET, M

snc

, P

gen

, ID yes

3 star cloud port stealing PS, P

, M

yes

4 star cloud DCP reconﬁg SET, M

snc

, P

gen

, ID yes

5 line local port stealing PS no false negative

6 line local DCP reconﬁg SET, ID yes

7 line cloud port stealing PS no unsuccessful attack

8 line cloud DCP reconﬁg SET, ID yes

9 star – PLC plug removed M

10 star – motor plug removed P

11 line – PLC plug removed – no motor keeps spinning

12 line – motor plug removed – no motor stops

13 star cloud PLC change name – no Siemens S7 trafﬁc

14 star cloud motor change name – no proprietary protocol

trafﬁc

and the subsequent repeated DCP Ident Requests that

an attack has taken place.

In order to validate the proposed IDS, we under-

took tests which might result in similar alarms: Re-

moving a cable from the switch in the star topology

case results in either an “expired” alarm from the mo-

tor or the PLC. Since there is neither a port stealing

attack active nor any DCP packets can be discovered,

the IDS does not generate an alert. That happens as

well for the management station changing the names

of the devices: Neither the Siemens TIA portal nor

the Lexium Software Suite make use of DCP. Both use

their own protocols for that purpose: Either Siemens-

S7 or a proprietary protocol. Summarizing, in none

of the tested cases appeared a false positive.

4.1 Comparative Evaluation

The IDS proposed by (Paul et al., 2013) (in the fol-

lowing referred to as PAUL) also focuses on intrusion

detection for PNIO networks. For that reason, we will

try to perform a comparative evaluation with our ap-

proach. However, since there is not any implemen-

tation of PAUL available, we will have to restrict the

comparison to the conceptual level.

PAUL derives n-grams of DCP packets from the

mirrored network stream. Each n-gram that appears in

a learning phase is considered a good one. Any other

n-gram that can be observed in the regular operation

phase is considered a bad one, depicting an attack.

In contrast to PAUL, we propose an IDS which

does not need any learning phase but works out of the

box once it has been conﬁgured for detecting security

breaches in PNIO networks. Learning phases in in-

dustrial automation systems can be leveraged only in

very rare cases since availability is the most important

parameter. For example, in order to detect DCP pack-

ets which rename a PNIO device, you would have to

interrupt existing communication relations and prob-

ably stop the industrial process.

As a second difference, our solution follows a dual

approach combining both intrusion evidence from the

well-known IT world with anomaly evidence from

automation protocols. Whereas PAUL is limited to

PNIO DCP, our IDS takes into account additional pro-

tocols of the PNIO protocol suite like CM and alarm

frames. That renders our IDS to be more comprehen-

sive than PAUL.

5 CONCLUSION AND FUTURE

WORK

In this paper, we took a look at the security of the

industrial Ethernet protocol Proﬁnet IO which is one

of the most common automation protocols being in-

stalled in Europe. We explained relevant functions

and mechanisms during the startup phase and while

running. Afterwards, we introduced the scenario in

which we performed our research. In an attack case

study, we motivated why we choose replay attacks as

the means of attack, how we performed the attacks

and conclude with a model for an IDS being able to

detect the attacks.

We then evaluated our detection approach which

takes into account both alarms from the well-known

IT world and different protocols of the Industrial Eth-

ernet world. In 14 different test cases, we ended

up with no false positive and one false negative in a

special constellation without any proper mirroring in

place. Additionally, we compared our approach with

On the Detection of Replay Attacks in Industrial Automation Networks Operated with Proﬁnet IO

691

another one and were able to show the advantages of

the proposed solution.

Taking care of replay attacks is very crucial since

PNIO devices are a worthwhile target. This is the case

because an attacker does not need any special skills

or knowledge of the process being controlled, making

these attacks easy to perform.

In order to enable data exchange with other sys-

tems in the use case of the so-called “Industry 4.0” or

“Internet of Things”, many companies connect their

industrial networks with their ofﬁce networks and the

Internet. Improper and unsecure conﬁgurations of

these connections are raising risk and danger. And

the danger is proverbial: Industrial processes control

real devices. If e.g. motors, valves, robots do not be-

have as expected, serious physical damage to property

and lives may happen.

This strengthens the need for intrusion detection

systems adapted for the industrial environment. Oth-

erwise, if anything gets damaged by a cyber attack,

like the replay attacks presented in this paper, it will

not be possible to identify the reason of the attack.

This is the case because of the PNIO inherent features

which restore the initial connection and do not persist

any evidence in the network.

5.1 Future Work

Performing replay attacks in automation systems is

only one type of possible means to disturb or destroy

an industrial processes, yet a simple and easy to per-

form one. There are many more attack vectors, like

the tampering of data that is presented in visualiza-

tions, worth being considered and assessed. Evalua-

tion criteria include the amount of knowledge about

the industrial process an attacker needs, how easy the

attacks are to employ and the extend of possible dam-

age. This work will be extended by an overall at-

tack case study of the used demonstrator including the

PLC, the motor, the local HMI as well as an HMI that

accesses data from the PLC and presents it on a web

interface in the cloud.

Many automation systems in Europe are operated

with PNIO. Nevertheless, there are many other au-

tomation protocols which are widespread. We will

setup demonstrators with protocols besides PNIO (for

example with EtherCAT) and will try to transfer our

attack and detection techniques.

An ongoing task is the implementation work in

our distributed open-source IDS. This task deals with

the main problem that common IDS start with the IP

layer. They do not support Ethernet-based protocols

as they are usually used in industrial automation net-

works and are not able to pay attention to the real-time

requirements of such networks. An effort to close this

gap is the development of a preprocessor for the pop-

ular IDS Snort which enables it to deal with PNIO

trafﬁc. Another effort is the work on different corre-

lation techniques that have to be employed in a central

correlation engine that controls the possible ﬂood of

different alerts from both the IT and the automation

process side.

REFERENCES

Akerberg, J. and Bj

orkman, M. (2009a). Exploring network

security in proﬁsafe. In International Conference on

Computer Safety, Reliability, and Security, pages 67–

80. Springer.

Akerberg, J. and Bj

orkman, M. (2009b). Exploring security

in proﬁnet io. In Proceedings of the 2009 33rd Annual

IEEE International Computer Software and Applica-

tions Conference - Volume 01, COMPSAC ’09, pages

406–412, Washington, DC, USA. IEEE Computer So-

ciety.

Akerberg, J. and Bj

orkman, M. (2009c). Introducing se-

curity modules in proﬁnet io. In 2009 IEEE Confer-

ence on Emerging Technologies & Factory Automa-

tion, pages 1–8. IEEE.

Baud, M. and Felser, M. (2006). Proﬁnet io-device emula-

tor based on the man-in-the-middle attack. In ETFA,

pages 437–440.

Biondi, P. (2010). Scapy documentation.

http://www.secdev.org/projects/scapy/doc/. [On-

line; accessed 08-December-2016].

Claise, B. (2015). Speciﬁcation of the IP Flow Informa-

tion Export (IPFIX) Protocol for the Exchange of IP

Trafﬁc Flow Information. RFC 5101.

Ferrari, P., Flammini, A., and Vitturi, S. (2006). Perfor-

mance analysis of proﬁnet networks. Computer stan-

dards & interfaces, 28(4):369–385.

Fullmer, M. and Romig, S. (2000). The osu ﬂowtools pack-

age and cisco netﬂow logs. In Proceedings of the 2000

USENIX LISA Conference.

Haag, P. (2005). Watch your ﬂows with nfsen and nfdump.

In 50th RIPE Meeting.

HMS Industrial Networks (2016a). Feldbusse

heute. http://www.feldbusse.de/trends/status-

feldbusse.shtml. [Online; accessed 08-December-

2016].

HMS Industrial Networks (2016b). Varianten-

vielfalt bei Kommunikationssystemen.

http://www.feldbusse.de/Trends/trends.shtml. [On-

line; accessed 08-December-2016].

IEC 61158-6-10 (2007). Industrial communication net-

works - Fieldbus speciﬁcations - Part 6-10: Applica-

tion layer protocol speciﬁcation - Type 10 elements.

Standard, International Electrotechnical Commission,

Geneva, CH.

McHugh, J. (2004). Sets, bags, and rock and roll. In Euro-

pean Symposium on Research in Computer Security,

pages 407–422. Springer.

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

692

McLaughlin, S., Konstantinou, C., Wang, X., Davi, L.,

Sadeghi, A.-R., Maniatakos, M., and Karri, R. (2016).

The Cybersecurity Landscape in Industrial Control

Systems. Proceedings of the IEEE, 104(5):1039–

1057.

Mo, Y. and Sinopoli, B. (2009). Secure control against re-

play attacks. In Communication, Control, and Com-

puting, 2009. Allerton 2009. 47th Annual Allerton

Conference on, pages 911–918. IEEE.

Paul, A., Schuster, F., and Knig, H. (2013). Towards the

Protection of Industrial Control Systems: Conclusions

of a Vulnerability Analysis of Proﬁnet IO. In Pro-

ceedings of the 10th International Conference on De-

tection of Intrusions and Malware, and Vulnerability

Assessment, DIMVA’13, pages 160–176, Berlin, Hei-

delberg. Springer-Verlag.

Popp, M. (2014). Industrial Communication with

PROFINET. PROFIBUS Nutzerorganisation e.V.,

Karlsruhe.

Roesch, M. et al. (1999). Snort: Lightweight intrusion de-

tection for networks. In LISA, volume 99, pages 229–

238.

On the Detection of Replay Attacks in Industrial Automation Networks Operated with Proﬁnet IO

693