Edge Logs as Evidence: An Audit Log That Proves What Was Served

01 /What an edge audit log can and cannot prove

An audit log at the edge or balancer is the record you produce when someone asks what your site served to a particular client at a particular time: a security review after a compromise, or a rights holder asking whether a file was ever available. An ordinary access log answers weakly: it is a text file on a machine the operator controls, written by a clock nobody checked, rotated away on a schedule nobody remembers. The Provenance on the Wire lane treats the log as an artefact with its own integrity requirements.

What a well-kept log can prove: that at a stated time, on a traceable clock, the edge received a request with these headers from this address and returned this status with a body of this digest, and that the record has not been altered since it was signed. What it cannot prove: that the address belonged to a particular person, that the digest matches a particular file unless you kept the file, or anything about requests that never reached the edge. An audit log that overclaims is worse than none.

02 /Which fields prove what: a log line dissected

Below is an RFC 5424 message as an edge might emit it, with the evidential fields in a structured data element rather than the free text, so a parser and a signature can both find them.

<134>1 2026-09-24T10:15:42.318905+00:00 edge-17 fnedge 4121 ACCESS
  [access@32473 src="203.0.113.44" srcport="51234" bot="verified" botm="fcrdns"
   req="GET /firmware/fi-8.0.30.bin HTTP/2" status="200" bytes="18874368"
   rdig="sha-256=:8XcVg1WzR0hK0wHq1rN3E2h6bO0yqk6yJ0J1mQm7cTQ=:"
   tls="1.3" cipher="TLS_AES_128_GCM_SHA256" sni="downloads.example.net"
   ua="Mozilla/5.0 (compatible; Googlebot/2.1)"] -

The bot state comes from the verified-bot checks at the balancer and is the only way to later show that a request treated as a crawler really was one. The rdig field is an RFC 9530 Repr-Digest of the body, which identifies what was served without storing it; keep the files elsewhere with their hashes and the two records corroborate each other.

03 /Time source and the RFC 5424 syslog format

Every claim in a log hangs on the timestamp, and a timestamp is only as good as the clock. RFC 5905 defines NTP version 4; run every edge node against at least two internal NTP servers that reference a traceable source, monitor the offset, and log a warning past a written threshold.

RFC 5424 gives the message a header of priority, version, timestamp, hostname, application name, process identifier and message identifier, then structured data and an optional free-text message. The timestamp is RFC 3339 form with a mandatory offset and an optional fraction to six digits; use UTC and the fraction. Structured data elements carry name and value pairs under an identifier that, for private use, ends in an IANA enterprise number, as access@32473 does above with the documentation number.

04 /RFC 5848: signed syslog messages

RFC 5848, Signed Syslog Messages, adds origin authentication, integrity, replay resistance, sequencing and detection of missing messages to an RFC 5424 stream. A Signature Block message, sent periodically, carries hashes of the preceding messages in a Signature Group and a signature over them. The block is itself a syslog message with an ssign structured data element holding a version, a reboot session identifier, a global block counter, the first message number covered, a count, the hash block and the signature.

A verifier recomputes the hash of each stored message, checks it against the hash block, and checks the signature with the signer's certificate, distributed in Certificate Block messages under ssign-cert. RFC 5848 requires SHA1 and recommends SHA256; use SHA256. The session identifier and counters expose any missing message. Few edge products emit RFC 5848 natively, so in practice the collector signs the plain RFC 5424 stream it receives over TLS, which moves the trust boundary from edge to collector; document that.

05 /Hash chains and write-once storage

Where RFC 5848 is unavailable, a hash chain gives most of the same guarantee. Each block of records stores the hash of the previous one, so the chain has a single head; publish that head periodically somewhere you do not control (a timestamping service, a printed register, a third party), and any later edit changes every hash after it and breaks the match with the anchor. Anchor often, since verification runs from the last anchor.

The signed or chained log must leave the edge quickly, over a transport that authenticates both ends, into a store the edge cannot modify: append-only object storage with retention locks, write-once media, or a collector whose write path is separate from its read path. An edge writing its own audit log to local disk is the arrangement an examiner trusts least. Corroboration from other devices helps: sampled flow records and interface counters read over SNMP come from different clocks with different failure modes.

06 /Building the audit log, step by step

1. 01

   Fix the clock

   Configure NTP against at least two servers, record the offset into the same log stream, and alarm on drift past your written threshold.

2. 02

   Define the record

   Choose the structured data fields from the table, assign a private enterprise number for the element, and emit RFC 5424 with UTC timestamps and fractional seconds, the verified-bot state and the body's Repr-Digest.

3. 03

   Ship it off the edge

   Send the stream to a collector over mutually authenticated TLS, so the collector knows which edge wrote each record.

4. 04

   Sign or chain on the collector

   Enable RFC 5848 signature blocks with SHA256, or a hash chain with an anchor published at a fixed interval. Store the signer's certificate and the anchors separately from the log.

5. 05

   Store write-once

   Write the signed stream to append-only storage with a retention lock equal to the retention period, which nobody can shorten without leaving a record.

6. 06

   Verify on a schedule

   Run the check in the transcript below against a sample daily and the full archive quarterly, and log the outcome.

7. 07

   Write down retention and disposal

   State the period, the reason and the disposal method; delete on schedule and log the deletion.

$ logverify --cert collector-signer.pem --batch access-2026-09-24-10.log
batch: rsid=1710000000 gbc=4417 fmn=88210 cnt=500 hash=sha256
message hashes recomputed: 500 of 500 match
sequence: no gaps in 88210..88709
signature: valid, signer CN=collector-2, not_after=2026-12-31
result: PASS
$ logverify --cert collector-signer.pem --batch access-2026-09-24-11.log
message hashes recomputed: 499 of 500 match (mismatch at msg 88903)
result: FAIL: record altered after signing

07 /Retention: how long, and how to end it

There is no universal retention period, only the one you can justify. NIST SP 800-92, the Guide to Computer Security Log Management, frames it as a policy question set by the organisation's legal and operational needs and enforced by the log infrastructure. Write the period down with its reason, apply it with retention locks, and treat disposal as a logged event. A log that ends on the date the policy predicts is evidence of process; one that ends when the disk filled is evidence of nothing.

08 /Pitfalls: clock drift, hidden addresses, broken chains

• Clock drift. An edge whose NTP client silently stopped keeps writing confident, wrong timestamps. Log the offset, alarm on it, and record the server used so timestamps can be corrected rather than discarded.
• Proxies hiding the client address. Behind a CDN or upstream balancer, src is the proxy. Log a forwarded-address header only when it came from a hop you authenticated, and log which hop supplied it.
• Log rotation breaking the chain. A rotation that starts a new file without carrying the previous hash forward, or compresses and re-timestamps the old one, breaks the chain at every boundary. Chain across files and rotate on the collector, never on the edge.
• Signing on the edge with its own key. If the edge is compromised, its key is too, and every block it signed is suspect. Sign on the collector.

The log is the ledger of every other page in the provenance section: it records the result of the reverse-DNS and signature checks on crawlers, the digests from integrity checks on served content, and the validation state of routes from RPKI origin validation.

An audit log at the edge is the ordinary access log with four additions: a checked clock, a defined record, a signature over it and a store it cannot be quietly removed from. Build those four and verify the archive on a schedule, and the next time someone asks what you served and when, the answer is a file rather than a recollection.