Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen
En incident response-rapport er skrevet for at inddæmme en hændelse og få driften i gang igen. Når den senere skal bruges i en tvist, fx med en IT-leverandør, et forsikringsselskab eller en samarbejdspartner, mangler den typisk fire ting: en beskrivelse af metoden, henvisninger til de kilder, hver påstand bygger på, en tydelig angivelse af usikkerhed og en dokumentation af, at de underliggende data er sikret og uændrede. Rapporten er ikke værdiløs uden dem, men dens konklusioner bliver lette at anfægte. Forskellen mellem de to discipliner er beskrevet i forensic eller incident response.
Hvorfor IR-rapporter ser ud, som de gør
En IR-rapport skrives under tidspres og til en læser, der skal handle: ledelsen, IT-driften, måske forsikringsselskabet. Formålet er at svare på, hvad der skete, om angriberen stadig er inde, og hvad der skal rettes. Derfor er rapporten ofte kort, præget af hypoteser og fokuseret på anbefalinger. Det er et rimeligt valg til formålet. Problemet opstår, når den samme rapport senere skal tåle en modparts sagkyndige.
De typiske mangler
- Ingen metodebeskrivelse · Fundene kan ikke efterprøves
- Påstande uden kildehenvisning · Det kan ikke ses, om en konklusion bygger på data eller antagelse
- Bekræftet og formodet blandet sammen · Formodninger læses som fakta
- Skærmbilleder fra konsoller i stedet for eksporter · De underliggende data kan ikke kontrolleres
- Ingen hashværdier · Det kan ikke vises, at data er uændrede
- Tidspunkter uden tidszone · Rækkefølgen kan anfægtes
- Indgreb ikke registreret · Egne handlinger kan forveksles med angriberens
- Ingen begrænsninger · Læseren kan ikke se, hvad der ikke blev undersøgt
Metode og kilder
Den vigtigste enkeltmangel er koblingen mellem påstand og kilde. “Angriberen fik adgang via VPN den 3. marts” kan være rigtigt, men en modpart vil spørge: Hvilken log viser det? Hvilken post? Hvornår blev loggen eksporteret, og af hvem? Uden svar står påstanden alene.
En IR-rapport, der skal kunne bruges som bevis, bør for hvert centralt fund angive kilden, fx en bestemt logkilde, et bestemt system og en bestemt tidsperiode, og hvordan data er hentet. Brug af telemetri fra EDR eller SIEM kræver særligt, at data er eksporteret fra konsollen, fordi de ellers forsvinder, når opbevaringsperioden udløber. → SIEM-data som bevis
Bekræftet, sandsynligt og formodet
Under en hændelse arbejder alle med hypoteser. Det er nødvendigt. Men i rapporten skal det være tydeligt, hvilke konklusioner der er bekræftet i data, hvilke der er sandsynlige, og hvilke der er arbejdshypoteser, der aldrig blev afprøvet. En fast skala, som også bruges i forensiske rapporter, gør forskellen synlig.
Særligt indgangsvejen er udsat. Den er ofte den konklusion, en tvist handler om, fx når spørgsmålet er, om en leverandør burde have lukket en sårbarhed. Samtidig er den ofte bygget på indicier, fordi de tidligste logs er udløbet. → Indgangsvejen: sådan underbygges konklusionen
Data og integritet
En IR-rapport bygger typisk på data, der er hentet i hast, og som ikke altid er sikret, så integriteten kan vises. Tre forhold går igen:
- Data blev analyseret direkte i kilden, fx i en EDR-konsol eller et SIEM, uden at blive eksporteret.
- Eksporter blev ikke hashet, så det ikke kan vises, at de er de samme i dag.
- Systemer blev genopsat, før der blev taget kopier, så de oprindelige spor er væk.
Det første og det andet kan ofte afhjælpes bagefter, så længe data stadig findes. Det tredje kan ikke. Derfor bør bevissikring foregå parallelt med genopretning, selv når fokus er drift.
Indgreb under hændelsen
Isolering af maskiner, nulstilling af adgangskoder, sletning af ondsindede filer, genstart og genopsætning ændrer alle de spor, en senere analyse bygger på. Er indgrebene ikke registreret med tidspunkt og person, kan de ikke skelnes fra angriberens handlinger. En log over indgreb er derfor en forudsætning for, at IR-arbejdet kan bruges som bevis. → Log over indgreb under incident response
Tidspunkter i en IR-rapport er ofte skrevet ned i forskellige tidszoner, fordi de stammer fra forskellige konsoller og fra mennesker, der noterede klokkeslæt i lokal tid. Før rapporten bruges i en tvist, bør alle tidspunkter kontrolleres mod kilden og normaliseres. Især tidspunktet for den første opdagelse og for de første indgreb er ofte omtvistet, fordi de har betydning for, om der blev handlet rettidigt.
Rollerne i rapporten
Er IR udført af den IT-leverandør, hvis sikkerhed tvisten handler om, har rapporten et indbygget troværdighedsproblem, uanset hvor godt arbejdet er udført. Det samme gælder, hvis den er bestilt af den part, der har en interesse i en bestemt indgangsvej. Det bør fremgå af rapporten, hvem der har udført arbejdet, for hvem, og om forfatteren har en rolle i de systemer, der undersøges. Det sikrer ikke uvildighed, men det gør det muligt for læseren at vurdere den.
Sådan rettes manglerne bagefter
Står en IR-rapport til at blive brugt i en tvist, kan dens grundlag ofte styrkes. En realistisk fremgangsmåde:
- Kortlæg, hvilke data der stadig findes: logs, eksporter, images, EDR-data, backup af berørte systemer.
- Sikr dem nu med hashværdier og dokumenteret kæde af ansvar (chain of custody), før opbevaringsperioder udløber.
- Gennemgå rapporten påstand for påstand, og knyt hver påstand til en kilde, eller markér den som uunderbygget.
- Klassificér konklusionerne som bekræftet, sandsynlig eller formodet.
- Rekonstruér indgrebene ud fra tickets, chatlogs og systemlogs, så de kan skelnes fra hændelsen.
- Skriv et selvstændigt teknisk dokument, der bygger på IR-arbejdet, men opfylder kravene til en forensisk rapport, frem for at omskrive IR-rapporten.
Det sidste punkt er vigtigt. Den oprindelige rapport bør bevares uændret, fordi den viser, hvad man vidste og gjorde på tidspunktet. Et nyt dokument kan henvise til den og præcisere den. En uvildig gennemgang af en eksisterende rapport kan være første skridt. → Second opinion på en IR- eller forensic-rapport
Forsikring og andre modtagere
Forsikringsselskaber beder ofte om tekniske oplysninger, der ligner dem, en tvist kræver: tidslinje, indgangsvej, omfang og sikkerhedsniveau før hændelsen. Er rapporten skrevet med de samme krav fra start, kan den bruges til begge formål, og risikoen for modstridende versioner falder. → Cyberforsikringen: de tekniske leverancer
Hvad en IR-rapport kan bære
Selv uden de forbedringer, der er beskrevet her, er en IR-rapport et dokument fra tidspunktet for hændelsen. Den kan vise, hvad organisationen vidste, hvornår, og hvad der blev gjort. Det kan have betydning i sig selv, fx når spørgsmålet er, om der blev handlet rettidigt. Hvad den ikke kan bære alene, er tekniske konklusioner, der ikke er knyttet til sikrede data, især om indgangsvej, omfang og hvem der var ansvarlig for en sårbarhed. De konklusioner skal underbygges, før de bruges.
Til næste hændelse
Det er billigere at skrive IR-rapporten bevisegnet første gang end at rette den bagefter. Indarbejd i jeres skabelon:
- ☐ Metodeafsnit med værktøjer og versioner
- ☐ Kildehenvisning ved hvert centralt fund
- ☐ Skala for bekræftet, sandsynligt og formodet
- ☐ Eksport og hashværdier for de data, konklusionerne bygger på
- ☐ Tidszone ved alle tidspunkter
- ☐ Log over indgreb som bilag
- ☐ Afsnit om begrænsninger og data, der ikke var tilgængelige
- ☐ Angivelse af, hvem der har udført arbejdet og for hvem
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: Kvalitet og standarder
Læs også: Typiske tekniske spørgsmål til metoden · Visualiseringer i forensiske rapporter: korrekte grafer og tidslinjer
→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
