multi-cloud secure applications...this project has received funding from the european union’s...

This project has received funding from the European Union’s Horizon 2020 research and

innovation

programme under grant agreement No 644429

MUlti-cloud Secure Applications

Deliverable title Deliverable ID:

Final security assurance mechanisms

and tools

D4.3

Preparation date:

01/12/2017

Editor/Lead beneficiary (name/partner):

Wissam Mallouli / MI

Internally reviewed by (name/partner):

Massimiliano Rak / CERICT, Stefan

Spahr / LHS, Arsalan Shah / TUT

Abstract:

This deliverable presents different security monitoring, notification and enforcement mechanisms for

multi-cloud applications developed in MUSA. The document builds on top of the previous deliverable

D4.1 Initial security assurance mechanisms and tools and completes it with progress made till the end

of the MUSA project. A state of the art of existing mechanisms and deployments strategies is presented.

The security metrics that are targeted in the context of MUSA project are listed. The MMT-based

monitoring agents and the enforcement agents developed in MUSA are also presented in detail. These

agents are integrated in the MUSA Security Assurance Platform presented in the deliverable D4.4 Final

MUSA Security Assurance Platform and User manual.

Dissemination level

PU Public X

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

D4.3: Final security assurance mechanisms and tools 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 Muntes

[email protected]

Montimage

(MI, France)

Contact: Edgardo Montes de Oca

edgardo.montesdeoca@montimage

.com

AIMES Grid Services

(AIMES, UK)

Contact: Prof Dennis Kehoe

[email protected]

Lufthansa Systems

(LHS, Germany)

Contact: Dirk Bracklow

