SPECS
Secure Provisioning of Cloud
Services based on SLA
SPECS Project
CeRICT, Italy (coordinator)
TUD, Germany
IeAT, Romania
CSA, United Kingdom
XLAB, Slovenia
EISI, Ireland
FP7-ICT-10-610795
Project Start: 1/11/2013 Project Type: STREP Duration: 30M
Total Funding: 3.5 M EU Contribution: 2.4 M
SPECS - The Problem
End User Cloud Provider Your Resources Your dataImagine
: You are a corporate security manager, You
want to migrate some applications to the Cloud.
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?SPECS - The Problem
End User Cloud Provider Your Resources Your data Denial of Services PrivacyWHO GRANTS YOU?
SPECS - The Problem
End User Cloud Provider Your Resources Your data Denial of Services Privacy Cloud Provider SPECS SLA SLASPECS Core Idea
P
roblem 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
SPECS Platform - WHO
GENERAL MODEL
Actors:
Customers Developer Service ProviderSystems:
Cloud Application Cloud Platform Cloud ProvidersSPECS 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
SPECS Platform - WHO
Interaction Model 2
Hosting CSP
Has
its
own
resources
Add Security to its
Services for End
Users
SPECS Platform - WHO
Interaction Model 3
End User Platform
Buy resources from
Cloud
End User improve
Security
on
the
target services
SPECS Platform - HOW
The Stack
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
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.
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
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.
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.
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.
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.
SPECS Platform – HOW - Monitoring
Example Scenario: SLA Run Time Status (I)
Problem:
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.
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.
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
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
