Massimiliano Rak, Valentina Casola and Umberto Villano, CERICT scarl, 19.10.2017
Cloud security is still considered one of the main inhibitors for the adoption of cloud-based solutions in many environments. The perception of lack of security is given by the loss of control that a cloud service customer (CSC) has over the cloud services: What exactly are the security measures adopted by the cloud service provider (CSP)? How to verify the effective enforcement of the security policies declared by CSPs?
The European Union Agency for Network and Information Security (ENISA)1 outlined in  that the main way to address this issue are Security Service Level Agreements (Security SLAs), i.e. agreements among providers and customers that state the level of security granted on the services delivered. CSPs declare their security policies and a set of Service Level Objectives (SLOs) in terms of thresholds on well defined security metrics.
Even if at state of art CSPs still do not offer Security SLAs, EU Projects like SPECS, SLA Ready and SLALOM proposed innovative models to represent in a standard way the security policies, expressed in terms of standard security controls, and to measure and quantify such security features. In addition to these models, tools like the CSA STAR registry2 and Cloud 28+3 are now available; they collect the information needed to evaluate a CSP security policy according to their security self-assessment declarations.
Security SLAs, however, do not completely solve the security issues for a cloud application: Security SLAs describe the security policies that a CSP is able to enforce, but not what is actually granted by a specific cloud service. As a simple example, let’s consider an SLA offered by a CSP (like Amazon or Google), that states the adoption of certain security policy. Even if this offers some assurance, little can be said about the level of security of the specific virtual machine that a CSC acquires. Saying it in another way, security policies address the provider internal security organization, not the security of the VMs operating system. This is exacerbated in the case of complex supply chains: consider, as an example, a CSC that acquires a software-as-a-service from a CSP which, in turn, acquires its infrastructure in cloud from another CSP: what exactly can be granted to the final end user?
Assuming that a (multi-)cloud application is an application made of multiple components deployed over resources acquired in the cloud, the above described problems can be summarized in the evaluation of the Security SLA that such an application is able to guarantee, taking into account all the composing services and their mutual relations. The MUSA SLA Composition tool implements an innovative technique that builds a security SLA that can be granted by a cloud application, by knowing the security SLAs of the CSPs offering application components/services and how such services are connected. The goal of Security SLA composition is to identify the security SLA of each of the services that compose the application and the security SLA associated to the whole application, these will contain the set of security controls that can be declared as correctly implemented. The SLA composition technique relies on graph-based models that represent the main features of the SLAs and of the multi-cloud application. The proposed technique combines the security policies (named SLATs in the Figure) of each component of the application with the SLAs of the CSPs that host the services, by applying composition rules to security controls, based on the relationships existing among components and providers.
The following figure graphically illustrates the output expected from the SLA Composition process for a simple deployment configuration made of a Virtual Machine, hosting an application server and a DB server with different security controls reported in the security policies, denominated SLATs. The final application graph specifies what are the actual security policies (i.e., the SLAs) that are enforced by each component in the actual physical deployment.
Figure 1. Illustration of the output expected from SLA Composition process
Details on the technique are reported in  where information available in the context of the MUSA project were used to demonstrate how MUSA tools enable to concretely deploy a secure multi-cloud application and monitor its security SLA.
The current implementation of the tool is mainly based on a subset of security controls from the NIST security control framework but we are planning to extend it to the full set of controls (including those specific for the privacy). Also, we are planning to extend it with more composition rules and to other security frameworks as, for example, the ones proposed by the Cloud Security Alliance in order to get already structured information from the cloud providers.
 Survey and analysis of security parameters in cloud SLAs across the European public sector [Deliverable 2011-12-19].
 M. Rak, Security assurance of (multi-)cloud application with security SLA composition, Lecture Notes in Computer Science 10232 LNCS (2017) pp. 786 – 799.
1 ENISA is a centre of expertise for cyber security in Europe, https://www.enisa.europa.eu/