Cloud Resources Placement based on

Functional and Non-functional Requirements

Asma Guesmi

, Patrice Clemente

, Fr

eric Loulergue

and Pascal Berthom

LIFO EA 4022, Universit

e d’Orl

eans, - B

atiment IIIA

Rue L

eonard de Vinci, B.P. 6759, F-45067 Orl

eans Cedex 2, France

LIFO EA 4022, INSA Centre-Val de Loire, 88 boulevard Lahitolle, CS 60013, 18022 Bourges cedex, France

Keywords:

Broker, Cloud computing, Security, Requirements.

Abstract:

It is difﬁcult for customers to select the adequate cloud providers which ﬁt their needs, as the number of cloud

offerings increases rapidly. Many works thus focus on the design of cloud brokers. Unfortunately, most of

them do not consider precise security requirements of customers. In this paper, we propose a methodology

deﬁned to place services in a multi-provider cloud environment, based on functional and non-functional re-

quirements, including security requirements. To eliminate inner conﬂicts within customers requirements, and

to match the cloud providers offers with these customers requirements, we use a formal analysis tool: Alloy.

The broker uses a matching algorithm to place the required services in the adequate cloud providers, in a way

that fulﬁlls all customer requirements. We ﬁnally present a prototype implementation of the proposed broker.

1 INTRODUCTION

With the rapid growth of cloud Computing, the cloud

customer now faces many choices to ﬁt her needs.

The user now wants to deploy distributed applications

on federations of clouds. Basically, those can be sets

of virtual machines on clusters of several providers.

Cloud brokers have thus appeared, designed to match

the user’s requirements against cloud providers of-

fers, in order to establish “Service Level Agreements”

between them. There exist however very few ap-

proaches aiming at providing conﬁgurable security,

allowing the customers to express precisely their se-

curity requirements. In this work, we propose a cloud

brokering process to deeply analyze the user’s model,

including abstract needs and requirements, i.e., func-

tional requirements (services, resources) and non-

functional ones (connections, security properties and

policies). We also propose to confront these require-

ments with the providers’ offers, in order to automati-

cally generate a deployment architecture for each cus-

tomer. This architecture responds to every functional

and non-functional requirement of the user. Our solu-

tion uses formal methods to analyze the security prop-

erties and to ensure that they are well described and

will be well implemented onto the Cloud. This avoids

malformed security policies. We also use formal ver-

iﬁcation tools to check the possibility of deploying

resources and ensuring the security requirements of

the customer before the deployment in the cloud. The

resulting generated deployment architecture is then

given back to the customer, who can accept it, or ask

for the next one, if possible.

The rest of the paper is organized as follows. Sec-

tion 2 describes the various steps of the brokering

process we propose, and details the speciﬁcation of

providers offers, customers models and requests, and

matching of both. Section 3 describes the current pro-

totype implementation. Section 4 compares our pro-

posal with related works. Section 5 presents perspec-

tives and concludes the paper.

2 METHODOLOGY

The general process consists of two big independent

steps. On one hand, cloud vendors describe their of-

fers and publish them. An offer contains templates of

resources such as Virtual Machines (VMs) and non-

functional offers such as security mechanisms. On the

other hand, the customer describes a system she wants

to have deployed in the cloud. In this paper we do not

detail the syntax of the speciﬁcation language. But we

can use extensions of the languages presented in ex-

isting works such as (Guesmi and Clemente, 2013) or

(Bleikertz and Groß, 2011). The system speciﬁcation

335

Guesmi A., Clemente P., Loulergue F. and Berthomé P..

Cloud Resources Placement based on Functional and Non-functional Requirements.

DOI: 10.5220/0005552503350342

In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT-2015), pages 335-342

ISBN: 978-989-758-117-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

deﬁned by the customer is sent to the cloud broker, as

a request. The requested system contains the descrip-

tion of resources (VMs for example) along with their

characteristics, location constraints and interconnec-

tion. It also describes security properties constraints.

This customer’s speciﬁcation will be referred as the

CIM (Customer Initial Model).

The novelty of our approach is that the CIM has to

