Network Segmentation to Prevent Ransomware: What the UCSF Attack Taught Us

You found the backup wrap up, your go-to podcast for all things

backup recovery and cyber recovery.

This week we look at network segmentation and how it can prevent ransomware from

tearing through your organization.

My co-host persona and I, uh, talked to Dr. Mike Saylor, my co-author on

learning ransomware response and recovery.

Uh, and we talk about, first off, we.

Talk about what it actually is, uh, what VLANs are, how they figure

into this, uh, the need to talk principle and also micro-segmentation.

We started with the, the UCFS ransomware attack as a good case study.

They did get hit, but they weren't destroyed basically because they got this.

Right.

Uh, we talk about how to, to do this without destroying everything.

Um, not that I've ever done that.

Anyway, just a quick note about me.

I'm w Curtis Preston, AKA Mr. Backup, and I've been obsessing over backup recovery

and now cyber recovery for over 30 years.

If that's your bag, then I'm your guy.

You're not gonna find anyone that cares about it more than me.

Ever since 1993 when I had to tell my boss there were no backups of that

production database that we lost.

Now I've written five books, a blog and a podcast.

Here we turn unappreciated admins into Cyber Recovery Heroes.

This is the backup wrap up.

Welcome to the backup wrap up.

I'm your host, w Curtis Preston, AKA, Mr. Backup, and I have a guy who continues to

surprise me at the stuff he knows about.

I don't remember what it was, persona, but just like the other day we were

talking and you were like, do you, do you, you started talking about

something else where you're like, are you surprised that I know this?

And then, it was something yet again.

I'm like, of course you are aware of the, I don't know what it was,

but something persona, Molly Yondi.

How's it going?

Persona,

I am good.

Curtis, you know what it might have been, was it our discussions around POE?

probably was about P oe.

Yeah.

yeah.

The, exactly the power over ethernet for those uninformed, I've been,

I've been living POE quite a bit, lately because I've been, re, re.

Basically reinstalling, you know, replacing all of the

cameras in a, in a, yeah.

Updating, thank you.

Updating a, a p OE based security camera system for a preschool.

And it's been, it's been a journey.

and, lots of, lots of time on ladders and, you know, good times.

I have yet to, you know, fall or anything.

I have drawn blood at least once.

But anyway, so.

It is expected.

but anyway.

And then we have our Intrepid cybersecurity

professional, Dr. Mike Saylor.

How's it going, Mike?

Well guys, thanks for having me.

Yeah, I am, you know, no one at home knows how much effort we went

into today to get you to sound

we were having, we were having so much difficulty.

microphone, troubleshooting.

Yeah, that was, something I, yeah,

But, but wait.

Curtis, before you go on, I think

yeah.

You should probably sort of give a bit of background about Dr. Mike

Yes, yes,

I know we have, we've been having him on a bunch recently on the

yes.

I think it might be worthwhile.

Yeah, so Mike is the, co-author on this book here, learning

Ransomware Response and Recovery that was published just last month.

Although he and I are still, it's, it's so new that he and I are still waiting

for our own little copies and, it's gonna be like a competition, like a, like a,

we need a. We need a, a pool to see who gets their, who gets their copies first.

Mike, of course was the, he did the cyber part of this book, and I did

the backup and Dr part of this book.

And, honestly, I think it was a, it was an incredible, I was about to say marriage.

let's not do that partnership.

Incredible partnership.

And that, Mike, I don't know if I told you, but the, but the, the.

Our editor said that she had actually never seen a team that worked as

well together as you and I did.

because I mean, you, it was such a clear delineation of expertise.

and you clearly know your stuff.

I clearly know my stuff.

And, this is one of those books where you really need stuff on both sides, right?

And, many of our,

like

what's that?

And it doesn't feel like two separate books.

Right.

we, we worked really hard to keep the voice consistent.

and, you know, that was, you know, Mike is clearly way smarter than I am, so I just

have to use lots of big words when I talk.

So, but yeah, so that's, that's, why Mike has been visiting us so much

on the podcast and will continue to do so for the foreseeable future.

Today we're, gonna talk about another cyber related topic.

And Mike, why don't you start us off with a story.

there's, there's so many good stories, but one of the stories we'll talk about is, a

healthcare, healthcare related, because.

they are one of the high, highest, targeted industries,

for a number of reasons.

one, it's easy to leverage them if you can bring the hospital down and, you want to.

You wanna get paid in return for restoring hospital operations.

That's, that's good leverage.

