Once the incident has been detected, classified,
and we've tried to contain it, we want to then eradicate the problem.
In this case, eradication where we remove the damage,
the damaged system or software,
and rebuild the system maybe from backups or making sure that we
have a clean backup that is not infected as well and apply any
patches that were missing that maybe allowed the attack to
happen in the first place.
In some cases today,
the problem is that many of the attacks will
actually affect the hardware itself, and there has been a number of cases,
especially with ransomware,
where it's actually required to actually replace the hardware because it's
impossible to remove the infection that's in there reliably.
The idea of restoration is we want to get back to normal,
and of course,
part of getting back to normal is to recover the
things that are most important first.
We set out timelines and priorities for recovery.
It's important, though,
that we don't just get back to normal and become re‑infected.
So we need to take steps to make sure that we've identified the
actual root cause of the initial infection and taken steps to
prevent that from happening again.
We've talked a number of times about documentation and sometimes the
documentation of the incident is the most valuable thing we have.
It outlines the steps and procedures we are to use in the recovery process,
but then it also documents what we did so that we can
make sure that we can review it, what went well,
what could be improved,
are there decisions that would have been easier to
make if we'd had more information, for example.
So we keep this documentation in order to assist in reviewing the feedback,
and of course, future incidents.
If we've already addressed this problem once,
it's really good if we know how we did it and we don't have to
reinvent the wheel and try to find out how to make that same repair
again or repeat even the same mistakes again.
Reporting is important.
We should obviously report when the incident is over and so that
everybody knows that this is now finished and completed.
But part of the report should include our analysis
and assessment of the incident, what caused it.
It could be more than one thing.
It could be many small things, not one big thing.
We often say that the problem is that organizations
look too much for the trigger,
but the trigger was just the spark that started it.
That was a small part.
There were many other things that led up to the incident
before maybe that spark or trigger happened.
We document and report on what we did.
How did we fix the problem?
And certainly from all of that, we assess how the staff responded as well.
Not everybody is good during a time of stress,
and we want to know who are the people that do work well
and excel when it's a time of stress, so those are key people on our teams.
All of this should result in lessons learned.
Now the problem, of course,
with many organizations is that by the time the incident is over,
they didn't document anything, and therefore,
they don't learn what they could have learned from it.
The key points review.
We need to have incident response plans because incidents will happen,
so it's a critical capability required for every business,
but we also need senior management support when there is an incident.
It's not that everybody is guessing what should we do,
but the senior management supports the plans we have in place.
We know that the plans should be detailed and action‑oriented and
should list the procedures we will follow and it should be required
that everybody follows those procedures.
All of the team members should be properly chosen,
trained, and equipped to be able to do their job in a crisis time.
And certainly, incident response should link to our other plans as well,
such as business continuity, disaster recovery,
and human resources plans.