[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 .......................................................................................................................................... 5 List of tables ............................................................................................................................................ 6 Executive summary ................................................................................................................................. 7 1 Introduction ..................................................................................................................................... 8

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

2 Overview of revisions and additions since D4.1 ........................................................................... 11 3 Monitoring tools in multi-cloud applications ................................................................................ 12

3.1 Monitoring agents deployment architectures for multi-cloud based applications ............... 12 3.1.1 Monitoring in virtualized environments .......................................................................... 12 3.1.2 State of art on monitoring virtualized applications ......................................................... 13 3.1.3 Distributed Monitoring Architecture for multi-cloud based applications ....................... 15 3.1.4 Specific monitoring deployment in OpenStack with MMT and Tap-as-a-Service ......... 16

3.2 Security monitoring techniques for cloud based applications ............................................. 18 3.2.1 Pattern-based approach and techniques ........................................................................... 19 3.2.2 Behaviour-based approach and techniques ...................................................................... 20 3.2.3 Hybrid-based approach .................................................................................................... 22 3.2.4 Data acquisition ............................................................................................................... 22 3.2.5 Challenges ....................................................................................................................... 23

3.3 MUSA monitoring agents .................................................................................................... 24 3.3.1 Network monitoring agent ............................................................................................... 24 3.3.2 Application monitoring agent .......................................................................................... 26 3.3.3 System monitoring agent ................................................................................................. 27 3.3.4 Behaviour monitoring agent ............................................................................................ 28 3.3.5 Kafka monitoring agent ................................................................................................... 29 3.3.6 MUSA monitoring agents final implementation ............................................................. 29

3.4 Security metrics that can be collected .................................................................................. 30 4 MUSA Security enforcement and mitigation in multi-cloud applications .................................... 32

4.1 High Availability framework ............................................................................................... 32 4.2 MUSA enforcement agents .................................................................................................. 37

4.2.1 Agent mechanism ............................................................................................................ 37 4.2.2 Agents configuration ....................................................................................................... 44 4.2.3 Agent deployment ........................................................................................................... 45 4.2.4 Agent catalogue ............................................................................................................... 46 4.2.5 Identity Management agent ............................................................................................. 48 4.2.6 Access Control agent ....................................................................................................... 50 4.2.7 MUSA enforcement agents final implementation ........................................................... 53

5 Notification ................................................................................................................................... 54 5.1 Principle ............................................................................................................................... 54 5.2 MUSA Web based notification ............................................................................................ 54


6 Conclusion ..................................................................................................................................... 56 References ............................................................................................................................................. 57 Appendix A. MUSA motivation and background ................................................................................. 63 Appendix B. The MUSA Metric Catalogue .......................................................................................... 64 Appendix C. Monitoring agents Chef recipes ....................................................................................... 89 Appendix D. Enforcement agents Chef recipes .................................................................................... 93 Appendix E. The MUSA IdM agent SLAT .......................................................................................... 96 Appendix F. The MUSA AC agent SLAT ............................................................................................ 98 Appendix G. The MUSA agent plugins configuration and interfaces ................................................ 112


List of figures

Figure 1. Network-based protection .......................................................................................................14 Figure 2. Virtual machine introspection .................................................................................................14 Figure 3. Host-based protection .............................................................................................................14 Figure 4. Distributed MMT architecture deployment ............................................................................15 Figure 5. Monitoring traffic of virtual machines ....................................................................................16 Figure 6. Monitoring based on VM Monitor ..........................................................................................17 Figure 7. MMT-based monitoring service integrated in Openstack.......................................................18 Figure 8. Taxonomy of threat detection approaches ..............................................................................19 Figure 9. Relationship between the threats and existing detection techniques ......................................20 Figure 10. MMT monitoring agent architecture .....................................................................................25 Figure 11. Application monitoring agent interfaces ...............................................................................27 Figure 12. Linux top command for system resources monitoring..........................................................28 Figure 13. Behaviour monitoring agent .................................................................................................29 Figure 14. Framework Architecture .......................................................................................................33 Figure 15. Service Lookup .....................................................................................................................33 Figure 16. Dockerized Service Startup ..................................................................................................35 Figure 17. Custom Service Startup ........................................................................................................35 Figure 18. An example of the run parameters file ..................................................................................36 Figure 19. MUSA enforcement agent mechanism .................................................................................37

Figure 20. MUSA enforcement agent architecture ................................................................................38 Figure 21. Example of a simple agent app configuration file ................................................................39 Figure 22. Agent Service System ...........................................................................................................39 Figure 23. Example of a plugin package.json file ..................................................................................40 Figure 24. MUSA enforcement agent finite state machine. ...................................................................42 Figure 25. Example of a coded JWT ......................................................................................................51 Figure 26. Example of a decoded JWT ..................................................................................................51 Figure 27. Example of XACML rules for access control .......................................................................52 Figure 28. Example of a request to connect to service ...........................................................................52 Figure 29. Example of Response produced by Access Control Agent ...................................................52 Figure 30. Web based notification in MUSA Security Assurance Platform ..........................................54


List of tables

Table 1. MUSA enforcement agents Catalogue and their Security Controls according to (NIST SP 800-

53 r4) ......................................................................................................................................................46 Table 2. Interface specification of IdM agent ........................................................................................49 Table 3: MUSA security metric catalogue - summary ...........................................................................64


Executive summary

This deliverable summarises the outcomes of three tasks of WP4, tasks T4.1, T4.2 and T4.3 where we

define different mechanisms for security monitoring, enforcement and notification adapted to multi-

cloud applications.

Section 3 presents a state of the art of existing security monitoring solutions and deployment

architectures that allow to measure different security metrics defined in multi-cloud applications SLAs.

The final aim is to learn the real-time behaviour of the multi-cloud environment and early detect the

security issues that are violations of the SLA, in order to be able to inform the multi-cloud application

DevOps team and minimize their impact. The security monitoring solution adopted in the context of

MUSA relies on the MMT (stands for Montimage Monitoring Tool) agents that are able to collect data

from network communication between distributed application components. These agents can also

monitor the VM or container system resources usage and the application internals at runtime. The

collaboration between different agents and other open source monitoring solutions deployed in different

CSPs allows the DevOps team to have better visibility on to the whole application security and the

protection and privacy of sensitive data it manage.

Section 4 describes, by relying on a state of art analysis, the needed set of security enforcement and

security risk mitigation mechanisms for the MUSA framework. Some of these mechanisms are to be

included in the MUSA Security Assurance Platform SaaS and are to be delivered as a set of embedded

libraries which will be used by the multi-cloud application components following a non-intrusive

approach. The whole set of enforcement mechanisms will work in an integrated way. The security

enforcement mechanisms are built on existing open-source solutions for data encryption, data signing,

data obfuscation etc. Through these MUSA security mechanisms, the data will be able to travel along

the application components and multi-cloud provider chain with the needed storage and handling

security policies enforced.

The last section 5, defines the principles for Web-based notification and response to detected security

issues in the multi-cloud application operation. Two kinds of notifications are defined: alerts and

violations. Alerts are notified when we are about to violate the SLA. The target of the violation as well

as the recommendation strategy to follow in order to mitigate it is also studied in this section.


1 Introduction

1.1 Objective of this document

The issue of data security and privacy in the cloud requires different solutions for implementing and

enforcing security policies. In cloud computing environments, many security aspects must be faced,

including risk management, data privacy and isolation, security-by-design applications, and

vulnerability scans etc. Moreover, it also becomes necessary to have a system that interrelates and

operates all security controls which are configured and executed independently on each component of

the system being secured and monitored.

In addition, thanks to the large diffusion of cloud computing systems, new attacks are emerging every

day, so threat detection systems play a key role in the security schemes, identifying possible attacks.

These systems handle enormous volume of information, as they detect unknown malicious activities by

monitoring different activities, from different points of observation, as well as adapting to new attack

strategies and considering techniques to detect malicious behaviours and react accordingly.

This document is deliverable D4.3 Final security assurance mechanisms and tools of MUSA project

(see Appendix A). It is part of the operation phase of the MUSA framework where we define security

mechanisms for runtime monitoring, security enforcement and alerts/violations notification included.

These security mechanisms are integrated into the MUSA Security Assurance Platform SaaS presented

in deliverable D4.4 Final MUSA security assurance platform. This platform is an external entity that

allows to monitor the multi-cloud application components already deployed in different Cloud Service

Providers (CSPs). It detects potential deviations from security Service Level Objectives (SLOs) defined

in the security Service Level Agreements (SLAs) and triggers counter-measures to enforce security

during application runtime.

The document presents the state of the art of existing security monitoring and enforcement mechanisms

and provides details about the monitoring agents integrated in the MUSA Security Assurance Platform

SaaS. It also presents two example of security enforcement agents integrated into this same platform:

The high availability framework and the XACML based access control framework.

1.2 Structure of this document

This document is composed of 4 main sections:

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

security assurance mechanisms and tool deliverable compared to the previous version.

• Section 3 presents a state of the art of existing security monitoring solutions for virtualized

environments as well as the possible deployment of such monitoring solutions. MMT

monitoring agents are presented and a list of relevant security metrics for MUSA project is

defined.

• Section 4 presents a state of the art of preventive security enforcement mechanisms that can be

integrated in cloud based environments. Two examples of such security enforcement

mechanisms are presented in detail to illustrate the mechanisms that can be offered by the

MUSA Security Assurance Platform SaaS.

• Section 5 presents the Web-based notification mechanism and the possible alerts, violations as

well as countermeasures status that are taken at runtime.

• Appendix A provides the context of the project.

• Appendix B provides the current MUSA Security Metric Catalogue.

• Appendix C provides the monitoring agents Chef recipes

• Appendix D provides the enforcement agents Chef recipes


• Appendix E offers the SLA template of the MUSA IdM agent.

• Appendix F offers the SLA template of the MUSA AC agent.

• Appendix G describes the preventive enforcement agents configuration and interfaces.

1.3 Relationships with other deliverables

The deliverable D4.3 Final security assurance mechanisms and tools presented in this document relates

on the following deliverables:

• D1.4 Final MUSA framework specification and guide: This deliverable describes the different

requirements of the MUSA framework including the security monitoring and assurance

mechanisms to be defined in WP4. This deliverable includes a step-by-step guide of the

activities needed by the assurance mechanisms to fit the MUSA approach.

• D2.3 Final SbD methods for multi-cloud applications: This deliverable describes the Security-

by-Design approach of MUSA including the multi-cloud application Security Service Level

Agreements (SLAs) concepts as well as SLA composition, security controls and metrics

relationships. The composed SLAs need to be monitored at runtime thanks to the monitoring

agents described in this D4.3 document.

• D4.4 Final MUSA security assurance platform: The security mechanisms identified in this D4.3

deliverable are integrated into the MUSA Security Assurance Platform SaaS. The D4.3 mainly

presents the security assurance mechanisms developed in MUSA for cloud and multi-cloud

based environments and D4.4 implements them and integrates them into a software solution

deployed as a service.

• D5.4 Final MUSA case studies implementation: Outcome software adapted, extended and

developed in D4.3 was integrated into the final MUSA case studies for evaluation.

• D5.5 Results of final evaluation of MUSA framework: Reports the results of the final evaluation

in MUSA including the evaluation of the assurance mechanisms described in this D4.3 and

integrated in the MUSA Security Assurance Platform.

1.4 Contributors

The following partners have mainly contributed to this deliverable:

• Tecnalia: Security Assurance mechanisms integration in MUSA framework, Enforcement

agents and service implementation and integration in MUSA Security Assurance Platform.

• Montimage: monitoring, notification and reaction services implementation and integration in

MUSA Security Assurance Platform, development coordination, integration in MUSA

framework.

• CERICT: Security metrics, Security SLAs, Security enforcement and mitigation mechanisms.

• TUT: HA enforcement agents and service implementation and integration, monitorable security

metrics.

• AIMES: MUSA Security Assurance Platform deployment support, security metrics and

notification mechanisms.

• CA: MUSA Security Assurance Platform integration in MUSA framework, security metrics,

notifications.


1.5 Acronyms and abbreviations

API Application Programming Interface ISP Internet Service Provider

HA High Availability Framework UML Unified Modelling Language

MMT Montimage Monitoring Tool URL Uniform Resource Locator

CSP Cloud Service Provider SaaS Software as a Service

SLA Service Level Agreement SLO Service Level Objective

1.6 Revision history

Version Date issued Author Organisation Description

0.1 02-Oct-17 Wissam Mallouli Montimage Initial ToC with initial content

0.2 10-Oct-17 Erkuden Rios Tecnalia Description of the MUSA

enforcement agents

0.3 26-Oct-17 Wissam Mallouli Montimage Update of the monitoring tools in

multi-cloud applications section

0.4 10-Nov-17 Samuel

Afolaranmi

TUT Detailed description of the Hight

Availability Framework

0.5 20-Nov-17 Wissam Mallouli Montimage New monitoring agents

description

0.6 22-Nov-17 Erkuden Rios Tecnalia Consolidation of the document

0.7 27-Nov-17 Wissam Mallouli Montimage Adding section 2

0.8.1 28-Nov-17 Massimiliano Rak CERICT Review 1

0.8.2 28-Nov-17 Stefan Spahr LHS Review 2

0.9.1 30-Nov-17 Erkuden Tecnalia Revised version 1

0.9.2 30-Nov-17 Wissam Mallouli Montimage Final version revised

0.9.3 01-Dec-17 Erkuden Rios Tecnalia Final version revised

1.0 01-Dec-17 Erkuden Rios Tecnalia Final release


2 Overview of revisions and additions since D4.1

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

security assurance mechanisms and tools, compared to the description of the initial version (deliverable

D4.1 Initial security assurance mechanisms and tools).

Change Section in

D4.1

Section in

D2.4

Rationale

Update in monitoring

agents deployment

architectures for multi-

cloud based applications

Section 2.1 Section 3.1 Update in the final version compared to

the initial version

Specific monitoring

deployment in OpenStack

with MMT and TAP-as-a-

service

N/A Section 3.1.4 Description of the possible combination

of TAP-as-a-service and MMT network

monitoring agent in order to supervise

simultaneously several VMs or

containers in the same tenant

Challenges in security

monitoring techniques for

multi-cloud based

applications

N/A Section 3.2.5 Issue of visibility on different clouds if

we rely only on public APIs.

New security monitoring

agents

N/A Sections

3.3.4 and

3.3.5

Description of behaviour monitoring

agent analysing deviation from a

learned model of the network usage and

a Kafla bus monitoring agent analysing

internal application components

communicating via this event bus.

Updated description of the

High availability

framework

Section 3.2.1 Section 4.1 Detailed description of the TUT High

availability framework

Updated description of

identity management and

access control agents

Section 3.2.2 Section 4.2 Detailed description of the Tecnalia

security enforcement agents


3 Monitoring tools in multi-cloud applications

3.1 Monitoring agents deployment architectures for multi-cloud based

applications

This section presents different state of the art architectures for security SLA monitoring in multi-cloud

based environment (called also virtualized environment) to guarantee security and efficiency of the

overall complex application. Besides, a list of requirements, features and challenges to be faced when

deploying this kind of monitoring solutions in real-world is presented.

3.1.1 Monitoring in virtualized environments

Monitoring is a solution that is required to ensure the correct operation of the whole system.

Malfunctioning or even minor problems in a virtual machine could introduce vulnerabilities and

instability of other virtual machines, as well as the integrity of the host machine. In MUSA, the

monitoring function is needed to be able to precisely understand what is going on in the network, system

and application levels, with a twofold objective. First, it is necessary for improving the security in the

communications and services offered by the virtual environments. Second, from the administration and

management’s point of view, it will help ensure the environment’s health and guarantee that the system

functions as expected and respects its security SLAs.

Existing monitoring solutions to assess security and performance can still be used in virtualized network

environments. Nevertheless, existing solutions need to be adapted and correctly controlled since they

were meant mostly for physical and not virtual systems and boundaries, and do not allow fine-grained

analysis adapted to the needs of cloud and virtualized networks. The lack of visibility and controls on

internal virtual networks, and the heterogeneity of devices used make many performance assessment

applications ineffective. On one hand, the impact of virtualization on these technologies needs to be

assessed. For instance, QoS monitoring applications need to be able to monitor virtual connections. On

the other hand, these technologies need to cope with ever-changing contexts and trade-offs between the

monitoring costs and the benefits involved. Here, virtualization of application component facilitates

changes, making it necessary for monitoring applications to keep up with this dynamicity.

Solutions such as Ceilometer [1], a monitoring solution for OpenStack, provide efficient collection of

metering data in terms of CPU and network costs. However, it is focused on creating a unique contact

point for billing systems to acquire all of the measurements they need, and it is not oriented to perform

any action to try to improve the metrics that it monitors. Furthermore, security issues are not considered.

StackTach [2] is another example oriented to billing issues that monitors performance and audits the

OpenStack’s Nova component. Similarly, but not specifically oriented to billing collected [3] gathers

system performance statistics and provides mechanisms to store the collected values.

A recent project from OPNFV1, named Doctor [4], focuses on the creation of a fault management and

maintenance framework for high availability of network services on top of virtualized infrastructures.

In terms of security, OpenStack provides a security guide [5] providing best practices determined by

cloud operators when deploying their OpenStack solutions. Some tools go deeper in order to guarantee

certain security aspects in OpenStack, for instance: Bandit [6] provides a framework for performing

security analysis of Python source code; Consul [7] is a monitoring tool oriented to service discovery

that also performs health checking to prevent routing requests to unhealthy hosts.

1 https://www.opnfv.org/


Enterprises with large-scale cloud implementations may require more robust cloud monitoring tools

which include specific characteristics, such as the ability to monitor multiple clouds and thus platforms

from a single point of reference, or intelligent analytics to automate processes like application lifecycle

management. High-end cloud monitoring tools should also have the ability to handle system failures

and security incidents automatically with capabilities such as self-monitoring, an explicit notification

mechanism, and include failover, self-healing and counter-measurements capabilities.

In the context of MUSA, we consider the monitoring of multi-cloud based application where each

application component can be deployed in a different cloud service provider. This architecture brings

more challenges to be able to fulfil an end-to-end security monitoring of the application execution and

communication at runtime. To our knowledge, no security monitoring solution has been designed for

such multi-cloud distributed systems. Before presenting the monitoring architecture adopted in MUSA,

we discuss in the next section the state of art possible monitoring deployments and present their

advantages and limits. Notice, that in MUSA, the monitoring solution includes the industrial monitoring

agents of Montimage called MMT (stands for Montimage Monitoring Tool). More details about this

tool are presented in section 3.3.

3.1.2 State of art on monitoring virtualized applications

To be able to assure end-to-end security in virtualized application components, a monitoring architecture

needs to be defined and deployed. This will permit to measure and analyse the network/application flows

at different observation points that could include any component of the system, such as physical and

virtual machines. The choice of the observation point depends on the monitoring objective and also the

monitoring administrator that can be one of the following actors:

• The Cloud Service Provider: Can deploy a monitoring tool (e.g., MMT solution) in its own

cloud infrastructure including servers and routers. It does have not the possibility to deploy its

solution in any virtual machine or container, but it can propose to its customers to deploy new

VMs or containers from OS images that already integrate a monitoring solution.

• The application owner: Can deploy a monitoring tool (e.g., MMT solution) in each VM or

container it deploys. A best practice is to have for each application component a monitoring

agent or a set of monitoring agents to observe different behaviours at runtime and check security

SLAs.

Setting up several observation points will help to better diagnose the problems detected. In cloud

environments, it is possible to create network monitoring applications that collect information and make

decisions based on a network-wide holistic view. This enables centralized event correlation on the

network controller, and allows new ways of mitigating network faults.

The monitoring probes can be deployed in different points of the system. Let’s consider a single

hardware entity that is controlled by a hypervisor that manages the virtual machines. A first approach

consists of installing the monitoring solution (MMT) in the host system (hypervisor) that operates and

administers the virtual machines (see Figure 1), in this way providing a global view of the whole system.

This approach requires less processing power and memory to perform the monitoring operations, since

the protection enforcement is located in a central point. In this way, network connections between the

host and the virtual machines can be easily tracked allowing early detection of any security and

performance issue. The main problem of this approach resides in the minimum visibility that the host

machine has inside the virtual machines, not being able to access to key parameters such as the internal

state, the intercommunication between virtual machines, or the memory content.


Figure 1. Network-based protection

Monitoring probes can also be located in a single privileged virtual machine that is responsible for

inspection and monitoring of the rest (see Figure 2). This approach is called Virtual Machine

Introspection (VMI) and offers good performance since the monitoring function is co-located on the

same machine as the host it is monitoring and leverages a virtual machine monitor to isolate it from the

monitored host [8]. In this way, the monitoring probes analyses the activity of the host through direct

observation of the hardware state and thanks to inferences on software state based on a priori knowledge

of software structure. VMI allows the monitoring function to maintain high levels of visibility, evasion

resistance (even if host is compromised), and attack resistance (isolation), and even enables the

manipulation of the state of virtual machines. Unfortunately, VMI based monitoring software is highly

dependent on the particular deployment and requires privileged access that cloud providers need to

authorize.

Figure 2. Virtual machine introspection

The approach that offers the best security performance is the deployment of the monitoring tools in

every virtual machine. In this way robust protection can be achieved since the security software has a

complete view of the internal state of every virtual machine, as well as the interactions with the host or

any other virtual machine. Figure 3 shows how this approach can be deployed.

Figure 3. Host-based protection

This third solution offers a good performance in terms of security even if loose visibility of hypervisor

behaviour. Here, the processing power and memory required are distributed among the virtual machines.

Furthermore, its deployment is simpler than other approaches since it can be included in the software

image of the virtual machine, so it is automatically initiated when instantiating each virtual machine


with no further configuration needed. On the other hand, the probes lose control over the physical

resources and it is impossible to monitor what happens at hardware and hypervisor level. As an example,

we can consider the case of one physical CPU shared among two virtual machines VM1 and VM2

assigned to two users U1 and U2. If the virtualization engine move CPU power from one VM1 to VM2,

assigning two-time slot to VM2 and 1 slot toVM1, VM1 will start going more slowly, but will always

perceive 100% CPU. The only way of bypassing this, is to access and monitor the hypervisor or use

their APIs if available.

Despite of the individual probes installed on each virtual machine, there is the need of a global

monitoring coordinator that supervises the monitoring tasks of each probe installed on each virtual

machine. For this, each probe must be able to directly interact with any other probe, as well as with the

monitoring coordinator. Local decisions can be taken by the individual monitoring probes installed on

each virtual machine, and the monitoring coordinator can perform coordination, orchestration and

complex event detection.

3.1.3 Distributed Monitoring Architecture for multi-cloud based applications

Considering the different monitoring deployments presented in the previous section, herein, a whole

architecture integrating monitoring probes and coordinator is presented.

Figure 4 represents a possible deployment scenario for MMT in multi-cloud environment. As depicted,

MMT probes capture performance and security meta-data from each virtual machine, and are able to

perform countermeasures to mitigate attacks and security risks. MMT probes have the capacity of P2P

communication, so they can share relevant information with the aim of increasing the efficiency of the

security mechanisms and, thus, ensure the correct operation of the whole system. To perform

coordination and orchestration of the whole monitoring system, a central MMT Operator (part of the

MUSA Security Assurance Platform) will receive information from the distributed MMT probes. The

MMT Operator is also in charge of correlating events to create reports to inform network managers of

the system activities, attacks avoided, and, countermeasures taken. Furthermore, it will be able to

globally analyse the information provided by individual MMT probes with the ultimate objective of

detecting complex situations that may compromise the system.

The architecture detailed in Figure 4 shows the deployment of MMT (MMT probes and MMT Operator)

over a set of physical hardware platforms that can be part of one or several cloud service providers. The

MMT Operator will be in charge of coordinating the diverse probes deployed in each virtual machine

and provide a global view.

Figure 4. Distributed MMT architecture deployment


Differing monitoring architectures are required to monitor various elements of the cloud stack the MMT

agents can monitor routers, firewalls etc. and these agents can only intercept data or monitor certain

elements of the cloud infrastructure or indeed application.

Often CSPs and Application providers utilise different monitoring tools to analyse different components

and aggregate the data and outputs to a single interface, however there is no intelligence behind this

approach and it is generally very inefficient.

The multi-cloud paradigm and approach means managing, and monitoring distributed applications

across heterogeneous cloud infrastructures is a challenge.

The best monitoring deployment looks at the various layers of which the MMT can intercept information

to properly target different security levels. Cloud Service Providers however will only allow limited, if

any access at all the infrastructure of which it operates. Therefore, buy in is needed both by the cloud

consumer and the CSP to allow these different monitoring architectures to both co-exist and to allow

the MMT to use this data to present it back to the consumer.

In the context of MUSA, we position ourselves from the application DevOps team and we consider that

we can only control our application. For this reason, we only consider at this stage, the deployment of

MMT in different VMs or containers where the application component is running.

3.1.4 Specific monitoring deployment in OpenStack with MMT and Tap-as-a-

Service

The following Figure 5 depicts a simple scenario where a user in tenant X wants to monitor the traffic

of virtual machines in this tenant. The two virtual machines VM1 and VM2 are hosted in two different

compute nodes. The user cannot access to Compute host to monitor the traffic because the two compute

nodes host also two other tenants Y, Z.

Figure 5. Monitoring traffic of virtual machines


Tap-as-a-Service (TaaS)2 is a project developed to provide a network service by mirroring network

traffic from the port of virtual machine to another port. The main idea of TaaS is to copy each packet

in/out the virtual machine via the port and transfer to another port. In the precedent scenario, we will

create a new virtual machine VM Monitor (shown in Figure 6), then, by using TaaS, we will copy and

transfer the traffic in/out of VM1 and VM2 from Port 1 and Port 2 to Port M. From now, the VM Monitor

receives every packet in/out VM1 and VM2, hence, it can monitor the traffic in Tenant without access

to Compute hosts. However, TaaS just provides the mirroring service, in order to monitor, analyze and

secure the tenant, so one needs to deploy the VM Monitor (provided by MMT, Montimage Monitoring

Tool).

Figure 6. Monitoring based on VM Monitor

As mentioned above, in order to monitor Tenant X, we must implement MMT in OpenStack. TaaS has

given a help by providing the Tap-Service. In the new virtual machine, VM Monitor, we will deploy a

MMT Probe, to monitor not only the traffic of VM Monitor but also the traffic of VM1 and VM2. The

deployment of MMT Probe in a virtual machine is as simple as in a physical machine. Then, the MMT

Probe can communicate with MMT Operator thanks to the public IP given by OpenStack. From this

point, the user can comfortably monitor traffic in tenant X (shown in Figure 6).

TaaS is developed as a plugin of Neutron and provides an API3. In order to observe the whole system

automatically, we will provide a MMT Service which communicates with Neutron API and TaaS API.

MMT Service will observe and compare the ports of OpenStack via Neutron API and the ports will be

mirrored by the TaaS via the TaaS API as illustrated in Figure 7. If a new virtual machine is created, a

new port will be also created and the MMT Service will then create a mirroring service in this port by

using TaaS API. The MMT Service can also be implemented directly in a dedicated monitoring virtual

machine, which helps simplifying the deployment of MMT in OpenStack. This work will be continued

in after MUSA project to validate the solution proposed, determine its portability to other virtual

platforms besides Open Stack, and show its efficiency/ adaptability to the different use cases: Security

2 Tap-as-a-Service (TaaS): Port Monitoring for Neutron Networks. Alan Kavanagh, Anil Rao, Vinay Yadhav,

OpenStack Summit, Vancouver, Canada, May 20, 2015. https://www.openstack.org/summit/vancouver-

2015/summit-videos/presentation/tap-as-a-service-taas-port-monitoring-for-neutron-networks 3 Tap-As-A-Service API. https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst


SLA assessment, SIEM scenarios and IDS/IPS functions. The results will be the basis of the Software

Defined Monitoring function that will allow selective inspection of virtualised network traffic.

Figure 7. MMT-based monitoring service integrated in Openstack

3.2 Security monitoring techniques for cloud based applications

Threat detection systems in cloud based environment usually correspond to a hardware device or

software application that monitors activity (e.g. network, host, user) for malicious policy violations.

Several characteristics of detection systems are well defined in literature ([9]-[17]), among those, fault-

tolerance, real time execution, self-monitoring, minimum operational, interoperability, self-

adaptiveness, scalability, etc.

Zbakh, M. et al evaluated in [18] several IDS architectures through proposed multi-criteria decision

technique, according to the above introduced requirement together with few others such as

● Performance,

● Availability (CSA inspired criteria)

● Service level expectations,

● Secured and encrypted communication channels,

● Accuracy, including the number of false positives (FP), false negatives (FN),

● Detection methods used, etc.

According to such literature, IDS architectures may vary if they are distributed, centralized, agent-based

[19] or collaborative; also, the positioning of various observation points also defines various types of

architectures (Section 3.1). In general, data collection and preparation are performed through a sensor

or existing database which works as an input for the data analysis and detection. The latter engine

corresponds to the module of the algorithms implemented to detect suspicious activities, detailed in the

following sections and showed by Figure 8.


Figure 8. Taxonomy of threat detection approaches

3.2.1 Pattern-based approach and techniques

Also known as signature-based or knowledge-based or misuse-based techniques, this approach acts upon

a set of rules which define a threat pattern. They have a high level of accuracy (i.e. low FN and FP), but

are limited to only known attacks. Therefore, pattern-based techniques cannot detect variants of known

or unknown attacks. On the other hand, keeping signatures’ databases updated may be a hard task.

Latest research focuses in facilitating cloud administrators the discovery of new attack patterns by

updating signature databases more easily. To assess this automatic and offline analysis, Inductive Logic

Programming was proposed by Hamdi et al. [20], while Huang et al. [21] used Growing Hierarchical

Self Organizing Maps (GHSOM) for the characterization of attack signatures. Other techniques are

grouped as rule-based and state based techniques presented in the following.

3.2.1.1 Rule-based techniques

For known or variant of known attacks, context rule-based techniques have been considered in several

research publications. In particular, Katz et al. [22] addresses data leakage threat, considering a context-

based detection of confidential documents and sections of confidential information embedded in non-

confidential documents. In detail, the corresponding rule-based techniques are:

• Watermarking: data breaches may occur in any of the data cycle and digital watermarking is a

reviewed technique for detecting data tampering. Garkoti et al. [23] introduced spacial domain

watermarking, encryption, and logging modules for clinical data.

• Fingerprinting was considered for malicious insider threat detection by Gupta et al. [24] through

the analysis of well-known programs and the malicious modification of their system call

sequences, as fingerprints, executed in the hypervisor. Provable Data Possession (PDP) is often

related to data losses and preserving data integrity over a client prepossessing the data and then

sending them to the cloud for storage while keeping a small amount of meta-data for later

checking. The classical idea behind this technique can only be applied to static (or append-only)

files. Hence, Erway et al. [25] presented a framework and construction for Dynamic Provable

Data Possession, which extends the PDP approach with the support provable updates to stored

data, using the new version of authenticated dictionaries based on rank information.

• Sequence alignment, while commonly used in bioinformatics, was proposed by Kholidy et al.

[26] for account or service hijacking threats, in specific for masquerade attacks. They introduced

Heuristic Semi-Global Alignment algorithm, which tests matching patterns of user’s session

sequences (e.g., mouse movements, system calls, opened windows titles, written commands,

opened file names) with the previous stored arrays.

3.2.1.2 State-based techniques

In relation with insider threats and further potential data related threats, Kumar et al. [27] considered a

method relied in well-known Bell-LaPadula model which aims to determine the identity of the internal


organization user who leaked data. The idea defines states, as the allowed access mode to any subject,

with any object allowed, with respect to a defined security policy. This model is built on the concept of

state machines with a set of allowable states. Various cryptographic and watermarking techniques can

be applied, to identify the internal user involved in the leakage.

Figure 9. Relationship between the threats and existing detection techniques

The described detection groups correspond to content-based techniques since they test ’known or

accepted’ action patterns. Therefore, data related threats are more deeply linked to these groups as they

may have low occurrences, and other techniques more prone to volume based identification of misuses

(e.g. statistical), may carry high FP rates. Additionally, hijacking threats such as masquerading attacks,

are subjects of study. These links can be seen in Figure 9 where rule-based and state-based techniques

share relations with the previous mentioned threats.

3.2.2 Behaviour-based approach and techniques

Also known as anomaly-based detection, this approach involves the collection of data in order to

construct a model of normal behaviour and then test new observed behaviours against potential

anomalies. An important aspect of the anomaly-based approach is the nature of the anomaly. Anomalies

are classified as point, contextual and collective anomaly.

The first one (point anomaly) consists in a single data event deviating from normal pattern of the dataset.

Contextual anomaly, on the other hand, exemplifies point anomaly within a particular known context.

The latter (collective anomaly) happens when a collection of similar data events behave anomalously

with respect to the rest of the dataset, where the group of data events defines a collective anomaly.

Techniques used for behaviour-based threat detection rely on the criteria adopted to model and identify

behaviour classified as normal and behaviour classified as suspicious. Therefore, existing techniques

can be grouped with respect to the way how such behaviours are analysed.

3.2.2.1 Statistical techniques

Statistical approaches are in general predefined by a threshold, first order statistics or probabilities, in

order to identify anomalies. One example is for a type of Denial of Service (EDoS) issued by [28], where


the authors study user demands against thresholds over duration parameters as the maximum number of

requests beyond when the auto-scaling feature is activated.

Non-parametric techniques also take place when the system observes the activity of subjects in terms of

statistical distribution and creates profiles which represent their behaviours for later comparison (i.e.

correlation). Shirazi et al. [29] presented a memory-less technique based in a non-parametric Cauchy

function, recursively updated upon the signal at the previous step. Entropy based techniques focus on

measuring the uncertainty or randomness associated with a random variable. For network flows,

comparing the rate of entropy of some packet header fields with another sample of the same nature

provides a mechanism for detecting changes in the randomness. For DDoS attack detection, Jeyanthi et

al. [30] proposed a cross-layer implementation where first component analyzes incoming traffic rate and

is handed to entropy profiler if acute. Sharma et al. [31] proposed a source and MAC address threshold

based analysis for incoming packet rate. Same threats concern and approach was followed in [32] where

the authors proposed to investigate VM status in real cloud environment based on OpenStack, arguing

on the fact that the malicious VMs share similar attack patterns.

Shape analysis is utilized for detecting shared technologies threat, as seen in Figure 9. For example, in

[33], the authors combined a two-stage detection mode based on shape tests which are used to extract

the attack features from the cache miss sequence, and regularity tests used to extract the attacks features

from virtual CPU utilization sequence and virtual memory utilization sequence. Bates et al. [34]

addressed covert side channel threats by detecting network flows watermarking. A Principal Component

Analysis (PCA) was used by Marnerides et al. [35], not only to reduce datasets dimensionality but also

to separate the normal data from anomalous.

Signal decomposition techniques such as Ensemble Empirical Mode Decomposition (E-EMD) were

presented in [36]. The authors proposed a data-driven method for malware, motivated by the fact that

the algorithm can sufficiently decompose and describe clouds’ non-linear and non-stationary traffic.

Catastrophe theory explores that systems can respond to continuous changes in control variables by

producing sudden, drastic and discontinuous changes from one equilibrium state to another (e.g. from

normal state to anomalous). A catastrophe potential function was introduced by Xiong et al. [37], in

order to describe the dynamic process in cloud network traffic.

3.2.2.2 Machine learning based technique

Machine learning techniques generally refer to the technique where we continuously analyse historical

behaviours (of an application or system) in order to detect deviations from a specific baseline that we

learned (can be static or dynamic base line). This technique permits to improve the detection capability

by learning from previous results. In this subsection, we group these techniques with respect to their

underlying models for detecting security threats in the clouds.

Decision trees are used in [38], addressing an unsupervised clustering algorithm for unlabelled data.

After labelling, a decision tree based analyser with Incremental Tree Inducer model is trained, updating

itself.

SVM technique was proposed by Watson et al. [39]. They studied an online novelty implementation of

a supervised one-class SVM algorithm, an extension of traditional two-class SVM which outputs either

a known class (VM normal behaviour) or unknown classes to the classifier, for each particular input

vector.

Artificial Neural Networks expose their accuracy based on the configuration of their hidden layers and

training phase. Based on different feed forward neural networks with back propagation algorithm,

Pandeeswari et al. [40] evaluated the error of the different ANN, with a fuzzy aggregation module is

used to combine the different neural networks results. A Synergetic Neural Network (SNN) was

addressed by Xiong et al. [41], given the dynamicity of the network traffic. Their argument relies in that

under some situations, the changing trend of the cloud-based network traffic is only determined by a

few primary factors and less contribution of others.


3.2.2.3 Clustering techniques

Clustering is utilized under the underlying assumption that ’normal’ data instances lie distance-wise

closer to a given centroid of a cluster, whereas anomalous data points are recognized due to their much

longer distance.

K-means technique was followed by Marnerides et al. [42], while showing it is directly affected by live-

migrations. In this testbed they detected DoS and netscan threats successfully when arose, but also

achieved high scores when only migration and normal traffic occurred. The same clustering idea was

used in the dimension reasoning technique (based on Local Outlier Factor) that was suggested for

memory leakage, and malicious port scan, by Huang et al. [43]. GHSOM techniques were also addressed

by Li et al. [44], by proposing a cluster system that identifies nmap4 malicious behaviours in VMs

through system call distributions and secondly, derives rules for SVM detection.

3.2.3 Hybrid-based approach

Depending on the architecture and a set of threats to be detected, the use of techniques in Cloud

architecture can require a hybrid approach [45][46][47][48].

While signature-based approach is more rigorous in its detection, behaviour-based methodology is able

to ’learn’ new threats. Therefore, the combination of previously mentioned approaches in Sections 3.1

and 3.2 and may reach a more extensive and accurate detection. As an example, Modi et Patel [46], used

SNORT5 for signature-based detection, whereas for anomaly-based detection they focused in Bayesian,

associative and decision tree classifiers.

Another way of analysing incoming IP packets was done by Shamsolmoali et al. [47] in a two-stage

detection: their system extracts the Time to Live value and computes the number of hops the packet has

travelled, and then packets headers are analysed for anomaly in the normal trained database.

3.2.4 Data acquisition

3.2.4.1 Monitoring design considerations

Depending on the type of threat, some of them may be visible depending on the network, host or

hypervisor based monitoring positioning. As it relies on the type of threat intended to detect, the

monitoring layers can be classified as follows:

• Network-based monitor activity of network traffic, mostly IP and transport layer;

• Host-based (HIDS) running on individual hosts or devices on the network;

• Hypervisor-based capturing virtual machine introspection in order to gather system-specific

features (e.g. process list, threats count, number of open ports);

• Cross-layer based related the monitoring from any combination of the previously mentioned.

Deploying design of threat detection system devices in the cloud infrastructure is very relevant. As

mentioned in [49], CSPs have to take into account if the used services are compromised, if hosts are

used to attack other victims or if the detection system itself is under attack. Therefore, it is useful to

design a detection component concerning each end-user and deploy a collaborative communication

exchange between detection nodes. If the detection system is used to monitor a VM host on the host

itself, it cannot be guaranteed that the system (e.g. HIDS) works properly when the host is compromised,

as the attacker could have modified it not to send any reports. For data related threats at upper levels,

4 https://nmap.org/ 5 https://www.snort.org/


HIDS may need to have separate configurations for each end-user client. Furthermore, a detector

associated with a specific VM should be sufficiently lightweight to travel with the migrating VM.

By covering a wide range of threats numerous detection systems are deployed; in fact, these systems

may have significant performance. In should be noticed that some studies have addressed this topic (see,

for example [50]) by processing data in parallel with MapReduce techniques.

3.2.4.2 Datasets

Evaluating the effectiveness of a given detection technique against specific threat (or their groups) is

mainly performed through corresponding experimentation. That is the reason, why building a proper

dataset that contains ’normal’ and abnormal behaviours with respect to different threats and taking

account various monitoring abilities, always remains a challenging problem.

Most commonly used datasets reviewed for cloud threat detection are: KDD Cup 99 [51][52][53][54],

DARPA 2000 [51] and self-generated testbeds [55][56][57][58][59].

Due to threat analysis and multiple layer vulnerabilities concerned, it may be intuitive to conduct the

use of joint datasets as mentioned in the previously cross-layer based system. Nevertheless, this decision

should concern techniques used and performance when analysing. Having high dimension vectors may

add higher complexity, and the correct election of the characterizing features is key. For instance,

Watson et al. [59] studied that raw system level—per process—features (e.g number of threats, memory

usage), are not useful if considering each sample as a single feature vector. They built statistical meta-

features of each feature across all processes. They also used one class SVM technique with system and

network data, while detection was no more effective than when analysed separately (only 10%

improvement).

As for tools for collecting data, for network level existing software like Wireshark, MMT tool, Bro,

CoralReef and tcpdump6 are considered. Hypervisor tools like libVMI and Volatily. System log tools in

the other hand, are held by Ntrace and Strace [24], while OProfile, which uses event-based sampling

[33].

3.2.5 Challenges

Security monitoring is a key component in gaining the visibility necessary to identify incidents quickly

and having the information necessary to respond and remediate. Monitoring any environment is difficult

but there are additional challenges that crop up for cloud and multi-cloud based application that are not

easily overcome, primarily when it comes to monitoring parts of the infrastructure in the control of the

provider and not of the data owner or subscriber. One major challenge in gaining visibility into what is

happening in the cloud environment is the inability to analyse network traffic and perform basic packet

capture or install intrusion detection systems.

As an alternative to monitoring activity in this way, there have been new cloud access security

technologies that leverages APIs to constantly query a particular cloud service to log every activity that

happens in the instance of the cloud. With this type of monitoring activity, there are indicators of

compromise that can be identified and reported as anomalies. In addition to calling out these anomalies,

such as logging in with the same credentials at the same time from geographically disparate regions,

these security technologies can also implement some machine learning algorithms to trend the behaviour

of every user and alter when something out of the ordinary happens.

Every cloud provider publishes a subset of APIs that allows subscribers to query the cloud instance for

different data; the problem arises when the subscribers has a need to monitor more granular information

6 www.tcpdump.org


than what the provider’s API supports. If sufficiently granular security information is available, it can

be compared to activity provided by threat feeds and watch lists, which can provide insight to malicious

behaviour that has been observed in other customer and cloud environments. These technologies and

techniques should be implemented in addition to the regular security monitoring tools used to monitor

traditional IT infrastructure. This kind of analyses is possible in the context of MUSA project, since, we

rely on different agents to collect different metrics that are relevant for security SLOs verification.

3.3 MUSA monitoring agents

To be able to deeply analyse security, in MUSA we rely on different agents to be installed in different

VMs or containers where application components are deployed. These agents collect data coming from

network, from system and from application internals and send them to a global monitoring platform

called MUSA assurance platform part of the MUSA framework. The deployment of such monitoring

agents is done systematically when an application component is deployed. The CAMEL model

describing the application composition already integrate them (ref. deliverable D1.4) and the MUSA-

Deployer (ref. deliverable D2.3) using Chef has the necessary cookbooks (ref. Appendix C) of different

monitoring agents to be able to deploy them automatically on different VMs and containers. More details

about these agents are presented in the following subsections.

3.3.1 Network monitoring agent

The MUSA monitoring agent [60] is based on MMT monitoring solution (MMT stands for Montimage

Monitoring Tool). It is a monitoring solution that combines a set of functionalities presented in the

following list:

• Data capture, filtering and storage,

• Events extraction and statistics collection, and,

• Traffic analysis and reporting providing, network, application, flow and user level visibility.

Through its real-time and historical views, MMT network agent facilitates network performance

monitoring and operation troubleshooting. With its advanced rules engine, MMT monitoring agent can

correlate network events in order to detect performance, operational, and security incidents.

MMT monitoring agent is composed of a set of complementary, yet independent, modules as shown in

the following Figure 10.


• Traffic Analysis

• Flow Identification

• Flow Classification

• Information extraction

DPI

Packet

Pa

cke

t C

ap

ture

En

gin

e

Pa

cke

t F

ilte

rin

g

Montimge Monitoring

Tool Probe

Security Analysis

QoS Analysis

Extraction rules

Events

KPI extraction

Traffic Statistics

Figure 10. MMT monitoring agent architecture

MMT-Capture: allows the capture of network packets based on the libpcap library.

MMT-Filter: is a basic filtering capability provided by MMT monitoring agent that permits to focus

on only some specific types of traffic depending on the usage of the network probe.

MMT-DPI is the core packet processing module, it is a C library that analyses network traffic using

Deep Packet and Flow Inspection (DPI/DFI) techniques in order to extract hundreds of network and

application based events, measure network and per-application QoS/QoE parameters and KPIs. The

MMT-DPI library has a plugin architecture. It is possible to extend the extraction engine with new

protocols and also add new security metrics. For this, a plugin needs to be created specifying the

extraction to add. An MMT-DPI plugin will initialize a protocol structure that contains the required

information regarding the protocol attributes, as well as the functions allowing extracting the data

corresponding to these attributes. In the context of MUSA, a set a security metrics has been identified

and integrated in MMT monitoring agent to be able to report them to the MUSA Security Assurance

Platform. These extracted metrics are important to be able to perform security analysis of the

communication between different application components and detect potential security flaws.

MMT-Security is an advanced rule engine that analyses and correlates network and application events

to detect performance, operational and security incidents. It is powered with self-learning capabilities to

derive the baseline network for dynamic threshold based analysis and potential Deny of Service (DoS)

attacks detection.

MMT-QoS is an interesting module in MMT monitoring agent that allows providing a certain visibility

on the quality of the network in terms of different KPI like delays, jitter, response time etc.

The implementation code of this agent is available in MUSA public source code repository following

this link:

https://bitbucket.org/musateam/musa-assurance_platform-

monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Network-System/

Inside the MUSA public source code repository in BitBucket.org:

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

https://bitbucket.org/musateam/musa-assurance_platform-monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Network-System/




3.3.1.1 MMT Features

MMT allows granular traffic analysis capabilities through the ability to extract a wide range of network

and application based traffic parameters and events (RTT, jitter, loss, HTTP response time, etc.). It

permits application classification making possible the detection of applications using non-standard port

numbers.

Besides, MMT has a powerful rule engine: that allows the detection of the occurrence of complex

sequence of events that conventional monitoring does not detect. This can be used for example to

monitor the access control policy (authorized users are authenticated prior to using a critical business

application), for anomaly or attacks detection (excessive login attempts on the application server),

advanced performance monitoring (identification of VoIP calls with QoS parameters exceeding

acceptable quality thresholds), etc.

In the context of MMT monitoring, DPI (Deep Packet Inspection) and DFI (Deep Flow Inspection) are

used to help detect and tackle harmful traffic and security threats as well as security SLA violation in

Cloud based environments. We define a set of security properties for network traffic, at both control and

data levels, to catch interesting events. Indeed, based on the defined security properties, we register the

attributes to be extracted from the inspected packets and flows. These attributes are of three types:

• Real attributes: They can be directly extracted from the inspected packet. They correspond to a

protocol field value.

• Calculated attributes: They are calculated within a flow. Packets from the same flow are grouped

and security/performance metrics are calculated (e.g. delays, jitter, packet loss rate) and made

available for the MUSA Security Assurance Platform.

• Meta attributes: These attributes are linked to each packet to describe capture information. The

time of capture of each packet (timestamp attribute) is the main meta attribute in the current

version of MMT monitoring agent.

3.3.2 Application monitoring agent

The role of the MMT-Application agent is to deliver information about the internal state of the target

system i.e. multi-cloud application component to the MUSA Security Assurance Platform during its

operation. It continuously checks and monitors application health. It notifies the MUSA Security

Assurance Platform about measurements of execution details and other internal conditions of the

application component.

The application monitoring agent is a Java library built of two parts. The first part is an aspect to be

weaved into the application code via pointcuts in order to send application-internal tracing information

to the MUSA Security Assurance Platform for analysis. It is composed of a set of functions that can be

weaved in strategic application points to capture relevant internal data. The second part connects the

aspect with the notification tool via a connector library and it provides a simple interface to send log

data to the MUSA Security Assurance Platform in a secure way. In other words, the application

monitoring agent is responsible for extracting the information from the system, and the MMT connector

is responsible for transferring it.

The application monitoring agent has two interfaces connecting it to the MUSA framework as shown in

Figure 11.


Figure 11. Application monitoring agent interfaces

• The application monitoring library is deployed as a Java AspectJ package. It is statically woven

into the target application at compile time using AOP. It connects to the application monitoring

agent based on annotations inserted into the source code base.

• The output of the application monitoring agent, a peek into the internal state of the monitored

system, is sent to the MUSA Security assurance platform. This platform is accessed using the

MMT Connector library, which provides a one-way secure channel for sending log messages.

It consumes a list of name-value pairs of textual data. The MMT Connector uses HTTPS for

communication.

To use the application monitoring library, it must be woven into the target application, and the target

source code must be annotated, using standard-like Java annotations (e.g., @Monitor). During operation

of the target application component, the application monitoring library produces a stream of log

messages. The developers can specify measurement points that generate data which is sent to the MUSA

assurance platform. Measurement points can be attached to classes, methods and attributes and depends

on security metrics to be monitored. More details are available following this link:

https://github.com/MUSA-Project/MMT_Annotations


this link:


monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Application/



3.3.3 System monitoring agent

MMT-System agent monitors system resources which may be the cause of server performance

degradation, like CPU, memory and disk accesses, and spots performance bottlenecks early on.

MMT-System agent relies on Linux “top” command (as shown in Figure 12) which is used frequently

by many system administrators to monitor Linux performance and it is available under many Linux/Unix

like operating systems. The top command used to display all the running and active real-time processes

in an ordered list and updates it regularly. It displays CPU usage, Memory usage, Swap Memory, Cache

Size, Buffer Size, Process PID, User, Commands and much more. It also shows high memory and CPU

utilization of all running processes. The top command is much useful for system administrator to monitor

and take correct action when required.


this link:


monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Network-System/



https://bitbucket.org/musateam/musa-assurance_platform-monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Application/

https://bitbucket.org/musateam/musa-assurance_platform-monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Application/






Figure 12. Linux top command for system resources monitoring

3.3.4 Behaviour monitoring agent

It is common for many security tools to first learn the behaviour of users, systems and networks before

they start generating alerts for unauthorized activity. This type of behavioural detection goes beyond the

black anomaly and creates profiles for each object/user using the cloud. Where it might be normal for

an administrator to transfer 10GB of data every day to and from the cloud and no alarm sounds, a typical

end user performing the same action would fire an alarm because they have never performed that type

of action before.

The behaviour analysis agent in MUSA relies on the DPI (stands for Deep Packet Inspection)

functionality of MMT that allows to identify the main application running in each network flow. Indeed,

information of a network flow indicates the IPs source and destination, the ports source and destination

and the hierarchy of protocols used. For instance, we can have Facebook running on HTTP on TCP on

IP on Ethernet. We also have the starting timestamp of the flow and the ending timestamps as well as

the volume and number of packets.

This typical information allows us to derive a profile for each IP address using the cloud application and

any deviation or change in this usage profile can be notified.

In the context MUSA project, the profiling is based on the volume of data for a specific category of

application. The change in the profile depends on a configuration rule defining the reference period of

analysis (e.g., the last 10 Mondays mornings from 8h to 12h) that is shifting in time. The comparison

between two periods of time permits to compute the deviation and raise an alarm is this deviation goes

beyond the threshold. The Figure 13 shows an example of report provided by the behaviour monitoring

agent.


this link: https://bitbucket.org/musateam/musa-assurance_platform-behaviour_agent



https://bitbucket.org/musateam/musa-assurance_platform-behaviour_agent



Figure 13. Behaviour monitoring agent

3.3.5 Kafka monitoring agent

This monitoring agent allows to synchronise events in an application Apache Kafka [66] event bus with

the Security Assurance Platform (SecAP) event bus. Basically, it subscribes to relevant application

internal events and resend them in a secure way to the remote event bus of SecAP. More analysis of

such event is performed there.


this link: https://bitbucket.org/musateam/musa-assurance_platform-

monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Bus/



3.3.6 MUSA monitoring agents final implementation

3.3.6.1 Prerequisites and installation

The MUSA monitoring agents work together with the monitoring service of the MUSA Security

Assurance Platform. These agents are available in the MUSA public source code repository in

BitBucket.org following this link:

https://bitbucket.org/musateam/musa-assurance_platform-monitoring_agent

The user can find more information about the monitoring agents there, in the README.md files.

3.3.6.2 Usage guide

The monitoring agents are deployed automatically with the application component using MUSA-

Deployer.

The final version of the MUSA Monitoring is available in the MUSA website under Tools menu,

www.musa-project.eu. The final MUSA monitoring agents’ software is also available in the public

bitbucket of MUSA as explained in next section.

The use of the MUSA agents is integrated within the MUSA Security Assurance Platform Monitoring,

which is explained in detail in deliverable D4.4 Final MUSA Security Assurance Platform and User

manual. To avoid redundancy, please refer to the guide available in this deliverable.

https://bitbucket.org/musateam/musa-assurance_platform-monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Bus/

https://bitbucket.org/musateam/musa-assurance_platform-monitoring_agent/src/8342fcce9ddc6159c03c6590451e69882038b487/MMT-Bus/



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


3.3.6.3 Source code repository

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

the following MUSA bitbucket public repository:


3.4 Security metrics that can be collected

As mentioned in deliverable D2.1, MUSA adopts and extends the Security Metric Catalogue developed

in the SPECS project [61], which defined a model for metric representation and proposed a set of

security-related metrics that were relevant for the project.

The initial set of security metrics available in the catalogue has been reviewed and enriched by MUSA

by (i) taking into account the metrics that have been proposed by standardization groups (e.g., in the

Special Publication “Performance Measurement Guide for Information Security” by NIST [62] and in

the “Consensus Security Metrics v1.1” by the Center for Internet Security (CIS) [63]) and by other EU

projects (such as Cumulus [64] and A4Cloud [65]), and by (ii) introducing specific metrics relevant to

the MUSA case study applications.

The result of this collection and analysis process is the catalogue reported in Appendix B, which

represents the current MUSA Security Metric Catalogue. Note that the final version of the catalogue

will be available only at the end of the project and that this is still a draft version.

Collected metrics are heterogeneous in that they significantly differ one from the others based on

different aspects.

Some of the identified metrics actually give information on the "level of security" of the system under

observation by taking into account the detection of specific events of interest (e.g., number of detected

attacks or of mitigated vulnerabilities). These metrics can be typically monitored with classical

monitoring tools and give information on how well the system was configured or on how much the

system is at risk.

Usually, these “technical” monitorable metrics may be used by a customer to specify his/her

requirements in an SLO (e.g., the customer may require that the percentage of incidents reported within

required time frame is 100%).

It should be noted, however, that it makes sense to use a metric of this kind in an SLO only if the

customer is provided with the means to monitor it (directly or indirectly) and if the desired value (or

range of values) set for the metric is someway under the control of the provider (e.g., it makes no sense

to set an SLO like “number of attack attempts<100” because the provider cannot control the behaviour

of attackers but only limit the resulting damage).

A different class of metrics is the one of “management” metrics, which refer to the way an organization

sets-up its security policies and procedures and handles security incidents (e.g., cost of incidents,

notification of incidents, level of automation in the procedures adopted by the organization for recording

the privacy training sessions of its employees, etc.). These metrics may be used in SLOs since they

represent high-level requirements that target organization aspects and can be “measured” by simply

checking how the system is configured. Also, they may be used to configure the target system, when

possible, with the parameters defined by the customers.

This introduces the third type of metrics, namely the “enforceable” metrics: they are preferably used for

the enforcement of specific security configurations (e.g., the “HTTPS_ON” metric identifies whether

the automatic redirect from HTTP to HTTPS is implemented) and can be “measured” by simply

checking the current system configuration.

Finally, technical metrics (both monitorable and enforceable) can refer to different application domains:



• Data protection: these metrics refer to the protection of data in transit or at rest (e.g., data

availability);

• Communication protection: these metrics refer to the protection of (HTTP) communications

(e.g., use of HTTPS in communications);

• SW component/system protection: these metrics refer to the protection of a SW component or

a SW system (e.g., frequency of vulnerability scans).

Metrics have been classified also based on the Abstract Metrics of reference. An Abstract Metric is a

metric that defines an abstract standard of measurement used to assess a property and therefore describes

what the result of the measurement means (e.g., frequency of operation, cost, feature activation etc.).

All the abstract metrics considered are reported in Appendix B.


4 MUSA Security enforcement and mitigation in multi-cloud

applications

Prevention, monitoring, detection, and mitigation generally illustrate the defense life-cycle. Prevention

involves the implementation of a set of defenses, practices, and configurations prior to any kind of

attack, with the aim of reducing the impact of such attack. These issues could be addressed by network

security, data protection, virtualization and isolation of resources. Traditionally, well-known

countermeasures have focused on dealing with threats through a variety of methods devised around

questions such as where is the attack detected? How is the attack detected? What is the response

mechanism? Where to apply the response mechanism? Where is the control (decision) center from which

filtering rules are taken?

In this section, we will describe a set of security enforcement agents part of the MUSA framework that

are relevant to the MUSA case studies. The first agent is used to ensure availability of data and services

(e.g. against a deny of service attack or a service/server failure) and the other are related to identity

management and access control.

4.1 High Availability framework

High Availability framework (HA framework), designed and built by TUT, is a cloud-oriented open-

source HA solution that aims to provide enhanced service availability without source code modification.

It is capable of handling service failures and dynamic routing in cloud environment even if the deployed

component does not have any HA capabilities.

The HA framework is a collection of software tied together with additional patches and automated

deployer. It provides reliability, scalability and availability to production services.

The main components of the framework are:

• Corosync - provides cluster messaging

• Pacemaker - resource manager

• Docker - container deployment environment

• HAproxy - acts as a lookup proxy for location-agnostic routing

• Nginx - acts as a security gateway

• Consul - keeps runtime configuration

• Gliderlabs Registrator - listens to the Docker socket and publishes events into Consul

• Consul_template - writes and manages runtime configuration


Figure 14. Framework Architecture

Figure 1 illustrates the architecture of the framework with respect to an example service that we are

calling “Service A”. In the example, service A is deployed in a node called Node A. Node A is one of

many similar nodes in a cluster. Figure 2 illustrates the lookup of a service B by another service A.

Figure 15. Service Lookup


In simple words, the HA framework checks the status of each services and nodes periodically for any

failure. In case of any failure, the services in the failed node are all restarted in another available node

in the cluster and the directory is updated immediately. This mechanism is implemented by several

software pieces working in collaboration with each other to provide a failure tolerant system. The

tolerance increases as the number of nodes in the cluster increases. The framework supports horizontal

scaling where additional nodes can be added as per the requirement.

Pacemaker detects application and recovers machine failures. It holds the configuration of all resources

in a Linux Cluster. In case of failure of one of the nodes, Pacemaker will detect the failure and start

configuring another node with similar environment and services.

Corosync is used here as communication system that enables all the nodes in the cluster to transfer

information between them. Corosync Communication System enables all of the nodes to know the exact

state of each other at all time. In case one of the Linux Cluster nodes fails this information will be

immediately transferred to other still existing Linux Cluster nodes.

Whenever a new service is added, the Gliderlabs Registrator discovers it from the docker socket and

reports it to be added to the directory. This makes it possible for any new services to be found regardless

the node they are deployed in.

The secure gateway (secure GW) act as an additional layer of security implemented with Nginx. The

lookup proxy implemented with HAproxy provides load balancing feature for the deployed applications.

Whenever a service is requested, the directory is checked and the request is redirected to the appropriate

node containing the requested service. The exact location of the requested service need not to be known

explicitly for it to be found. Only the address of the central or manager node need to be fixed which can

be easily retained and made fault tolerant too using an elastic IP.

Depending upon whether a service can be dockerized or not there are two methods to startup a service.

Dockerized service deployment

The easiest way to deploy the service can be used under the following conditions:

• The service is dockerized

• The service supports basepath setting

• The service operates over HTTP

In this case, the deployment can be carried out with the following steps:

• Upload the docker image to all nodes.

• Load the image into the server's docker instance.

• Create a new resource in pacemaker to load the service.


Figure 16. Dockerized Service Startup

Custom HTTP service Startup

It is used when the service can't be dockerized, or if it does not support basepath.

• Upload/install service to those nodes where it should be able to run.

• Add access port mapping to the K/V storage. Payload (port) here is an EXTERNAL port for

apps to request the API (where HAproxy listens).

• Create a service description file for Consul. Template follows. Port here is an INTERNAL port

used by HAproxy and Nginx.

• Reload consul config

• Create OCF script if needed

• Create a new resource instance. Example: TestApp resource (custom OCF)

• Configure constraints where the service should be able to run

Figure 17. Custom Service Startup

This HA framework can be deployed using Chef and includes the following steps:

• Designate one machine as a Chef server

• Download the recipe to this machine


• Install all needed Ruby gems

• Fetch all needed cookbooks

• Prepare the run parameters file for the node (Figure 18)

• If a built-in certificate generator is to be used create a certification authority (CA) using chef_ssl

• Bootstrap the node specifying the recipe

• Sign generated certificate requests using chef_ssl

• Re-run chef client on the target node using the knife ssh 'name:nodename' 'sudo chef-client'

command

Figure 18. An example of the run parameters file

The HA framework used by TUT is robust in nature and provides the following capabilities:

• Fully automated deployment for Docker-based apps

• Location-agnostic routing

• High Availability and automatic resource management

• Load-balancing between the service instances

• Event-driven automatic reconfiguration

• Certificate-based and ACL-based security

Despite the aforementioned capabilities, it wasn’t included as an enforcement agent in the Enforcement

Dashboard due to its complexity to integrate with the framework and extra overhead compared to other

similar and open source HA frameworks. For example, Docker has the option to setup high availability

which is as easy as writing one configuration file called the compose.yml. It also has features like

Universal Control Panel that provides a simple graphical interface to the developers to deploy and


monitor applications and services and manage all resources like nodes, volumes, and networks from one

centralized place.

4.2 MUSA enforcement agents

The MUSA enforcement agents are preventive security mechanisms or controls that are managed by the

MUSA Framework. The management refers to the possibility of configuring, activating, stopping and

getting informed on agent events at operation. This is supported by the Enforcement service within the

MUSA Security Assurance Platform. The enforcement mechanisms were proposed to be built on top of

existing open source solutions and the major innovation resides in having MUSA Framework as single

point of management for orchestrating multiple mechanisms that address diverse security properties on

the multi-cloud applications.

In the following we describe how the agent mechanism works together with the Enforcement service of

MUSA which manages the agents operation. The Enforcement service in the MUSA Security Assurance

Platform, including the Enforcement Dashboard to manage the agents, is explained deliverable D4.4

Final MUSA Security Assurance Platform and user manual.

4.2.1 Agent mechanism

Every agent communicates with a component called Enforcement Manager in the MUSA Security

Assurance Platform through an event bus as shown in the Figure 19.

Figure 19. MUSA enforcement agent mechanism

As it can be seen in the Figure 19, the agent mechanism in MUSA relies on the following components:

• MUSA enforcement agents: These are security mechanisms that adopt the MUSA defined

design described in this document so they can be managed through the MUSA Enforcement


service. In the Figure 19, the MUSA Access Control and MUSA IdM agents are depicted. Both

are described in detail below.

• MUSA enforcement service: the MUSA Enforcement Service is included in the Security

Assurance Platform and supports the service administrator (in the DevOps Team) in managing

the agents and in getting alerts from the events occurred with the agents.

• Event bus: Typical message broker or bus where agents subscribe and unsubscribe to topics, so

they can communicate their events to the Enforcement service within the MUSA Security

Assurance Platform. The event bus is implemented in Apache Kafka [66].

4.2.1.1 Agent architecture

The agents are all plugin based. A plugin registers itself in a Plugin System. Every Plugin has services

so once a plugin is registered all their services become available.

• Plugin: a plugin is the container of the services. It consists of a plugin descriptor and a plugin

implementation.

• Service: a plugin could provide 0..n services

• Plugin system: registers the plugin

• Service Orchestration: registers the available services provided by the plugins and requires the

services required by a plugin to another plugin.

The following figure shows the overall architecture of the plugin system:

Figure 20. MUSA enforcement agent architecture

The common plugins in agent applications are:

• System: A service to register the plugins.

• Log: A logger service that sends log to stdout.

• Events: An events service to subscribe and emit events.

• Broker: A broker service to send and subscribe to kafka events.

• Agent: An agent service to manage the lifecycle of agent using a Finite State Machine.

• Proxy: A proxy service to register http verbs on urls as a middleware to intercept http requests.

• JWT: An JWT service to manage the lifecycle of JSON Web Tokens.

The IdM agent in MUSA is constructed as an agent application that gathers all the common plugins

above and the Plugin IdentityManager.

Similarly, the AC agent in MUSA is constructed as an agent application that gathers all the common

plugins above and the Plugin Access Control.


4.2.1.2 Agent app

The MUSA agents are applications (app) made up of plugins. An app consists in a launcher that loads

an app's descriptor file with 1..n plugins.

An app is a descriptor JSON file with the list of plugins that must to be loaded in the app. Each plugin

of this JSON file must have the proper configuration.

The simplest configuration file could be the one in Figure 21, and app descriptor file which will load

only one plugin (logger):

Figure 21. Example of a simple agent app configuration file

4.2.1.3 Agent Service System

As depicted in Figure 22, plugins include services that a Service orchestration module composes. Each

plugin is a NodeJS module with a package.json file and a plugin.js file. It does not need to actually be

in Nodejs npm registry, it can be a simple folder in the code tree.

Figure 22. Agent Service System

A plugin is defined using a standard NodeJS npm package.json. Among other standard properties in the

package.json, there is one property that is used by Service Orchestration, the “plugin” property that has

to be added in the config file with the following two properties:

● provides: an array of string that represents the services that the plugin provides.

● consumes: an array of string that represents the services that the plugin requires, i.e. has

dependency with.

{

"name": "SimplestApp",

"plugins": {

"log": {

"packagePath": "./plugins/log",

"options": { }

}

}

}


An example of a plugin package.json is shown below, with a plugin that has three services consumed

(log, events, util) and one provided (proxyFactory):

Figure 23. Example of a plugin package.json file

4.2.1.4 States and transitions

A MUSA agent is basically a Finite State Machine (shown in Figure 24) with transitions and callbacks

associated to every transition. The defined states for an agent are the following:

An agent is started in the initial state by default, but this could be parametrized by configuration.

• initial: initial state.

• idle: the agent is idle and awaiting to awake.

• awaking: the agent is awaking.

• awaked: the agent is awaked.

• initiating: the agent is initiating.

• initiated: the agent is initiated.

• starting: the agent is starting.

• started: the agent is started.

• stopping: the agent is stopping.

• stopped: the agent is stopped.

• error: the agent is in an error state.

And the defined transitions and triggers are:

• initial: initial, it is fired once the agent is launched. Change from initial to idle state.

{

"author": "Author Name",

"name": "proxy",

"description": "Musa proxy plugin system",

"version": "0.0.1",

"main": "plugin.js",

"plugin": {

"consumes": [

"log",

"events",

"util" ],

"provides": [

"proxyFactory"

]

},

"repository": {

"url": ""

},

"engines": {

"node": "~0.6.11"

},

"dependencies": {

"express": "~4.14.0"

},

"devDependencies": { },

"optionalDependencies": {}

}


• awake: awake the agent. Change from idle to awaking.

• awaked: the agent is awaked. Change from awaking to awaked.

• init: init an agent. Change from awaked or error to initiating.

• initiated: agent is initiated. Change from initiating to initiated.

• update: update the config of an agent. Change from started to started.

• start: start an agent. Change from initiated or error or stopped to starting.

• starting: the agent is starting. Change from starting to started.

• stop: stop an agent. Change from started or error to stopping.

• stopping: agent is stopping. Change from stopping to stopped.

• error: agent is in error. Change from any of awaking, initiating, starting, stopping to error.


Figure 24. MUSA enforcement agent finite state machine.


4.2.1.5 Events

By default every agent is subscribed to a topic in the message broker, for example ‘musa.agents.e1’

would be the topic to which the agent named ‘e1’ is subscribed to. The agent uses the broker service

to emit events. All events have the same four properties:

• category: the name of the group of objects you want to track.

• action: a string that is uniquely paired with each category.

• label: an optional string to provide additional dimensions to the event data.

• value: a JSON file that can be used to provide extra data about the event.

The events emitted by the internal services of the agents are:

• Agent events: On every transition, a public event is emitted by the agents with:

o 'agent' string as category.

o 'state' string as action.

o 'action' string as label.

o {state: 'idle', trigger: 'idle', data: {}} JSON as value.

• Proxy events: events fired by internal Proxy service of the agents, e.g. when a request is

proxied.

o 'proxy' string as category.

o 'request' string as action.

o 'log' string as label.

o {'origin': 'http://framework.musa-

project.eu/deployer/plan.html?appId=9999&appName=TSM_APP', 'direction': 'in',

'protocol': 'http', 'url': '/plans/9999', 'ip': '::ffff:192.168.246.132', 'hostname':

'framework.musa-project.eu', .... , 'method': 'GET'} JSON as value.

• Log events: events fired by internal Logger service, e.g. log a value of a token.

o 'log' string as category.

o 'jwt' string as action.

o 'info' string as label.

o {'msg': 'Access control start', 'direction': 'in'} JSON as value.

The particular events emitted by IdM agent are:

• IdM events: events fired by Identity Management agent, e.g. when a redirect to identity

provider is done

o 'idm' string as category.

o 'state' string as action.

o 'action' string as label.

o {state: 'idle', trigger: 'idle', data: {}} JSON as value.

The particular events emitted by AC agent are:

• AC events: events fired by Access Control agent. E.g. when a request has been evaluated a not

permitted

o 'ac' string as category.

o 'request' string as action.


o 'deny' string as label.

o {'origin': 'http://framework.musa-

project.eu/deployer/plan.html?appId=9999&appName=TSM_APP', 'direction': in',

protocol': http', 'url': '/plans/9999', ... , 'result': 'deny', 'msg': 'Not allowed to

consume request', 'method': 'GET'} JSON as value.

4.2.1.6 JSON Web Token

MUSA enforcement agents use the JSON Web Token open standard RFC 7519 [66] as self-contained

security resource for securely transmitting information between communication parties in form of a

JSON object. The mechanism includes the creation of access tokens that are used to assert a number of

claims in the service requests.

4.2.2 Agents configuration

Once the agents are deployed, they need to be configured prior they can be used. The configuration is

made in the MUSA Enforcement Dashboard of the MUSA Security Assurance Platform. Each agent is

configured in a different way as explained below for IdM and AC agents.

See deliverable D4.4 Final MUSA Security Assurance Platform and user manual for more details on

agent configuration support.

Each plugin of the agents has its own configuration, as follows. For more information on configurations

and examples please refer to Appendix G.

• logger: the internal logger service that sends log to stdout.

• events: the internal events service to subscribe and emit events.

• broker: the broker service to send and subscribe to kafka events.

o hosts: where kafka-server is located. E.g. "mykafka.enforce.cu.cc:2181"

• proxy: the proxy internal service to register http verbs on urls as a middleware to intercept http

requests.

o host: the host to expose the proxy server. E.g. "0.0.0.0"

o port: the port to expose the proxy server. E.g. "3000"

o headers: the headers to retrieve from request

▪ token: the header string that holds the user's jwt token

▪ provider: the idp provider that issued token

• agent: an internal broker service to send and subscribe to kafka events.

o agentID: the id of the agent. This will be used to identify this agent on Enforcement

Service. E.g. "e1"

o type: the type of this agent. E.g. "IDentityManager"

o initialState: the initial state of the agent. E.g. "initial"

o keepAliveInterval: the interval of keep alive msg to send to Enforcement Service.

E.g. 30000

• accessControl: the AC agent. This service uses other services to implement access control

o proxy service: it uses this service to intercept all http requests.

o agent service: it uses this service to communicate with the Enforcement Service

and react to Enforcement Service commands.

▪ start: receives configuration and start to intercept http requests and apply

access control

▪ stop: stop this service, the request will not be intercepted

▪ reload: receives configuration and restart the services

▪ setEnable: intercept the request and bypass the policies and always permit.

• idm: the IdM agent.


o cookie_secret: secret to use on gateway session. E.g.

"eljfwmtewio181d4.3dPOLbp"

o cookie_name: name to use on gateway session. E.g. "musag"

o idps: An array with available authenticate providers. Currently only Auth0 is

available:

▪ name: name of the provider. E.g. "auth0"

▪ idp_type: the type of the idp. E.g. "auth0"

▪ domain: the domain of the auth0 project. E.g.

"yourapplication.domain.eu.auth0.com "

▪ clientID: the clientID of the auth0 account. E.g.

"mpM8ODeFkxgjadJ1YZn2yX6PEAz7XnBl"

▪ clientSecret: the client secret of the auth0 account. E.g. "bX8TSBYmp-

U75xNswCdAfkorslT3a1"

▪ signinPath: the path to handle signin process. E.g. "/auth/auth0"

▪ signoutPath: the path to handle signout process. E.g. "/auth/signout"

▪ passReqToCallback: E.g. true

▪ callbackURL: After the user authenticates we will only call back to any of

these URLs. E.g. "https://myidm.enforce.cu.cc:3000/callback"

▪ jwt: configuration of JWT Rest Service

▪ pem: path to perm obtained from Auth0. E.g. "./idm/providers/

yourapplication.domain.eu.auth0pem"

▪ cert: path to cert obtained from Auth0. E.g. "./idm/providers/

yourapplication.domain.eu.auth0.cert"

▪ issuer: url of the Auth0 JWT issuer. E.g. "https://

yourapplication.domain.eu.auth0.com/

▪ webapps: An array of client webapp integrated. For each webapp registered,

the agent will need:

▪ appID: a client ID, each client will have a unique ID. E.g. clientID_1

▪ successRedirect: callback to redirect browser when signin process

is successfully done. E.g.

"http://mywebapp.enforce.cu.cc:3001/auth/account"

▪ failureRedirect: callback to redirect browser when signin process

is failure. E.g. "http://mywebapp.enforce.cu.cc:3001/auth/fail"

▪ signoutRedirect: callback to redirect browser when signout

process is successfully done. E.g.

"http://mywebapp.enforce.cu.cc:3001/auth/post/signout".

4.2.3 Agent deployment

In order to be able to manage a MUSA agent at operation, the agent needs to be deployed beforehand.

In some cases, the agent will need to be deployed in the same Virtual Machine as the component and in

some others, the agent can be deployed separately. In the case of the current agents offered by MUSA

(the IdM and AC agents explained below), both can be deployed separately, and it is up to the DevOps

team to set exactly where the agents will be deployed.

This information is set in the Application model created with the MUSA Modeller, i.e. the Cloud

Provider Independent Model (CPIM) created in MUSA-extended CAMEL language (see deliverable

D2.4 for details). The agent deployment information in the CPIM will be automatically transferred to

the Implementation plan in the MUSA Deployer, and the tool will be able to deploy the agent as required

(see deliverable D3.4). The cookbooks of the different enforcement agents (ref. Appendix D) will need

to be ready or the MUSA Deployer to be able to deploy them automatically on different VMs and

containers.


To ease the process, the MUSA Modeller aids in the selection of the MUSA agents and in the

specification of the agents’ deployment information in the CPIM model. The tool presents to the user

the agents available in the MUSA agents catalogue (see below) together with an explanation of the agent

purpose, and automatically generates in the model the MUSA-extended CAMEL information

corresponding to the selected agent(s).

4.2.4 Agent catalogue

The set of enforcement security agents that is available in the MUSA Framework is shown in the table

below together with the security controls they provide. The naming of the security controls follows the

NIST SP 800-53 revision 4 [68], as in the Security Service Level Agreement (SLA) Generation and

Composition process. The set of controls provided by each of the agents is relevant for the Security SLA

Composition process when the generated application Security SLA takes into account the security

features provided by the selected MUSA agents within the multi-cloud application.

The process for obtaining the security controls offered by the MUSA agents is the SLAT assessment

process described in deliverable D2.3 Final SbD methods for multi-cloud applications. Whenever a new

agent would be inserted in the catalogue, a similar assessment procedure would be necessary to obtain

the agent SLAT prior to its usage with the MUSA framework, so in the creation of a multi-cloud

application that includes the new agent, the MUSA workflow can consider properly the security features

provided by the agent.

The table represents the agents in the MUSA Enforcement Agents Catalogue that is used by the MUSA

Modeller tool in order to ease the specification of the agents in the MUSA-extended CAMEL model.

See complete SLAT for the IdM agent in Appendix E and for the AC agent in Appendix F.

Table 1. MUSA enforcement agents Catalogue and their Security Controls according to (NIST

SP 800-53 r4)

Agent name Description

Security

Control ID

Security Control Name Security

Control ID

Security Control Name

Identity

Management

(IdM) agent

The MUSA Identity Management agent offers a complete solution to manage the identity

lifecycle of an application. This implies sign up, sing in and sign out process. It provides a

JWT token which can be used with the Access Control agent.

It provides Identity Management by connecting to Auth0 IdM provider; it acts as a proxy

for an IdM provider. It currently supports Auth0 IdM

IA-9(1)

Service Identification And

Authentication | Information

Exchange

IA-4(5) Identifier Management | Dynamic

Management

IA-5(13)

Authenticator Management |

Expiration Of Cached

Authenticators

IA-5(10) Authenticator Management |

Dynamic Credential Association

Access Control

(AC) agent

It provides an access control to REST services based on XACML rules. In order to apply

these rules each request must include a JWT token which includes the user information. If

you use the Identity Management agent the JWT is created automatically and returned

after the user sign in process.

AC-1 Access Control Policy And

Procedures AC-4(18)

Information Flow Enforcement |

Security Attribute Binding

AC-2 Account Management AC-4(19) Information Flow Enforcement |

Validation Of Metadata


AC-2(11) Account Management | Usage

Conditions AC-4(20)


Approved Solutions

AC-2(12) Account Management | Account

Monitoring / Atypical Usage AC-6(10)

Least Privilege | Prohibit Non-

Privileged Users From Executing

Privileged Functions

AC-3 Access Enforcement AC-16(1) Security Attributes | Dynamic

Attribute Association

AC-3(4) Access Enforcement |

Discretionary Access Control AC-16(2)

Security Attributes | Attribute Value

Changes By Authorized Individuals

AC-3(7) Access Enforcement | Role-Based

Access Control AC-16(3)

Security Attributes | Maintenance

Of Attribute Associations By

Information System

AC-3(8) Access Enforcement | Revocation

Of Access Authorizations AC-16(4)

Security Attributes | Association Of

Attributes By Authorized

Individuals

AC-3(9) Access Enforcement | Controlled

Release AC-16(6)

Security Attributes | Maintenance

Of Attribute Association By

Organization

AC-4(1) Information Flow Enforcement |

Object Security Attributes AC-16(7)

Security Attributes | Consistent

Attribute Interpretation


Security Policy Filters AC-16(10)

Security Attributes | Attribute

Configuration By Authorized

Individuals


Human Reviews AC-24 Access Control Decisions

AC-4(10)


Enable / Disable Security Policy

Filters

AC-24(1)

Access Control Decisions |

Transmit Access Authorization

Information

AC-4(11)


Configuration Of Security Policy

Filters

AC-24(2) Access Control Decisions | No User

Or Process Identity


Security Policy Filter Constraints AC-25 Reference Monitor

The data model of the agents described in Table 1 is characterized in the Catalogue by the following

attributes:

• ID – identifier of the agent.

• Name – Sort name of the agent.

• Description – Short description of the agent purpose.

• Security Controls provided – the set of security controls provided by the agent, according to the

NIST SP 800-53 rev. 4 controls family.

• Cookbook/Recipe – the Chef cookbook or recipe needed for the MUSA Deployer to be able to

deploy the agent.

• Agent CAMEL model – the deployment requirements for the agent expressed in MUSA-

extended CAMEL language


• Security capabilities CAMEL model – the security capabilities provided by the agent expressed

in MUSA-extended CAMEL language.

• Associated component CAMEL model – the component to which the agent will work with. This

is selected by the DevOps team.

4.2.5 Identity Management agent

The MUSA Identity Management (IdM) agent, designed and developed by Tecnalia, is an open source

solution aimed at guaranteeing that only authorised end-users of the multi-cloud application components

can access them.

The MUSA IdM agent provides the identity management service. The agent is developed in Node.js

[93]. It relies on OpenID Connect [94] for single sign-on and identity provision and OAuth 2.0 [95] for

the identity tokens. All data between the Client (it can be a web application or a native application) and

multi-cloud application components (backend services deployed in cloud) is transferred using JWT

(JSON Web Tokens) [66]. The MUSA Token Exchange is the security token service that manages the

life cycle of a JWT (create, sign, validate).

Therefore, the MUSA IdM agent offers a complete solution to manage identity lifecycle of the

application, including sign up, sing in and sign out processes. The agent provides a JSON Web Token

(JWT) ready to be used with the AC agent in MUSA (if desired).

The IdM agent provides Identity Management acting as a proxy for an IdM Provider by connecting to

it and re-sending the JWT created by the IdM Provider. It currently supports Auth0 [97] Identity

Provider, but it can be easily extended to support other Identity Providers.

The main features provided by the IdM agent are:

• Handle sign up, sign in, and sign out processes.

• Act as client in front of Identity Providers (IDPs).

• Generate a JWT Token with user information inside it.

• JWT REST Service to verify the token and sign payloads and return.

Therefore, as it can be seen in Figure 19, the sing in process of a user in an Application could be as

follows:

1. The Application Frontend registers a callback url to be redirected once user authentication

process is done. (In Figure 19, the callback registered is the MUSA AC agent).

2. A user, through his/her browser, makes an authenticated request to the Application Frontend.

3. The Application Frontend redirects the request to MUSA IdM agent.

4. The MUSA IdM agent will redirect the browser to Auth0 Identity Provider (IDP) to let the user

authenticate against Auth0 (or an Authentication mechanism registered on Auth0).

5. The user authenticates herself and then MUSA IdM agent redirects to the registered callback of

the Application Frontend with the user's JWT Token.

Now if a user needs to consume a service protected with MUSA AC agent, the only thing to do is send

the token as HTTP Header on service request. If user has rights to access the service, the request will

reach the service, otherwise will be rejected by MUSA AC agent, as explained in the following section.

The process of sign up is similar to the sign in and will return a user's JWT Token to Application

Frontend.

In the following Table 2, the specification of the interface offered by the MUSA IdM agent is described.


Table 2. Interface specification of IdM agent

Resource URI /verify

POST Description It verifies the given JWT Token.

Request body A JSON with the two properties:

• token: JWT Token encoded to verify.

• options: settings to set verifying a token.

o provider: provider value to be checked.

o audience (optional): audience (aud) value to

be checked.

o issuer (optional): string or array of strings of

valid values for the issuer (iss) field.

o subject: if you want to check subject (sub),

provide a value here

Request header Empty.

Response body A JSON with the following properties:

• error: if an error occurred will be filled with that

error.

• result: if the token is valid this property will store

the value of the JWT Token decoded.

Response code

semantics

200: everything was ok and the token is decoded on

property result.

403: something wrong happen and error will store details

of the error.

Resource URI /sign

POST Description It creates a JWT Token.

Request body A JSON object with the following properties:

• payload: payload to encode as JWT. If payload is

not a buffer or a string, it will be coerced into a

string using JSON.stringify.

• options: options to encode JWT.

o cert: certificate to use.

o expiresIn: expressed in seconds or a string

describing a time span zeit/ms. E.g.: 60, "2

days", "10h", "7d".

o notBefore: expressed in seconds or a string

describing a time span zeit/ms. E.g.: 60, "2

days", "10h", "7d".

o audience: audience (aud) value.


o issuer: issuer (iss) value.

o subject: subject (sub) value.

Request header Empty.

Response body A JSON with the following properties:

• error: if an error occurred will be filled with that

error.

• result: if the token is valid this property will store

the value of the JWT Token encoded.

Response code

semantics

200: everything was ok and the token is encoded on

property result.

403: something wrong happen and error will store details

of the error.

4.2.6 Access Control agent

The MUSA Access Control (AC) agent, designed and developed by Tecnalia, is an open source solution

aimed at guaranteeing that only authorised requesters can consume services in application components.

The MUSA AC agent provides the Authorisation service. The agent is developed in Node.js [93]. The

AC agent is intended to be integrated into the application as a reverse proxy that intercepts all requests

to a target and ensures that the requester has the rights to reach/consume the target. The agent includes

a rule engine based on XACML policies [97]. When a user needs to consume a service protected by the

MUSA AC agent, she needs to include the token as HTTP Header on the service request. The request

will be intercepted by the MUSA AC agent, and according to the user attributes in the token, the agent

will evaluate the XACML policy and grant or reject the access to the service.

The XACML model supports and encourages the separation of the access decision, the point of use, and

the management of the policies. In this implementation the access decision (XACML Policy Decision

Point, PDP) and the point of use (XACML Policy Enforcement Point, PEP) resides on the same instance

to improve the performance.

The AC agent includes the following features:

• A XACML PEP (Policy Enforcement Point) that intercepts access request and ensures

XACML PDP decision.

• A XACML PDP (Policy Decision Point) that evaluates XACML policies.

• A XACML PIP (Policy Information Point) that provides external information to the PDP,

such as LDAP attributes. It is implemented as data retrievers that get information from the

request (origin, date, IP address, user email, user name...).

• A JWT client to verify JWT token.

The management of the policies (XACML Policy Administration Point, PAP) is not supported inside

the agent. The XACML access policies would be defined in the Policy Administration Point (PAP). As

explained in deliverable D4.4, the Enforcement Dashboard within the MUSA Security Assurance

Platform provides a PAP functionality to view and edit the XACML rules as well as automatically

communicate them to the AC agent.

In Figure 19 it is shown how the AC agent protects an Application Backend service, for each request

sent by clients to consume this service, the agent will:


1. Intercept any request to the Backend service.

2. Extract user information from JWT Token located in request header.

3. Get context data from request.

4. Make access control decision based on policies, user information and context data.

5. If decision is permit it will redirect the request to Backend service.

6. If decision is not permit the request will be rejected.

The AC agent does not offer an external REST API, but it works as a reverse proxy that intercepts all

the requests to the protected Backend, i.e. offers an access control mechanism to REST services based

on XACML rules.

In order the agent can apply the XACML rules, each request must include a JWT token with the user

information. In case the MUSA IdM is used, this JWT token is created automatically by the MUSA IdM

agent and returned after the user sign in process.

The following Figure 25 shows the contents of a coded JWT, where there are included several attributes

of the user from the Identity Provider.

Figure 25. Example of a coded JWT

The following Figure 26 shows the same JWT but decoded so the attributes and values can be seen:

Figure 26. Example of a decoded JWT

{

"email": "[email protected]",

"email_verified": true,

"app_metadata": {

"roles": "business_manager",

"groups": [

"testing",

"flight_scheduling",

"smart_mobility"

]

},

"iss": "https://yourapplication.domain.eu.auth0.com/",

"sub": "auth0|98246398a27d3513e38b1d0d",

"aud": "RUqvdbjNwKTBw9ZyayXMRSelGwtuso0P",

"iat": 1511180544,

"exp": 1511216544

}

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJlbWFpbCI6ImJ1c2luZXNzLm1hbmFnZXJAbXVzYS1wcm9

qZWN0LmV1IiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImFwcF9tZXRhZGF0YSI6eyJyb2xlcyI6ImJ1c

2luZXNzX21hbmFnZXIiLCJncm91cHMiOlsidGVzdGluZyIsImZsaWdodF9zY2hlZHVsaW5nIiwic21hcnR

fbW9iaWxpdHkiXX0sImlzcyI6Imh0dHBzOi8vbXVzYS1wcm9qZWN0LmV1LmF1dGgwLmNvbS8iLCJzd

WIiOiJhdXRoMHw1OTUyNjM4OWExN2QzNTEzZTI5YjFkMGYiLCJhdWQiOiJRVXZnZGFqTndUQlh3O

Vp5YXlUUktTZWxHaWl1ZG8wSiIsImlhdCI6MTUxMTE4MDU0NCwiZXhwIjoxNTExMjE2NTQ0fQ.qkb

HEYWV6DZ8jBsdw8nKMadSJn5lU7T7ciIybgTpTm0


The AC agent can evaluate all and only the attributes included in the JWT. Therefore, the power of the

Attribute Based Access Control performed by the AC agent depends on the granularity of attributes

taken into account in the XACML rules.

As a simple example, the following Figure 27 shows an extract of an access control policy based on

XACML rules that evaluates the value of roles attribute contained in the JWT above.

Figure 27. Example of XACML rules for access control

In the following Figure 28, we provide an example of the HTTP request to use a particular service

protected with the MUSA AC agent.

Figure 28. Example of a request to connect to service

The response produced by the AC Agent would be a denial of access in those cases were the roles of

the requester is “developer”, “business_manager” or “service_administrator” as stated in the policy of

Figure 27 above.

Figure 29. Example of Response produced by Access Control Agent

Response

Error 403

{ "error": "Token: You don’t sufficient permissions" }

http://yourmulti-cloudapp/component1/serviceA/

{

...

"apply": "deny-overrides",

"policies": [

{

"rules": [

{

"target": [

{ "credentials:app_metadata.roles": "developer" },

{ "credentials:app_metadata.roles": "business_manager" },

{ "credentials:app_metadata.roles": "service_administrator" }

],

"effect": "deny"

}

],

"apply": "deny-overrides",

"target": [

{ "request:path": { "regexp": "/deployments/*"} }

]

},

….

http://yourmulti-cloudapp/component1/serviceA/


4.2.7 MUSA enforcement agents final implementation

4.2.7.1 Prerequisites and installation

The MUSA Enforcement agents work together with the Enforcement service of the MUSA Security

Assurance Platform. These agents are available in MUSA public source code repository following this

link :

https://bitbucket.org/musateam/musa-assurance_platform-enforcement_agents

The user can find more information about the enforcement agents there, in the README.md file.

4.2.7.2 Usage guide

The final version of the MUSA Enforcement is available in the MUSA website under Tools menu,

www.musa-project.eu. The final MUSA enforcement agents’ software is also available in the public

bitbucket of MUSA as explained in next section.

The use of the MUSA agents is integrated within the MUSA Security Assurance Platform Enforcement,

which is explained in detail in deliverable D4.4 Final MUSA Security Assurance Platform and User

manual. To avoid redundancy, please refer to the guide available in this deliverable.

4.2.7.3 Source code repository

The open source projects that implement the MUSA Enforcement agents described above can be found

in the following MUSA bitbucket public repository:


Specifically, this is the repository that include the MUSA agents:

o MUSA Security Assurance Platform:

▪ musa-assurance_platform-enforcement_agents

https://bitbucket.org/musateam/musa-assurance_platform-enforcement_agents

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



5 Notification

5.1 Principle

The role of the notification module is to continuously report to DevOps team the status of the running

multi-cloud application. This includes the notification of the potential alerts and violations of the

security SLA contract detected by the monitoring mechanisms as well as the recommendation of security

mitigation mechanisms that can be applied at different phases of multi-cloud application development

(i.e. design phase, selection of the CSP, deployment). Thus, the notification module defines different

mechanisms to suggest and elaborate responses to the detected issues and keeps the DepOps team

informed on the potential risks and the different security operations applied on their sensitive data

(access, migration, etc.).

Finally, we can conclude that the notification module is involved during the two phases presented in

sections 2 and 3:

• To report the monitoring results of security SLAs (single and aggregated results).

• To present recommendation strategies in order to react against a security alert or violation.

• To inform the DevOps teams about the new security mechanisms enforced at runtime in

automatic, semi-automatic or manual way.

5.2 MUSA Web based notification

In the context of MUSA, the notification module has been designed to inform the DevOps teams about

the status of the running multi-cloud application from a security point of view by relying on a Web based

report (see Figure 30) that is composed of a dashboard and several sub-reports to details information

related to specific security metrics.

Figure 30. Web based notification in MUSA Security Assurance Platform

Two type of notifications has been defined during the SLA monitoring phase:

• Alerts: Alerts are notified when a security metric is about to be violated but not violated yet.

This allows to the application administrator to react before a violation occurs.

• Violations: Violations occur when one of the SLOs (service level objectives) is not respected.

In this case, a countermeasure is needed at different levels depending on the violation severity.

In the case of a potential alert or violation detection, a set of security enforcement mechanisms to

counteract the security issue are presented to the DevOps team. These recommendations can be more or

less easy to deploy depending of the severity of the detected security flaw and the multi-cloud

development phase that is impacted.


Depending of the deployment strategy, the activation of the recommended security enforcement

mechanism can be either:

• Automatic: In this case, the MUSA security assurance mechanism activates the security

mechanism and informs the DevOps team about the activation status.

• Semi-automatic: In this case, several steps of security enforcement mechanism can be

performed automatically but still the intervention of the DevOps team is required.

• Manual: In this case, which is the most common case, the DevOps team needs to manually

perform the necessary step to activate the counter-measure.

Depending on the severity of the potential security flaw detected by the monitoring mechanism part of

the MUSA security assurance SaaS, the reaction can impact either:

• The design phase: In this case, the application composition or/and the risk analysis to define

the SLA templates need to be updated and the whole workflow of the MUSA framework needs

to be redone.

• The reselection of a CSP: This can be related one or several application components. In this

case and based on the new measurements performed by the monitoring tool, the CSP can

recommend new CSP that better fulfils the security experts’ requirements. The redeployment

of the application component and the migration of the data are required in this case.

• The deployment of new security enforcement mechanisms that will fix the security issue

detected.

• The activation or reconfirmation of an already deployed security enforcement mechanism. This

last option is the most likely to be automated but depends on the security control policy adopted

to grant or deny the MUSA Security Assurance Platform to remotely perform changes on

configuration at running.

More technical details on the Web based notification modules are presented in the deliverable D4.2.


6 Conclusion

The document presents a state of art of existing security monitoring and enforcement mechanisms and

provides first details about the monitoring agents to be integrated in the MUSA Security Assurance

Platform SaaS. These monitoring are responsible of collecting security related information and send

them to a centralized assurance platform for further analysis. The main idea is to combine different

source of information (network, system, application, event bus, user behaviour etc.) to be able to have a

better insight on security controls implemented for the multi-cloud application.

The document also presents examples of security enforcement agents integrated into this same platform:

The high availability framework, the identity management agent and the XACML based access control

agent. These preventive enforcement mechanisms allow to propose security controls against potential

risks identified during the risk analysis phase. They can also be used (after deployment) as reactive

mechanism if a security SLA is not respected.

These security mechanisms are integrated into the MUSA Security Assurance Platform SaaS. This

platform is an external service (according to the application) that allows to monitor the multi-cloud

application already deployment in different CSPs. It detects potential deviations from security SLAs and

triggers counter-measures to enforce security during application runtime. The security health of the

running application is continuously reported to the DevOps team thanks the notification module of

MUSA. More details about the technical features of the MUSA Security Assurance Platform SaaS are

presented in D4.4 deliverable.


References

[1] Openstack Ceilometer. Available at: http://docs.openstack.org/developer/ceilometer/

(Retrieved November 2017)

[2] StackTach. Available at: http://stacktach.readthedocs.org/en/latest/index.html


[3] Collectd, the system statistics collection daemon. Available at: http://collectd.org/


[4] OPNFV Doctor. Available at: http://wiki.opnfv.org/doctor (Retrieved November 2017)

[5] OpenStack Security Guide. Available at: http://docs.openstack.org/sec/ (Retrieved

November 2017)

[6] Bandit project. Available at: http://wiki.openstack.org/wiki/Security/Projects/Bandit


[7] Consul. Available at: https://www.consul.io/ (Retrieved November 2017)

[8] T. Garfinkel and M. Rosenblum, “A virtual machine introspection based architecture

for intrusion detection”, in Proceedings of Network and Distributed Systems Security

Symposium, 2003.

[9] Patel, A. et al. 2013. An intrusion detection and prevention system in cloud computing:

A systematic review. Journal of Network and Computer Applications. 36, 1 (Jan. 2013), 25–41.

[10] Rahman, N.H.A. and Choo, K.-K.R. 2015. A survey of information security incident

handling in the cloud. Computers & Security. (2015).

[11] Rosado, D.G. et al. 2012. Security Analysis in the Migration to Cloud Environments.

Future Internet. 4, 4 (Dec. 2012), 469–487.

[12] Security and Azure SQL Database technical white paper: 2016.

https://download.microsoft.com/download/A/C/3/AC305059-2B3F-4B08-9952-

34CDCA8115A9/Security\_and\_Azure\_SQL\_Database\_White\_paper.pdf.

[13] Shamsolmoali, P. et al. 2014. C2DF: High Rate DDOS filtering method in Cloud

Computing. International Journal of Computer Network and Information Security. 6, 9 (Aug.

2014), 43–50.

[14] Sharma, P. et al. 2015. A Detection Algorithm for DoS Attack in the Cloud

Environment. COMPUTE. (2015), 107–110.

[15] Shirazi, S.N.U.H. et al. 2016. Anomaly detection in the cloud using data density. (Apr.

2016).

[16] Vaquero, L.M. et al. 2011. Locking the sky: a survey on IaaS cloud security.

Computing. 91, 1 (2011), 93–118.

[17] Vasilomanolakis, E. et al. 2015. Taxonomy and Survey of Collaborative Intrusion

Detection. CSUR. 47, 4 (2015), 55–33.

[18] Zbakh, M. et al. 2015. A multi-criteria analysis of intrusion detection architectures in

cloud environments. 2015 international conference on cloud technologies and applications

(cloudTech) (2015), 1–9.

[19] Idrissi, H. et al. 2015. Mobile Agents with Cryptographic Traces For Intrusion

Detection in the Cloud Computing. Procedia Computer Science. 73, (2015), 179–186.

http://docs.openstack.org/developer/ceilometer/

http://stacktach.readthedocs.org/en/latest/index.html

http://collectd.org/

http://wiki.opnfv.org/doctor

http://docs.openstack.org/sec/

http://wiki.openstack.org/wiki/Security/Projects/Bandit

https://www.consul.io/


[20] Hamdi, O. et al. 2015. A cloud-based architecture for network attack signature learning.

2015 7th international conference on new technologies, mobility and security (nTMS) (2015),

1–5.

[21] Huang, S.-Y. et al. 2014. Event Pattern Discovery on IDS Traces of Cloud Services.

2014 iEEE international conference on big data and cloud computing (bdCloud) (2014), 25–

32.

[22] Katz, G. et al. 2014. CoBAn: A context based model for data leakage prevention.

Information Sciences: an International Journal. 262, (Mar. 2014), 137–158.

[23] Garkoti, G. et al. 2014. Detection of Insider Attacks in Cloud Based e-Healthcare

Environment. 2014 international conference on information technology (iCIT) (2014), 195–

200.

[24] Gupta, S. et al. 2012. A fingerprinting system calls approach for intrusion detection in

a cloud environment. 2012 fourth international conference on computational aspects of social

networks (cASoN) (2012), 309–314.

[25] Erway, C.C. et al. 2015. Dynamic Provable Data Possession. ACM Transactions on

Information and System Security (TISSEC). 17, 4 (Apr. 2015).

[26] Kholidy, H.A. and Baiardi, F. 2012. CIDS: A Framework for Intrusion Detection in

Cloud Systems. 2012 ninth international conference on information technology: New

generations (iTNG) (2012), 379–385.

[27] Kumar, N. et al. 2014. Detection of Data Leakage in Cloud Computing Environment.

2014 international conference on computational intelligence and communication networks

(cICN) (2014), 803–807.

[28] Baig, Z.A. and Binbeshr, F. 2013. Controlled Virtual Resource Access to Mitigate

Economic Denial of Sustainability (EDoS) Attacks against Cloud Infrastructures. IEEE.


2016).

[30] Jeyanthi, N. et al. 2013. An Enhanced Entropy Approach to Detect and Prevent DDoS

in Cloud Environment. IJCNIS 5(2). 5, 2 (2013).

[31] Sharma, P. et al. 2015. A Detection Algorithm for DoS Attack in the Cloud

Environment. COMPUTE. (2015), 107–110.

[32] Cao, J. et al. 2015. Entropy-based denial-of-service attack detection in cloud data

center. CONCURRENCY) 27(18. 27, 18 (2015), 5623–5639.

[33] Yu, null S. et al. 2013. An approach with two-stage mode to detect cache-based side

channel attacks. 2013 international conference on information networking (iCOIN) (2013),

186–191.

[34] Bates, A. et al. 2012. Detecting co-residency with active traffic analysis techniques.

CCSW ’12 (New York, New York, USA, 2012), 1–12.

[35] Marnerides, A.K. et al. 2014. Assessing the impact of intra-cloud live migration on

anomaly detection. 2014 iEEE 3rd international conference on cloud networking (cloudNet)

(2014), 52–57.

[36] Marnerides, A.K. et al. 2015. Malware detection in the cloud under Ensemble Empirical

Mode Decomposition. 2015 international conference on computing, networking and

communications (iCNC) (2015), 82–88.


[37] Xiong, W. et al. 2014. Anomaly secure detection methods by analyzing dynamic

characteristics of the network traffic in cloud communications. Information Sciences. 258, (Feb.

2014), 403–415.

[38] Chou, H.-H. and Wang, S.-D. 2015. An adaptive network intrusion detection approach

for the cloud environment. 2015 international carnahan conference on security technology

(iCCST) (2015), 1–6.

[39] Watson, M.R. et al. 2016. Malware Detection in Cloud Computing Infrastructures.

TDSC. 13, 2 (2016), 192–205.

[40] Pandeeswari, N. and Kumar, G. 2015. Anomaly Detection System in Cloud

Environment Using Fuzzy Clustering Based ANN. Mobile Netw Appl. (2015), 1–12.



2014), 403–415.



(2014), 52–57.

[43] Huang, T. et al. 2016. Anomaly detection and identification scheme for VM live

migration in cloud infrastructure. Future Generation Computer Systems. 56, (Mar. 2016), 736–

745.

[44] Li, Y.-H. et al. 2015. VISO: Characterizing Malicious Behaviors of Virtual Machines

with Unsupervised Clustering. 2015 iEEE 7th international conference on cloud computing

technology and science (cloudCom) (2015), 34–41.

[45] Kholidy, H.A. and Baiardi, F. 2012. CIDS: A Framework for Intrusion Detection in

Cloud Systems. 2012 ninth international conference on information technology: New

generations (iTNG) (2012), 379–385.

[46] Modi, C.N. and Patel, D. 2013. A novel hybrid-network intrusion detection system (H-

NIDS) in cloud computing. 2013 IEEE Symposium on Computational Intelligence in Cyber

Security (CICS). (2013), 23–30.



2014), 43–50.

