>> Everything that we just finished talking about covers
R portion of the React principle.
After we've done that,
the next portion of React is to evaluate.
In evaluating an incident,
one of the first questions that you want to ask is,
is the incident over?
Which helps focus the sense
of urgency and something's already happened and
it's no longer a threat to
your system you still may want to
investigate that the sense of
urgency may or may not be there.
Evaluating if the incident is over what type of
incident occurred which goes
into the next portion of the incident,
what major assets were involved?
Is this something that is just isolated
to one computer system or
has to span multiple computer systems it
has to span multiple geographic areas,
it's very important to consider.
The next thing is to evaluate
what type of damage was caused.
If essentially you have
a fishing incident and it was isolated,
no one clicked on the link,
or if you've had a virus detection,
but your virus software was able
to essentially quarantine that virus.
The incident for all attentive purposes it's
likely over and it caused little to no damage.
That will help tailor
the actual response that you're going to provide to
that incident and then is
continued operation possible are required.
If this is going to impact your business continuity,
if it's going to shut down operations, obviously,
that's going to be something that's going to take
that incident and place it at
a higher level on our priority.
As time progresses and
>> you're gathering more information,
>> you want to do a re-evaluation of any and
all relevant changes to your slides configuration.
So you're essentially trying to
rule out bad configuration,
bad assumptions, and operator error.
As part of that evaluation process,
a method that I like to use is
essentially the scientific method,
because of science we are able to answer
some of these questions in our evaluation process.
The first step of the scientific method is
essentially to ask a question, why?
Asking that question will essentially hope
to help you come up with answers to that question.
Soon as you pose that initial question for research,
you're going to do some background research.
What have others said?
What indicators might I see
if I were to expect something to happen?
We're going to construct that hypothesis essentially as
a statement that is going to
answer our research question.
I think someone has infiltrated
my network or has someone infiltrated my network?
I might do a little bit of background
research to see what
those indicators of compromise might look like,
based on the limited amount of evidence that I have,
I will construct that hypothesis
that I do in fact believe someone has
infiltrated my network and
go test that with an experiment.
I'm going to gather up all of
the available data that I have,
I'm going to conduct my investigation,
then I'm going to analyze those results.
What did they tell me?
Was someone able to actually penetrate my network?
If that hypothesis essentially it was proved true,
I can then go ahead and report
those results and I can essentially start taking
steps to mitigate that incident.
However, if I find that
my hypothesis was false and was partially true,
I might want to go back and
>> construct another hypothesis.
>> It does not necessarily mean
something didn't happen I have just
maybe been incorrect on what I
essentially guessed the first time.
I may want to go back and
test yet one more time for something else.
That scientific method helps us
evaluate and ask the right questions.
Hopefully, we can come up with the right answer.
So again, we've kind of talked
about that scientific method.
Another example of that scientific method in
action is the asking the question,
Why is my machine slow?
We're going to do that initial research of,
what do others say about slow systems?
What indicators can I look at?
We may do a cursory examination
>> of that system together,
>> some slight indicators to help us
formulate a better hypothesis.
Based on the observable information that
we've come up with about slow systems and about
what other people have said about slow systems
we hypothesize that I have a virus.
The virus is therefore causing my system to be slow.
In order to test that hypothesis,
I'm going to run a virus scanner,
I'm going to re-examined suspicious files.
We'll get into some of this
a little bit later in our malware analysis.
Based on the hypothesis testing and
the evidence that I have from testing that hypothesis,
is the hypothesis confirmed,
or is it unconfirmed?
If I'm able to confirm that hypothesis,
I can report the results,
but sometimes the results of
an unconfirmed hypothesis are just as important.
If I've confirmed that I don't have malware,
that's just as important as
the fact that I do have malware,
but also if the hypothesis is
unconfirmed and it's slightly fuzzy as to
whether or not I do or don't have a virus and I
haven't answered the question as to
why my machine is slow.
I may want to go back and conduct another test,
reformulate another hypothesis to help answer
additional questions as to why my machine is slow.
It could be that there may be
more than one cause as to why my machine's slow.
Just because I found an answer to one question,
or to one hypothesis,
it doesn't necessarily mean that that's
the only thing that is making my machine slow.
The scientific method helps us answer these questions
>> in a logical fashion in order to prevent
>> us from spinning our wheels and
going in 50 different directions.
Now maybe that we've answered some of the questions or
haven't answered some of the questions
using the scientific method,
we can go onto the other
>> essential elements of response.
>> That is Don't Panic.
If we figure out that something has
happened and we've kind of formulated
what we think may have
occurred the next thing we want to do is not panic.
If we've discovered elements of an incident,
the first thing we want to do is not to trash
the crime scene or not to trash all of the evidence
that we may have in order to help us remediate that
and/or take this case to
prosecution if we really need to.
Not trashing the crime scene,
preserving that evidence is
a very key step in doing that.
We also want to practice good operational security.
If this is something that we want to
essentially investigate and not tip-off,
the potential attackers, or hackers,
or potential criminal actor
that has caused this incident.
Panicking, taking actions to
violate operational security that essentially notify
the perpetrator of this Act
that we're investigating it can
lead them to stop taking action or
they might actually start destroying evidence.
Then knowing our limitations.
If we go into a scene and we're nervous or we're
scared about responding to this incident,
if we don't know how to properly respond to this,
we can actually make the situation worse.
As Clint Eastwood said,
a man's got to know his limitations,
a very important aspect when responding to incidents.