report on conceptual framework for cloud sla negotiation ... · secure provisioning of cloud...

SecureProvisioningofCloudServicesbasedonSLAManagement

SPECSProject–Deliverable2.2.2

1

Secure Provisioning of Cloud Services based on SLA Management

SPECS Project - Deliverable 2.2.2

Report on conceptual framework for Cloud SLA negotiation - Final

Version no. 1.0 31 October 2015

The activities reported in this deliverable are partially supported by the European Community’s Seventh Framework Programme under grant agreement no. 610795.



2

Deliverable information Deliverable no.: D 2.2.2 Deliverable title: Report on conceptual framework for Cloud SLA negotiation - Final Deliverable nature: Report Dissemination level: Public Contractual delivery: 31 October 2015 Actual delivery date: 31 October 2015 Author(s): Rubén Trapero (TUDA), Ahmed Taha (TUDA) Contributors: Valentina Casola (CeRICT), Massimiliano Rak (CeRICT),

Alessandra De Benedictis (CeRICT), Marina Bregu (CSA) Reviewers: Jolanda Modic (XLAB), Madalina Erascu (IeAT), Alain Pannetrat

(CSA) Task contributing to the deliverable:

T2.2

Total number of pages: 70



3

Executive summary Thisdeliverableisthesecondoftwodeliverables(D2.2.1,D2.2.2)thatpresentsthenegotiationmoduleandthefinaldescriptionof thecontributedtechniquestoreasonaboutcloudSLAs.AtmonthM12thedocumentD2.2.1presented:

• AconceptualmodeltorepresentSLAs• AhighlevelarchitecturetonegotiateSLAs• Negotiationandrenegotiationprocesses• Algorithms(REMandQHP)toreasonaboutcloudSLAs.

Thefinalversionofthedocument(D2.2.2)presents:

• AnupdatedconceptualmodeltorepresentSLAscompliantwiththelatestoutcomesofstandardsandworkinggroups.

• AmetriccataloguecompliantwiththeconceptualmodelandenrichedwiththefeedbackreceivedfromthePlatform(WP1),theEnforcementmodule(WP4),andthevalidationscenarios(WP5).

• A refined architecture: the main negotiation components are the same as the onescreatedinY1.However,theinteractionwithexternalmoduleshasbeenrefinedandalsotheinformationexchangedamongthem.

• Arefinednegotiationprocess:thankstothefeedbackreceivedfromtheEnforcementmodule and from the T2.3 we have redefined most of the negotiation process. Therefinedprocess is compliantwith theSPECSapplicationmethodology that isused togatherrequirementsfromtheEnd-users(EUs).ThenewnegotiationprocessalsotakesintoaccounttheconsolidatedapproachtocreatesupplychainsthatisorchestratedbytheEnforcementmodule.

• A refined renegotiation process: the renegotiation processes has been completelyredefined comparingwith the simplified process created inM12. To do sowe havereceivedacontinuousfeedbackfromthedevelopersoftheEnforcementmodulewhichoverseestheremediationprocessesthattriggerstherenegotiation.

• Newaspectsrelatedtothesecurityassessmentmethodologies.InY1wepresentedtwomethodologiestoevaluatecloudserviceproviderswithrespecttoEUs’requirements:REMandQHP.InD2.2.2weprovidedetailsabouthowREMhasbeenusedtoevaluatetheSLAModelofSPECS.Wealsoprovideanevolutionof theQHPmethodology thatconsidersuncertaintyonqualitativeEUs’requirementsbyusingquantificationoffuzzynumbers.



4

Table of contents Deliverable information.................................................................................................................................................2Executivesummary......................................................................................................................................................3Tableofcontents............................................................................................................................................................4Indexoffigures...............................................................................................................................................................5Indexoftables.................................................................................................................................................................61. Introduction...........................................................................................................................................................72. Relationshipwithotherdeliverables..........................................................................................................83. Overviewofrequirements...............................................................................................................................93.1 SLAconceptualmodelrequirements................................................................................................93.2 Architecturerequirements..................................................................................................................113.3 Negotiationprocessrequirements...................................................................................................133.4 Renegotiationprocessrequirements..............................................................................................153.5 SecurityReasoningrequirements.....................................................................................................16

4. SecurityLevelAgreementspecification...................................................................................................214.1 SLAconceptualmodel............................................................................................................................214.2 SLAmachinereadablerepresentation............................................................................................234.3 SPECSmetricscatalogue.......................................................................................................................25

5. Architectureoverview.....................................................................................................................................316. SLAnegotiationprocess..................................................................................................................................327. SLArenegotiationprocesses.........................................................................................................................367.1 CSPtriggeredrenegotiation................................................................................................................367.2 EUtriggeredrenegotiation..................................................................................................................39

8. SecurityReasoners............................................................................................................................................418.1 UseofREMfortheevaluationoftheSPECSSLAModel..........................................................428.1.1 REMEvaluationofCAIQsEvaluation..........................................................................................428.1.2 EvaluatingSLAofferswiththeREM...........................................................................................44

8.2 FuzzylogicbasedsecurityassessmentofSLAs..........................................................................489. Conclusions...........................................................................................................................................................5610. Bibliography....................................................................................................................................................58AppendixI.ExampleofaspecificSLA:CyptoBruteForceResistance...............................................59AppendixII.FoundationsofFuzzyLogic:thefuzzyinferencesystem............................................62AppendixIII.PrinciplesforhandlingfuzzyAnalyticHierarchyProcesses....................................63AppendixIV.Fuzzy-QHP:acasestudy..........................................................................................................65



5

Index of figures Figure1.Relationshipwithotherdeliverables................................................................................................8Figure2.SPECSsecuritySLAconceptualmodeproposedindeliverable2.2.1................................21Figure3.RefinedSPECSsecuritySLAconceptualmodel...........................................................................22Figure4.SLAmachine-readableformatmodel..............................................................................................24Figure5.Highlevelnegotiationarchitecture..................................................................................................31Figure6.Simplifiednegotiationprocess...........................................................................................................32Figure7.Highlevelsequencediagramforthenegotiationprocess......................................................34Figure8Simplifiedrenegotiationprocess(CSPtriggered).......................................................................36Figure9.RenegotiationprocesstriggeredbyCSPs......................................................................................38Figure10.Simplifiedrenegotiationprocess(EUtriggered).....................................................................39Figure11.RenegotiationprocesstriggeredbyanEU.................................................................................40Figure12.SimplifiedEvaluationWorkflow.....................................................................................................41Figure13.REMEvaluationstepsappliedontheCAIQ................................................................................43Figure14.TheCAIQtree..........................................................................................................................................43Figure15.FromSLAOfferstoSLAHierarchy.................................................................................................45Figure16.ExtracttheCAIQfromtheSLAOffer.............................................................................................46Figure17.CapabilityextractionfromanSLAoffer.......................................................................................47Figure18.GenerationoftheSPECSCAIQ..........................................................................................................48Figure19.FuzzyQHP:Methodologystages.....................................................................................................49Figure20.CloudSLAhierarchyusingfuzzybasedQHP.............................................................................50Figure21.Triangularfuzzynumber....................................................................................................................51Figure22. Linguistic terms for criterion importance........................................................................................53Figure23.ExampleofacompleteSPECSSLAhierarchyforanSLO.....................................................59Figure24.Fuzzyinferencesystem.......................................................................................................................62Figure25.TheintersectionbetweenM1andM2............................................................................................64Figure26.AggregationattheSLOlevelregardingthecustomer’sCaseIrequirements.............69Figure 27. SLA’s comparison with respect to customer Case I requirements at the Controlcategorylevel.................................................................................................................................................................69Figure28.Thetotalaggregatedsecuritylevelwithrespecttocustomerrequirements.............69



6

Index of tables Table1.RequirementrelatedwiththedefinitionoftheformatoftheSLA.......................................11Table2.RequirementsrelatedtothearchitectureofNegotiation........................................................13Table3.RequirementsrelatedwiththeNegotiationProtocol................................................................15Table4.RequirementsrelatedtotheRenegotiationprocess..................................................................16Table5.Requirementsrelatedtotheevaluationofsecurity....................................................................20Table6.MetricsimplementedbySPECSservicesthatareenforceableandmonitorable...........28Table7.MetricsdevelopedinWP5......................................................................................................................30Table8.DefinitionoftermsusedinthefuzzyQHP......................................................................................51Table9.Linguisticvariablesdescribingweightsofthecriteriaandvaluesofratings..................53Table10.SecuritySLOdefinitionofCryptoBruteForceResistance.......................................................60Table11.MetricsdefinitionforthesecuritySLOCryptoBruteForceResistance.............................60Table12.AbstractmetricdefinitionforthesecuritySLOCryptoBruteForceResistance.............61Table13.FuzzyQHPcasestudy:excerptofSLAsandcustomerrequirements...............................65



7

1. Introduction TheprocessofSLAnegotiationhasevolvedduringthesecondyearofSPECS.ThisdocumentdescribesthefinaloutcomesregardingtheNegotiationmoduledevelopedinSPECS.ThecurrentcontentofthedeliverableupdatestheinformationpresentedinD2.2.1byaddingupdatedinformation,changesinthedesign,andimprovementstothetechniquesandmethods introduced in the first year.The feedback received fromother tasks and from theimplementationactivitiescarriedoutduringthesecondyearhasalsohelpedtorefinethemainaspects of the negotiation and renegotiation process. To this end, the updated set ofrequirements inherited from WP1 and WP4 and especially from the deliverable D2.1.2(submittedatM12)isalsoconsideredintherefinementofthedesignsandprocessespresentedanddiscussedhereThecurrentdeliverableincludesthefinalformatusedtorepresentSLAs.Thearchitectureofthe Negotiation module is also presented, emphasizing the changes with respect to thearchitecture introduced in the first year. Changes to the SLA format and the design of theNegotiationmodulearemostlyduetotheimplementationactivitiesinT2.3andthefeedbackreceivedfromotherWPs(namelyWP1,WP4,andWP5).Securityreasoningtechniquesarealsovalidatedandimprovedinthisdeliverable.TheusageofsecurityassessmenttechniquesundertheSPECSframeworkispresented,aswellasanovelsecurity assessment technique that add the management of the uncertainty of end-users’requirements.Thedocumentisstructuredasfollows.Section2providesinformationabouttherelationshipbetweenthisdocumentandtherestofthedeliverables.Section3providesthesummaryofthenegotiationrequirements.Theorganizationofrequirementsisthebasisforthestructureoftherestofthesectionsinthedocument.Section4detailsthefinalversionoftheSLAspecification,includingtheconceptualmodeltodesignsecuritySLAs,andthelatestversionofthemachinereadableformatthatreliesonthedesignedconceptualmodel.AcompletemetriccatalogueisalsopresentedinSection4,whichcomprisesthecurrentsetofsecuritymetricsusedinSPECS.Section5providesanoverviewoftheNegotiationarchitecture.Thisisahighlevelpresentationof the Negotiation architecture that helps to better understand the negotiation andrenegotiation processes introduced in Sections 5 and 6, respectively. A detailed low leveldescriptionoftheNegotiationmoduleanditscorrespondingcomponentsisreportedinT2.3.Section8detailsthesecurityreasonersconsideredinSPECS.ThisincludesthedescriptionofhowoneofthemhasbeenintegratedintothenegotiationprocessesandanevolutionoftheotherthatusesfuzzyvariablestomanageEnd-users´requirementsuncertainty.Thedocumentconcludeswithashortsummary.



8

2. Relationship with other deliverables TheFigure1depictstherelationshipbetweenD2.2.2withrespectandtherestofdeliverablesofSPECS.

D2.2.2D2.2.1

D2.1.2

D1.3

D1.1.2

D2.3.1D1.5.1

D5.1.2

D4.3.2

D6.2.2

D2.3.2

D1.1.3

Figure 1. Relationship with other deliverables

Therearethreegroupsofdeliverables:theonesthatareinputforD2.2.2,deliverablesthatuseD2.2.2astheinput,andthentherearedeliverablesthatpresentboth,inputandoutput.Thefollowingisasummaryoftherelationships:

• DeliverablesusedasaninputforD2.2.2:o D1.1.2providesthegeneraloverviewoftheSPECSarchitecture.o D2.1.2 provides the final set of requirements compiled for the Negotiation

module.o D2.3.1providestheinitialfeedbackfromtheimplementationactivitiesrelatedto

theNegotiationmodule.• DeliverablesthatuseD2.2.2astheinput:

o D1.1.3 will provide the intermediate overview of the SPECS architecture,includingalsothelatestdesignoftheNegotiationmodule.

o D2.3.2will provide the second prototype of the Negotiationmodule andwilldependontheoutcomesoftheD2.2.2.

o D4.3.2willprovidetheseconditerationoftheEnforcementimplementationandwillincludetheoutcomesoftheD2.2.2,especiallyinwhatregardsthegenerationofsupplychainsandrenegotiationprocesses.

o D5.1.2providesvalidationscenariosthatarealsobasedonthenegotiationandrenegotiationprocessesreportedinD2.2.2.

o D6.2.2 will discuss the metrics catalogue reported in D2.2.2 as part of thestandardizationactivitiesinWP6.

• DeliverablesthatuseD2.2.2asinputandoutput:o D1.3providestheinterfacesamongallSPECSmodules.o D1.5providestheintegrationdetailsofSPECS.



9

3. Overview of requirements ThissectiondescribesallrequirementsthathavebeencoveredbySPECSPlatformandregardtheSPECSNegotiationmodule.Here is included theupdated listof requirements.All activerequirementswere selected from the onesbeing obsolete, supersededor rejected after theanalysisofimplementedSPECSapplications.Fewnewrequirementshaveemergedwhicharealsoincluded.Therestofthemareeitherthesame(aspresentedinD2.1.2)orupdated.Two main sources were considered in the process of eliciting requirements affecting thenegotiationprocesses:requirementselicitedindeliverableD1.2andinD2.1.2.However,othertasksbelongingtootherWPs(PlatformandEnforcement)werealsoconsidered.The requirements related to theNegotiationmodulewere filtered and selected. Theyweregrouped by common functionalities in order to provide an initial overview of the mainfunctional blocks required by the Negotiation module. With the result of this analysis thefollowinglistofactivitieshavebeenidentified:Activity1.SLAconceptualmodelrequirements:specificationofaconceptualmodelfordefiningSLAs.Activity2.Architecturerequirements:CreationoftheinitialarchitecturefortheNegotiationmodule.Activity 3.Negotiationprocess requirements: Creationof theprocess for thenegotiationofSLAs.Activity4.RenegotiationprocessrequirementsActivity5.Securityreasoningrequirements:CreationofaninitialapproachforevaluatingthesecurityofacloudservicewithrespecttotheCSC’ssecurityrequirements.The result of the elicitation of the requirements according to the aforementioned list ofactivitiesisasfollows:

3.1 SLAconceptualmodelrequirementsThisactivity includesthedefinitionofwhatasecuritySLA is, the informationthat itshouldcontain and the format chosen to represent the information. The following requirements(Table1)arecoveredbythespecificationoftheSLAdescribedinSection4: REQ_ID Requirement Description Comment SLANEG_R1 SLAlanguage

shouldsupportspecificationofrequiredcloudresources

SLA language should supportspecification of required IaaS,PaaS or SaaS resources andmapping between SLA termsandlow-levelCSPresources.

Hasremainedthesame

SLANEG_R2 SLAlanguageshouldsupportsimplecomposition

SLA language should supportthecombinationoftwoSLAsinorder tomodel a supply chainbuiltbetweenSPECSandaCSP.

Hasremainedthesame

SLANEG_R3 Thenegotiationprocessshouldsupportcompositecloudservices

In analogy to SLANEG_R2, alsothe SLA evaluation techniqueshould support the notion ofcomposition (cloud supplychainwithtwoormoreSLA’s).

Hasremainedthesame

SLANEG_R4 NegotiatedSLOsshouldbe

Thisisthebasicrequirementtobuild the (automated)

Hasbeenupdated



10

monitorableandenforceable

management of cloud SLAs inWP3andWP4.

