Making Audit Trails Tamper-Resistant

Getting your logs off the box makes them survive. It does not, by itself, make them trustworthy. A perfectly preserved log is still worthless as evidence if someone could have quietly edited it — deleted the three lines showing what they took, or changed a timestamp to move themselves out of the frame. The question an auditor, an investigator, or a court will eventually ask is not "do you have logs?" but "how do you know these logs are the truth, unaltered?" If your only answer is "we trust our administrators," you do not have an audit trail. You have a document.

Tamper resistance is the set of practices that lets you answer that question with something better than trust. None of it is exotic, and most of it a small team can adopt without special software. This article covers four ideas that reinforce each other: append-only thinking, so logs are added to but never edited; hash-chaining, so any alteration is mathematically detectable; separation of duties, so no one person can both act and erase the evidence of acting; and evidence quality, so what you keep is the kind of thing that actually holds up when it is examined.

It follows directly from getting transfer logs off the box — you need a controlled central store before tamper resistance means anything — and it is what turns that store into evidence you can stand behind. This is part of the Logging & Audit series.

Survival Is Not the Same as Trust

It helps to separate two properties that people often blur together. Availability is whether the log still exists when you go looking — the problem centralizing solves. Integrity is whether the log you find is the same log that was written — the problem this article solves. They are independent. You can have a log that survives perfectly and has been thoroughly edited; you can have a genuine, unaltered log that got deleted. An audit trail needs both, and integrity is the one people forget until an investigation turns on it.

The threat is not abstract. The person most motivated to alter a log is usually the person with the most access — a privileged administrator, or an attacker who has stolen that administrator's access. That is exactly the person a naive logging setup trusts completely. Tamper resistance is the discipline of designing your logs so that even a powerful insider, or an attacker wearing an insider's credentials, cannot rewrite history without leaving an obvious mark.

Append-Only Thinking

Append-only means the log is a thing you add to and never change. New lines go on the end; existing lines are never edited, reordered, or individually deleted. This is the natural shape of a good ledger and the unnatural shape of an ordinary file, which any editor can rewrite silently — so append-only is something you have to arrange on purpose.

You approximate it with layers rather than one magic switch:

• Forward off-box immediately. The single strongest append-only measure is the one from the previous article: a copy of each line lands on a separate collector the instant it is written. Even if the local file is later edited, the forwarded copy already left. The attacker would have to compromise two systems, in the right order, faster than the network — a far higher bar.
• Restrict deletion to a role, and log it. On the collector, no ordinary account should be able to remove or alter stored logs. Deletion belongs to one restricted role, used rarely, and every use of it is itself recorded. If the record can be pruned invisibly, it is not append-only.
• Prefer write-once storage for the archive. Some storage can be configured so that once written, data cannot be modified or deleted until a retention period elapses — often called WORM, for "write once, read many." Rolling your log archive onto storage like this makes append-only a property of the medium, not just a policy someone could change.
• Never expose an "edit log" path at all. There is no legitimate reason for a transfer service or its administrators to have a routine way to modify past log entries. The absence of that capability is a feature.

Append-only gets you most of the way: it makes casual tampering hard and forwarded-copy tampering nearly impossible. Hash-chaining closes the remaining gap by making any tampering that does occur detectable.

Hash-Chaining, in Plain Words

Start with a hash. A hash is a short fingerprint calculated from some data — feed in a log line, get back a fixed-length string of characters. Change even one character of the input and the fingerprint comes out completely different. You cannot work backward from a fingerprint to the data, and you cannot (in practice) find two different inputs with the same fingerprint. Hashes are the foundation of file integrity generally, covered in the file integrity verification pillar; here we use them to seal a log.

Now the chain. Hash-chaining means each log entry carries the hash of the entry before it. Entry 2 stores entry 1's fingerprint; entry 3 stores entry 2's fingerprint; and so on down the line. Each entry's own fingerprint is calculated from its text plus the fingerprint it inherited — so every entry's seal depends on every entry that came before. The log becomes a chain where each link is locked to the last.

