-: Well, it seems like these days
you can't turn on the evening news
without hearing about some company
who just suffered yet another data breach.
And that's when it hits you,
you're in the information security business.
That means one day, it could be you
who's trying to conduct an instant response and recovery.
Well, try as we might, we can never
make our systems 100% secure.
And that means eventually you're going to have to
perform an instant response and recovery operation.
Now, it's important to realize that how you decide
to handle this issue during that critical time
is going to determine how bad that incident truly becomes.
Personally, I've led numerous incident responses,
and they have not been something
that you should be looking forward to doing yourself.
They are stressful.
They include days without sleep.
The constant threat that the bad guy
is one step ahead of you and that you may not
have fully routed them out.
But, I digress, and I'm getting a little off topic,
so let's go back to the topic at hand.
Let's talk about some basic definitions
around this topic of incident response.
First, what is an incident response?
Well, an incident response is a set of procedures
that an investigator follows when they're examining
a computer security incident.
These incident response procedures
are part of your organizations overall
computer security incident management program.
This program should consist of the monitoring
and detection of security events
on a computer network and the execution
of proper responses to those security events.
Now, every organization has their own way
of doing incident response.
But, a basic six step procedure looks something like this:
Preparation, identification, containment,
eradication, recovery and lessons learned.
For the exam, you want to know these six steps
and you want to know the right order,
because you're going to get questions that look something like:
"What is the third step of an incident response?"
Or, "You've just done X, Y and Z actions,
which step are you in?"
Or, "Rearrange these steps
into the proper order for incident response."
And you'll have to move little blocks around
to put them in order from one to six.
Now, first, you need to conduct preparation.
And this is the preparation phase.
It's during this phase that your organization
is going to insure that it has a well planned
incident response procedure, a strong security posture
and a knowledgeable chief information security officer
who's able to limit the damage to data
and the companies reputation if an incident response occurs.
Now, we aren't waiting for something bad
to happen without preparing.
We can't do that.
Much like a disaster recovery plan that we have
for a fire or a flood, we need to be prepared
before the incident occurs.
If you wait until the incident happens
to start planning and reacting,
you're already going to be so far behind the bad guy.
It's going to take you forever
and you're going to have lot of damage.
Second, we have identification.
Identification is the process of recognizing
whether an event is actually going to be categorized
as an incident or not.
There are a lot of events that happen
on a network on a daily basis,
and some of them are minor, and some of them are major.
Your security analysts are responsible
for determining if something is an event
or a larger issue that we would categorize as an incident.
If it's an incident, we then move into our third phase,
which is containment.
Containment is focused on isolating the incident or problem.
For example, if we had a data breach
and it was being conducted actively,
somebody's currently stealing information
from our organization, I want to contain that.
I want to stop them from taking more data out.
And so, that will prevent it from spreading
further and creating more damage.
Similarly, if you have an incident
where you have malware on your system,
you want to be able to terminate the network connection
to prevent it from spreading out
to other machines on your network.
Your fourth step is what's known as eradication.
And this is the phase where
we're going to remove the threat or attack.
For example, going back to my virus example,
let's say I have a virus on the server,
I want to be able to eradicate it,
which means I'm going to clean it out
and remove it from the system,
and make sure the bad thing is gone.
That brings us to out fifth step.
And our fifth step is recovery.
Recovery's focused on making sure
we do data restoration, system repair,
and re-enabling and servers or networks
that we took offline during our incident response.
Basically, I want to get everything back
to a normal operating condition like it was
before we had the incident, except,
I also want to make sure I add
some additional security so that the bad thing
that happened doesn't happen again.
Our sixth and final step is known
as the lessons learned process.
Lessons learned is a process that we use
to document the incident response process
and we make any changes to the procedures
and the processes that we used
that we want to make sure we do better next time.
Basically, we all gather around a big table
in a conference room, and we start at the beginning.
We say: What caused the incident?
What was the route cause?
How did we detect it?
Did the detection work well?
How did we respond to it?
Did we respond to it well?
How did things go during the cleanup?
How about the recovery?
How about bringing it all back online?
Now, based on that, what can we do better next time?
After all, there are no regrets in life,
there are just lessons learned.
(soft electronic music)