Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
Incident response (IR) har ét hovedmål: at stoppe hændelsen og få driften tilbage så hurtigt og sikkert som muligt. Digital forensic har et andet: at fastlægge og dokumentere, hvad der skete, på en måde, som en anden fagperson kan efterprøve. De to discipliner bruger mange af de samme værktøjer og data, og i praksis kaldes de ofte samlet DFIR. Men de stiller forskellige krav til, hvordan data håndteres, og konflikten mellem dem opstår typisk i de første timer.
To mål, to tidshorisonter
- Spørgsmål · Incident response: Hvordan stopper vi det? · Forensic: Hvad skete der, og hvordan ved vi det?
- Tidshorisont · Incident response: Timer og dage · Forensic: Uger og måneder, ofte frem til en tvist
- Succes · Incident response: Driften kører, angriberen er ude · Forensic: Konklusionen kan efterprøves
- Data · Incident response: Brugt til beslutninger · Forensic: Bevaret som bevis
IR-teamet arbejder under tidspres og træffer beslutninger på ufuldstændige data. Det er rigtigt i situationen. Men en beslutning som “reimage alle klienter i afdelingen” fjerner samtidig de artefakter, der senere skulle vise, hvordan angriberen bevægede sig rundt. Forensic arbejder modsat: først bevares data, så analyseres de, og analysen dokumenteres, så den kan gentages.
Hvor de mødes
Overlappet er stort. Begge discipliner bruger EDR-telemetri, hændelseslogs, loginlogs, netværksdata og hukommelse. Begge bygger tidslinjer. Forskellen ligger i håndteringen:
- Indsamling. IR henter ofte data direkte fra et kørende system via EDR eller fjernværktøjer for at svare hurtigt. Forensic vil have en verificerbar kopi med hashværdi og dokumenteret fremgangsmåde. Begge dele kan lade sig gøre samtidig, hvis det er planlagt. Se Live response.
- Notater. IR-noter er ofte chatbeskeder og tickets. Forensic kræver en log over, hvem der gjorde hvad på hvilket system og hvornår. Uden den kan ingen bagefter skelne angriberens handlinger fra forsvarernes.
- Konklusioner. IR kan handle på en sandsynlig hypotese. Forensic skal angive, hvor sikker konklusionen er, og hvilke alternative forklaringer der er undersøgt.
Typiske konflikter
Inddæmning før sikring. At isolere en maskine i EDR er som regel uproblematisk, fordi den fortsætter med at køre. At slukke, reimage eller gendanne fra backup er det ikke. Hukommelse, kørende processer og netværksforbindelser forsvinder, og gendannelse overskriver diske. Rækkefølgen bør derfor være: isolér, sikr det flygtige, sikr disken eller et snapshot, og først derefter genopret. Hvad isolering konkret gør ved artefakterne, er beskrevet i Isolering og genopsætning.
Logs med kort opbevaring. IR-teamet kigger i loggene, men eksporterer dem ikke nødvendigvis. Når hændelsen er slut, kan loggene være roteret. Forensic kræver eksport med hash og dokumentation af, hvad der blev eksporteret.
Oprydning, der ligner angreb. Når IR-teamet sletter konti, fjerner persistens og nulstiller adgangskoder, skaber det hændelser i de samme logs, som angriberen har efterladt spor i. Uden en log over indgreb kan rækkefølgen ikke rekonstrueres. Skabelonen og fremgangsmåden står i Log over indgreb under incident response.
Rapporten skrevet til driften. En IR-rapport er typisk skrevet til ledelse og IT og fokuserer på anbefalinger. Den mangler ofte metodebeskrivelse, kildehenvisninger og usikkerhed. Det bliver et problem, hvis den senere skal bruges i en forsikringssag eller en tvist med en leverandør. Se IR-rapporten som bevis.
Samme team eller to teams?
I mindre hændelser er det ofte de samme personer, der både inddæmmer og sikrer. Det kan fungere, hvis rollerne er tydelige: én person ad gangen har ansvaret for sikringen og fører loggen. I større hændelser er det en fordel at adskille opgaverne, så den forensiske sikring ikke venter på driftsbeslutninger, og så de personer, der skal forklare konklusionerne bagefter, ikke også har truffet de beslutninger, der skal vurderes.
Er der en mulig tvist med den IT-leverandør, der står for driften eller for IR, er uafhængigheden et selvstændigt hensyn. Leverandøren kan have en interesse i, hvordan indgangsvejen beskrives. Det betyder ikke, at leverandørens arbejde er forkert, men at det bør kunne efterprøves af en, der ikke var involveret.
Data og noter efter hændelsen
Når driften er genoprettet, lukkes IR-sagen typisk, og her går mange data tabt. Midlertidige analysemiljøer bliver slettet, EDR-licensen til den ekstra opbevaring udløber, og den eksterne IR-leverandør beholder sine noter og værktøjsoutput. Aftal derfor ved afslutningen, hvad der skal overdrages: rådata og eksporter med hashværdier, indgrebsloggen, værktøjsoutput og de tidslinjer, der blev bygget undervejs. Notér også, hvad der ikke blev sikret, og hvorfor.
Det er især vigtigt, hvis forsikringsselskabet har udpeget IR-leverandøren. Så er det ikke givet, at virksomheden har adgang til alle data bagefter, og det bør afklares tidligt, hvem der har ret til hvad. Uden rådata kan ingen anden fagperson efterprøve konklusionerne, og så står IR-rapportens udsagn alene.
Forensic readiness: forbered samspillet
Det meste af konflikten kan løses, før noget sker:
- Aftal i beredskabsplanen, hvad der sikres, før der reimages, og hvem der beslutter undtagelser.
- Sørg for, at EDR-værktøjet kan hente hukommelse og filer, og at opbevaringen af telemetri er kendt. Se EDR-telemetri som bevis.
- Send centrale logs til et system, som en kompromitteret administratorkonto ikke kan ændre.
- Hav en skabelon til indgrebslog klar, og øv brugen af den.
- Afklar, hvem der må udtale sig om årsagen, og hvornår.
Hvad det betyder for beviserne
Data indsamlet under IR kan sagtens bruges som bevis. Forudsætningen er, at det kan dokumenteres, hvordan data blev indsamlet, af hvem, hvornår og med hvilket værktøj, og at data ikke er ændret siden. Det, der svækker bevisværdien, er sjældent selve IR-arbejdet, men manglende dokumentation af det. En hukommelsesdump hentet via EDR uden hashværdi og uden notat om værktøjsversion er svær at forsvare. Den samme dump med hash, tidspunkt og en kort beskrivelse er god.
Standarderne siger det samme. ISO/IEC 27037 og NIST SP 800-86 beskriver identifikation, indsamling og bevaring, uanset om det sker under en hændelse eller bagefter. Se ISO/IEC 27037 og NIST SP 800-86. ISO/IEC 27035-serien om håndtering af sikkerhedshændelser og ISO/IEC 27037 om digitale beviser hører til samme standardfamilie og er tænkt til at supplere hinanden, så bevissikring indgår i hændelseshåndteringen frem for at komme bagefter. Serien revideres løbende, så angiv i en rapport, hvilke udgaver der er brugt.
Hvad kan forensic, som IR ikke kan?
Forensic kan ikke vise mere, end data indeholder. Men den forensiske tilgang tvinger tre ting frem, som IR ofte springer over: en eksplicit beskrivelse af metoden, en vurdering af alternative forklaringer og en angivelse af, hvor sikker hver konklusion er. Det er netop det, en modpart, et forsikringsselskab eller en skønsmand vil spørge til. Hvordan de juridiske aktører ser på samspillet, er beskrevet i Forsikringssager efter cyberangreb.
Omvendt kan IR noget, forensic ikke kan: handle hurtigt nok til at begrænse skaden. Det rigtige spørgsmål er derfor ikke “IR eller forensic”, men hvordan IR udføres, så den forensiske dokumentation ikke går tabt undervejs.
Kilder og versioner
- ISO/IEC 27037: Guidelines for identification, collection, acquisition and preservation of digital evidence
- ISO/IEC 27035-1: Information security incident management, principles and process
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- NIST SP 800-61 Rev. 3: Incident Response Recommendations
Senest gennemgået: oktober 2026.
Næste skridt
- Ransomware: bevissikring parallelt med genopretning
- Indgangsvejen: sådan underbygges konklusionen
- Dataudtræk før kryptering: spor efter eksfiltration
Del af: Undersøgelse efter et hackerangreb
Læs også: Driftstab og genopretningstid: tekniske data til tabsopgørelsen · Log over indgreb under incident response
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
