Verification of Firewall Reconfiguration for Virtual ...

Verification of Firewall Reconfiguration for Virtual Machines Migrations in the Cloud Yosr Jarrayaa,∗, Arash Eghtesadia , Sahba Sadria , Mourad Debbabia , Makan Pourzandib a

Computer Security Laboratory, CIISE Concordia University, Montreal, Quebec, Canada. b Ericsson Security Research, Ericsson Canada, Montreal, Quebec, Canada.

Abstract While elasticity is valuable to the cloud, it may introduce security flaws due to misconfiguration after virtual machines migration. In this paper, we propose an automated approach to verify distributed firewalls reconfiguration after migration. To this end, we elaborate a language that captures distributed stateless and stateful firewalls with their underlying semantics. Integrated to Cloud Calculus, it allows specifying distributed firewalls topology. We also define semantic equivalence over stateful firewalls that forms the base for our verification approach. Furthermore, we define the property of network access control and state preservation using the concepts of soundness and completeness of firewall configurations. Additionally, we use constraint satisfaction problems to reason about our defined preservation property. Finally, we investigate the correctness and scalability of our approach. Keywords: Security, Verification, Stateful Firewalls, Distributed Firewalls, Cloud Computing, Constraint Satisfaction Problem 1. Introduction The appeal of cloud computing lies in its elasticity, i.e. its capacity to increase or decrease the allocated resources for accommodating workload spikes or resource shortages via seamless migration of virtual machines (VM). In spite of these benefits, elasticity may cause critical security issues due to mis∗

Corresponding author contact information: email:y [email protected]

Phone/Fax:

+1-514-848-2424/3171;

c 2015 Elsevier, Computer Networks. This manuscript version is made available under

the CC-BY-NC-ND 4.0 license. http://http://creativecommons.org/licenses/by-nc-nd/4.0/. The online version of the original article can be found under doi:10.1016/j.comnet.2015.10.008 at http://www.sciencedirect.com/science/article/pii/S138912861500376X

configurations. More precisely, multiple security appliances including packet filters and stateful firewalls are typically deployed to protect the data center resources and its hosted VMs. When a VM migrates, filtering rules should be reconfigured at source and destination locations and state-related information (e.g. existing connections) stored by stateful security appliances and called security context, should be correctly moved to the destination appliances. The importance of security context migration was endorsed by the research community and by the industry. Stateful firewalls use connection state information derived from past communications to make dynamic control decisions. While moving VMs, removing the previous configuration and simply reapplying the policy will cause loss of important state information, dynamically configured rules, and legitimate ongoing connections. As the migration mechanisms may fail, their correctness should be guaranteed (e.g. using auditing mechanisms). This is better illustrated by a bug discovered in a widely used cloud infrastructure management system, namely OpenStack, which prevents security groups from being reapplied after live migration1 . As scale and complexity of data centers are continually increasing and VMs are dynamically and frequently moved, manually verification is unrealistic. In this paper, we propose a reliable framework for detecting and reporting misconfiguration problems in distributed stateful and stateless firewalls due to VM migrations. Previous works on the verification of stateless firewalls proposed to do it with respect to the security policy. However, stateful firewall’s connection states are dynamic information that cannot be captured by the security policy. We advocate that the verification of stateful firewalls compliance after migration can be performed by checking the configuration and state after migration with the last known secure configuration and state, before migration. The main contributions of this paper are manifold: – Elaborate a specification language for stateless and stateful firewalls that captures the filtering rules and the security context states with their underlying semantics described using a denotational style [1]. – Define formally network access control and state preservation property and use the aforementioned semantics to reason about it. – Derive a systematic encoding of distributed stateful and stateless firewalls into a network of constraints expressed in the language of the 1

OSSA-2013-030:https://security.openstack.org/ossa/OSSA-2013-030.html

Sugar constraint solver [2]. – Elaborate an algorithm to generate constraint satisfaction problems (CSPs) formulas that allows the verification of network access control and state preservation property and identifying errors, if any. The paper is organized as follows. Section 2 reviews the related work. Section 3 describes the case study. Section 4 presents the firewall specification language. Section 5 defines network access control and state preservation and how to reason about it. Section 6 presents our verification approach. Section 7 discusses the complexity of our approach. Section 8 demonstrates the application of our approach on the working case study and how it can be used to detect misconfiguration. Section 9 presents performance evaluation of our approach. We conclude the paper in Section 10. 2. Related Work Two main research streams on firewall analysis exist: anomalies detection and resolution, and compliance verification. Several works target anomaly detection and resolution in stateless (e.g. [3, 4, 5, 6, 7]) and stateful firewalls (e.g. [8, 9]). While these works are valuable, they cannot detect rule addition or omission. Our work addresses the second topic. Brucker et al. [10] use test case generation for stateless firewalls; however, this is not suitable for highly dynamic environments such as the cloud. Hassan and Hudec [11] propose equivalence checking between security policy and stateless firewall access control rules. Gawanmeh and Tahar [12] use Event-B and invariants checking to verify firewall configurations consistency against the policy. Acharya and Gouda [13] show that any algorithm solving equivalence of stateless firewall verification can be also used to solve the firewall redundancy checking problem, and vice versa with the same time and space complexities. They highlighted that whether these results would apply on stateful firewalls is still an open problem. Satisfiability verification has been proposed in other works [14, 15, 16]. Al-Shaer et al. [17] model network access control policies as binary decision diagrams (BDDs) and use symbolic model-checking to verify reachability and other security requirements. Gouda et at. [18] verify the correctness of network of stateless firewalls with tree topologies using their own defined formal model, namely firewall decision diagram, and custom verification algorithm to verify accept and discard properties between each pair of domain nodes. While all these works

target stateless firewalls, we address the problem of statefull firewalls, which encompasses the verification of dynamically created information that cannot be captured by static security policy. Instead of comparing the configuration with the security policy, we compare the current security configuration with the last known secure configuration, which will be shown to be well-suited for frequently changing environments.

Vi2

Vi14

Vi3

Vi13

Vi1

Vi4

Vi9

Vi10

Vi4

Stateful vF3

vF1 - state

tcp tcp ⋯

estab estab ⋯

Vi4 Vi3 1029 Vi3 Vi1 1028 ⋯ ⋯ ⋯

8000 3306 ⋯ Stateful vF2

Vi7

Vi12

Stateful vF4

vS1 vS4

Vi5

Stateful sF1

sF1 - state

tcp tcp tcp ⋯

vS3

vS2

Vi8

Vi6

Vi11

Stateful vF1

estab syn s estab ⋯

IP1 IP2 Vi3 ⋯

Vi4 Vi4 Vi11 ⋯

CorpN

S1

1030 1031 1029 ⋯

R3

443 443 3306 ⋯

Stateful sF2

sF2 - state

tcp ⋯

estab ⋯

Vi3 Vi11 1029 ⋯ ⋯ ⋯

3306 ⋯

R2

R1

Internet

S2

Figure 1: Three-Tier Web Application Deployment Case Study

Several works propose a language for stateless firewalls (e.g. [19, 13]), and others for stateful firewalls (e.g. [8, 20]). The language proposed in [8] is mainly used for firewalls design. Operational semantics is proposed in [20] for stateful firewall rules, but not considering ongoing connections states. Our proposed language mainly differs at the semantic level. To the best of our knowledge, we are the only work proposing a denotational semantics for stateful firewalls and defining a semantic equivalence over them. Finally, our language is integrated in Cloud Calculus [21] to specify distributed firewalls. 3. Cloud Deployment Case Study A typical cloud deployment of three-tier web applications consists of: web, application, and database. We consider two data centers (DW) and (DE), hosting muti-tenants VMs as depicted in Fig. 1. Network topologies are twolevel trees (edge and core tiers) for both data centers. Between two given

zones, there exists a firewall path that enforces the access control between them. Table 1: Excerpt of Firewalls Rules Before and After Migration. After migration, rules/fields to be added are between [ ] and those to be deleted (e.g. remove VM4 from web1) are in bold. sF1 (DW) 1. * 2. CorpN 3. web2,[Vi4] 4. app2 vF1 (DW) 1. app1 2. web1 3. * sF2 (DE) 1. * 2. app1,app2 3. web1,web2 4. CorpN vF3 (DE) 1. * 2. [Vi4]

*

web1,web2,Vj1,Vj3

80,443

new,estab

Allow

* * *

web1,web2,app1,db1 app1 db1

22 8000 3306

new,estab new,estab new,estab

Allow Allow Allow

* * *

db1 app1 web1,Vj3

3306 8000 80,443

new,estab new,estab new,estab

Allow Allow Allow

* * * *

Vj2,[Vi4] db2 app2 app2,db2,[Vi4]

80,443 3306 8000 22

new,estab new,estab new,estab new,estab

Allow Allow Allow Allow

* *

Vj2 [app2]

80,443 [8000]

new,estab [new,estab]

Allow [Allow]

We suppose that the VMs are grouped within logical security groups (i.e. web, app, db) as shown in Fig. 1. In order to secure its instances, a firewall policy is specified for each VM group as follows:(1) Web group: Allow any to connect on ports 80 (HTTP) and 443 (HTTPS),(2) App group: Allow only web group to connect to port 8000, (3) Db group: Allow only application group to connect to port 3306, (4) Default (for all): Allow corporation network (CorpN) on port 22 (SSH) for Secure Shell. We consider the case where Vi4 has to be migrated from DW to DE to be collocated with the group app2. An excerpt of the firewall rules before and after migration are summarized in Table 1. An excerpt of related state tables is shown in Fig. 1. For instance, IP1 could be a user that is actually connected (established TCP connection) to the web service instance Vi4 through port 443. Since the stateful firewall sF 1 connects their respective zones, a record of the connection state is kept in the state table showing the current state of the connection (estab) and the involved parties (IP1 and Vi4 ) with their respective ports. Adding to the migration of Vi4 -related connection states, some firewalls have to be reconfigured after migration.

