A Security Evaluation Framework for Software-Deﬁned Network

Architectures in Data Center Environments

Igor Ivki

1,2

, Dominik Thiede

, Nicholas Race

, Matthew Broadbent

and Antonios Gouglidis

Lancaster University, Lancaster, U.K.

University of Applied Sciences Burgenland, Eisenstadt, Austria

Edinburgh Napier University, Edinburgh, U.K.

Keywords:

Network Security, Data Center Architecture, Software-Deﬁned Networks, Security Evaluation Framework.

Abstract:

The importance of cloud computing has grown over the last years, which resulted in a signiﬁcant increase of

Data Center (DC) network requirements. Virtualisation is one of the key drivers of that transformation and

enables a massive deployment of computing resources, which exhausts server capacity limits. Furthermore,

the increased network endpoints need to be handled dynamically and centrally to facilitate cloud computing

functionalities. Traditional DCs barely satisfy those demands because of their inherent limitations based on

the network topology. Software-Deﬁned Networks (SDN) promise to meet the increasing network require-

ments for cloud applications by decoupling control functionalities from data forwarding. Although SDN

solutions add more ﬂexibility to DC networks, they also pose new vulnerabilities with a high impact due

to the centralised architecture. In this paper we propose an evaluation framework for assessing the security

level of SDN architectures in four different stages. Furthermore, we show in an experimental study, how the

framework can be used for mapping SDN threats with associated vulnerabilities and necessary mitigations in

conjunction with risk and impact classiﬁcation. The proposed framework helps administrators to evaluate the

network security level, to apply countermeasures for identiﬁed SDN threats, and to meet the networks security

requirements.

1 INTRODUCTION

Over the last years, the evolution of cloud comput-

ing has triggered a rethinking of the entire Data Cen-

ter (DC) network architecture (Bilal et al., 2012).

One of the main drivers for cloud computing is vir-

tualisation, which enables a massive deployment of

computing resources like Virtual Machines (VMs)

(Eswaraprasad and Raja, 2017). However, the rise

of cloud computing impacts legacy Data Center Net-

works (DCN) since the number of network endpoints

increases, and the Central Processing Unit (CPU)

capacity and amount of Random-Access Memory

(RAM) of the servers become limiting factors. Ad-

ditionally, VMs are dynamically created on-demand

and can be deleted or moved in the same way. These

circumstances bring new requirements to DCN, since

(especially in large scale environments) former com-

munication networks and DCs used specialised and

costly hardware equipment.

Software-Deﬁned Networks (SDN) aim at provid-

ing solutions for these challenges by adding more

ﬂexibility compared to traditional DCN. SDN is an

emerging architecture that decouples the control plane

from the data plane. This separation facilitates the

shift of the network control from network devices

towards a logically centralised software-based en-

tity called an SDN controller. The SDN controller

resides in the control plane, where centralised for-

warding tables are calculated and pushed to the net-

work elements living in the data plane. Through the

SDN architecture, the network control becomes pro-

grammable and provides an abstracted layer where

application and network services are applicable. This

new solution enables a dynamic, cost-effective, man-

ageable and adaptable network solution matching the

increasing network requirements for ambitious cloud

applications (Chica et al., 2020). Even though the new

SDN architecture opens up new possibilities, it also

brings new security challenges.

Compared to traditional network architectures

consisting of many distributed forwarding devices the

network intelligence is now aggregated in a single vir-

tualised SDN controller. This centralisation of the

Ivki

c, I., Thiede, D., Race, N., Broadbent, M. and Gouglidis, A.

A Security Evaluation Framework for Software-Deﬁned Network Architectures in Data Center Environments.

DOI: 10.5220/0011988300003488

In Proceedings of the 13th International Conference on Cloud Computing and Services Science (CLOSER 2023), pages 277-288

ISBN: 978-989-758-650-7; ISSN: 2184-5042

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

277

network control is one of the most signiﬁcant advan-

tages and, at the same time, the biggest weakness of

the SDN topology. A successfully launched cyber-

attack where the SDN controller or application is

compromised has the potential to affect the entire net-

work (Al-Saghier, 2019). Network security is highly

prioritised in DC environments; especially when criti-

cal infrastructures are involved, a DC outage resulting

from an attack could have disastrous consequences.

In this paper we present a Security Evaluation

Framework for SDN architectures in DC environ-

ments. Similar to the work of Anisetti et al. (2021),

the framework consists of four phases where the out-

put of one phase is used as an input for the next one.

In the ﬁrst phase a threat and vulnerability analy-

sis is performed based on Spooﬁng, Tampering, Re-

pudiation, Information Disclosure, Denial of Service

(DoS), Elevation of Privilege (STRIDE) and Process

for Attack Simulation and Threat Analysis (PASTA)

(UcedaVelez and Morana, 2015). Next, a risk and im-

pact evaluation is executed for each identiﬁed threat

and vulnerability, including ranking each risk by its

severity by using the Common Vulnerability Scoring

System (CVSS). Based on the results of the CVSS,

attack scenarios are modelled for the highest-ranked

risks. Furthermore, we verify the impact of the mod-

elled attack scenario in an experimental study us-

ing a basic SDN setup consisting of Mininet (Kaur

et al., 2014) and one Open Network Operating Sys-

tem (ONOS) controller. Finally, we discuss how the

