Security Logging and Monitoring Failures: The Breach You Never Saw
Security Logging and Monitoring Failures is the odd one out on the OWASP list: it is not a vulnerability an attacker exploits directly, but the blindness that lets every other vulnerability go unnoticed. Renamed and expanded in 2021, it captures a quiet, corrosive truth — you cannot respond to what you cannot see, and most organisations discover breaches far too late, often from an outside party rather than their own systems.
This category is measured not by how easily it is exploited but by how badly it amplifies everything else. An attacker who trips no alert has time — time to escalate, move laterally, and exfiltrate. Industry breach studies consistently find that intrusions go undetected for weeks or months, and that detection frequently comes from a third party. Every one of those figures is a logging and monitoring failure in aggregate.
How the visibility gap forms
- Security events go unlogged. Failed logins, access-control denials, and input-validation failures are not recorded, so there is no trail to follow.
- Logs exist but nobody watches them. Data is collected and never analysed, alerted on, or correlated — storage without detection.
- Alerts drown in noise. Real signals are buried under false positives until responders learn to ignore the console.
- Logs are not protected. Attackers clear or alter them to erase their tracks, and no integrity control catches the tampering.
- No response follows detection. An alert fires into a void with no owner, no playbook, and no action.
There is a difficult balance here. Logging too little leaves you blind; logging too much — or logging the wrong things — creates its own problems. Recording passwords, session tokens, or personal data in plaintext logs turns your monitoring system into a fresh target and a compliance liability. Good logging is deliberate about what it captures, not just how much.
# repeated 200 times in 5 minutes, no alert raised — the probe nobody saw
Building visibility
- Log security-relevant events — authentication successes and failures, access-control decisions, input-validation failures — with enough context to investigate, and without capturing secrets.
- Centralise and correlate. Aggregate logs where they can be searched and cross-referenced, so a pattern across systems is visible as one story.
- Alert on meaningful patterns and tune relentlessly to keep signal above noise, so responders trust the alerts they receive.
- Protect log integrity. Ship logs off-host, make them tamper-evident, and restrict who can modify them.
- Have an incident response plan that turns detection into action, with owners, escalation paths, and rehearsed playbooks.
- Test your detection. Run exercises that confirm real attacks actually generate alerts someone acts on.
Logging and monitoring is where security stops being about prevention and starts being about time — how quickly you notice, and how quickly you act. The uncomfortable framing of A09 is that most organisations already have the data and simply are not looking at it. The whole category reduces to a single principle this site keeps returning to: you cannot defend, or even detect, what you have not discovered.
- Trigger a few failed logins and one access-denied event, then go look for them in your logs. If they aren't there, you are blind to the early stages of an attack.
- Ask a simple question: if an account were compromised right now, who or what would notice, and how long would it take? Silence is the failure mode.
The full, at-scale version — validating that security-relevant events are captured, alerted on and actually reachable during a real incident — is what our assessment (and SecStudio agents) runs for you.