A Cloud Application for Security Service Level Agreement Evaluation

Valentina Casola

, Massimiliano Rak

and Giuseppe Alﬁeri

DIETI, University of Naples Federico II, Naples, Italy

DIII, Second University of Naples, Aversa, Italy

Keywords:

Cloud Computing, Security, Cloud Application, SPECS, Negotiation, SLA.

Abstract:

Cloud security is today considered one of the main limits to the adoption of Cloud Computing. Academic

works and the Cloud community (e.g., work-groups at the European Network and Information Security

Agency, ENISA) have stated that specifying security parameters in Service Level Agreements actually en-

ables the establishment of a common semantic in order to model security among users and Cloud Service

providers (CSPs). However, despite the state of the art efforts aiming at building and representing Cloud

SecLAs there is still a gap on the techniques to reason about them. Moreover a lot of activities are being

carrying out to clearly state which are the parameters to be shared, their meanings and how they affect service

provisioning. In this paper we propose to build up a cloud application that is able to offer Security level Eval-

uation based on SLA expressed in many different ways. Such application can be offered as a service by Third

Parties in order to help customers to evaluate the offerings from providers. Furthermore it can be used to help

customers to negotiate security parameters in a Multi-Cloud system and perform Cloud brokering on the basis

of a quantitative evaluation of security parameters.

1 INTRODUCTION

Cloud security is today considered one of the main

obstacle to the widespread adoption of Cloud Com-

puting. In this paradigm, due to the self-service on-

demand characteristic, all data and servers reside on

the cloud and charged on a pay-per-use basis. Indeed,

this model brings great advantages from a business

point of view, as there are no maintenance and start-

up costs for any infrastructures, but there is a strong

negative perception of loss of control over the data

and resources.

To face security requirements in the Cloud, early

academic works like (Kandukuri B.R.,et. al., 2009)

and the Cloud Community (e.g., work-groups at the

European Network and Information Security Agency

(ENISA) (Dekker M. and Hogben G.,2011)) stated

that specifying security parameters in Service Level

Agreements (referred as Security Level Agreements or

SecLAs over this paper) actually enables the establish-

ment of a common semantic in order to model secu-

rity among users and CSPs.

However, despite the state of the art efforts aiming

at building and representing Cloud SecLAs (e.g., the

CSAs SLA and PLA working groups (Cloud Security

Alliance, 2012)), there is still a gap on the techniques

to reason about them.

Indeed, a lot of activities are carried out to clearly

state which are the parameters to be included in the

SecLAs, their meanings and how they affect service

provisioning. One of the biggest problems that arises,

even after Security parameters are clearly speciﬁed,

is the needing to help comparing and choosing dif-

ferent providers on the basis of such parameters: se-

curity features cover an incredible amount of differ-

ent aspects of the systems and the customers, often,

are not security experts, even if they have speciﬁc se-

curity constraints. As an example, let us consider a

health center that wants to use the Cloud to main-

tain a backup of its data. The information to be

stored have privacy and availability constraints, more-

over in many countries the law imposes constraints on

data localization. The advantage of using the cloud,

which can grant availability and in given conditions

privacy constraints, is annihilated by the absence of

clear grants on such security grants. Even if CSPs

offer SLAs specifying the security grants, it will be

hard for the customer to clearly compare the offerings

from different providers that offer the same service in

different ways, with different services and expressing

the grants through different policies and SLAs.

The work proposed in this paper born in the con-

299

Casola V., Rak M. and Alﬁeri G..

A Cloud Application for Security Service Level Agreement Evaluation.

DOI: 10.5220/0004858702990307

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 299-307

ISBN: 978-989-758-019-2

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

text of the SPECS (SPE, ) FP7 project, which aims

at building a platform able to offer security services

to Customers for Multi-Cloud environments. We pro-

pose a cloud application that is able to offer Security

Level Evaluation over SLAs expressed in many differ-

ent ways. The evaluation founds on the REM method-

ology, which aims at enabling a quantitative evalua-

tion of security policy. Such application is offered as-

a-service by a Third Party in order to help customers

to evaluate the offerings from providers. Moreover it

can be used to help customers to negotiate security

