OWASP A09 · LAB ENVIRONMENT

Logging & Alerting Failures

Logging & Alerting Failures happen when systems don’t record enough detail, don’t alert anyone, or bury the signal in noise — letting attackers operate undetected for days or months. Try the interactive playground below to watch an attack sail through a SOC’s log feed unnoticed, then see proper logging and alerting catch it in seconds.

OWASP Top 10 · 2025 · A09 — Logging & Alerting Failures

When Nobody Is Watching the Logs, Breaches Hide in Plain Sight

Logging & Alerting Failures happen when systems record events but nobody — human or machine — is actually watching for patterns that matter. Without correlation rules and alerting, a brute-force login attempt looks identical to normal traffic: just more lines scrolling past in a file nobody opens. The attack succeeds quietly, and the breach can sit undiscovered for weeks or months.

Interactive Demo — Simulated SOC Log Feed

Correlation Rule / Alerting: OFF

SIEM FEED — MONITORING: INACTIVE (no correlation engine)

Alerts Fired —

Mean Time To Detect —

Toggle the correlation rule on or off, then run the simulated brute-force attack to see the difference monitoring makes.

Vulnerable vs. Secure Logging Configuration

✕ Vulnerable — no monitoring

# logging.conf — INSECURE
log_targets: local_disk_only
storage: single web server, 1 file
retention_days: 3
correlation_rules: none
alerting: disabled
escalation_path: undefined
tamper_protection: false
log_review: "someone will check it
             eventually, probably"

✓ Secure — centralized & alerting

# logging.conf — SECURE
log_targets: [siem, xdr, s3-worm-bucket]
retention_days: 365

correlation_rules:
  - name: brute_force_login
    condition: >
      auth.fail count >= 10
      within 60s
      from same src_ip
    action: alert(
      severity = high,
      escalate_to = on_call_analyst,
      channel = pager + siem_ticket
    )

alerting: enabled
tamper_protection: true   # WORM storage
log_review: continuous (SOC, 24/7)

Why This Matters

Many breaches are only discovered months after they happened — often by a third party, a customer, or law enforcement, not by the victim organization itself. The evidence was almost always sitting right there in the logs; the difference between a five-minute detection and a five-month disaster is usually just whether anyone, or anything, was watching.

How to Detect & Fix It

Centralize logs into a SIEM or XDR platform instead of leaving them scattered across individual servers and apps.
Write correlation rules for known attack patterns — brute force, impossible travel, privilege escalation, mass data export.
Define and test alert escalation paths so a fired alert actually reaches an on-call analyst, not a silent inbox.
Protect log integrity — make logs tamper-resistant (e.g. WORM storage) and retain them long enough to support an investigation.
Test detection coverage regularly with purple-team exercises to confirm the rules that exist actually fire when they should.