MUlti-cloud Secure Applications › sites › musa3.drupal.pulsartecnalia.co… · D2.4: Final MUSA...

MUlti-cloud Secure Applications

Deliverable title Deliverable ID:

Final MUSA IDE for security-aware

design of multi-cloud applications

D2.4

Preparation date:

31/10/2017

Editor/Lead beneficiary (name/partner):

Maria Carmen Palacios, Gorka

Echevarría / Tecnalia

Internally reviewed by (name/partner):

Oscar Ripollés / CA

Balázs Somosköi / LHS

Abstract:

This deliverable presents the final version of the MUSA Modeller solution which supports the

modelling of multi-cloud applications taking into account their security concerns. The MUSA Modeller

enables: (a) the multi-cloud secure application components design and (b) declaring MUSA security

agents to use with the application components. The document is the technical report that accompanies

the final software prototype of the MUSA Modeller that has been designed and developed following

the architecture and implementation described herein. Note that the final version of the MUSA

Dashboard for the integrated MUSA Framework is described in deliverable D1.4 Final MUSA

framework specification and guide, and the final version of the SLA Generator that supports the

Security SLA specification and composition is described in deliverable D2.3 Final SbD methods for

multi-cloud applications.

Dissemination level

PU Public X

CO Confidential, only for members of the consortium and the Commission Services

D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 2

MUSA consortium

Fundación Tecnalia Research &

Innovation

(TECNALIA, Spain)

www.tecnalia.com/en

Project manager: Erkuden Rios

[email protected]

+34 664 100 348

Centro Regionale Information e

Communication Technology

(CER ICT, Italy)

Contact: Massimiliano Rak

[email protected]

CA Technologies Development Spain

SAU (CA, Spain)

Contact: Victor Muntés

[email protected]

Montimage

(MI, France)

Contact: Edgardo Montes de Oca

edgardo.montesdeoca@montima

ge.com

AIMES Grid Services

(AIMES, UK)

Contact: Prof Dennis Kehoe

[email protected]

Lufthansa Systems GmbH & Co KG

(LHS, Germany)

Contact: Dirk Muthig

[email protected]

TTY-säätiö

(TUT, Finland)

Contact: José Luis Martínez

Lastra

[email protected]

http://www.tecnalia.com/en

mailto:[email protected]









Table of contents

MUSA consortium .................................................................................................................................. 2 Table of contents ..................................................................................................................................... 3 List of figures .......................................................................................................................................... 4 List of tables ............................................................................................................................................ 5 Executive summary ................................................................................................................................. 6 1 Introduction ..................................................................................................................................... 7

1.1 Objective of this document .................................................................................................... 7 1.2 Structure of this document ..................................................................................................... 7 1.3 Relationships with other deliverables .................................................................................... 7 1.4 Contributors ........................................................................................................................... 8 1.5 Acronyms and abbreviations .................................................................................................. 8 1.6 Revision history ..................................................................................................................... 8

2 Overview of revisions and additions since D2.2 ........................................................................... 10 3 MUSA requirements for security-aware design of multi-cloud applications ................................ 11 4 The MUSA modelling language for multi-cloud applications ...................................................... 15

4.1 Innovations for security behaviour specification ................................................................. 17 4.2 Innovations for multi-cloud deployment .............................................................................. 18 4.3 Innovations for self-healing capability of multi-cloud applications .................................... 20

5 MUSA Modeller Architecture ....................................................................................................... 21 5.1 Objective and overview ....................................................................................................... 21 5.2 Component model ................................................................................................................ 21

5.2.1 Web Component .............................................................................................................. 22 5.2.2 Server Component ........................................................................................................... 23 5.2.3 Database Component ....................................................................................................... 24

5.3 Data model ........................................................................................................................... 28

5.4 Collaboration model ............................................................................................................. 30 5.5 Interface specification .......................................................................................................... 37

5.5.1 Creation of a new multi-cloud application specification model ...................................... 37 5.5.2 Modification of a multi-cloud application specification model ....................................... 37 5.5.3 Recovery of a multi-cloud application specification model ............................................ 38 5.5.4 Recovery of the MACM format of a multi-cloud application specification model given

application identifier ...................................................................................................................... 38 5.5.5 Update of a multi-cloud application specification model with elements related to a security

agent 39 5.5.6 Recovery of the validation errors after parsing the multi-cloud application specification

model 40

6 MUSA Modeller final implementation ......................................................................................... 41 6.1 Prerequisites and installation ............................................................................................... 41

6.2 Usage guide .......................................................................................................................... 41 6.2.1 Model validation - Warnings and error messages ........................................................... 42

6.3 Source code repository ......................................................................................................... 43 7 Innovation ...................................................................................................................................... 44 8 Conclusion ..................................................................................................................................... 45 References ............................................................................................................................................. 46 Appendix A. MUSA motivation and background ................................................................................. 48 Appendix B. CAMEL meta-model extensions in MUSA ..................................................................... 49 Appendix C. Example of TSM application CPIM ................................................................................ 52


List of figures

Figure 1. MUSA Security DSL ............................................................................................................. 16 Figure 2. MUSA overall workflow ....................................................................................................... 21 Figure 3. MUSA Modeller architecture overview ................................................................................. 22

Figure 4. MUSA Modeller Web Component ........................................................................................ 23 Figure 5. MUSA Modeller Server Component. .................................................................................... 24 Figure 6. Configuration file on which the mapping is established. ....................................................... 26 Figure 7. Configuration file on which the database access is set. ......................................................... 27 Figure 8. MUSA Modeller Database Component ................................................................................. 27 Figure 9. MUSA IDE Editor mu_mcapp table definition ..................................................................... 28 Figure 10. MUSA IDE Editor mu_controls table definition ................................................................. 28 Figure 11. MUSA IDE Editor mu_agents table definition .................................................................... 29 Figure 12. MUSA IDE Editor mu_apps_components_agents table definition ..................................... 29 Figure 13. MUSA IDE Editor mu_app_component table definition ..................................................... 30

Figure 14. MUSA IDE Editor mu_security_capabilities table definition ............................................. 30 Figure 15. MUSA Modeller sequence diagram for creating a new multi-cloud application model. ..... 32 Figure 16. MUSA Modeller sequence diagram for updating a multi-cloud application model. ........... 33 Figure 17. MUSA Modeller sequence diagram for recovering a multi-cloud application model. ........ 34 Figure 18. MUSA Modeller sequence diagram for recovering a MACM model .................................. 35 Figure 19. MUSA Modeller sequence diagram for adding a MUSA Security Enforcement agent to a

multi-cloud application model ............................................................................................................... 36 Figure 20. Modeller GUI ....................................................................................................................... 41 Figure 21. Modeller checking for syntax correctness and integrity while editing ................................ 42 Figure 22. Modeller support the selection of MUSA Security enforcement agents .............................. 42

Figure 23. Validation report of a multi-cloud application model .......................................................... 43


List of tables

Table 1. Overview of updates since D2.2.............................................................................................. 10 Table 2. Requirements for the MUSA Modeller and coverage in final prototype ................................ 11 Table 3. Interface specification for creating a new multi-cloud application specification model ......... 37

Table 4. Interface specification for updating a multi-cloud application specification model ............... 37 Table 5. Interface specification for recovering a multi-cloud application specification model ............ 38 Table 6. Interface specification for recovery of the MACM format of a multi-cloud application

specification model................................................................................................................................ 38 Table 7. Interface specification for updating a multi-cloud application specification model with elements

related to a security agent ...................................................................................................................... 39 Table 8. Interface specification for recovering the validation errors after parsing the multi-cloud

application specification model ............................................................................................................. 40 Table 9. Overview of MUSA extended CloudML features .................................................................. 44


Executive summary

This deliverable presents the final version of the MUSA Integrated Development Environment (IDE)

for the security-aware design of multi-cloud applications. The MUSA IDE is composed of the MUSA

Modeller, the MUSA SLA Generator and their accompanying repositories, and is named Key Result

KR1 of MUSA project. Nevertheless, the MUSA SLA Generator that supports the SLA specification

and composition of security requirements is described in deliverable D2.3 Final SbD methods for multi-

cloud applications.

Therefore, this document describes the MUSA Modeller only, which supports the modelling of multi-

cloud applications taking into account their security concerns. The MUSA Modeller enables: (a) the

multi-cloud secure application components design and (b) declaring MUSA security agents to use with

the application components.

The document is the technical report that accompanies the final software prototype of the MUSA

Modeller that has been designed and developed following the architecture and implementation described

herein. The software is publicly available in MUSA bitbucket here:

https://bitbucket.org/account/user/musateam/projects/MUSA.

This final version of the prototype supersedes the initial version description included in previous

deliverable D2.2 Initial MUSA IDE for security-aware design of multi-cloud applications and includes

improvements done addressing initial evaluation feedback. Please note that the state-of-the-art in multi-

cloud modelling languages and the rationale for CAMEL selection as MUSA baseline, both provided in

deliverable D2.2, are not repeated in this document.

It is important to note that the final version of the MUSA Dashboard for the integrated framework is

described in deliverable D1.4 Final MUSA framework specification and guide, which includes the

architectural specification of the integrated framework.

https://bitbucket.org/account/user/musateam/projects/MUSA


1 Introduction

1.1 Objective of this document

