Automated Incident Response for Industrial Control Systems Leveraging

Software-deﬁned Networking

Florian Patzer

, Ankush Meshram

and Maximilian Heß

Fraunhofer Institute of Optronics, System Technologies and Image Exploitation (IOSB), Karlsruhe, Germany

Vision and Fusion Laboratory (IES), Karlsruhe Institute of Technology (KIT), Karlsruhe, Germany

Keywords:

Incident Response, SDN Security, Industrial Control Systems, ICS Security, Software-deﬁned Networking.

Abstract:

Modern technologies and concepts for Industrial Control Systems (ICS) are evolving towards high ﬂexibility

of processes and respectively networks. Such dynamic networks are already functioning well, for example in

data centres. This is enabled by application of the Software-deﬁned Networking (SDN) paradigm. For this

reason, ICS is currently adopting SDN. The concept of having a centralized view of the network and generating

packet forwarding rules to control it enables performing automated responses to network events and classiﬁed

incidents via SDN. This automation can provide timely and, due to the holistic view of the network, accurate

incident response actions. However, availability, safety, real-time and redundancy requirements within the

ICS domain restrict the application of such an automated approach. At present, SDN-based incident response

(SDN-IR) does not take into consideration these requirements.

In this work, we identify possible SND-based response actions to ICS incidents and introduce classiﬁcation

of assets and links. Furthermore, we present a concept for SDN-IR where a predeﬁned rule set restricts the

response actions based on the asset’s classiﬁcation thereby satisfying ICS speciﬁc requirements. Subsequently,

we describe and evaluate a prototype implementation of this concept, built with the open-source SDN platform

OpenDaylight and the SDN protocol OpenFlow.

1 INTRODUCTION

Highly ﬂexible industrial processes are currently

evolving and spreading rapidly, due to new possibili-

ties digitalization provides. Hence, modern Industrial

Control Systems (ICS) face the need for highly ﬂex-

ible networks. Such dynamic networks are already

well established in other domains, like data centres.

Software-deﬁned Networking (SDN) is the enabling

paradigm in these domains and currently adopted by

ICS in order to meet the need for dynamic networks.

SDN is highly efﬁcient in providing ﬂexible central-

ized management of data ﬂows. This is achieved by

separating the control plane from the data plane (Kim

and Feamster, 2013). The control plane has a logi-

cally centralized view of the network and holds de-

tailed knowledge of its topology. The SDN controller

utilizes this knowledge to calculate packet forward-

ing rules and deploys them on the switches. For this,

the forwarding rule gets added to a ﬂow table, which

is the reason why such rules are often called ﬂow en-

tries. The switches follow the deployed ﬂow entries

for each packet matching one of them. If a packet

cannot be matched to a ﬂow entry, the switch sends

this packet to the SDN controller, which then can re-

act e.g. by generating new ﬂow entries.Since SDN

management (i.e. the controller and its environment)

control the data ﬂow within the whole SDN realm,

automated response to events and classiﬁed incidents

can be realized. As an example, (Martins and Cam-

pos, 2016) presented the automated incident response

with SDN using a security architecture where the In-

trusion Detection System (IDS) Snort sends alerts to

an SDN controller. Based on this alert, corrupt de-

vices are isolated and blacklisted via certain ﬂow en-

tries. This enables a fast reaction to detected events.

The importance of such fast responses can be com-

prehended from reading the SANS Incident Response

Survey 2017 (Bromiley, 2017). One can clearly con-

clude from the survey that faster containment and

short-term remediation help to prevent attack propa-

gation and aid damage regulation. Moreover, in ICS,

attacks tend to have dangerous impact on the safety of

humans and quickly cause massive ﬁnancial damage.

Thus, in such systems containment and short-term re-

mediation in a matter of milliseconds are of special

interest. Applying SDN for automated incident re-

sponse can achieve this objective.

Patzer, F., Meshram, A. and Heß, M.

Automated Incident Response for Industrial Control Systems Leveraging Software-deﬁned Networking.

DOI: 10.5220/0007359503190327

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 319-327

ISBN: 978-989-758-359-9

319

Leveraging SDN for incident response is still a

very young research ﬁeld. However, ﬁrst research

