Mapping the Hospital and Medical Device Threat Taxonomy

Brett Crawley
Brett Crawley 8 min read

Mapping the Hospital and Medical Device Threat Taxonomy to STRIDE, LINDDUN, CAPEC, CWE, ATT&CK, EMB3D and MDS2

TL;DR

  • Every one of the 231 entries in the Hospital and Medical Device Threat Taxonomy is mapped to as many as seven frameworks: STRIDE, LINDDUN, CAPEC 3.9, CWE 5.0, ATT&CK v20.0, MITRE EMB3D and the MDS2 security capabilities.
  • Coverage: CWE 222 entries, MDS2 225, CAPEC 184, ATT&CK 183, LINDDUN 76, EMB3D 73.
  • 7 entries have neither a CAPEC pattern nor a CWE weakness, and all of them are about running a hospital through an incident. That’s a finding in itself.
  • Integrity beats confidentiality. 73 entries point to an MDS2 integrity capability; 31 to a confidentiality one.
  • Every ID was checked against MITRE’s own data. CWE 5.0 retired CWE-613, so three entries now map to its successors.
Mapping the Hospital and Medical Device Threat Taxonomy: the seven frameworks over a faint radiograph of a chest.

In The Hospital Never Closes I published the Hospital and Medical Device Threat Taxonomy, the reference for my Critical Condition card game: 231 entries, each with a threat, a mitigation principle and design measures. This post is about the other half of each entry, the mappings.

Mappings are what let a finding travel. A threat found at a card table has to end up in a risk file, a premarket submission, a procurement question or a SOC rule, and each of those speaks a different framework. So I mapped every entry to the frameworks those people already use, and then looked at where the mappings run out. As usual, the gaps are more interesting than the coverage.

How the mappings were made and checked

Each entry was mapped by hand, then every ID was checked against the source data:

  1. ATT&CK Enterprise and ATT&CK for ICS from MITRE’s v20.0 release (October 2026). Revoked and deprecated techniques were excluded.
  2. CAPEC 3.9, from MITRE’s STIX data. Deprecated patterns were excluded.
  3. CWE 5.0 (28 October 2026). Only weaknesses whose mapping usage is Allowed or Allowed-with-Review were used, so there are no categories and no Discouraged or Prohibited entries.
  4. MITRE EMB3D, from MITRE’s published threat list, used only for entries about embedded devices.
  5. MDS2 codes from ANSI/NEMA HN 1-2019, the Manufacturer Disclosure Statement for Medical Device Security.

One thing changed while I was writing. CWE 5.0 retired CWE-613 Insufficient Session Expiration and replaced it with a family of more precise session weaknesses. Three entries used it, so CRI-CC-6 now maps to CWE-1463 Insufficient Session Timeout Value, CRI-EC-6 to CWE-1467 Use of Singular Authentication Artifact for Multiple User Sessions, and CRI-AC-7 to CWE-1463 and CWE-1464 Improper Session Invalidation.

The rule throughout was fit over coverage. A blank cell means nothing fitted well; a loose tag would only mislead.

Coverage at a glance

Mapping coverage by suit: for each of the 17 suits and the structural hazards, how many entries map to CAPEC, CWE, ATT&CK, EMB3D, MDS2 and LINDDUN.

Across all 231 entries:

  • CWE: 222 entries, 102 distinct weaknesses.
  • MDS2: 225 entries, all 22 capabilities used.
  • CAPEC: 184 entries, 97 distinct patterns.
  • ATT&CK: 183 entries, 87 distinct techniques (59 Enterprise, 28 ICS).
  • LINDDUN: 76 entries.
  • EMB3D: 73 entries, 31 distinct device threats.

Read by suit, the shape is clear. The device suits map almost everywhere, because devices are where the classic frameworks were built to look. The gaps open up in Continuity and Downtime (9 of 13 entries without a CAPEC pattern), the structural hazards (9 of 10) and Clinical Software and AI (7 of 13): recovery, the hospital as a whole and clinical judgement, none of which is an attack on a component.

STRIDE and LINDDUN

STRIDE and LINDDUN: entries per category. Tampering leads STRIDE with 110 entries; Data disclosure leads LINDDUN with 58.

STRIDE fits 227 of the 231 entries. The four it doesn’t are Trumps: CRI-TR-2 The device outlives its software, CRI-TR-3 Nobody owns the bedside, CRI-TR-4 Safety cases assume accidents, CRI-TR-7 Patch means revalidate. Those are properties of how hospitals buy, own and certify technology, and there’s no STRIDE category for “nobody owns it”.

Tampering leads with 110 entries, then Denial of service with 81. Split by deck, the picture changes. In The Patient deck Tampering dominates (63 of 104 entries), because the worst thing you can do to a device is make it do the wrong thing quietly. In The Hospital deck Denial of service comes first (49 of 117), because the worst thing you can do to a hospital is stop it.

LINDDUN applies to 76 entries, led by Data disclosure (58) and Identifying (37). Every entry in the Records and Patient Data suit carries a LINDDUN mapping (13 of 13), which is what you’d expect. What surprised me is how far privacy reaches beyond the record: into RTLS tags that track staff and patients, pagers read off the air, waveform archives and imaging metadata.

