Hvordan utføre risikoanalyser med fokus på skyløsninger

GDPR dikterer ikke hvordan en slik Impact Assesment skal se ut, og virksomheten står derfor fritt til å velge metodikk og dokumentasjonsform. Det finnes en rekke forskjellige metodikker for Risiko- og Sårbarhetsanalyser man kan velge mellom. Slik som:

• NIST-SP800-30
• NIST-SP800-37
• ISO 31000 / 31010
• ISO 27005
• IEC 62198
• DREAD og STRIDE
• COBIT
• Attack Trees
• NSM og Difi sine Risikovurderingsguider

Det eksisterer mange fler, og det finnes ingen fasit for hvilken man skal velge. Noen egner seg best på organisatorisk nivå (ISO 31000), andre passer ypperlig på teknisk applikasjonsnivå (DREAD m/ STRIDE) og så har man de mer generelle som man kan bruke nesten hvor som helst (RMF-NIST). Men som nevnt står man her fritt til å forme sitt rammeverk etter behov.

Det alle har til felles er at de synliggjør mulige svakheter ved virksomheten som kan utgjøre en trussel (tekniske så vel som organisatoriske og virtuelle så vel som fysiske), og deretter kvantifisere og prioritere de. Man står da igjen med en liste hvor noen trusler er røde og må tas tak i med en gang, mens andre risikoer aksepterer man. Virksomhetens kompetanse og ressurser dikterer om man kan minimere eller fjerne truslene selv, eller om man må hente inn spesialkompetanse. 

Først; Hva er risiko?

Risiko er usikkerhet. Hva skjer hvis…? Det er viktig å huske at risiko ikke alltid utligner en trussel, men også ofte muligheter. Man kvantifiserer oftest risiko på følgende måte:

Risiko = Sannsynlighet + Konsekvens 

Med en skala på 1 til 5. Hvor 1 er Lav og 5 er Høy. Noen plusser også på Vanskelighetsgrad (hvor vanskelig er det å utnytte denne svakheten), mens de fleste lar dette være en faktor som påvirker Sannsynlighet. Man kan velge at et tall betyr ca. så-så mange hendelser i løpet av uker, måneder, år, tiår, etc., men dette trenger ikke være viktig. Tallene man benytter er holistiske, og skal sees i sammenheng med hverandre, hvor målet er å kunne prioritere de korrekt.

Risikovurderinger bør behandles som levende dokumenter. Virksomheter så vel som IT systemer er i konstant utvikling, og dette kan endre risikobildet. Er man en statisk virksomhet med statiske systemer, så vil verden (dine omgivelser) endre seg hele tiden rundt deg.

Mange virksomheter har interne sikkerhetsgrupper som utfører slike rapporter, mens andre leier inn eksterne. Virksomheter som er virkelig fremoverlente har også fått på plass DPO (Data Protection Officer) som utfører egne vurderinger kalt PVK (personvernkonsekvensutredning). Jeg har sett at denne rollen ofte plasseres til Personvernombudet i virksomheten. Dette kan fungere, men det er viktig å poengtere at DPO slik den er spesifisert i GDPR skal inneha både teknisk og juridisk kompetanse. Ergo; ikke den enkleste rekrutteringsjobben.

Hvordan endres risikobildet når man flytter til skyen?

Rammeverkene er godt etablert og mange kjenner de. Det vi skal se på er hvordan en skystrategi (flytte systemer og data til offentlige skyleverandører, ofte utenlandske) endrer ditt risikobilde. Det er ikke enkelt å utføre risikoanalyser for skybaserte løsninger på lik linje som tidligere. Som kunde kjenner man sjelden til skyleverandørens infrastruktur, fysiske lokasjon eller rutiner. Noe kan man be om innsyn i, men mye vil ikke være mulig å få informasjon om.

Risikovurderinger synliggjør risikoappetitt (hvor er bristepunktet av hva du klarer å håndtere) og bør derfor være med i enhver virksomhetsstrategi, ikke bare hos IT.

Cloud Security Alliance (CSA) publiserte i 2013 et dokument ved navnet «The Notorious Nine: Cloud Computing Top Threats in 2013». Her listet de opp ni trusselområder som skykunder må ta høyde for:

1. Data breaches 
2. Data loss
3. Account or service traffic hijacking
4. Insecure interfaces and APIs
5. Denial of Service
6. Malicious insiders
7. Abuse of cloud services
8. Insufficient due dilligence
9. Shared technology vulnerabilites

Det som er viktig å påpeke her er at de ni er i kontekst av skyen. Man hadde disse truslene tidligere også, men ved egne datasentere eller driftspartnere med tett kontakt kunne man ha innsyn og kontroll på en helt annen måte.

Ser man ENSIA dokumentet «Cloud Computing – Benefits, risks and recommendations for information security» lister de opp fire hovedområder for risikoer:

1. Policy and organizational risks
2. Technical risks
3. Legal risks
4. Risks not specific to the cloud

ENSIA sitt dokument tar for seg en rekke scenarier og går igjennom eksempler på hvordan risikoen skal tolkes, klassifiseres og minimeres. Selv om dokumentet er 10 år gammelt er det anbefalt lesning.

Et rammeverk som tar for seg mye likt som ENSIA er The National Commission on Informatics and Liberty (CNIL), men her er hovedfokuset på personvern i skyløsninger.

Som nevnt i innlegget “12 trusler når man flytter til skyen” er tillit en av de store utfordringene ved å gå til skyen. Her tar mange i bruk såkalte Trust-models for å kunne gjøre bevisste valg. I de senere årene har det dukket opp flere trust-modeller som sikter direkte på skyløsninger. I dokumentet «A Model for User Trust in Cloud Computing» lister Rashidi og Movahhedinia opp en rekke faktorer som spiller inn på tillitsmodellen:

• Data lokasjon (skykunde vet hele tiden hvor deres data fysisk er oppbevart)
• Innsyn (skykunde kan til enhver tid se hvor sine data er i verden)
• Data segregering (data fra hver enkelt skykunde er separert fra hverandre)
• Tilgjengelighet (Skykunder har tilgang til sine tjenester og data til enhver tid)
• Priviligert tilgang (Priviligerte kunder (ex. sysadmins) er til å stole på)
• Backup og recovery (At skyleverandør har tilstrekkelig backup og recovery rutiner)
• Compliance (At skyleverandør er compliant med lover og regler og rammeverk, er sertifisert og er åpen for innsyn)
• Lang fartstid (Skyleverandøren har levert over minimumskrav i lang tid)

Tillitsmodeller bør være et eget dokument, men også dette skal være levende. Det er ikke en engangsjobb.

Slik gjør du en risikovurdering

Mange har egne definisjoner på hvordan man kategoriserer de forskjellige områdene/nivåene man skal vurdere risiko på. De fleste bunner ut i noe som kan se slik ut:

• Organisasjon
• Domene
• Applikasjon