Outline the incident response process

Incident response is the most process-driven material on the exam, and the questions reward knowing the order and the purpose of each phase. Almost every wrong answer in this objective is a correct action performed at the wrong time.

Two models, one process

Preparation

Everything you do before an incident, and the phase that determines how the rest goes.

• The IR plan — who decides, who does what, when to escalate, when to declare
• The team — a CSIRT with defined roles, including a designated incident commander
• A communication plan — including out-of-band channels, because if the corporate email is compromised you cannot coordinate a response in it
• Tooling and access — forensic tools, log retention, and the credentials to use them, ready in advance
• Playbooks for the incident types you expect
• Training and tabletop exercises — the rehearsal that finds the gaps while it is still cheap

Detection and analysis

Determining that something happened, what it is, and how bad. Two decisions come out of this phase:

Triage and severity classification decide the response's urgency and who gets woken up. The inputs are the usual ones: what is affected, how critical it is, whether sensitive data is involved, and whether the activity is ongoing.

Check yourself

An analyst confirms malware on one workstation and immediately reimages it. Two weeks later the same activity appears on four other hosts. What was the error?

• Reimaging was the wrong remediation
• The incident was never properly scoped before acting
• The malware sample should have been submitted to a public scanner
• The workstation should have been powered off instead

Containment

Stopping the spread without destroying what you need to understand it.

• Short-term containment — immediate action to stop the bleeding: isolate the host, disable the account, block the C2 address
• Long-term containment — temporary measures that let the business keep running while eradication is prepared
• Isolation vs segmentation — remove the host from the network entirely, or restrict it to a controlled segment where its behaviour can still be observed

Eradication and recovery

Eradication removes the adversary: delete malware, close the vulnerability that was used, remove persistence mechanisms, and reset compromised credentials. The recurring exam point is that eradication is incomplete unless the entry vector is closed — restoring a clean system into the same unpatched condition just invites a second visit.

Recovery returns systems to production, and it is a staged process, not an event:

1. Restore from a known-good source
2. Apply patches and harden before reconnecting
3. Return to production in stages
4. Monitor intensively — the period right after recovery is when a missed persistence mechanism shows itself

Post-incident activity

The phase most often skipped, and the only one that makes the next incident go better.

• Lessons learned meeting — held promptly while memory is fresh, and blameless, because a review that assigns fault produces defensive people and no useful information
• Root cause analysis — the actual origin, not the proximate symptom. "A user clicked a link" is rarely the root cause; "macro execution was not restricted and there was no detection for Office spawning shells" is closer.
• Incident report — timeline, impact, actions taken, and recommendations
• Metrics — dwell time, time to detect, time to contain
• Follow-through — the recommendations become tracked actions with owners, or the exercise was theatre

Check yourself

During a post-incident review, the discussion focuses on which analyst missed the initial alert. What is wrong with this?

• Nothing; accountability is important
• Blame suppresses the information the review exists to surface, and it points at a person rather than the system that let it through
• The review should have been held six months later
• Post-incident reviews should only involve management