identiﬁed SDN threats could be mitigated by either

using built-in features or by implementing a central

security solution.

The remainder of this paper is organised as fol-

lows: Section 2 summarises the related work in the

ﬁeld. Next, in Section 3, we present the Security Eval-

uation Framework and explain how it can be used to

evaluate the security of SDN-components. Further-

more, we show the general applicability of the pro-

posed framework in an experimental study in Section

4. Finally, in Section 5 we conclude our work and

give an outline of future work in the ﬁeld.

2 RELATED WORK

Since SDN are increasingly becoming more relevant

in the cloud computing ﬁeld, more and more security

evaluations and tests have been performed on the new

architecture. Ruffy et al. (2016) used the STRIDE

model to identify several SDN vulnerabilities and

proposed solutions for each of the six security risks

to mitigate them. Based on that they sketched a sam-

ple of secure SDN design for two network domains.

Their design integrated multiple SDN controllers for

redundancy together with traditional and new protec-

tion solutions, including Intrusion Detection Systems

(IDS), ﬁrewalls, and access control via Authentica-

tion, Authorisation, Accounting (AAA) servers. Nev-

ertheless, they considered just one threat analysis ap-

proach based on six generic Threat Categories (TCs),

which leads to unrecognised security ﬂaws that are

not part of the STRIDE categories.

Iqbal et al. (2019) identiﬁed several SDN vulner-

abilities and possible attack scenarios including their

impacts and focused on possible resolutions for their

determined SDN security ﬂaws. Their proposed so-

lution concentrated on the communication channels

between the SDN layers instead of considering the

entire SDN. Therefore, the resolution proposals are

limited to data encryption via Secure Sockets Layer

(SSL)/Transport Layer Security (TLS), ciphers like

Advanced Encryption Standard (AES) and Data En-

cryption Standard (DES) and role-based authorisation

adapted from FortNOX3 instance. Iqbal et al. (2019)

outlined a summary showing the correlation between

attack scenario, affected SDN layer/interface, and se-

curity. However, in contrast to the approach of Ruffy

et al. (2016), the threat analysis and countermeasure

proposal from Iqbal et al. (2019) is solely based on a

literature review.

Varadharajan et al. (2019) have discussed a

policy-based security architecture for SDN and cat-

egorised SDN-speciﬁc threats into (1) threats against

an SDN controller, (2) threats against the networking

devices (switches), (3) threats against communication

between the controller and the networking devices,

and (4) threats against communications between dif-

ferent SDN controllers. Based on those categories

they determined ﬁve attack scenarios and four secu-

rity requirements to prevent the successful execution

of the attacks. They developed a policy-based security

application that resides on the northbound interface of

the SDN controller to meet the previously identiﬁed

security requirements. Furthermore, they analysed

the performance of their policy-based security archi-

tecture as well as discussed, the capabilities to coun-

teract various security attacks and meet different se-

curity requirements using policy-based mechanisms.

Even though the approach is promising, their policy-

based mechanism provides one option to overcome

security ﬂaws in SDN. Considering that one counter-

measure does not ﬁx all vulnerabilities, an appropri-

ate solution should include several remediations to in-

crease the security of the entire SDN.

Chica et al. (2020) conducted an SDN secu-

rity analysis where they highlighted network attacks,

threat vectors, and attack surfaces on all three SDN

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

278

layers and the interfaces in between. In this re-

gard, they discussed to what extent SDN can increase

network security and how SDN security can be im-

proved. In addition, they brieﬂy discussed potential

ﬂaws and inconsistencies still present in the design of

security mechanisms for SDN. Moreover, they men-

tioned potential attack scenarios and their possible

impact on the network. However, they did not con-

sider the technical implementation of those attacks

and how the network impact can inﬂuence their SDN.

Al-Saghier (2019) proposed a framework for eval-

uating SDN security that is capable of automatically

instantiating known attacks against SDN elements.

The framework was implemented by adding addi-

tional components to the SDN topology, particularly

the agent manager, application agent, agent chan-

nel, and agent host. Furthermore, misconﬁguration,

malware, and insider attacks were categorised as at-

tack vectors. Finally, he provided a Proof-of-Concept

(PoC) SDN testbed and evaluated the impact on the

network when running different attack scenarios.

Sjoholmsierchio et al. (2021) focused on strength-

ening SDN security by improving the TLS encryption

for OpenFlow. According to them, TLS is currently

the only mechanism for protecting the control chan-

nel and is only considered an optional basis. Based

on their claim that TLS is vulnerable to downgrade at-

tacks, they used a protocol dialecting approach to pro-

tecting the TLS encrypted OpenFlow protocol against

it. In addition to that, they conceptualised a new form

of policy-based networking by extending the proto-

col dialecting functionality into a policy enforcement

proxy. Finally, they simulated a downgrade attack

in a Mininet-emulated SDN environment and demon-

strated how their proposed security mechanism could

be used to detect and prevent these attacks. Their re-

sults showed a higher security level on the control

channel at the cost of increased communication la-

tency by 22% compared to standard TLS.

Shaghaghi et al. (2020) presented a brief overview

of the latest security enhancements in the SDN data

plane. Furthermore, they identiﬁed ﬁve character-

istics of SDN that can have the most impact on its

security. These characteristics include a centralised

controller, open programmable interfaces, forwarding