parameters in a Multi-Cloud system as proposed in

(Liccardo et al., 2012; Amato et al., 2012).

In order to evaluate Cloud providers, we will fo-

cus on the security mechanisms provided to end users,

demonstrating that it is possible to use a standard lan-

guage to represent security parameters and enabling

the evaluation of different providers.

The reminder of this paper is organized as fol-

lows, next sections describe the key concepts to eval-

uate and compare different cloud providers and the

requirements for the development of a security evalu-

ation application; we will outline the background re-

lated to this paper, i.e. the mOSAIC Platofrm with the

API used to develop the Cloud Application and the

REM evaluation methodology. Section 4 describes

how to build policies from the security mechanisms

exposed to end users, in order to make a security eval-

uation. The following section, 5 describes the appli-

cation architecture and its reusable components. Pa-

per ends with section 6 dedicated to conclusions and

future works.

2 PROBLEM STATEMENT AND

APPROACH

As outlined in the previous section, our goal is the

development of an application able to help Cus-

tomers to evaluate and compare different Cloud Ser-

vice Providers (CSP) on the basis of the security they

are able to grant. In a companion paper we proposed

to evaluate providers on the basis of the STAR reposi-

tory, maintained by CSA, which contains the answers

that CSPs has given to a complex questionnaire dedi-

cated to Cloud Security. In this paper, instead, we will

focus on the real security mechanisms the CSPs ex-

pose to Customers and the implication they may have

on the security effectively granted.

We analysed different cloud providers (Amazon

EC2, Google Compute Engine, GoGrid), they offer

similar features (from customers point of view they

are mostly equivalent) but they use completely dif-

ferent technologies and techniques in order to en-

force security mechanisms into the service invocation

mechanism. As an example, Amazon Web Services

(aws) uses SOAP messages to control Amazon Ec2

services, they are secured through a set of HMAC

applied and evaluated to each message. GoGrid, in-

stead, performs an authentication through a dedicated

authentication server, which issues a security token to

be attached to each Web Service invocation. Such dif-

ferent choices have impact both on performances and

on the level of security offered.

Even if such features are clearly visible to end

users, so they can be explicitly evaluated by a third

party, the high number of different technologies of-

fered by different providers and the lack of a clear de-

scription of the adopted approaches, make such com-

parison a very difﬁcult task, usually performed by ex-

perts or, intuitively, by Customers.

We propose to follow a more systematic approach,

adopting existing standards to represent the way in

which security mechanisms are described and ser-

vices are invoked: WS-Policy(Bajaj et al., 2006) and

WS-Security-Policy(Della-Libera et al., 2002).

WS-Policy is a container language that allows to

create a XML Policy based on Assertions. It mainly

allows the use of a group of statements that are al-

ternatives to each other (also the empty alternative)

(ExactlyOne statement) or a group of statements that

must be met (even 0 assertions) (All statement). Ws-

Security-Policy is a language that deﬁnes a set of Se-

curity Assertions to be used within Ws-Policy. These

Assertions are useful to specify both what is required

and what should be guaranteed on the messages and

communication protocols in terms of security when

using a particular service.

We want to point out that the semantic of Secu-

rity Assertions made available by Ws-Security-Policy

is often directly linked to the way in which Security

is managed in the SOAP WebServices (namely in the

structure of the SOAP messages described in the stan-

dard Ws-Security). Since, de facto, a REST message

does not exist, there is not yet a standard language to

describe what is required or offered in terms of Secu-

rity on REST communications.

Such standard representation offers a common ba-

sis to represent the security mechanisms adopted by

the CSPs and this will facilitate the adoption of the

REM methodology to evaluate and compare the of-

fered solutions. In particular, in order to use the REM,

we will build a common template, whose instances

will correspond to the mechanisms adopted by the dif-

ferent providers.

In synthesis the technique we propose is based on

the following steps:

1. Description. Collect WS-SecurityPolicy repre-

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

300

sentations of the security mechanisms offered by

different CSPs based on a standard template we

prepared. Such description can be offered directly

by a provider (rarely) or deﬁned by third parties.

2. Comparison. Using the REM methodology we

