Hello, my name is Dave,
and welcome to Post Incident
Response we
are going through after
actions.
So I wanted to do a bit of a follow
up, because the lessons learned
after actions are
near and dear to my heart and
I see them as extremely important
to the entire incident handler
field and incident response team.
And I've seen them ignored.
I've seen them skipped over
and I've seen bad effects
from that. And I hope
to exhort you
as we come through this to do a
better job with this kind
of information in
this part of the incident response
process.
I'm not going to apologize for it
because it is extremely important.
But what I wanted to do was
share a couple of complaints with
you here as well and walk through
them with you fairly
quickly to sort of give
you some tools that you can use
to help your after action meetings
and or your tabletop
exercises, because
people have exercises
that are important for
companies to perform
for a wide variety of reasons.
We don't really have the time to
delve into them in this course,
but I can't stress enough
that they are very, very
important. So let's take a
look.
This is a sample table report
for you.
It's one that I've used in the
past. So I can
zoom this in here a little bit
closer and we can walk
through it together.
Now, as you can see,
the active corporation,
just to make it more generic,
this is in a word format so you can
change it around any
way you want.
And again, this is for a table part
exercise, but
because table tops emulate
incidents I've always
incorporated after
actions or lessons learned into
my tabletop exercises
to that way, a
kind of.
Perhaps people who expect
an after action, it
also perhaps them to be
thinking as they're going through
the whole process of
where they can improve what needs
improvement both for them and for
their team and for their tools,
and then thinking
on how they can present that
to others so that
they can learn from
either mistakes or from
experiences that they
they went through rather
than just ignoring them.
So you always almost every
single report that you see summary,
which is basically a short narrative
overview of what
was done
during the tabletop here
in this example.
So as you can see, we've pointed out
three separate scenarios and
wanted to test different aspects
of the response plan and the
procedures.
So if you're going to get into the
world of tabletops and all that, it
always helps to have a real world
example that you can draw from
in order to keep it very realistic.
Now that I'm
kind of going to
this isn't really a sidetrack,
but now I've seen tabletops
that were set up.
For failure,
the team couldn't win, it was it
was an exercise in frustration,
and that's not what the purpose of a
tabletop is.
It's it's not to
be totally, completely evil.
It's built to be a learning process.
And if you've done any kind of
education, you'll know
that if all you do is
train your students to failure,
you're in real world to become
failures. And the same thing's very
true when it comes to after actions
and also tabletops.
So crappy things.
Realistically, one thing
that I found when I was building
these pops out was interaction
with the security team was vital
because it gave me insight into
their networking environment, tools
that they used as a basis
so that I could actually apply it
to them and help
them learn as they went.
So you write up your summary
to include what
happened, how it was built, how it
was designed, if necessary.
Complement where you can do the same
thing. Should be true in your after
action report, sister or
a higher level member of
the user response team.
Don't withhold praise
for your people. They need it.
Remember we talked about morale,
the U.S. response team.
And if your morale is lagging, you
really think those people are going
to be doing their utmost to help
protect data network?
To answer that is, no,
they're going to be looking for ways
to get out of work rather than
trying to do more.
And one thing that I have found
in this field is that most
people that have come into it are
very passionate about it, and
they will work harder than most
normal people, even in off duty
hours. They're there doing things
that help them improve themselves.
So don't squash that and
then help
them develop that and build it up.
Not only do you want to do
the praise, but you also need to
remember that there may be some
negative recommendations
as well that may come out
so crap that in a way
that isn't totally
denigrating the team or people
involved use it as a learning
lesson to help build them up.
The same is true.
And after actions I say, and
one after action, when I was working
as a consultant where
the entire team came into the room,
we were included as the third party
and the sisso came in and
started screaming at people
and the entire.
Atmosphere became
toxic and hostile
and there was actually no learning,
there was no improvement made.
It was horrible.
And again, I don't want you to be
that person, so don't fall into that
trap. Always identify objectives
so that you have points at which
you want to shoot
so that you can clearly document it
back to where we talked about
metrics.
This is would be your metrics to
table covid after actions
to help give guidance to
to lead you on.
Some people are able to do this
free flow, very
little guidance, very little
structure, but yet can
still guide it along with other
people. Needed a lot more detail.
And it just depends upon your
personality type and your background
and whether you can do that.
But always identify objectives
so that when you're sitting down to
write up your reports, you're
able to address the objectives and
also lay out a format for
your work and then your observations
come into play.
Same thing can be true
when you're doing
an after action.
So one thing that we noted
here was proactive
scrubbing to deal with
acts, dealing
with ransomware and other types of
threats.
Quick side note here.
We were doing a ransomware tabletop
at a company financial company,
and it was more for the
high, higher level management
teams and sea levels.
And there were about 30, 35 people
in the room as we went through
the tabletop.
And we're going along.
We get to the point where we came
up with a ransom of
bitcoins.
Just as I'm not
up on exactly what the exchange rate
is for Bitcoin, there would have
been roughly, let's say, fifteen
thousand dollars.
US
is the CEO of the company was
in the room who was partaking in the
tabletop use for that.
And he was like, well,
do we pay this legal's?
Like, No,
I don't think we can afford to pay
that.
A little voice from the corner of
the room spoke up and said, you
know, our cyber insurance policy
covers up to thirty thousand dollars
per ransomware payment.
And that sparked off an entire
conversation about
their cyber insurance policy.
The CEO had no idea
what was in the cyber insurance
policy.
That kind of thing can be discovered
and it's better to know before an
incident rather than after.
So put that kind of thing in
trying to hit on different topics
that directly deal with
your team.
And as you can see, we did two
separate topics.
What's working? Well, so here's your
section and where can
improvements be made?
And that was from
our third party perspective.
You can do that internally as well.
And then you write up a nice, nice,
short conclusion highlighting
the different things that were
covered throughout the rest of
the report.
Excuse me.
Another thing I like for my table
tops is what's called a player
booklet.
This all the way.
An example is up on our
site as well so that you can pull it
down and utilize it if you want to.
Basically, it gives the people
sitting around the table something
to refer to
and write on
to help them remember.
And if you're like me, you need all
the help you can get remembering
different things, especially when
you're going through a multi tier
exercise moving
from we broke this down by days.
So each day a different
event happened and then they
had to actually deal with it.
We like to put in screenshots to
help make
it a little more realistic.
Of course, you see full stop, I'm
sure everyone see this kind of thing
from school, too.
And then we increase the complexity
and information
as each day passed and
then increased.
Also the technical knowledge that
would be needed to adequately
respond to it. And then they could
keep these books and utilize
them however they wish to.
Just a couple of examples for you if
you want to see one.
And that was done live by
me and some other people that I
know. There's a program
up on tech and dot
com.
You can go out and watch.
It's about forty six minutes long
where we go through a lot of
tabletop and into lessons
learned at the end.
If you have any questions or
comments or insights
to share.
Zammar, be one three five.
Fantastic day.