Safeguard
Security Guides•

How to make logs tamper-evident: protecting log integrity

Attackers edit or delete logs to hide their tracks. Ship logs off the host fast, use append-only storage, restrict access and monitor the logging system.

Safeguard Security Team
3 min read

Make logs tamper-evident by sending them off the originating system quickly, writing them to append-only or read-only storage, restricting who can change or delete them, and recording every access to the logs themselves. You cannot always prevent tampering, but you can make it visible.

The threat

Logs on the machine that was compromised are logs the attacker can edit. CWE-117 notes that attackers can insert fake entries, hide their activity or make it look as if someone else did something. Deleting a log file is cruder and just as effective. If your only copy sits on the host, your evidence goes down with it.

Controls that work, in order of value

1. Get logs off the host fast. The shorter the window between an event and its remote copy, the less an attacker can erase. Stream continuously rather than shipping files nightly.

2. Store in a separate trust domain. Put the log archive in a different account or project from the workloads, with different administrators. A compromised application admin should not be able to delete the archive.

3. Use append-only or write-once storage. OWASP's Top 10 entry on logging failures suggests audit trails for high-value transactions with integrity controls such as append-only storage. The OWASP Logging Cheat Sheet says to store or copy log data to read-only media as soon as possible.

4. Build in tamper detection. The cheat sheet recommends being able to tell whether a record has been modified or deleted. Hash chaining, where each batch includes the hash of the previous one, or periodic signed checkpoints, lets you prove nothing was removed from the middle.

5. Record and watch access to the logs. The same page says all access to logs must be recorded and monitored, and read privileges should be restricted and reviewed.

6. Protect the transport. Syslog over plain UDP can be intercepted, dropped or replayed. RFC 5424 says TLS is required for implementations and recommended for deployment, and notes that UDP is only appropriate on managed networks.

A simple architecture

  1. Applications write structured events to local stdout or a local agent.
  2. An agent forwards over an authenticated, encrypted channel to a collector.
  3. The collector writes to an archive in a separate account with deletion blocked for the retention period.
  4. A separate index gives analysts search access, with no ability to alter the archive.
  5. Alerts fire on log deletion attempts, retention changes and agent shutdowns.

What to test

  • Can an application administrator delete yesterday's archive? The answer should be no.
  • If you stop the forwarder on a test host, does anyone get an alert?
  • Can you prove a missing hour is missing and not just empty?

The limits

Tamper evidence is not tamper proof. A privileged attacker with control of the collector and the archive account can still do damage. The goal is to raise the bar and to make silent edits detectable. Pair this with detection when logging stops.

Quick check

Does encrypting logs make them tamper-evident?

No. Encryption protects confidentiality. Integrity needs hashes, signatures or write-once storage.

Is a read-only file permission enough?

Not against someone with root on the host. Remote, separately administered storage is the stronger control.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.