quantitatively measure each policy, offering a

clear basis to compare the different offerings of

providers. Thanks to the ﬂexibility of the REM

methodology different customers can specify dif-

ferent weights and evaluation criteria, obtaining

customized evaluations.

The main goal is the implementation of a cloud

application to provide the security evaluation as-a-

service. Before illustrating the details of such tech-

nique, in the next section, we will provide a technical

background to describe the the mOSAIC framework

to easily develop the cloud application and the REM

methodology.

3 TECHNICAL BACKGROUND

The solution we propose to build up a cloud appli-

cation to evaluate providers, founds on two existing

solutions, these will be summarized in this section.

In particular, in the following we will detail only the

key ideas needed to fully understand the proposed ap-

proach: the mOSAIC Framework to easily implement

cloud applications and the REM evaluation methodol-

ogy to evaluate security. For further details the inter-

ested reader may refer to the related papers.

3.1 The mOSAIC Framework

The mOSAIC framework aims at providing a sim-

ple way to develop cloud applications (Petcu et al.,

2011c; Petcu et al., 2011b; Petcu et al., 2011a); the

target user for the mOSAIC solution is the applica-

tion developer (mOSAIC user). In mOSAIC, a cloud

application is structured as a set of components run-

ning on cloud resources (i.e., on resources leased by

a cloud provider) and able to communicate with each

other. Cloud applications are often provided in the

form of Software-as-a-Service, and can also be ac-

cessed/used by users other than the mOSAIC devel-

oper (i.e., by ﬁnal users). In this case, the mOSAIC

user acts as service provider for ﬁnal users.

The mOSAIC framework is composed of a few

stand-alone components. Among them, the most im-

portant roles are played by the Platform and the Cloud

Agency. The ﬁrst one (mOSAIC Platform) enables the

execution of applications developed using the mO-

SAIC API. The second one (Cloud Agency) acts as

a provisioning system, brokering resources from a

cloud provider, or even from a federation of cloud

providers.

mOSAIC can be used in three different scenarios:

• when a developer wishes to develop an applica-

tion not tied to a particular cloud provider;

• when an infrastructure provider aims at offering

“enhanced” cloud services in the form of SaaS;

• when a ﬁnal user (e.g., a scientist) wishes to exe-

cute his own application in the cloud because he

needs processing power.

A mOSAIC application is built up as a collection

of interconnected mOSAIC components. Components

may be (i) core components, i.e., predeﬁned helper

tools offered by the mOSAIC platform for performing

common tasks, (ii) COTS (commercial off-the-shelf)

solutions embedded in a mOSAIC component, or (iii)

cloudlets developed using the mOSAIC API and run-

ning in a Cloudlet Container. mOSAIC cloudlets

are stateless, and developed following an event-driven

asynchronous approach (Petcu et al., 2011c; Petcu

et al., 2011a).

The mOSAIC platform offers ready-to-use com-

ponents such as queuing systems (rabbitmq and ze-

roMQ), which are used for component communica-

tions, or an HTTP gateway, which accepts HTTP

requests and forwards them to application queues,

NO-SQL storage systems (as KV store and columnar

databases). mOSAIC components run on a dedicated

virtual machine, named mOS (mOSAIC Operating

System), which is based on a minimal Linux distri-

bution. The mOS is enriched with a special mOSAIC

component, the Platform Manager, which makes it

possible to manage set of virtual machines hosting the

mOS as a virtual cluster, on which the mOSAIC com-

ponents are independently managed. It is possible

to increase or to decrease the number of virtual ma-

chines dedicated to the mOSAIC application, which

will scale in and out automatically.

Deﬁning a new application is very easy: a cloud

application is described in a ﬁle named Application

Descriptor, it lists all the components and the cloud

resources needed to enable their communication. A

mOSAIC developer has both the role of developing

new components and of writing application descrip-

tors that connect them together.

3.2 Evaluation of Security

The methodology implemented to evaluate security

is the Reference Evaluation Model (REM) (Casola

et al., 2007a; Casola et al., 2007b), it deﬁnes how

to express in a rigorous way the security policy, how

ACloudApplicationforSecurityServiceLevelAgreementEvaluation

