I am super excited about this episode.

We have a networking expert coming on and we talk about what to do in your network,

when you get a ransomware attack, I bet you've been wanting to know that answer.

So stay tuned.

Hi and welcome to Backup Central's Restore All podcast.

I'm your host, W.

Curtis Preston, aka a Mr.

Backup and have with me possibly my Pex consultant Prasanna Malaiyandi.

How's it going?

Prasanna,

am.

I'm good Curtis.

And just for people that's p e x, not P E C K S.

Yeah, this is the piping, the, uh, the modern

piping alternative to copper, which I think is far superior.

And, uh, You know what?

Just, just for those that are watching this on on video, which is only a

handful of you, but I'm gonna tilt my camera up and this is what my office

looks like right now because I got yet another pinhole leak in my, um, second

story bathroom water supply, which happens to be right above my office.

And yesterday I was just sitting here at my desk and I get this

drip drip on my face and I'm like,

you're like, am I sweating profusely?

Yeah.

And the pipe, the pipe is actually over there.

The, the, the joint that's leaking, it's actually over there, but you know,

the water finds its way, you know,

along a drywall seam and then it just sort of drips

down onto my face.

you know what though, Curtis, I have to say

congratulations on finally finishing your other project, which we should

tell our

my other pro.

Yeah.

Yeah.

For those who have been following along my other project is, is, I

mean, it, it's still, you know, at this point it's 98% done.

But, you know, I have put the, the stair, you know, the, the,

the flooring on the stairs.

Um, it looks really good.

Uh, it looks way better than the ceiling in this room, I will say that.

Um, and now there's the official first mess on the new floor

. There's just, as I

At some point it's gonna happen, you know?

yeah.

Well, apparently that some point is today.

Uh, but yeah, so the plumber, who is a good guy, uh, he's been here before,

um, he, um, he's talking to me about, he knows a guy that does, uh, PEX repiping

so, we'll,

Our listeners will learn all about water piping

soon in the next few episodes as we go

More, more than you ever wanted to know.

Uh, and by the way, I did check they can go through the attic.

So, um, that is a, that is a real possibility for the, um, and, um, yeah,

so anyway, um, and I just realized that, uh, my son-in-law is home today.

He's not normally home.

I just heard him making noise.

I hope he gets his bath out of the way before the plumber gets here.

I didn't, I didn't warn him.

Uh, I actually hear, I hear a bath going on right now, . So,

so that answer's that question.

Way too much information going on at depress pressing

household.

Well, listen.

okay.

Yeah, we wanna bring on our guest.

Uh, he is both, I would say, a friend of the pod.

He's also been an enemy of the pod at once.

You may recall that we had an episode where basically we just argued

with Tom without his per, without him being here to defend himself.

Um, that was over a blog post that he said, uh, something about, uh, backup

people reporting to security people.

And, uh, I

think I had an issue with that or something.

Tom has been in the industry about 20 years and he is an

event lead over at Gestalt.

It the, uh, what would you call it?

The makers of the Tech Field Day series, which, uh, uh, my

employer has used quite a bit.

And, um, uh, we're glad to have him on the podcast.

Welcome, Tom Hollingsworth.

Well, thank you for having me on Curtis.

It was, uh, it was fascinating to listen to an episode where I was, I was arguing

with somebody and it wasn't even here.

But, uh, I, I, I love, I love listening to you guys, and I've learned quite a bit.

In fact, uh, the very first time that Curtis and I ever met at Tech Field Day

back in 2011, he was teaching me about data de-duplication, and I was trying to

convince him that IP V6 was important.

And I can tell you which one of those things panned out a lot better than the.

Uh, well, you know, is it, is that the thing where

you do the nat behind the thing?

That's what I recall really learning from you was that you gotta do

if you want me to come crashing through your roof

like the Kool-Aid man, just keep

it up my.

Yeah.

Yeah.

I wanted to bring on somebody that actually understood networking

far better than me, right?

Which, which is basically many people in the world.

With ransomware attacks.

One of the things that we talk about is once you've, um, you

know, figured out that you actually have a ransomware attack, you,

you want to isolate the network.

And there there's a discussion, you know, I've been talking with with CISOs lately

and, and, and what, what appears to be the reality is that that few environments

actually do the, the actual full.

Like we just we're just shutting everything off.

Right.

Go grab the cable, pull it out quick, quick,

W. Curtis Preston:

They're actually, I know.

W. Curtis Preston:

Tom, did you ever watch, uh, alias when it was on

I've seen a couple of

and.

Okay, well there's an episode in there when they were having a cyber

attack and the, uh, what's his name?

Um, uh, Marshall Flank man comes running into the data center and he just literally

starts flipping, flipping power switches.

He's like, they're downloading all the files off the server and he down.

He just flips all the power switches off.

And so, you know, on one end there is the complete.

like networking, shutdown, like literally both internal and external, right?

Um, because, you know, once the, once the ransomware is inside, it's gonna try to

crawl around and, and make things worse.

So that's one way.

And then there are, you know, and, and then there's the, those that go, well,

well, I'm just going to turn it off, or I'm gonna unplug the cable at the

one server or the three servers that appear to be infected and I'm not gonna

worry about the rest of the network.

And somewhere in the, between those two extremes is what everybody else does.

And maybe we should also talk about basics

of networking before we jump into this to talk about the detail.

Because just

Go ahead.

Go ahead.

Prasanna,

what, what do you think we should be talking about first?

no, I think it's sort of, because what you just

mentioned, Curtis, like everyone might think, oh, all computers

are plugged into the same network.

Right?

I think it's important to talk about some of the best practices from networking,

Tom, if you could, about sort of network isolation, BLANs, other things like that.

Before we get into sort of the other side of things,

Yeah, so please explain all networking technology, period before

the good news.

,you've already talked a little bit about it because it's just

a series of tubes, pipes, if you will, that we send things through.

Uh, now the, the, the important thing to realize when you're trying to think

about how ransomware propagates through a network is to realize that, um, the

way that networks have traditionally been built is we have this perimeter

on the outside, you know, it's probably bounded by firewalls and a bunch of

other stuff, and it looks really, really imposing on the castle walls,

but inside of the network, it's a whole lot easier to get around.

And that's just due to the nature of the way that that networks operate.

I mean, ethernet is effectively like trying to shout out somebody's order

number at a fast food restaurant and hoping that you get the right one.

Everybody's gonna hear the message, but if it's not meant for you,

we're just gonna ignore it.

But the problem is, is that that allows you to propagate a lot of information