be formally analyzed using veriﬁcation techniques. If

a property in the system is found not consistent, the

broker returns a counter example to the customer. The

latter must then modify her requirements in order to

be consistent, if possible. If the system requirements

are consistent, the broker tries to match them with

the vendors offers and ﬁnd a suitable resources place-

ment. This is described in Section 2.3. The broker has

to select the providers that can host the required re-

sources and fulﬁll the requirements. To achieve that,

the broker also uses veriﬁcation techniques to provide

some rigorous and formal cues to ensure that the auto-

matically generated placement is safe and sound. This

is described in Section 2.4.

2.1 Providers Offers

Each provider describes its offers to the broker. Of-

fers may include:

• A set of clusters: (possibly virtual) groups of

physical hosts (that host the virtual resources),

their geographic locations, and a set of VM tem-

plates: OS, CPU, storage and some basic security

assurance facilities (encryption, certiﬁcation).

• A set of physical and virtual networks, ab-

stracted as information ﬂows and guardians

that interconnect the clusters. Guardians are in-

trusion protection systems and ﬁltering systems,

such as network ﬁrewalls, integrity checkers, etc.

• A set of conﬂicts or other company related rela-

tions between clusters or providers: we call con-

ﬂicting clusters, those hosting data of different

critical domains. For example, a cluster hosting

DoD data is conﬂicting with any other kind of

cluster. The conﬂicting providers/clusters should

not participate in the same cloud federation.

In this paper, we do not analyze the providers of-

fers. We assume the existence of two types of third

party certiﬁcations: The QoS certiﬁcation (Rajendran

et al., 2010) and the CSA STAR certiﬁcation (Cloud

Security Alliance, 2011b).

2.2 Customer Requirements

The CIM includes the elements that we classify as the

following:

A. Functional requirements

Compute nodes (or VMs) and their characteristics

such as: the CPU power, the RAM size, the storage

size and the data transfer rate.

Storage nodes and the characteristics such as: the

storage size, the RAM size and the data transfer

rate.

B. Non-functional requirements, i.e. system con-

straints and security requirements:

(a) The security level of some nodes: some nodes

may be labelled with a given security level, e.g.

public, normal (or semi-public

), private (in-

cluding: secret, top secret, etc.). By default,

the security level is set to secret (private).

(b) High-level security relations/properties be-

tween nodes speciﬁed by the customer:

• Collaboration: the customer may need some

nodes to collaborate, i.e. to share information

and/or computing services, etc.

• Concurrency (or conﬂict): the customer may

need some nodes to work in concurrency, e.g.

the concurrency between all secret nodes.

• Access (read/write) privilege: For example,

the customer should express that some normal

or secret compute nodes must be able to send

information to secret storage nodes; and that

some secret compute nodes can read informa-

tion from some secret storage ones.

• Isolation: the customer may need some nodes

to be fully isolated from others, e.g. all

top secret nodes have to be isolated.

• Conﬁdentiality/Integrity: the conﬁdentiali-

ty/integrity of some nodes must be ensured.

These high-level relation constraints implicitly

include security properties and policies.

Grouping constraint: the customer may de-

sire to host some nodes on the same cluster or

provider, e.g, collaborating nodes (in order to

increase the bandwidth, security trust, etc).

Separation constraint: the opposite of the pre-

vious one. Physical isolation: the customer

may ask to physically isolate (groups of) nodes

from others. Those nodes should then be hosted

“alone” on a cluster or several clusters of the

same provider.

2.2.1 Derived Constraints

In our solution, the cloud broker derives these high-

level (b) relations and placement constraints (c) into

Public means publicly available including unknown

nodes, whereas semi-public means only available from

known (owned) nodes.

SECRYPT2015-InternationalConferenceonSecurityandCryptography

336

more concrete ones, such as information ﬂow con-

straints between nodes, clusters, and providers, using

system and network security protection mechanisms

(i.e., guardians), location, etc. Some possible deriva-

tions rules are described hereafter. The user can be

given the choice of which derivation rule may be cho-

sen if available.

• Collaborating nodes: The connectivity of such

