An incident response plan is defined as a set of protocols that identify, detect, and address disruptive events such as data breaches. These incidents can be caused by anything, from abrupt hardware failures to human error. This article introduces you to incident response planning, its lifecycle, key steps, and some best practices for 2021.
Table of Contents
- What Is Incident Response in Data Security?
- Incident Response Lifecycle
- Incident Response Process: 10 Key Steps With Examples
- Incident Response Planning: 6 Best Practices for 2021
What Is Incident Response in Data Security?
An incident response plan is a set of protocols that identify, detect, and address disruptive events such as data breaches.
An incident is a situation or an anomaly that may negatively impact the company and customer data, critical assets, and, in turn, business continuity. An incident can be natural (e.g., earthquake-induced damage) or man-made (cyberattacks). Examples of incidents vary from natural fires and security breaches to corporate espionage.
Incident response is a chain of processes designed to be set off when an incident is detected. It is not a preventive measure but details a step-by-step plan on how to react to an incident when all lines of security defense fail.
Incidents can be categorized as:
- Organizational: Incidents confined to a single organization. For example, a building catching fire.
- Public: Universally applicable incidents, such as a pandemic.
- IT-related: Security and infrastructure-related incidents. These affect the company’s systems, network, and data.
Also Read: What Is Disaster Recovery? Definition, Cloud and On-Premise, Benefits and Best Practices
Components of an incident response plan
An incident response plan must outline:
- What constitutes an incident for the company — this is done by evaluating the likelihood of an event happening and the fiscal, legal, and reputational damage it may cause.
- Step-by-step instructions to be followed when each incident occurs.
- A list of personnel to be involved, with their contact details.
- A list of tools to be used for mitigating the attack. These can be USB drives with backups, hard disks to copy drive images, anti-malware software, forensic software, and network tools.
- A communication plan to be used within the organization and with consumers and the general public.
Why do organizations need an incident response plan?
Interpol’s 2020 assessment shows an alarming increase in the number of cyberattacks, with large corporations being targeted more than individuals and SMBs. This is a direct offshoot of the higher number of employees forced to work remotely during the COVID-19 pandemic. While this situation calls for a robust SIEM system in place, it also means that companies need to be prepared with a plan of action if any of these cyberattacks are successful.
An integral part of incident response planning is documentation. Procedures are developed and documented for future use. When an incident has occurred, documentation of the chain of events is maintained side by side while following the incident response plan. The incident response plan is therefore helpful during compliance regulation auditing. For example, GDPR mandates that companies report data security incidents within 72 hours of discovery. As an extension, if the incident were to ever evolve into a violation of civil or criminal law, the same set of documentation can be used as evidence.
That being said, the goal of an ideal incident response plan is to minimize the effect of a threat on the company’s infrastructure, brand, and assets. These threats include distributed denial-of-service (DDoS) attacks, malware, ransomware, phishing, power outages, failed hardware, or simply weak passwords and poorly structured access controls. A 2020 research by Cyentia Institute showed that companies that don’t have a good cyber incident response plan suffered losses that were 2.8 times greater than their counterparts that did have a good incident response plan.
Also Read: Top 8 Disaster Recovery Software Companies
Incident Response Lifecycle
Let’s understand the six stages of an incident response lifecycle.
Incident Response Lifecycle
1. Preparation
This is the only stage of the incident response plan that is executed beforehand. In the preparation stage of the incident response lifecycle, the computer security incident response team (CSIRT) needs to develop policies and a playbook for handling incidents when they arise. At this stage, they sketch communication and execution plan and document all the necessary information to execute the incident response plan.
During this step, possible threats are analyzed and flagged based on the likelihood of occurrence and the amount of damage they may cause. This is done with collective information from the SOC and threat intelligence teams. Not all threats are marked as incidents. Incidents are typically directed at information resources and assets and have a realistic chance of success.
Security risks are audited, and a response plan is created for incidents marked as high risk. An ‘alert’ roster is created, and a communication plan is outlined. Any relevant training that is required is kick-started at this stage.
2. Identification
The identification stage is when an incident is first flagged. The security operations center (SOC) team uses security information and event management (SIEM) tools and checks on logs, error messages, and firewall intrusions to accomplish this. Network monitoring tools and intrusion detection systems are also used. It is essential to flag anomalies based on the classification done during the previous stage. A high number of false positives (flagging an incident that is ultimately not of much consequence) dilutes the incident response plan process.
For example, an indicator of a possible incident may reflect the presence of unfamiliar files in a server. This may not necessarily mean that an incident has been triggered. A definite indicator of attack is the loss of availability of data or a sudden, unaccounted flurry of activity emerging from a dormant server.
This gathering of events that were used to identify and assess the incident from the logs and monitoring tools is known as gathering ‘evidence’. Once the evidence is gathered, the who, what, where, why, and how of the incident is entered into ongoing documentation of the incident. This document is updated at every stage of the lifecycle. It can also be used in a court of law if and when required.
Also Read: 5 Step Guide to Business Continuity Planning
3. Containment
This stage of the incident response lifecycle focuses on containing the incident and minimizing the damage caused. This step aims to recover control of the system. Containment can be divided into three stages:
- Short-term containment: Once an incident has been identified, the first step is to put immediate measures in place that will minimize or prevent further damage. This includes revoking access to the affected server.
- System backup: While it is crucial to roll back all affected systems to prevent further compromise, it is also crucial to take a copy of the system at that point in time. This is known as a ‘forensic image’, and is done for further investigations and serves as evidence.
- Long-term containment: This is the final stage of containment. It aims to ensure that the same incident is not replicated in the near future. All compromised accounts are terminated, any malware or backdoors installed by the attackers are removed, and the systems are scrubbed for recovery. This step flows over into the next stage of an incident response lifecycle, which is eradication.
By the end of this stage, the CSIRT team must be able to tell whether the incident needs to be escalated or if it can just be eradicated. An incident is escalated as a ‘disaster’ if:
- The CSIRT team is unable to contain the incident’s impact.
- Damage created by the incident is too severe for the organization to immediately recover operations.
When this sort of escalation occurs, the disaster recovery plan kicks in.
4. Eradication
At this stage, it is assumed that the source of the attack has been identified, isolated, and contained. All systems are analyzed to check for the extent of the compromise. Vulnerabilities in the system that allowed for the incident to occur are addressed to avoid repetition.
It is also essential to keep monitoring the systems to see how the attackers are reacting to these measures. Security analysts will need to develop anticipatory responses to any further attacks that these measures may have induced.
Also Read: Top 10 Firewall Hardware Devices in 2021
5. Recovery
Over the last few stages, some systems may have been brought down by revoking accesses and stopping services. During this stage, the focus is on bringing back all systems to a working condition, ensuring that the incident has completely been eradicated. All systems are tested.
Necessary security changes, such as installing patches, restoring from backups, and modifying authentication policies, come into effect. Every single step till now must be documented and communicated, as per the incident response plan. By now, it is assumed that the incident has been tackled and all systems are back in place.
6. Learnings
The CSIRT’s job is not complete until it revisits the response and has an after-action review (AAR). Here, the team goes through the documentation, from identification to recovery, and discuss the following:
- What went well?
- What could have been executed better?
- Which parts of the incident response plan need to be modified for future responses?
The incident response plan is then modified to reflect these learnings.
Also Read: What Is Content Filtering? Definition, Types, and Best Practices
Incident Response Process: 10 Key Steps With Examples
In this section, we will look at the ten key steps involved in the incident response process. It encapsulates the various stages of the incident response lifecycle. In July 2020, Twitter fell victim to a cyberattack, where around 130 high-profile user accounts were compromised.
The hacker used accounts of influential people such as Bill Gates and Elon Musk to tweet a link to a cryptocurrency scam, amassing around $117000. We will go through each step of the incident response process using Twitter’s response to this account takeover incident as an example.
1. Create a dedicated incident response team
Most organizations have a dedicated security team (or at least one admin) to monitor their assets, infrastructure, and data flow. But it is essential to have a dedicated team that exists with the sole purpose of detecting and responding to security incidents. For example, Twitter has a ‘Detection and Response Team’ that constantly monitors threats and vulnerabilities.
2. Identify critical assets and components
The incident response plan is a component (although maintained separately) of the business continuity plan. This means that one of the first steps to creating an incident response plan is to identify and rank assets and services based on how critical they are to the organization’s continued operations. Once this is done, existing vulnerabilities are identified and addressed. Next, possible threat scenarios are discerned, and appropriate monitoring systems are put in place.
Before the 2020 attack, Twitter had a few account takeover attacks, all caused by third-party app exploitations, or in one case, a SIM swap. After the attacks, Twitter informed its users that these issues had been addressed.
3. Create the incident response plan
An organization must define what an ‘incident’ means to it and its step-by-step response to any incident that occurs. While the course of action varies from incident to incident, a good plan tells the organization where to begin, whom to notify, when to escalate, and when to communicate. It must contain all components explained at the beginning of this article.
4. Provide training to all employees
Incidents usually need to be addressed in high-pressure situations, with both internal and external stakeholders watching. With this in mind, each member of the CSIRT must be thoroughly trained to address any problem they might face and the escalation protocols to be followed. It is also essential to train all employees with basic security hygiene and tell them whom to contact when they detect suspicious behavior.
Twitter’s attack was traced back to a series of phishing calls made to employees, where they were asked to enter their user credentials and their multi-factor authentication (MFA) codes into a spoofed site. While many employees phoned in suspicious behavior, at least one employee is suspected of having fallen prey. This gave the hackers access to Twitter’s internal systems.
5. Isolate the root cause of the incident
The most important role of security analysts in the CSIRT team is using all the monitoring tools at their disposal to pinpoint the exact reason (or sequence of events) for the attack. The sooner this is done, the lesser the damage done will be.
Also Read: What Is Ransomware Attack? Definition, Types, Examples, and Best Practices for Prevention and Removal
6. Contain, escalate or eradicate
Once the incident is analyzed, the next step is to bring down affected services and assets before widespread infection occurs. Then, based on the information provided by the lead investigator, the incident response manager must decide whether to escalate or eradicate the effects of the incident.
After Twitter figured out the root cause of the attack, its short-term response was to block all verified accounts from tweeting since the company could not just bring the whole application down. It also added restrictions to accounts that had changed passwords in the prior weeks. Internally, Twitter revoked VPN access to one data center at a time to counter any silent, compromised accounts. Eventually, the company set up a series of new security protocols, made physical 2FA key tokens mandatory, and changed access policies. It also gave employees mandatory security training.
7. Assess damage
Once the incident is deemed under control, the overall damage to the organization’s infrastructure, finances, and reputation must be assessed. Again, care must be taken to address each of these individually.
8. Communicate
Communication is an essential part of incident response. Employees must be notified on time. If any privacy laws such as GDPR or CCPA are being threatened, the public must be informed. To keep the organization’s reputation intact, consumers and external stakeholders must be kept in the loop with timely updates.
Twitter kept its users in the loop by constantly tweeting updates. While it assured users by giving them information about the possible cause of the attack and the measures the company was taking to fix it, Twitter refrained from providing detailed in-house security information. Besides real-time tweets, it also had a running blog that was updated for up to a month after the attack.
9. Recover and monitor
At the end of an incident response plan, all systems must be operational with minimal traces of the attack. An incident is not declared as resolved just because all operations have been recovered. It is important to keep an eye out for further suspicious activities that may have been spurred on by the response.
10. Reiterate
Every incident is different and exposes a different kind of vulnerability that the organization previously did not identify. Therefore, it is prudent for organizations to reassess their existing list of vulnerabilities and modify their incident response plans accordingly.
Also Read: What Is Password Management? Definition, Components and Best Practices
Incident Response Planning: 6 Best Practices for 2021
Let’s look at the seven best practices of incident response planning.
Incident Response Planning Best Practices
1. Create an overview of the plan
The incident response plan is maintained as a separate document from the disaster recovery plan (DRP) and business continuity plan (BCP) for ease of access when required. A brief overview of the incident response plan also helps the CSIRT team to spring into immediate action. This overview must contain:
- List of roles and responsibilities
- List of identified incidents and proposed actions
- Basic toolkit required to monitor, backup, and restore systems
- Contact details
2. Update the documentation at every stage
A well-documented incident response plan is considered a success, even if it had several ups and downs. This is because this documentation can be used:
- To evaluate vulnerabilities in the system
- To fix any shortcomings in the existing incident response plan
- As evidence in a court of law
3. Outline a solid communication plan
A communication plan makes or breaks the incident response plan. While it may seem like it is enough to spot and address incidents quietly, this is rarely enough in reality. A good communication plan answers questions such as:
- What happens when the SOC team comes across an incident?
- What happens when an employee notices suspicious activity?
- How do CSIRT members update each other while in crisis mode?
- How should the HR representative notify the organization’s employees?
- What tone, frequency, and level of information must the PR team expose to the public?
- When do law enforcers need to be notified?
- When should lawyers be involved?
Also Read: 10 Best Practices for Disaster Recovery Planning (DRP)
4. Create a list of follow-up tasks
While documenting each stage of the response, a running list of follow-up tasks on the side will prove to be useful during the eradication stage. As soon as all operations have been recovered and the response has been analyzed, these tasks must be set into motion.
5. Conduct regular employee training
One of the proactive things that a CSIRT can do is have periodic training for employees, briefing them on ways to spot and deal with suspicious activity such as phishing. In addition, password hygiene must be discussed, along with the importance of other security policies.
6. Monitor all systems for a specific period after the incident
Incidents rarely occur without extended ramifications. Exposed vulnerabilities are likely to catch the attention of more attackers. A compromised asset may have been overlooked. This incident may have set the stage for a different kind of attack. Keeping this in mind, all systems must be monitored with heightened security measures for a recommended period.
Also Read: Top 10 Firewall Software for Desktops in 2021
In conclusion
A 2019 study by IBM found that more than half of its respondents did not test their incident response plans. However, it is also true that companies that effectively respond to cyberattacks within 30 days save more than $1 million on average.
Methods of cyberattacks are constantly evolving. New malware is introduced every day. Therefore, an incident response plan must be revisited at the end of every response cycle. It must go through scheduled tests and updates, with up-to-date threat intelligence taken into consideration. A well-tested incident response plan is bound to reduce reaction time, thus saving money for the organization.
Did this article help you understand the basics of incident response planning? Tell us on LinkedIn, Twitter, or Facebook. We would love to hear from you!