This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 1

Automatically Enforcing Security SLAs in the

Cloud
Valentina Casola, Alessandra De Benedictis, Mădălina Eraşcu, Jolanda Modic, and Massimiliano Rak

Abstract—Dealing with the provisioning of Cloud services granted by Security SLAs is a very challenging research topic. At the state
of the art, the main related issues involve: (i) epresenting security so that it is understandable by both customers and providers and
measurable (by means of verifiable security-related Service Level Objectives (SLOs)), (ii) automating the provisioning of security
mechanisms able to grant desired security features (by means of a security-driven resource allocation process), and (iii) continuously
monitoring the services in order to verify the fulfillment of specified Security SLOs (by means of Cloud security monitoring solutions).
We propose to face the Security SLA life cycle management with a framework able to enrich Cloud applications with security features.
In this paper we (i) present a novel Security SLA model and (ii) illustrate a security-driven planning process adopted to determine the
(optimum) deployment of security-related software components Such process takes into account both specific implementation
constraints of the security components to deploy and customers security requirements, and enables the automatic provisioning and
configuration of all needed resources. In order to demonstrate the applicability of the approach, we present and discuss a practical
application of the model on a real case study.

Index Terms—Cloud security, Security Service Level Agreement, Optimal Resource allocation

1 I NTRODUCTION

T HE wide adoption of Cloud computing in many applica-

tion domains has urged the need for the introduction of
Service Level Agreements (SLAs) and, above all, of security-
related SLAs (referred to as Security SLAs), in order to meet
the continuous demand from Cloud customers to fulfill
diverse business requirements including security.
Indeed, the adoption of SLAs and Security SLAs in the
Cloud is quite recent, and in the last years many research
projects and initiatives have been funded to advance the
knowledge on this topic [1]. Currently, the most common
solutions for security enforcement, in both classical and
Cloud environments, rely upon the adoption of a certifica-
tion approach (NIST [2], CIRRUS project1 , CCM [3]), which
assumes a complete knowledge of all the service layers, and
they typically involve static security configurations, verified
through security audits. The adoption of Security SLAs,
instead, requires the automation of the process of setting up
and configuring security features for a target service based
on customers’ requirements. This assumes, on the one hand,
a well-defined representation of security requirements that
is understandable for both customers and providers and, on
the other hand, the capability of effectively monitoring that
such requirements are met (by means of verifiable security-
• V. Casola and A. De Benedictis are with the Department of Electrical
Engineering and Information Technology, University of Naples Federico
II, Naples, Italy. E-mail: {casolav, alessandra.debenedictis}@unina.it
• M. Eraşcu is with Institute e-Austria, Timişoara, Romania. E-mail:
merascu@info.uvt.ro
• J. Modic is with XLAB, Ljubljana, Slovenia.
jolanda.modic@xlab.si
• M. Rak is with the Department of Computer Engineering, Second Uni-
versity of Naples, Aversa, Italy. E-mail: massimiliano.rak@unina2.it.
1. The CIRRUS project web site, www.cirrus-project.eu
related Service Level Objectives). These issues, representing
an open research challenge as outlined in [1], [4] and rec-
ognized by some european research projects like SPECS2 ,
CUMULUS3 and MUSA4 , are discussed in this paper where
we present an innovative Security SLA model based on
the well-know WS-Agreement standard [5] for SLA repre-
sentation and management, which has been enriched with
security-related attributes and taking into account recent
standardization initatives from NIST and ISO, too.
As illustrated later in the paper, one of the main in-
novative aspects in the definition of such a model is to
enable the automatic enforcement of security policies (and
security best practice guidelines) by mapping the user secu-
rity requirements with a Security SLA that is automatically
implemented and offers security controls, guaranteed over
time, even if security incidents, that may potentially affect
the signed SLA, occurr. In particular, the proposed Security
SLA model takes into account proper security capabilities
and metrics, with respect to which the measurable Security
Service Level Objectives (SLOs) can be offered and granted
to the customer. Such security capabilities and metrics can
be enforced and monitored via the activation of proper
security mechanisms and related monitoring systems auto-
matically chosen on the basis of a standard Security Control
Framework that can be coded in the SLA model.
In this paper, based on the proposed model, we present
an innovative solution able to automatically acquire and
configure Cloud resources to (optimally) deploy security-
related software components for the enforcement of the
Security SLOs included in the SLA. The proposed approach
E-mail: founds on (i) matching customers’ security requirements
2. The SPECS project web site, http://specs-project.eu/
3. The CUMULUS project web site, http://www.cumulus-
project.eu/
4. The MUSA project web site, http://www.musa-project.eu/

