Cloud security del 3 - risikovurderingen

I teorien har brugerne ingen interesse i de tekniske systemer eller processer der benyttes i en Sky. Så længe man har fuld adgang til de rigtige data indenfor de fastsatte servicemål er man principielt tilfreds.

Cloud sikkerhed i praksis
Men i praksis det selvfølgelig ofte kritisk med detaljeret information om løsningen, for at kunne vurdere både sikkerheden - og om man tror på en leverandør kan opfylde de nødvendige servicemål.

Noget af det der i fremtiden vil adskille "Discount-Clouds" fra troværdige Cloud-leverandører vil være hvor meget information om sikkerheden, der vil være tilgængelig for kunderne.

Cloud Security del 1 og del 2 lagde grundlaget for at kunne vurderer sikkerheden i en Cloud løsning.
Vi går nu skridtet dybere og ser hvordan modellen fra del 1 kan bruges i praksis.

Data klassifikation
Første skridt er at klassificere den data og de forretningsprocesser, der indgår i den løsning man overvejer at Cloudsource (outsource til en
Cloud-leverandør). Der findes en række forskellige teknikker til at indsamle og klassificere informationen, som jeg ikke vil komme nærmere ind på her.

Afklaringerne fra dataklassifikationen bruges efterfølgende i risikovurderingen. Og jo mere kritisk den applikation eller de data man overvejer at lægge ud i Skyen er, jo flere krav skal man selvfølgelig efterfølgende stille, før en potentiel Cloud-løsning er sikkerhedsmæssigt acceptabel.


Risikovurdering
Spørgsmål man bør starte med at stille kan f.eks. være

1. Er vi underlagt lovkrav?
Hvis man er underlagt f.eks. Persondatalovgivningen eller Bogføringslovgivningen giver det selvfølgelig en række krav, der skal kunne håndteres af en mulig løsning.

2. Er der compliance hensyn at tage hensyn til?
Hvis relevant giver SOX, Euro-SOX, PCI osv en række andre krav, der skal kunne adresseres af den valgte løsning.

3. Hvilken sikkerhedsmodel benytter vi normalt?
DS484/ISO 27002 osv giver input til krav om bl.a. beredskabsplaner og håndtering af sikkerhedshændelser, både internt og hos den potentielle leverandør.

4. Vurdering af Cloud-løsningen på baggrund af SPI-aaS:

SPI-modellen ovenfor er meget effektiv til at afklare hvilke sikkerhedsområder der skal fokuseres på for en specifik Cloud-løsning. Herunder hvilke områder leverandøren har ansvar for, hvordan de håndteres - og hvad det forventes, at man selv håndterer.

I en PaaS-løsning skal man f.eks. måske selv sørge for alle sikkerhedsopdateringer, mens man normalt aldrig har mulighed for at opdatere noget - overhovedet - i en SaaS-løsning.

Lad os se på eksempler på de forskellige niveauer:

1) Infrastruktur
Afhængig af hvor kritisk den proces, applikationen eller data man overvejer at ligge ud i Skyen er, kan man f.eks. se nærmere på følgende hovedområder for en IaaS-løsning.

Den fysiske placering af datacenter
Persondataloven eller bekymringer om lokale lovkrav, f.eks. risiko for electronic discovery, eller at udenlandske regeringer udleverer materiale til lokale konkurrenter kan påvirke krav til hvor et datacenter kan være fysisk placeret.

Nogle Cloud-leverandører giver mulighed for at vælge regioner eller ligefrem specifikke datacentre som kunden kan ønske at bruge. Hvis placeringen er meget kritisk bør man nærlæse kontrakten for at bestemme leverandørens mulighed for at flytte data til andre datacentre.
Vær opmærksom på teknikker som VMotion/XenMotion, der gør det muligt at flytte virtuelle maskiner mellem forskellige datacentre.

Fysisk sikring af datacenter
Det er muligt at undersøge og vurderer alle standard kravene til et datacenter: skalsikring, overvågning - fra vagter og kamera til alarmsystemer, adgangskontrol, hvordan adgang er begrænset osv.

Hardware
Hvilken form for hardware bruger leverandøren, er der etableret (tilstrækkelig) logning, hvor meget adgang til logs er muligt. Er der etableret kryptering på netværksniveau, hvordan er krypteringen implementeret osv.

Netværk
Eksempler på områder der kan overvejes er bl.a. hvordan netværket er segmenteret, hvordan bruges firewalls og VLAN? Er beskyttelse imod DDoS (ude-af-drift angreb) standard.


2) Platform as a Service
Hvis den Cloud-løsning man overvejer også inkluderer platformen, f.eks. "Database as a Service", bør håndteringen af hele system management området også vurderes. Hvordan håndteres f.eks. patch management og configuration management? Hvad med overvågning, identity management osv.


3) Software as a Service
I SaaS-løsninger styres alle de underliggende IaaS- og PaaS systemer og processer af leverandøren. Og hvis man mener, at sikkerheden er utilstrækkelig har man, som nævnt, ofte kun meget begrænset mulighed for at bygge ekstra sikkerhed ind i løsningen.

Alle de underlæggende områder kan være relevante at spørge ind til. Derudover er der to ekstra hovedområder man bør fokuserer på i en SaaS-løsning: data og applikationerne.

Data
Hvordan beskyttes data - og er beskyttelsen tilstrækkelig i forhold til risikovurderingen og dataklassifikationen.
Er kryptering etableret eller måske endda standard, hvordan er krypteringen implementeret og ikke mindst hvordan er nøglehåndteringen. Hvilke muligheder for overvågning er tilgængelige, og hvordan integrerer kontrollerne med vores etablerede systemer.
Kan leverandøren oplyse hvordan de klassificerer data, gemmes al data som flade filer eller har kunden mulighed for at styre adgangen til specifik data, kan data f.eks. beskyttes imod adgang fra administratore?

Applikationer
Hvordan har Cloud-leverandøren sikret applikationen, hvilken udviklingsmodel benyttes, har man mulighed for selv at teste sikkerheden eller er det direkte forbudt. Giver applikationen mulighed for at ændre på sikkerhedsparametre, f.eks. styrke krav til passwords.
Har applikationen indbygget beskyttelse imod almindelige webapplikation angreb som XSS?


Opsummering
Ved at starte med en dataklassifikation og derefter gå videre med input fra lovkrav, compliance krav og en sikkerhedsmodel kan sikkerhedskrav mappes direkte til den cloud-løsningen der skal vurderes.

Risikoanalysen viser primært om Cloud-løsningen har "huller" i forhold til sikkerhedskravene. Næste skridt er selvfølgelig at vurderer om leverandøren kan lukke hullerne, om der er sikkerhedstiltag der kan kompenserer for problemområderne - eller om man kan leve med risikoen.

Det er i øvrigt altid en god idé at sammenligne resultatet af risikovurderingen med den nuværende beskyttelse inden Cloud-løsningen, for at se om de nye krav er realistiske og om de egentlig forbedrer sikkerheden.


Cloud-specifikke trusler
For at lave en komplet vurdering af sikkerheden er man naturligvis nødt til at vurderer Cloud-specifikke trusler og de trusler der er særlige kritiske for en Cloud-løsning.

En række af de specifikke trusler vil, sammen med krav til Cloudsourcingen, blive fokus for det 4. - og sidste - indlæg om introduktionen til Cloud Security.