Verifying the Enforcement and Effectiveness of Network Lateral

Movement Resistance Techniques

Mohammed Noraden Alsaleh, Ehab Al-Shaer and Qi Duan

Department of Software and Information Systems,

University of North Carolina at Charlotte, Charlotte, NC, U.S.A.

Keywords:

Resistance, Cyber Attacks, Resilience, Conﬁguration, Model Checking.

Abstract:

As the sophistication of cyber-attacks is ever increasing, cyber breaches become inevitable and their conse-

quences are often highly damaging. Isolation and diversity are key techniques of cyber resilience for creating

built-in resistance in cyber networks against the lateral movement of multi-step Advanced Persistent Threats

(APTs) and epidemic attacks. However, the key unaddressed challenges are (1) how to ensure that speciﬁc

isolation and diversity conﬁgurations are sufﬁcient to prevent the lateral movement of attacks and (2) how

to verify that such conﬁgurations are enforced safely despite the complex inter-dependency between cyber

components. In this paper, we address these challenges by developing formal models and properties to verify

the effectiveness and enforceability of proactive cyber resistance techniques. We present a bounded model

checking approach based on satisﬁability Modulo theories (SMT) for OpenFlow software deﬁned networks

(SDNs). We verify that given resistance techniques are enforced in a way that does not violate the cyber mis-

sion requirements and we evaluate the conﬁguration resistance based on user-deﬁned resistance properties.

1 INTRODUCTION

The recent incidents of data breaches, such as the at-

tacks on SnapChat, Yahoo, the SWIFT system, and

others reported in the recent Verizon Data Breach In-

vestigation Reports (Verizon, 2016; Verizon, 2017)

emphasize the important fact that cyber breaches have

become inevitable. This requires high assurance of re-

silient proactive defense techniques to increase the re-

sistance against the propagation of cyber attacks and

signiﬁcantly limit their impacts.

Cyber resilience is the capability that allows the

cyber to defend against active attacks (i.e., when

the attackers are partially or completely success-

ful) (Goldman, 2010; Melin et al., 2013). Although

different deﬁnitions exist in literature for cyber resi-

lience, they are all centered around three key stra-

tegies: resistance, deterrence, and recovery. In this

work, we focus on the cyber resistance and we de-

ﬁne it as “the capability of the network conﬁguration

to increase the required time, effort, skill set, resour-

ces and knowledge for active attackers in order to

achieve their goal.” Speciﬁcally, we study two key

techniques of cyber resistance, namely isolation and

diversity, that can potentially impede the lateral mo-

vement of cyber attacks. Lateral movement is a key

step in the kill-chains of cyber attacks where attackers

compromise the most vulnerable systems and move

through the network to reach their ultimate targets.

Isolation aims at segregating the network components

such that critical assets are less susceptible to thre-

ats from vulnerable sources (Rahman and Al-Shaer,

2013; Goldman et al., 2011; Sahinoglu, 2006). Thus,

ensuring that critical portions of the network continue

to function even if others are compromised. Diver-

sity aims at changing the attack surface as the attacker

progresses through the attack kill-chain by using he-

terogeneous variants of software and hardware com-

ponents (Larsen et al., 2015; Miu et al., 2005; Yang

et al., 2008), in an effort to increase the time and re-

sources that she requires to identify and exploit unfo-

reseen cyber vulnerabilities.

Network resistance is not only about whether an

attacker can reach and exploit a particular asset, but it

is more about the effort she has to spend in order to ac-

complish that. Resistance techniques are implemen-

ted to maximize this effort without violating the net-

work mission. However, in order to ensure cyber re-

sistance, two properties must be satisﬁed: (1) the de-

sired isolation and diversity conﬁgurations are imple-

mented correctly and (2) they are effective against the

lateral movement of speciﬁc cyber attacks. Through

246

Alsaleh, M., Al-Shaer, E. and Duan, Q.

Verifying the Enforcement and Effectiveness of Network Lateral Movement Resistance Techniques.

DOI: 10.5220/0006868902460257

In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 246-257

ISBN: 978-989-758-319-3

the rest of this paper, we refer to these two proper-

ties by the Enforcement and Effectiveness, respecti-

vely. We believe that violating the enforcement and

effectiveness properties can impose substantial risks

on both the security and the performance of the net-

work. On the one hand, resistance techniques are rea-

lized through one or more layers of network elements,

including the conﬁguration of hosts, the applications

hosted by them, and the network infrastructure, which

performs a variety of trafﬁc transformations, such as

ﬁltering, inspection, tunneling, encryption, and au-

thentication. This makes ensuring correct and con-

sistent resistance conﬁguration a challenge, especially

in complex, large-scale, and densely connected cyber

networks. A single mistake may jeopardize the mis-

sion of the network by granting unauthorized access

to critical network assets, denying legitimate access

to network services, exposing conﬁdential informa-

tion by inappropriately encrypting or decrypting net-

work trafﬁc, misplacing software components which

renders them nonfunctional, etc. On the other hand,

violating the effectiveness property implies the pre-

sence of security conﬁguration weaknesses and man-

dates more resistive conﬁguration. Hence, techniques

and tools are required to automatically verify the en-

forcement and effectiveness of resistance conﬁgura-

tion.

In this paper, we present a model checking fra-

mework to verify the enforcement and effectiveness

of resistance conﬁguration. Speciﬁcally, our contri-

bution in this paper is twofold. First, we develop a

scalable Linear Temporal Logic (LTL)-based boun-

ded model checker that models the entire data plane

of OpenFlow-based software deﬁned networks along

with the hosts conﬁguration and veriﬁes its resistance

against cyber attacks. To model the lateral movement,

our model checker encodes the indirect reachability

through stepping stones or intermediate hubs. To the

best of our knowledge, this is the ﬁrst network conﬁ-

guration model checking framework that goes beyond

end-to-end reachability and provides the ability to de-

ﬁne and verify properties that span an entire attack

path with all its intermediate hubs. In addition, our

model can be extended to integrate different types

of security middle-boxes and host conﬁgurations to

accommodate variant isolation and diversity strate-

gies. Second, we model two of the network resistance

techniques: isolation and diversity, and verify their

enforcement and effectiveness. We provide a high

level language to facilitate the speciﬁcation of resis-

tance techniques and demonstrate the capabilities of

our model checker. Our model checker is not limi-

ted to isolation and diversity and any other resistance

technique can be veriﬁed as long as it can be repre-

(1)

Enforcement

Verification

System

Configuration

Resistance

Specification

Resistance

Properties

Refine Configuration

(2)

Effectiveness

Verification

Refine Resistance

Correct

Incorrect

Resistance

Profiling

Tuning Thresholds

Not Effective

Try Stronger Resistance

Acceptable

Profile

Effective

Can we do better!

Mission

Requirements

