In this lesson, we're going to discuss
Root Cause Analysis.
Now, a root cause analysis is a systematic process
to identify the initial source of the incident
and to prevent it from occurring again.
This analysis is usually going to occur
using a four-step process.
First, we define the scope of the incident.
Second, we determine the causal relationships
that led to that incident.
Third, we identify an effective solution.
And fourth, we implement
and track the solution
to ensure that the incident is fully resolved.
So let's go through a quick example.
Let's say you had a malware infection
inside your organization.
First, you need to determine the initial cause
and scope of that incident.
Maybe it was caused
because malware was introduced into your network
because somebody plugged in a USB thumb drive
into their workstation,
or they clicked the link in a spear-phishing campaign,
or they visited a malicious website.
Now, whatever the initial attack vector was,
our goal is to identify that
so we can prevent it from happening again.
If somebody caused this incident to occur
by plugging in a thumb drive that was infected with malware,
there are a couple ways that we can prevent this.
One way would be to ensure that all of our workstations
have the latest version of antivirus installed on them.
This way, anytime you insert a disc, a CD,
or a DVD, download a file or plug in a USB thumb drive,
it's going to be scanned for viruses
and other malware before allowing you
to read from the device.
Another thing you might do
is to prevent the data transfer
from USB devices like thumb drives
and external hard drives
for all users on your enterprise network in the future,
this will be another great way
to stop data from getting from this infected device
onto your system.
Now, in addition to that, we might also find out
that this particular piece of malware
was only infected against certain types of machines
that were running a certain version of windows
or we're missing some type of security patch.
And in those cases, we would identify that weakness,
and then we will create a solution
to identify those things such as upgrading the version
of Windows or installing the security patches,
as that will protect us from this vulnerability.
So now that we've gathered this information,
we have to define and scope our incident.
We should know how many machines have been affected
and how many users have been affected by this incident,
and what operational impacts that has.
Then we go and we determine the causal relationships
that led to that incident.
In this case, somebody installed malware
using a USB thumb drive.
So we need to identify an effective solution to stop that,
and we came up with a handful here,
just as we were going through this example.
Things like adding antivirus
or preventing data from being read
from a USB mass storage device,
or installing a newer version of Windows,
or even an updated security patch
for that particular vulnerability.
And then this brings us to the fourth step,
which is to implement
and track the solutions to ensure
that the incident is fully handled.
Now, in this case, we might have a single system
that was infected by a piece of malware
on the USB device.
So we've identified what it was,
we determined the relationship that led to the incident,
and we've identified a couple of effective solutions.
In this case, I'm going to want to go ahead
and ensure that I block mass storage devices
from being read on the user system,
and I want to ensure that their antivirus
and antimalware solution is up to date.
And now I need to implement and track those action items.
In this case, I would tell my system administrators
through a change management process
to install the registry change
that will prevent USB devices
from being read on that machine
and make sure that it is part of our asset management
and change management process to update the fact
that machine has been updated
to the latest version of Windows
and has the latest security patches.
By doing all of these things,
we have now contained this incident
and figured out the root cause,
and stopped it from happening again.
Now, I like to take this one step further.
Because we have identified it on this single machine,
we also may need to look across the network
and see if there are other machines
that could have been affected as well.
For example, if we figure out the reason
that this piece of malware was able to be installed
is because you're running Windows 10 instead of Windows 11,
then we might need to look at the rest of our network
and say, "Hmm, how many Windows 10 machines do I have?"
If there are a lot of them, it may be a very large solution
for us to try to upgrade all systems to Windows 11
and prevent this vulnerability from being exploited again,
that's the real benefit of doing a root cause analysis.
You need to figure out what caused the incident
and then see how many other things across your network
or across your organization are going to have to have
that same feature set that could then be vulnerable
to the same type of attacks
so you can mitigate those vulnerabilities.
Now, when you conduct a root cause analysis,
you must make sure that this process uses
a no-blame approach.
In other words, the root cause analysis process
is not designed to point fingers or assign blame
to an individual or team.
Instead, our primary goal is to identify
the root cause of the incident
and develop effective preventative measures
to prevent the incident from occurring again in the future.
Using a no-blame approach can encourage open
and honest reporting,
which is crucial for improving cybersecurity practices
within an organization.
Consider the real-world example
of the two plane crash involving a Boeing 737 MAX
that occurred back in October 2018 and March of 2019.
After the crashes,
the United States National Traffic Safety Board,
known as the NTSB, joined the investigation
to conduct a root cause analysis.
During their investigation,
the NTSB conducted an independent,
no-blame root cause analysis
with the primary objective of determining
what went wrong and why.
Their investigations are meticulous,
thorough, and independent,
and they often evolve multiple experts
across various fields.
For instance, NTSB might look at an airline crash
to see if it was caused by one or more factors,
including pilot error, weather conditions,
or technical malfunction.
NTSB's investigators do not focus
solely on blaming the pilot, but instead,
they analyzed the entire chain of events,
including weather data, aircraft maintenance records,
communication transcripts, and cockpit voice recordings.
Now, in the case of that Boeing 737-MAX crashes of 2018
and 2019, it was determined that both crashes were caused
by issues in aircraft's new flight control software
that repeatedly pushed the jet's nose down
due to a defective sensor on the aircraft.
This essentially removed control from the pilots
and caused both planes to crash into the ground
since the pilot could not overcome
the new yet defective maneuvering characteristic
augmentation system used as a flight control system
on each planes.
So why does the NTSB use a no-blame approach
when conducting their root cause analysis?
Well, the NTSB is known for recognizing
that human errors are often the result
of systemic issues within the aviation industry,
such as training procedures, equipment design,
or regulatory oversight.
By using a no-blame approach,
the NTSB can identify these systemic weaknesses
and recommend improvements
to prevent similar incidents in the future.
In the case of the Boeing 737-MAX,
there are almost 400 planes in operation around the world.
So the NTSB and other country regulators
quickly grounded these planes
until the root cause was identified,
and the defective flight control software was reviewed
line by line to ensure that no other vulnerabilities
could be identified that might cause future crashes to occur.
So remember, when you conduct your root cause analysis,
remember that our primary purpose is not to assign blame,
but instead to figure out exactly what has occurred
to cause the incident in the first place.
By conducting a root cause analysis without blame,
we can better identify vulnerabilities
or weaknesses in our security practices
and create more robust protections against cyber threats.
Creating this no-blame culture
can also encourage collaboration, transparency,
and focus on solutions rather than assigning fault
during or after an incident response.