4. Distributed Firewall Specification Language This section presents our language that captures the syntax and semantics of distributed firewalls. It is integrated into the Cloud Calculus [21] to capture the network topology connecting firewalls. A summary of the notation used in this paper can be found in Appendix A. 4.1. Syntax Cloud Calculus (CC) allows capturing the network topology hierarchically using the concept of ambients. In our context, ambients represent different network components including firewalls, network zones, switches, physical hosts, and VMs. The most relevant subset of its syntax for this work is presented in Fig. 2. A CC process can be defined as follows: (1) nil represents the inactive process (2) P | Q denotes the parallel composition of two processes P and Q (3) A[P ] denotes an ambient A containing a process P (4) F ∶∶ A[P ] denotes an (security) ambient named A containing a running process P and protected by a stateless or stateful firewall denoted by F . (5) A is a reference to an ambient name (6) M.P is the process that executes mobility or communication capability M , and then continues as P . For brevity, capabilities described in [21] will not be detailed here. P, Q

∶ ∶= ∣ ∣

nil A[P ] A

inactivity ambient reference to ambient A

∣ ∣ ∣

P |Q F ∶∶ A[P ] M.P

composition security ambient capability

Figure 2: Processes Syntax Definition from Cloud Calculus

For example, network of Fig. 1 is expressed in CC as DW | DE: DW = sF1 ∶∶ S1[vF1 ∶∶ vS1[Vi1[] ∣ Vi2[] ∣ Vi3[] ∣ Vi4[]] ∣ vF2 ∶∶ vS2[Vi5[] ∣ Vi6[] ∣ Vi7[] ∣ Vj1[]]] DE = sF2 ∶∶ S2[vF3 ∶∶ vS3[Vj2[]] ∣ vF4 ∶∶ vS4[Vk1[] ∣ Vk2[]]]

where sF1, vF1, and vF2 are stateful firewalls in DW and sF2, vF3, and vF4 are stateful firewalls in DE. The syntax for stateless and stateful firewalls is illustrated in Fig. 3. A firewall F has its policy implemented using access control lists containing sequentially organized rules, denoted by R. Specific to stateful firewalls, S is

a table for tracking connections states. Therefore, a stateful firewall configuration F is denoted by ⟨R, S⟩, whereas a stateless firewall configuration is denoted by ⟨R, ∅⟩, or simply R. Stateless and Stateful Firewalls ∶ ∶= ⟨R, S⟩ F Firewall Rules ∶ ∶= 0 R ∣ 1 ∣ (ps ↦ d).R ∶ ∶= allow ∣ deny d Connections States ∶ ∶= ∅ S ∣ {p ∧ tcps = st tcp} ∣ S ∪ S TCP Status st tcp ∶ ∶= none ∣ syn s ∣ syn r ∣ est. ∶ ∶= val.val.val.val ip subnet ∶ ∶= ip/num val ∈ [0, 255] pval ∈ [0, 65535] prot ∈ [0, 255] ⋈ ∈ {=, ∈} ∶ ∶= * ∣ pval ∣ pval .. pval port

Rules Predicates ∶ ∶= st = s ∧ p ∣ p ps Connection State ∶ ∶= new s ∣ est. ∣ rel. ∣ s, s Packets Predicates ∶ ∶= tt p ∣ sip ⋈ add ∣ ps ⋈ port ∣ dip ⋈ add ∣ pd ⋈ port ∣ pr = prot ∣ icmp-t = type ∣ icmp-c = code ∣ icmp-id = id ∣ syn = flag ∣ ack = flag ∣ ¬p ∣ p ∧ p add ∶ ∶= * ∣ subnet ∣ ip flag ∈ {0, 1}

src addr src port dst addr dst port protocol

Figure 3: Stateful and Stateless Firewall Syntax

A firewall rule is denoted by ps ↦ d where predicate ps is the conjunction of predicates over packets’ attributes in the case of a stateless firewall, and additionally the predicate over the states to be tracked for the given rule, in the case of a stateful firewall. The decision of the rule is denoted by d. The rules 0 and 1 are “deny all” and “accept all” policies, respectively. The commonly used attributes in the packet header are protocol pr, source IP address sip, destination IP address dip, source port number ps, and destination port number pd. Stateful rules require additional attributes mainly connection state st (new, established, or related). Other packet attributes related to a specific protocol are needed to track connection states such as ICMP type and code and TCP syn and ack flags. For each new accepted

connection, a new entry is added into S that is composed of the conjunction of predicates over packet attributes as well as the TCP connection state tcps (none is used for stateless protocols such as UDP). The protocol is indicated by its number (e.g pr= 6 for TCP protocol) and the constant num represents the bit-length of the allocated network prefix. The symbol *, depending on its position, denotes the range of possible values in terms of IP or port. A range of port values is denoted by pval .. pval. Assume that 192.168.10.0/24, 192.168.11.0/24, and 192.168.12.0/24 are the subnets associated with groups web1, app1, and db1, respectively, and that the IP addreses of Vi4, Vi3, Vi1 are 192.168.10.14, 192.168.11.13, and 192.168.12.11, respectively. The stateful firewall rules of vF1 (c.f. Table 1) can be written as RvF 1 = r1.r2.r3.r4. For brevity, we detail only r1: r1 ∶= pr = 6 ∧ sip = 192.168.11.0/24 ∧ dip = 192.168.12.0/24 ∧ ps = ∗ ∧ pd = 3306 ∧ st = new, est. ↦ allow

A subset of the state table SvF 1 as provided in Fig. 1 is as follows: {pr = 6∧tcps = est.∧sip = 192.168.10.14∧dip = 192.168.11.13∧ps = 1029∧pd = 8000}.

Let ⊙ be the binary path operator over firewalls such that F = F1 ⊙ F2 is called a firewall path where F2 only analyzes the traffic that have been accepted by F1 . Note that ⟨1, S⟩ and ⟨0, S⟩ are the neutral element and the absorbing element, respectively, for the path operator. Thus, we have the following properties: ⟨1, S⟩ ⊙ F = F ⊙ ⟨1, S⟩ = F

and

⟨0, S⟩ ⊙ F

= F ⊙ ⟨0, S⟩ = ⟨0, S⟩

Let F↓p be the projection of a firewall F over a predicate p, such that F↓p accepts all packets that are accepted by F and satisfied by the predicate p and denies all packets that are denied by F and satisfied by p. As will be shown later, the concept of projection of firewalls over predicates is useful in elaborating the reasoning about our preservation property in Section 5. 4.2. Firewalls Denotational Semantics In the literature on stateless firewalls, it is agreed that their meanings can be naturally expressed in terms of sets of accepted and denied packets. In the following, we extend this to stateful firewalls. We define the semantics of firewalls using a denotational style [1]. The semantics of a predicate p is the set of packets satisfying it. More formally, let K be the set of all packets and P is the set of predicates, the denotational semantics function J−KK ∶ P Ð→ K is defined as follows: JpKK = {h ∈ K ∶ h ⊧ p}, where h ⊧ p means that the packet attributes

respect the formula p. Let att(h) be the value of the attribute of packet h corresponding to att ∈ {sip, dip, ps, pd, pr, icmp-t, icmp-c, icmp-id, syn, ack}. Let value ∈ {pval, ip, prot, type, code, flag}. Then, h ⊧ p is defined as follows: h ⊧ tt

h ⊧ att ⋈ value

h ⊧ ¬p

if h ⊭ p

h ⊧ p1 ∧ p2

if att(h) ⋈ value if h ⊧ p1 and h ⊧ p2

Let p̂ be the predicate derived from p such that the values sip and dip as well as ps and pd are swapped, respectively. Let p′ = p[att1 , att2 , ⋯, attn ] be a predicate built using a subset of the attributes of p, i.e. att1 , att2 ,⋯, and attn . For instance, we have p′ = p[sip, dip, ps, pd], if prot = tcp or p′ = p[sip, dip], if prot ∈ {icmp, udp}. The semantics of a record S of connection states, denoted by J−KK , is the set of packets accepted as a part of a recorded session up to the current state. More formally, we have: J∅KK =∅ J{p ∧ tcps = none}KK ={h ∈ K ∶ h ⊧ p ∧ pr(h) ≠ tcp} J{p ∧ tcps = syn s}KK ={h ∈ K ∶ h ⊧ p ∧ pr(h) = tcp ∧ syn(h) = 1 ∧ ack(h) = 0} J{p ∧ tcps = syn r}KK ={h ∈ K ∶ h ⊧ p ∧ pr(h) = tcp ∧ syn(h) = 1 ∧ ack(h) = 1} J{p ∧ tcps = est.}KK ={h ∈ K ∶ h ⊧ p ∧ pr(h) = tcp ∧ syn(h) = 0 ∧ ack(h) = 1} JS1 ∪ S2 KK =JS1 KK ∪ JS2 KK

The semantics of a stateful firewall, J⟨R, S⟩KK , is the tuple (α, β), such that α is the set of accepted packets and β is the set of denied packets. More formally, J⟨R, S⟩KK is defined as follows: J⟨0, S⟩KK = (∅, K) J⟨1, S⟩KK = (K, ∅) J⟨(ps ↦ d).R, S⟩KK = J⟨ps ↦ d, S⟩KK ⊎ J⟨R, S⟩KK such that if J⟨ps ↦ d, S⟩KK = (α, β) and J⟨R, S⟩KK = (α′ , β ′ ) we have (α, β) ⊎ (α′ , β ′ ) = (α ∪ (α′ ∖ β), β ∪ (β ′ ∖ α)), where J⟨ps ↦ d, S⟩KK is defined as follows: J⟨p ↦ allow, S⟩KK = (JpKK , ∅) J⟨p ↦ deny, SKK = (∅, JpKK ) J⟨(st = new) ∧ p ↦ allow, S⟩KK = (J((p ∧ ack = 0) ∨ (̂ p ∧ ack = 1)) ∧ syn = 1KK ∖ JSKK , ∅) J⟨(st = new) ∧ p ↦ deny, S⟩KK = (∅, JpKK ) J⟨(st = est.) ∧ p ↦ allow, SKK = (J(p ∨ p̂) ∧ syn = 0 ∧ ack = 1KK ∩ JSKK , ∅) J⟨(st = est.) ∧ p ↦ deny, S⟩KK = (∅, J(p ∨ p̂) ∧ syn = 0 ∧ ack = 1KK ∩ JSKK )