Figure 1: Design Philosophy.

sented in single or multiple LTL expressions.

The scope of this work encompasses the network

data plane and host conﬁguration abstracted by the

software variants running on top of it. Hence, we do

not model the complete application-layer conﬁgurati-

ons such as application level access control. We re-

alize that some lateral movement techniques require

higher level actions, such as privilege escalation, but it

also depends on the weaknesses that might exist in the

network data plane and the basic host conﬁguration.

For example, to exploit a remote access tool, the at-

tacker’s machine should be able to communicate with

the remote victim, which is controlled by the isolation

countermeasures in the network. Our objective in this

work is to discover and address such weaknesses.

We designed our framework to support the two-

phase veriﬁcation that is depicted in Figure 1. In the

ﬁrst phase, we verify the enforcement of the resis-

tance speciﬁcations, which is a composition of isola-

tion and diversity conﬁgurations. If the enforcement

property is not satisﬁed, a counter-example will be

generated to reﬁne the hosts and network data plane

conﬁguration. Otherwise, the model will further ve-

rify the effectiveness property with respect to user-

deﬁned resistance properties. If this is not satisﬁed, a

counter-example will be generated to show the weak-

nesses of the resistance techniques and reﬁne them ac-

cordingly. Multiple resistance properties can be com-

posed to measure the effectiveness of cyber resistance

against different attack capabilities. Thus, resistance

conﬁguration can be iteratively tuned until a satisfac-

tory resistance proﬁle is found. We implemented our

bounded model checker using Satisﬁability Modulo

Theories (SMT). The temporal relation between con-

secutive packet transformations, performed by Open-

Flow switches and security middle-boxes in the net-

work, is crucial for the enforcement and effectiveness

of the resistance conﬁgurations. Model checking can

efﬁciently capture such temporal dependency by ex-

ploring all relevant paths. Moreover, bounded model

checking does not require exponential space or ma-

nual manipulation of variables as the case in BDD-

Verifying the Enforcement and Effectiveness of Network Lateral Movement Resistance Techniques

247

based veriﬁcation (Clarke et al., 2001). Using SMT

allows our framework to support advanced decision

procedures for linear and non-linear arithmetic and

difference logic, which are needed to consider mis-

sion requirements and resistance thresholds.

The rest of the paper is organized as follows.

In Section 2, we present our technical details for a

resistance-oriented bounded model checker. In Secti-

ons 3 and 4, we present the models required to verify

the resistance enforcement and effectiveness proper-

ties. In Section 5, we report the performance evalu-

ation. Finally, the related work and conclusions are

presented in Sections 6 and 7, respectively.

2 OPENFLOW BOUNDED

MODEL CHECKING

An OpenFlow-based SDN consists of a set of

OpenFlow-enabled switches controlled by a central

controller. The controller provides interfaces to de-

ploy network management applications and dynami-

cally updates the ﬂow tables in the switches. Open-

Flow switches operate based on a ﬂow-based rule sets.

Each ﬂow rule consists of six components: the ma-

tch ﬁelds, priority, counters, instructions, timeouts,

and cookies. We focus on the components that di-

rectly affect the packet processing, which include the

match ﬁelds, the priority, and the instructions set.

The match ﬁelds are ﬁlters that determine the set of

ﬂows that match the ﬂow rule and they include the

Ethernet, IP, and TCP/UDP headers in addition to the

VLAN, MPLS, and PBB tags. The priority determi-

nes the matching precedence of the ﬂow rule. The

instructions set contains one or more of the instructi-

ons {Apply-Actions, Clear-Actions, Write-Actions, or

Goto-Table} according to the OpenFlow speciﬁcation

document 1.4 (ONF, 2013). Thus, a rule in an Open-

Flow table is a set of conditions on the OpenFlow ma-

tch ﬁelds and a set of instructions that are performed

on ﬂows matching the conditions.

In this section, we show how we model the net-

work data plane as a transition system for bounded

model checking. We also present the unique features

of our model checker that makes it suitable for re-

sistance veriﬁcation. The complete formalization and

low-level details of building the exact SMT asserti-

ons based on the OpenFlow conﬁguration are availa-

ble at (Alsaleh and Al-Shaer, 2016).

2.1 Transition System

The state of the network is determined by the uni-

que ﬂows (represented by the match ﬁelds) that can

be transferred through the network and their possible

locations. The ﬂows are represented by the ﬂow ma-

tch ﬁelds. The state in our model is encoded by the

following characteristic function:

σ : loc ×tbl × F ×A × L ×st × stns → {true, f alse}

The variables loc and tbl encode the unique switch

ID and the index of the ﬂow table within the Open-

Flow switch, respectively. The set F includes the ma-

tch ﬁelds’ variables. The Action Set variables A con-

tains a variable for each action that is carried between

the ﬂow tables during the pipeline processing inside

an OpenFlow switch. This set of variables are requi-

red to capture the ﬂow transformations inside a single

switch. L is an extensible set of special purpose varia-

bles, referred to by app-speciﬁc variables, that are in-

tegrated in the model only for particular applications.

The variables st and stns are deﬁned to capture the in-

direct reachability between network hosts, where st

represents the current step within a multi-step path

and stns is a list of the visited stepping stones in the

path.

Transitions between states are realized through

packet transformation and forwarding across Open-

Flow switches or across ﬂow tables in the same

switch. We add a transition to the global transition

relation if we encounter an Output action (a transition

to a new OF switch) or a Goto instruction (a transition

to a new table in the same OF switch). According to

OpenFlow speciﬁcation, multiple transitions may be

associated with the same ﬂow entry.

2.2 Resistance Veriﬁcation Model

We emphasize here the features provided in our model

that are required for the resistance veriﬁcation.

Modeling Stepping Stones. Using stepping stones or

intermediate attack hubs is a technique that is widely

used in attacks to bridge the connection between the

attacker and her targets (Nicol and Mallapura, 2014;

Shullich et al., 2011). Proactive resistance techniques

can break the chain of stepping stones by deploying

multiple heterogeneous resistance countermeasures in

potential attack paths.

Instead of discarding the packets once they reach

their direct destinations, we transform and forward

them back to the network. Incorporating the varia-

bles st and stns in the state characteristic function al-

lows us to track potential attack steps and the list of

stepping stones that has been visited in an attack path.

We modify the hosts behavior so that they will echo

the packets back to the network once they are recei-

ved and the list of previously visited stepping stones

is used to prevent loops.

SECRYPT 2018 - International Conference on Security and Cryptography

248

Modeling Middle-boxes. OpenFlow switches sup-

port the basic forwarding and ﬁltering functions, but

they do not support other important functions, such

as encryption, inspection, or authentication. This li-

mitation is addressed by integrating legacy middle-

boxes, such as VPN gateways, proxies, and intrusion

