Public deliverables

D1.1.1: Architecture Design – Preliminary Design

This deliverable is the first release of a series of three incremental deliverables (D1.1.1, D1.1.2 and D1.1.3) aimed at describing the SPECS platform architectural solution. In particular, this document outlines the global SPECS architecture, by introducing the main concepts and services, by providing a layered view to the main architectural components, and by describing preliminary details for SPECS future implementation.

Read More >

D1.1.2: Architecture Design – Intermediate Design

This deliverable is the second release of a series of three incremental deliverables (D1.1.1, D1.1.2 and D1.1.3) aimed at describing the activities of task T1.1 on the design of the SPECS platform architectural solution. In the preliminary phase we outlined the global SPECS architecture, by introducing the main concepts and services, by providing a layered view of the architecture, and by describing preliminary details for SPECS future implementation. Furthermore, we proposed some simple conceptual models whose purpose was to set a shared terminology to describe the main concepts related to the (SPECS) SLA-based approach.

Read More >

D1.1.3: Architecture Design – Finalized Design

This deliverable illustrates the final architecture of the SPECS platform, resulting from the design activities conducted in several tasks since the start of the project. The objective of the SPECS project is to design and develop an innovative Security Platform-as-a-Service (i.e. the SPECS platform) devoted to delivering cloud services characterized by specific security features, negotiated with End-users and guaranteed through SLAs. The SPECS platform is built on top of the SPECS framework, which provides all the software tools and components needed to develop applications that offer secure services based on SLAs.

Read More >

D1.2: Platform Requirements

As described in the proposal, the goal of the SPECS Project is to design a framework to provide security guarantees to cloud customers, by offering specific services to manage security parameters that can be negotiated, enforced and continuously monitored.
This objective will be implemented by exploiting two different innovative approaches: (i) security parameters will be negotiated, dynamically enforced and monitored with dedicated services to manage Service Level Agreements (SLAs) during their whole lifecycle, (ii) security will be provided as-a-Service to augment the security of existing public and private providers.
In particular, SPECS provides security services that act as an intermediary in the provisioning of cloud services, they play an active part in the provisioning of guaranteed services and different usage perspectives must be taken into consideration while designing the framework.

Read More >

D1.4.1: Module shared API and Core Services

This deliverable presents the final design of the SPECS SLA Platform module and the set of shared APIs that let all Core services cooperate for the management of the SLA life cycle. Indeed, during the second year, almost all the SPECS modules’ design evolved thanks to a refinement process compliant with the methodology that is used to gather requirements from the End-Users.

Read More >

D1.4.2: Module shared API and Core Services

This deliverable provides the supporting documentation for the prototypes demonstrating the SLA Platform module and two of the components of the Vertical layer, namely the Auditing component and the User Manager component, whose final design is presented in D1.4.1.
The SLA Platform is in charge of managing every aspect of the SLA life cycle and has to guarantee interoperability among all Core modules, namely Enforcement, Negotiation and Monitoring. In particular, it exposes a high-level and service-oriented API to manage the SLA life cycle.

Read More >

D2.1.1: Report on requirements for Cloud SLA negotiation – Initial

Despite the appealed advantages and user-friendliness offered by the cloud nowadays, it is true that the typical cloud customer is not a security expert (in particular small and medium enterprises -SMEs-), nevertheless will have some context-specific security requirements to fulfill. For such (prospective) customers, matching their security requirements with the security being offered by available Cloud Service Providers (CSP) is a task that is still manual, expensive and unrealistic to accomplish in many cases. This problem worsens if we take into account the ever increasing number of CSPs available in the cloud ecosystem. Despite the assumption that a given CSP “seems” secure, is it actually providing “good enough security” for my organization’s
requirements? How to compare different CSPs with regards to security? How can SMEs add realistic levels of automation to the process of negotiating security requirements with their customers?

Read More >

D2.1.2: Report on requirements for Cloud SLA negotiation – Final

In cloud security the “one size fits all” principle does not always apply: different customers have different security requirements, therefore rigid/static cloud security Service Level Agreements (SLA’s) will usually under-/over-provision the customers’ security needs. This fact becomes more critical if we take into account the increasing number of Cloud Service
Providers (CSPs), and the trade-offs associated with security (in particular performance and price). Because, how to provide customers with the cloud security level that is “good enough” for their requirements?
SPECS proposes a user-centric framework to negotiate security SLA’s between customers and CSPs, with the purpose of finding a set of measurable security Service Level Objectives (SLO’s) that fulfills the customer’s requirements. SPECS’ Negotiation framework consists of security SLA evaluation techniques, protocols and architectures to deploy it on top of the SPECS Platform being created by WP1.

Read More >

D2.2.1: Report on conceptual framework for Cloud SLA negotiation – Initial

The paucity of comprehensive approaches to specify, assess and quantitatively reason about security in cloud systems is a major impediment that users encounter when they decide to migrate their key applications to the cloud. On one hand, the CSPs are trying to convince End users to trust in the security of their provided services. On the other hand, users should themselves be able to assess and validate the security claims from the CSPs and then select the best provider that suits their security requirements. SPECS addresses this topic by providing a comprehensive framework to support the negotiation of the minimum level of security requested by an End-user when using cloud services. The level of security agreed between a user and a cloud service provider is formally defined within a Security Level Agreement (SLA). SPECS also guarantees the fulfillment of the SLA by providing monitoring and enforcement capabilities.

