Logkorrelation: sådan kobles hændelser på tværs af systemer

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

Logkorrelation er arbejdet med at vise, at poster i forskellige logs beskriver den samme hændelse eller den samme handlingskæde. Koblingen sker gennem fælles nøgler: tidspunkt, IP-adresse, brugerkonto, sessions-id og enheds-id. En korrelation er kun så stærk som den svageste nøgle, den bygger på, og derfor skal hver kobling kunne begrundes og efterprøves.

Hvordan en enkelt logfil læses, er forklaret på digital-bevissikring.dk, og sikringen af logs før rotation er beskrevet i Logfiler og logrotation. Her handler det om metoden, når flere kilder skal sættes sammen.

Hvorfor én log sjældent er nok

En enkelt log viser typisk ét lag af en handling. Entra ID-loginloggen viser, at kontoen blev godkendt fra en IP-adresse. Firewallen viser, at en intern enhed åbnede en forbindelse ud. Filserveren viser, at en mappe blev læst. Ingen af dem viser alene, at det var den samme handling. Først når posterne kobles, kan man sige noget om forløbet: hvilken enhed, hvilken konto, hvilken session, hvilke data.

Korrelation tjener også et andet formål. Når samme hændelse er registreret i to uafhængige systemer, styrker de hinanden. En post, der kun findes i én log, som den undersøgte person selv kunne ændre, vejer mindre end en hændelse, der også ses i leverandørens cloudlog.

De fem nøgler

Tid · Altid til stede, men kræver kendt tidszone, præcision og urafvigelse. Alene for svag i travle systemer.
IP-adresse · Stærk inden for samme netværkssegment og tidsrum. Svækkes af NAT, proxy, VPN og dynamisk tildeling.
Brugerkonto · Kobler handlinger til en identitet, ikke til en person. Navneformater varierer mellem systemer.
Sessions-id eller korrelations-id · Den stærkeste nøgle, hvor den findes, fordi den er unik for et forløb. Findes sjældent på tværs af leverandører.
Enheds-id · Værtsnavn, MAC-adresse, enheds-id i Entra ID eller MDM. Kobler handling til udstyr, men kan ændres eller deles.

Hovedreglen er, at en kobling bør bygge på mindst to nøgler. Tid og IP-adresse sammen er langt stærkere end tid alene. Tid, konto og sessions-id sammen kan være næsten entydig.

Trin 1: Saml og beskriv kilderne

Før noget kobles, skal hver kilde beskrives: system, version, tidszone, tidsformat, præcision, opbevaringsperiode og hvilke felter der findes. Det gælder også fysiske kilder som adgangskontrol og dørlogs og industrielle styringer; se OT og PLC. Det er især vigtigt at notere, om tidsstemplet angiver, hvornår hændelsen skete, hvornår den blev modtaget af en central opsamler, eller hvornår den blev skrevet til disk. De tre kan afvige med sekunder eller minutter.

Hvis data skal ensrettes i felter og formater, før de kan sammenlignes, er det et selvstændigt trin med egne fejlkilder; se Normalisering af logdata.

Trin 2: Ret tiden ind

Alle tider omregnes til én reference, normalt UTC, og den oprindelige værdi bevares ved siden af. Derefter fastlægges urafvigelsen for hver kilde. Den sikreste metode er at finde en hændelse, der uden tvivl er registreret i flere kilder, fx et bestemt login, der både står i VPN-loggen og i domænecontrollerens log, og måle forskellen. Fremgangsmåden ved et ur, der går forkert, er beskrevet i Urafvigelse og korrektion.

Brug et tidsvindue frem for et præcist tidspunkt. Vinduets størrelse skal afspejle den kendte afvigelse og logningens præcision, og den skal stå i dokumentationen. Et vindue, der er valgt bagefter for at få fundene til at passe, er en klassisk fejl.

Trin 3: Oversæt identiteterne