This document is the deliverable D2.4 Final MUSA IDE for security-aware design of multi-cloud

applications of MUSA project [1] (see Appendix A).

In order to address the project Objective SO2, the aim of this document is to describe the final version

of the methods for security-aware analysis and design of multi-cloud applications along with the tool

developed to support them. Although the MUSA IDE is composed of the SLA Generator along with the

Modeller tools, this document focuses only on the latter, i.e. the MUSA Modeller, which supports the

edition of the multi-cloud application models. Therefore, the document does not include the

specification of the final MUSA SLA Generator for the Service Level Agreement (SLA) creation and

composition which is described in deliverable D2.3 Final SbD methods for multi-cloud applications.

The modelling process starts with the analysis of the multi-cloud application and the specification of its

components together with their deployment and security requirements. Following the MUSA approach

described in D1.4 Final MUSA framework implementation, the DevOps Team will optionally use the

MUSA Modeller to specify also the MUSA security enforcement agents to use in order to assure a

number of security properties along the application lifecycle.

As other MUSA tools in the framework, this tool can be accessed from the MUSA framework

Dashboard (Kanban board like dashboard) that integrates the usage of the individual tools, for which a

detailed description is provided in deliverable D1.4.

1.2 Structure of this document

After this introductory section, the document is structured as follows:

• Section 2 provides an overview of the revisions and additions of this final version of the MUSA

IDE Modeller deliverable compared to the previous version.

• Section 3 presents the requirements related to the multi-cloud application modelling and

requirements specification activity among those presented in Deliverable D1.4, and discusses

their coverage by the final MUSA Modeller prototype application.

• Section 4 specifies the MUSA modelling language developed on top of CAMEL Domain

Specific Language for multi-cloud applications.

• Section 5 describes the architectural design of the final MUSA Modeller.

• Section 6 provides details on the final MUSA Modeller prototype implementation.

• Section 7 summarizes the main innovation brought by MUSA mechanisms and tools on multi-

cloud modelling.

• Section 8 concludes the document by summarising the contents of the document and the main

features and innovation in the MUSA Modeller.

• The Appendix A contextualizes the document by describing the MUSA motivation and

background.

• The Appendix B depicts the extensions to CAMEL developed in MUSA.

• Finally, Appendix C illustrates the meta-model through an example of the CPIM generated for

the Tampere Smart Mobility (TSM) application in Case Study B of MUSA.

1.3 Relationships with other deliverables

The D2.4 presented in this document relates to the following deliverables:


• D2.2 Initial MUSA IDE for security-aware design of multi-cloud applications, which detailed the

initial version of the MUSA Modeller presented herein. This document supersedes D2.2 because it

extends the previous version to describe all the innovations offered by the final MUSA modelling

language and the Modeller tool.

• D2.3 Final SbD methods for multi-cloud applications, which describes the final mechanisms and

tools that MUSA offers to define the security constraints of a multi-cloud application, in order to

support a security-by-design development process, focusing on the SLA Generation. The document

includes a detailed description of the final MUSA SLA Generator.

• D1.4 Final MUSA framework specification and guide, which details the final MUSA integrated

framework architecture, explaining also the final MUSA Dashboard tool. The document describes

how the MUSA Modeller fits in the complete MUSA architecture and how it relates to other MUSA

tools.

1.4 Contributors

The following partners have contributed to this deliverable:

• Tecnalia

• CERICT

• Montimage

1.5 Acronyms and abbreviations

API Application Programming Interface DST Decision Support Tool

CAMEL Cloud Application Modelling and

Execution Language

IDE Integrated Development Environment

CloudML Cloud Modelling Language QoS Quality of Service

CPIM Cloud Provider Independent Model SLA Service Level Agreement

CPSM Cloud Provider-Specific Model UML Unified Modelling Language

CSP Cloud Service Provider URL Uniform Resource Locator

DSL Domain-Specific Language VM Virtual Machine

1.6 Revision history

Version Date issued Author Organisation Description

1.0 11/09/2017 Maria Carmen

Palacios

Tecnalia TOC and initial draft.


Palacios

Tecnalia Intermediate proposed


Palacios

Tecnalia Final proposed with all sections

ready.

4.0 23/10/2017 Valentina Casola CERICT Version reviewed by CERICT

4.1 26/10/2017 Oscar Ripollés CA Version reviewed by CA


Version Date issued Author Organisation Description

4.2 27/10/2017 Balázs Somosköi LHS Version reviewed by LHS

5.0 30/10/2017 Erkuden Rios Tecnalia Revised version

6.0 31/10/2017 Erkuden Rios Tecnalia Final release


2 Overview of revisions and additions since D2.2

In this section, we provide the summary of the updates and additions included in this document, the final

MUSA IDE Modeller description, compared to the description of the initial version (deliverable D2.2

Initial MUSA IDE for security-aware design of multi-cloud applications). Please note that the state-of-

the-art in multi-cloud modelling languages provided in deliverable D2.2 (Section 3) and the rationale

for CAMEL selection as MUSA baseline (D2.2 Section 4) are not repeated in this document.

Table 1. Overview of updates since D2.2

Change Section in

D2.2

Section in

D2.4

Rationale

Updated of coverage of

requirements.

Section 2 Section 3 Updates in Final version compared to

Initial version of prototype.

Innovations for security

behaviour.

N/A Section 4.1 The section reflects all innovations in

the final modelling language.

Innovations for multi-cloud

deployment.



Innovations for self-healing

capability.



No change of high level

architecture.

Section 5.1 &

5.2

Section 5.1 &

5.2

High level architecture description left

in this document for the sake of

understandability of the document.

Changes in data model. Section 5.3 Section 5.3 Data model of final version described.

Changes in collaboration

model.

Section 5.4 Section 5.4 Collaboration model of final version

described.

Changes in prototype

interfaces.

Section 5.5 Section 5.5 Interfaces of final version described.

Changes to describe final

prototype usage.

Section 6 Section 6 Final implementation user manual and

pre-requisites described.

Changes in innovations of

the modelling language and

the supporting tool.

Section 7 Section 7 All the innovations offered by the final

version of the modelling language

formalisms and the tool prototype are

summarised.


3 MUSA requirements for security-aware design of multi-cloud

applications

This section reports on the coverage of requirements elicited in the context of WP1 and described in

section 4 of MUSA deliverable D1.4 Final MUSA framework specification and guide [2]. In particular,

the considered requirements refer to MUSA Modeller that is the part of the MUSA IDE that supports

the creation of the multi-cloud application specification model. In addition to identifying its functional

and security requirements, the DevOps Team will optionally use the MUSA Modeller to specify also

the MUSA security enforcement agents to use in order to assure a number of security properties along

the application lifecycle.

In the following, we review the coverage of the requirements related to the MUSA Modeller by the final

version of the prototype. Therefore, Table 2 summarizes how the Modeller addresses the MUSA

requirements that are relevant to the modelling phase in MUSA.

Table 2. Requirements for the MUSA Modeller and coverage in final prototype

ReqID Title Description Prio

rity

Coverage status

in final prototype

S1.2-R2 Selection of security

controls provided by

the cloud service (by

the CSP)

The MUSA framework should provide

technical information regarding the

security controls offered by the cloud

services (by the CSPs) in the market, in

order they can be selected for the

application components to use them.

1 The initial

prototype allows

specifying the

security controls

required in the

components.

S1.4-R1 Multi-cloud app

modelling tool

The MUSA Framework should provide

a tool that support application architects

in the modelling of multi-cloud

applications.

1 The prototype

allows for

modelling multi-

cloud applications

in an enriched

version of

CAMEL

language.

S1.4-R2 Multi-cloud app

properties defining

tool


a tool that support application architects

in the definition of functional and

security properties of multi-cloud

applications.

1 The enriched

CAMEL used

allows for

specifying

deployment and

security

requirements.

S1.4-R3 Tool for defining the

requirements of the

cloud services


a tool that enables application architects

to model functional and security

requirements of the cloud services

where the multi-cloud application will

be deployed.

1 This part is

covered in MUSA

by MUSA SLA

Generator [3].

S2.1-R1 Support modelling of

multi-cloud

applications


a tool to support application architects

in the modelling of multi-cloud

applications, in order to identify their

architecture and deployment.

1 The enriched

CAMEL used

allows for

specifying

deployment and



rity

Coverage status

in final prototype

security

requirements.

S2.1-R2 Support defining

multi-facet

requirements


a tool that supports application

architects in the definition of

application security, functional and

business requirements. The tool should

enable the architect to specify complex

requirements related to the usage of the

cloud resources belonging to different

providers.

1 Partially covered

in the prototype,

the specification

of business

requirements is

missing.

S2.3.1-

R2

Coherent Interfaces

for user interaction


a mechanism that allows the user

defining security and functional

requirements of cloud resources to use.

1 The prototype

offers a web GUI

for the users to

create the multi-

cloud application

models. The tool

is also integrated

with the MUSA

Dashboard.

S5.1-R1 Information

Governance/ Best

Practice

accreditations –

Specification

The MUSA Framework should allow

for specifying the need of particular

security accreditations of CSP's (define

it in multi-cloud application

SLA/model through MUSA IDE and

then MUSA DST interprets and selects

cloud resources according to this).

Examples include but are not limited to

IS027001, EuCoC, Uptime Institute

Tier rating

2 This part is