1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 2
reported in a Security SLA with a set of security mecha-
nisms offered as a service (Security-as-a-Service) and on (ii)
automatically generating and implementing an allocation
plan for the actual deployment of software components
belonging the desired security mechanisms. The addressed
security-driven planning problem is very challenging, as
it must take into account not only implementation and
deployment-specific constraints of the security mechanisms
to activate depending on the security features requested by
the customer, but it also must cope with security-related
constraints set by the specified Security SLOs. While some
work exists in the literature on the allocation of resources
based on Quality of Service parameters [6], no comprehen-
sive solutions to the problem of automatically providing
security based on SLAs has been proposed yet. Indeed, state
of art solutions devoted to the provisioning and allocation
of resources [7] do not address the problem of applying
such approaches to security mechanisms and do not take in
consideration customer-defined security requirements and
related security constraints. Moreover, automatic provision-
ing solutions are commonly focused on optimization of
costs and infrastructure resources usage. Such solutions
were applied mainly in the context of High Performance
Computation, on GRID and on clusters of workstations,
and they cannot be easily reused in Cloud, since Cloud
providers (CSPs) do not provide a static pool of resources
whose configuration and deployment features are known in
advance.
In order to demonstrate the feasibility and efficacy of our
proposal, we present a practical applications of the planning
problem on a real case study based on the provisioning of a
Secure Web Container application. With respect to such case
study, we present the whole enforcement phase up to the
definition of an optimal plan, and discuss also how planning
anomalies may occur and may be avoided.
The remainder of this paper is organized as follows: Sec-
tion 2 presents the proposed Security SLA model by speci-
fying the concepts of security metrics, security capabilities,
security mechanisms and Security SLOs, and by illustrating
the Security SLA life cycle and introducing the approach to
Security-as-a-Service; Section 3 details the SLA enforcement
process and analyzes in details the planning problem as
seen from a security driven perspective. Section 4 presents
and discusses the mathematical formulation of the proposed
planning model and the list of possible security constraints.
Section 5 presents some practical applications of the model
built within this paper with the presentation of a case
study. Section 6 discusses related work and, finally, Section
7 presents the conclusions and further research directions of
this work.
2 T HE S ECURITY SLA MODEL
As anticipated in Section 1, in this paper we address the
problem of enforcing security in the Cloud through Security
SLAs. In particular, we are interested in illustrating how
to plan the (optimal) deployment, on Cloud resources, of
software components implementing the security features
requested by a Cloud customer. Before going into the details
of the planning process, described in Section 3, in this
Section we present a novel Security SLA representation that
1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
enables the formal specification of security requirements
and constraints, thus remedying to the current lack of stan-
dards for their definition. Furthermore, we briefly discuss
the Security SLA life cycle and illustrate how it is managed
within the SPECS project, whose activities gave inspiration
to the work presented in this paper.
2.1 Security SLA representation
A Security SLA is an agreement between a Cloud customer
and a Cloud provider that specifies security-related terms
and conditions about delivered services. In addition to the
information about involved parties and provided services, a
Security SLA must include also security-related guarantees.
Unfortunately, despite the strong interest in security and the
existing efforts towards standardization, a shared format
for Security SLAs including the representation of security
attributes and security guarantees is not yet available.
WS-Agreement (WSAG) [5], born in the context of GRID
computing, is currently the only standard supporting both
a formal representation of SLAs and a protocol for their
automation, and has been recently widely adopted, in the
context of many Cloud-oriented FP7 projects (e.g., SPECS,
Contrail, mOSAIC, Optimis, Paasage), to represent SLAs in
the Cloud environment. However, WSAG does not allow, by
its original definition, to specify security-related attributes.
Hence, for the purpose of automatically managing the Se-
curity SLA life cycle, we introduced a Security SLA model
and a machine-readable format based on the WSAG’s XML
schema and extended with all security-related information.
The Security SLA model, according to our requirement
analysis, should enable the Cloud customer to specify its
own requirements through an SLA and verify evidence of
the grants through measurable Service Level Objectives.
Moreover, the SLA should be monitorable and enforceable.
In the security context, these requirements may be con-
flicting: Cloud service customers express security require-
ments with focus on the threats and risks, while Cloud
service providers usually express their grants in terms of
security mechanisms (i.e. tools and software that implement
security policies) and their configuration parameters. On
one hand, the Cloud service customer requirements are
usually hard to measure and enforce, and on the other hand,
the Cloud service providers security details are usually far
from customer interest and understanding.
In order to address such conflicting requirements, we
propose a model that aims at reducing the gap between
Cloud customers and providers by formalizing both declar-
ative and measurable terms.
The declarative terms describe the standard security con-
trols that are ensured over the services protected by the
SLA, and the SLOs (i.e. the measurable terms) are expressed
through metrics that are associated to the security controls
declared: i.e. we propose a set of SLOs and metrics that give
evidence that the security controls are being applied.
A high-level view of the proposed Security SLA model
is represented in the UML diagram in Figure 1, where the
extensions to WSAG to address security concepts are high-
lighted in light gray, in white boxes we reported the WSAG
concepts, while the dark gray box represents the main
concept, namely the Security SLA. As shown, a Security SLA
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 3
Fig. 1. The Security SLA model
is provided with basic information such as the agreement
name and some context information (including the agree-
ment initiator and responder), plus a Terms section (cf.
WSAG specification). The WSAG specification defines two
types of terms, namely service terms and guarantee
terms. Service terms provide information on the services
to which the agreement is referred and to which guarantee
terms can apply, while guarantee terms specify the service
levels that the parties agree upon.
Service terms are further refined in service
description terms and service property terms.
Service description terms define the functionalities that will
be delivered under the agreement, and are characterized
by a term name, a service name, and a domain-specific
description of the offered/required functionalities. In order
to enrich the WSAG specification with security-related
information, we proposed a security-based domain-specific
service term description, made of the following
three sections:
• service resources provider: this section de-
scribes the available infrastructure resource providers
(id, name, zone, and maximum number of allowed
instances reservations, if applicable) and the avail-
able appliances (i.e., virtual machines) offered by each
provider (type of appliance, HW/SW features and de-
scription);
• capabilities: this section describes the security ca-
pabilities5 offered/required on top of the services cov-
ered by the agreement. Each capability is defined as a
set of security controls belonging to a Security
Control Framework, such as NIST’s Control Frame-
work [2] or Cloud Security Alliance’s Cloud Control
Matrix [3];
• security metrics: this section includes the specifi-
cation of the security metrics referenced in the service
5. Security capabilities are defined by NIST as combinations of
mutually-reinforcing security controls (i.e., safeguards and countermea-
sures) implemented by technical means (i.e., functionality in hardware,
software, and firmware), physical means (i.e., physical devices and pro-
tective measures), and procedural means (i.e., procedures performed by
individuals) [2].
1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
properties section and used to define Security
Service Level Objectives (SLOs)6 in the guarantee
terms section. A metric specification includes all in-
formation needed to identify it and to correctly process
the SLOs in which it is involved, such as the metric’s
name, its definition, its unit and scale of measurement,
and the expression used to compute its value.
Service properties are used to define measurable
and exposed properties associated with a service. In our
model, each service property is explicitly associated with
a security capability (since it is used to check the enforce-
ment of related security controls), and contains a set of
variables, referring to security metrics above defined
and representing the actual parameters adopted in SLO
expressions.
Finally, guarantee terms include the conditions that
must be verified to fulfill the agreement. We adopted the
CustomServiceLevel item of the WSAG specification to
define our custom Security SLOs, identified by a SLO id, a
reference to the metric involved in the SLO, and the related
expression, along with a weight assigned by the service
customer and representing the related level of importance.
The proposed Security SLA model not only provides a
formal and shared (among customers and providers) repre-
sentation of security requirements and related SLOs, but it
also enables the automatic management of the Security SLA
life cycle, as illustrated in the following sections.
2.2 Security SLA management
According to current standards on Cloud SLAs (e.g., WSAG
and ISO19086 [8]), the SLA life cycle [9] is characterized by
five phases, namely Negotiation, Implementation, Monitoring,
Remediation and Renegotiation.
During the Negotiation phase, an agreement initiator en-
gages a negotiation process with an agreement responder.
In the considered process, a service customer specifies his
6. Security SLOs are conditions involving proper security metrics,
which allow to measure the level of security being delivered with a
service.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 4
business and security requirements and, based on these, the
agreement initiator, acting on behalf of the service provider,
prepares a SLA Offer. Note that SLA Offers may be built
based on proper SLA Templates, which help define the
admissible agreement requests and responses. The offer is
then submitted to the agreement responder, representing the
service customer, who may accept it or not, thus giving rise
to a possibly iterative process. Negotiation typically ends
with the formal acceptance of an SLA by both parties (often
referred to as the signature of the SLA), and is followed by
the enforcement phase.
During Implementation, not only the provider provisions
and operates the Cloud service, but it also sets up and
provides the customer with the processes needed for the
management and monitoring of the Cloud service itself.
After implementation, the Monitoring phase takes place,
in which the Cloud services covered by the SLA are moni-
tored in order to enable both the provider and the customer
to verify the observance of the SLA terms (i.e., Security
SLOs).
Finally, Remediation takes place when the provider has
to react to events in order to repair an SLA violation (or
to prevent such a violation) and Renegotiation takes place
if one of the two parties aims at changing the agreement
terms, before SLA termination.
Security SLA life cycle management is the core topic
of the FP7-ICT programme project SPECS [10], [11], whose
main objective is to provide an open source framework to
easily build applications that offer services covered by Secu-
rity SLAs. In particular, the SPECS framework is intended
to enhance the offers of existing providers by automatically
activating, in an as-a-service fashion, the security mecha-
nisms that implement the security capabilities negotiated
by Cloud customers. The SPECS framework is composed of
three main modules, namely the Negotiation module, which
manages the Negotiation and Renegotiation phases, the
Enforcement module, responsible of the actions associated
to Implementation and Remediation, and the Monitoring
module, which manages the respective phase. Within the
Enforcement module, the software components that offer
security services for the implementation of specific security
mechanisms are hosted. The SPECS application orchestrates
the services offered by the three main modules. In particular,
the application workflow, which relies upon the proposed
Security SLA model is as follows. A service customer
specifies, through the Application’s interface, the desired
(target) service features and the security capabilities that
he is willing to obtain with the service, among those avail-
able. Moreover, for each selected capability, the customer
also specifies related Security SLOs. Based on customer’s
requirements, a set of compliant SLA Offers is identified
and their feasibility is verified, by taking into account both
the constraints set by the implementation of security mech-
anisms and the Security SLOs defined by the customer. This
phase involves the building of an implementation plan, aimed
at determining the resources to acquire and at identifying
how to distribute (if possible) needed software components
on such resources in order to provide the requested security
features. Upon acceptance, the agreed terms are included in
a Security SLA that is finally signed. Afterward, the agree-
ment is implemented through the Enforcement services,
1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
which realize the implementation plan by actually acquiring
the needed resources and by deploying and configuring
proper components. At the same time, proper monitoring
components are configured and activated.
Let us consider a simple example. With SPECS, we can
choose different Control Frameworks coded in the SLA and
provide different security mechanisms to enforce required
security controls. In a world without SPECS, if we consider
a ”continuous scan of vulnerabilities” requirement and we
adopt the NIST SP800-53r4 on ”Security and Privacy Con-
trols for Federal Information Systems and Organizations” as
a guideline for assessing and coding the Security Control
Framework, a security administrator can verify that the
NIST prescribes the adoption of the RA-5 control (namely
Security Scanning), which imposes to adopt tools that con-
tinuously scans for vulnerabilities and (with ”enhanced con-
trols 1 and 2”) imposes the frequency for maintaining such
tools updated to the latest discovered vulnerabilities db.
With SPECS, we can automatically build and implement
a feasible SLA Offer offering this requirement (expressed
with a SLO). A security mechanism, that implements the
prescribed security control, must be available (as a ser-
vice), it supports metrics to implement and monitor desired
Service Level Objective and grant that the vulnerability
list is updated with a given frequency (this feature is
supported by many common tools, like OpenVAS). The
security mechanism, that provides this security control, is
configured to automatically download the vulnerability list
and update the scanning tools. If the SLA is violated, as
an example the vulnerability list cannot be downloaded in
time, a remediation action takes place, changing the source
of vulnerability list or (in the worst case) notifying that the
system is no more secure, the SLA cannot be sustained
and notifying it to the customer. The SPECS framework
enables to automatically enforce security policies according
to standard security policies and security best practices by
mapping the user security requirements with a Security
SLA that is automatically implemented and offers security
controls, guaranteed over time, even if security incidents,
that may potentially affect the signed SLA, occurr.
The work reported in this paper is focused on the au-
tomatic building of valid SLA Offers and on the definition
of the implementation plan. In particular, we address the
enforcement of a Security SLA from the point of view of the
planning activity aimed at identifying the optimal deploy-
ment of components implementing the requested security
requirements. Such planning activity has a twofold objec-
tive: it is fundamental during SLA Negotiation, in order
to verify the existence of a feasible solution to customer’s
requests, and it is essential during SLA Implementation,
in order to automatically deploy security mechanisms and
have them up and running as agreed in the SLA.
3 T HE SLA ENFORCEMENT PROCESS
With respect to the life cycle described in the previous
section, in this section we focus on the Enforcement phase
and in particular on one specific process orchestrated by the
SPECS Enforcement module, namely the planning process,
which is the essential step for both SLA Negotiation and
SLA Implementation.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 5
As shown in Figure 2, the SLA Negotiation phase starts
when a Cloud customer specifies the business and security
features of the desired service. In order to help the customer
express his requirements, a Security SLA Template is made
available, containing the available choices for the customer
(security capabilities, security metrics, SLOs, etc.). More in
general, security requirements may be specified step by
step in an interactive process, in such a way to gradually
achieve a Security SLA Template compliant with the model
discussed in Section 2.1, which contains all and only the
terms of interest for the customer.
The resulting Security SLA Template, including capa-
bilities and associated controls, security metrics and SLOs,
is forwarded to the Planning component (provided by the
Enforcement module in the SPECS framework) (Step 2),
which is in charge of evaluating its feasibility, building
the plan(s) that will be later used for implementation, and
preparing a set of SLA Offers.
Fig. 2. The enforcement process: building the plan
Based on the SLA Template information, the Planning
component identifies a set of security mechanisms needed to
enforce and monitor the security capabilities, determines the
number of resources needed to deploy all chosen security
mechanisms, and establishes the physical distribution of all
needed security mechanisms’ components on all required
resources. This planning process, carried out with the aid of
a Solver component (described in detail later in this section),
may result in the building of a set of SLA Offers (Step
2.1). It is worth noticing that we prepare the plans before
signing the SLA Offers with customers, in order to grant
their feasibility.
All generated SLA Offers can be ranked according to the
implementation costs and security levels of the associated
CSPs (Step 3.1); in fact, each SLA Offer built in the En-
forcement phase can be associated with an implementation
cost (i.e., the cost of the resources acquired with the CSP
defined in the SLA Offer, the specified zone, and the virtual
appliance type). Furthermore, the security level of each re-
1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
source provider can be evaluated using a security evaluation
methodology, such as REM [12], AHP [13] or QHP [14].
The Cloud customer has the opportunity to select the de-
sired SLA Offer and to sign it. The signed SLA is forwarded
to the Planning component (Step 5), which builds the im-
plementation plan (Step 5.1). This step entails transforming
the signed SLA into a configuration file, later forwarded to
the Implementation component (Step 6) to set and start the
services specified in the implementation plan.
Fig. 3. The enforcement process: SLA implementation
As depicted in Figure 3, the Implementation compo-
nent acquires resources, deploys and configures services
according to the implementation plan (Step 1). Moreover,
in (Step 2) the Implementation component also configures
the monitoring components needed to collect, aggregate
and filter all monitoring data sent by the deployed security
mechanisms’s monitoring components (Step 3), and thus
continuously monitors the fulfillment of the signed Security
SLA.
The implementation component is based on cloud au-
tomation tools (e.g. Chef [15] and Puppet [16]) that enable
to completely automate tasks as provisioning, configuring
and integrating cloud resources. The planning component is
focused on the proper distribution of security components
needed to guarantee SLOs, while the implementation plan
is then used to acquire VMs and deploy all services on a
Cloud IaaS that can guarantee scaling and elasticity features
according to their policies and user needs. In the next sub-
section we will focus our attention on the planning process,
in particular, on building feasible SLA Offers.
3.1 Building Feasible SLA Offers
One of the main functionalities offered by the Planning
component is the building of feasible SLA Offers, starting
from a SLA Template submitted by a Cloud customer. It is
the role of the Planning component to consider customer’s
specified security capabilities and SLOs, and to choose the
right set of security mechanisms and resources to enforce
them. In particular, each SLA Offer will be associated to
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 6

