OWASP Top 10 – A09: Security Logging and Monitoring Failures

Next up in the OWASP Top 10 series is a topic that’s less about preventing attacks and more about detecting and responding to them:
A09: Security Logging and Monitoring Failures

This section made me ask myself a very important question:

“If someone attacked your system today, would you even notice?”

And the honest answer — for most systems — is: probably not.
Because security isn’t just about stopping attacks. It’s also about noticing when they happen, knowing how to respond, and having the evidence to understand what went wrong.

Below are my notes and what I learned from researching this topic

What Is a Security Logging and Monitoring Failure?

This category includes failures in how a system:

Logs security-relevant events (or doesn’t),
Monitors logs or behaviors (or ignores them),
Raises alerts when something’s wrong (or never notices),
Stores and protects logs correctly (or allows tampering).

If an attack happens and no one notices, logs it, or responds to it — this category applies.

Why It’s So Important

If you can’t detect an attack, you can’t stop it.
If you don’t log malicious activity, you can’t investigate it.
If your logs are incomplete, inaccurate, or missing — post-incident forensics become nearly impossible.
Even if you use a SIEM (like ELK, Wazuh, or Splunk), it’s useless without proper configuration.

Security is not just about defense — it’s also about awareness and reaction.

Real-World Scenarios I Studied

1. No Logging on an Attacked API

A malicious user performs mass data scraping via an API. Since the API doesn’t log these requests, the breach goes completely unnoticed.

2. Brute-Force Attack on Login Panel

An attacker tries dozens of password combinations. The system doesn’t log failed attempts or raise alerts — so even if access is gained, no one knows.

3. Logs Exist, But No One Watches Them

A security incident is technically logged — but no alerts are set up, no one reviews the logs, and the breach isn’t discovered for months.

4. Logs Are Incomplete

Events are recorded, but without crucial data like user IDs, IP addresses, or endpoints. The logs are useless for understanding what actually happened.

When Are You at Risk?

When authentication events (login, logout, failed access) aren’t logged.
When logs are unencrypted, modifiable, or deletable.
When logs are stored locally and not backed up or centralized.
When no alerting or real-time monitoring is in place.
When logs aren’t retained for long enough or are overwritten quickly.

How to Prevent These Failures

1. Define Logging Standards

Decide which events to log (auth attempts, permission changes, API calls, errors, etc.).
Use a consistent format.
Include essential metadata: timestamps, user IDs, IP addresses, actions.

2. Secure the Logs

Logs should be append-only — no overwriting or deletion.
Apply strict file permissions.
Optionally sign logs or store in write-once media for integrity.

3. Implement Real-Time Monitoring

Use SIEM tools like Splunk, ELK, Wazuh, etc.
Set up alerts for suspicious patterns (e.g., 10 failed logins in 1 minute).
Monitor high-value systems continuously.

4. Respond to Alerts — Don’t Ignore Them

Avoid alert fatigue — only raise meaningful, actionable alerts.
Build and test an incident response plan.

5. Plan Log Retention and Backup

Define how long to retain logs (e.g., 6 months, 1 year).
Store logs securely and centrally.
Make logs accessible for audits and investigations.

Best Practices

Practice	Why It Matters
Log all login/logout/permission attempts	Tracks who accessed what and when
Use a SIEM to monitor logs	Detects real-time suspicious activity
Restrict access to logs	Prevents tampering and unauthorized access
Trigger alerts for critical events	Enables fast response to threats
Encrypt logs and store them safely	Prevents data leaks or manipulation

How to Test for These Failures

Log Injection Tests – Try to insert malicious inputs into logs and see how they’re handled.
Failed Login Simulations – Attempt repeated failed logins and check if they’re logged and alerted.
Incident Simulation – Trigger a controlled “incident” to test if it’s logged, detected, and responded to.
Privilege Abuse Test – Try accessing restricted features and verify if alerts are raised.

Who’s Responsible?

Developers:

Identify and log important security events.
Make logs meaningful — not just noise.

System Admins:

Protect and centralize log storage.
Ensure retention, access control, and backup policies are enforced.

Security Teams:

Configure and tune SIEM tools.
Build detection rules and response playbooks.
Actively monitor and respond to incidents.

The biggest takeaway I had from this topic:

You can’t stop what you can’t see.