Cloud Computing - Risikovurderingen

I teorien har brugerne ingen interesse i hvilke 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.

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?
SOX, Euro-SOX, PCI osv giver en række andre krav, der skal kunne adresseres af den valgte løsning, hvis relevant.

3. Hvilken sikkerhedsmodel benytter vi normalt?
Sikkerhedsmodeller som DS484/ISO 27002/ISF 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 SPIaaS:


SPI-modellen er meget effektiv til direkte at afklare hvilke sikkerhedsområder der skal fokuseres på for en specifik Cloud-løsning. Herunder hvilke sikkerhedsområder Cloud-leverandøren har ansvar for, hvordan områderne håndteres - og hvad det forventes, at man selv håndterer.
I en PaaS-løsning skal kunden f.eks. ofte 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 infrastrukturen.

Den fysiske placering af datacenter
Persondataloven eller lokale lovkrav, f.eks. risiko for [url=http://computerforensics.dk/ed.htm]electronic discovery[/url], eller risiko for 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. Vær opmærksom på teknikker som VMotion/XenMotion, der gør det muligt at flytte virtuelle maskiner mellem forskellige datacentre. Hvis placeringen er meget kritisk bør man således nærlæse kontrakten for at bestemme leverandørens mulighed for at flytte data til andre 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.
Den indledende risikovurdering bestemmer stadig om undersøgelsen kan ske ved at vurdere Cloud-leverandørens eksisterende dokumentation, ved at stille uddybende spørgsmål til leverandøren, igennem inspektion eller om der måske skal udarbejdes en uafhængig erklring om sikkerheden.

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? Hvordan transporteres data mellem kunden og Cloud-leverandørens net? Er beskyttelse imod DDoS (ude-af-drift angreb) standard og tilstrækkelig.

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 Cloud-leverandøren. Og hvis man mener, at sikkerheden er utilstrækkelig har man 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 beskytter leverandøren 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 problem områderne - eller om man kan leve med risikoen.

Det er i øvrigt altid en god ide 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.