The payoff is what happens when someone edits a past entry. Change the text of entry 2, and entry 2's fingerprint changes. But entry 3 recorded the old fingerprint of entry 2 — so now they disagree, and the chain is visibly broken exactly at entry 3. To hide the edit, the tamperer would have to recompute entry 3's fingerprint, which changes entry 3, which breaks entry 4, and so on all the way to the end. One small edit forces recomputing the entire rest of the chain.

The diagram shows the chain intact, and then the break that a single alteration causes.

Here is the same idea as a tiny worked chain you can trace with your finger. Each hash is computed from the entry's own text combined with the prev-hash it inherited:

INTACT CHAIN
  entry 1:  AUTH partner-07 OK          prev-hash=0000   hash=a91f
  entry 2:  RETR /out/ack-8840.csv       prev-hash=a91f   hash=7c2e
  entry 3:  QUIT clean                   prev-hash=7c2e   hash=4db0
  verify:   0000 -> a91f -> 7c2e -> 4db0     every link matches  OK

AFTER SOMEONE EDITS ENTRY 2 TO HIDE A DOWNLOAD
  entry 1:  AUTH partner-07 OK          prev-hash=0000   hash=a91f
  entry 2:  (text changed)               prev-hash=a91f   hash=b83d   <- recomputed
  entry 3:  QUIT clean                   prev-hash=7c2e   hash=????
  verify:   entry 3 expected prev-hash 7c2e, but entry 2 now hashes to b83d
            MISMATCH at entry 3 -> tampering detected, located exactly

You will never do any of this arithmetic by hand, and you do not need to understand the mathematics of hashing to rely on it. A log collector, a lightweight logging tool, or a short script computes and checks the chain for you; your job is to switch the feature on and to protect the anchor. The hash families involved are the same well-known ones used for file integrity everywhere else, so the concept — not the algorithm — is the part worth carrying in your head.

One more move seals the very end. The chain proves internal consistency, but a determined tamperer with enough time could recompute the whole thing. So you periodically take the latest hash — the fingerprint of the whole chain so far — and put a copy somewhere they cannot reach: write it to write-once storage, send it to the separate collector, or record it in a system they do not control. Now the chain is anchored. To forge history, they would have to change a value that is already sitting, unchangeable, outside their reach. That is the practical heart of tamper-evident logging, and it is the same signed-fingerprint idea that underpins digital signatures and non-repudiation.

Separation of Duties

The cleverest cryptography fails if one person controls everything, so tamper resistance has a human half as well as a technical one. Separation of duties means the people who operate the transfer servers are not the same people who can alter or delete the central logs. Put plainly: no one should be the sole guardian of the evidence of their own actions.

Concretely, that looks like a handful of arrangements:

• Transfer-server admins cannot delete from the collector. They can read the logs, but the ability to remove or modify stored records belongs to a different role held by different people — often a security or audit function rather than the operations team.
• The collector is administered separately. The account that manages the log store is not the account that manages the transfer servers. Compromising one does not hand over the other.
• Deletion needs a second pair of hands. For the rare legitimate deletion — enforcing a retention limit, honouring a privacy request — require two people, or at least record the action where the person taking it cannot later erase it.
• The auditor is not the audited. Whoever reviews the logs for wrongdoing should not be someone whose own wrongdoing the logs might contain. Independence is the whole point of an audit.

Separation of duties is what makes the technical controls meaningful. Append-only storage that the one all-powerful admin can reconfigure is not append-only; a hash chain whose anchor that same admin controls is not anchored. Splitting the roles removes the single person who could undo everything.

Evidence Quality: What Actually Holds Up

All of this aims at one outcome: logs that qualify as good evidence when someone finally examines them. "Evidence quality" is not a vague aspiration — it is a fairly concrete list of properties that auditors look for and that give a record weight in a dispute.

• Integrity you can demonstrate. You can show the record has not been altered — through the forwarded copy, the hash chain, the anchored fingerprint — rather than merely asserting it. "Here is why tampering would have been detected" beats "trust us."
• Trustworthy, synchronised time. Every timestamp is meaningful and comparable because all your machines share a synchronised clock. Evidence built on times that do not line up is evidence that falls apart under questioning; the signatures and non-repudiation pillar returns to this repeatedly.
• A chain of custody. You can account for where the logs have been and who could touch them from the moment they were written — created on the server, forwarded to the collector, retained under stated controls. Gaps in custody are where doubt gets in.
• Corroboration. The transfer log agrees with the firewall log, the authentication log, and any delivery receipts. Several independent records telling the same story are far harder to dismiss than one. This is exactly the value of a structured receipt like an AS2 MDN, discussed in MDN proof of delivery — an independent confirmation that corroborates your own logs.
• Completeness. The record covers the whole event without unexplained gaps, because you logged the right things (from what to log) and kept them long enough (retention from centralizing).

