Audit log tampering detection is a must-have control for organizations pursuing compliance with NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (AU.L2-3.3.8): attackers often try to erase or alter logs to hide traces of their activity, so you need reliable monitoring, immutable collection, and automated alerts to know when logs are modified or cleared. This post gives practical, actionable steps and concrete tool configurations that a small business can implement to meet the control and to operationalize detection and response.
Why monitoring for log tampering matters (risk overview)
If you do not monitor for audit log tampering, you risk undetected intrusions, failed incident investigations, and loss of contract/regulated data protections. An attacker who deletes or modifies logs can perform data exfiltration or privilege escalation while leaving no trace; auditors will flag incomplete audit trails and you may be non-compliant with CMMC/NIST requirements. The control's goal is to detect and alert on any attempts to clear, modify, or disable auditing so that response can be immediate.
Practical implementation steps (high-level)
Start with an inventory of audit sources (Windows Security logs, Linux auditd/journal, application logs, network devices, cloud trails, authentication systems). Centralize logs to a hardened collector (SIEM, centralized syslog, or cloud logging service) and enforce immutability where possible (append-only storage, S3 Object Lock, WORM storage). Protect transport with TLS and use mutual authentication for agents. Finally, instrument detection and alerting rules that identify log-clear, audit-policy-change, file-permission-change, and sudden gaps in logging.
Centralization and immutability — concrete actions
Small-business example: run a lightweight ELK/Opensearch + Wazuh stack or a managed SIEM (Splunk Cloud, Elastic Cloud, or a low-cost vendor). Configure agents (Filebeat/Winlogbeat or Wazuh agents) to forward logs over TLS to the central collector. For cloud logs, enable CloudTrail/Cloud Audit Logs and route to a dedicated, locked S3/GCS bucket with Object Lock and lifecycle retention that prevents deletion for the required retention period. For on-prem, use rsyslog/syslog-ng with omfwd over TLS and a dedicated log server with RAID and offsite backups; set the filesystem to disallow log file modifications by user accounts using ACLs and auditd monitoring.
Detection rules and example configurations
Build detection around high-confidence indicators. Examples: - Linux: Add an auditd rule to watch log directories: auditctl -w /var/log -p wa -k audit_logs (place in /etc/audit/rules.d/audit.rules for persistence). Use ausearch to surface events with key=audit_logs. - Windows: Enable Advanced Audit Policy (Policy Change: "Audit Policy Change") and monitor Security Event IDs such as 1102 (The audit log was cleared) and 4719 (System audit policy was changed), and 4670 (Permissions on an object were changed). Forward these to your SIEM via Windows Event Forwarding or Winlogbeat. - Cloud (AWS): Create an EventBridge rule for CloudTrail management events where detail.eventName is StopLogging, DeleteTrail, or UpdateTrail and send to SNS or a Lambda that triggers an alert/automated mitigation (e.g., revert StopLogging). - SIEM correlation: Example Splunk query to detect suspicious combos: index=wineventlog (EventCode=1102 OR EventCode=4719) OR index=syslog "logrotate" OR index=linux_audit key=audit_logs | transaction host maxspan=5m startswith=(EventCode=4719 OR key=audit_logs) endswith=(EventCode=1102) | search eventcount>0 — then trigger a high-severity alert.
Tuning alerts and triage playbook
Tune thresholds to avoid fatigue: flag single benign events (e.g., scripted logrotate) at low priority but escalate if correlated with policy-change events, privilege escalation, or a cleared log within 5 minutes. Create a triage playbook: (1) validate event authenticity and source; (2) check for recent admin maintenance windows; (3) preserve volatile evidence (memory, current logs) and take forensic snapshots; (4) rotate keys/accounts used by logging services; (5) notify stakeholders and the incident response team. Automate initial containment steps where safe (e.g., re-enable CloudTrail logging or revert CloudTrail configuration via IaC).
Small-business scenario: low-cost detection stack
A two-person ops team can achieve compliance using open-source tooling: deploy Wazuh for host-based IDS and FIM, Filebeat/Winlogbeat for reliable log shipping, and Opensearch/Kibana for centralization and dashboards. Configure Wazuh FIM to watch /var/log and C:\Windows\System32\winevt\Logs and create rules to generate alerts on file deletions, permission changes, or unexpected log clears. Use a small EC2 or VM as the log collector with automated snapshots and an S3 bucket with Object Lock for long-term retention to satisfy evidence requirements.
Compliance tips and best practices
Document your configuration baseline in policies and the system security plan: what is forwarded, retention time, who has access, and the incident response steps for tamper alerts. Enforce separation of duties so that users who manage systems cannot also modify/disable log storage. Regularly test detection by performing controlled log-clear exercises in a test environment and verify alerts fire and playbooks are followed. Keep timestamps synchronized with NTP and store logs in UTC to simplify correlation.
Failing to implement these controls leaves you blind to attacker activity and increases the chance of regulatory and contractual non-compliance; effective monitoring and alerting reduce detection time, improve response, and provide auditors with verifiable evidence that tampering attempts would be noticed and handled. By centralizing, hardening, instrumenting clear detection rules, and documenting processes, even small organizations can meet AU.L2-3.3.8 requirements without excessive cost.