device management protocol, third-party network ser-

vices and virtualised logical networks. They provided

an appropriate overview of SDN characteristics prone

to exposing security vulnerabilities. In detail, they

highlighted the data plane security challenges, solu-

tion requirements, and existing solutions.

Jiasi et al. (2019) designed a monolithic security

mechanism for SDN based on Blockchain. Their sug-

gested solution decentralises the control plane while

maintaining a network-wide view. Furthermore, their

mechanism guarantees authenticity, traceability, and

accountability of application ﬂows and provides ﬁne-

grained access control of network-wide resources and

a secure controller-switch channel. They achieved

this by adding a Blockchain layer between the con-

trol and data plane. In addition, they added attribute-

based encryption for access control at the northbound

interface and a high-performance securely authenti-

cated protocol, called HOMQV, for communication

between the Blockchain and the data layer. In conclu-

sion, the Blockchain-based mechanism can be used to

record all network ﬂows and events including an im-

plementation of secure protocols with smart contracts.

Kreutz et al. (2013) described several threat vec-

tors that may enable the exploit of SDN vulnerabil-

ities and sketched a design of a secure and depend-

able SDN controller platform. They identiﬁed seven

different attack vectors and discussed several mecha-

nisms to address their threats. Their proposed con-

troller platform design introduced three SDN con-

trollers (instead of one) to improve the system’s de-

pendability through replication. In addition, their de-

sign sketch included the requirement that the switches

need to associate with more than one controller dy-

namically. Moreover, they explained that the repli-

cation between the controllers should not rely on a

single one to leverage the diversity in the controller

platform. Their proposed design to increase the se-

curity and dependability of SDN is mainly based on

using several SDN controllers which is already appli-

cable in DCNs or other large-scale networks.

Prathima Mabel et al. (2019) gave a brief in-

sight into vulnerabilities of OpenFlow and counter-

measures to secure the SDN controller, data plane,

and OpenFlow channel. Furthermore, they presented

the “ﬂow tracer”-solution for securing the SDN con-

troller from being misused. Their solution can iden-

tify and isolate fraudulent ﬂow entries that a hacker

may inject. In addition, the ﬂow tracer encrypts the

packets towards the data plane using symmetric key

encryption. Finally, they simulated a DoS attack in

the Mininet emulator to validate their proposed solu-

tion. Overall, they showed that this single mechanism

can be an effective countermeasure since it can im-

prove the security of the SDN controller, data plane

and OpenFlow channel.

Cabaj et al. (2014) highlighted three considera-

tions regarding SDN security and proposed a theo-

retical solution to detect SDN threats through data

mining. The three mentioned SDN drawbacks in-

cluded (1) limitation of the OpenFlow protocol, (2)

centralised network operations, and (3) lack of mid-

dleboxes in SDN. Their proposed solution, called

A Security Evaluation Framework for Software-Deﬁned Network Architectures in Data Center Environments

279

Table 1: Summary of Related Work on Evaluating Security in SDN (template adapted from Scott-Hayward et al., 2013).

Related Work

Security

PoC

SDN Layer/Interface

Analysis Remediation

New Security

Solution

App App-Ctl Ctl Ctl-Data Data

Ruffy et al. (2016) ✗ ✓ ✗✓ ✗✓ ✗✓ ✗✓ ✗✓

Iqbal et al. (2019) (✗) (✓) ★ ✗✓ ✗✓★ ✗✓ ✗✓★ ✗✓

Varadharajan et al. (2019) ★ ★ ★ ★ ★

Chica et al. (2019) (✗) (✓) ✗✓ ✗✓ ✗✓ ✗✓ ✗✓

Al-Saghier (2019) (✗) ✗ ✗ ✗ ✗

Sjoholmsierchio et al. (2021) ★ ★ ★

Shaghaghi et al. (2020) (✗) (✓) ✗ ✗ ✗ ✗ ✗✓

Jiasi et al. (2019) ★ ★ ★ ★ ★ ★ ★

Kreutz et al. (2013) (✗) (✓) ★ ✗✓ ✗✓ ✗✓★ ✗✓ ✗✓

Prathima Mabel et al. (2019) (✗) (✓) ★ ★ ✗✓★ ✗✓★ ✗✓★

Cabaj et al. (2014) ★ ★

Fawcett et al. (2018) ★ ★ ★ ★ ★

This Paper ✗ (✓) ✗ ✗✓ ✗✓ ✗✓ ✗✓ ✗✓

aaa✗aSecurity Analysisaaaaa✓aSecurity Remediationaaaaa★aNew Security Solutionaaaaa() Fully Based on Literature Review

Distributed Frequent Sets Analyzer (DFSA), allows

fast detection of attacks that generate massive trafﬁc.

DFSA implements different modules in the SDN ar-

chitecture to facilitate an automatic reaction as soon

as a threat is detected which protects the SDN con-

troller against DoS attacks.

Fawcett et al. (2018) introduced a multi-level dis-

tributed monitoring and remediation SDN framework

for scalable network security called TENNISON. In

this regard, they brieﬂy described the main attributes

of their proposed security framework, including ef-

ﬁciency and proportionality, scalability and visibil-

ity, p programmability and extensibility, transparency,

availability and resiliency, and interoperability. The

TENNISON architecture is based on the ONOS con-

