Forensic readiness teknisk: baseline for logning, opbevaring og tidssynkronisering

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

Forensic readiness betyder, at de data, en undersøgelse får brug for, allerede findes, er gemt længe nok, har korrekte tidsstempler og kan eksporteres uden at skulle opfindes under tidspres. For en MSP er det mest effektive at definere én teknisk baseline, der rulles ud hos alle kunder, og som kun afviges, når en kunde bevidst fravælger noget. Baselinen dækker fire ting: hvad der logges, hvor længe det gemmes, hvordan urene holdes synkrone, og hvordan data kommer ud.

Kundens kontraktvinkel, altså hvad kunden bør kræve af sin IT-leverandør, er beskrevet på bevissikring-digitalt.dk. Her er MSP’ens tekniske side.

Hvorfor en fælles baseline

De fleste hændelser hos MSP-kunder ligner hinanden: overtagne mailkonti, ransomware, en medarbejder, der tager data med, en tvist om leverancen. Spørgsmålene i undersøgelsen er også de samme: hvem loggede ind hvorfra, hvad blev ændret, hvornår skete det. Når baselinen er ens, ved MSP’en på forhånd, hvad der findes hos hver kunde, og eksportscripts kan genbruges.

En fælles baseline gør også afvigelser synlige. Når en kunde har fravalgt en licens eller en logkilde, er det noteret, og det kan forklares, hvis det senere viser sig at mangle.

Lag 1: hvad der logges

Windows-klienter og -servere

Standardopsætningen i Windows logger mindre, end en undersøgelse har brug for. En baseline bør som minimum omfatte avanceret auditpolitik for logon og logoff, kontoadministration, ændringer i sikkerhedsgrupper, procesoprettelse med kommandolinje samt adgang til udvalgte filshares. PowerShell-scriptblokkelogning bør være slået til. Detaljerne om de enkelte indstillinger er gennemgået i Windows audit policy: de indstillinger en undersøgelse har brug for.

Hændelseslogenes maksimale størrelse bør også hæves, fordi standardstørrelsen på sikkerhedsloggen kan være fyldt på få dage på en travl server. På mange installationer er den kun 20 MB. Den aktuelle værdi kan aflæses med wevtutil gl Security og hæves via gruppepolitikken for hændelseslogtjenesten.

Microsoft 365 og Entra ID

Unified Audit Log skal være slået til, og det skal kontrolleres, ikke antages.
Postkasseauditering skal være aktiv med de relevante handlinger.
Entra ID-loginlogs og auditlogs bør sendes til et lager med længere opbevaring, fx Log Analytics eller en lagerkonto, fordi standardopbevaringen i portalen er kort.
Opbevaringen i Purview Audit afhænger af licensen. Hvad forskellen mellem Standard og Premium betyder i praksis, er beskrevet i Audit Standard eller Premium.

Netværk og perimeter

Firewall-, VPN- og proxylogs bør sendes til en central logserver eller SIEM i stedet for kun at ligge på enheden, hvor de roterer hurtigt. DNS-logning fra de interne resolvere er en billig kilde med stor værdi. DHCP-logs gør det muligt at koble en IP-adresse til en enhed.

MSP’ens egne værktøjer

RMM, PSA og fjernadgangsværktøjer logger MSP’ens egne handlinger. De logs skal også være en del af baselinen, både fordi de dokumenterer, hvad MSP’en har gjort, og fordi de kan være angrebsvejen.

Lag 2: hvor længe det gemmes

En log, der er slettet, før hændelsen opdages, er ingen hjælp. Mange hændelser opdages først uger eller måneder efter den første kompromittering. En fornuftig baseline er:

Loginlogs og auditlogs i cloud · 12 måneder, eksporteret til eget lager, hvis licensen ikke dækker
Windows-sikkerhedslogs · Centraliseret og gemt i 12 måneder
Firewall, VPN, proxy, DNS · 6 til 12 måneder centralt
EDR-telemetri · Så længe licensen tillader, og alarmer eksporteret løbende
RMM- og fjernadgangslogs · 12 måneder
Backup · Mindst én uforanderlig kopi med tilstrækkelig historik