very quickly, and that's what ransomware is trying to take, uh, advantage of

whenever it's, it's trying to, uh, do almost like, you know, reconnaissance

lateral movement in the network.

So I'm, I'm looking for a whole bunch of, um, , potentially vulnerable servers

going all the way back, you know, to the beginning of my professional IT career,

I was actually working on a help desk, uh, when the S SQL slammer worm came out.

And boy, you'd be surprised how many people had that port open to the internet,

uh, because everything shut down.

And it was really weird to see that.

And you're like, well, you know, at the time I'm, I'm kind of

freshly minted in my career.

And I'm like, well, how could that happen?

And, and now all these years later, I look at it and go, oh my God,

these people were stupid because you're not supposed to do that.

But that's one of the things that people want to take advantage of because the,

the systems want to talk to each other.

They want to be able to exchange information.

That's the purpose of a network.

You actually have to do extra work to prevent them from talking to each other.

Right.

Yeah.

I think that's, you know, I, I, and the, the number of times I went in and out

of data centers, uh, over the years, I remember only one, uh, where they had

very solid internal firewalls, basically.

Right.

That, that it was very difficult to do, to traverse laterally

within the organization.

And that was actually Intuit, uh, right.

And, and it's because of what they felt they had.

Right.

They had all of this very sensitive personal data, thanks to their, you know,

they, they had QuickBooks, they have TurboTax, they have all of that stuff.

And so they had to basically firewall off systems between each other to

prevent that lateral movement that you're right by design in most networks, you

buy a switch, you buy, well, a bunch of switches, you plug everything in.

And everything talk, everything can talk to everything.

Um, and unless you do something to prevent it, a lot of those ports that

you talked about, right, just like the SQL, uh, issue, a lot of those

ports are visible to the internet.

Right.

I, I think a, another one would be a, a vCenter Right.

And Hyper V, the, that, those ports being visible to the internet, I suppose

you hear about that a lot as well.

Yeah.

I usually do.

Whenever there's some kind of, uh, a vulnerability that comes out and

everyone's like, I hope you don't have these exposed to the internet, and

you can literally hear the scrabbling as people run into their keyboards

to figure out if that's the case.

But, you know, as,

as Prasanna mentioned, I mean, we have ways to kind of like segment

networks away from each other.

And it's funny that you bring up that, that Intuit had kind of a, a rigorous

internal firewall structure because in my experience, um, companies or organizations

that are very, uh, heavily regulat.

Have much more strict internal structure.

And the reason for that is because they need the ability to say

for a fact, Curtis cannot see anything on this network because he

hasn't been authorized to see it.

Now, you can do that through software constructs.

I mean, VLANs, virtual local area networks are kind of the, the most common

way to do it, where we, we effectively divide some, uh, uh, partition on the

switch and we say, this port belongs to this vlan, so it can only talk to

other ports that are on that vlan.

Uh, but that's not even good enough for some organizations.

And, and the, the one that everybody always thinks of is Mission Impossible,

the Tom Cruise movie with the, the machine that's in a vault that's

not connected to anything else.

We would call that an air gap system.

Or you can have an air gap network a lot of times things like, um, HVAC or

management systems are air gap from the rest of the network because they

have different controls and different needs, but I also don't trust those

people to, um, secure their stuff.

So I'm gonna build a wall in front of that air gap or just completely

isolate it, uh, itself so that I don't have to worry about securing it.

And if, uh, you, you say hvac, you say things like, you know, uh, um,

environmental control systems and any security people listening to this

podcast are immediately thinking, man, those are back doors that I

can use to get into the system.

Because no matter what, they're still gonna have to be connected

to the network somehow.

And that just increases your, um, you know, your threat profile.

Right.

Yeah, it's interesting because I think most people

who think about home networks, right?

Everything's typically flat in a home, right?

Everything can talk to everything, every single iot device out there, right?

And they're not always thinking about, Hey, I got this smart light bulb.

Isn't it great?

Isn't it awesome?

And then realizing that's on my network, everything is now exposed and could

be potentially exposed if there's a security issue with that single device,

Those devices are, you know, they obviously have an IP address,

they have some kind of a control system.

You would hope that most of them have some kind of a security function that

allows them to, to securely communicate back to whatever controls them.

But multiply that by a factor of 10 for all of the devices that could be

on your average enterprise network.

And when you start saying things like, you know, access controls for those devices,

or port security like network engineering and, and operations folks, like, they

just start breaking out into hives.

because like the, the, just the amount of work that it takes to create that

level of security is its own monster.

I mean, anyone who's ever deployed a technology like 8 0 2 0.1 x, which

is effectively, I am only gonna allow authorized devices to be plugged into

this port, knows that like there's this whole enrollment process and

are you on the authorized users list?

And what happens if you're using a different device today?

And it's just, it's maddening and it, it drives people to insane to the

point where, and that's the normal people who know what they're doing.

Could you imagine an executive plugging their laptop into a network port one

day and going, this doesn't work.

And you tell 'em, oh, it's doing that on purpose because we

want to keep everything secure.

What do you think is gonna happen?

The executive's probably gonna look at you and go, I don't care.

Make

Turn it off.

Exactly.

. We don't need that.

It's getting

in my way.

Yeah,

Yeah.

Well, I know that when we, when we had, um, you know, we had a, a, a security

person on and they had a list of things that they wanted people to do that they

felt were common sense, that were, um, ways to prevent basically, sort of,

I, I think the proper thing today when we talk about ransomware is to just

assume something in your, in your world is going to get ransomware, right?

It's just, it is, I think it's just impossible to, to,

to stop it 100% of the time.

So just assume that's going to happen.

So then there's all about.

How to prevent it from activating itself, from talking to the command and control

servers and also the lateral movement.

Right?

So he

reducing the black

W. Curtis Preston:

lateral movement, right?

W. Curtis Preston:

So what's that?

Limiting the blast

radius.

So, so Tom, what, what kinds of things besides VLANs?

Because even VLANs, you know, we have the, we have the VLAN

for this and the VLAN for that.

Still all the servers within that VLAN can talk to each other.

What else can companies do, uh, with modern networking equipment to prevent

lateral movement or to basically prevent it from everything and then, and then, uh,

selectively allow it for certain servers.

Well, the first thing you have to do is you have to

realize that a completely flat network.

Is not a stable network.

I mean, there is a limit to the amount of chatter that a network can tolerate

before it starts running into problems.

Um, ethernet is not a, uh, a medium that allows for a large number of hosts because

eventually they're gonna, it, you know, it's like recording a podcast eventually

