TechKnowSurge
NIST CSF RS.AN-03 CompTIA CySA+ 3.3 ISC2 CISSP 7.6 NIST NICE S0175 NIST NICE K0957 CompTIA CySA+ 3.2
TechKnowSurge Catalog Videos Root Cause Analysis
VideoSecurityFree

Root Cause Analysis

Root cause analysis (RCA) is a structured process used during incident response to trace an incident back to its true origin rather than stopping at surface-level symptoms. Identifying the root cause enables more effective containment, eradication, and recovery.

⚑ Complete this video to capture a CTF flag worth 1 point.

About this video

Root cause analysis (RCA) is a disciplined investigative process used during and after incident response to determine not just what went wrong, but why it went wrong and how far back the chain of causation extends. During an incident, the immediate priority is containment, eradication, and recovery — but resolving visible symptoms does not always mean the underlying problem has been found. RCA bridges that gap by systematically tracing observable effects back through contributing factors until the true origin of the incident is identified. Some incidents make root cause identification straightforward. A ransomware infection with a clear phishing vector, for instance, provides an obvious starting point for tracing the timeline of events. Other incidents are more ambiguous — a system may be restored to normal operation through a simple restart, yet the actual cause remains unknown until a thorough analysis is conducted. In a case where degraded application performance is ultimately traced through slow database responses, a CPU spike, a problematic stored procedure, and finally to incorrectly written application code, the fix applied at the database level addressed only the symptom. The root cause existed in the code on the application server. This layered investigative approach — following each clue deeper into the environment — is what defines effective root cause analysis. The process continues until the origin of the problem is clearly established, regardless of how many systems or components must be examined along the way. Understanding the true root cause is essential for implementing permanent corrective action, strengthening defenses, and preventing the same class of incident from recurring.

What you'll learn

What's covered

Root Cause Analysis

Aligned to

NIST CSF
RS.AN-03 Analysis is performed to establish what has taken place during an incident and the root cause of the incident.
CompTIA CySA+
3.3 Explain the preparation and post-incident activity phases of the incident management life cycle.
3.2 Given a scenario, perform incident response activities.
ISC2 CISSP
7.6 Conduct incident management
NIST NICE
S0175 Skill in performing root cause analysis
S0175 Skill in performing root cause analysis
K0957 Knowledge of root cause analysis tools and techniques

Key terms

Incident Response
IR
A structured process for identifying, containing, eradicating, and recovering from security incidents.
Ransomware
A type of malware that encrypts a victim's files and demands payment in exchange for the decryption key.
Root Cause Analysis
RCA
A systematic investigation process that identifies the underlying cause of a security incident or system failure, going beyond symptoms to prevent recurrence. RCA findings drive corrective actions and improvements to security controls.
Malware
Software specifically designed to disrupt, damage, or gain unauthorized access to a system.

Topics

Root Cause Analysis Incident Response Threat Analysis Incident Containment Security Operations

Transcript

Finding the Root Cause

One of the things that we're trying to establish when it comes to incidents is what is the root cause of the incident.

Through this incident response process, one of the things that we want to do is we want to analyze the situation, analyze what's happening, analyze the data, and figure out what the root cause is. We call this a root cause analysis. And preferably we do this sooner and are able to figure out what it is, so we can contain, eradicate and recover from this issue.

Now often the root cause is quite clear. For instance, if things are getting encrypted on a machine and then it pops up with a "you need to pay this amount to get access to these files again," then we think ransomware. Well, there's ransomware installed on the machine. Well, that could be considered maybe a root cause, but what was the root cause of the ransomware? How did it get on that machine? Did somebody click on an email and click on a link, and then it downloaded this? And so maybe we can trace it back and figure out what happened, and what was the timeline, and what was the root cause of this ransomware. And it's pretty clear, and then we go into the containment, eradication and recovery phase.

That's not always the case, though. A lot of times we see signs of malfunction, and then the system goes offline, and then customers report issues, and we have this series of events that doesn't necessarily pinpoint a specific problem. In fact, we may be able to contain, eradicate and recover from a situation without actually knowing what the root cause is.

An Example: A Slow Application

So for instance, let's say we have an application with a database on the back end, and the user reports in, well, we're having issues on the system, there's something really slow. We investigate, and we realize that the database CPU has spiked and there's something wrong with the database. So what we do is we do a restart on the database server, it comes back up, everything's fine, the user is not complaining anymore. So we fixed the issue without actually finding what the root cause was.

Here then we need to go into the root cause analysis and figure out what's going on here. Well, the user was experiencing something slow, so we look at the application, and on the application server we realize that there's a lot of slow responses coming from the database server. So then we look at the database server, and we see that the CPU is spiked at 100%. But why is it spiked at 100%? So now we look at the different processes, and one of the processes on the database is spiked. So we look at that process, but that doesn't really tell us the full thing. Maybe it's just a simple SQL database that has the SQL database processes spiked, and so that doesn't really tell us much.

So then we get on to the database side and see what's happening within our different structures and stuff, and we see maybe there's some sort of procedure that's being called that's causing a problem. So then we look at, well, that procedure, where is that being called from? And we realize it's the application server that's calling this problem. And so now we take a look at the application server, and we look at the code on the application server, and realize that it's coded wrong, that it is calling the wrong procedure in a wrong way. And so actually the cause is coming from the code over here.

And then we could also analyze, well, why did that code get onto the server to begin with? And we could even take it further back, but let's just say the root cause we determined is the code, and the code needs to be changed. And so even though our restart was done on the database server to fix the issue, the actual problem existed in the code sitting on this application server.

So that's why we go through root cause analysis: we keep tracing it back further and further and further, and how deep does this go, to find out what that root cause was.

About TechKnowSurge

TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.

Explore free tools and programs →