Tallene er en anbefalet baseline, ikke et lovkrav. Opbevaring skal også afvejes mod reglerne for persondata, og den konkrete periode bør besluttes og begrundes af kunden. Hvordan logs roterer, og hvordan de sikres, før de forsvinder, er beskrevet i logfiler og logrotation.

Lag 3: tidssynkronisering

En tidslinje på tværs af kilder kræver, at urene er enige. I et domæne synkroniserer klienter og servere normalt efter domænecontrolleren, som skal synkronisere efter en pålidelig ekstern kilde. Det lyder enkelt, men i praksis er der ofte huller: virtuelle maskiner, der følger værtens ur, netværksudstyr med manuelt indstillet tid, og enheder uden for domænet.

Baselinen bør angive:

én ekstern tidskilde for hele kundens miljø, fx via domænecontrolleren med PDC-rollen
NTP på alle netværksenheder, firewalls og NAS’er
at logs skrives i UTC eller med angivet tidszone
at hændelser for ændringer af systemtid logges

Urafvigelse kan korrigeres i analysen, men kun hvis den kendes. Se når enhedens ur går forkert.

Lag 4: eksportvejen

Det fjerde lag er det, der oftest mangler. At data findes, er ikke nok; MSP’en skal kunne få dem ud, fuldstændigt og dokumenteret, uden at skulle finde ud af det under en hændelse.

Hav afprøvede eksportscripts eller fremgangsmåder for loginlogs, auditlogs og postkasser pr. platform.
Sørg for, at der findes en konto eller app-registrering med de nødvendige læserettigheder, og at den er dokumenteret.
Afprøv eksporten mindst én gang om året pr. kunde, og notér tidsforbrug og eventuelle begrænsninger.
Hav et sted at lægge eksporterne med krypteret lagring og begrænset adgang.

Dokumentation pr. kunde

Baselinen giver først værdi, når der for hver kunde findes en kort oversigt over logkilder, opbevaringstider, licenser, tidskilder og eksportveje, og over hvad kunden har fravalgt. Et format til den oversigt findes i skabelon: teknisk datakort. Opdatér den, når kunden skifter licens, tilføjer systemer eller skifter leverandør.

Rækkefølgen ved indførelse

En fuld baseline hos alle kunder på én gang er sjældent realistisk. Prioritér efter, hvad der oftest mangler i en undersøgelse, og hvad der koster mindst at rette:

Kontrollér, at auditlogning i cloudtjenesterne er slået til, og at loginlogs eksporteres til eget lager.
Hæv størrelsen på Windows-sikkerhedsloggen, og centralisér den fra servere og domænecontrollere.
Ret tidssynkroniseringen, især på netværksudstyr og virtuelle maskiner.
Centralisér firewall-, VPN- og DNS-logs.
Udvid auditpolitikken på klienter, og slå PowerShell-logning til.
Skriv og afprøv eksportvejene.

Hvad baselinen ikke løser

En baseline sikrer, at data findes. Den sikrer ikke, at de bliver sikret korrekt, når hændelsen sker, og den gør ikke MSP’en uvildig i en sag, hvor MSP’ens egen drift er til diskussion. Den sikrer heller ikke mod en angriber med administratorrettigheder, der sletter logs lokalt. Derfor er centralisering og uforanderlig lagring vigtigere end den præcise logopsætning på den enkelte maskine.

Typiske afvigelser fra baselinen

Logs, der kun ligger lokalt på enheden og roterer på dage.
Cloudlicenser, der giver kortere opbevaring, end kunden tror.
Klienter uden for domænet, fx hos medarbejdere, der arbejder hjemme, med eget ur og uden central logning.
Eksportkonti, der er slettet ved en oprydning, og som ingen har genskabt.
MSP’ens egne logs, der ikke er med i nogen opbevaringspolitik.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Kvalitet og standarder

Læs også: Kvalitetsstyring i en lille forensic-praksis · Fra revisionsbevis til forensisk bevis

→ Second opinion på en IR- eller forensic-rapport · For MSP’er · 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