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

Network segmentation to prevent ransomware isn’t theoretical. It’s the difference between a bad day and a catastrophic one. The University of California, San Francisco found that out the hard way when attackers got in through compromised credentials — no phishing, no dramatic breach — just stolen VPN access. What saved them wasn’t luck. It was architecture. Their segmented network kept the infection contained to one part of their environment. Healthcare operations kept running. Labs stayed up. That’s what good segmentation buys you.

This blog post summarizes the main points of my latest podcast episode. If you’d like, you can listen to it or watch it at https://www.backupwrapup.com/network-segmentation-to-prevent-ransomware-ucsf.

What Network Segmentation to Prevent Ransomware Actually Means

At its core, network segmentation means dividing your network into smaller, isolated zones — and then controlling what can talk to what. Think of it like a warehouse with different sections. The air-conditioned office doesn’t have open access to the loading dock, and the loading dock doesn’t have open access to the server room. Each zone has its own rules about who gets in and what they can do once they’re there.

The benefits go beyond security. Segmentation helps with management, bandwidth control, troubleshooting, and compliance. HIPAA, for example, strongly advises — and in some cases requires — segmentation for environments that handle sensitive healthcare records. That’s part of why UCSF had it in place. Compliance pushed them toward an architecture that ended up being their best defense.

The tool most organizations use to do this is VLANs — Virtual Local Area Networks. A VLAN is a capability built into modern switches that lets you carve up your network virtually, without buying separate hardware for every segment. You log into the switch, assign ports to different VLANs, name them, set your access rules, and you’re off. Production gets its own VLAN. Guest devices get another. HR and legal get another. The key point is that VLANs don’t talk to each other unless you specifically allow it — and by default, you should allow as little as possible.

The Need to Talk Principle

One of the most practical concepts in network segmentation to prevent ransomware is what Dr. Mike Saylor calls the “need to talk” principle. Before any device gets access to any other device or system, you ask: does it actually need that access to do its job?

End user devices — laptops, phones, anything someone takes to Starbucks — are the highest-risk endpoints in your environment. They’re the ones most likely to get hit with ransomware. And yet in a lot of organizations, those devices have mapped drives straight into production servers. That means the moment ransomware lands on a laptop, it has a direct path to your most critical systems via that user’s credentials. Segmentation cuts that path. End user devices go in their own segment. They can reach what they need to reach — and nothing else.

This applies beyond laptops too. There’s no reason your dev and test environments need to talk to production. There’s no reason a web server needs direct access to your backend database from the user-facing side. Every unnecessary connection is an attack path you’re leaving open.

Microsegmentation and the Complexity Trap

Network segmentation to prevent ransomware can go even deeper with microsegmentation — where you control not just which VLANs can talk to each other, but which specific applications can talk to which other applications. When Prasanna and I worked at a cloud backup company, they had their S3 bucket configured so that only their specific application could read and write to it. Even if an attacker somehow got through every other layer of security, they couldn’t touch that storage. That’s microsegmentation in action.

Here’s the catch though: complexity is its own risk. You can build a segmentation setup so intricate that nobody on your team can understand it, nobody can troubleshoot it when something breaks, and the one person who built it is the only one who knows how it works — until they leave. Mike has seen this more than once. A new person walks into an overly complex environment right as an incident is happening, trying to figure out the architecture while the house is on fire. That’s not a good situation.

Doing nothing equals risk. But doing too much equals risk too. You need to find the balance between protection and manageability.

Network Segmentation to Prevent Ransomware: Where to Start

If you’re starting from scratch, don’t try to boil the ocean. Here’s a practical sequence:

Start by creating three basic segments: production, dev/test, and end user devices. That alone will dramatically reduce your exposure. End user devices get their own zone, locked down from production. Dev and test get separated from production — there’s almost never a good reason for them to have open access to it.

From there, look at your production environment and think about your multi-tier applications. Your users probably only need to talk to the web tier. The web tier talks to the app tier. The app tier talks to the database. You can segment those layers from each other and from everything else. Start open and monitor. Watch the traffic. See what’s actually communicating. Then lock it down in phases.

You need management buy-in before you do any of this. When you start segmenting, you will break things. Apps will stop working. People will call. You need support from above, and you need everyone to understand that this is intentional, temporary disruption in service of something that matters. Get that commitment first, then start building.

Network segmentation to prevent ransomware isn’t a silver bullet, and it’s not a one-time project. It’s an ongoing architecture decision that pays off the day something gets in — and something always eventually gets in. The question is how far it gets.

Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at S2|DATA, which helps companies manage their legacy data