a feasible and optimal allocation plan that includes an
available resource provider (e.g. Amazon EC2) and all the
settings for physical allocation of needed components on a
minimal number of resource.
Figure 4 describes the security-driven planning process
for building a list of SLA Offers. The process comprises three
steps: (i) preparation of a possible list of SLA Offers, (ii)
invocation of the solver to build plans and validate the list
of SLA Offers, (iii) preparation of the list of feasible SLA
Offers.
Fig. 4. Building SLA Offers: the process
In particular, the Planning component generates a possi-
ble SLA Offer on the basis of information specified by the
customer in the SLA Template, i.e. the available resource
providers and the desired security capabilities. The Plan-
ning component generates a possible SLA Offer for each
resource provider available, then selects the set of mech-
anisms able to enforce the security metrics and capabilities
that are declared in the SLA Template. In case when multiple
security mechanisms cover the requested capabilities and
metric, multiple possible SLA Offers will be generated. For
each possible SLA Offer, the Planning component’s Solver
generates a plan that takes into account the amount of
resources needed to enforce the selected security mecha-
nisms, the constraints that mechanisms impose for their
implementation and the SLOs. If the Solver is not able to
generate a plan, the SLA Offer is discarded from the final
list. Finally, the list of feasible SLA Offers is returned back
to the customer that can choose and sign it for effective
implementation.
The problem of building plans associated to security
SLA Offers is very challenging, not just because we need
to consider limitations of resources (e.g., maximal load on
each virtual machine), but because we need to take into
account constraints related to security mechanisms (e.g.,
dependencies or incompatibilities among components) and
to measurable and granteed SLOs.
Each security mechanism consists of a set of components,
which belong to two main categories:
• security components enforce security capabilities speci-
fied in a Security SLA.
• monitoring components observe configured services in
order to guarantee the fulfillment of a Security SLA.
The list of components belonging to a mechanism, along
with related configuration parameters, is included in the
mechanism’s metadata, provided by the mechanism’s de-
veloper. In addition to this, a mechanism’s metadata also
includes other information, such as the resource consump-
tion features of related components, the possible constraints
specified by the mechanism’s developer involving depen-
dencies and incompatibilities among components, and some
deployment rules (for details see Section 4.3.2).
For each security mechanism, the Planning component
has to identify the subset of related software components
that is actually needed to implement the Security SLA, and
then it has to retrieve and customize the set of constraints
related to them. In fact, as discussed more in details in
Section 4, the choice of components to deploy and the actual
definition of constraints to take into account in the planning
process, are both dependent on expressed Security SLOs.
Finally, according to the resource declaration section of
the Security SLA (for each CSP and each type of virtual
appliance offered by the CSP) and according to the final sets
of components and constraints, the Planning components
has to solve the planning problem to build feasible plans
(see Figure 5), i.e., it has to determine:
• the number of instances of each component,
• the number of resources needed to deploy all needed
components,
• the distribution of components over all resources.
The final set of components and their allocation is then
stored into the Planning component and associated to the
generated SLA Offer. SLA Offers that does not have a
solution using the planner are removed from the SLA Offers
list.
Fig. 5. Planning problem - Solver’s input and output
Providing Security SLAs in the Cloud and automatically
building implementation plans for securing Cloud services
is, at the state of the art, a problem that does not have
a known and applicable solution in the literature. At the
best of our knowledge, the majority of approaches is only
partially automated and still based on security administra-
tors following security best practices and security policies
to select, implement and audit security controls. According
to the proposed approach we faced this problem by the
definition of a clear and simple process that completely
enables the automation of the selection of security controls
and mechanisms to measure, monitor and guarantee them.
The approach includes a problem of automatic mechanism
selection, i.e. automatic enforcement of standard security
policies (SLA Offers preparation) and a planning problem
(generation of feasible SLA Offers), i.e., the optimal allo-
cation of software components to resources that will be
illustrated in details in the next sections.