SLANEG_R6 EvidenceassociatedwithmeasuredSLOs

Customers might need to beprovided with some sort ofevidence related with theimplementation of a specificSLO, in order to make aninformed decision whilenegotiating a cloud SLA inSPECS.Thisevidencemightcomeintheform of e.g., the associatedSecurity control’simplementationasdocumentedin the applicable securitycertification (e.g., CSA OCF orISO/IEC27002).

Hasremainedthesame

SLANEG_R8 Specificationofcustomer’ssecurityrequirements

Not all customers are securityexperts; therefore theirsecurityrequirements(inputofthenegotiationprocess)mightcome in different levels ofgranularity,basedontheSPECSsecurity SLA hierarchy (i.e.,from Control Categories toMetrics/Measurements).

Hasbeenupdated

SLANEG_R9 ReasoningaboutsecuritySLOsincloudSLA

A typical SLA might containseveral security related SLOs,whichmightbecumbersometonegotiate one by one. Thenegotiation mechanism shouldprovide the techniques toreasonaboutaggregatedsetsofsecurity SLOs (e.g., computingtheoveralleffectofacomposedsetofindividualSLOs).

Hasremainedthesame

SLANEG_R10 Followstandardsandindustrial-acceptedpractices

The different elements of thenegotiation process (e.g.,securitySLOs)shouldfollowasmuchaspossiblebothrelevantstandards and best practicesfrom the industrial domain.This requirement guaranteesthe interoperability andadoption of the expectedresults.

Hasbeenupdated



11

Table 1. Requirement related with the definition of the format of the SLA

3.2 Architecturerequirements This activity deals with the creation of the architecture of the Negotiation module. This includes the definition of the main functional blocks, the initial communication among them and the information

SLANEG_R11 Mappingtheuser’ssecurityrequirementstotheCSP’sofferedSLOs

Despitethelevelofgranularityutilized to specify the CSC’srequirements(cf.,SLANEG_R8),it is necessary to provide amappingtotheactualSLOsthatcanbeofferedbytheCSP.

Hasbeenupdated

SLANEG_R12 AdoptionofaconceptualmodelforsecuritySLOs

In order to promoteinteroperability, the securitySLOs being used in SPECSshould be associated with astandardized model thatdescribesinfurtherdetailtheirassociated elements e.g.,metricsandmeasurements.

Hasbeenupdated(has superseded oldrequirementsSLANEG_R14, R15andR17)

SLANEG_R16 OnlymeasurablesecuritySLO’scanbenegotiated

InordertobenegotiatedwithinSPECS, the security SLO’sshould be measurable (i.e.,associated with one or moremetrics). This feature allowsforcomparingtheusersecurityrequirements, with respect toeach one of the offered cloudserviceconfigurations.

Hasbeenupdated

SLANEG_R18 ManagementofAlertsonagreedSLA’s

TheSLAconceptualmodeldoesandshouldprovidesupportforthemanagementofalerts(e.g.,through the definition of thecorresponding thresholds),both to Monitoring andEnforcement.

Newrequirement

SLANEG_R19 SLOrepresentationusingamachine-readableSLAspecification

The selected SLA machine-readable specification shouldsupportbothSLO-independent,and SLO-dependentrepresentations(cf.,Section4.2,D2.1.2).

Newrequirement

SLANEG_R20 Securitymetricsmighthavequantitativeorqualitativevalues.

TheSLOincludedinanSLAmayinclude both quantitative andqualitative security attributes,as a consequence, securitymetricsshouldcopewitheitherquantitative or qualitativevalues.

Hasremainedthesame



12

exchanged. The following requirements (Table 3) are covered by the design of the architecture described in Section 6. REQ_ID Requirement Description Comment SLANEG_R3 Thenegotiation

processshouldsupportcompositecloudservices

InanalogytoSLANEG_R2,alsothe SLA evaluation techniqueshould support the notion ofcomposition (cloud supplychainwithtwoormoreSLA’s).

Has remained thesame

SLANEG_R4 NegotiatedSLOsshouldbemonitorableandenforceable

This is the basic requirementto build the (automated)managementofcloudSLAs inWP3andWP4.

Hasbeenupdated

SLANEG_R7 Interactiveandcustomercentricprocess

SPECs negotiation process isboth interactive andcustomer-centric: it is startedandfinalizedbythecustomer(e.g., evaluateddifferentSLAsuntil an agreement wasreachedwiththeCSP).Notice that this requirementdoes not apply to SPECS’ re-negotiation, which will befurtheranalysedinD2.1.2


SLANEG_R13 SecuritySLOshouldbemeasurableinthereal-world

ThesetofsecuritySLO’stobeconsidered by SPECS shouldbefeasibletoassess/measurein real-world clouddeployments.


SLANEG_R16

OnlymeasurablesecuritySLO’scanbenegotiated

In order to be negotiatedwithin SPECS, the securitySLO’s should be measurable(i.e., associated with one ormore metrics). This featureallowsforcomparingtheusersecurity requirements, withrespect to each one of theoffered cloud serviceconfigurations.

Hasbeenupdated

SLANEG_R18 ManagementofAlertsonagreedSLA’s

The SLA conceptual modeldoes and should providesupport for the managementof alerts (e.g., through thedefinition of thecorresponding thresholds),both to Monitoring andEnforcement.

Newrequirement

SLANEG_R19 SLOrepresentationusingamachine-

The selected SLA machine-readable specification shouldsupport both SLO-

Newrequirement



13

readableSLAspecification

independent, and SLO-dependent representations(cf.,Section4.2,D2.1.2).

ENF_PLAN_R3 DefinesecuritymechanismsrelatedtoSLOs

ThePlanningcomponentmustbe able to determine whichkind of security mechanismsaretobeapplied,givenasetofhigh-level SLOs contained intheSLAtoimplement.


ENF_PLAN_R14 ValidateanSLA The Planning component hastobeabletovalidateanSLAbyverifying that it can beenforced.

Newrequirement(Covers the discardedrequirementENF_PLAN_R1).

Table 2. Requirements related to the architecture of Negotiation

3.3 NegotiationprocessrequirementsThenegotiationprocessincludesthecompletedialogamongentitiesintheprocessesofreachagreementonasetofSLOsthatarepartofanSLA.Itincludesthestepsrequiredfromtriggeringa negotiation to the signing (or not) of an SLA. The following requirements (Table 2) arecoveredbythedesignofthenegotiationprocessesdescribedinSection6. REQ_ID Requirement Description Comment SLANEG_R3 Thenegotiation

processshouldsupportcompositecloudservices

The supply chain SPECS+CSP,might involve composing two-offered cloud SLAs for thenegotiation process. Thenegotiationprocessshouldhavearichenoughspecification thatwill allow for the definition ofthe interdependencies betweenthe constituent components ofcompositecloudservices.


SLANEG_R7 Interactiveandcustomercentricprocess

SPECs negotiation process isboth interactive and customer-centric:itisstartedandfinalizedbythecustomer(e.g.,evaluateddifferent SLAs until anagreementwasreachedwiththeCSP).Notice that this requirementdoesnotapplytoSPECS’ re-negotiation, whichwill be further analysed inD2.1.2


SLANEG_R34 Representingsecurityrequirementsofnon-expertusers

The negotiationmodule shouldprovide non-expert users withan easy way to express theirsecurity requirements (notnecessarily through individualSLO’s). For example, the

NewRequirement



14

approach followed by NIST onits Cloud Adapted RiskManagement Frameworkshouldbefurtherexplored.

SLAPL_R14 SearchCSPSLA The SPECS SLA Platform mustallow other SPECS componentstosearchforasetofSLAsintheCSP SLA repository byspecifyingasetofsearchcriteria


SLAPL_R21 GetSLA The SPECS SLA Platform mustallow other SPECS componentsto get the reference to a SPECSSLAcontainedintheSPECSSLArepository.


SLAPL_R10 GetCSPSLA The SPECS SLA Platform mustallow other SPECS componentsto get information (e.g. thegranted parameters) about aCSP’sSLAstoredintheCSPSLArepository by specifying an IDfor the SLA (obtained forexamplebyperformingasearchoperation).


SLAPL_R23 SearchSLA The SPECS SLA Platform mustallow other SPECS componentsto search for (i.e. obtain the IDof) a set of SPECS SLAs in theSPECS SLA repository, byspecifying a set of searchcriteria.


SLAPL_R24 CheckSLA The SPECS SLA Platform mustallow other SPECS componentstochecktheformalvalidity(e.g.,formatting, digital signatureexpiration etc.) of an SLAcontained either in the SPECSSLArepositoryorintheCSPSLArepository.


SLANEG_R23 Outputofasuccessfulnegotiationprocess

The result of a successfulnegotiation process is a well-formed SPECS security SLAhierarchy with the metricsvalues agreed with the End-user/customer.TheSLAisthensigned and stored in the SLArepository.


SLAPL_R27 CreateSLA The SPECS SLA Platform mustallow other SPECS componentstocreateaSPECSSLAdocument.




15

SLAPL_R33 SignSLA The SPECS SLA Platform mustallow the SPECS administratorandtheCSCtosignaSPECSSLA.


SLANEG_R32 Platformrepositories

The negotiation process needstoextract information fromthefollowingPlatformrepositories:Information about whichservices/mechanisms areallowed for a particular End-user.SLA’sofferedbySPECSPartnerCSP’s.Templates of supported SLA’s.Templates might be based ondifferent standards (ISO/IEC19086)andbestpractices(CSACCM/CAIQ).SLOservicecapabilityofferings.SLA’snegotiatedwithEnd-usersthroughSPECS.

Newrequirement

SLANEG_R33 SLAManagement

ThefollowingSLAmanagementoperationsshouldbesupportedbythePlatform:

• SearchCSPinrepository.• Search component for a

givenSLO.• Validatesupplychain.• SignnewSLA.• CreatenewSLA.• Search the CSP’s SLA

repository for usermatchingCSPSLO’s

• Create a new SLAtemplate

End-user-CSP negotiation andagreement on the (amended)SLAtemplate.

NewRequirement

Table 3. Requirements related with the Negotiation Protocol

3.4 RenegotiationprocessrequirementsSeveralsituationswilltriggertheinvalidityofacurrentsignedSLA.SuchareSLAviolationsorchanges inthecustomer´srequirements.Thiswillentail therenegotiationofnewSLAs.Thefollowingtablearetherequirementsassociatedtotherenegotiationprocess. REQ_ID Requirement Description Comment SLANEG_R25 Renegotiation

triggeredbyCSPortheEnd-user

Thegenericcase forsecurityrenegotiationcorrespondstothe CSP/End-user changingthe conditions applicable to

Newrequirement



16

itsservice,ortheoriginalsetof security requirementsrespectively.

SLANEG_R26 Inputforrenegotiation

Similar to negotiation, therenegotiation process startswith thesetofnew/changedsecurity requirements thatresulted on theviolation/alertoftheoriginalSLA. These new/changedsecurityrequirementsshouldbemanagedbySPECS in thesameway that the originallynegotiatedrequirements.

Newrequirement

SLANEG_R27 Outputofasuccessfulrenegotiation

PleaserefertoSLA_NEG_R22 Newrequirement

SLAPL_R34 ChangeSLA TheSPECSSLAPlatformmustallow the SPECSadministrator to update thecontentofaSPECSSLAafterre-negotiation.


SLAPL_R35 Generatealert TheSPECSSLAPlatformmustallow other SPECScomponents(belongingtotheMonitoring module) togenerate an alert to warnabout a possible incomingSPECSSLAviolation.


SLAPL_R36 Detect violation TheSPECSSLAPlatformmustallow other SPECScomponents(belongingtotheMonitoringmodule)todetecta SPECS SLA violation whentheguaranteedrequirementsarenolongerfulfilled.


Table 4. Requirements related to the Renegotiation process

3.5 SecurityReasoningrequirementsThisactivityprovidesthebasisforthesecurityevaluationapproaches.Theyallowtoreasonaboutsecurityinformation,takingasinputbothsecurityrequirementsandsecurityguaranteesprovided by security components and services from external CSPs. With such securityassessmentsomedecisiontoolscanbeprovidedtoCSCs,suchasrankingordashboards.Thefollowing requirements are covered by the design of the security assessment mechanismsdescribedinSection8.REQ_ID Requirement Description CommentSLANEG_R5 Supporttheevaluation Customers negotiating Has remained



17

oftrade-offs security SLOs throughSPECS, should be madeaware of the trade-offspossibly involving non-security related SLOs (e.g.,responsetime).

thesame

SLANEG_R6 EvidenceassociatedwithmeasuredSLOs

Customersmightneedtobeprovidedwithsomesortofevidence related with theimplementationofaspecificSLO, in order to make aninformed decision whilenegotiating a cloud SLA inSPECS.Thisevidencemightcomeinthe form of e.g., theassociated Securitycontrol’simplementationasdocumented in theapplicable securitycertification (e.g., CSA OCForISO/IEC27002).

Has remainedthesame

SLANEG_R8 Specificationofcustomer’ssecurityrequirements

Not all customers aresecurity experts; thereforetheirsecurityrequirements(input of the negotiationprocess) might come indifferent levels ofgranularity, based on theSPECS security SLAhierarchy(i.e.,fromControlCategories toMetrics/Measurements).

Has beenupdated

SLANEG_R9 ReasoningaboutsecuritySLOsincloudSLA

AtypicalSLAmightcontainseveral security relatedSLOs, which might becumbersome to negotiateonebyone.Thenegotiationmechanism should providethe techniques to reasonabout aggregated sets ofsecurity SLOs (e.g.,computingtheoveralleffectof a composed set ofindividualSLOs).

Has remainedthesame

SLANEG_R12 AdoptionofaconceptualmodelforsecuritySLOs

In order to promoteinteroperability, thesecuritySLOsbeingusedinSPECSshouldbeassociatedwith a standardized model

Has beenupdated(hassupersededoldrequirementsSLANEG_R14, R15



18

that describes in furtherdetail their associatedelements e.g., metrics andmeasurements.

andR17)

SLANEG_R34 Representingsecurityrequirementsofnon-expertusers

The negotiation moduleshould provide non-expertusers with an easy way toexpress their securityrequirements (notnecessarily throughindividual SLO’s). Forexample, the approachfollowed by NIST on itsCloud Adapted RiskManagement Frameworkshouldbefurtherexplored.

NewRequirement

SLANEG_R21 Orderedvaluesforsecuritymetrics.

All possible values(quantitativeorqualitative)associated with a securitymetric maintain an orderrelationshipbetween them.Forexample:!"#$"%&'# = *+, *- ⋯ */ where:

*+ < *- < ⋯ < */ And “<” denotes the orderrelationship.

Has remainedthesame

SLANEG_R22 Securitymetricsoperators

Securitymetricsvaluescanbespecifiedthroughanyofthefollowing:

• Binary operators “<,=,>,≤,≥”

• Logical operators“AND,OR,NOT”

• Intervals e.g. (512bits < EncryptionKeySize<2048bits)including temporalconditions e.g.(Hourly backupsfrom 8:00 hrs.to21:00hrs.)

Has remainedthesame

SLANEG_R28 Human-assessmentofsecuritymetrics

Atthestateofpractice,itiscommon to find securitymetrics that are assessedthrough humanintervention e.g., byauditorsverifyingtheCSP’ssecuritydocumentationand

NewRequirement



19

policies.These security metricsshould be also consideredduring the SPECS SLA lifecycle, and in particular inthe planning of themonitoringsystems/monitoring policytoactivate.

SLANEG_R29 Uncertainty/assuranceofperformedmeasurements

The security metricsnegotiated within SPECScan be assessed/measuredthrough different means(e.g., software sensors,documented policies) andactors (software agents,auditors). Given this widevariety of possibilities, wecan expect that theresulting/measured valuescan be associated withdifferent levels ofuncertainty/assurance.This requirementmight beimportant for bothmonitoring andenforcement.

NewRequirement

SLANEG_R20

Securitymetricsmighthavequantitativeorqualitativevalues

TheSLOincludedinanSLAmay include bothquantitativeandqualitativesecurity attributes, as aconsequence, securitymetrics should cope witheither quantitative orqualitativevalues.

