Logging, Detection and Incident Response

Every lesson so far has been about prevention — and prevention is most of the job. But a core security assumption, from Lesson 1, is that defenses eventually fail: a new vulnerability, a clever attacker, a human mistake. Mature security therefore plans for the breach that gets through. That means two things this lesson covers: detection (knowing something is wrong, fast) and response (handling it calmly and well). Both depend on groundwork you lay before anything happens — most of all, logging the right things.

Log the Right Things (and Never the Wrong Ones)

You cannot detect, investigate, or recover from what you didn’t record. Good security logging is deliberate: specific events, with enough context to be useful, and — just as important — without the sensitive data that would make the logs themselves a liability.

Always log the security-relevant events:

• Authentication events — successes and failures. Failed logins are your earliest brute-force signal; successes let you spot “logged in from a new country at 3 AM.”
• Authorization denials — who tried to access what and was refused. A burst of these is often an attacker probing (and a sign someone’s hunting for BOLA, Lesson 3).
• Administrative and privileged actions — role changes, permission grants, data exports, config changes. These are what an attacker does after getting in.
• Security-relevant changes — new API keys, modified security settings, user-permission edits.

And log them with the context that makes an investigation possible: who (user/service), what (the action), when (accurate timestamp), from where (IP, user agent), and a request/correlation id that lets you trace a single request across services.

Never log the things that turn your logs into a breach:

• Passwords, tokens, session ids, OTPs, API keys, secrets (Lesson 7). Logs are widely readable — developers, ops, log-aggregation vendors, backups — and long-lived. A secret in a log is a leaked secret, full stop.
• Full card numbers, CVV (PCI forbids it), and more personal data than you actually need for the log’s purpose. Every extra field of personal data in a log is extra breach liability and a privacy problem (Lesson 12). Mask and minimise.

Many logging libraries support redaction filters — configure them so secrets are scrubbed even if someone accidentally logs an object that contains one.

From Logs to Detection

Logs sitting unread on fifty servers don’t protect anyone. The step that creates detection is turning logs into timely signals:

• Centralise logs into one searchable place (a log platform / SIEM). During an incident you cannot be SSHing into individual machines to grep; you need to query everything at once. Centralising also means an attacker who compromises one host can’t erase the evidence — so make logs tamper-evident / append-only where you can.
• Alert on meaningful signals, not everything: a spike in failed logins, a surge of authorization denials (403s), logins from new geographies or impossible travel, unusual data-export volume, a sudden error-rate change. These are the patterns that indicate an attack in progress.
• Keep enough history to investigate — weeks to months — because breaches are often discovered long after the initial intrusion, and you’ll want to reconstruct the timeline. Balance this against privacy and retention limits (Lesson 12).
• Tune out the noise. This is the step teams skip, and it quietly defeats the whole effort: an alert that fires constantly for nothing gets ignored, and then the one real alert is ignored too (alert fatigue). A smaller set of high-signal, trustworthy alerts beats a firehose nobody reads.

Done well, this is what lets you notice a breach in hours instead of the industry-typical months — and early detection is often the difference between a contained incident and a catastrophe.

A Calm Incident-Response Playbook

When something does go wrong, the worst time to figure out what to do is in the middle of it, at 3 AM, with adrenaline high. So you decide the steps in advance and follow them. The standard shape (sometimes called PICERL) is six steps:

1. Prepare — before anything happens: know who’s on the response team and how to reach them, have runbooks for likely scenarios, keep contact lists (including legal and comms), and — critically — have tested backups you can actually restore from. Preparation is what makes the other five steps possible.
2. Identify — detect and confirm. Is this a real incident or a false alarm? What’s the scope (which systems, which data) and severity? Resist both panic and denial; establish the facts.
3. Contain — stop the bleeding. Isolate affected hosts, revoke compromised credentials and sessions, block the attacker’s access, disable the exploited feature. The goal is to limit the damage now, before you fully understand it — containment comes before root cause.
4. Eradicate — remove the cause. Patch the vulnerability, remove the malware or backdoor, close the gap the attacker used. Make sure they can’t just walk back in.
5. Recover — restore clean, verified service (from those tested backups if needed), and watch closely for recurrence — attackers often try again, and you want to be sure you actually got them out.
6. Lessons — a blameless postmortem (the same philosophy as operational incident reviews elsewhere on this site): understand how the system allowed this and fix the system — the missing control, the gap in monitoring, the process failure — rather than blaming a person. Update the playbook so you’re better next time. A review that produces no concrete, owned fixes was theatre.

The blameless part matters enormously for security specifically. If people fear punishment, they hide mistakes and near-misses — which is exactly the information you need to prevent the next breach. A culture where someone can say “I clicked the phishing link” or “I think I committed a key” immediately, without fear, detects and contains incidents far faster than one where people go quiet. Treat human error as a signal that the system made the error too easy, and fix the system.

Know Your Obligations

One more piece that’s not optional: when personal data is breached, you often have legal duties to notify. In India, the DPDP Act 2023 requires notifying the Data Protection Board and the affected users of a personal-data breach (Lesson 12 covers the Act more fully). Other regimes (GDPR, sectoral rules) have their own timelines and thresholds. Build notification into your incident-response plan — know in advance who decides, what counts as reportable, and how fast you must act — because discovering your legal obligations mid-incident is a bad time to learn them. Handling a breach honestly and promptly, including telling affected people, is both a legal requirement and the right thing to do for the users whose data you hold.

Pitfalls to Avoid

1. Not logging security events. You can’t detect or investigate what you didn’t record. Log auth (success + failure), authz denials, and privileged actions with full context.
2. Logging secrets or excess personal data. Logs leak and are widely readable. Never log passwords, tokens, OTPs, or card data; minimise personal data and use redaction.
3. Logs that are never read. Centralise into a searchable, tamper-evident platform and alert on real signals, or the logs protect no one.
4. Alert fatigue. A noisy alert that’s always ignored means the real one is ignored too. Tune for a few high-signal, trustworthy alerts.
5. No incident-response plan. Deciding what to do mid-breach guarantees chaos. Have the six-step playbook, with roles and tested backups, ready in advance.
6. Diagnosing before containing. Stop the bleeding first (isolate, revoke), then find root cause.
7. Blameful postmortems and ignored notification duties. Blame hides the information you need; fix the system. And know your breach-notification obligations (DPDP Act) before you need them.

Quick Recap

• Prevention fails eventually, so invest in detection and response, which depend on logging laid down in advance.
• Always log auth events (success + failure), authz denials, and privileged/security actions with who/what/when/where + a request id. Never log passwords, tokens, OTPs, card data, or excess personal data.
• Turn logs into detection: centralise, make tamper-evident, alert on real signals (failed-login spikes, 403 surges, new-geo logins, export volume), and tune out noise.
• Follow a calm, pre-decided IR playbook: Prepare, Identify, Contain before diagnosing, Eradicate, Recover, and a blameless Lessons step that fixes the system.
• Know your breach-notification duties — India’s DPDP Act requires notifying the Board and affected users.

Next lesson, the last: weaving security into how you build, not bolting it on — shift-left, SAST/DAST, a security culture, and privacy and compliance with India’s DPDP Act.