Scholarly article on topic 'An Integrated Meta-model for Cloud Application Security Modelling'

An Integrated Meta-model for Cloud Application Security Modelling Academic research paper on "Computer and information sciences"

CC BY-NC-ND
0
0
Share paper
Academic journal
Procedia Computer Science
OECD Field of science
Keywords
{cloud / security / control / DSL / meta-model / model / requirements / scalability / rules / metrics}

Abstract of research paper on Computer and information sciences, author of scientific article — Kyriakos Kritikos, Philippe Massonet

Abstract Model-driven engineering (MDE) promises to automate the cloud application management phases, including deployment and adaptive provisioning. However, most MDE approaches neglect the security aspect even if it is considered the number one factor for not migrating to the cloud. As such, this paper proposes a security meta-model that a cloud-based MDE approach can exploit to become security-aware. This meta-model captures both high- and low-level security requirements and capabilities to drive application deployment as well security-oriented scalability rules to guide application re-configuration. It is also coupled with OCL constraints enforcing the security domain semantics. A method for creating re-usable security elements facilitating rapid security model specification conforming to the meta-model is also proposed, to reduce the designer's modelling effort.

Academic research paper on topic "An Integrated Meta-model for Cloud Application Security Modelling"

CrossMark

Available online at www.sciencedirect.com

ScienceDirect

Procedía Computer Science 97 (2016) 84 - 93

CLOUDFORWARD:From Distributed toCompleteComputing,CF2016,18-20 October2016,Madrid,

An Integrated Meta-Model for Cloud Application Security

Modelling

Kyriakos Kritikosa *, Philippe Massonetb

aICS-FORTH, Heraklion, Crete, Greece bCETIC, Charleroi, Belgium

Abstract

Model-driven engineering (MDE) promises to automate the cloud application management phases, including deployment and adaptive provisioning. However, most MDE approaches neglect the security aspect even if it is considered the number one factor for not migrating to the cloud. As such, this paper proposes a security meta-model that a cloud-based MDE approach can exploit to become security-aware. This meta-model captures both high- and low-level security requirements and capabilities to drive application deployment as well security-oriented scalability rules to guide application re-configuration. It is also coupled with OCL constraints enforcing the security domain semantics. A method for creating re-usable security elements facilitating rapid security model specification conforming to the meta-model is also proposed, to reduce the designer's modelling effort. ©2016 The Authors.PublishedbyElsevierB.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-reviewunderresponsibility of organizing committee of the international conference on cloud forward: From Distributed to Complete Computing

Keywords: cloud;security;control;DSL;meta-model;model;requirements;scalability;rules;metrics

1. Introduction

Cloud computing promises the on-demand leashing of infinite and cheap resources to provide suitable infrastructure support to user applications. As such, it is increasingly adopted by many businesses that attempt to move their applications in the cloud to reduce costs and automate their reconfiguration. These businesses are assisted by free or proprietary cloud platforms which provide support to the application deployment and reconfiguration in the cloud.

The most sophisticated from these platforms employ model-driven engineering (MDE)1 to support the cloud application management due to its capability to automate the cloud-based application life-cycle activities as follows: (a) use of transformations to go from generic requirements to cloud-agnostic solutions and from those solutions to cloud-specific ones; (b) suitable runtime support (models@runtime2) where models are carriers of live information used to assess if user requirements are violated; (c) use of model transformations and reasoning to generate optimal deployment plans mapped to the specifics of the cloud services involved; (d) application adaptation via migrating to a new deployment plan which promises to better address the current application situation.

* Corresponding author. Tel.: +30-2810-391642 ; fax: +30-2810-391638. E-mail address: kritikos@ics.forth.gr

1877-0509 © 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of organizing committee of the international conference on cloud forward: From Distributed to Complete Computing doi:10.1016/j.procs.2016.08.283

While the aforementioned sophisticated management platforms seem to cover most user requirements and provide the respective automated support, they do not actually cover the security aspect, while security has been considered as a crucial factor towards cloud migration. Security could enhance the cloud application lifecycle activities as follows: (a) security requirements can be another driving factor apart from deployment and quality requirements towards filtering the provider space and reaching optimal application deployment solutions and (b) evaluation of security parameters (attributes or metrics) can enable assessing whether particular security levels are maintained by a cloud provider such that adaptation actions can be executed when these levels are violated leading to application reconfiguration.

