This post explains how to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control AU.L2-3.3.1 by creating, protecting, and retaining system audit records — with practical steps, concrete technical settings, and small-business examples you can implement immediately.
\n\nAU.L2-3.3.1 requires organizations to generate audit records that support detection, investigation, and reporting of unauthorized or anomalous system activity, then protect those records from tampering and retain them long enough to support investigations and contractual/regulatory requirements. The control does not prescribe a specific retention period; instead you must define and document a retention policy that meets your risk profile, contract clauses (e.g., DFARS), and investigative needs.
\n\nStart by listing all systems that process or transmit controlled unclassified information (CUI) or are critical to security: domain controllers, file servers, workstations with CUI access, cloud consoles, firewalls, VPN gateways, EDR/antivirus, and critical applications (e.g., Microsoft 365 admin logs). For each source define minimum events to capture: authentication successes/failures, account provisioning/deprovisioning, privilege elevation, changes to security configuration, file access to CUI stores, and administrative remote access. For example, a small engineering firm should ensure domain controller (Windows) audit policies include Account Logon/Logon events, Account Management, and Directory Service Access for changes to AD objects.
\n\nCentralization keeps logs off the originating host and supports analysis. Options for small businesses: a hosted SIEM (Splunk Cloud, Chronicle, Sumo Logic), cloud-native services (AWS CloudWatch + KMS + S3, Azure Monitor + Log Analytics), or an on-premises ELK/Graylog stack. Implement agents or forwarding: use Windows Event Forwarding (WEF) or NXLog/Winlogbeat for Windows, rsyslog/syslog-ng or Filebeat for Linux, and configure network devices to send syslog over TLS (RFC 5425). Example: configure auditd on Linux with rules like -w /etc/passwd -p wa -k identity_changes, forward /var/log/audit/audit.log via Filebeat to your central collector over TLS 1.2+, and tag events with hostname and UTC timestamps.
Protection has two parts: integrity (prevent modification) and confidentiality (prevent unauthorized access). Integrity controls: write-once or append-only storage (S3 Object Lock in compliance mode or WORM storage), immutability, and cryptographic hashes. Implement automated integrity verification: compute and store SHA-256 checksums, maintain a signed hash chain, or use an HSM/KMS to sign log batches. Confidentiality and access control: encrypt logs in transit with TLS 1.2/1.3 and at rest using strong keys (AES-256 with centrally managed keys), apply strict RBAC for log access, and enable MFA for console access. For small businesses on AWS, send logs to CloudWatch Logs with KMS encryption, set an S3 lifecycle to transition to Glacier after 90 days, and enable S3 Object Lock for critical audit buckets.
\n\nDefine a retention schedule that balances investigative needs, contract requirements, storage cost, and privacy. A practical small-business baseline: keep detailed logs online (hot) for 90 days for rapid investigation, maintain searchable archives for 1 year, and store cold archives for 3–7 years depending on contract/DFARS obligations. Implement automated retention policies: log rotation (logrotate or native collector rules), lifecycle rules in cloud storage to move data to cheaper tiers, and secure deletion procedures when retention ends (cryptographic erasure or complete object removal where permitted). Document the retention policy and map retention windows to each log source.
\n\nExample 1 — Small DoD subcontractor (10–50 employees): The firm uses Azure AD and hosts CUI on a hybrid file server. Implementation: enable Windows Advanced Audit Policy on domain controllers and file servers; forward events via Winlogbeat to Azure Sentinel; store logs in a dedicated Log Analytics workspace with daily automated snapshots to an encrypted storage account; enable immutable blob storage for 3 years for contract compliance. Example 2 — SaaS provider on AWS: enable CloudTrail (management & S3 data events) with logs delivered to an S3 bucket using KMS key; enable CloudWatch Logs for application logs; use S3 Object Lock with compliance mode for audit buckets and life-cycle transition to Glacier Deep Archive after 180 days to control costs.
\n\nMap your implementation to the AU.L2-3.3.1 requirement in your system security plan (SSP) and maintain evidence: configuration snapshots, forwarding rules, retention policy documents, and proof of immutability (S3 Object Lock settings or SIEM retention configurations). Validate timestamps via NTP across all systems (use authenticated NTP where possible) and include timezone normalization in your collector. Run periodic tests: simulate account lockouts, privilege changes, and ensure those events appear in centralized logs with expected fields. Keep alerting tuned: create alerts for suspicious events (multiple failed logons, new admin account created, log sources stopping forwarding) and test your incident response runbook end-to-end.
\n\nFailing to collect, protect, and retain audit records exposes you to late or missed detection of intrusions, inability to prove non-repudiation during investigations, contract non-compliance, financial penalties, and reputational harm. For small businesses supporting CUI, inadequate audit records can lead to lost contracts, mandatory remediation orders, or disqualification from future government work. Attackers often attempt to erase or alter local logs; without centralized immutable logs, evidence can be lost, and forensic timelines become unreliable.
\n\nSummary: Implement AU.L2-3.3.1 by inventorying log sources, centralizing collection, enforcing encryption and immutability, defining and automating retention, and validating the end-to-end workflow with tests and documented evidence. For small businesses, using cloud-native logging with KMS and object-lock features or a managed SIEM can provide compliance-grade controls without large upfront infrastructure, while clear policies and regular testing ensure you meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 expectations.
", "plain_text": "This post explains how to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control AU.L2-3.3.1 by creating, protecting, and retaining system audit records — with practical steps, concrete technical settings, and small-business examples you can implement immediately.\n\nWhat AU.L2-3.3.1 requires (in practical terms)\nAU.L2-3.3.1 requires organizations to generate audit records that support detection, investigation, and reporting of unauthorized or anomalous system activity, then protect those records from tampering and retain them long enough to support investigations and contractual/regulatory requirements. The control does not prescribe a specific retention period; instead you must define and document a retention policy that meets your risk profile, contract clauses (e.g., DFARS), and investigative needs.\n\nPractical implementation steps\n\n1) Identify and prioritize audit sources\nStart by listing all systems that process or transmit controlled unclassified information (CUI) or are critical to security: domain controllers, file servers, workstations with CUI access, cloud consoles, firewalls, VPN gateways, EDR/antivirus, and critical applications (e.g., Microsoft 365 admin logs). For each source define minimum events to capture: authentication successes/failures, account provisioning/deprovisioning, privilege elevation, changes to security configuration, file access to CUI stores, and administrative remote access. For example, a small engineering firm should ensure domain controller (Windows) audit policies include Account Logon/Logon events, Account Management, and Directory Service Access for changes to AD objects.\n\n2) Collect and centralize logs\nCentralization keeps logs off the originating host and supports analysis. Options for small businesses: a hosted SIEM (Splunk Cloud, Chronicle, Sumo Logic), cloud-native services (AWS CloudWatch + KMS + S3, Azure Monitor + Log Analytics), or an on-premises ELK/Graylog stack. Implement agents or forwarding: use Windows Event Forwarding (WEF) or NXLog/Winlogbeat for Windows, rsyslog/syslog-ng or Filebeat for Linux, and configure network devices to send syslog over TLS (RFC 5425). Example: configure auditd on Linux with rules like -w /etc/passwd -p wa -k identity_changes, forward /var/log/audit/audit.log via Filebeat to your central collector over TLS 1.2+, and tag events with hostname and UTC timestamps.\n\n3) Protect audit records for integrity and confidentiality\nProtection has two parts: integrity (prevent modification) and confidentiality (prevent unauthorized access). Integrity controls: write-once or append-only storage (S3 Object Lock in compliance mode or WORM storage), immutability, and cryptographic hashes. Implement automated integrity verification: compute and store SHA-256 checksums, maintain a signed hash chain, or use an HSM/KMS to sign log batches. Confidentiality and access control: encrypt logs in transit with TLS 1.2/1.3 and at rest using strong keys (AES-256 with centrally managed keys), apply strict RBAC for log access, and enable MFA for console access. For small businesses on AWS, send logs to CloudWatch Logs with KMS encryption, set an S3 lifecycle to transition to Glacier after 90 days, and enable S3 Object Lock for critical audit buckets.\n\n4) Retention, rotation, and secure disposal\nDefine a retention schedule that balances investigative needs, contract requirements, storage cost, and privacy. A practical small-business baseline: keep detailed logs online (hot) for 90 days for rapid investigation, maintain searchable archives for 1 year, and store cold archives for 3–7 years depending on contract/DFARS obligations. Implement automated retention policies: log rotation (logrotate or native collector rules), lifecycle rules in cloud storage to move data to cheaper tiers, and secure deletion procedures when retention ends (cryptographic erasure or complete object removal where permitted). Document the retention policy and map retention windows to each log source.\n\nReal-world small-business examples and scenarios\nExample 1 — Small DoD subcontractor (10–50 employees): The firm uses Azure AD and hosts CUI on a hybrid file server. Implementation: enable Windows Advanced Audit Policy on domain controllers and file servers; forward events via Winlogbeat to Azure Sentinel; store logs in a dedicated Log Analytics workspace with daily automated snapshots to an encrypted storage account; enable immutable blob storage for 3 years for contract compliance. Example 2 — SaaS provider on AWS: enable CloudTrail (management & S3 data events) with logs delivered to an S3 bucket using KMS key; enable CloudWatch Logs for application logs; use S3 Object Lock with compliance mode for audit buckets and life-cycle transition to Glacier Deep Archive after 180 days to control costs.\n\nCompliance tips, checks, and best practices\nMap your implementation to the AU.L2-3.3.1 requirement in your system security plan (SSP) and maintain evidence: configuration snapshots, forwarding rules, retention policy documents, and proof of immutability (S3 Object Lock settings or SIEM retention configurations). Validate timestamps via NTP across all systems (use authenticated NTP where possible) and include timezone normalization in your collector. Run periodic tests: simulate account lockouts, privilege changes, and ensure those events appear in centralized logs with expected fields. Keep alerting tuned: create alerts for suspicious events (multiple failed logons, new admin account created, log sources stopping forwarding) and test your incident response runbook end-to-end.\n\nRisk of not implementing AU.L2-3.3.1 correctly\nFailing to collect, protect, and retain audit records exposes you to late or missed detection of intrusions, inability to prove non-repudiation during investigations, contract non-compliance, financial penalties, and reputational harm. For small businesses supporting CUI, inadequate audit records can lead to lost contracts, mandatory remediation orders, or disqualification from future government work. Attackers often attempt to erase or alter local logs; without centralized immutable logs, evidence can be lost, and forensic timelines become unreliable.\n\nSummary: Implement AU.L2-3.3.1 by inventorying log sources, centralizing collection, enforcing encryption and immutability, defining and automating retention, and validating the end-to-end workflow with tests and documented evidence. For small businesses, using cloud-native logging with KMS and object-lock features or a managed SIEM can provide compliance-grade controls without large upfront infrastructure, while clear policies and regular testing ensure you meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 expectations." }, "metadata": { "description": "Practical, step-by-step guidance for small businesses to collect, protect, and retain system audit records to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 AU.L2-3.3.1 requirements.", "permalink": "/how-to-collect-protect-and-retain-system-audit-records-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-aul2-331.json", "categories": [], "tags": [] } }