patient data is pretty valuable, both from a identity theft perspective,

but then believe it or not, big pharma and some of these other less than

reputable companies are willing to pay for patient like oncology reports

and like, what could we sell this person, or what data could we use to.

I.

Promote our new drugs or, or procedures.

So there's a lot of reasons for that.

But nonetheless, university of, California, San Francisco, u

U-C-S-F-U-C-S-F.

you know, in an industry full of acronyms, sometimes I get 'em wrong.

so University of California, San Francisco, got hit with ransomware.

When was this?

how it happened, but.

when,

Yeah.

it's probably like five, five years ago,

Yeah.

maybe.

which is, which is another, another.

of the, of discussion is, you know, the, even, even though it's been

five years, the, the way bad guys compromised them and, and how that

whole thing went is still current.

it's still stuff that happens today and yet, you know, tomorrow, you

know, it's nothing, nothing that we've done in the last five years

have has helped mitigate this.

And in this particular case, it was, what we believe or they believe

to be, compromised credentials.

so it wasn't a phishing attack.

It wasn't, you know, bad guys, you know, truly kicking down the door.

it was, it was likely remote access or VPN credentials that were,

were harvested some other way.

whether they were easily guessed or, you know, former employee didn't

get turned off, that kind of thing.

so ransomware group got access, deployed their ransomware, and, you

know, people started having a bad day.

The good part of that though is, I think the topic of today,

which is network segmentation.

this environment was very well segmented for.

Any number of reasons.

One of them could just be compliance, hipaa, HIPAA compliance

and healthcare, strongly advises.

If not, in some cases, when with regard to confidential or sensitive

information like healthcare records, requires, segmentation, this group.

Did very well at segmenting their core IT environment from their,

healthcare operating environment, from their lab environment.

And so when, when one part of that network got infected, it

was contained that segment.

Mike,

and that's one of the reasons why this DISEN environment

didn't completely shut down.

and Mike, for some of our listeners who may not be as familiar with the

network side of things, could you provide a bit more context around

like, what is network segmentation?

Why is it important, that sort of thing as we walk through this.

Sure.

and there there's a, there's a number of analogies we can use in the,

in the book we talk about kind of comparing it to a warehouse where

you'd have different sections of the warehouse, even if it's just two.

You've got the office air condition section, and then The warehouse

on air conditioned section.

in my case, when I worked at a warehouse, at least the bathroom

was in, was air conditioned.

So that's where I went to take my naps.

But, in, in company environments, if you can, if you, and, and it's not just for

security, it's also for management and maintenance and, and bandwidth control.

I mean, there's a lot of benefits to network segmentation, backups, And

there's different ways to approach it.

So there's strategy behind this too.

It's not just, you know, marketing has its own segment, or the first

floor is a different segment than the second floor, or your, your

production network is a different segment than your voiceover IP network.

idea is how do we.

Organize our environment from an operations and management perspective.

So now we, we can truly measure and manage network traffic,

anomalies, troubleshooting.

from a. perspective whenever we create these segments.

We can also apply access control rules depending on the hardware you have, the

network hardware, so routers and switches.

we can, we can control who can.

Who can access that segment.

so marketing or, or, you know, maybe, maybe we put a HR and

legal in their own segment.

So in payroll, you know, maybe accounting.

So the rest of the company, you know, that doesn't need to worry themselves

about paying the bills and, HR records and, you know, legal holds on, on data.

all that stuff is, is truly protected.

Or depending on your business, whatever your, your prize drill, your, your.

Whatever your prized jewels are, you know, your data, your, logs, your fi,

whatever it is, intellectual property.

Put that in a secure segment or container, you can think of it that

way too, and restrict who has access to it and what can happen, at, at

a lot of different levels, right?

It's not just, it's not just the user, it's also the type of network traffic,

the services, the, the protocols, the, you can even limit bandwidth.

there's a lot you can do, when, when you look at that

type of, network architecture.

Strategy.

They think that

probably easily, easily associate with sort of wifi

networks, having like the guest

the

that you hand out to

hand out to every client,

they get.

No

get no access to.

other than the internet versus like people who might be logging into

like the corporate network or their home network where they have access

to devices and they're streaming things and other things like that.

And guess what?

For those of you that're like, I will absolutely never do network segmentation.

If you have a. Wireless network at home, and you've, you've separated, you know,

you know when, when, when your neighbor's kids come over and they can't, they

can't access your, your, your secret lab.

You've only given them internet access.

You've done segmentation.

