How to Develop an Effective Incident Response Plan

Quick Definition: An incident response plan is a document that outlines the roles and responsibilities within an organization to effectively and efficiently recover from a security breach.

You’ve probably heard of "stop, drop, and roll" in response to clothing catching on fire. The technological version of stop, drop, and roll are the procedures developed to handle security breaches. These procedures are known as an incident response plan (IRP). 

An incident response plan is crucial to effectively and efficiently react to a security incident and minimize damage. In this article, we'll discuss the components of an incident response plan, why you might need one, and some best practices for implementing and maintaining an effective IRP. 

What is an Incident Response Plan?

Imagine you work as a security analyst for a company, and you’ve detected anomalous activity on the network. Even at first glance, you can tell it’s bad, but do you know what to do? Who to call? That’s the purpose of your organization’s incident response plan. 

This plan acts as a step-by-step guide telling you exactly what actions to take to alert the correct people, confirm your initial analysis, contain and remove the issue, and return your network to its prior, healthy state.

There are six components to an Incident Response Plan:

1. Preparation

2. Detection and Analysis

3. Containment

4. Eradication

5. Recovery

6. Lessons Learned

Let's explore each step in more detail. 

Step 1: Preparation

You can’t have an incident response plan without first developing the plan itself. Preparation includes ensuring everyone knows their roles and is trained to properly carry out their responsibilities when the IRP needs to be implemented. 

Preparation also requires key stakeholders to know how to contact each other during an incident since incidents can often occur outside of normal business hours. Additionally, an asset inventory is critical to an effective response. You need to know what assets are on your network, where they are on the network, and who is responsible for them. Not knowing who to contact to interact with a server can bring IR activities to a screeching halt.

Step 2: Detection and Analysis

In a perfect world, you would never need to get past step one, but there's a good chance you will eventually need to continue to the detection and analysis step. This is where people such as Security Operations Center (SOC) analysts will first detect anomalous behavior on the network.  This could be triggered by any number of events, from multiple failed logins to a massive increase in data via an outbound connection. You will likely detect these events using a SIEM, or Security Information and Event Management tool, such as Splunk or Elastic Stack. 

After initial detection, you need to confirm whether the activity is malicious. This is where you will attempt to gather information to answer questions such as:

• When did the incident start?

• Is it ongoing, or has it ended?

• What’s the source of the compromise?

• What’s the scope of the incident?

Knowing this information will help you in future steps of the Incident Response Plan.

Step 3: Containment

After confirming a security breach, you need to contain the compromise so the attackers cannot cause further harm or compromise any more data than they already have. Actions taken during the containment phase of incident response include quarantining the affected device(s) from the network and collecting logs from all affected devices. Removing compromised devices from the rest of the network helps reduce additional issues by limiting attackers' foothold in the network. 

Containment activities can also include password resets and emergency patching. Even if there’s no reason to suspect a password has been compromised, it’s a good idea to have all accounts involved in the incident reset and verify multi-factor authentication is enforced. 

Step 4: Eradication

Now that the compromise has been contained, it’s time to remove the malware from all affected systems. This should be done while the devices are still quarantined, and successful removal should be confirmed before reintroducing the devices to the network. You may need to reimage the devices entirely,  depending on the type of malware used to compromise your network. 

It’s also crucial to determine the initial attack vector and patch whatever vulnerabilities were exploited throughout the compromise. While your organization should be patching and updating on a regular schedule anyway, you can look to the CISA KEV (Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities) catalog for a list of vulnerabilities that have been actively exploited in reported compromises.

Step 5: Recovery

With the incident contained and the malware removed, it’s time to begin reintroducing devices to your network and get back to business as usual. This process usually involves restoring the impacted devices from a known safe backup, patching the systems before reintroducing them to the network, and monitoring them for a period once they’ve been released from quarantine. 

As we mentioned in the previous section, the recovery phase may also require some or all of the affected devices to be completely reimaged and then restored from a known backup, depending on the type of malware used and the amount of damage caused. 

Step 6: Lessons Learned

With the incident over, the final component of the incident response plan requires that everyone involved in the incident response review every aspect of the incident and work together to determine what parts of the process need improvement. Maybe the initial attack vector was a critical vulnerability that was not patched within the appropriate amount of time per your organization’s security policy. Perhaps a user clicked on a link, falling victim to phishing, and introduced malware to the network. 

