Multi-cloud applications, i.e. those that are deployed over multiple independent Cloud providers, pose a number of challenges to the security-aware development and operation. Security assurance in such applications is hard due to the lack of insights of security controls applied by Cloud providers and the need of controlling the security levels of all the components and layers at a time. This paper presents the MUSA approach to Service Level Agreement (SLA)-based continuous security assurance in multi-cloud applications. The paper details the proposed model for capturing the security controls in the o ered application Security SLA and the approach to continuously monitor and asses the controls at operation phase. This new approach enables to easily align development security requirements with controls monitored at operation as well as early react at operation to any possible security incident or SLA violation.
Despite the tremendous growth in the expansion of Cloud Computing [
Copyright c 2017 by the paper's authors. Copying permitted for private and academic purposes.
The research on cloud SLAs started some years ago and a collection of
outcomes from initial EU-funded projects on the subject can be found in [
Nevertheless, several challenges for Security assurance in multi-cloud remain, like those tackled in this work. One one hand, we deal with the automatic creation of the (multi-)cloud applications' Security SLAs taking into account the SLAs of the composing components and the cloud services they use. And on the other hand we provide a solution for the continuous monitoring of such Security SLA, considering controls in all the layers involved: cloud service provider, system, network, application.
This paper presents the MUSA solution to SLA-based security assurance
for multi-cloud applications that use or have their components deployed in
distributed cloud services. The solution is based on the MUSA DevOps approach
[
The MUSA framework is a DevOps oriented solution that seamlessly integrates di erent tools to support multi-disciplinary DevOps teams in the securityaware life-cycle of (multi-)cloud applications, from application design (including its Security SLA creation) till continuous assurance at operation.
The paper is structured as follows. After the introductory section, the Section 2 describes the state of the art in security SLAs for multi-cloud based applications. The Section 3 introduces the complete MUSA work ow and framework for the security-intelligent life-cycle management of multi-cloud applications. In Section 4 we detail the proposed approach to Security SLA Assurance in multicloud, which is part of the MUSA DevOps framework. The Section 5 describes the validation of the solution in two use cases in the domains of ight scheduling prototypes and smart mobility services. Finally, the Section 6 presents the conclusions and the future work. 2
The term inter-cloud computing was de ned in [
Therefore, inter-cloud indicates the usage of cloud resources from multiple Cloud Service Providers (CSPs). These multiple CSPs can be part of a cloud federation, i.e. voluntarily collaborate to allow sharing of cloud resources between them, or they can be independent, with no need to exist an explicit collaboration agreement or interconnection among them.
In this work we focus on the security assurance of multi-cloud applications which components use or are deployed in multiple cloud services o ered by independent CSPs, which could be heterogeneous. Therefore, they pose more challenges to the design, creation and monitoring of their security SLAs because they combine services and security mechanisms from diverse and independent sources.
In order to be able to o er a holistic assurance in multi-cloud applications we need: i) mechanisms for SLA creation focused on security properties to derive composite Security SLA of applications that combine multiple clouds, and ii) mechanisms for continuous monitoring of such Security SLAs taking into account that heterogeneous controls can be applied by multiple providers at di erent layers: application, system or network. 2.1
According to ISO/IEC 20000-1 [
When it comes to cloud, a Cloud SLA is a contract framework that de nes
the terms and conditions necessary to ful l the obligations of a Cloud Service
Provider (CSP) for the service(s) o ered to a Cloud Service Consumer (CSC)
[
As de ned by NIST Security Control Framework [
The NIST Control Framework [
Other security control frameworks for cloud exist such as Cloud Security
Alliance's Cloud Control Matrix [
In our approach, we adopt the SPECS cloud Security SLA model, described
in detail in [
As it can be seen in the model, Security capability concept refers to a grouping
of security controls. Security capabilities are de ned by NIST [
The goal of Security SLA composition is to identify the security policy of each application component and the security policy of the overall application, i.e. the set of security controls that can be declared in the composite application Security SLA.
State of the art techniques of SLA composition range from ontology based [
In multi-cloud based applications, the Security SLA that can be o ered to the application customers depends on how the components are deployed, the relationships among them, the number and type of the cloud resources they use and the Security SLAs of all the individual parts.
In our solution we rely on the approach detailed in [
The SLA Template (SLAT) of the service is de ned as the document that describe the security policy implemented by a service according to its internal con guration and not taking into account the e ect of deployments. Therefore, Security SLA templates de ne the required security Service Level Objectives (SLOs) of the components in the basis of the SLOs required over the cloud services they will use.
In our approach the SLATs of the application components are obtained in a two-step process: in the rst step, a risks analysis process is performed where each threat over the component is associated to the relevant security controls that minimize the risk; in the second step, each control required by the risk analysis is assessed against the code of the component with the aid of a dedicated questionnaire. These controls are those that would like to be granted by the component and they could be: implemented by the component, required on the cloud service it uses, or requested to MUSA security agents, as explained later.
The proposed SLA composition process translates each SLATs associated to the components to a SLA. The composition is performed on a per security control basis and it assumes the controls can be independently evaluated. 3
Even if not particularly oriented to multi-cloud, there exist a number of Cloud
systems monitoring solutions such as those collected in the surveys provided in
[
Initiating the path towards security assurance, the CUMULUS project [
On security speci cs, the SPECS project [
To the best of authors' knowledge, no previous work addresses security-bydesign principles to multi-cloud application, identifying the security risks that multi-cloud applications are exposed to, expressing the security controls that can mitigate the risks in a machine-readable Security SLA, and nally, continuously monitoring the multi-cloud application composite security SLA. 4
Our approach to continuous security assurance in multi-cloud relies in
integrating a number of predictive and reactive security mechanisms in the application
life-cycle. MUSA promotes the DevOps paradigm [
The MUSA DevOps approach is enabled by the MUSA framework which supports the MUSA work ow depicted in Fig.2.
The MUSA approach aims at aiding multi-disciplinary DevOps teams in
multi-cloud application life-cycle. The work ow supported by the tools in the
MUSA framework is iterative and involves the following activities:
1. Application modelling : The initial step in the multi-cloud application design
is the speci cation of its Cloud Provider Independent Model (CPIM), a task
supported by the MUSA Modeller. The application CPIM is expressed in
a MUSA extended CAMEL language and speci es the application cloud
and security requirements in a level of abstraction independent from speci c
Cloud services and providers the application will use.
2. Continuous Risk Assessment that helps in the selection of the security
controls and metrics that will be granted in the Security SLA and controlled at
runtime. The activity follows a methodology similar to the one described in
[
In the MUSA work ow, Application modelling, Continuous Risk assessment and Cloud services selection follow an iterative loop that allows identifying whether there are any security requirements in the application that are not possible to be addressed with the security controls o ered by the cloud services available. In this case, the DevOps Team should revisit the CPIM to include protection components or specify the use of MUSA security enforcement agents that o er such missing security controls (if available).
In the following we detail the MUSA solution for Security Assurance which includes the last two steps: Continuous monitoring and enforcement. 5
Once all the components of the application have been appropriately deployed and the application is up and running, the runtime monitoring and operation of the multi-cloud application starts. The deployment scenarios may be diverse depending on application architecture, where some of the components may be deployed in cloud IaaS or may use PaaS or SaaS services. Therefore, the assurance solution in MUSA needs to be instantiated to select the right monitoring and security enforcement agents that ful l the selected deployment environment's needs. 5.1
In this section we zoom in the MUSA Security Assurance part of the MUSA work ow of Fig.2. There are two main activities included in the MUSA Security Assurance at operation that are explained in the following subsections. Continuous Monitoring The objective of this activity is to monitor the security behaviour at operation of the multi-cloud application under test, in order to early react to possible incidents and violation of the Security SLA. The subactivities are: { Extraction of metrics and thresholds from Security SLAs: After retrieving the o ered composite Security SLA registered in the MUSA Security Assurance Platform (in the Security SLA Repository of the platform), the platform will extract from it the security metrics that need to be monitored in the application components and in the cloud providers. The SLO thresholds that will apply for triggering the alerts and noti cations are also learned from the Security SLAs. { Con guration of monitoring agents: Make the needed arrangements and congurations for the MUSA monitoring agents to properly work and enable them to monitor the security metrics. { Security metrics measurement and monitoring: Take the actual values of the metrics and store them in the Measurement Repository. { Reporting and visualization of monitoring results: Show to the user the resulting values measured and the reports from the computation of the metrics. { Noti cation of security incidents: The DevOps Team can subscribe to desired alerts and noti cations. The envisaged noti cations could be mainly of two types: Security SLA violations (when it is detected that a SLOs in the Security SLA is not reached) and alerts (when it is detected that a threshold level in the SLO is not reached, i.e. before any violation in the SLO occurs).
The user will therefore need to set the threshold levels for the alerts. Adaptation and reaction The goal of this activity is adapt to security incidents detected while monitoring in order to try to ensure the Security SLA of the multi-cloud application still holds. Therefore, the activity involves the decisions on and execution of the necessary reaction measures in case potential or actual Security SLA violations are detected. The reaction mechanisms in MUSA relies depend on the cause and type of the incident as well as whether it is an alert or a violation, i.e. the SLA is about to be violated or violation has e ectively occurred already, respectively. The summary of the possible reaction measures that the DevOps Team can adopt is given below.
{ Activate a MUSA security enforcement agent : The MUSA security enforcement agents are software artefacts provided by MUSA framework that implement one or more security controls in the multi-cloud application components that use them. In those cases that the component was prepared at design time to be able to use a MUSA enforcement agent, it is possible to enable such agent at runtime. The enforcement service in the MUSA Security Assurance Platform will identify the needed MUSA enforcement agent and activate it in the component in case the incident was detected in such component and corresponds to a security control implemented by the agent. { Re-deployment of multi-cloud application : Whenever the cause of the security incident detected strives in a security control by a cloud service used by one or more of the components, the DevOps Team may need to replace the failing cloud service with some other cloud service o ering similar functionality and security controls. The DevOps Team will therefore perform a new search in the MUSA Decision Support Tool to nd a replacement service and redeploy the components that were using the failing cloud service. Most likely the rest of the components may not be a ected, but it is advisable the whole process starts from the beginning in order to make sure the new Cloud Service combination with the Cloud Service replacement still holds the multicloud application security requirements. { Re-design of multi-cloud application : In case the cause of the security incident resides in an defective or poor security performance of one or more of the constituent components and not in the Cloud Services in use, the DevOps Team may need to update the multi-cloud application design and re ne the security requirements or modify the components. This means that the DevOps Team will need to analyse the report of the causes and start the Design process again. 5.2
The MUSA Security Assurance solution ts the operation phase of the MUSA framework. The MUSA Security Assurance Platform takes as input the Security SLA of the application to monitor the multi-cloud composite application SLA as well as the individual components' SLAs referred by it. From individual SLAs, the platform knows the right security metrics to monitor in single components and from composite SLAs it is able to monitor the security of the overall application taking into account the communication exchanges between distributed components. In order to learn the list of monitoring agents deployed with each application component as well as their IP addresses, the MUSA Security Assurance Platform also requires the application deployment Implementation plan.
As shown in Fig.3, the MUSA Security Assurance Platform is composed of three main elements: { The MUSA Monitoring agents responsible for collecting the security metrics speci ed in the Security SLA and relevant events to be analysed by the centralized MUSA Security Assurance platform. { The MUSA Security enforcement agents that are deployed and/or activated in case of any security incident detection. { The MUSA Security Assurance Platform that is deployed as Software-asa-Service and allows collecting, displaying and managing all the security metrics and events from individual application components. The Platform gathers the measurements and events from the monitoring agents, checks the component Security SLAs and computes the composite metrics to check the global application Security SLA ("SLA checking" module). In case of an alert or a violation, the "security enforcement manager" is responsible for deploying, activating and con guring the local or remote security enforcement agents to mitigate the security risk. The communication with both monitoring and enforcement agents is done through the same KAFKA event bus.
In the following two subsections we present details of both the monitoring and enforcement agents.
MUSA Monitoring agents Three di erent types of monitoring agents can be
deployed in the same virtual machine or container as the application component
to compute security metrics by relying on di erent sources: Network, operating
system or application. The security metrics that can be monitored thanks to the
use of MUSA monitoring agents are those speci ed in the Security SLA of the
application which relates to the individual components' Security SLAs.
{ Network monitoring agent: This agent is responsible for analysing network
tra c from di erent network interfaces of the virtual machine or container
where the component is running. This agent facilitates network performance
monitoring and operation troubleshooting through its real-time and
historical data gathering. The agent correlates network events to detect
performance, operational and security incidents thanks to its advanced rules
engine.
{ System monitoring agent: This agent monitors operating system resources
to detect server performance degradation or performance bottlenecks early
on. The agent relies on Linux top command to monitor Linux performance.
The top command is available in many Linux/Unix-like operating systems
and is used to display all the running and active real-time processes, CPU
usage, Memory usage, Swap Memory, Cache Size, Bu er Size, Process PID,
User, among others.
{ Application monitoring agent: It monitors information about the internal
state of the target system, i.e., multi-cloud application component in which it
is deployed. It noti es the MUSA security assurance platform about
measurements of execution details and other internal conditions of the application
component. The application monitoring agent is a Java library composed by
two parts. The rst part is an aspect to be weaved into the application code
via pointcuts aimed at sending application-internal tracing information to
the MUSA Security Assurance Platform for analysis. It is composed of a set
of functions that can be weaved in strategic application points to capture
relevant internal data. The second part connects the aspect with the noti
cation tool via a connector library, providing a simple interface for sending
log data to the MUSA Security Assurance Platform in a secure way.
MUSA Security enforcement agents The security enforcement agents
offered in MUSA are security controls or mechanisms that can be easily
integrated in multi-cloud application components and activated at runtime
whenever needed to react to a violation in the Security SLA. The MUSA enforcement
agents are built on top of existing open source solutions and the major
innovation resides in having MUSA framework as single point of management for
orchestrating multiple mechanisms in an homogenized way and from the same
enforcement management dashboard. The enforcement agents can be deployed
by the MUSA Deployer just as the individual components of the application.
The MUSA Deployer interprets the application design model in MUSA extended
CAMEL to learn the agents deployment con guration and execute it. Below we
present two of the enforcement agents provided in the MUSA framework.
{ The high availability (HA) framework : The HA framework is a collection
of open-source software built around the Corosync/Pacemaker stack [
The DevOps Teams in both case studies followed the di erent steps of MUSA work ow to design the composite application, create its composite SLA and monitor it at runtime. In the process, individual SLA templates were created with the SLA Generator and Cloud service providers selected using the DST tool. After the application deployment planning and the computation of the composite application SLA, the application was deployed successfully using the MUSA Deployer tool and continuous monitoring and reaction was performed. In both use case scenarios, the MUSA monitoring agents described in section 5.2 were deployed to retrieve the security metrics speci ed in the applications' Security SLAs. For some of the components MUSA enforcement agents described in section 5.2 were deployed as well.
For instance, for the smart mobility service, one of the main application
components is called TSM Engine which is a Web service responsible for retrieving
diverse information (location, weather, paths, energy etc.) from the other
components. After the risk analysis step, the Security SLA speci ed the following
security controls (partial list), expressed according to the NIST Control
Framework [
And the following security metrics (partial list) where included in the Security SLA related to the security controls, as shown in Fig.4: { Availability { Vulnerability Measure { Risk Assessment Vulnerability Measure { M13-Scanning Frequency - Basic Scan { M22-Scanning Frequency - Extended Scan { M23-Up Report Frequency { Resilience to attacks { etc.
The continuous monitoring of the security metrics in the Security SLA allowed detecting potential malicious activities based on a set of detection rules denoting several kinds of attack signatures. For example, to evaluate the e ciency in availability, we stopped the Tomcat server where the TSM engine was running which caused the application availability rate (SLO more than 99%) stated in the Security SLA was not respected. The incident was detected by the MUSA monitoring agent and noti ed to the MUSA Security Assurance Platform that raised immediately a violation alarm to the DevOps Team together with the recommendation to restart the Tomcat server and to ensure server redundancy. The DevOps Team followed the advice and used the High availability framework MUSA enforcement agent to ensure server redundancy, which helped to recover from the incident. Additional monitoring and reaction strategies provided by the solution for incidents on identity thefts, unauthorized access control threats, etc. were evaluated successfully. 7
Multi-cloud applications pose a great challenge to security assurance due to they have to tackle the security of the individual components as well as the overall application security, which in turn depends on the security controls provided by the cloud services in use. Despite the cloud service providers o er their own security controls, the multi-cloud application has to ensure integrated security across the whole composition.
The MUSA DevOps framework has been conceived and prototype created to address such challenge. It supports the security-aware design and operation of multi-cloud applications and integrates security-by-design mechanisms with continuous security assurance. The later is o ered in form of a Software-as-aService solution named MUSA Security Assurance Platform.
The MUSA Security SLA-based assurance advances over the state of the art in security-aware cloud SLAs, which foster clarity and transparency in cloud service provisioning. The application composite Security SLA can be computed and expressed in machine-readable format, relying on standard security control families like those of NIST and Cloud Security Alliance.
The MUSA Security Assurance platform enables cloud transparency by being able to monitor security metrics in the Security SLA, and by keeping informed multi-cloud application consumers on the real-time behaviour of both the components and the cloud services underneath. Non-compliance with respect to security level objectives in the Security SLAs of the used CSPs and the application are early detected and reaction measures activated for prompt mitigation of the risks. As a result, the presented approach enables multi-cloud applications be secure and self-adaptive.
The initial evaluation of MUSA security assurance approach in two real case studies showed that the proposed methods and tools reduce the security aws in the application implementation and are e ective in ensuring the multi-cloud application complies with its composite Security SLA. Further evaluation rounds of the MUSA framework are planned in the next months within the two case studies presented above in order to assess the e ectiveness and usability of the framework tools, particularly in the support to an integrated and multi-disciplinary DevOps approach to enhance security in multi-cloud applications and rise consumers' trust in cloud-based environments.
The MUSA project leading to this paper has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 644429. We would also like to acknowledge all the members of the MUSA Consortium for their valuable help.