Your Foolproof Incident Response Plan [Templates + Examples]
There are many old sayings that highlight the importance of being proactive—such as “a stitch in time saves nine” or “an ounce of prevention is worth a pound of cure.” In cybersecurity, being prepared is crucial for minimizing the impact of different types of security incidents.
This is where having an incident response plan (IRP) is incredibly important for any organization’s IT department. What is an incident response plan? Why is having one important? How can you create a foolproof incident response plan?
To help you better understand IRPs and how to make them, the team here at Compuquip decided to assemble a quick guide to IRPs:
What is an Incident Response Plan?
An incident response plan is a set of guidelines and instructions designed to help everyone in an organization know how to recognize and react to different types of security incidents. By outlining processes for everyone to follow in response to different security incidents, impacts can be minimized.
The complexity and structure of an IRP can vary depending on what resources the organization making it has and the types of cybersecurity threats the plan is meant to counter. For example, a major international banking organization will likely have a much more complicated and nuanced incident response plan for preventing account fraud and data leaks of personally identifiable information than a B2B company that only operates in a single county.
Ideally, incident response plan tasks should be handled by a dedicated IT security team—experts who understand both the different kinds of cyber threats the organization may face and the tools required to thwart them. However, not every organization can afford to have full-time cybersecurity engineers on staff just to handle security. These organizations may have to either have their existing IT departments moonlight as their incident response team or contract a third-party managed security service provider (MSSP) to provide IRP services.
Types of Security Incidents
There are numerous types of security incidents—far too many to list them all in a comprehensive manner. Plus, new cyber threats are created each day as cybercriminals look for new ways to overcome endpoint security tools, firewalls, and other cybersecurity measures.
Some examples of security incidents that an IRP might have to account for include:
Accidental Data Leaks
One of the most common types of security incidents is the accidental leakage of data to a third party. For example, an employee might mean to send an email report with links or attachments containing privileged information to their manager or coworker, but accidentally put in the wrong email address.
This is a type of malware that infects a target system and encrypts the data on it so it is unusable to the owner. After the encryption is complete, a threatening message is generated demanding a payment in exchange for the encryption key.
When an employee or vendor with access to privileged information intentionally abuses their access, that is known as an “insider threat.” These threats can cause massive harm because of the attacker’s knowledge of your organization, practices, and security measures.
Phishing/Social Engineering Attacks
Rather than breaking your security measures, these attacks target your people and try to trick them into taking some kind of action—such as downloading malware, approving fake invoices, or giving up sensitive information. These attacks frequently involve the use of emails or business-focused communication channels to appear as legitimate requests.
Asynchronous Procedure Calls (APCs)
These threats interrupt a device’s normal processes to prioritize whatever command the attacker wants to run—in a way that is often difficult to detect. This allows attackers to hijack control of a system in a way that most non-IT people wouldn’t even suspect.
Distributed Denial of Service Attacks
These attacks try to overwhelm a system or network’s ability to process requests to prevent legitimate users from being able to access it. There are several ways for attackers to conduct these attacks, from simple brute-force pinging of systems with repeated requests to more insidious methods that leverage flaws in a traffic control device to make it unable to process new requests.
Each of these threats demand a different type of response to resolve them. So, it’s important to ensure that any IRP you build accounts for different types of threats and strategies for restoring normal network function.
The Basic Components of an Incident Response Plan
While incident response plans can vary depending on the organization’s resources and the types of security incidents that need to be countered, there are a few basic things that most IRPs share:
An IRP Budget
Everything costs money—from the time of individual cybersecurity experts to the tools that they use. Any incident response plan needs to have an appropriate budget to acquire and maintain the resources needed to enact it. In fact, there may need to be some extra room in the budget that goes unused to fund a response plan (to pay for things like security team overtime, anti-fraud insurance costs, and other protection measures for customers/clients).
Defined Roles and Responsibilities
As with any business initiative, if an incident response plan is to succeed, it needs to have someone in place who can assume responsibility for the plan as a whole. It also needs to have clear roles and responsibilities for each person involved in the plan so everyone understands what they need to do in case of a security incident like a denial of service attack or a phishing attempt. Without accountability, it is harder to get people to follow an IRP.
A Means of Tracking Security Incident Data
One crucial aspect of most IRPs is making changes after any kind of security incident to prevent it from happening again in the future. This typically means having a way to capture and store information about the event—such as a security information and event management (SIEM) software. Using the forensic data collected from an incident, it is possible to identify how the attack occurred and to close the security gaps that made it possible.
Tools and Strategies for Identifying and Defining Incidents
If a security breach occurs, and nobody realizes it, will the incident response plan make a difference? To ensure that an IRP can be put into practice, organizations need tools and practices in place that will allow people within it to recognize different cyber threats and enact the appropriate version of the response plan.
Variable Scenarios for the IRP
A comprehensive incident response plan will likely need to have several different scenarios to cover all kinds of circumstances. For example, there may need to be planned scenarios for loss of access to specific buildings or rooms used by the organization, loss of access to network infrastructure, the loss of specific technology or devices, and the loss of key personnel. Basically, if IT loses the keys to a heavily-secured server room while Frank the cybersecurity expert is out with the flu, how will the incident response plan be carried out?
Post Incident Recovery Objectives
What are the specific recovery time objectives (RTOs, or how quickly recovery occurs) and recovery point objectives (RPOs, or how much information is preserved) for the incident response plan? Generally speaking, the faster the recovery and the more recent the recovery point, the better. Although, more aggressive RTOs and RPOs are generally more expensive to create than less aggressive ones. Defining these objectives ahead of time helps to set expectations for the plan and allows whoever creates the plan to budget accordingly.
Why Are Incident Response Plans Important?
According to data from a Ponemon study sponsored by IBM, in 2019, the average data breach costs about $3.9 million. The longer a breach goes undetected or unresolved, the higher these costs can climb.
Security incident response plans are crucial for improving speed of response to potential breaches. This helps to minimize the potential impact of a security breach incident by reducing the attacker’s window of opportunity to cause harm. It also helps to preserve an organization’s reputation by avoiding making the news as the latest security breach headline.
The Phases of an Incident Response Plan
Discovering the Attack
The first step in any security incident response strategy is to detect that an attack has happened. This typically relies on the use of SIEM software or other event or behavior tracking solutions. For example, if your organization has a behavior tracking solution that analyzes what each user typically does (which files they access, when they’re supposed to be accessing them, etc.), and a user starts asking for data not related to their job function, it could be flagged as suspicious. This could be an early warning sign of an attack. The faster an attack can be identified, the better.
Containing the Security Breach
After an active security threat is identified, it will need to be contained. The specific containment strategy will depend on the type of security incident being responded to. However, this step of the IRP generally involves cutting off the attacker’s access by isolating whatever systems or assets that were compromised.
Eliminating the Breach
Following the containment step, the threat should be eliminated as soon as possible. While the exact method of elimination will change depending on the threat (for example, some distributed denial of service attacks might be neutralized by blocking the source IPs and updating firewall rules), it is necessary to ensure that the elimination method is thorough.
Post Attack Investigation
Without detailed information about the methodology behind a cyberattack, it is impossible to prevent similar attacks in the future. Using forensic data gathered by SIEM software tools, organizations should investigate the attack methodology to discover the specific security gaps the attacker used. Additionally, the network should be checked for any additional malware or other latent threats which the attacker may have left behind. Special care should be taken to identify which, if any, sensitive data was compromised.
Notifying Any Affected Parties
After identifying which systems, apps, and data may have been compromised by the security incident, it’s important to notify any and all parties who may have been affected by the breach. Although data breach notification laws vary by state (some states give you less time than others), it is generally a good idea to be able to notify all affected parties, and the authorities, as soon as possible. An additional piece of advice is to use multiple communication channels when sending out these data breach notifications. For example, instead of just sending an email (which might get sent to a spam folder), it can help to call customers by phone with an automated message providing some details about the breach and what they need to do to prevent fraud. Some organizations go as far as to offer consumer identity protection services free of charge to customers/clients that may be affected by a breach.
Restoring Any Affected Assets on the Network
This step often runs just before or concurrently with the previous step. Following any kind of security incident, organizations need to restore any compromised assets as soon as possible to ensure business continuity in the face of a breach. This step may be completed more quickly or slowly depending on the organization’s level of preparation for the breach and the nature of the threat. For example, if the devices on your network were infected with ransomware and you had a remote data backup of your critical files as part of a disaster recovery solution, you would be able to recover relatively quickly. If you had an offsite production environment ready to “spin up” as soon as your primary server goes down, then the transition could be made almost seamless.
Preparing for the Next Attack
Naturally, simply recovering to pre-incident conditions isn’t enough. It’s important to take measures to prevent future attacks from succeeding. This is where the data gathered by an SIEM tool becomes important. Using this data, you can identify the method behind the attack and close any security vulnerabilities that the attacker may have exploited. For example, if you had a faulty firewall rule that caused it to accept data packets without performing a deep inspection, then you could change that firewall’s settings to prevent future attacks.
How Can I Build a Foolproof Incident Response Plan?
Aside from checking the above content for key components and phases for incident response plans (as well as a smattering of threats you may need to prepare for), it can help to look at an incident response plan template and use that as a basis for your own response plan.
For example, TechTarget has a fairly comprehensive incident response plan template that provides a way to scope, create contingencies, assign responsibilities, and verify process steps for an incident response plan.
It can also help to ask for advice from your managed security service provider, if you have one. Odds are that your MSSP has helped other companies in your industry to create and manage comprehensive incident response plans that make the best use of their available resources.
MSSPs can also provide other services to help you with your incident response planning, such as:
Security Education, Training, and Awareness (SETA) Programs for Employees
Employees are often the weakest link in any cybersecurity strategy. MSSPs can often provide SETA programs that increase awareness of security issues and help employees understand what is expected of them during a security incident.
Endpoint Security Management
Another key service provided by many MSSPs is the management of specific endpoint security tools—like per-app/device firewalls, antivirus programs, password settings, etc. These help harden individual assets on your network against attack, which can be crucial for slowing attackers down during a security incident.
MSSPs may provide firewall management services to help ensure that your firewall rules are kept up to date so there are no rules conflicts that attackers might be able to leverage.
Forensic Data Analysis
SIEM tools and other event logging systems can produce mountains of data. This can be incredibly hard for IT teams to parse—especially if they don’t have much experience investigating security breaches or in using the SIEM tool in question. Managed SIEM services from an MSSP can greatly simplify things by providing detailed reports that only reflect the most important information pertaining to the breach for your analysis.
Many MSSPs provide services that help organizations identify potential security vulnerabilities and close them—even before an actual incident takes place. These vulnerability management services can help to mitigate risk early, preventing losses later.
Do you need a foolproof plan for responding to cyber threats and security breaches? Reach out to the Compuquip team for help and advice now!