BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Editor's note: This article was expanded and updated in November 2017.
Given the state of cybersecurity, it's more important than ever to have both an incident response plan and a disaster recovery plan.
An incident response plan template, or IRP template, can help organizations outline instructions that help detect, respond to and limit the effects of cybersecurity incidents. The types of incidents where an incident response plan comes into play include data breaches, denial-of-service attacks, firewall breaches, viruses, malware and insider threats.
These sorts of incidents aren't true disasters, but they could turn into one if they're not responded to quickly and handled properly. Such incidents are often the first step in detecting a disaster. When an out-of-normal condition occurs, it must be acknowledged as fast as possible, assessed as to its nature and severity, and responded to in an appropriate way that limits the effects on the organization and ends any threat.
Assessing the scope of an incident
When considering whether a situation is an incident or a disaster, a good rule is to assess the severity of the event and the likelihood of it ending quickly. An incident is an event that may be, or may lead to, a business interruption, disruption, loss or crisis.
For example, an incident could be something as simple as a leaky pipe, but if the pipe bursts, the situation can quickly escalate into a disaster. Introduction of a virus into a network would initially be treated as an incident, as the assumption is that it can be addressed quickly with various software tools and security techniques. However, if the virus proves to be a major denial-of-service attack, the incident can quickly become a disaster if the business is disrupted.
What is an incident response plan?
Incident response plans are sometimes called incident management plans or emergency management plans. Either term is acceptable, as long as the plan's composition is consistent with good incident response practices. Security incident response plans are required by various regulatory and certification bodies, such as the PCI DSS.
An IRP establishes the recommended organization, actions and procedures needed to:
- recognize and respond to an incident;
- assess the situation quickly and effectively;
- notify the appropriate individuals and organizations about the incident;
- organize a company's response, including activating a command center;
- escalate the company's response efforts based on the severity of the incident; and
- support the business recovery efforts being made in the aftermath of the incident.
Benefits of having an incident response plan
An IRP ensures an organization spots early signs that an incident or attack is about to happen or is happening. It also helps organizations follow proper protocol to contain a threat and recover from it when detected.
In practice, a well-organized incident response team with a detailed response plan can mitigate the potential impact of unplanned situations. An incident response plan can speed forensic analysis, minimizing the duration of a security incident and shortening recovery time. The overall effect can be to contain operational and financial damage.
Quick response, coupled with well-rehearsed actions, can often save an organization from invoking more complex and costly disaster recovery (DR) and business continuity (BC) plans. In addition to helping the company quickly return to normal, an IRP can minimize negative publicity.
Incident response plans are often activated when a local incident manager, or another suitably trained employee, determines that an incident, or out-of-normal condition, has occurred. Such action typically precedes more detailed activities, such as using disaster recovery and business continuity plans. If we look at a timeline for a disaster, we see that incident management is often the first response and the link to subsequent business recovery actions.
Good business continuity practice, as espoused by organizations like the Business Continuity Institute and DRI International, includes incident response planning as a key part of the overall business continuity management process.
But there will be situations where the severity of an incident is beyond the capabilities of an incident response team. In these scenarios, the incident response team relays the information they know to emergency management teams and first responder organizations to try and resolve the incident. If the situation causes physical damage to a building or severe damage to critical business systems, then the staff should relocate to an alternate location and BC/DR plans should be activated.
Key considerations for incident response planning
Here are some key points to keep in mind when creating an IRP:
- Senior management support is essential. Without senior management support, you won't be able to formulate a good incident management plan and secure a well-trained team to respond to incidents.
- Keep the plan simple. A well organized, step-by-step IRP with relevant information at your fingertips will help you get through most situations.
- Communicate regularly on the incident status. Provide the relevant facts as they are available, disseminate them quickly, follow up regularly, keep relevant parties informed and resolve incorrect information.
- Review and test. Once an incident response plan is complete, it should be reviewed and analyzed to ensure the documented procedures make sense and that the team is equipped to respond according to the plan.
- Be flexible. An IRP should have built-in flexibility to adapt to a variety of situations; this includes who is on the team and access to resources to mitigate the incident.
Components of an incident response plan
An incident response plan should identify and describe the roles and responsibilities of the incident response team members who must keep the plan current, test it regularly and put it into action. The plan should also specify the tools, technologies and physical resources that must be in place to recover damaged systems and compromised, damaged or lost data.
According to the SANS Institute, there are six parts to an incident response plan.
- Preparation. Train users and IT staff to handle potential incidents should they arise.
- Identification. Determine whether an event actually is a security incident.
- Containment. Limit damage from the incident and isolate the affected systems to prevent further damage.
- Eradication. Find the incident's cause and remove affected systems from the production environment.
- Recovery. Allow affected systems back into the production environment and ensure no threat remains.
- Lessons learned. Document the incident and analyze how it happened so staff can learn from it and improve future response efforts.
Key stakeholders in incident response plans
An IRP typically requires the formation of a Computer Security Incident Response Team (CSIRT), which is responsible for maintaining the incident response plan. CSIRT members must be knowledgeable about the plan and ensure that it's regularly tested and approved by management.
The response team should include technical staff with platform and application expertise. There should be infrastructure and networking experts on it, as well as systems administrators and people with a range of security expertise.
On the management side, the team should include an incident coordinator who is adept at getting team members with different perspectives, agendas and goals to work toward common goals. There should also be a team member tasked with handling communication to and from management. This role requires a person skilled at translating technical issues into the language of the business and vice versa.
Various data owners and business process managers throughout the organization should either be part of the CSIRT or be working closely with it and have input into the incident response plan. Representatives from customer-facing parts of the business, such as sales and customer service, must also be part of the CSIRT. And, depending on the company's regulatory and compliance obligations, legal and public relations should also be included.
How to develop an incident response plan
Developing and implementing a cybersecurity incident response plan involves several steps. The order in which an organization completes these steps depends on a number of variables, including its specific cybersecurity vulnerabilities and regulatory compliance needs.
Key sections to include in an incident response plan
- Policy, definition and scope.
- A diagrammatic representation of the process with key information.
- Incident reporting.
- First responders and incident team composition -- names, contact details, roles and responsibilities within the team.
- Incident assessment, including whether forensic evidence gathering is required.
- Incident countermeasures -- server/workstation/network isolation, invoking a disaster recovery plan or business continuity plan, evidence gathering, managing media reports and public relations, involving external parties as necessary, including the police and forensic investigators.
- Identifying corrective actions -- a detailed incident review, project and budgetary plan to implement corrective actions, can include company policy and procedures, training, hardware, software, etc.
- Monitoring corrective actions to the point where the incident team believes that the incident can be closed. A report should then be prepared for file and a summary report prepared for distribution to senior managers and the board.
Source: Peter Wenham, a committee member of the BCS Security Forum strategic panel and director of information assurance consultancy Trusted Management.
Incident response plan template
This incident response plan template is a useful starting point for developing your own incident response plan. Be sure to review it with various internal organizations, such as facilities management, legal, risk management and key operational units.
Also, if possible, have local first responder organizations review the incident response plan. Their suggestions should prove valuable and can increase the success of your incident response plan.
How to test an incident response plan
Testing the processes outlined in an incident response plan template is critical. Businesses shouldn't wait to find out if their IRP works during an actual incident. Incident response plans should be reassessed and validated annually, at a minimum. They should also be revised whenever changes are made to the company's IT infrastructure or its business, regulatory or compliance structure.
Businesses that regularly face attacks may feel they have less need to test their incident response plans. However, defending against one or two types of attacks on a regular basis doesn't ensure an organization is ready for that third or fourth type of attack.
All organizations must run simulations to ensure staff stays up to date and in practice on response processes and protocol. Testing should include a variety of threat scenarios, from ransomware and distributed denial-of-service attacks to inside data theft and system sabotage.
One frequently used approach to testing is discussion-based, tabletop exercises where a group talks through the procedures they would apply and issues that might come up with a specific cybersecurity event. A more in-depth approach involves hands-on operational exercises that put functional processes and procedures in the IRP through their paces. A combination of these two approaches is best.
When going through an incident, whether real or a test run, the response team must take time to compare how the response actually unfolds with what's outlined in the incident response plan to ensure it reflects the reality of an organization's reaction to an incident. Team members should track all discrepancies and problems no matter how small and adjust the plan to reflect what really happens or will happen during an incident response.
Buying incident response tools for your enterprise
How to create a well-built incident response program
Your cloud strategy needs incident response planning