[48] Yu, W. et al. 2013. A cloud computing based architecture for cyber security situation

awareness. 2013 iEEE conference on communications and network security (cNS) (2013), 488–

492.

[49] Corona, I. et al. 2013. Adversarial attacks against intrusion detection systems:

Taxonomy, solutions and open issues. Information Sciences: an International Journal. 239,

(Aug. 2013), 201–225.

[50] Chen, Z. et al. 2015. A Cloud Computing Based Network Monitoring and Threat

Detection System for Critical Infrastructures. Big Data Research. (Nov. 2015).

[51] Chou, H.-H. and Wang, S.-D. 2015. An adaptive network intrusion detection approach

for the cloud environment. 2015 international carnahan conference on security technology

(iCCST) (2015), 1–6.

[52] Pandeeswari, N. and Kumar, G. 2015. Anomaly Detection System in Cloud

Environment Using Fuzzy Clustering Based ANN. Mobile Netw Appl. (2015), 1–12.




2014), 43–50.



2014), 403–415.

[55] Huang, T. et al. 2016. Anomaly detection and identification scheme for VM live

migration in cloud infrastructure. Future Generation Computer Systems. 56, (Mar. 2016), 736–

745.

[56] Jeyanthi, N. et al. 2013. An Enhanced Entropy Approach to Detect and Prevent DDoS