J⟨(st = rel.) ∧ p ↦ allow, SKK = (Jp′ ∨ p̂′ KK ∩ JSKK , ∅) J⟨(st = rel.) ∧ p ↦ deny, S⟩KK = (∅, Jp′ ∨ p̂′ KK ∩ JSKK ) J⟨(st = s1 , s2 ) ∧ p ↦ d, S⟩KK = J⟨st = s1 ∧ p ↦ d, S⟩KK ∪ J⟨st = s2 ∧ p ↦ d, S⟩KK

The semantics of firewall path is JF ⊙F ′ KK = JF KK ⊕JF ′ KK , such that (α, β)⊕ (α′ , β ′ ) = (α ∩ α′ , β ∪ β ′ ). The semantics of the projection of a firewall is the firewall such that if JF KK = (α, β), then JF↓p KK = (α ∩ JpKK , β ∩ JpKK ) It has been shown in [13] that two stateless firewalls are equivalent if and only if for any packet either they both accept it or both discard it. Recall that a denotational semantics defines a semantic equivalence relation [1]. Thus, based on the defined denotational semantics J⟨R, S⟩KK , we define the semantic equivalence for stateful and stateless firewalls as follows: Definition 1. Firewall (Semantic) Equivalence. Two firewalls F1 and F2 are (semantically) equivalent regarding the denotational semantic model, denoted by F1 ∼ F2 , if JF1 KK = JF2 KK . Proposition 1. Projection of firewalls over predicates is distributive over ′ the path operator, i.e. (F ⊙ F ′ )↓p ∼F↓p ⊙ F↓p . Proof. The proof can be derived using the semantics of ⊙ and ↓ operators along with the distributive law in set theory. See Appendix B.

Proposition 2. If two firewalls F and F ′ are equivalent (i.e. F ∼ F ′ ), their respective projections on the same predicate p are also equivalent, i.e. ′ F↓p ∼ F↓p . Proof. This is straightforward from definition of ↓ and definition of firewall equivalence in Definition 1. See proof in Appendix C. ′ ′ It is worth noting that the reverse is false unless F↓p ∼ F↓p and F↓¬p ∼ F↓¬p . This can be generalized to n-predicates forming a partition of K.

Proposition 3. For any firewall F and any predicate p, we have JF Kk = JF↓p KK ∪ JF↓¬p K . Proof. As p and ¬p form a partition of K, this can be proven using set theory distributive laws. See Appendix D.

4.3. Cloud Calculus Denotational Semantics Cloud calculus allows specifying the network model of cloud’s data centers. The purpose of a network model is to identify the network components and its topology including the security appliances with their respective configurations. It also allows determining the set of possible paths between zones and thus, the set of security devices that are traversed by a traffic flow, knowing the source and destination zones. Thus, CC semantics can be expressed in terms of paths connecting security appliances to different zones. Let F be the set of firewall paths and C the set of cloud calculus terms. In order to infer firewall paths from the network topology, we define J−KF ∶ C → 2F to be a semantic function that generates the set of firewall paths and it is defined as follows: JnilKF =∅ JM.P KF =JP KF JF ∶∶ A[P ]KF ={F } ⊙ JP KF

JP ∣ QKF =JP KF ∪ JQKF ∪ JP KF ⊗ JQKF JA[P ]KF =JP KF JAKF =JA[P ]KF

where ⊗ is the composition operator over sets of firewall paths such that if π denotes a firewall path, {F ⊙ π} ⊗ {F ⊙ π ′ }= {π t ⊙ F ⊙ π ′ } where π t is the reverse path of π. The results of applying J−KF on terms DW and DE obtained earlier are paths in the data centers as follows: JDWKF = {vF1} ∪ {vF2} ∪ {sF1 ⊙ vF1} ∪ {sF1 ⊙ vF2} ∪ {vF1 ⊙ sF1 ⊙ vF2} JDEKF = {vF3} ∪ {vF4} ∪ {sF2 ⊙ vF3} ∪ {sF2 ⊙ vF4} ∪ {vF3 ⊙ sF2 ⊙ vF4}

Note that {F } ⊙ {π} = {F ⊙ π}. The operator ⊙ is distributive over ∪ and ⊗. The operator ⊙ takes precedence over ⊗, which takes precedence over ∪. 5. Network Access Control and State Preservation In the following, we define the property of network access control and state preservation. Data centers can be partitioned into network zones Z ∈ Z , which are logical grouping of VMs. The outside domain (i.e. Internet) is an additional zone. Communications between zones are generally secured using one or several firewalls, forming a firewall path. A security policy Φ can be denoted formally as {pi ↦ di }1≤i≤n and it generally specifies accepted/denied traffic according to the VM’s access policy. For instance, a policy that allows all web traffic to V i5 can be expressed as follows:{prot = 6 ∧ sip = ∗ ∧ dip = V i5 ∧ (pd = 80∨pd = 443) ↦ allow}. Let Φij be the network access policy between all VMs located in Zi and Zj such that Φij = Φ∀vp ∈Zi ↔∀vq ∈Zj = ⋃∀vp ∈Zi ,∀vq ∈Zj Φvp ↔vq ,

where vp ∈ Zi ↔ vq ∈ Zj means the bidirectional communication between vp ∈ Zi and vq ∈ Zj . The policy of a given vo ∈ Zi between Zi and Zj is denoted by Φij/v0 = Φv0 ↔∀vq ≠v0 ∈Zj . Let Sij be the union of all ongoing connections between Zi and Zj , which are a subset of all possible connections between these zones, i.e. Sij ⊆ S∀vp ∈Zi ↔∀vq ∈Zj . For a given vo ∈ Zi , Sij/v0 ⊆ Sv0 ∈Zi ↔∀vq ∈Zj represents all possible connections between vo and VMs in Zj . Let F be the set of all firewall paths. Let Fij ∈ F be the firewall path implementing the security policy Φij and having Sij as the current connections state between Zi and Zj . When v0 migrates from one location to another, communications between v0 and other VMs may have to be re-routed (e.g. to optimize communication delays). In these conditions, the implemented security policy in several firewall paths needs to be updated accordingly; either the firewalls traversed before migration are no longer in the routing path or new firewalls have to be traversed after migration. Additionally, ongoing connections states stored by the firewalls need to be maintained through the new routes. Let migrate be a migration process implementing the reconfiguration of firewall paths during migration. Let Fijb and Fija be the configuration of the same firewall path Fij , before and after migration respectively, such that migrate(Fijb ) = Fija . Let Φbij and Φaij be the security policy before and after migration, respectively. Let Sijb and Sija be the ongoing connections states before and after migration, respectively. Previous initiatives on stateless firewalls verification (e.g. [19]) have defined the concepts of soundness and completeness for stateless firewall configuration with respect to a policy. Informally, a non-empty stateless firewall configuration is sound if it complies with the pre-defined non-empty security policy and it is complete if every requirement of the security policy is implemented by the configuration. In our case, under the conditions that JF KK ≠ (∅, ∅) and J⟨Φ, S⟩KK ≠ (∅, ∅), a stateful firewall configuration F is sound if it complies with the pre-defined non-empty security policy and it stores the same ongoing connection states (i.e. JF KK ⊑ J⟨Φ, S⟩KK ). And it is complete if every requirement of the security policy is implemented by the configuration and every ongoing connection states corresponds to the states stored in the firewall (i.e. JF KK ⊒ J⟨Φ, S⟩KK ). Then, we have JF KK = J⟨Φ, S⟩KK if F is sound and complete. Note that if JF KK = (α, β) and J⟨Φ, S⟩KK = (α′ , β ′ ), then JF KK ⊑ J⟨Φ, S⟩KK means α ⊆ α′ and β ⊆ β ′ . We rely on these concepts to define network access control and state preservation

property in data centers, as follows: Definition 2. Network Access Control and State Preservation. Let assume that for a given data center, ∀ Fij ∈ F we have JFijb Kk ˆ J⟨Φbij , Sijb ⟩Kk for ˆ ∈ {=, ⊆, ⊇} where JFijb KK ≠ (∅, ∅) and J⟨Φbij , Sijb ⟩KK ≠ (∅, ∅). For any migrating VM v0 , the migration process is said to preserve network access control and state after migration if ∀ Fij , we have JFija Kk ˆ J⟨Φaij , Sija ⟩Kk with JFija KK ≠ (∅, ∅) and J⟨Φaij , Sija ⟩KK ≠ (∅, ∅). In order to verify such a property, we present in the following the sufficient conditions to decide on whether preservation holds. Before that, we present first some useful definitions and results that help in identifying these conditions. We distinguish between two types of firewall paths: affected and non affected firewall paths. The affected firewall paths are those that should be reconfigured after a given VM migration, and the definition is as follows: Definition 3. Affected Firewall Path. Let v be a migrating VM. A firewall path Fij between (Zi , Zj ) is said to be affected if its policy Φij and/or connection states need to be updated after migration of v with (non nul) policy and state. Let Fvu ⊂ F be the set of all affected firewall paths. Let map ∶ Z → Z , be a function that maps a zone to its image after v migration, such that map(Z) = Z if Z ≠ Z b and map(Z b ) = Z a . Let mig ∶ F → F be a function that maps a firewall path before migration into a firewall path after migration, such that mig(Fij ) = Fkl , where map(Zi ) = Zk , and map(Zj ) = Zl . The following proposition characterizes the difference between firewall paths in Fvu and in F ∖ Fvu and relates the corresponding policies and connections states before and after migration. Proposition 4. Let v0 be a migrating VM located initially at Z b and migrating to Z a such that Z a ≠ Z b . Let Φij/v0 ≠ ∅ be the security policy concerning v0 and Sij/v0 be the state of the connection from and to v0 between any two zones Zi and Zj where Fij is the corresponding firewall path. We have the following: – If Z b ∈ {Zi , Zj }, then Fij ∈ Fvu0 and we have: b Φaij = Φbij ∖ Φbij/v0 and Sija ⊆ Sijb ∖ Sij/v 0

(1)

– If Z a ∈ {Zi , Zj }, then Fij ∈ Fvu0 and ∃ Zk ∈ Z s.t. map(Zk ) = Z a and Zl and we have b Φaij = Φbij ∪ Φbkl/v0 Sija ⊆ Sijb ∪ Skl/v (2) 0