results already exist. The authors of (Koulouris,

T., Casassa Mont, M. and Arnell, S., 2017) intro-

duced SDN4S (SDN for Security), an SDN-based

incident response (SDN-IR) system leveraging au-

tomated countermeasures to minimize remediation

time. The authors introduced the concept of play-

books, consisting of a set of triggers (corresponding

to the incident addressed by the playbook) and a set

of executable actions (building the response strategy).

Therefore, playbooks describe the decisions an SDN

controller has to make upon the arrival of an incident

alert. Since their concept is not designed for ICS envi-

ronments, it does not meet ICS-speciﬁc requirements

like availability, reliability, safety, time sensitivity and

redundancy. We return to these requirements in sec-

tion 2.2. The requirements restrict the application of

SDN-IR within the ICS domain.

Even research results addressing ICS-speciﬁc

SDN-IR are available. (Piedrahita et al., 2018)

shows how SDN and Network Function Virtualization

(NFV) can be used for automated incident response

in ICS. The authors propose virtual incident response

functions which replace ICS components under at-

tack. If an attack on SCADA level is identiﬁed, the

virtual representation is used to create a honeypot of

the control system. (Di Lallo et al., 2017) addresses

the real-time requirements for SDN-based ICS secu-

rity. In their approach they leverage spare of band-

widths to transfer replicas of the sent packets within

the network to an IDS. This shows how SDN can as-

sist in the detection phase of incident response with-

out endangering the ICS network’s quality of service

guarantees.

At present, to the best of our knowledge no SDN-

IR concept is able to support all the peculiarities of

the ICS domain. This issue prevents the application

of SDN-IR in SDN-based industrial networks. How-

ever, we found SDN4S to be a simple and useful bases

to build an ICS-capable SDN-IR solution. Moreover,

the architecture of SDN4S allowed us to extend it to

incorporate ICS-requirements. For this, we extended

the playbook-based concept of SDN4S by introducing

classiﬁcation of assets (hosts, network components

and links) which represent ICS-speciﬁc requirements

and restrictive rules. Thus, as in SDN4S, the playbook

deﬁnes a set of response actions to perform for a given

incident/asset type pair. Afterwards the rules match-

ing the response actions, asset type and the asset’s

classiﬁcation are used to derive preconditions which

have to be met, before the actions are allowed to be

executed. If all applying rules allow the performing

of an action, it is transformed into ﬂow entries for re-

conﬁguration of the relevant SDN switches. To eval-

uate the feasibility of the concept’s implementation

with common SDN platforms, we present a prototype

implementation built upon the open-source SDN plat-

form OpenDaylight and the SDN protocol OpenFlow.

Afterwards, we describe some of the results of the

evaluation which was performed by applying the pro-

totype to example topologies using the Mininet net-

work emulator.

2 SDN-IR FOR ICS CONCEPT

In this chapter our concept of ICS-capable SDN-IR is

explained. The core concept of our approach can be

summarized as follows: A playbook entry is a map-

ping from an incident-asset type pair to a list of re-

sponse actions. For each asset type-response action

pair, certain rules apply for certain classes. These

rules restrict the conducting of the response actions

by deﬁning respective preconditions.

For this, we ﬁrst describe the types of assets and inci-

dents we considered. Afterwards, we introduce basic

classiﬁcations of assets, followed by the deﬁnition of

a basic rule set. At the end of this chapter we present

how these deﬁnitions are used in an SDN architec-

ture. The here described SDN-IR concept was de-

veloped for alerts which are either initiated by host-

based and network-based intrusion detection systems

or manually triggered, e.g. by an incident responder

for the purpose of activating intensive monitoring or

isolation of a certain component. Since this allows

a wide heterogeneity of incident types being handled,

we abstractly classify the incidents covered by our ap-

proach as compromised host, compromised network

component and malicious link, where hosts are net-

work participants and a link describes any identiﬁable

end-to-end connection (even if that connection is not

currently established). Furthermore, when we want

to refer to hosts and switches collectively, we use the

term node.

2.1 Response Actions

The incident response process can be divided into

seven phases: Preparation, Detection, Analysis, Con-

tainment, Eradication, Recovery and Post Incident

Activity (Cichonski et al., 2012). The actions we

identiﬁed for SDN-IR primarily support the Analy-

sis and Containment phases and are described in the

following paragraphs.

Isolate Host. Hosts can be isolated from the rest of

the network, if the incident suggests that they have

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

320

been compromised. This can be achieved by deploy-

ing high-priority ﬂow entries to the SDN switch the

device is directly connected to. Following the ﬂow

entries, the switch drops all packages from and to this

device.

Another strategy is the isolation of linked partners

from the rest of the network, but not from each other.

More generally, if a host is potentially compromised,

it might be necessary to isolate it from the rest of the

network. However, if it has a functionally critical link

to another host, it seems to be a valid strategy to keep

that link open. Since ﬂow entries can be deﬁned e.g.

for speciﬁc TCP/IP connections, this can be achieved

by deploying high priority ﬂow entries allowing the

critical link and lower priority ﬂow entries dropping

all packets from and to the host in question.

Isolate Switch. Like hosts, SDN switches can also

be isolated from the rest of the network. Such an in-

cident response action however has signiﬁcantly more

impact on the rest of the network than isolating a host.

Isolating switches can result in isolating other nodes

as well (cf. topology in ﬁgure 3 where isolation of

switch openﬂow:1 results in isolation of host3 and

switch openﬂow:6). In general, if any link cannot be

redirected via paths not containing the switch in ques-

tion, the availability of, for example, services is being

affected negatively. Thus, several conditions have to

be checked before isolating a switch (cf. section 2.3).

Block Links. Blocking certain links might be an

especially interesting approach against Denial-of-

Service attacks. For example, if a node within the

network is affecting others using a Denial-of-Service

attack, the links used for this attack can often be iden-

tiﬁed quickly and can then be blocked without iso-

lating the whole node which might be crucial for the

system. This example shows, blockage of links can

be chosen as a lighter alternative to the isolation of

whole nodes.

Mirroring/Packet Replicas. The arguably most

practical response is the replication of packets, e.g.

for monitoring. Whereas in traditional networking

special switches (or network TAPs) with the ability

to perform mirroring were needed, SDN can conduct

mirroring on every SDN switch by deploying respec-

tive ﬂow entries. This response action creates addi-

tional trafﬁc, but does not affect the network beyond

that. As already mentioned, (Di Lallo et al., 2017)

proposed an approach to minimize this effect.

If the replication of packets is performed to monitor a

host, the replication point or points can be chosen by

selecting all SDN switches the host is directly con-

nected to. If the monitoring of an SDN switch is de-

sired, the objective is generally a maximization of the

amount of monitored links directed over that switch.

For links between communication partners directly

connected to that switch, trustworthy monitoring is

only possible, if the switch to monitor is not a sus-

pect of compromising and can therefore replicate the

packets itself. Other links can be replicated by other

SDN switches along their paths.

Virtualization. As proposed by (Piedrahita et al.,

2018) it is possible to support a system under at-

tack with several virtualization strategies. For once

it might be possible to replace a host with its virtual

representation. This can even be extended towards

replacing physical processes with respective simula-

tions. The virtualization approach can therefore be

used to considerably improve the resilience of a sys-

tem. Even though this strategy is very promising and

worth more research, its complexity and heterogene-

ity disqualiﬁed it as part of our current research. How-

ever, the playbook approach we follow is sufﬁcient to

trigger such incident response actions as well.

Notiﬁcation. The SDN-IR solution can create no-

tiﬁcations which will be sent to conﬁgured contact

points, like an administrator’s email. The notiﬁca-

tion action can be beneﬁcial in several states of the

SDN-IR progress. It can be sent directly after an alert

is received, to inform the administrator and provide

ﬁrst reaction suggestions which, once permission is

granted, can be performed automatically. Further-

more, the notiﬁcation can be enriched with important

knowledge about the current network layout (or topol-

ogy) in order to support analysis and reduce reaction

time. In addition, the notiﬁcation can provide a report

about the actions taken during an automated incident

response. As already motivated in the introduction

(section 1), the here described response actions have

to be restricted for certain classes of assets. These

classes are explained in the following section.

2.2 Classiﬁcation of Assets

In this section, we introduce some basic classes of

hosts, network components and links. In various en-

vironments, it might be necessary to add more classes

or adapt the here deﬁned basic classes.

Certain nodes and links are critically important

e.g for controlling the production plant or to per-

form safety functions. Typically, the data transmis-

sion between hosts or via links may not be inter-

rupted, not even for containment. Such nodes and

Automated Incident Response for Industrial Control Systems Leveraging Software-deﬁned Networking

321

critical communication links are henceforth deﬁned

as functionally-critical.

Time sensitivity is an important requirement

within ICS. Certain links must meet speciﬁed time

conditions and adhere to them. These links are de-

ﬁned as time-critical.

Redundant network paths are incorporated in ICS

for two reasons: to increase the probability that, in

case of attack or disturbance, one of the paths remains

functional; and to increase total bandwidth power by

adding additional paths. For such redundant paths, it

is always important that the path contains a disjoint

set of physical transmission nodes. Hence redirecting

or interrupting redundant links might be undesired.

For this work, links instead of paths are classiﬁed as

redundant. If a link is classiﬁed as redundant more

than one path has to satisfy this link and the paths

have to be physically disjoint. Furthermore, hosts and

network components might also be classiﬁed as re-

dundant.

Typically links can belong to more than one class.

For example, functionally-critical and time-critical

links are common for safety systems.

2.3 Restrictive Rules

In the introduction, we already motivated why ICS

requirements have to be considered during the selec-

tion of applicable response actions from playbooks.

To enforce this consideration, a rule set has to be

available for the SDN-IR instance. We deﬁne this set

as restrictive, adjustable preconditions for response

actions taking into account ICS requirements. The

ICS requirements are expressed by the classes

described in section 2.2. We explain each rule and

deﬁne informal expressions wherever reasonable to

support a better understanding. The expressions are

composed of boolean statements. If the statements

result in the value true the respective action can be

performed and vice versa. We chose this additional

representation of rules to provide a valuable template

for implementations and extensions. The here pre-

sented rules are neither complete nor applicable for

every possible system. They only provide a starting

point to implement own specialized rule sets.

For the mentioned informal expressions the fol-

lowing deﬁnitions are needed:

• x ∈ N describes an index enumerating network

participants

• host

, mac

, ip

and port

represents a host, MAC

address, IP address and TCP/UDP port

• link

i, j

:= {host

,host

,mac

,ip

, port

port

} represents a link between host

and host

• L represents the set of known links

• path

i, j

represents a path from host

to host

as an

ordered set of switches

• time crit

(link) states that link is marked as time-

critical with a latency threshold of τ

• meets

(path) states that path can guarantee a la-

tency beneath τ

• path

link

represents the path of link

In production the deﬁnition of link

i, j

would generally

contain too much detail, since the ports (and eventu-

ally IP address) are not static. Thus, they have to be

replaced, e.g. by customized categories like “OPC

UA link between (host

,ip

) and (host

,ip

)”.

The following paragraphs describe our exemplary

rule set.

Blocking a Link. Links should not be blocked,

if they are classiﬁed as functionally-critical

(funct crit(link)). Thus, the corresponding rule

can be deﬁned as

block link(link

i, j

) := ¬funct crit(link

i, j

)(i 6= j) (1)

If a link is not classiﬁed as functionally-critical but

as redundant, it might be blocked, depending on the

severity of the incident.

Isolating a Host. A host should not be isolated, if it

is marked as functionally-critical or if isolation would

affect any link classiﬁed as functionally-critical. This

rule can be deﬁned as

iso host(host

) := ¬[funct crit(host

) ∨ ∃link

k,l

∈ L :

funct crit(link

k,l

) ∧ (k = i ∨ l = i)](i 6= j) (2)

If a link is not classiﬁed as functionally-critical but as

redundant, it might be still reasonable to isolate the

host, depending on the severity of the incident. Fur-

thermore, as mentioned in section 2.1, isolation of a

host with the exception of speciﬁc links is also possi-

ble.

Isolating a Switch. A switch can only be isolated

when each link classiﬁed as functionally-critical,

redundant and time-critical, directed through this