detection and prevention systems and conﬁguring the

OpenFLow switches to forward the trafﬁc to the ap-

propriate middle-boxes according to high level po-

licy (Qazi et al., 2013). In our work, these middle-

boxes provide the expected isolation between the net-

work assets and threat sources. Hence, it is essen-

tial to model their complete conﬁguration along with

the OpenFlow data plane. We provide a uniﬁed mo-

del that captures both the data plane of the Open-

Flow switches and the complete conﬁguration of se-

lected middle-boxes. We model the conﬁguration of

a middle-box as an ordered rule set. Each rule con-

sists of a set of conditions on the match ﬁelds and

an action that belongs to a predeﬁned set that might

include {stateful-inspect, deep-inspect, AH, ESP, tun-

nel}. This set may be extended based on the suppor-

ted middle-boxes in a network.

App-speciﬁc Variables. These variables are integra-

ted in the model for speciﬁc purposes such as deﬁ-

ning QoS parameters or aggregate functions at run

time without the need to recompile the framework.

We provide special keywords, def and map, to deﬁne

new app-speciﬁc variables and use them to verify re-

sistance properties. The def declares a variable that

will be encoded as an integer. The map is used to

assign values to the new variable based on the other

variables of the same state. For example, the app-

speciﬁc variable shown below deﬁnes a new variable

called Thr whose value is mapped from the loc varia-

ble. In this example, the value of the new variable is

50 if loc=1, 30 if loc=2, and so on.

def Thr = map(loc){{1, 50}, {2, 30}, . . . }

All the state variables including the location, match

ﬁelds (F), action set (A), and other app-speciﬁc va-

riables (L) can be used in the map construct. Once

deﬁned, users can use the new variables directly in

writing the mission or resistance properties.

2.3 Speciﬁcation Language

We use the standard LTL speciﬁcation language as a

generic means to specify various properties. Any pro-

perty that can be expressed using LTL can be veriﬁed

using our framework. However, as will be shown la-

ter, we provide high level speciﬁcation language to

describe the resistance requirements and properties

and we translate them automatically to LTL and, later,

Mission Requirements Speciﬁcation Syntax

QoS Param ρ ::= BW | D RATE | DELAY | ...

Operator ::= > | < | ≥ | ≤ | ==

predicate Φ ::= ρ | Z

| max(ρ) | min(ρ) |

sum(ρ) | avg(ρ)

QoSCond Ψ ::= Φ  Φ | Ψ ∧Ψ | Ψ ∨ Ψ

Location L ::= < (ip:port) >

Sec. Comp. M ::= C | I | A | ∗

Requirement R ::= CanReach(L, L, Ψ) |

Protect(L,M ) | R ∨R | R ∧ R

Resistance Techniques Speciﬁcation Syntax

Pattern P ::= E

| E

Isolation E

::= I

| E

∧ E

| E

∨ E

Diversity E

::= D | E

∧ E

| E

∨ E

CMeasure I

::= FW | V PN | PROXY | IDS | . . .

Div. Param D ::= OS | V ERSION | SERV ICE | ...

Res. Tech. S ::= ResistSpec(L, L, Z

,P )

Resistance Properties Speciﬁcation Syntax

Vector V ::= < software/hardware variants >

Property P

res

::= CanResist({L},{V },{M }, {I

})

Figure 2: Speciﬁcation Language Syntax. Z

is the set of

positive integers.

to SMT constraints. A property in LTL can contain

any of the standard LTL temporal connectives: next

(X), eventually (F), global (G), until (U), and release

(R). In addition, multiple temporal constraints can be

combined using the logical operators AND (∧), OR

(∨), and NOT (¬).

3 RESISTANCE ENFORCEMENT

VERIFICATION

The network data plane satisﬁes the resistance enfor-

cement property if it meets two conditions: (1) it cor-

rectly implements desired resistance techniques (i.e.,

isolation and diversity patterns) and (2) implementing

the desired techniques does not introduce violations to

the network mission requirements. In this section, we

formally deﬁne the resistance techniques and mission

requirements and show how we verify them using our

bounded model checker.

3.1 Resistance Techniques and Network

Mission Speciﬁcation

Resistance techniques enforce speciﬁc attack resis-

tance and deterrence measures, such as isolation,

Verifying the Enforcement and Effectiveness of Network Lateral Movement Resistance Techniques

249

through inspection or encryption, and diversifying the

network parameters in all paths from threat sources to

system assets. In this work, we consider two major

resistance techniques, isolation and diversity, and we

deﬁne them formally as follows.

Resistance Techniques Speciﬁcation. We deﬁne a

resistance technique as the tuple (S, D, P,F ), where:

• S is a set of locations in the network that represent

potential insider or outsider threat sources.

• D is a set of locations inside the network that re-

present critical assets.

• P is the isolation or diversity pattern. For isolation

techniques, P is expressed as a logical expression

in terms of the countermeasures deployed in the

network, such as VPN gateways, proxies, and in-

trusion detection/prevention systems. For diversity

techniques, P is expressed in terms of the hosts at-

tributes, such as vendor, platform, applications, and

their version.

• F is the frequency that determines in how many

steps of the attack steps the isolation pattern, P ,

should hold in any attack path.

Intuitively, an isolation technique speciﬁed based on

this deﬁnition means that the speciﬁed pattern should

be met in all direct and indirect paths between the spe-

ciﬁed threat sources and critical assets for at least F

number of times. Similarly, a diversity technique de-

termines how many times, in an attack path, the attac-

ker should encounter hosts that have different values

for the diversity parameters speciﬁed in the the pattern

P . The frequency F makes our deﬁnition suitable to

specify existing diversity requirements and metrics,

such as the d2-diversity metric (Zhang et al., 2016),

which typically specify the least number of distinct

components that must be encountered in potential at-

tack paths.

To simplify the speciﬁcation of the resistance re-

quirements, we provide a uniﬁed language to express

the resistance techniques in terms of the construct Re-

sistSpec, which can deﬁne both the diversity and iso-

lation techniques. In Figure 2, we show the syntax of

the ResistSpec construct, which takes four arguments.

The ﬁrst two represent the set of threat sources and

critical destinations. The third argument represents

the frequency. The fourth argument is a Boolean ex-

pression for the isolation or the diversity pattern. For

example, the isolation technique that “if a path is pos-

sible from students labs to the records servers, at le-

ast two rounds of inspection or header authentication

(AH) must exist” can be represented as:

ResistSpec(Labs, Records, 2, (inspect ∨ AH))

Mission Requirements Speciﬁcation. The mission

of cyber networks is not limited to binary conﬁgu-

ration decisions that specify whether hosts are con-

nected to each other or not. In addition to basic con-

nectivity, we identify two types of requirements that

may be crucial for successful mission: (1) to guaran-

tee particular performance and QoS requirements and

