#Digital

Slik integrerer vi informasjonssikkerhet i tradisjonelle modeller for samfunnssikkerhet

Mange er allerede godt kjent med risiko og sårbarhetsanalyser (ROS analyse). I denne bloggen beskriver vi et verktøy som ofte brukes for risiko og sårbarhetsanalyse innen samfunnssikkerhet, og ser på hvordan den samme metoden kan brukes fra et informasjonssikkerhetsperspektiv.

Skille mellom safety og security

På engelsk har man et tydelig skille i terminologien mellom

  • safety, som er knyttet til ulykker, uhell og tilfeldige feil,
  • og security, som i dataverden er knyttet til beskyttelse mot bevisst ondsinnede handlinger.

På norsk brukes samme ord – sikkerhet – for å representere begge disse begrepene. Dette kan lett føre til en rekke misforståelser når ulike miljøer snakker sammen. For å holde disse to perspektivene fra hverandre, bruker vi de engelske ordene istedenfor de norske i dette blogginlegget.

Risiko brukes som regel for å uttrykke kombinasjonen av sannsynligheten for og konsekvensen av en uønsket hendelse. Knyttet til investeringer og pengespill snakker man gjerne også om positiv risiko, altså mulighet for en ønsket hendelse, men dette blir et annet perspektiv som vi ikke behandler her.

To metoder for risiko og sårbarhetsanalyse

Hensikten med en risikovurdering er å danne et grunnlag for risikoreduserende tiltak som kan iverksettes i virksomheten. Resultatet fra en risikovurdering dokumenteres ofte i en risikomatrise, der alvorlighetsgraden av de de forskjellige risikoelementene enkelt kan vurderes opp mot hverandre. Men risikokomatriser er ikke den eneste muligheten for å visualisere risiko.

Et eksempel på hvordan en risikomatrise kan se ut.

Sløyfediagrammer (eng: bow tie diagrams) – du vil se et eksempel lengre ned i bloggen – er et annet enkelt og effektivt verktøy for å kommunisere resultater fra en risikovurdering til personer på alle nivåer i en virksomhet.

Et sløyfediagram visualiserer koblingen mellom årsak og konsekvens av uønskede hendelser. Sløyfeanalyse, som resulterer i et eller flere sløyfediagrammer, er vanlig å bruke for å kartlegge risiko av alvorlige hendelser i for eksempel olje- og gassindustrien, kraftbransjen og det maritime miljøet i Norge.

I motsetning til en risikomatrise er ikke hensikten med et sløyfediagram å sammenligne og vurdere alvorlighetsgrad av ulike risikoscenarier; fokus er heller på å få fram spredningen i ulike årsaker og konsekvenser i en gitt hendelse, samt rette oppmerksomheten på hvilke mottiltak som har (og ikke har) blitt iverksatt.

Sløyfediagram: Skred nær boligområde

Figuren nedenfor, som vi har lånt fra Direktoratet for samfunnssikkerhet og beredskap, viser et eksempel på et sløyfediagram der den uønskede hendelsen som vurderes er et skred nært et boligområde:

  • Til venstre vises en rekke mulige årsaker, for eksempel kraftig nedbør, som kan føre til at skredet inntreffer.
  • Til høyre vises mulige konsekvenser, for eksempel dødsfall og skader etter at hendelsen inntreffer.

Som vist i dette sløyfediagrammet har flere sannsynlighetsreduserende og konsekvensreduserende tiltak allerede blitt gjennomført.

Bilde fra Direktoratet for samfunnssikkerhet og beredskap sin webside: https://www.dsb.no/
Bilde fra Direktoratet for samfunnssikkerhet og beredskap

Sløyfediagrammer er vanlig å bruke i bransjer som er opptatt av sikring av liv, helse, eiendom og miljø (det er dette vi kaller safety på engelsk). Sløyfediagrammer er derimot ikke vanlig å bruke for å illustrere uønskede hendelser som påvirker informasjonssikkerheten (det som vi kaller security på engelsk), på tross for at brudd på informasjonssikkerhet i en organisasjon kan ha indirekte konsekvenser for både liv, helse, eiendom og miljø.

Når angripere er en reell fare

Virksomheter, som tidligere har vært mest opptatt av å evaluere hvilken påvirkning uhell og andre tilfeldige hendelser kan ha på liv, helse og miljø, har nå innsett at angripere kan være en reell fare og at sikkerhetsbrudd kan føre til utrygge tilstander for omgivelsene. De må derfor tenke sikkerhet, men vil gjerne bruke metoder de er vant med. Det er ikke helt enkelt å oversette safety terminologien som brukes i sløyfediagrammer til security-terminologi. Nedenfor følger vårt forslag.