Table 2: Firewall (Affected and Non Affected) Paths Before and After Migration Affected Before After vF 1 vF 1 ⊙ sF 1 ⊙ sF 2 ⊙ vF 3 vF 1 ⊙ sF 1 vF 3 ⊙ sF 2 vF 1 ⊙ sF 1 ⊙ vF 2 vF 3 ⊙ sF 2 ⊙ sF 1 ⊙ vF 2 vF 1 ⊙ sF 1 ⊙ sF 2 ⊙ vF 3 vF 3 vF 1 ⊙ sF 1 ⊙ sF 2 ⊙ vF 4 vF 3 ⊙ sF 2 ⊙ vF 4

– Fij ∉ Fvu0 , otherwise, and we have Φaij = Φbij

Sija = Sijb

Non Affected Before (=After) vF 2 vF 4 vF 2 ⊙ sF 1 vF 4 ⊙ sF 2 ⊙ vF 3

(3)

Proof. The proof is based on Definition 3 and the definitions of Z a and Z b , whether they are either source or destination of communication or not, before and after migration, respectively. More precisely, proving that v0 does not belong to any of the communicating zones Zi and Zj implies that no security policy and context related to v0 actually exist between these two zones. The complete proof can be found in Appendix E. Consider the cloud deployment illustrated in Fig. 1 where V i4 migrates from DW to DE. Therein, vF 1 is an affected firewall path, whereas, vF 2 is not. Table 2 summarizes the firewall paths before and after migration classified either as affected or non affected. Proposition 5. Let p be a predicate of the form p = (sip = v0 ∨ dip = v0 ). Let Φij and Φij/v0 be the security policy associated with all inter-communications of VMs in Zi ∪ Zj and associated with v0 and all VMs in Zi ∪ Zj , respectively. Let Sij and Sij/v0 be the states of the ongoing connections among VMs in Zi ∪ Zj and state of connection between v0 and VMs in Zi ∪ Zj , respectively. ∀ (Zi , Zj ) such that v0 ∈ {Zi , Zj }, these equations hold: (4) ⟨Φij , Sij ⟩↓¬p ∼⟨Φij , Sij ⟩ ∖ ⟨Φij/v0 , Sij/v0 ⟩ ⟨Φij , Sij ⟩↓p ∼⟨Φij/v0 , Sij/v0 ⟩ (5) ⟨Φij , Sij ⟩ ∼⟨Φij , Sij ⟩↓¬p ∪ ⟨Φij , Sij ⟩↓p (6) Proof. This can be proved using results from set theory, i.e. A = B iff A ⊆ B and B ⊆ A. It is based on proving by contradiction that elements of A are necessarily elements of B and vice versa. We mainly rely on the definition of ↓ operator and set theory involving intersection, union and De Morgan’s Laws. The complete proof can be found in Appendix F.

Proposition 6. ∀ p predicate, ∀Fij firewall path with a security policy Φij and state Sij between zones (Zi , Zj ), if JFij KK ˆJ⟨Φij , Sij ⟩KK then JFij↓p KK ˆ J⟨Φij , Sij ⟩↓p KK . Proof. Proof is straightforward from definition of ↓ and set theory. The following theorem allows us to reason about the network access control and state preservation property by providing the sufficient conditions that allows deciding whether this property holds. Theorem 1. Network Access Control and State Preservation. For any migrating VM v0 and ∀ Fij , Fkl ∈ F , such that Fkl = mig(Fij ) and b JFijb KK ˆ J⟨Φbij , Sijb KK ⟩ and JFklb KK ˆ J⟨Φbkl , Skl ⟩KK for ˆ ∈ {=, ⊆, ⊇}. Let p be predicates such that p = (sip = v0 ∨ dip = v0 ). The migration process preserves network access control and state on Fij and Fkl if one of the followings holds: – If Fij ∉ F u JFija KK =JFijb KK

(7)

– If Fij ∈ F u and Fkl ∈ F u such that Zi = Z b or Zj = Z b and (Zk = Z a or Zl = Z a ), then the followings hold: b JFija KK =JFij↓¬p KK (8) a b JFkl↓¬p KK =JFkl↓¬p KK a JFkl↓p KK

b =JFij↓p KK

(9) (10)

Proof. The proof can be derived using results from set theory on the equality of two sets (i.e. A = B iff A ⊆ B and B ⊆ A), proposition 6, equations in propositions 4 and 5 as well as the hypothesis stated in this theorem. We provide hereafter a sketch of the proof of soundness for the case Fij , Fkl ∈ F u such that Fkl = mig(Fij ). b JFij↓¬p KK ⊆J⟨Φbij , Sijb ⟩↓¬p KK (hypothesis, prop6) b b JFij↓¬p KK ⊆J⟨Φbij , Sijb ⟩KK ∖ J⟨Φbij/v0 , Sij/v ⟩KK 0

JFija KK

b ⊆JFij↓¬p KK

⊆

J⟨Φaij , Sija ⟩KK

(Eq4) (Eq1, Eq8)

Thus, we conclude on soundness of Fij . The complete proof can be found in Appendix G.

6. Verification Framework We assume all firewall anomalies (e.g. shadowing, correlation, and redundancy) are resolved using existing approaches (c.f. Section 2). Hereafter, we explain how to encode a single firewall and then distributed firewalls as CSP constraints. We also present our algorithm to generate CSP constraints for the verification of preservation property defined in Section 5. 6.1. Encoding Firewalls as CSP Constraints A constraint satisfaction problem (CSP) is a system of logical formulas over variables in their domains. Constraint solving involves finding solutions to a CSP where each solution is an assignment of values to all variables such that all constraints are satisfied. In this work, we use Sugar [2], a SAT-based constraint solver, whose syntax is Lisp-like expressions. We encode the firewalls’ filtering conditions and decisions of the rules as well as the connection states information as integer variables V . IP addresses require 4 integer variables within the range [0, 255]. A source (resp. destination) IP address is represented by {sipi }1≤i≤4 (resp. {dipi }1≤i≤4 ). The variable pr ∈ [0, 255] represents the protocol number. Two other integer variables within [0, 65535] are used to encode the source and destination port numbers, respectively ps and pd. We define an additional variable d to encode decision of the rule such that 0 is for “deny” and 1 is for “allow”. In the case of stateless firewall, the set of integer variables in CSP is V = {pr, sip1, sip2, sip3, sip4, ps, dip1, dip2, dip3, dip4, pd, d}. In order to encode the connection state table S, we use a variable ts ranging over [0..3] for the TCP connection state, such that a TCP syn packet corresponding to syn s will be encoded such that ts = 1, a TCP syn-ack packet (syn r) corresponds to ts = 2, and a TCP ack packet (est.) corresponds to ts = 3. Thus, the set of CSP variables for stateful firewalls is Vs = V ∪ {ts}. The value 0 is reserved for tcps =none. Firewall rules and records of the state table are encoded as predicates expressed as a conjunction of sub-predicates relating variables in Vs to their corresponding values as specified in the firewall rule or in the state table. For instance, a predicate sip = 192.168.1.20 ∧ dip = 192.168.1.1 ↦ deny would be written in Sugar syntax as follows: (and (= sip1 192) (= sip2 168) (= sip3 1) (= sip4 20) (= dip1 192) (= dip2 168) (= dip3 1) (= dip4 1) (= d 0))

Table 3: Firewall Rules and States Mapping to Logical Formulas s new est. rel. -

Firewall Rules logical formula (p ∧ d ∧ (ts = 1)) ∨ (̂ p ∧ d ∧ (ts = 2)) (p ∧ d ∧ (ts = 3)) ∨ (̂ p ∧ d ∧ (ts = 3)) ′ (p ∧ d ∧ (ts = 0)) ∨ (p̂′ ∧ d ∧ (ts = 0)) p ∧ d ∧ (ts = 0)

Connections States tcps logical formula none p ∧ (ts = 0) syn s p ∧ (ts = 1) syn r p ∧ (ts = 2) est. p ∧ (ts = 3)

Table 3 summarizes the logical formulae for each type of rule and connection state record. The connection state table S composed of session records is encoded in CSP as a disjunctive logical formula over all constraints of the records. Let Cr1 and Cr2 be the CSP formula for two given firewall rules such as r1 comes before r2. In order to take into account the order between r1 and r2, we encode the sequence r1.r2 into Cr1 ∨ (¬Cr1 ∧ Cr2 ). We use such encoding to encode all ordered rules of a firewall. Let C be the CSP formula encoding all the stateless firewall rules. Let Cn , Ce , and Cr be the CSP formula encoding all firewall rules with st = new, st = est., and st = rel., respectively. Let CS be the generated CSP constraint for the state table. In the case of an empty state table, CS = f alse The CSP formula encoding a stateful firewall F is as follows: CF = C ∨ (Cn ∧ ¬CS ) ∨ (Ce ∧ CS ) ∨ (Cr ∧ CS ). The disjunction in CF is required as any packet that belongs to one or the other category (belongs to new, established, or related session) is a solution of CF where the value of d for that solution categorizes the packet as accepted (d = 1) or as discarded (d = 0). Finally, a firewall path F =F1 ⊙ ⋯ ⊙ Fk is encoded in CSP as a conjunction of all constraints CFi , i.e. CF1 ∧CF2 ∧⋯∧CFk . 6.2. Generating Constraints from the Network Model In this section, we present the algorithm that we developed in order to generate a set of CSP constraints from the topology of the cloud data centers involved in the migration process. These constraints encode the conditions defined in Theorem 1, which were proved to be sufficient to verify that the preservation property holds. We assume all firewalls configuration are encoded as CSP constraints as described in Section 6.1. As we are dealing with a comparison between sets, the mapping from equations in Theorem 1 to constraints relies on a well-known result from set theory. Given two sets A

