█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Cybersecurity/Application Security/OWASP A09: Security Logging and Monitoring Failures
40 minIntermediate

OWASP A09: Security Logging and Monitoring Failures

After this lesson, you will be able to: Recognize, find, and fix Security Logging and Monitoring Failures (OWASP A09): the gap that lets a breach go undetected for months.

Security Logging and Monitoring Failures is OWASP A09. It is not an attack you suffer directly; it is the failure to see attacks happening, so breaches go undetected, unresponded, and forensically unrecoverable. The industry average dwell time (breach to detection) is measured in many weeks for a reason.

Prerequisites:Software and Data Integrity Failures

What it is

This category covers: not logging security-relevant events (logins, failures, access-control denials, high-value actions); logs with too little detail to investigate; logs not monitored or alerted on; logs stored only locally where an attacker can wipe them; and no incident response triggered when something does fire. The result is that an attacker operates for weeks or months unseen, and when the breach is finally found, there is no trail to reconstruct what happened.

⚠️ Real-world breach

Target (2013) is the cautionary tale. Their security tooling actually detected the intrusion and fired alerts, but the alerts were not acted on, so attackers exfiltrated about 40 million payment-card records over weeks. More broadly, breaches routinely go undetected for months; the failure is not always missing logs but missing monitoring and response on the logs that exist.

How to find it

Audit what is logged, monitored, and responded to.

  1. 1

    List security-relevant events and check each is logged: logins (success + failure), access-control denials, input-validation failures, high-value transactions, admin actions.

  2. 2

    Check log quality: enough context (who, what, when, where) to investigate, without logging secrets/PII.

  3. 3

    Verify logs are centralized and tamper-resistant (shipped off-host), not just local files an attacker can delete.

  4. 4

    Confirm alerting exists: do suspicious patterns (many failed logins, privilege changes) trigger a notification?

  5. 5

    Test the response: when an alert fires, does anyone act, and is there a runbook?

How to fix it

Log the right events with context, centralize them, and alert + respond.

tsx
// LOG security events with context (no secrets/PII in the message)
logger.warn('auth.login.failed', {
userId: attempt.userId, ip: req.ip, ts: Date.now(),
reason: 'bad_password', attemptNumber,
});
// FIX CHECKLIST
// - Log auth success/failure, access-control denials, validation failures,
// privilege changes, and high-value actions, with enough context to investigate.
// - Never log passwords, tokens, full card numbers, or other secrets.
// - Ship logs to a central, tamper-resistant store (SIEM / log service).
// - Alert on suspicious patterns (brute force, privilege escalation).
// - Have an incident-response runbook so an alert leads to action, not silence.
Quick Check

Target's tools detected the 2013 breach and alerted. Why is it still a logging-and-monitoring failure?

Pick the best answer.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←OWASP A08: Software and Data Integrity Failures
Back to Application Security
OWASP A10: Server-Side Request Forgery (SSRF)→