301

to evaluate a formalized policy, and how to state the

provided security level. Any policy is represented

through a tree, which contains all the policy provi-

sions (intermediate nodes and leaves).

In Figure 1 the three methodology phases are

shown: Policy Structuring, Policy Formalization

and Policy Evaluation:

The goal of the Structuring phase is to associate

an enumerative and ordered data type K

to the n

leave-provisions of the policy. A policy space “P” is

deﬁned as P =K

× K

× . . . × K

, i.e. the vectorial

product of the n provisions K

. The space is deﬁned

according to a policy template that strongly depends

on the application context.

In the Formalization phase the policy space “P”

is turned into an homogeneous space “PS”. This

transformation is accomplished by a normalization

and clusterization process which allows to associate

a Local Security Level (LSL) to each provision; after

that the provisions may be compared by comparing

their LSLs.

The goal of the Evaluation phase is to pre-process

the “PS” vector of LSLs and evaluate the so called

Global Security Level L

associated to the policy P

The Global Security Level has been deﬁned on the

basis of an Euclidean distance among matrices and

some reference levels:











i f f d

≤ d

i f f d

< d

i f f d

< d

i f f d

< d

i f f d

≤ d

where d

i,0

are the distances among the references

and the origin of the metric space (denoted as

0). This

function gives a numerical result to the security; in-

deed the idea is to evaluate the security associated to

an infrastructure through the evaluation of its security

policy.

The GSL is a measure of the security provided by

an infrastructure according to its security policy; it is

obtained by formalizing the process that is manually

performed by security experts while trying to extend

trust to other domains. The details of the methodol-

ogy are out of the scope of this paper, and they can be

found in (Casola et al., 2007a).

4 A PRACTICAL EXAMPLE

In order to show in practice how the proposed ap-

proach works, in this section we propose the WS Se-

curity Policy template and the instances for the three

generic providers.

The apply the REM to three Cloud Service

Providers, denoted by ProviderA, ProviderB and

ProviderC we need to describe the security mecha-

nisms according to the WS-* models that we created.

To better understand the policy, we ﬁrst summa-

rize the behaviour of the three providers.

ProviderA applies a redundant security mechanism,

it supports HTTPS for the Authentication of the Ser-

vice and the Message Conﬁdentiality. At Message

Layer it supports HMAC to assure the identity of

the sender (with a Secret Key for Encryption) and it

also signs the body of the message ensuring the mes-

sage integrity (operation redundant because it is on

HTTPS).

ProviderB supports HTTPS for the REST call invo-

cations, offering:

• Authentication of the Service : The user knows

that he is sending the message to the right desti-

nation.

• Conﬁdentiality of messages : No one can be aware

of content of a sent message, nor alter it.

At Message Layer it attaches an

AuthenticationToken that is created on the

basis of a shared secret (password), concatenates

the secret string to a string already containing a

username, a timestamp, the user agent (http ﬁeld) and

then applies the MD5 hash function. The receiver

performs the same operations before accepting the

request.

ProviderC basically offers the same

mechanism of ProviderB : HTTPS and an

AuthenticationToken for the User Authenti-

cation. The only positive difference is that it uses

SHA-1 instead of MD5.

4.1 Building the Common Template

In order to represent such features, Ws-Security-

Policy supports three main types of containers:

• Transport Binding the security mechanism

is enforced at transport layer, it may con-

tain different subﬁelds as HttpsToken and

TrasportToken;

• Symmetric Binding the security mechanism is

enforced at SOAP level as speciﬁed in Ws-

Security, by using symmetric keys; it also

allows to express other types of tokens as

SignatureToken and EncryptionToken;

• AsymmetricBinding the security mechanism is

enforced at SOAP level as speciﬁed in WS-

Security, by using asymmetric keys.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

302

Figure 1: Phases of the evaluation methodology.

In our template we will focus only on the ﬁrst two

containers.

We deﬁned a TransportBinding

container, giving to the sequence

TransportBinding/TransportToken the semantic

meaning of Security at the Transport Layer, and to

the HttpsToken subﬁeld the semantic meaning of

support of the HTTPS protocol.

