Why Do We Need an Incident Response Policy?

The incident response policy is the foundational document of any incident response team. It should act as a blueprint for incident response throughout the organization. Like any policy, this document sets the rules and governance around incident response for the organization. Unlike the other IR documents, the policy should be broad and not change much, if at all.

What should an incident response policy contain?

At a minimum, the policy should outline the core incident response elements for the organization, including:

• The purpose of incident response and why it is required
• Why the policy was created
• The scope of the policy (who and what does the policy apply to)
• Who within the organization is responsible for enforcing the policy
• Definitions for incident response and other key terms such as event and incident
• The requirements that must be met by the incident response team and larger organization
• A mandate on the creation of the incident response plan, which should include the key elements required of the plan

Creating an incident response policy holds the organization accountable for making incident response a priority.

What is the Incident Response Plan?

The incident response plan provides guidance on how to respond to various incident types. The Cybersecurity and Infrastructure Security Agency (CISA) defines the incident response plan as “a written document, formally approved by the senior leadership team, that helps your organization before, during, and after a confirmed or suspected security incident.”

The CISA definition includes two components that should not be overlooked:

1. The incident response plan must be approved by senior leadership and should ideally have an executive sponsor. Having leadership approval gives incident responders confidence and acknowledgment that they can take any action as defined by the plan to contain, eradicate, and recover from the incident. Without this approval in place, teams may be hesitant to act or be required to wait for approvals before taking time-sensitive actions, which could result in financial or reputational damage.
2. The incident response plan should cover how to detect, analyze, contain, eradicate, and recover from an incident. The incident response lifecycle has two crucial parts that should not be glossed over preparation and post-incident activities. The incident response plan should define and cover all phases of the incident response lifecycle, including both before and after the incident.

What are the key elements of an incident response plan?

Although no one-size-fits-all incident response template exists, the plan should contain the following items:

• A mission statement
• Goals and objectives
• Scope
• Roles and responsibilities, including primary and out-of-band contact information for the incident response team members
• Communication procedures for both internal and external communications
• Incident severity levels
• Incident types
• Incident definitions (incident, event, data breach)
• Incident response procedures in alignment with organizations’ chosen incident response lifecycle

Readers are encouraged to review NIST 800-61, which is an excellent guide for what should be contained within the incident response plan and also provides guidance on the incident response lifecycle.

The incident response plan is the guidebook to handling incidents. It should be a living document that is updated and tended to regularly. Fortinet recommends a bi-annual review of the plan and a review after each major incident. This timing ensures that any lessons learned from an incident are incorporated and that changes to the organization are considered and implemented into the plan.

What is the Purpose of an Incident Response Playbook?

Incident response playbooks standardize the response to a specific type of incident with procedures that include specific action steps that the organization must take to prepare for, respond to, and recover from specific incident types.

Using the National Institute of Standards and Technology (NIST) incident response framework as an example, an incident response playbook provides detailed guidance on each phase of incident response: preparation, detection and analysis, containment, eradication, recovery, and post-incident activity.

For example, during the analysis phase, the incident response plan may dictate that it is necessary to perform analysis on any file, process, or account suspected of malicious use during the incident. Although the incident response plan provides the general analysis steps that need to occur for any incident type, a ransomware playbook provides the detailed analysis steps of a ransomware incident, such as reviewing the owner of an encrypted file to determine the account used for encryption.

The playbook should define what specific actions need to be taken during the phase of incident response and the team or individual responsible for performing the action. Keep in mind these actions can be both technical, such as restoring the file server from backup to non-technical, such as constructing external communications to customers and distributing the communications.

What are the common scenarios for incident response playbooks?

To determine which playbooks to create, it is best to evaluate the current risks to the organization and develop playbooks around the risks that fall higher on the risk register. Common types of playbooks include:

• Ransomware playbook
• Data breach or data loss playbook
• Malware playbook
• Denial of service playbook
• Insider threat playbook
• Social engineering playbook
• Website compromise playbook
• Zero-day vulnerability playbook

The difference between an incident response plan and playbook in a data breach

To drive home the difference between the incident response plan and a playbook, here’s an example of what should be included in a data breach playbook. When developing a playbook, the organization should follow the incident response lifecycle defined within the incident response plan and the response efforts. This example uses the NIST lifecycle.

Preparation

To respond to a data breach, the organization must first define what constitutes a data breach, including all applicable laws, regulations, and contractual obligations around the data for which the organization is responsible. Organizations should get legal advice about what constitutes a data breach and include that information within the playbook.

Detection and Analysis

Determining whether a data breach has occurred requires that tools and technologies are in place, understood, and monitored by the organization. These solutions may be unique to an incident that involves the loss of data, such as a data loss prevention solution or dark web monitoring. With these items in place, processes can be built into the playbook to detect and respond to a data loss incident.

Once a breach is detected, individuals on the team collect evidence and maintain a proper chain of custody. This effort may need to be outsourced to an external incident response or forensics team. Regardless of whether the investigation is conducted internally or externally, steps should be defined within the playbook as to the analysis that must occur to discover the depth, severity, and root cause of the incident. With an incident involving data loss, another incident is likely to be occurring, such as phishing, malware, or even ransomware. Depending on what the other malicious activity is, it may be necessary to reference additional playbooks.

Containment, Eradication, and Recovery

To define actionable steps for containment, eradication, and recovery, it is important to consider communications during the incident. The type and nature of the data loss may lead to disclosure notifications to various organizations and individuals, such as regulators or even government entities. A data breach playbook should, at a minimum, reference the required communications procedures. Communications and legal teams may both need to be involved during an incident.

During containment and eradication, the organization should use tools and technologies, such as EDR or a VLAN to isolate hosts and eradicate the threat. Regardless of the method, the playbook should define the exact methods and if necessary, link to documentation on how to perform the tasks.

Recovery from a data breach incident often involves data restoration. Keep in mind, that once integrity is lost, it cannot be regained. However, systems and data can still be restored to ensure threats are eradicated. Recovery may include restoration from backup, so the playbook should include information about the data restoration tools and processes.

Post-Incident Activity

Post-incident activity for a data breach can be more intensive than other types of incidents, such as a lost or stolen laptop, because of the regulatory requirements related to the type of data compromised. For example, if customer Personally Identifiable Information (PII) for the state of California is impacted, the organization must ensure all requirements set forth by California’s reporting requirements have been met.

Developing incident response documentation, including playbooks is no small endeavor. However, it can and should be done to help reduce the impact of an incident and guide responders on what needs to be done.

Ensure Incident Response Documents are Complete and Comprehensive

Incident response plans and playbooks should clearly define all the individuals and teams that have a stake in the incident response process, even if they are only performing one or two items. By defining roles and responsibilities and having these individuals become familiar with the documentation through readthroughs and tabletop exercises, team members across the organization know what they need to do and when.

Incident response documentation should contain communication templates with information about the who, what, when, and how:

• Who is going to be drafting and conducting both internal and external communications?
• Who do we need to communicate with (regulators, insurance, customers, partners, vendors)?
• What needs to be communicated?
• When should the communication occur?
• How is communication going to occur, especially if companywide email is unavailable?