Unpatchable MRI Console on a Flat Clinical VLAN
A 12-year-old MRI console runs Windows 7 Embedded. The vendor approves a fixed patch set that cannot be extended and will not permit third-party endpoint protection on the console. The scanner sits on a clinical VLAN that is flat across three buildings. The vendor quotes $480,000 for a supported platform with a 14-month lead time. Radiology estimates downtime at roughly $9,000 per day in diverted and rescheduled scans. IT wants the device firewalled off the network entirely; radiology says that breaks the modality worklist and the PACS transfer, and the scanner has no standalone workflow. The organization's last HIPAA risk analysis did not list any medical device as a risk item. The CIO has asked for a decision memo within two weeks.
1. Make the decision: disconnect, leave as-is, or something else. Show the risk reasoning and name the risk owner.
Read the worked answer
It is not a binary. Disconnection causes certain, immediate availability harm; leaving it flat causes probable, delayed confidentiality and integrity harm. Score both sides on the same 5x5 used elsewhere in the organization.
Likelihood of exploit: 4. Unsupported OS, no endpoint protection, a flat VLAN shared across three buildings, and high clinical value make this a realistic pivot target. Impact if exploited: 4-5 - loss of the only MRI plus potential spread into the wider clinical VLAN.
Recommendation: segment, do not disconnect. Move the scanner to a dedicated VLAN with rules permitting only the specific worklist, PACS, and management endpoints on required ports, with a monitoring sensor, no internet egress, and no direct vendor remote access except through a jump host with MFA and session logging. This preserves the clinical workflow while removing the flat-network exposure.
Risk owner: the CIO, not biomed. Biomed is technical custodian; the CIO signs the time-bound risk acceptance with an expiry at the platform upgrade date and the CMO as co-signer for the clinical impact. Add the device to the risk analysis as a formal finding with a remediation date - the omission from the last risk analysis is itself a compliance gap that needs its own corrective line.
2. Specify the compensating controls and describe how you would prove the scanner still works clinically after the change.
Read the worked answer
Controls:
- Dedicated VLAN with deny-by-default ACLs, allowing only worklist, PACS store and query-retrieve, and management traffic on named ports.
- Passive network monitoring with alerting on traffic outside the baseline.
- No internet or email egress; USB ports physically blocked or disabled by policy with an approved exception process.
- Vendor remote support only through a jump host with MFA, session recording, and time-limited access windows.
- Physical port security on the switch, plus a documented break-glass procedure if segmentation blocks a clinical function.
- A tested downtime and backup plan for the console, and a loaner or mobile MRI arrangement while the upgrade is pending.
Validation - do not accept 'it pinged':
- Perform the change in a scheduled window with a radiographer present.
- Run a complete study end-to-end: order and worklist delivery from the RIS, acquisition, PACS store, and query-retrieve from a diagnostic workstation.
- Compare transfer times before and after, and confirm no other traffic is reaching the device.
- Baseline the logs for two weeks and confirm alerts fire correctly with a controlled test.
- Document all of it in the change record, signed by radiology and IT, because this paperwork is what demonstrates due diligence if the device is ever involved in an incident.
3. The CIO asks you to justify $480,000 against a 14-month risk acceptance. What is your argument, and what do you ask the vendor for?
Read the worked answer
The argument: compare the cost of the control to the cost of the risk. At $9,000 per day of diversion, a two-week exploit-induced outage is roughly $126,000 in direct operational cost before any recovery, regulatory, or breach-notification cost. The upgrade also ends the ongoing cost of compensating controls, removes a standing risk-analysis finding, and restores vendor support - the current console's failure mode is an unsupported component with a long lead time, which is an availability risk regardless of attackers.
Also be honest about what $480,000 does not buy: it does not remove the risk today, and 14 months is a vendor lead time, not a law of physics.
What to ask the vendor:
- A written patch commitment and a stated end-of-support date for the new platform, with notice of at least 24 months before any future end-of-support.
- A software bill of materials and the right to test patches before deployment.
- An interim support agreement covering the 14 months on the current console, including a defined response time and parts availability.
- A loaner or swap commitment if the console fails during the gap.
- Whether the upgrade can be staged - console and software now, magnet and site work later - and whether an early-order discount or a trade-in credit applies.
Put the interim support agreement in front of the CIO as the deliverable for this cycle; it is the item that actually reduces risk before the platform arrives.