Loghåndtering

Også kendt som: loganalyse, logindsamling

At samle logs fra alle systemer ét sted, i ét format, beskyttet mod ændringer og så længe, der er brug for dem.

Kladde - dette opslag er endnu ikke gennemgået.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

Udpeg en ejer, og skriv en logningspolitik, der angiver, hvilke spørgsmål logs skal kunne besvare under en hændelse, og dermed hvilke kilder der er nødvendige.
Begynd med de vigtigste kilder (identitet og login, firewall og VPN, mail, DNS, endpoints, audit-logs i cloud og kritiske applikationer), og slå de relevante audit-hændelser til.
Synkronisér alle ure med en fælles NTP-kilde, og registrér tidsstempler i UTC eller med en tydelig tidszone.
Send logs hurtigt over krypterede forbindelser til et centralt lager i en separat sikkerhedskonto, som administratorerne af de loggede systemer ikke kan ændre i.
Fastsæt opbevaringstiden pr. kilde ud fra efterforskningsbehov, regulering og GDPR, fx mindst 90 dage søgbart (CIS Safeguard 8.10) og længere i et billigere arkiv.
Pars logs til et fælles format, og begræns og log adgangen til selve logs, da de ofte indeholder personoplysninger.
Overvåg kildernes sundhed med seneste modtagne hændelse og forventet volumen pr. kilde, og slå alarm, når en kilde bliver tavs.
Gennemgå politikken og kilderne mindst hver 6. til 12. måned, og test, at I rent faktisk kan besvare et hændelsesspørgsmål ud fra logs.

Typiske faldgruber

At gemme logs kun på den enhed, der skabte dem, hvor en angriber kan slette dem.
At fravælge støjende, men værdifulde kilder som DNS for at spare licensudgifter.
Ure, der ikke stemmer overens, så hændelser fra forskellige systemer ikke kan lægges på én tidslinje.
At opdage under en hændelse, at en kilde holdt op med at sende for flere måneder siden.
At gemme logs med personoplysninger for evigt, fordi ingen har fastsat en slettefrist.

Gode vejledninger

Logning - en del af et godt cyberforsvar(åbner i en ny fane) · Styrelsen for Samfundssikkerhed
NIST SP 800-92 Rev. 1 (Initial Public Draft) - Cybersecurity Log Management Planning Guide(åbner i en ny fane) · NIST (på engelsk)
CIS Critical Security Controls - Control 8 Audit Log Management(åbner i en ny fane) · Center for Internet Security (på engelsk)
Introduction to logging for security purposes(åbner i en ny fane) · NCSC UK (på engelsk)
Best Practices for Event Logging and Threat Detection(åbner i en ny fane) · CISA (på engelsk)

Teknisk uddybning

NIST SP 800-92 (2006) definerer loghåndtering som processen med at generere, overføre, lagre, analysere og bortskaffe logdata og opbygger den som en infrastruktur med lag til generering, indsamling og lagring samt analyse. Efterfølgeren, SP 800-92 Rev. 1, "Cybersecurity Log Management Planning Guide", blev udsendt som første offentlige udkast i 2023 og behandler emnet som planlægning på tværs af hele organisationen. CIS Controls v8, kontrol 8 (Audit Log Management), opdeler det i safeguards, bl.a. at etablere en proces (8.1), indsamle auditlogs (8.2), sikre tilstrækkelig lagerplads (8.3), standardisere tidssynkronisering (8.4), centralisere logs (8.9), opbevare dem i mindst 90 dage (8.10) og gennemgå dem (8.11). ISO/IEC 27001:2022, bilag A, dækker det samme i kontrollerne 8.15 (logning), 8.16 (overvågningsaktiviteter) og 8.17 (synkronisering af ure).

Den tekniske pipeline har genkendelige trin. Kilder udsender hændelser via syslog (RFC 5424 for meddelelsesformatet, mens RFC 5425 definerer transport over TLS; det ældre BSD-format er beskrevet i RFC 3164), Windows Event Log (indsamlet af agenter eller Windows Event Forwarding), audit-API'er i cloud og applikationslogs, i stigende grad som struktureret JSON. Collectors og forwarders buffer og sender hændelser, helst over autentificerede, krypterede kanaler med back-pressure, så spidsbelastninger ikke taber data. Parsing og normalisering mapper leverandørernes felter til et fælles skema som Elastic Common Schema (ECS) eller Open Cybersecurity Schema Framework (OCSF); berigelse tilføjer kontekst om aktiver, identiteter og geolokation. Lagringen er normalt delt i hot, warm og cold- eller arkivlag med forskellig søgeydelse og pris.

Tid er et hovedanliggende. Alle kilder bør synkronisere med en fælles reference via NTP (RFC 5905) eller PTP, logs bør registrere tidsstempler med tidszone eller i UTC, og pipelinen bør bevare både hændelsestidspunktet og indlæsningstidspunktet, fordi urforskydning og forsinket videresendelse ellers ødelægger korrelation og rekonstruktion af tidslinjer. Integritetskontroller omfatter hurtig videresendelse af logs væk fra den oprindelige maskine, lagring i en separat sikkerhedskonto eller tenant, som administratorerne af de overvågede systemer ikke kan ændre i, write-once-lagring (WORM) eller object lock samt hashkæder eller signering til brug som bevis.

De typiske fejl er tavse: en kilde holder op med at sende efter en agentopdatering eller et udløbet certifikat, en ændret parser taber et felt, som detektionsregler afhænger af, eller volumenbaseret licensering får teams til at udelade værdifulde, men støjende kilder som DNS eller procesoprettelse. Overvågning af logkildernes sundhed (seneste modtagelse pr. kilde, forventede volumenintervaller) er derfor en del af selve loghåndteringen. Loghåndtering adskiller sig fra en SIEM, der bruger de håndterede data til at korrelere og slå alarm, og fra observability-platforme, der bruger logs, metrikker og traces primært til driftsstabilitet frem for sikkerhed og ofte gemmer dem i langt kortere tid.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

Log
→Loghåndtering

Relationer

Består af: Logopbevaring
Forudsætter: Log
Krævet af: CIS-kontroller
Bruges sammen med: SIEM Observerbarhed Sikkerhedsovervågning Audit-logning

Kilder og videre læsning

Standarder og officielle tekster

NIST SP 800-92 - Guide to Computer Security Log Management · NIST
CIS Controls v8 - Control 8 (Audit Log Management) · Center for Internet Security

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøen Foreslå en rettelse på GitHub Dette begreb som JSON

Test dig selv

Indlæser…