troller and several appliances distributed across the

application, coordination, and collection layers in a

top-down manner. In addition, TENNISON provides

a security pipeline with four ﬂow tables prepended

for the other network application tables. This ap-

proach achieves network monitoring and remediation

without interfering with forwarding functionality and

other network services. Fawcett et al. (2018) cre-

ated a PoC testbed with 350 nodes and 19 switches in

Mininet to evaluate the scalability, analysis, and per-

formance of TENNISON using four attack scenarios

including DoS, DDoS, scanning, and intrusion.

As shown in Table 1, the identiﬁed related work

focuses on performing security analyses, remediation

or providing new security solutions. Some authors

even used a combination of multiple approaches and

covered multiple aspects. Various researchers vali-

dated their developed solution using a testbed setup,

while others argued their suggested solution on a the-

oretical level. One of the most signiﬁcant differences

of the identiﬁed related work is the amount of consid-

ered SDN layers/interfaces. For a comprehensive se-

curity analysis, all ﬁve SDN main components (three

layers and two interfaces) should be part of the evalu-

ation. However, several authors concentrated on spe-

ciﬁc parts of the SDN architecture and did not pro-

vide a holistic view including all SDN components.

Compared to the identiﬁed related work, this paper

(1) analyzes threats and vulnerabilities based on the

STRIDE and PASTA model on the entire SDN archi-

tecture, (2) examines risks and impacts on a DC envi-

ronment with the aid of CVSS, (3) models attack sce-

narios for the most critical security ﬂaws and veriﬁes

their impact in a PoC testbed, and (4) highlights meth-

ods to improve the SDN security. The output of this

approach is a comprehensive SDN Security Evalua-

tion Framework, enabling the DC owners to evaluate

the security level of their networks including possible

subsequent impacts and provide them with remedia-

tions to mitigate elaborate security risks. Table 1 pro-

vides an overview of the identiﬁed related work and

draws a comparison to this paper.

3 SECURITY EVALUATION

FRAMEWORK

The architectural recomposition triggered by SDN

brings up exciting opportunities to DCN. Mainly dis-

tributed cloud applications hosted in DCs beneﬁt from

the emerging solution. However, from a security per-

spective the SDN topology creates new challenges,

since the centralisation of the network control can be

a strength and weakness at the same time. More pre-

cisely, the entire network is affected as soon as the

SDN controller or application is compromised (Al-

Saghier, 2019). In this section we present an SDN

Security Evaluation Framework and describe its four

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

280

Figure 1: Security Evaluation Framework for SDN Architectures in DC Environments.

stages. In this regard, we explain how the frame-

work can be used to identify threats and vulnerabil-

ities, analyse their risks and impact, model possible

attack scenarios and apply countermeasures to miti-

gate them (as shown in Figure 1).

3.1 Threat & Vulnerability Analysis

Since an SDN controller represents a single point of

failure for the entire network, Ruffy et al. (2016) sug-

gest performing a risk-beneﬁt analysis when consid-

ering deploying SDN technology. However, before

assessing risks, threats must be identiﬁed ﬁrst. Since

many threats could be relevant for a security evalu-

ation, threat groups or categories are typically used.

The STRIDE model developed by Microsoft is a com-

mon approach to distinguish security design ﬂaws on

a technical basis and is therefore feasible for the se-

curity assessment of SDN (Ruffy et al., 2016).

Categorising threats with the aid of STRIDE is

helpful to get an overview of the relevance of certain

threat groups. Still, product managers and supervi-

sors are keen to know which threats are relevant to

their business, product, and platform. The STRIDE

model categories may not include speciﬁc threats

to SDN. Therefore, a far-reaching risk-based threat

modelling methodology, called PASTA also needs to

be considered. PASTA integrates business impact,

inherent application risk, trust boundaries across ap-

plication components, correlated threats, and attack

patterns that exploit identiﬁed weaknesses from the

threat modelling. This methodology helps to model

SDN-speciﬁc threats and assess their business impact.

Summarising, the ﬁrst stage of the Security Evalua-

tion Framework incorporates both the STRIDE and

PASTA approaches to evaluate SDN-based security

threats and vulnerabilities.

3.2 Risk & Impact Analysis

Once the SDN threats and vulnerabilities have been

identiﬁed in the ﬁrst step, the next step requires to

categorise them based on their impact to the DC en-

vironment. Threats with similar impact are then com-

bined to TCs which enables a faster risk and impact

analysis. In order to achieve such classiﬁcation, the

outcomes from the STRIDE and PASTA analysis are

compared to eliminate possible redundancies. The ap-

proach to deﬁning the TCs follows the reverse way

compared to the PASTA analysis. During the PASTA

assessments, root and sub-threats were determined,

and afterwards, attack scenarios and vulnerabilities

were derived from the threats. For categorising the

security ﬂaws, the effect on the SDN is ﬁrst deﬁned,

and later, the threat correlation occurs.

Next, a risk and impact analysis has to be per-

formed using the Common Vulnerability Scoring Sys-

tem (CVSS). For applying the CVSS scoring system,

the National Vulnerability Database (NVD) provides

a CVSS calculator which calculates a score in the

range between 0 and 10. Based on that score the

severity of the TCs can be mapped to one of the fol-

lowing ﬁve categories:

Table 2: CVSS Scoring with Severity Base Score Mapping.