nodes must be ensured. They should be linked

by information ﬂows

• Conﬂicting nodes: (for example) are not linked

by any information ﬂow path (being directly or

transitively), or are separated or isolated.

• Separated/Isolated nodes: must be separated/iso-

lated physically (geographically) or virtually (us-

ing guardians).

• Node conﬁdentiality (resp. integrity): no outgo-

ing (resp. incoming) information ﬂow is possible

from (resp. to) this node.

2.3 Analyzing the Customer’s

Requirements – Preliminary Phase

In order to avoid functional anomalies, vulnerabili-

ties and security violations, the CIM should be con-

sistent before deploying the corresponding services

in the cloud. Indeed, the customer can make mis-

takes when describing the requirements. Thus, the

customer speciﬁcations may contain conﬂicts or er-

rors. The formal analysis of the designed system is a

rigorous way to detect such conﬂicts.

In this preliminary phase, the customer functional

and non-functional requirements are analyzed in or-

der to detect conﬂicts such as: various speciﬁcations

for one single resource (e.g., two different disk vol-

umes for one single VM, various locations or encryp-

tion mechanisms for the same resource), resources

deﬁned as concurrent and collaborating at the same

time, conﬂicting permissions (e.g., a rule authorizing

a given node to read a speciﬁed storage node and an-

other rule to prohibit the same fact.) Every conﬂict is

notiﬁed to the customer who should make the neces-

sary modiﬁcations on his speciﬁcations. This phase is

repeated until the customer corrects the inconsistent

properties of the CIM.

Once the customer requirements are consistent,

the broker starts to match them with the vendors of-

fers to select the suitable ones.

Although, guardians can appear on paths between col-

laborating nodes, in order to block unauthorized ﬂows or

transitive ﬂows from other nodes.

2.4 Generation of Conﬁgurations

During this step, the cloud broker tries to ﬁnd

matches between the customer needs (the CIM) and

the providers offers. It tries to place the nodes on

clusters and to interconnect them in a way to fulﬁll

all requirements. Figure 1 summarizes the algorithm

of clusters selection, nodes placement and the gener-

ations of conﬁgurations, as explained hereafter.

Solution

found?

Notification of

what can not

be ensured

Non-

Functional req

Phase 2: Matching non-

functional requirements

(info flows, guardians)

« firstSelection »

{providers, clusters} for each node

Phase 1: Matching

functional characteristics

(cpu, os, cost)

« secondSelection » Configuration

(placement+interconnection)

{nodes, clusters, guardians, info flows}

End End

Start

Functional

req

Yes

Next Solution

Solution

found?

Figure 1: The ﬂowchart of the placement algorithm.

2.4.1 Functional Requirements – Phase 1

This phase consists in matching the customer func-

tional requirements with the providers offers and se-

lect the compatible offers.

A node is placed on a cluster only if the required

node characteristics (e.g. CPU, RAM, Disk size, data

transfer rate) are provided by this cluster. Other crite-

ria (e.g., cost, location, encryption and authentication

mechanisms) may also be matched at this step.

The broker forms a ﬁrstSelection set containing a se-

lected cluster that satisﬁes the requirements for each

node. These are potential hosts of the customer re-

quired resources.

If no match is found, the broker notiﬁes the customer

about the criteria that cause problems. For example:

there is no cluster that provides Windows OS or there

is not enough storage space in the Denmark area.

Figure 2 presents a possible and simple use-case

of the customer requirements and the providers of-

fers. Each provider offers a set of clusters with spe-

CloudResourcesPlacementbasedonFunctionalandNon-functionalRequirements

337

N2: cpu2N1: cpu1

Provider1

C11:

cpu3

Provider2

N3: cpu3

C12:

cpu1,

cpu4

C22:

cpu3,

cpu4

C23:

cpu2,

cpu4

C21:

cpu2

Customer Requirements Providers Offers

Figure 2: Example: The requirements and offers.

ciﬁc characteristics. The clusters C12 and C21 are

conﬂicting clusters, and they cannot host nodes of the

same customer. The customer requirements consist in

