Cloud Calculus: Security Verification in Elastic Cloud Computing ...

Cloud Calculus: Security Verification in Elastic Cloud Computing Platform Y. Jarraya, A. Eghtesadi, and M. Debbabi Computer Security Laboratory, CIISE, Concordia University, Montreal, Quebec, Canada, Email:{y_jarray,a_eghte,debbabi}@encs.concordia.ca

Abstract—Cloud orchestration involves cloud resources scaling up and down, management, as well as manipulation to better respond user’s requests and to facilitate operational objectives of the service providers. These promote the elastic nature of cloud platform but force upon significant challenges to cloud service providers. Particularly, security issues such as inconsistency may arise while dynamic changes such as virtual machine migration occur. In this paper, we propose a formal framework for the specification of virtual machines migration and security policies updates. This framework enables us to verify that the global security policy after the migration is consistently preserved with respect to the initial one. To this end, we define a new calculus, namely cloud calculus that can be used to specify the topology of a cloud computing system and firewall security rules. It also enables specifying the virtual machines migration along with their security policies. The semantics of our calculus is based on structural congruence and a reduction relation. In order to verify the global security policy within the new configuration, we define a testing equivalence over cloud terms. Finally, we provide an illustrative case study to demonstrate the applicability of our approach. Keywords-Cloud Computing; Security Policies; Virtual Machine Migration; Verification; Cloud Calculus;Testing Equivalence;

I. I NTRODUCTION Cloud computing is increasingly gaining ground among a variety of users including enterprises, service providers, as well as governmental and educational entities. Cloud computing platform allows hosting of multiple services on a globally shared resource pool where resources are allocated to services on demand. Recent advances in the server virtualization technologies have improved flexibility and versatility of resource provisioning. A crucial technique that has recently emerged for data centers and cluster systems is the live migration of virtual machines (VMs) [1]. It basically allows virtual machines to migrate across distinct physical hosts without affecting the service-level agreements. This migration enables operators and administrators of the cloud to perform workload balancing and management, workload isolation, performance, and resource management as well as non-disruptive low-level system maintenance with no perceivable effect to the end user. However, the scale and elastic nature of the cloud platform enforce significant challenges

Y. Zhang† , and M. Pourzandi‡ Ericsson Research Sillicon Valley Lab, San Jose, CA, USA, Email: [email protected] Ericsson Canada Research, Montreal, Quebec, Canada, Email: [email protected] †

‡

in terms of security after virtual machine migration. More precisely, a variety of security policies (e.g. access control lists (ACL), firewalls, and IPS/IDS) are deployed in the data centers. Those polices are executed by rules configured or generated on network devices. When VM migrates, the consistency of these policies can be compromised because the destination network devices may not be able to enforce the same security policy for the incoming VM. Thus, VMrelevant policies need to migrate too in order to keep the running services secure. In this paper, we aim at providing a formal systematic mechanism to express and verify the VM deployment and migration process in the cloud from the security point of view. More precisely, we propose a framework that allows expressing the deployment and migration of VMs along with their related security policies and then verifying the preservation of the security after migration. This paper is the first initiative that employs a process algebraic approach for this matter. We cover in this first initiative packet filtering firewalls, however, we intend in the future to cover a security policy enforcement architecture that consists of different types of firewalls, including network layer and application layer firewalls, intrusion detection and prevention, as well as secure tunneling. The majority of existing research initiatives mainly focus on performance evaluation and cost and downtime analysis of virtual machines migration process. The contribution of this paper is twofold: (1) Definition of a process calculus, namely cloud calculus, that captures the dynamic topology of cloud computing systems and the global security policy of a given configuration (2) Elaboration of a concise approach that allows formally verifying the preservation of security policy after a live reconfiguration. The latter is based on a testing equivalence relation defined over cloud calculus terms. The rest of the paper is organized as follows. Section II provides an overview on the related work. Section III presents the cloud calculus syntax and semantics. Section IV is dedicated to present our approach for the verification that the global security policy in the new configuration is preserved with respect to the initial configuration. Section V comprises a case study showing the application of cloud calculus in order to orchestrate the mi-