That's what I

Interesting.

it does cause issues sometimes and

Yeah.

we'll talk later about firewall and how do you connect these

segments and all the rest of that.

But yes, it does lead to some issues.

Yeah, we have, we have tenants here at the house, like we have,

we are renting rooms out and I created a guest network for them.

And then of course they wanted to print and I was like, dang it,

printer's on the wrong segment.

which meant that either I have to give them access or I have to, I have to go on

the guest network to print whichever, you know, one, one or the other is gonna work.

so.

And, and by the way, luckily this recording was segmented because I

just got a call from my daughter and I was able to take that without,

destroying the rest of the recording.

You know, if you, you know, your, your adult daughter calls, you know, you

got, you gotta take the call, right?

That doesn't happen all the time.

so let's talk about, hang on one second.

Yeah.

Okay.

So am am I right in assuming Mike, that the key.

tool in network segmentation are VLANs.

The, the key tool is network, a network devices that would support segmentation.

All right.

Yeah,

old school way is still just as effective.

It's just not as easy.

It's not a, you know, it's not an interface that I can log into and

just drag and drop and click buttons.

I've

right.

line, right?

So

So let, well, so let's, let's go back.

Let's go back to that old school way.

The old school way.

It was literally, you gotta switch for this, you gotta switch for this,

and never the twain shall each.

Is that what you're saying?

And that, and that.

Now we have, VLANs.

What, what is a vlan?

Well, a VLAN is a capability of a switch.

So newer, newer switches, and I say new, but the, you know, the

VAN capable switches have been around for 10 or more years.

New to those of us with with gray in our beards.

So the, the older switches still could do segmentation, but you would have to.

You know, you, you'd plug a console cable into the back of the switch and

you, you would bring up a, a command prompt and you would have to physically

type and know what to type the commands and the, the configuration of, of

the segments that you want to create.

And, you know, heaven forbid, now we've gotta add security with

access control and other things.

That's more typing and more things you have to know and, and.

You know, it, it prone to mistakes.

and from a backup perspective, also something you would want to back up.

So if that switch died and you need to put a new switch in, you've got a a, a backup

of, of that config for all those segments.

'cause if you don't, then your network is broken and everybody's upset.

the newer switches, newer even, you know, being around 10, 15 years, it

you, you still log into the switch, but you can do it over the, the network.

You don't have to have a console cable.

You just, you hit the IP address, you get a nice user interface like a webpage, and

there are tabs and buttons and to fill in.

And as you interact with this interface, it's writing all that code in the backend.

To create these VLANs, and now it's, now it's a, it's a graphic, you know,

dashboard that shows you all your VLANs.

You can name them, you can apply restrictions, you can do reporting.

I mean, it's, it's, it's pretty, it's pretty easy to use.

And so with VLANs, right, you're basically creating those segments that you have.

Talked about earlier, right Mike?

So you might have a say a VLAN N ID of 10, which is your production network.

Maybe a VLAN ID of 20, which is your guest network, maybe a VLAN n

ID of 40, which is your HR network.

And in most cases, once you configure it, VLANs should not cross

unless you give access for them to communicate with each other.

Now, I know there are some systems out there where once you create a

vlan, it allows traffic by default, which isn't always the best approach.

Right?

It's, I know Curtis, we've talked a lot about sort of, okay, shut everything

down and then sort of add things back, and so I think from a VLAN perspective,

yeah, you want those isolated except for the things which should be

allowed to talk across each other.

You're right.

And, I think, I think the, the majority of devices that, that support

VLANs do, Unrestricted by default.

So it it's gonna start with, everybody can talk to this segment.

And so, and, and I don't think we've, you know, VAN stands

for Virtual Local Area Network.

and so when we talk about segmentation, you know, within this, this

company network, got the local area network, the land, and when you

create a segment by itself, it's not necessarily a different land.

When you restrict it, it becomes kind of a lan.

so because you've gotta have access to it, just like you would the

normal, the normal company network.

Well, very similarly when we talk about VLANs, because it's virtual,

I'm not adding new hardware.

I'm just adding.

Or taking advantage of the capability of this new switch,

this new router, this new gear that allows me to virtually configure.

And the way that works is, you know, if, if you can think of a network device

and it's got all the, the, the plugs, the jacks where you can, you know, plug

in a network cable, you know, whether it's, you know, eight or 16 or 32.

When you, when you go into the VLAN console, it shows you a picture of the

front of this device or the back where all these jacks are, and you just, you click

