Hello again from the Breach Report.
It's already the second episode and I think we talked about this in the first episode.
We won't have a, let's say, 100% regular occurrence of the podcast.
I don't think that's possible.
Uh rents and i are typically yeah working a lot so um yeah maybe it's every
other two weeks maybe it's every
other three weeks i think we will see if you want to get a little bit,
uh more information about what we do and who we are and you are now jumping
in into the second episode i think it's worth to listen to the first episode
as well rents how are you doing.
Hey robert yeah i'm good yeah it's good to be back on uh our podcast how are you.
I'm very good we we wanted to record an episode last week but my voice was first
i don't know whatever reason cracked so i had to postpone the the the recording for this week yeah.
I think you mentioned you sounded like mickey mouse and we don't want that on.
A podcast robert yeah i i
have good tooling to to tune the the sound
but uh not to that level um and
maybe for your listeners we a few minutes ago
we talked about what we want to talk about today and at first we wanted to talk
about recent news but then we both somehow said the things we are seeing at
the moment at least from a new side of things at least my perspective is it's it's not that,
mega exciting at the moment yeah.
Yeah i mean it's only been two weeks right so i don't think that there is a
huge or notable events on the security side i mean it's to usually the daily barrage of
a ransom companies out there and but that has become more of a normality for
for us then then it's shocking you know but yeah is that noteworthy people can
look it up it's all over the news but yeah that's our daily business.
I mean the the only thing that I always find not interesting because that goes
on for years and years and years but I see more and more news that companies for,
um said or a ransomware group or
some other threat actors um said hey we have
data for example i think the most recent year was nokia
um we have uh confidential data
stolen uh you can buy it from us i think for 20k
was the last price and nokia now
i think today or yesterday said yeah we have no indicators for uh stolen data
and that's the that's ongoing thing someone says i have data the company says
no no no data was stolen and in the end nobody really knows to be honest yeah.
Yeah i mean i guess we never know the
full extent of some of these breaches right can
also be corporate strategy right that there's still
an ongoing investigation obviously when
you have a big name there's litigation involved there
will be questions from the media so um
yeah you don't know in what stage these breaches are um
even when some of the data is posted online
right you don't know what kind of data is that really is it old data is it new
data was it just stolen in this breach sometimes they reproduce you know old
data but um yeah let's just say that sometimes the way that these things are
handled aren't always the truth right but,
yeah you just don't know all the time.
Yeah and i think it's it's getting harder and harder to really know i mean if
if they're pulling or exfiltrating terabytes of data that's something else but
if there's only a few maybe confidential documents i think it's always also very hard to,
really do the forensics on what did really happen i mean in the end you can
maybe see that someone has the data but to really prove that they were stolen
maybe it was an insider just sending it over that could also be the case in
some of these things i think doing forensic on something like that is not the easiest thing to do.
No, no, certainly not. Although if there are clear indicators of a breach,
right, you can always do the, let's say, the trail, like the breadcrumbs and then follow that.
And if you know what data is, you know, stolen or is published online and you
know where it's stored, there is definitely something possible there.
But yeah, it could have happened months ago, right?
You just, and then it becomes difficult to prove it. But yeah,
it's just the sheer volumes that are out there as well, right?
Like every day there are dozens of breaches and you see some names are showing
up there maybe two or three times a year, right? Large companies.
And you really think about, yeah, how is that possible, right? So yeah, it happens.
Yeah, and I think that brings us to the topic of today.
We wanted to talk about a few
let's say top learnings from incident response so
when we as trend micro or other
incident response teams finish up their work what are
the the top learnings in the
end for the company that was being breached and what
are i think then the the biggest
factors to do better and i think we we
speak way too less about the things that happened
and especially the victims itself um should
speak way more open about what happened and i know there
are many constraints about that and many people are just not
allowed to speak about it but i think it
would help everyone a lot when we would speak more about the actual things that
are happening and shit that goes wrong remind me shouldn't say these words but
i think that's the best description of these things from time to time.
Yeah. Yeah. And I mean, we could go into, let's say, the process side, right?
How should you respond to an incident on, let's say, a customer organization side?
What kind of processes should you have and which often they don't?
And then of course you have the the whole technical stuff
right so the lack of either visibility
or um overtly let's
say technical procedural mistakes and um i think we can categorize those but
there are certainly a couple that um that we see a lot and that people should
be aware of you know and address timely um so yeah we can we can go into that robert.
I think the first thing we want to speak about is
preparation i think that's that's totally clear
that a good preparation helps a
lot um when when those things are
happening um i mean to
be honest and that's what i'm always telling the companies
i'm dealing with is i think you can prepare yourself
as much as possible it will always be
a big surprise in not
the best way i would say it's not a good surprise and
there will always be things happening which you
haven't expected in the first place and
i think that that's for sure and i think even companies with
hell of a preparation in terms of how they
did red teaming how they did tabletop exercises we which we will talk about
in a minute i think in the end the actual the actual breach the actual incident
itself whatever it is is always something different and things will go wrong in my own experience.
Yeah, yeah, that's true. And like you say, it always comes at an untimely moment
when you least expect it.
And hopefully, you hope never to be in the situation.
But certainly, it's not like you can plan a exact order of events,
you know, so you can prepare for a certain order of events, but it's never going to happen.
It's never going to happen at that exact order, right?
And exactly at the time that you prepared for.
So that's true. And I think incident response as well, from a company perspective,
it's about adaptability, right?
It is being able to absorb that event and also the abnormality of it and being
able to adapt and overcome those difficulties. Yeah, for sure.
I think for me, one of the top learnings during the past few years when it comes
to preparation of incidents is, yes, there are still companies out there which
aren't prepared at all for that,
which don't even have an emergency response plan or whatsoever.
But most of the companies do have some structure. I don't say it's good.
I don't say it's practical. I just say there is something. one
constant thing i do see is that more or
less only one person is most of the time really
on the one hand does know
that there is something prepared and on
the other hand more or less has the whole knowledge about
the whole process and the things that should be done in one
mind and it's more or
less always the case that this one person at this
particular day is on vacation or maybe
sick or whatsoever and for me
that's the that's the top learning when i for do it when
for example i do toy builder exercises i
now started to say to
those people i have the whole it team in the room and i say
this one person who knows everything about the emergency response
process please leave the room we are now
acting like you are
on vacation you are on a sick leave we cannot reach you that was something in
my german podcast where my guest gargana talked about and gave me the recommendation
to do this to just leave this one person who knows everything about the company
just leave him or her out of the room.
Yeah, yeah, that's actually a good exercise, right?
Take some of these things that you rely on out of the equation and then see
if you can still handle it, which is very much real world, right?
When these things happen, you make a plan and then if you rehearse it,
you might think that all of these things that are in your plan are readily available.
But the reality is that some of them will
not be available and that is part of the
incident right that's part of that difficulty that you need
to overcome um so therefore i think
if we're talking about some of these key learnings having a
plan is is obviously important right and you
have companies do a variety of degrees right you have smaller ones you have
larger ones some have a very professional sock or knock and um or sec ops right
and they are more trained i would say or they're well equipped to to do that
but the majority of the companies out there right in that let's say.
Midfield enterprise they they don't always have
that right they don't they don't invest in that or they
don't have the the funds or the people um so
then plans become pretty rudimentary um and
um yeah i think key key there as well and
we mentioned that in our last podcast is you need to test
your defenses right so not only test your technical defenses but also test your
procedural defenses so go through that plan and like you say i think tabletop
exercises are a very good one there that you rehearse okay what happens when
an incident is occurring,
and what is the what is the flow right and what is the process in order to get back into operations.
I think especially when it comes to, and that's a constant discussion I have, companies I talk to are,
sometimes very proud of their emergency response
plan in a written form so a document they have and
i don't want to complain about everything but
the typical thing i see is that these things are
way too long that they um i
would say are more a business continuity management document
with maybe 100 pages talking about
backup and restore and whatsoever and i
always try to tell them in my personal opinion i try
to reduce those first steps how to
really let's say respond to
a threat to a breach to the bare minimum because
on the one hand it's way easier to have
this in an updated form because nobody updates a
200 pages document all the time and on the other hand like restoring data doesn't
play a major role during the first hours of the incidents and i always do the
example of and maybe it's not the best example but if you have a let's say a minor car crash.
Nothing really happened but you still have maybe
a few things and you
have to go to the hospital the first emergency
responder that comes to the crash only really
takes the first measure and then brings you to the hospital it's
not about a doctor and having an
operation on the scene or whatsoever it's more or less stabilizing
the situation bringing you to the hospital and then
the real work is being done and that's always my comparison for
um for cyber security incidents
for me this document should be very short the first
question i always ask the customer and typically
they are pretty surprised by that question because they never
asked themselves of that question is what indicator
doesn't even take you
to that plan because they always think about the worst
case scenario the oh i got
up in the morning and everything is encrypted that's
always the worst case they are thinking about but maybe
it's not the worst case maybe we are lucky and we are just seeing some indicators
and then for me the first step is always about how to judge or categorize the
thing i see how severe is it because constant thing i see companies are either overreacting.
Or underreacting a lot but they always
have a hard time in doing the right
things and categorizing what they see the right
way because in my opinion everything is dependent
on that categorization because for
a for example a p3 incident maybe
a few for example a few malware
findings but they were all blocked but
you still have to investigate that because there
was a way that this malware got into the
company maybe it was an email maybe it was the
proxy that let it in you have to analyze it but
do you really need to wake up your cio
your ceo at 4 a.m in the morning for this maybe
not really but if you have a p0
because you have a more or less let's
say guaranteed access to mailboxes you
saw and there were phishing emails sent out of your
mailboxes and you see that in a transport log maybe that's something where you
should wake up some very important people so everything we do in terms of action
in terms of communication and whatsoever is always dependent on the severity
and the categorization of something we see yeah.
Yeah i agree um that visibility and being able to judge what constitutes an
incident and whatnot and what triggers a response plan that's very important
um and i think a lot of technology vendors are,
you know gears to towards uh giving you
those platforms or offering you those platforms that actually will do the risk
categorization for you right or help you with it um so you can prioritize okay
what are these important events and how severe are they and which ones can i discard.
And then yeah if it's a serious event and if that is connected to a breach then
the incident response plan needs to go and kick into action um and just coming
back to that right to that to
the previous uh topic about that plan um for listeners out there and there are
a couple of interesting models where you can start right we have for instance
the sans model and the nist model,
which is uh which is these couple of steps that you need to go through to successfully,
handle an incident um and and there's there's there's good documentation out
there that per step will you know explain to you what you need to do during that chain of events.
And then you have checklists right which you can fill in yourself which is the
beginning of an incident response plan um and like you say that all starts with
