Tamper-Evident Log

An audit log is evidence, and evidence an attacker or an insider can edit is not evidence. The first action of a competent intruder is to remove traces, so a log that can be modified by anyone who compromised the system tells you nothing about what happened.

Mechanisms, in increasing strength:

Append-only storage with no delete or update permission for the writing identity — the baseline, and enough for many purposes. Write to a separate account or system whose credentials are not available to the audited environment. This is the highest-value structural step, because it means compromising the application does not grant access to its audit trail. Hash chaining, where each entry includes a hash of the previous one, so removing or altering any entry breaks the chain and is detectable. Object lock / WORM storage in compliance mode, so deletion is impossible for the retention period regardless of permissions. External anchoring, periodically publishing a checkpoint hash somewhere outside your control, which proves the log has not been rewritten wholesale.

Most organisations need the first three. The related requirement is completeness: a tamper-evident log that simply stops recording during an incident is equally useless, so absence of entries should itself alert.