Logging, monitoring, and incident response fundamentals
Every other lesson in this domain is about preventing an attack — this one is about what happens when prevention fails anyway, which it eventually will, and the difference between a contained incident and a much larger one usually comes down to how quickly it was actually noticed and understood.
4 min read
Why "we'll notice if something bad happens" is not a real plan
Without deliberate logging: an attacker who successfully exploits an
IDOR vulnerability (from this domain's own lesson) and reads 10,000
other users' invoices leaves NO trace at all — from the application's
point of view, it was just 10,000 ordinary, "successful" requests,
indistinguishable from legitimate traffic
Without logs specifically capturing security-relevant events, a successful attack can be genuinely invisible — from the application's perspective, a successful IDOR exploitation reading data it shouldn't have looks identical to a legitimate, successful request, since nothing about the request itself was malformed or rejected. Assuming "we'd notice" without actually logging and monitoring for exactly this kind of thing is a real, common gap — the technical vulnerability might be fixed eventually, but the fact that it was actively exploited before the fix can go completely undetected.
What's actually worth logging, specifically for security purposes
- Authentication events: every login SUCCESS and FAILURE, with enough
context to spot a pattern (many failures for one account = possible
brute force, covered in this domain's own lesson)
- Authorization failures: every time a user is DENIED access to
something — a real, useful signal, since a legitimate user rarely
triggers many authorization denials, but a probing attacker does
- Sensitive data access: who accessed what, and when — specifically
for data where "who looked at this" matters for later investigation
- Administrative actions: who changed what configuration, permission,
or user role, and when
Security-relevant logging is deliberately more specific than general application logging — the goal isn't logging everything (which produces an unusable volume of noise), it's logging the specific events that would actually matter during a security investigation: authentication attempts (both success and failure), authorization denials (a real, meaningful signal on their own — a pattern of many denials from one account is a real red flag), access to genuinely sensitive data, and administrative changes.
Monitoring: the difference between having logs and actually noticing something
Logs sitting in a file nobody ever looks at are functionally useless
for detection — monitoring means something ACTIVELY watches those logs
(or metrics derived from them) and ALERTS a real person when a genuine
anomaly appears, rather than requiring someone to manually read logs
after the fact, usually only AFTER already suspecting something's wrong
Logs alone are a record that could be examined; monitoring is the active practice of watching for patterns worth alerting on — a spike in authentication failures, an unusual volume of authorization denials from one account, a request rate far outside normal patterns for a given endpoint. The real, practical value of monitoring over logs alone is time: a monitored anomaly can trigger investigation within minutes, while logs that only get reviewed reactively (after something else already raised suspicion) mean an attack could run undetected for a genuinely long time.
What a basic incident response actually looks like, once something's detected
1. CONTAIN — stop the ongoing damage first (rotate a leaked secret,
this domain's own lesson; revoke a compromised session; block an
attacking IP) — before fully understanding every detail
2. INVESTIGATE — use the logs described above to determine WHAT
actually happened: what was accessed, by whom, for how long
3. REMEDIATE — fix the actual root cause (the specific vulnerability
that was exploited), not just the immediate symptom
4. LEARN — a genuine post-incident review: how was this missed, and
what would catch something like it faster next time
A basic, real incident response follows a deliberate order: contain the ongoing damage first (the same "rotate immediately" urgency this domain's secrets-management lesson argued for), investigate using the logs and monitoring described above to actually understand scope and impact, remediate the real underlying cause rather than just the symptom that was noticed, and finally conduct a genuine review of how the incident happened and how detection/response could improve — closing the loop back into better logging, monitoring, or prevention for next time.
Further reading
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why can a successful IDOR exploitation be completely invisible without deliberate security logging?
2. What's the actual difference between having logs and having real monitoring?
3. In a basic incident response, why does 'contain' come before 'investigate' rather than after?