Normalisering af logdata: ensretning af formater og felter

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

Normalisering er arbejdet med at bringe logs fra forskellige systemer på samme form, så de kan sammenlignes, søges i og lægges på én tidslinje. Det er nødvendigt i næsten enhver undersøgelse med mere end én logkilde, men det er også et sted, hvor information forsvinder uden at nogen opdager det. Reglen er derfor enkel: Normaliseringen er en arbejdskopi. Rådataene bevares uændret, og hver omformning skal kunne spores tilbage til den oprindelige post.

Selve koblingen af hændelser på tværs af kilder er beskrevet i Logkorrelation. Her handler det om trinnet før: at få dataene på en fælles form. Omregning til én tidszone og håndtering af sommertid står i UTC og sommertid i forensiske rapporter.

De almindelige formater

Syslog (RFC 3164 og RFC 5424) · Tekstlinjer med tidsstempel, vært og besked. Det ældre format har ofte ingen år og ingen tidszone.
JSON · Struktureret og typisk komplet, men felter kan være indlejret i flere niveauer og variere mellem poster.
CSV · Flad tabel. Indlejrede felter er ofte pakket ind i én celle eller udeladt. Tegnsæt og skilletegn varierer.
EVTX · Windows’ binære format. Beskrivelsen af hændelsen hentes fra skabeloner på det system, der viser den.
W3C og andre webserverformater · Feltlisten står i en kommentarlinje i filen og kan skifte midt i en fil.
Leverandørformater · Eksport fra SaaS og sikkerhedsprodukter, ofte JSON eller CSV med egne feltnavne.

Hvor information forsvinder

Felter, der falder ud

Den hyppigste fejl opstår, når et indlejret format konverteres til en flad tabel. En post i Microsoft 365’s auditlog har typisk et felt med yderligere data, der selv indeholder en struktur med mange underfelter. Eksporteres det til et regneark, kan underfelterne ende som én lang tekststreng eller forsvinde, hvis eksportværktøjet kun tager de felter, det kender. Det samme sker med EVTX-poster, hvor hændelsesdataene består af navngivne felter, der kan gå tabt, hvis kun den viste beskrivelse eksporteres. Se Eksport af Windows-hændelseslogs.

Kontrollér derfor efter hver konvertering, at antallet af felter pr. posttype er som forventet, og at et par udvalgte poster indeholder de samme værdier før og efter.

Tid, der flytter sig

Tidsstempler er den mest sårbare del. Typiske problemer:

Manglende tidszone. Ældre syslog skriver lokal tid uden angivelse. Et værktøj, der antager UTC, flytter alle poster en eller to timer.
Manglende år. Ældre syslog skriver kun måned og dag. Logs, der krydser et årsskifte, kan blive placeret i det forkerte år.
Tabt præcision. En kilde med millisekunder eller mikrosekunder konverteres til et format med hele sekunder, og rækkefølgen inden for samme sekund går tabt.
Regnearkets egen fortolkning. Regneark omformer datoer efter regionale indstillinger, kan bytte om på dag og måned og kan afkorte lange tal.
Forskellige epoker. Unix-tid, Windows FILETIME og andre formater har forskellige nulpunkter og enheder; se Tidsstempelformater.

Vælg én referencetid, normalt UTC, og gem både den oprindelige værdi og den omregnede værdi i hver post. Om sommertid og den dobbelte time i oktober, se Sommertid og tidszoner i rapporten.

Tegnsæt og tekst

Brugernavne, filnavne og emnelinjer med æ, ø og å kan blive ødelagt, hvis en UTF-8-fil læses som et andet tegnsæt. Det kan få søgninger til at fejle og to forskellige værdier til at se ens ud. Lange tal, fx id’er og hashværdier, kan blive afkortet eller omformet til videnskabelig notation i regneark. Arbejd derfor med tekstformater og værktøjer, der ikke fortolker værdierne.

Dubletter og sammenlægning

Mange systemer logger samme hændelse flere steder, og eksporter med overlappende perioder giver dubletter. Fjernes dubletter ud fra tid og besked alene, kan to reelt forskellige hændelser blive lagt sammen. Brug en unik nøgle fra kilden, hvis den findes, fx et record-id eller et hændelses-id, og registrér, hvor mange poster der er fjernet.