1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 7
4 P LANNING PROBLEM STATEMENT
All the constraints considered in our model can be expressed
in a linear way. Since our goal is to find the minimum
number of resources to acquire to implement an SLA, the
best suited approach to solving the planning problem (from
the constraints, optimization function, and also read com-
plexity and flexibility point of view) is to use Integer Linear
Programming (ILP).
In the following, we illustrate the formulation of the
planning problem. We show how the Planning component
uses information about available resources, information
about the limitations of the infrastructure, constraints re-
lated to the set of mechanisms to deploy, and then dynami-
cally builds the ILP model, i.e., prepares the input and finds
the optimal solution for a SLA Offer.
In order to solve the planning problem, the Planning
component uses a Solver, a component able to process
all requirements and all infrastructure constraints, and to
identify the optimal solution.
Note that, due to some constraints, it may happen that
the Solver is not able to find any solution to the planning
problem. As we mentioned earlier, that would mean that
the SLA offer cannot be enforced and will not be proposed
to customer for signature.
An extensive use case that outlines all planning steps
mentioned in this Section, and presenting our approach to
the automatic enforcement of security SLAs, is provided in
Section 5.
In particular, our formulation is aimed at minimizing the
number of virtual machines to acquire. Given the simplicity
of the model and the limited size of real-world problems,
it is possible to apply exact algorithms such as the Simplex
algorithm, which always returns optimum solutions if they
exist. In our case study, we will adopt Xpress Optimization
Suite that validates the approach, guarantees the feasibility
of the SLA and does not introduce a big computation
overhead. In general, a more complex but more efficient
algorithms (e.g., based on heuristics) may be considered to
cope with bigger problems.
In the following subsections, we discuss and provide the
mathematical formulation for the main input variables of
the model, the output variables, the objective function and
the constraints.
4.1 Input variables: components and virtual machines
The planning model has two main inputs, namely N soft-
ware components to deploy C̄ = c1 , · · · , cN and M avail-
able virtual machines V M = m1 , · · · , mM . As previously
said, this information is retrieved by the Planning com-
ponent from the analysis of the SLA Template: software
components to install, along with their configurations, are
identified based on the selected capabilities and on the
specified SLOs, while virtual machines-related information
is obtained from the resource declaration section of the SLA
Template.
In particular, for each declared capability, the Planning
component retrieves the corresponding security mechanism
and related metadata. The metadata contains the list of all
software components belonging to the mechanism along
with their configuration parameters, some information on
1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
their resource consumption features (e.g., required RAM or
CPU) and the set of constraints that have been specified
by the mechanism’s developer related to their deployment
(cf. Section 4.3). Note that, given a certain security mech-
anism to enforce, depending on the specified metrics and
on related SLOs, only a subset of the mechanism’s declared
components may be selected for actual deployment. These
components constitute the input set C̄ above defined. Each
component ci ∈ C̄ is assigned a computational load li
based on resource consumption features included in the
metadata. This information is easily obtained by properly
testing components in different load conditions.
From the resource declaration section of the SLA Tem-
plate, the Planning component is able to extract available
providers, zones and HW features of the available vir-
tual appliances. Moreover, we assume that the maximum
number of machines that can be acquired by a user from
each provider is also known (e.g., Amazon EC2 poses a
limit of 20 instance reservations per Availability Zone, per
month 7 ). As an alternative, the maximum number of virtual
machines can be computed based on the maximum cost
that the customer is willing to pay. For each provider and
virtual appliance type, the Planning component builds the
set V M of available virtual machines and computes the
optimal allocation of components in C̄ on resources in
V M . All virtual machines of V M are characterized by a
maximum allowed load V M Lmax, computed based on the
HW features declared in the SLA Template.
4.2 Output variables and objective function
As anticipated, we are interested in determining the (min-
imum) number of machines to acquire from the provider,
such that all components in C̄ are deployed on at least one
virtual machine belonging to V M . We have two main sets of
output variables, representing respectively the acquisition
of virtual machines and the allocation of components on
virtual machines:

1, if ci is deployed on machine mj ,
xij =
0, otherwise,
i = 1, 2, · · · , N, j = 1, 2, · · · , M , and

1, if mi is acquired,
yi =
0, otherwise
i = 1, 2, · · · , M .
The objective function aims at minimizing the number of
acquired virtual machines and can be formalized as follows:
M
X
min yi (1)
i=1
4.3 Model constraints
The allocation of components belonging to different mecha-
nisms to virtual machines is subject to various constraints. In
addition to general constraints, which are always considered
in the model and are related to basic allocation rules, it is
7. http://docs.aws.amazon.com/general/latest/gr/aws service limits.html
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 8

possible to identify a set of specific constraints defined by the components ci ∈ Ĉ (note that, by assumption, cα
mechanisms’ developers, which regulate the deployment and Ĉ belong to the same mechanism).
of components based on well-defined intra-mechanism and
inter-mechanism rules and on the values of specific metrics. xαj + xij ≤ 1,
While preparing the input for the model, the Planning ^
component retrieves the metadata associated with each ∀i = 1, 2, · · · , N : i 6= α ci ∈ Ĉ, (SC1a)
mechanism to enforce, and dynamically builds the planning ∀j = 1, 2, · · · , M
model by properly adding specific constraints at runtime.
In the following, we discuss both general and specific con- – SC1b. Full incompatibility/exclusive use: component cα
straints and provide a mathematical formulation for each of needs exclusive use of a machine. Note that this is
them. a particular case of SC1a and can be written in the
same way considering Ĉ = C̄ − cα .
4.3.1 General constraints • SC2. Number of instances. Such constraints refer to
the number of instances of components to deploy. The
We identified the following general constraints:
number of instances is defined through an expression
• GC1. Each component ci must be allocated to at least that includes an operator and a set of up to two values.
one machine. This class can be further divided into three subclasses:
M – SC2a. Number of instances of a component: the number
of instances of component cα must comply with an
X
xij ≥ 1, ∀i = 1, 2, · · · , N (GC1)
j=1
expression. The allowed expressions are summarized
in Table 1.
• GC2. The maximum allowed load V M Lmax on each
acquired machine cannot be exceeded. TABLE 1
SC2 allowed expressions