with too many guests on the podcast.

You're all gonna wanna talk over the top of each other,

and ethernet doesn't like that.

So once you had a certain boundary, you kind of have to divide it

up into these little domains.

Um, collision domains are what we call them, and that's one

of the things that a VLAN is.

But as we've learned over the years about what we really should be doing,

we've kind of built a super set of that.

And anyone out there who has been reading any kind of the tech press recently, or

been to any trade show in the last couple of years, probably heard of something

like Zero Trust Network Architecture or, or, you know, just Zero Trust in general.

It's a buzzword.

I'm, I'll be the first to admit it, but the principles behind it are fairly sound.

what you do is you take the tools that you've already been given, those ones

that I told you, make your network team break out in hives, and you try to

implement them in such a way as to reduce the complexity of the implementation.

And think about like, you know, think about a teenager and they

want a, a list of, uh, things that they can do when they get a car.

Are you gonna tell them you can do anything you want, but

you can't do this and you can't do that and you can't do this?

Or are you gonna be more explicit?

You can only do these things and if it's not on that list, you can't do it.

Well, most people would say, well, I'm only go, I'm gonna do the second

thing because I want to make sure that they're only going to school and to

work into this one friend's house.

But we don't build networks that way.

I mean, we, we typically allow as much as possible because of the

situations we find ourselves in where something doesn't work right.

And we don't know why.

So we will put a little catchall at the bottom of the, the access

list and go permit everything else.

and then we leave it.

And that's the worst thing that you can do.

And what Zero Trust Network architectures try to do is they try

to say, okay, that server over there is running our backup software.

What should it, what should communicate with it?

And how should it be communicated with, you know, maybe it only needs to accept

connections on these three or four ports.

Maybe it only accepts connections from these authorized users.

And you're effectively creating an isolation for that unit.

And if something needs to access it and you're having problems with it, the

software usually allows you to kind of dig into that a little bit and go, oh, it

looks like that this program did an update and it now needs to communicate over this

port, uh, and I need to allow that port.

But you're doing it in a, in a way that allows you to kind of control that access.

But more importantly, what happens is that when something tries to operate

outside of that access control, it slams it shut and hopefully will send

you some kind of a warning, you know, Hey, we just noticed that this server

over here is trying to communicate with the rest of the network on Port 4 45.

and I know it shouldn't be doing that.

You need to take a look at it.

And so limiting that blast radius, that broadcast capability tends

to prevent lateral movement.

And like you said, people who are going to attack you are, are

going to be dedicated in doing it.

Either they're gonna be dedicated to looking for a very specific exploit and

just kind of hauling in whatever they can do, or they're gonna be looking to

attack you, you specifically, however they can get to you that second kind

of attacker, very difficult to block.

It's like a door lock, a dedicated burglar is gonna get into your house.

You're looking to prevent more of the first one where it's like, oh, we were

able to get in through your HVAC system and boy, we're gonna turn this thing loose

and see what open file shares you've got out there and what we can do with them.

You, you need to create structure in the organization that does not allow

people to move laterally that that prevents them from accessing things.

Or worse yet, alerts you when things start doing a lot of scanning across

your network, looking for those kinds of things because the, the rest of the group

that's trying to get into your network doesn't know that stuff's there either.

They're gonna have to go looking and just like the burglars that are casing the

joint, you need to look for those people.

So multiple things popped up in my head,

Tom, as you were talking.

So the first is, as you're talking about the burglar example, I'm gonna bring this

up again for the second week, but Curtis had recommended reading The Cuckoo's Egg.

I don't know if you've read that book.

Tom.

Highly recommend you read it.

It's basically, 1980s, a hacker gets into a mainframe and starts moving

laterally across all these like military networks and science networks

because everything was connected.

And like you said, that example was go and try all the door locks and he

would try default passwords and some of these systems, like the mainframes,

people would not change the defaults.

And so he got in and it was just that lateral movement across

everything in the environment.

So that's like the first thing that came to mind as you were talking.

Um, the other thing that also came to mind is I totally get the reason to have

like that zero trust and only enables services that, and patterns that are known

to be valid and disable everything else.

Uh, my question.

As a network engineer or operations person, how do

you manage that at the scale?

Because there's so many applications, so many servers, it's hard to predict

what's going to talk with what, um, and coming up with, because

like, everything's all connected.

Like in my mind I think about like Facebook and graphs, right?

Everything is connected in the world, right?

And so everything in your network to some extent is probably

connected in some form or fashion.

So how do you sort of go about even coming up with, okay, these things

are the things that should be talking to the backup server in your example.

So it takes a lot of teamwork because as a network person,

I don't care what's running over my network, I just need to make sure that

these two things can talk to each other.

And so in a way, like if you've ever deployed a server, um, you, you have a

list, okay, it needs to communicate, uh, using this protocol over these ports or,

you know, uh, think about, uh, opening something like, I need to open HTTPS to

the server, but not http because I don't want it to ever communicate over http.

And that's actually one of the things that we've noticed a lot recently is that a

lot of protocols that used to have their own dedicated ports have now just started

writing over, uh, HTTP and https s.

Because it's just easier.

Uh, bit Torrent was actually one of the first ones to start doing this because

they're like, well, eighty's gonna be open anyway, which is the port for http.

So we'll just ride on that because most people fire, most people's firewalling

systems just allow that by default, because that's what the web uses.

And so it gets kind of insidious and you almost have to think at a higher level.

So what.

it crack open any networking textbook in the world, and they're gonna

give you this seven layer model.

It's like a seven layer dip from Taco Bell, but there's no refried

beans in the seven layer OSI model.

But we play a lot in the bottom of that, where the physical connections

happen, where the IP addresses allow systems to talk to each other.

Once we get above a certain level, that's where the applications take over.

And as networking people, we're not as concerned about that.

But boy, the server people are because, oh, you know, I need to be able to have

these two devices talking to each other.

I need to make sure this is all un impeded.

And the first thing that happens when two servers can't talk to each other is you

gotta find the network people, people.

And you're like, you need to tell me what's going on here.

And then invariably, like the security team gets drawn in because like, oh no,

we told him that he had to block that because nobody should ever be using that.

And, and you, you really do have to pull those people together.

I mean, think of, you know, think of a book like, uh, gene Kim's Phoenix project.

Like you can't work in isolation anymore.

As much as we might like to.

Because so many things are so inter interdependent now.

It's like, you know, the, the old joke is, is what does the server do?

I don't know.

Unplug the cable and we'll see who screams the loudest.