three nodes N1, N2 and N3 with the functional con-

straints (for reasons of simplicity and space limita-

tion, we consider only the CPU speed criterion) CPU1,

CPU2 and CPU3 respectively. These also include the

non-functional requirements:

1. Security relations: N1 and N2 are concurrent

nodes, N1 and N3 are collaborating nodes.

2. Security properties: N3 has write privilege on

node N2.

3. Derivated rules: concurrent nodes should reside in

different physical locations and should not com-

municate.

Figure 3(a) shows all the possible node-to-cluster

assignments corresponding to the use-case above.

The broker returns only one solution at a time. Fig-

ure 3(b) shows the ﬁrstSelection set returned after the

functional requirements matching by the broker. For

each node, a cluster that provides fulﬁlls functional

requirements is selected as a possible host. For exam-

ple: cluster C21 provides the CPU speed CPU2. There-

fore, node N2 can be allocated on this cluster.

Possible assignments

N1 -> C12

N2 -> C21, C23

N3 -> C11, C22

(a) Possible assignments

fir stSelection

N1 -> C12

N2 -> C21

N3 -> C11

(b) The ﬁrstSelection set

Figure 3: An example of the ﬁrstSelection set.

2.4.2 Non-functional Requirements – Phase 2

In the previous phase, the broker has selected a set of

clusters that provide the required functional charac-

teristics for all nodes.

In this second phase, the broker places the cus-

tomer’s nodes on corresponding clusters from the

ﬁrstSelection set, then tries to interconnect nodes and

clusters, in a way that the connectivity between nodes

and clusters ensures the global customer’s system to

work properly. Otherwise, The nodes and clusters

should be interconnected so that the necessary infor-

mation exchanges are possible and the undesired ones

are controlled and rejected. The broker also proposes

a placement of a set of guardians where necessary in

order to block the undesired communications.

The broker generates one placement of the nodes

and interconnections. It tests and checks the conﬁgu-

ration so as to ensure the security properties that the

customer selects from the list described in Section2.2.

The broker generates one conﬁguration of placements

and interconnections and checks its consistency. Fi-

nally, if the conﬁguration ensures the functional and

non-functional requirements of the customer, the bro-

ker produces a secondSelection set. This set contains

the generated conﬁguration. It represents the place-

ment of nodes on clusters, the interconnections be-

tween nodes and clusters, the placement of guardians

between nodes and clusters.

The broker notiﬁes the customer with the pro-

posed conﬁguration. If the customer agrees, she con-

ﬁrms the broker that she is ready for the deployment

and to set up the contract with the selected providers.

If the broker fails to generate a placement conﬁgu-

ration that guarantees the security properties, it gen-

erates another ﬁrstSelection solution. We call it next

solution, which is different from the previous ﬁrstSe-

lection solutions already treated. If such a solution ex-

ists then the broker retries to match the non-functional

requirements. If there is no further solution, then the

broker sends a notiﬁcation to the customer about the

properties that cannot be ensured. For example: the

number of clusters in the ﬁrstSelection set is not suf-

ﬁcient to host the isolated nodes separately; the cus-

tomer prefers that information cannot ﬂow between

concurrent nodes without using guardians, but the

only clusters that can host these nodes, are already

linked by ﬂows.

Let us illustrate phase 2 with the previous example

(cf. Figure 3). After that the broker matches the func-

tional needs, it matches the non-functional and secu-

rity requirements with the clusters of the ﬁrstSelection

set (Figure 3(b)). In this case, cluster C12 is selected

to host node N1 because it is the only one that pro-

vides CPU1. But cluster C12 is conﬂicting with C21,

and conﬂicting clusters cannot host nodes of one cus-

tomer. Thus, node N2 cannot be allocated on cluster

C21. This solution is not possible and does not fulﬁll

the non-functional requirements.

SECRYPT2015-InternationalConferenceonSecurityandCryptography

338

The broker then generates a next ﬁrstSelection solu-

tion. It is shown in Figure 4. Nodes N1, N2 and

N3 are allocated on clusters C12, C23 and C11 re-

spectively. The broker tries again to match the non-