N
X Operator value1 value2
xij ∗ li ≤ V M Lmax, ∀j = 1, 2, · · · , M (GC2) = n -
i=1 ≥ n -
≤ n -
• GC3. A component ci can be allocated to virtual ma-
in n1 n2
chine mj only if mj is acquired.
In the following, the related mathematical formula-
xij ≤ yj , ∀i = 1, 2, · · · , N , ∀j = 1, 2, · · · , M tions are listed.
(GC3) M
X
xαj = n (SC2a-1)
4.3.2 Mechanism-specific constraints j=1
As anticipated, further constraints may apply to mecha- M
nisms or to components depending on their specific fea-
X
xαj ≥ n (SC2a-2)
tures. We assume that such constraints are set by mech- j=1
anisms’ developers, who may not be aware of the other
M
implemented mechanisms and their components. As a con- X
sequence, we consider either intra-mechanism constraints xαj ≤ n (SC2a-3)
j=1
that express rules on the joint deployment of specific compo-
nents belonging to the same mechanism, or inter-mechanism M
X
constraints, which express general rules that only indirectly n1 ≤ xαj ≤ n2 (SC2a-4)
involve components from different mechanisms. j=1
Mechanism-specific constraints can be divided into – SC2b. Number of instances of a set of components: the
classes, by grouping together constraints of the same type. total amount of instances of components ci ∈ Ĉ must
We identified four main classes and, within each class, comply with an expression as defined in Table 1.
we also identified subclasses of constraints that can be Although this constraint includes the previous one,
expressed with similar mathematical formulations. This is we decided to consider them separately in favour of
particularly useful in order to define a syntax for the rep- the clarity of the case study, shown in Section 5. The
resentation of mechanism-specific constraints to include in related mathematical formulations are listed in the
the mechanisms’ metadata, as we will show in Section 4.3.3. following.
• SC1. Incompatibility. Such constraints express a con-
M
dition of incompatibility among components, which X
implies that the involved components cannot be de- xij = n (SC2b-1)
ployed on the same machine. This class can be further i:ci ∈Ĉ,j=1
specialized into two subclasses: M
X
– SC1a. Simple incompatibility: component cα cannot be xij ≥ n (SC2b-2)
allocated to a machine together with a set of other i:ci ∈Ĉ,j=1

1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 9

M
X M
X M
X
xij ≤ n (SC2b-3) xαj ≤ xβj (SC4-3)
i:ci ∈Ĉ,j=1 j=1 j=1

M M
X M
X
xαj = 1 + f loor(1/n ∗ xβj )
X
n1 ≤ xij ≤ n2 (SC2b-4) (SC4-4)
j=1 j=1
i:ci ∈Ĉ,j=1
Note that avoiding conflicts among constraints belong-
– SC2c. Full deployment of a component: cα must be
ing to the same mechanism is up to the mechanism’s
installed on each acquired machine.
developer. Nevertheless, conflicts may still appear among
Clearly, such constraint must take into account possi-
constraints of different mechanisms. Consider for instance
ble incompatibilities with other components in order
the following situation: an SC1b (full incompatibility) con-
to make the problem feasible and solvable. Therefore,
straint has been defined for component cα of mechanism
the developer must also indicate the set of compo-
sm1 , while an SC2c (full deployment) constraint has been
nents ci ∈ Ĉ that are incompatible with cα . The
set for component cβ of mechanism sm2 . Clearly, if such
resulting mathematical formulation is as follows:
constraints were included in the model without any mod-
X ification, the solver would not find any feasible solution.
xαj + xij = yj , ∀j = 1, 2, · · · , M In order to avoid this situation, the Planning component
(SC2c)
i:ci ∈Ĉ recognizes that two constraints of type SC1b and SC2c
respectively have been specified, and automatically rewrites
This formulation states that, if cα must be allocated constraint SC2c by including cα in the set Ĉ of components
on all acquired machines but it is incompatible with that are incompatible with cβ . An example of this will be
cβ (since, for example, an SC1b constraint has been shown in Section 5.
defined for it), then if machine mj is acquired (i.e.,
yj = 1), exactly one component between cα and cβ 4.3.3 A syntax for mechanism-specific constraints
will be deployed on mj .
A security mechanism developer must be provided with
• SC3. Minimum number of machines. Such constraint a clear and simple syntax to define specific constraints for
expresses the need for a minimum number n ≤ M of his mechanisms based on the classes above discussed. The
machines and may be explicitly introduced by a SLO. constraints specified by the developer will be included in
The formulation of this constraint is as follows: the mechanism’s metadata along with configuration param-
M
X eters and other information needed to run the mechanism.
yi ≥ n (SC3) Constraints and metadata in general may be specified in
i=1 several formats, based, for example, on the popular XML
and JSON technologies. In the SPECS project and in this
• SC4. Dependency. The number of instances of a com-
paper we adopt the JSON format as it is a lightweight data-
ponent cα depends on the number of instances of a
interchange format that is language-independent, easy to
component cβ according to an expression. The allowed
read and write for humans, and easy to parse and generate
expressions are summarized in Table 2.
for machines.
The JSON schema for mechanism-specific constraints
TABLE 2 is reported in Listing 1. The schema includes the id of
SC4 allowed expressions
the involved class or subclass of constraints (ctype), two
Operator value possible arguments (arg1 and arg2), an operator (op), and
= - two integer values (v1 and v2). The arguments may include
≥ - either the (integer) id of a component or the list of ids of
≤ - a set of components depending on the specific constraint
* n class/subclass, while the operator is one of those defined
in tables 1 and 2. Table 3 illustrates how to fill the JSON
While the meaning of the first three expressions is schema for each of the constraint classes defined in Section
straightforward, it is worth spending some words on 4.3. Given this mapping, a developer can add constraints to
the last one: this last expression is used to state that mechanisms’ metadata in a very easy way.
every n instances of cβ there must be one further
instance of component cα (at least one instance of cα
must be present). The mathematical formulation of this
class of constraints is as follows.
M
X M
X
xαj = xβj (SC4-1)
j=1 j=1

M
X M
X
xαj ≥ xβj (SC4-2)
j=1 j=1

1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 10