gration of virtual machines and the related firewall security policy. Finally, a conclusion summarizing our contributions and foreseeable future work is presented in Section VI. II. R ELATED W ORK In this section, we review some relevant research initiatives that aim at addressing security issues in highly dynamic environments such as cloud computing, mobile networks, grid computing, and mobile agent systems. Henderson [2] introduces a modeling language called SJAN that inherits the concept of ambient to model secure distributed computation, including Grid Computing. The correctness of SJAN models are verified and certified using a Java-based tool, namely J-Ambient, and the ARC tool for further validation. Feng et al. [3] present a formal modeling for grid workflow systems based on concurrent transaction logic [4], which is an extension of the sequential transaction logic. Bleikertz et al. [5] address security-related challenges encountered in virtualized infrastructures such as zone isolation, secure migration, and absence of single point of failure. Others use ambients in modeling network and security, e.g. [6], [7], but none of them uses this concept in cloud computing. More precisely, they do not focus on dynamic reconfiguration of security enforcement mechanisms, proper to the cloud computing environment [8]. For instance, Franqueira et al. [6] use Mobile Ambients to perform security threat analysis in networks. Scott et al. [7] propose a framework for creating location-based security policies for mobile agents.These policies can be used to make both positive and negative assertions about the dynamic spatial location of agents, useful for location-aware Sentient applications. In cloud computing environment, Matthews et al. [9] propose virtual machine contracts for automating the communication and management of VM requirements including access to a particular network segment or storage system. The contracts are then expressed using an extended version of the Open Virtual Machine Format. Hajjat et al. [10] tackle the challenges in migrating enterprise services into hybrid cloud-based deployments. They address the complexity of enterprise applications, and then focus on transaction delays, wide-area communication, and cost resulted from migration. They also consider the ACL migration and the reachability policies and provide and algorithm for ACL migration. However they do not provide any formal proof for the security policy preservation. III. C LOUD C ALCULUS In this section, we define the cloud calculus. It is a process calculus that aims at specifying cloud topology and expressing virtual machines migration within the same as well as across data centers along with their corresponding security policies. The cloud calculus is built upon a subset of the Mobile Ambients (MA) [11] and the Non-interfering Boxed

Ambients [12], and extends them with new constructs. These constructs allows expressing specific sort of ambients, such as security ambient and packet ambient, in addition to security policies at specific locations in the network, the selection of those policies that need to be migrated with their corresponding VMs, and the update of the destination location with the new policies. The choice of the ambient concept as a foundation for the cloud calculus is justified as it was successfully used by other researchers to represent a network as a graph of nested nodes. Ambients allow representing any type of resources including firewalls, switches, routers, gateways, physical hosts, and VM. Particularly, MA calculus is based on the concepts of hierarchy and grouping, which allow to fully represent the topology of a network. Furthermore, ambients have capabilities of moving around and communicating with other ambients. A. Syntax Terms T

∶ ∶= ∣ ∣ ∣ ∣

M A G x Ð → f(T )

capability ambient rules variable function application

Locations ∶ ∶= η ∣ ∣

A ↭

child parent local

Processes ∶ ∶= P, Q ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣

0 (νn)P P |Q !P M.P A[P ] h ▷ A[P ] G ∶∶ A[P ] (x)η .P ⟨T ⟩η .P

inactivity restriction composition replication capability ambient packet ambient security ambient input output

Capabilities M, N ∶ ∶= ∣ ∣ ∣ ∣ ∣ ∣

 x in A out A M.N ↓ (x, A, A′ ) ↑ (G)

empty path variable enter A exit A path export rules import rules

Ambients Names ∶ ∶= u A ∣ n Figure 1.

variable name

Syntax of the Cloud Calculus -Part1

The cloud calculus comprises six syntactic categories: terms T , processes P , capabilities M , firewall policies G,

Packet Header ∶ ∶= < prot, A, val, A, val > h Firewall Rules ∶ ∶= nop ∣ (c ↦ d).G G ∶ ∶= c ∶ ∶= Allow ∣ Deny d prot ∶ ∶= tcp ∣ udp ∣ icmp ∣ * ∶ ∶= ip [ .. ip] adr port ∶ ∶= val [ .. val] ∶ ∶= val.val.val.val ip ∶ ∶= num ∣ * val Figure 2.

Syntax of the Cloud Calculus -Part 2

ambient names A, and locations η. In the following, we briefly explain each construct. Ambient names can be a fixed name n or a variable u. Locations η are used to indicate where the communications take place: either locally within the same ambient, or across ambient boundaries (between a parent and a child). The location - means towards the parent, the location A means towards the subambient named A, and ↭ (generally omitted) means local communication. Terms enable us to specify the type of data that can be communicated between ambients. A term T can be a capability M , an ambient A, a security policy G, or a variable x. The syntax of cloud calculus is provided in Fig. 1 and Fig. 2. In the following we detail the constructs related to processes, capabilities, and security policies. A process can be defined using the following constructors: ● ●

●

●

●

●

●

●

●

0: represents the inactive process, that does nothing. (νn)P : denotes the restriction operator that creates a new (unique) name n within the scope P . It can be used to name ambients and operate on ambients by names. P | Q: denotes the parallel composition of two processes P and Q. !P : represents the unbounded replication of the process P that allows defining iteration and recursion. G ∶∶ A[P ]: denotes an (security) ambient named A containing a running process P and protected by a security policy defined in G. h▷A[P ]: is the packet ambient named A that possesses a header h and contains a running process P . The entity h denotes a five tuple consisting of the protocol, the source ambient, the source port, the destination ambient, and the destination port. M.P : is the process that executes a capability M , and then continues as P . (x)η .P : is the anonymous polyadic input of values that is a binder of the the variable x with continuation P . η ⟨T ⟩ .P : is the anonymous polyadic output of T .