(2) to preserve the conﬁdentiality, availability, and

the integrity of particular critical assets in the system.

The performance and QoS requirements are normally

described in the Service Level Agreement (SLA) and

translated to the QoS parameters of the networking in-

frastructure in terms of bandwidth, delays, jitter, etc.

The network data plane affects these parameters as

it determines which switches, ports, and queues the

trafﬁc passes through, which may have different per-

formance metrics. Therefore, end-to-end analysis is

required in order to ensure that the global network

conﬁguration can support the required QoS.

To formally specify the mission requirements, we

provide the language shown in Figure 2. According

to this syntax, a mission requirement, R, can be spe-

ciﬁed in terms of the two constructs CanReach and

Protect. CanReach is used to specify the QoS require-

ments between a pair of locations in the network. The

QoS Constraints are composed of a set of conditions

on the aggregate values of the network infrastructure

QoS parameters. The aggregate functions max, min,

sum, and avg calculates the maximum, the minimum,

the summation, and the average values of the para-

meter ρ in each possible path between the speciﬁed

locations. For example, let the set C be a set of clients

in an organization that are using a particular service

s. And let P be a pool of servers that are running that

service. Let us assume that the mission of this organi-

zation requires that: (1) “each client should be able to

reach at least one server with a data rate greater than

or equal to τ

” and (2) “the response from any ser-

ver to any client should not be delayed more that τ

”.

These requirements can be represented using our lan-

guage as follows:

c∈C

p∈P

CanReach(c, p : s, min(D

rate

) ≥ τ

)

p∈P

c∈C

CanReach(p : s,c,sum(DELAY ) ≤ τ

)

The construct Protect can be used to mark the cri-

tical assets in the network, those that if compromised,

the system mission will be in jeopardy. We further

provide the option to specify the ﬁne-grain security

component (i.e., Conﬁdentiality, Integrity, Availabi-

lity) of particular locations in the network, that is cri-

tical to the mission.

SECRYPT 2018 - International Conference on Security and Cryptography

250

3.2 Verifying Resistance Speciﬁcations

To verify the correct implementation of resistance

techniques, we translate their speciﬁcation to LTL

properties and verify them using our bounded model

checker. This cannot be possible without considering

the indirect reachability. We show in the following

how the resistance techniques speciﬁcation is transla-

ted to LTL expressions.

• Isolation Countermeasures. The isolation techni-

ques speciﬁcation depends on the set of counter-

measures that may be deployed in the network. We

deﬁne an app-speciﬁc variable that associates each

location in the network to its resistance functiona-

lity (i.e., whether it is a ﬁlter, a VPN gateway, a

packet inspection box, a proxy, etc). The values of

those variables are determined based on the loc va-

riables using the map construct. Then, we deﬁne a

marking variable for each type of countermeasures.

The marking variables capture which countermea-

sures a packet passes through between one parti-

cular source to a destination. At each transition,

the value of each marking variable is set to true if

the ﬂow passes through the corresponding counter-

measure. Otherwise, its value is copied from the

previous state as is.

• Diversity Attributes. For each diversity attribute

that is part of the resistance technique, we deﬁne

a new variable in the model and we use the map

construct to assign its value based on the locations

in the network.

• Resistance Pattern. At this point, we have deﬁned

the isolation marking variables in addition to the

diversity variables. The resistance pattern can be

expressed as a logical expression in terms of the

marking and diversity variables.

• Frequency. We deﬁne an app-speciﬁc variable

(step) that works as a counter. The value of this

counter is incremented only if the resistance pat-

tern is satisﬁed at the end of each attack step.

• Finally, the isolation speciﬁcation is expressed as

an LTL property that expresses a counter example

for the desired isolation speciﬁcation (i.e., it veri-

ﬁes if the attacker can indirectly reach the destina-

tion with inappropriate frequency of the speciﬁed

resistance pattern). The absence of counter exam-

ples proves the correct deployment of the speciﬁed

resistance techniques.

In Table 1, we show examples for isolation and di-

versity techniques speciﬁcations along with the trans-

lated LTL. In the isolation example, we deﬁne the

variable cm that maps each location in the network

to its type (i.e., host, ﬁlter, IDS, etc.). Then we

Table 1: Resistance Techniques Examples.

Isolation Technique Speciﬁcation

ResistSpec( dmz, c db, 2,(vpn ∨ ( f ilter ∧ d-inspect))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

def cm = map (loc) {{1, ﬁlter}, {2, vpn}, . . . }

def cm f tr = (cm == f ilter)?true : cm f tr

−1

def cm vpn = (cm == vpn)?true : cm vpn

−1

def cm dnp = (cm == d-inspect)?true : cm dnp

−1

def iso = ((step 6= step

−1

)∧

(cm vpn ∨(cm f tr ∧ cm dnp))) ?iso

−1

+ 1 : iso

−1

iso

= (loc == dmz) ∧ F [(loc == c db) ∧¬(iso > 2)]

Diversity fTechnique Speciﬁcation

ResistSpec( i net, c db, 3,os)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

def os = map (loc) {{1, win7}, . . . }

def div = ((step 6= step

−1

) ∧ (os 6= os

−1

)) ? div

−1

1 : div

−1

div

= (loc == i net)∧ F [(loc == c db) ∧¬(div ≥ 3))]

deﬁne the marking variables cm f tr, cm vpn, and

cm dnp. We deﬁne these variables using if-then-

else statement ( ? : ). For example, the statement

(cm vpn = (cm == vpn)? true : cm vpn

−1

) will set

the value of cm vpn to true if the system reaches a

state at which a packet is at a location whose type is

vpn. Otherwise, the previous value is carried along.

We use the notation v

−1

to represent the previous va-

lue of the variable v. The same goes for the other

marking variables. Then, we deﬁned the variable iso,

which counts the steps at which the speciﬁed isola-

tion pattern is satisﬁed, based on the marking vari-

ables. Note that this counter is incremented at each

stepping stone (i.e., when step 6= step

−1

). The ﬁ-

nal LTL expression P

iso

deﬁnes a counter example for

the desired speciﬁcation utilizing the state’s basic and

app-speciﬁc variables. We follow the same procedure

for the diversity example except that the counter div

is incremented only if the current stepping stone di-

versity attributes are different from the previous one.

The expression P

div

represent a counter example for

the desired diversity speciﬁcation.

3.3 Verifying Reachability and QoS

Requirements

In this section, we show the steps we follow to trans-

late the mission requirements to LTL properties and

verify them using our model checker. The translation

of the Protect is deferred to the following section be-

cause it depends on the attack description.

The reason that we need to verify the network

mission requirements is that misconﬁgurations in the

Verifying the Enforcement and Effectiveness of Network Lateral Movement Resistance Techniques

251

Table 2: Examples of CanReach Requirements.