Severity Base Score Range

Critical 9.0 - 10.0

High 7.0 - 8.9

Medium 4.0 - 6.9

Low 0.1 - 3.9

None 0.0

The CVSS scoring calculates a base score and an

overall score for each identiﬁed threat. The base score

is the foundation for determining the severity, while

the overall score represents the severity under consid-

eration of the environmental metric group. In case the

overall score is higher than the base score, the TC has

A Security Evaluation Framework for Software-Deﬁned Network Architectures in Data Center Environments

281

a higher impact on the environment as assumed by the

threat examination and vice versa. Summarising, the

second stage of the Security Evaluation Framework

uses a standardised approach (CVSS) to calculate the

severity and impact on SDN DC environments of the

previously identiﬁed threats and vulnerabilities.

3.3 Attack Modelling

After identifying threats and vulnerabilities and com-

pleting a risk and impact analysis, the third stage

focuses on the creation of attack scenarios validat-

ing their impact against an SDN testbed. The over-

all goal at this stage is to validate the results from

the risk and impact analysis by modelling attacks for

each TC. This could either be done on a real SDN-

based DCN, or by creating a close-to-reality test en-

vironment (testbed) where the attacks can be exe-

cuted without disrupting the production environment.

Furthermore, in some cases it might make sense to

choose between which TCs should be tested based

on the calculated CVSS score. For instance, the at-

tacks are modelled for the most likely and most crit-

ically ranked threats ﬁrst before evaluating the other

(less likely and less critical) ones. Summarising, the

third stage suggests conducting an experimental study

where attacks are modelled which provides an addi-

tional measure to ensure the correctness of the SDN

Security Evaluation Framework.

3.4 Threat & Vulnerability Mitigation

The ﬁnal stage of the framework provides counter-

measures that can be applied to mitigate identiﬁed

threats and therefore improve the overall SDN secu-

rity. In general, SDN countermeasures can be divided

into two main categories that either include methods

that mitigate speciﬁc threats (e.g., man-in-the-middle

attacks) or that increase the security of multiple SDN

components and prevent several types of attacks (e.g.,

Policy-based SDN Security). Mitigations within the

ﬁrst category can be directly mapped to the SDN iden-

tiﬁed threats from Stage 1 of the Security Evalua-

tion Framework. Such a correlation supports the user

of this framework in applying necessary countermea-

sures to mitigate identiﬁed threats and vulnerabilities

of their SDN. Those mitigations typically do not re-

quire a complex implementation of external tools or

software. Instead, the underlying Operating System

(OS) or protocols used in SDN environments often

provide functionalities to improve security, and it de-

pends on the administrator to enable them.

The second category of mitigations provides a

more central solution. Instead of applying counter-

measures against each identiﬁed SDN threat, a more

generic solution can be implemented to secure the

network against several attack types of multiple SDN

components. These solutions usually go along with

a complex and more time-consuming integration of

external systems. On the one hand, this approach

prevents several threats with one solution. On the

other hand, implementing such mitigations requires

external systems that have the potential of introduc-

ing new vulnerabilities to the SDN. Summarising, the

ﬁnal stage considers both categories to complete the

Security Evaluation Framework for SDN in DC envi-

ronments.

4 PROOF-OF-CONCEPT STUDY

4.1 Experimental Testbed

For the PoC evaluation a testbed was implemented

that simulates the basic functionalities of an SDN in

DC environments and follows a simple architecture

to reduce any unnecessary functionality overhead. In

order to achieve the right balance between simplicity

and functionality the testbed uses Mininet for creat-

ing a virtual SDN using process-based virtualisation

and network namespace features as provided by re-

cent Linux kernels. Mininet simulates links as vir-

tual ethernet pairs which reside in the Linux kernel

and connect the switches with the hosts. The Open

vSwitch (OVS) is software-based and uses the Open-

Flow controller communication protocol which is a

key feature for SDN simulation (Mininet, 2022).

Even though Mininet can emulate a rudimen-

tary SDN controller, this controller does not provide

enough functionalities for the test network. For this

reason, a separate SDN controller is necessary to sim-

ulate functionalities from DC environments, for in-

stance, multi-tenancy. The ONOS SDN controller is

used as an external controller to manage the switches

hosted by Mininet. The combination of the emulated

network hosted by Mininet and the ONOS SDN con-

troller provides a suitable base for designing a testbed

for the PoC evaluation.

The architecture of the test network is designed

as simple as possible but simultaneously complex

enough to measure the impact of the different attacks.

The test network topology consists of one SDN con-

troller connected to three switches, with links to three

VMs each (shown in Figure 2). The SDN applica-

tions are not running on a separate machine; instead,

the ONOS controller is a platform where SDN appli-

cations can be installed directly (ONOS, 2014). One

of those applications is Virtual Private LAN Service

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

282

Figure 2: SDN Testbed using Mininet, ONOS Controller and VPLS Services for Network Isolation.

(VPLS), used in the testbed to isolate multiple do-

mains from each other (Lasserre & Kompella, 2007).

This way, multi-tenancy can be simulated, which is a

crucial functionality for SDN in DC environments.

The testbed was conﬁgured in a way that hosts can

only reach other hosts from the same VPLS. This ser-

vice is later used in the testbed to verify whether cer-

tain attack scenarios can bypass the isolation or re-

