NIST SP 800-61 Incident Response

What it is

NIST SP 800-61 is a guide to handling computer security incidents, and its four phase process is the model the exam uses.

NIST has also published a newer revision that organises the work differently, but the four phase names below are the ones the exam outline lists.

An incident response plan sets out how the organisation prepares for, finds, handles and learns from incidents. The phases give the team a common order of work and a common language.

Questions ask you to name the phase of a described action, to list what a plan contains, and to apply the process to a short story.

How it works

The phases form a cycle, and lessons from the last phase improve the first.

Elements of an incident response plan

A plan should be approved by senior management, and it typically covers:

• The mission of incident response
• Strategies and goals for how the organisation will respond
• The organisational approach to incident response
• How the team communicates inside and outside the organisation
• Metrics to measure the response capability
• A roadmap for maturing the capability over time
• How the programme fits into the wider organisation

The related policy states management commitment, purpose, scope and the definition of an incident. It also sets roles and authority, severity ratings for incidents, and how incidents are reported.

Phase 1: Preparation

Preparation happens before any incident. It builds the capability.

• Write the policy and plan, and form the response team
• Prepare tools, such as analysis workstations, forensic software and a secure place to store evidence
• Prepare contact lists, including management, legal and external parties
• Train staff and run exercises
• Secure the systems with patching, logging and monitoring, so that fewer incidents occur

Phase 2: Detection and analysis

This phase finds out that something has happened and what it is.

• Collect precursors, which are signs that an incident may happen, and indicators, which are signs that one has happened or is happening
• Use alerts, logs, user reports and threat intelligence
• Validate the alert to rule out a false positive
• Scope the incident to see which systems and data are affected
• Prioritise by impact and document everything with times and actions
• Notify the right people

Common sources of incidents are grouped as attack vectors, such as removable media, web, email, impersonation, improper use by staff, and loss or theft of equipment.

Phase 3: Containment, eradication and recovery

This phase stops the harm and returns to normal operation.

Before containing, the team decides on a strategy. It considers the damage, the need to preserve evidence, the effect on services and how long the measure will last. Evidence should be collected before a system is wiped.

Phase 4: Post incident activity

After the incident, the team holds a lessons learned meeting. It asks what happened, how well the team and the plan worked, what was missed, and what should change.

The outputs include a report, updates to the plan and controls, and data for metrics. Evidence is kept according to a retention policy. This phase feeds back into preparation.

Applying the process to an event

A user reports a strange email, and the mail logs show that several staff received it. The steps follow the phases.

1. The report and logs are detection and analysis. The team confirms the email is malicious and finds which mailboxes were hit.
2. Blocking the sender and isolating a host that clicked is containment.
3. Removing the malware and resetting passwords is eradication.
4. Restoring the host and watching it is recovery.
5. The review meeting and the update to training is post incident activity.