Has remainedthesame

SLANEG_R30 RemediationthroughSLArenegotiation

Enforcement shouldconsider the renegotiationof an existing SLA as apotentialremedytoapplyincaseofalertsandviolations.

NewRequirement

SLANEG_R31 Alerts/violationsaffectingmultipleelementsofthesecureSLAhierarchy

A detected alert/violationmightaffectmore thanoneelement of the SPECSsecurity SLA hierarchy.Enforcement shouldconsider interrelationshipsalong SLA elements tochoose the optimalredressing technique (e.g.,renegotiationmighthelpto

NewRequirement



20

manage multiplealerts/violations).

ENF_PLAN_R3 DefinesecuritymechanismsrelatedtoSLOs

The Planning componentmust be able to determinewhich kind of securitymechanisms are to beapplied,givenasetofhigh-levelSLOscontained in theSLAtoimplement.

Has beenupdated

ENF_PLAN_R4 Getsecuritycomponents

The Planning componentmustbeabletoretrievetheavailable Enforcementsecurity components thatimplement the securitymechanisms related to thefulfilment of the SLOsdefined in the SLA toimplement.

Has beenupdated

ENF_PLAN_R5 Selectbestsecuritycomponent

Basedontheselectedtargetservice and on thenegotiated SLA, thePlanning component mustbe able to select the bestavailable Enforcementcomponents to invoke,amongdifferenttechnologystacks,inordertomeettheSLOsdefinedintheSLA.

Has beenupdated

Table 5. Requirements related to the evaluation of security



21

4. Security Level Agreement specification

4.1 SLAconceptualmodelIn D2.2.1, we introduced the SPECS security SLA hierarchy, specifying the main elementsrelevant to a security SLA, namely control categories, controls, service level objectives andsecuritymetrics,alongwiththeirinterrelationships.Theproposedconceptualmodel,showninFigure2,reportedthemainattributesoftheintroducedconceptsandputinevidencehowsuchconceptsarerelatedtooneanother.

Figure 2. SPECS security SLA conceptual mode proposed in deliverable 2.2.1

InFigure3,wereportthefinalSPECSSLAconceptualmodel,basedontheoneintroducedinD2.2.1.WerepresentanevolutionofitinthatitismoreorientedtotheactualimplementationofsecuritySLAs. Indeed,whiletheoriginalmodelwasmoresuitedfortheevaluationof thesecurityleveldeliveredwithaservice,theupdatedmodelallowsforthespecificationofalltheconcepts needed not only for security assessment but also for the automatic negotiation,enforcementandmonitoringofsecurityfeaturesontopofcloudservices.As shown, an SLA (referred to as Security SLA in the figure) is characterized by severalattributes related to the negotiation process itself (such as the agreement initiator andresponder)anditdeclaresaspecificSLATemplateonwhichitisbased.Indeed,asexplainedindetailsinSection5,negotiationisbasedontemplates.TemplatesrepresentthesetofnegotiablefeaturesthatcanbeincludedinanSLA.InSPECStheyarebuiltbytheSPECSOwnerandincludethesetofallsecurityfeaturesthatitiswillingtooffer,throughtheSPECSApplication,tothe



22

SPECSCustomers.Asdepicted, anSLA isbasically composedof threemain security-related concepts: securitycapabilities,securitymetricsandSLOs.

Figure 3. Refined SPECS security SLA conceptual model

Notethatthesecurity-relatedconceptsintroducedinthefirstversionofthemodelarestillvalidintheupdatedversion,evenifsomeslightchangeshavebeenmadeinordertobetterreflectthewaytheyareactuallyconsideredandimplementedinSPECS.

Firstofall,wesimplifiedtheconceptofcontrol,forwhichthefirstversionexplicitlyreportedadistinctionbetweensecuritycontrolsandcompensatingcontrols.InSPECS,weonlyconsidertheconcept of “security controls”, belonging to specific control categories of a chosen controlframework (e.g., CSA’s CCM [18] or NIST’s control framework [15]) and representing the“building blocks” of security capabilities1.AnEnd-user can require the activation of propersecurity capabilities (among those available in the template), to which specific securitymechanismsprovidedbytheEnforcementmodulearemapped.ThecontrolsthatbuildsuchcapabilitiesmaybeeithersecuritycontrolsorrelatedcompensatingcontrolsthatSPECSisabletoenforcetofulfiltheEnd-user’srequests.

Furthermore, the refined conceptual model does not explicitly consider interrelated SLOsanymore, as the dependencies among SLOs are captured by the dependencies among thesecuritymetricsontopofwhichtheSLOsarebuilt,andthesearemanagedatthetemplatelevel.Finally,weupdatedtheassociationbetweenSLOsandmetricstobecompliantwiththeWS-Agreementstandard,whichadoptstheconceptofvariabletobuildSLOsdependingonspecificmetrics.Intherefinedmodel,eachSLOisbasedonavariablethatreferstooneofthesecuritymetricsreportedintheservicedescriptiontermsection.Securitymetricsarestillrepresented1 Security capabilities are defined by NIST as combinations of mutually-reinforcing security controls (i.e.,safeguardsandcountermeasures)implementedbytechnicalmeans(i.e.,functionalityinhardware,software,andfirmware),physicalmeans(i.e.,physicaldevicesandprotectivemeasures),andproceduralmeans(i.e.,proceduresperformedbyindividuals)[14]



23

as reported in Figure 2, based on the RATAX specification; we did not include the relatedschemaforclarity’ssake.

In the next section,weprovidemore details on themachine-readable format based on thediscussedrefinedmodel.

4.2 SLAmachinereadablerepresentationWS-Agreement(WSAG),borninthecontextofGRIDcomputing,iscurrentlytheonlystandardsupportingbothaformalrepresentationofSLAsandaprotocolfortheirautomation,andhasbeenrecentlywidelyadopted,inthecontextofmanyCloud-orientedFP7projects(e.g.,Contrail,mOSAIC, Optimis, Paasage), to represent SLAs in the Cloud environment. However, WS-Agreement does not allow, by its original definition, to specify security-related attributes.Hence,forthepurposeofautomaticallymanagingtheSecuritySLAlifecycle,weintroducedaSecuritySLAmodelandamachine-readableformatbasedontheWS-Agreement’sXMLschemaandextendedwithallsecurity-relatedinformation.Anabstractviewof theSLAmachinereadable format isrepresented intheUMLdiagraminFigure4:asshown,itiscompletelycompliantwiththediscussedSLAmodel,whichisintegratedwithintheWSAGspecification(theextensionstoWSAGthatweproposedtoaddresssecurityarehighlightedinlightgrey).NotethatWSAGincludetermsabletospecifythebusinessvaluesassociatedtotheSLA(BusinessValueList),likethepenaltiesassociatedtoSLAviolations,inthefollowingwedonotdescribethemforsimplicity’ssake.Hence, as devised byWSAG, a Security SLA is providedwith basic information such as theagreement name and context data (including the agreement initiator and responder) andincludes a Terms section (refer to WS-Agreement specification), further structured inServiceTermandGuaranteeTerm.Servicetermsprovideinformationontheservicestowhich the agreement is referred and towhich guarantee terms can apply,while guaranteetermsspecifytheservicelevelsthatthepartiesagreeupon.Service terms are furtherrefined inservice description terms andservice property terms.Servicedescriptiontermsdefinethefunctionalitiesthatwillbedeliveredundertheagreement,andarecharacterizedbyatermname,aservicename,andadomain-specific description of the offered/required functionalities. In order to enrich the WSAGspecificationwithsecurity-relatedinformation,weproposedasecurity-baseddomain-specificservicetermdescription,madeofthefollowingthreesections:

• Resources Provider: thissectiondescribestheavailableinfrastructureresourceproviders(id,name,zone,andmaximumnumberofallowedinstancesreservations,ifapplicable) and theavailableappliances (i.e.,VMs)offeredbyeachprovider (typeofappliance,HW/SWfeaturesanddescription);

• Capabilities: this section describes the security capabilities offered/required ontopoftheservicescoveredbytheagreement.Asalreadymentioned,eachcapabilityisdefinedasasetofsecuritycontrolsbelongingtoaSecurityControlFramework,suchasNIST'sControlFrameworkorCloudSecurityAlliance'sCloudControlMatrix;

• Security Metrics: this section includes the specificationof the securitymetricsreferencedintheservice propertiessectionandusedtodefineSecurityServiceLevel Objectives (SLOs) in the guarantee terms section. A metric specificationincludesallinformationneededtoidentifyitandtocorrectlyprocesstheSLOsinwhichitisinvolved,suchasthemetricname,itsdefinition,itsunitandscaleofmeasurement,andtheexpressionusedtocomputeitsvalue.



24

Figure 4. SLA machine-readable format model



25

Service properties areused todefinemeasurableandexposedpropertiesassociatedwith a service. In ourmodel, each service property is explicitly associatedwith a securitycapability(sinceitisusedtochecktheenforcementofrelatedsecuritycontrols),andcontainsasetofvariables,referringtosecuritymetricsabovedefinedandrepresentingtheactualparametersadoptedinSLOexpressions.Finally, guarantee terms include the conditions that must be verified to fulfil theagreement.WeadoptedtheCustomServiceLevel itemoftheWSAGspecificationtodefineourcustomSecuritySLOs,identifiedbyanSLOid,areferencetothemetricinvolvedintheSLO,andtherelatedexpression,alongwithaweightassignedbytheservicecustomerandrepresentingtherelatedlevelofimportance.TheSLAplatformisdescribedinD1.1.3.TheXSDschemaofthemachinereadableformatisavailable online2 and also reported in D1.3. In Appendix I, we provide an example ofinstantiationofsuchschemaforaspecificcasestudy.

4.3 SPECSmetricscatalogueForthepurposesoftheSPECSnegotiationthemostimportantelementofasecuritySLAistheSLO. AccordingtotheconceptualmodelpresentedinSection3.1,aSLOiscomposedofonemetrics (either quantitative or qualitative), where the SLO metrics are used to set theboundariesandmarginsoferrorsCSPshavetoabideby(alongwiththeirlimitations).

The following table shows the metrics used for the SPECS services. These metrics aremeasurable,monitorableandcanbeenforced.EachmetricisassociatedtoasecuritycapabilityasdescribedinD4.3.2.ThelistofmetricsproposedresultsfromthedesignandimplementationofthesecuritymechanismsavailableatstateofartanditmakesobsoletethelistofmetricsthatwasreportedinD2.1.2.

Themetrics aremapped to control categories both from theNIST [15] andCloud SecurityAlliance’sCCM[18].

Capabilities Description Mappingto

NIST[15] MappingtoCCM[18]

Capabilities

Level of Redundancy (LOR)

This metric sets the minimum number (with respect to EU’s requirements and technological constraints) of web server engines, which are set-up and kept active throughout the service operation to increase the protection from attacks and vulnerabilities exploits. For example, level_of_redundancy = 3 ensures that there are at least three web servers running.

CP-6, CP-7, CP-9, CP-10, SC-5, SC-22, SC-36, SA-2,

SI-13

BCR-01 Web Resilience

Level of This metric sets the number of SC-23 BCR-01 Web

2SchemafortheSPECSSLAspecification:http://www.specs-project.eu/resources/repositories/



26

Diversity (LOD)

different web server types available on target VMs. For example, for level of diversity = 2, SPECS ensures that there are at least two different types of web servers deployed and available.

Resilience

TLS Cryptographic Strength (TCS)

This metric sets the cryptographic strength to be used by the TLS Terminator. TLS Terminator Configurator will choose the appropriate cryptographic ciphers that meet the negotiated level and configure TLS Terminator accordingly.

SC-13 EKM-01 TLS Security

Forward Secrecy (FS)

This metric ensures that the encrypted data sent through a session of the TLS secure channel cannot be decrypted even if the cryptographic data, used to generate the cryptographic credentials for that session, are compromised.


HTTP Strict Transport Security (HSTS)

This metric is a feature of HTTP transport layer that declares the web content available only over a secure HTTP connection.

SC-43 IAM-02 TLS Security

HTTP to HTTPS Redirects (HHSR)

This metric is a feature of HTTP delivery service that forces clients to use only secure HTTP protocol.


Secure Cookies Forced (SC)

This metric is a feature of HTTP protocol to force the clients to download session cookies, delivered by the HTTP services, only through a secured HTTP communication


Certificate Pinning (CP)

This metric is a feature of HTTP protocol allowing the verification of the SSL certificates between the client and the HTTP service where the hash of the public certificate is pinned into the HTTP response.

SC-17 IAM-09 TLS Security

Scanning Frequency - Basic Scan

This metric sets the frequency of the basic software vulnerability scanning. For

CA-7, RA-5 TVM-02 Software Vulnerability Assessment



27

(BSF) example, for scanning_frequency = 24h, SPECS ensures that software vulnerability scanning will be performed at least once every day.

List Update Frequency (LUF)

This metric sets the frequency of updates of the list of disclosed vulnerabilities. For example, for list_update_frequency=12, SPECS ensures that the list of published vulnerabilities will be updated and presented at least once every 12 hours.

CA-7 (3), RA-5 (1)

TVM-02 Software Vulnerability Assessment

Write-Serializability (WS)

This metric ensures the EU that any WS violation to his stored data will be detected in a defined period of time (detection periods are less than 2*epoch). In case of WS violations, the EU will be notified and the system will be restored to the state of the last finished epoch.

CP-2 (4), CP-2 (6), CP-6 (1),

CP-9, CP-9 (6), CP-10, SI-7, SI-7 (1), SI-7 (2), SI-7 (5)

IVS-02, BCR-01, BCR-11

Database and backup as-a-Service

Read-Freshness (RF)

This metric ensures the EU that any RF violation to his stored data will be detected in a defined period of time (detection periods are less than 2*epoch). In case of RF violations, the EU will be notified and the system will be restored to the state of the last finished epoch.

CP-2 (4), CP-2 (6), CP-6 (1),

CP-9, CP-9 (6), CP-10, SI-7, SI-7 (1), SI-7 (2), SI-7 (5)

AIS-03, BCR-01, BCR-11

Database and backup as-a-Service

Client-side Encryption Certification (EC)

ThismetricensuresthattheE2EE Client componentavailable at the providedaddressiscertifiedandthusgrants the security of theencryption.

SC-12, SC-13 EKM-01, EKM-03

End-2-End Encryption

Scanning Frequency - Extended Scan (ESF)

This metric sets the frequency of an extended software vulnerability scan. For example, for scanning_frequency=48, SPECS ensures that software vulnerability scans will be performed at least once every two days. Scans are performed




28

with two scanners and both scanning reports are presented.

Up Report Frequency (URF)

This metric sets the frequency of checks for updates and upgrades of vulnerable installed libraries. SPECS first updates vulnerability list, performs the vulnerability scan of the system, and then checks for available updates and upgrades of libraries on which vulnerabilities have been detected). For example, for up_report_frequency=24, SPECS ensures that checks for updates and upgrades are performed at least once every day.


Penetration Testing Activated (PTA)

This metric activates the penetration testing activity. The metric can be chosen together with metrics related to vulnerability scans. If chosen, scanner with penetration testing functionality is deployed.

CA-8 TVM-02 Software Vulnerability Assessment

Table 6. Metrics implemented by SPECS services that are enforceable and monitorable Table7displaysthengDCmetricsdevelopedinWP5(tobereportedinD5.3)aspartofthestorageautomationsoftware(ViPR3)thatcentralizes,automatesandtransformsstorageintoasimpleextensibleandopenplatform.Metric Name Description Mapping to

CCM Mappingto

NIST Capability

RAID Level (s)

Select which RAID levels the volumes in the virtual pool will consist of.

BCR-01 SA-2, SC-6, CP-9, CP-10,

SI-17

Availability

Multi-volume Consistency

Volumes can be assigned to consistency groups to ensure that snapshots of all volumes in the group are taken at the same point in time.

BCR-01 CP-1, CP-10, SI-17

Availability

High Availability (Type)

HA provides the foundation for a highly available environment.

BCR-01 SC-6, SI-17 Availability