covered in MUSA

by MUSA SLA

Generator [3].

S5.2-R1 The MUSA

framework should

support application

developer to specify

the country/region

where the data should

reside.

The MUSA framework should support

application developer in specifying the

country/region where the data should

reside.

1 The prototype

allows for

specifying the

location

requirement for

deployment.

S5.2-R2 The MUSA

framework should

support application

developer to specify

national security and

information

governance

requirements.


application developer in specifying

national security and information

governance requirements.

3 Not in MUSA

project lifetime.



rity

Coverage status

in final prototype

S5.3-R1 Geo Redundant

Storage –

Specification



need of geo redundant storage (in

MUSA IDE and DST interprets)

3 Not in MUSA

project lifetime.

S5.3-R4 CSP Resilience levels

- Specification

The MUSA Framework should support


levels of resilience (up-time, overhead

in VPN compatibility) required from

the CSPs.

2 Not in MUSA

project lifetime.

S5.4-R1 Cloud setting type –

Specification

The MUSA Framework should allow

application developer specifying the

type of cloud setting (hybrid, public,

private, community) required for the

multi-cloud application.

3 Not in MUSA

project lifetime.

S5.4-R2 Cloud bursting –

Specification



hybrid cloud for bursting functionality

under scalability settings of multi-cloud

application.

2 Not in MUSA

project lifetime,

though CAMEL is

prepared for

specifying

scalability

requirements.

S5.5-R1 Geolocation of

component –

Specification



country/region where the application

component should be executed/reside.

1 The prototype

allows for

specifying the

location

requirement for

deployment.

S6.1-R3 Language for the

specification of

security properties in

app model

The MUSA framework provides a

modelling language which will be used

to define the multi-cloud application

security requirements. (App

architecture modelling language).

1 The enriched

CAMEL used

allows for

specifying

deployment and

security

requirements.

S6.2-R1 Extract/process

security requirements

from components

The MUSA framework provides

functionality to assist developer to

specify security requirements for

existing application components. This

can be the MUSA security definition

language source or a pre-compiled

version. Source can be file, http, git, jar

etc.

3 Not in MUSA

project lifetime.

In summary, the following requirements that were initially specified for the security-aware multi-cloud

application modelling language and supporting tool in MUSA were finally addressed in the project:

• The language should follow a component-based approach. Therefore, it is required to capture

components, their capabilities as well as component dependencies (such as, the relationships

of communication between components) in models in order to be possible to reason, for


instance, through effective multi-cloud deployment or security status monitoring. This

requirement is fully completed.

• In order to fully support multi-cloud provisioning, it is required to gather cloud infrastructure

descriptions through the modelling of the types of resources exposed by these infrastructures

and required by the multi-cloud application or its components. The final language fulfils this

requirement and includes even concepts for deployments using containers and PaaS elements.

• The language should support security requirement concept. Users require expressing security

properties and requirements in multi-cloud applications and their components. In a sustainable

partnership, the parties involved should agree on the minimum level of service quality (with

regard to system availability and speed) that is to be observed. In practice, however, the issue

of quality is frequently left open in the service level agreement. In addition to the quality of

service, the varied aspects of data protection and data security are also extremely important for

the cloud consumer when drawing up a full and complete agreement. The tool enables to

specify both security requirements and security properties (in form of security controls)

required and provided by the components of the multi-cloud application. Thus, the requirement

is successfully addressed by the prototype.

• The language should support security control concept. Users need to identify the security

controls required to guarantee security requirements are respected. A security control can be

defined as a safeguard or a countermeasure prescribed to protect a system and meet a set of

defined security requirement. The extended language not only allows for defining the required

controls but also the provided controls in those cases when the component is a security

mechanism itself. This is the case of MUSA Security Enforcement agents that are considered

security mechanisms providing certain security controls which are defined in the model in order

they can be considered in the following Risk Analysis step and SLA Generation step in MUSA

framework.

• The language should allow declarative expression of complex deployment requirements such

as formal, detailed resource requirements (e.g., resilience, bursting or geolocation). Location

specification was allowed already in CAMEL and is kept in MUSA. Addressing performance

requirements in the application life-cycle was not the main focus of MUSA, but security

requirements. Therefore, the prototype does not address the performance related requirements

because the functionality of the rest of the tools in the framework was also focused in security

requirements.

• The tool should help users to automatize the multi-cloud application lifecycle as much as

possible. Managing the lifecycle of applications is still a tedious task and what is worse the

speed at which applications change in the cloud affects their security. Therefore, it is vital to

allow users to explicitly define these processes. The tool has fully achieved this requirement as

it enables the creation of the application model that is the basis for the plan of automatic

deployment in MUSA and it also automates the generation of the Multi-cloud Application

Composition Model (MACM) (required for the automatic generation of the security Service

Level Agreement) and automates the specification in the model of the MUSA Security

Enforcement Agents in case the user decides to use them.

• The tool should be tightly integrated with the other tools in the framework for a seamless

management the multi-cloud application lifecycle, so the DevOps teams can work efficiently

and following agile practices. As it is explained in deliverable D1.4, this requirement is

successfully addressed in the Modeller prototype and in all tools in the framework, because all

the tools work smoothly together to support the security in multi-cloud applications through

the usage of a framework Dashboard.


4 The MUSA modelling language for multi-cloud applications

As explained in deliverable D2.2, the MUSA Security Domain Specific Language (DSL) builds on top

of the CAMEL language and the main contributions are related to its expressiveness to define and

configure secure multi-cloud applications at design-time. Such a powerful definition can be used later

on by other MUSA tools to perform the risk analysis and to generate the individual components’ security

Service Level Agreement (SLA) templates and the application Composite Security SLA. Furthermore,

this allows deploying and monitoring the security properties of multi-cloud applications and its

components at run-time.

The state-of-the-art in multi-cloud application security modelling and rationale for CAMEL language

selection was already described in previous D2.2. In summary, CAMEL was selected as the baseline in

MUSA due to it is a powerful language that already addressed multi-cloud deployment specification and

included some security requirements specification features, easily extensible in MUSA

The MUSA Security DSL extends CAMEL as shown in Figure 1. In the following subsections we detail

the innovations brought by MUSA extensions.


Figure 1. MUSA Security DSL


4.1 Innovations for security behaviour specification

The MUSA innovations to CAMEL language include the enhanced component security behaviour

characterization, which addresses concepts required to support both composition of components’

security Service Level Agreements (SLAs) and risk analysis. They are described in the following:

• Classification of components by their nature which allows describing what the component

does. This information is required by the MUSA SLA Generator to create the Composite

Security SLA of the multi-cloud application from individual components’ SLAs and by the

MUSA Risk Analysis tool in order to identify the security threats and risks at component level.

Our CAMEL extension allows specifying the type of the component; in fact, the component can

be classified by two features: WHAT and HOW. While WHAT indicates the type of the

functionality delivered by the component, HOW indicates the way the component is delivering

such functionality.

Currently, three types of HOW have been defined:

a. COTS, which refers to Commercial of-the-shelf software that the application uses.

b. SERVICE, meaning that the component is not a commercial package but developed by

the DevOps Team responsible for the multi-cloud application engineering.

c. AGENT, i.e. a MUSA Agent component provided by the MUSA framework and

available in the MUSA Security Agent Catalogue.

The types of WHAT include:

a. in case the component is COTS or SERVICE, the possible WHAT values are: Web,

Storage, IDM or Firewall. Web refers to any functionality provided through a Web

interface, Storage refers to data storage solutions (e.g. MySQL), IDM stays for Identity

Management and Firewall for any software solution that protects resources from

unauthorised access.

b. in case the component is AGENT, the possible values of WHAT come from the list of

the agents in the MUSA Security Agent Catalogue.

• Security Controls information that properly supports Security Control Framework families.

For example, name attribute has been updated to <Family>-<Number>(Number) format. In

addition, the subdomain attribute in the Security Control entity now is optional instead of

compulsory.

The CAMEL extension developed in MUSA allows specifying which security capabilities are

required and provided by each multi-cloud application component. The security capabilities are

defined in the model by selecting and grouping the security controls part of the capability. The

security controls of a Security Control Family are predefined and the list is offered to the user

by the MUSA Modeller to ease the selection of the ones included in the capability.

Currently, the security controls from the NIST SP 800-53 rev.4 [4] are supported. In the

following example two security capabilities CAP1 and CAP2 are defined, the first with three

security controls and the second with only two.


Once the security capabilities are defined in the CAMEL (in the security model part of the

model), the user can specify what security capabilities the components require and/or provide.

In the following example, Comp1Cap is a provided capability and Comp1CapReq a requested

one.

When a component requires a specific security capability from another component (in the

example, Comp1CapReq) then the matching of the capability needs to be modelled as follows.

4.2 Innovations for multi-cloud deployment

Other MUSA innovations to CAMEL language address improvements for enhancing the expressiveness

of the deployment requirements, as follows:

• Explicit characterization of the nature of the IP address associated with virtual machines in

which the components will be deployed. At deployment phase, when acquiring new cloud

resources such as VMs, the system operator needs to indicate whether a public IP address is

required. The CAMEL extension allows specifying whether the IP address required for a VM

should be public or not by the IP public attribute on each component. The possible values for

this attribute are: true or false.

• Specification of the deployment order of the application components. Dealing with multi-