Capabilities are obtained from names or variables. They can be described as follows: ● ●

x: denotes a capability variable. in A: is the capability to enter into an ambient A,

out A: is the capability to exit an ambient A, M.N : is a composition of capabilities forming a path, ● : denotes the empty path, ′ ● ↓ (x, A, A ): allows exporting security policies of the enclosing ambient that specifically concerns the ambient A and bound it into the variable x. The ambient A′ represents the destination security ambient. ● ↑ (G): allows importing security policies G into the enclosing ambient. A security policy denoted by G represents a sequence of rules defining constrains on the mobility of ambients and on the communication between them. Security policies can be expressed as follows: ● nop: denotes the empty security policy. ● (c ↦ d).G denotes a sequence of access control rules. A given access control rule is defined by the tuple c and the decision d (either allow or deny). The tuple c is formed by the protocol prot, the source ambient represented by an IP value or a range adr, the source port represented by a port number value or a range port, the destination ambient adr, and the destination port port. Note that, in practice, the name of an ambient corresponds to an IP address. The free names and free variables, noted fn() and fv() respectively, have standard definitions and will not be detailed here due to lack of space. The notation P [T /x] denotes the free substitution defined only if T and x are of the same arity. A closed process contains no free variables. We also omit the inactivity 0 in process expression such as P ∣ 0 and M.0. ●

●

B. Operational Semantics The operational semantics is defined in terms of reduction and structural congruence. The structural congruence, noted ≡, is the least congruence that satisfies the laws in Fig. 3. Before presenting the cloud reduction rules, we present two auxiliary sub-reductions, namely →ev and →exp . The first is needed for the evaluation of the security policy G while having a packet ambient with a header h trying to move from a source to a destination. The second subreduction is needed for determining the rules to be exported to the new destination ambient given the name of the migrating ambient A and the destination ambient A′ . Given a sequence of firewall rules G, we define the auxiliary function ev that evaluates G in the sequential order. We define ⟦c⟧(h) as the evaluation of the tuple c of a specific rule (c ↦ d) against the values in the tuple h. The function ⟦c⟧(h) returns true if the header h matches c, f alse otherwise. Fig. 4 illustrates the reduction rules for →ev . Rule SEQ allows to evaluate the firewall rules in the sequential order. Rule MATCH is used when the currently evaluated firewall rule matches with h and has a decision d. Rule NEXT is used when the currently evaluated firewall rule doesn’t match with

MONOID

●

P ∣0 ≡ P P ∣Q ≡ Q∣P P ∣(Q∣R) ≡ (P ∣Q)∣R REPL

!P ≡ P |!P RES INACT

●

(νn)0 ≡ 0 RES RES

(νn)(νm)P ≡ (νm)(νn)P

n≠m

RES PAR

(νn)(P |Q) ≡ P |(νn)Q

n ∉ fn(P )

PATH ASSOC

(M.N ).P ≡ M.(N.P ) RES AMB

(νn)m[P ] ≡ m[(νn)P ]

n≠m

RES SEC AMB

(νn)G ∶∶ m[P ] ≡ G ∶∶ m[(νn)P ]

n≠m

RES PCKT AMB

(νn)h ▷ m[P ] ≡ h ▷ m[(νn)P ]

n≠m

●

SEC AMB

nop ∶∶ n[P ] ≡ n[P ] Figure 3.

Structural Congruence

h. Finally, rule NONE is used when we reach the end of the firewall rules sequence with no match. We denote by ⇓ev the reduction to normal form of the expression h ⊩ ev(G). In order to select the firewall rules corresponding to a migrating ambient A, we define an auxiliary function exp that parses each firewall rule and decides either to completely move (Rule MOVE) the rule, to copy (Rule COPY) the rule, or to do nothing (Rule NEXT). Rule SEQ and LAST are used to parse the security rules in sequential order and to evaluate the last firewall rule, respectively. Note that copying a firewall rule is needed when the rule concerns more than one VM such that c integrates c′ and c′′ , written c = c′ + c′′ . We define a set of five projection functions, denoted by πi5 , that takes a tuple c and returns the ith element of the tuple. The function Sub(n,n’) returns true if n is a sub-ambient of n′ and f alse otherwise. Fig. 5 provides the reduction rules for →exp . We denote by ⇓exp the reduction to normal form of the expression A′ , A ⊩ jexp(G), nopo, where A is the migrating ambient and A′ is the destination firewall. The normal form is of the form jG, G′ o, where G′ is the rules to be migrated and G is the rules that remain within the enclosing ambient. The cloud calculus reduction relation uses the two aforementioned sub-reductions and it is defined by the rules for mobility, communication, firewall rules manipulation, and structural rules given in Fig. 6. Therein, contexts are processes with one hole defined as follows:

●

●

●

●

●

●

