3.3.4 — Alert When Logging Breaks

The One-Liner

An attacker’s first move is often to disable logging. If nobody notices for a week, a week of evidence is gone.

What It Says

Alert in the event of an audit logging process failure.

What It Actually Means

If logging stops — for any reason, on any CUI system — someone must be notified immediately. This covers every failure mode:

1. Log source goes silent. A server stops forwarding events to the SIEM. A heartbeat monitor detects the silence and alerts within minutes, not days.

2. Disk full / storage failure. The local log partition fills up and logging stops writing. The system alerts before it’s full (threshold alerts at 80%) and again if logging actually stops.

3. SIEM stops ingesting. The central log collector crashes or a connector breaks. The SIEM’s health monitoring triggers an alert.

4. Audit service crashes. The Windows Event Log service stops, the syslog daemon dies, the cloud audit pipeline breaks. Each failure generates a notification.

Three things the assessor checks:

• Who gets alerted? Named personnel or roles — not a distribution list nobody reads. The list must be documented.
• What failures trigger alerts? Defined failure types — not just “SIEM down” but also individual source silence, storage issues, and service crashes.
• Do alerts actually fire? The assessor may ask you to simulate a failure and show the alert arrives.

This requirement exists because a gap in logging is a gap in evidence. Whether the cause is an attacker disabling logs or a mundane storage failure, the result is the same: blind time.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are personnel or roles to be alerted identified?	Documented list of named people or on-call roles who receive logging failure alerts
2	Are audit logging failure types defined?	List of monitored failure conditions: source silence, disk full, service crash, ingestion failure
3	Are identified personnel actually alerted on failure?	Show a recent alert or demonstrate a simulated failure triggers notification

---

What to Have Ready on Assessment Day

Documents they’ll review: Audit and accountability policy; procedures addressing audit logging failure response; list of personnel to be notified; defined failure types and thresholds; system security plan; system configuration showing alerting rules; sample alert notifications

People they’ll talk to: Personnel with audit and accountability responsibilities; information security personnel; system or network administrators; anyone on the alert recipient list

Live demos they’ll ask for: “Show me your alerting rules for logging failures.” “Show me a recent alert — or simulate a failure and show me the notification.” “Who gets notified? Show me the distribution.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “If a CUI server stopped sending logs right now, who would know and how quickly?”
• “Show me the alerting rule that detects a log source going silent.”
• “Who is on the notification list for logging failures? How was that list determined?”
• “Show me the last time a logging failure was detected. What happened?”
• “What types of logging failures do you monitor for? Is it just SIEM down, or individual sources too?”
• “What’s your response procedure when a logging failure alert fires?”

Real-World Example

A defense contractor uses Microsoft Sentinel with heartbeat monitoring on all log sources. Each CUI system runs a Log Analytics agent that sends a heartbeat every minute. A Sentinel analytics rule triggers if any source misses heartbeats for 15 minutes — generating an incident that pages the on-call security engineer via PagerDuty. Separately, Azure Monitor alerts fire if the Log Analytics workspace ingestion drops below expected volume or if storage reaches 80% capacity. The security team’s on-call rotation is documented and updated monthly. When a Windows server’s Event Log service crashed during a patch cycle, the heartbeat alert fired within 15 minutes, the on-call engineer restarted the service, and the incident was logged in the ticketing system with root cause and resolution. The assessor reviews the alert rule, the PagerDuty notification history, and the incident ticket.

---

Where Companies Trip Up

No alerting at all. Logging is configured and working, but nobody would know if it stopped. The assessor asks “what happens if this server stops logging?” and the answer is silence. Configure heartbeat or health monitoring on every log source.

Alert fatigue. So many alerts fire daily that logging failure alerts get buried. Logging failure alerts should be high-priority — separate them from informational noise. If your team ignores alerts, you effectively have no alerting.

SIEM-level only. An alert fires if the entire SIEM goes down, but not if a single source stops forwarding. You need per-source monitoring. A server compromised by an attacker who disables local logging won’t take down your SIEM — it’ll just go silent.

No documented response. Alert fires, but nobody knows what to do. Define a procedure: acknowledge, investigate, restore logging, document the gap period and root cause.

---

How to Talk About This

To a CEO or Board

If any logging system fails anywhere in our CUI environment, our security team is alerted within minutes. We’ve never had a logging gap longer than 30 minutes without it being detected and resolved.

To an Engineering Team

Sentinel heartbeat monitoring: 15-minute silence threshold per source. Azure Monitor: ingestion volume anomaly + storage threshold at 80%. PagerDuty integration for on-call paging. Documented response procedure: acknowledge → investigate → restore → document gap. Monthly on-call rotation review. Alert rules tested quarterly by simulating a source outage.

---

Connected Requirements

Requirement	Why it matters here
3.3.1 — Log Everything	Creates the logging this requirement monitors for failures
3.3.8 — Tamper-Proof Logs	An attacker disabling logging is also an integrity issue — detect it fast
3.14.6 — Watch the Network	System monitoring that can detect logging anomalies as part of broader monitoring
3.6.1 — Plan for Incidents	Logging failure response should be part of your incident response plan

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: AU.L2-3.3.4 | SPRS Weight: 1 point | POA&M Eligible: Yes