switch, can be redirected without using the switch.

Moreover, for links marked as time-critical, the re-

spective time requirements have to be met for their

new paths and links classiﬁed as redundant have to be

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

322

ensured to stay redundant. This rule can be deﬁned as

iso switch(switch) :=

∀link

i, j

∈ L : switch ∈ path

link

i, j

⇒

[funct crit(link

i, j

) ⇒ ∃path

i, j

: switch /∈ path

i, j

]

∧ [time crit

(link

i, j

) ⇒ ∃path

i, j

: switch /∈ path

i, j

∧ meets

(path

i, j

)]

∧ [redundant(link

i, j

) ⇒ ∃path

i, j

, path

i, j

switch /∈ path

i, j

∪ path

i, j

∧ path

i, j

∩ path

i, j

0](i 6= j) (3)

For the sake of complexity reduction the above ex-

pression is reduced to its essential statements. For ex-

ample, a link marked as time-critical and redundant

must have an alternative path which meets the time re-

quirements and is disjoint to the current backup path

(in order to be redundant). The expressed rule does

not yet take such combinations into account.

Monitoring a Host. The main issue in replicating

data from hosts for monitoring purposes is the intro-

duction of new trafﬁc between the replicating switch

and the monitoring system. Thus, the SDN manage-

ment might only need to verify that no link classiﬁed

as time-critical looses its real-time assurance when

the path between the replication switch and the mon-

itoring system is deployed.

Monitoring a Switch. When monitoring a switch,

as many links directed over that switch should be

monitored as possible. Assuming the switch can no

longer be trusted, a prerequisite to monitor such a

link is that its current path contains other switches

which can act as replicating switches. Just like for

“Monitoring a Host”, the only time-sensitivity and

availability restrictions for this action apply to the

path from the replicating switch to the monitoring in-

stance. Thus, for the replication path, the same time-

sensitivity checks have to be conducted as explained

for “Monitoring a Host”.

Virtualization. Since different possibilities lever-

aging virtualization for incident response exist, which

all need further research, rules for such techniques are

out of scope for this paper.

2.4 Architecture

Earlier, we described what incident response actions

can be executed with SDN (cf. section 2.1) and how

they can be restricted. Extending the SDN4S ap-

proach, we developed an architecture to build our

Figure 1: Overview of the here described SDN-IR architec-

ture.

SDN-IR approach with common SDN platforms (cf.

ﬁgure 1). We introduced the components Security De-

cision Engine (SDE) and Rule Library to the SDN4S

approach. The SDE receives alerts, e.g. from an IDS.

Upon receiving an alert, the SDE derives the match-

ing playbook from the Playbook Library. Since the

here described SDE relies on deterministic decisions,

we assume the existence of a matching playbook for

every possible received alert. Given the response ac-

tions suggested by the retrieved playbook and the type

of assets (i.e. host, switch or link) affected by or re-

sponsible for the incident, the SDE obtains the respec-

tive restrictive rules (cf. section 2.3) from the Rule

Library. Interpreting the rules, the SDE knows which

checks to perform for what assets, in order to decide

whether to perform an action or not. Like our basic

rules deﬁned in section 2.3, most rules will instruct

the SDE to perform certain checks on assets with spe-

ciﬁc classiﬁcations. For this, the classiﬁcations of

such assets have to be retrieved from corresponding

inventories, like the Host Inventory. If the SDE de-

cides to perform the response actions based on the

check results, it generates ﬂow entries either by it-

self, or by using the SDN’s ﬂow engine (cf. L2Switch

of OpenDaylight, section 3), which depends on the

speciﬁc implementation. Thus, the SDE is able to

use the intelligence of the ﬂow engine to ﬁnd the best

ﬂows for the current topology, e.g. when links have

to be redirected, or apply straight-forward ﬂow en-

tries (e.g. when a certain link has to be blocked).

The ﬂow entries are then deployed on or removed

from the switches via the Conﬁguration Interface (e.g.

Automated Incident Response for Industrial Control Systems Leveraging Software-deﬁned Networking

323

Figure 2: Simpliﬁed overview of the prototype implementa-

tion of the here proposed SDN-IR architecture (cf. section

2.4).

NETCONF

, OpenFlow (McKeown et al., 2008) or

SNMP

). The incident response ﬂow entries are de-

