Logging Failures

All the prior categories (A01–A08) are about preventing specific attacks. A09 is different: it's about visibility. Even if you prevent 99% of attacks perfectly, the 1% that gets through is worthless to know about unless you can see it happening and respond to it. A09 is the category that answers: "Do you have logs? Are they trustworthy? Are you watching them? Do you know when you've been breached?"

A09: Security Logging & Monitoring Failures

This category covers the absence or inadequacy of security event logging and real-time monitoring — failures that mean attacks go undetected, breaches persist for months, and forensics after the fact are impossible. The core failures are:

• Insufficient logging — not capturing security-relevant events (auth attempts, access control failures, input validation failures, suspicious patterns).
• Logs not protected — logs are stored in the application server (where an attacker can delete them) or sent unencrypted (where they can be intercepted or modified).
• No monitoring — logs exist but nobody is reading them; no alerts on suspicious activity; no incident response plan.
• Poor log visibility — logs are too verbose or too sparse; signal is buried in noise, or critical events are absent.

What to Log (and What NOT to Log)

DO LOG (security events):

• Authentication — login attempts (success and failure), MFA challenges, session creation/destruction, password resets.
• Authorization — access control decisions (allowed and denied), privilege escalation attempts, attempts to access resources outside the user's scope.
• Input validation — validation failures (inputs that don't match expected patterns), suspicious payloads, repeated failed validations from the same IP.
• Data access — who accessed what data and when (especially sensitive data).
• Configuration changes — admin actions, deployment events, security settings changes.
• Errors — unexpected errors, especially security-related (crypto failures, deserialization errors, CORS violations).

DO NOT LOG (sensitive data):

• Passwords, API keys, tokens, secrets (even in error messages).
• Personally identifiable information (PII): credit card numbers, SSNs, email addresses, phone numbers.
• Health data, financial data, or other regulated information unless required by compliance and redacted.

Log Integrity: Protecting the Logs

Logs are a crime scene. If an attacker can modify or delete them, they can cover their tracks. A09 defences for log integrity:

• Centralized logging — send logs to a separate system (a logging service, a SIEM, a write-only database) that the application can't delete. If logs stay on the app server, an attacker who compromises the app deletes them.
• Write-once storage — logs are appended to immutable storage (e.g. a write-once tape, or a cloud service with audit logs that can't be deleted, like AWS CloudTrail). Once written, they can't be modified or deleted.
• Signed/hashed logs — each log entry is signed or chained (e.g. each entry includes a hash of the previous entry). Tampering breaks the chain and is detectable.
• Encryption in transit — logs are sent over HTTPS/TLS; they're not readable if intercepted.
• Access control — only authorized personnel can read logs; an attacker with app-level access doesn't have log access.

Monitoring and Alerting (the Human/Automated Response)

Logs are useless if nobody reads them. A09 defences for visibility:

• Real-time monitoring — a SIEM (Security Information & Event Management) tool watches logs as they arrive and flags anomalies (e.g. 10 failed logins from the same IP, a user accessing 1000 files in 1 second, a privilege escalation).
• Alerting — automated alerts to on-call security staff when suspicious activity is detected (email, SMS, PagerDuty).
• Baselines and thresholds — know what "normal" looks like (typical login times, typical data access patterns) so you can spot when activity deviates.
• Incident response plan — when an alert fires, who is on-call? What's the playbook? Can you kill a compromised session, revoke a stolen token, isolate a server?

Breach Detection: How A09 Connects to Everything Else

A09 doesn't prevent any of the attacks in A01–A08. But it lets you detect them:

• A01 (Access Control) — log access control failures; alert on repeated denials or escalation attempts.
• A02 (Crypto) — log crypto errors; they're usually rare and often indicate an attack or misconfiguration.
• A03 (Injection) — log input validation failures; SQL errors that indicate injection attempts.
• A04 (Insecure Design) — log business-logic anomalies (large transactions, unusual access patterns, price manipulations).
• A05 (Misconfiguration) — log config changes; alert on changes to security settings.
• A06 (Outdated Components) — log library version changes and known-CVE scanners; alert on vulnerable versions reaching production.
• A07 (Auth) — log auth events extensively (login attempts, MFA, sessions, recovery).
• A08 (Integrity) — log artifact deployments, signed-commit validations, CI/CD actions.

A09 is the safety net — it doesn't prevent breaches, but it catches them before they become catastrophic.

Hands-On Exercises