firstSelection

N1 -> C12

N2 -> C23

N3 -> C11

Figure 4: Example: The ﬁrstSelection set (next solution).

functional requirements using the assignments of the

new ﬁrstSelection set. Figure 5 shows the gener-

ated conﬁguration which fulﬁlls all customer require-

ments. To ensure communication between nodes, the

secondSelection

 N1 -> C12

 N2 -> C23

 N3 -> C11

 Info flow: N1->N3, N3->N1, N3->N2,

C12->C11, C11->C12, C11>C23

 Guardian: (C11,C23)

Figure 5: Example: The secondSelection set.

information ﬂows should be set up between the col-

laborating nodes N1 and N3, and a ﬂow from node

N3 to N2. Thus the corresponding hosts should be

linked by ﬂows.

Guardians are placed in order to block the unde-

sired ﬂows. A guardian is placed between cluster C11

and cluster C23 to block the unauthorized ﬂows from

node N2 to N3 and to block the transitive ﬂows from

node N1 to node N2 via node N3 (node N1 and node

N2 are concurrent and should not communicate). This

conﬁguration is shown in Figure 6. The process of

placement stops here and the broker notiﬁes the cus-

tomer with this proposed conﬁguration.

Provider2

C11:

C12:

C22:

C23:

C21:

Provider1

Figure 6: Example: The ﬁrst conﬁguration of the secondS-

election.

2.4.3 The Formal Analysis and Matching

The broker generates a placement conﬁguration based

on the security properties described below. Then it

checks the consistency of the generated conﬁguration.

Therefore, it veriﬁes the assurance of all the required

properties using the information ﬂows that intercon-

nect the nodes.

To be able to do that, the broker transforms any non-

functional or security properties speciﬁed by the cus-

tomer (cf. Section 2.2) into a set of information ﬂows

between nodes called the Flows.

Formal Model – The broker has a formal view

of both providers offers and customers requirements.

We describe a simpliﬁed subset of this formal model

hereafter. Formally, it consists of the following ele-

ments:

A. Sets

• Nodes: the set of nodes. Nodes are actives

and/or passive resources.

There exist subsets of Nodes:

– Isolation ⊂ Nodes: nodes that must be iso-

lated

– Con f identiality ⊂ Nodes: nodes that must

stay conﬁdential

– Integrity ⊂ Nodes: nodes that must keep in-

tegrity

• EO: the set of Elementary (primitive) access

Operations on the system. Seen at very low

level (close to the infrastructure system level),

these elementary operations are simple write or

read access privilege from one active resource

(node) to another.

B. Relations

• Flows : Nodes× EO × Nodes: the global set of

information ﬂows.

• DirFlows ⊂ Flows: The set of direct informa-

tion ﬂows.

∀n

∈ Nodes,eo

∈ EO, (n

,eo

) ∈

DirFlows means the existence of an infor-

mation ﬂow from n

to n

. A ‘write’ access

privilege is equivalent to a forward ﬂow.

A ‘read’ access privilege is equivalent to a

backward ﬂow. Such a direct ﬂow between n

and n

will be noted n

→ n

• InDirFlows ⊂ Flows: the transitive closure of

the DirFlows relation.

∀n

∈ Nodes,eo

∈ EO, (n

,eo

) ∈

InDirFlows means there exists an indirect

(passing through other nodes) information ﬂow

between n

and n

CloudResourcesPlacementbasedonFunctionalandNon-functionalRequirements

339

Such an indirect ﬂow between n

and n

will be

written: n

∗

−→ n

Obviously, Flows = DirFlows ∪ InDirFlows.

• Let Concurrence, Con f licting, and Access, be

subsets of Nodes × Nodes relations, to repre-

sent the concurrent nodes, the conﬂicting nodes

and the write/read privileges respectively.

• Let Guardians be a set of Nodes × Nodes

relation, which represents the placement of

guardians between nodes.

Analysis – The broker generates a conﬁguration

and check its consistency. This consists in verifying

the speciﬁcations derived or expressed using informa-

tion ﬂows such as the following rules (i.e. predicates

in the Alloy language).

