Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
En teknisk skadesundersøgelse for et forsikringsselskab skal svare på tre spørgsmål: hvad der forårsagede skaden, hvornår de afgørende hændelser fandt sted, og hvilke systemer og data skaden omfatter. Den adskiller sig fra incident response ved, at målet ikke er at stoppe angrebet, men at fastlægge fakta, som en dækningsafgørelse og eventuelt et regreskrav kan bygge på. Undersøgelsen skal derfor skrives, så forsikringstageren, en IT-leverandør og en senere skønsmand kan efterprøve den.
Hvordan en IR-rapport læses af skadebehandleren, står i skadebehandlerens tjekliste, og hvilke leverancer forsikringstageren selv afleverer, i cyberforsikringens tekniske leverancer. Denne artikel handler om den undersøgelse, selskabet selv bestiller.
Opdraget
Undersøgelsen står og falder med opdraget. Et opdrag som “vurdér skaden” giver en rapport, der blander fakta, vurderinger og anbefalinger. Formulér i stedet konkrete spørgsmål:
- Hvad er indgangsvejen, og hvilket evidensniveau har konklusionen?
- Hvornår er det tidligste spor efter angriberens aktivitet?
- Hvornår blev hændelsen opdaget, og hvornår blev der reageret?
- Hvilke systemer blev kompromitteret, krypteret eller isoleret som forholdsregel?
- Hvilke dele af genopretningen genskaber den tidligere tilstand, og hvilke ændrer den?
Opdraget bør også sige, hvad der ikke undersøges. Spørgsmålet om, hvorvidt et forhold er dækket, er skadebehandlerens og ikke den tekniske undersøgers. Den tekniske rapport bør heller ikke konkludere, at en IT-leverandør er ansvarlig. Den kan beskrive, hvad leverandøren gjorde, og hvad det betød teknisk.
Adgang til data
Forsikringsselskabet har sjældent selv data. De ligger hos forsikringstageren, IR-leverandøren og driftsleverandøren. Undersøgeren skal derfor bede om dem, og anmodningen bør være præcis:
- diskkopier i et forensisk format med hashværdier fra sikringstidspunktet,
- logeksporter i oprindeligt format, fx EVTX og JSON, med angivelse af eksportfilter,
- EDR-telemetri og alarmer for hele perioden, ikke kun fra opdagelsen,
- IR-leverandørens indgrebslog og arbejdsnoter,
- konfigurationseksporter fra før genopretningen.
Registrér for hver kilde, hvem der har leveret den, hvornår, og hvilken hashværdi den havde ved modtagelsen. Kan en hashværdi ikke sammenholdes med en værdi fra sikringstidspunktet, så skriv det. Mangler en kilde, noteres det som en begrænsning, ikke som stilhed. Se overdragelse fra IR til sagkyndig og EDR-telemetri som bevis.
Årsag med evidensniveau
Indgangsvejen er det punkt, dækning og regres oftest drejer sig om. Angiv konklusionen sammen med et evidensniveau, fx:
- Påvist · Direkte spor af første adgang, fx et login eller en udnyttelse i en log
- Sandsynlig · Indirekte spor, der peger samme vej, uden direkte spor af første adgang
- Mulig · Forudsætningen var til stede, men der er ingen spor af brug
- Udelukket · Data viser, at vejen ikke blev brugt i perioden
Beskriv de alternative veje, der er undersøgt, og hvorfor de er forkastet eller ikke kan udelukkes. En sårbarhed, der fandtes på systemet, er ikke i sig selv indgangsvejen. Metoden er uddybet i indgangsvejen: sådan underbygges konklusionen.
Tidslinjen mod policeperioden
Dækningen kan afhænge af, hvornår skaden anses for indtruffet, og policer knytter det til forskellige tidspunkter. Den tekniske undersøgelse skal derfor levere tidspunkterne adskilt, så skadebehandleren kan bruge det, policen henviser til:
- det tidligste spor efter angriberens aktivitet,
- det første spor af skadevoldende handling, fx kryptering eller sletning,
- opdagelsen,
- de første indgreb.
Første kompromittering ligger ofte uger eller måneder før krypteringen. Forskellen kan have betydning, hvis den ligger på hver sin side af policens ikrafttræden eller fornyelse. Angiv for hvert tidspunkt kilden og usikkerheden, fx hvis tidligere logs er roteret væk, så den tidligste dato kun er en nedre grænse for, hvad der kan ses. Se dwell time og første kompromittering og tidslinjeanalyse.
Omfanget
Opgør systemer i grupper, så de ikke blandes:
- Kompromitteret: spor efter angriberens aktivitet på systemet.
- Ramt: krypteret, slettet eller ændret, uden nødvendigvis spor af interaktiv adgang.
- Isoleret eller genopsat som forholdsregel: ingen spor, men behandlet af sikkerhedsgrunde.
Den sidste gruppe er relevant for omkostningerne, men ikke for beskrivelsen af angrebets rækkevidde. For data skelnes mellem det, der med sikkerhed er hentet ud, det, der sandsynligvis er, og det, angriberen havde adgang til. Se ransomware: spor efter dataudtræk.
Genskabelse eller ændring
Efter et angreb bliver systemer sjældent genopbygget, præcis som de var. Undersøgelsen kan dokumentere forskellen ved at sammenholde konfigurationen før og efter: styresystemversion, licensniveau, ny backupløsning, nye sikkerhedsprodukter, ændrede politikker for godkendelse. Kilden til tilstanden før er konfigurationseksporter, backup af systemopsætningen, CMDB-data og leverandørens dokumentation. Resultatet er en liste pr. system med tre kolonner: før, efter og om ændringen var nødvendig for at genetablere driften. Hvordan forskellen håndteres i opgørelsen, er ikke undersøgerens afgørelse, men listen gør den mulig. Den økonomiske side er beskrevet for advokater i forsikringssager efter cyberangreb.
Uvildighed og roller
En undersøger bestilt af forsikringsselskabet arbejder for den part, der afgør dækningen. Det er ikke i sig selv et problem, men rapporten bliver stærkere, når metoden er åben: forsikringstageren får de samme rådata, kan stille spørgsmål, og rapporten skelner tydeligt mellem fund og vurdering. Har driftsleverandøren også håndteret hændelsen, bør det fremgå, hvilke konklusioner der hviler på leverandørens egne oplysninger.
Rapportens opbygning
En rapport, der skal kunne genbruges, holder tre lag adskilt: fund, der kan føres tilbage til en konkret post i rådata, vurderinger, der bygger på flere fund, og anbefalinger. Anbefalinger om forbedret sikkerhed hører hjemme i et separat bilag eller slet ikke i skadesrapporten, fordi de let læses som en konstatering af mangler, der ikke er påvist.
Oplysninger fra samtaler med forsikringstagerens medarbejdere eller leverandører markeres som det, de er: forklaringer, ikke tekniske fund. Hvor en forklaring er sammenholdt med logs, angives resultatet. Giv rapporten versionsnummer og dato, og før en ændringsliste, hvis nye data kommer til efter den første version. Vedlæg tidslinjen i maskinlæsbar form og en fortegnelse over modtagne kilder med hashværdier, så en anden sagkyndig kan begynde, hvor undersøgelsen slap.
Typiske fejl
- Opdraget beder om en samlet vurdering i stedet for konkrete tekniske spørgsmål.
- Indgangsvejen angives uden evidensniveau og uden afprøvede alternativer.
- Det tidligste synlige spor præsenteres som første kompromittering, selv om ældre logs mangler.
- Systemer isoleret som forholdsregel tælles med i angrebets rækkevidde.
- Rådata modtages uden hashværdier fra sikringstidspunktet.
Hvad undersøgelsen kan og ikke kan bære
En velbygget skadesundersøgelse kan bære en dækningsafgørelse og danne grundlag for et regreskrav, fordi den viser, hvad data understøtter, og hvor de ikke rækker. Den kan ikke afgøre, hvad policen dækker, og den kan ikke udfylde huller i logs med antagelser. Bruges den senere mod en leverandør, vil den blive efterprøvet af en part, der ikke var med. Se regres: leverandørens andel.
Kilder og versioner
- NIST SP 800-86: integration af forensiske teknikker i hændelseshåndtering
- NIST SP 800-61 Rev. 3: incident response
- ISO/IEC 27037: identifikation, indsamling og bevaring af digitale beviser
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Undersøgelse efter et hackerangreb
Læs også: IOC’er i en civil undersøgelse · Regres: teknisk dokumentation af leverandørens andel i et angreb
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