You wanna figure out what people, uh, what port is being used.

Let's block it and see who comes to yell at us.

Like, that's kind of the way you have to do some of these things.

Cuz

the other thing, and we, we all know that nobody, nobody ever

skips documentation, right?

I realized while editing this episode, that we forgot to

throw out our disclaimer.

Uh, Prasanna and I work for different companies.

He works for zoom.

I work for Druva.

This is not a podcast of either company.

It is an independent podcast.

So the opinions that you hear are ours.

Also, if you'd like to join the podcast, please reach out to me

at w Curtis Preston on, uh, at Gmail or at WC Preston on Twitter.

Or linkedin.com/i N slash Mr.

Backup.

And you'll find me, uh, we'd love to have you join and also be sure to

rate us at your favorite podcatcher.

Thanks a lot.

Now onto my silly story.

You brought up an old memory of mine.

Literally like my first months in being a cis admin, we were trying to decommission,

um, uh, the, you know, the, the, the first computer designed to run Unix was the

three BK and the at and t had a three BK I think it was like a three B 1000.

And it was their attempt at a multiprocessor architecture.

And we had this beast and we were trying to decommission it.

And, uh, we had gotten down to, we had fi you know, and, and we had gotten down

to that phase where it's like, well, we're just gonna turn it off and whoever

yells will be the one that we missed.

Right.

But I remember the, um, We had, uh, stripped it, all of, all of

its regular networking cable.

I don't exactly remember exactly why, but I remember that there was one cable

left and it was running across the floor and we were doing the last like

download of, of whatever it was off of this server onto something else.

And the manager for that cost center was in there and he

kept stepping on the cable.

And, um, we told him that he was slowing down the download whenever

he would step on the cable.

And, um, we actually caught him, we left him into data center.

We actually caught him like watching the monitor and like the throughput speed

and sort of stepping on and stepping up and off and off on the cable.

Anyway.

Yeah.

Good, good stories.

I, so the question I want to ask you about, all of the things you just talked

about, is this something built into modern networking equipment or is this, um,

you know, are these extra applications that I'm buying that then configure

that networking equipment for me?

So it can be both.

The, the basics of being able to isolate hosts and configure systems

has been built in for years.

I mean, anyone can write an a c L, right?

The thing is, is that scaling that across a large organization

is where it typically falls down.

Eventually, your security team can't keep up with all the changes.

They throw their hands up in the air and it lies fallow for as long as

it takes for you to get infected.

So the additional tools that are basically being brought to market and are, are

popular now, kind of organize that system.

They put a, a, a shiny.

UI on it, if you will, to, to go in and say, okay, I, I want to enable port

security on these ports because back when I started this port security was,

if it isn't being used, shut it off.

Just like shut down the port.

And then if somebody plugs into it and it doesn't work, well then now we know

we need to enable that port and we need to know who's trying to use it.

But now you have the ability to like have somebody plug in a device,

whether it's an IOT system or what have

you, and this, the device will like register with the system.

It'll say, Hey, I need access.

And then the system can come back and say, Hey, it looks like somebody

plugged in an S thermostat over here.

Well, that's actually a bad example cause they don't use wires, but you know, a

laptop or some other kind of device, you need to go, like check it out.

Or you can even set a policy that says, I'm going to allow you for

now, but I have the ability to just cut it off if I need to.

Or if it's one of these recognized device classes or something like that.

So for smaller systems, , you know, for, for smaller organizations, if

your IT department isn't already completely overworked, you can't

implement some of this by hand.

It's just a matter of if it works really well, that means you're gonna

be spending a lot of time tuning that system to keep working effectively.

And once you get past a certain point, the, uh, the solutions

that do this are reassuringly expensive because they're worth it.

Right.

Oh, I understood cuz that, that they would help you save the, the, the labor.

And is there a category of these types of tools that, that a

category name that we give to them?

Uh, there's, there's a bunch of different ones.

Uh, access management is typically one that you, you see, um, honestly,

tools like Aruba ClearPass or uh, Cisco ice, uh, ise, uh, integrated

services engine, or integrated security engine, I forget which one it is.

But they're, they're, they're not identity and access management,

although they can be integrated that.

There are some smaller ones that, that have these capabilities.

A lot of it is, is mostly figuring out what you need because there's

different, you know, some systems are, are configured so that you're

controlling access to devices.

I only wanna authorize people to be able to log into this

device and make changes to it.

Well, that's different than I want to change the way that people

in my network are accessing data like that is a different kind of

identity and access management.

So you need to do a little bit of investigative work to make sure that you

are, uh, properly using the right tool.

Cause if you spend a lot of money on one that doesn't give you what you want or

does a, a, a terrible job of it, then not only are you gonna be upset, but the

people that are or authorizing your budget are not gonna be very happy with you.

Now a lot of these changes, if I think about an

enterprise environment, things are easier to a fair extent to control, right?

If you're looking at servers or virtualization, other things like that.

But then I go to think about other environments like a school, right, where

you have students coming and going, right?

Or a stadium or a conference center, right?

Does it get significantly more difficult to do what you talked

about, Tom, in those environments?

Or can the same tools apply there as well?

Yes and no.

Um, I, I, I'm, I'm the typical IT nerd.

The answer is, it depends for whatever question you ask, but I'll tell you

that in some ways, um, schools and other places where your user base

is not employed directly by you.

Can have a slightly easier time if you're willing to, um, sacrifice a little bit.

So I know that there are a lot of colleges out there that treat their student

dorm networks like the wild, wild west.

We don't care what goes on out there, but we're not gonna keep an eye on it either.

So like, if

there's a, you know, a piece of ransomware or something that's running rampant

through the system, all we did is tell you that you had to have your antivirus

up to date to be able to join our network.

So,

so what, uh, the stadiums are actually a, a really interesting, uh, problem

too, because not only do you have a a, a group of users that are outside of

your control, they're very transient, um, in a lot of those places.

Like they, they actually have, uh, wireless networks that are set up

so that, um, they can only talk.

, like they block all device to device communication, which

is something that you can do.

It's a little bit more complicated, but it effectively treats, um, the stadium

itself like a demilitarized zone in a, uh, in a, in a security structure.

So for most people that are, that are familiar with it, you know, you've got the

outside internet, which is big and scary.

You've got your inside network, which is soft and, and you know,

uh, you don't want it to get hurt.

And then in the middle you have the dmz, which is basically the moat where

you're like, I'm gonna put everything that I don't care if it gets attacked

out there so that if it breaks, it can't get back into my network.

And so, but the otherwise, the other thing there is I only allow