i. Conﬂicting nodes should not be interconnected:

∀n

∈ Nodes,(n

) ∈Con f licting =⇒ (n

∗

−→

/∈ Flows ∧ n

∗

−→ n

/∈ Flows)

ii. There is no information that ﬂows into or outside

isolated nodes:

∀n

∈ Nodes, n

∈ Isolation =⇒ @n

∈

Nodes,((n

→ n

)) ∈ Flows∨ (n

→ n

) ∈ Flows)

iii. Isolated nodes can be interconnected with other

nodes but protected by guardians:

∀n

∈ Nodes, n

∈ Isolation =⇒ @n

∈

Nodes,∃n

∈ Nodes,((n

→ n

∈ Flows ∨ n

→

∈ Flows) ∧ ((n

) ∈ Guardians ∨ (n

) ∈

Guardians))

iv. Nodes conﬁdentiality:

∀n

∈ Nodes,n

∈ Con fidentiality =⇒ @n

∈

Nodes,(n

→ n

∈ Flows)

v. Nodes integrity:

∀n

∈ Nodes,n

∈ Integrity =⇒ @n

∈

Nodes,(n

→ n

∈ Flows)

3 IMPLEMENTATION

We have developed the cloud broker including the

previous described steps in one JAVA application.

This application uses an external formal analysis tool:

Alloy (MIT, 2004). Figure 7 presents the workﬂow of

the application. The providers send their offers to the

broker via a speciﬁc interface.

The customer describes its requirements on the

User Interface. This interface is designed in a way

that the customer deﬁnes easily its functional and

non-functional needs, including security properties,

as described in §2.2.

These requirements are translated automatically to

Alloy speciﬁcations via the text2Alloy module. The

Alloy speciﬁcations are then sent to the module that

is dedicating to analyzing the system requirements.

This module receives the Alloy customer speciﬁca-

tions, analyzes them using the Alloy JAVA API at

backend. If it detects some inconsistent properties,

it sends a notiﬁcation containing counterexamples to

the customer. The Alloy2text module translates the

counterexamples to visual and XML formalisms so to

be easily read by the customer. The latter is supposed

to modify its speciﬁcations to avoid the inconsisten-

cies.

The formal analysis using the Alloy API are trans-

parent to the customer. Therefore, the customer can

easily modify its requirements and consult the outputs

of the analysis and the placement without needing to

know Alloy.

When the requirements speciﬁcations are consis-

tent, they are transmitted to the placement modules.

The ﬁrst module consists on matching the functional

requirements with the providers offers. This module

returns the ﬁrstSelection of node to clusters assign-

ments. The second module consists on generating the

secondSelection set. This includes the placement of

nodes across clusters, and setting the possible infor-

mation ﬂows and guardians between nodes and clus-

ters so as to fulﬁll the functional and non-functional

requirements, as described in §2.4.

If a placement is found, the corresponding con-

ﬁguration is sent to the client and visualized via the

Alloy JAVA API. If the customer agrees then she no-

tiﬁes the broker with a deployment conﬁrmation.

The last step consists in deploying the resources such

as compute and storage nodes. We did not develop

this step but we can draw inspiration from existing

mechanisms such as the compatibleOne broker (Yan-

gui et al., 2014).

Alloy Example – We illustrate in this paragraph an

example on how we use Alloy to specify the customer

requirements. We show also how to enforce the secu-

rity properties in the model. Consequently how these

constraints are considered in the matching phase.

The following example shows how to enforce the se-

curity property ii (cf. §2.4.3). This property is spec-

iﬁed by the following rule: there is no information

that ﬂows into or outside all isolated nodes(VMs in

this example).

First we deﬁne some Alloy components we use in this

example: A sig (signature) represents the basic entity

of the model and contains a set of atoms. A fact de-

ﬁnes the constraints that must be satisﬁed all the time

by the described model.

SECRYPT2015-InternationalConferenceonSecurityandCryptography

340

Broker

Customer

Counter Example

Consistent

system req

Provider

Offers

Provider

User Interface

Placement

