CMMC Audit Logging on Linux

What Does CMMC Require of Linux Audit Logs?

CMMC — the Cybersecurity Maturity Model Certification — is the US Department of Defense's programme for verifying that contractors protect the controlled unclassified information (CUI) they handle. Its Level 2 aligns with the security requirements of NIST SP 800-171 and is verified by a third-party assessor, a C3PAO. Nowhere does it name an operating system, but the systems that store and process CUI are overwhelmingly Linux, so its audit-logging requirements land squarely on how you configure the Linux Audit daemon, auditd.

Search for how to actually do this and the results are thin — the most visible answer is a Reddit thread in which a practitioner concludes the concrete guidance does not exist. It does; it is just rarely written down for Linux. This page maps the audit-logging expectations of CMMC to the auditd rules, retention, and protection that satisfy them, so that when an assessor asks to see your audit records you have a defensible answer rather than a screenshot and a hope.

Scope decides how much of this applies. Contractors handling only federal contract information face the lighter Level 1; those handling CUI face Level 2 and the full NIST SP 800-171 requirement set, assessed by a C3PAO rather than self-attested. The in-scope boundary is the set of systems that store, process, or transmit CUI, together with the infrastructure that protects them — and on those Linux hosts the audit trail is not optional supporting material but a control an assessor will test directly, host by host.

AU.L2-3.3.1 and the Audit and Accountability Domain

The anchor practice is AU.L2-3.3.1, drawn from NIST SP 800-171. In full, it requires an organisation to "create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity." Two verbs carry the weight: create — the logs must actually be generated for the activity that matters — and retain — they must survive long enough, and intact enough, to support an investigation.

AU.L2-3.3.1 does not stand alone; it sits in the Audit and Accountability domain, and a Linux team has to satisfy its neighbours in the same breath. Practice 3.3.2 requires that logged actions can be traced to an individual user — which rules out shared root logins, because a shared account attributes nothing. Practice 3.3.4 requires the system to alert on a failure of the audit logging process, so a stopped auditd cannot pass unnoticed. Practice 3.3.7 requires an authoritative time source, so events on different hosts can be correlated. Practices 3.3.8 and 3.3.9 require the audit information to be protected from unauthorised access, modification, and deletion, and audit management to be limited to a privileged subset of users. Read together, they describe a complete, attributable, tamper-resistant audit trail — and on Linux that is an auditd configuration.

The phrase "to the extent needed" is not a licence to log little. In assessment practice it means the events that let you detect and investigate misuse: successful and failed logons, failed access attempts, use of privileged commands, changes to accounts and credentials, and use of third-party or shared credentials — each recorded with enough detail to answer who did what, where, and when. Logging both successes and failures matters because an attacker's successful action looks identical to a legitimate one until the record lets you trace it back to an account and a moment.

auditd Rules That Satisfy an Assessment

auditd ships with every enterprise Linux distribution and is the mechanism assessors expect to see. The task is to make its rules complete: capture logon and privileged activity, record both successes and failures, attribute every event to the real user through the audit login uid (auid), and watch the files whose change would matter to an investigator. A workable baseline looks like this:

## authentication and session activity
-w /var/log/lastlog -p wa -k cmmc_logins
-w /var/run/faillock/ -p wa -k cmmc_logins
## identity and credential changes (3.3.2 attribution)
-w /etc/passwd -p wa -k cmmc_identity
-w /etc/shadow -p wa -k cmmc_identity
-w /etc/group  -p wa -k cmmc_identity
-w /etc/sudoers -p wa -k cmmc_privilege
-w /etc/sudoers.d/ -p wa -k cmmc_privilege
## privileged command execution, attributed to the real user
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k cmmc_rootcmd
## access to and protection of the audit trail (3.3.8)
-w /var/log/audit/ -p wra -k cmmc_logaccess
-w /etc/audit/ -p wa -k cmmc_auditconfig

The details matter to an assessor. Filtering execve on auid greater than or equal to 1000 ties a privileged command to the human who ran it rather than to root, directly supporting the attribution practice. Watching /etc/audit and the audit log directory records anyone touching the audit configuration or the logs themselves. Running auditd with its rules made immutable — the -e 2 setting, which prevents changes until a reboot that is itself logged — is how you demonstrate the logs are protected from tampering. None of this is exotic; the failure mode is not exotic either — it is auditd installed but left with a near-empty ruleset that logs almost nothing.

