Trackr.Live The landing site for Trackr Services
§ Trackr.Live

AU — Audit and Accountability

Audit and Accountability is the family that answers the question every incident eventually asks: who did what, when, from where, and can you prove it. AU governs which events the system records, what each record contains, how the records are protected, how long they survive, and who is allowed to read or alter them. It does not decide who gets access (that is AC) and it does not establish identity (that is IA). What AU does is bolt accountability onto the actions those families permit, so that an authenticated, authorized user still leaves a trail you can reconstruct later. When an SSP smears AC, IA, and AU into one “logging and access” narrative, an assessor reading carefully will pull them apart, and AU is usually the one written thinnest.

Schematic of an audit trail: timestamped event records streaming from several hosts into a sealed, append-only store guarded against the administrators feeding it.

AU is a control catalog family from SP 800-53, not a step in the RMF. The RMF is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. AU controls get pulled in at Select off the 800-53B baseline for your impact level, implemented and documented at Implement, and graded at Assess. Whatever fails lands in the POA&M and rides into continuous monitoring, where AU has a second life: the audit records this family generates are the raw feed for CA-7 continuous monitoring and SI-4 system monitoring. So AU is both a thing that gets assessed and the plumbing that keeps assessing everything else.

What’s in the family

In Rev 5 the AU family runs AU-1 through AU-16, but that range is not a clean list of live controls, and getting this wrong is the fastest way to look like you’re quoting Rev 4. AU-7’s audit reduction capability and AU-15’s alternate logging capability both got reworked in the Rev 4-to-Rev 5 cleanup (AU-15 was withdrawn and folded into AU-5(5)). If your SSP still cites “AU-15, Alternate Audit Capability” as a live requirement with full prose, that’s a stale artifact someone forgot to retire. Verify the live-vs-withdrawn status against the current catalog before you write a word of narrative.

The ones that carry the weight:

  • AU-1, Policy and Procedures. The family -1. Org-level audit policy plus the procedures that operationalize it. First thing pulled, because everything else inherits its existence from here.
  • AU-2, Event Logging. Note the Rev 5 title — it’s Event Logging, not the Rev 4 “Audit Events.” This is event selection: which events the system is capable of logging and which subset you actually turn on, plus the cadence for reviewing that selection with the people who consume the logs.
  • AU-3, Content of Audit Records. The base control wants the who/what/when/where/source/outcome of each event. The real content lives in the enhancement, AU-3(1) Additional Audit Information, which is where session IDs, full command text, and the extra fields an investigator actually needs come from. Conflating the base and the enhancement is a common SSP tell.
  • AU-4, Audit Log Storage Capacity. Sizing the store so you don’t blow past it. Reads boring until you connect it to AU-5 and AU-11 and realize it’s a budget control wearing a technical hat.
  • AU-5, Response to Audit Logging Process Failures. What the system does when logging breaks — alert, shut down, or overwrite oldest. AU-5(1) adds a storage-volume warning threshold; AU-5(2) adds real-time alerting on failure.
  • AU-6, Audit Record Review, Analysis, and Reporting. Someone (or something) actually looks at the records. AU-6(1) automates the process, AU-6(3) correlates across repositories so a login here and a privilege escalation there line up.
  • AU-8, Time Stamps. Authoritative time source, internal clocks mapped to UTC. This is where the time-skew problem lives, and it’s load-bearing for AU-6(3) correlation.
  • AU-9, Protection of Audit Information. Protects the records from tampering and deletion. AU-9(2) stores logs on a separate system, AU-9(3) adds cryptographic protection, and AU-9(4), Access by Subset of Privileged Users, is the one that protects the audit trail from the admins it’s auditing.
  • AU-11, Audit Record Retention. How long records survive. Driven as much by regulation and legal hold as by security need.
  • AU-12, Audit Record Generation. The control that says the system can actually produce the records AU-2 selected, at the components that matter, attributable to the right identity. AU-12(1) builds a system-wide, time-correlated trail; AU-12(3) governs changes to what gets logged.

AU-13 (Monitoring for Information Disclosure), AU-14 (Session Audit), and AU-16 (Cross-Organizational Audit Logging) are real, live Rev 5 controls, but they are not in the standard Low/Moderate/High baselines. You get them through an overlay or a tailoring-in decision, not by default. AU-16 matters on shared or joint systems where audit responsibility crosses an org boundary. AU-10 (Non-Repudiation) is also live but allocated differently: it first goes live at High in the 800-53B baseline (it’s absent from Low and Moderate), so a High system carries it by default while a Low or Moderate one only picks it up through tailoring or an overlay where non-repudiation is a mission requirement. Don’t write AU-13/14/16 up as universal mandates, and don’t write AU-10 up as overlay-only when it’s a standing High-baseline control.

Baselines and where the controls come from

The baselines moved out of the catalog in Rev 5. Low/Moderate/High allocations now live in SP 800-53B, the document you tailor against. FIPS 199 sets categorization, FIPS 200 sets the floor, 800-53B turns the impact level into a starting control set, and CNSSI 1253 overlays it for national-security systems. AU-2, AU-3, AU-4, AU-5, AU-6, AU-8, AU-9, AU-11, and AU-12 are in all three baselines. The enhancements are where the climb happens: AU-3(1), AU-6(1) and AU-6(3), and AU-9(4) come in at Moderate and stay through High, while AU-9(2), AU-9(3), AU-12(1), and AU-12(3) are High-only and don’t appear until you hit the High baseline. So your AU control set is the 800-53B baseline for your level, plus or minus tailoring you can defend, plus whatever your overlay forces.

