16. februar 2024
Efter man har beskrevet sin kontekst, er næste trin i risikostyringen at kigge nærmere på, hvad man har af ”værdier”, også kaldet aktiver. Første trin i den underproces er at få afgrænset det system/område, man analyserer, og få kortlagt, hvad der findes af aktiver, så man derefter kan kigge på de enkelte aktiver individuelt.
Risikostyring handler overordnet om at skabe overblik, så man kan træffe beslutninger på et oplyst grundlag. Forinden selve risikoanalysen, handler det om at finde ud af, hvilke aktiver man har, så man efterfølgende kan vurdere, hvilke trusler de kan være udsat for. Formålet er at skabe det nødvendige overblik til at udarbejde den liste med aktiver, som risikoanalysen vil tage udgangspunkt i.
For at kunne identificere de forskellige risici i systemet, kan man kigge på de ting i systemet, som har eller skaber værdi. Det er som udgangspunkt lettest at identificere aktiver i forbindelse med en workshop på et par timer (afhængigt af det system man undersøger), evt. med noget beskrivende arbejde som opfølgning.
Selve processen omkring kortlægningen af aktiver kan groft inddeles i to dele: scope og brainstorm, som vil blive uddybet i de kommende afsnit.
Det er som udgangspunkt en god ide at tilstræbe mangfoldighed i denne proces, så der både deltager folk med forretningsforståelse og teknisk indsigt. Hvis der fx kun er teknikere med, kan man komme til at overse noget, der er vigtigt for forretningen. Omvendt har forretningsfolk ikke nødvendigvis den nødvendige tekniske viden om, hvordan systemet er bygget, så her kan man også komme til at overse noget.
I det forudgående trin, kontekstetablering, blev en række interessenter beskrevet. Denne liste burde indeholde de relevante personer, men hvis det er første gang, man udfører en risikoanalyse, skal listen måske tilrettes.
Herunder ses et overblik over interessenter fra værktøjet kontekstetablering.
Processen med at kortlægge aktiver følger 3 overordnede trin. Hvert trin vil blive mere detaljeret beskrevet i forbindelse med det gennemgående eksempel, som kommer efter guiden.
Find yderligere inspiration i eksemplet med IoT-dørlåsen nedenfor.
For at sikre, at alle deltagere i workshoppen er enige om præcist, hvad der undersøges, er det en god ide at få afklaret begreberne. Der findes allerede en overordnet afgrænsning/definition af systemet som en del af kontekstbeskrivelsen, men det kan være en god ide at gentage dette og evt. præcisere efter behov. Hvis man allerede har arkitekturdiagrammer eller andre tekniske beskrivelser, kan det også være et godt sted at starte. Her skal man dog være opmærksom på, at arkitekturdiagrammer som regel indeholder meget information og kan være vanskelige for ikke-teknikere at gennemskue.
Har man ikke mulighed for at tage udgangspunkt i eksisterende materiale, må man begynde fra bunden. Det kan være en god ide at holde tegningen forholdsvis abstrakt i starten og fokusere på de store linjer. Det er f.eks. ikke unormalt, at en klient og en server kommunikerer med hinanden på forskellige måder (REST, WebSocket, m.fl.), ligesom serveren internt kan bestå af en række microservices. Hvis man skal have alle de detaljer med i diagrammet, bliver det hurtigt vanskeligt at overskue, og oplysningerne bliver først nødvendige senere, når der skal arbejdes med trusselsmodellering. I stedet bør man fokusere på de større komponenter og nøjes med at markere, at der er kommunikation mellem A og B.
Når man tegner systemet, kan man f.eks. starte med at indtegne en bruger. Brugeren kan interagere med en mobil-app, en laptop-baseret web app og selve IoT-enheden. Når først man har fået de første par elementer på plads, plejer det at være let at få det sidste på plads også.
I eksemplet ses et sammenkoblet netværk af hardware, software og kommunikationssystemer, herunder IoT-dørlås-hardware med et kommunikationsmodul, en IoT-hub, en mobilapplikation til fjernadgang og en cloud-infrastruktur til datalagring og -behandling.
I løbet af workshoppen vil man sandsynligvis komme i tvivl om, hvorvidt nogle komponenter skal med eller ej. Det kan f.eks. være, at ens eget system leverer data til tredjeparter gennem et API, og man er i tvivl om, hvorvidt tredjepartens system også skal inkluderes i tegningen. En del af formålet med at udarbejde et scope er netop at tage sådanne diskussioner og notere resultatet. På den måde sikrer man, at antagelser og afgrænsninger bliver eksplicitte for alle, så man ikke baserer senere beslutninger på en forkert antagelse.
Når man arbejder med risikostyring generelt, kan “aktiver” dække over mange ting, lige fra bygninger og anlæg til medarbejdere og viden. Når man arbejder med risikostyring indenfor IT- og cybersikkerhed, kan man med fordel tænke på “aktiver” som data. Det skyldes primært, at den metode vi efterfølgende vil beskrive til at vurdere konsekvensen ved en hændelse, er bedst egnet til information/data og ikke fungerer så godt til fysiske ting. Der kan naturligvis være fysiske ting i systemet, der også skal beskyttes, f.eks. hvis en sensor er dyr og kan blive stjålet, men det vil ikke være omfattet af denne analyse. Ovenstående betyder, at f.eks. en server eller en laptop ikke er et aktiv, mens de data, der ligger på serveren, er.
I nogle tilfælde vil det “generelle aktiv” kunne dække over et “informationsaktiv”, der passer bedre i forbindelse med IT- og cybersikkerhed:
Når man har lavet et diagram af sit system og er enige om, hvad det omfatter, kan man påbegynde den egentlige identifikation af aktiver. Man foretager som udgangspunkt en brainstorm og noterer, hvad man finder. Man kan dog bruge nogle teknikker til at gøre selve brainstormen mere struktureret og sikre, at man ikke overser noget:
Metode A: Tekniske og forretningsmæssige aktiver:
Man kan lade folk med forretningsmæssig forståelse beskrive, hvilke data kunderne og andre interessenter får/ønsker, hvad de skal bruges til, og hvad der skal til for at skabe disse data. Samtidig kan man lade teknikere se på, hvilke data der findes i systemet. Det drejer sig om, hvad der bliver gemt i databaser/filsystemer, data der hentes fra eksterne partnere, data der sendes til klienter osv. De to lister kan derefter samles i én liste.
Metode B: Følg systemdiagrammet:
En anden mulighed er at gennemgå det diagram, man lige har lavet. For hver komponent i diagrammet kan man overveje, hvilken rolle komponenten udfører, og hvilke data der er nødvendige. Hvis man f.eks. har en klient-applikation, der tilgår en backend, kan man se på, hvad klienten kan, og hvilke data der bliver sendt fra/til klienten i den forbindelse. Det kunne være brugernavn/password for at tilgå systemet, mulighed for at se de enheder (og deres målinger), der er tilknyttet kontoen, mulighed for at registrere nye enheder samt mulighed for at aktivere eller på anden vis manipulere en tilknyttet enhed.
Download eksempel: Liste over aktivoplysninger for IoT dørlåsesystem
Når man har været igennem brainstormen, skal resultaterne konsolideres. Hvis man f.eks. har anvendt metode A, vil listen af tekniske aktiver være forholdsvis lang og indeholde meget specifikt data. Mange af disse aktiver kan evt. beskrives på et mere overordnet forretningsmæssigt plan. For eksempel kan “fakturaer”, “ordrer”, “reklamationer”, “kontaktinformation” og “leveringsadresse” beskrives som “kundedata”, uden at vigtige informationer går tabt.
I andre tilfælde kan man have behov for at opdele et aktiv i mindre dele for bedre at kunne analysere det. Ovennævnte “kundedata” kan evt. deles op i to dele: persondata og ikke-persondata, for at gøre det nemmere at reflektere over, hvad konsekvenserne ved en hændelse ville være.
Det kan derudover være en god ide at anvende begge fremgangsmåder, så man er sikker på at få det hele med. Selvom man tror, man har været grundigt omkring hele systemet, kan man godt risikere at finde en komponent i diagrammet, som tilsyneladende ikke indeholder nogle aktiver. Eller man kan risikere, at diagrammet måske slet ikke indeholder komponenter, som ellers er nødvendige for en vigtig funktionalitet i systemet. I begge tilfælde skal man sikre, at diagrammet afspejler virkeligheden.
Generelt kan det være en udfordring at finde et passende abstraktionsniveau. Dels er det måske ikke nødvendigt at skelne imellem noget, man umiddelbart tænker er to forskellige aktiver. Dels kan man risikere at få lavet en så bred definition af et aktiv, at man – når skal arbejde videre med det – er nødt til at have forskellige versioner, afhængig af hvilken kontekst man kigger på aktivet i.
Udbyttet af processen er en liste af de aktiver, som er vigtige for systemet. Aktiverne er de informationer, som får systemet til at fungere og derved skaber værdi. Listen af aktiver anvendes i den efterfølgende analyse, hvor man kigger på, hvad konsekvensen vil være, hvis et aktiv kompromitteres.
I princippet kan listen også anvendes direkte sammen med en liste af sikkerhedsmekanismer, så man kan undersøge, hvordan aktiverne er beskyttet.
Det vil som regel være nødvendigt at involvere folk med teknisk viden om systemet i denne proces. Folk med forretningsforståelse vil være gode til at definere de konceptuelle aktiver men vil muligvis ikke have fuldt kendskab til de “usynlige” aktiver, der rent faktisk får systemet til at virke. Teknikerne vil kunne give et værdifuldt bidrag og identificere aktiver, som man ellers ikke ville have været opmærksom på.
Det er også bedre at medtage for mange aktiver end for få i dette trin. Man kan altid fjerne et aktiv, hvis det senere viser sig ikke at være relevant, men hvis man sorterer et aktiv fra i dette trin, vil man ikke få det analyseret efterfølgende, og man dækker dermed ikke hele systemet.
I forbindelse med konsolidering og verificering kan det være en god ide at få verificeret listen af personer, som ikke har været direkte involveret i brainstormen. Hvis de undrer sig over nogle af de endelige beskrivelser, kan der måske være noget, man har overset.
Efter at aktiverne er kortlagt, kan man undersøge, hvad konsekvenser er, hvis et aktiv kompromitteres mht. fortrolighed, integritet og tilgængelighed, det er beskrevet nærmere i Konsekvensanalyse af aktiver.
Indholdselementerne ovenfor er udviklet gennem projektet:
’CyPro – Cybersikker produktion i Danmark’ af Aarhus Universitet, Alexandra Instituttet, DAMRC, UGLA Insights og FORCE Technology støttet af Industriens Fond. Materialet fra projektet er offentliggjort under licens CC BY-SA 4.0
