Ransomware on a Vendor Laptop Inside the MRI Network

Containment first, but coordinate with clinical operations so containment does not injure a patient.

1. Confirm the alert with the SOC and get the switch port, IP address, and any hash or ransom note detail.
2. Isolate the laptop at the network layer by disabling its switch port or applying a quarantine VLAN, rather than powering it off, so volatile forensic evidence survives. Ask the SOC to preserve memory and logs.
3. Do not disrupt an active scan. Confirm with radiology that the two sedated patients are safe, then isolate affected systems in order of clinical impact. If a scanner has to be taken off the network, it stops receiving worklist updates but can usually finish the current exam; the radiologist and IT make that call together.
4. Determine blast radius: which file shares were mounted, whether encryption has begun on the file server, and whether the shared VPN account was used elsewhere. Disable that VPN account and the shared team account immediately.
5. Stand up the incident command structure: CISO and CIO own the technical response, the privacy officer starts a HIPAA breach assessment (notification decisions are due within 60 days of discovery), and clinical leadership activates downtime procedures for radiology and any dependent service.
6. Communicate a single approved message to radiology staff: what is down, what the paper workaround is, and where to send questions.
7. Engage externally: the device vendor, the laptop vendor's security team, and law enforcement (FBI/IC3). Ransom payment is an executive and legal decision, not an HTM one.
8. Document a timeline from the first alert forward, because every later question will depend on it.

Every step has a named owner; HTM owns the medical device impact assessment, not the network decision.

I would score each device on four axes and rank, rather than treating "unsupported OS" as a single bucket.

• Clinical impact of unavailability or corruption: a scanner that stops producing images is disruptive; a device that could be manipulated to deliver wrong results is worse.
• Exposure: is it reachable from other VLANs or the internet, does it have vendor remote access, are there USB ports in use, are credentials shared or default?
• Patient volume and criticality: studies per day and whether the service has an alternative.
• Exploitability: known CVEs for that OS and application, and whether an exploit is public.

Compensating controls, in order of preference: segment each device or device class onto its own VLAN with explicit allow-lists for only the ports and servers it needs; remove internet access; disable unused services and USB mass storage; replace default and shared credentials with unique accounts; route vendor access through a controlled gateway with multi-factor authentication, time-limited sessions, and logging to the SIEM; add network monitoring or a medical device protection platform that can alert on anomalous traffic and apply virtual patching; verify that backups exist and that a restore has actually been tested.

Where residual risk stays high, the honest answer is replacement, funded in the capital plan with a dated commitment. The 12 devices should be entered on a risk register with the controls applied, the residual score, an owner, and a review date. Risk acceptance has to be signed by hospital leadership, not by HTM alone, and it has to be revisited rather than filed.

The shared national VPN account is the most serious finding here. It means the hospital cannot attribute any action to an individual technician, cannot revoke one person, and cannot prove what happened. That has to change regardless of the contract.

Contract and governance:

• Named individual accounts with multi-factor authentication, granted per visit for a defined window, routed through a controlled jump host, with session recording and logs sent to the hospital SIEM.
• A security addendum requiring manufacturer disclosure of known vulnerabilities, security patch timelines, supported OS lifetime commitments, an MDS2 or equivalent security questionnaire at purchase, and a software bill of materials where available.
• Right-to-audit and notification clauses, plus coordinated vulnerability disclosure.
• A vendor access request workflow with a clinical sponsor and a post-session review, so access is a granted privilege rather than a standing one.

On the patch conflict: an immediate update is a clinical downtime decision, not a vendor convenience. I would ask the vendor to document the vulnerability severity and whether a workaround exists, then schedule the update in a clinical window agreed with radiology leadership, test it on one unit or in a lab where possible, and have a documented rollback plan. If the risk is truly urgent, escalate to the CMO with a specific downtime plan and staffing for it. The decision and its rationale get recorded, because the next auditor or surveyor will ask who decided and on what basis.