In3, a risk assessment over cloud computing identified many risks related to security. One major risk relates to compliance. It was argued that "Certain organisations migrating to the cloud have made considerable investments in achieving certification either for competitive advantage or to meet industry standards or regulatory requirements (e.g., PCI DSS). This investment may be put at risk by a migration to the cloud". To mitigate these risks during the cloud provider selection, it is critical to assess each candidate cloud provider with respect to relevant cloud security risks. Cloud provider assessment methodologies, such as the Cloud Security Alliance's (CSA) Star Program Assessment and Certifications https://cloudsecurityalliance.org/star/, aim to provide a framework to evaluate and compare cloud providers. Such assessment methodologies rely on Cloud security control frameworks, such as4,5 to assess cloud providers. In such frameworks, security controls can be considered as high-level security requirements driving the cloud provider selection. Such cloud security control frameworks also define de-facto industrial standards for securing cloud infrastructures. Many critical business applications have strong requirements over cloud computing risks, and require a risk analysis before deciding to deploy them on a cloud computing platform.

Based on the above analysis, it is critical to specify security requirements on cloud deployments, link them with other requirement types and exploit them to properly manage and reconfigure cloud-based applications. As such, in the context of the PaaSage project www.paasage.eu, following a MDE approach towards multi-cloud application management, a security domain specific language (DSL) has been carefully designed and integrated with other project DSLs (collectivelly named as CAMEL - Cloud Application Modelling & Execution Language). Such integration enables this DSL to completely specify requirements on the application deployment and application reconfiguration rules. OCL6 constraints are coupled with this DSL to enforce the security domain semantics to guarantee that only syntactically and semantically correct security models are produced.

This DSL's design has been inspired by de facto industrial cloud security control standards4 as well as prominent security meta-models7. This design is also minimal in respect to the amount of concepts and the complexity in specifying security requirements to cater for a small modelling effort. The main DSL features are that it enables: (a) the specification of high-level security requirements in terms of security controls; (b) the specification of low-level security requirements in terms of constraints on security parameters; (c) linking the different types of security requirements to support requirement traceability; (d) it more extensively covers security metric specification.

This paper also proposes a method to generate a basic security model, conforming to the suggested DSL, leading to a reduced modelling effort as such it can be used as a reference when creating security-oriented requirements and adaptation rules. This model also meaningfully connects the defined concrete security elements in a specific hierarchy and partitions them accordingly in certain security domains. It also links cloud providers to high-level security capabilities (security controls supported) to enhance provider space filtering during deployment reasoning.

The rest of this paper is structured as follows. Section 2 analyses the security DSL proposed and how it integrates with other PaaSage DSLs. Section 3 explains the basic security model generation method. Section 5 reviews the related work. Finally, the last section concludes the paper and draws directions for further research.

2. PaaSaage Security DSL

2.1. Design Requirements on Security Modelling

Particular requirements for the security DSL were defined concerning especially the coverage of the cloud security domain and the integration with other CAMEL DSLs. These requirements were the following:

1. Cover basic domain concepts and their relations, such as security controls, metrics, and properties.

0 CompositeSecuntyMetnclnstanca 0 RawSecuntyMetriclnstanc

Fig. 1. The security DSL proposed

2. Enable the specification of two types of security requirements: (a) security control-based requirements and (b) security SLOs. Associate each requirement type to priorities.

3. Align the above types of requirements to the requirement DSL

4. Align security SLOs with the way normal SLOs are specified (via CAMEL Scalability Rules Language (SRL)8).

5. Provide appropriate details for security metrics to enable their proper measurement.

6. Introduce OCL constraints to cover the security domain semantics.

7. Observe the cloud security domain and check complementarities with respect to evolving security standards

These requirements were used for the initial design of the security DSL which was then updated by considering end-user and developer feedback. We should note that the last requirement was quite critical as it enabled covering some information details not originally anticipated as well as the coupling with other standards.

2.2. DSL Analysis

