Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
En IR-rapport kan bære en skadeopgørelse, når fire ting fremgår tydeligt: hvordan angriberen kom ind, hvornår det skete, hvad der blev ramt, og hvilke data konklusionerne bygger på. Mangler én af dem, er rapporten en beretning om en genopretning, ikke dokumentation af et skadeforløb. Denne tjekliste er skrevet til skadebehandlere og tekniske rådgivere hos forsikringsselskaber, der skal læse en rapport, som de ikke selv har bestilt.
Hvorfor IR-rapporter ofte ser ud, som de gør, og hvad forfatteren kan gøre bedre, er beskrevet i IR-rapporten som bevis. Her er vinklen modtagerens: hvad skal du kigge efter, og hvad skal du spørge om.
1. Opdrag og afgrænsning
Start med rapportens egen beskrivelse af opdraget. Hvem bestilte undersøgelsen, hvornår begyndte den, og hvad var målet? En IR-leverandør, der er hyret til at få driften op hurtigst muligt, har typisk ikke haft til opgave at fastlægge indgangsvejen med sikkerhed. Det er ikke en fejl, men det skal fremgå.
- Står det, hvilke systemer der indgik, og hvilke der ikke gjorde?
- Er der en dato for, hvornår analysen blev afsluttet, så senere fund kan holdes adskilt?
- Er det klart, om rapporten er endelig eller foreløbig?
2. Indgangsvejen
Indgangsvejen er ofte det punkt, dækningen afhænger af. Kig efter, om konklusionen hviler på direkte spor eller på en slutning.
- Direkte spor: fx en loginhændelse fra en ekstern adresse på en bestemt konto, en udnyttet sårbarhed med tilhørende logpost eller en ondsindet vedhæftning, der kan følges til første proces.
- Slutning: fx “angriberen kom sandsynligvis ind via VPN, fordi VPN-løsningen havde en kendt sårbarhed”. Det kan være rigtigt, men det er en hypotese, indtil logs viser det.
Spørg efter de konkrete poster, der understøtter konklusionen, og om alternative indgangsveje er undersøgt og afvist. Metoden er beskrevet i indgangsvejen: sådan underbygges konklusionen.
3. Tidspunktet for første kompromittering
Forsikringens periode, karensregler og spørgsmålet om, hvornår sikringsforanstaltningerne skulle være på plads, gør tidspunktet afgørende. Rapporten bør angive et interval med en tidligste og seneste grænse, ikke ét tidspunkt uden forbehold.
- Er tidspunktet angivet i UTC eller med tydelig tidszone?
- Står det, om det tidligste spor kan være et resultat af logrotation, så de reelle spor er ældre end loggene?
- Er initial adgang og egentlig aktivitet holdt adskilt?
Fejlkilderne er gennemgået i dwell time: hvornår kom angriberen ind?.
4. Omfanget
Omfang har to sider: hvilke systemer angriberen var på, og hvilke data der blev tilgået eller kopieret. Kig efter, om rapporten skelner mellem “berørt”, “tilgået” og “eksfiltreret”. De tre ord bruges ofte i flæng, men betyder noget forskelligt for både databrudsvurderingen og skadeopgørelsen.
- Bygger påstanden om dataudtræk på netværksdata, logs over filadgang, spor af komprimeringsværktøjer eller angriberens egen påstand på en lækageside?
- Er mængden målt eller skønnet?
- Er systemer, der ikke kunne undersøges, nævnt som ukendte i stedet for at blive udeladt?
5. Rådata og integritet
En rapport uden adgang til de data, den bygger på, kan ikke efterprøves. Spørg efter en liste over sikrede kilder med hashværdier, sikringstidspunkt og værktøj.
- Er der forensiske kopier af de centrale maskiner, eller kun EDR-telemetri og skærmbilleder?
- Findes logeksporterne stadig, og i hvilket format?
- Hvem har dataene nu, og hvor længe opbevares de?
Hvis kopierne er slettet efter genopretningen, kan konklusionerne ikke længere testes. Det betyder ikke, at de er forkerte, men det bør vægte i vurderingen.
6. Indgreb under hændelsen
IR-arbejde ændrer systemerne: maskiner isoleres, konti nulstilles, malware fjernes, servere geninstalleres. Rapporten bør indeholde en indgrebslog med tidspunkter, så det er muligt at skelne spor efter angriberen fra spor efter undersøgelsen.
- Er det angivet, hvad der blev ændret før sikringen?
- Er backup brugt til genopretning, og er det dokumenteret, at backuppen var fri for angriberens værktøjer?
7. Sikringsniveauet før hændelsen
Mange skadesager drejer sig om, hvorvidt de oplyste sikkerhedsforanstaltninger faktisk var i drift. IR-rapporten er ofte den eneste tekniske kilde til det. Kig efter, om MFA, backup, patchniveau og logning er beskrevet som konfiguration på hændelsestidspunktet eller som det, kunden oplyste. Forskellen er beskrevet i dokumentation af sikkerhedsniveauet før hændelsen.
8. Konklusionernes sikkerhed
En god rapport angiver, hvor sikker hver konklusion er, og skelner mellem bekræftet, sandsynligt og muligt. Vær opmærksom på formuleringer som “der er intet, der tyder på”, når det ikke fremgår, om der overhovedet var data at kigge i. Fravær af spor i en log, der kun gik tre dage tilbage, siger meget lidt om de foregående måneder.
9. Uvildighed og roller
IR-leverandøren arbejder for forsikringstageren og har ofte også en driftsrolle eller en løbende kontrakt. Det udelukker ikke en korrekt rapport, men det er relevant, hvis konklusionerne berører leverandørens eget arbejde, fx en konfiguration leverandøren selv har sat op. Spørg, hvem der har skrevet rapporten, om forfatteren har haft andre opgaver for kunden, og om nogen uden for IR-teamet har gennemgået den. Spørg også, om rapporten er redigeret efter dialog med forsikringstageren eller dennes rådgivere, og i givet fald om tidligere versioner kan udleveres. Ændringer mellem udkast og endelig version er ikke i sig selv et problem, men forskelle i konklusionerne bør kunne forklares med nye fund.
10. Sammenhæng med skadeopgørelsen
Omkostningerne i en cyberskade er ofte opgjort pr. system: hvor mange servere der blev genopbygget, hvor mange klienter der blev geninstalleret, og hvor længe driften stod stille. Hold disse tal op mod rapportens tekniske fund. Hvis rapporten kun beskriver kompromittering af tre servere, men skadeopgørelsen omfatter genopbygning af hele miljøet, skal forskellen forklares. Det kan være fuldt berettiget som forebyggende tiltag, når man ikke kan udelukke, at angriberen har været andre steder, men så skal begrundelsen stå et sted. Det samme gælder nedetid: knyt den til tidspunkter i indgrebsloggen, ikke kun til et samlet antal dage.
Når tvivlen ikke kan løses ved spørgsmål
Hvis svarene ikke er tilstrækkelige, er næste skridt en uafhængig efterprøvning på grundlag af rådata. Det kræver adgang til kopierne og logeksporterne, og jo før det sker, jo mindre er risikoen for, at de er slettet. Nielco IT kan efterprøve IR-rapporter uvildigt og har selv indsigt i og erfaring med incident response og hackerangreb. Det sker ved siden af IR-leverandøren, ikke i stedet for den. Hvordan en sådan gennemgang foregår, er beskrevet i second opinion på en IR- eller forensic-rapport. Den juridiske side af forsikringssager efter angreb findes på digital-bevissikring.dk.
Tjeklisten samlet
- ☐ Opdrag, afgrænsning og status er beskrevet
- ☐ Indgangsvejen er underbygget af konkrete poster
- ☐ Første kompromittering er angivet som interval med tidszone
- ☐ Omfang skelner mellem berørt, tilgået og eksfiltreret
- ☐ Sikrede kilder er listet med hashværdier og opbevaringssted
- ☐ Indgreb under hændelsen er logget med tidspunkter
- ☐ Sikringsniveauet er dokumenteret som konfiguration, ikke kun oplyst
- ☐ Konklusionernes sikkerhed er angivet
- ☐ Forfatterens roller og eventuelle bindinger fremgår
Kilder og versioner
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- ISO/IEC 27043:2015, principper og processer for hændelsesundersøgelser
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Undersøgelse efter et hackerangreb
Læs også: Hændelse hos flere kunder på én gang · NIST SP 800-61 og bevissikring under incident response
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For forsikring · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