configurations

Visioning

Deployment

confirmation

Functional

properties

Resources

Model

description

nonFunctional

properties

Requirements

Editing

text2Alloy

Sys req

Analyzing

the system req

Offers

Placement found

Deployment

Placement not found

Placement found

Alloy2text

Placement

Match

functional req

Match non-

functional req

Phase 1

Phase 2

Java Alloy

API

Figure 7: The workﬂow of the broker application.

sig Customer{vms: some VM}

sig VM{attributes: set Attribute }

sig Attribute {}

sig DirFlows{vm ﬂow: set VM→VM }

sig Isolation {isolated: set VM}

fact fact vm ﬂow isol { ∀ vi :VM | @ vj: VM |

vi ∈ Isolation . isolated ∧

( vi→vj ∈ DirFlows.vm ﬂow ∨ vj→vi ∈ DirFlows.vm ﬂow)}

The core model of this example contains the sig-

natures Customer, VM , Attribute, DirFlows and Isola-

tion. A customer requests some VMs. A VM is char-

acterized by a set of Attributes (cpu, ram, etc. which

we do not detail here). The signature DirFlows con-

tains the set of VM × VM vm ﬂow which gathers all

the direct ﬂows of the model. The signature Isolation

contains a set of isolated VM.

The fact vm ﬂow isol consists in enforcing the fact

that for any VM vi such as vi is an isolated VM, there

exists no VM vj such as (vi → vj) or (vj → vi) belong

to the set DirFlows.vm ﬂow.

When the broker sets up all the ﬂows deﬁned in the

DirFlows.vm ﬂow set, it also enforces all the con-

straints deﬁned as facts. This is how our broker en-

sures that the proposed placement fulﬁlls all the cus-

tomer requirements.

4 RELATED WORK

Brokerage & Security Requirements – Very few

brokerage works consider the non-functional require-

ments such as QoS and security. The CSA proposed a

detailed set of questions (CAIQ) (Cloud Security Al-

liance, 2011a) to assess the security capabilities of

cloud providers. A trust management system for the

cloud is proposed in (Habib et al., 2014). This system

allows to assess the trustworthiness of cloud providers

using the the CAIQ repository. Almorst et al. pro-

posed to evaluate security offers of providers based on

the conﬁdentiality, integrity and availability metrics

(Almorsy et al., 2011) . In (Luna Garcia et al., 2012),

(Garcia et al., 2013), the authors proposed methods

for quantitative evaluation and ranking of the security

level of cloud providers. A generic algorithm is pro-

posed in (Jhawar and Piuri, 2013). It considers users

hight level requirements to allocate applications and

tries to optimize both performance and availability.

Authors in (Jhawar et al., 2012) proposed a heuristics-

based approach to consider security requirements for

the resource management in cloud.

Formal Veriﬁcation – Principally, formal methods

are used to check access control policies. Several

works have described how to check the consistency of

access control policies and related security properties.

In papers (Schaad and Moffett, 2002; Schaad, 2003)

and (Toahchoodee and Ray, 2008; Toahchoodee and

Ray, 2009), the authors use the Alloy language to

specify access control policies and security speciﬁ-

cations. They use Alloy analyzer to check that the

access control policies are well implemented.

Bleikertz et al (Bleikertz and Groß, 2011) propose

a formal language to express high-level security goals

CloudResourcesPlacementbasedonFunctionalandNon-functionalRequirements

341

such as the isolation management in cloud environ-

ment. They introduce in (Bleikertz et al., 2011) an

approach for analyzing static virtualized cloud infras-

tructures. They verify the correctness of the deploy-

ment in the cloud given by a conﬁguration snapshot.

5 CONCLUSION

In this paper, we propose a cloud brokering process

based on functional and non-functional requirements.

We propose a matching algorithm which matches the

customers requirements with the providers offers and

propose a corresponding placement conﬁguration to

the customer. We use the Alloy language and ana-

lyzer to specify the provider offers, the customer re-

quirements (and their analysis) and the matching al-

gorithm. Alloy generates a placement conﬁguration

which is analyzed and validated in a way to fulﬁll the

