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.

Les mer: 12 mulige trusler når man flytter til skyen

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.

Les mer: 8 risikoer ved å benytte Github eller andre kodehus

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.

Last ned vår guide der sikkerhetsekspert Even Lysen gjennomgår hvordan du kan utføre sikkerhetstesting gjennom hele utviklingsløpet.

Last ned guiden

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

Organisasjon er på et overordnet nivå. Her ser man på om man har de nødvendige strategiene og rollene på plass. Er sikkerhetsarbeidet (som ikke bare handler om IT, ,men fysisk sikring for bygg og ansatte er også med) godt kommunisert, er det en del av virksomhetens strategi og er visjonen godt kommunisert. Her ser man på holdninger og generell modenhet innenfor hendelseshåndtering og masse mer.

Domene ser på det totale bildet av husets teknologistack. Infrastruktur, applikasjonsportefølje, eksternes tilgang, leverandører og samarbeidspartnere, nettverk og dataflyt mellom systemer, koblinger til eksterne virksomheter, overvåkning, logging, backup og restore systemer, etc.

Applikasjon ser på hver enkelt applikasjon. Hvem har tilgang til hva (tilgangstyring), er det benyttet least-privilege, kodestandarder, arkitekturen, dataflyt, lagring av applikasjonens data, statisk og dynamisk kodeanalyse. Har utviklerne korrekt kompetanse, benytter de utviklingsmetodikker med fokus på sikkerhet, har de en security champion, hvordan påvirker produksjonssetting av denne applikasjonen domenet, etc.

Når man skal utføre en risikoanalyse må man først velge en metodikk, et scoringssystem og bestemme scope av analysen. Alle metodikkene har omtrent følgende til felles:

1.   Kategorisere
2.   Velge
3.   Implementere
4.   Vurdere
5.   Autorisere
6.   Monitorere

For at en risikoanalyserapport skal klare å kommunisere godt trengs et felles språk.

Den vanligste måten å kategorisere risikoer på er i den klassiske CIA (Confidentiality, Integrity, Availability). Sett opp en tabell for hver kategori

Konfidensialitet

Integritet

Tilgjengelighet

Ved endt risikoanalyse putter man hver risiko ID inn i risikomatrisen.

Risikokart / Risikomatrise

 

Man står da igjen med en liste over risikoer, holistiske tall over sannsynlighet og konsekvens og et risikokart som indikerer hvordan du bør prioritere (Hint-hint. Start med de røde). Hvert mitigerende tiltak bør skrives til en Use-Case eller Task og tas med inn i neste Sprint planlegging (eller tilsvarende startmøte for din iterative agile arbeidsmetodikk).

Ved overlevering av en risikoanalyse bør man få produkteier eller prosjektleder til å skrive under på mottakelse av rapporten. Deretter bør den distribueres til utvikler teamet (med mindre de var så flinke å gjorde dette selv). Ansvaret for at tiltak blir implementert legges på teamets Security Champion og/eller Lead Dev eller Prosjektleder. Ikke la det bli noe som noen bare trengte fordi de fikk beskjed om å ha det. Bruk den! =)