Maximum Snapshots

Maximum number of local snapshots allowed for resources from this Virtual Pool.


3http://www.specs-project.eu/solutions-portofolio/vipr/



29

Max Native Continuous Copies

The maximum number of continuous copies for a virtual pool


HA Max Mirrors

Maximum number of data storage mirrors

BCR-09 SC-5, SC-6, SI-13, CP-6,

CP-9

Availability

Provisioning Type

Storage type provisioning for the current virtual pool

IVS-04 SA-2, CM-2 Performance

Protocols This depends on what is available to ViPR (e.g. could also support ScaleIO)

BCR-11 SA-2, CM-2 Performance

Drive Type All current supported hardware type


System Type Supported system type for the virtual pool


Min SAN Multi Path

The minimum number of paths that can be used between a host and a storage volume. If this many paths cannot be configured, Export requests will fail.

BCR-09 SC-6, SI-17 Performance

Max SAN Multi Path

The maximum number of paths to a given StorageArray from a host. Depending on paths_per_initiator, one or more ports may be assigned to an initiator if max_paths is sufficiently high for the number of initiators.


Data geolocation

In which data center the virtual storage and its copies are located

BCR-06 PE-17, PE-18, PE-20, SI-12

Security Storage

Anti-virus Policy

Anti-Virus scanning schedule interval in the virtual storage

TVM-02 CA-7, SC-28, SC-35

Security Storage

CloudProof Write-Serializability

This metric ensures the EU that any WS violation to his stored data will be detected and remediated in a defined period of time (detection and remediation periods are less than 2*epoch). In case of WS violations, the EU will be notified, and the system will be restored to the state of the last finished epoch.

IVS-02 CA-7, SC-28, IR-5, IR-8

Security Storage

CloudProof Read-Freshness

This metric ensures the EU that any RF violation to his stored data will be detected

AIS-03 CA-7, SC-28, IR-5, IR-8

Security Storage



30

and remediated in a defined period of time (detection and remediation periods are less than 2*epoch). In case of FR violations, the EU will be notified, and the system will be restored to the state of the last finished epoch.

CloudProof Client-side Encryption Certification

This metric ensures that the code available at an address is certified by a trusted entity.

EKM-01 SC-13, SC-17, SC-28,

Security Storage

Protection Mirror VPool

The virtual pool for protection mirrors

BCR-01 SC-6 Availability

HA VArray VPool

Indicates whether or not to use the HA side of the VPlex as the RecoverPoint protected site in an RP+VPLEX setup. In a MetroPoint context, if true, this field indicates that the HA VPlex site will be the active site.

BCR-01 SC-6 Availability

HA Protection Mirror VPool

The virtual pool for protection mirrors on the High Availability side


Fast Expansion

Indicates that virtual pool volumes should use concatenated meta volumes, not striped

BCR-07 SA-2, SC-6 Performance

Path per Initiator

The number of paths to be provisioned for each initiator that is used. In any event no more ports are used per host than max_paths. If there are excess initiators that cannot be paired with paths_per_initiator number of ports because max_paths is too low, the excess initiators are not provisioned.


Table 7. Metrics developed in WP5



31

5. Architecture overview Thehigh leveloverviewof theNegotiationmodule isdepicted inFigure5.Thearchitectureitselfhasnotchanged,whatactuallychangedwithrespecttodesigninyear1aretheinterfacesandinteractionsamongtheNegotiationcomponentsandtherestofthemodulesoftheSPECSframework.Consideringthatthenegotiationandrenegotiationprocesseshavebeenamended,therolesofcomponentsslightlychanged.

Figure 5. High level negotiation architecture

Threecomponentscomprisethefinalnegotiationarchitecture:

• The SLO Manager is the component that offers the negotiation API to the SPECSApplication. It orchestrates the entire negotiation and renegotiation processes. ItmanagesthecreationofSLAtemplates,ittriggersgenerationofsupplychainsaccordingtotheEnd-user’ssecurityrequirements,andinvokesevaluationandrankingoftheSLAoffersthatarebuiltaccordingtothesupplychains.

• The Supply Chain Manager is the component in charge of building supply chainsaccordingtothesetofsecurityrequirementschosenbytheEnd-user.Thecreationofsupply chains is supported by the Enforcement module (through the Planning); forfurtherdetailsseeD4.3.2.

• TheSecurityReasonercomponentevaluatesandrankstheSLAofferscreatedduringthenegotiationprocess.Theevaluation isdonebyusing security assessment techniquesthatapplyquantificationalgorithmstoreasonaboutthelevelofsecurityprovidedbyeachoftheSLAofferwithrespecttotheenduserrequirements.Section8detailsthetwotechniquesadoptedinSPECS.

The(implementation)detailsofthebuildingblocks,interfaces,andprotocolsaregivenaspartoftaskT2.3,andwillbereportedindeliverablesD2.3.2andD2.3.3atM30.



32

6. SLA negotiation process Theevolutionof thenegotiationprocessduringY2 isa consequenceof the implementationactivities carried out in T2.3, some processes designed in Enforcement (i.e., supply chaincreationandremediation,describedinD4.3.2),andaspectsoftheSPECSApplication(describedinD5.1.3)approach.Theamendednegotiationprocesshastwomainnewfeatureswithrespecttotheonepresentedinthefirstyear:

• End-users(EUs)candecidemoreaspectsoftheservice,includingthetypeofservice,theCSPtobeusedforeachservice,thesecuritycapabilitiestoaddtotheserviceandthecontrolsandmetricsdetailsforeachoftheselectedcapabilities.ThisapproachallowstoenhancetheusabilityofthesolutionasseenfromtheEUsperspective.Separatingthedefinition of user´s preferences into services, capabilities, controls and metrics is aflexiblewaytodefinedifferentapproachesforeachfeaturetobespecifiedbyEUs.TheD5.1.3detailshowthishasbeenimplemented.

• The role of the CSP during the negotiation process has been included by adding acertification of the valid offers performed by CSPs. Like in real life, the negotiationapproach proposes a bilateral agreement between the CSP and the EU, where bothpartiessignthecontract.ThesignatureoftheCSPcertifiesthat(1)theCSPcanprovideallthefeatures(fromasecurityperspectiveandalsofromafunctionalpointofview)that an SLA specifies, (2) the CSP guarantees to provide the terms included in theagreement.FromtheEU’sperspectivethesignature isusedtocertifythecontractualrelationship between the CSP and the EU (payment conditions, actions in case ofunfulfillment,etc.).

Figure6representsasimplifiedflowdiagramofthenegotiationprocess.

Negotiation process

Definition of EUs’ preferences

Supply chains creation

Start Negotiation

Select Service

EU selects capabilities

EU selects controls

EU selects metrics

SLA offers creation

Rank SLA offer

Provide EU with valid, ranked, and verified SLA offer

EU selects and signs SLA offer

Implement SLA

CSP signs valid SLA

offers

Figure 6. Simplified negotiation process

TheEnd-userstartsselectingtheservicetouse(forexample,aSecureWebContainerservice).Once the service is selected, the EU customizes the security aspects offered by the chosenservice.ThestepstodefinethesecurityfeaturesoftheservicehavebeenrefinedinY2.Theterm capability is now introduced which represents a set of security controls that can beimplementedwithoneormoresecuritymechanismsontopofasecurityservice.Forexample,in case the EUwants periodic vulnerability scans on the requestedweb servers under theumbrella of the Secure Web Container service, the capability to add will be the SoftwareVulnerability Assessment capability (which can implement a security control related topenetrationtests).Ontopofthechosencapabilities,theEUcanfinetunehispreferencesbyspecifyingconcretecontrolsandmetricvalues.Ofcourse,thisdependsonthelevelofexpertise



33

oftheEU.ExpertEUsareabletospecifyspecificvalues(beingabletospecify,forexample,thefrequency of the vulnerability scans). Non-expert EUs are able to specify qualitativerequirements(intheformofnotimportant,veryimportant).Thisuncertaintyofnon-expertEUsistakenintoaccountwhenevaluatingthesecurityleveloftheserviceofferschosenbytheEU. The security reasoner described in Section 8.2 uses fuzzy-based algorithms to add theuncertaintytotheanalysis.OnceSPECScollectsalltheinformationrequiredbytheEU,thecreationoftheSLAofferstarts.EachcreatedSLAofferwillcorrespondtoasupplychainandeachsupplychainiscomposedofoneCSPandasetofresourcesenrichedwithsecuritymechanismsenforcingandmonitoringEU’s chosen security features. The supply chains are created by SPECS according to theavailable securitymechanisms (either offered by SPECS or provided by external CSPs) andsecurityrequirementsprovidedbytheEU.ThecombinationoftheseelementswillprovidealistofsupplychainsthatwillbetransformedintoasetofpotentialSLAs(i.e.,SLAoffers).EachSLAofferwillrepresentonesupplychain.BeforeeachSLAofferisproposedtotheEU,ithastobe validated by the CSP. This is necessary to guarantee that the supply chains created areactuallyfeasible(forexample,tocheckthattheCSPcanactuallyprovidetheservicewiththecontrolsspecifiedbytheEU). TheEUthenreceivesthelistofvalidSLAs.ThelistofSLAsisrankedaccordingtotheEU’srequirementsbyapplyingthereasoningalgorithmsthatperformcomparisons and evaluations to determine what are the SLAs that better match EUrequirements.

Amore detailed negotiation process is depicted in the sequence diagram of Figure 7. TheinteractionswiththeSLAPlatformandwiththeEnforcementmoduleareclearlyrepresentedinthediagram.

Tounderstand thedetailedprocess,wewill onlyoutline themost relevant steps.FormoreimplementationrelateddetailsofthisprocessweforwardthereadertodeliverablesD2.3.2,D2.3.3andD4.3.3deliveredatM30.

Thenegotiationprocess is triggereddirectlyby theEU through theSPECSApplication.TherequestisforwardedtotheSLOManager(step2-4)thatreturnstotheEUthelistofsecurityservices offeredby SPECS, for example, a secureweb container service or a secure storageservice. Note that all communication between the EU and SPECS goes through the SPECSApplication.

The selectionof a service triggersdefinition, by anEU, of the specific requirements for theselectedservice.Todoso,theSLOManager(afterreceivingtheservicechosenbytheEUinsteps5-6)retrievesfromtheSLAPlatformthesetofsecurityfeaturesavailablefortheselectedservice(steps7-9).ThisisdonebytheusageofSLAtemplatesthataremodifiedaccordingtothechosenserviceandthepossiblecombinationsofsecurityfeatures(capabilities,controls,andmetrics).NotethatonlyoneservicecanbeenforcedwithoneSLAandthatforeachserviceonespecificSLAtemplateisavailable.

Inordertobuild thissetofsecurity features for theselectedservice, theSPECSApplicationinteractswiththeEUofferingfirstsecuritycapabilities,thensecuritycontrolsapplicabletothechosensetofsecuritycapabilities,andattheendsecuritymetricsapplicabletothesetofchosensecuritycontrols(steps11-15).Asmentionedbefore,thewaythesesecuritypreferencesaresetdependsonthetypeofEU(expertornon-expert).



34

Figure 7. High level sequence diagram for the negotiation process



35

Steps16-21comprisethecreationofthesupplychains.Oncetheserviceandalltheassociated

securityfeaturesareset,theSLOManagerinvokesthegenerationofthepossiblesupplychains.The Supply ChainManager invokes the Planning componentwhich has all the information

(aboutavailableservicesandresourcesandtheir implementationandconfigurationdetails)

requiredtobuildallpossiblesupplychainsthatfulfilEU’ssecurityrequirements.ThePlanningrepliesbacktotheSupplyChainManagerwithalistofIDs,eachrepresentingonesupplychain

thathasbeencreated.AdetaileddescriptionoftheprocessisavailableinD4.3.2.

TheSLOManagerthenretrievesallgeneratedsupplychainsandcreatesanSLAofferforeachsupplychain(step22).ThecompletesetofSLAoffersisgiventotheSecurityReasonerthat

performsevaluationandprovidestherankingofSLAsintermsofsecuritylevelstheyguarantee(steps22-25).NotethateachsupplychainistiedtoadifferentCSP,thuseachsupplychainand

eachassociatedSLAofferassuresadifferentlevelofsecurity.Thetechniquesusedtocarryout

thissecurityassessmentaredescribedindetailinSection8.

BeforeprovidingtheEUwiththecompleterankedlistofSLAoffers,allCSPsareaskedtocheck

theirvalidity(step26).ToavoidofferingtotheEUunfeasiblecompositionsofservices,theCSPswillcheckallcomposedprovisions.OnlyvalidSLAoffers(i.e.,validsupplychains)willbesigned

andofferedtotheEU(step27).TheEUselectshispreferredSLAandsignsit(step28).The

chosenSLAofferisthenstoredasasignedSLA(theprocessishandledbySLOManagerafterstep29),andthenitcanbeenforced(step30).



36

7. SLA renegotiation processes Duringthesecondyearoftheproject,theprocessofrenegotiationhasbeencarefullystudied.

Strong synchronization activities have been conducted between the Enforcement and

Negotiationmodules. Renegotiation occurswhen an enforced SLA needs to be changed forsomereason.TwocasesrepresentthesituationswhereasignedSLAhastoberenegotiated:

• CSP triggered renegotiation: in this case, aviolation invalidates the currentenforcedSLA.Thishappenswhenaviolationoccursand there iseithernoremediationaction

availableortheremediationprocessrequiresachangeinsomeSLO.Asaresult,theSLAisnotvalidanymoreandanewagreementhastobenegotiated.

• EUtriggeredrenegotiation:inthiscase,theEUwantstochangesomeoftheconditionsof the SLA (to addor remove capabilities, controls,metrics, or to simply change the

conditionsofoneormoreSLOs).

Inbothcases,theinitiallyenforcedSLAisnotvalidandanewSLAhastobesigned.Thisisamandatoryrequirement,sinceanychangeinanSLA,nomatterhowsmallitis,invalidatesthe

signatureandthecontract.

Tosimplifytheprocessesandoptimizetheneedforimplementationefforts,wetriedtoreuse

thecurrentnegotiationprocessasmuchaspossible.Thefollowingsubsectionsdetailthetwotypesofrenegotiation.

7.1 CSPtriggeredrenegotiationInaCSPtriggeredrenegotiation,anotificationfromtheRDScomponentoftheEnforcementmodulestartstheprocess.ThisnotificationmaybetheresultofanSLOviolationthatentailed

theinvalidationofasignedSLA.ThesimplifiedprocessisdepictedinFigure8.

Negotiation process

Renegotiation notification

Implement SLA

Retrieve affected SLA

Notify end user about the violation/alert

Ask EU to renegotiate

Prepare SLA template

EU defines capabilities, controls, metrics

Figure 8 Simplified renegotiation process (CSP triggered)

NotethattheEnforcementmoduleonlynotifiestheNegotiationthatsomepartofthesigned

SLA isno longervalid. It isup to theEnd-user toeither terminate theSLA,accept therisksassociatedtotheviolation,orrenegotiatetheSLA.

AfterreceivingthenotificationfromtheEnforcementmodule,theprocessbeginsbyretrievingthe affected SLA. According to the violated SLA an SLA template for the initially enforced

securityserviceisretrievedandfilledwiththeinitialsetofsecurityfeaturesextractedbythe

violatedSLA.Thisallows theEU (in case she/hedecides to renegotiate theSLA) touse theinitiallychosensecuritysettings,tochecktheaffectedSLOs,andtoprovideanewsetofsecurity

requirementsrelatedtothoseaffectedSLOs.Ofcourse,theEUisallowedtoremoveoldand/or



37

addnewsecuritycapabilities,controls,andmetrics.

OncetheEUhasacceptedtorenegotiatetheviolatedSLA,thenegotiationprocessiscarriedout

(followingtheprocessdescriedinSection6).Iftherenegotiationendssuccessfully,thenewly

signedSLAisreadytobeimplemented.

Thisapproachhasallowedus tocompletely reuse thenegotiationprocess, thusmaking the

integrationofbothprocessesintheimplementationstagemucheasier.

