Practice and strategy · Module 6
Detection and incident response
Detection closes the gap between compromise and action.
Previously
Vulnerability management
Vulnerability management is not a panic feed.
This module
Detection and incident response
Detection closes the gap between compromise and action.
Next
Privacy, ethics, and auditability
This section is the glue.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Before the tools, agree on the decision you are practising.
What you will be able to do
- 1 Explain the detection and response loop and who owns each step
- 2 Build a timeline that supports scope and containment decisions
- 3 Tune detections with an explicit trade off between noise and misses
Before you begin
- You understand what logs are and why time matters
Common ways people get this wrong
- Panic response. Rushing creates more harm. A rehearsed sequence prevents chaos.
- Over-containment. Containment that breaks the business can be its own incident. Choose proportional actions.
Main idea at a glance
From events to action
Systems emit events → SIEM rules → alerts → analyst follows a playbook.
Detection to response operating loop
`flowchart LR
Sources["System &\napp logs"] --> Pipeline["Log pipeline\n& normalise"]
Pipeline --> Correlation["SIEM rules\n& analytics"]
Correlation --> Alert["Prioritised\nalert"]
Alert --> Analyst["Analyst\ntriage"]
Analyst --> Contain["Contain &\nrespond"]
Contain --> Recover["Recover\nservices"]
Recover --> Lessons["Lessons &\nrule tuning"]
Lessons --> Correlation
`Detection to response operating loop
Detection closes the gap between compromise and action. A SIEM feeds alerts to a SOC. Good detection reduces dwell time. Response follows a loop. Triage, contain, eradicate, recover, and learn.
Why this exists. Prevention fails. Detection and response are how you limit business impact when you have a bad day. This is also where trust gets rebuilt. Customers do not need perfection, but they do need competent, transparent handling.
Who owns it. SOC and incident response teams own day to day triage and response. Engineering owns fix and deploy. IT owns endpoint actions. Security leadership owns priorities, playbooks, and escalation rules. Leadership and legal often co own external communication and reporting decisions. Third parties frequently own part of the telemetry and response actions.
Trade offs. More detection rules can mean more noise. Aggressive thresholds catch more, but can burn analysts out and lead to missed real incidents due to alert fatigue. Heavy containment can protect systems, but can also take critical services offline. Good programmes balance risk reduction with operational sustainability.
Failure modes. Collecting logs without being able to answer questions from them. Treating a SIEM as a product purchase rather than an operating model. No clear owner for response decisions, no tested playbooks, and no authority to contain when it hurts.
Maturity thinking. Basic looks like centralised logging, MFA for admin, and a minimal set of high value detections. Good looks like playbooks, on call rotation, regular tabletop exercises, and tuning based on real incidents. Excellent looks like measured time to detect and time to contain, cross team drills, and a learning loop where fixes land fast.
Threat hunting is proactive. Forming a hypothesis and looking for weak signals before an alert fires. In some platforms you will see UEBA (user and entity behaviour analytics), which is basically pattern detection over behaviour. Use it, but do not worship it. Playbooks standardise common steps. Tabletop exercises build muscle memory.
Before the tools, agree on the decision you are practising. Are you prioritising speed of containment over service availability. Are you building evidence for a regulator. Are you deciding whether this is an incident or just a weird Tuesday.
Afterwards, interpret like an investigator and like a leader. The timeline is not just for curiosity. It drives scope, impact, and next actions. It also affects evidence quality. Can you show who did what, when, and from where, in a way that would stand up in a review.
After you run it, document the judgement. Which signals are mandatory, which are optional, and who owns them. Then turn it into an operating rule. Who can change detections, how changes are reviewed, and what you monitor to detect drift.
Mental model
Detect to recover
Incident response is a sequence: detect, contain, recover, learn.
-
1
Detect
-
2
Contain
-
3
Recover
-
4
Learn
Assumptions to keep in mind
- Roles are clear. If nobody is on point, response becomes a meeting. Roles create speed and calm.
- Evidence is captured early. Change destroys evidence. Capture what you need before you fix.
Failure modes to notice
- Panic response. Rushing creates more harm. A rehearsed sequence prevents chaos.
- Over-containment. Containment that breaks the business can be its own incident. Choose proportional actions.
Key terms
- SIEM
- Security information and event management (SIEM), a platform that collects and correlates security events
- SOC
- security operations centre (SOC), a team that monitors and responds
- dwell time
- how long an attacker stays unnoticed
Check yourself
Quick check. Detection and response
0 of 7 opened
Scenario. Your SIEM fires constantly and nobody trusts it. What should you do
Reduce noise. Tune rules, add context, tie alerts to playbooks and owners, and prioritise a small set of high value detections first.
What does a SIEM do
Collects and correlates events to surface potential security issues.
Why does dwell time matter
The longer an attacker remains undetected, the more damage they can do.
What is the usual response flow
Triage, contain, eradicate, recover, then learn and improve.
What is threat hunting
Proactively searching for weak signals of attack before alerts fire.
Why use playbooks
To make response consistent and faster under pressure.
Name one valuable log source
Authentication and authorisation events, or admin actions on critical systems.
Artefact and reflection
Artefact
An incident timeline and a short playbook excerpt
Reflection
Where in your work would explain the detection and response loop and who owns each step change a decision, and what evidence would make you trust that change?
Optional practice
Arrange log events into a timeline and practise telling the story of what happened and when.
Also in this module
Map detection coverage
Map attacks to signals and aim for at least two signals per attack stage.