and B, A = B holds if and only if A ⊆ B and B ⊆ A. Let A and B be sets of solutions for CSP constraints C1 and C2 , respectively. We have A ⊆ B implies C1 ∧ ¬C2 ⊧ UNSAT and B ⊆ A implies C2 ∧ ¬C1 ⊧ UNSAT. 1: procedure GenCSP(paths) 2: for all Fij ∈ paths do 3: if src(Fij ) ∉ {Z b , Z a } and dst(Fij ) ∉ {Z b , Z a } then a b b a } ▷ Eq 7 ∧ ¬Cij } ∪ {Cij ∧ ¬Cij 4: C = C ∪ {Cij b 5: else if (src(Fij ) = Z or dst(Fij ) = Z b ) then ▷ Fkl =mig(Fij ) a b b a 6: C = C ∪ {Cij ∧ ¬(Cij ∧ C¬p )} ∪ {(Cij ∧ C¬p ) ∧ ¬Cij } ▷ Eq 8 a b b a 7: C = C ∪ {Ckl ∧ C¬p ∧ ¬(Ckl ∧ C¬p )} ∪ {Ckl ∧ C¬p ∧ ¬(Ckl ∧ C¬p )}∪ ▷ Eq 9 b a a b 8: {Cij ∧ Cp ∧ ¬(Ckl ∧ Cp )} ∪ {Ckl ∧ Cp ∧ ¬(Cij ∧ Cp )} ▷ Eq 10 9: end if 10: end for 11: return C 12: end procedure Figure 4: Constraints Generation

Let Cijt be the constraint that encodes the firewall path JFijt KK before or t after migration, where t ∈ {a, b}. JFij↓p KK is encoded as Cijt ∧ Cp , where Cp is the encoding of the predicate p = (sip = v0 ∨ dip = v0 ) defined in Theorem 1. The algorithm that generates all constraints related to the verification of preservation property is provided in Fig. 4 given a set of firewall paths. These constraints should be UNSAT, otherwise, one can conclude that preservation property doesn’t hold in all paths and migration errors can be detected by analyzing the solution provided by Sugar. For t, t′ ∈ {a, b}, the satisfiability of these constraints (i.e. a SAT result) implies an incorrect migration process, and the interpretation of each satisfiable constraint is as follows: ′

– Cijt ∧¬Cijt ⊧ SAT: At least a packet h is treated differently by the firewall Fij before and after migration. However, it should not as this is a non affected path. – Cija ∧¬(Cijb ∧C¬p ) ⊧ SAT: At least a packet h not concerning the migrating VM on which the decision of Fij has changed after migration (but it should not). For example, a new rule is added after migration but not related to v0 . – (Cijb ∧ C¬p ) ∧ ¬Cija ⊧ SAT: Similar to the previous satisfiable constraint. However, it corresponds to a rule deleted after migration but not related to v0 .

′

t t ∧ ¬Cp ) ⊧ SAT: At least a packet h not concerning the – Ckl ∧ ¬Cp ∧ ¬(Ckl migrating VM on which the decision of Fkl has changed after migration. ′

t ∧ Cp ) ⊧ SAT: there exists at least a packet h concerning – Cijt ∧ Cp ∧ ¬(Ckl the migrating VM (i.e. having source or destination v0 ) on which the decision of Fij before migration is not consistent with the decision of Fkl after migration, where Fkl = mig(Fij ). This corresponds to the case where the migration processes deleted or added a v0 rule.

7. Complexity Let p be the number of firewall paths. Let kp be the number of firewall rules per path. The most computational intensive parts of our approach are: compute all paths, generate CSP constraints, and verify constraints using Sugar. Note that we assume a static setup of the network topology during verification and computation of all paths happens less frequently then VMs migration. The time complexity of our approach is then bounded by Procedure GenCSP (CSP constraints generation) and by SolveConstraints using Sugar. Procedure GenCSP encodes each firewall configuration into CSP files, which consists in sequentially exploring all rules/states. The complexity of GenCSP depends on two nested loops respectively depending on p and kp . Thus, time complexity of GenCSP is O(pkp ). Sugar is based on the order encoding [2]; the resulting CSP instances have been shown to be tractable and can be solved by standard SAT-solvers polynomial-time in the number of clauses [22]. According to results obtained during our performance-related experiments, the number of clauses of our encoding increases linearly with the number of rules and states. This means the time complexity is polynomial in the number of rules, which is O(p × kp ). Therefore, the upper bound time complexity of our approach is O(p × kp ). 8. Applicability Evaluation Experimental Setup We used the Graphical Network Simulator (GNS3) Cisco tool as our simulation testbed. The latter enables the design of network topologies connected to the real world, the emulation of various Cisco devices, the simulation of switches, and integration with the Oracle VM VirtualBox2 . We also used statefull firewalls provided by Cisco IOS 3725 and 2

https://www.virtualbox.org/

ASA 5520 components available in GNS3. First, we implemented the network topologies of both data centers presented in Fig. 1. We also pre-configured the firewalls according to the security policies before migration of Vi4 . We coded a migration process that reconfigures the firewalls after migration by adding/removing rules or state using the firewall management interface. We designed several migration scenarios that introduce different misconfigurations in the firewalls. Among them, we have the following: omission of adding a (randomly selected) rule at a destination firewall after migration, omission of adding a (randomly selected) connection state, and randomly adding an extra rule not in the security policy. In order to simulate network traffic and detect whether the firewall paths allow/deny specific traffic, we used Zenmap3 , a Windows GUI for Nmap security scanner, to scan all ports of a target VM, from different locations. We also used the packet analyzer Wireshark4 to capture packets that successfully passed through the firewall and are received at the destination VM. These tests are run on an Intel core 2 duo computer, 3.00 GHz, with 4.00 GB of RAM. Results and Discussions. Before migration, we ran a first experiment to confirm that all types of traffic specified in Vi4 security policy are correctly handled by the implemented firewalls on all paths. To do that, we used Zenmap to scan the ports of Vi4 from different sources (e.g. CorpN, Vj2 , etc.) while collecting the traffic reaching Vi4 using Wireshark. The analysis of the traffic types with respect to the policy confirmed that the Vi4 security policy is correctly implemented before migration. A copy of the configurations of each firewall is then saved for verification purposes. Our second experiment consists in migrating Vi4 and reconfiguring the firewalls according to the randomly selected misconfiguration scenario. A copy of the new configuration of each firewall is also saved for verification purposes. After migration, we scanned ports of Vi4 at its new location while capturing the traffic successfully passed through the firewalls. Fig. 5 illustrates the chart summarizing the type of traffic observed by Wireshark reaching Vi4 . The x-axis represents the type of packets sent by Zenmap, where the label “others” means any type of traffic other than the ones shown. The y-axis represents the distribution of packets received by Vi4 from different sources. According to the scanning results, there is potentially a misconfigu3 4

http://nmap.org/zenmap/ http://www.wireshark.org/

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

Customer Internet user Vk1 Vj2 Vj1 Vi2 Vi1

HTTP

HTTPS

SSH

ICMP

others

Figure 5: Percentage of Packets per Packet Type and per Source Received by Vi4 with Firewall Configurations. Note the circled area denoting missed SSH traffic reaching Vi4

ration related to SSH traffic, supposed to be received by Vi4 from corporate network, as one can note the circled area in Fig. 5. Our third experiment uses the saved configurations of various firewalls before and after migration and uses our verification approach of the preservation property. Each firewall configuration (rules and states), before and after migration, are systematically encoded into Sugar syntax using the procedure in Section 6.1. Then, algorithm GenCSP described in Fig. 4 is provided with input all paths shown in Table 2 to generate all CSP constraints. After submitting these constraints to the SAT-solver, we obtain all satisfiability results for all constraints. Particularly, SAT was returned for C11 and C12 with a particular assignment to the variables for each. These constraints concern the path vF 3 ⊙ sF 2 using Eq 10, which corresponds to mig(vF 1 ⊙ sF 1), and their expressions are as follows: C11 = (vF 1b ∧ sF 1b ∧ p15 ∧ p) ∧ ¬(vF 3a ∧ sF 2a ∧ p35 ∧ p) C12 = (vF 3a ∧ sF 2a ∧ p35 ∧ p) ∧ ¬(vF 1b ∧ sF 1b ∧ p15 ∧ p)

where vF 1b denotes the encoding of stateful firewall vF 1 before migration in CSP. The predicate pij is of the form sip = Zi ∧ dip = Zj and allows the extraction of only the rules concerning these zones. Both solutions provided by Sugar have in common packet fields values including the source address CorpN , the destination address Vi4, the protocol T CP and the destination port 22. However, the solution for C11 is with an accept decision whereas for C12 it is a deny decision. This pinpoints exactly the problematic rule, which concerns SSH traffic, that was not preserved after migration. While inspecting the firewall rules in vF 3 and sF 2 guided by the solution, one can

CPU time 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0

CPU%

Mem%

60

Time (s)

Usage(%)

50 40 30 20 10

(a) CPU Time (s)

9.64

9.14

8.64

8.14

5.6

7.13

4.6

3.6

2.08

1.08

10.16

Firewall Config. Size per Pair of Zones (thousands of rules+states)

0.08

0 0.08 1.08 2.08 3.6 4.6 5.6 6.7 7.13 7.64 8.14 8.64 9.14 9.64 10.16

0

FirewallConfig.SizeperPairofZones (thousandsofrules+states)

(b) Peak CPU and Memory Usage (%)

Figure 6: (a) CPU Time (s) (b) CPU and Memory Usage as a Function of the Number of Rules and States (thousands of rules and states)

notice the rule allowing SSH traffic towards Vi4 was not added correctly into sF 2 after migration causing the SSH traffic to be dropped. 9. Performance Evaluation The purpose of this experiment is to have an appraisal of the performance of our approach. We use a Ubuntu virtual machine running on VirtualBox configured with one virtual Intel Core CPU running at 1.80 GHz, around 1114 MB of RAM, and 5.86 GB of disk storage. A benefit of our approach is that once the CSP constraints are generated, they can be verified in parallel by several solver instances. Thus, the performance of the largest constraint determines the performance of our approach. The experiments consist in increasing the size of a constraint, which in turn can be achieved by increasing the number of firewall rules and ongoing connection states in a given path, and measuring CPU time, and peaks of CPU and memory usages. This has the same effect as increasing the number of VMs/firewalls in a path. The CPU time for the verification of up to ten thousands rules and states is shown in Fig. 6.(a). The chart shows that the CPU time increases slightly and linearly with respect to the size of the firewall configuration and that the verification of 10.000 rules and states between two given zones takes less than 4 seconds. Fig. 6.(b) shows CPU and memory peak usages. The peak memory usage is slightly changing and remains below 5%. The peak CPU usage, however, has a steady increase as a function of the number of CSP

constraints but remains under 50% for 10.000 rules. The main CPU usage is essentially due to encoding the CSP file to SAT by Sugar before the actual verification. It is worth noting that this peak only lasts less than a second. 10. Conclusion In this paper, we proposed a verification framework for distributed stateful and stateless firewalls in the cloud for the detection of potential firewall misconfigurations in the context of VM migration. It can be used as a basis for an auditing tool for firewalls compliance after reconfiguration. We developed the theoretical foundations underlying our approach by elaborating a specification language for stateless and stateful firewalls endowed with a denotational semantics and semantic equivalence. The latter allowed us to define the property of network access control and state preservation and reason about it. As future work, we envision tackling issues related to frequent routing changes and security policy orchestration in elastic and dynamic cloud. Appendix A. Glossary of symbols This is a glossary of main formal notations used in this paper.

p∈P

A predicate p in a set of predicates

J KK

h∈K

A packet h in the set of all possible packets K Attribute of a packet corresponding to a field in the IP packet The value of the attribute of packet h The first argument satisfies the second argument A predicate derived from p such that the IP and port of source and destination are swapped A predicate derived from p such as only a subset of the sub-predicates are considered Firewall decision of a given rule

F↓p

Denotational semantics for stateless and stateful firewalls Firewall projection over predicate p

v0

the migrating VM v0

( )b

( ) before migration

( )a

( ) after migration

Z

Zone hosting

Fij

Firewall path between Zi and Zj

Fvu

A single firewall rule Sequential firewall rules where 0 and 1 are “deny all” and “accept all” policies, respectively. Security state context

Φij Φij/v0

Set of firewall paths affected by the migration of v Security policy between Zi and Zj Security policy concerning v0 between Zi and Zj

Variable ranging over possible states of a connection Variable denoting the state of a connection

∼

pr

Variable denoting the protocol

sip

Variable denoting the source IP address Variable denoting the destination IP address

Vs and V C r1

att att(h) ⊧ ̂ p p′

d p↦ d R

S s st

dip

F1 ⊙ F2

mig

C, Cn , Ce , Cr , CS

ps

Variable denoting the source port

t Cij

pd

Variable denoting the destination port Variable ranging over the possible states of a TCP connection

Cp

tcps

vF 1b

Firewall path consisting of F1 and F2 Semantic equivalence between firewalls A function that maps a given firewall path to its image after migration Set of CSP variables for stateful and stateless firewalls, respectively. CSP constraint associated with rule r1 CSP formula for: stateless rules, rules with state st = new, rules with state st = est., rules with state st = rel., and ongoing connection states, respectively CSP constraint for the firewall path t K JFij K before or after migration, where t ∈ {a, b} CSP of the predicate p = (sip = v0 ∨ dip = v0 ) The CSP encoding of the configuration (rules and states) of the stateful firewall vF 1 before migration

Appendix B. Proof of Proposition 1 Let JF KK = (α, β), JF ′ KK = (α′ , β ′ ), α1 = α∩JpKK , β1 = β ∩JpKK , α1′ = α′ ∩JpKK , ′ and β1′ = β ′ ∩ JpKK . JF1 KK = (α1 , β1 ) = JF↓p KK and JF1′ KK = (α1′ , β1′ ) = JF↓p KK . ′ ′ ′ JF ⊙ F KK = (α ∩ α , β ∪ β ) Sem. of⊙ J(F ⊙ F ′ ) ↓ pKK = (α ∩ α′ ∩ JpKK , (β ∪ β ′ ) ∩ JpKK ) ′

Sem. of ↓ ′

= ((α ∩ α ∩ JpKK ), (β ∩ JpKK ) ∪ (β ∩ JpKK )) = (α1 ∩ α1′ , β1 ∪ β1′ ) = JF1 KK ⊕ JF1′ KK ′ = JF↓p KK ⊕ JF↓p KK ′ J(F ⊙ F ′ ) ↓ pKK = JF↓p ⊙ F↓p KK

Appendix C. Proof of Proposition 2 F1 ∼ F2 Ô⇒ J(F1 )KK = J(F2 )KK = (α, β). By definition of ↓, JF1↓p KK = (α ∩ JpKK , β ∩ JpKK ) = JF2↓p KK . Thus, F1↓p ∼ F2↓p . Appendix D. Proof of Proposition 3 JF↓¬p KK = (α ∩ J¬pKK , β ∩ J¬pKK ) JF↓p KK = (α ∩ JpKK , β ∩ JpKK ) JF↓¬p KK ∪ JF↓p KK = (α ∩ J¬pKK ∪ α ∩ JpKK , β ∩ J¬pKK ∪ β ∩ JpKK ) = (α ∩ (J¬pKK ∪ JpKK ), β ∩ (J¬pKK ∪ JpKK )) since J¬pKK and JpKK form a partition of K = (α ∩ K, β ∩ K)) = (α, β)) = JF KK