certain traffic to come back through.

So if something bad were to happen, I can just basically cut it off and

sink it into the moat and I'm done.

Yeah, I think, uh, hotels have a similar model, right?

Where the base, uh, I know having, having plugged in multiple devices that

needed to talk to each other in hotel networks, they don't like that very much.

Uh, and you end up having to bring basically your own router if, if

that's something that you want to do.

Right?

Um, so the, so it sounded like, um, if I understood you correctly,

the access management part is this sort of basic security thing, that

there are tools that do just that, and then there's also this identity

access, which is a, a bigger pain.

I would, I would imagine.

But those that want that, and it sounds like when we put those

two together, that's what, what we call a SEIM tool, right?

Is uh, uh, identity and access management.

But it sounds like there's just an access management.

That, for those that need just that there, there's smaller and less

expensive than a full SEIM tool.

Yeah.

Not, not inexpensive, but just less expensive.

Well, and it, it also matters as to what you're spending

your resources on, because there are tools that will do this for free.

But they are not supported at all by anybody other than people on a forum.

And they'll be glad to tell you that you misconfigured something

and go figure it out yourself.

Like we, we've dealt with that.

And I'm not really crapping on the open source community because

they do an amazing job of this.

I'm crapping on the fact that open source communities are not as well supported

as the bigger players in these markets.

And that's honestly where the expensive part comes from.

You're not paying for the software, although you, you

kind of are in some ways.

You're paying for somebody to answer the phone when somebody is like breathing

down your neck because something won't work or something won't come online.

And so a and a and you're also trying to get to that point where

it's, it's not automated as much as it is as low friction as possible.

Because what you want in situations is people to just

be able to get on the network.

That's, that's the thing.

If you've ever tried to log into a wifi network that has a captive portal

that requires you to like accept a whole bunch of licensing agreements

and type your room number in and all the other stuff, you know that it's not

the most frustrating thing, but it's definitely not what you want to hear.

As opposed to like, oh, this device has already been pre-authorized cuz you logged

in with your active directory username.

Well, we'll just let it on the network.

That's completely frictionless.

But the amount of effort that it takes to make it frictionless is where your time

and resource invests gonna come from.

Tom, I know we started this all out with Curtis asking,

how do you prevent lateral movement in networks right from ransomware?

Just given the fact that ransomware does move laterally in a lot of networks?

Does this mean people are not using these tools or have not

configured the networks correctly?

Because it seems like if you did all the things that we just talked about, it

should have prevented a lot of the lateral movement that we see in ransomware today.

Well, Prasanna, I'm gonna tell you something

that my dad always tell me, and you have to understand.

My dad grew up in the country.

If a frog had wings, he wouldn't bump his ass every time he hopped.

So yes, if you turn on all of these tools, you will cut down on a lot of this stuff.

But does that mean your network's not working correctly?

No.

It just means that we didn't enable all these extra features that we have

to keep track of because I can get four, uh, four network ports on a.

and plug four devices in there and they're gonna work is the

best way for them to work.

Absolutely not, but I also don't have to do a whole lot of extra configuration.

A lot of people are looking at this from the perspective of, I need to

make sure that everything is, is able to communicate with everything else.

They're not looking at it like you, like the example you had earlier, Curtis, when

you log into the hotel wifi and I can't talk to anything else on the hotel wifi.

They're not thinking in a, in an isolation mode.

And we're, we're that ship's turning because a lot of people are now

realizing that, that that traditional idea of having a very stiff, crunchy

perimeter with a very soft internal network doesn't work so well.

Because what ends up happening is, is that once people get through

the perimeter, they have free reign to do whatever they want.

You, you do have to build these controls in place to effectively

slow them down or to herd them to places that you want them to go.

And that's what a lot of people have spent time developing and working on.

And there's varying degrees of success to make that work.

It has to shift the mindset though.

Um, you know, application people are just turn on all the ports

and I'll turn them off later.

When I tell you which ones I don't need, you won't, because you'll

get busy doing something else.

It's like developers, they're like, I'm gonna load everything I can possibly

think of in the memory so that I know the library that I need is there.

And then you wonder why your, your, uh, application is consuming

like three terabytes of ram.

It's like, uh, maybe you need to pa pair back a little bit on that.

Yeah.

So it, it sounds like these tools are there.

Uh, I think a lot of people do use them, but you talked about, like in the very

beginning, you, you said that people's heads are gonna start spinning or

whatever, because there is a lot of work involved in implementing these things.

And the moment you flip that switch from, you know, per, you know, from

everything is permitted to only the things that are permitted or permitted, uh,

you're gonna get 5,000 tickets, right?

I can't do this and I can't do that.

And they, they see that.

They see that very real worry.

Uh, and I, and I think it stops many people from implementing this

because they just see it as the amount of work they're gonna have

to do to initially implement it.

Um, they're, and they're not seeing the risk of what's gonna happen when

they get a ransomware infection, and then it just goes crazy.

Most tools that are, are set up like this.

Uh, they have a learning mode where they will, you could put 'em in place and

they just sit there and they watch for at

least the first, you know, week or two.

And they're mapping out all of these application dependencies.

So, you know, the backup system needs to receive traffic on this port for

this application from this subnet.

And then it allows you to carefully craft that rule so that only devices

from this subnet can talk to that server on these ports and nothing else.

And if you let the tool go long enough, you'll be able to like, suss

out exactly what you need to know.

But yeah, that first day you click the switch to from, you know, allow list to

deny a list is just like you're, you're staring at the ticket queue because

you're like, oh, what happens if I, if this machine hadn't been turned on for a

week or what, you know?

yeah.

Yeah.

It just, it, it, it is, it's maddening because you're always gonna wonder if you

didn't get the right stuff, but like you said, would you rather be worried about

one machine that can't talk to another?

Or would you be worrying about the fact that you're getting a phone call from

the CIO saying, uh, yeah, the database has just got encrypted by this new flavor

of malware that we haven't seen yet.

Uh, why did that?

Yeah.

Another thing I want to ask you, I wanna sort of move forward into

the, the ransomware part here.

Although Prasanna, I'm so glad you basically told us to go backwards.

You always, you're really good at that, you know, you're really good at

making me go backwards.

Uh, anyway, uh, I wanted, so one of the things, so we talked about

trying to limit lateral movement.

Another thing that was suggested was to not permit, uh, new, new either

new domains, like domains that just recently were created, or domains

that w got recently active, right.

From a DNS perspective, is that, is that still fall under the networking purview?

Um, or is that like, is that another world?