Rule (ENTER) allows a (non-packet) ambient n containing the process in m.P to enter a sibling ambient m. If no sibling m exists, the operation blocks until a time when such a sibling exists. If more than one m sibling exists, any one of them can be chosen. Rules (ENTER ALLOW) and (ENTER DENY) are used with a packet ambient p containing a process in m.P that is willing to enter m, a sibling security ambient containing the firewall rules Gm . The first rule applies if there is a firewall rule with decision allow that matches with h, which results in the packet p entering the ambient m. The second rule applies if there is either a matching security rule with decision deny or no matching rule at all, which results in dropping the packet ambient p. Rule (EXIT) is used to allow a (non-packet) ambient n containing the process out m.P to exit a parent ambient m. If the parent ambient is not named m, the operation blocks until such a condition holds. Rule (EXIT ALLOW) and (EXIT DENY) are used with a packet ambient p containing a process out m.P that is willing to exiting m, a parent security ambient containing the firewall rules Gm . The first rule applies if there is a firewall rule with decision allow that matches with h, which results in the packet p exiting the ambient m. The second rule applies if there is either a matching security rule with decision deny or no matching rule at all, which results in dropping the packet ambient p. Rule (LOCAL) allows a local communication between a local input of x and a local output T within the same ambient to take place. This results in the substitution of all occurrences of variable x in P with the value T . Rule (INPUT n) allows a communication between a parent and its child by an output of T from a child ambient n and an input of x from its parent ambient. Rule (OUTPUT n) allows a communication between a parent and its child by an output of T from a parent ambient and an input of x from its child ambient n. Rule (IMPORT) defines an import operation (dual of export) of a sequence of firewall rules G′ to a security ambient n. We define an auxiliary function Merge that allows to merge two sequences of firewall rules such that G′n =Merge(Gn , G′ ) represents the new firewall rules sequence of n. Rule (EXPORT) defines an export operation of a sequence of firewall rules G′ that are related to a migrating virtual machine m and having as destination a security ambient m′ . This results in the substitution of all occurrences of variable x in P with the value G′ .

C[⋅] ∶ ∶= [⋅] ∣ P ∣C[⋅] ∣ (νn)C[⋅] ∣ G ∶∶ A[C[⋅]] ∣ h ▷ A[C[⋅]]

IV. S ECURITY P OLICY V ERIFICATION

The reduction relation is closed by structural congruence and context,where →∗ denotes the reflexive and transitive closure of →. In the following, we explain the reduction rules:

In this section, we introduce the notion of security policy preservation and describe our approach to verify it. Security policy preservation means that the security policy in the new

SEQ MOVE COPY

NEXT

LAST

A′ , A ⊩ jexp((c ↦ d).G), Go →exp jexp((c ↦ d)).G, Go A′ , A ⊩ jexp((c ↦ d)).G, Go →exp jexp(G), (c ↦ d).Go if (π2 (c) = A and Sub(π4 (c), A′ ) ) or (π4 (c) = A and Sub(π2 (c), A′ )) A′ , A ⊩ jexp((c ↦ d)).G, Go →exp j(c′′ ↦ d).exp(G), (c′ ↦ d).Go if [d = Allow and ( (π2 (c) = A and !Sub(π4 (c), A′ ) ) or (π4 (c) = A and !Sub(π2 (c), A′ ) ) or (A ⊂ π2 (c) ∪ π4 (c)))] where c′ + c′′ = c A′ , A ⊩ jexp((c ↦ d)).G, Go →exp j(c ↦ d).exp(G), Go if (A ⊈ π2 (c) and A ⊈ π4 (c)) or (d = Deny and (A ⊂ π2 (c) or A ⊂ π4 (c)) or (d = Deny and A = π2 (c) and !Sub(π4 (c), A′ ) ) or (d = Deny and A = π4 (c) and !Sub(π2 (c), A′ ) )) A′ , A ⊩ jG.exp(nop), Go →exp jG, Go Figure 5.

Mobility: (ENTER ) (ENTER ALLOW)

(ENTER DENY) (EXIT ) (EXIT ALLOW)

(EXIT DENY) Communication: (LOCAL ) (INPUT n) (OUTPUT n)

Reduction Rules for Firewall Rules Export

