Service level agreement‐based GDPR compliance and security assurance in(multi)Cloud‐based systems

IET SoftwareVolume 13, Issue 3 p. 213-222 ArticleOpen Access Service level agreement-based GDPR compliance and security assurance in(multi)Cloud-based systems Erkuden Rios, Corresponding Author Erkuden Rios erkuden.rios@tecnalia.com Fundación Tecnalia Research & Innovation, Derio, SpainSearch for more papers by this authorEider Iturbe, Eider Iturbe Fundación Tecnalia Research & Innovation, Derio, SpainSearch for more papers by this authorXabier Larrucea, Xabier Larrucea Fundación Tecnalia Research & Innovation, Derio, SpainSearch for more papers by this authorMassimiliano Rak, Massimiliano Rak orcid.org/0000-0001-6708-4032 University of Campania Studies Luigi Vanvitelli, Naples, ItalySearch for more papers by this authorWissam Mallouli, Wissam Mallouli Montimage Research & Development, Paris, FranceSearch for more papers by this authorJacek Dominiak, Jacek Dominiak CA Technologies, Warszaw, PolandSearch for more papers by this authorVictor Muntés, Victor Muntés CA Technologies, Barcelona, SpainSearch for more papers by this authorPeter Matthews, Peter Matthews CA Technologies, Berkshire, UKSearch for more papers by this authorLuis Gonzalez, Luis Gonzalez FAST Laboratory, Tampere University of Technology, Tampere, FinlandSearch for more papers by this author Erkuden Rios, Corresponding Author Erkuden Rios erkuden.rios@tecnalia.com Fundación Tecnalia Research & Innovation, Derio, SpainSearch for more papers by this authorEider Iturbe, Eider Iturbe Fundación Tecnalia Research & Innovation, Derio, SpainSearch for more papers by this authorXabier Larrucea, Xabier Larrucea Fundación Tecnalia Research & Innovation, Derio, SpainSearch for more papers by this authorMassimiliano Rak, Massimiliano Rak orcid.org/0000-0001-6708-4032 University of Campania Studies Luigi Vanvitelli, Naples, ItalySearch for more papers by this authorWissam Mallouli, Wissam Mallouli Montimage Research & Development, Paris, FranceSearch for more papers by this authorJacek Dominiak, Jacek Dominiak CA Technologies, Warszaw, PolandSearch for more papers by this authorVictor Muntés, Victor Muntés CA Technologies, Barcelona, SpainSearch for more papers by this authorPeter Matthews, Peter Matthews CA Technologies, Berkshire, UKSearch for more papers by this authorLuis Gonzalez, Luis Gonzalez FAST Laboratory, Tampere University of Technology, Tampere, FinlandSearch for more papers by this author First published: 01 June 2019 https://doi.org/10.1049/iet-sen.2018.5293Citations: 14AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract Compliance with the new European General Data Protection Regulation (Regulation (EU) 2016/679, GDPR) and security assurance are currently two major challenges of Cloud-based systems. GDPR compliance implies both privacy and security mechanisms definition, enforcement and control, including evidence collection. This study presents a novel DevOps framework aimed at supporting Cloud consumers in designing, deploying and operating (multi)Cloud systems that include the necessary privacy and security controls for ensuring transparency to end-users, third parties in service provision (if any) and law enforcement authorities. The framework relies on the risk-driven specification at design time of privacy and security level objectives in the system service level agreement and in their continuous monitoring and enforcement at runtime. 1 Introduction The entry into force of the European General Data Protection Regulation (Regulation (EU) 2016/679, from now on GDPR) in May 2018 has definitively increased the concerns on better assuring privacy measures adopted by software systems. Privacy capabilities are intrinsically related to security capabilities in personal data processing information systems. Even the GDPR itself requires that personal identifiable information (PII) shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures ('integrity and confidentiality'). (Article 5.1(f)). Therefore, there is a need to follow a holistic approach to risk assessment that addresses both privacy and security threats. This is even more challenging in (multi)Cloud-based systems because of the need of controlling not only system components' own risks but also those of the Cloud providers. Security, privacy and data protection continue to be major barriers to Cloud adoption [1]. The users' concerns on security and privacy of Cloud systems strive from the lack of trust, visibility and auditability of the privacy and security controls the Cloud providers offer in their services. Since the arrival of GDPR, solving these issues is an urgent necessity for Cloud consumers and providers acting as data processors or controllers, because the personal data processing principles in Article 5.1(a) 'lawfulness, fairness and transparency' and Article 5.2 'accountability' require systematic privacy assessment and evidence collection for assurance and transparency towards data subjects, collaborators in processing and supervisory authorities. In this paper, we propose a novel approach to ease assurance and transparency of Cloud-based systems by means of the use of Cloud service level agreements (SLAs), which are defined as a contract framework that defines the terms and conditions necessary to fulfil the obligations of a Cloud Service Provider (CSP) for the service(s) offered to a Cloud Service Customer (CSC) [2]. The paper presents our solution to SLA-based privacy and security assurance for (multi)Cloud applications, i.e. applications or services that use or have their components deployed in distributed Cloud services. The solution relies on the MUSA DevOps approach to enable the complete risk-driven life-cycle management of (multi)Cloud applications using SLAs. The advances brought include methods for the risk-driven selection of Cloud services to use, the automatic creation of the SLA offered by the application and the continuous assurance at runtime of the security and privacy service level objectives (SLOs) specified in the SLA. The solution presented is supported by the MUSA framework which is an open source integrated tool suit developed as the core result of the European Union's H2020 project MUSA [3] and is being extended with IoT privacy features in the European Union's H2020 project ENACT [4]. The work herein extends previous works [5, 6] by adding privacy SLA analysis and the full description of the risk assessment process and selection of Cloud services in MUSA based on both security and privacy controls. The MUSA SecAP assurance tool [5] has also been extended with behaviour analysis and the solution validation included privacy controls. The paper is structured as follows. Section 2 provides a review of the state of the art on Cloud SLAs usage for security and privacy assurance in Cloud systems. Section 3 introduces the complete MUSA methodology and framework for Security and Privacy SLA Assurance in (multi)Cloud-based systems. Section 4 presents the proposed risk-driven selection of Cloud services. Section 5 introduces the process to obtain the Composed SLA of (multi)Cloud-based applications. Section 6 presents the operational assurance methods proposed in the solution. Section 7 introduces the experimental results obtained in the validation of the methodology. Finally, Section 8 ends the paper with concluding remarks on the work and future lines of research. 2 Security and privacy SLAs in cloud The standard ISO/IEC 20000–1 defines a SLA as a documented agreement between the service provider and customer that identifies services and SLOs. With the terms Security SLA and Privacy SLA or privacy level agreement (PLA) we therefore, respectively, refer to the agreements that specify security level objectives and privacy level objectives offered by a service, which can be considered as part of an overall SLA or as complementary to agreements on other SLOs, such as quality or performance SLOs. In the Cloud computing context, a Cloud SLA is a contractual agreement between the CSP and the Cloud Service Customer (CSC) specifying the security grants offered by the consumed Cloud service [7]. The Cloud Security SLA and Cloud PLA would express, respectively, the security policy and privacy policy of Cloud services offered to CSCs. A (multi)Cloud-based system would therefore offer a Security SLA and PLA that depend on the Cloud Security SLA and Cloud PLA of the Cloud services it uses. 2.1 Security level agreements in Cloud The use of Cloud SLAs has been significantly explored in the last years with the aim of increasing trust in Cloud systems and facilitating their adoption. Recent projects such as SPECS [8], SLA-READY [9] and SLALOM [10] and guidelines such as CSCC's [11] have significantly advanced in Cloud SLA reference models and Cloud SLA life-cycle management systems. Still the generation of (multi)Cloud-based system SLAs and their use for GDPR compliance and security assurance that we propose in our work remained as unresolved challenges so far. With our methodology we aim at starting the path towards full automation of security and privacy assurance in Cloud-based composite services. An extract of the reference model of Cloud SLA we use in our approach is shown in Fig. 1. The model is a derivation of the SPECS Security SLA model [12] where we have consolidated the concepts to embrace the privacy perspective, thus integrating Security SLA with PLA. Fig. 1Open in figure viewerPowerPoint SLA model integrating PLA and Security SLA As shown in the model, an SLA defines the SLOs and associated controls. Controls ensure that the Cloud service's and/or the organisational CSP's capabilities satisfy the necessary requirements derived from the policies, which can range from regulations (like GDPR) to organisational policies or orders. The SLOs are expressed in terms of metrics to quantitative and unambiguously specify the capability levels guaranteed in the SLA. Therefore, Security SLAs associate to each service both the security controls that are implemented on top of it and the SLOs of the security capabilities of the service and its provider. In our approach, we adopt the NIST Security and Privacy Control Framework revision 5 Draft [13] to define the controls, which extends the previous version of the framework and defines, besides security controls, privacy controls that are specifically devoted to meet privacy requirements and to manage the privacy risks in an organisation, and joint controls that can meet privacy and security requirements at a time. Security controls are defined by NIST as the safeguards or countermeasures prescribed for an information system or an organisation to protect the confidentiality, integrity and availability of the system and its information, while privacy controls are the administrative, technical and physical safeguards employed within an agency to ensure compliance with applicable privacy requirements and manage privacy risks. NIST organises the controls in families, such as access control (AC), identification and authentication (IA), risk assessment (RA), system and communications protection (SC), system and information integrity (SI) and so on. A new privacy authorisation family has been added. The advantages of NIST over other security control frameworks for Cloud such as Cloud Security Alliance's (CSA's) Cloud Control Matrix (CCM) [14], ISO/IEC 27017 are its greater maturity, granularity of the controls and the integration of privacy and security controls. The MUSA implementation of the SLA is based on the well-known WS-Agreement standard. The metrics to set the security SLOs are selected from the MUSA Security Metric Catalogue presented in [15] which maps security threats to security controls and corresponding metrics. The catalogue is freely available in the community [3], proposed and enriched with results from different research projects (e.g. SLALOM [10], SLA-READY [9], SPECS [8] and MUSA [3]), standardisation bodies (e.g. NIST SLA [16] and ISO) and consortia like The Centre for Internet Security (CIS). The collection of metrics therein is currently being extended to include a comprehensive catalogue of privacy threats, controls and metrics as well. It is worth outlining that this paper explicitly addresses the problem of proposing a methodology to support security and privacy issues in a technical way, clearly identifying privacy and security requirements and to suggest related countermeasures. For what regards the compliance to actual regulation, like GDPR, especially in terms of legal aspects compliance, few concrete experiences are available (as an example [17]), and we hold over the topic for a future work. 2.2 PLAs in Cloud PLAs are intended to describe a service privacy policy in form of privacy controls. GDPR oriented PLA metamodels can be found in the literature [18, 19]. For Cloud services, standard privacy control definitions are offered by privacy control frameworks such as ISO/IEC 27018 for public Cloud PII processors and the PLA for Cloud services by the CSA, named the Privacy Level Agreement Code of Practise (PLA CoP) [20]. The CSA's PLA CoP is published as part of their code of conduct for GDPR compliance and it includes a PLA template intended to facilitate the declaration of the level of personal data protection a Cloud provider offers to its customers. Following the template, the PLA collects the privacy and security provisions implemented by the CSP acting as data controller or data processor (depending on the case) in a structured way in form of privacy control list. The CSA's PLA defines a total of 94 privacy controls that CSPs acting as data controllers and/or data processors would specify in their privacy policy. In Table 1, we propose the main relationship between the CSA's PLA controls, the provisions of the GDPR and the Security SLA controls. As seen in the table, we could say that the PLA contains or can refer to the Security SLA of the personal data, as security mechanisms applied by the processor on the PII are required to be expressed as part of the PLA. As explained in the previous section, the SLA controls could be expressed by using those of the CSA's CCM [19] or any other security control framework. Table 1. Proposed CSA's PLA relationship with GDPR and security controls in Security SLA PLA requirement PLA control GDPR requirement 1. CSP Declaration of Compliance and Accountability DCA-1.1 to DCA-1.4 Art. 24 – Responsibility of the controller, Art. 28 – Processor 2. CSP Relevant Contacts and its Role CAR-1.1 to CAR-1.5 Art. 24 – Responsibility of the controller, Art. 26 – Joint controllers, Art. 27 – Representatives of controllers or processors not established in the Union, Art. 28 – Processor, Art. 29 – Processing under the authority of the controller or processor 3. Ways in which the Data will be Processed WWP-1.1 to WWP-1.15, WWP-2.1, WWP-3.1 to WWP-3.5, WWP-4.1 to WWP 4.2, WWP-5.1 to WWP-5.9 Art. 25 – Data protection by design and by default 4. Recordkeeping REC-1.1 to REC-1.8, REC-2.1 to REC-2.5 Art. 30 – Records of processing activities 5. Data Transfer DTR-1.1 to DTR-1.2 Chapter 5 (Art. 44–50) – Transfers of personal data to third countries or international organisations 6. Data Security Measures (Security Controls -> in Security SLA) SEC-1.1, SEC-1.2, SEC-1.2i – availability, SEC-1.2ii – integrity, SEC-1.2.iii – confidentiality, SEC-1.2.iv – transparency, SEC-1.2.v – isolation (purpose limitation), SEC-1.2.vi – intervenability, SEC-1.2.vii – portability, SEC-1.2.viii – accountability. Art. 32 – Security of processing, Art. 5 – Principles relating to processing of personal data 1(f) – integrity and confidentiality 7. Monitoring MON-1.1 Art. 4 (1). The information provided to the public and to data subjects, Art. 5 – Principles relating to processing of personal data 1(a) -transparency 8. Personal Data Breach PDB-1.1 to PDB-1.7 Art. 33 -Notification of a personal data breach to the supervisory authority, Art. 34 – Communication of a personal data breach to the data subject, Art. 5 – Principles relating to processing of personal data 1(a) – transparency 9. Data Portability, Migration and Transfer Back PMT-1.1 to PMT-1.2 Art. 20 – Right to data portability 10. Restriction of Processing ROP-1.1 Art. 18 – Right to restriction of processing, Art. 5 –Principles relating to processing of personal data 1(b) – purpose limitation and 1(c) – data minimisation 11. Data Retention, Restitution and Deletion RRD-1.1 to RRD-1.2, RRD-2.1, RRD-3.1, RRD-4.1 to RRD-4.5 Art. 16 – Right to rectification, Art. 17 – Right to erasure ('right to be forgotten'), Art. 5 – Principles relating to processing of personal data 1(d) – accuracy and 1(e) – storage limitation 12. Cooperation with The Cloud Customers CPC-1.1 to CPC-1.2 Cooperation with data subject to fulfil Chapter 3 (Art. 12–23) – Rights of the data subject 13. Legally Required Disclosure LRD-1.1 Art. 31 – Cooperation with the supervisory authority 14. Remedies for Cloud Customers RMD-1.1 Art. 77 – Right to lodge a complaint with a supervisory authority, Art. 79 – Right to an effective judicial remedy against a controller or processor 15. CSP Insurance Policy INS-1.1 Art. 82 – Right to compensation and liability 2.3 SLAs for multiCloud In general, multiCloud-based applications have their components deployed in or their components use a priori independent Cloud services. Following this definition, federated Cloud-based and hybrid Cloud-based applications fall in the category of multiCloud applications too. Therefore, the application is a CSC that can be considered as the composition of individual components that exploit Cloud resources in diverse models (IaaS, PaaS, SaaS). The challenge is therefore the computation of the SLA offered by the application to its customers as a function of how the components are deployed, the type and number of Cloud services they use, the relationships among the Cloud services and among the components themselves and the SLAs offered by each party, i.e. components and Cloud services. State-of-the-art techniques of SLA composition are limited and mainly focused on reliability and performance controls using different techniques that range from ontology based [21] to WS-Agreement based [22]. Our approach to Security SLA composition is fully detailed in [23] and summarised in Section 5. We are currently extending this solution for PLA composition in multiCloud environments which lacks references in the literature yet. 3 MUSA DevOps approach to multiCloud security assurance The MUSA solution to holistic security assurance in multiCloud applications involves the integration of preventive measures and reactive measures. While MUSA preventive activities aim at preparing the application and defining its SLA including the offered security and privacy controls, the purpose of the reactive activities is to control the actual fulfilment of the defined SLA. MUSA proposes a DevOps oriented approach to support all the phases of the security- and privacy-aware life-cycle of multiCloud applications, from application privacy-by-design and security-by-design (including the SLA creation) to deployment on Cloud services selected, and finally continuous assurance of SLA fulfilment at operation. MUSA enables multi-disciplinary DevOps teams, which gather together application architects, developers, security architects, business managers, service operators and system administrators, to manage security and privacy risks in all the phases of the multiCloud application life-cycle. The complete workflow proposed by MUSA thus involves development activities and operation activities of the multiCloud application as shown in Fig. 2. While the last three activities are operation activities, the first three activities are development activities that can be considered security- and privacy-by-design practices which prepare the application to be compliant with security and privacy requirements and regulations. Fig. 2Open in figure viewerPowerPoint MUSA DevOps workflow for SLA-based security assurance in multiCloud The MUSA approach is supported by the MUSA framework (available in [3]) that seamlessly integrates different tools to support each of the workflow steps. The framework is an open source tool suit offering an integrated Kanban style dashboard to manage the status and progress of all the application components along the application engineering process. The whole MUSA workflow is made of six main steps (briefly described in the following). Next sections will detail the SLA related activities. Step 1 – Modelling: The start of the engineering process is the creation of the application model which specifies both the component level architecture of the application and its Cloud deployment requirements. The model is created in MUSA extended CAMEL language as explained in [24]. The model is a Cloud provider independent model (CPIM) where Cloud requirements of the components are defined without references to the actual Cloud services that will be selected for the deployment in the next step. The purpose of the model is therefore to define which are the application components, which are their communication relationships, which type and location of Cloud services they need, which are their Cloud resources needs (e.g. size of VM memory, CPU etc.) and which are the enforcement agents that will optionally operate with them to implement a required security or privacy control (see Section 6). Step 2 – Risk-driven Cloud services selection: In this step, the actual Cloud services to use by the application components will be selected so as they match both the requirements stated in the application model expressed as required Cloud resources and the application risk profile. The risk profile is the result of the risk assessment process carried out by analysing the threats against the application components and selecting the desired treatments or controls. This process is supported in MUSA framework by the MUSA Decision Support Tool (DST) and detailed in Section 4 below. Step 3 – Creation of Composed SLA: This step consists of the generation of the (multi)Cloud application SLA that can be offered to its clients. The tool in the MUSA framework which supports this functionality is the SLA generator. The SLA granted will be computed as the composition of the SLAs of the application components and the SLAs of the Cloud services used after an SLA validation process to learn the actual controls that can be effectively supported. The composition methodology is summarised in Section 5. Step 4 – Deployment: Once the Cloud services to use are selected and the Composed SLA is obtained, the components of the application will be automatically deployed and the Cloud resources initialised and configured as needed. The monitoring and enforcement agents to be used together with the components are also deployed and configured in this step. They will be the responsible for controlling at operation that the application behaves as promised in the SLA. This step is supported in MUSA framework by the MUSA deployer, an open source multiCloud broker and deployer that supports OpenStack, Eucalyptus and Amazon AWS. Step 5 – Monitoring of Composed SLA: The main objective of compliance and security assurance is to make sure that the Composed SLA holds during application provisioning. This is ensured in MUSA by continuously monitoring the security and privacy levels through metrics defined in the Composed SLA. The monitoring functionality in the MUSA framework is supported by the MUSA Security Assurance Platform that will be described in Section 6. Step 6 – Enforcement of Composed SLA: In case actual or potential violations of the promised SLOs are detected, it is necessary to try to enforce the SLOs and take prompt remediation actions to avoid the violation or to recover the security and privacy behaviour as soon as possible. The cause of the violation of the Composed SLA may reside in a failing application component (including enforcement agents used) or a failing Cloud service (i.e. the CSP is not fulfilling its Cloud SLA). Depending on the failing SLO, reaction actions may be procedural activities carried out by the DevOps team (e.g. the redesign of the application to update the architecture and include enforcement agents like the MUSA AC agent) or automatic enforcement mechanisms supported by the multiCloud application itself (e.g. the activation of a data encrypting component) a or by external systems (e.g. the activation of a vulnerability scanner). The enforcement agent management in MUSA framework is part of the MUSA Security Assurance Platform too, as explained in Section 6. The agile and DevOps paradigms are achieved by two main iteration loops in the workflow. First, at design time the initial CPIM model of the application (in modelling) and/or its risk profile (in risk-driven Cloud services selection) are revisited by the DevOps team until the Composed SLA satisfies all the requirements expressed in both, i.e. until the application architecture and Cloud deployment plan enable to grant a feasible Composed SLA that includes only those controls and levels that can be effectively granted after the selection of the Cloud services to use. Second, at operation time, in case a CSP is identified as the cause of the Composed SLA violation, in order to solve the situation and replace the Cloud service, a redeployment action is tried which would include a new risk assessment iteration. Following we detail the SLA-related MUSA activities in order to show the crucial role of SLAs for compliance and security assurance in multiCloud-based systems. 4 Risk-driven selection of Cloud services for multiCloud In the context of (multi)Cloud applications, the challenges associated with privacy-by-design and security-by-design principles increase, due to the possible lack of control over the involved assets in those cases where assets are under the control of external CSP or when assets are elastic, for example, a cluster composed of a varying number of virtual machines. Both scenarios make it difficult to evaluate the level of risks associated and they illustrate the main difference existing between Cloud Security and Security in System Engineering. Security in system engineering assumes that the system under design is completely under control of the designer and it is possible to identify assets and configure them according to the privacy and security requirements at every level of the system architecture. In Cloud-based applications, the assets are frequently under CSPs' control, continuously vary in time and it is less possible for Cloud application designers to impose constraints over their implementation, the attack surface is blurred and new techniques are needed to satisfy privacy and security requirements [25]. With the aim to address (multi)Cloud risk challenges, we adopt the SLA-based approach where we rely on the existence of a Security SLA (and PLA) associated to each application component that is not under control of the designer and is offered as a service (i.e. is a Cloud service consumed by the application). Such Security SLA would express the security levels granted by the Cloud service expressed as SLOs measurable by security metrics. Similarly, Cloud PLA would reflect its privacy SLOs and metrics. In the following, we detail how the selection of the Cloud services is made based on the analysis of the threats associated with application components and how the Cloud services' SLAs may tackle them. 4.1 Continuous risk assessment The risk assessment process in MUSA is considered the key driver to Cloud services selection decision support. Depending on whether the multiCloud application processes PII, risks may involve not only security concerns but also risks to data privacy. MUSA promotes that risk evaluation is a continuous task where multiple perspectives of organisation roles should take part. Whenever the application architecture changes or whenever the security and/or privacy status at runtime is in alert the DevOps team should perform a new risk assessment iteration, which involves the following sub-steps: 4.1.1 Identification of threats against components In order to assess the risks in the different components of the application, in MUSA we use a risk model based on the OWASP threat risk modelling [26]. The DevOps team chooses the threats that the component under consideration is susceptible to. These threats may be chosen from a threat catalogue such as that included in the MUSA Security Metrics Catalogue [15], which describes potential threats to different service types taken from expert sources such as the OWASP TOP 10 threats catalogue. The security threats selected are classified in the STRIDE [27] categories (Spoofing identity, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege). The DevOps team is required to provide the likelihood and impact of each threat and the composite risk index (CRI) of each threat is evaluated as (1)Both Likelihood and Impact are computed on a scale of 1–9 whilst the product is qua