Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
Organizations that want to avoid a security breach or attack naturally do everything in their power to avoid it from happening in the first place.
The more proactive and preventative work you do, the higher your chance of avoiding an attack. Whether that’s user training, vulnerability patching, or ongoing maintenance – everything helps.
But even then, you still need to plan for the worst.
You can never completely eliminate the risk of attack. That’s why you need an incident response plan in place, so you can make your response as coordinated and effective as possible.
Here’s everything you need to know about what an incident response plan involves and how you can get started creating one.
What Is an Incident Response Plan – and Why Do You Need One?
An incident response plan is a formal document that outlines the steps an organization should take before, during, and after a security incident.
The goal is to co-ordinate the response as efficiently and securely as possible, so you can minimize its potential impact.
The moments following a suspected attack can be fast-paced, stressful, and chaotic.
The last thing you need in this situation is confusion about who’s doing what, what needs doing, and how best to resolve the situation.
An effective incident response plan is the best way to avoid this.
In its essence, it seeks to clarify:
- The identity and responsibilities of people in the incident response team (IRT)
- Definitions of incidents and solutions for common attacks
- Communications protocols
The goal is for everybody on the incident response team to know who they are, understand their responsibilities, and have the authority to act on them when suspected attacks are identified.
Done right, this should lead to a faster, more efficient, and more effective response.
Commonly Available Incident Response Frameworks
Incident response plans can and do vary from company to company, but they usually follow a fairly established pattern. While it is possible to construct your own from scratch, it’s not necessary.
These documents can be quite detailed, so many organizations choose to adapt existing frameworks for their own purposes.
Though there are differences between these frameworks, they’re all based on the same basic process.
Here are four of the most well-known examples:
1. NIST: National Institute of Standards and Technology
As part of the US Department of Commerce, the NIST incident response process is the most well-known framework. It breaks the response into four key stages:
- Preparation
- Detection and analysis
- Containment, eradication, and recovery
- Post-incident activity
Find the full NIST guide here.
2. International Organization for Standardization
ISO is an independent, non-governmental organization that seeks to build voluntary, international frameworks for situations like incident response.
A similar process is outlined as in the NIST framework, though in this case it forms five phases:
- Planning and preparation
- Detection and reporting
- Assessment and decision
- Response to incidents
- Lessons learned
Find the latest ISO report on incident management here.
3. ISACA: Information Systems Audit and Control Association
Another international organization, ISACA focuses specifically on IT governance. It provides industry-leading certifications and guidance on effective IT policy and security. Its framework also follows five stages:
- Preparation
- Identification
- Detection and analysis
- Containment
- Eradication and recovery
- Post-incident
Find out more about ISACA’s incident response guidance here.
4. SANS Institute: SysAdmin, Audit, Network and Security
The SANS Institute is another organization that specializes in cybersecurity training, certification, and research. Their framework similarly follows six stages:
- Preparation
- Identification
- Containment
- Eradication
- Recovery
- Lessons learned
Read the full SANS guide to incident response here.
Companies will choose different frameworks for different reasons. But if you’re unsure of where to start, checking out the details in these guides can help you understand what you need to do to get your plan in place.
How to Create an Incident Response Plan
A well-crafted incident response plan goes beyond mere preparedness. It equips your team with the essential tools and guidance to respond swiftly and with certainty in high-pressure situations.
Dragos Roșioru, MXDR Team Lead, Heimdal®
By now, you’ll be familiar with the main stages of the response plan and roughly what they need to include.
The frameworks we listed above are a great place to start – but they can’t be of much use unless you know how to adapt them to the specific needs of your organization.
Ideally, you should do this in collaboration with trained security professionals who can tailor the plan carefully to the risks you face and the IT environment you’re protecting.
Here are some of the most important parts of this process:
1. Form an incident response team
The first step is to identify the roles and responsibilities of the incident response team members. This could include a range of roles, such as:
- Incident manager – Leads the IRT and coordinates the overall response
- Tech manager – The subject matter expert who leads the technical strategy
- Communications manager – Manages internal and external comms between employees, customers, stakeholders, and others
This list of incident response roles isn’t exhaustive, and you may choose to adapt it to your specific needs. But this is generally considered a good starting point from which to construct your IRT.
Each member should have a clear understanding of their roles and responsibilities. It should also be clear who is responsible for determining and classifying the breach.
2. Develop playbooks
The goal of this step is to provide the incident response team with ready-made solutions to common security challenges. Examples could include a phishing email being detected, an unauthorized access alert, malware infection, or data breaches.
Of course, this list is never going to be exhaustive, and it’s probably not that helpful to develop detailed policies for every type of security threat imaginable. However the goal should be to create clear instructions for the most likely threats, so the IRT can react quickly and effectively once the suspected incident is detected.
Here is an example of the remediation steps you might choose if, for instance, you receive an alert about unauthorized or suspicious access:
- Investigate the source and scope of the access attempt
- Temporarily disable the affected user account
- Identify the extent of access
- Reset credentials and access controls
The guidance here should be fairly broad. Ultimately, every incident will be subtly different and you don’t want to be so prescriptive that the advice doesn’t relate to the specific situation you’re facing.
3. Create a comms plan
Effective and prompt communication is vital during a security incident. This approach shapes the perception of customers, employees, and stakeholders towards your organization in the aftermath and subsequent months of the incident.
Dragos Roșioru, MXDR Team Lead, Heimdal®
A serious security incident can have a significant impact on your brand reputation. In the direct aftermath of the attack, comms has a huge role to play in managing this situation and reducing that damage to an absolute minimum. This requires fast comms that clearly explain the situation and what you’re doing to resolve it.
Needless to say, getting these written and signed off in the middle of the crisis is a recipe for disaster. That’s why it’s so important to have these comms pre-arranged and signed off so that the IRT can quickly publish. This should include:
- Preparation: Develop pre-prepared responses and notifications for employees and customers to ensure timely and accurate communication during a crisis.
- Communication channels: Establish the channels you’ll use to communicate, including within the IRT, the wider company, and with customers. This might involve multiple channels for different uses, perhaps internal and external. It’s also important to identify what backup channels to use if the main channel has been compromised as part of the security incident.
- Stakeholder policies: Clearly outline how and when to communicate with various stakeholders, including customers, shareholders, regulatory bodies, and suppliers. This ensures that all parties are informed appropriately and in compliance with legal and compliance requirements.
- Law enforcement: You should clearly specify the point at which it becomes necessary to involve law enforcement. Depending on your industry and organization, there will likely be specific legal obligations it’s important to be aware of and include in the incident response plan.
This list is not exhaustive, and it’s helpful to think about the specific relationship you have with customers, employees, vendors, stakeholders, and more before you define the incident response procedures.
4. Test the plan
Any incident response plan needs testing; this is the only way you can get an idea of how well it will actually work in reality. The best way to do this is using simulation or ‘tabletop’ exercises. These are structured, usually verbal discussions where the IRT talks through potential security breaches and the response.
You should aim to identify the most common or likely scenarios for security incidents and talk through the responses for each. It’s inherently hypothetical, of course, but there’s a lot of value in getting the actual people who will be responding to coordinate the plan in advance. The goal here is to identify potential issues, confusion, or instances in which the guidance doesn’t work.
Then you should proactively adjust the guidance, ensuring the overall response is slicker and more efficient when the actual incident occurs.
The Four Stages of an Effective Incident Response Process
As you’ll have inevitably discovered earlier in the article, most common frameworks follow the same basic approach – and only really differ in how many incident response phases they break the process up into.
When constructing your plan, you’ll need to start by defining roles as discussed earlier in this blog. Then, you should create a list of activities and responsibilities, roughly aligning with the 4-6 stages outlined by whichever framework you’re following.
Here is a list of incident response steps you might need to include or prepare for, using the NIST framework as a basis:
1. Preparation
Preparation is everything you do before an incident occurs. In effect, the incident response plan is itself an act of preparation. This is also true for all the proactive work you do to avoid security incidents at all, including:
- Ongoing vulnerability monitoring and remediation
- Staff training
- Creating security best practices, policies, and guidelines
- Installing anti-malware, anti-virus, and other protective software
- Risk assessments
All this is important and helpful in avoiding security incidents. But you also need to prepare for the worst and ensure your IRT can quickly start moving when an attack does occur. There are a number of proactive measures you can take to make the IRT’s life easier when an incident is detected:
- Communications – You should start by clearly listing the stakeholders who will be contacted in an emergency and their contact information. This could include primary and backup contact details, email addresses, public encryption keys, and instructions for verifying each others’ identities.
- Tools – Including laptops, backup devices, blank removable media, portable printers, and tools to gather evidence like cameras, audio recorders, and more.
- Resources – It can also be helpful to compile technical documentation that can be quickly accessible when needed. This could include port lists, network diagrams, lists of critical assets, and more.
In an emergency, every second matters. The information and resources compiled here will give your IRT the best headstart they can have.
2. Detection and analysis
One of the biggest challenges is simply detecting when an incident has occurred. Sometimes, this is easy: If you’ve just had an alert that a sales exec has logged in from Hong Kong, despite them being in the London office yesterday – there’s a pretty good chance something is up. But this isn’t always the case.
The longer it takes to identify a potential incident, the harder it is to reduce its impact. Constant training and monitoring are therefore hugely important. Both the security team and the wider organization should be aware of the warning signs for common threats like external media, web-based attacks, email compromises, and impersonation tactics.
With potentially thousands of IT events per day in an organization, it can be a challenge to spot that one dangerous outlier when it does occur. But tools like a SIEM (security information and event management) are one great way to help here, as they can automatically flag potential risks, using .log data analysis. But ultimately, there should always be a trained professional making the call on whether a security incident might have occurred.
Once detected, the goal then should be to identify the depth of the compromise, its source, and whether it was successful. From there, you can start making proactive decisions about how to solve the issue or reduce the damage.
One key thing to remember is the IRT must investigate and remediate the issue without damaging or removing evidence. If law enforcement becomes involved, this could be a vital part of any investigation. Destroying or altering evidence can also make it difficult or impossible to identify how the attack occurred – which is a vital part of improving your response once the IRT’s work is done.
3. Containment, eradication, and recovery
As you’d expect, this stage involves everything the IRT does to respond to the threat, get affected systems back online, and reduce any damage to the organization. The precise steps to take here will depend on the type of attack and your organization – so it’s impossible to create a prescriptive how-to guide that’ll work in every situation.
That being said, it can be useful to proactively create playbooks for common attacks, so the IRT has the best chance of success when the worst occurs.
For each of the containment, eradication, and recovery phases, there are several steps that your team might take to respond to the threat:
Containment
- Remove damaged systems
- Isolate relevant devices
- Lock down compromised accounts
- Segment networks to reduce spread
- Temporarily disable affected services
Eradication
- Restore systems from backup
- Delete malware
- Disable/remove breached accounts
- Gather relevant evidence
- Root cause analysis to determine the underlying cause of the incident
- Clean infected systems
Recovery
- Remediate vulnerabilities
- Install patches or updates
- Remove or create new passwords for compromised accounts
- Test new functionality/ processes/ systems
Of course, these are just suggestions, and not every solution will work in each situation. That’s why it’s so important that your IRT consists of trained professionals with the skills and experience to quickly diagnose the right solution to the specific problem you’re facing.
4. Post-incident activity
While the immediate crisis may have passed, the lessons learned from a security incident are invaluable. Skipping the post-incident review is like driving without looking in the rearview mirror – you’re doomed to repeat past errors.
Dragos Roșioru, MXDR Team Lead, Heimdal®
After the incident has been resolved, it’s crucial to take the time to understand what happened, how it occurred, and what should be done next time. This is the only way to avoid similar future incidents happening again.
The key thing to remember is, if you were attacked by a particular vector, you are much more likely to be attacked through the same vector in future. After all, if one hacker found a vulnerability – there’s no reason another can’t.
Even if the specific incident has been resolved, it’s important to have strategic conversations about how it could have been avoided.
This is also a great opportunity to critique your incident response planning, as well as your wider security posture and readiness. How effectively did the IRT respond? What information, tools, or other preparation would have made their task easier?
In this stage, you should discuss with all IRT members and stakeholders and find any opportunity you can to improve your posture and the preparedness of your response.
Of course, your framework can go into much more detail than this, and many organizations should tailor the jobs to be done and priorities based on their unique needs and IT setup.
It’s worth pointing out, however, that you should avoid being too prescriptive about the specific solution to the crisis. While it’s helpful to define playbooks for common situations, the IRT needs the flexibility to respond and adapt to the situation in front of them. If the incident response plan makes this more difficult, then it’s failing in its original purpose.
How Can Heimdal Help Your Company?
Choosing an automated updating system like our Heimdal® Patch & Asset Management Software not only conserves valuable time and resources but also ensures your systems remain secure.
Here’s what our software offers:
- Centralized patching for Windows, Linux, macOS, third-party apps, and even proprietary software.
- Compile software and asset records.
- Simplify compliance with in-depth, auto-generated reports (e.g., GDPR, UK PSN, HIPAA, PCI-DSS, NIST).
- Streamline vulnerability and risk assessments.
- Address vulnerabilities, counteract threats, and roll out updates both worldwide or locally, at any moment and from any location.
- Tailor the software to align seamlessly with your organization’s specific needs.
Heimdal® Patch & Asset Management
- Create policies that meet your exact needs;
- Full compliance and CVE/CVSS audit trail;
- Gain extensive vulnerability intelligence;
- And much more than we can fit in here...
Incident Response Planning: It Pays to Prepare for the Worst
While proactive cybersecurity monitoring is the basis of any effective strategy, your defense simply isn’t complete without incident response planning.
Ultimately, a well-crafted incident response plan not only mitigates the damage of security incidents but also enhances the overall resilience of the organization, and helps avoid further future incidents. Though creating the incident response plan can be a challenging process, it will make a world of difference to your incident response team and wider organization if the worst does come to pass.
FAQs
What is an incident response plan?
A technology incident response plan is a set of procedures for responding to security incidents. It defines the roles of the incident response team and outlines steps for handling different security situations. The aim is to efficiently manage incidents to minimize damage and recovery time.
Why is an incident response plan important?
This plan is crucial for quick and effective threat response, minimizing potential damage. It helps in reducing downtime, preventing data loss, and maintaining compliance with legal and regulatory standards. Without it, organizations risk significant operational and reputational damage.
How do you create effective incident response plans?
Create a plan by forming a skilled team, defining roles, and developing response playbooks for common scenarios. Use established frameworks like NIST or ISO as guides. Regularly test and update the plan to ensure it meets your organization’s specific needs and risks.
If you want to keep up to date with everything we post, don’t forget to follow us on LinkedIn, Twitter, Facebook, and Youtube for more cybersecurity news and topics.
Cristian is a Content Editor & Creator at Heimdal®, where he developed a deep understanding of the digital threat landscape. His style resonates with both technical and non-technical readers, proof being in his skill of communicating cybersecurity norms effectively, in an easy-to-understand manner.
