![](bg2.png)
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 difficult 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 defines 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-
CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience
300