C9: Implement Security Logging and Monitoring

📋 What Is This Control?

Security Logging and Monitoring is the proactive control of recording security-relevant events, watching those records in near-real time, and wiring them into detection and response. Logging without monitoring is a write-only archive nobody reads; monitoring without logging has nothing to watch. The control requires three linked obligations - log, monitor, and respond - joined to an incident-response process that can act on what they surface. It is the discipline that lets an organization know when something is going wrong, and prove afterward what happened.

C9 Proactive Control

Detection Focus Area

OWASP 2024 Proactive Controls

🎯 What It Prevents

Long-dwell silent compromise: attackers operating undetected for weeks or months
Undetected credential stuffing / brute force: auth failures that leave no alertable trace
Enumeration & access-control probing (IDOR/BOLA): one actor generating many "forbidden" outcomes
Insider & post-compromise privilege abuse: role changes and new admin accounts going unnoticed
Bulk data exfiltration: exports that dwarf normal usage passing unseen
No forensic trail: missing or attacker-wiped local logs after an incident
Log injection & tampering: untrusted data forging entries or erasing tracks
Alert fatigue: real detections buried under untuned noise

🧭 How It Works

1. Instrument: emit structured security events with
who/what/when/where + a correlation/trace ID
↓
2. Ship & centralize: forward off-host in near-real
time to a SIEM (never trust local disk alone)
↓
3. Protect: append-only, integrity-checked storage;
NTP-synced clocks; redact secrets/PII
↓
4. Baseline & alert: learn normal, fire tuned,
actionable, deduplicated alerts
↓
5. Respond via a rehearsed playbook; test that detection fires

❌ Without This Control

# Free-text, no context - who? what? when? where? unparseable
logger.info("error occurred")
logger.info("user logged in")          ← which user? from where? outcome?

# Log injection - untrusted data concatenated verbatim
log.info("login user=" + username)     ← CRLF in username forges a new entry

# Secrets and PII written in cleartext (logs are widely copied & read)
log.info("request " + str(request_body))  ← passwords, tokens, card #s leak

# Auth failures and access denials are NOT logged at all
# → brute force, credential stuffing, IDOR probing leave no trace

# Logs kept only on local disk, mutable, rotated away in days
# → an attacker on the host deletes them; nothing to correlate

# No monitoring, no baseline, no alerts
# → the breach is discovered months later, by a third party
                

✅ Applying the Control

# Structured, machine-parseable event with full context + trace ID
{
  "timestamp": "2026-08-29T14:03:11.482Z",   # UTC, ISO-8601, NTP-synced
  "event": "authn.login.failure", "outcome": "failure",
  "actor": { "user_id": "u_8842", "src_ip": "203.0.113.44" },
  "target": { "resource": "/api/session", "method": "POST" },
  "reason": "invalid_password", "trace_id": "b7f1c2a9-...-77a0d1e4f8bd",
  "service": "auth-api", "env": "prod"
}

# Neutralize untrusted data - structured fields escape newlines
log.info("login attempt", extra={"actor": {"user_name": safe(username)}})

# Redact secrets/PII at the logging boundary (deny-list of field names)
REDACT = {"password", "token", "authorization", "cookie", "ssn", "card"}

# Ship off-host + immutable storage (S3 Object Lock, writer = PutObject only)
aws s3api put-object-lock-configuration --bucket sec-logs \
  --object-lock-configuration '...Mode=COMPLIANCE,Days=365...'

# SIEM detection over the stream - baseline, then alert on deviation
alert if count(event="authn.login.failure") by src_ip
        over 5m > baseline_p99 * 3       # credential stuffing
                

✓ Implementation Checklist

A documented list of security-relevant events exists and is implemented
Every security event logged with who/what/when/where + a correlation ID
Logs are structured (e.g. JSON) with a consistent, documented schema
Untrusted data is neutralised (no log injection); structured fields used
Secrets and PII are redacted/masked at the logging boundary
Logs shipped off-host in near-real time to a central SIEM/log platform
Storage is append-only/immutable, integrity-protected, and access-controlled
Retention meets investigation and compliance needs, with a defined expiry
All clocks are NTP-synchronised; timestamps are UTC/ISO-8601
A baseline of normal behaviour exists; anomalies are detected
Alerts are tuned, actionable, deduplicated, and severity-routed
Alerts feed a documented playbook; detection is tested by pentests/red team

🔍 Tools & Techniques

Pipeline & SIEM:

Elastic / ELK Splunk Filebeat Logstash CloudTrail S3 Object Lock

Alerting & Integrity:

Alertmanager PagerDuty chrony / NTP OpenTelemetry trace IDs Purple-team emulation

How to Verify:

Confirm auth, access-control, admin, and high-value events are captured
Check every entry carries actor, target, outcome, and a trace ID
Try to forge a log line with a CRLF in input - it must be neutralised
Confirm secrets/PII are redacted before the log store
Run a pentest / red-team exercise - it must trigger alerts
Verify log-gap monitoring fires when a service stops sending logs

🌍 Why It Matters

The durable, defensible pattern across public post-mortems is that detection failures extend dwell time - attackers operate for weeks or months because the events that would have exposed them were never logged, monitored, or alerted on. These are incident classes, not fabricated figures.

Long-dwell breaches discovered by outsiders: the victim learns of a compromise from a bank, researcher, or law enforcement rather than its own monitoring. The events existed but were never logged, centralised, or alerted on.
Credential stuffing at scale: automated login attacks succeed quietly when auth failures are not logged and rate anomalies are not alerted. Structured authn logs plus a baseline make a spike of failures obvious.
Enumeration / IDOR-BOLA probing: one actor generating hundreds of "forbidden" outcomes across many objects is a clear detection when access-control failures carry actor and target.
Insider abuse & bulk exfiltration: role changes, new admin accounts, and mass exports are fingerprints of persistence and theft - surfaced only when admin actions and high-value transactions are logged and baselined.

📌 Quick Tips

DO NOT log secrets, tokens, or PII in cleartext
DO NOT write untrusted data verbatim (log injection)
DO NOT keep logs only on local, mutable disk
DO log the right events with who/what/when/where + trace ID
DO centralize to append-only storage on NTP-synced clocks
DO tune alerts to be actionable and fight alert fatigue
DO test that pentests and red-team runs trip your alerts

📊 Security Logging and Monitoring