cloud environments, it is critical to identify the order in which each component should be

deployed and configured, since there are inter-dependencies among the components that are part

of the same application. For example, the start up of a component may require that another

component is up and running in advanced. The CAMEL extension allows specifying the order

provided security capability Comp1Cap {

security capability SEC.CAP2

}

required security capability Comp1CapReq

security model SEC {

security capability CAP1 {

controls [MUSASEC.AC-11(1), MUSASEC.AU-13(2),

MUSASEC.AC-17(6)]

}

security capability CAP2 {

controls [MUSASEC.AC-11(1), MUSASEC.AC-17(6)]

}

}

capability match Comp1ToComp2 {

from Comp1.Comp1CapReq to Comp2.Comp2Cap

}


in which the components are required to be deployed. This can be done by using the order

attribute for each component. The expected value for the order attribute is an integer number.

• Explicit definition of data exchange protocols. In the MUSA extended CAMEL, users can

model the communications between the components (e.g. by setting the IP addresses and ports

in the configuration of the components) and specify the need to use a specific data exchange

protocol (e.g. MySQL, OAuth, Other).

• Modelling of dynamic configurations of communications between components. In CAMEL,

users model the communications between the components in a static way (i.e. through specific

port numbers and operating system configuration variables). However, in MUSA, dynamic

characteristics have been introduced such as context paths (instead of IP addresses) and dynamic

port ranges.

Such new capabilities are useful, for instance, to configure explicitly inbound traffic when users

deploy components in Docker [5] containers.

• Modelling of deployment handlers. In CAMEL, the user can model components and associate

deployment instructions for installing, configuring, starting, and stopping the components on

virtual machines. However, such deployment instructions are restricted to scripted commands

and CAMEL lacks support to the specification of configuration management tools such as

Cloudify [6], Puppet [7], or Chef [8]. Therefore, in MUSA this gap between multi-cloud

application models and these advanced frameworks has been faced via the new Configuration

entity and its associated concepts (e.g. cookbooks and recipes in case of Chef).

• Modelling of PaaS layer elements. CAMEL lacks support to the description of architectures

where the application components are not directly deployed in Virtual Machines (VMs) but in

containers. Our extension allows specifying the container type that will be used in deployment

and defining the component allocation strategy it should follow, even in cases when the

container uses VM pools. The new elements in our extension include:

o pool: is a cluster of VMs, which will be used by a container.

o manager: the VM in a pool that will act as the manager in contrast to the rest that will

act as workers.

o container:

- type: the container solution to use, for example, Docker Swarm [9].

- allocationStrategy: defines the allocation strategy of the containers on top of

the acquired VMs for resource optimization (e.g. automatically scheduling

container workloads). It supports the following four values:

• spread: balance containers across the VMs in a pool based on the available

CPU and RAM of the VMs.

• binpak: schedule containers to fully use each VM capacity. Once the full

VM capacity has been used, the container moves on to the next one in the

pool.

• random: choose a VM randomly.

• custom: the user defines the specific VMs in which the containers should

run.

• Refinement of security aspects in Organisation, User, Credentials and Role entities. A number

of enhancements to CAMEL have been made in order to manage the authorisation of different

roles in the DevOps Team to multi-cloud application deployment execution. For instance, in

MUSA the types of credentials available to authenticate a user have been extended. Moreover,


it has been added expiration dates to Credentials and the re-use of Role Assignments has been

improved by allowing an easy assignment of roles to multiple groups and users.

4.3 Innovations for self-healing capability of multi-cloud applications

Considering self-healing as the capability of a multi-cloud application of being able to self-control or

modify its security behaviour at runtime so as security incidents or attacks are corrected or mitigated,

self-healing is enabled in MUSA by the MUSA Enforcement Agents.

As their name suggests, the MUSA Security Enforcement Agents enforce multi-cloud application

security properties at runtime such as access control, security vulnerability scanning or Denial of service

mitigation mechanisms. For these mechanisms to work, they need to be deployed at the same time as

the application components are deployed. Some of these mechanisms require to be deployed together

with (in the same VM) the component that they will enforce the property on.

Therefore, the MUSA extended CAMEL allows the definition of MUSA Security Enforcement Agents

as Internal Components of the application, similarly to application components themselves, so as they

can be included in the deployment plan. Such agents are already pre-defined in the MUSA Security

Agent Catalogue so users are able to re-use and configure them in a friendly way. Some of these agents

are always on and some will be managed through the enforcement services in the MUSA Security

Assurance Platform.


5 MUSA Modeller Architecture

This section contains the description of the final MUSA Modeller’s architecture.

The MUSA IDE was identified as KR1 and includes MUSA Modeller and MUSA SLA Generator. The

SLA Generator is explained in deliverable D2.3 Final SbD methods for multi-cloud applications and

this section focuses in the Modeller.

5.1 Objective and overview

The MUSA Modeller is a web editor that allows the creation and maintenance of CAMEL (extended)

models. Through these models it is possible to specify a complete specification of the requirements

needed by an application to be deployed in a secure multi-cloud environment.

Next figure shows the MUSA overall workflow and how the MUSA Modeller fits in it. As initial step

of the design phase, the DevOps Team creates the Cloud Provider Independent Model (CPIM) of the

multi-cloud application using the MUSA Modeller. The CPIM of the application is a specification done

in a level of abstraction independent from information of specific Cloud Services that the application

will use. The generated CPIM is used in the risk assessment and in the multi-cloud application

deployment as input. Please note that in the final version, the SLA generation process does not require

as input the generated CPIM, because it uses the MUSA Modeller created Multi-cloud Application

Composition Model (MACM) instead. The detailed MUSA workflow is described in D1.4 Final MUSA

framework specification and guide.

Figure 2. MUSA overall workflow

5.2 Component model

Even if the MUSA overall workflow has slightly changed from the initial version, being the Modeller

the first step in the workflow, its high level architecture has not changed.

Next are described the high level components in which the MUSA Modeller is structured:

• Web component: represents the interface from which the user accesses the Modeller and all

the logic necessary to access the services offered by the Server Component. It includes the Xtext

Web Editor framework [10] libraries that offer services for remote management of syntax

validation and auto completion


• Server component: contains the main logic of the Modeller. It offers a series of web services

that can be invoked from the Web component and that implement all the necessary

functionalities.

• Database component: contains all the logic through which database operations are performed.

It uses the Hibernate framework [11], which allows abstracting from the database engine by

using a declarative specification (in configuration files) of the connection data.

In the following sections a detailed explanation of each of these components is made.

Figure 3 illustrates a high level overview of the full architecture.

Figure 3. MUSA Modeller architecture overview

5.2.1 Web Component

5.2.1.1 Overview

The Web Component represents the interface through which the DevOps Team accesses the Modeller.

It invokes services deployed on the Server Component.

5.2.1.2 Component diagram

As it can be seen in next figure, the Web Component is mainly composed of three sub-components:

• Modeller Web Page: Interface through which the DevOps Team accesses the Modeller and

models the CPIM of the multi-cloud application. It consists of html code with controls that allow

the user to interact with the system and stylesheets and javascript files provided by the Xtext

Web Editor framework [10]. The javascript files contain code used to invoke the Xtext services,

allowing this way the creation of a (extended) CAMEL language´s syntax editor within a web

browser.

• CAMEL DSL (Domain Specific Language): Library containing the specification of the

extended CAMEL meta-model (official library + extension made to meet MUSA project´s

specific needs). This library is used by Xtext to validate the syntax and to handle the auto

completion functionality of the elements belonging to the models written in the editor of the

Modeler by the DevOps Team members.


• Xtext Web Services: Xtext library that contains a series of REST services capable of providing

the tool's full functionalities within a web environment. Until the appearance of Xtext version

2.9 in December 2015, the framework had provided the functions of creating and validating

syntax of domain dependent languages only in stand-alone environments (mainly within the

Eclipse ecosystem), but in version 2.9 Xtext included a series of REST web services together

with javascript files and style sheets in order to facilitate the use of the framework in web

environments.

Figure 4. MUSA Modeller Web Component

5.2.2 Server Component

5.2.2.1 Overview

The Server Component acts as an intermediary between the Web Component and the Database

Component. It implements web services through which maintenance operations (creation, consultation

and modification) of the CAMEL models are offered. These services send the corresponding request to

the Database Component to execute the operation on the database.

Moreover, this component implements the REST service that transforms a multi-cloud application

model in CAMEL format to Multi-cloud Application Composition Model (MACM) format that will be

used by the MUSA SLA Generator (see Section 7).


The Server Component is composed of two sub-components.

• Maintenance Web Services: Web services exposed through a REST interface that are invoked

from the Web Component to create, modify or query a (extended) CAMEL model given an

application identifier. These services delegate all necessary processing to classes contained in

the Maintenance Core, which are responsible of processing the data that is sent and retrieved

from the database through the Data Component.


• Maintenance Core: A package containing a series of java classes in which web services

delegate all data processing and access to the database.

Figure 5. MUSA Modeller Server Component.

5.2.3 Database Component

5.2.3.1 Overview

This component encapsulates all the accesses to the database in which the (extended) CAMEL models

are stored.

This component makes use of Hibernate [11], the object-relational mapping framework for the Java

language. Hibernate's primary feature is mapping from Java classes to database tables; and mapping