Appendix E. Proof of Proposition 4 If Z a = Z b , no VM migration happens and therefore, no firewall path is affected, i.e. Fvu0 = ∅. From here on, we assume Z a ≠ Z b .

– Case1: Z b ∉ {Zi , Zj } and Z a ∉ {Zi , Zj }. Before migration, v0 ∉ {Zi , Zj }. Thus, we only have other VMs security policies and states. After migration, a b v0 ∉ {Zi , Zj } and thus no change is needed. Thus, Φaij = Φbij and Sij = Sij and Fij ∉ Fvu0 . – Case2: Z b ∈ {Zi , Zj } and Z a ∉ {Zi , Zj }. Assume Z b = Zi , which means v0 ∈ Zi (the case where (Z b = Zj ) can be proved similarly by replacing Zi with Zj ). Thus, before migration we have the security policies and states related to all VMs in Zi and Zj , including v0 , i.e. Φbij = Φ∀v≠v0 ∈Zi ↔∀v≠v0 ∈Zj ∪ b Φv0 ∈Zi ↔∀v≠v0 ∈Zj and Sij ⊆ S∀v≠v0 ∈Zi ↔∀v≠v0 ∈Zj ∪ Sv0 ∈Zi ↔∀v≠v0 ∈Zj . After mia a ⊆ gration, v0 ∈ Z ∉ {Zi , Zj }. Therefore, Φaij = Φ∀v≠v0 ∈Zi ↔∀v≠v0 ∈Zj and Sij S∀v≠v0 ∈Zi ↔∀v≠v0 ∈Zj as no more communications related to v0 between (Zi , Zj ) b b a . ∖ Sij/v ⊆ Sij after migration. Therefore, we have Φaij = Φbij ∖ Φbij/v0 and Sij 0 u Thus, Fij ∈ Fv0 . – Case3: Z a ∈ {Zi , Zj } and Z b ∉ {Zi , Zj }. Assume Z a = Zi (the other case can be proved similarly by replacing Zi with Zj ). Since v0 ∈ Z b ∉ {Zi , Zj }, b ⊆ S∀v≠v0 ∈Zi ↔∀v≠v0 ∈Zj . Let Zk be we have Φbij = Φv≠v0 ∈Zi ↔∀v≠v0 ∈Zj , and Sij b a zone such that Z = Zk ∉ {Zi , Zj } such that map(Zk ) = Zi = Z a and let map(Zj ) = Zj . All communications before migration between v0 ∈ Zk and all VMs in Zj will be rerouted to traverse (Zi , Zj ) after migration. Thus, the b related security policy Φbkj/v0 and states Skj/v should be added to the already 0 set security policy and states related to other VMs communications between a b b (Zi , Zj ). Thus, we should have Φaij = Φbij ∪Φbkj/v0 and Sij ⊆ Sij ∪Skj/v . Thus, 0 u Fij ∈ Fv0 . – Case4: {Z b , Z a } ⊆ {Zi , Zj }. Four sub-cases (Zi , Zj ) = (Z b , Z a ) or (Zi , Zj ) = (Z a , Z b ) or (Zi , Zj ) = (Z a , Z a ) or (Zi , Zj ) = (Z b , Z b ). In all these cases, we a b = ∅. For instance, for = Sij can easily verify that Φbij = Φaij = ∅ as well as Sij b a a b (Z , Z ), before migration ∄v ∈ Z which implies Φij = ∅. After migration, ∄v ∈ Z b thus Φaij = ∅. In all these sub-cases, Fij ∉ Fvu0 .

Appendix F. Proof of Proposition 5 Assume J⟨Φij , Sij ⟩KK = (α, β) and J⟨Φij/v0 , Sij/v0 ⟩KK = (αv0 , βv0 ). We use the theorem that A = B iff A ⊆ B and B ⊆ A to prove all equations. – Proof of J⟨Φij , Sij ⟩↓¬p KK ∼ J⟨Φij , Sij ⟩KK ∖ J⟨Φij/v0 , Sij/v0 ⟩KK We have J⟨Φij , Sij ⟩↓¬p KK = (α ∩ J¬pKK , β ∩ J¬pKK ) (Semantics of ↓) and J⟨Φij , Sij ⟩KK ∖ J⟨Φij/v0 , Sij/v0 ⟩KK = (α ∖ αv0 , β ∖ βv0 ).