on the ones that you want in this vlan.

So it's both physical and virtual.

Virtual from the perspective that it's applying logic to the traffic within the

device, and then physical on the front end where, know, if I, if I want something

on VLAN N one, I just need to plug it into whichever JAKs on the front of

this device I've assigned to VLAN N one.

Yeah, and there are also the capabilities, I know you were talking about the

ports, Mike, where you can have actually multiple VLANs assigned to a single port.

So you could imagine the case where you have a wifi access point, which is.

broadcasting your guest network, your production

network, your HR network, right?

You could basically have all three VLANs come in on one physical

port, but it, that port would support all three of those VLANs.

So it's not always sort of a one-to-one physical to VLAN mapping, but you could

have multiple sharing, a same, port.

Yeah.

And I, I, I was trying to think of, of a scenario where that was, you

remember you were trying to talk about the, the, the, the wireless one there,

but I was trying to think of a, of a different scenario where I would want

an individual port, you know, which is gonna talk to another device, right.

to be on more than one vlan.

Can you think of a, of another scenario besides wireless?

Well, you can think of the case where you're doing an uplink from one port

to another, or sorry, sorry, from one switch to another, or from one

switch to like an aggregate switch.

So you need to be able to transfer all of those VLANs from that need to be.

Transmitted from one switch to the other.

And so you would have multiple VLANs on a single port.

Yeah, that actually that's a, yeah.

Yeah, that's a really good, that's a really good analogy.

Thanks.

That because of, because of vlan, and again, for those that not familiar

with the VA VLAN isn't, like you said, it's not limited to a port, but

it's also not limited to a switch.

Right?

So a VLAN could be across switches, so then you've gotta have inter

intercommunication, but then you've gotta allow that communication to go.

So, yeah.

So that's, and then you might, like you said, you might

trunk multiple ports together.

When you're doing, inter switch communication, the, so what's, let's

talk about, so that I, so I still go back to my original statement, that

VLANs or the principle manner in which we're gonna implement this, but.

It's like virtualization.

Yeah.

Yeah.

I get it.

I get it.

I just, you know, anyway, so let's talk about, the need to talk principle.

You wanna talk about that, Mike?

what do, what do we mean when we talk about the, the need to talk?

So, yeah, the need to talk principle is, is similar to at least privilege.

is just a, it's a good security, strategy.

The need to talk or the, the need to access, however, however you may have

heard it, or, or you can think of it, is the whether or not it's appropriate

for an end user device like a laptop.

to be able to connect directly to a, a production server.

and there's a variety of, of reasons to determine whether that's appropriate.

but it's also an exercise you have to go through, which a

lot of organizations don't.

so identifying your critical assets, determining and based on the, that.

That criticality, you can classify them confidential, public, et

cetera, and then determine what's appropriate from an access perspective.

In this case though, we, we were talking, we opened the, the segment

with a, an example of ransomware.

Imagine a, a user's computer.

Got ransomware and they had a, a network, you know, there was a, a map drive.

you know, when whenever they turn their computer on, they look at,

you know, my, you know, the file explorer or my computer, and there's

your S drive or your U drive.

And that is an automatic, you know, scripted to a production server

based on this user's credentials.

Well, that ransomware now has.

Those users credentials and would also, by association, have access

to everything that this does, this device and that user is mapped

to like those production servers.

And so even though it's difficult and it's, it's a, it's a burden like security

is automatically scripting access to production systems is, is frowned upon

It's

Say that again Automatically.

Script automatically scripted, authentication to production

Oh, okay.

I understand what you're saying.

Gotcha.

Right.

So, and, and I, I, I can see that because if, if we think about it, would you

agree that end user, end user devices are probably the ones at most risk

of being infected with ransomware?

Right.

Would, is that?

Seem like a fair.

Yeah.

Okay.

Yeah, because they're the ones, like they're taking their laptop and they're

going to Starbucks and whatever.

Right.

And so they're, they're getting infected in that scenario.

And so this is why you have this concept of not allowing them to

directly communicate with servers unless there is a reason to do so.

Yeah, server servers are not proactively or, or, you know, mindlessly clicking on

links and opening emails with attachments.

Yeah, exactly.

I mean, we, we start deploying AI agents to do, to do more.

You know, that may, that may, there may be a phase we go through.

but currently, yeah, it's, it's

Where ser, where servers get bored and they start browsing the web.

So, so I was just, as you guys were talking through this, I was thinking

about the episode, I think a couple weeks ago maybe we had, where we were talking

