Forensic readiness‑test: kan logningen bære en undersøgelse?

Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen

Den eneste pålidelige måde at vide, om logningen kan bære en undersøgelse, er at teste den: udfør kendte handlinger på et aftalt tidspunkt, find sporene i de logs, der skulle have registreret dem, eksportér dem, som det ville ske i en sag, og kontrollér, at felter og tidsstempler er korrekte. Gentag kontrollen efter nogle uger for at se, om hændelserne stadig findes. En konfigurationsgennemgang viser, hvad der burde ske. Testen viser, hvad der faktisk sker.

Den tekniske baseline, testen holdes op imod, er beskrevet i forensic readiness teknisk: baseline for logning, opbevaring og tidssynkronisering. Ledelsens spørgeskema til samme emne findes på bevissikring-digitalt.dk. Her er den tekniske testprocedure, som IT-afdelingen, SOC’en eller IT-revisionen kan gennemføre.

Princippet

Hver test følger samme kæde: en kendt handling, et forventet spor, en søgning, en eksport og en kontrol. Hvis kæden brydes et sted, er det et hul, der også ville have ramt en rigtig sag. Det er ikke nok, at hændelsen kan ses i en konsol. Den skal kunne eksporteres i et format, der bevarer felterne, inden for den tid og med de rettigheder, der ville være til rådighed under en hændelse. Testen bør derfor udføres af de personer, der rent faktisk skulle sikre sporene i en sag, og ikke kun af den specialist, der har opsat logningen. Det er også en øvelse i selve fremgangsmåden.

Forberedelse

Testplan: en liste over scenarier med forventede spor og ansvarlige.
Testkonti og testmaskiner: navngivet, så de tydeligt kan genkendes som test, fx med et fast præfiks. Brug en almindelig klient, ikke administratorens egen maskine.
Tid: notér hvert trin med tidspunkt fra en synkroniseret kilde, med sekunder og tidszone.
Godkendelse: testen godkendes i ændringsstyringen. Beslut, om SOC’en skal orienteres på forhånd, eller om detektion også testes.
Testlog: før en handlingslog over alt, der udføres. Den gør det også muligt senere at genkende testhændelserne, hvis de dukker op i en rigtig undersøgelse.

Testscenarier

Interaktivt login og RDP-login med testkonto · 4624 med logontype 2 og 10, Kerberos-hændelser på domænecontrolleren
Fejlet login · 4625 på klient eller server
Oprettelse af lokal bruger og tilføjelse til gruppe · 4720 og 4732
Proces startet med argumenter · 4688 med kommandolinje
Kørsel af et ufarligt PowerShell-script · 4104 i PowerShell-loggen
Login i Microsoft 365 og oprettelse af en indbakkeregel · Loginlog i Entra ID og New-InboxRule i revisionsloggen
Download af en testfil fra SharePoint · FileDownloaded i revisionsloggen
VPN-forbindelse fra kendt adresse · Session i VPN- og firewall-loggen

Hvilke indstillinger der skal være slået til, for at Windows-hændelserne overhovedet logges, er beskrevet i Windows audit policy. Tilpas listen til miljøet: et Linux-miljø, et ERP-system eller en SaaS-platform har sine egne scenarier.

Find sporet

For hvert scenarie registreres:

om hændelsen blev fundet, og i hvilke kilder,
hvor lang tid det tog at finde den,
hvem der kunne finde den, og med hvilke rettigheder,
om leverandøren skulle involveres.

Et spor, der kun kan findes af én bestemt medarbejder eller kun med leverandørens hjælp, er en risiko, selv om det findes.

Eksportér sporet

Eksportér hændelserne, som det ville ske i en sag: fra kildesystemet, i oprindeligt format, med hashværdi. Notér, om eksporten havde begrænsninger, fx et maksimalt antal rækker, felter, der faldt fra, eller tidsstempler, der blev omregnet. Mange problemer viser sig først her: en konsol kan vise et felt, som eksportformatet ikke indeholder.

Verificér felter og tid

Sammenlign de eksporterede tidsstempler med testloggen. En afvigelse på mere end nogle sekunder tyder på et ur, der ikke er synkroniseret, eller på en tidszone, der ikke er angivet. Kontrollér, at de felter, en undersøgelse har brug for, er udfyldt: bruger, enhed, IP-adresse, proces, kommandolinje og resultat. Kontrollér også, at samme handling kan genfindes og kobles på tværs af kilderne, fx samme login i Entra ID, i VPN-loggen og på klienten.

Mål den reelle opbevaring

Konfigureret opbevaring og reel opbevaring er ikke det samme. Windows-logs overskrives, når de er fulde, og en travl server kan miste uger på dage. Mål derfor:

den ældste hændelse i hver log på testdagen,
om testhændelserne stadig findes efter en aftalt periode, fx 30 og 90 dage.

Det er den målte værdi, der skal stå i oversigten over logkilder, ikke den konfigurerede. Hvordan Windows’ logstørrelse og overskrivning hænger sammen, er beskrevet i hvor længe gemmes Windows’ event log?.

Arkiverede logs og backup

Mange organisationer flytter ældre logs til et arkiv, et billigere lager eller en backup. Det tæller kun som opbevaring, hvis de kan hentes frem igen. Test derfor også, at en arkiveret log fra en given dato kan gendannes, åbnes og søges i, og notér, hvor lang tid det tager. En gendannelse, der kræver en leverandør og flere dages ventetid, kan være for langsom, hvis en anden kilde roterer imens. Kontrollér samtidig, at arkivet bevarer de oprindelige felter og tidsstempler, og ikke kun en komprimeret eller sammenfattet version.

Ud over Windows og Microsoft 365

De samme principper gælder for andre kilder. I et ERP- eller regnskabssystem kan testen bestå i at ændre et felt på en teststamdatapost og kontrollere, at ændringsloggen viser gammel og ny værdi, bruger og tidspunkt. I en SaaS-platform kan det være en test af, om administratorhandlinger kan eksporteres, og hvor langt tilbage de findes. For firewall og VPN kan en forbindelse fra en kendt adresse på et kendt tidspunkt vise, om NAT-oversættelser og sessionsdata gemmes. Vælg de kilder, som en sandsynlig sag i netop jeres organisation ville afhænge af.

Resultatet

Saml resultatet i en matrix med én række pr. kilde: fundet ja/nej, tid til at finde, eksport mulig, manglende felter, tidsafvigelse, ældste hændelse og ansvarlig. Hvert hul får en handling og en frist. Matrixen er samtidig dokumentation for, at organisationen har testet sin evne til at sikre spor, hvilket kan være relevant over for revisor, forsikring eller tilsyn.

Hyppighed

Gentag testen mindst én gang om året og efter væsentlige ændringer: ny MSP, ny SIEM-løsning, ændret licensniveau, migrering til cloud eller nye logpolitikker. Mange huller opstår ikke ved en fejl, men ved en ændring, der ingen tænkte på havde betydning for logningen.

Faldgruber

Test på det forkerte udstyr: administratorens maskine har ofte andre indstillinger end almindelige klienter.
SIEM uden rådata: hændelsen ses i SIEM’et som en normaliseret post, men den rå hændelse gemmes ikke.
Ingen opfølgning: hullerne noteres, men lukkes ikke.
Testhændelser uden mærkning: en senere undersøgelse støder på testkontoens aktivitet og må bruge tid på at forklare den.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Kvalitet og standarder

Læs også: Fra revisionsbevis til forensisk bevis · SWGDE’s vejledninger: hvad de dækker, og hvordan de bruges i civile sager

→ Second opinion på en IR- eller forensic-rapport · For IT-revision · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik