Prevent log disruption by protecting log transport, authentication, and write access to the central repository. Use tamper-evident forwarding, segregated administrative roles, and alerting for stopped agents, queue growth, or unreachable collectors. Keep local buffering enabled where possible so attackers cannot erase activity simply by interrupting transmission.
How to prevent log disruption at the transport layer
Blocking logging often starts with interference before events ever reach the central store. The first mitigation is to harden the path from source to collector so that a compromised host cannot simply stop forwarding, redirect traffic, or break name resolution and silently hide activity.
Use transport protections that preserve authenticity and integrity, then make the collector endpoint resilient to partial failure. If your logging channel can be disabled with ordinary host access or a simple network change, the control is too weak to trust during an intrusion.
How to keep repository access from becoming the single point of failure
The central repository itself must be harder to tamper with than the systems it records. Separate administrative duties, restrict write paths, and ensure that logging infrastructure has its own tightly controlled access model so that a compromised application, server, or operator account cannot erase or suppress records.
Local buffering is a practical backstop. When forwarding is interrupted, the source should continue to hold events until delivery resumes, which limits the attacker’s ability to erase evidence by breaking a network dependency alone.
What to watch for when logging is being suppressed
Suppression is usually visible in the control plane before it is obvious in the logs themselves. Stopped agents, queue growth, collector outages, repeated authentication failures to the repository, and sudden drops in event volume are all signs that the logging pipeline is being impaired rather than merely delayed.
Alerting should cover both transport health and volume anomalies, because either one can reveal a deliberate attempt to blind monitoring. If the pipeline is silently degrading, the organisation may still believe it has coverage while the attacker is already operating without visibility.
Risk and Threat Considerations
Blocking central logging is a high-value tactic because it reduces detection, delays investigation, and can help an attacker preserve access after initial compromise. The most dangerous failure mode is not complete log loss, but partial suppression that makes the environment look healthy while key events never arrive.
Failure mechanism: An attacker interrupts forwarding, tampers with credentials or administrative access to the collector, or disables the source agent so that events never reach the repository or are discarded before retention.
Impact: Security teams lose the evidence needed for triage, containment, and forensic reconstruction, which increases dwell time and can allow persistence, lateral movement, and follow-on abuse to continue undetected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Central logging integrity depends on protected collection, storage and alerting. |
| Recommendation — Harden log collection, retention and alerting so tampering or interruption is detected quickly. | ||
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | This question is about preventing audit logs from being blocked or altered before review. |
| AU-5 — Response to Audit Logging Process Failures | Stopped agents, queue growth and unreachable collectors are audit pipeline failure conditions. | |
| IA-5 — Authenticator Management | Repository and collector access depends on protecting the credentials used for write and admin access. | |
| Recommendation — Protect audit records and their transport from unauthorized access, modification and destruction. Configure alerting and response for logging process failures and degraded collection paths. Rotate and control authenticators used by logging infrastructure and administrative roles. | ||
Practitioner Guidance
What to prioritise: Treat logging integrity as an availability problem as well as a detection problem. Protect the transport, the authentication path, and the repository write plane with different controls, because a single safeguard rarely covers all three failure modes.
What to verify: Confirm that you can still see alerts when forwarding stops, that buffered logs survive short collector outages, and that a lower-privileged operator cannot alter retention or suppress ingestion. Test the failure path, not just the happy path.
Common mistake: Assuming that “logs are enabled” means visibility is assured. A logging stack that depends on one network route, one admin role, or one collector has not removed the blind spot, it has only relocated it.
Practitioner takeaway: The real objective is not uninterrupted logging at all costs, but trustworthy logging that remains observable, tamper-resistant, and recoverable even when an attacker is actively trying to hide.
Related resources from NHI Mgmt Group
- Guide: EDR Evasion and Defence Guide
- What mitigations reduce the risk of data from a configuration repository?
- What mitigations reduce the risk of exfiltration to a code repository?
- What mitigations reduce the risk of Prevent Command History Logging?
- What mitigations reduce the risk of blocking OT messages?