# Device & API abuse, cured — the address is the device > Your clinical network runs on machines built to be trusted, not to prove who they are — > so a stolen token, a hardcoded key, or a same-VLAN IP walks the FHIR API and the DICOM > port, scrapes a population of records, and rotates egress until all your SOC has logged is a > meaningless *last IP*. The address **is** the device: a routable, DNSSEC-anchored /128 the > endpoint proves with its own key — publicly verifiable across the HDO, vendor and HIE > boundary UDAP's private trust can't cross. Additive to your IoMT platform and SIEM. Tens of thousands of them — pumps, monitors, scanners, EHR and FHIR endpoints — sit on flat clinical VLANs, most on operating systems too old to patch or run an agent. Every one authenticates a *claim*: a bearer token, a shared credential, a same-subnet IP — never the machine on the other end. So a phished login, a key lifted from an app bundle, or an over-broad OAuth scope walks the FHIR API and the DICOM port, scrapes a population of records, and rotates egress across Amazon, Google and Azure until all your SOC ever logs is a meaningless *last IP*. It is a HIPAA and GDPR exposure, and — increasingly — a patient-safety one. **Stop trying to detect it. Make it an identity problem.** The address **is** the device — a routable, DNSSEC-anchored **/128** the endpoint proves with its own key, so a stolen token with nothing behind it authenticates to **nothing** — and it verifies across the HDO, vendor and HIE boundary UDAP's private trust can't cross. **Give every device an identity it can prove — and no one can forge.** `whisper verify --trustless` — anchored at the IANA DNS root. Our own API is not in the trust path. - **53%** — of connected medical/IoT devices carry a known *critical* vulnerability - **75%** — of infusion pumps ship with ≥1 known security gap (~200k pumps studied) - **~1B+** — medical images sit exposed on open DICOM servers, under 1% over TLS - **100%** — of the production FHIR APIs tested in one study leaked records via BOLA - **~133M** — Americans' health records exposed in a single year, a record - **+35–41%** — in-hospital mortality for patients already admitted when ransomware hits --- ## The anatomy, end to end **It isn't a breach.** Your own machines and APIs are used exactly as built — by someone they can't tell from a peer. No zero-day required. Three surfaces stack the same failure — a device that authenticates a claim, not a machine — and a single operator walks straight through them. **The device default: trusted, not authenticated.** Device lifecycles run 10–20 years against 3–5 years of OS support, so many sit on end-of-life systems that can't be patched or run an agent — ~60% of health systems say they can't protect their unpatchable, agentless devices. On a flat clinical VLAN, with IT/OT/IoMT converged, the controller, the EHR, the API each trust a token, a shared credential, or a same-subnet IP. A stolen secret simply *is* the device. **The FHIR API surface: a claim, not a machine.** The data layer is a modern REST API and inherits REST's worst failure mode. `SMART-on-FHIR` issues OAuth scopes that are routinely over-broad; UDAP adds dynamic client registration; a mis-scoped or replayed token then walks the records — change the patient ID, read the next patient (`OWASP BOLA`). One study of production FHIR APIs found the flaw in *every one it tested*, and hardcoded keys in 77% of 30 mHealth apps. HL7 is right that this is an *implementation* flaw, not the FHIR standard — which is exactly why an identity anchor, not a spec change, closes it. **Legacy protocols: no auth at all.** Beneath the API sit protocols that assume a trusted LAN and authenticate nothing. `HL7v2` flows in the clear. `DICOM` AE-Titles are set by hand at install and unverified — scans find open DICOM servers exposing over a billion images, under 1% over TLS, ~99.5% accepting connections with no AE-Title validation. Proprietary device protocols are no better. On a flat segment, whoever can reach the port is trusted. ### The kill chain — one operator, straight through all three 1. **DISCOVER — find an exposed endpoint.** An internet-reachable FHIR base URL or an open `DICOM` port — thousands of them, most accepting connections with no AE-Title validation at all. 2. **CREDENTIAL — default, weak, or over-broad.** A default password, a `hardcoded key` from an app bundle, or an over-broad `SMART-on-FHIR` scope / mis-scoped token. Auth says yes; nothing behind it is a *machine*. 3. **CONVERGE — cross the IT/OT/IoMT bridge.** Land on the flat, converged clinical segment where the imaging network, the pumps, and the EHR share trust — the convergence bridge does the pivoting for you. 4. **IMPERSONATE — flat-network IP-trust, defeated.** A pump, a PACS, an endpoint authenticates a *claim* — a same-VLAN IP, a shared cred. Present it and you *are* the device. Nothing checks a key. 5. **ACT — scrape PHI or move an order.** Walk records via FHIR `BOLA`, pull exams over unauth `DICOM C-STORE`, or manipulate an infusion or imaging order. Legitimate-looking, at population scale. 6. **VANISH & REUSE — no attribution, then cross-org.** Egress hops clouds and residential proxies — a fresh *last IP*, nothing to correlate. Then reuse the loot at organization B: a credential burned at A still works, because there is no cross-org revocation. Invisible *by design*: a clinician's app is one session to one record; the abuser is one operator to a whole population — holding valid credentials, showing you a disposable address every few requests, reusing at org B what it burned at org A. And the stakes are physical, at the class level: peer-reviewed Medicare-claims research finds in-hospital mortality rises 35–41% for patients *already admitted* when a ransomware attack begins, and neighboring emergency departments degrade as ambulances divert. A single third-party clearinghouse compromise cascaded nationally to roughly 190 million individuals — about a third of all US records, the largest healthcare breach on record. Healthcare has been the costliest industry to breach for 14 consecutive years. --- ## The reframe · stop detecting the abuse, prove the identity Detection will always be a step behind a credential that is genuinely valid. You can tune anomaly models forever and the abuser still looks exactly like a peer — because, to your endpoint, it is one. The only strictly-stronger move is to change what the endpoint trusts. **Today · the endpoint trusts a claim.** A session token, an OAuth scope, an API key, a same-subnet IP — whoever holds it can present it. The credential proves a *claim*, never *which device or which endpoint* is on the other end, so a stolen one is indistinguishable from the real thing — and the source IP that *might* have narrowed it is disposable. **Tomorrow · the endpoint authorizes a machine that proves itself.** Bind authority to an identity the device or FHIR endpoint *holds* and can demonstrate cryptographically, not a secret anyone can copy. Now a request either proves it is the endpoint it claims to be — before a single detection rule runs — or it has no authority at all. Detection stops being the last line of defense and becomes a bonus. That identity already has a home on the networks that connect your HDO, your device vendors, and your HIE partners: an address. Here is how an endpoint's own key becomes an address no one can forge — and, unlike UDAP's private trust, one that verifies across every one of those org boundaries. --- ## The cure · the address is the device Whisper has one primitive: **the address is the identity.** A routable IPv6 **/128** out of `2a04:2a01::/32` (announced by **AS219419**), deterministically derived from a key, DNSSEC-anchored, **DANE-EE** pinned, RDAP/WHOIS-registered — re-derivable and verifiable by anyone with `dig`. **Point it at the endpoint.** Derive each FHIR endpoint's — or each device's — /128 from the public key it already holds: the **UDAP** server-cert key that anchors its base URL, the device's secure element, a TPM, an 802.1AR-style IDevID — with the FHIR **`Endpoint.identifier`** or the **FDA UDI** (Device Identifier) as the domain separator. The private key never leaves the device; the address is a one-way function of its public half and that identifier. No re-flashing the fielded fleet — you bind the identity the endpoint or device already carries. (For an ISO/IEEE 11073 point-of-care device already named by a 64-bit `EUI-64`, that hardware identity is simply one more native identifier it can pass as its `device_id` domain separator — the address stays a one-way function of the device's key and that identifier, never the `EUI-64` in the clear.) ``` Endpoint / device key ── public key + identifier ──▶ /128 ── DNSSEC + DANE-EE 3 1 1 ──▶ a name ANY party can verify UDAP cert · secure element · 2a04:2a01:9a::f417 whisper verify --trustless TPM · 802.1AR IDevID routable, tenant-bound (outside the community · no anchor) id: Endpoint.identifier / FDA UDI op:'revoke' → gone at DNS-TTL (private key stays on the device) UDAP asserts base-URL ↔ cert PRIVATELY (community CA · TEFCA / state-HIE anchor · CRL/OCSP in-community) DANE-EE publishes the SAME binding PUBLICLY (verifiable across HDO ↔ vendor ↔ HIE — no pre-provisioned anchor) ``` UDAP already binds the FHIR base URL to the server certificate — a genuinely good binding, trapped in a private community anchor and revoked only by in-community CRL/OCSP. Whisper keeps the exact binding, DANE-pins it into DNSSEC, and makes it publicly verifiable and revocable across the HDO ↔ vendor ↔ HIE boundary. Complements the community CA; never replaces it. What becomes true the moment an endpoint holds one: - **"Scrape one endpoint → the whole HIE" becomes impossible.** You cannot present thousands of endpoint identities whose keys you don't hold; every forgery is a DNSSEC/DANE inconsistency any verifier catches. - **IP rotation becomes irrelevant.** Identity is not the source IP — the "last IP" was never the credential, so rotating it across clouds or residential proxies changes nothing. - **Stolen tokens and hardcoded keys fail.** A replayed OAuth token or a key lifted from an app bundle, with no endpoint key behind it, authenticates to nothing. - **One `revoke` kills a compromised identity everywhere** at DNS-TTL speed, across every relying party and organization: `dig -x` returns nothing, verify returns false — the cross-org off-switch UDAP's CRL/OCSP never delivered. > **"UDAP already gives our FHIR endpoints X.509 identity. Why isn't that enough?"** > Because it can't be verified outside your community, and revocation is slow and > anchor-scoped. UDAP's identifying URI is the FHIR base URL, which SHALL match a > `uniformResourceIdentifier` in the server cert's `SubjectAltName` — a real, good binding. > But it lives in a private community CA, is trusted only by parties provisioned with that > anchor, and revokes via in-community CRL/OCSP. Whisper keeps the exact binding, DANE-pins > it into DNSSEC, so a relying party who never joined your community verifies it against the > DNS root — and one revoke drops it for everyone at DNS-TTL. **The `Endpoint.identifier` is the public index — the /128 is its cryptographic counterpart.** The identifier and base URL flow through every directory (TEFCA/RCE, the National Directory) — good for interoperability, but not a secret. The /128 is bound to the endpoint's key *and* its identifier, so the identifier alone yields nothing: you cannot go `Endpoint.identifier` → /128 without the key, there is no enumerable directory, and RDAP/reverse-DNS return the registry object, never the endpoint's whereabouts. Because the derivation is **tenant-bound**, the same device under two HDOs yields two unrelated /128s — no one can link a unit across organizations. **Additive, never a replacement.** Whisper complements the anchors you already run — UDAP/SSRAA, SMART-on-FHIR, the TEFCA/QHIN trust fabric, an OEM's device PKI, TPM/HSM/secure elements. It is the publicly verifiable, DNSSEC/DANE-anchored layer *on top*, anchoring the endpoint↔caller and device↔cloud boundary — a *second* proof keyed to `Endpoint.identifier` that hardens what UDAP already asserts. It never reaches into HL7v2 on the clinical bus, an unauthenticated DICOM association between two same-segment nodes, or a device's own on-board command path — those stay a segmentation and protocol-auth problem. Complements, never replaces. **Lifecycle, end to end.** Enrollment → in-life authorization → incident `revoke`. A board swap or module replacement re-keys to a new /128 and revokes the old one; a decommission or a change of custodian is one `revoke` and a re-register to the new owner. Compromise one device and you've compromised *that device*, not the fleet. And nothing is issued in the dark: every mint and every revoke lands in a public, append-only **RFC 6962 Merkle transparency log**, Ed25519-signed and anchored to Bitcoin via OpenTimestamps — an auditable issuance trail for your regulator. *Honest status: tamper-evident today; independent witnessing is the next step.* Maps to FDA **§524B(b)(1)/(b)(2)** authentication + postmarket-containment evidence, the **HIPAA Security Rule NPRM**'s asset-inventory / network-map / segmentation / **§164.312(a)(d)** entity-authentication asks, **EU MDR** Annex I §17.4, and **IEC 62443 FR1** — delivered as a network primitive, not a compliance binder. --- ## See & govern — the surface no one else has An identity you can prove is also one you can *watch*. Because every endpoint's name resolves through Whisper's own authoritative DNS and RDAP, the owner sees exactly who looked — a reconnaissance tripwire the community directory never gave you — and can govern precisely what each device may talk to. - **Who checked this endpoint is a query.** `op:lookups` (and the keyless `/ip//lookups`) returns who resolved or RDAP-queried an endpoint's identity — an early warning that someone is enumerating your FHIR endpoints, *before* the scrape, not a post-mortem after it. Shipped & live. - **Govern what each device may reach.** A graph-first resolver and source-bound egress enforce **default-deny** per device — allow the EHR and the vendor's update endpoint, block everything else, by name or subnet. Agentless **L3 segmentation** for the machines that can't take a NAC agent — direct substance for the HIPAA NPRM network-map + segmentation asks. - **Per-device firewall, budget, kill-switch.** `op:firewall` allow/deny by host, cidr or port; `op:budget` caps a device's traffic; `op:revoke` cuts a compromised unit off worldwide in one call — no re-imaging, no truck roll. - **Non-repudiable telemetry & orders.** Sign a device's outputs to its forge-proof /128 so a downstream system, an auditor, or an FDA postmarket review can trust an infusion log or an imaging order came from the *real* device — not a spoof on the segment. The same *address-is-identity* primitive that governs a compromised pump also governs the AI agents your HDO is about to run against PHI — per-agent /128, per-agent logs, default-deny egress, one `revoke`. From day one. --- ## The graph · for what already got in Identity stops the next forgery. The graph names whoever already scraped you. You won't re-key every endpoint by Monday, and there is abuse in your logs right now — 41% of 2024 healthcare breaches started with a third-party vendor. So the same platform back-traces the operator behind the sessions you already logged — attribution that *survives* the rotation and *crosses* the organization boundary your inventory tools can't see past. **The answer — the graph, not another rate-limit.** A live internet-infrastructure graph — billions of nodes and relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms — fingerprints the *operator*, not the IP. Two levers, kept honestly separate: for **cloud rotation** the graph clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy; for a **residential-proxy swarm** — where a subscriber IP gives an infra graph nothing to grab — a `JA4/JA3` client fingerprint travels with the *tooling* regardless of the exit and collapses the swarm to one operator. **And it's a question, not a signature.** Express the abuse directly — *"one source touching N distinct endpoint- or device-identities across orgs in a window"* — as read-only Cypher, and the graph returns the operator with a reproducible evidence chain your SOC, your `PSIRT`, an OCR investigator and a regulator can replay. That's rogue-aggregator and `BOLA` scraping caught by its shape across the fleet, not by a pattern you had to know in advance. ```bash # ask the graph the business-logic question directly — read-only Cypher over the public graph API curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \ -H 'content-type: application/json' -d '{"query":"MATCH (src)-[t:TOUCHED]->(e:EndpointIdentity) WHERE t.window = \"15m\" WITH src, count(DISTINCT e) AS endpoints WHERE endpoints > 25 RETURN src, endpoints ORDER BY endpoints DESC"}' operator 1 source → 1,204 distinct endpoints / 15m · across 3 HIE orgs egress: AWS eu-central → GCP europe-w4 → Azure westeu (collapsed to 1) ja4: same tooling across 41 residential exits → 1 operator reproducible, replayable JSON evidence chain → your SIEM ``` > **"When they rotate residential proxies and fresh cloud IPs, can you actually attribute them — > or just rate-limit an IP and move on?"** > Track them. Infrastructure genealogy collapses the cloud rotation; a JA4 client fingerprint > collapses the residential swarm. The egress IP is the one thing we don't rely on — so the > rotation that hides them from your SOC is exactly what the graph reads through, and it reaches > across the org boundary your inventory tools stop at. The verbs your analysts run — or your agent runs for them: `identify(ip)` (who really operates a host, even behind a CDN) · `origins(prefix)` + `walk(node,depth)` (cluster rotating IPs into one genealogy) · `history` / `watch` (a timeline and a standing sentinel over a suspect operator). Every answer is reproducible, replayable JSON: the HIPAA and GDPR paper trail for an unauthorized-aggregator finding, not a screenshot. Identity is the cure; the graph is how you clean up what got in before it — and catch the operator who tries anyway, even across organizations. Detection made durable, on top of a root-cause fix. --- ## Honest scope — what this does, and what it doesn't This is an identity, attribution and reachability control. It is powerful precisely because it is narrow, so here is the honest boundary — the same one we'd want asked in a review. **What it governs** - **WHO may reach and speak to** a device or FHIR endpoint — egress governance + reachability. - Kills stolen-static-credential and **hardcoded-key** possession — a secret alone no longer suffices. - A publicly verifiable endpoint anchor that shrinks **token-replay and rogue-aggregator** scraping across orgs. - **Attribution** that survives egress/IP rotation and crosses the organization boundary. - **Cross-org revocation** at DNS-TTL — a credential burned at org A stops verifying against org B. - The forge-proof asset-identity + issuance evidence FDA §524B and the HIPAA NPRM inventory/segmentation asks demand. **What it does NOT do** - Does **not stop a purely internal, unauthenticated-protocol manipulation** once an attacker is already on the clinical segment — an HL7v2 injection or an unauth DICOM C-STORE between two same-segment nodes is a segmentation + protocol-auth problem; *in-path enforcement is still needed*. - Is device/endpoint identity, **not human MFA** and not user authentication — it proves which machine is on the wire, never who the clinician is; it does not satisfy the NPRM's MFA ask for human logins. - Does **not patch the unpatchable CVE** — URGENT-11 / Ripple20-class flaws stay exploitable on-path; it reduces *who can reach* the device and attributes them, it does not fix the bug. - Identity is **only as forge-proof as key custody** — an end-of-life device with no TPM or secure element has weaker key storage, and we say so. - Provides **no §524B SBOM**, encryption-at-rest, vuln-scanning or pen-testing — those stay yours. In one line: an **identity, attribution and reachability** control — complementary to network segmentation, device patching and lifecycle, and protocol-level authentication of legacy clinical traffic. Additive by construction. The HIPAA NPRM is directional, not yet final — the current-law hooks are **§164.312(a)/(b)/(d)/(e)** and the §164.308 risk analysis. --- ## Prove it in 60 seconds · no account Two tiers, by design. **No key:** anyone can verify an endpoint's identity, resolve it, and see who's been checking it — trustless, anchored at the IANA root. **Your key:** bind a device to the identifier it carries, govern its egress, back-trace a rogue caller, revoke it worldwide. ```bash # keyless — re-derive and verify any device or FHIR endpoint identity, trustless whisper verify --trustless 2a04:2a01:9a::f417 ✓ DNSSEC chain valid to the IANA root ✓ DANE-EE (TLSA 3 1 1) leaf matches the endpoint's UDAP server cert ✓ RDAP: registered under AS219419 · 2a04:2a01::/32 identity: VERIFIED — and our own API was never trusted # the address is the endpoint — reverse DNS names it (the Endpoint.identifier) dig -x 2a04:2a01:9a::f417 +short fhir.example-hie.whisper.online. # who's been checking this endpoint — a recon tripwire, still no key curl -s https://whisper.online/ip/2a04:2a01:9a::f417/lookups | jq '.recent[0]' { "kind":"TLSA", "from_asn":"AS…", "note":"someone is enumerating your FHIR endpoints" } # who really operates a suspicious caller — with your key, via the public graph API curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \ -H 'content-type: application/json' -d '{"query":"CALL whisper.identify(\"34.90.x.x\")"}' operator: · seen across AWS / GCP / Azure residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator ``` ```bash # bind a FHIR endpoint (or a device) to the identifier it already carries, and govern it export WHISPER_API_KEY=whisper_live_xxx curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" \ -H 'content-type: application/json' --data @- <<'JSON' {"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'', device_id:'2.16.840.1.113883.3.72.5.2'}}) YIELD op,ok,status,result,error RETURN op,ok,status,result,error"} JSON → identity 2a04:2a01:9a::f417 DNSSEC + DANE-EE live # device_id = Endpoint.identifier (or the FDA UDI) whisper policy set --default deny --allow ehr.example-hdo.org,updates.vendor.example whisper kill --revoke 2a04:2a01:9a::f417 # worldwide, at DNS-TTL — across every relying party ``` --- ## The fit · additive, mapped, priced Your IoMT visibility tool tells you *what* is on the network and infers identity from behavior, inside one organization's console — necessary, and where that picture stops. UDAP proves endpoints inside a private community anchor. Whisper adds the two layers no one else owns: a **publicly verifiable, DNS/DANE-anchored** device and endpoint identity, and **cross-organization attribution** across rotating egress. It's depth on top of the stack you already run — not a console your analysts babysit. | | IoMT visibility | FHIR / UDAP endpoint trust | Whisper | |---|---|---|---| | Medical-device asset discovery & inventory | ✓ | — | additive (consumes UDI as `device_id`) | | **Publicly verifiable** DNS/DANE-anchored device/endpoint identity | — | partial (private anchor) | ✓ | | Cross-**organization** attribution across rotating egress | — | — | ✓ | | Cross-org revocation at DNS-TTL of a routable identity | — | partial (CRL/OCSP) | ✓ | - **Feeds your SIEM and PSIRT.** The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings arrive as signed, replayable JSON mapped to CEF and ECS fields — with **STIX 2.1 over TAXII** and H-ISAC export on the roadmap — that you can hand OCR or push straight into a PSIRT workflow. - **Speaks your compliance language.** Direct substance for FDA **§524B(b)(1)/(b)(2)** authentication + postmarket containment, three of the HIPAA NPRM's hardest asks — **asset inventory, network map, segmentation** — plus §164.312(a)/(d) entity auth, EU MDR Annex I §17.4, and IEC 62443 FR1. Honest: not SBOM, not human MFA, and the NPRM isn't final. - **Additive to your IoMT platform.** Plugs into **Claroty, Armis, Forescout, Ordr, Palo Alto** — consuming their inventory's UDI as the `device_id` — and publicly anchors a Medcrypt- or UDAP-issued leaf. No new appliance, no sensor vantage, no re-enrollment. - **Availability-safe by construction.** It rides existing DNS/IPv6 and adds **no inline clinical chokepoint**. If your endpoint authorizes against the DANE/verify path, that plane is built to **fail open** — a Whisper outage never bricks a pump or a scanner; checks degrade to your existing anchors. Anycast on AS219419, no single node in the path. - **On-prem or your own tenant.** Data residency, HIPAA and GDPR by construction — the graph and the per-device logs stay where your regulator needs them. No PHI and no whole-fleet telemetry leaving your boundary to a third party you never contracted. - **A vendor that will still be here.** Real routable address space (AS219419), run by people who ran the internet's regional address registry and operated one of its root DNS servers. POC → pilot → enterprise, keyless to start — a flat, per-device line item, not per-transaction. --- ## Give every device an identity it can prove The address is the device — routable, DNSSEC-anchored, verifiable across the org boundary UDAP can't cross, revocable worldwide in one call. Keyless to try, one call to provision, one more to revoke. The device and FHIR-API abuse that no rate-limit ever caught simply runs out of forgeries. Or run `whisper verify --trustless` right now.