A cybersecurity Incident Response Plan (CSIRP) is the guiding light that grounds you during the emotional hurricane that follows a cyberattack. A CSIRP helps security teams minimize the impact of active cyber threats and outline mitigation strategies to prevent the same types of incidents from happening again.
But as the complexity of cyberattacks increases, so too should the strategies that prevent them. Unfortunately, many businesses are relying upon outdated Incident Response Plans that are incapable of addressing today’s advanced cyberattack tactics.
To increase your chances of surviving your next cybersecurity incident, this post outlines the process of creating a cybersecurity Incident Response Plan, based on the suggestion of two leading incident response authorities - NIST and the SANS Institute.
What’s the Difference Between a Cybersecurity Incident Response Plan, a Disaster Recovery Plan, and a Business Continuity Plan?
A cybersecurity Incident Response Plan helps security teams address active cyber incidents. A business continuity plan keeps business operations running during any disruption. This could include any incident involving:
- Finance
- People
- Compliance
- Cybersecurity
- Natural disasters
Disaster recovery plans outline a pathway back to normal operations following a major incident. These incidents are not limited to cyberattacks and can include any of the events in the list above.
Some incidents can be completely addressed with just an Incident Response Plan. Others require a concerted effort between multiple.
An example of a cyber incident requiring just an Incident Response Plan is a phishing email that team members did not respond to. Since there’s no threat of a malware injection or security breach, there’s no risk of business interruption; so there’s no need to appeal to response plans designed to reverse business interruptions.
That said, IRPs also outline incident response procedures for cyber threats leading to sensitive data compromise. This playbook is threaded through all three response plans to help incident response team members understand how to address breaches of increasing severity.
Because Ransomware attacks are specifically designed to disrupt business operations, these events will require more than just an IRP. An IRP will help responders isolate affected systems and prevent further damage. A Business Continuity Plan will help get the business back up and running to meet its minimal SLA expectations, and a disaster recovery plan will help the business return to its original operational state before the attack.
Learn more about Ransomware Attacks.
Here’s a brief breakdown of each response plan to further highlight their differences:
Incident Response Plans:
- Outline an escalation criteria for different cyber threats.
- Map potential information security impacts to relevant industry standards and regulations.
- Outline remediation procedures to maintain compliance with industry standards and regulations.
- Outline security response roles and responsibilities across all departments.
- Outline communication plans to keep stakeholders informed during incident handling processes.
- Outline communication plans for informing security breach victims when their Personally Identifiable Information (PII) is compromised.
- Outline communication plans for informing the relevant authorities/regulatory bodies about the security breach within the regulated time frame. This can vary depending on which jurisdiction you operate in and who is impacted.
- Defines the roles and responsibilities in each incident response process.
- Included measurement strategies for testing the effectiveness of remediation responses.
- Include the best communication tool and up-to-date contact information for the security response team.
Business Continuity Plans:
- Identify the critical business functions and what their continuity and recovery plan is.
- Support the availability of critical business operations.
- Outline Business Impact Analysis (BIA) for determining appropriate remediation responses
- Outline an action plan for returning to normalcy.
- Aim to minimize interruption to daily tasks.
- Aim to rapidly return services to customers and users.
- Outline people safety procedures.
- List local authority contact information.
- Include relevant communication templates.
Learn How to Create a Business Continuity Plan.
Disaster Recovery Plans:
- Outline the implementation and activation of data backup systems.
- Outline a regular audit schedule for testing the integrity of these data backup systems.
- Determine whether there will be any down time and impacts on SLAs for customers.
- Outline what type of disaster recovery setup is required - hot, warm or cold recovery site.
There are obvious overlaps between the processes of each response strategy because each response plan maps to the same overarching security objective - minimizing the impact of all security risks.
The level of acceptable risk or risk tolerance that governs each of these plans is outlined in an organization’s Enterprise Risk Management Statement.
Is a Cybersecurity Incident Response Plan Mandatory?
All 50 states of the United States have breach notification laws requiring private businesses and, in some cases, government entities to notify victims of security breaches when their personally identifiable information is compromised.
For a list of security breach laws that apply to each US state, see this post by the National Conference of State Legislatures.
A cybersecurity Incident Response plan should outline the notification protocol for such events, making the document a critical necessity for complying with US notification laws.
An incident response plan is also a requirement for certain cybersecurity regulations, including:
- HIPAA - Security Rule §164.308(a)(6)(i).
- Payment Card Industry (PCI) - Rule 12.10.
- New York Department of Financial Services (NYDFS) Cybersecurity Regulation (23 NYCRR 50) - Section 500.16.
- Massachusetts 201 CMR - Section 17.03(2)(j).
- Federal Trade Commission 16 CFR - §314.4(h).
- Gramm-Leach-Bliley Act - § 314.4(h).
The combination of US breach notification laws and the incident response plan expectations within popular regulations means that most US businesses require a cybersecurity Incident Response Plan.
The 6 Phases of a Cybersecurity Incident Response Plan
The Cybersecurity Incident Response framework below is an amalgamation of the recommended incident response frameworks defined in the NIST Computer Security Incident Handling Guide and the SANS Institute. The combination of the two draws upon the benefits of each framework to create the most effective incident response design.
The SANS Institute divides a Cybersecurity Incident Response Plan into 6 phases:
- Preparation
- Identification
- Containment
- Eradication
- Recovery
- Lessons Learned
The NIST Cybersecurity Incident Response Plan is similar but with slightly different wording.
- Preparation
- Detection and Analysis
- Containment
- Eradication
- Recovery
- Post-Incident Activity
For simplicity, this guide will follow the same 6 phase naming convention as the framework outlined by the SANS Institute, with the insights of both the SANS and NIST CSIRP frameworks combined in each phase.
It’s important to approach your CSIRP as a lifecycle by following each phase of incident response in its correct sequence. Not only because each step builds upon the work completed in the last, but also because the process will likely circle back to the preparation phase as new threat intelligence is discovered.
Mini cycles will also often occur between the containment, eradication, recovery, and identification phases to confirm the successful remediation of each discovered threat - for example, to confirm the restoration of compromised resources as response teams burrow deeper into an infected network following a ransomware attack.
Phase 1 - Preparation
The preparation phase establishes the architecture of your CSIRP, shaping all of the components of each incident response process. The following tasks should be completed in the preparation phase:
1.1 Create Security Policies
Security policies should outline your security hygiene standards. This could include behavioral controls - such as prohibiting social media access on corporate devices, and the enforcement of specific security tools - such as Multi-Factor Authentication for all corporate login sessions. Security policies should also make any activity monitoring security tools clear to all employees - such as using keyloggers for detecting insider threats.
You should create security policies at an organizational level - within your risk appetite statement and across each department.
While establishing security policies, you might discover overlooked security issues adversely impacting your security posture. For example, you might find that some departments fail to encrypt sensitive data in motion. These security risks and potential incidents should be documented so that they can be addressed in the response strategy task following this step.
All remaining potential security events and vulnerabilities across all your third-party service providers should be discovered with risk assessments and security questionnaires.
1.2 Create a Response Strategy
Create response strategies for all risks discovered from security policies and third-party risk assessments.
To establish an efficient foundation for your entire CSIRP, the remediation processes in each response strategy should prioritize risk with the highest potential impact on your security posture. This is achieved by comparing all risks to your defined risk appetite, organizing them by severity level, and then strategizing a remediation protocol based on this risk hierarchy.
Learn how to define a risk appetite for your Third-Party Risk Management program.
To further improve the efficiency of your response strategy design, map your third-party vendors to their associated risks in this hierarchy and use the resulting risk distribution to tier your vendors by security criticality. This will allow you to focus your response efforts on the vendors with the most significant potential impact on your security posture.
Learn more about vendor tiering.
Any residual risks exceeding your risk tolerance threshold should be compressed to acceptable levels with appropriate security controls.
1.3 Define Incident Communication Streams
Define a communication plan for delivering cyber incident information to stakeholders, senior management, affected parties, and law enforcement entities when necessary. This plan should include contact information for all incident response team members within and outside your organization. An efficient communication plan will help you respond to cyber incidents faster, which could significantly reduce the damage costs of data breaches.
For an overview of breach notification best practices, refer to this breach incident response guide by DLA Piper.
It’s important to encrypt cyber incident communication streams between internal team members. This is an essential requirement for Federal agencies that must use a FIPS-validated encryption algorithm.
1.4 Establish a Cyber Incident Documenting System
Each incident response team member should document their actions in an Incident Handlers Journal outlining the following:
- Who responded to the incident?
- What was affected?
- Where did the incident occur?
- Why was this action taken?
- How did this action help?
The information in this journal will help response teams evaluate their efforts in the final stage of the cybersecurity Incident Response Plan and inform the creation of response documentation for future related incidents.
Documenting response efforts is also a great method for gathering evidence should the cyber event develop into a lawsuit.
The intelligence from incident documentation will help your response team refine and optimize its processes for future similar attacks.
1.5 Fill Your Incident Response ToolBox
You need a set of incident response tools on hand and ready to use in a cyber event. If you don’t have any incident response solutions, prioritize their onboarding. Having the right solution on hand could be the difference between a mitigated breach attempt and sensitive data loss.
Here are some recommended Incident Response solutions:
- Vendor Risk - Helps you secure your third-party attack surface to prevent third-party breaches
1.6 Incident Response Training
A real cyber incident should never be the first time your incident response teams address a given cyber threat. The goal of the entire preparation phase of the Cybersecurity Incident Response lifecycle is to ensure your teams are equipped and confident to contend with all foreseeable cyber threats.
Whenever a new cyber threat is discovered, either from a zero-day notification or following a cyberattack post-mortem, security teams should revisit the preparation phase and document the threat in an incident response strategy that’s rehearsed in a simulated environment.
Drills should occur regularly (at least annually) to ensure each incident response member understands their specific duties during each incident.
1.7 Access Control
During a cyber event, access controls should be manipulated to contain the threat as quickly as possible. This process usually involves rapidly removing account access to prevent privilege escalation.
It’s also important to ensure that response teams have the access levels required to address a given threat successfully. Some threat scenarios may require a temporary access level elevation for specific response staff.
Learn more about access control.
After successfully identifying a cyber event and evaluating its potential impact, the cybersecurity Incident Response team can progress to Phase 2.
Preparation Phase Checklist
The following checklist will help you address the critical requirements of the Preparation phase.
🔲 All incident response team members are aware of all organizational security policies.
🔲 Implement threat awareness training.
🔲 Implement threat response drills
🔲 All incident response team members know who to contact during a cyber incident.
🔲 Incident Response Journals are updated with the latest foreseeable cyber threats.
🔲 All incident response team members have access to incident response journals.
🔲 Responses for all foreseeable cyber incidents have been rehearsed in response drills.
🔲 Metrics for evaluating the readiness of response teams have been established.
Phase 2 - Identification
During the identification phase, security teams determine whether an incident response plan should be activated. This decision is made by carefully analyzing error messages, log files, firewalls, and intrusion detection systems to identify critical deviations from normal process boundaries.
When suspicious activity is detected, the relevant incident response team members should be alerted as quickly as possible to allow sufficient time for appropriate response strategies to be activated. This is why efficient communication streams are paramount to a successful incident response plan.
Ensure your response teams have already started documenting their response efforts in an Incident Handlers Journal (see section 1.4 of the Preparation phase above).
Potential threat identification is the responsibility of all employees in your organization, not just your security staff. This expectation should be clearly outlined in security policies and reiterated in regular security awareness training sessions.
An example of the identification phase in action is a sales representative contacting the security department, reporting that their computer has significantly slowed down after opening an email attachment.
Notice that in this scenario, response teams didn’t need to commence their efforts at the Preparation phase. Because a cyber threat has already been confirmed, security teams should rapidly progress to the Containment phase with the support of relevant response strategy documentation created in the Preparation phase.
.png)
If the identified cyber threat was unexpected, such as a zero-day exploitation, security teams would need to outline a potential remediation strategy in the Preparation phase before progressing to the Containment phase.
Identification Phase Checklist
The following checklist will help you address the critical requirements of the Identification phase:
🔲 Who identified the incident first?
🔲 Who reported the cyber incident?
🔲 Which device/network segment did the cyber incident occur in?
🔲 How was the cyber incident discovered?
🔲 What is the likely degree of impact?
🔲 Which critical systems are likely to be impacted?
🔲 Has the root cause of the incident been identified and located? If so, where, when, and what are they?
Phase 3 - Containment
The primary objective of this phase is to isolate the cyber incident and prevent further damage to surrounding systems. Forensic operations must immediately follow containment with a comprehensive report of findings filed to shareholders, board members, regulators, and your cyber insurance entity.
Do not modify the threat environment in any way before forensics is complete, otherwise you may forfeit your insurance claim.
The containment process consists of three steps.
Step 1 - Short-Term Containment
The goal of short-term containment is simple - to prevent further damage to your network and do it quickly, even if it impedes the operation of essential business processes.
Though you may have a detailed response strategy in place for the specific threat you’ve fallen victim to, at this point of a cyberattack, you don’t have the luxury of unraveling your planned response strategy. Always fully contain a cyber threat before activating its response strategy.
The potential for complete system recovery is highest when cyberattack damages are minimal.
Some examples of short-term containment strategies are:
- Disconnecting infected devices from a network.
- Re-routing network traffic away from compromised assets and towards backup systems.
- Isolating an infected segment of a network.
- Shutting down routers to infected networks.
A short-term containment strategy could be as simple as disconnecting an infected device from your network or isolating an infected segment of a network.
Some network segmentation best practices are outlined in this Ransomware Guide by the Cybersecurity and Infrastructure Security Agency (CISA).
Step 2 - Perform forensics
Immediately perform a forensic analysis. This can be done with specialized threat intelligence software, such as Forensic Tool Kit (FTK). Forensic analysts aim to capture the pure state of the compromised environment at the time of the cyberattack.
Some cyber insurers expect to be immediately notified about a cyber incident as soon as a malicious event is confirmed.
Step 3 - System Backup
After successfully isolating the cyber threat, a forensic image of the infected system (also known as system backup) must be taken to gather incriminating evidence should the event develop into a lawsuit. Forensic analysis is performed with specialized threat intelligence software, such as Forensic Tool Kit (FTK). Forensic analysts aim to capture the pure state of the compromised system at the time of the cyberattack.
Step 4 - Long-Term Containment
This is a more strategic containment solution to replace the quick-fix exercised in step one. This step aims to resume business continuity by fixing affected systems - either by installing security patches, removing backdoors, or rerouting network traffic to clean backup systems.
UpGuard can detect unpatched security vulnerabilities placing you and your vendors at a heightened risk of suffering a data breach. Click here to learn more.
After all compromised systems and devices have been successfully isolated, you can progress to the next phase.
Containment Phase Checklist
The following checklist will help you address the critical requirements of the Containment phase.
Short-Term Containment Checklist
🔲 Can the cyber incident be isolated?
🔲 Have all compromised systems and devices been isolated?
🔲 Are all comprised system owners aware of the incident?
🔲 Work with system owners and security managers to determine necessary further action.
System Backup Checklist
🔲 Have forensic backups of comprised system been created?
🔲 Are all forensic backups stored securely.
🔲 Have response team members been documenting their efforts for forensic purposes?
Long-Term Backup Checklist
🔲 Has all malware been removed from infected systems?
🔲 Have exploited vulnerabilities been patched?
🔲 Have all compromised systems been hardened?
🔲 Have business operations returned to normal levels?
Phase 4 - Eradication
Response teams will naturally commence removing the cyber threat while isolating infected systems in the Containment phase. This effort is continued to completion in the Eradication phase.
Eradication efforts could involve:
- Disabling infected systems to harden the network against ongoing cyberattacks.
- Scanning infected systems for traces of malware and unpatched vulnerabilities.
- Ensuring the vulnerabilities that caused the breach are addressed in sanitary backups of compromised systems
Response teams should refer to your defined risk appetite outlined in your risk appetite statement to determine the appropriate degree of security controls necessary to compress residual risks down to acceptable levels. The documentation response team members have been completing up until this phase will support this effort by indicating the potential impact of the cyber incident.
Eradication Phase Checklist
The following checklist will help you address the critical requirements of the Eradication phase:
🔲 Can compromised assets be hardened against similar cyber attacks?
🔲 Have comprised assets been completely sanitized?
🔲 Have response teams been documenting their response efforts?
🔲 Have all the vulnerabilities that caused the cyber incident been addressed?
Phase 5 - Recovery
The objective of the recovery stage is to return systems to their pre-compromised state. This process begins by replacing targeted environments that have passed through the Eradication phase with sanitary backups.
Remember, these sanitary backups likely contain the same vulnerabilities that were exploited in the original cyber attack, so that need to be addressed with appropriate security patches and remediation efforts.
Before reconnecting recovered systems to the internet, monitor for abnormal log activity that could be indicative of an enduring malware infection or the presence of an Advanced Persistent Threat (APT).
Recovery Phase Checklist
The following checklist will help you address the critical requirements of the Eradication phase:
🔲 Have compromised systems been replaced with sanitary backups?
🔲 Have the vulnerabilities that caused the breach been addressed in restored systems?
🔲 Have restored systems been monitored for suspicious activity?
Phase 6 - Lessons Learned
At this phase, response teams should complete the incident documentation they have been constructing during the entire response cycle. Once completed, this documentation should clearly outline the entire incident response sequence and be easily understood by stakeholders
outside of the incident response team.
No more than two weeks following a cyber event, response teams and stakeholders should convene to discuss the event, how it was handled, and how response efforts could have been improved.
Here’s an example of an evaluation framework for a Lessons Learned meeting:
- When was the cyber incident first detected?
- Who detected the cyber incident?
- Who reported the cyber incident?
- Who was the cyber incident reported to?
- How was the cyber incident contained?
- How were the compromised systems sanitized?
- What steps were taken to measure the success of eradication efforts?
- What processes were involved in the recovery phase?
- What areas were the response teams most effective in?
- How can response efforts be improved for future similar cyber threats?
After an optimized response process for this cyber event has been confirmed by all team members, it should be outlined in a response strategy for future similar events by cycling back to the Preparation phase.
Lessons Learned Phase Checklist
The following checklist will help you address the critical requirements of the Lessons Learned phase:
🔲 Has the entire incident response report been reviewed by all meeting members?
🔲 Have areas of improvement been identified?
🔲 Has an optimized response process been documented based on the discussed areas of improvement?
🔲 Was the optimized response document used to update/create a response strategy for similar cyber events in the future?
Free Incident Response Plan Examples
Here’s a list of cybersecurity Incident Response Plans and related documentation to inspire the structure of your own Incident Response Plan:
