AU.L2-3.3.1—the audit and accountability requirement under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2—requires organizations handling Controlled Unclassified Information (CUI) to create, protect, and retain audit records to support incident response, investigations, and accountability; a properly implemented Security Information and Event Management (SIEM) system is the most practical way for small and mid-sized organizations to meet this control in a verifiable, repeatable manner.
\n\nThis control’s objectives are straightforward: ensure your systems generate meaningful audit logs, securely collect and preserve those logs, make them available for timely review and investigation, and retain them for the period required by policy or contract. For Compliance Framework implementations, that means documenting which events are audited, how logs are protected (integrity, confidentiality), how long they're retained, who can access them, and how log reviews and incident investigations are performed and recorded.
\n\nA SIEM centralizes logs from endpoints, servers, network devices, cloud services, and applications; normalizes them into a common schema; detects suspicious activity through correlation and rules; and provides retention, secure storage, and forensic search capabilities. Key SIEM features that map directly to AU.L2-3.3.1 include: reliable ingestion (with TLS/syslog over TCP), parsing and normalization (CEF/LEEF/JSON mapping), immutable or append-only storage, access controls and audit trails for the SIEM itself, alerting and investigation workflows, and exportable evidence (search results, policy configurations, retention settings) for auditors.
\n\nStart by creating a log-source inventory: list all Windows hosts, Linux servers, domain controllers, firewalls, VPNs, proxies, SaaS apps (Office 365 / Azure AD), cloud audit services (CloudTrail, CloudWatch, Azure Monitor), and any custom applications. For each source note: log types produced, expected daily volume (MB/day), retention requirement, and required owner. For small businesses, prioritize Domain Controllers, privileged systems, perimeter devices, and the systems that process CUI.
\n\nConfigure reliable transport—use syslog over TCP+TLS for network devices (rsyslog or syslog-ng), Windows Event Forwarding (WinRM/WEC) or the vendor agent for Windows, and cloud-native connectors for AWS/Azure/GCP. Normalize to a common schema (CEF/LEEF or Elastic ECS) so correlation rules work across sources. Ensure timestamps are normalized to UTC and all sources sync to NTP (or domain time). For on-prem agents use HMAC/signing if available; for cloud logs use provider-signed event streams (CloudTrail).
\n\nDefine and enforce a retention policy that aligns with contract and organizational policy—common baselines are 1 year online for incident investigation and 3–7 years for archived compliance evidence depending on contractual obligations. Protect stored logs using encryption at rest (AES-256), role-based access control to the SIEM and storage, and immutability where possible (S3 Object Lock/WORM storage or append-only volumes). Implement integrity verification—store periodic hashes (SHA-256) of log batches and retain signatures in a separate, access-controlled location so auditors can verify tamper resistance.
\n\nCreate detection rules mapped to AU.L2-3.3.1 objectives: monitor for tampering attempts (log truncation, missing events), unusual privilege escalations, failed authentication storms, data staging activity, and anomalous exfiltration patterns. Example rule: alert if a privileged account logs in from a new country or if >50 failed auth attempts across multiple accounts from a single IP within 10 minutes. Tune rules to reduce false positives and document weekly/monthly review processes—capture review sign-offs, investigation tickets, and remediation timelines as audit evidence.
\n\nSmall-business practicals: estimate log volume per host (Windows server ~50–200 MB/day; Linux ~10–50 MB/day; firewall ~5–100 MB/day depending on traffic). Calculate retention storage: Total GB/day × 365 = annual TB; factor in compression (SIEM storage often compresses 3:1). Use TLS 1.2+ for transport, enable mutual TLS or API keys where possible, and keep NTP within 1 second to preserve event order. Configure index rollovers and cold storage tiers—keep last 90 days hot, 91–365 days warm, older data archived to immutable object storage. For integrity, run a weekly hash job (SHA-256) on daily log bundles and store hashes in an offline or separate system. Backup SIEM configurations and parse rules as part of evidence.
\n\nExample: a 50-employee defense subcontractor uses Azure AD, M365, five on-prem Windows servers, 10 Linux build agents, and a Palo Alto firewall. Implementation steps: enable unified audit logging in M365, forward Azure Activity and Sign-in logs to Azure Monitor (and into Microsoft Sentinel), configure Palo Alto to forward logs to a forwarding collector over TLS, deploy an Elastic + Wazuh cluster (or use Sentinel/ Splunk Cloud) with a retention policy of 12 months hot and 3 years archived. Evidence for an assessor: the log-source inventory spreadsheet, screenshots of ingestion dashboard showing recent events, retention policy document, SIEM role assignments, sample alert tickets, and a hash verification log for archived daily bundles.
\n\nWithout centralized, protected logging you expose the organization to undetected breaches, inability to investigate incidents, loss of CUI, and contractual or regulatory penalties—including losing DoD contracts. Practical compliance tips: start small and iterate (cover highest-risk systems first), document everything (policies, runbooks, onboarding), use cloud SIEM/MSSP if you lack staff, automate evidence collection for audits, and perform tabletop exercises to validate that logs provide the necessary data to perform a reconstruction of an incident.
\n\nIn summary, a SIEM is the practical mechanism to meet AU.L2-3.3.1 when implemented with an inventory-driven approach, secure transport and storage, integrity protections, documented retention and review processes, and tuned detections; for small businesses this can be achieved cost-effectively by prioritizing CUI-bearing systems, using managed or cloud SIEM options, and keeping clear, auditable evidence of configuration and operational procedures.
", "plain_text": "AU.L2-3.3.1—the audit and accountability requirement under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2—requires organizations handling Controlled Unclassified Information (CUI) to create, protect, and retain audit records to support incident response, investigations, and accountability; a properly implemented Security Information and Event Management (SIEM) system is the most practical way for small and mid-sized organizations to meet this control in a verifiable, repeatable manner.\n\nUnderstanding AU.L2-3.3.1 and key objectives\nThis control’s objectives are straightforward: ensure your systems generate meaningful audit logs, securely collect and preserve those logs, make them available for timely review and investigation, and retain them for the period required by policy or contract. For Compliance Framework implementations, that means documenting which events are audited, how logs are protected (integrity, confidentiality), how long they're retained, who can access them, and how log reviews and incident investigations are performed and recorded.\n\nHow a SIEM maps to the control\nA SIEM centralizes logs from endpoints, servers, network devices, cloud services, and applications; normalizes them into a common schema; detects suspicious activity through correlation and rules; and provides retention, secure storage, and forensic search capabilities. Key SIEM features that map directly to AU.L2-3.3.1 include: reliable ingestion (with TLS/syslog over TCP), parsing and normalization (CEF/LEEF/JSON mapping), immutable or append-only storage, access controls and audit trails for the SIEM itself, alerting and investigation workflows, and exportable evidence (search results, policy configurations, retention settings) for auditors.\n\nImplementation checklist and best practices\n\nInventory and prioritize log sources\nStart by creating a log-source inventory: list all Windows hosts, Linux servers, domain controllers, firewalls, VPNs, proxies, SaaS apps (Office 365 / Azure AD), cloud audit services (CloudTrail, CloudWatch, Azure Monitor), and any custom applications. For each source note: log types produced, expected daily volume (MB/day), retention requirement, and required owner. For small businesses, prioritize Domain Controllers, privileged systems, perimeter devices, and the systems that process CUI.\n\nCollection, transport, and parsing\nConfigure reliable transport—use syslog over TCP+TLS for network devices (rsyslog or syslog-ng), Windows Event Forwarding (WinRM/WEC) or the vendor agent for Windows, and cloud-native connectors for AWS/Azure/GCP. Normalize to a common schema (CEF/LEEF or Elastic ECS) so correlation rules work across sources. Ensure timestamps are normalized to UTC and all sources sync to NTP (or domain time). For on-prem agents use HMAC/signing if available; for cloud logs use provider-signed event streams (CloudTrail).\n\nRetention, protection, and evidence\nDefine and enforce a retention policy that aligns with contract and organizational policy—common baselines are 1 year online for incident investigation and 3–7 years for archived compliance evidence depending on contractual obligations. Protect stored logs using encryption at rest (AES-256), role-based access control to the SIEM and storage, and immutability where possible (S3 Object Lock/WORM storage or append-only volumes). Implement integrity verification—store periodic hashes (SHA-256) of log batches and retain signatures in a separate, access-controlled location so auditors can verify tamper resistance.\n\nDetection, alerting, and review\nCreate detection rules mapped to AU.L2-3.3.1 objectives: monitor for tampering attempts (log truncation, missing events), unusual privilege escalations, failed authentication storms, data staging activity, and anomalous exfiltration patterns. Example rule: alert if a privileged account logs in from a new country or if >50 failed auth attempts across multiple accounts from a single IP within 10 minutes. Tune rules to reduce false positives and document weekly/monthly review processes—capture review sign-offs, investigation tickets, and remediation timelines as audit evidence.\n\nTechnical configuration details and sizing guidance\nSmall-business practicals: estimate log volume per host (Windows server ~50–200 MB/day; Linux ~10–50 MB/day; firewall ~5–100 MB/day depending on traffic). Calculate retention storage: Total GB/day × 365 = annual TB; factor in compression (SIEM storage often compresses 3:1). Use TLS 1.2+ for transport, enable mutual TLS or API keys where possible, and keep NTP within 1 second to preserve event order. Configure index rollovers and cold storage tiers—keep last 90 days hot, 91–365 days warm, older data archived to immutable object storage. For integrity, run a weekly hash job (SHA-256) on daily log bundles and store hashes in an offline or separate system. Backup SIEM configurations and parse rules as part of evidence.\n\nReal-world small business scenario\nExample: a 50-employee defense subcontractor uses Azure AD, M365, five on-prem Windows servers, 10 Linux build agents, and a Palo Alto firewall. Implementation steps: enable unified audit logging in M365, forward Azure Activity and Sign-in logs to Azure Monitor (and into Microsoft Sentinel), configure Palo Alto to forward logs to a forwarding collector over TLS, deploy an Elastic + Wazuh cluster (or use Sentinel/ Splunk Cloud) with a retention policy of 12 months hot and 3 years archived. Evidence for an assessor: the log-source inventory spreadsheet, screenshots of ingestion dashboard showing recent events, retention policy document, SIEM role assignments, sample alert tickets, and a hash verification log for archived daily bundles.\n\nRisks of not implementing AU.L2-3.3.1 and compliance tips\nWithout centralized, protected logging you expose the organization to undetected breaches, inability to investigate incidents, loss of CUI, and contractual or regulatory penalties—including losing DoD contracts. Practical compliance tips: start small and iterate (cover highest-risk systems first), document everything (policies, runbooks, onboarding), use cloud SIEM/MSSP if you lack staff, automate evidence collection for audits, and perform tabletop exercises to validate that logs provide the necessary data to perform a reconstruction of an incident.\n\nIn summary, a SIEM is the practical mechanism to meet AU.L2-3.3.1 when implemented with an inventory-driven approach, secure transport and storage, integrity protections, documented retention and review processes, and tuned detections; for small businesses this can be achieved cost-effectively by prioritizing CUI-bearing systems, using managed or cloud SIEM options, and keeping clear, auditable evidence of configuration and operational procedures." }, "metadata": { "description": "Practical guide to configuring SIEM to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 AU.L2-3.3.1, with a step-by-step implementation checklist, technical details, and small-business examples.", "permalink": "/how-to-use-siem-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-aul2-331-implementation-checklist-and-best-practices.json", "categories": [], "tags": [] } }