Audit trail

PEART keeps an audit trail because the product deliberately does not defend against its most privileged actors, the host operator and the installation administrator. The trail does not stop them; it records what happened, so an investigation has a truthful account.

Insert-only

The audit trail is an insert-only table: the application never updates or deletes a row in it. An audit record, once written, is not rewritten by the same system that wrote it, which is what lets it be trusted as a record rather than a mutable view.

What is audited, by rule

What gets audited is defined by a generative rule, not a list someone has to remember to extend. Every event that changes security-relevant state is recorded, so a new action in one of those categories is audited by construction rather than by someone remembering to add it. Authentication and authorization decisions, changes to a finding's disposition, report release and withdrawal, and key destruction all land in the trail.

Two of those deserve naming, because they are the ones an auditor asks about. Withdrawing a full report also withdraws the released retest summaries of that engagement, and each cascading withdrawal is its own record that names the document which caused it, so the chain is readable months later. And when an administrator releases another user's edit lock by hand, that forced release is recorded; the automatic releases the interface performs by itself never touch another user's lock, so they never produce one of these records.

Identifiers, never content

The trail records identifiers and never content values. An audit record that copied a finding's text would turn the audit table into a second, unencrypted copy of the most sensitive asset, so it records which record changed and by whom, not what the text said. When an engagement is purged, the destruction of its key is itself recorded, so the erasure leaves a trace even though the data it erased does not.

An actor can outlive the account that names it. The actor's id and a readable label are written into the line itself, and neither is a foreign key, so removing a portal account, or purging an engagement, leaves those lines legible and attributed. A reader who looks up an actor and finds no matching account in the roster is seeing the design, not an inconsistency.