from Java data types to SQL data types. Hibernate also provides data query and retrieval facilities. It

generates SQL calls and relieves the developer from manual handling and object conversion of the result

set.

Apart from this, Hibernate allows to make an abstraction of the database engine used, by specifying the

database configuration data declaratively, so that in case of a change of database engine, it would not be

necessary to modify the code to access to it.


The Database Component is composed of two sub-components.

• Database Manager: A component that contains all the operations that can be performed against

the database tables. Please note that the database tables are described in Section 5.3.

It is based on a java class that implements the following methods:

o addMCApp (String mcApplication, String version, String camel)


Method through which a new record is inserted into the mu_mcapp table. It receives as

parameters the application ID, the application version and the camel model that is

wanted to be stored for the application.

o getMCApps( )

Returns all the applications with their associated CAMEL models.

o getMCApp(String mcApplication)

Retrieves the data of a certain application from its identifier.

o updateMCApp(String mcApplication, String camel)

Updates the model associated to an application given its identifier and the new version

of the model.

o deleteMCApp(String mcApplication)

It deletes all the data corresponding to an application given its identification.

o addDomain (String id, String domain)

Method through which a new record is inserted into the mu_controls table. It receives

as parameters the ID and name of the domain to be stored.

o getDomains( )

Returns all the security domains stored on the database.

o addSC (String id, String name, String specification, String domain)

Method through which a new record is inserted into the mu_controls table. It receives

as parameters the ID, name, specification and domain of the security control to be

stored.

o getSCs( )

Returns all the security controls stored on the database.

o checkIfAppAgentRelationExists(String, String, String)

Checks if a security agent is related to an application.

o checkIfAppComponentAgentRelationExistsIfNotExecuteInsert(String, String,

String)

Checks if a security agent is related to an application´s component. If not, it establishes

the relation in the database.

o checkIfAppExists(Long)

Checks if an application exists in the database.

o deleteNonExistingComponents(Long, ArrayList<Integer>)

Deletes components from the mu_app_component table that no longer exist.

o getAgents()

Recovers the existing security agents from the database.

o getAppCamel(Long)

Returns a multi-cloud application model in CAMEL format stored in the database given

its id.

o getAppCamelXML(Long)

Returns a multi-cloud application model in XMI format stored in the database given its

id.

o getAppValidationReport(Long)

Returns a list containing all the validation errors stored in the database after parsing the

model.


o getComponentsByApplication(Long)

Returns a list of all the components related to an application given its id.

o getSecurityAgentCamelModel(String)

Recovers the security agent model from the mu_agents table given the agent id.

o getSecurityCapabilityByAgentId(String)

Recovers the security capability from mu_security_capabilities table given the

capability id.

o updateCamelAndXMIofMCApp(Long, String, String)

Updates the multi-cloud application model in both CAMEL and XMI format by storing

them in the database.

• Hibernate Configuration: Set of configuration files and classes through which declarative

access to the database is managed via Hibernate. It is also established an automatic mapping of

java objects with database tables (in this case we only have one). This automatic mapping even

allows the database to be created when the server is started, without the need to launch a script

or to access a client to access the particular database engine.

Next, we show the content of the two configuration files that are used:

Figure 6. Configuration file on which the mapping is established.


Figure 7. Configuration file on which the database access is set.

In the next figure, the component diagram of the MUSA Modeller Database Component is depicted.

Figure 8. MUSA Modeller Database Component


5.3 Data model

This section presents the data model used by the Modeller Editor.

The data model consists of several tables: mu_mcapp, mu_controls, mu_agents,

mu_apps_components_agents, mu_app_component and mu_security_capabilities.

Next it is included a description of the tables contained in the modeller database.

mu_mcap stores all information related to multi-cloud applications.

Figure 9. MUSA IDE Editor mu_mcapp table definition

Where:

• Id: application identifier (auto-incremental value).

• Date: date on which a record is inserted or modified.

• MCApplication: descriptive name of the application.

• MCAVersion: version of the (ext.) CAMEL model for the application.

• Camel: CAMEL model.

• CamelXMI: CAMEL model in XMI format.

• CamelReport: Validation report of the CAMEL model.

mu_controls, like mu_mcap has a direct correspondence with the structure of the classes shown in the

previous section related to the Hibernate Configuration and stores all information related to security

controls.

Figure 10. MUSA IDE Editor mu_controls table definition


Where:

• Id: internal security control identifier (auto-incremental value).

• Control: group of the family to which the security control belongs to (e.g., “2”).

• Control_description: textual specification of the security control provided by the different

service providers.

• Control_id: security control identifier known by the service providers, security bodies and

authorities (e.g., “AC-2(1)”).

• Control_name: short name used to identify the security control (e.g., “Access Control Policy

and Procedures”).

• Enhancement: for internal use.

• Family_id: abbreviation of the family name (e.g., “AC”).

• Family_name: represents the family associated with the security control (e.g., “Access

Control”) and allows grouping security controls. It can represent a security domain or sub-

domain.

mu_agents stores all information related to security agents.

Figure 11. MUSA IDE Editor mu_agents table definition

Where:

• id: agent identifier.

• name: agent name.

• description: agent description.

• cook_book: cook book associated to the agent.

• camel_model: CAMEL model associated to the agent to be included in the multi-cloud

application model when the agent is added to a component of a specific application.

• security_capability_id: foreign key referring the security capability related to the agent in the

mu_security_capabilities table.

• avalilable: indicator to know if the agent is available to be included or not.

mu_apps_components_agents relates application controls with security agents.

Figure 12. MUSA IDE Editor mu_apps_components_agents table definition


Where:

• app_id: application id.

• component_id: component id.

• agent_id: agent id.

mu_app_component stores the relation between applications and components.

Figure 13. MUSA IDE Editor mu_app_component table definition

Where:

• app_id: application id.

• component_id: component id.

• component_name: component name.

mu_security_capabilities stores data related to the security capabilities associated to the security agents.

Figure 14. MUSA IDE Editor mu_security_capabilities table definition

Where:

• id: capability id.

• name: capability name.

• value: capability value.

5.4 Collaboration model

The collaboration model below describes the three main operations that can be executed through the

MUSA Modeller, which capture all the functionalities offered by the module:

• creation of a new multi-cloud application specification model (extended camel)

• update of a multi-cloud application specification model.

• recovery of a multi-cloud application specification model given application identifier.

• recovery of the MACM format of a multi-cloud application specification model given

application identifier.

• selection and insertion of a MUSA Security Enforcement Agent into a multi-cloud application

specification model.

Figure 15 shows the process followed to create a new multi-cloud application specification model.


First, the DevOps Team accesses the Modeller Web Page with the aim of creating a new multi-cloud

application specification model. This page contains an editor through which the engineer can specify

the deployment features of the application by following the extended CAMEL grammar. As the engineer

edits the model, the syntax of the model is validated by invoking a series of REST web services offered

by the Xtext Web Editor framework.

Once the model has been written by the DevOps Team, he can make a request to save it associated with

an application by invoking the createMcApp operation of the Maintenance Web Services. This service

delegates the management of the insertion to the database to the Maintenance Core component, which

in turn will use the Database Manager to finally perform the insertion.

Figure 16 shows the process followed to perform the modification of a multi-cloud application


The process is practically the same as in the previous case. As it can be seen in the sequence diagram,

the only two differences are as follows: in this case, first the DevOps Team has to select the application

and the version of which he wants to get the model for later editing. Once he has the model loaded in

the web page editor, he can edit it. When the model has been edited and by selecting the "save" option,

the updateMcApp service of Maintenance Web Services will be invoked, and the corresponding update

will be made in the database. This service requires the application id and the modified camel to be passed

as parameters.

Figure 17 shows the process that is executed to retrieve a multi-cloud application specification model

by giving the id of the application to which it belongs to.

In this case, a REST client calls the getCamel service exposed by the Maintenance Web Services

component. As in the previous cases, the web service delegates all the management of the request to the

Maintenance Core, which at the same time uses the Database Manager to perform the operation in the

database. Once the query has been executed, the recovered CAMEL model is returned as a string in case

it has been found and, if it is not found, an error message indicating this situation is returned.

Figure 18 shows the steps executed when it is necessary to retrieve the Multi-cloud Application

Composition Model (MACM) format of the CAMEL model, i.e. when this is required by the MUSA

Dashboard to make it available to: (i) the SLA Generator that will use the information in the MACM for

the Service Level Agreement composition process (see deliverable D2.3 for further information of the

SLA composition process), and (ii) the DST (both Risk Analysis and Decision) that will use the

information for the risk analysis and cloud service selection processes. In this case, the getCamel service

is used with MACM value in Format parameter, so the Maintenance Web Services knows that it has to

retrieve the model in MACM format.

Figure 19 shows the process for adding a MUSA Security Enforcement agent to a multi-cloud

application model. The REST client uses the putAgent service exposed by the Maintenance Web

Services component, and the Maintenance Core is called to store the agent information in the database

and check whether the relationship between the Agent and the Component is already defined, and if not,

the relationship is created automatically in the database.


Figure 15. MUSA Modeller sequence diagram for creating a new multi-cloud application model.


Figure 16. MUSA Modeller sequence diagram for updating a multi-cloud application model.


Figure 17. MUSA Modeller sequence diagram for recovering a multi-cloud application model.


