PCI Segmentation With an Unpatchable Imaging Server
Riverbend Health Partners runs 14 outpatient clinics under one /16 (10.20.0.0/16), about 1,900 hosts, connected over an MPLS L2VPN. Payment kiosks (38), clinical workstations and a CT scanner control server sit on the same flat VLAN at each site. The CT server runs Windows Server 2012 R2, uses SMBv1 to write images to a PACS, and the vendor states it cannot be patched without voiding support; the contract runs to 2027. The PACS vendor supports the site through a shared TeamViewer account used by three engineers, with the password stored in a shared spreadsheet and no MFA. A PCI DSS pre-assessment found the kiosks in scope with the clinical estate, and the QSA has asked for evidence of CDE segmentation. Clinic staff report that imaging must stay available 07:00-19:00, and any change requires a vendor-supervised window.
1. Propose a segmentation design that reduces PCI scope and identify where enforcement should sit. Justify the choice against the available constraints.
Read the worked answer
Target scope. Reduce the CDE to the 38 kiosks and the payment path, not the whole clinical estate. Each kiosk should sit in a dedicated CDE VLAN with a gateway that permits only outbound traffic to the acquirer's published IPs and ports, denies all inbound and lateral traffic, and has no route to clinical workstations. Management of kiosks should come from a dedicated jump host in the same zone, not from staff laptops.
Enforcement point. Do not rely on VLAN separation alone, especially over an L2VPN where a trunk misconfiguration or a dual-homed device can bridge zones. Enforce with a stateful firewall or a layer-3 switch with explicit ACLs between the CDE and every other zone at each site, with a default-deny posture and logging. If a site lacks that hardware, centralise the CDE gateway at the regional data centre and backhaul kiosk traffic rather than extending a flat VLAN.
Why this design. The QSA needs evidence that the CDE is isolated and that the segmentation is tested, not just documented. A small, well-defined zone is cheaper to monitor and easier to prove than attempting to bring 1,900 clinical hosts into scope. It also avoids touching the clinical workflow during clinic hours: kiosk recabling can be done outside 07:00-19:00 and does not depend on the CT vendor.
Evidence to produce. Firewall rule sets, data-flow diagrams, quarterly segmentation tests from a clinical host to a kiosk (expected deny), and change records. Note that kiosk management endpoints and any shared update server must be placed inside the CDE or replaced with a proxy, or scope creeps back.
2. The CT server cannot be patched until 2027. What compensating controls would you require, and would you accept the residual risk?
Read the worked answer
Isolate the device, do not just VLAN it. Place the CT server and PACS in a dedicated medical-device zone with a firewall between it and clinical desktops. Permit SMBv1 only from the CT server to the specific PACS IP and share, deny all other SMB, block outbound internet and inbound remote access, and log all flows. Disable unnecessary services and local accounts on the server, apply application allowlisting, and restrict interactive logon to a vendor jump host.
Add detection the device cannot provide. Since the OS is out of support, use network-based intrusion prevention with virtual patching for known SMB exploits, plus file-integrity monitoring on the PACS share and alerting on unusual SMB volume or new outbound connections. Retain NetFlow for at least 90 days. Scan the device with authenticated scans where the vendor permits, otherwise with safe network checks, and track exceptions.
Vendor access. Replace shared TeamViewer with named accounts, MFA, just-in-time approval, session recording and an IP allowlist, brokered through the jump host. The vendor's own security posture and incident notification obligations should be written into the contract.
Acceptance judgement. These controls reduce but do not remove the risk of an unpatchable, internet-adjacent Windows Server 2012 R2 system with SMBv1. I would accept only as a time-bound exception, signed by the clinical owner and CIO, with a review at least every six months, a funded replacement plan before the 2027 contract end, and a defined trigger to disconnect the device if exploitation is detected in the sector. Acceptance without a replacement path is not defensible.
3. How would you redesign third-party remote support without disrupting the 07:00-19:00 imaging service?
Read the worked answer
Move from a shared interactive tool to brokered privileged access. Create individual vendor accounts federated to the vendor's identity provider or held in the PACS vendor's own directory, each bound to a named engineer. Require MFA at the broker, and require a Riverbend ticket or approval before a session is enabled. Grant access only to the jump host in the medical-device zone, from which the engineer can reach the CT server and PACS on defined ports; the vendor should never land on a clinical workstation or the general corporate LAN.
Record sessions, log keystrokes and file transfers where the tool supports it, and alert on out-of-window sessions, new source countries and after-hours access. Set the access window to the vendor-supervised change slot rather than 24/7, and auto-expire the entitlement at the end of the ticket.
Sequencing matters. Pilot with one clinic in a low-activity window, keep the old path available read-only for one week as a rollback, then cut over site by site. Because the change is on the support path rather than the imaging path, it need not interrupt 07:00-19:00 service; the risk is misconfiguration of the jump host, so test PACS writes and DICOM retrieval before each cutover.
Also remove the password from the shared spreadsheet, rotate anything that was stored there, and check the vendor's logs for the past 90 days for sessions that do not match a ticket. The shared credential may already be known outside the three engineers, so treat past sessions as untrusted.