TheCSPtriggeredrenegotiationprocessisdetailedinthesequenceofFigure9.ThediagramhighlightsthenegotiationprocessasreusedfromtheonedescribedinSection6.

Steps1-9 illustrate thesteps thatareexclusive to theCSPtriggeredrenegotiation.Once the

notificationhasbeenreceivedfromtheRDStotriggertherenegotiationprocess(step1),theSPECSApplicationretrievestheaffectedSLAfromtheSLAManager(steps2-3).

Steps4-7comprisethecustomizationoftheSLAtemplateassociatedtotheinitiallyenforced

security service. This customization (filling the templatewith EU’s initially chosen security

features)permitstoshowtotheEUtheinitialservicesettingsandmakestheselectionofnewfeatures easier. This can alsobeused to show to theEU the affected SLOs.TheEUhas the

possibilitytoacceptarenegotiationorterminatetheSLA(step8).Theprocessofterminating

anSLAisdescribedinD4.3.2aspartoftheEnforcementactivities.

IncasetheEUacceptstherenegotiation,theprocessofnegotiatingthenewSLAstarts(steps

10-30)withthesamestepsalreadydescribedforthenegotiationprocess(seeSection6).ThedifferenceishiddeninthewaytheEUischoosingthesecurityfeaturesfortheservice.Whilein

thenegotiationprocessthepreferencesarechosenfromscratch,intherenegotiationprocess

the preferences are set to the values of the initial SLA, so that the EU can simply modifyparametersthatshe/heprefers.Duringtherenegotiationprocessthepossiblesupplychains

arebuiltagainandofferedtotheEUintheformofrankedSLAofferslikeinthenegotiation.

This isdonetocover thepossibilityofchanges in thenumberofrequiredresourcesor inacombinationofsecuritymechanismsenforcingandmonitoringtheselectedsecurityfeatures,

or evendue to the changeof a CSP. Formoredetails on the implementationdetails of thisprocessweforwardthereadertothedeliverablesproducedbytasksT2.3andT4.3.



38

Figure 9. Renegotiation process triggered by CSPs



39

7.2 EUtriggeredrenegotiationAnEU triggered renegotiationoccurswhen it is theEUwho freelydecides to change someaspectofhissignedSLA(forexample,toremoveoraddanewcapability,control,metric,ormodifyconditionsofsomeSLO).TheprocessoftheEUtriggeredrenegotiation(showninFigure10)isevensimplerthantheCSPtriggeredrenegotiationandalsoreusesthenegotiationprocesspresentedinSection6.

Negotiation process

EU triggers renegotiation

Implement SLA

Retrieve SLA to

renegotiate

EU defines new capabilities, controls, metrics

Rebuild service

Figure 10. Simplified renegotiation process (EU triggered)

TheEUsendsarenegotiationrequestthoughtheSPECSApplication.TheSLAisretrievedfromtheSLAManagerbyusingtheIDoftheservice.AnSLAtemplateisthencustomizedwiththecontentsof the signedandmonitoredSLA. Similarly to theCSP triggered renegotiation, thecustomizedSLAtemplatecontainstheEU’sinitialsecuritypreferencesandisusedtopromptthe EU tomodify the existing ones or remove and/or add new features. The EU redefinescapabilities, controls, and metrics, and the negotiation process continues up to theimplementationofthesignedSLA.Figure11showsthedetailedEUrenegotiationprocess.Steps1-9representthe interactionsthatareexclusive to theEU triggeredrenegotiationwhile steps10 to30correspond to thenegotiationofthenewSLA(totheprocessdescribedinSection6).Renegotiation process startswith the EU’s invocation (step 1). In steps 2-3 the previouslyenforcedSLAthattheEUwantstomodifyisretrievedfromtheSLAPlatform.SameasintheCSPtriggerednegotiation,thecontentofthisSLAisusedtobuildanewSLAtemplate(steps4-7)thatcontainstheinitiallynegotiatedSLOs.ThecustomizedSLAtemplateissenttoSPECSApplicationthatisusedtogivetheEUthepossibilitytochangetheconditionsoftheinitiallyenforcedsecurityservice(step8-15).Inthiscase,theprocessofcreatingnewsupplychainsisdoneagainsinceitispossiblethatwiththenewsecuritypreferencesselectedbytheEU,newserviceofferscanbeprovided(differentCSPs,differentsettingsforthecapabilities,etc.).FormoreimplementationrelatedtothedetailsofthisprocessweforwardthereadertothedeliverablesproducedbytasksT2.3andT4.3.



40

Figure 11. Renegotiation process triggered by an EU



41

8. Security Reasoners AccordingtothenegotiationprocessasetofsupplychainsarecreateddependingontheEU’srequirements. These supply chains, as described in D4.3.2, are composed of one CSP andcapabilitiesofferedbySPECSwhichenhancesomespecificsecurityfeaturesaccordingtotheEU’spreferences.AsdescribedinSection6,adifferentSLAofferisbuiltforeachsupplychaincreatedduringthenegotiationprocess;asaresulteachSLAofferisalsolinkedtothesecuritycontrolsofaCSPandtotheSLOsofthecapabilitiesofferedbySPECS.TheproposedsetofSLAoffersaresenttotheEUsothatshe/hecanchoosewhichonetosign.WhileSPECSprovideswithmechanismstoenforceSLOsthatarepartoftheSPECSservices,thereexistsacertaindegreeofuncertaintywithregardstothesecuritycontrolsprovidedbytheCSPsthatarepartofanSLAofferbutareoutofthecontrolofSPECS(becausetheyarenotenforceableormonitorable).Todealwiththisissue,thesecurityreasonerprovideswiththenecessaryinformationthatcanhelpEU’stodecidewhichCSPbettermatcheshisrequirements.Bycomparing,consideringcontrolsimplementedbytheCSPsweareabletobuildarankingofSLAoffers.ThescoreofeachSLAofferwilldependonthefulfilmentofthesecuritycontrolsthatarenotenforceablebySPECSbutareprovidedbytheCSPthatispartofthesupplychain.Figure 12 summarizes the evaluationworkflow, as requested in the SPECS behaviour. ThereasonerhastoextracttheinformationfromtheSLAoffers,asreportedintheSLAmachinereadable format described in Section 4 and then evaluate them according to the reasonedmethodology.

SLAOffers

ExtractInformationforQuantitative

EvaluationRanking

OrderedSLAOfferswithQuantitative

Evaluation

Figure 12. Simplified Evaluation Workflow

EUs’securityrequirementsareusedinadifferentwayforreasoningdependingonthetypeofcontrolthatisbeingconsidered:

• RequirementsforSLOsofSPECSservices.TheycanbeenforceableandmonitorablebySPECSandthereforearepartofasignedSLA.SPECScanadaptthemetricsofthesecuritycontrolschosenbyEUsandprovidethemwithacompatibleSLAoffer.

• Requirements forsecuritycontrolsofCSP.Thesecontrolscannotbeenforceableandmonitorable,sincetheyareundertheCSPdomain.AsaresulttheyarenotpartofthesignedSLA.Howevertheyplayan importantrole inthedecisionsupportmechanismthatisprovidedtoEUsbySPECS.SecurityreasonersareabletocompareCSPsaccordingto the level of fulfilment of these controls with respect to EU’s requirements, thusprovidingthemwitharankingthatsortsSLAoffersaccordingtheserequirements.

Theevaluationperformedbythesecurityreasonerisbasedontwoassessmentalgorithmsthat



42

areabletocompareEUsecurityrequirementswithrespecttothesecuritycontrolsprovidedbyCSPs.SPECShasdesignedtwoalgorithms:

• REM[18](cf.,section8.1),thatusesaggregationtechniquestoperformanevaluationofthesecuritylevelprovidedbyaprovider.

• Afuzzylogicbasedsecurityassessmentmethodologybasedonfuzzy-AHP[9][10](cf.,section8.2)thatisabletomanageuncertaintyofEU’srequirementstoprovideamulti-layeredcomparisonofthesecurityprovidedbyprovidersandrequirementsdemandedbyEUs.

TheinformationusedasinputforbothREMandfuzzy-QHPisbasedontheconceptualmodeldefined in section 4 to represent SLAs. Both techniques will produce similar hierarchicalstructurestoprocesstheinformation,asitwillbedescribedforeachtechniqueinthefollowingsections.

8.1 UseofREMfortheevaluationoftheSPECSSLAModelThis section describes how the REM technique has been adapted to be used in the SPECScontext.ThedescriptionoftheREMmethodologywasreportedinD2.2.1.

8.1.1 REMEvaluationofCAIQsEvaluationInordertoevaluatedifferentprovidersthatcanbeadoptedwithSPECStohostatargetservice,weusedtheinformationstructurebasedontheSPECSconceptualmodeltorepresentSLAs.ForthespecificusagebyREMtheavailablesecuritycontrolsprovidedintheCloudControlsMatrix(CCM),isused.Furthermore,webuildahierarchicalstructureofsecuritycontrolsbyreferringtotheConsensusAssessmentsInitiativeQuestionnaire(CAIQ)[11]thatprovidesaseriesof“yesorno”controlassertionquestionstoassessCloudServiceProviderssecurity.

The CAIQ can be considered a very simple form of Security Service Level Agreementrepresentation:itdeclaresallthesecuritycontrolsthataCSPisabletoprovide,evenifitdoesnot offer any concrete guarantee about their real enforcement (it is not a contract amongcustomerandprovider,itisjustapublicdeclaration).Moreoveritcannotbemonitoredfromacustomer,notofferinganyconcretesecuritymetric.AtmostitispossibletoperformanauditprocesswhichverifiesthecorrectnessoftheCSPdeclarations.So,asecuritySLAcontainsallthe information a CAIQ includes, but the contrary is not true. Furthermore a repository ofquestionnairecompiledbymorethan100CSPsisalreadyavailableforcomparison(c.f.,STARrepository[17]).ThepositiveaspectoftheCAIQandtheSTARrepositoryisthattheyrepresenta public repository of declarations that enables anEU toperforma comparison among thesecurityofferedbyeachCSP;nevertheless,theCAIQcontainsabout300questions(categorizedincontrolsandcontroldomains)makingitverydifficulttoanalysethemforCSPcomparisonfrom theEU’sperspectives.TheREMeasily supports suchaprocessoffering aquantitativerepresentationthattakesintoaccounttheEU’srelativeneeds.

Figure 13 illustrates the REM methodology steps applied on the CAIQ: Structuring,Formalization,WeightingandEvaluation.



43

Figure 13. REM Evaluation steps applied on the CAIQ

ThegoaloftheStructuringphaseistocreateatreedatastructurestartingfromtheCAIQandassignanenumerativedatatypetoeachnodeofthetree.InthecaseoftheCAIQ,thisprocessisverysimple;asillustratedinFigure14,theCAIQalreadyhasatreestructure,therootnodeis associated to the full questionnaire, and second level of the tree includes the controlcategories,thefollowingonetotheControlgroupsandthelatestonetothespecificsecuritycontrols.

Figure 14. The CAIQ tree

In theFormalizationphase, theCAIQ tree is turned intoa treeenrichedwithhomogeneousvalues.AllleafnodesintheCAIQtreehavethesamedatatype(Yes/No)butinsomecasestheyarenotspecified(N/A);wecanrepresentthesewithanorderedenumerativevalues(N/A, No, Yes)andassignanumericalvalueforcomparison.Theset{N/A, No, Yes}canbeorderedinthisphase,according todifferentevaluationcriteria. InSPECS,weproposedadefaultascendingorder:N/Ameans thatCSP isnotable toreplyandweconsider thisworse thantheexplicitchoiceofNOTadoptingthecontrol.

Thesevaluesarethenmappedonascaleoffoursecuritylevels(c.f.,LocalSecurityLevels)4;apossiblemappingis:Yes=3,No=1andN/A=0.

4WiththeREM,theassignmentofvaluesisconfigurable.Wesuggestfourlocalsecuritylevelsandthismapping,sincethischoicebetterhighlightthedifferencebetweenverysimilarSLAs.



44

AnEnd-usercangiveadifferentimportancetoeachsecuritycontrolandcontrolgroupinthetree.IntheWeightingphasetheEnd-Usercanprovideitsownweightonbothsinglecontrolsoronthelargercategoryandexpress,inthisway,his/herprioritiesanddesiderata.

Inthelaststep,itispossibletoevaluatetheGlobalSecurityLevelprovidedbytheCSP.

TheGlobalSecurityLevelhasbeendefinedonthebasisofaEuclideandistanceamongmatricesandsomereference levels.This functiongivesanumerical result to thesecuritybutcanbeeasilyappliedtodifferentsub-treesoftheCAIQinordertohelptheEnd-usertovisualizetheweaknessesandstrengthsofdifferentproviders.

8.1.2 EvaluatingSLAofferswiththeREMIn order to completely use the REM to evaluate SLA offers represented according to theproposed conceptual model, we need to pre-elaborate the SLA offers in order to extractinformationfortheevaluation.

AccordingtotheproposedSLAmodel,anSLAoffercontainsthefollowinginformation:• Target Service and Resource providers, i.e., the service offered to EUs and the

resources/servicesrequestedtoExternalCSPs.• SecurityCapabilities,i.e.,thesetofsecuritycontrolsassociatedtotheservicewhichcan

begrantedtotheEU.• SecurityMetrics, i.e., the quantitative values used tomonitor the enforcement of the

securitycontrols.• SLOs,i.e.,theobjectives,expressedwithrespecttosecuritymetricvaluesthatmustbe

respectedtogranttheSLA.

Furthermore,intheproposedmodelthesefieldsareenrichedwithanimportanceattributetospecifyweights,i.e.whichcontrols,metrics,andSLOsareconsideredmorerelevantfromtheEU’sperspective.Suchattributesareextremelyusefulinthenegotiationphase,becausetheyhelptheEUintheselectionofanSLAOffer.Indeed,anSLOmustberespectedindependentlyfromitsimportancevalue.

InordertoapplytheREMmethodology,weneedarepresentationoftheSLAasatree.InD2.2.1weintroducedtheSLAHierarchytotransformtheSLAsintreesthattheproposedmethodologyis able to evaluate. TheGlobal Security Level associated to the root node of the tree is thequantitativeevaluationassociatedtotheSLAoffer.

InthecaseoftheREMmethodology,thecomparisonamongdifferentoffersismeaningfulonlyifthetreestructureisthesame(i.e.wecancomparetwoSLAoffersonlyiftheycontainexactlythesamenumberofnodesandonlythevalueoftheleavesaredifferent).

Figure15graphicallyillustratestheprocesstotransformaSLAOffer,representedaccordingtotheproposedSLAmodel,intoaSLA(tree)hierarchy,asintroducedinD2.1.2,toenableaclearevaluationoftheSLA.



45

SLAOffer

ServiceDescriptionTerm GuaranteeTerms

Resouerces Capabilities SLO SLO

Metric MetricCapability Capability

ControlID ControlID ControlIDControlID

CSP1 CSP2

Resource

reference

SLAHierarchy

ControlFamily1 ControlFamilyN

ControlID ControlID ControlID ControlID

... ......SLO SLO

Figure 15. From SLA Offers to SLA Hierarchy Thedifferencebetweenthetwoformatsisgivenbythedifferentusagecontext:oneaimsatautomating the process of SLA management (SLA offers), the other focuses only on theevaluation.ItisimportanttooutlinethateachSLAofferhasonlyoneExternalCSPthathoststargetservicesandresources(wealwaysassumeasinglecloudprovider,multicloudapplicationareoutofourscope).TheCSPofferingresourcesmayhaveitsownsecurityfeaturesthatshouldbetakenintoaccountandtheSTARrepositorycontainsaverywidesetofsuchdeclarationsfrommanyEuropeancloudproviders.Finally,theapproachweadoptedforSLAoffersevaluationisverysimpleandtakesintoaccountboth the selected CSP hosting the target service, through its CAIQ available in the STARrepository,andthespecificServiceLevelObjectives.AsillustratedinFigure16,welocateandretrievefromeachSLAoffertheCAIQassociatedtotheCSP(wehaveinthiswayasharedtreethatoutlineswhicharethecontrolsthataregranted



46

bytheexternalCSP).NotethattheyaredeclaredbyaenexternalCSPandtheSLAofferdoesnotofferanyconcretegrantontopofthemso,forthis,inthenegotiationwejustgivesupporttochoosetheCSP.