A DSL is usually designed by specifying its abstract syntax in terms of a specific meta-model. As such, EMF Ecore was used to specify this meta-model, depicted in Figure 1. Figure 2 also explicates the following integration points of this DSL with other CAMEL DSLs: (a) the basic CAMEL constructs from which the security DSL was built; (b) how security information complements other types of information in CAMEL to enable, e.g., the full specification of application requirements. The security DSL contains sufficient and minimal constructs to specify cloud security requirements and capabilities complemented by other constructs in other CAMEL DSLs/meta-models. This enables more focused modelling and low modelling effort. In addition, it constitutes the first complete approach towards specifying both high- and low-level security requirements as well as linking them. It is also assorted by OCL constraints, to enable semantic and syntactic model validation, specified based on the semantics of the security domain. The subsequent DSL analysis follows the presentation of different meta-model facets, along with the respective OCL rules, in different sub-sections.

2.3. Security Requirements

The security meta-model can specify two types of security requirements: security control requirements and security SLOs. Each requirement type is a sub-class of HardRequirement in the CAMEL requirement DSL. Via this sub-classing and exploiting other CAMEL constructs, end-users can specify complex combinations of any requirement type, involving logical AND and OR hierarchies in a tree-based structure. As such, they can specify different alternative service levels for an application with each level comprising both quality, security and cost requirements.

SecurityControlRequirements are linked to security controls. They express either generic security control requirements that should hold for any application or specific ones to hold for a certain associated application or its components. Such requirements should hold for whichever cloud provider is used to host an application's components. One integration point applies here: associating the security control requirement to the Component class at the CAMEL deployment DSL. This point is supported by an OCL constraint, checking that the referenced component is actually part of the deployment model of the application considered.

i RawSecurityMetra g RawSecurityMetricInstana

g Com pos i teSecu ri ty Me t rid ns ta na

S CompositeMetricInsta nefs

[g RawMetriq

g Ra wMet ricins tan a

[1..*] composingMetricInstances

[1..1] conditionContext

1 ConditionContext2

: QuantifierType = ANY

S MetricInstance

B MetricConte*!

r0..11 metricContext.

^ Condition

B MetricFormula

[1..1] formula I

I] customServiceLevel I

|g Service Leve IQbjecti^ p HardRequiremefflj

0 CompositeMetric

[0..*1 subProperties

g Security Proper^

BSecuritySLÜj S Requirement

S CompositeSecurityMetffl

B CloudProvidé

= EBoolean = falsi ro..*1 securityCapability S SecurityCapabiliq)

-»,»-

y Schedule

ndowlype : Windowlype = FIXED eType : WindowSizeType = MEAS

[1..1] metric

1..1] metric

Metric

3 Property

ncFunctionlype = PLUS

Fig. 2. Integration of security DSL with other CAMEL DSLs

Security SLOs are normal ServiceLevelObjectiveType(s) (class in requirement DSL ) which include security-based constructs, like security metrics or properties. The mapping of security SLOs to security constructs is also checked via an OCL constraint. SLOs are associated to conditions (see condition association in Figure 2) indicating that the value of a metric or property is bound, via a comparison operator (such as GREATER-THAN), to a certain threshold. Such conditions reference the application and the respective component to indicate that they should hold under this specific context. For instance, we might want to evaluate mean availability (represented by a respective metric) only for a certain application component. Via this integration point with SRL (definition of conditions) and requirement DSLs, security SLOs are expressed equivalently to any other SLO type.

2.4. Security Capabilities

To enable the proper security requirements matching, cloud provider security capabilities are modelled via the SecurityCapability class. This class associates a provider's data centre to a set of realised security controls. This enables a more sophisticated and realistic mapping between security control requirements and capabilities assisting in producing more optimal deployment plans closer to the actual security requirements posed.

2.5. Security Constructs

Four main constructs are covered: (a) security controls; (b) security metrics; (c) security metric instances; (d) security properties. Security controls are high-level security constructs, linked to a particular security domain, indicating whether certain high-level security features are in place in the provider's offered cloud services. These controls are mapped to low-level constructs, security properties and metrics, to enable linking high- and low-level requirements.

Security properties are abstract or certifiable security characteristics which can be linked to a security control and its security domain. They are sub-classes of the Property class in CAMEL SRL. The Certifiable class represents properties that can be certified via security metrics measurements. On the other hand, abstract are high-level security properties, not measurable by a metric, that are characterized by more concrete sub-properties. Security property measurability is checked via a respective OCL constraint.

An abstract security property example is incident management quality, defining the quality level in which incidents are managed by a cloud system. This property has the timely incident handling certifiable sub-property indicating the

