Critical SMBv1 Vulnerability in a 212-Pump Fleet the Vendor Will Not Patch

The defensible path is a documented, time-limited risk acceptance with defined compensating controls - not a unilateral patch and not an indefinite deferral.

Elements the analysis must contain:

1. Preconditions for exploitation. Does this platform actually run SMBv1, and is it reachable from anything other than the drug-library server? A vulnerability that requires SMB on a service the pumps do not run is a different risk than one they expose.
2. Harm pathway. An exploited pump can be reprogrammed to deliver an incorrect dose - the credible worst case is serious injury or death, which is what drives the seniority of the sign-off.
3. Exposure. Shared VLAN with nurse call and telehealth carts materially widens lateral movement; domain authentication means credential reuse is a realistic escalation path.
4. Control effectiveness and residual risk, rated honestly with the reasoning, plus a named owner and an expiry date for each claim.
5. Vendor engagement record. A written request to the vendor's product security team with a response deadline, plus a check of published FDA safety communications for this device family.

Judgement point: applying an unvalidated OS patch against explicit vendor instruction risks breaking drug-library behavior or pump delivery in ways no one has tested, and it may complicate warranty and support without actually removing the vulnerability. Containment plus vendor pressure is usually the lower-risk route, but it must be recorded as a deliberate decision by the CMO, CISO, and CNO - with a review date - not left as an undocumented gap that looks like negligence in an after-action review.

1. Dedicated segmentation (highest value). Move the pumps to their own VLAN with no route to clinical workstations, the internet, or the general server estate. What it buys: removes the paths an attacker needs after initial access. Verify by an actual scan from a clinical subnet showing no reachability, not by reading the firewall rule.

2. Least-privilege access control lists. Permit only the drug-library server, the vendor service host, and the specific AD endpoints required; deny pump-to-pump SMB, which is not a clinical requirement. Verify with flow logs showing denies and confirms.

3. SMBv1 mitigation. If the vendor confirms it is not needed for the update path, disable it; if it is needed, block SMB at the switch/firewall boundary. Verify with a configuration audit and a packet capture during a drug-library update.

4. Detection. Deploy IDS/IPS signatures and medical-device security monitoring with alerts routed to the SOC and an on-call biomedical engineer. What it buys: you convert an invisible compromise into an alertable event. Verify with a scheduled test alert.

5. USB and service-path control. Keep mass storage disabled except for the vendor laptop, scan that laptop, and log every update session. Verify by audit of update records.

6. Identity hygiene. Remove shared local administrator accounts, rotate credentials, restrict domain rights so a pump cannot be used to pivot.

7. Operational fallback. A pump-specific incident response runbook that includes manual infusion fallback and a pre-agreed trigger for pulling devices offline.

Judgement point: none of these removes the vulnerability, and saying so plainly is part of the job. The residual risk rating must reflect that the exploit is public and reachable if segmentation fails.

Message to the CNO, CMO, and CISO - one page, no jargon:

• What the risk is: a publicly exploitable flaw that, if used, could alter pump programming.
• What is contained: pumps are isolated from workstations and the internet; only the drug-library server can reach them; monitoring is live.
• What remains: the flaw still exists in the devices; a determined attacker with physical or network access inside the restricted segment could still exploit it.
• What nursing must do: independent double-checks on high-alert infusions, confirm the displayed program against the order, report any unexplained pump behavior immediately, and do not plug unapproved devices into the pump segment.
• What happens next: vendor deadline, review date, and replacement/patching plan for the next capital cycle.

Conditions that force removal from service:

1. Any evidence of exploitation or anomalous SMB traffic from a pump.
2. Loss of segmentation - for example a network change that places pumps back on a shared clinical VLAN.
3. Loss of monitoring or loss of the SOC alerting path.
4. A vendor position that the device will never be supported, combined with a reachable exploit and failed containment.

Judgement point: refusing to commit to removal triggers is what makes the exception indefensible. Equally, pulling 212 pumps pre-emptively would create a larger and more certain patient harm than the theoretical exploit, which is why the decision belongs to clinical and executive leadership with engineering advice - not to the CISO alone. Also distinguish the organization's internal restriction from a manufacturer-issued recall; they carry different authorities and different documentation obligations.