ﬁned with a higher priority than common ﬂow entries.

Therefore, old ﬂow entries, colliding with the SDE’s

ﬂow entries are ignored when packets have to be for-

warded. This way, the old state of the network can be

recovered easily if the measure gets repealed. The old

ﬂow entries will be immediately active again after the

SDE’s ﬂow entries were removed. For most actions,

this strategy might be preferable to removing original

ﬂow entries. Furthermore, when using NFV an imple-

mentation of the SDE could leverage existing security

controls like ﬁrewalls as well. For actions which can

be performed by such controls, this is a more consis-

tent approach than directly applying ﬂow entries.

3 EVALUATION

Our goal was the identiﬁcation of possible pitfalls

when it comes to the implementation of our concept

on a common SDN platform. Thus, for evaluating

our concept, we applied and extended the well es-

tablished OpenDaylight (ODL) framework (Medved

et al., 2014). The modular architecture of ODL al-

lowed us to build a customized SDN management

platform. A simpliﬁed overview of our prototype im-

plementation can be found in ﬁgure 2. To conserve

https://tools.ietf.org/html/rfc6241.html

https://tools.ietf.org/html/rfc1157

space, we only give a brief insight into our implemen-

tation.

In our implementation, the alerts are passed to

ODL via POST REST calls which consist of an as-

set id (e.g. openﬂow:1 cf. ﬁgure 3), an alert category

and a priority value. On the target side of this REST

call a RESTCONF (Bierman et al., 2017) interface re-

ceives the alert. The RESTCONF interface is applied

as a so called northbound interface in ODL which is

responsible for the communication between ODL and

external applications or users.

ODL’s database management is called Model-

driven Service Abstraction Layer (MD-SAL)

which

uses the modelling language YANG (Bjorklund,

2010) to deﬁne the database scheme. Among other

things, it is used to store ﬂows, switch conﬁguration

and topology information. We added our own models

to store additional host information (like identiﬁers,

status ﬂags and classiﬁcations (cf. section 2)), sub-

mitted alerts, the playbook and rule libraries. Further-

more, we extend the Flow Database (cf. ﬁgure 2) to

store classiﬁcation for links. This is a practical strat-

egy, chosen under the assumption that all conﬁgured

links are represented by persisted end-to-end ﬂow en-

tries. In consequence, for every link which should be

classiﬁed, e.g. as functionally-critical or redundant,

our prototype demands ﬂow entries being generated

in order to add the classiﬁcations to them.

The received alert ﬁrst gets persisted to the

database. Afterwards, the SDE gets invoked and is

given the alert’s identiﬁer. The SDE retrieves the new

alert from the database and queries the Playbook Li-

brary for actions to perform for the given combina-

tion of the alert category, asset type and priority. The

priority is used as an indicator for the severity of the

incident. In our case, the type of asset, can be deter-

mined via interpretation of the asset identiﬁer given

as argument of the REST call. The playbook received

as the response can be seen in listing 1.

SWI T C H

DE N I A L O F S E R V I C E

Pr i o r i t y . HIGH

Ac t io n T y pe . I S OL A T E

Ac t io n T y pe . N O TIF Y

Pr i o r i t y . L O W

Ac t io n T y pe . M O NI T O R

Ac t io n T y pe . N O TIF Y

Listing 1: Example playbook entry for switches on

DENIALOFSERVICE suspicion, which deﬁnes response

actions for two different alert priorities.

Subsequently, the SDE retrieves the rules from the

Rule Library using the combination of asset type and

https://wiki.opendaylight.org/view/OpenDaylight

Controller:MD-SAL:Developer Guide

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

324

action to perform (listing 2 shows an example rule for

asset type SWITCH and action ISOLATE).

SWI T C H

IS O L AT E

LINK S

fun c t ion a l ly - c r i t ic a l

{ red i re c t a b l e }

re d un d an t

{ red i re c t a b l e }

Listing 2: Example rule entry for switch isolation.

The resulting requirements are then checked by

ODL’s built-in functionality, like the NetworkGraph-