It, it tend, anything that involves names and not

numbers tends to float up towards the application team or the security

team.

Uh, and the reason for that is because, like you said, like one of the things

that, that we see a lot in security now is it's this idea that you wanna black hole

things that are, that are relatively new.

Like why is this machine suddenly starting to communicate over a d n

s name that I've never seen before?

But it also

requires that your devices have the intelligence to be able to resolve that

because, you know, application layer firewalls will see, oh, you are trying to

access this service that I don't recognize on a domain that I've never seen before.

Whereas a, a lower level, almost like a packet filtering firewall will say,

oh, well that's an IP address connection on this port from here to there.

Uh, I don't see a reason why I shouldn't be using that.

And so, You, You, kind of have to integrate those two things together

because like you said, you know, something doesn't look right here

because why would it be contacting a brand new DNS name that it should, it

has no reason to contact or worse yet?

Uh uh.

You can ask the people over at SolarWinds.

Why is this DLL suddenly talking to .ru addresses?

right?

Yeah.

Well, when he says new domain names, he actually means domain names that were

like recently registered, not just domain names that are new to your network.

And then also ones that, that were, they were registered but they had, they hadn't

been active or something like that.

So that sounds like that's a d n s uh, you know, there's a d I world, right?

Um, we had, we had somebody on from that.

I think we need to have some, because this is, I think that's, , if you can

reasonably do that, where you could basically push a button, just sort of like

the, the, the deny the allowed deny thing.

If you can reasonably say, I, I don't want, I don't want anybody

talking to domain names that were registered 24 hours ago.

Right.

I, I If you could, if you could do something like that, it will of course

also create some trouble, uh, tickets.

But I'm thinking far less.

And if you could do that, it stops to command and control, uh, you

know, the, the ransomware from reaching out at command and control,

um,

slows the

process down.

But the one thing I will say there though, is that you need to make sure

that your users are expecting that change.

Because if it requires you to go out and check a list or, uh, get some kind of

una authorization to go to this domain name, even if it adds one second to the

resolution time, that's one extra second that people are going to complain about

and you know who they're gonna complain.

the networking team, because the network isn't working.

Not the d n s block list checker or the application that has this built into it.

Oh, no, no.

It's the network's fault because the packets aren't

going where they're supposed to.

As we used to say back, back when I was, you know,

when I first said that we, we would say the problem's under the floor.

Right?

Uh, meaning, meaning it was a networking problem.

Um, go ahead, Prasanna.

So moving on.

So we talked about how to prevent lateral movement, how to detect these, uh,

rogue, uh, servers that are coming up.

One thing I wanted to ask is, so say you do get hit by ransomware, right?

They're able to move laterally.

What happens next from a networking perspective?

Well, I guess two questions.

One is how do you, how would you go about bringing down your network or sort

of isolating what needs to be isolated?

Like how do you actually figure out what's going on in your network?

And then the second question is, okay, now that you've sort of

identified that, how do you slowly recover from those situations?

Incident response is never fun because

it's a whole lot of cleanup.

And, uh, and, and the first thing you have to do is you have to,

you have to get people out of your network because there's, you know,

there's obviously, there's the tools that kind of run on their own.

And there are tools that kind of have to be piloted by people.

So you have to create, uh, limits on the, on the system to be able to stop that.

And fingers crossed that you're not in a situation where your entire

network has been taken down by whatever is causing the problem.

Because I've seen that before too, where not only does it try to laterally move to

infect systems, it also throws up enough extra garbage that you are, it's Inca,

you're capable of logging into any of your

management networks.

So we're lesson number one.

Make sure all your management networks are kind of isolated so that you

always have the ability to use those.

But the first thing that I would.

As I would cut off outside access immediately, I would

lock the firewall in place.

I mean, you don't have to like run through the data center screaming with

your hair on fire and start yanking cables out like the alias episode.

But you need to be able to lock all of those connections down.

And specifically you need to look for ones that, you know, could be like, you know,

from really weird external addresses, or worse yet ones that are coming in.

Once you've blocked that external access in and out, you gotta do it

in both directions because obviously you don't want anything getting out

because the two things that I can think of are command and control traffic.

If some kind of tool that's being, uh, um, orchestrated or data exfiltration

and, and you're like, oh, well I can stop those file transfers.

Yeah, look up oil rig.

It was, uh, it was able to exfiltrate data through DNS queries.

Like that's the kind of crap you have to worry about.

So you've gotta lock it down.

Then you have to isolate because that's

the other thing too.

But, but before you move on,

I stop you there?

Uh, so how, how do you do that, right?

Is this, is this something where you have to create.

A button to press up, you know, because this sounds like a lot of little steps

you probably need to do to do this manually, or is there something I can

do upfront that says, in the event of a ransomware attack, push this button.

Hey, gum.

Shut up.

Anyway, uh, in the event of a ransomware attack, press this button and it

does the 10 things I need to do.

Uh, what, what do you think

Some of them do have a big red button press here to, to like

terminate all firewall connections.

But most of the time you're gonna have to create like a checklist or, or have

a system of like, okay, I'm gonna go into these rules and I'm gonna uncheck

these five boxes and then I'm gonna hit the terminate connections button to make

sure that no new connections can be made.

Also, if you have a rule at the bottom of your firewall list that

says Permit ip, any, any, take it out

now because it's not doing you any good.

But, but more importantly, you, you have to, you know, uh, all

kill switches have to be wired.

, there's no such thing as a magical switch that you can just hit, even if it's one

that the, that the provider has given you investigate what it actually does.

Does it dump the rules completely?

Does it just like suspend the rules until you go in and manually add them?

Remember that that could also cut off your connection to the firewall, so

you need to have another way to get into it just in case that happens.

Another reason for an isolated management network, but the, the idea is, is that

you, you, you need to investigate what your options are because God help you

if you really do have to run down to the data center and yank the cables

out, and if that is a case and, and hey, it's just as valid as anything else.

Can you make sure that you have the right keys, that you know which

firewall you're yanking out of?

Are there any other exits off of your network?

Because that's another problem that you may run into.

What happens if someone has created another exit off of your network,

either accidentally or on purpose?

And what happens then?

Because you know it's just as easy for me to plug something into your network.

And if there's another way off of it, I'm gonna find it.

Yeah.

The one other thing though, I know you talked about, and it totally

makes sense to kill all incoming and outcoming traffic, but just thinking a

step forward, like when you're dealing with incident response, like doesn't

that also take out like your chat channels, your slack channels, your

video conferencing, everything else, like what do you do at that point?