CSPCAIQ

SLAOffer





CSP

Resource

reference

CAIQ/CCM



Figure 16. Extract the CAIQ from the SLA Offer

AsasecondstepweextracteachcapabilityfromtheSLAOffer,inordertoknowwhicharetheadditionalcontrolsthatweareabletoenforcethroughtheSPECSsecuritymechanisms.



47

CSPCAIQ

SLAOffer





CSP

Resource

reference

CAIQ/CCM



Capability

ControlIDControlID

Figure 17. Capability extraction from an SLA offer ThefinalresultisthatweareabletogenerateanewCAIQ,whichrefers,thistime,nottotheexternalCSP,buttoSPECSasproviderofthespecificservice.



48

Figure 18. Generation of the SPECS CAIQ Wecan finallyusetheREMevaluationtechniquetoevaluateandcomparetheSPECSCAIQsassociatedtothedifferentSLAoffers.

8.2 FuzzylogicbasedsecurityassessmentofSLAsThe conceptualmodel defined to represent SLAs (as described in section 4), considers thespecification of EUs’ security requirements by defining levels of importance in the form ofweights. To encourage the smooth adoption of SPECS services by EUs, we took intoconsiderationtheEUs'desiretoexpresstheirgeneralrequirementsorimprecisepreferencesinnaturallanguagephrases(forexample,toonlyassignacertainlevelofimportancetoasetofoffered features). Most of the used security assessment techniques require EUs to providedetaileddescriptionoftheirrequirementsandsubmitstaticweightstomodeltheirpriorities[1][2][3][5][6],whichrequireexpertknowledgeandaretimeconsuming.Inaddition,itisalsodifficult forsomeEUs todeterminesecurityrequirements inaccuratevalues. In lightof theabove,itisbecominganimportantissueforbothCSPsandEUstobeabletomakedecisionsregardinghowtoassessandrankSLAswithrespecttoEUs’uncertainrequirements.

InthissectionwespecifyaquantitativereasoningapproachtocloudSLAsthatfacilitatesthefollowing:

1. Assessment,comparison,andrankingofvariousSLAsbyusinganassessmenttechniquetoidentifytheonethatbettermatchtheEU'ssecurityrequirements.Thisassessmenttechniqueisbasedonthefuzzyanalytichierarchyprocess(fuzzyAHP).

2. Submission and specification of EU’s requirements and preferences using naturallanguagephrasesandlinguisticdescriptorsatvariouslevelsofsecurityservices,-thusallowingbothnoviceandexpertEU’stoprovidetheirsecurityrequirementsaccordingtotheirexpertiseandspecificoruncertainneeds.



49

3. CaptureEU’s subjective requirements throughemployingmembership functions thatuseafuzzyinferencesystemtoderivetheEUs’requiredsecuritylevels.

TheSLAoffersareconstructedasaSLAhierarchyasdescribedinSection4.ThishierarchicalstructureallowsEUstohavetheabilitytospecifytheirsecurityrequirements(accordingtotheirexpertise)atdifferentlevelsoftheSLAhierarchy.TheresultscanbeusedtoprovidewithagraphicalinterfacethatEUscanusetoanalysetheresultsoreventoobtaintherequiredSLAs.InSPECS,thecomparisonismadetoprovidearankingthatsortsSLAoffersaccordingtoEU’srequirements.Figure19illustratesthegeneraloverviewofthemethodology.Therearetwomajorsteps.Thefirst step captures EUs’ descriptive requirements. The second step computes quantitativevalues for SLA offers based on their security levelsmeasured according to the EU securityrequirements.Themain stepsareperformed inprogressive stages, as shown inFigure19. InStageA,wereceivetheEU’srequirementsaswellastheSLAoffers.InStageBweaddressthesecurity-levelquantificationthatisassociatedwitheachSLAoffer,thenweusethisdatatoserveasaninputtotherankingalgorithmbasedonfuzzyAHPinStageC.

1

32

ResultingrankingofSLAoffers

StageB.QuantifythesecuritylevelassociatedwitheachSLAoffer

StageA.DefineEUandprovidersSLAoffersEU

requirementsSLAs

StageC.Securityevaluation1.Hieraticalstructure

2.Comparisonmatrices

composition

3.Weightsassignment

4.SLOsaggregation

SLAoffersInput

1

32

Rankingresults

EU

SLAoffersEvaluationRequirements

SLAoffers

SupplyChainManager

SupplyChainManager

Figure 19. Fuzzy QHP: Methodology stages

StageA.SLAsrequirementsspecificationFuzzy-QHP transforms the SLA offers into a hierarchical structure as shown in Figure 20.FollowingtheSPECsnegotiationprocess,EUs’willbeprovidedwithasetofSLAoffers thatincludeSPECSservicesthatfulfilwiththeirsecurityrequirements.CSPscontrollevelsarealsoselectedandusedtorankSLAoffers.InSPECSEUsareprovidedwithCSPscontrolswhiletheFuzzy-QHPisabletohandlealsoSLOvaluestorankSLAs.Withthehierarchicalstructurebuiltfor the fuzzy-QHPmethodology, EUshave the ability to specify their security requirements(accordingtotheirexpertise)atvariedlevelsoftheSLArepresentation(forexample,theEUcanspecifyhisrequirementsnotonlyat thecontrolgroup levelbutalsoat theSLOlevelorboth).Forthesakeofcompletionwewillprovideadescriptionofthefuzzy-QHPmethodologyconsideringthecompleteSLAhierarchyasdepictedinFigure20.



50

CloudSecSLA

Category1

Category2

ControlGroup1

SLO1.1.1

ControlGroup3

ControlGroup4

ControlGroup2

SLO1.1.2

SLO1.2.1

SLO1.2.2

SLO3.1.1

SLO3.1.2

SLO4.1.1

Weigh

tsWe

ights

Controlcategorylevel

Rootlevel

Controlgrouplevel

SLO2.1.1

SLO2.1.2

…

SLOlevel

Control1.1

Control1.2

Control2

Control3

Control4

Weigh

ts

Weigh

ts

Weigh

tsWe

ights

Weigh

ts

Controls

Figure 20. Cloud SLA hierarchy using fuzzy based QHP

Thishierarchycanbeusedintwodifferentways:ononehand,asmentionedbefore,itcanbeusedtorepresentSLAoffersbydefiningSLOsatthelowestlevelofthehierarchy.Ontheotherhand, theSLAhierarchycanalsobeusedtodefineEUs’requirementsbyrepresentingtheirrelativeimportanceatdifferentlevelsofgranularity.Thefuzzy-QHPmethodologysupportstwotypesofEUsecurityrequirements:(a)qualitative,whicharemodelledas fuzzynumbersor(b)quantitative,whichareassignedasvalues.Forfurtherexplanation,weprovidetwoexamplesattheSLOlevel:anSLOfor“TLSCryptographicStrength”,whichiscomposedof8possiblevaluesaccordingtotheECRYPTIIrecommendations20125{level1, level2,… , level8},suchthat level8 isbetterthanlevel1.Thesemetricsarethenmodelledasfuzzynumbers.ForanSLOwithtwometricsdefinedusingyes/no(asinthemetric“Penetrationtestingactivated”),themetricsarespecifiedasBooleantrue/falseandmodelledasfuzzynumbers.BlendedsubmissionofdifferenttypesofrequirementsforthesameSLAofferisalsosupportedinthismethodology.StageB.FuzzysecurityrequirementsquantificationToassessandcomparethesecuritylevelsprovidedbydifferentSLAoffersaccordingtotheEUs’fuzzy security requirements, themeasurementmodel fordifferent security SLOs isdefined.Fuzzy requirements are represented by membership functions μ, which translate thevaguenessandimprecisionofEUs’requirementsaccordingtotheirsecurityexpertise.In this study, the triangular fuzzy numbers (TFNs) are used to represent the fuzzyrequirements.TFNsareusedintheliteraturetocapturethevaguenessoftheparameters.ATFNisgraphicallyshowninFigure21,wheretheTFN!isrepresentedas(l,m,u),l<m<u,inwhich the parameters l,m, andu respectively denote the smallest possible value, themostpromisingvalue,andthelargestpossiblevaluethatdescribethefuzzyevent(i.e.,whenl=m=u,thefuzzynumberbecomesarealnumber).Thus,afuzzynumber!onthesetofrealnumbers5http://www.keylength.com/en/3/



51

RisdefinedasaTFNifitsmembershipfunction#$ % ,#:R→[0,1],whereasxisanypositiverealnumberandl<m<u,isequalto(asshowninFigure21):

1

0 xl m u

MµM(x)

Memb

ership

fn

Figure 21. Triangular fuzzy number

#$ % =

'()

*(), ,-. ≤ % ≤ 0,

1('

1(*, ,-0 ≤ % ≤ 2,

0,45ℎ789,:7.

(1)

This means a fuzzy set is specified as a TFN if (i) there exists only one element that themembershipfunction#$ % =1(atx=m)and(ii)#$ % isacontinuousfunction.Table8detailsthetermsusedinthisdescription.

Term Definition

k= Security SLO i, such that i∈{1,2,....,j}, where j is the number of SLOs. SLAG SLA offer j, such that j∈{1,2,....,n} , where n is the number of SLA offers.

VG,= Value of SLO k= provided by SLAj, which is defined as TFN (li, mi, ui) using its membership function µKL,M x .

VOP,= EU’s required value of SLO k= defined as TFN.

SLAQ,= SLAR,= Indicates the relative rank of SLAp over SLAq regarding SLO k=, such that p and q∈{1,2,....,n}, where n is the number of SLAs and p≠q.

STUV,W XYW Indicates the relative rank of SLA1,i over EUi, which specifies if SLA1 satisfies EU requirements, with respect to k=.

Table 8. Definition of terms used in the fuzzy QHP TherelationshipbetweenSLAoffers(orSLAoffersandEU)withrespecttosecuritySLOk=withvaluesZ[,W andZ\,W isrepresentedasaratio:

SLAV,W SLA],W = ZV,W/Z],W (2)

suchthat

SLAV,= SLA],= =1, 1, 1 , VV,= ≡ V],=

lV],mV], uV] , otherwise

where

lV]=klmn,mV] =

ol

onanduV] =

mlkn.

ThefollowingexampleillustratesthesecurityrequirementquantificationusingTFN.ConsideranSLO, termedask1,specified inStageA, that iscomposedof threemetricsvalues thatare



52

defined using the notion of security levels (level3, level2, level1). These security levels arerespectivelymodelled as fuzzy numberswhich are calculated as TFN as shown in Table 8.Consider twoSLAs, SLA1andSLA2providingSLOk1with level3 and level2 respectively.ThismeansSLA1andSLA2areofferingk1withvaluesZV=3≡level3andZ]=2≡level2.Moreover,theEUrequireslevel3regardingSLOk1sothatZ1=3≡level3.Thus,usingEquation2andthetermsdefined inTable1, therelativerankofSLA1overEUisdefinedas:SLA1/EU=3/3=(1,1,1).Therefore,SLA1issatisfyingtheEUrequirement.Moreover,therelativerankofSLA2overEUisdefinedas:SLA2/EU=2/3.

StageC.Securityevaluationbasedonfuzzy-AHPIntheconventionalAnalyticHierarchyProcess(AHP),thepairwisecomparisonsforeachlevelwithrespecttothegoalofthebestalternativeselectionareconductedusinganine-pointscale.However, according to [9]: (1) The AHP method is mainly used in nearly fixed decisionapplications,(2)theAHPmethodcreatesanddealswithaveryunbalancedscaleofjudgment,(3)theAHPmethoddoesnottakeintoaccounttheuncertaintyassociatedwiththemappingofone’s judgment to a number, and (4) the subjective judgment, selection, and preference ofdecisionmakershavegreatinfluenceontheAHPresults.Furthermore,itisalsorecognizedthatthehumanassessmentofqualitativeattributesisalwayssubjective.Generally,itisimpossibletoreflect thedecisionmakers’uncertainpreferencesthroughfixedvalues.Therefore, fuzzy-AHPistorelievetheuncertaintyandinabilityoftheAHPinhandlinglinguisticvariables.Thefuzzy-AHPapproachallowsamoreaccuratedescriptionofthedecision-makingprocess,wherefuzzysettheoriesareusedtoexpresstheuncertaincomparisonjudgmentsasfuzzynumbers.There are several procedures to attain CSPs ranking in fuzzy-AHP, in this deliverable themethodology of fuzzy-AHP based on Chang’s extent analysis [10] is utilized (Appendix IIprovidesthedetailsofthismethodology).Theproposedsecurityevaluationmethodconsistsoffourmainphases,asshowninFigure19.Phase1.Structuringdecisionhierarchy.SimilartoconventionalAHP,thefirststepistobreakdownthecomplexdecision-makingproblemintoahierarchicalstructure.TheSLAoffersareconstructedasahierarchicalstructureasspecifiedinStageAandrepresentedinFigure20.ThehierarchicalstructuredefinesthestructureofcloudSLAsfromthehighestlevel(theRootlevel,whichdefinesthemaingoalandaimstofindtheoverallrank)tothelowestlevel(thecontrollevel).Phase2.Linguisticweightsassignment.InordertocomparetwoSLAoffers’securitySLOs,therelativeimportanceleveloftheEU'srequirementsforeachsecuritySLOshouldbeassignedasweights,asshowninFigure20.WeutilizelinguistictermstospecifytheimportanceofeachSLOandtheuncertaintyoftheEUneeds,asshowninFigure22andTable9.Thus,noviceEUscanassignlinguistictermsattheControlcategorylevelorattheControlgrouplevelwithoutspecifying the lowest level attributes (which requires an extremelyhigh level of expertise).Furthermore,inordertoletEUsadoptcloudservices,itwouldbedesirabletoletthemexpresstheirgeneralrequirementsorpreferencesinadescriptivemanner.Toaddressthisissue,weconsidertheassignmentoflinguistictermsbyEUs.EUscanassignfuzzylinguistictermsasweightstoindicatetheirpriorities.Thenumberofpossibletermsdependsonthelevelofaccuracyrequiredfortheanalysis.AgreatnumberoflevelswillresultonamoreaccurateanalysisbutwillforcetheEUtobemoreprecisewhendefininghispreferences.Forthecurrentdescriptionwewilluseaseven-levelscaleasfollows:Extremely-Important(EI),Highly-Important(HI),Important(I),Low-Important(LI),Not-Important(NI),Not-Required(NR),andDo-not-know(Dk).TheselabelsdefineuncertainrequirementsoftheEUs,andare



53

representedasTFNs,asshowninFigure22andTable9.TheproposedframeworkallowstheEUs to: (i) assign linguisticweights at varied levels of thehierarchical specification, and ii)individuallyadjust the linguistic termsaccording to their requirements.To furtherease thetask,especiallyfornoviceEUs,thesystemcansetdefaultvaluesforeachlinguisticrequirement,accordingtothespecifiedSLOspecifiedinFigure22andTable9.Extremely-ImportantdenotesthatallsecuritySLOsaremandatoryrequirementsfortheEU.Not-Required(NR)indicatesthatthesecuritySLOsarenotrequiredbytheEU.Not-Important,Low-Important, and Highly-Important specify the EU’s different degrees of requirementsimportancewheretheEUcanacceptvariedvaluesspecifyingseveraldegreesof importancethatdependontheconsideredscale.Do-not-knowspecifiestheEU’sunknownrequirements.Inourmodel,werepresentDo-not-knowasTFNthatcanhaveallpossiblerangesfrom1to9thuswedefineditas(1,5,9),whichmeansthemostpromisingvalueis5,thatistheordinateofthehighestintersectionpointbetweenLow-ImportantandImportant.

1

0

LowImportant

HighImportant

ImportantNotImportant

1

ExtremelyImportant

3 5 7 9

Mem

bersh

ipfn

x

µM(x)

