>> Moving on from this slide,
we have another visual here
>> that lays out that CIRC Team Composition.
>> Depending on your organization,
it may or may not vary from this,
but at the center of that,
>> you're going to have that team leader.
>> Then you'll have that incident manager,
your forensics person, local IT support,
IT administrators maybe
>> if your system spans many geographical regions,
>> and then your incident response team members.
Also included in this incident response team
is going to be a dispatcher.
Dispatchers are going to essentially
man and answer the response hotline.
They may or may not be actual part of that team
>> but if you'd have a ticketing system
>> similar to maybe ARC site,
>> they might be the person who receives that initial call
>> and puts a ticket in the system that says,
>> "Hey, we've had some type of incident."
Essentially their responsibilities are to
receive distress calls from clients or employees
>> and they provide general information
>> about the various incident response services.
They'll fill out the reports,
they'll essentially assign a tracking number
so you can keep track of that incident,
and they'll connect clients with
the appropriate incident response team personnel
for further assistance.
Then technically this function is
going to be conducted around the clock
>> as many organizations have 24/7 up time,
>> especially if they're large global organizations.
Another aspect we're looking at
this incident response totality
is the awareness of something occurring.
That's going to be the first level of
the incident response that something happened
>> and that we may or may not know what happened,
>> but we want to know how do we know that this occurred.
Then we're looking for these indicators.
Indicators may come in various forms.
It could be something from IDS,
so maybe you've got a ping
>> or something that someone has tried to do something
>> to your network and you need to go
>> and investigate that to get exactly what that was.
>> Maybe you've had someone
>> who was cruising along the Internet
>> or they've opened up some type of file on
>> their email and all of a sudden you have
this virus scanner alert pop up
>> and say that your system is either
>> infected and/or that your virus scanner has quarantines
>> and that would warrant some type of incident response.
>> The next indication you might have is
a violation of acceptable use policies.
If you're monitoring traffic on your network
>> and you're seeing boys go to certain websites
>> that they're not supposed to,
or you see them using a computer
>> for other than its intended purpose.
>> That might be something that you want to investigate
>> and figure out further what exactly happened,
>> why they're doing what they're doing.
You may also have firewall notifications
that something's happening
or someone's trying to get into your network
>> or something's trying to escape your network,
>> that shouldn't.
>> You could also have self-reporting.
Maybe a user has opened up that email attachment
>> and they've notice that
>> they're now infected with ransomware
>> or maybe they've lost their laptop
>> or their mobile devices
>> that's connected to your network
and they're calling the dispatcher to report that.
Then lastly hopefully, this doesn't occur,
but it has in fact to a few several organizations
>> is that you get a report in the news
>> that you've been hacked
>> and you don't know about it,
>> or you're having to now respond
>> to this reported hack in the news
>> so you're definitely behind the power curve.
>> Moving on after the awareness stage,
we essentially have to question that
now that we know something happened,
>> how do we know?
>> We're going to identify what happened,
the who, what, when, where, how.
Then we ask ourselves the question,
is this actually an incident?
Oftentimes events may happen
>> and they may not rise to the level of
>> something being an incident.
>> Does the event violate any principle of
that CIA triad about confidentiality, integrity,
>> or availability of data on your network?
>> Hopefully, those things will be laid out
in your incident response policy.
But if not it's important to ask those questions.
Then, once you determine that
it is an incident that it does violate
>> some principle of that CIA triad,
>> you have to ask yourself how serious of
a problem is that incident.
If it's phishing with no data loss,
it may just warrant essentially blocking
that sender's email address
or if it's a DDoS attack that shuts down your network,
you're obviously going to have to spin up a lot more of
your incident response personnel
>> to essentially deal with that
>> and you'll probably call in your ISP provider
>> to essentially have some assistance in blocking
>> that large amount of traffic
that's coming into your network.
Then obviously,
>> once you're starting to respond to these incidents,
>> it's important to follow your organizational
>> procedures and policies as required.
>> After we've figured out that plan of action,
the next thing that we're going to have to do is
to react to that incident.
In reacting to that incident,
we've broken that down into a simple,
>> easy-to-remember process.
>> The first step that R is
>> to review the policies and procedures,
>> we keep hammering on that policy and procedures.
That just shows the necessity and the importance
>> of having good policies and procedures in place.
>> After you've done that,
we're going to evaluate the situation.
Determine again what we talked about, who, what, when,
where, why, how of the situation.
The next step is to avoid panic.
Oftentimes, when something happens,
such as a very serious incident,
a lot of people want to panic and make rash decisions.
Avoiding panic, thinking through the process,
logically coming up
>> with a good solution is a very important step.
>> Collecting information is obviously going to help us
>> come up with that solution to the problems.
>> Just like G.I. Joe said,
knowing is half the battle,
the more information that you
can collect and the more information
>> that you know about an incident will help tailor
>> that response to the incident.
>> Lastly, after you've collected that information
>> and you have an understanding of
>> the exact situation that's occurring,
you'll want to take the appropriate action.
But obviously, if you don't follow
the aforementioned steps in
reviewing your policies and procedures,
knowing and understanding the situation, not panicking,
and not collecting any information about the incident,
it's very difficult to come up with
>> the appropriate action to take.
>> It's very important to follow that REACT principle
>> in that step action that's outlined.
>> Looking at the REACT principle a little more in-depth,
let me talk about the first process
>> which is reviewing the policies and procedures.
>> Anytime that there's an incident,
you want to locate the policy
that addresses incident response.
Then you want to look at
the incident response procedures.
In those different procedures,
it should state what is and what is not allowed.
It should give a playbook of who to call
>> and who not to call
>> especially if you've got a large enterprise.
>> Maybe if you're in the United States
>> and you've got someone in Mongolia
>> or if you've got someone in China,
>> there may be other individuals
that you're going to have to call in as part
of that incident response plan of reaction.
Knowing who to call,
knowing what policies and procedures
>> to access are very important.
>> Then the question is,
what if you don't have
any incident response policies and procedures?
What do you do at that point in time?
Who do you call who can make some type of decision
>> in order to start beginning
>> to work this incident and remediate it?