SPECS Secure Provisioning of Cloud Services based on SLA Management

Transcription

1 SPECS Secure Provisioning of Cloud Services based on SLA Management

2 SPECS Project CeRICT, Italy (coordinator) TUD, Germany IeAT, Romania CSA, United Kingdom FP7-ICT Project Start: 1/11/2013 Project Type: STREP Duration: 30M Total Funding: 3.5 M EU Contribution: 2.4 M XLAB, Slovenia EISI, Ireland

3 SPECS - The Problem Imagine : You are a corporate security manager, You want to migrate some applications to the Cloud. Your Resources Cloud Provider End User Your data

4 SPECS The Problem Data resides on a remote Cloud Service Provider (CSP). Data is security sensitive: Assurance that the CSP's personnel will not have access to your data guarantee that only authorized people can access your data assess a CSP's ability to meet the security requirements, and select a CSP on this basis. What are the security trades-offs offered by different CSPs? - How does one continuously monitor, and enforce the agreed Cloud security levels with the CSP?

5 SPECS - The Problem Denial of Services Your Resources Cloud Provider End User WHO GRANTS YOU? Your data Privacy Cloud Provider

6 SPECS - The Problem Your Resources Denial of Services SLA Cloud Provider End User SPECS SLA Privacy Cloud Provider Your data

7 SPECS Core Idea Problem Statement: End-User Cloud Security (How to compare CSP?, What they grant? How to improve their security features if they do not grant enough? ) Approach: Security-as-a-Service (SECaaS), a Platform which offers security services. Service Level Agreement (SLA) for Security. End-User and CSP features described through SLAs. The SECaaS granted through the SLA life cycle

8 SPECS Platform - WHO GENERAL MODEL Actors: Customers Developer Service Provider Systems: Cloud Application Cloud Platform Cloud Providers

9 SPECS Platform - WHO Interaction Model 1 Hosted Platform Buy resources from Cloud Offer (Security) Services to End Users Buy/Broker resources from Cloud for end user

10 SPECS Platform - WHO Interaction Model 2 Hosting CSP Has its own resources Add Security to its Services for End Users

11 SPECS Platform - WHO Interaction Model 3 End User Platform Buy resources from Cloud End User improve Security on the target services

12 SPECS Platform - HOW The Stack

13 SPECS Platform HOW SLA Management SLA among Users, SPECS and Providers Negotiation Finding the Agreement Monitoring Veryfing the respect of Agreement Enforcement Take Action to grant the Agreement

14 SPECS Platform - HOW SLA Negotiation Conditions: SLA is not fully defined, customer(s) and provider(s) conduct a negotiation process on requirements/services to find agreement Goals Service Provider's view: evaluate the services requested, matching to what can be granted. evaluate the risks related to incorrect evaluation, The customer' s view: evaluate the trade-off across service specifications and the corresponding costs.

15 SPECS Platform HOW - Negotiation Example Scenario: Storing Confidential Data Problem: A User wants to store data on remote Cloud providers, and with data confidentiality requirements. State of the Art: The User chooses a Cloud provider with storage features. Manually checks their SLA, verify the kind of security features offered. Studies different offerings, and chooses. Limitations: Manual evaluation of security. SPECS solution: Single access point: User accesses SPECS services and utilized it to negotiate security requirements. SPECS helps specify needed requirements on a provider even if it does not support it natively

16 SPECS Platform HOW - Negotiation Example Scenario: Security-Oriented Cloud Federation (I) Problem: A User consumes the IaaS resources from a Cloud Federation The User has security requirements that must be fulfilled and observed during the whole usage period. The User may be a Customer or a Cloud Provider. Limitations: No systematic solution for managing the life-cycle of User s security requiremets in a Cloud Federation. Quality of Security (QoSec), refers to the (possibly quantitative) evaluation of security granted by a CSP. No standardized means to specify security requested/provided between Users and CSPs respectively. Manually search for appropriate Cloud offering, particularly in the field of security and privacy possibilities (attributes). SPECS solution: Cloud security can be specified in the form of SLAs. SPECS Security-as-a-Service broker can be deployed between End Users and Cloud Federations to automatically manage the whole SLA life-cycle. SPECS Security-as-a-Service can be used to deploy additional security components when needed by the deployed services SPECS Security-as-a-Service broker can be deployed between End Users and various Clouds or even Cloud Federations to automatically manage the whole SLA life-cycle.

17 SPECS Platform HOW - Negotiation Example Scenario: Security-Oriented Cloud Federation (II) SPECS solution: Cloud security can be specified in the form of SLAs. SPECS Security-as-a-Service broker can be deployed between End Users and Cloud Federations to automatically manage the whole SLA life-cycle. SPECS Security-as-a-Service can be used to deploy additional security components when needed by the deployed services SPECS Security-as-a-Service broker can be deployed between End Users and various Clouds or even Cloud Federations to automatically manage the whole SLA life-cycle.

18 SPECS Platform - HOW SLA Monitoring Conditions: A set of signed SLAs Goals SLA is checked for its actual degree of conformance or for penalties if in violation. Service Provider s view: verifying that the SLA are respected (eventually access infrastructure inaccessible to customers) generating alerts before SLAs are broken, in order to activate remedial actions. Customer's view: Having grants bout the effctive respect of agreed SLAs.

