SIEM‑data som bevis: integritet og eksport

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

Et SIEM-system er ofte det første sted, man leder efter spor, fordi det samler logs fra mange kilder ét sted og gemmer dem længere end kildesystemerne. Som bevis har SIEM-data en vigtig styrke og en vigtig svaghed. Styrken er, at data er opsamlet centralt og løbende, uden for de systemer, sagen handler om. Svagheden er, at det, analytikeren ser i SIEM-systemet, ofte er en bearbejdet udgave af den oprindelige log. Eksporten skal derfor skelne mellem den normaliserede hændelse og den rå log og dokumentere begge.

Hvad et SIEM gemmer

Når en logpost modtages, sker der typisk flere ting:

Modtagelse. Posten ankommer via syslog, en agent, en API-forbindelse eller en filimport. Opsamlingstidspunktet registreres.
Parsing. En parser udtrækker felter som tid, bruger, kilde-IP og hændelsestype.
Normalisering. Felterne lægges ind i SIEM-systemets fælles skema, og feltnavne ensrettes.
Berigelse. Systemet tilføjer oplysninger, fx geolokation af IP-adresser, oplysninger fra trusselsfeeds eller brugerattributter fra kataloget.
Lagring. Den normaliserede hændelse gemmes. Om den rå post også gemmes, afhænger af produkt og konfiguration.

Hvert trin kan ændre det, man ser. Parseren kan have tabt felter eller fejltolket et tidsstempel. Berigelsen afspejler oplysninger på berigelsestidspunktet, fx en geolokationsdatabase, der siden er opdateret. Og hvis kun de normaliserede felter er gemt, kan den oprindelige post ikke længere genskabes. Problemstillingen er beskrevet mere generelt i Normalisering af logdata.

Normaliseret hændelse og rå log

Form · Normaliseret hændelse: Felter i SIEM-systemets skema · Rå log: Kildens oprindelige tekst eller struktur
Fuldstændighed · Normaliseret hændelse: Kun de felter, parseren kender · Rå log: Alt, kilden skrev
Tid · Normaliseret hændelse: Ofte omregnet, evt. med opsamlingstid i stedet for hændelsestid · Rå log: Kildens egen værdi
Berigelse · Normaliseret hændelse: Kan indeholde tilføjede oplysninger · Rå log: Ingen
Velegnet til · Normaliseret hændelse: Søgning, overblik, korrelation · Rå log: Dokumentation af, hvad kilden registrerede

I en sag bør den rå post være udgangspunktet, når den findes. Den normaliserede hændelse kan bruges til at finde posterne og til at vise forløbet, men hvor der er tvivl, er det den rå værdi, der skal citeres. Gemmer SIEM-systemet ikke rå poster, skal det fremgå af dokumentationen, og der bør om muligt hentes data direkte fra kilden til kontrol.

Tidsstempler i SIEM-data

De fleste SIEM-systemer har mindst to tider pr. hændelse: det tidspunkt, kilden angav, og det tidspunkt, SIEM-systemet modtog posten. De kan afvige med sekunder, men også med timer eller dage, hvis en agent har været offline og sender sin kø senere. Søgninger og grafer bruger ofte modtagetiden som standard. Kontrollér, hvilken tid der vises, og eksportér begge. Hvordan tider fra flere kilder rettes ind, er beskrevet i Logkorrelation.

Integritet i SIEM-systemet

Et SIEM-system kan give god integritet, men det skal vises, ikke antages. Relevante forhold:

Adgangskontrol. Hvem kan slette eller ændre data? Har den person, sagen handler om, haft administratoradgang til SIEM-systemet?
Uforanderlighed. Er data lagret i et lager, der ikke kan ændres i opbevaringsperioden, eller kan administratorer slette indekser?
Systemets egen auditlog. Mange SIEM-systemer logger søgninger, ændringer af regler og sletning af data. Den log er relevant for at vise, at data ikke er manipuleret.
Opsamlingens fuldstændighed. Var alle kilder forbundet i hele perioden? Huller i en kildes data kan skyldes nedbrud, licensgrænser eller ændret konfiguration.

Metoderne til at underbygge, at en log ikke er ændret, er samlet i Logintegritet.

Eksport trin for trin