In this phase of the IRP, your team should be analyzing logs, network traffic, response times, communication effectiveness, and cross-referencing the IRP with what really happened. In most cases, this after-action review of the incident will highlight at least one area of your security posture or plan that could benefit from change.

The Role of IT Experts in Incident Response

Every incident response plan should enumerate the required roles and their corresponding responsibilities throughout the incident response process. For example, security analysts should be listed as critical to the IR process, with the role including activities such as identifying security breaches, contacting other roles to assist with IR, and gathering information about the breach. 

Similarly, people on the network team should be listed as critical for helping determine the scope of the attack, as well as monitoring any impacted devices as they rejoin the network. 

It’s not just the technical roles that get involved during incident response. If applicable, the legal team may need to get involved to determine what duties the organization has to alert impacted users and shareholders. 

The finance team may need to be informed of any revenue impacts due to downtime or potential ransom payments. Depending on the type of attack and attack vector, even human resources may need to get involved. For example, if the attack stems from a malicious insider, HR would likely begin the process of terminating that user’s employment. 

An incident response plan should define factors that impact which roles are required, and teams should work collaboratively to minimize damage as quickly and efficiently as possible. Since threats are constantly evolving, teams should engage in continuous education to ensure they are ready for anything. 

How to Develop an Effective Incident Response Plan

Just about anything you do in security or networking requires an accurate asset inventory. The first step to creating a good incident response plan is to confirm your existing inventory and assess the risks they face. Some assets may be public-facing, some may be old, and some may be managed by a third party. Regardless, it’s important to understand what they are, where they are, and who manages them. 

The next step in creating a good incident response plan is setting goals for responsiveness. Your IRP should list an ideal timeline of events. For example, let’s say from the moment a security breach is confirmed, we want to have containment complete within one hour, we want to complete the eradication phase within three hours of detection, and we want to be finished recovering within 24 hours of detection. While the numbers themselves may change based on your needs and regulatory compliance, the idea is to set standards so everyone moves quickly and efficiently.

Once you have your goals, define who will help meet them. If it hasn’t been mentioned enough yet, a good incident response plan lists the roles necessary for incident handling. This means a team is formed and made aware of their role throughout the entire process. 

Now, it’s time to get to the gritty details. Who does what, using what tools, and how much time does it take? All this should be in the procedures section of your Incident Response Plan.

What are the Best Practices for Implementing an Incident Response Plan?

The single best thing your organization can do to ensure its IRP is effective is to practice effective communication. Even the best procedures and tools in the industry won’t do much good without effective communication. Think of incident response as a defensive line in football—everyone should know where they need to be and what they need to cover, and they should constantly be keeping up with new tactics and techniques.

The good news is you don't need to reinvent the wheel. Many incident response plan templates are available that comply with different regulatory frameworks. Whether you use a template or create a new IRP, review and update it frequently to reflect changes within your organization and the security landscape.

Finally, it’s important to document as much as possible during incident response. Document everything because even if you think it may not be significant in the moment, it may be useful during the post-incident review or other incident response activities in the future.

Common Pitfalls to Avoid in Incident Response Planning

One of the most difficult obstacles to overcome is a lack of support. If people don’t believe in the benefits of an incident response plan, they won’t want to dedicate time or money to building and maintaining one. One way to overcome this is by quantifying potential damage using a mix of productivity hours and financial loss, such as “if our website were to be unavailable due to a breach, we would need at least X hour to bring it back online, and we would lose X dollars for the duration of the outage.” 

Another issue to be cautious of is a lack of awareness once the IRP is in place. A plan is only useful when it’s executed properly, so everyone involved in the plan must know there is a plan, know their role, and communicate. The plan should also be tested regularly to confirm its effectiveness. 

Finally, design your plan with compliance in mind. Many compliance frameworks require you not only to have a plan but that the plan lists specific requirements such as timelines and training. For example, if your organization needs to follow PCI (payment card industry) compliance, you’ll need to be able to prove certain things, such as the plan is reviewed at least once per year and that there are specific roles available 24/7 to respond to an incident.

Conclusion

An incident response plan is a must-have for any organization. The ability to detect and recover from a security breach is imperative to continued operations. These days it’s a matter of when, not if, something will go wrong. An effective IRP outlines the goals of incident response, the participating roles, and their corresponding responsibilities and is reviewed frequently. To learn more about how to respond to a security breach, check out CBT Nuggets Trainer Bob Salman's Incident Response Online Training.