Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
Et driftstab regnes i kroner af økonomifunktionen eller revisor, men det hviler på tekniske tidspunkter: hvornår hvert system faldt ud, hvornår det var delvist i drift, og hvornår det var fuldt tilbage. IT-siden skal levere de tidspunkter pr. system med kilde og usikkerhed, og den skal kunne forklare, hvorfor genopretningen tog den tid, den tog. Begge dele bliver efterprøvet, både af forsikringsselskabet og af en eventuel modpart i et regreskrav.
Hvordan advokaten bygger opgørelsen op, er beskrevet på digital-bevissikring.dk, og hvad virksomheden selv skal holde styr på, i ransomware og forsikringen. Her er det de tekniske data.
Nedetid pr. system
Start med en liste over forretningskritiske systemer og deres afhængigheder. Et ordresystem kan være oppe, men ubrugeligt, hvis databasen, godkendelsen eller integrationen til lageret er nede. For hvert system fastlægges tre tidspunkter: udfald, delvis drift og fuld drift. Kilder:
- Overvågning: tilgængelighedstjek og alarmer med tidspunkter. Se monitoreringsdata som bevis.
- Windows-hændelseslogs: fx Event ID 6005 og 6006, når hændelseslogtjenesten starter og stopper, Event ID 6008 ved uventet nedlukning, og Event ID 1074 ved en nedlukning sat i gang af en bruger eller proces. Se Event ID-opslag.
- Hypervisoren: hændelser for start, stop og gendannelse af virtuelle maskiner.
- Applikationslogs og webserverlogs: første og sidste vellykkede transaktion. Se webserverlogs.
- Ransomwarens egne spor: tidsstempler på krypterede filer og løsesumsbeskeder markerer, hvornår systemet blev ramt.
Logs fra krypterede systemer kan selv være ramt. Brug derfor kilder uden for det ramte miljø, fx overvågning hos en ekstern udbyder eller logs sendt til et SIEM, og notér, hvilke tidspunkter der hviler på én kilde alene.
Lever resultatet som en tabel med én linje pr. system og tidspunkt: system, hændelse (udfald, delvis drift, fuld drift), tidspunkt i UTC, oprindelig tidszone, kilde, henvisning til den konkrete post og en vurdering af usikkerheden. Er to kilder uenige, fx overvågningen og serverens egen log, så vis begge og forklar forskellen i stedet for at vælge den, der passer bedst. Et tilgængelighedstjek, der kører hvert femte minut, kan ikke placere et udfald mere præcist end inden for fem minutter, og det skal fremgå.
Hvornår er et system tilbage?
Definitionen af “fuld drift” skal ligge fast, før tidspunkterne fastsættes. Et system kan være startet, men uden data fra de seneste dage, uden integrationer eller kun åbent for nogle brugere. Brug en funktionel definition: første vellykkede transaktion af den type, systemet findes for, fx en bogført ordre eller en afsendt faktura. Det tidspunkt kan dokumenteres i applikationens egne data og er sværere at bestride end et tidspunkt for, hvornår en server svarede på ping.
Delvis drift og nødprocedurer
Mange virksomheder arbejder videre på papir, i regneark eller i reservesystemer. Det er ikke fuld drift, men heller ikke stilstand. Dokumentér perioden med delvis drift for sig og beskriv, hvilke funktioner der virkede. Typiske spor er mails med ordrer, regneark oprettet i perioden og senere efterregistrering i ordre- eller økonomisystemet.
Efterregistreringen er vigtig. Ordrer, der blev taget manuelt og bogført efter genstarten, er ikke tabt omsætning. Bogføringsdato og oprettelsestidspunkt i systemet adskiller sig, og forskellen kan vise, hvad der blev indhentet. Se database og transaktionslog.
Aktivitetsdata som grundlag
Tidspunkter for nedetid siger ikke alene, hvor stort tabet var. Det kræver aktivitetsdata: ordrer, transaktioner, produktionsenheder eller fakturerbare timer pr. time eller dag. Træk dem for:
- en sammenlignelig periode før hændelsen, fx de samme uger året før og ugerne lige før,
- perioden med udfald og delvis drift,
- perioden efter genstart, til aktiviteten igen svarer til niveauet før.
Den tekniske opgave er at sikre data uændret, med beskrivelse af forespørgslen, der trak dem, og med hashværdi for udtrækket. Træk så vidt muligt på enkelttransaktioner frem for færdige rapporter, så aggregeringen kan gentages og kontrolleres. Datamængder fra den periode, hvor systemet var nede, kan være nul, fordi intet blev registreret, ikke fordi intet skete. Forklar det i rapporten. Sæson, kampagner og andre forhold skal vurderes af dem, der kender forretningen. Den tekniske rapport bør ikke selv konkludere, at et fald skyldes angrebet.
Genopretningstid
Varigheden er ofte det mest omstridte. Forsikringsselskabet eller en leverandør kan gøre gældende, at genopretningen burde have gået hurtigere. Del genopretningstiden op i faser, hver med start og slut fra logs:
- Inddæmning og sikring · Indgrebslog, EDR-isolering, sikringslog
- Klargøring af miljø · Tickets, hypervisor- og netværkslogs
- Gendannelse af data · Gendannelsesjob med start, slut og datamængde
- Test og genstart · Tickets, applikationslogs, første transaktion
- Ventetid · Tickets og mails om udstyr, licenser og beslutninger
Gendannelsesjob viser datamængde og varighed og dermed den opnåede hastighed. Den kan sammenholdes med den hastighed, backupløsningen var dimensioneret til. Ventetid, fx på nyt udstyr, bør stå for sig, så det er tydeligt, hvilken del af forløbet der var teknisk betinget. Se indgrebslog under incident response og backup og gendannelse som forensisk metode.
RTO og RPO som målestok
Har virksomheden en beredskabsplan, angiver den ofte genopretningsmål: RTO, den tid et system må være nede, og RPO, hvor meget data der højst må gå tabt målt i tid. NIST SP 800-34 bruger begreberne i sin konsekvensanalyse sammen med MTD, den maksimalt acceptable nedetid. Målene er nyttige som målestok, men kun hvis de var besluttet før hændelsen. Sammenhold de faktiske tider med målene pr. system, og vis, hvor afvigelserne opstod. Var målene aldrig testet, bør det fremgå.
RPO har også betydning for tabet. Var den nyeste brugbare backup flere dage gammel, skal data fra perioden genskabes manuelt, og den indsats er en selvstændig post.
Sikringens egen indvirkning
Sikring af beviser kan forlænge nedetiden, fx hvis servere holdes nede, mens der tages diskkopier. Dokumentér i indgrebsloggen, hvilke systemer der ventede på sikring, hvor længe og hvorfor. Hvor det var muligt at sikre parallelt med genopretningen, bør det også fremgå. Se ransomware: bevissikring parallelt med genopretning.
Typiske fejl
- Én samlet nedetid for hele virksomheden i stedet for tidspunkter pr. system.
- Tidspunkter hentes alene fra logs på de krypterede systemer.
- Efterregistrerede ordrer tælles som tabt omsætning.
- Aktivitetsdata trækkes uden dokumentation af forespørgsel og afgrænsning.
- Ventetid og teknisk gendannelsestid blandes sammen.
- Tidszoner blandes mellem overvågning, servere og forretningssystemer.
Hvad data kan og ikke kan bevise
Tekniske data kan vise, hvornår systemer var nede og oppe, hvordan aktiviteten faldt og steg, og hvad der bestemte genopretningstiden. De kan ikke alene vise, at et fald i omsætningen skyldes angrebet, og de kan ikke sætte beløb på tabet. Den skadesundersøgelse, der fastlægger årsag og omfang, er beskrevet i skadesundersøgelse for forsikringsselskabet.
Kilder og versioner
- NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
- ISO 22301:2019, Business continuity management systems
- NIST SP 800-61 Rev. 3: incident response
Senest gennemgået: oktober 2026.
Næste skridt
- Forsikringstvist: dokumentation af sikkerhedsniveauet før hændelsen
- Persondatabrud på 72 timer: de tekniske fakta, der skal være fastlagt
- Hvilke persondata blev berørt? Teknisk afgrænsning af et databrud
Del af: Undersøgelse efter et hackerangreb
Læs også: Regres: teknisk dokumentation af leverandørens andel i et angreb · Forensic eller incident response? Forskellen og samspillet
→ 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