Gn ∶∶ n[in m.P ∣ Q] ∣ Gm ∶∶ m[R] → Gm ∶∶ m[Gn ∶∶ n[P ∣ Q] ∣ R] h ⊩ ev(Gm ) ⇓ev Allow h ▷ p[in m.P ] ∣ Gm ∶∶ m[Q] Ð→ Gm ∶∶ m[h ▷ p[P ] ∣ Q] h ⊩ ev(Gm ) ⇓ev Deny h ▷ p[in m.P ] ∣ Gm ∶∶ m[Q] Ð→ Gm ∶∶ m[Q] Gn ∶∶ n[Gm ∶∶ m[out n.P ∣ Q] ∣ R] → Gm ∶∶ m[P ∣ Q] ∣ Gn ∶∶ n[R] h ⊩ ev(Gm ) ⇓ev Allow Gm ∶∶ m[h ▷ p[in m.P ] ∣∣ Q] Ð→ h ▷ p[in m.P ] ∣Gm ∶∶ m[Q] h ⊩ ev(Gm ) ⇓ev Deny Gm ∶∶ m[h ▷ p[in m.P ] ∣ Q] Ð→ Gm ∶∶ m[Q] (x).P | ⟨T ⟩ .Q → P {T /x} | Q (x)n .P | Gn ∶∶ n[⟨T ⟩- .Q ∣ R] → P {T /x} | Gn ∶∶ n[Q ∣ R] ⟨T ⟩n .P | Gn ∶∶ n[(x)- .Q ∣ R] → P | Gn ∶∶ n[Q{T /x} ∣ R]

Firewall Rules: (IMPORT)

(EXPORT )

G′n = Merge(Gn , G′ ) Gn ∶∶ n[↑ (G′ ).P ] → G′n ∶∶ n[P ] m′ , m ⊩ jexp(Gn ), Go ⇓exp jG′n , G′ o Gn ∶∶ n[↓ (x, m, m′ ).P ] → G′n ∶∶ n[P {G′ /x}]

Structural and Context: P ≡ P′ (STRUCT ) (CTX )

P ′ Ð→ Q′ Q′ ≡ Q P Ð→ Q P Ð→ Q ⇒ C[P ] Ð→ C[Q] Figure 6.

Cloud Calculus Reduction Rules

NONE

h ⊩ ev((c ↦ d).G) →ev ev((c ↦ d)).G h ⊩ ev((c ↦ d)).G →ev d if ⟦c⟧(h) = true h ⊩ ev((c ↦ d)).G →ev ev(G) if ⟦c⟧(h) = f alse h ⊩ ev(nop) →ev Deny

Figure 4.

Reduction Rules for Firewall Rules Evaluation

SEQ MATCH NEXT

configuration of the cloud after VM and security policies migration doesn’t break the security policy of the initial configuration before migration. In other words, we would

like to verify that every packet will be treated equally by both security policies in the initial and the new configurations, denoted by Ci and Cn , respectively. Thus, we propose to define an equivalence relation based on the may testing equivalence [13], which is used in Spi calculus to compare processes from the security point-of-view. In order to define a test, let h ▷ p[P ] be a packet ambient and s be an ambient that serves as a transporter of the packet towards the source virtual machine vsrc wherein the specific test is triggered by instructing p to move towards a destination virtual machine vdst . The process P within the

ambient p has the capability to receive mobility instructions from s that will be executed once the test is run. Meaning that P = (x)- .x. Thus, the ambient s is expressed as follows: p Rh = s[Mvsrc . ⟨out s.Mvdst ⟩ ∣h ▷ p[(x)- .x]] where h=, Mvsrc expresses the p capability to move s towards vsrc and ⟨out s.Mvdst ⟩ is the output action of a mobility path to p that consists in instructing p to exit s and then to move towards vdst . The test s is then run first in parallel with Ci then in parallel with Cn . In order to conclude that the security policy is preserved, both configurations should equivalently pass the test. More formally, the cloud capability grammar defined in Fig. 2 should be extended by adding a new syntactic capability construct denoted by Ω. The latter is a distinguished capability, reserved for the definition of tests only, that can perform only ω. We use ω at the end of the path capabilities of the packet so that, if the packet reaches his destination successfully, he performs ω, otherwise, we can conclude that it was filtered by a firewall along that path and will never be able to perform ω. In the following, we use the definitions in [13]. This is basically enough in the context of our framework as there is only a single interaction for each test on each configuration (no interference). Given a process P, the predicate P exhibits ω, written P ↓ ω, is defined by the axiom and the rules defined as follows: (A1) (R2) (R4)

Ω↓ω P ↓ω (νn)P ↓ ω P ↓ω h ▷ A[P ] ↓ ω

(R1) (R3) (R5)

P ↓ω P ∣Q ↓ ω P ↓ω G ∶∶ A[P ] ↓ ω P ≡Q Q↓ω P ↓ω

The convergence predicate P ⇓ ω is defined as: P ⇓ ω = ∃Q∣(P →∗ Q) ∧ (Q ↓ ω) A process P may pass a test Rh if and only if P ∣Rh ⇓ ω. The testing preorder ⊑ and the testing equivalence ≃ are defined as follows: P ⊑ Q = ∀Rh P ∣ Rh ⇓ ω Ô⇒ Q ∣ Rh ⇓ ω P ≃Q=P ⊑Q∧Q⊑P where P ≃ Q means that the tests that P and Q may pass are the same. In other words, P ≃ Q means that no test can distinguish between P and Q. In our case, security policy is preserved in Cn with respect to Ci , if Cn and Ci cannot be distinguished by any given test Rh . Thus, verifying security policy preservation consists in proving that Ci ≃ Cn . V. C ASE STUDY Network security in a cloud infrastructure has to be scalable, flexible, virtual and easy to manage. When changes happen to the current configuration of the cloud, the system is subject to misconfiguration in terms of security policies. The policy modification can be triggered by events like: VM migration, VM creation/removal, load changes in different nodes, or topology changes. To better illustrate cloud calculus, we present an example of a cloud network

