Hello, my name is David,
and welcome to Post Incident
Response.
Welcome back. The incident handling
and then handlers, everyone
got yourself kind of like being a
dog in front.
And in some ways that's what it is.
But dealing with people and with
data and equipment
and we are going to be talking
about documentation,
not a popular topic.
Nobody likes paperwork and
the same way.
But we live in a world
where you can't escape paperwork.
I grew up in a world with a lot of
paper free digital age.
As you may remember me mentioning
earlier, I am on the old
guys. I hear
about documentation, whether
it's done digitally, whether it's
done on paper and
a written form, whatever
is extremely important to the
handling process.
And one of the biggest
ones is your plan,
your instant response plan.
But there are a ton of other
plans out there,
other ways to document things that
are going on.
You have an instant response,
forensic report.
You can have a malware
analysis report.
You can have reports
from sys admins, exchange
admins.
You can have ServiceNow tickets that
are included as part of your report.
So you can see your building, your
documentation and coming
out of law enforcement.
One of the big things that we
learned was document, document,
document. If it's not written down
somewhere, then it technically
did not happen.
And auditors are
vague on that, too.
So don't think that's just some
stupid law enforcement thing
for an auditor.
A lot of times that they can't see
it on a piece of paper in front of
them, on the screen, in front of
them. Then to them it
is a non issue.
It never happened.
So when it comes to is it management
incident response
documentation is extremely important
when it comes to an
incident, a breach,
it's extremely important to follow
your documentation.
It's not time to go the way
of the Wild, Wild West and you start
shooting in all directions.
It's time to
follow the plan.
The auditors will ask about that.
Inspectors will ask about
that. They may very well sit down
and look at your incident response,
documentation
of something that happened
during the incident.
Let's say then they're going
to look back at you. It's response
plan and see if you actually
followed it.
If you didn't, you could very well
be dinged by them because you fail
in that aspect of the audit.
I have seen that happen in the real
world. Some auditors are
highly particular about those kinds
of things. So what we need to
do is focus on documentation
for a few minutes.
Who together you have
reports, processes
and procedures.
You have emails
again, not only do
auditors check these things out, but
civil liability
could come into play as well.
I've used examples
from court testimony, things like
that, in some prior episodes,
I don't really want to bore years of
those kinds of things, but I do need
to stress it with you that this
is important to remember.
Emails can be vital.
One email sent from an
incident response analyst to a sys
admin providing them with
indicators compromised and to
say yes or no.
And then during the
follow up period, the after action,
it's learned that there's indicators
compromise weren't added
to the IEDs
or IPS. Well, then it becomes a
battle of words sys
admin saying that email
the incident response saying,
I know I sent it to you, but the
instant response was deleted
and has no record of it
and things get uncomfortable very
quickly.
So if you're in the middle of an
incident, document, document,
document, we talk about
the incident response plan.
There are
going to say hundreds, but it's
probably not hundreds.
But there is at least dozens of
templates out there on the Internet
that you can do searches for
and download and utilize
to draft your own.
The thing I want to warn you about
here is that don't
be that person
that downloads a template.
So your company logo on
it. This is our response
plan. When you throw in a folder or
a binder, it goes in your desk.
And once the NCUA
auditors come in and they ask
for your response plan, that's what
you get.
It's ridiculous and it's
foolish, but that's what
I see many, many times out
in the real world.
That's how non-technical
people address this issue.
You as the expert, the subject
matter expert or me or
ask me, can't afford
to allow that kind of thing to
happen. So I want to do
in this episode is actually take a
look at the computer
security incident response.
Now, this is just one template.
I'm actually going to load this onto
our course
so that if you want it, you can
download it and you can adapt it and
take it and use it
again. I'm already here.
Don't just slap your logo
on it and say this is it
personal and build it
the right way.
These can be as complex
or as complex as you want
to make them.
I find that they need to be fairly
detailed in order to.
Actually be adequate and useful
in the real world.
Document, history, section,
basically these things,
these reports, these plans should be
updated in multiple
ways.
After every incident, they should
be reviewed and updated
at least annually.
If there's no incident in the year,
then it should be reviewed and
updated because guess what?
The cyber world is always changing.
New attacks, new protective
measures,
new personnel being assigned to your
team or hired by the company come
into play.
So at least annually,
and it definitely should be done
after each incident.
It should be reviewed.
And then you document those reviews
and updates underneath the document
history section right here.
That way you have a record of
when you document it in an updated.
Then you need some signatures,
because this is basically your
authoritative.
This is the decree from the king
that is giving the lower
voices in the field the
authority to do certain things.
If you remember back a few episodes,
we talked about who has the
authority to unplug the system, to
shut down a Web server, to
restore a database.
This is where that comes from.
So you have some signatures
here. And depending upon how
they are titled in your company,
of course, you have managers or
whoever may have written it,
then they really important ones
would be in your director
level.
You're your VP level.
You get my mouse to line up, right.
Or your sister should
sign off on this.
These approval signatures are
important in order
to grant the proper authority
and power to your instant
responders who are going to
be asking for things like shut
down the exchange server, shut
down that database, turn off all
access to it.
It could cost your business money
and it could cause business
continuity issues.
And if the authority isn't provided
in a written format, then
people are going to be saying, well,
you don't have the authority to do
that, do that number.
In our last episode, I say the
assistant manager was a playground
monitor.
That's where that comes into play.
So you can write this up in a number
of different ways. There's always an
introduction sort of setting the
stage, providing the objectives
of the plan so that everybody that
reads it knows what is
going to be covered in the plan.
You definitely need to do.
And it's the roles and
responsibilities and identify
who is the deceased cert.
Is needed, whether it's the Sisso
or vice president or director,
the incident manager or one of the
most important roles
during an incident needs to be
identified here
so that whoever is going to
be put in that position knows they
have the authority and of course,
the document or management team
and then the policy response
procedure, which should be followed.
And these can be taken
and updated.
However you want to have that beeper
in there. So this is rather old.
But, hey, some companies do still
use beepers
identifying all the different steps
that need to be followed.
So, again, take this
adapted to your use
and whatever way and methods
that you need and whatever
appendixes you need.
So we have some task within
the instant response lifecycle,
which is is identified.
We've seen these before.
Preparation, detection,
analysis, containment,
eradication and recovery.
And then finally, lessons learned.
And so you can adapt
these however you want a
root cause analysis is important
when it comes to incident.
And then you have roles again laid
out what they're responsible for.
Again, this is going to be up
on the on the course website
so that you can download this and
review it as you will, and
pleasure and
then adapted to the use
that you find necessary
for it.
That's a quick introduction
to incident documentation
during Question Time one three five,
happy to talk to you once.
I have a great day.