We gave to the sequence SymmetricBinding /

SignatureToken the semantic meaning of security at

the Message Layer (Http message), where there may

be some signed message parts. We did not add the se-

quence SymmetricBinding/EncryptionToken, be-

cause none of the analyzed Providers provides con-

ﬁdentiality on the message at the message layer. Fur-

thermore, in SignatureToken we added predeter-

mined ﬁelds including AlgorithmSuite and Signed-

Parts.

In particular, among the possible

AlgorithmSuite alternatives we used: Md5,

SHA1, HMAC, No (from XMLSignature Speciﬁcation).

Among the possible SignedParts subﬁelds we

added :

• TimeStamp against replay attacks (WS-Trust

Speciﬁcation);

• Password obtaining thus Authenticity of the

Sender (Ws-Security Speciﬁcation);

• Body of Message obtaining thus Integrity of the

message;

By combining WS-Policy and WS-SecurityPolicy

to deﬁne the template, we built the template presented

in the following listing:

Listing 1: The Ws Security Policy Template.

<? xml v e r s i on =” 1 . 0 ” e n c o d i n g =” u t f −8”

<w s p : P o l i c y xmlns:w s p =” h t t p : / / www. w3

. o r g / ns / ws−p o l i c y ”

x m l n s : s p =” h t t p : / / docs . o a s i s −open . o r g

/ ws−sx / ws−s e c u r i t y p o l i c y / 2 00 7 0 2 ”

x m l n s : d s =” h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 9 /

x m l d s i g # ”

x m l n s : w s s e =” h t t p : / / doc s . o a s i s −open .

o r g / wss / o a s i s −wss−w s s e c u r i t y

s e c e x t − 1 . 1 . xsd ”

xmlns:wsu=” h t t p : / / schem a s . x mlsoap . /

ws / 2 0 0 5 / t r u s t

/ Ws−T r u s t . xsd ”>

< s p : T r a n s p o r t B i n d i n g>

< s p : T r a n s p o r t T o k e n>

<s p : H t t p s T o k e n s p : I n c l u d e T o k e n =”

h t t p : / / d o c s . o a s i s

open . o r g / ws−sx / ws−s e c u r i t y p o l i c y

/ 2 0 0 7 0 2

I n c l u d e T o k e n A l w a y s T o R e c i p i e n t ”

w s p : O p t i o n a l = ” t r u e ” />

<!−−N o t P r e s e n t < P r e s e n t−−>

< / w s p : A l l>

< / w s p : E x a c t l y O n e>

< / w s p : P o l i c y>

< / s p : T r a n s p o r t T o k e n>

< / w s p : A l l>

< / w s p : E x a c t l y O n e>

< / w s p : P o l i c y>

< / s p : T r a n s p o r t B i n d i n g>

< s p : S i g n a t u r e T o k e n s p : I n c l u d e T o k e n =”

h t t p : / / d o c s . o a s i s −

ACloudApplicationforSecurityServiceLevelAgreementEvaluation

303

open . o r g / ws−sx / ws−s e c u r i t y p o l i c y

/ 2 0 0 7 0 2

I n c l u d e T o k e n A l w a y s T o R e c i p i e n t ”>

< s p : S i g n e d P a r t s>

<wsu:T i mesta m p w s p : o p t i o n a l =” t r u e ” />

<!−−N o t P r e s e n t < P r e s e n t−−>

<wsp:Body w s p : o p t i o n a l =” t r u e ” />

<!−−N o t P r e s e n t < P r e s e n t−−>

<!−−N o t P r e s e n t < P r e s e n t−−>

< / s p : S i g n e d P a r t s>

< s p : A l g o r i t h m S u i t e>

<d s : S i g n a t u r e M e t h o d d s : A l g o r i t h m =

” h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g #

hmac−s h a 1 ” />

<d s : S i g n a t u r e M e t h o d d s : A l g o r i t h m =

” h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g #

sh a 1 ” />

<d s : S i g n a t u r e M e t h o d d s : A l g o r i t h m =

” h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g #

md5” />

<!−−md5 < s ha 1 < hmac−s h a 1−−>

< / w s p : E x a c t l y O n e>

