This post explains how to design and operate a SIEM-driven logging and alerting program to satisfy AU.L2-3.3.3 requirements in the Compliance Framework context (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2), with practical steps, configuration suggestions, and real-world small-business examples you can implement immediately.
What AU.L2-3.3.3 expects in practical terms
At a high level AU.L2-3.3.3 requires that organizations record, monitor, and take action on audit-relevant events so that activity affecting Controlled Unclassified Information (CUI) and privileged operations is detectable and attributable. For Compliance Framework implementation this means centralized log collection, protected retention, regular review or automated alerting, documented response procedures, and evidence you can present during assessments. You don't need a massive SOC—what you need is reliable logs, tuned detection, and repeatable response steps.
Designing a SIEM-based solution for Compliance Framework
Start by defining scope: identify all systems that store, process, or transmit CUI and those that grant privilege (domain controllers, file servers, ATP/endpoint agents, VPN, cloud control planes). Deploy lightweight collectors (Winlogbeat/osquery/NXLog for Windows/Linux, Filebeat for logs, CloudTrail/CloudWatch events for AWS, Audit Logs for GCP/Azure) and forward to the SIEM over TLS (syslog TLS on TCP/6514 or vendor secure channels). Normalize and timestamp events, enable integrity protection for log storage (WORM/immutable indices where possible), and apply a minimum retention policy (for small organizations a common pragmatic approach is 90 days hot + 1 year cold for audit purposes, but follow contract or agency-specific requirements). Ensure role-based access to SIEM data and that audit logs themselves are logged and protected.
Recommended log sources and event types (small-business focus)
For a small business (e.g., 20–100 employees, hybrid cloud and a few on-prem servers), target these minimum sources: Windows Security Events (4624/4625/4672/4688/1102), Linux auth and auditd logs, domain controller auth events, VPN connection logs, firewall allow/deny and admin changes, cloud control plane logs (CloudTrail/AzureActivity), file server access and share changes, endpoint EDR telemetry, and application logs for CUI handling. Prioritize events that show authentication anomalies, privilege elevation, data access/export, and configuration changes. Collecting these gives a defensible coverage baseline for AU.L2-3.3.3.
Alerting strategy and tuning
Automated alerts are the most practical way to meet the "monitor and take action" expectation. Develop detection use-cases (failed login storm followed by success, privileged account used from new geo/IP, creation of archive files in CUI directories, disabled logging services) and convert these into correlation rules. Use thresholds and baselining to reduce false positives (e.g., allow up to N failed logins per 10 minutes for known remote offices). Map rules to MITRE ATT&CK techniques to prioritize. Define SLAs for alert investigation (e.g., triage within 1 hour for high-severity alerts) and instrument dashboards that show open incidents, time-to-first-action, and log collection health. Regularly review and update rules after incidents to close detection gaps.
Concrete detection examples and queries
Examples you can implement in common SIEMs: (1) Failed-then-success rule: correlate 5+ EventCode=4625 (failed logon) from same account/IP within 10 min followed by EventCode=4624 (success) within 2 minutes — this indicates credential stuffing or brute force followed by success. Splunk SPL: index=wineventlog (EventCode=4625 OR EventCode=4624) | transaction Account maxspan=10m | search EventCode=4624 AND mvcount(EventCode=4625)>=5. (2) Privileged file access: detect a privileged account reading large numbers of files in a CUI directory within an hour — use file audit logs with a threshold (e.g., >500 file reads by same account). (3) Unusual VPN geo: detect VPN login from country X followed by access to CUI resources — use geolocation enrichment and alert when geolocation != expected regions. For Elastic/Kibana you can use KQL like event.code:4625 AND source.ip:* to build similar rules. Export detections as Sigma rules so you can port them between SIEMs.
Operationalizing alerts: playbooks, ticketing, and evidence
Alerts must lead to documented actions. Create simple playbooks for common detections: triage steps, containment actions (reset creds, disable account, block IP), evidence collection (export relevant logs with hash and timestamp), and notification channels (email + ticket + pager). Integrate SIEM with a ticketing system (Jira, ServiceNow) and, if available, a SOAR tool for automated containment (block IP in firewall, isolate endpoint via EDR). Record all steps as evidence for assessors — timestamped SIEM alerts, investigation notes, and corrective actions show compliance with AU.L2-3.3.3. For small teams, scripted automations (e.g., Lambda to quarantine IP) can provide SOC-like capabilities without 24/7 staffing.
Compliance tips and best practices
Protect log integrity (encrypt in transit, use immutable storage for archives), limit who can modify SIEM data, and log SIEM admin actions. Maintain a logging policy that defines retention, log review cadence, and responsibilities. Perform quarterly alert tuning reviews, tabletop exercises using past alerts, and annual evidence collection drills to ensure you can present logs and forensic artifacts to auditors. Use threat intelligence feeds to enrich alerts and reduce investigation time. Finally, document all configurations and changes — auditors want to see that logging/alerting configurations are deliberate and maintained.
Risks of not implementing AU.L2-3.3.3 effectively
Without centralized logging and tuned alerts you face multiple risks: breaches can go undetected for long periods, loss or unauthorized access to CUI may not be discovered or attributable, you will lack the forensic trail needed for incident response and reporting, and you risk losing contracts or failing assessments. For small businesses this often translates into business disruption, reputational damage, and potential financial penalties — all of which are far more costly than a modest SIEM and an effective alerting program.
Summary: Meeting AU.L2-3.3.3 is practical and achievable for small organizations — centralize relevant logs, protect and retain them, implement a prioritized set of correlation rules and playbooks, integrate alerts with ticketing/automation, and document everything for assessors. Start with the core log sources and 5–10 high-value detections, tune aggressively to reduce noise, and expand coverage iteratively; doing so will both reduce security risk and provide clear evidence of Compliance Framework conformance.
