A09 · Security Logging and Alerting Failures
Program: Application Security — OWASP Top 10 and Threat Modeling Module: OWASP Top 10 — Web Application Security Risks Submodule: A09:2025 · Security Logging and Alerting Failures
Renamed in 2025 from "Security Logging and Monitoring Failures" — the emphasis is now explicitly on acting on logs, not just collecting them. Every credible breach post-mortem includes some variant of "the logs were there but nobody looked." This category maps to STRIDE's Repudiation and, indirectly, to dwell time.
1. What It Is
Any weakness in the visibility, integrity, or usability of security telemetry:
- Missing logging on security-relevant events — logins, authorization denials, admin actions, changes to permissions, transfers of money, deletions.
- Insufficient context — a log line that says "auth failed" with no user, no IP, no timestamp, no request ID.
- Logs that don't reach a central store — files rotated off local disk, no forwarder, no aggregator.
- No alerts — logs pile up but nothing raises an alarm on suspicious patterns.
- Alerts that no one reads — SOC is drowning in false positives and tunes out the true positive.
- No integrity protection — attacker with local access can edit or delete logs.
- Long dwell time — attacker present for weeks/months before detection.
- PII / secrets logged — creating a new breach out of the logging pipeline (mixed with A04).
2. What to Log (and What Not To)
| Category | Log | Alert on |
|---|---|---|
| Authentication | Success + failure, user, IP, geo, device, MFA outcome | Bursts of failures per IP/user; success from new geo/device; MFA-bypass indicators |
| Authorization | Denials with subject/object/action | Repeated denials by same subject; denials on high-value objects |
| Admin actions | Every change: user create/modify/delete, role change, permission grant | Any change; especially outside business hours; especially by service accounts |
| Data access | Bulk exports, high-volume reads, cross-tenant reads | Volume above baseline; access to sensitive columns |
| Payments / finance | Every transaction, source, destination, amount | Refund-loops; failed-then-succeeded patterns; velocity anomalies |
| Deployments / IaC | Every apply, initiator, diff | Deploys outside pipeline; drift from IaC |
| Runtime security | WAF blocks, IDS alerts, signature verification failures, deserialization failures | Any invalid signature; deserialization failures; new WAF-rule matches |
| Infrastructure | Cloud API activity (CloudTrail, GCP Audit, Azure Activity) | Root-user use; IAM policy changes; access-key creation |
Never log: passwords, tokens (session, JWT, refresh, MFA OTP, password-reset), full PAN, CVV, full SSN, secrets from environment, LLM system prompts, contents of encrypted fields.
3. Prevention
Concrete guidance:
- Structured logging (JSON) with a stable schema — user_id, request_id, tenant_id, ip, session_id, event, outcome, resource. Makes SIEM correlation possible.
- Correlation IDs end-to-end — one ID travels through browser → API → downstream services → DB access → audit log.
- Central, write-once log storage — S3 with Object Lock, or an append-only SIEM. Attacker with app-tier access should not be able to erase logs.
- Time synchronization everywhere (NTP/chrony); timestamps in UTC with time zone; consistent format (RFC 3339 / ISO 8601).
- Retention aligned to legal & IR requirements — commonly 90 days hot, 1–3 years cold. Some regulations (PCI DSS, HIPAA) are prescriptive.
- Alerts, not dashboards. Detection rules with a runbook attached — every alert must tell the responder what to do next.
- Baseline-driven detection — user's normal geo/device/hours as input to anomaly rules. Reduces noise vs pure signature rules.
- Tabletop exercises — regularly rehearse "we got this alert, now what?" Feeds A06 · Insecure Design forward and A09 back.
- Legal / privacy alignment — logging PII creates GDPR obligations (purpose, retention, subject-access). Minimize before collecting.
4. Detection & Testing
- Purple-team exercises — attacker replays a known-bad action; check that (a) the log exists, (b) the alert fired, (c) on-call saw it, (d) the runbook worked, (e) the response was in-time.
- Log-completeness testing — for each Top 10 category, generate an event and verify the corresponding log line exists in the SIEM.
- PII-in-logs scan — regex/DLP scans of log samples for card numbers, tokens, emails, secrets. Redact at the source.
- Time-to-detect / time-to-respond metrics — measure and reduce over time. Correlate with incidents to feed the improvement loop.
- Detection-as-code — SIEM rules in version control, peer reviewed, tested. Sigma / Splunk SPL / KQL / Panther / Elastic Detection rules all support this pattern now.
5. Key Takeaways
- Rename matters: the 2025 shift from "Monitoring" to "Alerting" reflects that the industry-wide failure is acting, not collecting.
- Every security-relevant action needs an entry — auth, authorization, admin, data access, deploys, integrity failures. Missing logs are usually where post-incident forensics stalls.
- Log integrity matters. Attackers with app-tier access should not be able to erase evidence — store logs off-host, write-once, time-synchronized.
- Alerts without runbooks are dashboards. Every alert must answer "what does the responder do now?"
- Never log secrets. PII redaction and secret filtering at the logger, not "we'll fix it later."
6. Glossary (this submodule)
- SIEM — Security Information and Event Management; central store + query engine + alerting for security logs. Splunk, Sentinel, Chronicle, Elastic, Panther.
- SOC — Security Operations Center; team that watches alerts and drives incident response.
- Dwell time — elapsed time between an attacker's initial access and detection/containment. Primary driver of breach cost.
- MTTD / MTTR — Mean Time To Detect / Respond; the two headline metrics for an SOC.
- Runbook — step-by-step response procedure attached to a specific alert.
- Detection as code — SIEM/EDR detection rules maintained under version control with tests and peer review.
- Object Lock — S3 (and equivalent) feature preventing log objects from being modified or deleted for a retention period — gives WORM (Write Once Read Many) semantics.
7. What's Next
- A10 · Mishandling of Exceptional Conditions — the closing category, covering what happens (and doesn't) when something goes wrong at the edge.
- Cross-refs: A01 · Broken Access Control and A07 · Authentication Failures (both feed the majority of alertable events), A02 · Security Misconfiguration (log pipeline is itself infrastructure).