Segmenting a Flat Clinical Network With an Incomplete Map
Helio Health runs 1,400 workloads across two data centers and AWS. Its internal network is largely flat: 60 VLANs routed any-to-any through a pair of core firewalls seeing 8 Gbps peak. Last quarter an infostealer on a developer laptop reached the imaging archive in 11 minutes. The board approved $2.4M for segmentation. Infrastructure proposes replacing the core firewall pair with next-gen appliances that inspect all east-west traffic with full TLS decryption. The clinical application team says dependency mapping is 'about 70% complete' and that the EHR vendor will not support any network change without 60 days' notice and a vendor-approved diagram. The imaging archive runs Windows Server 2016 and cannot take the vendor's agent-based microsegmentation option.
1. Evaluate the proposed east-west design with full TLS decryption. What will it actually achieve, and where will it fail?
Read the worked answer
What it achieves: better visibility into east-west flows and the ability to write policy based on application identity rather than IP. Those are real benefits.
Where it fails:
- Throughput and latency. Inspection with decryption typically derates appliance throughput substantially. Sizing for 8 Gbps of inspected, decrypted traffic means a much larger purchase than the $2.4M implies, and clinical workflows are latency-sensitive - an EHR round trip that gains 15 ms per call is a clinician complaint, not a footnote.
- Decryption breaks things. Pinned certificates, mutual TLS between services, and vendor appliances that will not accept a substitute trust anchor will fail or be excluded from inspection. Every exclusion is a hole in the very design being sold.
- It is still a chokepoint, not a boundary model. You are moving the same any-to-any problem behind faster hardware. If a developer laptop can still route to the imaging archive because the policy is coarse, the 11-minute path survives.
- It assumes the map exists. The dependency data is 70% complete, meaning 30% of the policy is being written from assumption. Enforcement built on an incomplete map produces outages, and outages produce rollbacks, and rollbacks produce a flat network again.
The design is not wrong in kind, but buying decryption capacity to compensate for missing policy and missing segmentation is funding the wrong constraint.
2. Sequence the first 90 days. What gets segmented first, and why that rather than something else?
Read the worked answer
Order by blast radius and data value, and enforce where you can without waiting for the tooling that does not exist yet.
- Days 1-14: instrument before you enforce. Turn on VPC flow logs and NetFlow from the core, retain 90 days. Inventory the crown jewels: EHR database, imaging archive, backup infrastructure, identity providers, CI/build. Do not write a single deny rule yet.
- Days 15-40: coarse zones in monitor mode. At the existing core firewalls, define zones and log what would be blocked. Publish the proposed deny list to app owners. This is where the missing 30% of the dependency map gets filled with real traffic.
- Days 41-70: enforce the highest-value, lowest-coupling boundary first - the imaging archive. It is the thing that was reached in 11 minutes, and it is the one asset the agent-based option cannot cover. Because the Windows 2016 host is unmanageable by the vendor agent, enforce at the network layer: security groups or firewall zones permitting only the known PACS and application tiers. Network-layer enforcement does not require the host to cooperate.
- Day 1, in parallel: start the EHR vendor's 60-day notice clock. The process, not the technology, is the long pole. Submit the diagram for approval on day 1 so that enforcement is possible in month three.
- Days 71-90: EHR database, app-tier-only.
Metrics that matter: legitimate flows denied per enforced rule, tickets opened per zone, and percentage of crown-jewel assets inside an enforced boundary.
3. The CISO has $300k left and asks you to choose between a third-party dependency-mapping tool and additional firewall capacity. How do you decide?
Read the worked answer
Frame it as which constraint is binding. Dependency mapping addresses 'we cannot write correct policy.' Firewall capacity addresses 'our chosen enforcement design is too slow.' Only one of those is on the critical path today.
The capacity purchase is funding a design decision you have not made. If enforcement moves to host-based or identity-based controls for server-to-server traffic, you do not need a bigger chokepoint. Buying capacity first locks in the architecture you were trying to evaluate.
The mapping tool may also be premature. You already own the data: NetFlow and VPC flow logs from the instrumentation phase will produce most of the dependency graph for work you have already funded. Run a four-week flow-analysis pilot before spending $300k on a product.
What I would actually fund:
- The flow-analysis pilot, to test whether you need the tool at all.
- Enforcement points that scale with workload count rather than with aggregate bandwidth - host-based controls for the 80% of workloads that can take them, so incremental segmentation does not require a new appliance.
- The engineering time to do the EHR vendor approval process properly.
Decision rule to give the CISO: spend on the constraint that is currently stopping a deny rule from being written; defer spend that assumes an architecture not yet chosen.