In the context of cybersecurity, incident response refers to the tools, processes and methodologies that businesses use to respond to security events. Examples of such events include ransomware attacks, network breaches and phishing assaults.
Although responsible security teams always strive to prevent incidents from occurring in the first place, the reality is that no organization can ever be immune to a successful attack. There will always be unforeseen vulnerabilities or unexpected types of attacks that can be used to exploit even the best-laid defenses.
Building a successful incident response plan is what prevents these inevitable breaches from turning into critical problems. By enabling teams to react quickly and effectively to attacks as soon as they are detected, incident response keeps systems and data secure, and allows business to continue operating, even when attackers manage to slip past defenses.
Understanding the importance of incident response
It is easy to assume that incident response plans can be formulated on the fly. Teams may assume that because every security event is different, every response must be different, too, and that there is therefore little point in trying to establish a response plan ahead of time.
Yet having no response plan in place, or relying on one that is minimally thought-out, leaves businesses at tremendous risk. It means that teams must waste precious time trying to formulate a plan when a breach occurs — a task that can be particularly difficult and time consuming when the details of the incident are not completely clear. In this scenario, when an attack occurs, team members lack a streamlined and preplanned communication process, as well as the necessary tools necessary to respond.
In contrast, a well-established incident response plan not only enables fast reaction to breaches, but also allows teams to react as efficiently and as effectively as possible. Although it’s true that every incident is unique, teams can prepare “playbooks” ahead of time that guide them through reactions to different categories of incidents and remove much of the on-the-fly guesswork required to respond to security events.
Security orchestration, automation and response software (SOAR) can execute automated playbook actions, giving security operations managers can more consistent, repeatable processes for a given investigation type, no matter the analyst working the case. Not only does this provide a predictive workflow, ensuring that “tribal knowledge” is captured, but it also speeds up the response process by helping to remove perfunctory and manual tasks from the equation.
Response plans can also include protocols for communicating among team members – including the broader organization – and delegating responsibilities, an approach that does much to ensure that resources are not wasted and efforts are not needlessly duplicated in the confusing aftermath of an incident.
In addition, when coupled with modern security technologies, incident response plans allow teams to take advantage of automation features so that response tasks are executed automatically, without having to wait on humans to intervene. Automation provides greater consistency, as well as faster reaction, in the face of common security threats.
Common types of security incidents
When preparing an incident response plan, start by identifying the types of security incidents that are most likely to affect your team and organization. The most pressing types of incidents for a particular business depend on factors such as the industry it operates in, its size and the types of IT systems in use.
For example, a finance company that stores banking information is an attractive target for phishing attacks designed to steal this financial information. Additionally, a health care company relying on patient data to provide accurate care is often at high risk for ransomware attacks. In this situation, attackers can take advantage of the company’s need to restore data and resume normal operations by holding patient data for ransom.
In order to tailor incident response plan to a specific organization, it’s important to address the most prevalent types of threats.
- Phishing: In a phishing exploit, attackers attempt to trick employees into giving away sensitive information, such as passwords or private data. Phishing often relies on social engineering (for example, posing as an IT worker who needs an employee’s password to fix a broken system) and can be carried out through multiple vectors: Email, phone calls, SMS messages or even in-person visits.
- Malware: Malware refers to any type of software that is surreptitiously installed on a system or hidden within data in order to provide attackers unauthorized access to a business’s IT infrastructure or assets. It can be hidden in places like an office’s shared file system, email attachments, websites that employees visit.
- Insider threat: An insider threat involves the abuse of a business’s IT systems by someone who has legitimate access, such as a disgruntled employee.
- Rogue probes and connections: Attackers regularly conduct reconnaissance and look for vulnerabilities by scanning a business’ infrastructure for problems that they could exploit in order to gain unauthorized access, such as unsecured/open network ports or outdated software.
- Ransomware: Ransomware incidents happen when attackers encrypt a business’s data and demand a ransom in order to restore access to it.
The five steps of an incident response plan
An incident response plan defines the steps that a security team will follow when a security incident occurs. It also includes information about determining what counts as a security incident in the first place, in order to decide when to trigger the plan.
According to the SANS Institute, an incident response plan should consist of the following six components:
- Preparation: The first step is to prepare the response by identifying and assembling the team members who will be involved in the response, as well as assigning roles to each of them. Preparation also entails creating a “war room” (which could be either a physical location, such as an office, or a virtual one, like a Slack channel) where the responding team can communicate, coordinate activities and monitor the progress of the response. Preparation plans should be assembled and tested ahead of time, before incidents actually strike.
- Identification: To trigger a response, staff must determine that an incident has occurred. Typically, this decision is made based on data from monitoring and alerting systems. The type of security incident should also be identified: For example, is it a phishing attack, malware, ransomware or something else?
- Eradication: The next step is to destroy the active threat. The exact approach taken here will depend on the type of threat; for malware, it will involve expunging the malicious 9code from any systems on which it resides and taking steps to prevent it from being redeployed. For an insider threat, it means revoking the insider’s access to critical systems.
- Recovery: After the threat has been eradicated, the security team must recover and repair any damage caused. If data was deleted by attackers, it will need to be restored. If systems were shut down in order to stop the attack, they will need to be turned back on (taking care to ensure that the threat is no longer active within them) or rebuilt from clean copies.
- Lessons learned: The final step is to assess what happened, why it happened and how the same type of incident can be prevented from occurring again in the future. To systematize this process, it is helpful to collect metrics about incident response, such as which types of incidents occur most often and how long each type takes to resolve, on average. Then, teams can set goals to improve upon these metrics over time, prioritizing the types of improvements that will yield the greatest benefit.
Automating the incident response plan
Incident response plans represent the difference between attacks that lead to serious business disruptions, and those that are shut down quickly before critical damage occurs. And although it may be tempting to assume that you can make up a security plan as you go, the reality is that having a systematic, well-established plan in place before breaches take place is key to minimizing the time and resources required to respond to incidents.
This is especially true of teams that build automation into their incident response plans. By defining playbooks that specify how different types of alerts, cases and incidents should be handled, then deploying software that automatically carries them out, teams can save critical time, while also mitigating the risk of human error or misinterpretation when executing incident response plans.
The Siemplify security orchestration, automation and response platform makes this automation possible. By using threat intelligence to automate responses, Siemplify takes the guesswork out of incident response and empowers teams with fast, effective resolution of whichever threats make it past their defenses.