about sort of users having admin access

Mm-hmm.

on their systems, right?

And it's very similar in this case, right?

It's like, hey, it's easier to just be like, yeah, users get

access to production, whatever.

I don't need to worry about.

authorizing access every single time someone needs it.

Maybe my IT shop is a little lazier, doesn't want to deal with

these issues, or the end users want certain, privileges, I guess.

And so it's sort of a bad design to say, Hey, all the users can run as.

route or admin on their personal laptops.

I think in the same way here, it's sort of like, okay, if you let them

run with full access to production, that may be a risky maneuver.

Same thing.

It's less work.

Just like you're saying, Mike, it's less, it's more work to do what we're saying.

It's more work to segment, it's more work to say servers can't talk to

laptops unless there is a particular use reason for them to do so, and they

can't talk to, you know, mobile phones and, you know, all of that kind of stuff.

but yeah, go ahead.

Well, I just, well, but it's a good idea to do so, just like everything that we

talk about, literally, there's nothing that we say in any of this, any part

of this book where it's like, you know.

Here's the thing that you could do that has no effort and great

level of reward right there.

There's just, there's everything we say.

It's like, you should probably do this.

There is a great amount of reward, right?

a great reduction in risk.

Imagine, you know, just like, again, another previous episode,

not that long ago we talked about.

If you don't have business with China and Russia and other similar

countries, then just don't let servers in anyone in, in Russia or

China communicate with your servers.

Just turn it off and boom.

Takes a little bit of effort.

Huge amount of reward in terms of making sure you're not gonna get stuff from that.

Of course, what those guys are gonna do, just hop on A-A-A-V-P-N

and pretend like they're in the us.

But you know,

Yeah,

we're, we're, we're trying to stop the stupid bad guys, not the.

So,

Not the smart ones.

about the effort, right, Curtis, and we understand that managing, managing

these environments, especially as new applications are spun up, right?

New systems are brought on board.

It's complicated, right?

You have a network admin who's probably very overwhelmed or an IT generalist, and

yes, the tools may be easier to configure it and versus what they used to be,

but it's still work, it's still effort.

You still need to monitor all the rest of that.

And so.

are managing these rules in order to allow those access.

And Mike, in some of these environments, and I know you're just gonna say

it depends, like how many firewall rules do you see sometimes in these?

Like is it like tens to hundreds?

Is it thousands?

I'm sure it varies significantly, but like these are rules that someone

created, someone has to manage right?

You're right.

I have seen quite a, quite a variety, if not the whole spectrum of like.

Just default rules and because we don't know, and then just

overly crazy cumbersome rules that actually cause problems.

and then somewhere in between, you know, there there's also layers.

So you've got your perimeter firewall and you've got, you know, internal firewalls.

You've got firewalls for specific applications or servers or segments.

there's a variety of strategy and architecture thought you

can put to deployment of.

Things at multiple layers, firewalls, one layer, segmentation's, another layer.

yeah, there's, there's, I've seen, I've seen a lot.

I've seen it.

I've seen it.

Good and the bad.

And, and not to say one's better than the other, it depends on the,

environment and, and the organization and,

There's probably a point.

Go ahead.

Go ahead.

Finish Mike.

And the people and skills that, that you need to manage it.

There's probably a point of decreasing marginal returns where like, you know,

with, you know, with 50 rules, you get, you get this much, but with 400

rules, you get this, this much more.

The, the one that I saw, the, an environment that I was at where

they had all of their applications stored very sensitive information.

Right.

And they had ano and they were, they were publicly faced, publicly

facing applications, like to the public via the internet.

And what they did a really good job of is segment, you know, basically vertical

segmentation within their environment.

So if you were interfacing with this app, you got access, you and

the, the application that you were talking to and everything that

that application needed to talk to.

Was all available to that application.

But if you were right next door and a server literally in the

next rack, and you were talking to that application, that server

couldn't talk to this server, right?

So that I, I really like that now.

It didn't end up creating.

An incredible pain in the butt when I, the crazy backup guy

wanted to talk to all the servers.

That was considered like really verboten at the time.

and, it led to a lot of fun, which, I've told a story about.

Go ahead.

I thought that was a

Yeah, it's the, it's the same story.

It's the same story.

The one that results in me losing my, you know what, and

At late

out obscenities late at night.

Yeah.

Yeah.

Mm-hmm.

and Mike, I want you brought up a very interesting point, in your last

comment, which was the skills of people.

Right.