Afgræns spørgsmålet: tidsrum, kilder, konti, enheder og hændelsestyper.
Dokumentér søgningen. Gem den præcise forespørgsel, tidsrummet og tidszonen. Søgesproget er produktspecifikt, så forespørgslen skal kunne gentages i samme system.
Eksportér bredt nok. Tag hele tidsrummet for de relevante kilder frem for kun de poster, der matcher en snæver søgning. Ellers kan tætheden af hændelser og alternative forklaringer ikke vurderes.
Eksportér rådata og normaliserede felter i det mest komplette format, systemet tilbyder, typisk JSON frem for CSV.
Kontrollér antallet. Sammenlign antal eksporterede poster med det antal, SIEM-systemet viser for søgningen. Mange systemer har grænser pr. eksport, som afkorter resultatet uden tydelig advarsel. I Log Analytics, som Microsoft Sentinel bygger på, returnerer en forespørgsel fx højst 500.000 poster (på tidspunktet for gennemgangen, oktober 2026).
Beregn hashværdier for hver eksportfil straks, og registrér dem; se Hashalgoritmer i forensic.
Gem konteksten: parserversioner, relevante regler, opbevaringsindstillinger og en liste over forbundne kilder i perioden.
Notér, hvem der eksporterede, med hvilken konto og hvornår. Eksporten er i sig selv en handling, der bør fremgå af SIEM-systemets auditlog.

Alarmer og korrelationsregler

En alarm i et SIEM-system er resultatet af en regel. Alarmen viser, at reglens betingelser var opfyldt, ikke at der skete noget bestemt. Indgår en alarm i sagen, skal reglen dokumenteres med version og logik, og de underliggende hændelser skal eksporteres. Reglen kan være ændret siden, så det skal også fremgå, hvilken version der var aktiv på tidspunktet.

Berigede felter skal behandles for sig

Berigelse er nyttig i den daglige drift, men i en sag skal berigede felter adskilles fra de registrerede. Et land eller en by ud fra en IP-adresse, en risikoscore fra et trusselsfeed eller en afdeling fra brugerkataloget er oplysninger, SIEM-systemet har slået op, ikke noget kilden har registreret. Opslagene afspejler databasen på opslagstidspunktet, og databasen kan være opdateret siden. I eksporten bør det derfor fremgå, hvilke felter der er berigede, og hvilken kilde og version berigelsen kom fra. I rapporten bør berigede oplysninger enten efterprøves mod en uafhængig kilde eller præsenteres med det forbehold, at de er et opslag.

Når data ligger hos en ekstern SOC

Mange mindre organisationer har deres SIEM drevet af en ekstern leverandør. Organisationen ejer data, men har ikke altid adgang til at søge eller eksportere selv. Det bør afklares tidligt, hvem der udfører eksporten, med hvilken konto, og om leverandøren kan levere rå poster frem for et udtræk i regneark. Leverandørens medarbejder, der laver eksporten, bør dokumentere den på samme måde som en intern analytiker, og dokumentationen bør følge med data.

Opbevaring og tidspres

SIEM-data opbevares efter konfiguration og licens, ofte i flere lag med kortere tid for hurtigt søgbare data og længere tid for arkiv. Data i arkivlaget kan kræve gendannelse, før de kan søges. Kend opbevaringen, før en sag opstår; organisationens overvejelser om opbevaringstid er behandlet på bevissikring-digitalt.dk. Ved en konkret hændelse bør relevante data sikres hurtigt, uanset hvor lang opbevaringen er, fordi den kan ændres, og fordi data under undersøgelse ikke bør ligge i et system, der kan slette dem automatisk.

Typiske fejlkilder

Geolokation fra berigelsen bruges som fakta, selvom den er et opslag i en database med kendte fejl.
Opsamlingstid forveksles med hændelsestid.
En søgning med standardgrænse returnerer kun de første resultater.
Data fra en managed SOC-leverandør leveres som udvalgte uddrag i en rapport, ikke som eksport. Det samme gælder de logkilder, en NIS2-rapport bygger på; se NIS2: varsling og rapporter. Hvornår SOC’en bør trække en uvildig ind, står i Hvornår SOC’en skal kalde en uvildig ind. Se IR-rapporten som bevis.
Fravær af hændelser tolkes som fravær af aktivitet, selvom kilden ikke var forbundet.

Hvad SIEM-data kan bevise

SIEM-data kan vise, at bestemte kilder har registreret bestemte hændelser, og at registreringerne er opsamlet centralt på et givent tidspunkt. Styrken afhænger af, hvor uafhængigt SIEM-systemet er af de involverede personer, og af, om den rå log er bevaret. Dokumentationen bør derfor beskrive både systemet, eksporten og de forbehold, der følger af parsing og normalisering.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: Normalisering af logdata: ensretning af formater og felter · Logintegritet: sådan vises det, at en log ikke er ændret

→ 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