Read More >

D2.2.2: Report on conceptual framework for Cloud SLA negotiation – Final

This deliverable is the second of two deliverables (D2.2.1, D2.2.2) that presents the negotiation
module and the final description of the contributed techniques to reason about cloud
SLAs.

Read More >

D3.1: Available services for monitoring

We present in what follows an analysis of the state-of-the-art services for monitoring in clouds and their appropriateness for SPECS. The aim is to identify how SPECS can improve that state-of-the-art in what concerns the SLA-based cloud security monitoring and to identify the potential concepts, methods and tools that can re-used in the context of SPECS developments.

Read More >

D4.1.1: SLA enforcement mechanisms requirements – Preliminary

The activities reported in this deliverable are related to Task T4.1, and are focused on the definition of the requirements for the SLA enforcement module of the SPECS framework. The deliverable will be released in two subsequent versions: in this document, D4.1.1, we aim at identifying the baseline functionalities which the Enforcement module must offer in order to enable the implementation of an SLA, once it has been negotiated and signed, and the management of possible alerts/violations detected during the monitoring phase to apply possible remedies.

Read More >

D4.1.2: SLA enforcement mechanisms requirements – Finalised

This deliverable is released in two subsequent versions: in the preliminary version (deliverable D4.1.1), we identified the basic functionalities that the Enforcement module must offer in order to enable the implementation of a signed SLA, and the management of possible alerts/violations detected during the monitoring phase. In this deliverable, we refined and enriched the analysis of different validation scenarios and user stories from the SLA Enforcement perspective, in order to elicit a set of requirements related to the management of two main SAL phases, namely SLA implementation and SLA remediation.

Read More >

D4.2.1: Design of the enforcement SLA components – Preliminary

This deliverable is the first of two deliverables (D4.2.1, D4.2.2) that present the design of SPECS enforcement module. While this document presents the preliminary design, D4.2.2 will deliver the final design of Enforcement component.

Read More >

D4.2.2: Design of the enforcement SLA components – Finalised

This deliverable is the second of two deliverables (D4.2.1, D4.2.2) that present the design of the SPECS Enforcement module. While D4.2.1 introduced a preliminary design of the module at month 6, this document presents the refined architecture of the SPECS Enforcement.

Read More >

D4.3.1: Implementation of the enforcement SLA components – Preliminary

This deliverable is the first of the three deliverables (D4.3.1, D4.3.2, and D4.3.3) that demonstrate the Enforcement module implementation. The three prototypes presented in this document follow the architecture designed in T4.2 and reported in D4.2.2. They demonstrate the core Enforcement components, namely Planning, Implementation, Diagnosis, and Remediation Decision System.

Read More >

D4.3.2: Implementation of the enforcement SLA components -Intermediate

This document presents the intermediary implementation of the Enforcement module. The demonstrated prototypes follow the implementation plan introduced in D4.3.1, and are based on requirements and design presented in D4.1.2 and D4.2.2, respectively, user stories and validation scenarios defined in T5.1, and even some new requirements from stakeholders.

Read More >

D4.4.1: The Credential Service Components -Preliminary

This document presents the intermediary implementation of the Enforcement module. The demonstrated prototypes follow the implementation plan introduced in D4.3.1, and are based on requirements and design presented in D4.1.2 and D4.2.2, respectively, user stories and validation scenarios defined in T5.1, and even some new requirements from stakeholders.

Read More >

D4.5.1: Testing and validation – Preliminary

In the context of the SPECS project, one of the problems addressed by the WP4 is the definition of a coherent validation methodology aiming to demonstrate the correctness of the Enforcement module. Moreover, such activity should guarantee that the entire Enforcement module is enough secure to be adopted in SPECS.

Read More >

D4.5.2: Testing and validation – Intermediary

Validation encompasses a variety of activities along the software development life cycle with the common objective of ensuring that the developed product is secure, of good quality, and that it complies with all requirements. This deliverable presents the final validation methodology to be used for both, the Enforcement module and the other elements of the entire framework.

Read More >

D5.1.1: Description of the validation scenario scenarios and identification of common elements

This deliverable is the first release of a series of three deliverables, aimed at describing and prototyping the usage patterns and example applications (Task T5.1). This first document describes the validation methodology that will be implemented by the validation scenarios. In order to avoid the definition of non-useful validation scenarios and to measure the coverage of the defined ones, some key features are defined as sensitive aspects of the SPECS framework. Furthermore, four user stories are defined to provide general containers of the validation scenarios. The coverage of the defined scenarios has been measured according to some Key Concerns: SLA lifecycle, SPECS users, invocation chains, and target services. Another important Key Concern is the set of the requirements of the SPECS platform as well as the three modules (Enforcement, Negotiation and Monitoring).

Read More >

D5.1.2: Description of the validation scenarios and identification of common elements

This document deals with the methodological, planning and coverage aspects related to the user-oriented system level testing of the SPECS software, products and artifacts.

Read More >

D5.1.3: Description of the validation scenarios and identification of common elements

This deliverable reports the status of development activities of the web container and metric catalogue application. These applications are in charge of demonstrating the feasibility of the SPECS approach; they also have the purpose of testing the entire SPECS platform and modules implementing the Validation Scenarios according to the methodology expressed in D5.1.2.

Read More >