Generating and keeping the records is not sufficient on its own; the Audit and Accountability domain also expects them to be reviewed. An assessor looks for evidence that a person examines the audit data on a defined schedule and that the review is itself recorded, producing dated artefacts a C3PAO can inspect. A trail nobody reads meets the letter of log creation while missing its purpose — to notice unlawful or unauthorised activity in time to act on it — so the review cadence and its output are as much a part of the evidence as the rules that generate the logs.

Retention and Protection

Creating the records is half of AU.L2-3.3.1; retaining and protecting them is the other half. NIST SP 800-171 does not name a specific retention period, and it is important not to assert one it does not set. In practice, assessors and DoD contracts commonly expect on the order of ninety days of readily available logs backed by roughly a year of archived history — but the governing figure is whatever your contract and system security plan specify, so confirm that rather than a number from a blog. The defensible approach is to state your retention period, meet it, and be able to show it. Whatever period you choose belongs in your system security plan, because the SSP is the document an assessor reads first and measures the hosts against; a retention practice that lives only in someone's memory is a finding waiting to happen.

Protection is where local logs fall down. If a privileged user on a host can edit or delete /var/log/audit, the audit trail proves nothing, so practice 3.3.8 pushes you to ship logs off the host to a central, access-controlled store that the local administrators cannot alter, and to limit who can manage the audit system at all (3.3.9). A central collector also satisfies the correlation the domain expects, and combined with an authoritative time source (3.3.7) it lets an investigator reconstruct an event across the whole estate rather than one host at a time.

Common Implementation Gaps

Most CMMC audit-logging findings on Linux come from a short list of recurring gaps. auditd is installed but effectively idle, running the distribution's minimal ruleset rather than one built for the AU practices. Root is shared, so events cannot be tied to an individual and practice 3.3.2 fails no matter how good the logging is. Nothing alerts when auditd stops, so a host silently drops out of coverage until someone notices — if they ever do — breaching 3.3.4. Logs stay on the host instead of a protected central store, so a compromised administrator can erase the evidence. And sometimes the trail captures everything except the one thing that matters — privileged escalation — because the ruleset was never told to watch sudo or execve, leaving comprehensive-looking logs that miss the events an investigator most needs.

The subtler gap is drift. A ruleset that is correct on the golden image quietly diverges as hosts are patched, rebuilt, and hand-edited, so the fleet an assessor samples no longer matches the configuration you documented. The only durable answer is to treat the audit configuration as something verified continuously: check every in-scope Linux host against the intended ruleset, confirm auditd is active and immutable, and flag the moment a host falls out of line — so that the audit trail an assessment depends on is provably present everywhere, not just on the machine you last looked at.

For how CMMC audit logging fits alongside NIS2, DORA, and the wider compliance picture, see the Linux access controls evidence guide, which walks through the access-control and audit expectations across frameworks for IT teams.

FAQ

Does CMMC apply to Linux servers?

CMMC does not name any operating system, but it applies to the systems that store or process controlled unclassified information, which are overwhelmingly Linux. Its Level 2 requirements align with NIST SP 800-171, and the Audit and Accountability practices — starting with AU.L2-3.3.1 — are satisfied on Linux by configuring auditd to generate, attribute, retain, and protect the audit trail an assessor will examine.

What is CMMC practice AU.L2-3.3.1?

AU.L2-3.3.1, drawn from NIST SP 800-171, requires organisations to create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. On Linux that means auditd must generate logs for the activity that matters and those logs must be retained, intact, long enough to support an investigation.

What auditd rules does CMMC need on Linux?

A ruleset that captures logon and session activity, changes to identity and credential files, privileged command execution attributed to the real user via the audit login uid, and any access to the audit configuration and logs themselves — recording both successes and failures. Running auditd with immutable rules (-e 2) and shipping logs to a protected central store supports the related practices for attribution, failure alerting, and tamper protection.

How long must CMMC audit logs be retained on Linux?

NIST SP 800-171 does not mandate a specific retention period. In practice assessors and DoD contracts commonly expect on the order of ninety days of readily available logs plus about a year of archived history, but the governing requirement is whatever your contract and system security plan specify. State your retention period, meet it, protect the logs from modification and deletion, and be able to evidence all three.