The primary objective of investing in cybersecurity controls is to prevent security incidents. However, no control is perfect - cyberattacks happen and data breaches, unfortunately, occur in the presence of even the most rigorous information security programs.
In fact, more than 3.2 million records were exposed in the 10 biggest data breaches in the first half of 2020 alone, according to data compiled by the Identity Theft Resource Center (ITRC) and the U.S. Department of Health and Human Services.
How your organization responds in the aftermath of a data breach determines whether a cybersecurity incident is an inconvenience or a damaging, sometimes business-ending, event. Conducting an incident response root cause analysis immediately after experiencing a breach can help to determine the necessary actions to reduce the impact of the incident and avoid future breaches.
Related Reading: Ransomware Prevention to Incident Response
What is Root Cause Analysis?
Trying to make good cybersecurity decisions without sufficient information is a recipe for failure, and cyber security incidents are rarely clear-cut. Each incident is different, and the nuances must be well understood to guide response and recovery efforts.
Enterprises must not only understand individual vulnerabilities but what ultimately causes them, which often relate to non-technical risks such as inadequate governance, lack of process adherence or failure of oversight functions.
The National Institute of Standards and Technology (NIST) defines root cause analysis as, “A principle-based, systems approach for the identification of underlying causes associated with a particular set of risks.”
Few cybersecurity incidents are caused by a single vulnerability. More commonly, investigation reveals a number of problems lurking beneath the surface. By identifying the underlying factors that contributed to the causes of a given security incident, an organization can improve the effectiveness of containment and eradication efforts and decrease its vulnerability to future attacks.
Related Reading: Why Pen Tests are Key to a Robust Incident Response Plan
What is the Goal of aN INCIDENT RESPONSE ROOT CAUSE ANALYSIS?
When an incident occurs, it’s important to learn as much about it as possible to ensure you completely eradicate the threat from your systems. Identifying the contributing factors to an incident enables an organization to address each link in the chain of events which led to the problem.
In addition, cybercriminals often create backdoors to enable them to regain access to a compromised system even after incident response has eliminated the obvious signs of their presence. Many cyberattacks exploit the same infection vectors and vulnerabilities to gain access to an organization’s systems. Addressing these risks makes it difficult for an attacker to maintain persistent access or regain access which was removed during initial response activities.
Performing root cause analysis can also help your organization to identify other outlying factors that may have contributed to the success of a data breach. For instance, unintentional insider threats, where employees cause damage without meaning to, often contribute to the severity of an incident.
Identifying negligent actions that led to a breach enables to you to take steps to mitigate the threat, such as cybersecurity awareness training and implementing least privilege policies.
Related Reading: 3 Differences in Incident Response for a New Remote Workforce
When to Use Root Cause Analysis
Identifying vulnerabilities can be accomplished at an individual weakness/deficiency level or at a root-cause level. Understanding specific exploitable weaknesses is helpful when problems are first identified or when quick fixes are required.
When it’s time to study the root cause, these specific details provide organizations with necessary information for putting the pieces of the puzzle together to eventually diagnose the root causes, especially those problems that are systemic in nature.
This process should be completed as soon after an incident occurs as possible. Delays in identifying and mitigating the causes of an incident could exacerbate the effects of an ongoing incident or leave the organization vulnerable to additional attacks.
Root Cause Analysis Methods
There are several methods to conduct a root cause analysis. The choice of which to use largely depends on preference.
Creating a Root Cause Analysis Map
When an event occurs, the organization should start its data breach analysis by creating a cause map. This connects individual cause and effect relationships to reveal the root cause of the incident.
At a high level, the cause map helps to create a visual representation of the event by determining the following:
- What happened
- Why it happened
- What to do to reduce the likelihood of it happening again
Of course, each of these steps requires careful and objective analysis. This must be performed by those with both subject matter expertise and background knowledge of the circumstances leading up to the incident.
Root Cause Analysis 5 Whys
The 5 Whys root cause analysis approach is designed to peel away multiple layers of explanations to get to the source of a problem. By repeatedly asking the question “Why” - often five times - it is possible to gain a deeper understanding of the reasons a certain incident occurred.
In many cases, what appears to be the cause of a particular incident is actually a symptom of another problem.
The 5 Whys approach is simple: Look at the original incident, ask why it occurred. If the answer to this question is not the root cause of the incident, repeat the process. Once the root cause has been fleshed out, develop a plan to address it that will also mitigate the other issues identified along the way.
Fishbone Method of Root Cause Analysis
The fishbone method of root cause analysis uses an Ishikawa diagram to identify the causes of a particular incident. In this diagram, the incident is placed at the far right of the diagram (the fish’s head) with a line pointing to it (the fish’s spine).
Factors that contribute to the incident are drawn branching off this line (the fish’s ribs). Each of these branches can have additional branches, indicating contributing factors.
This process of identifying and adding contributing factors for each branch continues until only root causes of the incident remain.
The result of this analysis should be a map of every factor that contributed to the incident. This provides a framework for incident remediation activities as well as guidance regarding the steps that must be taken to ensure that the incident does not recur in the future.
Combining multiple methods can also be helpful. For example, the 5 Whys method can be used to develop the Ishikawa diagram created in the Fishbone method of root cause analysis.
Applying Objectivity and Root Cause Analysis Expertise
Because your own employees might not have the right skills or be too invested in the situation to objectively classify risks, it’s important to hire a neutral third party to investigate the causes behind a data breach or a cybersecurity incident.
Skilled incident responders can find the root cause of breaches, develop a remediation roadmap, and implement future prevention efforts. Not taking the necessary steps to fully remediate lapses in information security increase the chance that attackers can successfully target your enterprise again.
Empower Yourself to Act Quickly When an Attack Occurs. Download the e-book.
- The six phases of a comprehensive IR plan
- The five steps required for getting started
- The factors and entities you need to consider when writing your IR plan
- How to practice your plan for responding to an incident
Learn more about Avertium's DFIR Retainer.
Paul Caiazzo, Senior VP of Security and Compliance
Paul brings his wealth of cybersecurity experience to guide Avertium customers through challenging security problems while keeping business goals and objectives at the forefront. His primary focus is on business development, partner and client engagement and other strategic initiatives.