Security Incident Response
The lifecycle is NIST-shaped
SIR incidents move from a draft/preparation state through Analysis, Containment, Eradication, and Recovery to closure. Exact state labels shift slightly between releases, so understand the order and what each gate implies: containment actions (isolate a host, disable an account, block a hash) usually require approval; closure requires a close code or close notes and, for significant incidents, a completed post-incident review.
Analysts work in the Security Operations/SIR Workspace rather than classic forms. There they record observables, associate affected configuration items, and track response tasks.
Playbooks drive the work. A playbook is a Flow Designer flow triggered by incident creation, a state change, or a manual run. It generates security incident tasks (sn_si_task) and can request approval before a containment action. Process-based playbooks cover common scenarios - phishing, malware, lost device, denial of service.
Traps
- Delete vs close. Security incidents and their tasks are closed or cancelled, never deleted; deletion destroys audit evidence.
- Skipping states. Jumping from Analysis directly to Closed without containment/recovery appears as a distractor; valid answers respect workflow order.
- Task vs incident. A containment action is a task under the incident, not a new incident.
- Assignment. Incidents are routed by assignment rules and response-team records, not by hand-editing the assigned-to field.
Worked example
A phishing report arrives by inbound email and SIR creates an incident in Analysis. The phishing playbook creates tasks to collect headers, detonate the URL, and search mail for other recipients. The analyst adds the sender IP and URL as observables, which TI may match. The incident moves to Containment when mailboxes are purged, Recovery after credential resets, then closes with a resolution code.
Rule of thumb: if the state is changing, something should be recorded - an observable, a task, or an approval.