En cyberrisikoanalyse skal forklare, hvad der kan gå galt, hvem der kan blive ramt, og hvilke foranstaltninger der ændrer forløbet. En liste over sårbarheder er ikke nok. Analysen skal forbinde en sandsynlig hændelseskæde med konkrete konsekvenser og en beslutning om den risiko, der bliver tilbage.
Her bruges en arbejdsform inspireret af ANSSI’s EBIOS Risk Manager. Metodens fem workshops giver en nyttig struktur fra afgrænsning til risikobehandling. Eksemplet er tilpasset en fiktiv dansk virksomhed og er ikke en fuld EBIOS-analyse eller en erstatning for en konsekvensanalyse efter GDPR.
Vælg et afgrænset beslutningsproblem
Den fiktive virksomhed Broværk Service vil give en ekstern it-leverandør fjernadgang til et system med kundeaftaler og medarbejdernes vagtplaner. Ledelsen skal beslutte, hvilke adgangsvilkår der skal være opfyldt før åbning. »Vurder hele virksomhedens cybersikkerhed« ville være et for bredt udgangspunkt for denne beslutning.
Afgrænsningen omfatter leverandørens identiteter, fjernadgangen, applikationen, dens database og den relevante backup. Lønsystemet er ikke direkte med i opgaven, men en fælles administratorkonto kan skabe en afhængighed, som skal undersøges. Et system uden for den formelle afgrænsning må ikke forsvinde fra analysen, hvis angrebsvejen går gennem det.
ANSSI’s metodebeskrivelse forklarer bevægelsen fra organisationens opgaver til mulige angrebsveje og tekniske forhold. Datatilsynets vejledning om risikovurdering understreger, at GDPR ikke foreskriver én bestemt model. Metoden vælges, fordi den hjælper med beslutningen, ikke fordi dens navn i sig selv dokumenterer overholdelse.
Første workshop: opgave, data og sikkerhedsgrundlag
Saml driftsansvarlig, systemejer, en medarbejder med kendskab til den praktiske serviceopgave og den relevante databeskyttelsesfunktion. De har forskellige oplysninger. It ved, hvordan adgangen etableres; systemejeren ved, hvilke konsekvenser en ændret vagtplan kan få for medarbejderne.
Broværk beskriver tre uønskede resultater: kundedata kopieres ud, vagtplaner ændres uden godkendelse, og serviceplanlægningen bliver utilgængelig under et nedbrud. For hvert resultat beskrives både driftskonsekvens og konsekvens for personerne. En mistet arbejdsdag for virksomheden er ikke det samme som, at en medarbejders private kontaktoplysninger offentliggøres.
Kortlæg derefter eksisterende foranstaltninger og kendte huller. MFA findes for interne medarbejdere, men leverandøren har en delt konto. Backup findes, men gendannelsesprøven omfatter endnu ikke applikationens konfiguration. Brug den basale sikkerhedsgennemgang til at opdage sådanne mangler uden at vente på, at hele analysen er afsluttet.
Anden workshop: hvem kan ville opnå hvad?
Identificér relevante kombinationer af aktør og mål. I Broværks tilfælde vælges en cyberkriminel aktør, der vil afpresse virksomheden ved at kopiere og låse data, samt en intern aktør, der vil ændre vagtplaner uden godkendelse. Det er mulige scenarier, ikke beskyldninger mod bestemte medarbejdere eller leverandører.
Spørg, hvorfor netop denne aktør og dette mål er relevante. Har aktøren en realistisk adgangsvej? Er oplysningerne eller driftsafhængigheden interessante? Et eksotisk scenarie kan optage meget tid, mens en delt adgangskode overses.
EBIOS’ angrebsscenarier har særlig fokus på tilsigtede handlinger. Utilsigtede fejl, strømproblemer og almindelige driftsfejl skal stadig dækkes i organisationens samlede risikovurdering. De kan behandles gennem sikkerhedsgrundlaget og særskilte scenarier. En analyse af ondsindede aktører bør ikke fremstå som et bevis på, at alle risikotyper er gennemgået.
Tredje workshop: tegn den overordnede angrebsvej
Beskriv vejen gennem organisationens relationer. Broværks første scenarie lyder: »En angriber overtager en identitet hos supportleverandøren og bruger den godkendte fjernadgang til at nå kundesystemet.« Det peger på en konkret afhængighed, som virksomheden ikke kan vurdere ved kun at undersøge sin egen firewall.
Undersøg leverandørens adgangsmodel, godkendelsesproces og mulighed for at opdage misbrug. Aftaler og tekniske begrænsninger skal hænge sammen. En kontrakt om begrænset supportadgang hjælper mindre, hvis den aktive konto stadig er administrator hele døgnet.
Forbind scenariet med kortlægningen af systemer og leverandøradgange. Det skal fremgå, om adgang til ét system også giver adgang til backup, identitetsstyring eller andre databaser. Et detaljeret diagram er kun nyttigt, hvis de faktiske adgangsveje er med.
Fjerde workshop: gør forløbet vurderbart
Nedbryd det overordnede scenarie i handlinger. Broværk beskriver, at en angriber får leverandørens fælles login, forbinder gennem fjernadgang, bruger kontoens brede rettigheder og eksporterer kundedata. Teamet undersøger derefter, hvilke trin de eksisterende kontroller faktisk kan forhindre eller opdage.
Skeln mellem en konstateret svaghed og en antagelse. Den delte konto er konstateret. Muligheden for at eksportere alle kundedata er endnu ikke afprøvet. Notatet skal vise denne usikkerhed, så en manglende oplysning ikke bliver til en falsk sikkerhedsvurdering.
Teamet bruger kategorierne lav, middel og høj sandsynlighed med en skriftlig definition. Alvor vurderes særskilt ud fra de berørte personer og skadens karakter. Skalaen er et internt hjælpemiddel; den gør ikke et usikkert skøn til en målt årlig sandsynlighed.
Udfyldt scenarie og behandling
| Felt | Broværks udfyldte vurdering |
|---|---|
| Uønsket resultat | Kundernes kontakt- og aftaleoplysninger kopieres af en uvedkommende |
| Indgang | Overtaget, delt leverandørkonto til fjernsupport |
| Kendt svaghed | Adgangen er permanent og kan ikke knyttes entydigt til én person |
| Konsekvens for personer | Oplysninger kan bruges til målrettet svindel og afsløring af kundeforhold |
| Usikkerhed | Det er endnu ikke bekræftet, om kontoen kan eksportere hele databasen |
| Beslutning | Fjernadgang åbnes ikke under den nuværende kontomodel |
| Valgt ændring | Navngivne konti, MFA, tidsbegrænset godkendelse og begrænsede systemrettigheder |
| Bevis før åbning | Udført adgangsprøve, registreret aktør i log og dokumenteret lukning efter supportopgaven |
Den udfyldte beslutning undgår at kalde risikoen accepteret, før foranstaltningerne er gennemført. En handlingsplan er ikke en eksisterende kontrol. Hvis leverandøren ikke kan levere den nye adgangsmodel, må systemejeren vælge en anden supportform eller genforelægge den konkrete situation.
Femte workshop: ansvar, frister og resterende risiko
ANSSI’s officielle guide beskriver risikobehandlingen som det afsluttende led i et iterativt forløb. I praksis skal den enkelte handling have en ansvarlig, en realistisk leverance og et kriterium for, at den virker.
Broværks it-ansvarlige etablerer kontiene. Leverandørens kontaktperson oplyser de personer, der skal have adgang. Systemejeren godkender hver supportsag, og en anden driftsmedarbejder gennemgår prøven af logning og lukning. Planen angiver den interne dato før åbning af den nye adgang; datoen er ikke en generel lovfrist.
Efter ændringen er det fortsat muligt, at en autoriseret person misbruger sin adgang under en supportsag. Teamet vurderer denne resterende risiko med de faktiske begrænsninger og overvågningsmuligheder. Den ansvarlige ledelse træffer beslutning på det oplyste grundlag. En forsikring eller en erstatningsklausul flytter ikke personernes skade væk og ophæver ikke lovkrav.
Foranstaltninger skal ændre et bestemt trin
MFA kan mindske risikoen ved stjålne adgangskoder, men løser ikke alle former for overtaget session eller misbrug fra en legitim bruger. Begrænsede rettigheder kan reducere adgangens rækkevidde. Sikkerhedslogning kan gøre misbrug synligt, hvis nogen følger op på de relevante hændelser.
Knyt derfor hver foranstaltning til et trin i scenariet og beskriv dens begrænsning. »Kryptering løser risikoen« er utilstrækkeligt, hvis angriberen bruger applikationens normale eksportfunktion og får data udleveret i læsbar form. »Backup løser afpresning« overser mulig offentliggørelse af allerede kopierede oplysninger.
En genopretningsplan med RTO og RPO er relevant for tilgængelighedsscenariet. Den skal afprøves med de nødvendige systemafhængigheder. Gendannelse af en database alene hjælper ikke, hvis ingen kan starte applikationen eller få adgang til de nødvendige nøgler.
Hold cyberanalysen og DPIA’en forbundet
Cyberanalysen kan levere viden om fortrolighed, integritet og tilgængelighed til en DPIA. Den besvarer ikke alene, om behandlingen er nødvendig og proportional, eller om formål, dataminimering og rettigheder er håndteret. Datatilsynets beskrivelse af konsekvensanalyser forklarer det bredere vurderingsforløb.
Brug den udfyldte DPIA-skabelon, hvis behandlingen kræver denne analyse. En underskrift på et cyberrisikonotat erstatter ikke en eventuel forudgående høring ved en fortsat høj risiko, som ikke kan begrænses tilstrækkeligt.
Broværk genbesøger vurderingen, hvis leverandøren ændres, en ny integration åbnes, eller en kontrol viser sig ikke at virke. Den gemte analyse skal vise beslutningens forudsætninger, ikke blot dens farve i en matrix. Derved kan næste ændring vurderes uden at begynde forfra eller ukritisk genbruge en gammel konklusion.
Metode- og myndighedskilder er kontrolleret den 8. september 2026. Det udfyldte eksempel er en forenklet demonstration af arbejdsgangen.