Hello, my name is David,
and welcome to Post Incident
Response.
We're moving here through Episode
four into Lessons Learned, which
is one of my hot topics,
so I can hopefully keep the short
for you and not ramble
too much, because like
I said, this is an
important topic for me.
A very important topic to
skip skipped too much.
We all know that we need to learn
from our mistakes.
It's everybody acknowledges
that, but rarely
do we even do that in our
real lives.
I can't tell you how many times I
watched somebody make the same thing
and I'll say it, same stupid
mistake again and again and
again.
And the same is true here in the
incident response world
cybersecurity.
Why do you think we keep seeing
companies get hit with ransomware?
Because we aren't learning from our
mistakes. Now, you see them already
going on around here.
I don't want you to be that person.
And you need to be the change
use kind of the colloquialism out
there, be the change, be
the one that ask when are we going
to do the after action?
When are we going to do our lessons
learned?
You may be told to shut up, you may
be to on the corner.
Don't let it cost you your job,
but be the evangelist for this,
be the one that says we have to do
this. We can't just keep making the
same stupid mistakes over and over
again. It not only will frustrate
you, but it will harm
the company that you're working for.
So step up here
be the change
you're looking at. It needs to
include all the participants in
the incident itself and also in
the recovery process.
Everyone.
Yeah, I know that could be a huge
list.
And most of the time
these that I've been involved
in our remote or
could involve even several
different lessons
learned meetings, because
in one case that I can
think of for myself that involved
well over seventy five different
people. So we actually had three
different meetings with around
roughly twenty five people coming in
for each meeting. Now there were
some repeat attendees,
but we made
sure that anybody who was involved
in that incident had
a voice at the table during
the after action slash lessons
learned and just make
a short note here.
All use those terms interchangeably
after action and lesson learned.
You can even include multiple
incidents in the same after action,
if possible.
If there are shorter incidents,
not major breaches, then yeah,
you could actually do a couple
of them all at the same time,
especially if they don't include too
many people.
But weigh that carefully.
You don't want to lose the overall
effect of learning
from your incidents by trying to
cram too many
incidents in the one meeting.
Once the incident has been
closed, the next step should
be the after action
again, include everybody that
was included in the incident
process, even if they have to
do it remotely and call it.
The whole purpose of the step is to
improve your posture, your security
posture, and also
to enhance or increase your
response and protective
capabilities.
Really,
no incident is truly
closed until you have completed
your after action.
And I know far too many companies
ignore this step, but that
is true nonetheless.
And that's why you see companies
getting breached again.
Now, the format of your
lessons learned meeting can vary
widely from company
to company.
A lot of it may depend upon the
personality of SASO or your
executive leaders.
They may have a format that they
prefer and you don't want
to go against that and have yourself
do what your boss wants you to
do. It's great that they want
to do, but the format
should be chosen. That best helps
your knowledge.
It allows everyone's voice to be
heard. Anyone involved in
the incident should be able to speak
freely in these meetings.
I've seen meetings where
lowly stock analyst
Tier one only been on the job
for eight months, had one
of the greatest insights ever
into an incident and how to prepare
against future incidents.
And they were allowed to speak there
in the meeting to the sister,
who was the sea level executive
for a global company.
And that was fantastic.
Whether it be positive
or even
negative, they should
be allowed to speak without
receiving any kind of
back.
Think of the whole whistleblower
scenario.
There are pros and cons to that.
But in these after action reports,
let them talk because
you need to hear about the negative
and the positive so that you can
take action in order to
correct problems and then discover.
Now, if you delay this too long,
you're going to lose a lot of the
knowledge that
was being gathered and
gained from the
process itself.
So don't push these back six
months, seven months, eight months,
because people are going to forget
what they did. They're going to
forget what they learned.
The passion is going to dissipate
and they're going to become
just an exercise in futility for
people and thus go against
your purpose.
So what do you want to cover in
these after actions?
Well, basically, these are easy,
right? What happened?
Good grief. Every asset manager
should be doing that, should be able
to provide that,
whether it be a PowerPoint or
whether it be the written report,
whatever.
I've seen timelines develop
that were then put into a PowerPoint
presentation. That was a fantastic
review. We're.
Procedures followed
the incident response plan and throw
it up on the table and say, let's
walk through it and see if we would
expect these things to run a couple
hours, they're not going to be sure.
And if you're a C-level executive
listening to this, your
people launch provide them
with coffee and donuts or something.
I mean, help them out here
where the procedures adequate and if
not having been updated
and they
go through what information should
have been produced quicker,
we're any steps or actions taken
that hindered the response or
recovery that can be technical
or personal.
If you've got personality conflicts,
these after actions are the place to
reveal them and address them
and fix them.
Remember the example that I gave of
the security analyst and
the exchange admin screaming
at each other across the table?
Thankfully, that wasn't a real world
incident, but if that's allowed
to fester and
rot, it will harm
the entire response process.
Don't let that kind of thing happen.
What could you have done differently
is another question that could be
addressed and asked in after action
reports document these things.
The incident recorder is there.
The answer? Reporters should be
writing up an after action report
and any assignments are made
to make corrections and amendments
and changes.
Then that should be included
in the after action report as well.
How could information sharing be
improved both internally and
externally?
For example, when
Sony was breached,
they lost all ability
to communicate.
Their email servers were down,
their cell phones were down.
They had to actually go into a
closet and dig out old BlackBerrys
in order to be able to communicate
with each other.
That should be identified in
an after action report and then
corrective measures.
How about externally?
How did you operate working with
your auditors or with
Heffer or
somebody? The FBI are now
being kind of US centric here, but
that's where I live, wherever
you might live.
Ask yourself that external,
who are we dealing with and how
could we improve the communication
process?
What new corrective or protective
actions can be established and
implement, identify and
document?
How could you improve monitoring?
There's a whole host of things that
you can cover.
One big one that I like is what
additional resources
could be purchased and implemented
to protect against future attacks.
Then again, I already hit this, but
I dropped it in here again anyway.
Should be an open speech.
Policy, honesty and clarity
should be sought after
and.
Promoted from everyone involved.
That's the only way you're ever
really, truly going to be able to
deal with the problems that you're
facing anyway.
Well, are they formal or informal?
Again, that depends upon your
internal.
Corporate environment and
thought processes, some
after actions, have included third
party providers, and they may be
more formal because of that, but if
they're internal, they can be
informal and allow
for more freedom of speech and
thought. Now, if you have third
party providers involved, remember
your privacy issues.
So you may have to be careful
what you talk about, what you don't,
what time per incident.
Some people like to include this
in their after action, so I'll leave
that up to you.
But I did want you to know that it's
available so that you
can help create a timeline and then
manage future incidents, some
other items to include review
existing policies and procedures for
gaps. Did you actually identify
the cause and
any remediation steps taken should
be covered?
Was it leftovers of a previous
incident? And if so, why wasn't that
dealt with?
Thank you very much.
That was a quick overview of after
action lessons learned.
If you have any questions or
comments, ideas throughout the
day, be one three five Siberry
not too soon.