Samme person kan optræde som et UPN i Microsoft 365, et SAM-kontonavn i Active Directory, en e-mailadresse i et SaaS-system og et numerisk bruger-id i en database. Byg en oversættelsestabel med kilden til hver kobling, fx et udtræk fra Active Directory med både UPN og objekt-id. Det samme gælder enheder: værtsnavn, IP-adresse på et givent tidspunkt og MAC-adresse kobles via DHCP-, NAC- eller MDM-data.

Trin 4: Følg IP-adressen gennem oversættelserne

En IP-adresse er kun en nøgle, hvis man ved, hvilken adresse det er. Den offentlige adresse i en cloudlog er ofte firewallens udgående adresse og deles af alle på kontoret. Først firewallens NAT-log kan koble den offentlige adresse og port til en intern adresse, og først DHCP-loggen kan koble den interne adresse til en enhed på det givne tidspunkt. Hvert led er en ny kobling med sin egen usikkerhed. Om de typiske fejl ved NAT, CGNAT og geolokation, se IP-adresser som bevis.

Trin 5: Byg kæden og test den

Saml de koblede poster i en tidslinje, hvor hver række angiver kilde, oprindeligt tidsstempel, omregnet tid og de nøgler, der binder den til de øvrige. Test derefter kæden aktivt:

Alternative forklaringer: Kunne en anden konto eller enhed have haft samme IP-adresse i vinduet?
Tæthed: Hvor mange andre hændelser i samme vindue ville også matche? Er svaret mange, er koblingen svag.
Huller: Mangler der poster, man ville forvente, fx et login før en filadgang?
Retning: Passer rækkefølgen med det tekniske forløb, fx DNS-opslag før forbindelse og forbindelse før download?

Typiske fejl

Tid alene som nøgle. I et system med tusindvis af hændelser i minuttet er sammenfald i tid ikke en kobling.
Blandede tidszoner. En kilde i lokal tid og en i UTC giver en forskydning på en eller to timer, afhængigt af sommertid.
Systemhandlinger tolket som brugerhandlinger. Synkronisering, antivirus og indeksering skaber poster, der ligner menneskelig aktivitet.
Delte konti og delte IP-adresser. En fælles servicekonto eller et gæstenet ødelægger koblingen til en bestemt person.
Udvalgte uddrag. Hvis en leverandør kun har leveret linjer, der matcher en søgning, kan man ikke vurdere tætheden eller alternative forklaringer.

SIEM og automatisk korrelation

Mange organisationer har allerede et SIEM, der korrelerer automatisk. Resultatet er et godt udgangspunkt, men det kan ikke stå alene i en sag. Korrelationsreglerne er skrevet til at finde mistænkelige mønstre, ikke til at dokumentere en kæde, og de normaliserede felter kan have mistet detaljer fra rådataene. Kontrollér derfor hver vigtig kobling mod de oprindelige logposter, og beskriv reglen, hvis en automatisk korrelation indgår i rapporten.

Hvad korrelationen kan og ikke kan vise

En velbegrundet korrelation kan vise, at en bestemt konto fra en bestemt enhed udførte en række handlinger i et bestemt tidsrum. Den kan ikke i sig selv vise, hvem der sad ved enheden. Til det skal der andre spor til, fx fysisk adgang, anden aktivitet på enheden og forklaringer fra de involverede. Konklusionen bør derfor formuleres som en kobling mellem tekniske identiteter med den usikkerhed, nøglerne giver.

Dokumentation

For en korrelation, der skal holde i en civil sag, dokumenteres:

hver kilde med system, tidszone, præcision og sikringsmetode,
urafvigelsen pr. kilde og den hændelse, den er målt på,
de nøgler, der er brugt, og tidsvinduets størrelse,
oversættelsestabeller for konti, IP-adresser og enheder med kilde,
de alternative forklaringer, der er undersøgt, og resultatet.

Arbejdet kan med fordel samles i en tidslinje som beskrevet i Tidslinjeanalyse. Når en anden sagkyndig kan tage de samme rådata, følge de samme koblinger og nå samme resultat, er korrelationen dokumenteret godt nok.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: Webserverlogs (IIS, Apache, Nginx): felter, tidszoner, proxy og CDN · Normalisering af logdata: ensretning af formater og felter

→ 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