– Case J⟨Φij , Sij ⟩↓¬p KK ⊆ J⟨Φij , Sij ⟩KK ∖ J⟨Φij/v0 , Sij/v0 ⟩KK . We need to prove that α ∩ J¬pKK ⊆ α ∖ αv0 and β ∩ J¬pKK ⊆ β ∖ βv0 Case α ∩ J¬pKK ⊆ α ∖ αv0 . Proof by contradiction. Assume ∃x ∈ α ∩ J¬pKK but x ∉ α ∖ αv0 (Assumption 1) x ∈ α ∩ J¬pKK Ô⇒ x ∈ α and x ∈ J¬pKK (Assumption 2) Ô⇒ x is not destined to v0 but it is accepted by α x ∉ α ∖ αv0 Ô⇒ x ∉ α ∩ αvc0 since x ∈ α (Assumption 2), then x ∉ αvc0 Ô⇒ x ∈ αv0 Ô⇒ (x is accepted and it is destined to v0 ) Ô⇒ x ∈ JpKK Contradiction with (Assumption 1) x ∈ J¬pKK . Thus α ∩ J¬pKK ⊆ α ∖ αv0 holds. Case β ∩ J¬pKK ⊆ β ∖ βv0 .Proof by contradiction. Assume ∃x ∈ β ∩ J¬pKK but x ∉ β ∖ βv0 (Assumption 1) x ∈ β ∩ J¬pKK Ô⇒ x ∈ β and x ∈ J¬pKK Ô⇒ x is not destined to v0 and it is denied by β. However, βv0 is by definition the set of packets destined to v0 and denied by policy of v0 Ô⇒ x ∈ β ∖ βv0 . However, this contradicts the assumption that x ∉ β ∖ βv0 . Thus, β ∩ J¬pKK ⊆ β ∖ βv0 holds. We conclude for this case that J⟨Φij , Sij ⟩↓¬p KK ⊆ J⟨Φij , Sij ⟩KK ∖ J⟨Φij/v0 , Sij/v0 ⟩KK . – Case J⟨Φij , Sij ⟩↓¬p KK ⊇ J⟨Φij , Sij ⟩KK ∖ J⟨Φij/v0 , Sij/v0 ⟩KK . We need to prove that α ∩ J¬pKK ⊇ α ∖ αv0 and β ∩ J¬pKK ⊇ β ∖ βv0 . Case α ∩ J¬pKK ⊇ α ∖ αv0 . Proof by contradiction. Assume ∃x ∈ α ∖ αv0 but x ∉ α ∩ J¬pKK (Assumption 1) x ∈ α ∖ αv0 Ô⇒ x ∈ α and x ∉ αv0 (Assumption 2) x ∉ αv0 Ô⇒ either x ∈ βv0 (x is destined to v0 but it is denied) or {x} ∩ JpKK = ∅ (x is not destined to v0 ) (1) If x ∈ βv0 as βv0 ⊆ β Ô⇒ x ∈ β Ô⇒ impossible since x ∈ α and α ∩ β = ∅ (consistency requirement). (2) If {x} ∩ JpKK = ∅ Ô⇒ {x} ∩ J¬pKK ≠ ∅ Ô⇒ x ∈ J¬pKK We have x ∈ J¬pKK and from (Assumption 2) x ∈ α Ô⇒ Contradiction with (Assumption 1) x ∉ α ∩ J¬pKK . Thus, α ∩ J¬pKK ⊇ α ∖ αv0 holds. Case β ∩ J¬pKK ⊇ β ∖ βv0 . Proof by contradiction. Assume ∃x ∈ β ∖ βv0 but x ∉ β ∩ J¬pKK (Assumption 1) x ∈ β ∖ βv0 Ô⇒ x ∈ β and x ∉ βv0 (Assumption 2) x ∉ βv0 Ô⇒ either x ∈ αv0 (x is destined to v0 but it is accepted)

or {x} ∩ JpKK = ∅ (x is not destined to v0 ) (1) If x ∈ αv0 as αv0 ⊆ α Ô⇒ x ∈ α Ô⇒ impossible since x ∈ β and α ∩ β = ∅ (consistency requirement). (2) If {x} ∩ JpKK = ∅ Ô⇒ {x} ∩ J¬pKK ≠ ∅ Ô⇒ x ∈ J¬pKK We have x ∈ β (from Assumption 2) and x ∈ J¬pKK Ô⇒ Contradiction with (Assumption 1) x ∉ β ∩ J¬pKK . Thus, β ∩ J¬pKK ⊇ β ∖ βv0 holds. We conclude for this case that J⟨Φij , Sij ⟩↓¬p KK ⊇ J⟨Φij , Sij ⟩KK ∖ J⟨Φij/v0 , Sij/v0 ⟩KK . Thus, we conclude that J⟨Φij , Sij ⟩↓¬p KK = J⟨Φij , Sij ⟩KK ∖ J⟨Φij/v0 , Sij/v0 ⟩KK . – Proof of J⟨Φij , Sij ⟩↓p KK ∼ J⟨Φij/v0 , Sij/v0 ⟩KK We have J⟨Φij , Sij ⟩↓p KK = (α ∩ JpKK , β ∩ JpKK ) (Semantics of ↓). – Case J⟨Φij , Sij ⟩↓p KK ⊆ J⟨Φij/v0 , Sij/v0 ⟩KK Case α ∩ JpKK ⊆ αv0 . Assume ∃x ∈ α ∩ JpKK (Assumption 1) x ∈ α ∩ JpKK Ô⇒ x ∈ α andx ∈ JpKK Ô⇒ x is accepted along the path (Zi , Zj ) and it is destined to v0 . However, by definition of αv0 , we should have x ∈ αv0 . Thus α ∩ JpKK ⊆ αv0 holds. Case β ∩ JpKK ⊆ βv0 . Assume ∃x ∈ β ∩ JpKK (Assumption 1) x ∈ β ∩ JpKK Ô⇒ x ∈ β andx ∈ JpKK Ô⇒ x is denied along the path (Zi , Zj ) and it is destined to v0 . However, by definition of βv0 , we should have x ∈ βv0 . Thus β ∩ JpKK ⊆ βv0 holds. We conclude for this case that J⟨Φij , Sij ⟩↓p KK ⊆ J⟨Φij/v0 , Sij/v0 ⟩KK – Case J⟨Φij , Sij ⟩↓p KK ⊇ J⟨Φij/v0 , Sij/v0 ⟩KK Case α ∩ JpKK ⊇ αv0 . Assume ∃x ∈ αv0 (Assumption 1) and x ∉ α ∩ JpKK (Assumption 2) x ∈ αv0 Ô⇒ x is accepted by the policy of v0 along the path (Zi , Zj ) and it is destined to v0 . Since x is destined to v0 , we should have x ∈ JpKK . x ∉ α∩JpKK and x ∈ JpKK Ô⇒ x ∉ α (Assumption 3). However, x is accepted along the path (Zi , Zj ) and v0 ∈ {Zi , Zj }. Thus we should have x ∈ α Ô⇒ contradiction with (Assumption 3). Therefore, α∩JpKK ⊇ αv0 holds. Case β ∩ JpKK ⊇ βv0 . Assume ∃x ∈ βv0 (Assumption 1) and x ∉ β ∩ JpKK (Assumption 2) x ∈ βv0 Ô⇒ x is denied by the policy of v0 along the path (Zi , Zj )

and it is destined to v0 . Since x is destined to v0 , we should have x ∈ JpKK . x ∉ β ∩JpKK and x ∈ JpKK Ô⇒ x ∉ β (Assumption 3). However, x is denied along the path (Zi , Zj ) and v0 ∈ {Zi , Zj }. Thus we should have x ∈ β Ô⇒ contradiction with (Assumption 3). Therefore, β ∩JpKK ⊇ βv0 holds. We conclude for this case that J⟨Φij , Sij ⟩↓p KK ⊇ J⟨Φij/v0 , Sij/v0 ⟩KK Thus, we conclude that J⟨Φij , Sij ⟩↓p KK = J⟨Φij/v0 , Sij/v0 ⟩KK – Proof of J⟨Φij , Sij ⟩KK = J⟨Φij , Sij ⟩↓¬p KK ∪J⟨Φij , Sij ⟩↓p KK . The proof is straightforward from Eq 4 and Eq 5.

Appendix G. Proof of Theorem 1 Proof of Soundness (⊆) b – Case 1: Fij ∉ F u . Our hypothesis is that JFijb KK ⊆ J⟨Φbij , Sij KK ⟩. First, a b a b a we have Φij = Φij and Sij = Sij (Proposition 4) and JFij KK = JFijb KK a (equation (7)). This implies JFija KK ⊆ J⟨Φaij , Sij KK ⟩.

– Case 2: Fij , Fkl ∈ F u such that Fkl = mig(Fij ) b ⟩KK JFijb KK ⊆J⟨Φbij , Sij b b JFij↓¬p KK ⊆J⟨Φbij , Sij ⟩↓¬p KK

(hypothesis) (prop6)

b ⊆J⟨Φbij , Sij ⟩KK

b ⟩KK ∖ J⟨Φbij/v0 , Sij/v 0 b b b ⟩KK ∖ Sij/v JFij↓¬p KK ⊆J⟨Φbij ∖ Φbij/v0 , Sij 0

(Eq4)

b a JFij↓¬p KK ⊆J⟨Φaij , Sij ⟩KK

(Eq1)

b JFij↓¬p KK

JFija KK

a ⊆J⟨Φaij , Sij ⟩KK

(Eq8)

Thus, we conclude on soundness of Fij . a a a KK KK ∪ JFkl↓¬p JFkl KK = JFkl↓p

= =

a JFkl↓p KK b JFij↓p KK

b ∪ JFkl↓¬p KK b ∪ JFkl↓¬p KK

b b ⊆ J⟨Φbij , Sij ⟩↓p KK ∪ J⟨Φbkl , Skl ⟩↓negp KK

(P rop3) (Eq9) (Eq10)

b (Fijb and Fkl soundness and prop 6) b b ⟩↓¬p KK ⟩KK ∪ J⟨Φbkl , Skl ⊆ J⟨Φbij/v0 , Sij/v 0

(Eq5)

b b b ⟩KK ⟩KK ∪ J⟨Φbkl , Skl ⟩KK ∖ J⟨Φbkl/v0 , Skl/v ⊆ J⟨Φbij/v0 , Sij/v 0 0

(Eq4)

b b ⊆ J⟨Φbij/v0 , Sij/v ⟩KK ∖ ∅ ⟩KK ∪ J⟨Φbkl , Skl 0

v0 ∉ {Zk , Zl } before migration b b ∪ Skl ⟩KK ⊆ J⟨Φbij/v0 ∪ Φbkl , Sij/v 0 a ⟩KK ⊆ J⟨Φakl , Skl

(Eq2)

Thus, we conclude on soundness of Fkl Proof of Completeness (⊇). As we are using equations the same steps of the soundeness proof can be made for completeness by using ⊇ instead of ⊆. b KK ⟩. We – Case 1: Fij ∉ F u . Our hypothesis is that JFijb KK ⊇ J⟨Φbij , Sij a b a b a have Φij = Φij and Sij = Sij (Proposition 4) and JFij KK = JFijb KK a KK ⟩. (equation (7)). This implies JFija KK ⊇ J⟨Φaij , Sij