Fare

Begrepet fare (eng: hazard) brukes for å representere noe som potensielt kan forårsake skade på mennesker, helse, eiendom eller miljø. Fra et risikovurderingsperspektiv må faren derfor kontrolleres, slik at uønskede hendelser ikke vil oppstå.

Et første steg i en ROS analyse (fra et safety perspektiv) er alltid å identifisere farer og scenarier, som siden brukes som input til selve risikovurderingen. Eksempler på to farer som ble identifisert i en safety analyse er «oppbevaring av eksplosivt materiale i bygningen» og «arbeid i høyden».

En fare kan i utgangspunktet være hva som helst som kan forårsake skade, men som er nødvendig for bedriften å leve med. Så vidt vi vet, så finnes det ikke noe tilsvarende begrep når man snakker om informasjonssikkerhet. Vi kan muligens trekke en parallell til de kritiske systemer og prosesser som er nødvendige for organisasjonen, men som også kan misbrukes eller manipuleres for å forårsake skade. I vårt eksempel bruker vi begrepet fare på denne måten og kan da identifisere alt fra prosesskontrollsystemer til medisinsk utstyr som eksempler på farer.

Uønsket hendelse

En uønsket hendelse (eng: unwanted event, or loss event) et det som vil skje hvis man mister kontrollen over faren. I en safety-analyse så vil alltid en uønsket hendelse forårsakes av et uhell eller en tilfeldig feil. Begrepet uønsket hendelse er også vanlig å bruke i informasjonssikkerhetsanalyser. I våre bow-tie diagrammer bruker vi dette begrepet for å betegne hendelser som skyldes tilsiktede handlinger eller en tilstand som kan føre til at verdier (se under) blir utsatt for brudd på konfidensialitet, tilgjengelighet eller integritet.

Verdi

Verdi (eng: asset) er et typisk informasjonssikkerhetsbegrep. En verdi er noe som har en høy betydning for en organisasjon og som derfor må beskyttes. ISO/IEC 27005 standarden for risikohåndtering skiller mellom primære verdier, som er virksomhetens kjerneprosesser og den informasjon som hører til disse, og sekundære verdier, som er det som må være på plass for å beskytte de primære verdiene men som nødvendigvis ikke har så høy betydning i seg selv.

Typiske eksempler på primære verdier kan være bedriftshemmeligheter, kunderegister (personopplysninger), krypteringsnøkler som brukes for å beskytte sensitiv informasjon, betalingstjenester, etc. men dette vil selvsagt variere mellom ulike virksomheter.

Verdi er ikke et konsept som er vanlig å bruke i klassisk safety-analyse. Der er det alltid menneskeliv, helse og miljø som må beskyttes og uønskede hendelser evalueres kun i henhold til disse. En safety-analyse er derfor ikke egnet å fange opp angrep og andre tilsiktede hendelser der informasjon kompromitteres, endres eller misbrukes med viten og vilje, selv om slike hendelser kan ha innvirkning på liv, helse og miljø.

Vi har derfor utvidet våre sløyfediagrammer med dette begrepet, slik at vi kan knytte hver identifiserte fare til en eller flere verdier som vil bli rammet dersom den uønskede hendelsen inntreffer.

Trussel og angripere

En trussel (eng: threat) er noe som kan forårsake en uønsket hendelse. Som allerede nevnt, så tar klassisk safety-analyser bare hensyn til uhell og tilfeldige feil, men det er vanlig at informasjonssikkerhetsanalyse bare fokuserer på ondsinnede angrep. Siden våre primære interesse er informasjonssikkerhet, fokuserer vi på ondsinnede angrep i våre sløyfediagrammer, og vi kobler disse til en eller flere angripere (eng: attacker or threat agent), som representerer den gruppe av mennesker som vi tror har tilstrekkelig kompetanse, anledning, ressurser og motivasjon for å utføre angrepet.

Barrierer og mottiltak

I safety-analyser definerer man også begrepet barriere (eng: barrier) til å være en mekanisme som forhindrer et scenario, slik at de identifiserte truslene ikke resulterer i uønskede hendelser, eller som forhindrer at de uønskede hendelsene leder til noen konsekvenser med tanke på safety. Dette begrepet tilsvarer det vi vanligvis kaller mottiltak (eng: mitigation or countermeasure) i en informasjonssikkerhetssammenheng.