Listing 1. JSON schema for mechanism-specific constraints which represent the guarantee terms that the customer and
{ the CSP agree upon. In our case study, two metrics related to
{
"ctype": "string",
the Web Resilience capability are considered, namely Level
"arg1": { "type": "array", of Redundancy (LoR) and Level of Diversity (LoD).
"items": { The former represents the number of replicas of the web
"type": "integer" container that are set-up and kept active throughout the
},
}, service operation to ensure redundancy, while the latter is
"arg2": { the number of different software and/or hardware versions
"type": "array", of the web container service that are set-up and kept active
"items": {
throughout the service operation to increase the protection
"type": "integer"
}, from attacks and vulnerabilities exploits. Note that LoR and
}, LoD are both metrics, which can be easily checked by verify-
"op":"string", ing the number of active replicas, and enforcement parame-
"v1":"integer",
"v2":"integer", ters, used to actually configure the WebContainerPool mech-
}, anism in order to achieve the desired resiliency. Regarding
"required":["ctype"] the Intrusion Detection capability, the Report Generation
} Frequency (RGF) metric is considered. This metric spec-
ifies the frequency (in hours) of generation of intrusion
detection reports, and is actually used as a configuration
TABLE 3
Mechanism-specific constraints parameter when building the implementation plan. In our
case study, during negotiation, the customer selects LoR=3
ctype arg1 arg2 op v1 v2 and LoD=2 and specifies RGF=2. These SLOs are included
SC1a cα ci ∈ Ĉ - - - in the SLA Template, which is passed to the Enforcement
SC1b cα - - - - module to prepare SLA Offers. The Enforcement module
SC2a-1 cα - = n - retrieves the mechanisms associated with the selected capa-
SC2a-2 cα - ≥ n - bilities along with their metadata and instantiates the model
SC2a-3 cα - ≤ n -
SC2a-4 cα - in n1 n2
discussed in section 4 by identifying the input and output
SC2b-1 ci ∈ Ĉ - = n - variables and the specific constraints to include (see next
SC2b-2 ci ∈ Ĉ - ≥ n - subsections).
SC2b-3 ci ∈ Ĉ - ≤ n -
SC2b-4 ci ∈ Ĉ - in n1 n2
SC2c cα ci ∈ Ĉ - - - 5.1 Model input and output variables
SC3 - - - n -
SC4-1 cα cβ = - - The first input to the model is represented by the set of
SC4-2 cα cβ ≥ - - components that must be deployed. The WebContainerPool
SC4-3 cα cβ > - -
SC4-4 cα cβ ∗ n -
mechanism is implemented by a set of different web con-
tainer components and a Balancer, which is responsible for
dispatching web requests to the active web containers to
ensure load balancing. Since the customer requested LoD=2,
5 A WEB CONTAINER CASE STUDY only two different web container components are selected,
In order to illustrate the introduced approach, in this section namely Apache and Nginx. For what regards the WebIn-
we discuss a case study involving the provisioning of a se- trusionDetection mechanism, two components are involved,
cure web container service (cf. Figure 6). The web container namely an IDSAgent, to be installed on the resources to
service is offered without security guarantees by a CSP, protect, and an IDSServer, which collects data gathered by
while the security capabilities specified by the customer the IDSAgents and performs the detection activities.
during negotiation are provided, in an as-a-service fashion, Overall, we have N = 5 components:
by the SPECS framework. In our case study in particular, the
customer is interested in acquiring a web container service C̄ = {Balancer, Apache, N ginx,
provided with the following security capabilities: (2)
IDSServer, IDSAgent}
• resilience to attacks and failures by means of the intro-
duction of redundancy and diversity techniques, and Regarding virtual machines, let us assume that the se-
• protection from unauthorized and potentially danger- lected provider allows to acquire M = 20 machines at most.
ous accesses, by means of the integration of proper Therefore, we have a set of 100 variables xi,j representing
intrusion detection tools. the allocation of components to machines plus a set of 20
Such security capabilities, named respectively Web Re- variables yi to express the acquisition of virtual machines.
silience and Intrusion Detection, are implemented through Note that, although the size of the problem is pretty big,
proper software mechanisms offered as part of the SPECS linear programming tools are able to provide a solution
Enforcement module, namely WebContainerPool and WebIn- quite easily for this kind of models.
trusionDetection. Related to each capability and more pre- Finally, as for components’ costs and machines’ capac-
cisely to the included security controls, proper security met- ities in terms of computational load, let us assume that
rics can be selected by the customer to define Security SLOs, li = 1 ∀i = 1, 2, · · · , N and that V M Lmax = 10.

1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 11

Fig. 6. The case study planning process

5.2 Mechanism-specific constraints "n1": (LoR)}