conﬁgure the service and allow the communication

between isolated hosts. In order to run different attack

scenarios (Stage 3 of the Security Evaluation Frame-

work) against the testbed, an additional node running

Kali Linux is used. Kali Linux is an open-source,

Debian-based Linux distribution aimed at advanced

penetration testing and security auditing. This pro-

vides several tools to test the security in various cate-

gories, such as penetration testing, security research,

computer forensics and reverse engineering. Due to

the comprehensive security tools, Kali is a suitable

source to attack the SDN-based testbed.

4.2 Experimental Study

As shown in Figure 1, the ﬁrst stage of the Secu-

rity Evaluation Framework suggests to perform an

SDN Threat & Vulnerability Analysis using STRIDE

and PASTA. The main SDN components were inves-

tigated separately for all six threats of the STRIDE

analysis. Afterwards, the PASTA model was adapted

to analyze SDN environments. The modiﬁed PASTA

model composed of three steps was used to execute

an SDN threat and vulnerability analysis. The analy-

sis identiﬁed four root threats subdivided into 18 sub-

threats and linked to the same amount of vulnerabili-

ties, as summarised in Table 4 and Table 5 in the Ap-

pendix (Output 1). Additionally, it turned out that the

SDN threats are similar to traditional network threats.

However, due to the SDN architecture’s centralisation

and the SDN components’ dependencies, the same

threats have different impacts on the DC environment.

In Stage 2, the identiﬁed threats with the same im-

pact on the DC environment were aggregated into cat-

egories to eliminate impact redundancies. Next, the

CVSS methodology was used to rank the TCs based

on their impact severity on a DC environment. As

shown in Table 3, the TC with a critical or high sever-

ity can potentially harm the entire DC environment

and need to be mitigated ﬁrst. Table 3 shows all 14

TCs, their base and overall score, and severity classes:

Table 3: CVSS Results ordered by TC-Severity (Output 2).

In Stage 3, three attack scenarios are modelled for

the three highest-ranked TCs from the previous stage.

These attack scenarios are then executed on the ex-

perimental testbed which has been deployed without

A Security Evaluation Framework for Software-Deﬁned Network Architectures in Data Center Environments

283

any hardening. That means no countermeasures to in-

crease the security of the testbed have been applied.

This allows to verify the impact of an attack against

the SDN in case security measures are not considered.

The following three attack scenarios have been exe-

cuted (Output 3):

• Brute Force Attack: this attack was executed

ﬁrst on the ONOS controller by using four tools

on the Kali VM. The fastest tool (Patator) cracked

the ONOS default password in 4 seconds, while

the slowest (THC Hydra) took ≈ 22 minutes.

• Man-in-the-Middle Attack: this attack was exe-

cuted on the Mininet VM where packets were cap-

tured for the ICMP, Telnet, and OpenFlow proto-

cols. All trafﬁc was analyzed with Wireshark, and

it was possible to expose the entire SDN testbed

including network services. The same attack also

facilitated eavesdropping on an entire Telnet ses-

sion, including login credentials.

• DoS Attack: the DoS attack in the form of an

SYN ﬂood attack was executed from the Kali VM

against the OpenFlow port (6653) of the ONOS

controller. With the aid of the hping3 tool, over

4 Mio. SYN packets were sent to the controller,

which caused a trafﬁc interruption between all

hosts within their VPLS after 8 seconds and de-

stroyed all three VPLS services. Due to the dis-

rupted network services, the data trafﬁc did not

recover, which required a VPLS service reconﬁg-

uration to restore the testbed to its initial state.

Finally, in Stage 4 the Security Evaluation Framework

provides countermeasures for mitigating the identi-

ﬁed and ranked threats and vulnerabilities from the

previous stages. For the ﬁrst category, the mitiga-

tions can be directly mapped to the identiﬁed SDN

threats from Stage 1. In Table 6, we have identiﬁed 18

mitigations (M1 – M18) that can directly be mapped

to the previously identiﬁed threats (T1 – T18) from

Stage 1. Moreover, Table 6 provides speciﬁc coun-

termeasures per threat based on the MITRE Corpora-

tion and OWASP . The presented mitigations (M1 –

M18) typically do not require a complex implementa-

tion of external tools or software. Instead, the OS or

protocols used in SDN environments already provide

functionalities to improve security, and it depends on

the admin/operator to enable such measures. For in-

stance, the threat (T6) ”Network Snifﬁng” can be mit-

igated by applying encryption for sensitive data (M6).

Data encryption via TLS is a built-in feature of the

OpenFlow protocol but is disabled by default. En-

abling TLS for the OpenFlow channel increases secu-

rity. Furthermore, the man-in-the-middle attack from

Stage 3 (Attack Modelling) showed how much infor-

mation about the SDN could be exposed when the

OpenFlow protocol is not encrypted.

For threats where the corresponding mitigations

are not applicable (M5 and M7), preventive controls

are difﬁcult to apply since the threat exploits system

features. However, that does not mean that there is

no countermeasure present at all. Mitigations in the

second category can protect the SDN against such

threats by using a central solution. Instead of applying

countermeasures against each identiﬁed SDN threat,

a more generic solution is implemented to secure the

network against several attack types on multiple SDN

components. These solutions usually go along with a

complex integration of external systems.

One of the solutions to mitigate several attack

