Network segmentation & zero trust

A regional hospital group runs one large internal network. On it sit the electronic health records system, the imaging archive, infusion pumps and lab analyzers, payroll, front-desk PCs, and a remote-access link for the vendor that maintains the pumps. A firewall at the edge keeps the internet out; inside, every machine can reach every other.

Then a front-desk PC opens a phishing attachment. The attacker now has a machine inside, and inside means trusted: the records database answers it, the imaging servers answer it, the pumps answer it. The flaw in this design: once attackers breach the perimeter, further lateral movement is unhindered.

The old model is a medieval castle: thick walls, a moat, one guarded gate, and anyone past the drawbridge trusted. It worked when every employee sat in a company building on a company machine. It fails when staff work from home, clinicians use tablets, vendors connect remotely and applications live in clouds, and it fails completely once anything inside is compromised. Two answers follow: divide the castle into rooms, and stop trusting the castle at all.

Network segmentation splits the network into zones by function and sensitivity, and denies traffic between zones except for flows that are explicitly allowed. The hospital's zones and the only flows between them:

The same idea appears at every level of a modern stack, and the defaults matter:

• Cloud security groups contain only allow rules. A new group admits no inbound traffic until rules are added, and a rule can name another security group as the source, so "app servers may reach the database" stays true as servers come and go (Private networks: NAT, VPCs & firewalls).
• Kubernetes NetworkPolicies start the other way: every pod accepts all traffic until some policy selects it. Once selected, a pod accepts only what its policies allow, and the cluster's network plugin must support enforcement, or the policies do nothing.

Finer segments are safer and harder to run. Microsegmentation draws a boundary around each application or even each workload, which limits a breach to one service but needs rules for every legitimate conversation. Start with the crown jewels: the records database should accept connections only from the records application servers, whatever else is still flat.

Segmentation still trusts by location, just in smaller rooms: anything inside the records zone can reach the database. Zero trust removes location as a source of trust. It assumes no implicit trust is granted to users or devices based solely on their network location or on who owns the asset. Its seven tenets, condensed:

None of this means "trust nobody, block everything". It means each decision is made on evidence about the request itself, at the moment it happens, rather than on the network it came from. A clinician at home on a managed, patched laptop may get more access than a stranger's laptop plugged into a ward's network socket.

A zero trust architecture splits access into two roles. A policy enforcement point (PEP) sits in front of each resource and lets traffic through or not. A policy decision point, made of a policy engine that decides and a policy administrator that carries out the decision, evaluates each request against policy and outside signals:

Google's BeyondCorp is the best-known working example. It removed the privileged corporate intranet and moved internal applications onto the internet behind an access proxy that every request passes, whether the employee sits in an office or a café. Only managed devices, tracked in a device inventory database, can reach corporate applications. Even devices in Google's offices are placed on an unprivileged network that closely resembles an external one, so being in the building grants nothing.

Cloud providers now sell the same pattern. Google Cloud's Identity-Aware Proxy, for example, checks identity and role for each request to an application and can add context-aware conditions, without a VPN. That is the point of the US government's 2022 zero trust strategy as well: users should log into applications rather than networks, and every application should be treated as if it were reachable from the internet.

Zero trust applies between machines as much as between people. Inside the hospital's data center, the records application calls the database, the imaging service, and a billing service. In a perimeter model, those calls are trusted because they come from internal addresses. In a zero trust model, each service has its own cryptographic identity, every call is encrypted and authenticated in both directions, and a policy names which services may call which (Encryption in transit & at rest).

A service mesh is one common way to provide those identities and policies without changing each service (Service mesh & sidecars). Concrete targets follow from it: encrypt all DNS requests and HTTP traffic inside the environment, isolate systems from each other, enforce multi-factor authentication at the application layer rather than the network layer, require phishing-resistant MFA for staff, and consider at least one device-level signal alongside the user's identity when granting access.

No hospital rebuilds its network in a weekend. CISA's zero trust maturity model, used by the US federal strategy, organizes the work into five pillars, identity, devices, networks, applications and workloads, and data, with visibility and analytics, automation and orchestration, and governance cutting across them. A practical order for the hospital:

Some things will never fit the model fully. Medical devices and other equipment often can't present identities or run agents, so they stay in tightly segmented zones with monitored gateways: segmentation and zero trust are complementary, not alternatives. Not every tenet can be fully implemented in its purest form, and most enterprises will run hybrid architectures for a long time.

For the hospital group, the checklist:

• Assume something inside is already compromised, and design so it reaches as little as possible.
• Segment by function and sensitivity, default deny between zones, and list every allowed flow.
• Know the defaults: security groups admit nothing until allowed; Kubernetes pods accept everything until a policy selects them.

Then, step by step:

• Put applications behind an enforcement point that checks user, device and context on every request.
• Use phishing-resistant MFA at the application, not just the network.
• Give services identities, encrypt every hop, and write which services may call which.
• Keep unmanageable devices in their own zones, reached only through gateways.
• Migrate one application at a time, starting with the most sensitive.