>> Moving on from the respond portion
>> of incident response,
>> or from the React portion of incident response,
the respond portion, we'd have three principles that
essentially correlate to the respond portion
and those are contain, remediate and ensure.
So as part of the contained portion,
you want to stop the threat so quarantine the virus,
or taking the affected system offline
or informing users to take certain actions,
like perhaps, maybe changing their passwords.
The next thing that we want to do as part of
respond is to remediate that incident.
So that could be removing the virus,
or enter unlock codes from malware,
or it could be re-imaging of system that
is infected and the next thing we want
to do is ensuring that the incident
does not occur again under
the same or similar circumstances.
That could be patching the
>> system for that vulnerability.
>> Educating users not to click on
every link that they receive in their e-mail.
Or it could be re-configuring our firewall settings.
Then moving on from our response portion,
we're going to get into the after action.
During the after action phase,
we're going to review what happened.
We're going to essentially
start from the very beginning of the incident.
We're going to create a timeline and we're
going to list the steps that we have
taken into
responding and remediating that incident
and list that central outcome
that we've achieved.
Then we're going to look at what happened after
we remediated that incident.
We're going to implement
new security policies and procedures as needed.
We're going to look at why we had an incident occur?
Was it something with our policy
or procedures that essentially
enabled a malicious actor to
take advantage of some vulnerability that we have.
Or do we need to increase security in some levels.
So if we do that analysis,
would go back to our policy.
We're looking at the vulnerabilities that we have
and the likelihood of something occurring.
How much more security doing it to
devote to prevent such an event
from occurring in the future.
Then we're going to document
>> everything that we've done.
>> We have this for historical purposes.
If we have a similar incident in the future,
we have a blueprint on how to respond to that.
We're going to report this.
So if you have that separate threat intelligence team
and they're not already tied
in to your incident response,
you're going to want to give them
that report of what happened and also
you may want to share
that with the rest of the community.
You've got to want to give this to the US CERT team.
Or if you work in a essentially have teams or if
you have cooperation with
other organizations within your community,
you're going to want to share that information
with them so
that they may also
reciprocate in the future when they have an incident,
they'll provide you information so you can hopefully
not have the same thing happen to you.
Then lastly, you're going to want
to educate your workforce.
If something has occurred,
particularly if it's the problem within
the workforce that you observed,
you're going to want to create those new policies and
procedures and educate them
on how to prevent this from occurring in the future.
Or if you've determined that something happened because
of the policy and procedure failure,
and you've had to create a new one,
you're going to want to educate
the workforce on that new policy and procedure.
This wraps up our discussion on
the basic principles and
procedures of responding to an incident.
We've talked about that react
principle of reviewing policies and
procedures that apply to incident response
after we've had something occur and we're
going to evaluate that situation.
As part of that evaluation,
we talked about doing
the scientific method to essentially ask
good questions and get answers
to our research questions and hypothesis.
We've talked about not panicking.
Sometimes if we have an incident that occurs,
panicking will actually make the situation worse.
Then collecting information that's available,
so we can formulate
the best type of incident response that's possible.
Then taking the appropriate step actions
and then as we're doing these step actions,
we want to make sure that we maintain
the integrity of the scene and operational security.
Some of the actions that we take and actually tip
off the attacker or
hacker that has penetrated
our networks or has caused some type of action.
We don't want to inform them
of the plans that we are hopefully going to take.
Then we talked about getting help.
Oftentimes, incidence may
be very large in magnitude and we may not have
the expertise that's on staff to
essentially remediate and investigate
this as an incident as required.
We may have to go out and get outside help or find
help from within your own organization
to remediate these incidents.
Then lastly, we talked about responding,
which essentially covers containing the incident,
remediating and ensuring that
that incident doesn't happen again.
To help ensure that that incident doesn't happen,
you're going to do an after action review,
detailing every thing that happened
>> during that incident,
>> the step actions that were taken,
and we're going to identify the cause of that incident.
Then once you've identified that cause,
you may end up having to go in and change policies and
procedures to help prevent that from occurring.
Or if you're going to need to go back in and
educate your workforce on
the potential actions that they can take to help
the incident or to
prevent the incident from occurring again.
Or if you've changed certain policies and procedures,
you may also have to go back in and
educate that workforce on those new policies.
This concludes our discussion on
the incident response procedures.
Just provides that basic overview.
I hope you've enjoyed the class and join
us on the next topic of discussion,
which is the legal aspects of incident response.