types is the Policy-Based SDN Security Architecture

(PbSA) which is a security application implemented

in the northbound interface of the SDN controller.

The main objective of the PbSA is a security policy-

based authorisation of ﬂows in an SDN environment.

The security policies use different ﬂow parameters to

authorise ﬂows within the SDN. The policy adminis-

trator can specify ﬁne-grained security policies based

on various attributes such as users, devices, or Au-

tonomous Systems (AS). Furthermore, the PbSA en-

forces a default deny policy which drops ﬂow requests

that are not permitted explicitly. The PbSA contains

an additional module to secure the communication

between network devices with the aid of distributed

keys. A novel feature includes path-based policies

establishing an alternative path through the network

when the original path is blocked (e.g., DoS) (Varad-

harajan et al., 2019).

The PbSA mitigates several threats across multi-

ple SDN layers. For instance, it can detect DoS at-

tacks, block suspicious ﬂows and redirect the data

trafﬁc over alternative paths. Furthermore, the archi-

tecture is capable of blocking all trafﬁc (e.g., drop-

ping malicicious ﬂows or denying misconﬁgured ser-

vices) by default that does not satisfy a permit policy

which represents an extra security layer in form of

an internal SDN ﬁrewall. Moreover, the new module

ensures a secure communication between several net-

work devices by mitigating the ”Network Snifﬁng”-

threat (T6) which enhances the SDN security for the

control and data plane, and the southbound interface.

Another central solution was proposed by Weng

et al. (2019) which is based on a Blockchain layer

between the SDN controller and the data plane.

Attribute-based encryption is used to ensure a ﬁne-

grained access control for encrypted data at the

northbound interface. For the communication be-

tween the Blockchain layer and the data layer they

establish the HOMQV protocol. The Blockchain

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

284

Figure 3: Correlation Map for SDN Threats, Vulnerabilities, and Mitigations (Output 4).

layer provides functionalities of resource-sharing and

resource-recording among multiple SDN controllers

on the control plane. Therefore the Blockchain is used

to record the network resources of each controller and

to share recorded resources (network events) among

all controllers to ensure the same network view.

The Blockchain notes all application ﬂows and

network events associated with the respective network

condition. Such information is stored as a raw trans-

action in the Blockchain. Furthermore, smart con-

tracts are used to implement security protocols, for

instance, to alert the failure of an SDN controller.

In addition, the controllers participating in the un-

derlying Blockchain send their recorded network data

(from the application and data layer) as raw transac-

tions into the Blockchain. This makes the Blockchain

layer a real-time reliability instance of all recorded

application ﬂows and all time-series of the network-

wide views. The proposed solution provides mono-

lithic security mechanism for each SDN component

that can also mitigate threat T5 which cannot be eas-

ily mitigated with preventive controls since it is based

on the abuse of system features. However, due to the

introduced Blockchain layer and HOMQV protocol,

this security mechanism provides secure authentica-

tion for applications, controllers and switches.

Another way of mitigating several threats with

a central solution was developed by Fawcett et al.

(2018) where they provided a multi-level distributed

monitoring and remediation SDN framework for scal-

able network security called TENNISON. The TEN-

NISON framework presents an adaptive and extensi-

ble security platform that is technology-independent

and qualiﬁed to support a wide range of security

functions. The TENNISON security framework is a

comprehensive solution which mainly focuses on the

security enhancement of the SDN control and data

plane. The distributed ONOS controllers enable avail-

ability and resiliency, and the monitoring and reme-

diation functionality detects attacks and drops mali-

cious trafﬁc in the data plane. Fawcett et al. (2018)

proved the effectiveness of their solution for four dif-

ferent attack types: DoS, DDoS, scanning, and intru-

sion. This security framework can also overcome the

burdens of mitigating threat T7 which cannot easily

be mitigated using speciﬁc countermeasures.

Summarising, Figure 3 provides a correlation

mapping between the identiﬁed threats and vulnera-

bilities, and the two types of mitigating countermea-

sures. This mapping enables the user of the frame-

work to ﬁnd the proper correlation between an SDN

vulnerability, the resulting SDN threats and the coun-

termeasures to mitigate them. As shown in Figure 3,

there is no single SDN security solution that can mit-

igate all threats. Therefore, a combination of miti-

gations against speciﬁc threats and a central security

solution are required to provide proper security mech-

anisms for SDN in DC environments.

A Security Evaluation Framework for Software-Deﬁned Network Architectures in Data Center Environments

285

5 CONCLUSIONS

Using SDN in DC environments facilitates the utili-

sation of cloud applications for multiple users. The

emerging architecture enables a dynamic, manage-

able, and adaptable network solution by decoupling

the control from the data plane. However, it also poses

new network security challenges.

In this paper we presented an SDN security eval-

uation framework and showed how it can be used

to identify SDN threats and vulnerability including

a risk and impact analysis. Once a security threat

has been identiﬁed, the correlation mapping within

the framework directly indicates which vulnerability

caused the threat and which countermeasure can be

applied to mitigate it. Furthermore, the CVSS scoring

shows the impact severity of the threat on the DC en-

vironment if countermeasures are not applied. In case

a security ﬂaw has been identiﬁed which is not men-

tioned in the evaluation framework, it still provides all

necessary models, tools, and procedures to facilitate