CAPEC, CWE and the gap

The references the taxonomy leans on: the eight most-used CWE weaknesses, ATT&CK techniques and EMB3D threats.

The most-used CWEs are CWE-1357 Reliance on Insufficiently Trustworthy Component (22), CWE-359 Exposure of Private Personal Information to an Unauthorized Actor (22), CWE-306 Missing Authentication for Critical Functionality (20), CWE-353 Missing Support for Integrity Check (19). That’s a fair summary of medical device security in four lines: components trusted that shouldn’t be, data exposed, functions with no authentication, and data with no integrity check.

Now the gap. 7 entries have neither a CAPEC pattern nor a CWE weakness:

  • CRI-CD-10 Downtime procedures nobody has practised
  • CRI-CD-8 Diversion overloads the neighbours
  • CRI-CD-5 Incident communications on compromised systems
  • CRI-CD-4 No planned restore order
  • CRI-CD-3 Extortion deadlines rush the recovery
  • CRI-TR-9 The hospital never closes
  • CRI-TR-10 Hospitals are strategic targets

Every one of them is about running a hospital through an incident: downtime procedures, diversion, restore order, incident communications, extortion deadlines, and the two Trumps about the hospital as critical infrastructure. They’re real threats with real consequences, and there’s no weakness to file them under, because the weakness isn’t in the code. It’s in the plan. If your threat modeling only finds threats it can tag with a CWE, it will never find these. That’s the strongest argument I know for a domain taxonomy.

ATT&CK closes that gap from the other side: no entry lacks all three of CAPEC, CWE and ATT&CK, because ATT&CK has techniques for impact, such as Service Stop and Data Encrypted for Impact. The top techniques are T1565.001 Stored Data Manipulation (19), T1565.002 Transmitted Data Manipulation (18), T0836 Modify Parameter (16). 64 entries use ATT&CK for ICS techniques, mostly devices and building systems, where Modify Parameter and Manipulation of View describe a monitor or a pump better than any Enterprise technique.

EMB3D: the device view

EMB3D maps to 73 entries: 49 in The Patient deck and 23 in The Hospital deck. The most-cited device threats are TID-406 Unauthorized Messages or Connections (12), TID-310 Remotely Accessible Unauthenticated Services (8), TID-210 Device Vulnerabilities Unpatchable (8). EMB3D is the right tool for the device maker. The taxonomy uses it where the threat lives inside the device, and leaves it out where the threat is the device’s place in the hospital.

MDS2: what to check when you buy

MDS2 capabilities: how many entries cite each capability of the MDS2 form, and how many cite it as the main one.

This is the mapping I’m most pleased with. The MDS2 form (the Manufacturer Disclosure Statement for Medical Device Security) is the questionnaire hospitals already ask vendors to fill in when they buy a device. Each taxonomy entry names the capabilities a sound device or system shows against that threat, main one first, so a finding from the card table turns straight into a procurement question.

225 entries map to MDS2. The 6 that don’t are about people and operations rather than products: Patients trained to click hospital links, Backup radio and satellite never tested, Diversion overloads the neighbours, Incident communications on compromised systems, Payments and claims stop flowing, Hospitals are strategic targets.

The three most-cited capabilities are IGAU Health data integrity and authenticity (62 entries, 39 as the main one), AUDT Audit controls (57) and AUTH Authorization (52). Add TXIG Transmission integrity and 73 entries point to an integrity capability, against 31 for confidentiality. In a hospital, the question isn’t only “who can see it?” but “can I trust what the monitor, the pump and the result say?”

At the other end, EMRG Emergency access appears on only 6 entries and ALOF Automatic logoff on 4. They’re few, but they’re the ones where security and care pull hardest against each other, and they tie back to Trump CRI-TR-1 Life before login.

Note to procurement and clinical engineering: when you play the game, write the MDS2 code next to each finding on the log. You’ll leave the session with a list of the answers to check on the next vendor’s form.

Standards

201 entries name at least one standard that addresses them directly. The most common are IEC 80001-1 (86), ISO 27799 (46), FDA premarket (32). IEC 80001-1 leads because so many threats only appear once a device is connected to a hospital’s network and processes, which is exactly the ground that standard covers.

Final thoughts

The frameworks cover the devices well. If your threat model asks whether someone can reprogramme the pump, spoof the monitor or tamper with the image, CAPEC, CWE, ATT&CK and EMB3D will all help you name what you find. That’s not where hospitals have suffered most.

The entries the frameworks miss share a shape. They’re about the hospital carrying on: the downtime procedure nobody practised, the diversion that overloads the neighbours, the restore order nobody planned, the extortion deadline that rushes recovery. A general framework tells you what kind of thing went wrong. A domain map tells you where to look.

If you think I’ve mapped an entry too generously or too harshly, or know a CAPEC pattern, a CWE weakness or an EMB3D threat I missed, tell me on LinkedIn and I’ll update the mapping.

Stay tuned!

References

You may also like: