Audit logs: what to record, how to keep them intact, and who may read them

What it is

The OWASP Logging Cheat Sheet (cited) asks each entry to record when, where, who and what: event and log timestamps, application and host, the acting user or machine identity and its source address, the type of event, the object affected, the result and the reason. Its list of events to always log includes authentication successes and failures, authorization failures, user administration actions, use of administrative privileges, access to sensitive data, key use and rotation, and configuration changes. An audit log is the subset of this that documents actions taken on behalf of a principal, kept as a record rather than as troubleshooting output.

Why it matters

An audit log is only worth something if it is complete for the actions that matter and cannot be quietly edited by the person whose actions it records. The cheat sheet's own list of attacks on logs includes an attacker preventing writes or damaging the log to cover their tracks, and causing the wrong identity to be logged to conceal the responsible party.

How to apply

• Emit audit events from the application layer where the principal and the object are known, as structured records with a stable schema: actor, actor type, action, object type and id, outcome, reason, request id, timestamp in UTC.
• Record the actor as an identifier, not a display name, and include impersonation ("admin X acting as user Y") explicitly.
• Do not write session identifiers, access tokens, passwords, keys or full personal data; the cheat sheet lists these among data to exclude or mask.
• Ship entries promptly to storage the application cannot alter: an append-only table under a write-only database role, or object storage with a retention lock. Amazon S3 Object Lock (cited) describes a write-once-read-many model whose compliance mode prevents overwrite or deletion by any user for the retention period.
• Add tamper evidence, for example a hash chain or periodic signed digests, and verify it on a schedule.
• Restrict read access to a named group, log every read, and review the privilege list periodically, as the cheat sheet asks.
• Define retention up front and delete on schedule; keeping audit data beyond its purpose is itself a liability.

Pitfalls

Mixing audit records into application logs that rotate after a week. Logging the intent ("delete requested") but not the outcome. Free-text messages that cannot be queried. Trusting a client-supplied user id in the event. An immutable log that nobody ever reads until the incident.