Audit Log Integrity

Audit records need protections that make unauthorized modification or deletion detectable. The goal is tamper evidence: preserving trustworthy evidence about what happened, when, and by whom.

Audit log integrity means designing audit records so unauthorized changes are difficult to perform silently. Integrity controls should cover both the log contents and operations such as modification, deletion, truncation, and reordering.

A common technique is append-only storage: application components can create audit events, but normal application paths cannot update or remove existing events. Stronger designs place logs in a separate system or storage boundary with restricted write and administrative access, reducing the chance that an attacker who compromises the application can rewrite its history.

Cryptographic integrity mechanisms can make changes detectable. For example, each record can contain a cryptographic hash that commits to selected fields and the previous record's hash, forming a hash chain. An attacker who changes an earlier event would then need to recompute subsequent hashes; protecting a trusted checkpoint or digest outside the log makes such rewriting detectable.

Integrity is different from confidentiality and availability. Encryption can prevent unauthorized reading but does not by itself prove that a stored event has not changed. Backups and replication improve durability, but copied data can still be consistently corrupted unless integrity verification is also provided.

A production Java service should also consider authorization, time synchronization, retention, key management, monitoring, and failure handling. Audit logging should avoid allowing ordinary application users to disable or rewrite historical records, and integrity failures should be treated as security events rather than silently ignored.

Key points

• Use append-only or write-once storage to prevent ordinary modification and deletion.
• Use cryptographic hashes or signatures when tamper detection must extend beyond storage permissions.
• Protect integrity checkpoints or signing keys outside the log's normal trust boundary.
• Separate audit-log access from ordinary application privileges.
• Monitor integrity failures, unexpected gaps, truncation, and unauthorized administrative operations.

Interview questions

Why is append-only storage useful for audit logs?

Append-only storage prevents normal clients from changing or removing historical events after they are written. This preserves the sequence of recorded activity and reduces opportunities for silent alteration. The storage policy should be backed by authorization that ordinary application identities cannot bypass. It is still useful to add independent integrity verification for stronger tamper evidence.

How does a hash chain help detect audit-log tampering?

Each record can include a hash derived from the current event and the previous record's hash. Changing an earlier record therefore changes its digest and breaks the chain for later records. Detection is meaningful only if some trusted checkpoint or digest is protected from the same attacker. Without such an external trust anchor, an attacker with complete control could potentially rebuild the entire chain.

What would you do if an attacker can compromise the application server that writes audit logs?

I would move the audit sink into a separate trust boundary and restrict the application's permissions to creating events only. The log store should reject updates and deletes for the application's identity, while administrative access should be separately controlled and monitored. I would also use integrity mechanisms such as hash chaining or signatures and maintain protected checkpoints. Alerts should fire on failed integrity verification, unexpected gaps, or suspicious administrative activity.

What are the limitations of a hash chain for audit integrity?

A hash chain proves relationships among records, but it does not by itself prove that the records were generated by a trusted source. If an attacker can rewrite every record and replace the chain's starting point, the chain remains internally consistent. A protected checkpoint, external digest, or digital signature can establish a stronger trust boundary. The design also needs controls for deletion, truncation, key management, clock integrity, and privileged access.