Property LTL Property Expression

1. CanReach(s, d, ) P

= (loc == s)∧(IP SRC == s)∧(IP DST == d)∧F[(loc == d)∧(IP DST == d)]

2. CanReach(s, dc, min(DR) ≥ τ)

def DR = map (queue) {{1, 512}, {2, 1024} . . . }

= (loc == s) ∧ (IP DST == dc) ∧ F [(min(DR) < τ) ∧(loc == dc))]

isolation and diversity techniques may have negative

impacts on the network mission requirements. Incor-

rect placement of software and hardware variants may

cause reachability and/or performance violations be-

cause some variants may require speciﬁc conﬁgura-

tion in the network infrastructure level to make them

accessible or they may not be capable of providing

the required performance. Similarly, if an isolation

technique is implemented incorrectly, it may intro-

duce reachability, performance, or security violations

by blocking some legit trafﬁc ﬂow, forwarding trafﬁc

ﬂows through inappropriate ports or queues that are

incapable of providing the required QoS, or granting

undesired access to critical assets in the network. As a

part of verifying the enforcement of resistance techni-

ques, we ensure that all network mission requirements

are satisﬁed under the deployed techniques.

The CanReach construct can specify basic rea-

chability requirements without any constraints on the

QoS as appears in the ﬁrst example of Table 2. The

corresponding LTL expression that is shown in the ta-

ble is satisﬁed if packets that are initially located at

location s will be located at the destination d at any

future state.

The CanReach requirements can also specify con-

straints on the QoS between sources and destinations

in the network. In order for these requirements to be

satisﬁed, the source should be able to reach the desti-

nation and the QoS, in terms of the QoS parameters,

should meet particular thresholds. In this case, we

follow the following steps:

• The QoS parameters such as bandwidth, data rate,

and delay are deﬁned as app-speciﬁc variables and

encoded using the map construct. We assume that

every device/port in the network will have a value

for each quality of service parameter.

• If any aggregate functions are used, they will be en-

coded as app-speciﬁc variables and their values are

computed accumulatively at each transition. The

use of SMT allows us to compute their commuta-

tive values utilizing the basic arithmetic and condi-

tional operators.

• Since the QoS parameters and the aggregate values

are deﬁned as app-speciﬁc variables, the QoS con-

straints are encoded directly into SMT by replacing

the QoS parameters deﬁned in the constraints with

the corresponding app-speciﬁc variables.

The second property in Table 2 shows an exam-

ple of CanReach requirements with QoS constraints.

In this example, the mission requires that the trafﬁc

from a particular server s to the data center dc does

not pass through a port which has a data rate less

than a particular threshold τ. Such requirement is cru-

cial in several solutions that have proposed techniques

for task scheduling in MapReduce architectures (Qin

et al., 2014). Since this requirement depends only on

one QoS parameter, data rate, we deﬁne the DR pa-

rameter and assign it is value as a map between the

OpenFlow queue ID and the data rate of that parti-

cular queue. Next, we express the requirement as an

LTL expression that contains a constraint in terms of

the new variable DR and the aggregate function min

that is satisﬁed if the data rate in all the paths between

the source and destination does not drop below the

given threshold.

4 RESISTANCE EFFECTIVENESS

VERIFICATION

The effectiveness of resistance techniques is evalu-

ated with respect to speciﬁc attack propagation mo-

dels. We model in this section the resistance proper-

ties, which deﬁne attacks with certain capabilities and

we show how to verify the effectiveness of the resis-

tance conﬁguration against them.

4.1 Network Resistance Properties

We study the resistance of the network conﬁguration

within the context of multi-step attacks, in which the

attacker compromises multiple hosts (stepping sto-

nes) sequentially in order to reach his target. This

behavior is commonly used in two major classes of

cyber attacks: worms and Advanced Persistent Thre-

ats (APTs). We characterize cyber attacks based on

the following attributes:

• Attack Target. The attack target is reaching and

compromising critical assets in the network in or-

der to gather sensitive information or gain access to

private computer systems.

• Impact. The impact speciﬁes which security com-

ponent(s) (i.e., Conﬁdentiality, Integrity, and/or

SECRYPT 2018 - International Conference on Security and Cryptography

252

Availability) the attack is targeting.

• Attack Vector. The attacker in our model posses-

ses some capabilities to exploit speciﬁc software

or hardware components in order to propagate and

compromise network resources.

• Propagation. If the attacker can reach a vulnera-

ble host whose vulnerabilities belong to the attack

vector, that host becomes a stepping stone and the

attack can automatically propagate to its neighbors.

• Countermeasures. Each attack is associated with a

set of countermeasures that are capable of preven-

ting it. An attack is successful if there is at least one

attack path in which the attacker reaches his target

without encountering any of the speciﬁed counter-

measures.

The resistance properties evaluate the ability of

the implemented resistance techniques to resist a gi-

ven attack with certain capabilities. Hence, a resis-

tance property describes an attack based on the attack

model discussed above as follows:

Resistance Properties We deﬁne a resistance pro-

perty as the tuple (O,V , M ,C ), where:

• O is a set of untrusted locations that are assumed to

be compromised and they constitute the potential

origins of the attack.

• V is the attack vector, a set of software/hardware

variants that the attacker is capable of compromi-

sing.

• M ⊆ {C, I,A} is the impact vector.

• C is a set of countermeasures that can prevent

and/or divert the attack if encountered in an attack

path.

The network conﬁguration satisﬁes a resistance pro-

perty if it can prevent the speciﬁed attack from propa-

gating and compromising its target. We consider any

critical asset in the network, that is deﬁned as part of

the mission requirements using the Protect construct,

as a potential target of the attack.

Based on this deﬁnition, we can see that there is a

direct relation between the implemented isolation and

diversity patterns and the satisfaction of the resistance

properties. The selection of software and hardware

variants in each location in the network through diver-

sity techniques determines whether or not the attacker

encounters variants that she is capable of compromi-

sing (i.e., those variants that belong to the attack vec-

tor V ). On the other hand, the optimal deployment

of isolation techniques can guarantee that attackers

