{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/log-management","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/log-management/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/log-management/"},"term":{"en":"Log management","da":"Loghåndtering"},"aka":{"en":["log analysis","log collection"],"da":["loganalyse","logindsamling"]},"domain":["security","cs"],"cluster":"security-operations","layer":"data","status":"current","summary":{"en":"Collecting logs from every system into one place, in one format, kept safe from change and for as long as they are needed.","da":"At samle logs fra alle systemer ét sted, i ét format, beskyttet mod ændringer og så længe, der er brug for dem."},"body":{"formal":{"en":"The planned handling of logs through their whole life - deciding what to record, sending it to a central store, putting it in a common format with correct times, protecting it against change, keeping it for a set period and then deleting it.","da":"Den planlagte håndtering af logs gennem hele deres levetid - at beslutte, hvad der skal registreres, sende det til et centralt lager, bringe det på et fælles format med korrekte tidsstempler, beskytte det mod ændringer, gemme det i en fastsat periode og derefter slette det."},"plain":{"en":"Like the archive at the town hall, which gathers the papers from every office, files them the same way, locks them up and throws them out on a fixed date.","da":"Som arkivet på rådhuset, der samler papirerne fra alle kontorer, ordner dem på samme måde, låser dem inde og kasserer dem på en fast dato."},"inPractice":{"en":"An IT manager at a small engineering firm finds that the firewall, email and cloud servers each keep logs for only a week, each on its own clock, so she sends them all to one central store with one time source.","da":"IT-chefen i en mindre ingeniørvirksomhed opdager, at firewall, mail og cloudservere kun gemmer logs i en uge og hver med sit eget ur, så hun sender dem alle til ét centralt lager med én fælles tidskilde."},"whyItMatters":{"en":"Logs scattered across machines, with clocks that disagree, cannot be searched or trusted when an incident happens; good handling is what makes them useful as evidence.","da":"Logs spredt ud over mange maskiner, med ure der ikke stemmer overens, kan hverken gennemsøges eller stoles på, når en hændelse sker; god håndtering er det, der gør dem brugbare som bevis."}},"deepDive":{"en":"NIST SP 800-92 (2006) defines log management as the process of generating, transmitting, storing, analysing and disposing of log data, and structures it as an infrastructure of generation, collection and storage, and analysis tiers. Its successor, SP 800-92 Rev. 1, \"Cybersecurity Log Management Planning Guide\", was released as an initial public draft in 2023 and reframes the topic as organisation-wide planning. CIS Controls v8 Control 8 (Audit Log Management) breaks it into safeguards, including establishing a process (8.1), collecting audit logs (8.2), ensuring adequate storage (8.3), standardising time synchronisation (8.4), centralising logs (8.9), retaining them for at least 90 days (8.10) and reviewing them (8.11). ISO/IEC 27001:2022 Annex A covers the same ground in controls 8.15 (Logging), 8.16 (Monitoring activities) and 8.17 (Clock synchronisation).\n\nThe technical pipeline has recognisable stages. Sources emit events via syslog (RFC 5424 for the message format, with RFC 5425 defining transport over TLS; the older BSD format is described in RFC 3164), Windows Event Log (collected by agents or Windows Event Forwarding), cloud audit APIs and application logs, increasingly as structured JSON. Collectors and forwarders buffer and ship events, preferably over authenticated, encrypted channels with back-pressure so that bursts do not drop data. Parsing and normalisation map vendor fields to a common schema such as Elastic Common Schema (ECS) or the Open Cybersecurity Schema Framework (OCSF); enrichment adds asset, identity and geolocation context. Storage is usually tiered into hot, warm and cold or archive layers with different query performance and cost.\n\nTime is a first-class concern. Every source should synchronise to a common reference via NTP (RFC 5905) or PTP, logs should record timestamps with time zone or in UTC, and the pipeline should keep both the event time and the ingestion time, because clock skew and delayed forwarding otherwise break correlation and timeline reconstruction. Integrity controls include forwarding logs off the originating host quickly, storing them in a separate security account or tenant that administrators of the monitored systems cannot modify, write-once (WORM) or object-lock storage, and hash chaining or signing for evidential use.\n\nCommon failure modes are silent ones: a source stops sending after an agent update or certificate expiry, a parser change drops a field that detection rules depend on, or volume-based licensing leads teams to exclude high-value but noisy sources such as DNS or process creation. Health monitoring of log sources (last-seen time per source, expected volume ranges) is therefore part of log management itself. Log management differs from a SIEM, which consumes the managed data to correlate and alert, and from observability platforms, which use logs, metrics and traces primarily for reliability rather than security and often keep them for much shorter periods.","da":"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).\n\nDen 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.\n\nTid 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.\n\nDe 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."},"edges":[{"type":"requires","to":"cs/log","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/siem","why":{"en":"Log management gathers and stores the logs; the SIEM reads them and raises alarms.","da":"Loghåndtering samler og gemmer logs; SIEM'en læser dem og slår alarm."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"platform/observability","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/security-monitoring","confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"NIST SP 800-92 - Guide to Computer Security Log Management","url":"https://doi.org/10.6028/NIST.SP.800-92","tier":"standard","publisher":"NIST"},{"title":"CIS Controls v8 - Control 8 (Audit Log Management)","tier":"standard","publisher":"Center for Internet Security"}],"draft":true}