Incident Response
The IR lifecycle (PICERL) — event vs incident, containment vs monitoring, attack timelines, phishing triage, breach scoping, ransomware playbooks, chain of custody and breach notification.
13 questions
JuniorTheoryVery commonWhat is the difference between an event, an alert and a security incident?
What is the difference between an event, an alert and a security incident?
An event is any observed occurrence such as a logon or a file write. An alert is an event a rule flagged as suspicious. An incident is a confirmed or likely security violation. Triage is the analyst decision that promotes alerts to incidents.
Common mistakes
- ✗Calling every alert an incident, which inflates counts and burns the team
- ✗Believing only outages qualify, so silent data theft is never declared
- ✗Treating the promotion decision as automatic instead of an analyst judgement
Follow-up questions
- →What triage inputs decide whether an alert becomes an incident?
- →How does severity classification change who is woken up and when?
JuniorTheoryVery commonWhat are the phases of the incident-response lifecycle, and why does preparation dominate?
What are the phases of the incident-response lifecycle, and why does preparation dominate?
Preparation, detection and analysis, containment, eradication, recovery, lessons learned. Preparation dominates because logs, runbooks, backups and decision authority cannot be built mid-incident — what exists beforehand caps every later phase.
Common mistakes
- ✗Treating preparation as audit paperwork rather than the phase that sets your ceiling
- ✗Skipping lessons learned once service is restored, so the same gap repeats
- ✗Assuming missing telemetry can be recreated after the incident has started
Follow-up questions
- →Which artefacts must exist before an incident for the analysis phase to work at all?
- →Why is a blameless postmortem — a no-fault review format — better at surfacing gaps?
JuniorTheoryCommonWhat is an attack timeline, and what do dwell time and patient zero mean on it?
What is an attack timeline, and what do dwell time and patient zero mean on it?
A timeline orders every confirmed attacker action on one normalised clock, normally UTC. Dwell time is the gap between first compromise and detection. Patient zero is the first host or account compromised — without it you cannot scope honestly.
Common mistakes
- ✗Mixing local timestamps from different sources without normalising to UTC
- ✗Reading dwell time as time-to-contain rather than compromise-to-detection
- ✗Calling the loudest infected host patient zero without proving it was first
Follow-up questions
- →How do clock skew and time zones corrupt a multi-source timeline?
- →Why does a long dwell time widen the scope you must investigate?
JuniorTheoryCommonWhat is short-term versus long-term containment, and what does isolating a host cost you?
What is short-term versus long-term containment, and what does isolating a host cost you?
Short-term containment stops damage now — isolate the host, disable the account. Long-term containment is the sustainable fix that holds while you eradicate. Rushing isolation can destroy volatile evidence and tip off an active intruder, so capture memory first.
Common mistakes
- ✗Powering a host off to contain it and losing memory-resident evidence
- ✗Assuming isolation is invisible to an intruder who is still on the keyboard
- ✗Treating short-term containment as the fix and never applying a durable one
Follow-up questions
- →When would you deliberately monitor a compromised host instead of isolating it?
- →What acquisition order preserves volatile evidence before you cut the network?
JuniorTheoryCommonHow does eradication differ from recovery, and when do you rebuild a host instead of cleaning it?
How does eradication differ from recovery, and when do you rebuild a host instead of cleaning it?
Eradication removes the attacker — persistence, implants and the entry vector — and rotates credentials they could have taken. Recovery restores service from known-good state and watches it. Rebuild rather than clean once a host had system-level compromise.
Common mistakes
- ✗Deleting the malware but leaving persistence and the original entry vector open
- ✗Skipping credential rotation, so the attacker walks back in with stolen secrets
- ✗Cleaning a host that had kernel or SYSTEM-level compromise instead of rebuilding
Follow-up questions
- →Which credentials count as exposed when a workstation is compromised?
- →What monitoring would you add to a restored host and for how long?
JuniorDebuggingCommonA user forwarded this message to the security mailbox — triage the headers and state the verdict.
A user forwarded this message to the security mailbox — triage the headers and state the verdict.
SPF, DKIM and DMARC all fail for the claimed sender, so the From header is forged. The display name reads Billing while the domain is a lookalike, paypa1 with a digit one, Reply-To points elsewhere, and the subject manufactures urgency. Keep the raw headers.
Open full question →Common mistakes
- ✗Assuming delivery to the inbox means the message passed authentication
- ✗Reading a lookalike domain as a legitimate partner or delivery subdomain
- ✗Deleting the message before the raw headers are preserved as evidence
Follow-up questions
- →What would you search for to find who else received the same campaign?
- →Why is the email-authentication policy
DMARCset to reject on the spoofed domain relevant here?
SeniorDesignCommonIt is 02:40. A file server holding the finance share is encrypting files, and three workstations show the same ransom note. Backups are nightly to a NAS on the same domain. You have two responders, a domain admin on call, and no legal counsel until morning. The board will ask later whether the incident was scoped correctly. Design the containment plan for the next two hours: what you cut, in what order, what you capture before cutting, how you avoid destroying the evidence needed to find initial access, and how you decide whether the attacker is still interactive. State your assumptions and the decision points at which you would escalate.
It is 02:40. A file server holding the finance share is encrypting files, and three workstations show the same ransom note. Backups are nightly to a NAS on the same domain. You have two responders, a domain admin on call, and no legal counsel until morning. The board will ask later whether the incident was scoped correctly. Design the containment plan for the next two hours: what you cut, in what order, what you capture before cutting, how you avoid destroying the evidence needed to find initial access, and how you decide whether the attacker is still interactive. State your assumptions and the decision points at which you would escalate.
Capture volatile state first — memory and network sessions on the file server and one workstation — then isolate at the network layer, not by powering off. Take the NAS off the domain to protect backups, disable suspect accounts, and escalate if activity continues.
Common mistakes
- ✗Powering hosts off, which destroys memory-resident keys, sessions and process state
- ✗Leaving backups reachable from the compromised domain while containment runs
- ✗Declaring the three known hosts the full scope without hunting for initial access
Follow-up questions
- →What signals tell you the intruder is interactive rather than an automated payload?
- →How would the plan change if the encryption reached a third-party managed service?
MiddleTheoryOccasionalWhat is chain of custody for digital evidence, and what keeps that evidence defensible?
What is chain of custody for digital evidence, and what keeps that evidence defensible?
Chain of custody is the unbroken signed record of who held each item of evidence, when and why. Evidence stays defensible when you hash the original, work only on a verified copy, re-hash to prove nothing changed, and log every transfer with time and handler.
Common mistakes
- ✗Analysing the original media instead of a verified working copy
- ✗Hashing only after analysis, which proves nothing about the original state
- ✗Leaving handovers between responders undocumented
Follow-up questions
- →What is the order of volatility, and why is memory acquired before disk?
- →Who decides when evidence handling must meet a legal standard rather than an internal one?
MiddleTheoryOccasionalWhat is the purpose of a tabletop exercise, and what does a good scenario actually test?
What is the purpose of a tabletop exercise, and what does a good scenario actually test?
A tabletop is a discussion-based rehearsal of an incident where no system is touched. Its purpose is to find plan gaps while they are cheap. A good scenario tests decisions, not trivia — who declares the incident, who may stop production, when legal and customers hear.
Common mistakes
- ✗Running a tabletop as a knowledge quiz instead of a decision rehearsal
- ✗Excluding legal, PR and management, so communication gaps stay hidden
- ✗Confusing a tabletop with a live technical simulation against real systems
Follow-up questions
- →What output of a tabletop turns into an actual change in the runbook?
- →How would you design a scenario that stresses decision authority out of hours?
MiddleDebuggingOccasionalThese four sources disagree on time — put the attacker actions in their true order.
These four sources disagree on time — put the attacker actions in their true order.
Normalise to UTC and fix the skew first — the file server runs 47 minutes fast, so its 09:52 +03:00 entry is really 06:05Z. True order is VPN logon 05:58Z, mass file read 06:05Z, service installed 06:15Z, then the 1.4 GB egress at 06:22Z.
Open full question →Common mistakes
- ✗Ordering by the printed digits without converting zone offsets to UTC
- ✗Adding the drift of a fast clock instead of subtracting it
- ✗Discarding a skewed source instead of correcting it by a measured offset
Follow-up questions
- →How would you measure and record a host clock offset so the correction is defensible?
- →Which additional source would confirm the VPN logon was the initial access?
SeniorDesignOccasionalYour team confirms that a misconfigured export exposed a table with names, emails and delivery addresses of 40,000 customers, including EU residents and Russian users. The exposure lasted nine days and access logs are incomplete. It is Friday evening. Marketing wants to say nothing until Monday, support is already receiving questions, and one enterprise customer has a contract clause requiring notice within 24 hours. Design the communication and notification plan: who is told internally and in what order, what you tell the regulator and when, what you tell affected customers, and how you handle the gap that incomplete logs create in your statement.
Your team confirms that a misconfigured export exposed a table with names, emails and delivery addresses of 40,000 customers, including EU residents and Russian users. The exposure lasted nine days and access logs are incomplete. It is Friday evening. Marketing wants to say nothing until Monday, support is already receiving questions, and one enterprise customer has a contract clause requiring notice within 24 hours. Design the communication and notification plan: who is told internally and in what order, what you tell the regulator and when, what you tell affected customers, and how you handle the gap that incomplete logs create in your statement.
Escalate to leadership and legal first — legal owns the regulatory clock, and GDPR expects the supervisory authority told within 72 hours of awareness. Meet the customer's 24-hour contractual term, tell users what data and what risk, and state what the logs cannot confirm.
Common mistakes
- ✗Letting marketing rather than legal own the regulatory notification clock
- ✗Treating incomplete logs as a reason to delay or deny notification
- ✗Ignoring contractual notice terms that are shorter than the statutory one
Follow-up questions
- →How does the notification duty differ when you are the processor rather than the controller?
- →What wording keeps a statement honest when the blast radius is still an upper bound?
SeniorTheoryOccasionalWhen is it safe to declare an incident eradicated and recovered?
When is it safe to declare an incident eradicated and recovered?
Only after you have found initial access and the full blast radius — every account, host and token the attacker could reach — and closed the vector, not the symptom. Scope by attacker behaviour rather than the first indicator list, then rotate exposed credentials.
Common mistakes
- ✗Declaring recovery while initial access is still unknown
- ✗Scoping only from the first indicator list instead of attacker behaviour
- ✗Rebuilding hosts but leaving stolen credentials and tokens valid
Follow-up questions
- →Why does behaviour-driven scoping find more than an indicator-of-compromise list?
- →What heightened monitoring would you keep after the incident is formally closed?
SeniorDesignOccasionalYou join a 25-person product company as its first security engineer. There is no incident-response plan: alerts land in a shared inbox, everyone has production access, and the last outage was handled by whoever noticed it. Leadership will fund one quarter of your time. Design the incident-response plan you would write: the roles and who fills them in a team this small, how an incident is declared and by whom, the decision authority to take production down, the communication paths to leadership, legal and customers, and how you would rehearse and revise it. Explain what you deliberately leave out of version one and why.
You join a 25-person product company as its first security engineer. There is no incident-response plan: alerts land in a shared inbox, everyone has production access, and the last outage was handled by whoever noticed it. Leadership will fund one quarter of your time. Design the incident-response plan you would write: the roles and who fills them in a team this small, how an incident is declared and by whom, the decision authority to take production down, the communication paths to leadership, legal and customers, and how you would rehearse and revise it. Explain what you deliberately leave out of version one and why.
Name one incident commander per rotation, separate from the hands-on responder, with explicit authority to take production down. Define one declaration channel and a severity scale deciding who is woken. Write short runbooks for the two likeliest scenarios, rehearse and revise them.
Common mistakes
- ✗Leaving decision authority undefined, so nobody dares stop production
- ✗Writing an exhaustive playbook set nobody reads instead of two usable runbooks
- ✗Treating the plan as finished at publication and never rehearsing it
Follow-up questions
- →How do you keep the commander role viable when the on-call pool is three people?
- →What changes in the plan when the incident originates at a third-party vendor?