{ "ctype": "SC3",
As anticipated, in addition to general constraints (cf. Section "n1": (LoR+1)}]
4.3.1), a set of specific constraints is defined at development
time for each security mechanism. While preparing the
model input, the Planning component must dynamically in- TABLE 4
clude such constraints in the model and possibly customize WebContainerPool constraints
them based on the values of specific SLOs reported in the
ctype arg1 arg2 op v1 v2
SLA Template. In the following, we discuss specific con-
SC1a Balancer {Apache, - - -
straints for the two considered mechanisms and provide the N ginx}
related formal representation based on the syntax illustrated SC1a Apache N ginx - - -
in Table 3. SC2a-1 Balancer - = 1 -
SC2b-2 {Apache, - ≥ LoR -
N ginx}
5.2.1 WebContainerPool constraints SC3 - - - LoR + 1 -
The constraints set for the WebContainerPool mechanism are
the following: 5.2.2 WebIntrusionDetection-specific constraints: syntax
1) The Balancer component cannot be deployed on the The following specific constraints are defined for the WebIn-
same machine where any of components {Apache, Ng- trusionDetection mechanism:
inx} reside.
1) IDSServer components need exclusive use of machines.
2) The Apache component cannot be deployed together
2) One component IDSAgent must be allocated on every
with the Nginx component.
acquired machine except where an IDSServer is in-
3) Exactly one component Balancer has to be instantiated.
stalled.
4) The total amount of instances of components {Apache,
3) There must be an IDSServer component additional in-
Nginx} must be at least equal to LoR.
stance every ten IDSAgent component instances.
5) At least LoR + 1 virtual machines must be acquired.
The representation of such constraints based on the in-
Listing 2 shows the representation of such constraints in troduced syntax is illustrated in Listing 3 and Table 5. Note
the reference syntax, while a more readable view is given in that, for SC1b constraint (full incompatibility of IDSServer),
Table 4. the indexes of all the other components, with which the
incompatibility holds, will be computed by the Planning
Listing 2. WebContainerPool constraints: JSON specification
[{
component when preparing the inputs to the model.
"ctype": "SC1a",
"arg1": [1], Listing 3. WebIntrusionDetection constraints: JSON specification
"arg2": [2,3]} [{
{ "ctype": "SC1a", "ctype": "SC1b",
"arg1": [2], "arg1": [4]}
"arg2": [3]} { "ctype": "SC2c",
{ "ctype": "SC2a-1", "arg1": [5],
"arg1": [1], "arg2": [4]}
"op": "=" , { "ctype": "SC4-4",
"n1": 1} "arg1": [4],
{ "ctype": "SC2b-2", "arg2": [5],
"arg1": [2,3], "op": "*" ,
"op": ">=" , "n1": 10}]

1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 12

Table 5 shows the representation of such constraints in formulations for automatic processing may result more or
the reference syntax. less complicated depending on the related syntax. In order
to conclude the case study discussion with some experimen-
TABLE 5 tal results, we translated the analytical model to the Mosel
WebIntrusionDetection-specific constraints: syntax language 8 and processed it with the Xpress Optimization
Suite 9 , a commercial product for analytical optimization
ctype arg1 arg2 op v1 v2 that provides an educational release, adopted to conduct
SC1b IDSServer - - - - the experiments for this paper. Translation is quite straight-
SC2c IDSAgent IDSServer - - -
SC4-4 IDSServer IDSAgent ∗ 10 - forward and can be easily accomplished through a parser.
We run the model, consisting of 120 variables and 289
constraints, and obtained that 5 machines must be acquired
and components must be allocated as indicated in Table 6.
5.3 The Secure Web Container planning model
In the following, the complete planning model for our case TABLE 6
study is reported. Planning problem solution

20
X VM Components
min yi (objective function) 1 Apache, IDSAgent
i=1 2 Nginx, IDSAgent
s.t. 3 IDSServer
20
X 4 Balancer, IDSAgent
xij , ≥ 1 ∀i = 1, 2, · · · , 5 (GC1) 5 Apache, IDSAgent
j=1
Since a solution has been found, the Planning component
5
X builds an SLA Offer containing all capabilities and SLOs
xij ∗ 1 ≤ 10, ∀j = 1, 2, · · · , 20 (GC2)
specified by the customer during negotiation and submits it
i=1
to the customer for the signature. Later on, during the Im-
xij ≤ yj , ∀i = 1, 2, · · · , 5, ∀j = 1, 2, · · · , 20 (GC3) plementation phase, results produced by the solver will be
used to actually implement the plan and install components
x1j + xij ≤ 1, ∀i ∈ [2, 3], ∀j = 1, 2, · · · , 20 (SC1a)
on machines.
x2j + x3j ≤ 1, ∀j = 1, 2, · · · , 20 (SC1a) Let us consider a slightly different formulation of the
20
problem. Assume that constraint number 1 (“The Balancer
X component cannot be deployed on the same machine where
x1j = 1, (SC2a-1)
any of components {Apache, Nginx} reside”) of WebCon-
j=1
tainerPool mechanism is changed to: “Balancer components
20
X need exclusive use of machines” (SC1b). If the related
xij ≥ 3, (SC2b-2) model formulation was given in input to the solver, no
i:i∈[2,3],j=1 feasible solutions would be found, since the new intro-
20 duced constraint conflicts with constraint number 2 (“One
X
yi ≥ 4, (SC3) component IDSAgent must be allocated on every acquired
i=1 machine except where an IDSServer is installed”) of WebIn-
trusionDetection mechanism. In order to cope with this issue,
x4j + xij = 0, ∀i ∈ [1, 2, 3, 5], ∀j = 1, 2, · · · , 20 the Planning component always checks for the existence of
(SC1b) potentially conflicting constraints (in our case, SC1b and
x5j + x4j = yj , ∀j = 1, 2, · · · , 20 (SC2c) SC2c) and, in case of a conflict, it reformulates the less
20
X 20
X strict one, which in this case is the SC2c constraint set
x4j = 1 + f loor(1/10 ∗ x5j ), (SC4-4) on WebIntrusionDetection. In particular, such constraint is
j=1 j=1 updated to: “One component IDSAgent must be allocated
on every acquired machine except where an IDSServer or a
xij ∈ {0, 1}, i = 1, 2, · · · , 5, j = 1, 2, · · · , 20 Balancer are installed”, which corresponds to the following
yi ∈ {0, 1}, i = 1, 2, · · · , 20 formulation:
(bin. variables)
As discussed, this model is passed to an automatic x5j + x4j + x1j = yj , ∀j = 1, 2, · · · , 20 (SC2c)
solver running within the Planning component. Several
open source software libraries exist that allow to build and Such an updated planning model is then provided to the
solve linear programming models in a programmatic way, solver, which returns the results reported in Table 7.
and the implementation of a solver module that adopts such As a final remark, let us briefly discuss what happens
libraries within the Planning component is devised in the when no feasible solutions are found. As a simple example,
SPECS project and is part of the work in progress activities.
8. http://www.fico.com/en/wp-content/secure upload/Xpress-
Clearly, the final representation of the model is strictly Mosel-Libraries.pdf
dependent on the library selected for its implementation 9. http://www.fico.com/en/products/fico-xpress-optimization-
and solution, and the translation of model’s mathematical suite

1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 13
TABLE 7
Planning problem solution version 2
VM Components
1 Apache, IDSAgent
2 Nginx, IDSAgent
3 IDSServer
4 Balancer
5 Apache, IDSAgent
consider the above discussed case study with its last up-
dated formulation, and assume that the components’ loads
and the virtual appliances’ features are such that it is not
possible to allocate an IDSAgent on each machine due to
maximum load constraints. If any other SLA Offer is gener-
ated for a different set of virtual appliances/providers, then
the customer will be returned the available offers, otherwise
he will be asked to change his requirements and the whole
planning process will be repeated.
6 R ELATED WORK
Automatically providing security features through Security
SLAs is a challenging task. This was first outlined in [4],
[17], where the authors provided hints on how Cloud SLAs
could be extended to cover security aspects, allowing com-
position of Cloud services from several service providers
with a defined security level. The Security SLA life cycle
(negotiation, monitoring, enforcement) was also introduced:
the SLAs are first published generically by a provider, and
when a customer wishes to use a Cloud service, he will then
negotiate a specific SLA to which the provider will commit,
and the service will be provisioned. The customer may want
to monitor the service to ensure that the negotiated SLA is
being adhered to by the provider. At any time during the
commitment, provisioning and monitoring phases, the cycle
may return to the negotiation phase, e.g., if the provider
after a violation of some SLA guarantee term cannot commit
to the previously negotiated SLA (renegotiation). As dis-
cussed, this approach is followed in the SPECS project and
also by the majority of the approaches dealing with Security
SLAs.
Attempts to automatically enforcing Security SLAs have
been materialized in a few European projects as described
below.
Contrail10 provides a stack of software components de-
signed to work together and combine a number of indepen-
dent Clouds into one integrated federated Cloud. In partic-
ular, the Contrail SLA component enables SLA definition,
monitoring and enforcement at all levels of the federated
Cloud. SLA Enforcement is performed via the SLA com-
ponent at the provider layer. An SLA encompasses, among
other constructs, Quality of Protection (QoP) attributes, de-
scribing a specific measurable aspect of the protection/se-
curity of a service (e.g. authentication, strength, reputation),
and therefore security attributes can be negotiated, moni-
tored and enforced.
SLA@SOI11 aims at enabling automatic negotiation of
personalized SLAs across multiple providers and at empow-
10. http://contrail-project.eu/
11. http://sla-at-soi.eu/
1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
ering IT services to be traded as economic goods. Enforce-
ment of the SLAs is realized through a rule-based technique
having the following features: (a) is tightly coupled with
monitoring data, (b) SLA Enforcement is performed through
triggering infrastructure policies, (c) dynamic adjusts in case
the load varies, (d) restores the service parameters. Security
is addressed by QoS like VM Persistence, VM Image, Service
Isolation, Auditability, SAS70 Compliance, Service Data Re-
tention, Service Data Delete Method, VM Snapshot Backup
and VM Snapshot Retention but is not very clear how these
QoS are measured.
OPTIMIS12 aims at optimizing IaaS Cloud services by
producing an architectural framework and a development
toolkit. Optimis gives service providers the opportunity to
easily orchestrate Cloud services from scratch, run legacy
applications on the Cloud and make intelligent deployment
decisions based on their preference regarding trust, risk,
eco-efficiency and cost. Furthermore, it supports end-to-end
security and compliance with data protection. Furthermore,
Optimis Toolkit provides security services ensuring secure
data communication and storage for the virtual machines.
Further, [18] presents a Cloud Service Brokerage mecha-
nism which helps customers select the right SaaS provider
that can fulfill their functional and quality-of-service (QoS)
requirements. In their approach, negotiation and enforce-
ment are not distinct modules, but the negotiation compo-
nents (Selection Manager, SLA Manager, Profile Manager,
Policy Manager) interplay in order to deliver personalized
services to clients. No reference to security QoS is mentioned
in the paper.
The focus of this paper is on solving the planning problem,
that is, on finding the best allocation of software compo-
nents necessary for enabling security mechanisms on a (min-
imum) set of virtual machines. In particular, as mentioned
in Section 4, the planning has to take into account both
general and mechanism-specific constraints. Regarding related
research on how to model and solve the planning problem,
we mention that there exists extensive research on opti-
mal VM provisioning with respect to the so-called general
constraints (cost, energy/power consumption, availability,
throughput, etc.): the problem is typically formalized as a
bin-packing /multicriteria optimization problem and solved
by using various tools implementing heuristics like greedy,
linear programming, dynamic programming. A survey of
methods and tools solving the VM provisioning problem
is available in [19]. For example, [20] proposes a decen-
tralized economic approach for dynamically adapting the
Cloud resources of various applications, so as to statisti-
cally meet their SLA performance and availability goals
in the presence of varying loads or failures. [21] proposes
resource allocation policies for the management of multi-tier
virtualized Cloud systems with the aim of maximizing the
profits associated with multiple-class SLAs and a heuristic
solution for them based on local-search which provides
availability guarantees for the running applications. Finally,
[7] proposes a resource provisioning and scheduling strat-
egy for scientific workflows on Infrastructure as a Service
(IaaS) Clouds. Their strategy is based on the meta-heuristic
optimization technique, particle swarm optimization (PSO),
12. http://www.optimis-project.eu/
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2016.2540630, IEEE
Transactions on Services Computing
IEEE TRANSACTIONS ON SERVICES COMPUTING - SPECIAL ISSUE ON SECURITY AND DEPENDABILITY OF CLOUD SYSTEMS AND SERVICES, VOL. , NO. , SEPTEMBER 14
which aims to minimize the overall workflow execution cost
while meeting deadline constraints.
It is important to point out that, even if the discussed
literature addresses problems that are very similar to the
one that is object of this paper, such solutions do not
take into consideration security constraints specified by the
customers through the SLAs. Indeed, the main benefit intro-
duced by our model is its flexibility, as it allows the mech-
anism developer to add, at development time, mechanism
specific constraints that will be automatically customized
and included in the model at run-time, based on the terms
included in a Security SLA.
7 C ONCLUSIONS
In this paper, we addressed the automatic enforcement of se-
curity controls on top of Cloud services based on a Security
SLA. In particular, we focused our attention on the problem
of automatically planning the allocation, on a minimum set
of Cloud resources, of the software components needed to
implement security features requested by a Cloud customer
during negotiation.
As illustrated, the automatic activation of security fea-
tures based on customers’ specified security requirements
needs, first of all, a clear and formal way to express such
requirements: for this reason, we introduced an extension of
the WS-Agreement specification including security-related
parameters and representing our reference format for Secu-
rity SLAs. Based on such specification, we built a planning
model able to find the optimum allocation of components
while taking into account several constraints and configura-
tion parameters provided at runtime and partly dependent
on input security requirements.
The novelty of our contribution is twofold: from the one
hand, we provided a security-related SLA representation,
which is still missing despite the recent interest of industrial
and academic communities and the numerous initiatives
in this direction; from the other hand, we introduced a
practical approach to automatically configure and activate
security mechanisms (and related monitoring systems) for
enhancing existing Cloud services, based on the security
guarantees requested by a customer.
As discussed, the presented work is part of a wider
project and framework, SPECS, which is focused on the
management of the whole Security SLA life cycle. The
results illustrated in this paper are very promising for the
project, and we plan to extend the planning approach to
cope with the phase of SLA Remediation, which comes into
play when a violation of a signed Security SLA occurs and
can be handled by automatically reconfiguring the delivered
security mechanisms in order to keep the desired level of
security. Furthermore, we intend to improve the resource
planning process by dealing concurrently with multiple
service requests from clients and better exploit multitenancy
features.
ACKNOWLEDGMENTS
This research is partially supported by the grant FP7-ICT-
2013-11-610795 (SPECS).
1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
R EFERENCES
[1] M. Dekker and G. Hogben, “Survey and analysis of security
parameters in cloud slas across the european public sector,” 2011.
[2] NIST, “NIST Special Publication 800-53 Revision 4: Security and
Privacy Controls for Federal Information Systems and Organiza-
tions,” 2013.
[3] Cloud Security Alliance, “Cloud Control Matrix v3.0,” https://
cloudsecurityalliance.org/download/cloud-controls-matrix-v3/.
[4] K. Bernsmed, M. G. Jaatun, P. H. Meland, and A. Undheim,
“Security SLAs for Federated Cloud Services,” in Sixth Interna-
tional Conference on Availability, Reliability and Security, ARES 2011,
Vienna, Austria, August 22-26, 2011, 2011, pp. 202–209.
[5] A. Andrieux, K. Czajkowski, A. Dan, K. Keahey, H. Ludwig,
T. Nakata, J. Pruyne, J. Rofrano, S. Tuecke, and M. Xu, “Web
Services Agreement Specification (WS-Agreement),” 2007.
[6] J. Yu and R. Buyya, “A budget constrained scheduling of workflow
applications on utility grids using genetic algorithms,” in Proc. of
1st Workshop Workflows Support Large-Scale Sci., 2006, pp. 1–10.
[7] M. A. Rodriguez and R. Buyya, “Deadline Based Resource Pro-
visioning and Scheduling Algorithm for Scientific Workflows
on Clouds,” IEEE TRANSACTIONS ON CLOUD COMPUTING,
vol. 2, no. 2, 2014.
[8] International Organization for Standardization, “ISO/IEC NP
19086-1. Information Technology–Cloud Computing – Service
Level Agreement (SLA) Framework and Technology – Part 1:
Overview and Concepts,” 2014.
[9] A. De Benedictis, M. Rak, M. Turtur, and U. Villano, “REST-based
SLA Management for Cloud Applications,” in Proc. 2015 IEEE 24th
International Conference on Enabling Technologies: Infrastructures for
Collaborative Enterprises (WETICE 2015), 2015, pp. 93–98.
[10] V. Casola, A. De Benedictis, M. Rak, and U. Villano, “Preliminary
Design of a Platform-as-a-Service to Provide Security in Cloud,”
in CLOSER 2014 - Proceedings of the 4th International Conference on
Cloud Computing and Services Science, Barcelona, Spain, April 3-5,
2014., 2014, pp. 752–757.
[11] M. Rak, N. Suri, J. Luna, D. Petcu, V. Casola, and U. Villano,
“Security as a service using an SLA-based approach via SPECS,”
in Cloud Computing Technology and Science (CloudCom), 2013 IEEE
5th International Conference on, vol. 2, 2013, pp. 1–6.
[12] V. Casola, A. Mazzeo, N. Mazzocca, and V. Vittorini, “A Policy-
Based Methodology for Security Evaluation: A Security Metric for
Public Key Infrastructures,” Journal of Computer Security, vol. 15,
no. 2, pp. 197–229, 2007.
[13] V. Casola, A. R. Fasolino, N. Mazzocca, and P. Tramontana, “A
policy-based evaluation framework for quality and security in
service oriented architectures,” in Web Services, 2007. ICWS 2007.
IEEE International Conference on. IEEE, 2007, pp. 1181–1190.
[14] A. Taha, R. Trapero, J. Luna, and N. Suri, “AHP-Based Quantita-
tive Approach for Assessing and Comparing Cloud Security,” in
The 13th IEEE International Conference on Trust, Security and Privacy
in Computing and Communications, IEEE TrustCom-14, 2014, Beijing,
China, September 24-26, 2014, 2014, pp. 391–399.
[15] S. Nelson-Smith, 2011.
[16] J. Loope, Managing Infrastructure with Puppet. ” O’Reilly Media,
Inc.”, 2011.
[17] K. Bernsmed, M. G. Jaatun, and A. Undheim, “Security in Service
Level Agreements for Cloud Computing,” in CLOSER 2011 -
Proceedings of the 1st International Conference on Cloud Computing
and Services Science, Noordwijkerhout, Netherlands, 7-9 May, 2011,
2011, pp. 636–642.
[18] E. Badidi, “A Cloud Service Broker for SLA-based SaaS Provision-
ing,” in Information Society (i-Society), 2013 International Conference
on, 2013, pp. 61–66.
[19] B. Jennings and R. Stadler, “Resource Management in Clouds:
Survey and Research Challenges,” Journal of Network and Systems
Management, pp. 1–53, 2014.
[20] N. Bonvin, T. G. Papaioannou, and K. Aberer, “Autonomic SLA-
Driven Provisioning for Cloud Applications,” in Cluster, Cloud
and Grid Computing (CCGrid), 2011 11th IEEE/ACM International
Symposium on, 2011, pp. 434–443.
[21] B. Addis, D. Ardagna, B. Panicucci, and Z. Li, “Autonomic Man-
agement of Cloud Service Centers with Availability Guarantees,”
in Cloud Computing (CLOUD), 2010 IEEE 3rd International Confer-
ence on, 2010, pp. 220–227.