- In this lesson, 21.2,
we're gonna focus in on incident response.
So let's start with an incident response flowchart.
First thing that happens is an incident is detected.
Okay, that's great.
The incident is reported, right?
So whatever your detection system has, it reports it out.
And then the incident is probably assigned, right?
So there is an assignment made, okay?
You go figure out that incident.
So the incident investigation, right, gets assigned.
Then the next thing that has to happen,
is validation and prioritization.
Just because an incident has been reported,
doesn't really mean an incident has necessarily occurred,
or maybe it has occurred,
but it really doesn't have much impact.
So you wanna validate that the incident has occurred.
And then if there's more than one thing happening,
at a time, we wanna prioritize our response.
So validation and prioritization.
From there, we're gonna wanna contain it, right?
We're gonna wanna keep it tight,
we're gonna wanna eradicate it,
get rid of whatever's, you know, causing the incident.
We're gonna wanna recover from it,
and then we're gonna wanna do lessons learned.
So those are all of the components of incident response.
So now let's dive a little deeper into some of them.
Validation.
Validation is really important.
The focus of validation is determined,
whether an incident has actually occurred.
Now you might have, you know, indicators of attack,
maybe some indicators of compromise,
but they really need to be understood, right?
So we wanna determine,
whether an incident has actually occurred, and if so,
the type, the extent, and the magnitude of the problem.
Remember, an indicator tells us that something is happening,
or has happened, but even if an indicator is accurate,
it doesn't necessarily mean that an incident has occurred.
It could just be a problem.
The following predefined processes,
the incident response team should work quickly,
to analyze and validate potential incidents.
Now, prioritization is the process of determining
the order of importance or urgency,
and it's one of the most critical decision points,
in the incident handling process.
So we wanna pre-established incident prioritization,
and escalation guidance as a component,
of our incident response preparation.
There may be some incidents that we say,
we have to respond to immediately, drop everything.
There's others 30 minutes, maybe others two hours,
maybe others within a day, another within 24 hours.
So within a day being a workday,
24 hours could go over to the next day.
But we really want to say, based on these type of incidents,
right, this is how we're gonna respond.
And then what are those escalation thresholds,
as well, for those incidents?
So relevant factors include,
what's the functional impact of the incident?
What is the confidentiality impact of the incident,
and what's our recovery of the incident?
So it could be that the longer the incident goes on,
the harder it's gonna be to recover from it.
Now the escalation process is initiated at the point
where an incident requires a higher level,
of attention or response.
So now we're focused in on that incident,
and what we wanna really do is contain it.
Containment is a short-term approach,
to limiting or reducing the impact of an incident.
Now, containment strategies are gonna vary,
by type of incident, which of course,
should be documented in your incident playbook.
Relevant stakeholders, like system owners,
should be included in decision making,
and evidence is collected during containment,
for problem resolution and for potential legal proceedings.
So if we are going to build a criminal,
or civil case during this containment phase,
we will be gathering evidence.
The eradication process is inclusive of all of the steps,
taken to either correct and or eliminate the root cause,
not just the symptoms, the root cause,
that led to the incident.
Now, a really good practice to get into,
is doing what's known as an RCA, a root cause analysis.
A root cause analysis is a method of problem solving,
used to investigate known problems and identify,
what happened and what's the underlying cause,
you know, and there's such a tendency,
in instant response to really look at the symptoms and say,
"okay, I gotta fix those symptoms."
Well, that's good,
but we really always wanna understand the root cause,
because the main goal of doing the root cause analysis,
is to prevent the problem from reoccurring.
And only if we understand the root cause can we do that.
So looking at the root cause analysis process,
we start with defining the incident,
gathering data and input,
and then identifying possible causal factors.
Now, there could be a lot of factors.
So we wanna whiteboard this and throw them all up there.
It's not just that the symptoms, we wanna think back,
what could have possibly caused this,
what are the possible factors?
And we'll go through looking at those possible factors,
over and over again, and we might even go
through a process called the five why's,
where you ask the question why five times,
each time you come up with a new answer.
But ultimately we should be answering the question,
what was the root cause?
Identifying the root cause.
Once we know the root cause,
then we can look to find solutions.
And once we've found solutions,
we can implement the solutions.
So we're defining the incident, gathering data and input,
identifying the possible factors, you know,
coming up with what the root causes are,
finding the solutions based on those root causes,
and then implementing those solutions.
Now recovery is the process of restoring normal operations,
confirming that all of our systems,
are back functioning properly again.
And if applicable,
remediating any associated vulnerabilities.
The recovery activities can include things like,
restoring and or rebuilding systems,
replacing compromised files with a clean version,
installing patches, changing passwords,
and tightening, you know,
network perimeter security or hardening our systems.
That implementing enhanced monitoring,
is often a part of the recovery process, right?
Once a resource is successfully attacked, you know,
it's not that unusual to have it attacked again.
So having that resource attacked again, or another resource
within the organization being attacked in a similar manner.
So we really wanted to up our game,
and have enhanced monitoring.
And then at the end of this process, we wanna say,
what can we learn from this?
What are our lessons learned?
So post-incident lessons learned should be evaluated,
and integrated into organizational processes and controls.
So what's part of our lesson learned?
Well, we wanna say exactly what happened,
and really when did it happen?
How well did we respond to this incident?
What would we do different,
next time a similar incident occurred?
What actions can prevent similar incidents in the future?
What precursors or indicators should be watched for,
in the future to detect a similar incident?
And what additional tools,
or resources are needed to detect, analyze,
or mitigate future incidents?
So the whole goal of lessons learned is improvement.
It's never to assign blame,
it's always organizational improvement.
And now my friends, brings us to a three second challenge.
Five challenge questions, three seconds each.
Oh, you know how to do this.
Incident response process that focuses on improvement.
It's the one we just talked about.
1, 2, 3,
lessons learned.
Number two, incident response process,
that focuses on eliminating the threat.
1, 2, 3,
that is eradication.
Number three,
incident response process that focuses on minimizing damage.
1, 2, 3,
it's gonna be containment.
Number four,
problem solving method used to identify underlying causes.
1, 2, 3,
it's gonna be a root cause analysis or an RCA.
Lastly, number five,
the point at which an incident requires a higher level,
of attention or response.
1, 2, 3,
it's your escalation threshold,
or just escalation would work as an answer.
All right, let's do a security and action.
And this is about incident response activity.
The help desk receives three calls right in a row,
from users on the same floor of a building,
who state that they're having problems,
with their wireless access.
The network admin goes to the floor and picks up,
an unauthorized WAP, wireless access point, signal.
You're being kept apprised of the situation.
So here's what I want you to tell me.
What incident response phase is currently
in process and what should happen next?
So the help desk gets three calls, boom, boom, boom,
right in a row, right?
So three calls right in a row from users.
They're on the same floor of the building,
and they're having real problems, you know,
with their wireless access, perhaps they get, you know,
they're being, you know, taken off, de-authenticated.
So your network admin goes up to the floor, you know,
doing some investigation,
picks up an unauthorized WAP signal, maybe an evil twin.
You're being apprised of the situation.
So what I wanna know from you is,
what incident response phase is currently in process,
and then what should happen next.
So definitely put me on pause, write down some notes.
So let's talk about the IR phases.
The response is currently in the validation phase,
the expected actions are confirmation and prioritization.
So we need to validate that having that unauthorized
access point is really what was causing the problems.
Now having an unauthorized access point might be a problem,
in and of its own, but just because we have a symptom,
right, or something happening,
doesn't mean it was necessarily the cause of the problem.
Now, if an incident is detected,
the next stage is containment, right?
Now, in this case the WAP would need to be physically found,
and disabled, 'cause all he's found so far is the signal,
he has to go find the that WAP and disable our de-power it.
Now, after that, so we had containment, right?
'Cause we are now in the, we already had detection.
That was what our users did, right?
We have this validation going on by the IT guy, right?
If the incident is declared our next stage containment,
and then after that we would do eradication, right?
Eradication being the removal of the wireless access point,
reconfiguration of impacted systems,
and also figuring out,
how the unauthorized device was installed.
That's a root cause.
Now recovery would be ensuring that all users
can properly connect to the wireless network.
And lastly, lessons learned would include your findings,
and post-incident recommendations.
So being able to go through all of these phases,
you don't ever wanna skip a phase.
You always wanna make sure that you are validating,
and you never wanna mistake a symptom for a root cause.
Doing all that, my friends, that's security and action.
There is your word cloud.
Make sure that you know what happens,
in all of these different phases and that you can speak
to every term and concept that is on this word cloud.
When you're ready, head on over to the next lesson.
I'll be waiting for you there.