< / w s p : A l l>

< / w s p : A l l>

< / w s p : E x a c t l y O n e>

< / w s p : P o l i c y>

< / s p : A l g o r i t h m S u i t e>

< / w s p : A l l>

< / w s p : E x a c t l y O n e>

< / w s p : P o l i c y>

< / s p : S i g n a t u r e T o k e n>

< / w s p : A l l>

< / w s p : E x a c t l y O n e>

< / w s p : P o l i c y>

< / s p : S y m m e t r i c B i n d i n g>

< / w s p : A l l>

< / w s p : E x a c t l y O n e>

< / w s p : P o l i c y>

Note that a security expert can perform different

kind of analysis on the policies. For example, being

ProviderA the only one supporting HTTPS, one will

expect it will perform better than the others. On the

other hand, ProviderB and ProviderC do not ensure

the integrity of the message, nor its conﬁdentiality. If

an attacker applies the man in the middle technique,

he can replace the message with a different body. At

that point even the identity of the sender loses mean-

ing. If the attacker is not able to make the man in

the middle technique but only sniff the messages, he

could retrieve the md5 hash and crack it in seconds

obtaining the user password. The SHA1 is stronger

than md5 and he can only guess the password by a

bruteforce attack. If the communication is on HTTPS,

the attacker should perform a bruteforce attack and

the longer is the password, more secure will be the

mechanism.

About ProviderA, the attacker can not use the man

in the middle technique, because the user has signed

the content with HMAC, but he can observe it: the

Security is in the difﬁculty with which the attacker

can guess the key with a ofﬂine bruteforce attack.

In particular, with HTTPS, the attacker should force

with a brute force online attack which is impracti-

cal. From these considerations, it could be said that:

the TransportBinding/TransportToken branch should

leveling out differences however it makes appear the

ProviderA the most secure. On the SymmetricBind-

ing/SignatureToken branch the ProviderA should pro-

vide a Security Level quite high compared to the oth-

ers.

Once made these preliminary actions, and apply-

ing the methodology, the results we obtain in the eval-

uation give three different Global Security Level. For

brevity’s sake we cannot report the whole evaluation

process but the ﬁnal result is:

• ProviderA GSL := 3;

• ProviderC GSL := 2.67;

• ProviderB GSL := 2.5;

Such results are coherent with an intuitive analysis

of the behaviours described at start of the section.

Even if such analysis can be done by an inde-

pendent expert, the approach we propose offers a

clear step toward an automatization of the proce-

dure, assuming a collection of Ws-Security-Policy de-

scriptions of the services offered by different Cloud

Providers, which can be done even by third parties.

5 THE SECURITY EVALUATION

APPLICATION

In this section we will illustrate the functionalities that

the cloud Evaluation Application can offer to a secu-

rity evaluator.

The evaluation of the Security Level of a SecLA

is an action that can be carried out by Security Ad-

ministrators who will have the task of managing their

Platform. They can be Developers who want to test an

application or Methodology Researchers who want to

use the application to run tests in order to study pos-

sible alternatives in the evaluation methodology ﬁeld.

The role of the security evaluator can be clearly hired

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

304

Figure 2: The Application Users.

Figure 3: The Application Use Case diagram.

by End Users who use the application to choose a

Provider. It in turn may be classiﬁed as a Customer

End User, or as a Provider End User who wants to use

the service to test the Security Level of their standards

before entering the market. Figure 2 clariﬁes the rela-

tionships among all these actors.

The Application functionalities are reported in

Figure 3 with the UML Use Case diagram.

The user can request the evaluation of the secu-

rity requirements according to the REM Methodology

(Casola et al., 2007a), compare them with other secu-

rity policies (eventually supplied by cloud providers)

and classify the results in order to choose the best so-

lution.

In the next sections we will illustrate at ﬁrst a

Java library that enables the application of the REM

Methodology, then we will present the mOSAIC com-

ponents that enable its execution in a cloud environ-

ment.

5.1 The Java Library

The Java Library consists of a set of Java Compo-

nents organized in packages.

The Representation Package supplies the data

structures and all the mechanisms required to repre-