Figure 18. MUSA Modeller sequence diagram for recovering a MACM model


Figure 19. MUSA Modeller sequence diagram for adding a MUSA Security Enforcement agent to a multi-cloud application model


5.5 Interface specification

The REST API interfaces offered by the MUSA Modeller to perform the operations described in the

previous section are described below:

• creation of a new multi-cloud application specification model (extended camel)

• update of a multi-cloud application specification model.

• recovery of a multi-cloud application specification model given application identifier.

• generation of the MACM format of a multi-cloud application specification model given

application identifier.

• update of a multi-cloud application specification model with elements related to a security agent,

given data related to the application and component to which the agent is added and data related

to the agent itself.

• recovery of the validation errors after parsing the multi-cloud application specification model.

5.5.1 Creation of a new multi-cloud application specification model

The following table presents the set of REST calls associated with the creation of a new model. For each

call, it is detailed the URI (i.e. the call path) and the HTTP method used, along with the request and

response header/bodies.

Table 3. Interface specification for creating a new multi-cloud application specification model

Resource URI /createMcApp

POST Description It requests for the creation of a new multi-cloud

application specification model.

Request body Multi-cloud application (McApplication) id, version and

extended camel document in json format.

Response body Media type: Application/json

Response code

semantics

200 (OK) if the model has been created correctly.

Diverse 400 type messages depending on the error.

5.5.2 Modification of a multi-cloud application specification model

The following table presents the set of REST calls associated with the update of a model. For each call,

it is detailed the URI (i.e. the call path) and the HTTP method used, along with the request and response

header/bodies.

Table 4. Interface specification for updating a multi-cloud application specification model

Resource URI /updateMcApp

POST Description It requests for the update of multi-cloud application


Request body Multi-cloud application (McApplication) id and extended

camel document in json format.


Response body Media type: Application/json

Response code

semantics

200 (OK) if the model has been updated correctly.


5.5.3 Recovery of a multi-cloud application specification model

The following table presents the set of REST calls associated with the recovery of a model given the

application id to which it belongs to. For each call, it is detailed the URI (i.e. the call path) and the HTTP

method used, along with the request and response header/bodies.

Table 5. Interface specification for recovering a multi-cloud application specification model

Resource URI /getCamel/{is}/CAMEL

GET Description It requests the retrieval of a multi-cloud application

specification model given an application id.

Request body Empty

Response body Media type: Text/plain

Response code

semantics

A string containing the model if it can be recovered.


5.5.4 Recovery of the MACM format of a multi-cloud application specification

model given application identifier

The following table presents the set of REST calls associated with the recovery of the Multi-cloud

Application Composition Model (MACM) format of a model given the application id to which it belongs

to. For each call, it is detailed the URI (i.e. the call path) and the HTTP method used, along with the

request and response header/bodies.

Table 6. Interface specification for recovery of the MACM format of a multi-cloud application

specification model

Resource URI /getCamel/{is}/MACM

GET Description It requests the retrieval of a multi-cloud application

specification model in MACM format given an

application id.

Request body Empty



Response code

semantics

A string containing the model if it can be recovered.


5.5.5 Update of a multi-cloud application specification model with elements

related to a security agent

The following table presents the set of REST calls associated with the update of a multi-cloud

application specification when a security agent is associated to an application component. For each call,

it is detailed the URI (i.e. the call path) and the HTTP method used, along with the request and response

header/bodies.

Table 7. Interface specification for updating a multi-cloud application specification model with

elements related to a security agent

Resource URI /getAgents

GET Description It requests the retrieval of information related to the

security agents

Request body Empty


Response code

semantics

Data related to agents recovered from the database in json

format.


Resource URI /getComponentsByApplication/{appId}

GET Description It requests the retrieval of the components related to an

application id

Request body Empty


Response code

semantics

Data related to components recovered from the database

in json format.


Resource URI /putAgent/{appId}/{appName}/{agentId}/{agentName}/{componentId}/{com

ponentName}


PUT Description It requests the update of the model and the database

given the ids and names of the application, component

and agent.

Request body Empty


Response code

semantics

200 (OK) if the model has been updated correctly.


5.5.6 Recovery of the validation errors after parsing the multi-cloud application

specification model

The following table presents the set of REST calls associated with the recovery of the validation errors

after parsing the multi-cloud application specification model. For each call, it is detailed the URI (i.e.

the call path) and the HTTP method used, along with the request and response header/bodies.

Table 8. Interface specification for recovering the validation errors after parsing the multi-cloud

application specification model

Resource URI /getValidationErrorsByApplication/{appId}

GET Description It requests the retrieval of the validation errors after

parsing an application model given its id.

Request body Empty


Response code

semantics

A string containing the validation errors if any.



6 MUSA Modeller final implementation

In this section, we describe the final version of the MUSA Modeller that was produced in the project.

6.1 Prerequisites and installation

The MUSA Modeller requires the installation of a MySQL database manager that is used by the

Database Component.

All other libraries required are included in the java Eclipse project itself.

6.2 Usage guide

The current version of the MUSA Modeller is available in the MUSA website under Tools menu,

www.musa-project.eu. The final MUSA Modeller prototype software is also available in the public

bitbucket of MUSA as explained in next section.

The use of the MUSA Modeller will be integrated within the complete MUSA framework usage flow,

which will be explained in detail in deliverable D1.3 Initial MUSA framework implementation.

The Modeller has a simple Graphical User Interface (see Figure 20) that allows:

• Editing and saving the application models (SAVE button). The application models are stored in

the Database component for future reuse.

• Model checking for syntax correctness and integrity while editing. The tool provides messages

of warnings and errors whenever non-conformances are identified in the model (see Figure 15).

• selecting MUSA Security enforcement agents (see Figure 22). The presented agents are those

stored in the MUSA Security Agent Catalogue.

Figure 20. Modeller GUI

http://www.musa-project.eu/


Figure 21. Modeller checking for syntax correctness and integrity while editing

Figure 22. Modeller support the selection of MUSA Security enforcement agents

A video explaining the usage of the Modeller can be seen in the video named “MUSA Modeller”

available at the MUSA youtube channel “MUSA project eu” here:

https://www.youtube.com/channel/UCA7mR0pU82yKPhF5jkPSlPw

The video is also available at the MUSA public website www.musa-project.eu within the Tools menu.

6.2.1 Model validation - Warnings and error messages

Model validation analysis is one of the most interesting aspects of the MUSA Modeller since end-users

get informative feedback about the validity (e.g. grammar, scoping) of the multi-cloud application

models. In this tool there are basically three different kinds of validation:

• The syntactical correctness of any textual input is validated automatically according to the

MUSA extended CAMEL DSL definition.

• Any broken crosslink or reference to other model entities is checked and resolved as well.

Similarly to syntax errors, any unresolvable crosslink is reported.

https://www.youtube.com/channel/UCA7mR0pU82yKPhF5jkPSlPw



• All constraints that are implied by the MUSA extended CAMEL are validated. Meeting these

constraints for a model is mandatory to be serialized. Specifically, in MUSA Modeller the

following validation checks are the most relevant:

o Duplicated entities are not allowed, that is, have entities with the same URI/name.

o In a Container, it is a must to choose a Virtual Machine (VM) belonging to the defined

Pool as manager.

o In an Internal Component to be deployed on a Container with a custom allocation

strategy, it is a must to choose a VM belonging to the defined Pool as container host.

o To ensure the completeness of the semantic model, it is a must that the necessary

Communications, Hostings and Capability Matches are properly defined and none is

missing.

Such validations are performed as users type and the corresponding error messages are shown

graphically with a red cross ( ) on the left column by the line number. Additionally, whenever a user

saves the created or updated multi-cloud application model, the Validation results report appears in a

pop-up window as it is shown in the next figure.

Figure 23. Validation report of a multi-cloud application model

6.3 Source code repository

The open source projects that implement the MUSA Modeller described above can be found in the

following MUSA bitbucket public repository:


Specifically, these are the five repositories that compose the MUSA Modeller:

• eu.musa.modeller.utils

• eu.musa.modeller.web-tomcat

• eu.musa.modeller.ws

• org.camel_dsl

• org.camel_dsl.dsl.parent


https://bitbucket.org/musateam/eu.musa.modeller.utils

https://bitbucket.org/musateam/eu.musa.modeller.web-tomcat

https://bitbucket.org/musateam/eu.musa.modeller.ws

https://bitbucket.org/musateam/org.camel_dsl

https://bitbucket.org/musateam/org.camel_dsl.dsl.parent

https://www.google.es/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwjL9KiY25jXAhVE0RQKHeF1B6cQjRwIBw&url=https://pixabay.com/en/stop-button-red-warning-error-31189/&psig=AOvVaw2r4OQFgRi-Pc-LcJh1eiXY&ust=1509465447586266


7 Innovation

The main innovations achieved in MUSA on secure multi-cloud application modelling mechanisms are

related to both results: the MUSA extended CAMEL language and the supporting modelling tool named

MUSA Modeller.

Regarding the improvements to the CAMEL language, as detailed in Section 4, we extended the

metamodel to improve the expressiveness of security aspects of multi-cloud applications that will be

relevant for the SLA composition afterwards. Moreover, we also provided extensions for enhancing the

expressiveness of the deployment planning itself. The deployment extensions include concepts required,

for example, in those situations when a Configuration Management tool will be used for deployment