19 SPECS Platform HOW - Monitoring Example Scenario: SLA Run Time Status Problem: A User wants real-time status on SLA accomplishment. State of the Art: The User needs to accept the supplier monitoring or supplier metrics. The User must create local measurements, for example time to resolve an issue, or down time of the service. Limitations: User intervention needed. SPECS solution: SPECS provides a full set of features of monitoring SLA accomplishment. SPECS provides a simple access point to monitoring system. Users know in near real-time what is the status of the SLA.

20 Problem: SPECS Platform HOW - Monitoring Example Scenario: SLA Run Time Status (I) A Customer consumes Cloud services by different CSPs. The Customer needs the tools to systematically reason about Cloud SLAs, including side-by-side CSP comparison, negotiation and continuous monitoring. Limitations: Lack of the automated tools to aid prospective Cloud customers taking decisions about the stored CSP information (e.g., comparing different providers, evaluating trade-offs, etc.). For current Cloud customers, there are not tools allowing them to monitor in real-time the fulfillment of the contracted Cloud SLA. Lack of customization, as the users are only able to assess compliance with respect to the full SLA used by the repository (i.e., not with subsets of these SLA). SPECS solution: With SPECS it is possible to provide prospective/existing Cloud customers with a real-time Dashboard to enable basic features (e.g., comparing two or more CSP side-by-side) and, also more advanced SLA operations (e.g., real time monitoring of specific SLA clauses). This Dashboard can be integrated to existing repositories such as STAR, to provide a full-solution for Cloud users.

21 SPECS Platform HOW - Monitoring Example Scenario: SLA Run Time Status (II) SPECS solution: With SPECS it is possible to provide prospective/existing Cloud customers with a real-time Dashboard to enable basic features (e.g., comparing two or more CSP side-by-side) and, also more advanced SLA operations (e.g., real time monitoring of specific SLA clauses). This Dashboard can be integrated to existing repositories such as STAR, to provide a full-solution for Cloud users.

22 SPECS Platform - HOW SLA Enforcement Conditions: A set of signed SLAs Goals the actions needed to respect the SLAs are effectively taken Service Provider s view: At service startup/dynamicly (reconfiguration) Activation of software modules, acquisition of resources, Policy definition and management Improving/selecting security features of Cloud Providers Customer's view: the application of the service requirements explicitly requested into the SLA

23 SPECS Platform - HOW SLA Enforcement Conditions: A set of signed SLAs Goals the actions needed to respect the SLAs are effectively taken Service Provider s view: At service startup/dynamicly (reconfiguration) Activation of software modules, acquisition of resources, Policy definition and management Improving/selecting security features of Cloud Providers Customer's view: the application of the service requirements explicitly requested into the SLA

24 Milestones MS Milestone name Date Means of verification 1 Preliminary Framework Definition 2 Framework Design and Proof-of-Concept M6 D1.1.1,D1.2,D2.1,D3.1,D4.1, D4.2, D6.1, D7.1 M12 D1.1.2, D2.1.2, D2.2, D3.2, D4.1.2, D4.4.2, D4.3.1, D4.4.1, D4.5.1, D , D , D6.2.1, D Framework Prototype M18 D1.3, D1.6, D2.3.1, D3.3, D3.4.1, D , D Framework Operative M24 D1.1.3, D1.4, D2.2, D4.2, Prototype D4.3, D4.5.2, D6.2.2, D7.2.2, 5 Framework Operative M30 D1.5, D1.6.2, D2.3.2, D.3.4.2, D.4.3.3, D.4.5.3, D5.2, D5.3., D5.4, D6.2.3, D7.2.3, D7.3

25 Objective 1: Design an innovative Security Platform-as-a-Service Offer a solution for the SPECS Security-as-a- Service approach, proposing a clear design for a Platform-as-a-Service dedicated to security services and to SLA life cycle management. SO1.1 Design a Security SLA-Oriented Platformas-a-Service SO1.2 Design services dedicated to security SLA Management SO1.3 Design of the interaction protocols among different SLA modules

26 Objective 2: Allow user-centric negotiation of Cloud SLA Propose solution for helping End Users to negotiate Cloud SLA effectively with a set of CSP, by understanding the resulting trade-offs. SO2.1 Design of user-centric Cloud SLA negotiation solution for security parameters SO2.2 Develop the techniques to systematically evaluate the trade-offs related with offered security in Cloud SLA SO2.3 Provide a reference implementation of security negotiation services for Cloud SLA

27 Objective 3: Innovative Solutions for Continuous Security Monitoring Design and implement SLA monitoring solutions dedicated to continuously control the security offered by CSP and to help ensuring the granted QoSec. SO3.1 Identify the requirements for continuously monitoring the fulfillment of SLA in what concerns to the SPECS measures of interest. SO3.2 Evaluate the appropriateness of the stateof-the-art services for SPECS monitoring. SO3.4 Propose innovative monitoring services

28 Objective 4: Develop Innovative Security Services to Enforce SLA Offer a clear design and an implementation of services dedicated to grant security features to Cloud end users in order to fulfill an agreed SLA and, keep a sustained QoSec.. SO4.1 Services to check the effective availability of security features, supprt Negotiation, grant SLAs. SO4.2 Services able to monitor and react in order to respect an agreed Cloud SLA. SO4.3 Provide a sustained QoSec during the life cycle of the application/service, as agreed on the Cloud SLA- SO4.4 Offer additional security services to end users in order to sustain a minimum required QoSec.

29 Objective 5: Real-world validation of SPECS outcomes Implement two relevant use cases to empirically validate the outcomes of the project. SO5.1 Definition of SPECS Platform Use Cases through a set of real applications SO5.2 Design and implement real applications using the SPECS platform.