NIST SP 800-171 / CMMC 2.0 AU.L2-3.3.3 requires organizations to review and analyze logged events so that anomalous or suspicious activity is identified and acted upon; using a SIEM to automate logged-event reviews makes meeting this control practical, repeatable, and auditable for small businesses with limited staff.
What AU.L2-3.3.3 requires (practical interpretation for Compliance Framework)
At its core, AU.L2-3.3.3 expects regular, documented review of audit records to detect potential incidents and policy violations. For Compliance Framework purposes that means: collect the right sources (authentication, privileged actions, system changes, network flows), normalize timestamps/fields, run automated analysis to surface anomalies, assign alerts to a reviewer, and retain evidence of the review and any follow-up actions. Frequency and depth should align with risk — automated reviews should run continuously with human review escalation at defined thresholds.
Designing an automated SIEM review process — technical implementation notes
Start by cataloging log sources and mapping to required event types: Windows Security (Event IDs 4624/4625/4672/4688/4670), Sysmon (process create 1, network connect 3, file create 11), Linux auditd / auth logs, firewall/NAT, VPN, cloud console logs (Azure AD sign-ins, AWS CloudTrail), EDR alerts, and DLP/Proxy logs. Use secure, TLS-encrypted forwarding (CEF/JSON over TCP/TLS or HTTPS) and ensure time sync with NTP/chrony on all sources. Normalize into a consistent schema (ECS or CEF) to make correlation rules portable. Implement a log integrity mechanism (e.g., signing or periodic checksums) and monitor for ingestion gaps — alert on gaps longer than an agreed SLA (example: >15 minutes for critical sources).
Detection engineering: automated reviews, rules, and baseline behavior
Create a layered detection set: simple, deterministic rules (e.g., repeated failed logins, new admin account creation), statistical baselines (typical outbound bandwidth per workstation), and behavior analytics (UEBA for deviations in process launches or account usage). Example rules you can implement immediately: a) Splunk SPL: index=wineventlog EventCode=4625 | stats count by src_ip, AccountName | where count>5; b) KQL for Sentinel: SecurityEvent | where EventID == 4625 | summarize FailedCount = count() by Account, bin(TimeGenerated, 5m) | where FailedCount > 5. Also track spike detection on data egress (e.g., >1 GB/hour from single endpoint) and alert on privilege use outside business hours or from new geolocations. Tune thresholds to the environment to reduce false positives and include whitelists for known service accounts.
Small-business real-world example
A small contractor with ~50 employees uses Azure AD, Office365, three on-prem Windows servers, and cloud-hosted Linux app servers. Practical pipeline: enable Azure AD sign-in logs and stream to Azure Sentinel, deploy Winlogbeat/NXLog to endpoints to forward Windows logs and Sysmon events to the SIEM, and configure Filebeat to ship Linux auth and auditd logs. Implement a starter rule set: failed logon (>5 attempts in 5 minutes), new local admin creation, service account password changes, RDP access from external IPs, and sudden high-volume uploads to cloud storage. Set up an automated playbook that enriches alerts with username, asset owner (CMDB lookup), geolocation, and last seen antivirus/EDR status, then routes to the assigned NIST-appointed reviewer via ticketing (Jira/ServiceNow) if the alert is medium/high priority.
SOAR and response automation — implementation details
Use SOAR playbooks to reduce manual review time: automatically enrich alerts (WHOIS, IP reputation, AD lookup), run enrichment steps in parallel, and apply decision logic (if EDR shows lateral movement -> escalate to incident response and isolate host via EDR API; if simple brute-force -> block IP at firewall and mark as reviewed). Maintain human-in-the-loop gates for high-impact actions. Instrument metrics: MTTD (mean time to detect), MTTR (mean time to respond), and false positive rate; keep thresholds and logic under version control and document changes for audit evidence.
Risks of not automating logged-event reviews and compliance tips
Without automation, small teams can miss indicators of compromise, take longer to detect breaches, and lack consistent, auditable evidence of review — increasing risk to Controlled Unclassified Information (CUI) and potentially failing audits. Compliance tips: 1) Start with a minimum viable detection set that covers authentication/privilege changes and data egress; 2) Keep an evidence trail (alert, enrichment, reviewer comments, ticket closure) retained as part of compliance artifacts; 3) defend logs (TLS, integrity checks, retention policies) and validate ingestion via synthetic log generators; 4) run quarterly tuning and tabletop exercises; 5) align retention policies with contract and risk (searchable index for 90 days, archived for 1 year is a common starting point). Protect admin credentials and ensure multi-factor authentication is enforced to reduce noisy alerts caused by credential theft.
In summary, automating logged event reviews with a SIEM for AU.L2-3.3.3 is achievable for small businesses by focusing on the right log sources, normalizing data, creating a layered detection strategy, using SOAR for enrichment and response, and documenting all steps for auditors. Implement incrementally, measure outcomes, and tune continuously so the automated review process remains effective and defensible under the Compliance Framework.