Service. For example, in listing 2: “links classiﬁed

as functionally-critical or redundant have to be redi-

rectable”. If the action’s requirements can be mapped,

the SDE generates the respective ﬂow entries, e.g.

to isolate the switch, and requests additional ﬂows

from the L2Switch, e.g. by creating a temporary

topology and letting the L2Switch generate the new

ﬂows for this topology. The ﬂow entries are sent to

an OpenFlow plugin (McKeown et al., 2008), which

we chose as the SDN controller’s interface towards

SDN switches (southbound interface). This interface

matches the Conﬁguration Interface of ﬁgure 1.

Despite the evaluation regarding the feasibility of

the implementation of our concept with current SDN

platforms, we were interested in its impact to the net-

work’s performance. To be able to set up various

topologies, we used Mininet

in version 2.2.0 for a

network emulator, which supports SDN switches and

external SDN controllers. We conﬁgured Mininet us-

ing our ODL implementation as external controller,

communicating with it via OpenFlow 1.3, using a

bandwidth limit of 10 MBit/s and a delay of 10

ms. Afterwards, we conducted several tests, namely

isolating hosts and switches, redirecting trafﬁc of

hosts and switches to the monitoring system as well

as blocking various links. These actions were per-

formed with and without classiﬁcations and on vari-

ous topologies. Furthermore, the latency and band-

width during the execution of the response actions

were measured. One of these topologies can be found

in ﬁgure 3. Amongst others, we used this topology to

test the isolation of a switch. This test had the most

signiﬁcant, measurable impact on the network, which

is the reason why here we use it as an example of our

results.

Figure 4 depicts the measured latency (using the

ping command) between host1 and host2 when the

isolation of switch openﬂow:1 is performed in second

12.

Before the isolation, the two hosts communicate

over the path (openﬂow:2, openﬂow:1, openﬂow:3).

http://mininet.org

Figure 3: Example topology we used for evaluation of our

prototype. The numbers next to the SDN switches index the

physical ports of each switch.

Figure 4: Latency measurement when isolating switch

openﬂow:1 in second 12.

Figure 5: Bandwidth measurement when isolating switch

openﬂow:1 in second 12.

After the isolation the new path (openﬂow:2, open-

ﬂow:5, openﬂow:4, openﬂow:3) was used. The pic-

ture shows that after the switch is isolated in sec-

ond 12, the latency slightly increases due to the ex-

tra hop in the new path. In contrast, the bandwidth

(measured using iPerf ) remains unchanged, besides a

Automated Incident Response for Industrial Control Systems Leveraging Software-deﬁned Networking

325

small slump in second 15 which can be traced back to

the adaptation to the new path (cf. ﬁgure 5).

During the validation we identiﬁed open tasks re-

garding the implementation in terms of a productive

usage. Our prototype currently only supports the

object-oriented deﬁnition of rules. This is closely

aligned to the way our program conducts the feasi-

bility analysis. In the future, a more general approach

would improve implementations, e.g. by providing a

respective speciﬁed rule language. Furthermore, if a

playbook’s action is refused, it is currently not pos-

sible to conﬁgure alternative actions. Even though

it is possible to add additional playbooks for the

same incident-asset-classiﬁcation combination, they

currently cannot be prioritized. In addition, whether

an alternative path can meet the time criteria of a

real-time link has to be determined by the controller

before the alternative path can be selected and sug-

gested to the SDE. This might then result in an SDE-

L2Switch negotiation to ﬁnd alternative paths. How-

ever, currently our implementation is lacking the sup-

port of the real-time calculation (and thus the nego-

tiation). As part of the project FlexSi-Pro

we are

currently developing a solution for this issue using

Time-Sensitive Networking

. In section 3, we pro-

posed the strategy to mimic the classiﬁcation of links

by classifying their respective ﬂow entries. In pro-

duction, it would be more reasonable to have a ded-

icated link representation within the SDN database,

e.g. within the topology inventory, and adding classi-

ﬁcations there. This slightly increases the necessary

development effort and the complexity of determin-

ing the links, but separates the link conﬁguration from

the currently available ﬂow entries and therefore does

not require end-to-end ﬂow entries being preconﬁg-

