MUSA – a multi-cloud security framework that supports the DevOps approach

The development of multi-cloud applications composed of components deployed over infrastructures that are provided by different and independent Cloud Service Providers (CSPs) is a challenging task, particularly when security requirements play a major role, because at the state of the art, existing development environments hardly support their definition, monitoring and enforcement.

The MUSA project sets out to develop an integrated toolchain that provides exactly these missing features, while supporting a DevOps approach.

The set of tools that are being developed in MUSA will support the Design, Deployment and Runtime phases of the generic multi-cloud application lifecycle, illustrated in Figure 1.

Generic multi-cloud application lifecycle

Figure 1: Generic multi-cloud application lifecycle

The projected tools include:

  • the MUSA IDE Modeller, that allows the specification of the multi-cloud architecture and requirements,
  • the MUSA SLA Generator, that enables the creation of the corresponding Service Level Agreement (SLA),
  • the MUSA Decision Support Tool (DST), that supports the selection of the Cloud service offerings to use for the components,
  • the MUSA Deployer, for provisioning the needed cloud resources and deploying the application components and the needed MUSA agents, and
  • the MUSA Security Assurance Platform (SAP), for controlling the security features of the multi-cloud application in operation,

which are complemented by a set of MUSA Security Agents, responsible for monitoring and enforcing the security requirements of a multi-cloud application in deployment scenarios that lack according monitoring and enforcement mechanisms.

In the multi-cloud application design phase, the MUSA IDE Modeller is used for defining the application components and their interfaces, as well as their security requirements, in a Cloud Platform Independent Model (CPIM), following the Model Driven Architecture/Development (MDA/MDD) approach. The design activity includes the lookup of available Cloud service types (IaaS, PaaS, SaaS, DBaaS, etc.) and the specification of particular Cloud requirements, like the number of cores, RAM, etc. for each component.

The next step consists of defining the security requirements by performing an initial risk analysis on the defined assets from both business-oriented and technically oriented viewpoints. For each asset, the risks, their acceptable thresholds and mitigation actions are defined. In the following step, with the help of the MUSA SLA Generator, this information is converted into machine readable Service Level Agreements (SLAs) (i.e. security SLA). The feasibility of these SLAs is then evaluated by matching them with the discovered existing Cloud service offerings, which allows identifying missing security controls that might have to be provided, for instance, by specific MUSA security enforcement agents. The last activity in the design phase is the creation of the composite security SLA for the entire multi-cloud application which includes all the security requirements for both the individual components and their communications.

Once all application components are available, either as external services or as released executable versions (e.g. in a repository), the deployment of the respective multi-cloud application can be kicked off with the support of the MUSA DST, SLA Generator and Deployer. The MUSA DST will verify if there exists at least one combination among the identified Cloud services that fits the requirements stated in the security SLAs and CPIM. The result of this verification may require adapting certain security SLAs, by moving back to the design phase. Based on the MUSA DST identification and ranking of adequate and suitable Cloud service combinations, the DevOps team will then make their final choice on which Cloud services to use for each component. The SLA Generator will then be used to create the individual and composite SLAs of the offered application services, which are input for specifying the Cloud Provider Specific Model (CPSM) that contains the provider specific instantiation of the features and requirements defined in the CPIM. The MUSA Deployer finally interprets the information provided by the CPSM and security SLAs and generates the deployment script that contains all the needed information and instructions to perform the deployment of the multi-cloud application components and MUSA security agents and to set up and provision the Cloud services to be used.

The runtime phase is supported through the MUSA Security Assurance Platform (SAP), which provides functions for subscribing to desired threshold alerts and notifications of multi-cloud application SLA violations. The goal of the MUSA SAP is to enable monitoring the security behaviour of the multi-cloud application and their components at runtime, in order to be able to detect and react upon possible security incidents as early as possible. The actions to be carried out in case of a detected security incident depend on the decisions of the DevOps team and may imply the activation of a MUSA enforcement agent, the re-deployment of (parts of) the application, or the re-design of the multi-cloud application or their components.

The described MUSA tool-chain is expected to be integrated in a web-based Kanban view that allows for the seamless collaboration of the DevOps team members and the transparent interaction of the different tools when shifting between multi-cloud application lifecycle phases as illustrated in the following figures (note: the figures only represent a possible approach):

MUSA Dashboard style


MUSA Dashboard style


MUSA Dashboard style

Author: Stefan Schuster, IT Competitiveness Area, TECNALIA, Spain (

Share this post