Et fælles skema

En normalisering kræver en målstruktur. Mange arbejder med et fælles skema, fx et af de åbne skemaer, der bruges i sikkerhedsværktøjer, eller et enkelt skema til den konkrete sag. Det vigtigste er ikke hvilket skema, men at koblingen mellem kildefelt og skemafelt er dokumenteret. Et felt, der hedder “bruger” i det fælles skema, kan i én kilde være et UPN, i en anden et kontonavn uden domæne og i en tredje en e-mailadresse. Den forskel skal fremgå.

Byg derfor en feltoversigt pr. kilde med kildefeltets navn, betydning ifølge leverandørens dokumentation, eksempelværdi og målfelt. Felter, der ikke har en naturlig plads, skal ikke kasseres, men bevares i et ekstra felt.

Fremgangsmåde

Sikr rådataene i oprindeligt format, beregn hashværdier, og arbejd kun på kopier. Se Logfiler og logrotation.
Beskriv hver kilde: format, tidszone, præcision, tegnsæt og felter.
Lav feltoversigten og målstrukturen.
Konvertér med et værktøj, der kan gentages, fx et script eller en dokumenteret importfunktion, ikke manuelt i et regneark.
Bevar en reference i hver normaliseret post til kildefil og linje eller record-id.
Kontrollér: antal poster før og efter, stikprøver af felter, første og sidste tidsstempel og fordelingen over tid.
Gem konverteringen: script, version, parametre og output med hashværdi.

Valg af værktøj

Til normalisering bruges typisk tre kategorier: scripts i et almindeligt programmeringssprog, logbehandlingsværktøjer med parsere til kendte formater og de importfunktioner, der findes i tidslinje- og analyseværktøjer. Alle tre kan bruges, hvis de opfylder to krav. Resultatet skal kunne gentages med samme input og samme parametre, og værktøjet skal kunne rapportere poster, det ikke kunne læse. En parser, der i stilhed springer linjer over, som ikke passer til det forventede format, er en alvorlig fejlkilde, fordi de oversprungne linjer ofte er netop de usædvanlige, der er interessante. Kontrollér derfor altid fejl- og advarselsoutput, og gem det sammen med resultatet.

Når loggen kommer fra et SIEM

Data, der hentes fra et SIEM, er ofte allerede normaliseret af SIEM-systemets egne parsere. Det er bekvemt, men det betyder, at et led i kæden er ukendt. Parseren kan have droppet felter, omregnet tid eller sammenlagt poster. Om forskellen på den normaliserede hændelse og den rå log, og hvordan begge eksporteres, se SIEM-data som bevis.

Kontrol, der afslører fejl

Fordeling over tid. Vis antal poster pr. time for hver kilde. Et spring på præcis en eller to timer mellem kilder tyder på en tidszonefejl.
Kendte hændelser. Find en hændelse, der skal stå i flere kilder, fx et login, og kontrollér, at den ligger samme sted efter normaliseringen.
Tomme felter. Tæl, hvor mange poster der har tomme værdier i hvert målfelt. Et felt, der pludselig er tomt fra en bestemt dato, kan skyldes et formatskifte i kilden.
Tilbageføring. Tag tilfældige normaliserede poster og find dem i rådataene via referencen.

Hvad normaliseringen ikke må gøre

Normalisering må ensrette form, men ikke ændre betydning. Den må ikke udfylde manglende værdier ud fra antagelser, fx tildele en tidszone, uden at det fremgår, og den må ikke filtrere poster fra, uden at filteret er beskrevet. En normaliseret tidslinje er et analyseprodukt, ikke selve beviset.

Dokumentation

Rapporten bør beskrive kilderne, feltoversigten, de valgte konventioner for tid og tegnsæt, værktøj og version, antal poster før og efter samt de kontroller, der er udført. Når en modpart kan tage rådataene og det samme script og få det samme resultat, er normaliseringen efterprøvelig.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: Logkorrelation: sådan kobles hændelser på tværs af systemer · SIEM-data som bevis: integritet og eksport

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · 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