ured for every classiﬁed link. Thus, we are planning

to detach the link representations from ﬂow entries.

We are currently addressing these open tasks in

the mentioned project FlexSi-Pro and will deploy and

further develop our prototype in our ICS test labora-

tory (Pfrang et al., 2016).

4 CONCLUSIONS

In this work, we described an SDN-based solution for

automated incident response in ﬂexible ICS networks.

In contrast to previous research, our proposed solution

takes into account the multiple restrictions for auto-

mated incident response in an ICS, utilising restric-

tive rules and asset classiﬁcation. A basic, adaptable

https://www.wibu.com/uk/ﬂexsi-pro.html

http://www.ieee802.org/1/pages/tsn.html

set of such rules is described in this paper. Instead

of reinventing the wheel, we designed our solution to

be compliant with the already existing SDN4S con-

cept and built a prototype demonstrating the feasibil-

ity of the implementation of our approach on com-

mon SDN platforms. Based on this prototype, we

were able to evaluate our concept to identify remain-

ing issues and potential starting points for future re-

search. With this paper, we presented an enabler for

SDN-based incident response in environments which

have special restrictions, regarding incident response

actions affecting host, network components and com-

munication links.

REFERENCES

Bierman, A., Bjorklund, M., and Watsen, K. (2017). REST-

CONF Protocol. RFC 8040, RFC Editor. Last ac-

cessed on Dec, 2018.

Bjorklund, M. (2010). YANG - A Data Modeling Language

for the Network Conﬁguration Protocol (NETCONF).

RFC 6020, RFC Editor. Last accessed on Dec, 2018.

Bromiley, M. (2017). The Show Must Go On! The 2017

SANS Incident Response Survey. Analyst paper,

SANS. Last accessed on Dec, 2018.

Cichonski, P., Millar, T., Grance, T., and Scarfone, K.

(2012). Computer Security Incident Handling Guide

: Recommendations of the National Institute of Stan-

dards and Technology. National Institute of Standards

and Technology.

Di Lallo, R., Griscioli, F., Lospoto, G., Mostafaei, H.,

Pizzonia, M., and Rimondini, M. (2017). Leverag-

ing SDN to Monitor Critical Infrastructure Networks

in a Smarter Way. In Proceedings of the IM 2017

- 2017 IFIP/IEEE International Symposium on Inte-

grated Network Management, pages 608–611, Piscat-

away, NJ. IEEE.

Kim, H. and Feamster, N. (2013). Improving Network Man-

agement with Software Deﬁned Networking. IEEE

Communications Magazine, 51(2):114–119.

Koulouris, T., Casassa Mont, M. and Arnell, S. (2017).

SDN4S: Software Deﬁned Networking for Security.

Report, Hewlett Packard Enterprise. Last accessed on

Dec, 2018.

Martins, J. S. B. and Campos, M. B. (2016). A Security

Architecture Proposal for Detection and Response to

Threats in SDN Networks. In Proceedings of the 2016

IEEE ANDESCON, pages 1–4, Piscataway, NJ. IEEE.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar,

G., Peterson, L., Rexford, J., Shenker, S., and Turner,

J. (2008). OpenFlow: Enabling Innovation in Campus

Networks. ACM SIGCOMM Computer Communica-

tion Review, 38(2):69.

Medved, J., Varga, R., Tkacik, A., and Gray, K. (6/19/2014 -

6/19/2014). OpenDaylight: Towards a Model-Driven

SDN Controller architecture. In Proceeding of IEEE

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

326

International Symposium on a World of Wireless, Mo-

bile and Multimedia Networks 2014, pages 1–6. IEEE.

Pfrang, S., Kippe, J., Meier, D., and Haas, C. (2016). De-

sign and Architecture of an Industrial IT Security Lab.

In Testbeds and Research Infrastructures for the De-

velopment of Networks and Communities, pages 114–

123. Springer.

Piedrahita, A. F. M., Gaur, V., Giraldo, J., Cardenas, A. A.,

and Rueda, S. J. (2018). Virtual incident response

functions in control systems. Computer Networks,

135:147–159.

Automated Incident Response for Industrial Control Systems Leveraging Software-deﬁned Networking

327