encounter appropriate attack countermeasures ((i.e.,

those that belong to set C ) in any potential path to the

critical assets of the network.

To specify resistance properties, we provide the

high level construct, CanResist, whose syntax is

shown in Figure 2. For example, let us assume that

preserving the integrity and conﬁdentiality of two

database servers, db

and db

, is speciﬁed as part

of the mission requirements using the requirement

Protect({db

,db

},{I,C}), then the following repre-

sent a valid resistance property:

CanResist({dmz, i net}, {RH-6.0}, {I, C}, ids)

This property speciﬁes that threat sources may

exist in the Internet (i net) and the dmz, the attacker

is capable of exploiting Red Hat 6.0 (RH-6.0), the

attacker is targeting the integrity and conﬁdentiality

of its victims, and IDS is an effective countermeasure

against this attack proﬁle.

4.2 Verifying Resistance Properties

In this section, we demonstrate how we translate the

resistance properties to LTL and verify them using

our bounded model checker. Modeling indirect rea-

chability and potential attack propagation makes the

veriﬁcation of such properties straight forward. Re-

sistance properties are speciﬁed using the construct

CanResist(O, V ,M , C). To verify that the resistance

conﬁguration can prevent the speciﬁed attack from re-

aching the critical locations in the network, we iden-

tify the set of critical locations deﬁned using the Pro-

tect construct as part of the mission requirements.

Speciﬁcally, we follow the following procedure to

translate resistance properties to LTL expressions.

• First, we deﬁne an app-speciﬁc variable, cm, and

assign its value using the map construct to identify

the type of each location in the network (i.e., whet-

her it is a host, ﬁlter, ids, etc.).

• Second, we deﬁne another app-speciﬁc variable, v,

that identiﬁes the software/hardware proﬁle of each

location in the network (i.e., the installed software

and hardware variants). Similar to the cm variables,

it is mapped to appropriate values using the map

construct based on the loc variable.

• Third, We compile a set of hosts in the network

(W) that are declared critical for the network mis-

sion and they are potential targets of the speciﬁed

attack. Recall that the Protect construct not only

speciﬁes the location, but also the critical security

component (i.e., conﬁdentiality, integrity, and/or

availability). If the security component speciﬁed

in the Protect construct is the wild card (∗) or it be-

longs to the impact vector of the speciﬁed attack,

we add the location to the set of critical hosts W.

Verifying the Enforcement and Effectiveness of Network Lateral Movement Resistance Techniques

253

Formally,

∀ Protect(l, m) : (l ∈ W) ⇐⇒ (m = ∗) ∨(m ∈ M )

• Finally, we compile the LTL expression that

searches for violations of the desired resistance

property utilizing the Until temporal operator as

follows:

o∈O

(loc = o)∧



((cm /∈ C )∧ ((cm = host) → v ∈ V ))

U(loc ∈ W)



This LTL property is satisﬁed if there is a path from

any location that belongs to the untrusted set (O)

to any of the critical locations (W), such that all

the intermediate nodes are either vulnerable hosts

or middle-boxes that do not belong to the set of

countermeasures (C ) that are effective against the

speciﬁed attack.

5 EVALUATION

We implemented a tool using C#.NET that automati-

cally reads the complete data plane of an OpenFlow

network and provides a GUI for the user to specify the

mission requirements, the resistance techniques spe-

ciﬁcation, and the resistance properties. This tool uses

the Z3 .NET API to compose the proper SMT expres-

sions and generate an SMT ﬁle that contains the com-

plete problem encoded as SMT assertions. We then

feed this ﬁle to the Z3 SMT solver. We ran all expe-

riments on a standard PC with 3.4 GHz Intel Core i7

CPU and 16 GB of RAM.

To evaluate the performance and the scalability of

our framework, we measure the time required to solve

the satisfaction problem with respect to multiple pa-

rameters, such as the network size, the sizes of ﬂow

tables, the number of app-speciﬁc variables, and the

complexity of the mission requirements and isolation

speciﬁcations.

5.1 Extensive Scalability Evaluation

The scalability of model checking tools depends on

the size of the problem in terms of the state space

and the number of transitions. In our case, the size

of the problem depends on multiple network parame-

ters, such as the network size and the length of ﬂow

tables. Due to the lack of real large-scale networks

conﬁgurations, we synthesized a number of network

instances with given parameters based on tree topo-

logy, where the leafs are hosts and the inner nodes

are OF switches. In all the generated networks, the

core switches do not constitute more than 15% of the

total nodes in the network. We then generate the con-

straints satisfaction problem and solve it using the Z3

SMT solver. We record the time and memory required

to solve the problem. As presented in Sections 3 and

4, both the resistance speciﬁcations and properties are

translated into some form of reachability queries with

varying number and structure of app-speciﬁc varia-

bles. Hence, the following evaluation applies on each

of the mission requirements, the resistance speciﬁca-

tions, and the properties.

The Impact of Network Size. In this experiment, we

study the impact of the overall number of network no-

des. We generated a number of networks whose sizes

varied from 75 to 2100 nodes. For each of them, we

report the average time and space of verifying 20 re-

achability properties between random pairs of hosts.

We conducted the experiment under two different set-

tings of the bound k. In one setting, the bound k va-

ries based on the number of ﬂow tables. It was set to

a constant value in the other setting regardless of the

network size. Each switch in these experiments con-

tains up to two ﬂow tables with an average length of

50 ﬂow rules. Figure 3 shows the results of this expe-

riment. We can see that in the case of ﬁxed bound, the

time and space requirements are linear with respect

to the network size. However, in the case of varying

bound, the performance is affected by both: the net-

work size and the bound and it is best described by a

quadratic polynomial with respect to network size.

The Impact of the Flow Table Size. In this experi-

ment, we generated various networks with the same

number of nodes (300 nodes), but with varying ﬂow

table sizes measured by the number of rules. All the

rules have the same structure (i.e. the same number of

instructions and the same length of actions lists). As

reported in Figure 4, the total number of rules ranged

from 1.4 to 33.5 thousand rules. The results show that

the growth in time and space tends to stabilize after a

threshold (i.e. increasing the ﬂow table size does not

signiﬁcantly increase the requirements). We believe

this behavior is due to the compact representation of

assertions in Z3 that merges similar expressions to-

gether.

The Impact of the Bound k. The bound determines

the number of steps to consider in the bounded model.

For each step, a new set of variables and a replica of

the transition relation is added. To study the impact

of the bound value, we generated two networks: Net-

work 1 that consists of 300 nodes and Network 2 that

consists of 600 nodes. Each switch in the network

has up to 2 tables and an average of 50 ﬂow rules per

table. For each network, we ran our experiment mul-

tiple times, selecting a different bound each time. The

SECRYPT 2018 - International Conference on Security and Cryptography

254

1000

2000

3000

4000

5000

6000

100

150

200

250

300

350

400

0 300 600 900 1200 1500 1800 2100

Memory (MB)

Time (sec)

Network Size

Memory (Varying Bound)

Memory (Fixed Bound)

Time (Varying Bound)

Time (Fixed Bound)

Poly Trendline (Varying Bound)

Linear Trendline (Fixed Bound)

Figure 3: The impact of network size.

-100

300

700

1100

1500

14 54 94 134 174 214 254 294 334

Memory (MB)

Time (sec)

Total number of rules (hundred)

Verification Time

Memory

Logarithmic Trendline

Figure 4: The impact of the table size.

100

150

200

250

300

350

0 1000 2000 3000 4000

Memory (MB)

Time (sec)

App-Specific Variables (QoS, Countermeasures)

Time (simple)

Time (complex)

Memory (simple)

Memory (complex)

Figure 5: The impact of app-speciﬁc variables.

350

700

1050

1400

1750

2100

2450

100

120

140

160

50 150 250 350 450 550

Memory (MB)

Time (sec)

Bound (k)

Time - Network 1

Time - Network 2

Memory - Network 1

Memory - Network 2

Figure 6: The impact of the bound.

bounds ranged from 50 to 600. Figure 6 shows that in

both networks the time and space requirements incre-

ase linearly with respect to the bound.

The Impact of App-speciﬁc Variables. We con-

ducted an experiment to study the impact of app-

speciﬁc variables, which depends on the QoS para-

meters, diversity attributes, and the number of coun-

termeasures. For this purpose, we ran our framework

against a network of 300 nodes with a varying num-

ber of app-speciﬁc variables that ranged from zero to

5000. Moreover, we deﬁned two types of app-speciﬁc

variables, namely simple and complex. The simple va-

riables were deﬁned as additive operations (e.g., sum

of delays over a path), while the complex includes

non-linear multiplication. Figure 5 reports the time

and space for both types. We can see that the number

of app-speciﬁc variables of both types has a very mi-

nor impact on the time and space requirements. They

remain almost constant even with a large number of

app-speciﬁc variables.

5.2 Real Network Case Study

In this case study, we evaluate the performance of

our framework on the Stanford backbone network, a

mid-size enterprise network whose entire conﬁgura-

tion has been made public for researchers (Zeng and

Kazemian, ). The network consists of 14 zones con-

nected to two backbone routers via ten layer-2 swit-

ches with a total of 240 hosts in the 14 zones and a

total of 3840 ﬂow rules distributed over 16 switches.

We ran more than 50 reachability requirements

with quality of service constraints on the number of

hops between random pairs of hosts in the network.

The source and destination of each pair were selected

from different zones. For both the satisﬁed and not

satisﬁed requirements, the measured time ranged bet-

ween 6 and 18 seconds with a mean of 14.34 seconds.

This case study shows the applicability of our veriﬁ-

cation framework for verifying real requirements on

real networks. We believe that the running time is

acceptable as our veriﬁcation is conducted ofﬂine and

does not interfere with the live operation of the net-

work.

Verifying the Enforcement and Effectiveness of Network Lateral Movement Resistance Techniques

255

6 RELATED WORK

The veriﬁcation of network invariants has attracted

a signiﬁcant body of research in both enterprise and

software deﬁned networks. In this literature review,

we focus on the data plane veriﬁcation tools for

OpenFlow-based Software Deﬁned Networks. Flow-

Checker (Al-Shaer and Al-Haj, 2010) and HSA (Ka-

zemian et al., 2012) are ofﬂine conﬁguration analysis

tools. FlowChecker encodes the OpenFlow ﬂow ta-

bles using Binary Decision Diagrams (BDD) and uses

model checking to verify security properties. HSA

veriﬁes tha data plane correctness by modeling the

network as a geometric model to discover reachability

violations, forwarding loops, and trafﬁc isolation. Ve-

riFlow (Khurshid et al., 2012), FLOVER (Son et al.,

2013), NetPlumber (Kazemian et al., 2013), and Flo-

wGuard (Hu et al., 2014) are real time policy veriﬁ-

cation tools. VeriFlow proposes to slice the OF net-

work into equivalence classes to efﬁciently check for

reachability violations. FLOVER is a model checker

that checks the OpenFlow conﬁguration for security

violations using Yices SMT solver. NetPlumber is a

real time policy checking tool based on HSA that uti-

lizes a dependency graph between ﬂow entries to in-

crementally check for loops, black holes, and reacha-

bility properties. FlowGuard examines dynamic ﬂow

updates to detect ﬁrewall policy violations. Flow-

Guard also provides violation resolution approaches.

Although these works can check the compliance of

OpenFlow network updates with speciﬁc invariants.

Their applications are limited to reachability or re-

lated analyses in (Kazemian et al., 2012; Kazemian

et al., 2013; Son et al., 2013) and to ﬁrewall policy

veriﬁcation in (Hu et al., 2014).

ConﬁgChecker (Al-Shaer et al., 2009) (BDD-

based model checker) and Anteater (Mai et al., 2011)

(SAT-based model checker) are two model checking

frameworks that allow the speciﬁcation of system pro-

perties using temporal logics. They both employ si-

milar conﬁguration abstraction as our framework, but

they are targeting traditional networks conﬁguration

and they use binary analysis platforms (BDD and

SAT), which make it hard to verify properties with

arithmetic constraints. SecGuru (Bjorner and Jayara-

man, 2014) is another tool that is based on the bit-

vectors theory in Z3 solver for checking network in-

variants. Since SecGuru is also built using Z3, there

may be a potential for extending it to apply bit-vector

arithmetic. However, this has not been demonstrated

in the applications presented in (Bjorner and Jayara-

man, 2014).

The aforementioned related works provide mul-

tiple platforms to verify the end-to-end reachability

in enterprise and software deﬁned networks, but they

do not focus on resistance veriﬁcation. None of them

provides the ability to express properties for indirect

reachability and reason about multi-step attack paths.

They also have very limited support for QoS requi-

rements veriﬁcation, which is required to ensure the

network mission integrity. In this bounded model

checking framework, we utilize the arithmetic theory

in SMT to verify end-to-end reachability with QoS

credentials and we model the indirect reachability be-

tween network hosts in order to verify the resistance

speciﬁcations and their effectiveness against multi-

step attacks.

7 CONCLUSIONS AND FUTURE

WORK

In this paper, we propose a model checking approach

to model the complete conﬁguration of networks and

verify that (i) given mission requirements and resis-

tance techniques speciﬁcations are properly enforced

in the network and (ii) they are effective in resisting

certain attacks. We also demonstrated how to achieve

this using our model checker utilizing the linear and

nonlinear arithmetic theories of SMT solvers. Our

evaluation shows that we can verify the effective-

ness of resistance measures against worms/APT at-

tacks propagation. Although the performance evalua-

tion reveals that the framework needs relatively large

time to verify resiliency requirements for large net-

works, the veriﬁcation is conducted ofﬂine. Thus, it

will not affect the live operation of the network. We

believe that the result are comparable to other tools

that have been presented recently for SDN conﬁgu-

ration veriﬁcation. We plan to extend our framework

by integrating more middle-boxes that support advan-

ced functions and modeling other categories of cyber

attacks. We are also investigating the feasibility of

using hierarchical veriﬁcation techniques by dividing

the network and the properties into groups and in-

vestigate optimization and expression simpliﬁcation

techniques to enhance the performance of our frame-

work.

ACKNOWLEDGEMENTS

This research was supported in part by the National

Security Agency and Army Research Ofﬁce. Any

opinions, conclusions, or recommendations stated in

this material are those of the authors and do not ne-

cessarily reﬂect the views of the funding sources.

SECRYPT 2018 - International Conference on Security and Cryptography

256

REFERENCES

Al-Shaer, E. and Al-Haj, S. (2010). Flowchecker: Conﬁgu-

ration analysis and veriﬁcation of federated openﬂow

infrastructures. In Proceedings of the 3rd ACM works-

hop on Assurable and usable security conﬁguration,

pages 37–44. ACM.

Al-Shaer, E., Marrero, W., El-Atawy, A., and Elbadawi, K.

(2009). Network conﬁguration in a box: Towards end-

to-end veriﬁcation of network reachability and secu-

rity. In ICNP, pages 123–132.

Alsaleh, M. N. and Al-Shaer, E. (2016). Towards automated

veriﬁcation of active cyber defense strategies on soft-

ware deﬁned networks. In Proceedings of the 2016

ACM Workshop on Automated Decision Making for

Active Cyber Defense, SafeConﬁg ’16, pages 23–29,

New York, NY, USA. ACM.

Bjorner, N. and Jayaraman, K. (2014). Network ve-

riﬁcation: Calculus and solvers. In Science and

Technology Conference (Modern Networking Techno-

logies)(MoNeTeC), 2014 International, pages 1–4.

IEEE.

Clarke, E., Biere, A., Raimi, R., and Zhu, Y. (2001). Boun-

ded model checking using satisﬁability solving. For-

mal Methods in System Design, 19(1):7–34.

Goldman, H. (2010). Building secure, resilient architectures

for cyber mission assurance. The MITRE Corporation.

Goldman, H., McQuaid, R., and Picciotto, J. (2011). Cyber

resilience for mission assurance. In Technologies for

Homeland Security (HST), 2011 IEEE International

Conference on, pages 236–241. IEEE.

Hu, H., Han, W., Ahn, G.-J., and Zhao, Z. (2014). Flow-

guard: Building robust ﬁrewalls for software-deﬁned

networks.

Kazemian, P., Chan, M., Zeng, H., Varghese, G., McKeown,

N., and Whyte, S. (2013). Real time network policy

checking using header space analysis. In NSDI, pages

99–111.

Kazemian, P., Varghese, G., and McKeown, N. (2012). He-

ader space analysis: Static checking for networks. In

NSDI, pages 113–126.

Khurshid, A., Zhou, W., Caesar, M., and Godfrey, P. (2012).

Veriﬂow: Verifying network-wide invariants in real

time. ACM SIGCOMM Computer Communication Re-

view, 42(4):467–472.

Larsen, P., Brunthaler, S., Davi, L., Sadeghi, A.-R., and

Franz, M. (2015). Automated software diversity. Synt-

hesis Lectures on Information Security, Privacy, &

Trust, 10(2):1–88.

Mai, H., Khurshid, A., Agarwal, R., Caesar, M., Godfrey, P.,

and King, S. T. (2011). Debugging the data plane with

anteater. ACM SIGCOMM Computer Communication

Review, 41(4):290–301.

Melin, A., Ferragut, E., Laska, J., Fugate, D., and Kisner, R.

(2013). A mathematical framework for the analysis of

cyber-resilient control systems. In Resilient Control

Systems (ISRCS), 2013 6th International Symposium

on, pages 13–18.

Miu, A., Balakrishnan, H., and Koksal, C. E. (2005). Impro-

ving loss resilience with multi-radio diversity in wi-

reless networks. In Proceedings of the 11th Annual

International Conference on Mobile Computing and

Networking, MobiCom ’05, pages 16–30, New York,

NY, USA. ACM.

Nicol, D. M. and Mallapura, V. (2014). Modeling and ana-

lysis of stepping stone attacks. In Proceedings of the

2014 Winter Simulation Conference, WSC ’14, pages

3036–3047, Piscataway, NJ, USA. IEEE Press.

ONF (2013). Openﬂow switch speciﬁca-

tion, version 1.4.0 (wire protocol 0x05).

https://www.opennetworking.org/images/stories/

downloads/sdn-resources/onf-speciﬁcations/

openﬂow/openﬂow-spec-v1.4.0.pdf.

Qazi, Z. A., Tu, C.-C., Chiang, L., Miao, R., Sekar, V.,

and Yu, M. (2013). Simple-fying middlebox policy

enforcement using sdn. In ACM SIGCOMM Compu-

ter Communication Review, volume 43, pages 27–38.

ACM.

Qin, P., Dai, B., Huang, B., and Xu, G. (2014). Bandwidth-

aware scheduling with sdn in hadoop: A new trend for

big data. arXiv preprint arXiv:1403.2800.

Rahman, M. A. and Al-Shaer, E. (2013). A formal frame-

work for network security design synthesis. In Distri-

buted Computing Systems (ICDCS), 2013 IEEE 33rd

International Conference on, pages 560–570. IEEE.

Sahinoglu, M. (2006). Quantitative risk assessment for de-

pendent vulnerabilities. In Reliability and Maintai-

nability Symposium, 2006. RAMS ’06. Annual, pages

82–85.

Shullich, R., Chu, J., Ji, P., and Chen, W. (2011). A survey

of research in stepping-stone detection. International

Journal of Electronic Commerce Studies, 2(2):103–

126.

Son, S., Shin, S., Yegneswaran, V., Porras, P., and Gu, G.

(2013). Model checking invariant security properties

in openﬂow. In Communications (ICC), 2013 IEEE

International Conference on, pages 1974–1979.

Verizon (2016). 2016 data breach investigations report.

http://www.verizonenterprise.com/resources/reports/

DBIR 2016 Report en xg.pdf.

Verizon (2017). 2017 data breach investigations report.

http://www.verizonenterprise.com/resources/reports/

rp DBIR 2017 Report en xg.pdf.

Yang, Y., Zhu, S., and Cao, G. (2008). Improving sensor

network immunity under worm attacks: A software

diversity approach. In Proceedings of the 9th ACM

International Symposium on Mobile Ad Hoc Networ-

king and Computing, MobiHoc ’08, pages 149–158,

New York, NY, USA. ACM.

Zeng, J. H. and Kazemian, P. Mini-Stanford Backbone).

https://reproducingnetworkresearch.wordpress.com/

2012/07/11/atpg/.

Zhang, M., Wang, L., Jajodia, S., Singhal, A., and Alba-

nese, M. (2016). Network diversity: a security me-

tric for evaluating the resilience of networks against

zero-day attacks. IEEE Transactions on Information

Forensics and Security, 11(5):1071–1086.

Verifying the Enforcement and Effectiveness of Network Lateral Movement Resistance Techniques

257