>> Incident response.
The learning objectives for this lesson,
are to define each step of the incident response process,
to explore incident response playbooks,
and to detail the importance of lessons learned.
Let's get started. Here is
an overview of the incident response process.
We begin with preparation,
is where we harden our systems,
we create policies and procedures,
we also create our incident response procedure.
Then we move to detection and analysis,
where we decide if an incident has occurred,
how serious is it, and then we
would notify our stakeholders.
After that, we move to containment
where we limit the scope of the breach,
and after that, we move to eradication and
recovery where we remove the cause of the breach.
Then finally we have our post-incident activity
where we have our after action
review or lessons learned,
what did we do well and what can we improve.
Let's go over each of these in more detail.
Preparation. The first thing we would do
here is to identify
our critical systems and their current state.
We would also want to harden key systems
by removing any unnecessary services,
and making configuration changes that
help us further secure the system.
We also want to create
our proper policies and procedures,
including our incident response procedure.
What backup systems do we have?
Have we tested those backup systems?
How often do they backup?
All of that needs to be considered.
A thing I like to consider when I think about
preparation is when did Noah build the ark?
He built it before it started raining.
Then we move to the detection analysis phase.
The first step is to determine,
if an incident has actually occurred.
Is it just a false positive or has something
happened that we really need to look deeper into.
If it has happened,
then we need to classify it.
Then once it's classified,
we need to notify the appropriate stakeholders,
based on the level of the incident, who needs to be told?
Who all needs to be involved with this,
and what level of information needs to be
given to each one of those?
Stakeholders may also be different
depending on the severity of the incident.
Containment. Now that we've
identified that this is an incident,
and we've let the appropriate stakeholders know
we have to move about containing this breach.
This is a critical stage of
our incident response process.
Our goal here is to limit the scope.
We don't want it to spread any further to other systems.
We can use firewall rules or
router ACLs to help us prevent lateral movement.
Then we move to the eradication and recovery phase.
This is where we isolate the impacted systems,
and we begin to remove the source of the incident.
Is it malware, ransomware?
What we want to do is keep them
from spreading and then cleaning it.
This process may need to be repeated several times,
so that we're absolutely sure that the system is
clean and we're ready for it to go back into production.
Then finally, we have our post-incident activity.
This is where all stakeholders get together,
and we discuss what happened.
What can we improve for next time?
We want to make sure that we document
those lessons learned,
and add them to our procedures so that
next time we don't make the same mistakes.
Do any of the procedures need to be changed?
What technology might we consider
investing in to help us not happening again?
Again, this is also known as
the lessons learned part of the process.
But the key here is, this is critical,
because we don't want to keep making
the same mistakes over and over again.
If there is something
we can do differently to prevent it,
we want to make sure that it's documented
and then passed out to
all key people to help us
ensure that it gets implemented.
Incident response playbooks.
These will describe the specific actions,
that will need to be taken in
response to different sorts of incidents.
The goal is to provide clarity,
when you're not in your right frame of mind.
An incident response is often
a chaotic situation and you're not thinking clearly.
You're maybe a little bit jumped up on adrenaline.
We want to make sure we
have a checklist, or in this case,
a playbook that identifies
all the steps we need to take,
to respond to very specific types of incidents.
Imagine it this way.
Ransomware response won't necessarily be the
same as a DDOS attack.
We want to have those steps already
predefined for each one of those.
Those steps may change,
as we go through different incidents
and we go through our lessons learned.
We also are insuring that
only approved steps and
actions are being performed on this,
because we've got those documented in our playbooks.
Let's summarize. We went over
the five steps of incident response.
We also went over the importance
of incident response playbooks.
We also discussed the importance of lessons learned.
Let's do some example questions.
Question 1, this is a formal document,
that details the steps
necessary to respond to a specific incident.
Incident response playbook. Question 2,
in this stage of the incident response process,
changes that need to be made for
future incidents are discussed.
Stage 5, our post incident activity
are also lessons learned.
Question 3, in
this stage of the incident response process,
the source of the incident is
removed from impacted systems.
Stage 4, eradication and recovery.
Finally, Question 4, in
this stage of the incident response process,
systems are hardened against attacks.
We will create policies and procedures,
and also key personnel are identified.
Stage 1 or preparation.
I hope this lesson was helpful
for you, and I'll see you in the next one.