AU.L2-3.3.1  System Audit Logging

1Overview

AU.L2-3.3.1 opens the Audit and Accountability family and is one of the most heavily weighted requirements in the framework. It requires that the system create and retain audit logs sufficient to monitor, analyze, investigate, and report unlawful or unauthorized activity. It is a five-point requirement that cannot be deferred on a plan of action, because without records of what happened, none of the later audit controls have anything to work with.

Auditing is the system's memory. When something goes wrong, a compromised account, a file taken, a control bypassed, the audit record is what allows the organization to see that it happened, understand how, and respond. This control is the foundation of that memory: it asks the organization to decide what events must be logged, define what each record must contain, generate those records, and retain them long enough to be useful. The word "sufficient" is doing real work, because logs that capture too little, or are discarded too soon, cannot support the monitoring and investigation the rest of the family depends on.

The requirement has two connected parts: create and retain. To create is to log the event types that matter, with records that carry enough content, the who, what, when, where, and outcome, to be meaningful. To retain is to keep those records for a defined period so they are available when an investigation needs them. The five-point weight reflects that audit records are the evidence base for the entire family, and an environment that does not generate and keep them is blind to its own history.

2The Assessment Objectives

NIST SP 800-171A decomposes 3.3.1 into six objectives: specify the event types, define the record content, generate the records, confirm they carry the content, define retention, and retain accordingly.

The six objectives pair definition with execution across three subjects: what to log, what each record holds, and how long to keep them. The common gap is at objectives [e] and [f], retention, where logs are generated but roll over within days, so by the time an incident is noticed the relevant records are gone. The assessor looks for records that are both sufficiently detailed and retained long enough to matter.

3Failure Patterns

The failures are about logging too little, records that lack content, and retention too short to be useful.

4Ownership

This is an IT-owned technical control, and its main demands are deciding what to log and building retention that outlasts the delay between an event and its discovery.

5Tooling

The control is delivered by the logging built into the systems and by central collection that gives the records a retained home.

The caveat is that logging locally is not the same as retaining usefully. Local logs roll over, so central collection with a defined retention period is usually what actually satisfies objectives [e] and [f]. The assessor examines what is logged, what the records contain, and how long they are kept, so all three have to hold together across the systems in scope.

6Evidence

The satisfied version of 3.3.1 shows specified events, defined and present record content, and retained records across the environment.

The evidence should show that the right events are logged, that the records carry enough to investigate, and that they are kept long enough to be there when needed. Configuration plus sample records plus a central retention setup, spanning the systems in scope, is the clearest demonstration, and because this control cannot sit on a plan of action, the logging has to be real and retained at the time of assessment.

7Sources