Is it just hope you have everyone's cell phone numbers?

you need to have a plan for out of band incident

response because y it's, it, it's just like any crime scene.

I need to figure out what's, what's been hit and I need to figure out

how much of it is going to spread.

And you're thinking to yourself like, I can't shut my network down

permanently because you know it's gonna cost me X amount of dollars.

Yes, but it's also gonna cost you x plus whatever amount of

dollars when the next system gets

hit, when it uncovers a device that no, nobody's patched it in years.

Um, I'm not gonna lie.

Incident response can work over iMessage text threads for a good couple of

hours while you try to figure that out.

Or, you know, buy your incident response team like those little, you

know, hotspots or enable the data plans on their phone so that they can join

their laptop there and join a Slack instance outside of your network.

because that way nothing is working internal to your network.

Because that's the other thing too.

If you, if this is something that's particularly insidious on a window

system and your incident responders are using Windows systems and they join

the network to be able to do incident response and their laptops get compromised

because they join the network again, you're gonna feel really, really dumb.

It's like, uh, the professional, when they blew up the bomb squad truck, it's like,

come on guys, what were you expecting?

You just reminded me of the, there's a, there's a series

of commercials and there's one where the commercial is like, it's like a

horror movie and the, there's a bunch of kid, it's like the, you know, I got

the guy with the, the, the ax murderers looking for the group of kids, and

they're like, why don't we go hang out?

Why don't we go hide in that shed over there with all the, uh, with all

the, uh, machetes or something like

Yeah.

Um, so, so we talked about blocking external traffic.

What about blocking internal traffic?

You know, uh, basically the lateral traffic, uh, be due to the, we

know we have ransomware and we know it's gonna try to crawl.

What about blocking that, uh, access?

So that's where you hope that your management

networks are, um, isolated because the first thing I would do going

into a router is shut down the route.

Tables prevent, um, traffic from being passed across network boundaries.

Um, what you're effectively doing in there is you are

containing the damage to one area.

Now, yeah, you're gonna take things down, but if you can isolate that network as

the location for wherever the problem is, you can then bring other networks

back online and be relatively certain that they're not gonna be infected.

I really hope that you're not using like, just regular routing, that you

have some kind of a security boundary there, because that makes it a whole lot.

But you, you've got to think in, in phases.

Obviously, you know, using the kill switch is gonna take everything

down, but then you have to start, you know, can I bring this back online?

Is this going to be infected?

What would I be looking for?

Um, so I actually have a, a story about this, uh, this happened

last year to my children.

Uh, one of 'em goes to the public high school here, uh, and I got a rocket

text message from their IT department saying, please turn off all public school

issue devices until further notice.

And I'm like, uhoh, somebody got hit with something fun.

And this was like the last day before Christmas break or something.

So we went in and we turned off my kid's MacBook, right?

So now, immediately I, because I know what the, the thing was, I don't

want anybody to like phone home and get infected and then like infect

the parents networks or whatever.

Okay, no problem.

We just shut it off.

But then I'm like, I wonder what it could.

like I, I'm kind of curious and, and they've, to this day, they've never

disclosed what it was, but you would get an email like the next week,

oh, if you're using like a, a, a, a corporate phone or if you're using

a MacBook, you can turn it back on.

Well, that automatically kind of lowers the horizon of, it has to

be something that's focused on Windows or something like that.

So then you start running through your head of what it could possibly be.

Well, an incident response, you have to do the same thing.

What server got hit?

Oh, well, it was the database server and it was running this version of,

uh, you know, windows or SQL server.

Okay.

Does that mean that Max can get on the network?

Do I want them on the network?

Is it a situation where even though they can't be infected, they could

propagate something to another location?

Like there's a lot that you have to go into because obviously the executives are

gonna be like, when can we do back up and.

and if you're a publicly traded company, oh God, the stockholders are like outdoors

with pitchforks and torches and they wanna know when they can get their dividends.

And you're like, uh, when I figure out how much of this data got encrypted

or stolen, and you're always gonna be fighting that tension and you can't

just shut everything off forever.

So that's part of incident response is you've got one team working on figuring

out how to stop whatever infected you, but you've got another team figuring

out how to bring things back online.

That's why we call it business continuity now.

Right.

It is interesting about the incident response.

How have you seen cases?

Like how do you actually, well, two questions I have.

How do you figure out like that, this segment, going back to what

you said, you kill all the routes.

How do you figure out that this segment is safe or not?

And then I guess that, yeah, that's actually only one question.

Well, so typically what, and, and you're, you're

effectively, when you create these boundaries, it's, it's like looking

for the hot potato effectively, because unless you, like in the alias episode,

just go click all the switches off.

Those devices can still communicate to each other at layer two.

Now, where you don't wanna have a problem is, is that it's in the data.

because if you isolate the layer two data center, now you've got a real problem.

Because if those servers, if if it's looking for servers, those

servers can still get infected.

That's why it's actually better to have like a, you know, a host route or

something like that, or something that, that kind of isolates that per unit thing.

I mean, honestly, like a V switch is perfect for this because like,

if it's not bound for that host, I'm not gonna let it go any further.

But effectively what you have to do is you have to look for chatter

that's still going on in the network.

Like you, you, I've shut all this down.

and I told my users to like disable their machines or, or turn them off or

whatever, what's still trying to talk.

And then you go take that on a case by case basis.

Oh, this device is still sending traffic that it's, but

it's looking for this server.

Okay, well I'm, I, I can shut it off because I know that it's probably safe.

But then you run into something like, oh, this thing is chattering

an awful lot and it's chattering on a way that it shouldn't be chattering.

Like that's how I've gone and found hosts that have been infected, but not

by ransomware, but by early malware because they just kept hammering the

firewall with these outbound requests.

And I'm like, you shouldn't

be doing that.

So it's, it's almost like a little bit of detective work.

The good news is, is that even though the network devices are kind of like

dumb from the perspective of I don't care what application is trying to talk,

where they're really good at telling you that things are still generating traffic.

It's like, oh, this port is still sending a ton of packets f bound

for this address on this location.

And so then you're like, oh, I think something might be up here.

Do you ever see cases where people.

, almost do a, like, create a black hole on the device itself to sort

of sync the packets there so it doesn't go out, rather than having

to necessarily do it on the switch.

Um, you can, uh, that's actually a really great way to

determine what it's trying to contact is to create like a null route on the system.

Uh, uh, going all the way back like three or four years.

Like Mark Marcus Hutchins, that's how he actually stopped a major outbreak of