– Case 2: Fij , Fkl ∈ F u such that Fkl = mig(Fij ) b JFijb KK ⊇J⟨Φbij , Sij ⟩KK b b JFij↓¬p KK ⊇J⟨Φbij , Sij ⟩↓¬p KK

(hypothesis) (prop6)

b ⟩KK ⊇J⟨Φbij , Sij

b ⟩KK ∖ J⟨Φbij/v0 , Sij/v 0 b b b ⟩KK ∖ Sij/v JFij↓¬p KK ⊇J⟨Φbij ∖ Φbij/v0 , Sij 0

(Eq4)

b a JFij↓¬p KK ⊇J⟨Φaij , Sij ⟩KK

(Eq1)

a ⟩KK ⊇J⟨Φaij , Sij

(Eq8)

b KK JFij↓¬p

JFija KK

Thus, we conclude on completeness of Fij . a a a JFkl KK = JFkl↓p KK ∪ JFkl↓¬p KK

(P rop3)

b ∪ JFkl↓¬p KK b ∪ JFkl↓¬p KK

(Eq9)

= =

a KK JFkl↓p b JFij↓p KK

b b ⟩↓negp KK ⟩↓p KK ∪ J⟨Φbkl , Skl ⊇ J⟨Φbij , Sij

(Eq10)

b (Fijb and Fkl completeness and prop 6) b b ⟩↓¬p KK ⟩KK ∪ J⟨Φbkl , Skl ⊇ J⟨Φbij/v0 , Sij/v 0

(Eq5)

b b b ⟩KK ⟩KK ∪ J⟨Φbkl , Skl ⟩KK ∖ J⟨Φbkl/v0 , Skl/v ⊇ J⟨Φbij/v0 , Sij/v 0 0

(Eq4)

b b ⊇ J⟨Φbij/v0 , Sij/v ⟩KK ∖ ∅ ⟩KK ∪ J⟨Φbkl , Skl 0

v0 ∉ {Zk , Zl } before migration b b ∪ Skl ⟩KK ⊇ J⟨Φbij/v0 ∪ Φbkl , Sij/v 0 a ⟩KK ⊇ J⟨Φakl , Skl

(Eq2)

Thus, we conclude on completeness of Fkl

References [1] D. A. Schmidt, Denotational Semantics: A Methodology for Language Development, 1997. [2] N. Tamura, M. Banbara, Sugar: A CSP to SAT Translator Based on Order Encoding, in: the Proc.of the 2nd Internat. CSP Solver Competition, 2008, pp. 65–69. [3] E. Al-Shaer, H. Hamed, R. Boutaba, M. Hasan, Conflict classification and analysis of distributed firewall policies, Selected Areas in Communications, IEEE Journal on 23 (10) (2005) 2069 – 2084. [4] A. X. Liu, M. G. Gouda, Complete redundancy detection in firewalls, in: In Proc. of 19th Annual IFIP Conf. on Data and Applications Security, LNCS 3654, Springer-Verlag, 2005, pp. 196–209. [5] R. Chaure, An Implementation of Anomaly Detection Mechanism For Centralized and Distributed Firewalls, International Journal of Computer Applications 7 (4) (2010) 5 – 8. [6] S. Thanasegaran, Y. Yin, Y. Tateiwa, Y. Katayama, N. Takahashi, A Topology-Based Conflict Detection System for Firewall Policies using Bit-Vector-Based Spatial Calculus, IJCNS 4 (11) (2011) 683–695. [7] J. Garcia-Alfaro, F. Cuppens, N. Cuppens-Boulahia, S. Preda, Mirage: a management tool for the analysis and deployment of network security policies, in: Data Privacy Management and Autonomous Spontaneous Security, Springer, 2011, pp. 203–215.

[8] M. Gouda, A. Liu, A Model of Stateful Firewalls and its Properties, in: the Proc. of Internat. Conf. on Dependable Systems and Networks (DSN’05), 2005, pp. 128 – 137. [9] F. Cuppens, N. Cuppens-Boulahia, J. Garcia-Alfaro, T. Moataz, X. Rimasson, Handling Stateful Firewall Anomalies, in: Information Security and Privacy Research, Vol. 376, Springer Berlin Heidelberg, 2012, pp. 174–186. [10] A. D. Brucker, L. Br¨ ugger, P. Kearney, B. Wolff, Verified Firewall Policy Transformations for Test Case Generation, in: Proceedings of the 3rd Internat. Conf. on Software Testing, Verification and Validation, IEEE Computer Society, Washington, DC, USA, 2010, pp. 345–354. [11] A. A. Hassan, L. Hudec, Management and Verification of Firewall an Router Access Lists, Computing and Informatics 23 (1) (2004) 77–100. [12] S. T. Amjad Gawanmeh, Modeling and Verification of Firewall Configurations Using Domain Restriction Method, in: 6th International Conference on Internet Technology and Secured Transactions, 2011. [13] H. Acharya, M. Gouda, Firewall Verification and Redundancy Checking are Equivalent, in: IEEE INFOCOM, 2011, pp. 2123 –2128. [14] N. Ben Youssef, A. Bouhoula, Automatic Conformance Verification of Distributed Firewalls to Security Requirements, in: Social Computing, 2010 IEEE Second International Conference on, 2010, pp. 834 –841. [15] Y. Yin, J. Xu, N. Takahashi, Verifying Consistency Between Security Policy and Firewall Policy by Using a Constraint Satisfaction Problem Server, in: Future Computing, Communication, Control and Management, Vol. 144 of LNCS, Springer Berlin Heidelberg, 2012, pp. 135–145. [16] Y. Jarraya, A. Eghtesadi, M. Debbabi, Y. Zhang, M. Pourzandi, Formal Verification of Security Preservation for Migrating Virtual Machines in the Cloud, in: SSS’15, Vol. 7596 of LNCS, Springer, 2012, pp. 111–125. [17] E. Al-Shaer, W. Marrero, A. El-Atawy, K. ElBadawi, Network Configuration in a Box: Towards End-to-End Verification of Network Reachability and Security, in: 17th IEEE Internat. Conf. on Network Protocols, ICNP 2009., 2009, pp. 123 –132.

[18] M. Gouda, A. Liu, M. Jafry, Verification of Distributed Firewalls, in: Global Telecommunications Conference, 2008. IEEE GLOBECOM 2008. IEEE, 2008, pp. 1 –5. [19] M. Mejri, K. Adi, H. Fujita, Formal specification and analysis of firewalls, in: Proc. of the Conf. on New Trends in Software Methodologies, Tools and Techniques, Amsterdam, Netherlands, 2009. [20] N. B. Youssef, A. Bouhoula, Dealing with Stateful Firewall Checking, in: Digital information and communication technology and its applications, Springer, 2011, pp. 493–507. [21] Y. Jarraya, A. Eghtesadi, M. Debbabi, Y. Zhang, M. Pourzandi, Cloud calculus: Security verification in elastic cloud computing platform, in: IEEE CTS, IEEE, 2012, pp. 447– 454. [22] J. Petke, P. Jeavons, The order encoding: from tractable csp to tractable sat, in: Theory and Applications of Satisfiability Testing-SAT 2011, Springer, 2011, pp. 371–372.

Authors’ Biographies Yosr Jarraya Dr. Yosr Jarraya is currently a Postdoctoral Researcher at Ericsson Security Research, Montreal, Canada. She previously worked as a Research Associate at the Concordia Institute for Information Systems Engineering at Concordia University, Montreal. She is an active member of the Computer Security Laboratory (CSL). She was previously a Postdoctoral Fellow and a Research Assistant at Concordia University. She holds a Ph.D. in Electrical and Computer Engineering from Concordia University, Montreal and a M.Sc. ´ in Telecommunications from Ecole Sup´erieure des Communications de Tunis (Sup’Com), Tunisia. She published 1 book and more than 20 research papers in journals and conferences. Her research interests include cloud computing, software-defined networking, network security, cyber security, verification and validation, and software and systems engineering.

Arash Eghtesadi Arash Eghtesadi has a M.Sc. degree since 2013 in Information Systems Security at Concordia University, Montreal, Quebec, Canada. He worked as a research assistant in Computer Security Laboratory at Concordia Institute for Information Systems Engineering. Prior to that, he received M.Sc. in Computer Engineering from Amirkabir University of Technology, Tehran, Iran in 2008. Since August 2012, he is a lifetime member of Golden Key International Honour Society. His research interests include formal methods in security, security in cloud computing, and network security. Sahba Sadri Sahba Sadri has a M.Sc. degree since 2014 in Information Systems Security at Concordia Institute for Information Systems Engineering in Concordia University, Montreal, Qc, Canada. He is currently working on cloud computing management systems and their integration with Software Defined Networks (SDN). His research interests include cloud computing, firewalls and SDN security. Mourad Debbabi Dr. Mourad Debbabi is a Full Professor at the Concordia Institute for Information Systems Engineering. He holds the Concordia Research Chair Tier I in Information Systems Security. He is also the President of the National Cyber Forensics Training Alliance, Canada. He is the founder and one of the leaders of the Computer Security Laboratory at Concordia University. In the past, he served as Senior Scientist at the Panasonic Information and Network Technologies Laboratory, Princeton, New Jersey, USA; Associate Professor at the Computer Science Department of Laval University, Quebec, Canada; Senior Scientist at General Electric Research Center, New York, USA; Research Associate at the Computer Science Department of Stanford University, California, USA; and Permanent Researcher at the Bull Corporate Research Center, Paris, France. Dr. Debbabi holds Ph.D. and M.Sc. degrees in computer science from Paris-XI Orsay, University, France. He published more than 200 research papers in journals and conferences on computer security, cyber forensics, formal semantics, Java security and acceleration, cryptographic protocols, malicious code detection, programming languages, type theory and specification and verification of safety-critical systems.

Makan Pourzandi Dr. Makan Pourzandi is a Researcher at Ericsson, Canada. He received his Ph.D. degree in Computer Science from University of Lyon, France and ´ his M.Sc. Degree in Computer Science from Ecole Normale Sup´erieure de Lyon, France. His current research interests include security, cloud computing, software security engineering, cluster computing, and component-based methods for secure software development.