execution and when application components will not be deployed on top of Virtual Machines but in

containers.

Regarding the innovation brought by the MUSA Modeller, as detailed in Sections 5 and 6, the major

innovation brought by the tool is that it enables the on-line edition of MUSA extended CAMEL models

by means of a Web service based on Xtext Web. Besides model edition support features, the tool

executes also model semantics verification rules and model correctness verification rules, providing

warnings and error messages to the user which facilities the model creation. Last but not least, the tool

is able to produce the Multi-cloud Application Composition Model (MACM) required by the SLA

Generation step in the MUSA workflow. This model synthesizes the application components’ type and

their relationships, together with the components relationships with the required cloud resources types

that have been expressed in the MUSA extended CAMEL model.

The following table summarises the features offered in our extended CloudML and the rationale for

including them.

Table 9. Overview of MUSA extended CloudML features

Feature Rationale

Modelling of component nature Required by the SLA Composition process within the SLA-

based Security-by-Design approach of MUSA.

Modelling of Security controls provided by

components properly supporting Security

control families.

Required by the SLA Composition process within the SLA-

based Security-by-Design approach of MUSA.

Modelling of nature of the IP address. Required in virtual machines provisioning phase.

Modelling of components deployment order. Required by deployment phase.

Modelling of data exchange protocols. Required by deployment phase.

Modelling of dynamic configurations of

communications between components.

Required in deployment where components may have

dynamic configurations.

Modelling of deployment handlers. Required in deployments managed by deployment handlers.

Modelling of PaaS layer elements. Required in deployments that use clusters of containers.

Supporting tool Web GUI Enables DevOps team to work on-line from multiple

platforms and enhances maintainability of the tool.

Supporting tool - MACM generation Required by the DST and SLA Generation process within

MUSA workflow.

Supporting tool – model correctness

validation

Ensures created CPIM model will be a correct input for the

rest of the tools in MUSA workflow.

Supporting tool – model completeness

validation

Ensures created CPIM model will be a correct input for the

rest of the tools in MUSA workflow.


8 Conclusion

This document provides a description of the final security-aware multi-cloud application modelling

mechanisms and supporting prototype developed in MUSA.

The aim of this document is to explain the further extensions of CAMEL model since the initial version

described in D2.2 along with the description of the final prototype architecture and implementation

details.

The CAMEL extensions developed are related to address the concepts required to support composition

of components’ SLAs in MUSA. Other updates are related to a better definition of Security Controls

information, to properly support Security Control Framework families as different families may be used

in the SLA specification. The specification of Security controls in MUSA is needed when application

components do provide security capabilities or require them from other components. This is the case of

MUSA security enforcement agents (see deliverable D4.3). Note that, in MUSA, when components do

require security capabilities from cloud service providers this information is not captured in the

Modelling step but in the Risk Analysis.

In addition, in order to address the deployment requirements of MUSA’s use case applications, we have

extended CAMEL to enable the specification of deployments over PaaS solutions and deployments that

use Configuration Management tools like Chef.

The final prototype supporting the extended CAMEL is a Web tool integrated with the MUSA

Dashboard and available in the MUSA website and in the MUSA bitbucket repository. The tool is easily

adaptable to a standalone version that can be used as application modelling service in other frameworks

too.

One of the possibilities that was studied to increase the reusability of the created CAMEL models was

the design of the tool in a way that it could support composability of component level CAMEL models

for creating the overall multi-cloud application CAMEL model by referring to individual components’

CAMEL models. This was discarded in the end because CAMEL integrates several metamodels

(Location, Requirements, Deployment, etc.) and many cross-references would be needed between these

models at both component and application levels which would drastically reduce the usability of the

tool. Moreover, splitting CAMEL models at component level would mean completely losing

compatibility with other existing CAMEL variants.


References

[1] MUSA H2020 Project, Multi-cloud Secure Applications. 2015-2017. Available at: www.musa-

project.eu

[2] MUSA H2020 Project. D1.4 Final MUSA framework specification and guide – Final version.

December 2017. Available at: www.musa-project.eu

[3] MUSA H2020 Project. D2.3 Final SbD methods for multi-cloud applications. October 2017.

Available at: www.musa-project.eu.

[4] NIST Joint Task Force and Transformation Initiative. Security and privacy controls for federal

information systems and organizations. NIST Special Publication 800, 53 (2013), 8–13.

[5] Docker Inc. Docker. Available at: https://www.docker.com/ (Retrieved October 2017)

[6] Cloudify Platform Ltd. Cloudify. Available at: http://cloudify.co/ (Retrieved October 2017)

[7] Puppet Labs: IT Automation Software for System Administrators. Puppet documentation.

Available at: https://docs.puppet.com/puppet/ (Retrieved October 2017).

[8] Chef Software Inc. Chef technology. Available at: https://www.chef.io/chef/ (Retrieved

October 2017).

[9] Docker Inc. Docker Swarm. Available at: https://docs.docker.com/swarm/ (Retrieved October

2017).

[10] Eclipse Foundation Inc. 2017. Xtext Web Editor. Available at:

http://www.eclipse.org/Xtext/documentation/330_web_support.html (Retrieved October

2017).

[11] Red Hat Inc. 2017. Hibernate framework. Available at: http://hibernate.org/ (Retrieved

October 2017).

[12] PaaSage consortium. D2.1.2 CloudML Implementation Documentation. April 2014.

Available at: http://www.paasage.eu/images/documents/paasage_d2.1.2_final.pdf (Retrieved

October 2017)

[13] PaaSage EU FP7 project. Available at: http://www.paasage.eu/ (Retrieved October

2017)

[14] CAMEL Documentation v2015.9 by PaaSage EU Project. Available at: http://camel-

dsl.org/documentation/ (Retrieved October 2017)

[15] Model-based provisioning and deployment of cloud-based systems. CloudML project.

Available at: http://cloudml.org (Retrieved October 2017)

[16] FERRY, Nicolas, et al. Towards model-driven provisioning, deployment, monitoring,

and adaptation of multi-cloud systems. En CLOUD 2013: IEEE 6th International Conference

on Cloud Computing. 2013. p. 887-894.

[17] Clément Quinton, Daniel Romero and Laurence Duchien. ‘Cardinality-based feature

models with constraints: a pragmatic approach’. In: SPLC 2013: 17th International Software

Product Line Conference. Ed. by Tomoji Kishi, Stan Jarzabek and Stefania Gnesi. ACM, 2013,

pp. 162–166. ISBN: 978-1-4503-1968-3. DOI: 10.1145/2491627.2491638.

[18] Kyriakos Kritikos, Jörg Domaschka and Alessandro Rossini. “SRL: A Scalability Rule

Language for Multi-Cloud Environments”. In: Cloud-Com 2014: 6th IEEE International

Conference on Cloud Computing Technology and Science. Ed. by Juan E. Guerrero. IEEE

Computer Society, 2014, pp. 1–9. ISBN: 978-1-4799-4093-6. DOI:

10.1109/CloudCom.2014.170.





https://www.docker.com/

http://cloudify.co/

https://docs.puppet.com/puppet/

https://www.chef.io/chef/

https://docs.docker.com/swarm/

http://www.eclipse.org/Xtext/documentation/330_web_support.html

http://hibernate.org/

http://www.paasage.eu/images/documents/paasage_d2.1.2_final.pdf

http://www.paasage.eu/

http://camel-dsl.org/documentation/

http://camel-dsl.org/documentation/

http://cloudml.org/


[19] Alessandro Rossini. ‘Cloud Application Modelling and Execution Language (CAMEL)

and the PaaSage Workflow’. In: Advances in Service-Oriented and Cloud Computing—

Workshops of ESOCC 2015. Ed. by Antonio Celesti and Philipp Leitner. Vol. 567.

Communications in Computer and Information Science. Springer, 2016, pp. 437–439. isbn:

978-3-319-33313-7. doi: 10.1007/978-3-319-33313-7.

[20] ARTIST project. Advanced software-based service provisioning and migration of

legacy software. Available at: www.artist-project.eu/ (Retrieved October 2017)

[21] MODAClouds consortium. D4.2.2 MODACloudML development – Final version.

September 2014. Available at: http://www.modaclouds.eu/wp-

content/uploads/2012/09/MODAClouds_D4.2.2_-

MODACloudMLDevelopmentFinalVersion.pdf (Retrieved October 2017)

[22] Creator4Clouds. Available at: http://forge.modelio.org/projects/creator-

4clouds/wiki/Creator4Clouds-Introduction (Retrieved October 2017)

[23] MODAClouds consortium. D4.3.3 MODACloudML IDE – Final Version. Available at:

http://www.modaclouds.eu/wp-

content/uploads/2012/09/MODAClouds_D4.3.3_MODACloudMLIDEFinalVersion.pdf

(Retrieved October 2017)

[24] Modelio Constellation. Available at:

https://www.modeliosoft.com/en/products/modelio-constellation.html (Retrieved October

2017)

[25] Bergmayr, A., Rossini, A., Ferry, N., Horn, G., Orue-Echevarria, L., Solberg, A., &

Wimmer, M. (2015). The Evolution of CloudML and its Manifestations. In Proceedings of the

3rd International Workshop on Model-Driven Engineering on and for the Cloud (CloudMDE)

(pp. 1-6).