malware, uh, for all the good it did, and he got arrested by the FBI later.

But he basically black hole the dns.

He bought the domain black hole it because if that domain name was

active, then it would stop propagating.

And so he figured that out by saying, oh, I wonder where this is

going and I wonder what it's doing.

You can do that.

And it's actually the next step in incident response, which you've isolated

the system, is I wanna see how it behaves and what it's trying to do.

Cuz that could give me a clue as to what I got hit with and

what they could be looking for.

And that gives you, you know, a, a little bit of opportunity, but that's

a little bit more of an advanced tool that you would, you would want to use.

Uh, just because black holding traffic on a, on a device takes

a little bit of setup, especially if you're fighting against people

who don't want you to do that.

Yeah.

W. Curtis Preston:

Yeah, so it sounds like.

W. Curtis Preston:

A, a lot of the things that you talked about in the last couple of minutes, they

W. Curtis Preston:

would be a lot easier to do again, if we segmented the network in the first place,

W. Curtis Preston:

right?

W. Curtis Preston:

We put people with Windows laptops on one network.

W. Curtis Preston:

We put people with Mac laptops on a network, another network.

W. Curtis Preston:

We put the, the, the phones right?

W. Curtis Preston:

That are doing the wifi.

W. Curtis Preston:

We put them on another network.

W. Curtis Preston:

Um, and we put servers on a different network.

W. Curtis Preston:

We put, maybe we put servers of a different type on, on a different network.

W. Curtis Preston:

So that way you could basically say you don't have to tell the,

W. Curtis Preston:

the, the users to not do anything.

W. Curtis Preston:

You can just say shut off the, the laptop, uh, network.

W. Curtis Preston:

Right?

W. Curtis Preston:

Um, and you, you shut off the laptop network and so on.

W. Curtis Preston:

And, and all the networks that where we don't currently,

W. Curtis Preston:

what we're not looking at.

W. Curtis Preston:

And then, okay, who's trying to talk?

W. Curtis Preston:

Who's trying to talk?

W. Curtis Preston:

Why is this server surfing?

W. Curtis Preston:

The web

Yeah.

W. Curtis Preston:

There's nobody over there.

W. Curtis Preston:

Why is this server going over report 80?

Well, a lot of places already kind of have this by

default, even if they didn't realize they were doing it because you have

different classes of devices that you wanna treat them differently.

Like for example, the uh, um, the server network, we want to have a

little bit more security in there.

Maybe a little less host to host East to west traffic kind of thing.

The wireless network where all the laptops and the devices connect.

I'm a little less careful about that because I actually have identity

management in place that validates the users when they try to log in.

Maybe I have a guest wireless network for my, for people that come into the lobby.

That one's wide open to the internet outbound only.

So I don't need to worry about that quite as much.

And then, you know, like phones and printers and things like that, that

have very specific things like, you know, I wouldn't enable Bonura in my

internal network, but maybe for the printer vlan I would, because I want

people to be able to find a printer.

Open up their laptop.

So they've already created these segments.

You just have to know where the buttons are to shut them off.

So maybe the example is I wanna isolate the servers from the rest

of the network, cuz I think there's something in there, but I can still

leave the wireless network up.

Maybe have everybody join the guest access network and force them all

out to the internet to do, you know, incident response or chat channels

or something like that where I'm, you know, but I'm creating these bounds so

that traffic flows one direction only, or it prevents certain things inside

of other areas because, you know, there's nothing to say like the, you

know, the, the, uh, s IDs that are on printers that are like, you know, set up,

uh, set me up or something like that can't be compromised.

And then if they can get into your printer network, it's like,

oh crap, where can they go from?

Yeah.

And, and Bonjour of course would be the, um, I, I don't know how would

I define

file sharing.

It, it is, it's almost like an auto configuration announcement,

uh, setting where, uh, it, it, and you can thank Steve Jobs for this.

He's like, I hate setting up printers.

And so basically what he did is he set up a system so that the printers

can announce that they exist.

And your laptop is constantly listening for these.

Bonura is another one of those protocols that is extra chatty and you kinda

wanna put bounds on it so that like you don't have the Apple TV four hallways

down announcing itself to the people in accounting because one, it's annoying.

And two, you never know when you're gonna do something you're not supposed to.

Interesting.

So yeah, I guess a lot of these are really around setting up

that initial network properly.

So then when you do have these issues, you can recover quickly and

identify and then recover quickly.

Right?

But if you don't have that initial setup done, then you're

in for a world of hurt, I guess.

and not just initial setup.

You actually do have to treat the network like a living, breathing organism.

I can't think of a single server admin out there that installs,

you know, windows server.

What are we up now?

20 20, 20 23 Windows, server X, I don't know, installs it

and then never patches it.

Never

touches it again.

Like, like you people are probably just shaking, even thinking.

, you cannot configure a network and then just leave it alone.

You do have to go in and, and tweak things and move things and change things.

And, you know, not just when you're trying to fix a broken thing,

either, you have to like, okay, is this subnet big enough for the

number of hosts that are in it?

Should I create routes over here?

It looks like there's a lot of extra traffic going on over this direction.

Maybe I need to disallow that because it looks like it's something

that shouldn't be happening.

Like, if you're not constantly pruning back what you are working on then,

and that's the problem that a lot of the, the, uh, ransomware writers have

figured out, like a lot of, a lot of their secrets, if you wanna call them,

that are just inadequate it support.

Like, we're gonna hope that you had left this on by default and we're

gonna take advantage of it and use it.

And if you did, I'm sorry, but like, you know, if any best practices

guide out there says, shut that off, and you didn't shut it off,

are you in that big of a hurry?

Yeah, well we're, we're living in a world

where, uh, you know, people don't even change their default password.

So, um, listen, here's the thing, Tom, my plumber's here, so, uh, I, I, you

know, I got a tradesman that actually showed up at two o'clock when he said

he was gonna be here at two o'clock.

So I gotta , we gotta shut this baby down.

Uh, Tom, this has been, this has been a great conversation.

Um, so thanks, thanks a lot.

Well, thanks for having me.

It's, it's been fun to talk about networking with, uh, with some folks

that coming at it from a slightly different perspective and understanding,

you know, what are we trying to accomplish with it, and in some

cases, what are we trying to disallow?

Hmm,

Absolutely.

Thanks again, Prasanna, once again, making me go backwards,

I, you know me, I try, you take one step back, two steps

forward or something like that, right?

something like that.

I

like that.

All right.

And thanks again to our listeners.

Remember to subscribe so that you can restore it all.