Figure 7.

Example of a Three-tier Architecture Service in the Cloud Table I F IREWALL RULES BEFORE M IGRATION

FW1 1. 2. 3. 4. 5. 6. FW2 2. 3. 4. 5. 6. 7.

TCP TCP TCP TCP

*.*.*.* *.*.*.* VM1,VM3 CorpIP

ANY ANY ANY ANY

80 443 3306 22

Allow Allow Allow Allow

ANY ANY

VM5 VM5 VM2 VM1,VM3, VM5 VM1, VM3 *.*.*.*

TCP TCP

VM5,VM7 *.*.*.*

8000 ANY

Allow Deny

TCP TCP TCP TCP TCP TCP

*.*.*.* *.*.*.* VM1,VM3 CorpIP VM7 *.*.*.*

ANY ANY ANY ANY ANY ANY

VM7 VM7 VM2 VM2,VM7 VM1,VM3 *.*.*.*

80 443 3306 22 8000 ANY

Allow Allow Allow Allow Allow Deny

model consisting of two data centers depicted in Fig. 7. This example is inspired from Amazon Elastic Compute Cloud (Amazon EC2) [14]. The service is built using a three-tier architecture: Web tier, application tier, and database tier. The example illustrates the live migration of a VM from one cloud data center to another. The goal of this case study is to show how migration of the VM and the corresponding firewall security rules is handled using cloud calculus. We suppose that for the purpose of load balancing, VM7 has to migrate from the physical server PS4 in the data center 2 to the physical server PS2 in the data center 1. The initial firewalls rules (before migration) are provided in Table I. Note that we assume that the addresses of the customer’s corporate network is grouped under the label CorpIP. Before migration, we suppose that the security policy for VM7 are enforced at the source firewall FW2. These firewall rules need to migrate to the destination firewall FW1. Note that the rules at FW3 and FW4 are general and are not concerned by the migration process. The firewall rules, as they should be after migration, are given in Table II and they comply to the security policy specified by Amazon EC2 [14].

VM7 Migration m1 [ G1 ∶∶ l1 [ r1 [v1 [P1 ] ∣ v3 [P3 ] ] ∣ r2 [ v5 [P5 ] ] ] ] | m2 [ G2 ∶∶ l2 [r3 [ v2 [P2 ] ] ∣ r4 [ v7 [P7 ] ] ] ] → C1 | m2 [ G2 ∶∶ l2 [r3 [ v2 [P2 ] ] ∣ r4 [ ] ∣ v7 [out l2 .out m2 .in m1 .in l1 .in r2 ] ] ] → C1 | m2 [ G2 ∶∶ l2 [r3 [ v2 [P2 ] ] ∣ r4 [ ] ] ] ∣ v7 [in m1 .in l1 .in r2 ] → m1 [ G1 ∶∶ l1 [ r1 [v1 [P1 ] ∣ v3 [P3 ] ] ∣ r2 [ v5 [P5 ] ] ] ∣ v7 [in l1 .in r2 ]] | C2′ → m1 [ G1 ∶∶ l1 [ r1 [v1 [P1 ] ∣ v3 [P3 ] ] ∣ r2 [ v5 [P5 ] ∣ v7 [] ] ] ] | C2′ FW2 Rules Export l1 , v7 ⊩ jexp(G2 ), nopo = l1 , v7 ⊩ jexp((↦ Allow).G′2 ), nopo →exp exp((↦ Allow).G′′2 ), (↦ Allow).nopo ⋮ →exp jGsrc , Gmig o where Gmig = (↦ Allow).(↦ Allow). (↦ Allow).(↦ Allow).nop Firewall Rules Migration t Pl2 =↓ (xg , v7 , l1 ). ⟨xg ⟩ and Pl1 = (x)t .x and Pt = (xg )- .Mt . ⟨↑ (xg )⟩ Mt = out l2 .out m2 .in m1 .in l1 t m1 [ G1 ∶∶ l1 [ Pl1 ∣ Q1 ] ] | m2 [ G2 ∶∶ l2 [↓ (xg , v7 , l1 ). ⟨xg ⟩ ∣ (νt)t[Pt ] ∣ Q2 ] ] t →m1 [ G1 ∶∶ l1 [ Pl1 ∣ Q1 ] ] | m2 [ Gsrc ∶∶ l2 [⟨Gmig ⟩ ∣ (νt)t[(xg )- .Mt . ⟨↑ (xg )⟩ ] ∣ Q2 ] ] →m1 [ G1 ∶∶ l1 [ Pl1 ∣ Q1 ] ] | m2 [ Gsrc ∶∶ l2 [ (νt)t[Mt . ⟨↑ (Gmig )⟩ ] ∣ Q2 ] ] →m1 [ G1 ∶∶ l1 [ Pl1 ∣ Q1 ] ] | (νt)t[in m1 .in l1 . ⟨↑ (Gmig )⟩ ] | m2 [ Gsrc ∶∶ l2 [ Q2 ] ] →m1 [ G1 ∶∶ l1 [ (νt)t[⟨↑ (Gmig )⟩ ] ∣ (x)t .x ∣ Q1 ] ] | m2 [ Gsrc ∶∶ l2 [ Q2 ] ] →m1 [ G1 ∶∶ l1 [ (νt)t[0] ∣ ↑ (Gmig ) ∣ Q1 ] ] | m2 [ Gsrc ∶∶ l2 [ Q2 ] ] →m1 [ G′1 ∶∶ l1 [ Q1 ] ] | m2 [ Gsrc ∶∶ l2 [ Q2 ] ] where G′1 = merge(Gmig , G1 ) Figure 8.

