I dette innlegget beskriver jeg kort bakgrunnen og metoden bak en enkel risikoanalyse og/eller en simpel DPIA. I GDPR er det et krav om at sikringstiltak skal gjøres basert på en Data Protection Impact Assessment (DPIA). Men hva betyr egentlig det?
I forbindelse med etablering av prosesser for å tilfredsstille kravene i GDPR var gjennomføring av DPIA ett av flere tiltak. Men å tro det var nok å bare gjøre det en gang er ikke rett siden det forutsettes i loven at dette skulle gjentas – regelmessig - og at det derfor er viktig å ha dette på et format som gjør det enkelt å fornye og oppdatere denne analysen. Særlig for små og mellomstore virksomheter uten mye ressurser tilgjengelig.
Jeg laget derfor et enkelt regneark hvor jeg benyttet et grunnlag for gjennomføring av risikoanalyser som jeg lærte mens jeg var med i Information Security Forum (ISF). Her ble det lagt stor vekt på å gjøre en «First Cut» for å skille ut de systemene som er kritiske for virksomheten fra andre systemer med lav eller middels kritikalitet. Når jeg først var i gang, laget jeg verktøyet slik at man både kan vurdere et system ut fra selskapets kritikalitet og for den personlige subjekts kritikalitet for brudd på sikring av informasjoner som selskapet besitter. Disse 2 aspektene kan ofte være nesten diametralt motsatte av hverandre. Forretningskritisk informasjon som ikke inneholder personopplysninger er selvfølgelig ikke kritiske for enkeltpersoner, informasjon som er lite kritisk for virksomheten kan være meget kritisk for den enkelte som er registrert der, etc. Ved å kombinere dette i en og samme oversikt vil den årlige gjennomgangen ikke bare dekke kravene til GDPR, men også til for eksempel ISO 27001 som sier at alle gjennomførte sikkerhetstiltak for systemer skal være basert på risikobasert vurdering. Det finnes også andre lovkrav og forretningsmessige krav som kan kreve en slik regelmessig vurdering.
Analysen er enkel og vi ser at dersom man bruker 20-30 minutter på den første systemanalysen, vil en systemeier etterpå bruke ca. 5 minutter per system han/hun analyserer. Hvorfor er det så enkelt? Det ligger en empirisk kalkulering bak hver av de 7 enkeltvurderingene som gjøres for hvert system.
Den kritikalitet man blir eksponert for vil være brudd på IT sikkerhet. Dette uttrykkes gjerne som brudd på 3 definerte elementer:
Konfidensialitet: Uvedkommende får tilgang til informasjon enten bevisst eller ubeviss
Integritet: Selve informasjonens kvalitet blir ødelagt slik at man ikke lenger kan stole på resultatet av prosessert informasjon
Tilgjengelighet: Informasjonen er ikke tilgjengelig til å brukes når du har behov for det.
NB/NOTE: Mange blander «Tilgang» med «Tilgjengelighet». Det blir feil. Tilgang er en del av konfidensialitets-aspektet da det vil bety at noen får eller skaffer seg tilgang systemer og informasjon de ikke skal ha. Tilgjengelighet går derimot på hvordan avbrudd i dataprosessering kan reduseres til å skape minimalt med forstyrrelser for den enkelte bruker ved hjelp av kontinuitetsplaner og beredskapsplaner. Tilgjengelighet må derfor vurderes langs en tidsakse, mens de andre 2 elementene vurderes enkeltvis.
Basert på den kritikaliteten som et system har innenfor de 3 elementene nevnt over, kan man beregne en vektet kritikalitet totalt for systemet og iverksette tiltak der de faktisk kan fjerne den sårbarheten man har avdekket.
Når analysen brukes, er den knyttet opp mot 5 verbale begrep for skadeomfang:
Levels of impact |
|||
Level |
Description |
Quantified as |
Norsk |
A/5 |
Shall not happen at any cost |
a) Extremely harmful |
Må ikke inntreffe |
B/4 |
Major impact |
b) Very significant harm |
Svært alvorlig skade |
C/3 |
Significant impact | c) Significant harm |
Alvorlig skade |
D/2 |
Minor impact |
d) Minor harm |
Liten skade |
E/1 |
Negligible impact |
e) Negligible harm |
Ingen eller ubetydelig skade |
Det skal her gå et skille mellom «B» og «C» i den forstand at en alvorlig skade kan aksepteres, selv om den er smertelig for virksomheten; mens «B» og «A» er uakseptable skadeomfang som må unngås. Jeg pleier i forberedelsene til analysene å utarbeide et enkelt dokument hvor jeg forklarer hvordan disse 5 begrepene skal forstås i den enkelte virksomhet. Det vil jo være forskjeller mellom en bakerivirksomhet og et høyteknologisk selskap i hva som anses som akseptabelt og uakseptabelt. Imidlertid bruker jeg tid sammen med ledelsen til å sette opp verdier for de 5 begrepene basert på forskjellige former for skadearter. Det kan være tap av rykte og rennommé («tap av Brand»), det kan være tap i arbeidstimer, produksjon, beslutningsgrunnlag eller rene økonomiske tall osv. Når tabellen er satt opp, blir den presentert og diskutert med den enkelte systemeier. Men vi ser at når de har forstått bakteppet for vurderingene, så er de mer komfortable med å bruke de verbale begrepene. Og når de først har vært gjennom metoden en gang, så faller de neste analysene lett å gjennomføre. Enten kan man fylle inn i et skjema eller fylle direkte inn i regnearket.
Eksempel på enkelt papirskjema eller input skjermbilde for en access database.
I dette innlegget har jeg beskrevet kort bakgrunnen og metoden bak en enkel risikoanalyse og/eller en simpel DPIA. I neste innlegg vil jeg presentere mine erfaringer med bruk av dette hos virksomheter.