Notice that no single control delivers evidence quality on its own. It is the combination — the right events, preserved off-box, made append-only, sealed by a hash chain, guarded by separated duties, and stamped with trustworthy time — that produces a record able to withstand scrutiny.

Picture the request that tests all of it. Months from now, someone asks: "Prove that the download record for this account is complete and was not edited to remove a file." A weak setup answers with a shrug and an assurance that the team is trustworthy. A tamper-resistant setup answers with substance: here is the forwarded copy that left the server in real time; here is the hash chain, intact, whose anchor we published daily to a system operations cannot touch; here is the firewall log showing the same session from the same IP at the same synchronised timestamp; and here is the record of who could have deleted anything, and the fact that no such deletion is logged. That is the difference between hoping you are believed and being able to demonstrate the truth.

Tamper Resistance for a Small Team

Separation of duties assumes you have enough people to separate, and plenty of shops run their whole transfer estate with two or three administrators who each do everything. You cannot invent staff you do not have — but you can still remove the single point where one person silently rewrites history, which is most of the benefit. Aim for "good enough," honestly implemented, rather than a textbook model you cannot staff.

A workable small-team version looks like this. Forward every server's logs to a collector where the delete permission is held by one person — ideally the person least involved in day-to-day transfers, such as a manager or a security-minded colleague — rather than shared across the whole team. Lean on the medium to do the separating that people cannot: put the archive on write-once storage, or in a managed store configured so that even an administrator cannot alter what is already written, and let that technical guarantee substitute for a role you do not have. Anchor the chain somewhere outside the operations team's control — a hash mailed daily to a distribution list, or recorded in a system a different department runs — so the seal does not depend on the same hands that hold the logs. And write down, plainly, who can do what, so the arrangement survives the next staff change. It is not perfect independence, but it converts "any admin could quietly edit the record" into "altering the record requires defeating the storage medium and the outside anchor" — a bar an opportunist will not clear.

A Tamper-Resistance Checklist

Copy this into your logging standard and work down it. Each item is a lever; together they turn a preserved log into trustworthy evidence.

TAMPER-RESISTANCE CHECKLIST
===========================

APPEND-ONLY
[ ] Logs forwarded off-box the instant they are written
[ ] No routine path to edit or reorder past entries
[ ] Deletion limited to one restricted role
[ ] Every deletion is itself logged, out of that role's reach
[ ] Archive on write-once (WORM) storage where possible

INTEGRITY
[ ] Hash-chaining or equivalent tamper-evidence in place
[ ] Latest chain hash periodically anchored out of reach
[ ] Integrity can be demonstrated, not just asserted

SEPARATION OF DUTIES
[ ] Transfer-server admins cannot delete central logs
[ ] The collector is administered by different accounts
[ ] Legitimate deletion needs a second pair of hands
[ ] The reviewer is independent of the reviewed

EVIDENCE QUALITY
[ ] All machines on a synchronised clock (UTC preferred)
[ ] Chain of custody documented, server -> collector -> archive
[ ] Corroborating logs (firewall, auth, receipts) kept together
[ ] Retention long enough for late-discovered incidents

Where This Leaves You

A log that survives is necessary but not sufficient. To be an audit trail, it must also be trustworthy — provably the same record that was written. You get there by making logs append-only so they are added to but never edited, by hash-chaining so any alteration is detectable and locatable, by separating duties so no one person can both act and erase, and by tending the details of evidence quality — synchronised time, chain of custody, corroboration — that make a record hold up. None of it requires a large budget; all of it requires deciding, on purpose, that your logs are evidence and treating them accordingly.

Next, turn this trustworthy record into early warning with alerts worth raising from transfer logs, and into painless audits with audit-ready reporting. If you have not yet built the controlled central store this article assumes, start with getting transfer logs off the box.

Frequently Asked Questions