Figure 22. Linguistic terms for criterion importance

Linguistic scale for importance

Fuzzy numbers

Membership function

Domain TFN (l, m, u)

Not-Important (NI) 1 #$ % =3 − %

3 − 1 1≤x≤3 (1, 1, 3)

Low-Important (LI) 3 #$ % =

% − 1

3 − 1

1≤x≤5 (1, 3, 5) #$ % =

5 − %

5 − 3

Important (I) 5 #$ % =

% − 3

5 − 3

3≤x≤7 (3, 5, 7) #$ % =

7 − %

7 − 5

High-Important (HI) 7 #$ % =

% − 5

7 − 5

5≤x≤9 (5, 7, 9) #$ % =

9 − %

9 − 7

Extremely-Important (EI) 9 #$ % =% − 7

9 − 7 7≤x≤9 (7, 9, 9)

Do-not-know (Dk) 4 #$ % =

% − 1

5 − 1

1≤ x ≤9 (1, 5, 9) #$ % =

9 − %

9 − 5

Table 9. Linguistic variables describing weights of the criteria and values of ratings



54

Phase3.Pairwisefuzzycomparisonmatrices.Theprocessofmodellingvaluestoaquantitativemeaningfulmetricdenotingthespecifiedsecuritylevelisnotstraightforward,asSLOscanhavevarious types of values. Therefore, we used a relative-ranking model based on a pairwisecomparisonmatrixofsecuritySLOsprovidedbydifferentSLAoffersandrequiredbyEUsusingTFNs. Thus, pairwise comparison judgments are represented by triangular fuzzy numbersindicatingtherelativerankbetweentwoprovidersoraproviderandaEUsuchthatxij=(lij,mij

,uij),whereaslij=)y)z,mij=

*y

*z,anduij=

1y1z(cf.Equation2).AsintheconventionalAHP,usinga

comparisonmatrixU=xijforeachSLAandtheCSC,weobtainaone-to-onecomparisonofeachSLAandEUforaparticularSLO.Thiswillresultinacomparisonmatrixofsize(n+1)x(n+1)ifthereisatotalofnCSPsandoneEU.Suchthatxij=

V

{zy=

V

1zy,V

*zy,V

)zy

A=12…nn+1

1 2 … n n+1aVV aV]a]V a]]

⋯aV�a]�

aVma]m

⋮ ⋱ ⋮a�V a�]amV am]

⋯a�� a�mam� amm

Wherex12=SLA1/SLA2,whichindicatestherelativerankofSLA1overSLA2asindicatedinTable9,sothat:

A=

SLAVSLAV…SLA�EU

SLAV SLAVSLA] SLAV

⋯SLAV SLA� SLAV EUSLA] SLA� SLA] EU

⋮ ⋱ ⋮SLA� SLAVEU SLAV

⋯SLA� SLA� SLA� EUEU SLA� EU EU

(3)

Next,therelativerankingofalltheSLAoffersandtheEUforaparticularSLOarecalculatedasapriorityvector(PV)ofthefuzzycomparisonmatrixU.ThePVindicatesanumericalrankingofprovidersthatspecifiesanorderofpreferenceamongthem,asindicatedbytheratiosofthenumericalvalues.ThereareseveralprocedurestoattainPVinfuzzy-AHP.ThemethodologybasedonChang’sextentanalysismethod[10]istheoneutilizedinthepresentedmethodology.ThePVisoftheform:

ÑZ[y = ÖVÖ] …ÖÜÖ1 ,(4)whereNi,i=1,2,…,n,isanumericalvaluerepresentingtherelativerankoftheSLAiandwithrespect to the EU regarding an SLO ki. Similarly,Nu is the relative rank of the EU requiredsecuritylevelwithrespecttothesecuritylevelsofferedbytheSLAoffers.Phase4.SLOsAggregation.Inthefinalphase,wefollowupwithabottom-upaggregationtogiveanoverallassessmentofthesecuritylevelsandafinalrankingoftheSLAoffers.Toachievethat,thepriorityvectorofeachSLO(Phase3)isaggregatedwithitsrelativenormalizedweightassignedinPhase2.ThisaggregationprocessisrepeatedforallSLOsinthehierarchywiththeirrelativeweights,whichresultsintherankingofallthecloudprovidersbasedonEU-definedrequirementsandweights:



55

ÑZ{ââäãâ{åãç = ÑZ[l …ÑZ[é (9W)(5)HerewiistheEU-assignedweightsofcriteriaiandPVkiisthepriorityvectorcalculatedforSLOki, i=1,2,…, n. The methodology presented in this section is validated using a case studypresentedinAppendixIV.



56

9. Conclusions ThisdocumentreportsthefinalresultswithrespecttotheconceptualframeworkfortheCloudSLAnegotiation.Themaintargetof thisdeliverable isT2.3 that implements thenegotiationcomponents and processes designed. The results of this deliverable will also be used indedicatedWP1,WP4,andWP5activities,andprototypesdeliveredatM24andM30.This deliverable reports the following results (and the evolutionwith respect to the initialreportD2.2.1):

• The final version of the Negotiation module architecture, including the negotiationcomponents(implementedinT2.3)andthehighlevelinterfacesthatarethebasisfortheAPIsthatarecompletelydefinedinT1.3.ThoughthebasicsofthearchitecturehavenotchangedwithrespecttoD2.2.1,theinterfacesandrelationshipwiththerestofthemodulesoftheSPECSframeworkhavebeendefinedinD2.2.2.

• The final version of the SLA specification. This is the basis for the definition of thecontentoftheSLAandtherelationshipamongtheelementsthatcomprisetheSLA.TheSLAisoneofthemaininformationstructuresusedinSPECS,sinceitisusedtodefinetheservicecommitmentssignedwiththeEU.ItisalsousedtotriggertheenforcementofthesecuritymechanismsincludedintheSLA(thatwillalsotriggerthemonitoringandremediationactivities).Thenewspecification reportedatM24 is compliantwith thelatestversionsofthespecifications(namely,theNISTRATAXandISO/IEC19086).ThemainchangescomprisetheintroductionofthecapabilityconceptandthedefinitionoftherelationshipbetweensecuritymetricsandSLOs.ThelatestconceptualmodelalsodefinestheelementsincludedintheSLA(includingalsonon-functionalpropertiessuchastheexpirationtimeofthesignedSLA).

• ThemachinereadablespecificationfortheSLA(basedonthelatestSLAspecificationreportedabove) is alsoprovided.The changeswith respect to themachine readableformat reported in D2.2.1 comprise the introduction of new elements (such ascapabilities)andproperties,whilethelanguageusedtorepresentit(WS-Agreement)isthesameasinD2.2.1

• Anewmetric catalogue that containsnewsecuritymetrics tobeprovidedbySPECSservicesanddevelopedduringthesecondyear(includedinthesignedSLA,enforceableandmeasurableinordertochecktheirfulfilment)andmetricsdevelopedinWP5fortheViPRservice(tobereportedinD5.3).Ofcourse,themetriccatalogueiscompliantwiththe latest specificationof the SLAs.Anonline versionof themetric catalogue is alsoavailable6asreportedinWP5.

• The final version of the negotiation process. The feedback from the implementationtasksandtheintegrationofactivitiesamongNegotiation,Enforcement,andPlatformarethemain sources thathavebeenused todesign thenewprocessas it is reported inD2.2.2.ThenewprocessdrawsalsofromthenewspecificationofSLAsandtheapproachto gather EU’s security requirements (defined in D5.1.3 as part of the SPECSApplication).

• Thefinalversionoftherenegotiationprocesses.AtM24twotypesofrenegotiationhavebeenidentifiedandD2.2.2reportsthedetailsofbothprocesses.Thenewrenegotiationprocesses are the result of the information received from the Enforcement module(especiallyinwhatregardsremediationandimplementationactivities).

• RedefinitionofthereasoningalgorithmsusedtorankSLAoffersduringthenegotiationprocess.Ononehand,D2.2.2detailshowtheREMmethodology(alreadyreported in

6SecurityMetricsCatalogueApplication:http://apps.specs-project.eu/specs-app-security_metric_catalogue/



57

D2.2.1)hasbeenappliedbyusingSLAmodelalsoreportedinD2.2.2.Ontheotherhand,theQHPmethodology(alreadyreported inD2.2.1)hasbeenrevised to include fuzzylogicinordertomanagetheuncertaintyofqualitativerequirements.



58

10. Bibliography [1] A.Taha,R.Trapero,J.Luna,andN.Suri,“AHP-BasedQuantitativeApproachforAssessing

andComparingCloudSecurity,”Proc.ofTrust,SecurityandPrivacy inComputingandCommunications,pp.284–291,2014.

[2] J. Luna, R. Langenberg, and N. Suri, “Benchmarking Cloud Security Level AgreementsUsingQuantitativePolicyTrees,”Proc.ofCloudComputingSecurityWorkshop,pp.103–112,2012.

[3] Casola,V.,Preziosi,R.,Rak,M.,&Troiano,L.(2005).AReferenceModelforSecurityLevelEvaluation:PolicyandFuzzyTechniques.J.UCS,11(1),150-174.

[4] O.Hussain, F.Hussainetal., “Iaas Cloud Selection using mcdm methods,” Proc. ofInternationalConferenceone-BusinessEngineering,pp.246–251,2012.

[5] S.Garg,S.Versteeg,andR.Buyya, “Smicloud:A framework forcomparingandrankingcloudservices,”Proc.ofUtilityandCloudComputing,pp.210–218,2011.

[6] F.Hussain,O.Hussainetal., “Towardsmulti-criteriacloudservicese- lection,”Proc.ofInnovative Mobile and Internet Services in Ubiquitous Computing, pp. 44–48, 2011.M.MenzelandR.Ranjan,“Cloudgenius:decisionsupportforwebservercloudmigration,”Proc.ofWorldWideWeb,pp.979–988,2012.

[7] J.Mendel,“Fuzzylogicsystemsforengineering:atutorial,”Proc.ofIEEE,vol.83,no.3,pp.345–377,1995.

[8] C.QuandR.Buyya,“Acloudtrustevaluationsystemusinghierarchicalfuzzyinferencesystem for service selection,” Proc. of Advanced Information Networking andApplications,pp.850–857,2014.

[9] G. Kabir and M. Hasin, “Comparative analysis of AHP and fuzzy AHP models formulticriteriainventoryclassification,”JournalofFuzzyLogicSystems,pp.1–16,2011.

[10] Y.Chang,“ApplicationsoftheextentanalysismethodonfuzzyAHP,”Europeanjournalofoperationalresearch,pp.649–655,1996.

[11] CloudSecurityAlliance, “TheConsensusAssessments InitiativeQuestionnaire,”Online:https://cloudsecurityalliance.org/research/cai/,2011.

[12] “Guidelines on information security controls for the use of Cloud computing servicesbased on ISOIEC 27002,” International Organization for Standardization, Tech. Rep.ISOIEC27002,2014.

[13] “Security and Privacy Controls for Federal Information Systems and Organizations,”NationalInstituteofStandardsandTechnology,Tech.Rep.NIST800-53v4,2014.

[14] “CloudServiceLevelAgreementStandardisationGuidelines,”EuropeanCommission,C-SIGSLA,Tech.Rep.C-SIGSLA2014,2014.

[15] “(Draft) Cloud Computing: Cloud Service Metrics Description,” NIST, Tech. Rep. NIST,2014.

[16] J.Luna,A.Taha,R.TraperoandN.Suri, “QuantitativeReasoningAboutCloudSecurityUsing Service Level Agreements,” IEEE Transactions on Cloud Computing. (to bepublished)

[17] “Cloud Security Alliance. Security, Trust & Assurance Registry (STAR),” Online:https://cloudsecurityalliance.org/star/,2011.

[18] “Cloud Security Alliance. Cloud Control Matrix”, Online:https://cloudsecurityalliance.org/group/cloud-controls-matrix/.2014

[19] V. Casola, A. Mazzeo, N. Mazzocca, and V. Vittorini, “A policy-based methodology forsecurityevaluation:Asecuritymetricforpublickeyinfrastructures,”JournalofComputerSecurity,vol.15,no.2,pp.197–229,2007.



59

AppendixI.ExampleofaspecificSLA:CyptoBruteForceResistanceThisappendixintroducesconcreteexamplesofadefinitionofasecuritySLAsthatfollowstheconceptualmodelpresentedinSection4.1.Theexamplestartswithacategoryandderivestheassociatedcontrols,SLOs,metricsandtheabstractmetrics.ThefollowingdiagramrepresentsthecompletesecuritySLAhierarchyoftheexample.

Figure 23. Example of a complete SPECS SLA hierarchy for an SLO

Applying the conceptual model described in Section 4.1 to the security SLOCryptoBruteForceResistance,thefollowingtabledetailstheattributesofeachelementoftheSecuritySLAhierarchy.

secSLO_CryptoBruteForceResistance Control Category

name: Encryption and Key Management referenceId: EKM controlFramework: CSA Cloud Controls Matrix v3.0 customerDefinedWeight: note: n/a

Security Control

name: Entitlement referenceId: EKM-01



60

customerDefinedWeight: Compensating Control

name: n/a referenceId: n/a customerDefinedWeight: n/a note: n/a

Security Service Level Objective

customerDefinedWeight: n/a objective: tls_crypto_strength_level ≥ M3_value note: expresses the strength of a cryptographic protection applied to a resource based on its key length, e.g. using the ECRYPT II security level recommendations or the FIPS security levels for encryption. This normalizing scale allows comparison of the strengths of different types of cryptographic algorithms.

Security Metric serviceLevel:

Table 10. Security SLO definition of CryptoBruteForceResistance

CMD_CryptoStrength_LA_ECRYPT of secSLO_CryptoBruteForceResistance Metric name: Cryptographic Strength of a protection mechanism - Low assurance assessment – EECRYPT II. referenceId: CMD_CryptoStrength_LA_ECRYPT note: this metric provides a low security assurance (high uncertainty) method to assess the cryptographic strength of a resource. Primary Abstract Metric name: Cryptographic strength of a protection mechanism referenceId: AMD_CryptoStrength Metric Rules name: Configuration-based assessment (Assessment method) referenceId: AMR_Assessment_CryptoStrength definition: The value associated to the parameter "Security Bits (Symmetric Equivalent)" is obtained by performing look up at the configuration/properties file. This assessment method is associated with a low security assurance (high uncertainty). note: A Concrete Metric MUST specify the assessment method Metric Parameters name: Security Levels (Security Bits Equivalent) referenceId: AMP_CryptoStrength definition: This parameter refers to the mapping between "security levels" and corresponding "security bits" note: The parameter must be specified in form of a list of couples ["security levels":"security bits"]

Table 11. Metrics definition for the security SLO CryptoBruteForceResistance

AMD_CryptoStrength of secSLO_CryptoBruteForceResistance Abstract Metric

name: Cryptographic strength of a protection mechanism referenceId: AMD_CryptoStrength unit: Security Level (1 … 8) scale: Qualitative expression: The cryptographic strength (security level) is computed based on the security bits defined by the underlying abstract metric "Symmetric Equivalent". For this purpose is used the



61

ECRYPT II mapping7 shown in following table: Security Level Security bits (symmetric equivalent)

1 32 2 64 3 72 4 80 5 96 6 112 7 128 8 256

For computing the “Security bits” associated to the cloud resource under evaluation, please refer to the underlying abstract metric definition below. definition: This abstract metric expresses the strength of a cryptographic protection applied to a resource based on its key length, using the ECRYPT II security level recommendations for encryption. Instead of using key lengths alone, which are not always directly comparable from one algorithm to another, this normalizing scale allows comparison of the strengths of different types of cryptographic algorithms. note: This metric is related to C-SIG SLA standardization guidelines' CR-1 (Cryptographic brute force resistance) SLO

Abstract Metric Rule Definitions

name: Assessment method. referenceId: AMR_Assessment_CryptoStrength definition: This rule defines how to assess/measure the strength of the cryptographic mechanism. Each assessment method can be associated with a different level of assurance. The following methods are possible {configuration_file_lookup,runtime_test} note: A Concrete Metric MUST specify the assessment method.

Abstract Metric Parameter Definitions

name: Security Levels (Security Bits Equivalent) referenceId: AMP_CryptoStrength definition: This parameter refers to the mapping between "security levels" and corresponding "security bits"

note: The parameter must be specified in form of a list of couples ["security levels":"security bits"] underlyingAbstractMetrics

name: Symmetric Equivalent referenceId: AMD_SymmetricEquivalent

Table 12. Abstract metric definition for the security SLO CryptoBruteForceResistance

7 ECRYPT II recommended key sizes (symmetric equivalent), please refer to Table 7.4 inhttp://www.ecrypt.eu.org/documents/D.SPA.20.pdf



62

AppendixII.FoundationsofFuzzyLogic:thefuzzyinferencesystemThefuzzyinferencesystem(FIS)isaprominentapplicationoffuzzylogicandfuzzysetstheory.FISisusedtosolvereasoningproblemsinuncertainenvironmentsduetoitsabilitytohandleinaccurate and imprecise inputs ([7] [8]).We further detail themain building blocks of asshowninFigure24:• Rules:areexpressedasacollectionofif-thenstatementsthatdefinetheinferencemodel,

e.g.,“Ifx1iswarmtheny1isquitelow”.Therulestructureis:ifantecedentthenconsequent,whereantecedentandconsequentarefuzzypropositions.Theseruleshelpinquantifyinglinguisticvariables(e.g.,x1mayhaveafinitenumberoflinguisticvariablesassociatedwithit,rangingfromextremelywarmtoextremelycold),byusingfuzzymembershipfunctions.AdditionallywecancombinemultiplerulesusingANDorORoperators.Thatis,whenthesystemisappliedtoaparticularsituation(agiveninput),allrulesarefiredin parallel (applied all at once to this given input), and for each rule its conclusion iscomputed. The computation takes into account the degree in which the antecedent issatisfiedinsuchawaythatifitisnotatallsatisfied,theconclusionistheemptyset.

• Membership function: defines to which degree the fuzzy element belongs to thecorrespondingfuzzyset.Itmapsspecificrealvaluestomembershipdegreesbetween0and1.Inafuzzyinferencesystem,eachinputandoutputvariablehasitsownsetofmembershipfunctions.

• Fuzzifier:comprisestheprocessoftransformingcrispinputvaluesintothemembershipfunctionstoobtaincorrespondingmembershipdegreesforeachfuzzyinputsets.

• Inferenceengine:definesthefuzzylogicoperatorsandhandlesthewayinwhichrulesarecombinedinordertoaggregatefuzzyoutputsets.

• Defuzzifier:mapstheaggregatedfuzzyoutputsetsintocrispvalues(usuallyanumericalvalue)usingtheoutputmembershipfunctions.Thisprocessiscalleddefuzzificationandcanbe seen as either an element selection froma set (in fact, froma fuzzy set), or a fusionprocess in which the information to be fused is the fuzzy set and the outcome is thenumericalvalue.

Outputmembershipfunctions

Inputmembershipfunctions

Fuzzyoutputsets

Crispoutputs

Fuzzifier Defuzzifier

InferenceCrispinputs

Fuzzyinputsets

Membershipfunctions

Rules

Figure 24. Fuzzy inference system.



63

AppendixIII.PrinciplesforhandlingfuzzyAnalyticHierarchyProcessesThefollowingappendixoutlinesChang’s[10]extentanalysismethodonfuzzy-AHP.Wewillexplain Chang’s method using an example of two TFNs (l1, m1, u1) and (l2, m2, u2), whichrepresentaprovidersecurity-levelandauserrequirementforaparticularSLO.Theprocessstartbycalculatingthecomparisonmatrix,

A=12…nn+1

1 2 … n n+1aVV aV]a]V a]]