Deeper: the enhancement that everyone tailors out, and shouldn’t.
AU-9(4), Access by Subset of Privileged Users, is the single highest-value AU enhancement that quietly goes missing, and that’s the flag I’ll plant on this page. The base AU-9 protects logs from ordinary users, which is easy and which everyone implements. AU-9(4) is harder: it says the people who can read and manage the audit logs must be a different, smaller set than the people who administer the systems being audited. The threat model is the malicious or compromised admin who clears their own tracks, and a root account that can both take an action and delete the record of it makes the entire AU family decorative. Real separation means the log store is somewhere the system admins can’t reach — a separate Splunk index with its own RBAC, forwarders that ship write-only over a one-way path, retention enforced by WORM or append-only object storage with an immutability lock the admins can’t unset. Shops skip it because it’s organizationally painful (now you need a log-admin role that isn’t your sysadmin role) and because the assessor often lets a hand-wave slide. At High it shouldn’t slide. If your domain admins can rm the security event log, you don’t have AU-9.

Control Typical first live at What an assessor actually checks
AU-2 Low The event selection list, compared to the SSP. Are privileged-function events actually selected, or just “successful logons”?
AU-3 Low Pull a real record. Does it carry who/what/when/where/outcome, or just a timestamp and a vague action?
AU-3(1) Moderate The additional fields (session ID, full command, source) are present in records, not just promised in policy.
AU-4 Low Storage sizing math versus actual daily volume. How many days before the store fills?
AU-5 Low Trigger a failure (or check config). Does it alert, shut down, or silently overwrite? Confirm it matches the documented behavior.
AU-6 Low Evidence of actual review, not a dashboard that loads. Who looked, when, and what did they do about it?
AU-8 Low Time source configured to an authoritative server; sample host clocks for skew against UTC.
AU-9(4) Moderate Log-admin role is distinct from system-admin role; system admins cannot delete or alter the audit store.
AU-11 Low Retention period config matches the SSP and the records actually go back that far.
AU-12 Low The components in scope are generating records and feeding the trail; no silent gaps.

Treat “first live at” as directional. An overlay moves things, and a FedRAMP or DoD baseline often pulls AU enhancements in above the bare 800-53B set.

Where it actually goes wrong

Time skew quietly poisons correlation. AU-8 reads like a checkbox until you try to reconstruct an incident across twelve hosts and the timestamps don’t line up. Two minutes of drift between a web front-end and the database behind it is enough to scramble cause and effect, and AU-6(3) correlation across repositories is only as good as the clocks feeding it. Point everything at the same authoritative source and map internal clocks to UTC, not local time (chasing a DST-shifted log set during an incident is its own special misery). The usual failure is a host whose NTP/chrony stopped syncing months ago and nobody noticed, because nothing alerts on clock drift until an investigation needs those timestamps and they’re already wrong. Check that the time service is actually running and reachable, not just configured.

Log volume versus retention cost is a real budget fight, and AU-4/AU-11 are where it surfaces. Turn on verbose logging across the fleet and the daily volume goes from interesting to expensive fast. Hot storage that’s instantly searchable costs real money; cold archive is cheap but slow to pull. The honest design is tiered: keep recent records hot for active hunting and meeting the AU-6 review cadence, age the rest to cold for the AU-11 retention tail (often a year, sometimes far longer when legal hold or a regulatory driver applies). Where shops go wrong is setting AU-11 retention by aspiration instead of by what the AU-4 storage budget can actually hold, then either silently dropping records or watching the index fill. The retention number in the SSP has to be the number the storage can keep, and an assessor will pull records from the far end of the stated window to check.

AU-5 gets misconfigured at exactly the wrong moment. The three behaviors when logging fails (alert and continue, overwrite oldest, or halt the system) are not interchangeable, and the default is often the worst choice for a High system. A box configured to overwrite-oldest on a full audit log will cheerfully erase the evidence of the very activity that filled it. A box configured to halt on logging failure is more defensible for High-impact systems but turns a logging hiccup into an availability outage, so it needs AU-5(2) real-time alerting in front of it or someone gets paged at 0300 for a disk that filled. Pick the behavior on purpose, document it, and make sure the config matches the SSP, because this is one an assessor can trigger and watch.

AU-6 review that’s a dashboard nobody reads. This is the contestable one, so I’ll say it plainly: a large share of “AU-6 satisfied” claims are a SIEM dashboard that loads, not analysis that happens. Standing up Splunk and pointing AU-6 at it satisfies the tooling, but AU-6 asks for review, analysis, and reporting by humans or by tuned automation that escalates. A dashboard nobody opens between assessments is not review. The defensible version is AU-6(1) automation that generates alerts on defined conditions and a documented trail of who triaged them, with AU-6(3) correlating across the repositories so the picture is whole. If the only evidence of review is that the dashboard exists, expect “Other Than Satisfied.”

The cross-family ties that matter

AU doesn’t stand alone, and the assessor knows the seams. The defining tie is to AC: AC-6(9), logging of privileged-function execution, is selected over in Access Control but the record lands here, in the AU trail. If AC-6(9) is claimed but the privileged events aren’t in the audit store, both controls are weaker than the SSP says. AU also feeds IR — the audit records are what IR-4 and IR-5 reach for during incident handling — and it’s the data source under SI-4 system monitoring and CA-7 continuous monitoring. The identity in each record traces back to IA, which is what makes accountability stick. An AU narrative that never references these seams is describing a logging system in isolation, which is not how the family is actually assessed.

The fastest way to fail an AU assessment is an SSP that restates the 800-53 control text back at the assessor instead of describing what this system logs, where it keeps the records, who’s locked out of them, and how long they survive. They’ve read the catalog. They want your event selection list, your retention number, your time source, and your log-admin role.

Sources

Adjacent material on this site