Mottiltak er en måte å håndtere risiko på og kan inkludere sikkerhetsmål, retningslinjer og forskjellige prosedyrer som kan være administrative, tekniske, forvaltende eller lovbestemte. Hensikten med mottiltak er å unngå, detektere, dempe eller minke risikoen i virksomheten.

Man skiller vanligvis mellom forebyggende mottiltak, hvis hensikt er å hindre uønskede hendelser, detekterende mottiltak, hvis hensikt er å oppdage og klassifisere hendelser som skjer, og korrigerende mottiltak, hvis hensikt er å minke skaden forårsaket av en hendelse.

Opptrappende faktor

Til slutt har vi begrepet opptrappende faktor (eng: escalation factor) som kan være hva som helst som leder til at en identifisert barriere ikke virker som tiltenkt. Det finnes ikke noe direkte oversettelse mellom dette begrepet fra safety-analyser og noen av de etablerte begrepene i informasjonssikkerhetsanalyse.

Men begrepet har fellestrekk med sårbarhet, som, ifølge ISO 27005, er en svakhet i en eller flere verdier som kan utnyttes av en eller flere trusler. I våre sløyfediagrammer bruker vi derfor dette begrepet for å representere de sårbarheter som finnes i systemet som skal risikovurderes.

I safety-analyse er det også vanlig å identifisere mottiltak til de opptrappende faktorene (eng: escalation factor controls) for å representere de barrierene som er implementert spesielt for å redusere sannsynligheten av de identifiserte sårbarhetene.

En generell mal for sløyfediagram

I figuren under ser vi hvordan begrepene er illustrert i en generell mal av et sløyfediagram. Diagrammet viser at risikoen for en uønsket hendelse, som påvirker en verdi (som inngår i et kritisk system) er en kombinasjonen av sannsynlighet og konsekvens.

bilder_page_2
En generell mal av et sløyfediagram for informasjonssikkerhet

Case: Havn mottar ikke data fra skip

I figuren under har vi lekt oss litt med ett eksempel fra det maritime miljøet. Vi har sett på risikoen av en ny type tjeneste som er i ferd med å implementeres i hele Europa; Maritime Single Window som er et felles meldingspunkt for skipsrapportering, for eksempel ankomstbeskjed til havn.

Hensikten er at skipsfart kun må forholde seg til et sted for å innrapportere nødvendig data, som siden distribueres til de nasjonale og internasjonale etater som trenger denne informasjon.

Sløyfediagrammet viser den uønskede hendelsen «havn mottar ikke data fra skip», som vil resultere i at skipet blir forsinket inn til kai eller, i verste fall, nektes adgang til havnen. Tre trusler kan forårsake denne hendelsen, men det har kun blitt implementert mottiltak til en av dem.

bilder_page_3
Et sløyfediagram som visualiserer et angrep mot Maritime Single Window tjenesten.

Fordelene med sløyfeanalyse

Sløyfeanalyse er en fin teknikk for å visualisere spredningen i ulike årsaker og konsekvenser av en gitt hendelse, samt sette fokus på hvilke mottiltak som har (og ikke har) blitt implementert, men metoden har selvsagt noen begrensninger, spesielt hvis man ønsker å bruke den for å vurdere informasjonssikkerhet.

Som figuren viser så inkluderer man vanligvis ikke noen detaljer om hvordan de identifiserte angrepene kan gjennomføres og det blir derfor vanskelig å vurdere alvorlighetsgraden av de forskjellige truslene i et og samme diagram oppimot hverandre.

Vi anbefaler å komplettere

Vi anbefaler derfor at diagrammet kompletteres med noen av de etablerte metodene for angrepsanalyse, for eksempel angrepstrær (eng: attack trees), eller misbrukstilfeller (eng: misuse cases).

Hovedfordelen med sløyfeanalyse er at metoden er velkjent i miljøer som tradisjonelt har hatt stor fokus på safety (for eksempel det maritime miljøet, luftfart, olje- og gass, kraftbransjen).

Og hva kan vel være bedre enn å legge til rette for at bedrifter kan gjenbruke metoder og verktøy de er vant til?

Til syvende og sist er det jo sånn at jo mer oppmerksomhet man har på informasjonssikkerhet desto bedre klarer man å oppdage svake punkter og dermed beskytte sine systemer.

Denne bloggen er en omarbeidet versjon som først ble publisert på SINTEF Infosec-blogg.

0 comments on “Slik integrerer vi informasjonssikkerhet i tradisjonelle modeller for samfunnssikkerhet

Legg inn en kommentar