NAC Rollout Versus an Unpatchable MRI Console
Valley Regional Clinic is a 180-bed facility with a flat 10.20.0.0/16 network. It has 1,400 endpoints and 60 medical devices, including an MRI console running Windows 10 IoT LTSC 2019 that the vendor will not allow to be patched outside its quarterly window or to run a NAC agent. The clinic plans a NAC rollout with 802.1X and profiling. A pilot scan using credentialed vulnerability scanning caused the MRI scheduling system to stop responding for 40 minutes last month, so radiology now refuses any active scanning. The CISO wants to put all medical devices in one VLAN by Friday. The network team has a single maintenance window on Sunday from 01:00 to 04:00, and the MRI is booked from 07:00. The vendor support contract says any network change must be approved 10 business days in advance. The clinic has no dedicated security staff, only a network engineer and a help-desk lead.
1. Should the CISO put all 60 medical devices in one VLAN? Explain the segmentation design you would recommend and the first phase.
Read the worked answer
No. A single medical-device VLAN is easier to operate but creates a large flat blast radius: one compromised MRI console could reach every other device. Segment by clinical function and vendor support model. Phase 1 should be the smallest safe ring around the MRI: the MRI console, its acquisition workstation, and the PACS endpoint it must reach, each in a dedicated VLAN or private VLAN, with an allowlist of required protocols and ports. Keep DHCP and DNS to approved servers. Do not move all 60 devices in one Sunday window, because the vendor requires 10 business days notice and one failed change can cancel Monday scans. Use the Sunday window for the MRI ring only after vendor approval, with a rollback plan and a 06:00 validation test before the 07:00 booking. The second phase groups devices by vendor and clinical service, not by medical as a category.
2. How should the MRI console be handled given the no-agent and no-scan constraints? Include compensating controls and an exception record.
Read the worked answer
Treat the MRI as an exception with compensating controls, not as an unmanaged device. Controls:
- Passive profiling only: DHCP fingerprinting, MAC and OUI class, switch CDP/LLDP, and NetFlow; no credentialed scans.
- Dedicated VLAN with ACLs that allow only MRI-to-PACS, MRI-to-update-server, and DNS/NTP; deny all other east-west traffic.
- Port security, storm control, and 802.1X MAC authentication bypass if the console supports it; otherwise static MAC and unused-port shutdown.
- IDS/IPS monitoring on the VLAN and alerting on new flows, SMB, RDP, and outbound connections.
- Vendor-approved patching on the quarterly window; verify firmware hashes.
- Document the risk owner (radiology director), the business justification, the review date, and the vendor written support constraint. The exception should expire and be re-approved, not live forever.
3. What would you monitor to detect lateral movement from the flat network into the new medical VLAN without active scanning?
Read the worked answer
Without active scanning, monitor for flow and identity anomalies:
- NetFlow or IPFIX from the medical VLAN: new internal destinations, SMB (445), RDP (3389), WinRM (5985/5986), and outbound connections to the internet that are not the update server.
- Firewall and ACL deny logs: repeated denies from a medical device to workstation subnets are a strong lateral-movement signal.
- DNS logs for the medical VLAN: new domains, DGA-like names, or the MRI resolving hosts it never touched.
- Passive asset inventory changes: a new MAC on the MRI port, a new OS fingerprint, or a device suddenly speaking a new protocol.
- IDS signatures on the VLAN and a baseline of normal MRI-to-PACS flow volume and timing.
- Authentication logs: service accounts used from the medical VLAN outside the approved host. Set alerts on deviations from the baseline rather than trying to scan. The MRI normal behavior is narrow, which makes anomaly detection practical.