EXIT r4 EXIT ∗ ENTER m1 ENTER∗

SEQ + MOVE LAST

EXPORT OUTPUT

t

EXIT ∗ ENTER∗ INPUT t IMPORT

VM and Firewall Rules Migration

Table II F IREWALL RULES A FTER M IGRATION

follows: P7 = out r4 .out l2 .out m2 .in m1 .in l1 .in r2

FW1 1. 2. 3. 4. 5. 6. FW2 2. 3. 4.

TCP TCP TCP TCP

*.*.*.* *.*.*.* VM1,VM3 CorpIP

ANY ANY ANY ANY

80 443 3306 22

Allow Allow Allow Allow

ANY ANY

VM5,VM7 VM5,VM7 VM2 VM1,VM3, VM5,VM7 VM1,VM3 *.*.*.*

TCP TCP

VM5, VM7 *.*.*.*

8000 ANY

Allow Deny

TCP TCP TCP

VM1,VM3 CorpIP *.*.*.*

ANY ANY ANY

VM2 VM2 *.*.*.*

3306 22 ANY

Allow Allow Deny

Let mi , li , and ri be the ambient names that refer respectively to GWi , SWi , and P Si . The virtual machines will be named vi . The cloud calculus terms for the initial configuration of the data center 1 and 2, denoted respectively by by C1 and C2 , are as follows: C1 = m1 [ G1 ∶∶ l1 [ r1 [v1 [P1 ] ∣ v3 [P3 ] ] ∣ r2 [ v5 [P5 ] ] ] ] C2 = m2 [ G2 ∶∶ l2 [r3 [ v2 [P2 ] ] ∣ r4 [ v7 [P7 ] ] ] ]

The whole cloud system is expressed by the parallel composition of these two terms, meaning C1 ∣ C2 . The migration of the virtual machine v7 is expressed as a capabilities path in the cloud calculus executed by a process, P7 , defined as

The actual migration is performed by applying the mobility reduction rules (ENTER) and (EXIT) and a subset of the structural congruence rules (MONOID and PATH ASSOC) to the term C1 ∣ C2 . This results in the migration of v7 , which becomes a sub-ambient of r2 . This is explained by the first group of reductions in Fig. 8. Note that C2′ = m2 [ G2 ∶∶ l2 [r3 [ v2 [P2 ] ] ∣ r4 [ ] ] ]. In order to migrate the security rules, we need to export from FW2 every rule that concerns v7 , without affecting the security of the other applications, and import them to FW1. The rules of FW2 are expressed as follows: G2 =(↦ Allow). ⋯ (↦ Allow).nop

The second group of reductions in Fig. 8 details exporting FW2 rules, where the entities Gsrc and Gmig denote the firewall rules remaining in FW2 and the firewall rules to be migrated to FW1, respectively. Rules are either copied (Rule copy) or completely deleted and moved (Rule move) to the destination firewall. This depends on two factors: the source or destination IP addresses and the location of the