system ability to timely handle security incidents. Such a property could be measured via the percentage of timely incident responses metric indicating the system's percentage of timely incident responses to security incidents.

Security metrics can be composite or simple. Any security metric is associated to certain information including the metric unit, value type and monotonicity (0 for negative monotonic metrics and 1 for positive monotonic metrics), inherited from the Metric class in SRL (see Figure 2). A RawSecurityMetric is directly computed from a Sensor, while a CompositeSecurityMetric is computed by applying a formula over other security metrics or properties. An example security metric is "mean time to revoke user access" defined as a composite metric derived via applying an aggregation function (i.e., AVERAGE) over a simple metric providing raw respective measurements. This composite metric has a certain unit (e.g., SECONDS - see unit association in Figure 2), measures a specific property (e.g., "User Access Revocation" - see property association in Figure 2) and has a particular value direction (e.g., 1).

By following the type-instance pattern, each metric instance instantiates one metric (see association metric in Figure 2). It is also associated to specific information constituting the metric context, spanning how often aggregation is performed (see Schedule class in Figure 2), the window of measurement (see Window class in Figure 2) and which component is measured (e.g., a cloud provider's VM instance). As such, concrete instances map to specific contexts and instantiate types which are defined across such contexts, enabling the re-use of the respective information.

Similarly to the type level, a security metric instance can be raw or composite. A raw metric instance is directly associated to the sensor providing its measurements, while a composite metric instance is computed from other metric instances (see componentMetrics association in Figure 2). Both security metric instance classes are sub-classes of respective classes in SRL.

As it can be seen, security constructs are well integrated with SRL constructs. This integration enables both quality and security requirements to be modelled and provides a competitive advantage to a system exploiting this combined information to, e.g., better match user requirements with respective cloud provider capabilities.

3. Security Model Production Method and Case Study Application

While a meta-model provides the structure via which a certain model can be produced, the modelling effort required for expressing such models can be substantial, especially if rich meta-models are involved. As such, to assist modellers and reduce their modelling effort, some information in the form of basic models should be in place which can be reused towards specifying a complete model as desired by the modeller.

In the context of the security meta-model proposed, we desire not to have each modeller specify each time: (a) all security controls needed to express security requirements or capabilities; (b) all security properties and metrics needed to express security SLOs. As such, a particular method was followed enabling to produce a basic security model that can assist modellers in security specification tasks.

The method followed to produce the basic security model relied on three input types: (a) CSA's security control matrix4, (b) the consensus assessments initiative questionnaires (CAIQ)9 posing questions assisting in evaluating a security control realisation degree and (c) two security models proposed in10,11. Concerning our first input choice, the security control matrix (CCM) is an extensive de-facto industrial standard well embraced by the research community while linked to various previous proposals in the field. Provided that the first input was selected, the second input was a rational choice as provides the means to associate security controls to cloud providers. The last input comprises two models. The first model was selected as it is embraced by the EC and was generated by a group involving members from major industrial players. It was derived by considering the specific needs of the European cloud market, especially regarding the security and data protection domains. The second is a quite extensive security model produced by a research, highly-expert in security consortium. This model along with the first one can be used as reference to link security controls to security properties and metrics. Such a linking is crucial in assessing the degree and quality of realization for a respective security control advertised to be supported by a cloud provider.

The first two inputs enable us to produce two sub-models concerning: (a) security controls and (b) security control provider capabilities. The last input enables us to produce a sub-model of security properties and metrics which is linked to the security controls identified in the first sub-model. As such, the method involves processing each input, producing respective sub-models and then linking them accordingly. In the following, each method step is analysed in detail while a pseudo-code for all the method steps can be found in https://drive.google.com/ file/d/0B1oLQgQCVlqrdG11UERKSTV5Y28/view?usp=sharing. Figure 3(a) also depicts the method content and

(a) (b)

Fig. 3. (a) The basic security model production method;(b) Security model exploitation in PaaSage provisioning workflow

the respective input and output models for each method step. The way the resulting method outputs can be exploited in the PaaSage provisioning flow is depicted in Figure 3(b).

3.1. Security Control Sub-Model Production

By processing each CCM entry, we collected the following types of information for each security control: its ID, domain, sub-domain and its description. Based on this information, we created a domain hierarchy (based on the domain and sub-domain information) under which the respective security controls (identified by the rest of the collected information) are placed. A security-control sub-model's snapshot can be found at https://drive.google.com/ open?id=0B1oLQgQCVlqrT0F4NFZwZmt1bm8. In this snapshot you can see that, for instance, the domain "Application & Interface Security" has "Application Security" as its sub-domain and the latter domain contains the "AIS-01" security control. In total, 151 domains were created, from which 13 were root, as well as 133 security controls.

3.2. Security Control Capability Sub-Model Production

When answered by cloud providers, the CAIQ questionnaire can be used to indicate how well the CCM's security controls have been realized, if realized at all. As such, each security control is associated to a set of questions. Answers to the questions can have the form of "yes" or "no" or can be more involved. In fact, as different CAIQ versions were circulated, different ways to represent this information were employed. In version "v1.1" (published in 2011), questions are answered in a single column where the cloud provider is free to provide any answer type. In version "v3.0.1" (published in 2014), the question answering involves two columns: (i) one indicating a "yes" or "no" answer; (ii) another justifying the previous answer.

As such, each cloud provider maps to one questionnaire answering and the latter must be processed to produce the provider's security control capabilities. The main problems with processing such input were the following: (a) version "v1.1" of an answered questionnaire requires manual inspection and interference to evaluate whether an involved answer to a certain query is positive or negative, and (b) IDs of the security controls map to different CCM versions for each CAIQ version. The first problem was handled in a manual way for CAIQ version "v1.1" but it is envisaged that in the future either a more automated approach is followed or all cloud providers will resort to answering the newer CAIQ version. The second problem was handled by associating the previous security control ID with the new one when processing the CCM matrix as the old control ID is also represented as a CCM column.

The main algorithm of this second step is as follows:

1. Process each questionnaire answer of a cloud provider depending on the CAIQ version

(a) If CAIQ version is "v1.1", first manually alter the questionnaire to include a new column indicating whether the answer to a query is "yes" or "no". Then, check the percentage of queries positively answered for a security control. If this percentage is above threshold T, associate security control to the respective cloud provider in the following way: check the mapping of old to new security control ID, find the security control id by searching it at the security control sub-model, create a SecurityControlCapability for the cloud provider if not exists and finally associate to it the security control.

(b) If version is "v3.0.1", first check for each query the answer in respective column. For all queries of a certain security control, compute the percentage for which the answer was positive. If the percentage is above T, associate the security control to the respective cloud provider security control capability by first identifying the security control via a query on the security control sub-model and then creating the capability.

In the end, all cloud providers which have provided an answer to the questionnaire will be associated to all the security controls for which the realization degree is above threshold T. This threshold was set with the value of 0.65 indicating that 65 percent of related queries to a security control need to be positively answered. In the future, the assessment of whether a security control has been realized could be modified to consider each query's significance to the control realization. However, this requires great manual work and probably some discussions with security experts. Thus, it was decided to be left as future work. The threshold could also be either modified, if deemed too low or high, or our approach could be slightly modified to indicate also the realisation degree for each security control when associated to a respective cloud provider. Either solution along with the respective future work direction will be examined in detail so as to appropriately adapt our security control capability production step.

3.3. Security Property and Metric Sub-Model Production

By relying on EC's recent recommendation in terms of the content of SLAs and especially with respect to a certain set of security properties (now called security model Model1) to be considered in such SLAs10 as well as the research work conducted in the Cumulus European project11 resulting in a particular security model (now called Model2), we have developed a semi-automatic algorithm able to map the security properties and metrics recommended by EC to the CSA's security controls. The main rationale is to have a structured way to filter cloud providers based on security requirements starting from high-level constructs, such as security controls, and going down to more concrete ones, such as security properties and metrics. As such, we can also identify measurable security objectives, also recommended by the EC, which can then be used to assess the degree and quality of the respective security controls realization as well as react on critical security situations.

The analysis of the step's main algorithm now follows. For each security element e in Modell, we first check whether it is a security property or metric and create the respective security meta-model class instance. If this element maps to a security property p in Model2, we copy the property hierarchy above this matched property (i.e., create also its parent properties) and then match its domain with the security control top domains. The domain matching will result in considering some security controls (of the matched domains) to be the high-level candidates to be linked with the matched property's highest property ancestor a. A particular security control is then selected, if its semantics match the ancestor property's semantics in the sense that if a security control is realized, the property is also satisfied.

If e in Model1 is not matched to a Model2 property, we first check if a higher-level property a can be created to bridge the gap between the unmatched security element and the respective security control to be linked to it. Here this task relies on the experience of the authors in the security domain and their knowledge of many prominent security and quality models (as sometimes there is usually an overlap between these two model types). Once the new, highlevel property a is created, an equivalent sub-process with respect to the previous case is followed where first the most appropriate domain d is discovered and then the most appropriate security control is selected which matches the semantics of the higher-level security property.

In the end, the input security models are transformed to the desired output security sub-model, part of which is depicted in Figure 4. In total, 34 security properties were modelled out of which 14 were root while 6 were mapped to specific metrics. The security properties were connected to 17 CCM security controls. As it can be easily seen, a hierarchy of class instances has been created, where from the top we can see the domains going down to the security controls down to the properties and sub-properties and finally to the metrics that measure them.

y Domain: Identity & Access Management

è Domain: Business Continuity Management and Operation Resilier

B Prop: identity assurance]B CertProp: user access revocatiofl

