-: Finishing the response.
So, we've gone through all the steps of the response.
We've eradicated it, we've recovered from it.
Now, what do we do?
We're done, right?
Well, not quite.
There's a couple more steps we wanna do
now that we're back to normal business operations,
and that's going through
the change management response process,
the lessons-learned process, and the final report.
So, as incident responders, one of the things
that we do is when there's an incident,
we start making changes quickly through
what's called an Emergency Change Management Board.
This will give us authorization
to take a lot of different actions we need
during the incident response with having to go through
the normal long change management process,
but now that we're done with the incident response,
we need to go back and follow up
to make sure all the changes to be made
are now documented properly.
That means we wanna make sure
the network diagrams are updated,
vulnerability scan profiles have been updated,
and all of the other things
that normally would have occurred
through a change management process are now gone back
and all those Is are dotted and all those Ts are crossed.
We wanna make sure that we're doing everything the right way
and going back through
that change management process will do that for us.
The next thing we wanna do
is what's called a lessons-learned,
and a lessons-learned is basically a big session
where we start documenting the details, the root cause,
and the solution to a particular incident that we had.
We're gonna through and conduct
this big fact-finding meeting
and we're gonna conduct this as close to the end
of the incident response as possible.
So, we've just conducted the incident response,
we've all been working 12 to 18 hour days
to clean up the mess,
and now, before I let you guys go home,
I wanna sit you all in a room for a couple hours
and pick your brains.
I wanna figure out what did you do, what worked,
what didn't work, how can we do things better next time.
All of these needed changes need to be identified
during this lessons-learned process,
fed back into resourcing, through management,
and into the change management process
because maybe we go through and we say,
when I was conducting this incident,
I found out that we're still running SMBv1
on a lot of our Windows servers.
We should change that.
Well, that might require new resources.
That may require additional funding.
That may require us to make configuration changes,
which go in the change management process.
So, all of those things we found during the lessons-learned
and they'll get fed into our last step,
which is the final report.
Every incident you do should finish
with a final compiled written report.
This report will establish organizational memory for you,
so that in five years, if I'm no longer with the company,
you can pull up this report and go,
ah, when Jason did this incident response,
here's what he learned
and we should take those things into practice.
This can serve as documentation
in the case of any further legal action as well
because maybe, the police officers
have now found out who did the attack.
They can pull this final report
and use information from that.
You can also identify other deficiencies
that were in the incident
that need to be addressed by management.
Again, going back to additional justification
of why we need more responders, why we need a bigger budget,
why we need to spend more on security systems.
All of that can be addressed inside this final report
as we collect our lessons-learned
and bring them back into management.
The final report should include a lotta different things.
It should include a timeline of the incident
and the response events.
When did we notice it, what did we do about it,
how did we fix it, and when?
This should also include the incident,
the root cause of the incident.
So, how did the bad guy get it?
Was it because we didn't path something?
Is it because we didn't have a firewall in place?
Is it because of a user error?
Those are things we wanna know.
We wanna know the location and description
of any evidence that we collected.
So, if I said, well, this computer the user used,
clicked the malware, that was my first point of entry,
it was located in this room, this building
in this type of machine.
Actions taken to contain, eradicate, and recovery.
All of those things and reasons for them
should be documented in the final report.
Again, going back to that organizational memory.
Why did Jason, who led the incident response team,
do it this way and George,
who led the other incident response team last year,
did it that way?
These are things that can be found in the incident report.
Your estimated impact to the organization.
So, when you write the final report,
you should have something that says,
this cost us x amount of man hours.
You know, if we just spent three weeks
going though this incident working 18-hour days,
that's a lot of money for the organization.
How much time did it cost us,
how much money, and how many people?
Those are type of things that you wanna capture
inside this final report.
You wanna do a post-validation recovery.
You also wanna do a post-recovery validation effort results.
So, we've now scanned the network
and based on the changes we did with recovery,
we are now more or less secure than we were before
based on the vulnerability scans.
And then finally, you wanna document your lessons-learned
because again, those feed into this.
One of the last paragraphs I usually put in my final reports
is based on what we've learned this time,
I recommend blank, blank, and blank,
whatever those three things are that we should do,
those lessons that we should learn and implement
as we move forward.
That's the idea here is we gotta finish up the response.
You're tidying up those lose ends.
You are going through and you're doing your lessons-learned,
your after action, and your change management process
to make sure that we are ready
for the next incident to occur
and put this one behind us and into the books.
(electronic buzzing)