⋯aV�a]�

aVma]m

⋮ ⋱ ⋮a�V a�]amV am]

⋯a�� a�mam� amm

,being xW\ =V

êyz=

V

mzy,V

ozy,V

kzy

Theresultingcomparisonmatrixfortheexampleis:

A=i=1i=2

j=1 j=2(1,1,1) (lV],mV],uV])

(l]V,m]V,u]V) (1,1,1)

AfterUcalculation,thestepsofChang’sextentanalysistoattainthePVaredetailedasfollows:Step1.Thevalueofthefuzzysyntheticextentwithrespecttoithobjectiscalculatedsuchthat:

S== lGoGëV , mG

oGëV , uG

oGëV ⊗

V

mìîïñl

,V

oìîïñl

,V

kìîïñl

(6)

Whereas⊗denotesfuzzymultiplication,i=1...n,andj=1...m.WeexplainthisstepusingthetwoconsideredTFNs’comparisonmatrixU(m=n=2)sothat:

SV= 1+lV],1+mV],1+uV] ⨂1

1+uV]+1+u]V,

1

1+mV]+1+m]V,

1

1+lV]+1+l]V

S]= 1+l]V,1+m]V,1+u]V ⨂1

1+uV]+1+u]V,

1

1+mV]+1+m]V,

1

1+lV]+1+l]V

Bytheendofthisstep,M1andM2willberepresentedasTFNwithvalues(l1,m1,u1)and(l2,m2,u2).Step2.ThedegreeofpossibilityofM2=(l2,m2,u2)≥M1=(l1,m1,u1)isdefinedasV(M2≥M1)=sup[min(μM1(x),μM2(x))](asshowninFigure25)andisrepresentedasfollows:

V(S]≥SV)=

1,ifm]≥mV

0,iflV≥u]

kl-mnon-mn ol-kl

,otherwise(7)

WheredistheordinateofthehighestintersectionpointDbetweenμM1andμM2(seeFigure25).ForthecomparisonweneedthevaluesofbothofV(S1≥S2)andV(S2≥S1).



64

Step3.ThedegreepossibilityforafuzzynumbertobegreaterthankfuzzynumbersSiwherei=1,2,...,kcanbedefinedby:

V S≥SV,S],…,Sö =V S≥SV , S≥S] ,…, S≥Sö =min V S≥S= i=1,2,…,k(8)

Assumingthatd'(Ai)=min(V(Si≥Sk)),fork=1,2,...,n;k≠i.ThenthepriorityvectorisgivenbyPV0=(d'(A1),d'(A2),...,d'(An))TwhereAi(i=1,2,...,n)arenelements.

1

0 xm2

µM(x)

u2l1 u1l2 m1

M2 M1

d

DV(M2)≥V(M1)

Figure 25. The intersection between M1 and M2 Step4.Vianormalization,thenormalizedpriorityvectorsarePV=(d(A1),d(A2),...,d(An))TwherePV is a non-fuzzy number that gives priorityweights of an attributewith respect to otherattributes.AttheendofStep4,weattainthepriorityvectorofthefuzzycomparisonmatrixforaparticularSLO.ThismethodisdoneforalltheSLOs’matrices.Afterthisstep,thepriorityvectorofeachSLOisaggregatedwithEU-assignedweights,asinPhase4.



65

AppendixIV.Fuzzy-QHP:acasestudyThisappendixwillvalidatetheproposedmethodologydescribedinSection8.2byapplyingittoasetofSLAsforagivenservice.Thecasestudywillassumeasecurewebserverservice.Accordingtothenegotiationprocess,thesupplychainmanagerwillprovidethereasonerwithasetofSLAoffersthatwillberankedaccordingtoEU’ssecurityrequirements.ThereasonerwillevaluatetheSLAoffersaccordingtotherequirementssetbothtothecontrolsimplementedbytheSPECSservicesandtothecontrolsimplementedbyCSPs.Inorder toshowthepossibilitiesof the fuzzy-QHPmodelwewillextend theCSPs’ securitycontrolsbyconsideringrequirementsattheSLOleveloftheSLAhierarchy(cf.,Figure20).Thiswillallowustoconsideralsorequirementsdifferenttoyes/noanswersasitusedinSPECSatthecontrollevel.Table13showstheSLAforeachSLAofferandtheEUs’requirementsforthetwousecases shown in thisappendix.FourSLAswillbe compared (SLA1,SLA2,SLA3,andSLA4),andeachSLAwillincludeadifferentCSP.ThecomparisonwillconsidertwoEU(EU1andEU2)withdifferentrequirementsanddifferentexpertise.AccordingtotheEU’sexpertiserequiringtheevaluation,thevalidationwillconsidertwocases:

• CaseI.TheSLAs(SLA1,SLA2,SLA3andSLA4)willbeevaluatedaccordingtoanexpertEU(EU1)givingadetailedspecificationoflow-levelrequirements(eitherlinguisticornumericalrequirements).

• Case II.TheSLAs(SLA1,SLA2,SLA3andSLA4)willbeevaluatedaccording toanEU(EU2) specifying linguistic weights at three different levels of granularity(correspondingtothehierarchyshowninFigure20)namelyControlcategory,Controlgroup,ControlsandSLOlevels.Thisisthecaseofacustomerhavingexpertknowledgeof only some controls (specified at the low level), no knowledge for other controls(specifiedattheControlcategorylevel),orspecifyingattheintermediatelevelaccordingtotheknowledgeshe/hehas.

Cloud SLA SLAs End users (EU) Control category

Control group

Control SLO SLA1 SLA2 SLA3 SLA4 EU1 EU2

Supply Chain Management, Transparency and Accountability (STA)

Data Quality and Integrity

STA-01 SLO1 level3 level4 level3 level4 level4 HI

Network / Infrastructure Services

STA-03 SLO2 level3 level4 level2 level4 level4

Data security and information lifecycle management (DSI)

Information leakage

DSI-05 SLO3 yes yes yes no yes Dk

Governance and risk management (GRM)

Data focus risk management

GRM-02 SLO4 no yes yes yes yes yes

Risk management framework

GRM-11 SLO5 level3 level3 level3 level3 level3 level3

Table 13. Fuzzy QHP case study: excerpt of SLAs and customer requirements InordertoevaluatetheSLAs’withrespecttothecustomer’srequirements,weproceedtoapplythefuzzyQHPmethodologypresentedinsection8.2.Forthecase-studycalculationswenotethefollowing:

1. LinguisticweightsarespecifiedasTFNasshowninTable9.



66

2. Numericalrequirementsarespecified,asTFNsuchthatyesandnoaredenotedas(79,9)and(1,1,1);similarly48,24,and12arecalculatedas(7,9,9),(5,7,9),and(3,5,7).Furthermore, levels 1, 2, 3, 4, and 5 are represented respectively using TFN by themembershipfunction#$ % = 1, 3, 5, 7, and9(asdefinedinTable9).

3. All CSPs’ security SLOs are normalized to the customer requirements to eliminatemasquerading.Themasqueradingeffecthappenswhentheoverallaggregatedsecuritylevelvaluesmostlydependonthosesecuritycontrolswithahigh-numberofSLOs,thusnegativelyaffectinggroupswithfeweralthoughpossiblymorecriticalprovisions.OthermethodologiesfortheCloudsecurityassessmentsufferfromthiseffect.

CasestudyI:ExpertEU1detailsrequirementsatthelowestlevelFor this case, the end user (EU) specifies his requirements at the lowest level of the SLAhierarchy(i.e.,SLOs)andconsidersthesamerelativeimportance(i.e.,weights)forallofthese.Forthe“SupplyChainManagement,TransparencyandAccountability(STA)”categorytherearetwocontrolscategories,whicharefurtherdividedintoanothercontrol(STA-01andSTA-03).EachcontrolhasoneSLO(SLO1forSTA-01andSLO2forSTA-03).ForSLO1theprovidersandtheEUcanspecifytheirmetricsfromlevel1tolevel5.UsingthedatashowninTable3,Equation2isusedtodefinetheSLO1pairwiserelationsuchthat:

Therefore,thecomparisonmatrixofSTA-01AúùûVis:

Then, using Chang’s extent analysis method explained in Appendix 1, we get the relativerankingoftheCloudprovidersforSLO1,whichisgivenbythepriorityvectorofAúùûV(PVSLO1).PVSLO1iscalculatedasfollows,usingStep1inAppendix1,wegetthevalueofthefuzzysyntheticextentforAúùü†Vsuchthat:



67

Afterwards,usingStep2wegetthedegreeofpossibilitysothat:

Then,thepossibilityforafuzzynumbertobegreaterthanotherfuzzynumbersiscalculatedusingStep3:

Similarlyd'(ASLA2),d'(ASLA3),andd'(AEU)arecalculatedusingSteps2and3:

Thus,theSLO1priorityvectorPVisgivenby:

ThisreflectswhichoftheSLAsprovidetheSLO1securitySLOrelativetootherSLAsandtothecustomerrequirements.Afternormalization,PVSTA-01is:

ThismeansthatbothSLA2andSLA4equallysatisfyEU’sSLO1requirement.However,SLA1andSLA3donotfulfilthatrequirement.Similarly,thepriorityvectorofSLO2iscalculatedusingits



68

comparisonmatrixAúùû].TheSTApriorityvectoristhenpremeditatedbyaggregatingPVSLO1andPVSLO2with customer-definednormalizedweights (wSTA)usingEquation5.As specifiedearlier,inCaseIthecustomerconsidersthesamerelativeimportance(i.e.,weights)foralloftheseSLOs,suchthat:

Therefore,

ThepriorityvectorforSLO3(belongingtothecontrolDSI-05)iscalculatedthesameway,suchthat:

ThismeansthatonlySLA4doesnotfulfilEUSLO3requirement.InasimilarwaythepriorityvectorsaggregatedforthecategoryGRM,PVGRM,is:

The SLAs rankings according to the customer requirements at the Control group level areshowninFigure26andatthecategorylevelareshowninFigure27.Finally,thepriorityvectorsofDSI,STA,andGRMareaggregatedtoobtainthetotalpriorityvector,asshowninFigure28.



69

Consequently,onlySLA2fulfilsthecustomer’srequirements,asshowninFigure26.Thatwasexpected,asSLA1isnotofferingSLO4andisunder-provisioningSLO1andSLO2.SLA3isnotfulfillingcustomerrequirementsforSLO1andSLO2.Moreover,SLA4isnotprovidingSLO3.OnlySLA2 fulfils customer’s requirements and, as a result, SLA2 is the best matching provideraccordingtothecustomer’srequirements,followedbySLA3,asshowninFigure26.

Figure 26. Aggregation at the SLO level regarding the customer’s Case I requirements

Figure 27. SLA’s comparison with respect to customer Case I requirements at the Control category level

Figure 28. The total aggregated security level with respect to customer requirements



70

CasestudyII:NonexpertEU2specifiesrequirementsanddifferentlevelsWeassumethecustomerspecifieslinguisticweightsattheControlcategorylevel,bydenotingHigh-ImportanttoSTA.Inadditionto,denotingDo-not-knowattheControlDSI.Andsimilarly,asCaseIthecustomerspecifieslow-levelrequirementsforGRM,asshowninTable13.SinceSTAisassignedEI,therespectiveweightissetto(5,7,9),whiletheDSIweightissetto(1,4,7).Therefore,PVSTA,PVDSIandPVGRMareweightsaggregatedsuchthat:

SinceDSIisassignedDk,therespectiveweightissetto(1,4,7),suchthat:

Similarly,GRMisevaluatedasexplainedinCaseI:PVSLO4andPVSLO5areaggregatedtoobtaintheGRMpriorityvector.

Finally, thepriorityvectorsofDSI,STA,andGRM areaggregated toobtain the totalpriorityvector.

Therefore,onlySLA2satisfiesthecustomerneeds,whereasallSLA1,SLA3andSLA4donotfulfilcustomerrequirements,asshowninFigure28.Thatwasexpected,asSTAishighlyimportanttotheEUandunderprovisionedbySLA3andSLA1.Moreover,SLO3isnotprovidedbySLA4.Thus, the presented framework can give accurate SLAs ranking even if the low level is notdefinedandvaguepreferencesarespecifiedatthehighestlevels,whichmeansacustomercandefineweightsatthehigherlevelsinsteadofansweringmultiplelow-levelquestions.

report on conceptual framework for cloud sla negotiation ... · secure provisioning of cloud...

Documents