Incident Response

The standard phases

Almost every IR framework (NIST SP 800-61, SANS, your favorite vendor) describes the same loop, with slightly different vocabulary:

1. Prepare. Before anything happens: contacts, playbooks, logging, backups, drills.
2. Detect & analyze. Notice something is wrong; figure out what it is and how serious.
3. Contain. Stop the bleeding without erasing the evidence.
4. Eradicate. Remove the attacker's presence and the root cause.
5. Recover. Bring things back, carefully, and watch for return visits.
6. Learn. Write down what happened, change something so it's less likely next time.

The order isn't arbitrary. Containing before you understand can make things worse; eradicating before you contain just lets the attacker pivot. Recovering before you know what got in invites them back in an hour.

The first thirty minutes

• Don't panic, don't hide it. The early hours decide outcome. Get the right people in the room (virtual is fine).
• Establish facts before theories. Who reported it, what did they actually see, what time?
• Preserve evidence. Snapshot logs, take memory captures of suspected hosts, copy disks. Avoid powering things off if you can help it.
• Contain locally, not globally. Isolate the affected host or account; don't shut down the entire network unless you have to.
• Start a single timeline. Every action, every observation, with timestamps and who did it. Future-you will thank present-you.
• Open a single communication channel for responders only, separate from the channel where everyone is asking what's going on.

Eradication and recovery

Eradication is the technical work: kill processes, remove persistence, rotate secrets the attacker may have seen, patch the entry point. Recovery is restoring service confidently:

• Rebuild from known-good media where you can; don't "clean" suspected systems.
• Restore from backups that pre-date the compromise. Verify them.
• Rotate credentials. Every credential the compromised system held.
• Watch closely for re-entry attempts in the days following.

The post-mortem (this is the prize)

After things are stable, write down what happened. Done well, this is the single most valuable artifact in the whole incident.

Two rules:

• Blameless. The document focuses on systems and conditions, not people. People act reasonably given the systems they're in. If a phish succeeded, the question is "how did our processes let that email get to that user with no checks?", not "why did Alex click?"
• Action items with owners and dates. "We will improve detection" is not an action item. "Owner X will add SIEM alerts on Y by date Z" is.

A short IR plan for small teams

1. A one-page document with: who's on call, how to reach them, where the runbooks live.
2. A list of the systems that matter most and what "known good" looks like for each.
3. An offline copy of credentials and contact info (yes, on paper). The day you need them, your systems may be the things that are down.
4. A printed checklist for the first thirty minutes.
5. An annual tabletop exercise, talk through a scenario together. The first time you read your IR plan should not be during an incident.