When we work with customers, we often discover that they are confused about the terminology and incident response (IR) documentation that they should have within their organization. When managing a cyberattack, we recommend three documents: the incident response policy, the incident response plan, and incident response playbooks. In this article, we cover the purpose of each document along with guidance on the key components for an organization.
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.
At a minimum, the policy should outline the core incident response elements for the organization, including:
Creating an incident response policy holds the organization accountable for making incident response a priority.
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:
Although no one-size-fits-all incident response template exists, the plan should contain the following items:
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.
Incident response playbooks standardize the response to a specific type of incident with procedures that include specific actions 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 nontechnical, such as constructing external communications to customers and distributing the communications.
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:
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.
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.
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, the team collects evidence and maintains 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.
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 endpoint detection and response (EDR) or a virtual local area network (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 data restoration tools and processes.
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.
Incident response plans and playbooks should clearly define all of the individuals and teams that have a stake in the incident response process, even if they are only performing one or two actions. 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:
Experienced a breach or would like assistance in developing incident response documentation? Fortinet has a team of incident response experts available to help deliver critical services before, during, and after a security incident. Reach out to the FortiGuard Incident Response team today for support.