in Cloud Environment. IJCNIS 5(2). 5, 2 (2013).



(2014), 52–57.


2016).

[59] Watson, M.R. et al. 2016. Malware Detection in Cloud Computing Infrastructures.

TDSC. 13, 2 (2016), 192–205.

[60] Erkuden Rios, Wissam Mallouli, Massimiliano Rak, Valentina Casola and Antonio M.

Ortiz. SLA-driven Monitoring of Multi-Cloud Application Components using the MUSA

framework. In the Second IEEE International Workshop on Security Testing and Monitoring

STAM 2016. Nara, Japan. June 27, 2016.

[61] The SPECS project web site. Available at: http://www.specs-project.eu/

[62] Elizabeth Chew, Marianne Swanson, Kevin Stine, Nadya Bartol, Anthony Brown, and

Will Robinson. “Performance Measurement Guide for Information Security”. NIST Special

Publication 800-55 Revision 1. Available at: http://csrc.nist.gov/publications/nistpubs/800-55-

Rev1/SP800-55-rev1.pdf

[63] The Center for Internet Security. “CIS Security Metrics v1.1.0”. 2010. Available at:

https://benchmarks.cisecurity.org/tools2/metrics/CIS_Security_Metrics_v1.1.0.pdf

[64] The CUMULUS project web site. Available at: http://www.cumulus-project.eu.

