Report on conceptual framework for Cloud SLA negotiation ... · Secure Provisioning of Cloud...
Transcript of 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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
Has remained thesame
SLANEG_R13 SecuritySLOshouldbemeasurableinthereal-world
ThesetofsecuritySLO’stobeconsidered by SPECS shouldbefeasibletoassess/measurein real-world clouddeployments.
Has remained thesame
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
Has remained thesame
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.
Has remained thesame
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
Has remained thesame
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
14
approach followed by NIST onits Cloud Adapted RiskManagement Frameworkshouldbefurtherexplored.
SLAPL_R14 SearchCSPSLA The SPECS SLA Platform mustallow other SPECS componentstosearchforasetofSLAsintheCSP SLA repository byspecifyingasetofsearchcriteria
Has remained thesame
SLAPL_R21 GetSLA The SPECS SLA Platform mustallow other SPECS componentsto get the reference to a SPECSSLAcontainedintheSPECSSLArepository.
Has remained thesame
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).
Has remained thesame
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.
Has remained thesame
SLAPL_R24 CheckSLA The SPECS SLA Platform mustallow other SPECS componentstochecktheformalvalidity(e.g.,formatting, digital signatureexpiration etc.) of an SLAcontained either in the SPECSSLArepositoryorintheCSPSLArepository.
Has remained thesame
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.
Has remained thesame
SLAPL_R27 CreateSLA The SPECS SLA Platform mustallow other SPECS componentstocreateaSPECSSLAdocument.
Has remained thesame
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
15
SLAPL_R33 SignSLA The SPECS SLA Platform mustallow the SPECS administratorandtheCSCtosignaSPECSSLA.
Has remained thesame
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
Has remained thesame
SLAPL_R35 Generatealert TheSPECSSLAPlatformmustallow other SPECScomponents(belongingtotheMonitoring module) togenerate an alert to warnabout a possible incomingSPECSSLAviolation.
Has remained thesame
SLAPL_R36 Detect violation TheSPECSSLAPlatformmustallow other SPECScomponents(belongingtotheMonitoringmodule)todetecta SPECS SLA violation whentheguaranteedrequirementsarenolongerfulfilled.
Has remained thesame
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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]
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
24
Figure 4. SLA machine-readable format model
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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/
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SC-12 EKM-03 TLS Security
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.
SC-8 EKM-03 TLS Security
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
SC-29 EKM-03 TLS Security
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
CA-7, RA-5 TVM-02 Software Vulnerability Assessment
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
CA-7, RA-5 TVM-02 Software Vulnerability Assessment
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.
BCR-09 SC-6, SI-17 Availability
3http://www.specs-project.eu/solutions-portofolio/vipr/
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
29
Max Native Continuous Copies
The maximum number of continuous copies for a virtual pool
BCR-09 SC-6, SI-17 Availability
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
IVS-09 SA-2, CM-2 Performance
System Type Supported system type for the virtual pool
IVS-09 SA-2, CM-2 Performance
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.
BCR-09 SC-6, SI-17 Performance
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
BCR-01 SC-6, SI-17 Availability
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.
BCR-09 SC-6, SI-17 Performance
Table 7. Metrics developed in WP5
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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).
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
34
Figure 7. High level sequence diagram for the negotiation process
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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).
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
38
Figure 9. Renegotiation process triggered by CSPs
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
40
Figure 11. Renegotiation process triggered by an EU
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
46
bytheexternalCSP).NotethattheyaredeclaredbyaenexternalCSPandtheSLAofferdoesnotofferanyconcretegrantontopofthemso,forthis,inthenegotiationwejustgivesupporttochoosetheCSP.
CSPCAIQ
SLAOffer
ServiceDescriptionTerm GuaranteeTerms
Resouerces Capabilities SLO SLO
Metric MetricCapability Capability
ControlID ControlID ControlIDControlID
CSP
Resource
reference
CAIQ/CCM
ControlFamily1 ControlFamilyN
ControlID ControlID ControlID ControlID
Figure 16. Extract the CAIQ from the SLA Offer
AsasecondstepweextracteachcapabilityfromtheSLAOffer,inordertoknowwhicharetheadditionalcontrolsthatweareabletoenforcethroughtheSPECSsecuritymechanisms.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
47
CSPCAIQ
SLAOffer
ServiceDescriptionTerm GuaranteeTerms
Resouerces Capabilities SLO SLO
Metric MetricCapability Capability
ControlID ControlID ControlIDControlID
CSP
Resource
reference
CAIQ/CCM
ControlFamily1 ControlFamilyN
ControlID ControlID ControlID ControlID
Capability
ControlIDControlID
Figure 17. Capability extraction from an SLA offer ThefinalresultisthatweareabletogenerateanewCAIQ,whichrefers,thistime,nottotheexternalCSP,buttoSPECSasproviderofthespecificservice.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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/
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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:
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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/
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
57
D2.2.1)hasbeenappliedbyusingSLAmodelalsoreportedinD2.2.2.Ontheotherhand,theQHPmethodology(alreadyreported inD2.2.1)hasbeenrevised to include fuzzylogicinordertomanagetheuncertaintyofqualitativerequirements.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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).
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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:
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
67
Afterwards,usingStep2wegetthedegreeofpossibilitysothat:
Then,thepossibilityforafuzzynumbertobegreaterthanotherfuzzynumbersiscalculatedusingStep3:
Similarlyd'(ASLA2),d'(ASLA3),andd'(AEU)arecalculatedusingSteps2and3:
Thus,theSLO1priorityvectorPVisgivenby:
ThisreflectswhichoftheSLAsprovidetheSLO1securitySLOrelativetootherSLAsandtothecustomerrequirements.Afternormalization,PVSTA-01is:
ThismeansthatbothSLA2andSLA4equallysatisfyEU’sSLO1requirement.However,SLA1andSLA3donotfulfilthatrequirement.Similarly,thepriorityvectorofSLO2iscalculatedusingits
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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
SecureProvisioningofCloudServicesbasedonSLAManagement
SPECSProject–Deliverable2.2.2
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.