The 5 Key Elements to Include in Your Incident Response Plan

Any organization can become the target of a breach or cyberattack, and when that happens, it can not only mean lost data, but also hits to your reputation, customer trust and ultimately your revenue. This is why it’s critical to have an incident response plan in place. Much like a business continuity plan, an incident response plan outlines a step-by-step process your organization will take to ensure any attacks on your network can be addressed and mitigated as quickly as possible.

So where to start? In this article, we’ll outline the five key elements you need to include in your incident response plan. Plus, we offer a template you can download at the end of this article.

Download today: 8 Questions that Cut Through the Lingo of Cybersecurity Incident Response

Overview

This section of your cybersecurity incident response plan is your opportunity to set the tone and communicate its purpose. For example, your purpose could be to provide guidance and procedures to restore services, systems and/or networks to a pre-breach status. It’s also the place where you will specify when you will put the plan into motion – i.e., you can indicate that you’ll begin taking action in the event of an attack on electronic data stored within networks and/or systems as a direct result of hackers, insider threats and/or other malicious activities.

Scope

In the scope section, you’ll list out all the assets covered in the incident response plan. This is typically all electronic data stored on workstations, servers and any other devices that may fall under the responsibility of the Information Technology department.

Participants

This is a crucial part of the incident response plan. In an emergency, you don’t want to be spending time figuring out who does what. At a minimum, this section should include a cross-functional list of point people from teams including cybersecurity/information security, public relations, executives and other relevant team members from across the business. Make sure you have their cell phone numbers and that each person on the list understands that if they’re contacted, they need to be prepared to act quickly.

Categories of Incidents

Each company should define the priority of their incidents in the incident response plan. A common way to do this is to establish priority levels 1-4, with priority 1 being the most urgent. Make sure you clearly define what falls into each priority category, including common cybersecurity attacks. For example, a successful denial of service attack (DDoS) should always equal a priority 1 incident.

Another thing to keep in mind is that you need to and ensure that the priority categories you’ve put in your incident response plan are in line with the overall company’s categorization of incidents. If a priority 1 ticket is established, it should be a priority 1 ticket across the enterprise, both in meaning and urgency.

Cybersecurity Incident Life Cycle

It’s assumed that all incidents under this plan will be priority 1 incidents. If the incident involves the potential compromise of data, systems and/or networks, and additional requirements need to be met during the incident investigations, then those requirements must be referenced in the plan (I.e., PCI, HIPAA, etc.).

Incident Response Team Composition

For all priority 1 cybersecurity incidents, you should assemble an Incident Response Team. Make sure to identify who is on this team before any incident happens and list them in this section. Regularly revisit this roster to ensure it’s still current and make updates when needed.

At a minimum, identify an Incident Commander to lead the incident, a Forensic and Endpoint Detection and Response (EDR) Analyst to conduct analysis for the incident and lastly (if available), a Project Manager to keep pace of the investigations and be the main coordination point of contact for the Incident Response Team.

Identification

During the identification phase of the incident, establish a chain of custody for every system suspected of having suspicious activity conducted against it before the systems are modified in response to the incident. Avoid significant changes to the file system until you acquire a forensic image. Track each piece of evidence contributing to the incident in an incident management system or ticket.

Containment

Once you’ve confirmed the incident, it needs to be contained to stop or prevent the malicious activities from spreading to other systems and/or networks. Containment occurs within the following phases:

Phase 1: Identify malicious activity. This generally means identifying Indicators of Compromise (IOCs) to identify the spread of the activities.

Phase 2: Tactical remediation. The goal of this phase is to prevent the incident from spreading or causing more damage. If the tactical remediation efforts will impact business operations, then the business must be made aware of and approve action being taken unless prior pre-approved actions have been defined for these situations.

Phase 3: Creation of a repository of forensic images of all systems that were identified during the “Identify” phase. If the system(s) cannot be forensically acquired, then a collection of volatile data must be collected. Analysis of both forensic images and volatile data will produce additional IOCs or artifacts that need to be eradicated.

Phase 4: Bringing back systems in a secure manner. If the system can remain offline, then no action is needed for the system besides a rebuild of the system from a known clean source. If the system needs to be placed back into production, then compensating controls need to be in place before containment actions are performed.

Eradication

During eradication, the goal is to remove any remaining artifacts on impacted systems that were not removed during containment. For example, a piece of benign malware or malware output file should be eradicated. These types of artifacts should be identified during forensic analysis.

Recovery

Once eradication is completed and the team sees no further signs of malicious activity, systems may be brought back online in accordance with business needs.

Lessons Learned

This phase should cover all the lessons learned during the incident and be incorporated into a continuous improvement process. The process is dependent on the business, budget and the risk appetite of the business. Long-term strategic initiatives should be covered in this section as well.
Like what you read? You can download this helpful Incident Response Plan Template, which includes sample runbooks.

At Nuspire, our mission is to make clients fanatically happy through a relentless pursuit of excellence. Let’s talk about how we can work together to provide a new, fresh and inspiring approach to closing cybersecurity gaps.