The Breach Report

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