[65] The A4Cloud project web site. Available at: http://www.a4cloud.eu

[66] Apache Kafka® distributed streaming platform by Apache Software Foundation.

Available at: https://kafka.apache.org/ (Retrieved November 2017)

[67] JSON Web Token (JWT) standard by Internet Engineering Task Force (IETF).

Available at: https://tools.ietf.org/html/rfc7519 (Retrieved November 2017)

[68] 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.

[69] A. Carlin, M. Hammoudeh, and O. Aldabbas, “Intrusion Detection and Countermeasure

of Virtual Cloud Systems - State of the Art and Current Challenges,” International Journal of

Advanced Computer Science and Applications, vol. 6, no. 6, 2015.

[70] S. Yu, X. Gui, J. Lin, F. Tian, J. Zhao, and M. Dai, “A Security-Awareness Virtual

Machine Management Scheme Based on Chinese Wall Policy in Cloud Computing,” The

Scientific World Journal, vol. 2014, pp. 1–12, 2014.

http://www.a4cloud.eu/

https://kafka.apache.org/

https://tools.ietf.org/html/rfc7519


[71] A. Volokyta, I. Kokhanevych, and D. Ivanov, “Secure virtualization in cloud

computing,” 2012.

[72] C.-J. Chung, P. Khatkar, T. Xing, J. Lee, and D. Huang, “NICE - Network Intrusion

Detection and Countermeasure Selection in Virtual Network Systems.” TDSC, vol. 10, no. 4,

pp. 198–211, 2013.

[73] Federated Identity solutions from Wikipedia. Available at:

https://en.wikipedia.org/wiki/Federated_identity (Retrieved November 2017)

[74] Comparison of cryptographic libraries from Wikipedia. Available at:

https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries (Retrieved November

2017)

[75] The SPECS project deliverable D4.2.2. Available at: http://www.specs-

project.eu/publications/public-deliverables/d4-2-2/ (Retrieved November 2017)

[76] Ficco M, Rak M (2012a) Intrusion tolerance in cloud applications: The mosaic

approach. In: 6th International Conference on Complex, Intelligent and Software Intensive

Systems (CISIS 2012). IEEE Computer Society Press. pp 170-176.

[77] M. Ficco and M. Rak. Intrusion Tolerance as a Service: A SLA-Based Solution. In Proc.

Of the 2nd Int. Conf. on Cloud Computing and Services Science, Apr. 2012. IEEE CS Press.

[78] T. Karnwal, T. Sivakumar, and G. Aghila, “A comber approach to protect cloud

computing against XML DDoS and HTTP DDoS attack,” 2012 IEEE Students’ Conference

on Electrical, Electronics and Computer Science, 2012.

[79] P. Shamsolmoali, M. A. Alam, and R. Biswas, “C2DF: High Rate DDOS filtering

method in Cloud Computing,” International Journal of Computer Network and Information

Security, vol. 6, no. 9, pp. 43–50, Aug. 2014.

[80] A. Shameli-Sendi, M. Pourzandi, M. Fekih-Ahmed, and M. Cheriet, “Taxonomy of

Distributed Denial of Service mitigation approaches for cloud computing,” Journal of

Network and Computer Applications, vol. 58, pp. 165–179, Dec. 2015.

[81] O. Osanaiye, K.-K. R. Choo, and M. Dlodlo, “Distributed denial of service (DDoS)

resilience in cloud: Review and conceptual cloud DDoS mitigation framework,” Journal of

Network and Computer Applications, Jan. 2016.

[82] B. Wang, Y. Zheng, W. Lou, and Y. T. Hou, “DDoS attack protection in the era of

cloud computing and Software-Defined Networking,” Computer Networks: The International

Journal of Computer and Telecommunications Networking, vol. 81, no. C, pp. 308–319, Apr.

2015.

[83] Madhusudan, S and Srikanth, S.P, “Detection of Network Intrusion and

Countermeasure Selection in Cloud Systems,” IOSR Journal of Computer Engineering, vol.

16, no. 2, pp. 84–88, 2014.

[84] CSO Online news on DDoS knocks down DNS, data centers across the U.S. affected.

October 2016. Available at: http://www.csoonline.com/article/3133992/security/ddos-knocks-

down-dns-datacenters-across-the-u-s-affected.html (Retrieved November 2017)

https://en.wikipedia.org/wiki/Federated_identity

https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries

http://www.specs-project.eu/publications/public-deliverables/d4-2-2/

http://www.specs-project.eu/publications/public-deliverables/d4-2-2/

http://www.csoonline.com/article/3133992/security/ddos-knocks-down-dns-datacenters-across-the-u-s-affected.html

http://www.csoonline.com/article/3133992/security/ddos-knocks-down-dns-datacenters-across-the-u-s-affected.html


[85] R. A. Michelin, A. F. Zorzo, and C. A. De Rose, “Mitigating DoS to authenticated cloud

REST APIs,” in 2014 9th International Conference for Internet Technology and Secured

Transactions (ICITST). IEEE, 2014, pp. 106–111.

[86] Corosync. Available at: http://corosync.github.io (Retrieved November 2017)

[87] Pacemaker. Available at: http://clusterlabs.org/ (Retrieved November 2017)

[88] Consul_template. Available at: https://github.com/hashicorp/consul-template


[89] HAproxy. Available at: http://www.haproxy.org/ (Retrieved November 2017)

[90] Nginx. Available at: https://nginx.org/ (Retrieved November 2017)

[91] Docker. Available at: https://www.docker.com/ (Retrieved November 2017)

[92] Gliderlabs Registrator. Available at: http://gliderlabs.com/registrator/ (Retrieved

November 2017)

[93] The Node.js project. Available at: https://nodejs.org/en (Retrieved November 2017)

[94] The OpenID Connect 1.0. Available at: http://openid.net/connect/ (Retrieved November

2017)

[95] The OAuth 2.0 specification. Available at: https://oauth.net/2/ (Retrieved November

2017)

[96] JWT.IO for JSON Web Tokens. Available at: https://jwt.io/ (Retrieved November

2017)

[97] Auth0 Identity services. Available at: https://auth0.com/ (Retrieved November 2017)

[98] eXtensible Access Control Markup Language (XACML) Version 3.0. Available at:

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html

http://corosync.github.io/

http://clusterlabs.org/

https://github.com/hashicorp/consul-template

http://www.haproxy.org/

https://nginx.org/

https://www.docker.com/

http://gliderlabs.com/registrator/

https://nodejs.org/en

http://openid.net/connect/

https://oauth.net/2/

https://jwt.io/

https://auth0.com/

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html


Appendix A. MUSA motivation and background

The main goal of MUSA 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. The MUSA Metric Catalogue

Table 1 reports the metrics collected so far, for which the following information is given:

• Metric ID: a unique metric identifier;

• Metric Name: an intuitive name for the metric;

• Abstract metric ID: the ID of the Abstract metric that the metric inherits from (see Table 2 for a description of the Abstract metrics considered);

• Applicability: the applicability domain of the metric (see Section 4.2);

• Description: a description of the metric;

• Value range: the type and range of values that the metric can assume;

• Unit: the unit of measure of the metric, if applicable. The unit can be a percentage (%), a level (in case of qualitative metrics that can assume a discrete

range of values), a cost (computed in Euros or “Euros per event”), a time period (days, hours) or the number of occurrences of a given event/action/item.

• Value description: for qualitative metrics assuming only a discrete (level) value, the meaning of the different levels is described;

• Default: the (possible) default value of the metrics;

• Operator if used in SLO: the operator that may be used when adopting the metric to define and SLO in an SLA.

Table 3: MUSA security metric catalogue - summary

Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range

Unit Value Description Default Operator if

used in SLO

DATA_ AV Data

availability

AV Data

protectio

n

Percentage of time in which data

access is available to data owners

0 ≤ int ≤

100

% n/a ge (≥)

SERVICE_

AV

Service

availability

AV SW

compone

nt/

system

protectio

n

Percentage of time in which service

access is available to users

0 ≤ int ≤

100

% n/a ge (≥)

COMPENS

ATORY_C

OST

Total

expenses

due to

COST manage

ment

This metric indicates the total

expenses incurred due to

compensatory damages.

