Having an incident response plan is key to minimizing potential damage from a cyberattack.
According to research, the average cost of a data breach is USD 4.35 million. However, companies that regularly update their incident response plans were able to save USD 2.66 million on average.
An incident response plan helps to detect threats faster, contain them more effectively, and isolate infrastructural and reputational damage.
In ANY.RUN, we specialize in malware analysis — however, cybersecurity is a vast field that goes beyond malware research. In this educational article, then, we’ve collected general information about incident response planning: what is it, what goes into it and why do you need it?
We’ll go over:
- What are some of the common components of an incident response plan
- How some industry-standard templates look like and where to find them
Remember that this article is meant to be educational. Incident response is a very complex topic and there is no one-fit-all approach.
What is an incident response plan?
Let’s get started by defining what an incident response plan actually is.
An incident response plan is a systematic approach that outlines the processes to follow when a cybersecurity incident such as a data breach or advanced persistent threat occurs. Implementing this plan ensures that an organization can respond swiftly, reducing potential damage.
Most incident response plans follow 6 stages, defined in standards like NIST’s Special Publication 800-61. These stages form a systematic approach to handling cybersecurity incidents:
- Preparation: developing the plan and team.
- Identification: recognizing the incident.
- Containment: preventing further spread.
- Eradication: removing the threat.
- Recovery: restoring functionality.
- Lessons Learned: analyzing and improving.
The stages are designed to create a loop of learning and adaptation. They help companies learn from past incidents and make the incident response procedure more effective with each iteration.
Common parts of an incident response plans
Most incident response plan documents follow a similar proven structure and share standard components:
- Purpose. The purpose section defines the scope, objectives, and priorities of the incident response plan. It provides a clear understanding of what the plan aims to achieve, aligning it with the organization’s overall cybersecurity strategy.
- Testing and updating. This section outlines the procedures for regularly testing and updating the incident response plan. The cybersecurity landscape is constantly changing, and a plan that’s not regularly tested and updated can quickly become outdated.
- Roles and responsibilities. Detailing the roles and responsibilities is crucial for a coordinated response. This section clearly defines who is responsible for what during an incident, eliminating confusion and ensuring that critical tasks are carried out efficiently.
- Response checklist. A step-by-step guide for handling an incident. It includes specific actions to take at each stage of the response, from initial detection to resolution.
How a plan helps to respond to threats more effectively
An incident response plan enables the security team to follow a proven sequence of effective steps, even under stress.
For example, one of the steps most plans will include is to thoroughly document compromised systems. This is something that’s easy to overlook in the heat of the moment. However, a lack of documentation can lead to failure later when it’s time to contain and eradicate the threat. Forget isolating one infected component opens the door for malware to propagate further into the system.
A plan ensures that nothing crucial is overlooked, and everyone on the team knows their exact responsibilities and what actions they’re expected to take in what order.
In short, an incident response plan:
- Ensures coordination: keeps the whole team aligned.
- Provides clarity: outlines specific responsibilities.
- Guides actions: defines the sequence of steps.
- Prevents oversights: focuses on crucial details, like identification and containment steps.
- Minimizes risk: reduces the chance of further propagation.
6 template examples of incident response plans
If you are looking for a very comprehensive plan, consider these 4 frameworks for incident response:
1. NIST SP 800-61
NIST SP 800-61, revised in 2012 by the U.S. National Institute of Standards and Technology, is a complete guide to incident handling. It emphasizes the coordination between legal and technical aspects, especially in the U.S.
Use if:
- Look into this template if your organization is subject to U.S. federal regulations.
Where to download it:
2. ISO/IEC 27035-2
The ISO/IEC 27035-2 is a globally recognized incident response standard. This paid template focuses on security team formation, policy development, and management through regular reviews and updates.
Use if:
- Consider this template if you are a member of a large organization implementing security policies for the first time
- Use it when standard compliance is important, such as for financial organizations
Where to download it:
3. SANS Incident Response Process
Our own template is partially based on this whitepaper. Developed by SANS Institute, this framework focuses the most on detailing steps to take during an incident — including where to look for clues in different systems.
Use if:
- Legal compliance, policy building, and external communication is less of a focus for your team
- Your team in charge of an incident investigation is at least partially or fully comprised of general IT specialists
Where to download it:
4. CERT Resilience Management Model (CERT-RMM)
Carnegie Mellon University’s CERT-RMM focuses on a more holistic perspective of incident handling, describing components, stages, and parties involved in an incident. This can be beneficial to larger enterprises seeking alignment with overall business strategies. However, the information might be too generalized for teams looking for actionable advice.
Use if:
- You are looking for strategic guidance rather than step-by-step incident handling advice
- You need a description of the phases and components of incident responding
Where to download it:
5. CIS Controls Implementation Guide
The Center for Internet Security (CIS) offers guidance for implementing essential security controls. This framework is centered on best practices for the prevention and detection of cybersecurity threats.
Use if:
- Your organization needs a comprehensive set of controls that go beyond just incident response.
- You are aiming for a broad approach to security, including policy development, prevention, and recovery.
Where to download it:
6. Cloud Security Alliance (CSA) Incident Response Framework
CSA’s Incident Management Guide is designed for organizations utilizing cloud services. It emphasizes the unique considerations, strategies, and protocols necessary for incident handling in a cloud environment.
Use if:
- Your organization relies heavily on cloud-based systems and needs guidance tailored to that environment.
- You need to align your incident response planning with cloud security best practices.
Where to download it:
More useful resources
A plan is usually at the core of an incident response strategy, but there are more useful tools you can add to your toolbox. Here, we’ve collected some of them:
| Preparation | Identification | Containment, eradication, recovery |
|---|---|---|
| Emergency contact directory | ANY.RUN | System restoration snapshots |
| A guide to reach key individuals within and outside the team during a security incident | Utilize it to examine malicious files and connections, execute digital forensics tasks. | Employ these to revert a system to a verified clean state using a trusted backup solution. |
| Log retention guidelines | Threat trackers | File Backups |
| Defines how long data is kept to help security specialists analyze it. | Use tools like the ANY.RUN trends tracker to follow and study current threats. | Keep code backups on a separate server to replace compromised files with clean ones. |
| Communication Plan | Network monitoring tools | Recovery playbooks |
| Detailed plan for internal and external communication during an incident. | Tools to watch network traffic for anything suspicious. | Step-by-step guides to help bring affected systems back to normal. |
| Asset Inventory | Log comparison guidelines | Incident Prioritization Table |
| A complete list of all critical assets to prioritize during an incident. | Checklists that help narrow down data in logs to find any differences that stand out. | A guide to choose immediate or strategic containment based on incident complexity. |
Utilizing a sandbox environment to detect threats
Sandboxes are essential tools during incident response and investigations. They create a controlled virtual space where malware can be made to run. This helps analysts to see how exactly It interacts with the system.
Consider this Redline task we executed in ANY.RUN. The sandbox reveals a lot of useful information right off the bat, but let’s focus on two:
- IOCs
- MITRE ATT&CK Matrix
For example, the IOCs report shows malicious DNS and IP addresses that hosted Redline’s C2 server while running the task. This is the information we can use when searching in network logs.
The attack matrix helps to align suspicious and malicious actions, which were automatically detected by the sandbox, with known techniques and malware families.
For example, we can see that ANY.RUN detected the use of Credentials from the Web Browsers Technique.
Main takeaways
- Having a plan can help you respond to an incident more effectively. Tt minimizes potential damage from cyberattacks and can save an average of USD 2.66 million according to IBM’s research.
- There are must-have components to effective incident response strategies. Most plans follow six stages first defined in NIST’s Special Publication 800-61 — Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned.
- Most plans follow the same framework. They include similar components. Typically, these are Purpose, Testing and Updating, Roles and Responsibilities, and a Response Checklist, each serving a distinct goal.
- There is no one-fit-all plan. We looked at some of the well-known frameworks, including NIST SP 800-61, ISO/IEC 27035-2, SANS Incident Response Process, and CERT Resilience Management Model, each suitable for different organizational needs.
A few words about ANY.RUN
ANY.RUN is a cloud malware sandbox that handles the heavy lifting of malware analysis for SOC and DFIR teams. Every day, 300,000 professionals use our platform to investigate incidents and streamline threat analysis.
Request a demo today and enjoy 14 days of free access to our Enterprise plan.
Jack Zalesskiy
Jack Zalesskiy is a technology writer with five years of experience under his belt. He closely follows malware incidents, data breaches, and the way in which cyber threats manifest in our day-to-day lives.
0 comments