And I think what ends up happening is a lot of what we talked about has.

So far been mainly about like on-premises networking infrastructure

to the most part, right?

When we talk about physical switches, everything else, once you start throwing

in cloud and the various ways that they protect their networks, the perimeter,

their virtual data centers, whatever you wanna call a vbcs and AWS's case, right?

All of that now adds a layer of complexity, and

now when you try to overlay.

settings, those rules would say something that also runs on premises

and communicates back and forth.

Now it gets very, very complicated, very quickly.

It does.

I'll, I'll, I will add part of this conversation that virtualization has

so many benefits and security is one of those, if something's compromised, you

just blow it away and, you know, go back to the most recent snapshot if you're, if

you've got a good strategy around that.

but for sure, whenever you're, you're talking cloud, you know, someone else's

data center, whether it's co-located or truly outsourced, You're relying on all

the controls and capabilities and and skills of the people supporting that.

That, that you don't have control over it, aside from your, your

contract, and then all of the communications between you and them.

So how are you syncing?

How are you sending and receiving?

how do we, how do we ensure that access is appropriate and how

are we monitoring all of that?

and so one of the things I was.

Touch on just from our last, you know, just the last thread, was

the more complexity you add to your environment, more overhead it's gonna

take to make sure, well one, how do we troubleshoot what's going on?

What is anomalous?

How do we go through these different layers to figure out what happened?

And then back to the skills, you've gotta have the right people.

and, and sometimes those.

Those people will tell you, you need all this stuff.

It needs to be this complicated thing.

which maybe that's because of where they came

Shiny new toys.

it in that other environment, right.

Or, sometimes the, you know, selling you this overly complex thing is, is their

way of, sometimes overselling themselves.

So a word of caution there too.

the more, the more layers and things you put in place does not

necessarily mean that you're, you're more protected or that your

operations are gonna be more reliable.

in, in the majority of cases that I've been involved with,

it's actually been the opposite.

The more complicated something is, the, the more difficult it is to

respond and truly analyze things.

It's also more difficult to manage it and keep it, keep it, keep it up and running.

Glad you brought that up because the next topic that I wanted to talk under

this, and it's related to the thing that persona just mentioned, which is the

concept of microsegmentation, right?

Where we're not just limiting things to VLANs and things like that, but

we're also saying, this application can only talk to this application, or

this applica, this piece of storage can only talk not just to this server,

but especially in a world of the cloud.

the where I, for example, have seen this when, you know.

Persona and I worked, used to work at a cloud backup company and they, they

used S3 as their target and they had, they had S3 configured so that only

their application could write to that S3 write and read to that S3 bucket,

so that even if you somehow had managed to break through all of the levels

of security, get to get to S3, it wasn't, it you, you wouldn't be able to

actually, read or write because they had.

Pre preview already configured it so that it could only talk

to the appropriate application.

So I, I like the idea of microsegmentation, but Mike, I, this

idea, you know, what you're saying is, is so true, is we can configure

it just like everything else.

We can configure this till the cows come home.

And we can configure it so that it's so good that A, nobody can understand it.

And b, we can't troubleshoot it when things, you know, when we get a,

when we get a trip, you know, that nobody understands why we, why we

got it and why we keep getting it.

the more complicated we make it.

You, you know, even though we, we talk about this stuff a lot, right?

We're, we're, we're always recommending you need to look into

this, you need to look into that.

But we still have to argue for simplicity, right?

Simplicity or complexity.

Equals risk, right?

Doing nothing equals risk, but doing way too much equals risk.

You, you have to find a balance between doing things that you can understand.

And I do think, by the way, just that, you know, we haven't, it has been 30

seconds since we've said the word ai.

I, I do think this is an area where AI can help, where you can say,

you know, potentially you can say, here are the goals that I want

to have for this organization.

And that potentially AI could make a much more complicated security,

you know, security forward network and application segmentation that

wouldn't be possible otherwise.

And I'm really curious to know your thoughts on what I just said.

The, the, that last part.

I, I agree with it.

I, I agree that AI should be a good.

Resource, for organizations to assess not only what, what they,

what they're thinking about doing, but also what they currently have.

and don't forget, and I've said it a couple times,

forget to include your people.

Whether those are internal people or your contractors, don't, don't

forget to include them in this analysis because that's critical,

especially if it's something complex.

One of the biggest risks to environments that have these complex, you know,

segmentations and layers, it, it's usually one or two people that built

that with almost no documentation.

Hmm.