§ CertProp: user authentication and identity assurance leve

SecControl: BCR-0Í B SecControl: BCR-Oa B SecControl: BCR-11

E Prop: recoverabilit^ |B Prop: robdstnesfl [B Prep: ret enden polio|

g CertProp: data backup method[0,,*] s

B CertProp: processing purposes

B Metric mean time to revoke user access

B CertProp: level of redundancy

B Domain: Security Incdent Management, E-Discovery and Cloud Forensics

i Domain: Data Security & Information Lifecycie

g SecControl: ÇEF-dJ g ÇecControt SEF-Cq

SecControl: SEF-0

Prop: incident management quali

[0,,*] subFrop ^_

|b CertProp: logging parameters

_[0,*] su

B CertProp: timely incident handling

B Metric: percentage of timely incident resolutions

B Metric: percentage of timely incdent response

B Metric: percentage of timely incident reports

B 'lecControl: ECl-d I B EecControl: EEl-dJ

B Prop: classification managemenï B Prop: data leakage control

B CertProp: data geolocation list

B CertProp: personal data breach policy

B CertProp: data geolocation selection

Fig. 4. Snapshot of the security model produced

To better comprehend the algorithm analysed above, we provide two examples mapping to the two cases addressed by this algorithm. The first example concerns the property of "user authentication and identity assurance level" in Modell. This property also exists in Model2 and is linked in that model to the higher level property of "identity assurance". Via the domain of the latter property, "Identity & Access Management", we search for those security controls in this top-level domain (13 in number and all prefixed with "IAM" in their ID) that must have the same semantics with this property. In this way, the security control identified by IAM-02 is discovered, related to established policies and procedures at the provider side which ensure appropriate identity, entitlement and access management.

The second example concerns the property of "mean time required to revoke user access" which is not mapped to any property in Model2. As such, we first created a higher-level property to be finally linked with the respective security control, named as "User access revocation" indicating the ability of a cloud provider to revoke user access. Then, by searching all possible top domains in the security control sub-model, the "Identity & Access Management" domain was selected and its respective security controls were inspected. The most suitable security control from those inspected was found to be IAM-11 related to the timely de-provisioning of user access to data and to organizationally-owned or managed applications or infrastructural components.

4. Related Work

High-relevant work relates to certain security models and meta-models. Our proposal includes generating a security model that better links high- to low-level security constructs, while it can be expanded to include information from existing sophisticated models (11). It also includes a minimal but sufficient security DSL which is more elaborate than other security metric meta-models.

4.1. Security Models

ENISA report in12 proposes a multi-dimensional taxonomy of resilience metrics, comprising the temporal dimensions of the incident and the dimension of parts of different disciplines or domains that constitute resilience.

Both the National Institute of Security and Standards (NIST) and the Center for Internet Security (CIS) have proposed similar security models that include a detailed taxonomy of security metrics. CIS provides two metrics

categorizations13: (a) based on the business function; (b) based on the metric purpose and audience. On the other hand, NIST categorises metrics14 as implementation, effectiveness/efficiency and impact measures.

Arshad et al.15 propose a fault model for cloud computing based on which a security requirements model was developed for compute intensive workloads. Each security requirement is associated to a specific metric which in turn is mapped to one of three main security properties, namely integrity, availability and confidentiality.

CSA aims to associate CCM's security controls to concrete and quantifiable metrics. To achieve this goal, CSA's Metrics Work Group (CSA Metrics WG) has defined 10 metrics which cover approximately 25 security controls.

The EU CUMULUS project defined a quite rich and extensive vocabulary11 connecting 16 CCM control domains with both abstract and certifiable security properties. This security model could be joined with our basic security model to cover additional CCM domains and respective security controls.

4.2. Security Meta-Models

The CUMULUS security property meta-model7 associates each security property, complex or simple, to an attributes set characterizing it. While it is comprehensive and extensive, covering also security requirements characterization (e.g., threats or attacks) and their type (e.g., application, certification), it does not cover security metrics.

Wang16 proposes a formal properties set to hold for any security metric and a hierarchical model structure for security models comprising 3 main layers: (a) user space where security is defined as exhibited by users, (b) service space where intermediate-level security requirements for services are posed and (c) physical infrastructure space where the security requirements on the infrastructure supporting the intermediate-level services is specified.

Fenz and Ekelhart17 propose a security ontology including important concepts, like security controls, threats, vulnerabilities, assets and properties. This ontology covers more concepts than our security DSL so could be considered for further extending it. However, the ontology does not provide details for each security concept, such as its main attributes. It does not also model security metrics. In18, Fenz proposes a particular automated methodology via which ISO-27001 security metrics can be generated based on the organization-specific control implementation knowledge.

The PoSecCo EU project19 developed an ontology set covering many aspects of a service-based system, like access control, application, network, and virtualization. Then, by relying on inferencing and the knowledge of an IT resource's security capabilities, security capabilities for a pattern of software components can be derived. All possible security configuration alternatives can also be produced to satisfy a specific IT policy. This is a different cloud provider security capability evaluation approach than ours, relying on information not available in the public cloud world.

In20, a security-based MDE approach is proposed where security requirements are decoupled from the application such that multiple security requirements posed by different tenants can be enforced on the same application instance. This approach exploits a security meta-model covering concepts, such as security controls but not security metrics.

Nuez et al.21 define a meta-model for accountability properties and metrics, out of which a certain model is generated linking the transparency property to a metric as well as to CCM security controls by relying on CAIQ.

NIST and CIS define particular metric templates providing all appropriate information to realise security metrics. The CIS template includes information like the metric's formula, unit, measurement frequency, the data sources from which it will be calculated and the target threshold for the measure's satisfactory rating. The NIST metric template involves similar information but includes the statistical function for aggregation. Compared to SRL, most information specified by these templates is already covered with particular exceptions due to the nature of the metrics types and differences in the evaluation procedure. The exceptions include: (a) the target which should be part of a metric condition; (b) reporting format and responsible parties - this information is external to the metric specification itself; (c) implementation evidence. The metric templates proposed lack any type of formality, mapping to simple tables with textual entries. They do not also cover aspects like: (a) metric value type; (b) metric type (simple or composite); (c) metric composition - they just mention the metric formula and statistical function which maps to the actual definition of two levels of metrics, simple and composites, thus liming the metric composition cases that can be covered.

5. Conclusions and Future Work

This paper proposes a DSL enabling to specify different security requirement types, from the highest to more concrete levels. Such requirements, along with functional and quality ones, can then drive cloud application deployment

and adaptive provisioning. The proposed DSL is the first of its kind and was especially designed to be integrated with the CAMEL family of cloud-related DSLs focusing on different and complementary aspects to security. A set of OCL constraints were also modelled to enable the syntactic and semantic validation of models conforming to this DSL.

This paper also proposes a method able to produce a basic security model characterized by the following features: (a) it considers all CCM security controls; (b) it considers recommended security properties and metrics by the EC that should be utilized in security SLAs; (c) it meaningfully connects all this information to enable users to specify security requirements at different levels of abstraction. Such a basic security model lowers the user modelling effort to the minimum when specifying security requirements.

The next research directions are envisaged. First, considering prominent security models to produce a full-fledged basic security model connecting all CCM security controls to high-level properties which are then elaborated until the level of concrete metrics to enable the measurement and evaluation of concrete security levels. Second, extending the security DSL to cover possibly neglected security aspects or improve modelling of the current aspects considered. Third, coupling the security DSL with other standardised cloud languages like TOSCA to enable users to have a full control over all possible aspects when defining their application requirements. Apart from TOSCA, WS-Agreement could also benefit from the proposed DSL as this would enable users specifying all possible SLO types.

Acknowledgments

This work is partially funded by the EU FP7 PaaSage project (FP7-317715).

References

1. Schmidt, D.C.. Guest editor's introduction: Model-driven engineering. Computer 2006;39(2):25-31. doi:10.1109/MC.2006.58.

2. Amann, U., Bencomo, N., Cheng, B.H.C., France, R.B.. Models@run.time (dagstuhl seminar 11481). Dagstuhl Reports 2011;1(11):91-123.

3. Catteddu, D., Hogben, G.. Benefits, risks and recommendations for information security. Technical Report;European Network and Information Security Agency;Heraklion, Crete, Greece;2009. URL: https://www.sbs.ox.ac.uk/cybersecurity-capacity/system/ files/ENISA7,20Cloud7,20Computing7,20Security7,20Risk7,20Assessment.pdf.

4. Cloud Security Alliance,. Cloud Control Matrix. Tech. Rep.;2011. URL: https://cloudsecurityalliance.org/research/ccm/.

5. Joint Task Force Transformation Initiative, . Security and Privacy Controls for Federal Information Systems and Organizations. Technical Report;National Institute of Standards and Technology;USA;2013.

6. Object Management Group, . Object Constraint Language; 2014. http://www.omg.org/spec/OCL/2.4/.

7. Gomez, A.M., Fernandez, M.A., Harjani, R., Munoz, A.. An Engineering Process to Address Security Challenges in Cloud Computing. In: Proc. of the Third ASE International Conference on Cyber Security. ASE; 2014,.

8. Domaschka, J., Kritikos, K., Rossini, A.. SRL: A Scalability Rule Language for Multi-Cloud Environments. In: Proceedings of the 2014 IEEE International Conference on Cloud Computing Technology and Science; CLOUDCOM '14. IEEE Computer Society; 2014,.

9. Cloud Security Alliance,. Consensus Assessments Initiative Questionnaire. Tech. Rep. v3.0.1;2014.

10. Cloud Select Industry Group (C-SIG), . Cloud Service Level Agreement Standardization Guidelines. Technical Report;2014. URL: http://ec.europa.eu/information_society/newsroom/cf/dae/document.cfm?action=display&doc_id=6138.

11. Pannetrat, A.. D2.1: Security-aware SLA specification language and cloud security dependency model. Cumulus Project Deliverable;2013.

12. Trimintzios, P.. Measurement Frameworks and Metrics for Resilient Networks and Services. Technical Report;2011.

13. The Center for Internet Security,. The CIS security metrics v.1.10. Technical Report 28;USA;2010. URL: https://buildsecurityin. us-cert.gov/sites/default/files/CIS_Security_Metrics_v1.0.0.pdf.

14. Chew, E., Swanson, M., Stine, K., Bartol, N., Brown, A., Robinson, W.. Performance measurement guide for information security. Technical Report;National Institute of Standards and Technology;USA;2008.

15. Arshad, J., Townend, P., Xu, J.. Quantification of security for compute intensive workloads in clouds. In: ICPADS. IEEE;2009, p. 479-486.

16. Wang, A.J.A.. Information security models and metrics. In: ACM-SE. Kennesaw, Georgia: ACM;2005, p. 178-184.

17. Fenz, S., Ekelhart, A.. Formalizing Information Security Knowledge. In: ASIACCS. Sydney, Australia: ACM;2009, p. 183-194.

18. Fenz, S.. Ontology-based Generation of IT-security Metrics. In: SAC. Sierre, Switzerland: ACM;2010, p. 1833-1839.

19. Basile, C., Silvestro, J., Lioy, A., Canavese, D., Neri, M.A., Paraboschi, S., et al. D3.2: Security Ontology Definition. PoSecCo Project Deliverable; 2011.

20. Almorsy, M., Grundy, J., Ibrahim, A.. Adaptable, model-driven security engineering for saas cloud-based applications. Automated Software Engineering 2014;21(2):187-224. doi:10.1007/s10515-013-0133-z.

21. Nunez, D., Fernandez-Gago, C., Pearson, S., Felici, M.. A metamodel for measuring accountability attributes in the cloud. In: CLOUDCOM. Washington, DC, USA: IEEE Computer Society. ISBN 978-0-7695-5095-4;2013, p. 355-362.