{"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":"cs/audit","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/audit/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/audit/"},"term":{"en":"Audit logging","da":"Audit-logning"},"aka":{"en":["audit log","audit trail","security log"],"da":["revisionsspor","auditlog","sikkerhedslog"]},"domain":["cs"],"cluster":"os","layer":"os","status":"current","summary":{"en":"A system's record of who did what, and when, for the actions that matter to security.","da":"Et systems registrering af, hvem der gjorde hvad og hvornår, ved de handlinger, der har betydning for sikkerheden."},"body":{"formal":{"en":"A kind of log in which the operating system or an application records security-relevant actions - logins, changes to permissions, opening protected files - each tied to the account that did it and protected against later change.","da":"En slags log, hvor styresystemet eller et program registrerer sikkerhedsrelevante handlinger - login, ændrede rettigheder, åbning af beskyttede filer - hver knyttet til den konto, der udførte den, og beskyttet mod senere ændring."},"plain":{"en":"Like the visitor book and key-card record at a secure building's front desk - not what happened in general, but exactly who went where and when.","da":"Som gæstebogen og adgangskortregistreringen i receptionen på en sikret bygning - ikke hvad der skete i almindelighed, men præcis hvem der gik hvorhen og hvornår."},"inPractice":{"en":"After citizens' data leaks from a municipality, the audit log in the case system shows that a former employee's account, which should have been closed, opened the case at 22:14 the evening before.","da":"Efter et læk af borgeroplysninger fra en kommune viser audit-loggen i sagssystemet, at en tidligere medarbejders konto, som burde have været lukket, åbnede sagen kl. 22.14 aftenen før."},"whyItMatters":{"en":"It holds people accountable for their actions and gives investigators and auditors the evidence they need; standards such as ISO 27001 expect it.","da":"Det gør folk ansvarlige for deres handlinger og giver efterforskere og revisorer det bevis, de har brug for; standarder som ISO 27001 forventer det."}},"deepDive":{"en":"An audit record must answer who, what, when, where, on which object and with what outcome, which is almost literally the content requirement in NIST SP 800-53 control AU-3. The surrounding AU family sets the rest of the design: AU-2 (which events to log), AU-8 (time stamps), AU-9 (protection of audit information), AU-11 (retention) and AU-12 (audit record generation). ISO/IEC 27001:2022 covers the same ground in Annex A controls 8.15 (logging), 8.16 (monitoring activities) and 8.17 (clock synchronisation). The difference from an ordinary application or debug log is purpose and integrity: an audit trail is evidence, so it must be complete for the defined event set, attributable to an individual identity, and tamper-evident.\n\nOn Windows the Security event log is written by the Local Security Authority according to Advanced Audit Policy; frequently used event IDs include 4624 and 4625 (successful and failed logon), 4672 (special privileges assigned at logon), 4688 (process creation, optionally with command line), 4720 (account created), 4728/4732 (member added to a security group) and 1102 (audit log cleared). PowerShell script block logging (event 4104) and Sysmon add depth. On Linux the kernel audit subsystem, controlled by auditd and rules such as -w /etc/shadow -p wa -k shadow, records syscalls with the loginuid (auid) that survives sudo and su, so actions remain attributable to the original user. Databases, SaaS platforms and business applications have their own audit trails, which are often the only place that records who read a specific patient record or case file.\n\nIntegrity is the hard part, because an attacker with administrative rights on a host can stop or clear local logs (MITRE ATT&CK T1070.001 and T1562.002). The standard countermeasures are real-time forwarding to a separate collector or SIEM that the host's administrators cannot modify, WORM or immutable object storage, hash chaining or signed log batches so gaps and edits become detectable, and alerting on the audit service itself stopping or the log being cleared. Separation of duties matters: system administrators should not be able to alter the trail of their own actions. Synchronised clocks (NTP, ideally with UTC timestamps) are a prerequisite for correlating events across systems.\n\nDesign mistakes are common in both directions. Logging too little misses reads of sensitive data, which is exactly what investigations of insider misuse need; logging too much drowns detection and can itself create a personal-data problem, since audit logs are personal data under GDPR and require a legal basis, purpose limitation, access control and a defined retention period. OWASP lists security logging and alerting failures as A09 in its Top 10:2025. An audit log is not an audit: the log is the system's record, while an audit is an independent assessment that frequently samples that record to test whether controls such as access reviews actually operated.","da":"En auditpost skal besvare hvem, hvad, hvornår, hvor, på hvilket objekt og med hvilket resultat, hvilket næsten ordret er indholdskravet i kontrol AU-3 i NIST SP 800-53. Resten af AU-familien fastlægger designet: AU-2 (hvilke hændelser der logges), AU-8 (tidsstempler), AU-9 (beskyttelse af auditoplysninger), AU-11 (opbevaring) og AU-12 (generering af auditposter). ISO/IEC 27001:2022 dækker det samme i Annex A-kontrollerne 8.15 (logning), 8.16 (overvågningsaktiviteter) og 8.17 (synkronisering af ure). Forskellen fra en almindelig applikations- eller debuglog er formål og integritet: et revisionsspor er bevismateriale og skal derfor være komplet for de definerede hændelser, kunne henføres til en bestemt identitet og være manipulationssikret.\n\nPå Windows skrives Security-eventloggen af Local Security Authority efter Advanced Audit Policy; ofte brugte event-id'er er 4624 og 4625 (vellykket og mislykket logon), 4672 (særlige rettigheder tildelt ved logon), 4688 (procesoprettelse, eventuelt med kommandolinje), 4720 (konto oprettet), 4728/4732 (medlem tilføjet til en sikkerhedsgruppe) og 1102 (auditlog ryddet). PowerShell script block logging (event 4104) og Sysmon giver ekstra dybde. På Linux registrerer kernens audit-subsystem, styret af auditd og regler som -w /etc/shadow -p wa -k shadow, systemkald med loginuid (auid), som overlever sudo og su, så handlinger kan henføres til den oprindelige bruger. Databaser, SaaS-platforme og fagsystemer har deres egne revisionsspor, som ofte er det eneste sted, der registrerer, hvem der læste en bestemt patientjournal eller sag.\n\nIntegriteten er den svære del, fordi en angriber med administratorrettigheder på en maskine kan stoppe eller rydde lokale logs (MITRE ATT&CK T1070.001 og T1562.002). Standardmodtrækkene er videresendelse i realtid til en separat opsamler eller et SIEM, som maskinens administratorer ikke kan ændre, WORM- eller uforanderlig objektlagring, hashkæder eller signerede logbatches, så huller og rettelser kan opdages, og alarmer, når auditservicen stopper, eller loggen ryddes. Funktionsadskillelse er vigtig: systemadministratorer bør ikke kunne ændre sporet af deres egne handlinger. Synkroniserede ure (NTP, helst med UTC-tidsstempler) er en forudsætning for at korrelere hændelser på tværs af systemer.\n\nDesignfejl er almindelige i begge retninger. Logges der for lidt, mangler læsninger af følsomme data, som netop er det, undersøgelser af misbrug fra insidere har brug for; logges der for meget, drukner detektionen, og loggen kan selv blive et persondataproblem, fordi auditlogs er personoplysninger efter databeskyttelsesforordningen og kræver hjemmel, formålsbegrænsning, adgangsstyring og en fastlagt opbevaringsperiode. OWASP placerer mangler i sikkerhedslogning og alarmering som A09 i Top 10:2025. En auditlog er ikke en audit: loggen er systemets registrering, mens en audit er en uafhængig vurdering, der ofte udtager stikprøver af registreringen for at teste, om kontroller som gennemgang af adgange faktisk er udført."},"edges":[{"type":"requires","to":"cs/account","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/log","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"security/audit","why":{"en":"Audit logging is a system's own record of actions; an audit is a person's independent review of whether controls work - which often reads those records.","da":"Audit-logning er systemets egen registrering af handlinger; en audit er en uafhængig gennemgang af, om kontrollerne virker - og den læser ofte netop de registreringer."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"security/siem","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/non-repudiation","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/version-control","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/log-management","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":"Modern Operating Systems","tier":"textbook","publisher":"Tanenbaum & Bos (Pearson)"}],"draft":true}