sent data. In particular, the parsers package contains

a set of Java Classes to transform security policies ex-

pressed in an interoperable format (XML, for infor-

mation tranfers) into a format suitable for the elabo-

rations (Java Jung Tree) (Jun, ) being the latter de-

ﬁned in the data

structure package. The ”parsers”

and ”data structures” packages can be extended with

new Java Classes in case a new type of Security Pol-

Figure 4: Cloudlets organization.

icy (corresponding to a new template) should be pro-

cessed by the system. The distance evaluator pack-

age implements the speciﬁc evaluation technique.

The difference evaluator package provides classes

able to compare two instances of Security Policies.

These packages can be extended in order to imple-

ment new evaluation techniques which extend those

already deﬁned.

5.2 The Cloud Application Components

The Cloud application, based on the mOSAIC frame-

work brieﬂy described in section 3.1 is composed of

a set of ready-to-use Cloudlets, that embeds the Java

Components. The Cloudlets can be reused and com-

posed by a developer in order to realize its custom

evaluation application.

Figure 4, shows the implemented cloudlets orga-

nized by packages, depending on offered functional-

ities. The cloud representation package contains the

cloudlets offering to developers and ﬁnal users a way

to convert their Security Policies from an human read-

able format to a platform readable representation (and

vice versa), ready to be elaborated. These cloudlets

implement, using the mOSAIC API, the classes de-

ﬁned in the representation package of the Java Li-

brary; they are:

• QSTRepresentation (converts and stores the pol-

icy from readable format via user interface to in-

ternal representation);

• WeightsRepresentation (converts and stores infor-

mations about possible weights from user inter-

face to internal representation);

• ResultRepresentation (converts and stores results

internally represented to an human readable for-

mat from the interface);

The cloud elaboration package contains the

cloudlets offering to developers the Security Policy

evaluation functionalities, with likelihood to choose

between the various elaboration techniques. The

cloudlets contained in this package therefore imple-

ment, using the mOSAIC API, the classes deﬁned

ACloudApplicationforSecurityServiceLevelAgreementEvaluation

305

Figure 5: The mOSAIC Evaluation cloudlets.

in the elaboration package of the Java Evaluation

Framework.

The cloudlets contained in the package are:

• REMEvaluation (offers the evaluation functional-

ities. It implements, using the mOSAIC API, the

”distance evaluator” package of Java Evaluation

Framework);

• WeightsEvaluation (applies the weights to se-

curity policies in accordance with deﬁned

techniques and the type of representation.

It implements using the mOSAIC API the

”weights evaluator” package of the Java Evalua-

tion Framework);

• RemCompare (offers comparation functionalities

between two instances of a Security Policy. It

implements, using the mOSAIC API, the ”differ-

ence evaluator” package of the Java Evaluation

Framework);

• Ranking (rankes the Security Policies conve-

niently evaluated and compared);

The cloud administration package contains essen-

tial cloudlets for the administration, the messages

management, and the interoperability of cloudlets de-

ﬁned in the above packages.

Furthermore, in addition to deﬁned packages, a set

of mangement kv-stores is managed by the system.

They keep the necessary informations for the correct

execution of the mOSAIC Evaluation Applications.

Figure 5 shows the mOSAIC application that eval-

uates a Security Policy submitted by an user.

To describe in greater detail the modus-operandi

of cloudlets, we proceed to illustrate in detail the op-

erations of two cloudlets of the mosaic application.

The QSTRepresentation takes in input a mes-

sage from an HTTP RESTful interface, extracts data,

stores them (eventually) in the QST kv-store, and con-

verts them in two different representations:

• RT (XML representation) (optional, for user re-

trieval);

• JJT (Java Jung Tree Data Structure representa-

tion);

The cloudlet sends the JJT representation of the

Security Policy on an exit queue.

The REMEvaluation takes in input a message

from a the representation cloudlet, containing the

JJT representation of a Security Policy, evaluates it

and stores the JJT evaluated. The cloudlet can send

the JJT list of evaluated Security Policies on an exit

queue.

Summarizing, the user deﬁnes the istance of his

Security Policy (in the QST format) and submits it

to the system through an HTTP interface (mhttpgw).

