This post provides a practical, implementation-focused guide for small businesses and security practitioners to configure logging and a SIEM to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SI.L2-3.14.7 (Prevent and detect unauthorized system use), including specific log sources, agent/configuration examples, detection rules, retention guidance, and audit evidence that map to the Compliance Framework.
\n\nThe Practice for SI.L2-3.14.7 requires continuous monitoring and detection capabilities to surface unauthorized system use. For small organizations this means collecting the right telemetry from endpoints, servers, network devices, and cloud services; forwarding it securely to a central analysis point (a SIEM); and creating alerts and review processes that produce audit evidence.
\n\nThe control expects evidence that the organization can detect unauthorized access or use of systems that handle Controlled Unclassified Information (CUI). That evidence typically includes configured audit/event collection, retention and review procedures, documented SIEM detection rules, and incident response playbooks that trigger on those alerts.
\n\nKey objectives are: 1) collect authoritative logs for authentication, privilege changes, process execution, and network activity; 2) secure and centralize logs with time-synchronization and integrity controls; 3) implement correlation and alerting for unauthorized use patterns (impossible travel, lateral movement, privilege elevation, log clearing); and 4) retain and review logs per organizational policy to demonstrate detection capabilities to auditors.
\n\nArchitect a lightweight pipeline: agents -> secure transport -> central SIEM/indexer -> alerts/workflow. Recommended small-business stack examples: Winlogbeat / NXLog / Elastic Agent on Windows, Filebeat / auditbeat / auditd on Linux, syslog-ng for network devices, and CloudTrail/CloudWatch (AWS), Azure Monitor/Activity Logs (Azure) forwarded to your SIEM. Use TLS for transport and enforce mutual authentication. Ensure NTP is configured across hosts and collectors to avoid timestamp drift that breaks correlation.
\n\nWindows: collect Security channel events (4624 logon, 4625 failed logon, 4648 explicit credential use, 4672 privileged logon, 4688 process creation, 4697 service install, 1102 audit log clear) and supplement with Sysmon (v12+) for detailed process creation (Event ID 1), network connections (3), and driver load (6). Example: deploy a Sysmon config that captures command-line arguments, parent process, and hashes and forward Sysmon and Windows Security logs via Winlogbeat or NXLog over TLS to the SIEM.
\n\nLinux & cloud: enable auditd rules to watch authentication and privilege files (e.g., -w /etc/sudoers -p wa -k privileged-change), collect /var/log/auth.log or /var/log/secure, and capture execve events via auditd. In AWS enable CloudTrail management events and, where CUI access is possible, enable data events for S3 and Lambda; forward CloudTrail and VPC Flow Logs to your SIEM. In Azure, collect Azure AD sign-in logs, AuditLogs, and NSG flow logs. For all cloud providers, include console logins, API calls that create users/roles, and storage access events.
\n\nBuild detection rules that translate the control's intent into actionable alerts. Examples: (1) impossible-travel: same user authenticating from geographically distant locations within an impossible timeframe; (2) failed-brute-followed-by-success: >10 failed logons on an asset then a successful logon within 5 minutes; (3) privilege-change-and-remote-login: new admin user created (CloudTrail CreateUser/CreateRole) followed by authentication from an external IP; (4) log-clear: Windows Event 1102 or Linux audit log truncation; (5) lateral movement: credentials used to log into multiple hosts within short window. For a small business, tune thresholds to avoid noise — e.g., 5 failed logins in 10 minutes instead of enterprise thresholds — and include allowlists for known automated services.
\n\nRetention should be driven by policy mapped to contractual or DFARS requirements; practical small-business guidance is to keep at least 90 days of high-fidelity logs online for quick investigations and 1 year searchable in the SIEM; archive 3+ years offline if contracts require long-term proof. Maintain a documented log review cadence: daily high-priority alert triage, weekly anomaly review, and monthly reporting. For audit evidence, export SIEM alert histories, rule configuration screenshots, log-collection agent inventories, and the playbook used when an alert fires.
\n\nBest practices: maintain an asset inventory mapped to CUI flow so you know which systems must be instrumented; enable host-based telemetry (Sysmon/auditd) and network logging (DNS, proxy, EDR network events); protect log integrity with role-based access and WORM or append-only storage; implement automated alerting with an on-call rotation and playbooks; and perform regular rule tuning and tabletop exercises. If you do not implement these measures you risk undetected lateral movement and data exfiltration, loss of CUI, contractual penalties or termination, and failed CMMC assessments—small breaches often start as \"authorized\" access that should have been flagged as unauthorized use.
\n\nSummary: To satisfy SI.L2-3.14.7 you must collect authoritative logs (auth, process, network, cloud management), centralize and protect them, implement tuned correlation rules that detect unauthorized use patterns, and document retention and review processes. For small businesses, use cost-effective agents and managed SIEM options, focus first on the systems that handle CUI, and maintain a lightweight playbook to turn alerts into verifiable incident evidence for auditors.
", "plain_text": "This post provides a practical, implementation-focused guide for small businesses and security practitioners to configure logging and a SIEM to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SI.L2-3.14.7 (Prevent and detect unauthorized system use), including specific log sources, agent/configuration examples, detection rules, retention guidance, and audit evidence that map to the Compliance Framework.\n\nUnderstanding the requirement\n\nPractice\nThe Practice for SI.L2-3.14.7 requires continuous monitoring and detection capabilities to surface unauthorized system use. For small organizations this means collecting the right telemetry from endpoints, servers, network devices, and cloud services; forwarding it securely to a central analysis point (a SIEM); and creating alerts and review processes that produce audit evidence.\n\nRequirement\nThe control expects evidence that the organization can detect unauthorized access or use of systems that handle Controlled Unclassified Information (CUI). That evidence typically includes configured audit/event collection, retention and review procedures, documented SIEM detection rules, and incident response playbooks that trigger on those alerts.\n\nKey Objectives\nKey objectives are: 1) collect authoritative logs for authentication, privilege changes, process execution, and network activity; 2) secure and centralize logs with time-synchronization and integrity controls; 3) implement correlation and alerting for unauthorized use patterns (impossible travel, lateral movement, privilege elevation, log clearing); and 4) retain and review logs per organizational policy to demonstrate detection capabilities to auditors.\n\nImplementation Notes\nArchitect a lightweight pipeline: agents -> secure transport -> central SIEM/indexer -> alerts/workflow. Recommended small-business stack examples: Winlogbeat / NXLog / Elastic Agent on Windows, Filebeat / auditbeat / auditd on Linux, syslog-ng for network devices, and CloudTrail/CloudWatch (AWS), Azure Monitor/Activity Logs (Azure) forwarded to your SIEM. Use TLS for transport and enforce mutual authentication. Ensure NTP is configured across hosts and collectors to avoid timestamp drift that breaks correlation.\n\nTechnical configuration details and examples\n\nWindows: collect Security channel events (4624 logon, 4625 failed logon, 4648 explicit credential use, 4672 privileged logon, 4688 process creation, 4697 service install, 1102 audit log clear) and supplement with Sysmon (v12+) for detailed process creation (Event ID 1), network connections (3), and driver load (6). Example: deploy a Sysmon config that captures command-line arguments, parent process, and hashes and forward Sysmon and Windows Security logs via Winlogbeat or NXLog over TLS to the SIEM.\n\nLinux & cloud: enable auditd rules to watch authentication and privilege files (e.g., -w /etc/sudoers -p wa -k privileged-change), collect /var/log/auth.log or /var/log/secure, and capture execve events via auditd. In AWS enable CloudTrail management events and, where CUI access is possible, enable data events for S3 and Lambda; forward CloudTrail and VPC Flow Logs to your SIEM. In Azure, collect Azure AD sign-in logs, AuditLogs, and NSG flow logs. For all cloud providers, include console logins, API calls that create users/roles, and storage access events.\n\nDetection rules, correlation examples, and small-business scenarios\n\nBuild detection rules that translate the control's intent into actionable alerts. Examples: (1) impossible-travel: same user authenticating from geographically distant locations within an impossible timeframe; (2) failed-brute-followed-by-success: >10 failed logons on an asset then a successful logon within 5 minutes; (3) privilege-change-and-remote-login: new admin user created (CloudTrail CreateUser/CreateRole) followed by authentication from an external IP; (4) log-clear: Windows Event 1102 or Linux audit log truncation; (5) lateral movement: credentials used to log into multiple hosts within short window. For a small business, tune thresholds to avoid noise — e.g., 5 failed logins in 10 minutes instead of enterprise thresholds — and include allowlists for known automated services.\n\nRetention, review, evidence, and operational tips\n\nRetention should be driven by policy mapped to contractual or DFARS requirements; practical small-business guidance is to keep at least 90 days of high-fidelity logs online for quick investigations and 1 year searchable in the SIEM; archive 3+ years offline if contracts require long-term proof. Maintain a documented log review cadence: daily high-priority alert triage, weekly anomaly review, and monthly reporting. For audit evidence, export SIEM alert histories, rule configuration screenshots, log-collection agent inventories, and the playbook used when an alert fires.\n\nBest practices and risk of non-implementation\n\nBest practices: maintain an asset inventory mapped to CUI flow so you know which systems must be instrumented; enable host-based telemetry (Sysmon/auditd) and network logging (DNS, proxy, EDR network events); protect log integrity with role-based access and WORM or append-only storage; implement automated alerting with an on-call rotation and playbooks; and perform regular rule tuning and tabletop exercises. If you do not implement these measures you risk undetected lateral movement and data exfiltration, loss of CUI, contractual penalties or termination, and failed CMMC assessments—small breaches often start as \"authorized\" access that should have been flagged as unauthorized use.\n\nSummary: To satisfy SI.L2-3.14.7 you must collect authoritative logs (auth, process, network, cloud management), centralize and protect them, implement tuned correlation rules that detect unauthorized use patterns, and document retention and review processes. For small businesses, use cost-effective agents and managed SIEM options, focus first on the systems that handle CUI, and maintain a lightweight playbook to turn alerts into verifiable incident evidence for auditors." }, "metadata": { "description": "Step-by-step guide to configuring logs and SIEM to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 SI.L2-3.14.7 for detecting unauthorized system use.", "permalink": "/how-to-configure-logs-and-siem-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-sil2-3147-to-detect-unauthorized-system-use.json", "categories": [], "tags": [] } }