http://www.artist-project.eu/

http://www.modaclouds.eu/wp-content/uploads/2012/09/MODAClouds_D4.2.2_-MODACloudMLDevelopmentFinalVersion.pdf



http://forge.modelio.org/projects/creator-4clouds/wiki/Creator4Clouds-Introduction

http://forge.modelio.org/projects/creator-4clouds/wiki/Creator4Clouds-Introduction

http://www.modaclouds.eu/wp-content/uploads/2012/09/MODAClouds_D4.3.3_MODACloudMLIDEFinalVersion.pdf

http://www.modaclouds.eu/wp-content/uploads/2012/09/MODAClouds_D4.3.3_MODACloudMLIDEFinalVersion.pdf

https://www.modeliosoft.com/en/products/modelio-constellation.html


Appendix A. MUSA motivation and background

The main goal of MUSA project is to support the security-intelligent lifecycle management of

distributed applications over heterogeneous cloud resources, through a security framework that includes:

a) security-by-design mechanisms to allow application self-protection at runtime, and b) methods and

tools for the integrated security assurance in both the engineering and operation of multi-cloud

applications.

MUSA overall concept is depicted in the figure below.

Figure A.1: MUSA overall concept

MUSA framework combines 1) a preventive security approach, promoting Security by Design practices

in the development and embedding security mechanisms in the application, and 2) a reactive security

approach, monitoring application runtime to mitigate security incidents, so multi-cloud application

providers can be informed and react to them without losing end-user trust in the multi-cloud application.

An integrated coordination of all phases in the application lifecycle management is needed in order to

ensure the preventive oriented security to be embedded and aligned with reactive security measures.


Appendix B. CAMEL meta-model extensions in MUSA

Figure B.1: MUSA overall meta-model


Figure B.2: MUSA Deployment meta-model


Figure B.3: MUSA Organisation and Security meta-models


Appendix C. Example of TSM application CPIM

camel model TSMModel {

security model TSMSecurity{

security capability CAP_ENF_AC {

controls [MUSASEC.AC-1, MUSASEC.AC-3]

}

}

application TSMApplication {

version: 'v2.0'

owner: TUTOrganisation.test_user1

deployment models [TSMModel.TSMDeployment]

} // application TSMApplication

location model TSMLocation {

region EU {

name: Europe

}

country IE {

name: Ireland

parent regions [TSMLocation.EU]

}

country UK {

name: UnitedKingdom

parent regions [TSMLocation.EU]

}

} // TSMLocation Model

requirement model TSMRequirement {

quantitative hardware HW_2CPU_4RAM {

core: 2..4 // min and max number of CPU cores

ram: 4096..8196 // size of RAM

}

os Ubuntu {os: Ubuntu 64os}

location requirement UKReq {

locations [TSMLocation.UK]

}

location requirement IrelandReq {

locations [TSMLocation.IE]

}

} // requirement model TSMRequirement

organisation model TUTOrganisation {

organisation TUT {

www: 'http://www.tut.fi/en/home'

postal address: 'Korkeakoulunkatu 10, 33720 Tampere, Finland'

email: '[email protected]'

}

user test_user1 {

first name: test_name

last name: test_surname


email: '[email protected]'

musa credentials {

end time: 2017-12-31

username: 'mcp'

password: ''

}

}

user test_user2 {

first name: user2_name

last name: user2_surname

email: 'its email'

musa credentials {

username: 'user2'

password: ''

}

}

user group test_group {

users [TUTOrganisation.test_user1, TUTOrganisation.test_user2]

}

role devop

role assignment test_nameDevop {

start: 2016-02-26

end: 2017-12-31

assigned on: 2016-02-25

users: [TUTOrganisation.test_user1, TUTOrganisation.test_user2]

role: devop

}

role assignment test_groupDevop {

start: 2016-02-01

end: 2017-12-31

assigned on: 2016-02-25

role: devop

user groups: [TUTOrganisation.test_group]

}

security level: HIGH

} // organisation model TUTOrganisation

deployment model TSMDeployment {

// example of VMRequirementSet only applicable to a specific Component

// ------------------------------------------------

// Requirements

// ------------------------------------------------

requirement set JourneyPlannerHostRS {

os: TSMRequirement.Ubuntu

quantitative hardware: TSMRequirement.HW_2CPU_4RAM

location: TSMRequirement.IrelandReq

}

requirement set TSMEngineHostRS {



location: TSMRequirement.UKReq

}

requirement set ConsumptionEstimatorRS {





}

requirement set JourneyDatabaseRS {




}

// ------------------------------------------------

// VMs

// ------------------------------------------------

vm JourneyPlannerVM {

requirement set JourneyPlannerHostRS

provided host JourneyPlannerHost

}

vm TSMEngineHostVM {

requirement set TSMEngineHostRS

provided host TSMEngineHost

}

vm ConsumptionEstimatorVM {

requirement set ConsumptionEstimatorRS

provided host ConsumptionEstimator

}

vm JourneyDatabaseVM {

requirement set JourneyDatabaseRS

provided host JourneyDatabaseHost

}

// ------------------------------------------------

// Components

// ------------------------------------------------

internal component TSMEngine {

type: MUSACONF.SERVICE.Web

order: 4

IP public: true

required security capability CAP_AC_Req

provided communication TSMEnginePort { port: 8080 }

// COMMUNICATION with JourneyPlanner

required communication TSMEngineToJourneyPlanner { port: 8085 }

// COMMUNICATION with CEC

required communication TSMEngineToCEC { port: 9090 }

// COMMUNICATION with Database

required communication TSMEngineToDatabase { port: 5432 }

required host TSMEngineHostReq

configuration TSMEngineConfigurationCHEF {

CHEF configuration manager C1 { //Configuration Management tool

cookbook: 'tut'

recipe: 'musa_tsme'

}

}

}

internal component ACAgentForTSMEngine {

type: MUSACONF.AGENT.MUSA_AccessControl

order: 5


IP public: true

provided security capability CAP_AC {

security capability TSMSecurity.CAP_ENF_AC

}

provided communication TSMEnginePortThroughACAgent { port: 80 }

required communication MUSAMessageBrokerPortReq1 {port: 9092 mandatory}

required communication MUSAMessageBrokerPortReq2 {port: 2181 mandatory}

required host ACAgentForTSMEngineHostReq

configuration ACAgentForTSMEngineConfigurationCHEF {


cookbook: 'enforcement_agents'

recipe: 'ac'

}

}

}

internal component JourneyPlanner {


order: 2

IP public: true

provided communication JourneyPlannerPort { port: 8085 }

required host JournayPlannerHostReq

configuration JourneyPlannerConfiguration{

CHEF configuration manager C1 {

cookbook: 'tut'

recipe: 'musa_mjp'

}

}

}

internal component ConsumptionEstimator {


order: 3

IP public: false

provided communication ConsumptionEstimatorPort {port: 9090}

required host ConsumptionEstimatorHostReq

configuration ConsumptionEstimatorConfiguration{

CHEF configuration manager C1 {

cookbook: 'tut'

recipe: 'musa_cec'

}

}

}

internal component JourneyDatabase {

type: MUSACONF.SERVICE.Storage

order: 1

IP public: false

provided communication DatabasePort {port: 5432}

required host JourneyDatabaseHostReq


configuration DatabaseManualConfiguration{


cookbook: 'tut'

recipe: 'musa_db'

}

}

}

// ------------------------------------------------

// HOSTING

// ------------------------------------------------

hosting TSMEngineHost {

from TSMEngine.TSMEngineHostReq to TSMEngineHostVM.TSMEngineHost

}

hosting JourneyPlannerHost {

from JourneyPlanner.JournayPlannerHostReq to

JourneyPlannerVM.JourneyPlannerHost

}

hosting ConsumptionEstimatorHost {

from ConsumptionEstimator.ConsumptionEstimatorHostReq to

ConsumptionEstimatorVM.ConsumptionEstimator

}

hosting DatabaseHost {

from JourneyDatabase.JourneyDatabaseHostReq to

JourneyDatabaseVM.JourneyDatabaseHost

}

hosting ACAgentForTSMEngineHost {

from ACAgentForTSMEngine.ACAgentForTSMEngineHostReq to

TSMEngineHostVM.TSMEngineHost

}

// ------------------------------------------------

// Communication

// ------------------------------------------------

communication TSMtoJourneyPlanner {

type: ANY

from TSMEngine.TSMEngineToJourneyPlanner to

JourneyPlanner.JourneyPlannerPort

}

communication TSMeToCEC {

type: ANY

from TSMEngine.TSMEngineToCEC to

ConsumptionEstimator.ConsumptionEstimatorPort

}

communication TSMeToDatabase {

type: ANY

from TSMEngine.TSMEngineToDatabase to JourneyDatabase.DatabasePort

}

// ------------------------------------------------

// Security Capability Matching

// ------------------------------------------------

capability match TSMEngineToMUSAAgentAC1 {

from TSMEngine.CAP_AC_Req to ACAgentForTSMEngine.CAP_AC

}


} // deployment model TSMDeployment

}

MUlti-cloud Secure Applications › sites › musa3.drupal.pulsartecnalia.co… · D2.4: Final MUSA...

Documents

Transcript of MUlti-cloud Secure Applications › sites › musa3.drupal.pulsartecnalia.co… · D2.4: Final MUSA...