Protecting logs from tampering: a practical checklist

To keep logs trustworthy, send them off the machine that produced them, restrict who can modify or delete them, secure the transport, record access to the logs themselves and monitor for gaps. An attacker who reaches a server will often try to edit its logs first.

The threats to plan for

The OWASP logging guidance describes attacks on logs in four groups: exposure of personal data and secrets, integrity attacks through crafted payloads, availability attacks such as filling the disk, and accountability attacks such as blocking writes or forging identities.

A checklist should cover each.

Integrity

• Forward logs to a separate system in near real time. A local file on a compromised host is not evidence.
• Give the sending application permission to append only. It should not be able to read back or delete.
• Give the log store separate administrators from the systems it records.
• Add tamper detection where practical. OWASP lists this along with copies on read-only media as soon as practical.
• Sanitize input so attackers cannot forge entries. See the post on log injection.

Confidentiality

• Keep secrets, tokens and passwords out of logs to begin with.
• Restrict read access, and review who has it on a schedule.
• Remember that logs often hold personal data. Treat the store as sensitive.

Transport

• Use an encrypted channel, such as syslog over TLS, across untrusted networks, as OWASP suggests.
• Verify the origin of events where forgery matters, for example by authenticating the sender.

Availability

• Set disk and ingestion limits so a flood from one source does not push out everything else.
• Alert when a source stops sending. Silence is a signal.
• Make sure logging failures do not crash the application or leak information, which OWASP also calls out.

Accountability

• Record and monitor all access to the logs themselves, including searches and exports.
• Keep clocks in sync so events from different systems can be ordered.
• Do not exclude internal systems or testers from logging. OWASP says to flag them instead.

Test it

Once a quarter, run a drill. Pick a host, write a harmless marker event, then check it reached the central store and that the host account cannot alter it there. Also stop a source on purpose and confirm the silence alert fires. Keep the result as evidence, because auditors often ask how you know your logs are complete.

If you use a compliance platform to collect evidence, keep log protection settings among the items it tracks. Safeguard's compliance and evidence automation can hold this kind of control evidence next to the rest of your audit material.

Quick check

Sources

• OWASP Logging Cheat Sheet

Related: log injection and forged entries.

Last reviewed: 19 October 2026.