Hospital & Medical-Device Security Tracker

Each hospital's Risk score (0–100) is a transparent composite. It is a prioritization signal, not a claim that any named hospital is currently compromised. Reasoning:

• Severity (0–40) — worst CVSS among the hospital's exposed devices, scaled. A CVSS-10 device (GE MDhex) contributes the full 40.
• Exploitability (0–25) — how reachable the flaw is: network-exploitable + low attack complexity scores highest (GE MDhex), same-network/chainable next (B. Braun), physical/adjacent lowest (Philips).
• External-facing (0–15) — the device sits on a shared clinical network, i.e. it's part of the initial-access attack surface rather than air-gapped.
• Incident history (0–10) — a documented past breach is direct evidence that this organisation's posture has been successfully exploited.
• Blast radius (0–10) — bed count as a proxy for device count and patients affected; a 1,000-bed center is a bigger target than a 100-bed community hospital.

Bands: critical ≥70, high 50–69, medium 30–49, low <30. Confidence is not subtracted from the score (that would hide risk) — instead it's shown as a label: a "(inf)" suffix means the underlying device is inferred, so the risk is potential, to confirm on a call. Hover any Risk chip for its full breakdown and the top recommended action.

Prioritized, drawn from the CVEs actually present in this fleet:

1. Segment clinical devices off the business network. Nearly every device CVE here (GE MDhex, Baxter/BD/Braun pumps, Philips monitors) is downgraded from "network-exploitable" to "needs physical access" by proper VLAN/segmentation. This is the single highest-leverage control.
2. Patient monitors first (GE CARESCAPE). MDhex is CVSS 10 and easily exploitable — isolate the MC/IX monitoring network per GE's config guide before anything else.
3. Bring infusion-pump firmware current. Alaris 12.3 / PCU 12.1.2, Baxter WBM updates (disable Telnet/FTP), B. Braun SpaceCom2 — then keep pumps on their own VLAN.
4. Enforce MFA on email and remote access. The UMass Memorial breach (209k records) was phishing into un-MFA'd email; this is the cheapest high-impact fix.
5. Harden the edge and rehearse ransomware recovery. The Signature Healthcare (Brockton) ransomware incident shows the impact; VPN/firewall hardening, network segmentation, and tested backups are the counters.
6. Stand up an SBOM/VEX intake and a CVD process. Ingest vendor SBOMs and VEX files so the next component-level flaw (Ripple20/URGENT-11 style) maps to your fleet automatically — the 524B-aligned program BitSense sells.

This is exactly the remediation roadmap a BitSense assessment would deliver, priced per the earlier services model.

Click any hospital name to open a clean detail sub-page: risk breakdown, full device fleet, per-device CVE exposure, incident history with source, and prioritized posture actions. Each detail page has an Ask box, and there are portfolio-wide and device-level Ask boxes too. Behind them is an agent: given a question, the model plans and calls tools over the tracker — list_hospitals (filter/rank by state, risk, incident, device), get_hospital, get_device_cve, list_cves — iterates across several steps, then answers only from what the tools returned (it can't invent hospitals, CVEs, or numbers). It separates confirmed from inferred and proposes compensating-control mitigations when a vulnerability isn't remediated. The tools it used are shown above each answer. Deployment note: the agent calls the Anthropic API, which works inside Claude.ai. Self-hosted on GitHub Pages, proxy it through a Cloudflare Worker holding your API key (your usual pattern). If the API isn't reachable, every Ask box degrades to a local keyword engine over the same data, so it still works offline.

Populating device tags legitimately: hospital beds/locations/affiliations are public. Which devices a hospital runs is not — fill tags from your own discovery calls, GPO/IDN affiliation, public bids/RFPs, MDS2 exchanges, and published deployments. Inference from size/system is a hypothesis (amber), not fact. The "+ add device" box autocompletes from real FDA-cleared infusion-pump products (a spelling picklist only; it assigns nothing).

Where the security incidents come from & how they're retrieved. Incidents are documented matters of public record, not speculation. The authoritative sources, in order:

1. HHS OCR breach portal (ocrportal.hhs.gov/ocr/breach) — the federal "Wall of Shame." HIPAA-covered entities are legally required to report breaches affecting 500+ individuals; each entry lists the entity, individuals affected, breach type (hacking/IT, unauthorized access, theft, loss) and the location of breached information. This is the systematic per-hospital source.
2. State Attorney General breach notifications (e.g. Maine, Massachusetts OCABR) — often list individual counts earlier and more precisely than the federal portal.
3. Reputable breach reporting — HIPAA Journal, Comparitech, The Record, Becker's, and local news, used to establish cause/threat actor and timeline.

Each incident here is cited to its source and states the cause where public (phishing, ransomware group, third-party/vendor compromise). "None found" means no public record surfaced in this pass — not proof of no incident. The honest next step is a full per-hospital HHS OCR portal sweep, which would give every one of the 74 hospitals a real, cited incident history. Note also that many large healthcare breaches are third-party/vendor (Blackbaud, MOVEit, Netgain, Change Healthcare) rather than a direct hospital compromise — the tracker records these against the affected hospital but names the vendor as the cause, because vendor risk is itself a core part of the security posture BitSense assesses.