Lesson 3 of 15 · 7 min read
Incident Handling: Declare, Contain, Scope, Recover, Learn
In this lesson
TL;DR: Declare against written criteria; it is better to declare and downgrade. Put an incident commander in charge. Contain with the least destructive action that stops harm (isolate a host, revoke sessions), after capturing what is volatile. Scope beyond the first host: identities, cloud accounts, other machines with the same indicators. Eradicate persistence and recover from trusted states, rebuilding rather than cleaning when code ran. Learn blamelessly, with actions that change systems and are tracked. NIST SP 800-61r3 places all this inside the CSF 2.0 functions.
Before you read
Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.
1During an account compromise, the responder resets the user's password first. What may the attacker still have?
Roles and declaration
An incident is declared when written criteria are met (confirmed malicious execution, account takeover, regulated data exposure, unauthorised production change). Declaring starts obligations: a commander who coordinates and decides, a scribe who records, technical leads, and links to legal, communications and leadership. Severity levels set response speed and who is involved.
The handling sequence
Protecting: A clean, trusted environment after the incident
- 1
1 · Preserve volatile evidence
memory, live state, snapshots
- Stops: Evidence destroyed by rebooting or reimaging
- 2
2 · Contain early
isolate, revoke, block
- Stops: Attacker keeps moving while you investigate
- 3
3 · Scope widely
indicators, identities, cloud
- Stops: Other hosts and accounts missed
- 4
4 · Rebuild from trusted state
rotate credentials
- Stops: Persistence survives cleanup
- 5
5 · Blameless review
tracked system changes
- Stops: Same weakness exploited again
- Contain. EDR network isolation keeps the investigation channel while cutting the attacker off; revoke sessions and tokens; disable compromised accounts; block indicators; in cloud, quarantine security groups and session revocation for roles.
- Preserve. Order of volatility: memory and live state, then disk snapshots, then logs. Record every action (chain of custody).
- Scope. Search for the same indicators and behaviours across hosts, check the identities involved (sign-ins, tokens, consents), and query cloud audit logs for the credentials used, in all regions.
- Eradicate and recover. Remove persistence; reimage hosts where code ran; rotate secrets the attacker could reach; restore from backups predating compromise; rebuild identity infrastructure first if it was compromised.
- Learn. Timeline from evidence, contributing factors rather than culprits, three to five verifiable actions with owners.
Choosing a containment action
Containment is a trade-off between stopping harm quickly, keeping evidence and not warning the attacker before you are ready. The options are not equivalent.
| Action | Speed | Evidence cost | Tip-off risk | Use when |
|---|---|---|---|---|
| EDR network isolation | Minutes | Low: memory and disk stay intact, investigation channel stays open | Medium | A host is confirmed compromised |
| Revoke sessions and tokens, reset credentials | Minutes | Low | High: the attacker loses access and knows it | Identity compromise, coordinated with host actions |
| Block indicators (domains, IPs, hashes) | Minutes | None | Medium | Known infrastructure, as one layer |
| Quarantine a cloud workload or security group | Minutes | Low if snapshotted first | Medium | Compromised instance or container |
| Power off or wipe | Fast | High: volatile memory is lost | High | Only when harm is ongoing and nothing else stops it |
| Watch and wait | None | None | None | Rarely, with legal and leadership agreement, to scope a sophisticated intruder first |
The usual mistake is acting on one foothold at a time. If the attacker holds three hosts and two accounts, isolating one host warns them and leaves four ways back. Coordinate containment across every known foothold at once, including identities and tokens.
Wipe and rebuild immediately
Malware found on one server
Server reimaged within the hour
memory and disk lost
Attacker returns via a stolen token
Outcome, unsafe: Scope unknown, attacker still in
Evidence of how they got in and what else they took is gone.
Isolate, preserve, contain everywhere at once
EDR isolation, memory captured
Footholds and identities scoped
hosts, tokens, cloud
Coordinated revoke, then rebuild
Outcome, safe: Attacker removed, story known
Rebuild follows evidence, not the other way round.
Fast but blind
Wiping first destroys volatile evidence and leaves other footholds untouched.
Evidence: order of volatility, with time budgets
| Evidence | Lifetime | How it is usually collected |
|---|---|---|
| Memory, running processes, network connections | Until reboot or isolation side effects | EDR live response or a memory capture tool, in the first minutes |
| Disk | Until reimage | Snapshot (cloud) or forensic image (physical) |
| Local logs | Until rotated or cleared | Collected centrally if forwarding exists. Windows Event 1102 means the audit log was cleared, and Microsoft recommends investigating every occurrence |
| Cloud audit logs | Retention-limited | AWS CloudTrail Event history keeps 90 days of management events per Region by default; data events and longer history exist only if a trail or event store was already configured |
The last row is the one that decides many investigations. If nothing recorded S3 data events before the incident, nobody can prove what was read, and the honest answer is to treat the data as exposed.
Identity-plane incidents
Many incidents are now identity incidents first. Signals and steps worth knowing:
- Token theft in cloud identity. Sign-ins from new devices or locations without a matching password or MFA event, refresh-token reuse, new OAuth consents or app registrations. Contain by revoking sessions and refresh tokens, not only resetting the password, which leaves issued tokens valid.
- Kerberos abuse in Active Directory. Service ticket requests (Event 4769) using RC4 are increasingly anomalous now that Windows Server 2025 domain controllers do not issue RC4 ticket-granting tickets and Microsoft has moved RC4 disablement to enforcement. A forged ticket-granting ticket (Golden Ticket) is eradicated only by resetting the krbtgt account twice, because the previous key stays valid; wait for replication and the maximum ticket lifetime (10 hours by default) between resets.
- Domain admin compromise. Treat identity infrastructure as compromised: rebuild trust from a clean administrative tier, reset krbtgt twice, rotate service account secrets, and review delegation and ACL paths. See Windows and Active Directory security.
Where NIST SP 800-61r3 puts this
Revision 3 (April 2025) organises incident response around CSF 2.0: Govern (policy, roles, decision rights), Identify (assets and dependencies, improvement), Protect (controls that reduce incidents), Detect, Respond and Recover. The classic phases still describe handling; the revision makes preparation and improvement part of the same programme.
| Revision 2 phase | Where it sits in Revision 3 (CSF 2.0 functions) |
|---|---|
| Preparation | Govern, Identify and Protect |
| Detection and analysis | Detect |
| Containment, eradication and recovery | Respond and Recover |
| Post-incident activity | Identify (improvement) |
Revision 2 was withdrawn on 3 April 2025, the day Revision 3 was published. CSF 2.0 itself, released in February 2024, added Govern as the sixth function, covering organisational context, risk strategy, roles, policy, oversight and supply chain risk. In interviews, describe the familiar handling sequence and say where it maps, rather than presenting the four phases as current NIST guidance.
Worked example: leaked cloud key
A developer pushes a cloud access key to a public repository. Contain: deactivate the key immediately (it was copied within minutes). Preserve: pull audit logs for the key's activity before and after the leak. Scope: new IAM users, roles or keys created, compute launched in unused regions (miners), data read from storage. Eradicate: remove attacker-created resources and identities; rotate secrets the key could read. Recover: services use a new credential from a secret manager. Learn: push protection for secrets, short-lived credentials via workload identity, alerting on key use from unexpected locations.
The same key, with the clocks
| Time | Handling | External clock |
|---|---|---|
| T+0 | Key found in a public repository | Awareness recorded |
| T+5 min | Key deactivated, not deleted, so activity stays linkable to it | |
| T+15 min | CloudTrail Event history pulled for every Region: 90 days, management events only | |
| T+2 h | Scope: new IAM principals, compute in unused Regions, KMS decrypt calls, any data events if recorded | |
| Within a day | Legal assesses materiality and personal data exposure | GDPR: 72 hours from awareness, where feasible, if EU personal data is involved |
| On a materiality decision | Disclosure drafted | SEC Form 8-K Item 1.05: 4 business days after the company determines the incident is material, not after discovery |
Two points earn credit. The SEC clock starts at the materiality determination, which must itself be made without unreasonable delay, so keep a dated record of when it was assessed. And declaring an incident is an internal operational decision; disclosure is a separate legal one with its own clocks. Merging them, for example by delaying declaration to avoid disclosure, only delays the response.
Key found
T+0, awareness
Deactivate
T+5 min
Pull audit logs
T+15 min, all Regions
Scope
T+2 h
Legal clocks
72 h, 4 business days
Stop the bleeding
Deactivating rather than deleting the key cuts access and keeps its history linkable.
A review that changes something
A blameless review has a structure: a timeline built from evidence rather than memory; contributing factors, technical and organisational, rather than a culprit; and three to five actions, each with an owner, a date and a way to verify it worked. Track time to detect and time to contain across incidents, because the trend says more about the programme than any single incident.
Misconceptions interviewers listen for
- "The NIST model is preparation, detection, containment, post-incident." That is Revision 2, withdrawn in April 2025; Revision 3 maps handling onto CSF 2.0.
- "Wipe the box first." It destroys volatile evidence and leaves other footholds in place.
- "The SEC clock starts at discovery." It starts at the materiality determination.
- "Reset krbtgt once." Twice, spaced by replication and ticket lifetime.
- "Scope the first host." Scope identities, tokens and cloud control planes too.
What if · interview follow-ups
Hold your answer as the constraints change
You are incident commander. EDR has flagged credential theft on a finance workstation, and the stolen account turns out to have domain admin rights. The interviewer pushes on each decision.
Start here
The attacker may still be active. What happens when you isolate the workstation?
One foothold or many?
Expect a reaction. If they hold other hosts or tokens, isolating one warns them and leaves the rest. Scope first as fast as possible, then contain every known foothold together: host isolation, session and token revocation, account disablement and indicator blocks in one coordinated action, while watching for fallback command-and-control.
Carry it forwardContain all known footholds at once, identities included.
Weak answerIsolating the one host and declaring the incident contained.
Constraint changes
What changes because the account is a domain admin?
What can a domain admin forge?
Treat Active Directory as compromised. The attacker could have created accounts, changed delegation or forged Kerberos tickets. Rebuild trust from a clean administrative tier, reset the krbtgt account twice with replication and ticket lifetime between resets, rotate service account secrets, and review delegation and ACL paths before restoring normal admin access.
Carry it forwardDomain admin compromise means rebuilding identity trust, not resetting one password.
Weak answerResetting the admin's password and moving on.
Constraint changes
What if logs were never kept long enough to show how they got in?
What can you honestly claim?
State the evidence gap plainly, assume the wider impact the gap allows, and avoid claims such as "no data was taken" that the evidence cannot support. Make retention and log coverage a tracked action with an owner, since that decision before the incident determined what could be proven.
Carry it forwardReport what evidence can and cannot prove; fix retention as an action.
Weak answerConcluding there was no exfiltration because none was seen.
Constraint changes
Legal suggests waiting before declaring an incident, to avoid disclosure duties. How do you respond?
Declaration versus disclosure.
Declaration is an internal operational trigger that starts the response; disclosure is a separate legal determination with its own clocks, such as the SEC's four business days after a materiality decision and GDPR's 72 hours for personal data breaches. Delaying declaration slows containment without changing the legal analysis, so declare now and keep a dated record of when materiality was assessed.
Carry it forwardDeclare on operational criteria; let legal run disclosure on its own clock.
Weak answerAgreeing to delay the response.
Constraint changes
What if the incident turns out to be an AI agent that acted on injected content?
Same sequence, different evidence.
Run the same sequence. Contain by revoking the agent's tokens and disabling its tools; preserve prompts, retrieved documents, tool calls with arguments and model versions; scope every action taken under the agent's identity; and fix the authority design, such as narrower tools and approvals, rather than only the prompt.
Carry it forwardAI incidents use the same handling with AI-specific evidence and containment.
Weak answerTreating it as a model bug and editing the system prompt.
Now defend it
As the defender, which measurements would show the incident programme is improving?
Time to detect and time to contain across incidents, the share of incidents where scope could be fully evidenced, coverage and retention of key logs, how many review actions were completed and verified on time, and repeat incidents with the same contributing factor.
How this shows up in interviews
Ransomware, miners, compromised mailboxes, domain admin escalations and AI agent incidents all test this sequence. Interviewers listen for containment before cleanup, evidence before changes, scope beyond the obvious, and real follow-through.
Say it in 30 seconds: "I declare against criteria and get a commander in place, capture volatile evidence, then contain with the least destructive action that stops harm: isolate, revoke sessions, block. I scope beyond the first host to identities and cloud accounts, remove persistence and rebuild from trusted states, rotating anything exposed. Then a blameless review with a few tracked system changes. NIST 800-61r3 frames all of it inside CSF 2.0, so preparation and improvement count too."
Check yourself
Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.
1Why is reimaging usually preferred over cleaning a host where attacker code executed?
2In a ransomware recovery, why restore identity infrastructure before business systems?
3When does the SEC Form 8-K Item 1.05 clock start, and how long is it?
4Why must the krbtgt account be reset twice after a Golden Ticket compromise?