int > 0 euros n/a leq(<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

compensat

ory

damages

AVG_COM

PENSATO

RY_COST

Average

expenses

due to

compensat

ory

damages

COST manage

ment

This metric indicates the average

expenses due to compensatory

damages per upheld

complaint/incident

int > 0 euros n/a leq(<=)

INCIDENT

S_COST

Cost of

Incidents

COST manage

ment

This metric measures the total cost

to the organization from security

incidents occurring during the

metric time period.

int>0 euros n/a leq(<=)

AVG_INCI

DENT_

COST

Mean Cost

of

Incidence

COST manage

ment

This metric measures the mean cost

to the organization from security

incidents identified relative to the

number of incidents that occurred

during the metric time period.

int>0 euros

per

incide

nt

n/a leq(<=)

AVG_INCI

DENT_

RECOV_C

OST

Mean

Incident

Recovery

Cost

COST manage

ment

This metric measures the cost of

returning business systems to their

pre-incident condition.

int>0 euros

per

incide

nt

n/a leq(<=)

AVG_PAT

CH_ COST

Mean Cost

to Patch

COST manage

ment

The goal of this metric is to

understand the effort required for

patch management activities.

int>0 euros

per

patch

n/a leq(<=)

INFR_DAT

A_

LOCATIO

N

Datacenter

Location

DL Data

protectio

n

This metric defines the geolocation

of the datacenter infrastrucure for

governance and compliance

purposes

geograp

hical

zone

n/a eq (=)

RES_

UTILIZAT

ION_ EFF

Resource

Utilization

Efficiency

EFF SW

compone

nt/syste

m

It measures the efficiency of cloud

resources allocated to application, to

determine the utilisation

0 ≤ int ≤

100

% n/a ge(>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

protectio

n

DATA_WS

_ON

Write-

Serializabili

ty

Activation

FA Data

protectio

n

This metric ensures the EU that any

WS violation to his stored data will

be detected in a defined period of

time (detection periods are less than

2*epoch). In case of WS violations,

the EU will be notified, and the

system will be restored to the state

of the last finished epoch.

yes / no n/a yes eq (=)

DATA_RF_

ON

Read-

Freshness

Activation

FA Data

protectio

n

This metric ensures the EU that any

RF violation to his stored data will be

detected in a defined period of time

(detection periods are less than

2*epoch). In case of RF violations,

the EU will be notified, and the

system will be restored to the state

of the last finished epoch.


FWSEC_O

N

Forward

Secrecy

Activation

FA Commun

ication

protectio

n

This metric ensures that the

encrypted data sent through a

session of the TLS secure channel

cannot be decrypted even if the

cryptographic data, used to generate

the cryptographic credentials for

that session, are compromised.


HSTS_ON HTTP Strict

Transport

Security

Activation

FA Commun

ication

protectio

n

This metric enables the feature of

the HTTP transport layer that

declares the web content available

only over a secure HTTP connection.


HTTPS_O

N

HTTP to

HTTPS

Redirect

Activation

FA Commun

ication

protectio

n


the HTTP delivery service that

forces clients to use only secure

HTTP protocol.



Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

SEC_COO

KIES_ON

Secure

Cookies

Enforceme

nt

FA Commun

ication

protectio

n


the HTTP protocol that forces the

clients to download session cookies,

delivered by the HTTP services, only

through a secured HTTP

communication


CERT_PIN

_ON

Certificate

Pinning

Activation

FA Commun

ication

protectio

n


the HTTP protocol allowing the

verification of the SSL certificates

between the client and the HTTP

service where the hash of the public

certificate is pinned into the HTTP

response.

yes / no n/a no eq (=)

VULN_SC

AN_FREQ

Vulnerabili

ty Scanning

Frequency

FOP SW

compone

nt/syste

m

protectio

n

It represents the frequency of

software vulnerability scanning.

int > 0 hours 24 eq (=)

VULN-

LIST_UPD

_FREQ

Vulnerabili

ty-List

Update

Frequency

FOP SW

compone

nt/syste

m

protectio

n

It represents the vulnerability list

update frequency (from an available

repository such as OVAL/NDV)


SW_UPDA

TE_

CHECK_F

REQ

SW Update

Check

Frequency

FOP SW

compone

nt/syste

m

protectio

n

This metric sets the frequency of

checks for updates and upgrades of

vulnerable installed libraries.


AUDIT_RE

CORD_FR

EQ

Audit

Record

Generation

Frequency

FOP SW

compone

nt/syste

m

It measures the average frequency of

audit records review and analysis

for inappropriate activity .

int > 0 days 7 ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

protectio

n

K_ANONI

MITY_ ON

k-

anonimity

k-

anoni

mity

Data

protectio

n

This metrics ensures that, given

person-specific field-structured

data, the individuals who are the

subjects of the data cannot be re-

identified while the data remain

practically useful.

Data is said to have the k-anonymity

property if the information for each

person contained in the release

cannot be distinguished from at

least k-1 individuals whose

information also appear in the

release.


L_DIVERS

ITY_ON

l-diversity l-

diversi

ty

Data

protectio

n

This metric ensures l-diversity,

which is a form of group based

anonymization that is used to

preserve privacy in data sets by

reducing the granularity of a data

representation. This reduction is a

trade off that results in some loss of

effectiveness of data management or

mining algorithms in order to gain

some privacy.

The l-diversity model is an extension

of the k-anonymity model which

reduces the granularity of data

representation using techniques

including generalization and

suppression such that any given

record maps onto at least k other

records in the data.



Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

T_CLOSEN

ESS_ON

t-closeness t-

closen

ess

Data

protectio

n

This metric ensures the t-closeness

feature, which is a further

refinement of l-diversity group

based anonymization that is used to

preserve privacy in data sets by

reducing the granularity of a data

representation. This reduction is a

trade off that results in some loss of

effectiveness of data management or

mining algorithms in order to gain

some privacy. The t-closeness model

extends the l-diversity model by

treating the values of an attribute

distinctly by taking into account the

distribution of data values for that

attribute.


CONFID_L

EVEL

Level of

confidentia

lity

LOC Data

protectio

n

This metric indicates the level of

confidentiality achieved by a system

regarding client data independently

of the means used to achieve this

objective.

0 ≤ int ≤

4

(level) Level 0 – Data confidentiality does not satisfy

any of the next levels.

Level 1 – Data may be accessible by the cloud

provider personnel for regular operational

purposes, under the control of an

authentication, authorization and accounting

(AAA) mechanism.

Level 2 – Technical and organizational

measures are in place so that data may only

be accessible to privileged CSP personnel

(administrators) for debugging or

maintenance purposes, under the control of

an AAA mechanism.

Level 3 – Technical and organizational

measures are in place so that data is only

accessible to privileged CSP personnel to

respond to law enforcement or

extraordinary requests made by the client,

under the control of an AAA mechanism.

Level 4 – Data is encrypted by the client with

0 ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

cryptographic keys that cannot be

ascertained by the provider.

KEY_EXP

OSURE_LE

VEL

Key

Exposure

Level

LOC Data

protectio

n

This metric indicator of key

exposure to reflect the level of

confidentiality afforded to

cryptographic secrets, from a cloud

client point of view.

0 ≤ int ≤

4

(level) Level 0 – Access to decrypted data or

cryptographic secrets by the CSP is

necessary to

provide some functionalities of the service.

Level 1 – Access to decrypted data or

cryptographic secrets is available to specific

personnel of the CSP, for administrative or

debugging purposes only.



personnel of the CSP, for administrative or

debugging purposes only. It is governed by

the principle of

dual control and split knowledge.



personnel of the CSP in exceptional

circumstances only. It is governed by the

principle of dual control

and split knowledge, under the supervision

of a hardware security module.

Level 4 – Cryptographic secrets needed to

decrypt the data are known to the cloud

client only.

0 le (<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

ACC_TRAI

NING_LEV

EL

Account of

Privacy and

Security

Training

LOC manage

ment

This metric describes the quality of

the accounts given with respect to

the privacy

training and awareness programs in

place.

0 ≤ int ≤

4

(level) Level 0 – No records of training are

maintained.

Level 1 – Records of training sessions are

maintained, but there is no evidence of

individual attendance.

Level 2 – Individual records of attendance

are maintained.

Level 3 – Individual evaluation of the training

contents is performed and recorded.

Level 4 – The training program includes

automated procedures for recording

attendance as well as for evaluating

personnel individually.

0 ge (>=)

DATA_IS_

TESTING_

LEVEL

Data

Isolation

Testing

Level

LOC Data

protectio

n,

manage

ment

This metric describes the level of

testing that has been done by the

cloud provider to

assess how well data isolation is

implemented.

0 ≤ int ≤

3

(level) Level 0 – No data isolation testing has been

performed.

Level 1 – Read/write isolation has been

tested.

Level 2 – Secure deletion has been tested, in

addition to read/write isolation.

Level 3 – Absence of known side channel

attacks has been tested, in addition to

read/write

and secure deletion.

0 ge (>=)

CONSENT

_TYPE

Type of

Consent

LOC Data

protectio

n,

manage

ment

This metric describes the type of

consent obtained for collecting,

using and sharing

private data. The type of consent can

be ranked in levels according to its

preference.

0 ≤ int ≤

3

(level) Level 0 – No Consent: Consent is not obtained

at or before collection of private data.

Level 1 – Implied Consent: The consent is

infered from the behaviour of the data

subject, or even from failing to explicitly

object. No opt-out or opt-in mechanisms are

offered.

Level 2 – Opt-out Consent: Data subjects can

take measures for prevent the collection of

private data, but no opt-in mechanisms are

offered.

Level 3 – Opt-in Consent: Data subjects

explicitly grant permission for collecting or

0 ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

using

private data.

NOTICE_T

YPE

Type of

notice

LOC Data

protectio

n,

manage

ment

This metric describes the type of

privacy notice provided by the

collecting organization, depending

on how the privacy notice is offered

to the data subjects. Ideally, multi-

layer notice should be provided so

data subjects have the information

necessary to make decisions at any

point in time.

0 ≤ int ≤

2

(level) Level 1 – Single notice: The organization

provides only a single document describing

the privacy notice.

Level 2 – Multi-layer notice: The

organization provides different layers of

notices. Each layer can present different

degrees of information, as long as the union

of all the layers is compliant with applicable

privacy regulations.

1 ge (>=)

DATA_SU

BJ_

ACCESS_

PROCEDU

RES

Procedures

for Data

Subject

Access

Requests

LOC Data

protectio

n,

manage

ment


the procedures in place for

guaranteeing data

subjects’ access to their personal

information.

0 ≤ int ≤

3

(level) Level 0 - No procedures are established for

permitting data subject access to their

personal

information.

Level 1 - Procedures for data subject access

exist but are not documented or consistent.

Level 2 - Documented and consistent

processes for data subject access are

established.

Employees responsible of such procedures

are identified and trained on how to respond

to

requests. There also exist procedures for

handling with denial of access.

Level 3 - Automated and self-service

procedures for data subject access are in

place,

including the case of denied access.

0 ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

PRI_NOTI

CE_READ

ABILITY

Readability

(Flesch

Reading

Ease Test)

LOC manage

ment

This metric describes quantitatively

the level of readibility of a given text,

computed from

the number of sentences, words and

syllables. This is of interest for

assessing readibility of privacy

notices and notifications, which

should be written in a clear and

concise way. This metric is known as

the Flesch Reading Ease Test, and is

widely utilized for evaluating

readibility.

0 ≤ real ≤

100

n/a 90.0–100.0: Very easy to read. Easily

understood by an average 11-year-old

student.

80.0–90.0: Easy to read. Conversational

English for consumers.

70.0–80.0: Fairly easy to read.

60.0–70.0: Easily understood by 13- to 15-

year-old students.

50.0–60.0:Fairly difficult to read.

30.0–50.0: Difficult to read.

0.0–30.0: Very difficult to read. Best

understood by university graduates.

70 ge (>=)

PRI_RESP

_LEVEL

Rank of

Responsibil

ity for

Privacy

LOC manage

ment

This metric describes numerically at

what level within the organization

hierarchy the

person responsible for privacy is

located.

int > 0 (level) n/a eq (=)

LOG_INTE

GRITY_LE

VEL

Log

Unalterabil

ity

LOC SW

compone

nt/syste

m

protectio

n

This metric describes the level of

protection of the log management

systems against

tampering.

0 ≤ int ≤

2

(level) Level 0 – No integrity mechanisms are in

place

Level 1 – Log integrity is protected only by

access control measures.

Level 2 – Cryptographic mechanisms are in

place for guaranteeing log unalterability or

WORM (Write Once Read Many) devices are

used.

0 ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

AUTHENT

ICATION_

LEVEL

Identity

Assurance

LOC SW

compone

nt/syste

m

protectio

n


the authentication mechanisms in

place.

0 ≤ int ≤

4

(level) Level 0 – No authentication mechanisms are

in place.

Level 1 – Simple challenge response

mechanisms are allowed and no identity

proofing is

required.

Level 2 – Single factor remote network

authentication is required; in this case,

authentication

is successful if the claimant proves control of

the authentication token through a secure

authentication protocol.

Level 3 – Multifactor authentication

mechanisms are in place. Proofs of control of

the

authentication token are done through a

cryptographic protocol.

Level 4 - Multifactor authentication with a

hardware cryptographic token is required.

Strong

cryptographic mechanisms are required

along physical tokens with a FIPS 140-2 level

greater

than 2, and identity proofing is done in

person.

0 ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

INCIDENT

_NOTIF_Q

UALITY

Type of

incident

notification

LOC manage

ment


the notification procedures after a

privacy incident or breach.

0 ≤ int ≤

3

(level) Level 0 – No notification of privacy incidents

is done, or it is done inconsistently.

Level 1 – General notification, usually as a

public notice. Affected users may not be

aware of

the incident

Level 2 – Individual notification to each

affected user.

Level 3 – Automated and self-service

procedures for data subject access are in

place,

including the case of denied access.

0 ge (>=)

CRYPTO_

S

Cryptograp

hic

Strength

LOC Data

protectio

n,

Commun

ication

protectio

n

It is a measure of the strength of a

cryptosystem in terms of the

expected number of operations

required to defeat the underlying

cryptographic mechanism. The

values (level 1-8) are based on

ECRYPT II recommendations 2012: .

https://www.keylength.com/en/3/

1 ≤ int ≤

8

(level) LEVEL1: Attacks in "real-time" by

individuals. Only acceptable for

authentication tag size.

LEVEL2: Very short-term protection against

small organizations. Should not be used for

confidentiality in new systems.

LEVEL3: Short-term protection against

medium organizations, medium-term

protection against small organizations.

LEVEL4: Very short-term protection against

agencies, long-term protection against small

organizations.

LEVEL5: Legacy standard level.

LEVEL6: Medium-term protection.

LEVEL7: Long-term protection.

LEVEL8: "Foreseeable future".

7 eq (=)

LOR Level of

Redundanc

y

LOC SW

compone

nt/syste

m

protectio

n

It represents the number of replicas

of a software component that are

set-up and kept active at the same

time during system operation

int > 0 n/a 1 ge (≥)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

LOD Level of

Diversity

LOC SW

compone

nt/syste

m

protectio

n

It represents the number of different

software / hardware replicas of a

software component that are set-up

and kept active at the same time

during system operation

int > 0 n/a 1 ge (≥)

MTB_INCI

DENTS

Mean time

between

incidents

MTBE SW

compone

nt/syste

m

protectio

n, data

protectio

n,

commun

ication

protectio

n

This metrics measures the mean

time between two subsequent

incidents

MTT_REV

OKE_USE

RS

Mean time

to revoke

users

MTTC SW

compone

nt/syste

m

protectio

n, data

protectio

n,

commun

ication

protectio

n,

manage

ment

This attribute describes

quantitatively how fast an

organization revokes users’ access

to data and organizationally-owned

or managed (physical and virtual)

applications, infrastructure systems,

and network components, based on

user's change in status (e.g.,

termination of employment or other

business relationship, job change or

transfer).

int > 0 hours n/a le (<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

MTT_RES

POND_CO

MPLAINT

S

Mean time

to respond

to

complaints

MTTC SW

compone

nt/syste

m

protectio

n, data

protectio

n,

commun

ication

protectio

n,

manage

ment


time that the organization takes for

responding to

complaints from stakeholders.

int > 0 hours n/a le (<=)

MTT_REA

CT

Timeliness

of reaction

MTTC SW

compone

nt/syste

m

protectio

n, data

protectio

n,

commun

ication

protectio

n


time to react to a security incident

int>0 second

s

n/a le (<=)

MTT_CRI

TICAL_PA

TCH

Mean Time

to Deploy

Critical

Patches

MTTC SW

compone

nt/syste

m

protectio

n

The metric measures the average

time taken to deploy a critical patch

to the organization’s technologies

int>0 second

s

n/a le (<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

MTT_DET

ECT_INCI

DENT

Mean Time

to Incident

Discovery

MTTC SW

compone

nt/syste

m

protectio

n, data

protectio

n,

commun

ication

protectio

n

This metric measures the

effectiveness of the organization in

detecting security incidents, as it

returns the average time to detect

incidents

int>0 second

s

n/a le (<=)

MTT_REC

OVER

Mean Time

to Incident

Recovery

MTTC SW

compone

nt/syste

m

protectio

n, data

protectio

n,

commun

ication

protectio

n

This metric measures the

effectiveness of the

organization to recovery from

security incidents

int>0 second

s

n/a le (<=)

MTT_PAT

CH

Mean Time

to Patch

MTTC SW

compone

nt/syste

m

protectio

n

This metric measures the average

time taken to deploy a patch to the

organization’s technologies

int>0 second

s

n/a le (<=)

MTT_COM

PLETE_CH

ANGES

Mean Time

to

Complete

Changes

MTTC SW

compone

nt/syste

m

protectio

n

The average time it takes to

complete a configuration change

request.

int>0 second

s

n/a le (<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

MTT_

CONTAIN

MENT

Mean Time

from

Discovery

to

Containme

nt

MTTC SW

compone

nt/syste

m

protectio

n

It measures the effectiveness of the

organization to identify and contain

security incidents.

int>0 second

s

n/a le (<=)

PRI_PROG

_UPDTS

Privacy

Program

Updates

NOE manage

ment

This metric describes the frequency

of updates to the privacy program,

policies and procedures by a

competent role (e.g. Data Protection

Officer (DPO)).

int > 0 (updat

es)

n/a ge (>=)

PERIODIC

_PRI_

ASSESSM

ENTS

Periodicity

of Privacy

Impact

Assessmen

ts for

Informatio

n Systems

NOE manage

ment

This metric describes the periodicity

of Privacy Impact Assessments for

Information

Systems

int > 0 (assess

ments)

n/a ge (>=)

CERTIFIC

ATIONS

Frequency

of

certificatio

ns

NOE Data

protectio

n,

manage

ment

This metric describes how often

employees certify their acceptance

of responsibilities for

activities that involve handling of

private data.

int > 0 (certifi

cations

)

n/a ge (>=)

RCVD_PRI

V_

AUDITS

Number of

privacy

audits

received

NOE SW

compone

nt/syste

m

protectio

n,

manage

ment

This metric describes the number of

independent reviews and

assessments performed to the

privacy program, policies and

procedures in place.

int > 0 n/a n/a ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

DATA_SU

BJ_

ACCESS_R

QSTS

Number of

Data

Subject

Access

Requests

NOE Data

protectio

n

This metric describes the number of

data subject access requests

received during a given period of

time.

int > 0 (acces

s

reques

ts)

n/a le (<=)

COMPLAI

NTS_

NUMB

Number of

complaints

NOE manage

ment

This metric indicates the number of

complaints received during a given

period of time.

int > 0 (compl

aints)

n/a eq (=)

PRI_INCI

DENT_

NUMB

Number of

privacy

incidents

NOE manage

ment

This metric provides the number of

privacy incidents and breaches that

have occurred in

a given period of time.

int > 0 (incide

nts)

n/a le (<=)

3RD-

PARTY_P

RI_

INCIDENT

S_ NUMB

Privacy

incidents

caused by

third

parties

NOE manage

ment


privacy incidents caused by a third

party to whom

personal information was

transferred (i.e. Data Processors)

int > 0 (incide

nts)

n/a le (<=)

DAMAGE_

INCIDENT

S

Incidents

with

damages

NOE manage

ment


incidents that end up with

compensatory or punitive

damages.

int > 0 (incide

nts)

n/a ge (>=)

INCIDENT

S

Number of

Incidents

NOE SW

compone

nt/syste

m

protectio

n,

manage

ment

It indicates the number of detected

security incidents the organization

has experience during the metric

time period. In combination with

other metrics, this can indicate the

level of threats, effectiveness of

security controls, or incident

detection capabilities

int >=0 n/a n/a le (<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

VULNERA

BILITIES

Number of

Vulnerabili

ties

NOE SW

compone

nt/syste

m

protectio

n,

manage

ment

It is the number of known

vulnerabilities that have been found

on organization’s systems during

the vulnerability identification

process (per catergory or severity)

int>=0 n/a n/a le (<=)

TESTED_

BCR_

PLANS

Number of

Business

Continuity

Resilience

(BCR) plans

tested

NOE manage

ment


business continuity resilience and

incident response

plans that have been tested in a

given interval of time.

int > 0 (plans) n/a le (<=)

SANCTIO

NS

Sanctions NOE manage

ment

This metric indicates the number

and type of sanctions that the

organization has

received. The EU DPD defines

different types of sanctions: (i) a

notice addressed to the Data

controller (e.g. for compulsory

audit), (ii) a fine, (iii) an injunction

dictating the end of processing

operations, and (iv) a (temporary or

permanent) revocation of the

authorization allowing the

processing of personal data.

int > 0 (sancti

ons)

n/a eq (=)

DATA_EN

CRYPTIO

N_PERC

Data

encryption

percentage

PERC data

protectio

n

The metric represents the

percentage of encrypted stored data

in the cloud infrastructure.

0 ≤ int ≤

100

% yes eq (=)

DATE_IN

DICATION

_PERC

Record of

Data

Collection,

Creation,

and Update

PERC Data

protectio

n,

manage

ment

This metric describes a percentage

of the extent to which date is

recorded when collecting, creating

and updating private records. Date

of data collection, creation and

0 ≤ int ≤

100

% n/a ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

update is relevant for complying

with data retention schedules.

DATA_CL

ASSIFICA

TION_PER

C

Data

classificatio

n

PERC Data

protectio

n,

manage

ment

This metric describes a percentage

of the extent to which private data is

identified and

classified according to sensitivity

and risk.

0 ≤ int ≤

100

% n/a ge (>=)

PII_AUTH

ORIZ_PER

C

Authorized

collection

of PII

PERC manage

ment

This metric describes the coverage

of authorizations for collecting

personally identifiable information

(PII).

0 ≤ int ≤

100

% n/a ge (>=)

PRI_BUD

GET_

PERC

Privacy

Program

Budget

PERC manage

ment

This metric describes the

percentage of the organization’s IT

budget that is allocated for

establishing and maintaining a

privacy program

0 ≤ int ≤

100

% n/a ge (>=)

PRI_TRAI

NING_

PERC

Coverage of

Privacy and

Security

Training

PERC manage

ment


percentage of relevant employees

who have received training on the

privacy program and policies in

place. The definition of relevant

employee could vary (e.g., those that

handle private data)

0 ≤ int ≤

100

% n/a le (<=)

NOTIFIED

_PRI_INCI

DENTS_P

ERC

Coverage of

incident

notification

s

PERC SW

compone

nt/syste

m

protectio

n, data

protectio

n,

manage

ment

This metric provides the percentage

of privacy incidents and breaches for

which affected stakeholders were

notified, for a given period of time.

0 ≤ int ≤

100

% n/a ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

MITIGAT

ED_HIGH_

VULNS_PE

RC

Mitigated

High

Vulnerabili

ty Measure

PERC SW

compone

nt/syste

m

protectio

n,

manage

ment

It measures the percentage of the

vulnerabilities ranked as HIGH in the

NVD database that have been

mitigated within organizationally

defined time periods after discovery.

0 ≤ int ≤

100

% n/a ge (>=)

REMOTE_

ACCESSES

_PERC

Remote

Access

Control

Measure

PERC SW

compone

nt/syste

m

protectio

n,

manage

ment

It measures the percentage (%) of

remote access points used to gain

unauthorized access.

0 ≤ int ≤

100

% n/a le (<=)

SHARED_

ACCOUNT

S_PERC

User

Accounts

Measure

PERC SW

compone

nt/syste

m

protectio

n,

manage

ment


users with access to shared

accounts.

0 ≤ int ≤

100

% n/a le (<=)

REPORTE

D_

INTIME_I

NCID_

PERC

Incident

Response

Measure

PERC SW

compone

nt/syste

m

protectio

n,

manage

ment


incidents reported within required

time frame per applicable incident

category.

0 ≤ int ≤

100

% n/a ge (>=)

REMEDIA

TED_

INTIME_V

Remediate

d

PERC SW

compone

nt/syste

m


vulnerabilities remediated within

organization-specified time frames.

0 ≤ int ≤

100

% n/a ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

ULNS_

PERC

Vulnerabili

ty Measure

protectio

n,

manage

ment

MITIGAT

ED_OS_

VULNS_PE

RC

Mitigated

OS

Vulnerabili

ties

PERC SW

compone

nt/syste

m

protectio

n,

manage

ment


operating system vulnerabilities for

which patches have been applied or

that have been otherwise mitigated

(over total number of applicable

vulnerabilities found through scans)

0 ≤ int ≤

100

% n/a ge (>=)

VULN_SC

ANNED_

SYSTEMS_

PERC

Vulnerabili

ty Scanning

Coverage

PERC SW

compone

nt/syste

m

protectio

n,

manage

ment

It measures the percentage of the

organization’s systems under

management that were checked for

vulnerabilities during vulnerability

scanning and identification

processes. This metric is used to

indicate the scope of vulnerability

identification efforts.

0 ≤ int ≤

100

% n/a ge (>=)

RCVD_AU

DITS_

PERC

Successful

audits

received

PERC manage

ment


percentage of independent reviews

and assessments

performed to the policies and

procedures in place for complying

with applicable contractual and

regulatory obligations.

0 ≤ int ≤

100

% n/a ge (>=)

DATA_SU

BJ_

ACCESS_R

PLYS_

PERC

Responded

data

subject

access

requests

PERC Data

protectio

n


percentage of data subject access

requests that have been responded

and for which a record of the request

and the response exists.

0 ≤ int ≤

100

% n/a ge (>=)

RESP_CER

TIFICATI

ON_PERC

Certificatio

n of

acceptance

PERC manage

ment


percentage of employees who have

certified their acceptance of

0 ≤ int ≤

100

% n/a ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

of

responsibil

ity

responsibilities for activities that

involve handling of private data.

REVIEWE

D_

COMPLAI

NTS_PERC

Reviewed

complaints

PERC manage

ment

This metric indicates the percentage

of complaints that have been

reviewed during a

given period of time.

0 ≤ int ≤

100

% n/a le (<=)

CONF_CH

ANGES_PE

RC

Configurati

on Changes

Measure

PERC manage

ment

It measures the percentage (%)

approved and implemented

configuration changes identified in

the latest automated baseline

configuration.

0 ≤ int ≤

100

% n/a ge (>=)

CONTING

ENCY_

PLAN_TES

TED_

SYSTEMS_

PERC

Contingenc

y Plan

Testing

Measure

PERC manage

ment


information systems that have

conducted annual contingency plan

testing.

0 ≤ int ≤

100

% n/a ge (>=)

MANTEIN

ED_

SYSTEMS_

PERC

Maintenanc

e Measure

PERC manage

ment


system components that undergo

maintenance in accordance with

formal maintenance schedules.

0 ≤ int ≤

100

% n/a ge (>=)

SANITIZE

D_

MEDIA_P

ERC

Media

Sanitizatio

n Measure

PERC manage

ment


media that passes sanitization

procedures testing for FIPS 199 high

impact systems.

0 ≤ int ≤

100

% n/a ge (>=)

PHY_INCI

DENTS_P

ERC

Physical

Security

Incidents

Measure

PERC manage

ment


physical security incidents allowing

unauthorized entry into facilities

containing information systems.

0 ≤ int ≤

100

% n/a le (<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

INTIME_S

OLVED_IN

CIDENTS_

PERC

Percentage

of timely

incident

resolutions

PERC SW

compone

nt/syste

m

protectio

n,

manage

ment


security incidents that were solved

in a given period of time

0 ≤ int ≤

100

% n/a ge (>=)

AUTHORI

ZED_

USERS_PE

RC

Planning

Measure

PERC manage

ment

It measures the percentage of

employees who are authorized

access to information systems only

after they sign an acknowledgement

that they have read and understood

rules of behaviour.

0 ≤ int ≤

100

% n/a ge (>=)

PERSONN

EL_

SCREENIN

G_PERC

Personnel

Security

Screening

Measure

PERC manage

ment


individuals screened before being

granted access to organizational

information and information

systems .

0 ≤ int ≤

100

% n/a ge (>=)

SECURITY

_

CONTRAC

TS_PERC

Service

Acquisition

Contract

Measure

PERC manage

ment


system and service acquisition

contracts that include security

requirements and/or specifications.

0 ≤ int ≤

100

% n/a ge (>=)

DEVICE_

PROTECT

ION_PERC

System and

Communic

ation

Protection

Measure

PERC manage

ment

It measures the percentage of

mobile computers and devices that

perform all cryptographic

operations using FIPS 140-2

validated cryptographic modules

operating in approved modes of

operation.

Strategic Goal: Accelerate the

development and use of an

electronic information

infrastructure.

Information Security Goal: Allocate

sufficient resources to adequately

0 ≤ int ≤

100

% n/a ge (>=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

protect electronic information

infrastructure.

LAST_RQS

T_LOC

Most recent

request

location

RL Data

protectio

n, SW

compone

nt/syste

m

protectio

n

The metric returns the last location

source of the request made by a user

to the cloud service

geograp

hical

zone

n/a eq (=)

MOST_FR

EQ_

RQST_LO

C

Most

frequent

request

location

RL Data

protectio

n, SW

compone

nt/syste

m

protectio

n

The metric returns the most

frequency location source of the

request made by a user to the cloud

service

geograp

hical

zone

n/a

MTPD Maximum

tolerable

period for

disruption

(MTPD)

TIME manage

ment

This metric indicates the maximum

tolerable period for disruption, as

defined by the

organizations’ BCR plans.

int > 0 minute

s

n/a le (<=)


Metric ID Metric

Name

Abstra

ct

Metric

ID

Applica

bility

Description Value

Range


used in SLO

APP_RSP_

TIME

Application

response

time

TIME SW

compone

nt/syste

m

protectio

n

The average time (in milliseconds)

to answer a specific request (can be

categorized by request)

int > 0 millise

conds

1 le (<=)


Appendix C. Monitoring agents Chef recipes

Installing MMT agents:

#

# Cookbook:: mmt-network

# Recipe:: default

#

# Copyright:: 2017, Montimage EURL, All Rights Reserved.

platform = node[:platform]

#global variable representing name of cookbook

# => we donot need to re-declare

#cookbook_name = "install-mmt-network"

#install mmt packages

bash "install-mmt-packages" do

user "root"

cwd "#{Chef::Config[:file_cache_path]}/cookbooks/#{cookbook_name}/files/#{platform}"

case platform

when "ubuntu"

code <<-EOF

dpkg -i mmt-dpi*.deb

dpkg -i mmt-security*.deb

dpkg -i mmt-probe*.deb

ldconfig

EOF

when "centos"

code <<-EOF

rpm -i mmt-dpi*.rpm

rpm -i mmt-security*.rpm

rpm -i mmt-probe*.rpm

ldconfig

EOF

end

end

Starting MMT agents

#

# Cookbook:: start-mmt-network

# Recipe:: default

#


include_recipe '::parser'

probe_id = node["mmt"]["id"]

input_source = node["mmt"]["nic"]

if probe_id == nil then

fail "Cannot find parameters of id and nic"

end


puts "Monitoring agent having id = #{probe_id} starts to monitor on NIC #{input_source}"

#copy kafka certificat

cookbook_file "/opt/mmt/probe/kafka-ca.cert" do

owner "root"

group "root"

mode 0644

source "kafka-ca.cert"

action :create

end

#update default configuration by a new one

template "/opt/mmt/probe/mmt-probe.conf" do

owner "root"

group "root"

mode 0644

source "mmt-probe.conf.erb"

action :create

variables(

:probe_id => probe_id,

:input_source => input_source

)

#notifies :create, "bash[start-mmt-probe]", :immediate

end

#run mmt-probe in background

bash "start-mmt-probe" do

user "root"

code <<-EOF

pkill mmt-probe

( mmt-probe > /tmp/mmt-probe.log 2>&1 ) &

EOF

End

#

# Cookbook:: start-mmt-network

# Recipe:: default

#


# This file will parse an implementation plan to get information concerning monitoring agent

# specifically, vm_seq_num and nic

# get private IP of running node

local_ip = node["ipaddress"]

if local_ip == nil then

fail "Cannot find local IP of this node"

end

puts "Local ip: #{local_ip}"

# get implementation plan


plan_id = node['implementation_plan_id']

begin

plan = search("implementation_plans","id:#{plan_id}").first

#if we do not find

rescue Net::HTTPServerException

puts "Not found plan_id by searching"

plan = nil

plans = node["implementation_plans"]

if plan_id == nil or plans == nil then

fail "Implementation plain is undefined"

end

node["implementation_plans"].each do | p |

if p["plan_id"] == plan_id then

plan = p

end

end

end

#We found an implemenation plan?

if plan == nil then

fail "Implementation Plan with id: #{plan_id} is not present in Implementation plans data bag"

end

# default value

probe_id = 0

probe_src = "eth0"

is_found_agent = false

# search

plan['csps'].each do | csp |

csp['pools'].each do | pool |

pool['vms'].each do | vm |

#info of one vm

probe_id = vm['vm_seq_num']

probe_src = vm['nic']

#check input

if probe_id == nil then

fail "Do not find 'vm_seq_num' attribute in the implementation plan #{plan_id}"

end

if probe_src == nil then

fail "Do not find 'nic' attribute in the implementation plan #{plan_id}"

end

vm['components'].each do | component |

if (component['cookbook'] == "start-mmt-network" and component['recipe'] == "default") then


# found monitor agent

is_found_agent = true

# => need to check if this has permission to run on this VM: same private IP

component['private_ips'].each do | ip |

if (ip == local_ip ) then

puts "Found vm_seq_num = #{probe_id}, nic = #{probe_src}"

node.default["mmt"]["id"] = probe_id

node.default["mmt"]["nic"] = probe_src

return

end

end

end

end

end

end

end

if ( is_found_agent == false ) then

fail "Not found start-mmt-network cookbook"

end

fail "Not found any private IP in local_ips matches #{local_ip}"


Appendix D. Enforcement agents Chef recipes

IdM agent:

#

# Cookbook:: enforcement_agents

# Recipe:: idm

#

#

# Licensed under the Apache License, Version 2.0 (the "License");

# you may not use this file except in compliance with the License.

# You may obtain a copy of the License at:

# http://www.apache.org/licenses/LICENSE-2.0

# Developers:

# * Borja Urkizu <[email protected]>

#

include_recipe 'nodejs::nodejs_from_binary'

include_recipe 'git'

%w[/opt/musa /opt/musa/enforcement /opt/musa/enforcement/agents].each do |path|

directory path do

action :create

end

end

git '/opt/musa/enforcement/agents' do

repository 'http://chef_ro:[email protected]:7990/scm/musa/musa-assurance_platform-

enforcement_agents.git'

revision 'GetInfoFromDeployer'

action :sync

end

execute 'npm prune' do

cwd '/opt/musa/enforcement/agents'

end

#copy kafka certificate

cookbook_file "/opt/musa/enforcement/agents/plugins/broker/certs/kafka-ca.cert" do

owner "root"

group "root"

mode 0644


action :create

end

## INSTALL DEPENDENCIES

bash "install_idm_dependencies" do

cwd "/opt/musa/enforcement/agents"

code <<-EOH

npm install;

npm install plugins/*;

EOH

end


execute "chown ubuntu" do

command "chown -R ubuntu:ubuntu /opt/musa/enforcement/agents"

user "root"

end

## Configure access control agent

nodejs_npm "pm2" do

version "2.7.2"

path "/opt/musa/"

end

## Run Access Control Agent

bash "run_ac_agent" do


code <<-EOH

/opt/musa/node_modules/pm2/bin/pm2 start agent.js --name idm -- -a app.idm.json

EOH

end

AC agent:

#

# Cookbook:: enforcement_agents

# Recipe:: ac

#

#

# Licensed under the Apache License, Version 2.0 (the "License");

# you may not use this file except in compliance with the License.

# You may obtain a copy of the License at:

# http://www.apache.org/licenses/LICENSE-2.0

# Developers:

# * Borja Urkizu <[email protected]>

#

include_recipe 'nodejs::nodejs_from_binary'

include_recipe 'git'

%w[/opt/musa /opt/musa/enforcement /opt/musa/enforcement/agents].each do |path|

directory path do

action :create

end

end

git '/opt/musa/enforcement/agents' do

repository 'http://chef_ro:[email protected]:7990/scm/musa/musa-assurance_platform-

enforcement_agents.git'

revision 'GetInfoFromDeployer'

action :sync

end

execute 'npm prune' do

cwd '/opt/musa/enforcement/agents'

end


#copy kafka certificate

cookbook_file "/opt/musa/enforcement/agents/plugins/broker/certs/kafka-ca.cert" do

owner "root"

group "root"

mode 0644


action :create

end

## INSTALL DEPENDENCIES

bash "install_ac_dependencies" do


code <<-EOH

npm install;

npm install plugins/*;

EOH

end

execute "chown ubuntu" do

command "chown -R ubuntu:ubuntu /opt/musa/enforcement/agents"

user "root"

end

## Configure access control agent

nodejs_npm "pm2" do

version "2.7.2"

path "/opt/musa/"

end

## Run Access Control Agent

bash "run_ac_agent" do


code <<-EOH

/opt/musa/node_modules/pm2/bin/pm2 start agent.js --name ac -- -a app.ac.json

EOH

end


Appendix E. The MUSA IdM agent SLAT

In the following we provide the SLA Template of the MUSA Access Control Agent written in WS-

Agreement. This will be used as input in the SLA Composition process in MUSA for those applications

that use the IdM agent. For further information on SLA-based security by design mechanisms in MUSA

see deliverable D2.3 Final SbD methods for multi-cloud applications.

-<ns1:AgreementOffer xmlns:ns5="http://www.specs-

project.eu/resources/schemas/xml/control_frameworks/ccm" xmlns:ns1="http://schemas.ggf.org/graap/2007/03/ws-agreement" xmlns:ns4="http://www.specs-project.eu/resources/schemas/xml/control_frameworks/nist" xmlns:ns3="http://www.specs-project.eu/resources/schemas/xml/SLAtemplate">

-<ns1:Name>

TSMEngine_assessed_slat </ns1:Name>

-<ns1:Context>

-<ns1:AgreementInitiator>

CUSTOMER </ns1:AgreementInitiator>

-<ns1:AgreementResponder>

PROVIDER </ns1:AgreementResponder>

-<ns1:ServiceProvider>

AgreementResponder </ns1:ServiceProvider>

-<ns1:TemplateName>

ASSESSED_SLA_TEMPLATE </ns1:TemplateName> </ns1:Context>

-<ns1:Terms>

-<ns1:All>

-<ns1:ServiceDescriptionTerm ns1:Name="TSMEngine_assessed_slat" ns1:ServiceName="CUSTOM WEB APP">

-<ns3:serviceDescription>

-<ns3:serviceResources>

<ns3:resourcesProvider maxAllowedVMs="0" /> </ns3:serviceResources>

-<ns3:capabilities>

-<ns3:capability mandatory="false">

-<ns3:controlFramework id="NIST_800_53_r4" frameworkName="NIST Control framework 800-53 rev. 4">

-<ns3:NISTsecurityControl id="IA-9(1)" name="SERVICE IDENTIFICATION AND AUTHENTICATION | INFORMATION

EXCHANGE" securityControl="9"control_enhancement="1" control_family="IA">

-<ns4:description>

The organization ensures that service providers receive, validate, and transmit identification and authentication information. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="IA-5(13)" name="AUTHENTICATOR MANAGEMENT | EXPIRATION OF CACHED

AUTHENTICATORS" securityControl="5"control_enhancement="13" control_family="IA">

-<ns4:description>

The information system prohibits the use of cached authenticators after [Assignment: organization-defined time period]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="IA-4(5)" name="IDENTIFIER MANAGEMENT | DYNAMIC

MANAGEMENT" securityControl="4" control_enhancement="5"control_family="IA">

-<ns4:description>

The information system dynamically manages identifiers. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="IA-5(10)" name="AUTHENTICATOR MANAGEMENT | DYNAMIC CREDENTIAL

ASSOCIATION" securityControl="5" control_enhancement="10"control_family="IA">

-<ns4:description>

The information system dynamically provisions identities.


</ns4:description> </ns3:NISTsecurityControl> </ns3:controlFramework> </ns3:capability> </ns3:capabilities> <ns3:security_metrics /> </ns3:serviceDescription> </ns1:ServiceDescriptionTerm>

-<ns1:GuaranteeTerm ns1:Name="TSMEngine">

-<ns1:QualifyingCondition>

false </ns1:QualifyingCondition>

-<ns1:ServiceLevelObjective>

-<ns1:CustomServiceLevel>

<ns3:objectiveList /> </ns1:CustomServiceLevel> </ns1:ServiceLevelObjective> </ns1:GuaranteeTerm> </ns1:All> </ns1:Terms> </ns1:AgreementOffer>


Appendix F. The MUSA AC agent SLAT

In the following we provide the Service Level Agreement Template (SLAT) of the MUSA Access

Control Agent written in WS-Agreement. This will be used as input in the SLA Composition process in

MUSA for those applications that use the AC agent. For further information on SLA-based security by

design mechanisms in MUSA see deliverable D2.3 Final SbD methods for multi-cloud applications.

-<ns1:AgreementOffer xmlns:ns5="http://www.specs-

project.eu/resources/schemas/xml/control_frameworks/ccm"xmlns:ns1="http://schemas.ggf.org/graap/2007/03/ws-agreement" xmlns:ns4="http://www.specs-project.eu/resources/schemas/xml/control_frameworks/nist"xmlns:ns3="http://www.specs-project.eu/resources/schemas/xml/SLAtemplate">

-<ns1:Name>

ACAgentForTSMEngine_assessed_slat </ns1:Name>

-<ns1:Context>

-<ns1:AgreementInitiator>

CUSTOMER </ns1:AgreementInitiator>

-<ns1:AgreementResponder>

PROVIDER </ns1:AgreementResponder>

-<ns1:ServiceProvider>

AgreementResponder </ns1:ServiceProvider>

-<ns1:TemplateName>

ASSESSED_SLA_TEMPLATE </ns1:TemplateName> </ns1:Context>

-<ns1:Terms>

-<ns1:All>

-<ns1:ServiceDescriptionTerm ns1:Name="ACAgentForTSMEngine_assessed_slat" ns1:ServiceName="IDM">

-<ns3:serviceDescription>

-<ns3:serviceResources>

<ns3:resourcesProvider maxAllowedVMs="0" /> </ns3:serviceResources>

-<ns3:capabilities>

-<ns3:capability mandatory="false">

-<ns3:controlFramework id="NIST_800_53_r4" frameworkName="NIST Control framework 800-53 rev. 4">

-<ns3:NISTsecurityControl id="AC-4(20)" name="INFORMATION FLOW ENFORCEMENT | APPROVED

SOLUTIONS" securityControl="4" control_enhancement="20"control_family="AC">

-<ns4:description>

The organization employs [Assignment: organization-defined solutions in approved configurations] to control the flow of [Assignment: organization-defined information] across security domains. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(3)" name="SECURITY ATTRIBUTES | MAINTENANCE OF ATTRIBUTE

ASSOCIATIONS BY INFORMATION SYSTEM" securityControl="16"control_enhancement="3" control_family="AC">

-<ns4:description>

The information system maintains the association and integrity of [Assignment: organization-defined security attributes] to [Assignment: organization-defined subjects and objects]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-7(2)" name="UNSUCCESSFUL LOGON ATTEMPTS | PURGE / WIPE MOBILE

DEVICE" securityControl="7" control_enhancement="2"control_family="AC">

-<ns4:description>

The information system purges/wipes information from [Assignment: organization-defined mobile devices] based on [Assignment: organization-defined purging/wiping requirements/techniques] after [Assignment: organization-defined number] consecutive, unsuccessful device logon attempts. </ns4:description> </ns3:NISTsecurityControl>


-<ns3:NISTsecurityControl id="AC-4(10)" name="INFORMATION FLOW ENFORCEMENT | ENABLE / DISABLE SECURITY

POLICY FILTERS" securityControl="4"control_enhancement="10" control_family="AC">

-<ns4:description>

The information system provides the capability for privileged administrators to enable/disable [Assignment: organization-defined security policy filters] under the following conditions: [Assignment: organization-defined conditions]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-23" name="DATA MINING

PROTECTION" securityControl="23" control_enhancement="0" control_family="AC">

-<ns4:description>

The organization employs [Assignment: organization-defined data mining prevention and detection techniques] for [Assignment: organization-defined data storage objects] to adequately detect and protect against data mining. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-9(4)" name="PREVIOUS LOGON NOTIFICATION | ADDITIONAL LOGON

INFORMATION" securityControl="8" control_enhancement="4"control_family="AC">

-<ns4:description>

The information system notifies the user, upon successful logon (access), of the following additional information: [Assignment: organization-defined information to be included in addition to the date and time of the last logon (access)]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-5" name="SEPARATION OF

DUTIES" securityControl="5" control_enhancement="0" control_family="AC">

-<ns4:description>

The organization: a. Separates [Assignment: organization-defined duties of individuals]; b. Documents separation of duties of individuals; and c. Defines information system access authorizations to support separation of duties. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-13" name="SUPERVISION AND REVIEW — ACCESS

CONTROL" securityControl="13" control_enhancement="0" control_family="AC">

-<ns4:description>

Withdrawn: Incorporated into AC-2 and AU-6. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(21)" name="INFORMATION FLOW ENFORCEMENT | PHYSICAL / LOGICAL

SEPARATION OF INFORMATION FLOWS" securityControl="4"control_enhancement="21" control_family="AC">

-<ns4:description>

The information system separates information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques] to accomplish [Assignment: organization-defined required separations by types of information]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-21(1)" name="INFORMATION SHARING | AUTOMATED DECISION

SUPPORT" securityControl="21" control_enhancement="1"control_family="AC">

-<ns4:description>

The information system enforces information-sharing decisions by authorized users based on access authorizations of sharing partners and access restrictions on information to be shared. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(2)" name="INFORMATION FLOW ENFORCEMENT | PROCESSING

DOMAINS" securityControl="4" control_enhancement="2"control_family="AC">

-<ns4:description>

The information system uses protected processing domains to enforce [Assignment: organization-defined information flow control policies] as a basis for flow control decisions </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(16)" name="INFORMATION FLOW ENFORCEMENT | INFORMATION TRANSFERS

ON INTERCONNECTED SYSTEMS" securityControl="4"control_enhancement="16" control_family="AC">

-<ns4:description>

Withdrawn: Incorporated into AC-4. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-25" name="REFERENCE

MONITOR" securityControl="25" control_enhancement="0" control_family="AC">

-<ns4:description>

The information system implements a reference monitor for [Assignment: organization-defined access control policies] that is tamperproof, always invoked, and small enough to be subject to analysis and testing, the completeness of which can be assured.


</ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(8)" name="SECURITY ATTRIBUTES | ASSOCIATION TECHNIQUES /

TECHNOLOGIES" securityControl="16"control_enhancement="8" control_family="AC">

-<ns4:description>

The information system implements [Assignment: organization-defined techniques or technologies] with [Assignment: organization-defined level of assurance] in associating security attributes to information. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-19(4)" name="ACCESS CONTROL FOR MOBILE DEVICES | RESTRICTIONS FOR

CLASSIFIED INFORMATION" securityControl="19"control_enhancement="4" control_family="AC">

-<ns4:description>

The organization: (a) Prohibits the use of unclassified mobile devices in facilities containing information systems processing, storing, or transmitting classified information unless specifically permitted by the authorizing official; and (b) Enforces the following restrictions on individuals permitted by the authorizing official to use unclassified mobile devices in facilities containing information systems processing, storing, or transmitting classified information: (1) Connection of unclassified mobile devices to classified information systems is prohibited; (2) Connection of unclassified mobile devices to unclassified information systems requires approval from the authorizing official; (3) Use of internal or external modems or wireless interfaces within the unclassified mobile devices is prohibited; and (4) Unclassified mobile devices and the information stored on those devices are subject to random reviews and inspections by [Assignment: organization-defined security officials], and if classified information is found, the incident handling policy is followed. (c) Restricts the connection of classified mobile devices to classified information systems in accordance with [Assignment: organization-defined security policies]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6(5)" name="LEAST PRIVILEGE | PRIVILEGED

ACCOUNTS" securityControl="6" control_enhancement="5" control_family="AC">

-<ns4:description>

The organization restricts privileged accounts on the information system to [Assignment: organization-defined personnel or roles]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(7)" name="ACCOUNT MANAGEMENT | ROLE-BASED

SCHEMES" securityControl="2" control_enhancement="7"control_family="AC">

-<ns4:description>

The organization: (a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles; (b) Monitors privileged role assignments; and (c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6(6)" name="LEAST PRIVILEGE | PRIVILEGED ACCESS BY NON-ORGANIZATIONAL

USERS" securityControl="6"control_enhancement="6" control_family="AC">

-<ns4:description>

The organization prohibits privileged access to the information system by non-organizational users. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2" name="ACCOUNT

MANAGEMENT" securityControl="2" control_enhancement="0" control_family="AC">

-<ns4:description>

The organization: a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types]; b. Assigns account managers for information system accounts; c. Establishes conditions for group and role membership; d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account; e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts; f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions]; g. Monitors the use of information system accounts; h. Notifies account managers: 1. When accounts are no longer required; 2. When users are terminated or transferred; and 3. When individual information system usage or need-to-know changes; i. Authorizes access to the information system based on: 1. A valid access authorization; 2. Intended system usage; and 3. Other attributes as required by the organization or associated missions/business functions; j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(10)" name="ACCOUNT MANAGEMENT | SHARED / GROUP ACCOUNT CREDENTIAL

TERMINATION" securityControl="2"control_enhancement="10" control_family="AC">

-<ns4:description>

The information system terminates shared/group account credentials when members leave the group. </ns4:description> </ns3:NISTsecurityControl>


-<ns3:NISTsecurityControl id="AC-3(8)" name="ACCESS ENFORCEMENT | REVOCATION OF ACCESS

AUTHORIZATIONS" securityControl="3" control_enhancement="8"control_family="AC">

-<ns4:description>

The information system enforces the revocation of access authorizations resulting from changes to the security attributes of subjects and objects based on [Assignment: organization-defined rules governing the timing of revocations of access authorizations]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3(6)" name="ACCESS ENFORCEMENT | PROTECTION OF USER AND SYSTEM

INFORMATION" securityControl="3"control_enhancement="6" control_family="AC">

-<ns4:description>

Withdrawn: Incorporated into MP-4 and SC-28. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(8)" name="INFORMATION FLOW ENFORCEMENT | SECURITY POLICY

FILTERS" securityControl="4" control_enhancement="8"control_family="AC">

-<ns4:description>

The information system enforces information flow control using [Assignment: organization-defined security policy filters] as a basis for flow control decisions for [Assignment: organization-defined information flows]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-9" name="PREVIOUS LOGON (ACCESS)

NOTIFICATION" securityControl="8" control_enhancement="0" control_family="AC">

-<ns4:description>

The information system notifies the user, upon successful logon (access) to the system, of the date and time of the last logon (access). </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3" name="ACCESS

ENFORCEMENT" securityControl="2" control_enhancement="0" control_family="AC">

-<ns4:description>

The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-22" name="PUBLICLY ACCESSIBLE

CONTENT" securityControl="22" control_enhancement="0" control_family="AC">

-<ns4:description>

The organization: a. Designates individuals authorized to post information onto a publicly accessible information system; b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information; c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and d. Reviews the content on the publicly accessible information system for nonpublic information [Assignment: organization-defined frequency] and removes such information, if discovered. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-7" name="UNSUCCESSFUL LOGON

ATTEMPTS" securityControl="7" control_enhancement="0" control_family="AC">

-<ns4:description>

The information system: a. Enforces a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and b. Automatically [Selection: locks the account/node for an [Assignment: organization-defined time period]; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6" name="SEPARATION OF

DUTIES" securityControl="6" control_enhancement="0" control_family="AC">

-<ns4:description>

The organization: a. Separates [Assignment: organization-defined duties of individuals]; b. Documents separation of duties of individuals; and c. Defines information system access authorizations to support separation of duties. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16" name="SECURITY

ATTRIBUTES" securityControl="16" control_enhancement="0" control_family="AC">

-<ns4:description>

The organization: a. Provides the means to associate [Assignment: organization-defined types of security attributes] having [Assignment: organization-defined security attribute values] with information in storage, in process, and/or in transmission; b.


Ensures that the security attribute associations are made and retained with the information; c. Establishes the permitted [Assignment: organization-defined security attributes] for [Assignment: organization-defined information systems]; and d. Determines the permitted [Assignment: organization-defined values or ranges] for each of the established security attributes. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-20(3)" name="USE OF EXTERNAL INFORMATION SYSTEMS | NON-

ORGANIZATIONALLY OWNED SYSTEMS / COMPONENTS / DEVICES"securityControl="20" control_enhancement="3" control_family="AC">

-<ns4:description>

The organization [Selection: restricts; prohibits] the use of non-organizationally owned information systems, system components, or devices to process, store, or transmit organizational information. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-21(2)" name="INFORMATION SHARING | INFORMATION SEARCH AND

RETRIEVAL" securityControl="21" control_enhancement="2"control_family="AC">

-<ns4:description>

The information system implements information search and retrieval services that enforce [Assignment: organization-defined information sharing restrictions]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(11)" name="INFORMATION FLOW ENFORCEMENT | CONFIGURATION OF

SECURITY POLICY FILTERS" securityControl="4"control_enhancement="11" control_family="AC">

-<ns4:description>

The information system provides the capability for privileged administrators to configure [Assignment: organization-defined security policy filters] to support different security policies. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(4)" name="SECURITY ATTRIBUTES | ASSOCIATION OF ATTRIBUTES BY

AUTHORIZED INDIVIDUALS" securityControl="16"control_enhancement="4" control_family="AC">

-<ns4:description>

The information system supports the association of [Assignment: organization-defined security attributes] with [Assignment: organization-defined subjects and objects] by authorized individuals (or processes acting on behalf of individuals). </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(2)" name="ACCOUNT MANAGEMENT | REMOVAL OF TEMPORARY / EMERGENCY

ACCOUNTS" securityControl="2"control_enhancement="2" control_family="AC">

-<ns4:description>

The information system automatically [Selection: removes; disables] temporary and emergency accounts after [Assignment: organization-defined time period for each type of account]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-17(9)" name="REMOTE ACCESS | DISCONNECT / DISABLE

ACCESS" securityControl="17" control_enhancement="9"control_family="AC">

-<ns4:description>

The organization provides the capability to expeditiously disconnect or disable remote access to the information system within [Assignment: organization-defined time period]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(11)" name="ACCOUNT MANAGEMENT | USAGE

CONDITIONS" securityControl="2" control_enhancement="11"control_family="AC">

-<ns4:description>

The information system enforces [Assignment: organization-defined circumstances and/or usage conditions] for [Assignment: organization-defined information system accounts]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(14)" name="INFORMATION FLOW ENFORCEMENT | SECURITY POLICY FILTER

CONSTRAINTS" securityControl="4"control_enhancement="14" control_family="AC">

-<ns4:description>

The information system, when transferring information between different security domains, implements [Assignment: organization-defined security policy filters] requiring fully enumerated formats that restrict data structure and content. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-24(2)" name="ACCESS CONTROL DECISIONS | NO USER OR PROCESS

IDENTITY" securityControl="24" control_enhancement="2"control_family="AC">

-<ns4:description>

The information system enforces access control decisions based on [Assignment: organization-defined security attributes] that do not include the identity of the user or process acting on behalf of the user.


</ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-7(1)" name="UNSUCCESSFUL LOGON ATTEMPTS | AUTOMATIC ACCOUNT

LOCK" securityControl="7" control_enhancement="1"control_family="AC">

-<ns4:description>


-<ns3:NISTsecurityControl id="AC-2(12)" name="ACCOUNT MANAGEMENT | ACCOUNT MONITORING / ATYPICAL

USAGE" securityControl="2" control_enhancement="12"control_family="AC">

-<ns4:description>

The organization:(a) Monitors information system accounts for [Assignment: organization-defined atypical usage]; and (b) Reports atypical usage of information system accounts to [Assignment: organization-defined personnel or roles]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-18(4)" name="WIRELESS ACCESS | RESTRICT CONFIGURATIONS BY

USERS" securityControl="18" control_enhancement="4"control_family="AC">

-<ns4:description>

The organization identifies and explicitly authorizes users allowed to independently configure wireless networking capabilities. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-14" name="PERMITTED ACTIONS WITHOUT IDENTIFICATION OR

AUTHENTICATION" securityControl="14" control_enhancement="0"control_family="AC">

-<ns4:description>

The organization: a. Identifies [Assignment: organization-defined user actions] that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and b. Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-12(1)" name="SESSION TERMINATION | USER-INITIATED LOGOUTS / MESSAGE

DISPLAYS" securityControl="12"control_enhancement="1" control_family="AC">

-<ns4:description>

The information system: (a) Provides a logout capability for user-initiated communications sessions whenever authentication is used to gain access to [Assignment: organization-defined information resources]; and (b) Displays an explicit logout message to users indicating the reliable termination of authenticated communications sessions. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(17)" name="INFORMATION FLOW ENFORCEMENT | | DOMAIN

AUTHENTICATION" securityControl="4" control_enhancement="17"control_family="AC">

-<ns4:description>

The information system uniquely identifies and authenticates source and destination points by [Selection (one or more): organization, system, application, individual] for information transfer. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(13)" name="ACCOUNT MANAGEMENT | DISABLE ACCOUNTS FOR HIGH-RISK

INDIVIDUALS" securityControl="2"control_enhancement="13" control_family="AC">

-<ns4:description>

The organization disables accounts of users posing a significant risk within [Assignment: organization-defined time period] of discovery of the risk. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6(7)" name="LEAST PRIVILEGE | REVIEW OF USER

PRIVILEGES" securityControl="6" control_enhancement="7" control_family="AC">

-<ns4:description>

The organization: (a) Reviews [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges; and (b) Reassigns or removes privileges, if necessary, to correctly reflect organizational mission/business needs. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-9(1)" name="PREVIOUS LOGON NOTIFICATION | UNSUCCESSFUL

LOGONS" securityControl="8" control_enhancement="1"control_family="AC">

-<ns4:description>

The information system notifies the user, upon successful logon/access, of the number of unsuccessful logon/access attempts since the last successful logon/access. </ns4:description> </ns3:NISTsecurityControl>


-<ns3:NISTsecurityControl id="AC-17(6)" name="REMOTE ACCESS | PROTECTION OF

INFORMATION" securityControl="17" control_enhancement="6"control_family="AC">

-<ns4:description>

The organization ensures that users protect information about remote access mechanisms from unauthorized use and disclosure. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(9)" name="INFORMATION FLOW ENFORCEMENT | HUMAN

REVIEWS" securityControl="4" control_enhancement="9"control_family="AC">

-<ns4:description>

The information system enforces the use of human reviews for [Assignment: organization-defined information flows] under the following conditions: [Assignment: organization-defined conditions]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(1)" name="SECURITY ATTRIBUTES | DYNAMIC ATTRIBUTE

ASSOCIATION" securityControl="16" control_enhancement="1"control_family="AC">

-<ns4:description>

The information system dynamically associates security attributes with [Assignment: organization-defined subjects and objects] in accordance with [Assignment: organization-defined security policies] as information is created and combined. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-18(3)" name="WIRELESS ACCESS | DISABLE WIRELESS

NETWORKING" securityControl="18" control_enhancement="3"control_family="AC">

-<ns4:description>

The organization disables, when not intended for use, wireless networking capabilities internally embedded within information system components prior to issuance and deployment. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-11" name="SESSION

LOCK" securityControl="11" control_enhancement="0" control_family="AC">

-<ns4:description>

The information system: a. Prevents further access to the system by initiating a session lock after [Assignment: organization-defined time period] of inactivity or upon receiving a request from a user; and b. Retains the session lock until the user reestablishes access using established identification and authentication procedures. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(13)" name="INFORMATION FLOW ENFORCEMENT | DECOMPOSITION INTO

POLICY-RELEVANT SUBCOMPONENTS"securityControl="4" control_enhancement="13" control_family="AC">

-<ns4:description>

The information system, when transferring information between different security domains, decomposes information into [Assignment: organization-defined policy-relevant subcomponents] for submission to policy enforcement mechanisms. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(3)" name="ACCOUNT MANAGEMENT | DISABLE INACTIVE

ACCOUNTS" securityControl="2" control_enhancement="3"control_family="AC">

-<ns4:description>

The information system automatically disables inactive accounts after [Assignment: organization-defined time period]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(10)" name="SECURITY ATTRIBUTES | ATTRIBUTE CONFIGURATION BY


-<ns4:description>

The information system provides authorized individuals the capability to define or change the type and value of security attributes available for association with subjects and objects. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(2)" name="SECURITY ATTRIBUTES | ATTRIBUTE VALUE CHANGES BY


-<ns4:description>

The information system provides authorized individuals (or processes acting on behalf of individuals) the capability to define or change the value of associated security attributes. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6(3)" name="LEAST PRIVILEGE | NETWORK ACCESS TO PRIVILEGED

COMMANDS" securityControl="6" control_enhancement="3"control_family="AC">

-<ns4:description>


The organization authorizes network access to [Assignment: organization-defined privileged commands] only for [Assignment: organization-defined compelling operational needs] and documents the rationale for such access in the security plan for the information system. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-18(5)" name="WIRELESS ACCESS | ANTENNAS / TRANSMISSION POWER

LEVELS" securityControl="18" control_enhancement="5"control_family="AC">

-<ns4:description>

The organization selects radio antennas and calibrates transmission power levels to reduce the probability that usable signals can be received outside of organization-controlled boundaries. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-11(1)" name="SESSION LOCK | PATTERN-HIDING

DISPLAYS" securityControl="11" control_enhancement="1" control_family="AC">

-<ns4:description>

The information system conceals, via the session lock, information previously visible on the display with a publicly viewable image. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(1)" name="INFORMATION FLOW ENFORCEMENT | OBJECT SECURITY

ATTRIBUTES" securityControl="4" control_enhancement="1"control_family="AC">

-<ns4:description>

The information system uses [Assignment: organization-defined security attributes] associated with [Assignment: organization-defined information, source, and destination objects] to enforce [Assignment: organization-defined information flow control policies] as a basis for flow control decisions. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(9)" name="ACCOUNT MANAGEMENT | RESTRICTIONS ON USE OF SHARED /

GROUP ACCOUNTS" securityControl="2"control_enhancement="9" control_family="AC">

-<ns4:description>

The organization only permits the use of shared/group accounts that meet [Assignment: organization-defined conditions for establishing shared/group accounts]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(7)" name="SECURITY ATTRIBUTES | CONSISTENT ATTRIBUTE

INTERPRETATION" securityControl="16" control_enhancement="7"control_family="AC">

-<ns4:description>

The organization provides a consistent interpretation of security attributes transmitted between distributed information system components. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6(1)" name="LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY

FUNCTIONS" securityControl="6" control_enhancement="1"control_family="AC">

-<ns4:description>

The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-16(6)" name="SECURITY ATTRIBUTES | MAINTENANCE OF ATTRIBUTE

ASSOCIATION BY ORGANIZATION" securityControl="16"control_enhancement="6" control_family="AC">

-<ns4:description>

The organization allows personnel to associate, and maintain the association of [Assignment: organization-defined security attributes] with [Assignment: organization-defined subjects and objects] in accordance with [Assignment: organization-defined security policies]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-14(1)" name="PERMITTED ACTIONS WITHOUT IDENTIFICATION OR

AUTHENTICATION | NECESSARY USES" securityControl="14"control_enhancement="1" control_family="AC">

-<ns4:description>


-<ns3:NISTsecurityControl id="AC-2(5)" name="ACCOUNT MANAGEMENT | INACTIVITY

LOGOUT" securityControl="2" control_enhancement="5" control_family="AC">

-<ns4:description>

The organization requires that users log out when [Assignment: organization-defined time-period of expected inactivity or description of when to log out]. </ns4:description>


</ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-9(3)" name="PREVIOUS LOGON NOTIFICATION | NOTIFICATION OF ACCOUNT

CHANGES" securityControl="8"control_enhancement="3" control_family="AC">

-<ns4:description>

The information system notifies the user of changes to [Assignment: organization-defined security-related characteristics/parameters of the user’s account] during [Assignment: organization-defined time period]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-19(5)" name="ACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE /

CONTAINER-BASED ENCRYPTION" securityControl="19"control_enhancement="5" control_family="AC">

-<ns4:description>

The organization employs [Selection: full-device encryption; container encryption] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3(1)" name="ACCESS ENFORCEMENT | RESTRICTED ACCESS TO PRIVILEGED

FUNCTIONS" securityControl="3"control_enhancement="1" control_family="AC">

-<ns4:description>


-<ns3:NISTsecurityControl id="AC-2(1)" name="ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT

MANAGEMENT" securityControl="2"control_enhancement="1" control_family="AC">

-<ns4:description>

The organization employs automated mechanisms to support the management of information system accounts. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(4)" name="ACCOUNT MANAGEMENT | AUTOMATED AUDIT

ACTIONS" securityControl="2" control_enhancement="4"control_family="AC">

-<ns4:description>

The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies [Assignment: organization-defined personnel or roles]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3(3)" name="ACCESS ENFORCEMENT | MANDATORY ACCESS

CONTROL" securityControl="3" control_enhancement="3"control_family="AC">

-<ns4:description>

The information system enforces [Assignment: organization-defined mandatory access control policy] over all subjects and objects where the policy: (a) Is uniformly enforced across all subjects and objects within the boundary of the information system; (b) Specifies that a subject that has been granted access to information is constrained from doing any of the following; (1) Passing the information to unauthorized subjects or objects; (2) Granting its privileges to other subjects; (3) Changing one or more security attributes on subjects, objects, the information system, or information system components; (4) Choosing the security attributes and attribute values to be associated with newly created or modified objects; or (5) Changing the rules governing access control; and (c) Specifies that [Assignment: organization-defined subjects] may explicitly be granted [Assignment: organization-defined privileges (i.e., they are trusted subjects)] such that they are not limited by some or all of the above constraints. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6(10)" name="LEAST PRIVILEGE | PROHIBIT NON-PRIVILEGED USERS FROM

EXECUTING PRIVILEGED FUNCTIONS" securityControl="6"control_enhancement="10" control_family="AC">

-<ns4:description>

The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-24(1)" name="ACCESS CONTROL DECISIONS | TRANSMIT ACCESS AUTHORIZATION

INFORMATION" securityControl="24"control_enhancement="1" control_family="AC">

-<ns4:description>

The information system transmits [Assignment: organization-defined access authorization information] using [Assignment: organization-defined security safeguards] to [Assignment: organization-defined information systems] that enforce access control decisions. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3(4)" name="ACCESS ENFORCEMENT | DISCRETIONARY ACCESS


-<ns4:description>

The information system enforces [Assignment: organization-defined discretionary access control policy] over defined subjects and objects where the policy specifies that a subject that has been granted access to information can do one or more of the following:


(a) Pass the information to any other subjects or objects; (b) Grant its privileges to other subjects; (c) Change security attributes on subjects, objects, the information system, or the information system’s components; (d) Choose the security attributes to be associated with newly created or revised objects; or (e) Change the rules governing access control. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3(7)" name="ACCESS ENFORCEMENT | ROLE-BASED ACCESS


-<ns4:description>

The information system enforces a role-based access control policy over defined subjects and objects and controls access based upon [Assignment: organization-defined roles and users authorized to assume such roles]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(19)" name="INFORMATION FLOW ENFORCEMENT | VALIDATION OF

METADATA" securityControl="4" control_enhancement="19"control_family="AC">

-<ns4:description>

The information system, when transferring information between different security domains, applies the same security policy filtering to metadata as it applies to data payloads. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-2(6)" name="ACCOUNT MANAGEMENT | DYNAMIC PRIVILEGE

MANAGEMENT" securityControl="2" control_enhancement="6"control_family="AC">

-<ns4:description>

The information system implements the following dynamic privilege management capabilities: [Assignment: organization-defined list of dynamic privilege management capabilities]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-4(18)" name="INFORMATION FLOW ENFORCEMENT | SECURITY ATTRIBUTE

BINDING" securityControl="4" control_enhancement="18"control_family="AC">

-<ns4:description>

The information system binds security attributes to information using [Assignment: organization-defined binding techniques] to facilitate information flow policy enforcement. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-20(4)" name="USE OF EXTERNAL INFORMATION SYSTEMS | NETWORK

ACCESSIBLE STORAGE DEVICES" securityControl="20"control_enhancement="4" control_family="AC">

-<ns4:description>

The organization prohibits the use of [Assignment: organization-defined network accessible storage devices] in external information systems. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3(9)" name="ACCESS ENFORCEMENT | CONTROLLED

RELEASE" securityControl="3" control_enhancement="9" control_family="AC">

-<ns4:description>

The information system does not release information outside of the established system boundary unless: (a) The receiving [Assignment: organization-defined information system or system component] provides [Assignment: organization-defined security safeguards]; and (b) [Assignment: organization-defined security safeguards] are used to validate the appropriateness of the information designated for release. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-12" name="SESSION

TERMINATION" securityControl="12" control_enhancement="0" control_family="AC">

-<ns4:description>

The information system automatically terminates a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-9(2)" name="PREVIOUS LOGON NOTIFICATION | SUCCESSFUL / UNSUCCESSFUL

LOGONS" securityControl="8"control_enhancement="2" control_family="AC">

-<ns4:description>

The information system notifies the user of the number of [Selection: successful logons/accesses; unsuccessful logon/access attempts; both] during [Assignment: organization-defined time period]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-3(10)" name="ACCESS ENFORCEMENT | AUDITED OVERRIDE OF ACCESS

CONTROL MECHANISMS" securityControl="3"control_enhancement="10" control_family="AC">

-<ns4:description>


The organization employs an audited override of automated access control mechanisms under [Assignment: organization-defined conditions]. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-15" name="AUTOMATED

MARKING" securityControl="15" control_enhancement="0" control_family="AC">

-<ns4:description>

Withdrawn: Incorporated into MP-3. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-6(2)" name="LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY

FUNCTIONS" securityControl="6"control_enhancement="2" control_family="AC">

-<ns4:description>

The organization requires that users of information system accounts, or roles, with access to [Assignment: organization-defined security functions or security-relevant information], use non-privileged accounts or roles, when accessing nonsecurity functions. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-24" name="ACCESS CONTROL

DECISIONS" securityControl="24" control_enhancement="0" control_family="AC">

-<ns4:description>

The organization establishes procedures to ensure [Assignment: organization-defined access control decisions] are applied to each access request prior to access enforcement. </ns4:description> </ns3:NISTsecurityControl>

-<ns3:NISTsecurityControl id="AC-10" name="CONCURRENT SESSION

CONTROL" securityControl="10" control_enhancement="0" control_family="AC">

-<ns4:description>

The information system limits the number of concurrent sessions for each [Assignment: organization-defined account and/or account type] to [Assignment: organization-defined number]. </ns4:description> </ns3:NISTsecurityControl> </ns3:controlFramework> </ns3:capability> </ns3:capabilities>

-<ns3:security_metrics>

-<ns3:Metric name="Planning Measure" referenceId="AUTHORIZED_USERS_PERC">

-<MetricDefinition>

-<expression>

(Number of users who are granted system access after signing rules of behavior/total number of users with system access) *100 </expression>

-<definition>

It measures the percentage of employees who are authorized access to information systems only after they sign an acknowledgement that they have read and understood rules of behavior. </definition> </MetricDefinition> </ns3:Metric>

-<ns3:Metric name="Identity Assurance" referenceId="AUTHENTICATION_LEVEL">

-<MetricDefinition>

<expression />

-<definition>

This metric describes the quality of the authentication mechanisms in place. </definition> </MetricDefinition> </ns3:Metric>

-<ns3:Metric name="User Accounts Measure" referenceId="SHARED_ACCOUNTS_PERC">

-<MetricDefinition>

-<expression>

(Number of users with access to shared accounts/total number of users) *100 </expression>

-<definition>

It measures the percentage (%) of users with access to shared accounts. </definition> </MetricDefinition> </ns3:Metric>

-<ns3:Metric name="Personnel Security Screening Measure" referenceId="PERSONNEL_SCREENING_PERC">


-<MetricDefinition>

-<expression>

(Number of individuals screened/total number of individuals with access) *100 </expression>

-<definition>

It measures the percentage (%) of individuals screened before being granted access to organizational information and information systems . </definition> </MetricDefinition> </ns3:Metric>

-<ns3:Metric name="Mean time to revoke users" referenceId="MTT_REVOKE_USERS">

-<MetricDefinition>

-<expression>

T_i: Revocation time for user i (expressed in a given time unit, such as hours) N: Total number of user revocation, for a given period of timeOutput = (1/N) *SUM(T_i) </expression>

-<definition>

This attribute describes quantitatively how fast an organization revokes users<= access to data and organizationally-owned or managed (physical and virtual) applications, infrastructure systems, and network components, based on user's change in status (e.g., termination of employment or other business relationship, job change or transfer). </definition> </MetricDefinition> </ns3:Metric>

-<ns3:Metric name="User Accounts Measure" referenceId="SHARED_ACCOUNTS_PERC">

-<MetricDefinition>

-<expression>

(Number of users with access to shared accounts/total number of users) *100 </expression>

-<definition>

It measures the percentage (%) of users with access to shared accounts. </definition> </MetricDefinition> </ns3:Metric>

-<ns3:Metric name="Identity Assurance" referenceId="AUTHENTICATION_LEVEL">

-<MetricDefinition>

<expression />

-<definition>

This metric describes the quality of the authentication mechanisms in place. </definition> </MetricDefinition> </ns3:Metric>

-<ns3:Metric name="Application response time" referenceId="APP_RSP_TIME">

-<MetricDefinition>

<expression />

-<definition>

The average time (in milliseconds) to answer a specific request (can be categorized by request) </definition> </MetricDefinition> </ns3:Metric> </ns3:security_metrics> </ns3:serviceDescription> </ns1:ServiceDescriptionTerm>

-<ns1:GuaranteeTerm ns1:Name="ACAgentForTSMEngine">

-<ns1:QualifyingCondition>

false </ns1:QualifyingCondition>

-<ns1:ServiceLevelObjective>

-<ns1:CustomServiceLevel>

-<ns3:objectiveList>

-<ns3:SLO SLO_ID="slo0">

-<ns3:MetricREF>

AUTHORIZED_USERS_PERC </ns3:MetricREF>


-<ns3:SLOexpression>

-<ns3:oneOpExpression>

-<ns3:operator>

geq </ns3:operator> </ns3:oneOpExpression> </ns3:SLOexpression> </ns3:SLO>


-<ns3:MetricREF>

AUTHENTICATION_LEVEL </ns3:MetricREF>



-<ns3:operator>



-<ns3:MetricREF>

SHARED_ACCOUNTS_PERC </ns3:MetricREF>



-<ns3:operator>

leq </ns3:operator> </ns3:oneOpExpression> </ns3:SLOexpression> </ns3:SLO>


-<ns3:MetricREF>

PERSONNEL_SCREENING_PERC </ns3:MetricREF>



-<ns3:operator>



-<ns3:MetricREF>

MTT_REVOKE_USERS </ns3:MetricREF>



-<ns3:operator>



-<ns3:MetricREF>

SHARED_ACCOUNTS_PERC </ns3:MetricREF>




-<ns3:operator>



-<ns3:MetricREF>

AUTHENTICATION_LEVEL </ns3:MetricREF>



-<ns3:operator>



-<ns3:MetricREF>

APP_RSP_TIME </ns3:MetricREF>



-<ns3:operator>

leq </ns3:operator> </ns3:oneOpExpression> </ns3:SLOexpression> </ns3:SLO> </ns3:objectiveList> </ns1:CustomServiceLevel> </ns1:ServiceLevelObjective> </ns1:GuaranteeTerm> </ns1:All> </ns1:Terms> </ns1:AgreementOffer>


Appendix G. The MUSA agent plugins configuration and

interfaces

In this annex, we provide the description of the configuration of the common plugins and the IdM and

AC plugins that are used to create the MUSA IdM agent and MUSA AC agent. We also provide at the

end the summary of the interfaces offered by the plugins.

1. Logger

A logger service that sends log to stdout. The service name to set in “consumes” property in config file

is log. See logger service’s readme file in enforcement agents repository for more information about

available service functions.

Configuration:

● transports: where every log entry should be written, could be: file, console, ...

Example: "log": {

"packagePath": "./plugins/log",

"options": {

"transports": [

{

"name": "file",

"options": {

"name": "musa-logger-ac",

"filename": "musa-agent-ac.log"

}

}

]

}

},

2. Events

An events service to subscribe and emit events. The service name to set in “consumes” property in

config file is events. See event service’s readme file in enforcement agent repository for more

information about available service functions.

Configuration:

-

Example:

"events": {

"packagePath": "./plugins/events",

"options": {}

},

3. Broker

A broker service to send and subscribe to kafka events. The service name to set in “consumes” property

in config file is broker. See broker service’s readme file in enforcement agent repository for more

information about available service functions.


Configuration:

● hosts: where kafka-server is located. E.g. "mykafka.enforce.cu.cc:2181"

● client: the client configuration

○ sslOptions

○ connectionString

○ clientId

Example:

"broker": {

"packagePath": "./plugins/broker",

"options": {

"hosts": "127.0.0.1:2181",

"client": {

"sslOptions": {

"rejectUnauthorized": false,

"ca": "./plugins/broker/certs/kafka-ca.cert"

},

"connectionString": "127.0.0.1:2181",

"clientId": "musa-agent"

}

}

},

4. Proxy

A proxy service to register http verbs on urls as a middleware to intercept http requests. The service

name to set in “consumes” property in config file is proxy. See proxy service’s readme file in

enforcement agent repository for more information about available service functions.

Configuration:

● host: the host to expose the proxy server. E.g. "0.0.0.0"

● port: the port to expose the proxy server. E.g. "3000"

● headers: the headers to retrieve from request

○ token: the header string that holds the user's jwt token

○ provider: the idp provider that issued token

Example: "proxy": {

"packagePath": "./plugins/proxy",

"options": {

"host": "0.0.0.0",

"port": 4000,

"secure": false,

"headers": [

{

"name": "token",

"value": "X-access-token"

}

]

}

},


5. Agent

An agent service to manage the lifecycle of agent using a Finite State Machine. The service name to set

in “consumes” property in config file is agent. See agent service’s readme file in enforcement agent

repository for more information about available service functions.

Configuration:

● agentID: the id of the agent. This will be used to identify this agent on Enforcement Service.

E.g. "e1"

● type: the type of this agent. E.g. "IDentityManager"

● initialState: the initial state of the agent. E.g. "initial"

● keepAliveInterval: the interval of keep alive msg to send to Enforcement Service. E.g. 30000

Example: "agent": {

"packagePath": "./plugins/agent",

"options": {

"agentID": "comp1",

"type": "AccessControl",

"keepAliveInterval": 300000

}

}

6. JWT

An jwt service to manage the lifecycle of jwt tokens. The service name to set in “consumes” property in

config file is jwt. See jwt service’s readme file in enforcement agent repository for more information

about available service functions.

Configuration:

● agentID: the id of the agent. This will be used to identify this agent on Enforcement Service.

E.g. "e1"

● type: the type of this agent. E.g. "IDentityManager"

● initialState: the initial state of the agent. E.g. "initial"

● keepAliveInterval: the interval of keep alive msg to send to Enforcement Service. E.g. 30000

Example: "jwt": {

"packagePath": "./plugins/jwt",

"options": {

"secret": "hM9LSBYsw-U68xNsuDdAfOjDyFSI-cslT3a2-z",

"issuer": "https://musa.eu.auth0.com/",

"remote": {

"headers": {

"token": "X-access-token",

"payload": "X-access-payload",

"options": "X-token-options"

},

"host": "https://musa.eu/jwt",

"verify": "/verify",

"sign": "/sign"

},

"pem": "./certs/.pem",

"cert": "./certs/musa.cert",

"mode": "direct"


}

},

7. Identity Management

An Identity Management service to manage the lifecycle of authentication. The service name to set in

“consumes” property in config file is idm. See idm service’s readme file in enforcement agent repository

for more information about available service functions.

Configuration:

■ cookie_secret: secret to use on gateway session. E.g. "eljfwmtewio181d4.3dPOLbp"

■ cookie_name: name to use on gateway session. E.g. "musag"

■ idps: An array with available authenticate providers. Currently only Auth0 is available:

○ name: name of the provider. E.g. "auth0"

○ idp_type: the type of the idp. E.g. "auth0"

○ domain: the domain of the auth0 project. E.g. "yourapplication.domain.eu.auth0.com "

○ clientID: the clientID of the auth0 account. E.g.

"mpM8ODeFkxgjadJ1YZn2yX6PEAz7XnBl"

○ clientSecret: the client secret of the auth0 account. E.g. "bX8TSBYmp-

U75xNswCdAfkorslT3a1"

○ signinPath: the path to handle signin process. E.g. "/auth/auth0"

○ signoutPath: the path to handle signout process. E.g. "/auth/signout"

○ passReqToCallback: E.g. true

○ callbackURL: After the user authenticates we will only call back to any of these URLs.

E.g. "https://myidm.enforce.cu.cc:3000/callback"

○ jwt: configuration of JWT Rest Service

■ pem: path to perm obtained from Auth0. E.g. "./idm/providers/

yourapplication.domain.eu.auth0pem"

■ cert: path to cert obtained from Auth0. E.g. "./idm/providers/

yourapplication.domain.eu.auth0.cert"

■ issuer: url of the Auth0 JWT issuer. E.g. "https://

yourapplication.domain.eu.auth0.com/

■ webapps: An array of client webapp integrated. For each webapp registered, the agent will need:

○ appID: a client ID, each client will have a unique ID. E.g. clientID_1

○ successRedirect: callback to redirect browser when signin process is successfully done.

E.g. "http://mywebapp.enforce.cu.cc:3001/auth/account"

○ failureRedirect: callback to redirect browser when signin process is failure. E.g.

"http://mywebapp.enforce.cu.cc:3001/auth/fail"

○ signoutRedirect: callback to redirect browser when signout process is successfully

done. E.g. "http://mywebapp.enforce.cu.cc:3001/auth/post/signout".

Example: "idm": {

"packagePath": "./plugins/idm",

"options": {

"cookie_secret": "eljfwejewio282d4.3dPOLaw·q253%4wwqwqqs1&",

"cookie_name": "musag",

"idps": [

{

"name": "auth0",

"domain": "musa.eu.auth0.com",

"idp_type": "auth0",


"clientID": "rrG4OMeKxmgjadY1HZn2zX6KEAz7XnBl",

"clientSecret": "hM9LSBYsw-U68xNsuDdAfOjDyFSI-cslT3a2-z_",

"signinPath": "/auth/auth0",

"signoutPath": "/auth/signout",

"passReqToCallback": true,

"scope": "openid email app_metadata",

"callbackURL": "http://idm-

musa.enforcement.cu.cc:3000/callback",

"callbackHTTPMethod": "get"

}

],

"webapps": [

{

"appID": "clientID_1",

"successRedirect": "http://webapp-

musa.enforcement.cu.cc:3001/auth/account",

"failureRedirect": "http://webapp-

musa.enforcement.cu.cc:3001/auth/fail",

"signoutRedirect": "http://webapp-

musa.enforcement.cu.cc:3001/auth/post/signout"

}

]

}

}

8. Access Control

An Access Control service to manage the authorization process of http requests. The service name to set

in “consumes” property in config file is ac. See ac service’s readme file in enforcement agent repository

for more information about available service functions.

Configuration:

● enable: apply enforcement must be enabled. If false, every request will be redirected without

being evaluated.

● enforcement: the enforcement configuration. Basically, the policies to apply on every request.

○ apply: combining algorithm, it could be “permit-overrides” or “deny-overrides”.

○ policies: an array of XACML policies defined in JSON format.

Example: "accesscontrol": {

"packagePath": "./plugins/accessControl",

"options": {

"enable": true,

"enforcement": {

"apply": "permit-overrides",

"policies": []

}

}

}

9. Agent Interface Specification Model

Each agent exposes a service, and every service exposes some functions to be called by other services.

Next you can see the specification model of the main services:


Service Function Arguments Description

Log error • message: the message to log

Log message on level error

warn • message: the message to log Log message on level warn

info • message: the message to log Log message on level info

debug

• message: the message to log Log message on level debug

on • Function: function to call when

message is logged on the level

• Level: the level to subscribe

Subscribe a function to execute

on every message logged on

level


Events onAny • function: the function to execute

when an event is emitted on topic

On any topic the function

subscribed is executed

on • topic: the topic to subscribe

• function: the function to execute


When a topic is emitted on topic

the subscribed function is

executed

emit • topic: the topic to emit on

• message: the message to emit

Emit the message to a topic


Proxy on • topic: the topic to subscribe. Must

to be one of the following

o request



When a topic is emitted on topic

the subscribed function is

executed

addHeaders An object with the following properties:

• name: the name of the header

• value: the header to add

On every request only the

headers registered will be

available

addService An object with the following properties:

• method: the http method

• url: the url of the request

• Function: the function to call

On every request with method

on url the function will be called

start

• function: the function to call once

started

Start intercepting requests


stop • function: the function to call once

stopped

Stop intercepting requests


Agent on • topic: the topic to subscribe. Must


o state

o message



When an event is emitted on

topic the subscribed function is

executed

doAction • action: execute the action on agent.

Must to be any action described on

states and transitions

On every request only the

headers registered will be

available

start • function: the function to call once

Start receiving actions and

messages

stop

An object with the following properties:

• function: the function to call once

started

Stop receiving actions and

messages


Broker subscribe • topic: the topic to subscribe. Must


o message



When an event is emitted on

topic the subscribed function is

executed

unsubscribe • topic: the topic to subscribe. Must

to be one of the following:

o message

• function: functio to unsubscribe

Unsubscribe from topic

emit • topic: the topic to emit. Must to be

one of the following:

o Message

• message: the message to emit

Emit a message on topic


JWT decode • token: the token to decode Decode the given token


verify • token: the token to verify

• provider: the provider that must be

on token

• options: options to verify token

• Function: function to call once

token is verified

Verify the given token using

options

sign • payload: the payload to generate

on token

• options: the options to use signing

token

Generate a JWT token using

payload and options