and so if you lose those people, you, you're.

You're in a, I don't wanna say world of hurt, but, that's, that's a lot of

risk to bear for someone new to come in.

And I've seen this a lot, unfortunately, or coincidentally, the last couple

of environments where I've seen a new person come in, into an

environment that's overly complex.

It was usually, pretty close to an incident, ransomware or something else,

and they're trying to figure stuff out, out while the house is on fire.

And they're figuring it out, but they also don't have time to document any of it.

So it's still not documented.

But,

Yeah.

a lot of environments where all these great things are in place.

more than you need, and that person, you know, walks off the job or isn't available

anymore and there's people have no idea.

One other thing I'm gonna a add real quick about microsegmentation and, and

you touched on it briefly, Curtis, you know, this application can only talk to

that backend database or that bucket.

of times that authentication is hard coded somewhere.

You know, it's, it's, it's saved credentials or cashed credentials, or it's

in a script or, it's a service account.

again, years later, know, we're doing some other kind of audit or

assessment and we find these things and we're like, what's this for?

And nobody knows.

So we turn it off and things break, or we delete that account

or, you know, we update the code.

It's not documented.

It's hard coded, it's bad practice.

And in a lot of cases it's, it's really not necessary.

There's other ways to do this than, than some of these one-to-one

authentication, approaches.

you say though, Mike, that that example you just gave where you're using

some sort of credential or service account or whatever else, so talk to

another between two services that.

Network microsegmentation is an additional layer, like it's not an either or, right?

It's just an additional benefit to the authentication such that if someone

stole those credentials and say, try to access that server from a different

machine or something else, that the microsegmentation can help at least

isolate and protect that endpoint rather than leave it completely wide open.

Sure.

and, you know, I, I got, I got pretty granular with, with credentials,

but a step up from that is just, you know, the trust relationship.

Is it one way trust, is it bilateral trust?

I mean, that's been around forever.

and those are appropriate.

'cause that's just, that's a setting, you know?

Right.

So it that, that's not credentials.

That's a, that's, you know, tokens or, Berros ticket or whatever.

that's a setting.

And, and those are appropriate.

And those, those are, you know, very prevalent and.

And, you know, good best practice if you can put the time into making sure it's

set up right and main and documenting it.

but no, you're right.

I think, if, if you can start with network segmentation in general, put your

production environment its own segment.

Determine how to restrict or what's appropriate for other devices and

users, to access that segment.

And the, the behavior, like what does the network traffic look like?

What do the trusts look like?

in a lot of cases, you know, the majority of cases, that approach is gonna satisfy.

Your objectives, your security objectives, your resilience, your backups, your,

you know, protection from ransomware.

that's gonna do the majority of the, of the heavy lifting.

If you, if you really have sensitive systems, you know, maybe you're

A-A-A-C-P, a firm and you, you've got all this tax data, you can do more, you

can, I, I don't know that, you know.

The, the very technical approach to microsegmentation that we've been

talking about is necessary, but there's other security approaches, you know,

with, dongles or tokens, you know, the UB keys and some other things,

that could probably be more user friendly and manageable than

the very technical approach to microsegmentation that, that would

take some skill and, and some strategy.

And it's

I. Yeah, I, I think I like this idea.

Again, you know, we're in sort of the action items part of, of the, of the

recording here, and I like this idea first just sort of segmenting production from

test dev and from end user devices, right?

If we could create those three segments and then, I'd say the next step past

that is when you look at your production environment, most applications are multi.

They're, they're, you know, you start with like a web server in the front end.

Then you have a database server, an application server behind that,

and whatev whatever you've got.

You might, you might have a whole number of things behind, but you could

say, well, I, my, my devices only need to be able to talk to the web server.

They don't need to be able to talk to all these other service.

This server needs to be able to talk to those servers.

So you can start with, with sort of a basic thing like that.

Like you said, I like the idea of separating the, the dev and test.

There's no reason that the dev and test need to talk to production.

well, there's one reason I can think of, but again, that's a,

it's a, it's an occasional reason.

and I like the idea of restricting the end user devices, in their own

little, you know, land ghetto, right?

So that they're not allowed to, you know, talk to things.

Again, anytime you do this, you just have to.

you know, we've said this before.

You need a, you need a, it, it's an on high thing.

You need support from the people above you, because once you start doing

this, you're gonna step on some toes.

You're gonna, you're gonna hurt some apps and you're gonna, and, and so what you

do, you is the thing of like, we turn on the new feature and then we wait.

Right.

We wait for, we wait for people to call the, to call the thing.

Okay.

It's been 15 minutes and nobody's called.

Right?

again, I, I'll give you a story from, from back in the day.

There was this server, it was called Snazzy.

I still remember the day.

It was a little HP UX box, this little, little tiny thing.

And, I had been told a lot of times backups would break on this

box, and I, I didn't know why I, I was a brand new Unix guy.

Right.

And I was told, that when that happens, you just reboot the server.

Right.

And so one day this was happening, and so I rebooted the server and then all

of a sudden, whoop, whoop, whoop, whoop.

You know, people are literally running into the server room.

They're like, what's going on with snazzy?

I'm like, it's, it's rebooting.

They're like, that's our communication.

That's, that, that is the server through which we communicate to the

mainframe in Dallas, you know, the, the mainframe that has all our money

and we're a credit card company.

Yeah.

So you, you know, you, you're gonna break things, but you need to be prepared.

The, the management needs to prepare and they need to support you.

We're gonna do this, we're doing this for a reason, and we're doing this, you know,

in a way that, we're trying, we're trying not to step on as many toes as we can.

But, anyway, I'll step down on my soapbox.

like you said, you do it in a phased approach, right?

Mm-hmm.

those four groups, right?

Production, right test and dev end users.

And then you could honestly just leave everything open on your

production and then over time, just start locking it down,

Yeah.

And you monitor right?

Leave it open and monitor.

Right?

Mike, can you talk about, about that a little bit?

How do we monitor I vlan traffic.

How do we figure that out?

Well, there's an interface for that.

Yeah.

and then there's, there's, there's an, there's a variety of tools,

both free, like Spiceworks or SolarWinds From a network operations

perspective, you know, you can, you can monitor a, a number of attributes

of your network across those VLANs.

'cause it's, it's essentially.

at traffic and whether you have that inside a, a segment or enterprise wide

firewall all the way out to the perimeter.

but that's really just network attributes.

so bandwidth, thresholds on packets, users, machines, health.

Someone trying to print, across different, segments.

you can see all those protocols, all that good stuff from a

cybersecurity perspective.

Very similarly, you would put a a, a collector in each, within

each segment that doesn't have.

Trust.

So any, any truly segmented, part of your network, it would have to

have its own We call 'em sensors.

And then you would push all the cis log and agent data to that collector.

That collector would then meet up with other collectors and consolidate

before it goes out through the firewall to a, a cloud data lake.

And that's where

That,

run all this analysis

that be a collector of collectors?

It would be a collect a collector collection.

A

Electric collection.

Yes.

All right.

Well, hey, I think that, I think this been good recording.

we got, you know, we get in the weeds on, on how to do this and obviously

the implementation is gonna vary from, environment to environment right.

And how you actually do the dragging and dropping.

but and I think Mike is recommending that everybody just go back to

old school lands, not VLANs, just.

Sports on a switch?

no ai, no v anything.

just,

not recommending that.

back in the day.

I'll tell you, I'll tell you, I'll tell you the new, the new generation of hack.

You know, the older guys are, are, you know, they've, they've, they've

finally filled their nest egg and they're on a beach somewhere.

or they moved outta, they finally moved outta mom's house.

But, You know, a lot of the newer guys don't know how to hack some of the legacy

stuff, you know, back, you know, old IBM, you know, big blue hardware, Novell,

they, they have no idea how to hack a Novell, even though there's, there's

good stuff out there for how to do it.

so I'm not, I'm not, I'm not saying, you know, simple network, flat network

is bad as long as it's appropriate for your environment, and your risk profile.

But yeah.

any number of things, you know, segmentation, load balancers,

firewalls at the application network, even operating system level.

there's a ton of resources out there.

You just have to do the, an analysis.

You have to know yourself and what you're trying to do, what your objectives

are, and where everything is that inventory, and then figure out the

best approach to protecting it all.

Well, persona, thanks again.

you got to, got to show off your VLAN expertise there.

That this is what I've been doing at home the last couple years.

Curtis

gotta try things out for once.

All right, and once again, thanks again, Mike for, for being on the pod.

You are welcome.

All right.

And thanks to our listeners, you know, you are why we do this.

I hope you're enjoying this.

you know, give us a comment, give us a shout out, recommend the pod to

other people, and, tell 'em to buy the dang book while they're at it.

There you go.

The Learning Ransomware Response and Recovery by w Curtis

Preston and Dr. Mike Saylor.

That is a wrap.