the extension of the correlation mapping and classi-

ﬁcation of the impact. The presented framework en-

ables network administrators to evaluate, classify and

enhance security of their SDN-based DC networks.

In future work, the SDN threat and vulnerability

analysis will be enhanced by adding a complete list

of attack scenarios. Due to the enormous number of

possible attacks per threat, a complete list would pro-

vide more insights into their technical realisation and

help to provide mitigating solutions. Furthermore, we

plan to increase the accuracy of the CVSS scoring by

comparing long and short-term severity impacts on

DC environments. We aim at answering the ques-

tions, whether attacks that affect the functionality of

an SDN for a short period of time are more harm-

ful compared to attacks that longer remain undetected

(e.g., eavesdropping on sensitive data). In future work

we will provide an answer to this question by intro-

ducing an additional metric to the CVSS model to

evaluate the impact of long- and short-term effects on

DC environments.

REFERENCES

Al-Saghier, H. (2019). Attack on sdn infrastructure and se-

curity measures. Journal of Engineering and Applied

Sciences, 6(2).

Anisetti, M., Ardagna, C. A., Bena, N., and Foppiani, A.

(2021). An assurance-based risk management frame-

work for distributed systems. In 2021 IEEE Interna-

tional Conference on Web Services (ICWS). IEEE.

Bilal, K., Khan, S. U., Kolodziej, J., Zhang, L., Hayat, K.,

Madani, S. A., Min-Allah, N., Wang, L., and Chen, D.

(2012). A comparative study of data center network

architectures. In ECMS, pages 526–532.

Cabaj, K., Wytrebowicz, J., Kuklinski, S., Radziszewski,

P., and Dinh, K. T. (2014). Sdn architecture impact on

network security. In FedCSIS (Position Papers).

Chica, J. C. C., Imbachi, J. C., and Vega, J. F. B. (2020).

Security in sdn: A comprehensive survey. Journal of

Network and Computer Applications, 159:102595.

Eswaraprasad, R. and Raja, L. (2017). A review of vir-

tual machine (vm) resource scheduling algorithms in

cloud computing environment. Journal of Statistics

and Management Systems, 20(4):703–711.

Fawcett, L., Scott-Hayward, S., Broadbent, M., Wright, A.,

and Race, N. (2018). Tennison: A distributed sdn

framework for scalable network security. IEEE Jour-

nal on Selected Areas in Communications.

Iqbal, M., Iqbal, F., Mohsin, F., Rizwan, M., and Ahmad, F.

(2019). Security issues in software deﬁned network-

ing (sdn): Risks, challenges and potential solutions.

International Journal of Advanced Computer Science

and Applications, 10(10).

Jiasi, W., Jian, W., Jia-Nan, L., and Yue, Z. (2019). Secure

software-deﬁned networking based on blockchain.

arXiv preprint arXiv:1906.04342.

Kaur, K., Singh, J., and Ghumman, N. S. (2014). Mininet as

software deﬁned networking testing platform. In In-

ternational conference on communication, computing

& systems (ICCCS), pages 139–42.

Kreutz, D., Ramos, F. M., and Verissimo, P. (2013). To-

wards secure and dependable software-deﬁned net-

works. In Proceedings of the second ACM SIGCOMM

workshop on Hot topics in SDN, pages 55–60.

Lasserre, M. and Kompella, V. (2007). Virtual private lan

service (vpls) using label distribution protocol (ldp)

signaling. Technical report.

Prathima Mabel, J., Vani, K., and Rama Mohan Babu, K.

(2019). Sdn security: challenges and solutions. In

Emerging Research in Electronics, Computer Science

and Technology, pages 837–848. Springer.

Ruffy, F., Hommel, W., and von Eye, F. (2016). A stride-

based security architecture for software-deﬁned net-

working. ICN 2016, page 107.

Scott-Hayward, S., O’Callaghan, G., and Sezer, S. (2013).

Sdn security: A survey. In 2013 IEEE SDN For Future

Networks and Services (SDN4FNS), pages 1–7. IEEE.

Shaghaghi, A., Kaafar, M. A., Buyya, R., and Jha, S.

(2020). Software-deﬁned network (sdn) data plane se-

curity: issues, solutions, and future directions. Hand-

book of Computer Networks and Cyber Security.

Sjoholmsierchio, M., Hale, B., Lukaszewski, D., and Xie,

G. (2021). Strengthening sdn security: Protocol di-

alecting and downgrade attacks. In 2021 IEEE 7th

International Conference on Network Softwarization

(NetSoft), pages 321–329. IEEE.

UcedaVelez, T. and Morana, M. M. (2015). Risk Centric

Threat Modeling: process for attack simulation and

threat analysis. John Wiley & Sons.

Varadharajan, V., Karmakar, K., Tupakula, U., and

Hitchens, M. (2018). A policy-based security archi-

tecture for software-deﬁned networks. IEEE Transac-

tions on Information Forensics and Security.

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

286

APPENDIX

Table 4: Threat Analysis based on MITRE Corporation and OWASP Top 10 (2021).

A Security Evaluation Framework for Software-Deﬁned Network Architectures in Data Center Environments

287

Table 5: Vulnerability Analysis based on MITRE Corporation and OWASP Top 10 (2021).

Table 6: Mitigations for identiﬁed SDN Threats (T1 - T18).

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

288