The Segmented Clinic Network
A 40-person outpatient clinic runs a flat /24 network. The electronic medical records server, staff workstations, guest Wi-Fi, and networked infusion pumps all share one VLAN. The clinic director asks you to "add a firewall" after a ransomware scare at a peer clinic. Budget is limited to one next-generation firewall with 8 copper ports; no new switches are approved this quarter. The infusion pumps are managed by a vendor that refuses firmware changes and requires the pumps to reach a cloud management endpoint over HTTPS. Staff currently print to shared printers on the same subnet, and the guest network must remain open but isolated. The clinic operates 12 hours daily and cannot tolerate more than a 30-minute outage for the cutover.
1. Propose a segmentation approach achievable with the single 8-port firewall and no new switches, and justify the zones.
Read the worked answer
The constraint is port count, not policy ambition. With eight copper ports I can carve four zones without new switching: (1) clinical workstations and printers on one firewall port via the existing switch uplink, (2) the EMR server on a dedicated port, (3) infusion pumps on a dedicated port, and (4) guest Wi-Fi on a dedicated port. The remaining ports go to the WAN uplink, a management interface, and spares. The EMR server and pumps get their own physical segments because they carry the highest clinical risk and the pump vendor cannot patch. Printers stay with workstations because cross-zone printing would require a broad allow rule that weakens the workstation zone. Guest traffic gets internet-only egress and no route to any internal zone. This is defensible because each zone boundary maps to a distinct trust level and a distinct failure consequence, not to org-chart convenience.
2. The vendor insists pumps must reach a cloud endpoint over HTTPS. What policy do you write, and how do you handle the risk that the pumps are unpatched?
Read the worked answer
I write a default-deny pump zone policy permitting only outbound TCP 443 to the vendor's published endpoint hostnames or IP ranges, with logging on every permit and deny. I do not allow the pumps to initiate connections to workstations or the EMR. Because the pumps are unpatched and vendor-frozen, I treat them as untrusted endpoints: restrict inbound to established sessions only, enable IPS signatures for the pump traffic where the firewall supports it, and alert on any pump connection to a destination outside the allowlist. I also document the residual risk and ask the vendor in writing to confirm the endpoint ranges and whether mutual TLS is supported. If the vendor cannot provide stable ranges, I would consider a forward proxy rather than a blanket HTTPS allow, and I would record the compensating control in the risk register.
3. Plan the cutover to meet the 30-minute outage limit.
Read the worked answer
I pre-stage the firewall configuration offline, including zones, policies, NAT, and logging, and validate it against a lab copy of the switch config. I schedule the cutover outside clinic hours, though the 12-hour operating window means early morning. The sequence is: snapshot current switch and firewall configs; move the EMR server cable to its new port; move the pump segment; move guest Wi-Fi; then flip the workstation uplink. Each move is tested with a scripted checklist (EMR login, print, pump heartbeat, guest captive portal). I keep the old flat configuration on standby so rollback is a cable move plus config restore, targeted at under 10 minutes. The 30-minute limit is met because no step requires re-addressing endpoints if I use the same subnets on the new zones and route between them on the firewall.