This transforms the data into a suitable elaboration

format through the QST Representation Cloudlet and

sends it to REMEvaluation Cloudlet, which executes

the evaluation according to one of techniques de-

scribed in the early section. The chosen technique

can be speciﬁed by the user through the same inter-

face. The Evaluation Result Cloudlet stores the result

in a manner that it can be referred later by the user.

6 CONCLUSIONS AND FUTURE

WORKS

The loss of control over the resources is the ﬁrst cause

of the perception of low security in cloud computing.

In this paper we made a ﬁst step in the direction of

offering to customers a new way to control the level

of security offered by provider over the resources they

control. We proposed a way to use standard languages

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

306

to build up comparable policies that enable customers

to compare different provider on the basis of the tech-

nologies adopted using an automated and quantitative

way. We proposed the adoption of WS Policy and

WS Security Policy as standard languages to describe

the mechanisms adopted by provider and, in future

works, we aims at building a collection of policies

describing the technological solutions adopted by dif-

ferent cloud providers. We have shown on real case

studies the application of the proposed technique over

real cloud providers, showing that the results obtained

are coherent with a manual evaluation of the technol-

ogy adopted. Moreover we proposed a Cloud appli-

cation able to automatize the process and support the

security evaluators to apply the technique. The results

in this paper will be improved in the future, build-

ing a dedicated framework which suppot the devel-

opment of custom evaluation application and able to

fully exploit the ﬂexibility of the underling methodol-

ogy, which will be further extended.

REFERENCES

Jung - java universal network/graph framework toolkit.

Specs project.

Amato, A., Liccardo, L., Rak, M., and Venticinque, S.

(2012). Sla negotiation and brokering for sky com-

puting. In CLOSER, pages 611–620.

Bajaj, S., Box, D., Chappell, D., Curbera, F., Daniels, G.,

Hallam-Baker, P., Hondo, M., Kaler, C., Langworthy,

D., Nadalin, A., et al. (2006). Web services policy

1.2-framework (ws-policy). W3C Member Submis-

sion, 25:12.

Casola, V., Mazzeo, A., Mazzocca, N., and Vittorini, V.

(2007a). A policy-based methodology for security

evaluation: A security metric for public key infras-

tructures. Journal of Computer Security, 15(2):197–

229.

Casola, V., Mazzocca, N., Luna, J., Manso, O., and Medina,

M. (2007b). Static evaluation of certiﬁcate policies for

grid pkis interoperability. In Availability, Reliability

and Security, 2007. ARES 2007. The Second Interna-

tional Conference on, pages 391–399. IEEE.

Della-Libera, G., Gudgin, M., Hallam-Baker, P., Hondo,

M., Granqvist, H., Kaler, C., Maruyama, H., McIn-

tosh, M., Nadalin, A., Nagaratnam, N., et al.

(2002). Web services security policy language (ws-

securitypolicy). Public Draft Speciﬁcation (Juli

2005).

Liccardo, L., Rak, M., Di Modica, G., and Tomarchio, O.

(2012). Ontology-based negotiation of security re-

quirements in cloud. In Computational Aspects of

Social Networks (CASoN), 2012 Fourth International

Conference on, pages 192–197.

Petcu, D., Craciun, C., Neagul, M., Lazcanotegui, I., and

Rak, M. (2011a). Building an interoperability api

for sky computing. In High Performance Computing

and Simulation (HPCS), 2011 International Confer-

ence on, pages 405–411. IEEE.

Petcu, D., Cr

aciun, C., Neagul, M., Panica, S., Di Mar-

tino, B., Venticinque, S., Rak, M., and Aversa, R.

(2011b). Architecturing a sky computing platform. In

Towards a Service-Based Internet. ServiceWave 2010

Workshops, pages 1–13. Springer.

Petcu, D., Craciun, C., and Rak, M. (2011c). Towards a

cross platform cloud api. components for cloud fed-

eration. In Procs. 1st International Conference on

Cloud Computing and Services Science, SciTePress–

Science and Technology Publications, Portugal, pages

166–169.

ACloudApplicationforSecurityServiceLevelAgreementEvaluation

307