communication (within the same or between different data centers). For instance, a rule with the only migrating VM IP at the destination address filed and the keyword “any” at the source address is completely deleted from the source firewall and moved to the destination firewall. The third and last group of reductions in Fig. 8 provides the actual migration of Gmig rules from FW2 to FW1. In the following, we use the following: Q1 = r1 [v1 [P1 ] ∣ v3 [P3 ] ] ∣ r2 [ v5 [P5 ] ∣ v7 [] ] and Q2 = r3 [ v2 [P2 ] ] ∣ r4 [ ]. The process Pl2 within the ambient l2 has two capability actions: triggers exporting the rules of v7 (rule (EXPORT)) and sends the values Gmig to a new ambient t (rule (OUTPUT t)). The latter ambient is charged to migrate the rules to l1 (rules (ENTER) and (EXIT)). The process Pt within the ambient t, will first receive the rules Gmig at the variable xg , then execute a mobility capability and finally after reaching l2 communicate the capability of importing rules Gmig to Pl1 . The firewall rules migration terminates when the process Pl1 located in l1 receives a capability x and execute it. Expressing the cloud data center with its security appliances in cloud calculus enables to systematically decide whether the firewall rules of the migrating VM, should be completely deleted from the source firewall and moved to destination or only copied to the destination firewall. This allows avoiding introducing errors into the firewall configuration. Furthermore, using the testing equivalence relation defined in Section IV and packets mobility reduction rules in Fig. 6, one can validate formally that the security is preserved after migration. VI. C ONCLUSION In this paper, we presented a formal framework for the specification of the migration of virtual machines and the related security policies in the cloud using a process algebraic approach. To the best of our knowledge, we are the first to propose this approach for this matter. Thus, we elaborated a novel calculus namely cloud calculus that can be used to capture cloud topology and express VM migration along with their corresponding firewall security rules. The semantics of the cloud calculus is based on structural congruence and a reduction relation. In order to verify that the global security policy is preserved after migration, we defined a testing equivalence over cloud terms. The expressiveness of cloud calculus allows us to specify the protocol for coordinating virtual machines migration along with their security policies. As future work, we plan to elaborate more on the verification and validation of security policies in the cloud taking into account not only packet filtering firewalls, but also web application firewall, intrusion detection and prevention, and secure tunneling. R EFERENCES [1] C. C. Keir, C. Clark, K. Fraser, S. H, J. G. Hansen, E. Jul, C. Limpach, I. Pratt, and A. Warfield, “Live Migration of Virtual Machines,” in the Proceedings of the 2nd ACM/USENIX

Symposium on Networked Systems Design and Implementation (NSDI), 2005, pp. 273–286. [2] Y.-J. Lee and P. Henderson, “A Practical Modelling Notation for Secure Distributed Computation,” in the Proceedings of the 19th Int. Conf. on Advanced Information Networking and Applications, (AINA), vol. 2, March 2005, pp. 439–442. [3] X. L. Zhilin Feng, Yanming Ye, “A Formal Modeling Method for Grid Workflow Based on Concurrent Transaction Logic,” in JCIT: Journal of Convergence Information Technology, vol. 6, no. 2, 2011, pp. 59–69. [4] A. J. Bonner and M. Kifer, “Concurrency and Communication in Transaction Logic,” in JICSLP’96, 1996, pp. 142–156. [5] S. Bleikertz, T. Groß, and S. Mödersheim, “Automated Verification of Virtualized Infrastructures,” in the Proceedings of the 3rd ACM workshop on Cloud Computing Security (CCSW), 2011, pp. 47–58. [6] V. Nunes Leal Franqueira, P. A. T. van Eck, R. J. Wieringa, and R. H. C. Lopes, “A Mobile Ambients-based Approach for Network Attack Modelling and Simulation,” in the Proceedings of the 4th Int. Workshop on Dependability Aspects on Data Warehousing and Mining applications, (DAWAM). Los Alamitos: IEEE Computer Society, March 2009, pp. 546–553. [7] D. Scott, A. Beresford, and A. Mycroft, “Spatial Security Policies for Mobile Agents in a Sentient Computing Environment,” in the Proceedings of the 6th International Conference on Fundamental Approaches to Software Engineering. Berlin, Heidelberg: Springer-Verlag, 2003, pp. 102–117. [8] I. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud computing and grid computing 360-degree compared,” in Grid Computing Environments Workshop, 2008. GCE ’08, Nov. 2008. [9] J. Matthews, T. Garfinkel, C. Hoff, and J. Wheeler, “Virtual machine contracts for datacenter and cloud computing environments,” in the Proceedings of the first Workshop on Automated Control for Datacenters and Clouds (ACDC). New York, NY, USA: ACM, 2009, pp. 25–30. [10] M. Hajjat, X. Sun, Y.-w. E. Sung, D. Maltz, and S. Rao, “Cloudward Bound : Planning for Beneficial Migration of Enterprise Applications to the Cloud,” in the Proceedings of the ACM SIGCOMM 2010. New York, NY, USA: ACM, 2010, pp. 243–254. [11] L. Cardelli and A. D. Gordon, “Mobile Ambients,” Theoretical Computer Science, vol. 240, no. 1, pp. 177 – 213, 2000. [12] M. Bugliesi, S. Crafa, M. Merro, and V. Sassone, “Communication and Mobility Control in Boxed Ambients,” Inf. Comput., vol. 202, no. 1, pp. 39–86, 2005. [13] L. Durante, R. Sisto, and A. Valenzano, “Automatic Testing Equivalence Verification of Spi Calculus Specifications,” ACM Trans. Softw. Eng. Methodol., vol. 12, pp. 222–284, April 2003. [14] Amazon.com, “Amazon web services: Overview of security processes,” http://awsmedia.s3.amazonaws.com/pdf/ AWS_Security_Whitepaper.pdf, May 2011.