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.