customer requirements.

However, some elements of our global brokering pro-

cess remain to be done. In particular, the numerical

part of the non-functional matching phase is currently

under development, using a ﬁnite domain solver, be-

cause Alloy is not suited for this kind of task. This

part concerns the matching of quantities of resources

(e.g. RAM or disk size, CPU frequency, number of

VMs).

REFERENCES

Almorsy, M., Grundy, J., and Ibrahim, A. S. (2011).

Collaboration-based cloud computing security man-

agement framework. In Cloud Computing (CLOUD),

2011 IEEE International Conference on, pages 364–

371. IEEE.

Bleikertz, S. and Groß, T. (2011). A virtualization assur-

ance language for isolation and deployment. In Poli-

cies for Distributed Systems and Networks (POLICY),

2011 IEEE International Symposium on, pages 33–40.

IEEE.

Bleikertz, S., Groß, T., and M

odersheim, S. (2011). Au-

tomated veriﬁcation of virtualized infrastructures. In

Proceedings of the 3rd ACM workshop on Cloud com-

puting security workshop, pages 47–58. ACM.

Cloud Security Alliance (2011a). Consen-

sus Assessments Initiative Questionnaire.

https://cloudsecurityalliance.org/research/cai/, ac-

cessed on March 15, 2013.

Cloud Security Alliance (2011b). STAR Certiﬁcation.

https://cloudsecurityalliance.org/star/certiﬁcation/,

accessed on January 2015.

Garcia, J. L., Vateva-Gurova, T., Suri, N., Rak, M., and Lic-

cardo, L. (2013). Negotiating and brokering cloud

resources based on security level agreements. In

CLOSER, pages 533–541.

Guesmi, A. and Clemente, P. (2013). Access control

and security properties requirements speciﬁcation for

clouds’ SecLAs. In Cloud Computing Technology and

Science (CloudCom), 2013 IEEE 5th International

Conference on, volume 1, pages 723–729. IEEE.

Habib, S. M., Ries, S., M

uhlh

auser, M., and Varikkattu, P.

(2014). Towards a trust management system for cloud

computing marketplaces: using CAIQ as a trust in-

formation source. Security and Communication Net-

works, 7(11):2185–2200.

Jhawar, R. and Piuri, V. (2013). Adaptive resource man-

agement for balancing availability and performance in

cloud computing. In SECRYPT, pages 254–264.

Jhawar, R., Piuri, V., and Samarati, P. (2012). Support-

ing security requirements for resource management in

cloud computing. In CSE, pages 170–177.

Luna Garcia, J., Langenberg, R., and Suri, N. (2012).

Benchmarking cloud security level agreements using

quantitative policy trees. In Proceedings of the 2012

ACM Workshop on Cloud computing security work-

shop, pages 103–112. ACM.

MIT (2004). Alloy: a language and tool for relational mod-

els.

Rajendran, T., Balasubramanie, P., and Cherian, R. (2010).

An efﬁcient WS-QoS broker based architecture for

web services selection. International Journal of Com-

puter Applications, 1(9):79–84.

Schaad, A. (2003). A framework for organisational con-

trol principles. In PhD thesis, The University of York,

York, England.

Schaad, A. and Moffett, J. D. (2002). A lightweight ap-

proach to speciﬁcation and analysis of role-based ac-

cess control extensions. In Proceedings of the seventh

ACM symposium on Access control models and tech-

nologies, pages 13–22. ACM.

Toahchoodee, M. and Ray, I. (2008). On the formal analysis

of a spatio-temporal role-based access control model.

In Data and Applications Security XXII, pages 17–32.

Springer.

Toahchoodee, M. and Ray, I. (2009). Using alloy to anal-

yse a spatio-temporal access control model supporting

delegation. IET Information Security, 3(3):75–113.

Yangui, S., Marshall, I.-J., Laisne, J.-P., and Tata, S. (2014).

Compatibleone: The open source cloud broker. Jour-

nal of Grid Computing, 12(1):93–109.

SECRYPT2015-InternationalConferenceonSecurityandCryptography

342