{ "@context": { "skos": "http://www.w3.org/2004/02/skos/core#", "dcterms": "http://purl.org/dc/terms/", "cc": "http://creativecommons.org/ns#", "owl": "http://www.w3.org/2002/07/owl#", "xsd": "http://www.w3.org/2001/XMLSchema#", "ost": "https://ostering.com/ns/taxonomy#", "prefLabel": { "@id": "skos:prefLabel", "@language": "en" }, "definition": { "@id": "skos:definition", "@language": "en" }, "notation": "skos:notation", "inScheme": { "@id": "skos:inScheme", "@type": "@id" }, "topConceptOf": { "@id": "skos:topConceptOf", "@type": "@id" }, "hasTopConcept": { "@id": "skos:hasTopConcept", "@type": "@id" }, "broader": { "@id": "skos:broader", "@type": "@id" }, "narrower": { "@id": "skos:narrower", "@type": "@id" }, "broadMatch": { "@id": "skos:broadMatch", "@type": "@id" }, "closeMatch": { "@id": "skos:closeMatch", "@type": "@id" }, "relatedMatch": { "@id": "skos:relatedMatch", "@type": "@id" }, "scopeNote": { "@id": "skos:scopeNote", "@language": "en" }, "principle": { "@id": "ost:mitigationPrinciple", "@language": "en" }, "measures": { "@id": "ost:designMeasure", "@container": "@list" }, "prompts": { "@id": "ost:mitigationPrompt", "@container": "@list" }, "harm": "ost:harm", "physicalSafety": { "@id": "ost:physicalSafety", "@type": "xsd:boolean" }, "deck": "ost:deck", "rank": "ost:rank", "stride": { "@id": "ost:stride", "@type": "@id" }, "linddun": { "@id": "ost:linddun", "@type": "@id" }, "mds2": "ost:mds2Capability", "standard": "ost:standard", "seenIn": { "@id": "ost:seenIn" }, "source": { "@id": "dcterms:source", "@type": "@id" }, "title": "dcterms:title", "license": { "@id": "dcterms:license", "@type": "@id" }, "ccLicense": { "@id": "cc:license", "@type": "@id" }, "rights": "dcterms:rights", "creator": "dcterms:creator", "issued": { "@id": "dcterms:issued", "@type": "xsd:date" }, "versionInfo": "owl:versionInfo" }, "@graph": [ { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "@type": "skos:ConceptScheme", "prefLabel": "Hospital and Medical Device Threat Taxonomy", "title": "Hospital and Medical Device Threat Taxonomy", "definition": "This is the reference for the Critical Condition card game: every card's threat, the mitigation principle a sound design follows, design measures, and mappings to STRIDE, LINDDUN, CAPEC, CWE, ATT&CK, EMB3D and MDS2.", "creator": "Jonathan Brett Crawley", "issued": "2026-11-04", "versionInfo": "1.0", "license": "https://creativecommons.org/licenses/by-nc-nd/4.0/", "ccLicense": "https://creativecommons.org/licenses/by-nc-nd/4.0/", "rights": "© 2026 Jonathan Brett Crawley. Hospital and Medical Device Threat Taxonomy v1.0, licensed under CC BY-NC-ND 4.0 with additional permissions: threat modeling with it (including for paying clients), internal use and training, and quoting entries with credit are allowed; shipping it in a product needs written permission. Terms: https://ostering.com/taxonomies/hospitals-and-medical-devices/#licence", "hasTopConcept": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/" ] }, { "@id": "https://ostering.com/ns/stride#", "@type": "skos:ConceptScheme", "prefLabel": "STRIDE" }, { "@id": "https://ostering.com/ns/stride#S", "@type": "skos:Concept", "notation": "S", "prefLabel": "Spoofing", "inScheme": "https://ostering.com/ns/stride#" }, { "@id": "https://ostering.com/ns/stride#T", "@type": "skos:Concept", "notation": "T", "prefLabel": "Tampering", "inScheme": "https://ostering.com/ns/stride#" }, { "@id": "https://ostering.com/ns/stride#R", "@type": "skos:Concept", "notation": "R", "prefLabel": "Repudiation", "inScheme": "https://ostering.com/ns/stride#" }, { "@id": "https://ostering.com/ns/stride#I", "@type": "skos:Concept", "notation": "I", "prefLabel": "Information disclosure", "inScheme": "https://ostering.com/ns/stride#" }, { "@id": "https://ostering.com/ns/stride#D", "@type": "skos:Concept", "notation": "D", "prefLabel": "Denial of service", "inScheme": "https://ostering.com/ns/stride#" }, { "@id": "https://ostering.com/ns/stride#E", "@type": "skos:Concept", "notation": "E", "prefLabel": "Elevation of privilege", "inScheme": "https://ostering.com/ns/stride#" }, { "@id": "https://ostering.com/ns/linddun#", "@type": "skos:ConceptScheme", "prefLabel": "LINDDUN" }, { "@id": "https://ostering.com/ns/linddun#L", "@type": "skos:Concept", "notation": "L", "prefLabel": "Linking", "inScheme": "https://ostering.com/ns/linddun#" }, { "@id": "https://ostering.com/ns/linddun#I", "@type": "skos:Concept", "notation": "I", "prefLabel": "Identifying", "inScheme": "https://ostering.com/ns/linddun#" }, { "@id": "https://ostering.com/ns/linddun#Nr", "@type": "skos:Concept", "notation": "Nr", "prefLabel": "Non-repudiation", "inScheme": "https://ostering.com/ns/linddun#" }, { "@id": "https://ostering.com/ns/linddun#D", "@type": "skos:Concept", "notation": "D", "prefLabel": "Detecting", "inScheme": "https://ostering.com/ns/linddun#" }, { "@id": "https://ostering.com/ns/linddun#DD", "@type": "skos:Concept", "notation": "DD", "prefLabel": "Data disclosure", "inScheme": "https://ostering.com/ns/linddun#" }, { "@id": "https://ostering.com/ns/linddun#U", "@type": "skos:Concept", "notation": "U", "prefLabel": "Unawareness and unintervenability", "inScheme": "https://ostering.com/ns/linddun#" }, { "@id": "https://ostering.com/ns/linddun#Nc", "@type": "skos:Concept", "notation": "Nc", "prefLabel": "Non-compliance", "inScheme": "https://ostering.com/ns/linddun#" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "@type": "skos:Concept", "notation": "CRI-IM", "prefLabel": "Implants and Programmers", "definition": "Pacemakers, ICDs, neurostimulators, cochlear and retinal implants and implantable pumps, with the programmers, home transmitters and clouds that talk to them.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-a", "@type": "skos:Concept", "notation": "CRI-IM-A", "prefLabel": "Unauthenticated therapy commands over the air", "definition": "The implant accepts programming commands over its radio link without proving the programmer is genuine. Anyone within range with a suitable transmitter could change pacing, stop therapy or deliver a shock.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "An implant acts only on commands from a programmer it has authenticated, over a link protected for integrity.", "measures": [ "Require mutual authentication between implant and programmer before any therapy-changing command is accepted.", "Protect every command with message integrity and freshness so injected or altered commands are rejected.", "Limit the commands available over long-range radio; keep therapy changes to close-range sessions.", "Log every programming session in the implant for review at the next follow-up." ], "prompts": [ "How does the implant know the programmer talking to it is genuine?", "Which therapy changes can be made over the radio link at all?", "What stops a nearby transmitter injecting a programming command?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "NAUT", "AUTH", "TXIG" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/594.html", "https://capec.mitre.org/data/definitions/216.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/940.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0831/", "https://emb3d.mitre.org/threats/TID-406.html", "https://emb3d.mitre.org/threats/TID-310.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "Medtronic Conexus telemetry, 2019", "source": [ "https://cisa.gov/ics/advisories/ICSMA-19-080-01" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-k", "@type": "skos:Concept", "notation": "CRI-IM-K", "prefLabel": "Malicious firmware loaded into the body", "definition": "Firmware for the implant can be installed from a programmer or home transmitter without verifying who signed it. A modified build changes therapy or bricks the device, and the only recovery is surgery to replace it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Implant firmware is accepted only when signed by the manufacturer and is never allowed to roll back to a weaker version.", "measures": [ "Verify a manufacturer signature in the implant before installing any firmware, whatever channel delivered it.", "Refuse rollback to earlier firmware with known vulnerabilities.", "Keep a protected fallback image and safe therapy mode if an update fails or is interrupted.", "Restrict firmware installation to in-clinic sessions with a clinician present unless risk analysis justifies remote delivery." ], "prompts": [ "Who signs implant firmware, and where does the implant check it?", "Can an older, weaker firmware version be installed again?", "What happens to therapy if an update fails part way?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#D" ], "mds2": [ "IGAU", "CSUP" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://capec.mitre.org/data/definitions/669.html", "https://cwe.mitre.org/data/definitions/494.html", "https://cwe.mitre.org/data/definitions/347.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1495/", "https://emb3d.mitre.org/threats/TID-211.html", "https://emb3d.mitre.org/threats/TID-213.html", "https://emb3d.mitre.org/threats/TID-216.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "Abbott (St. Jude Medical) pacemakers, 2017", "source": [ "https://www.helpnetsecurity.com/2017/08/31/pacemakers-firmware-update/", "https://www.csoonline.com/article/3222068/465000-abbott-pacemakers-vulnerable-to-hacking-need-a-firmware-fix.html" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-q", "@type": "skos:Concept", "notation": "CRI-IM-Q", "prefLabel": "Remote monitoring cloud controls thousands", "definition": "Home transmitters link implants to the manufacturer's cloud for follow-up and updates. If that cloud or its update path is compromised, an attacker reaches every connected patient at once: harvesting their data, altering transmitters or pushing changes towards implants.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A compromise of the remote monitoring service cannot change therapy in the body or reach all patients at once.", "measures": [ "Never let the cloud issue therapy changes; reserve them for authenticated clinician sessions.", "Sign transmitter updates offline and verify them on the transmitter, so cloud compromise alone cannot push code.", "Segment the service by region and clinic, and rate-limit any fleet-wide action with human approval.", "Encrypt implant data end to end from transmitter to the clinic, not only to the cloud." ], "prompts": [ "What can the monitoring cloud actually change in a patient's implant?", "How many patients would one cloud compromise reach?", "Who reviews changes pushed to home transmitters before release?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#L" ], "mds2": [ "RMOT", "NAUT", "CONN" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/187.html", "https://capec.mitre.org/data/definitions/439.html", "https://cwe.mitre.org/data/definitions/940.html", "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1199/", "https://attack.mitre.org/techniques/T1195/002/", "https://emb3d.mitre.org/threats/TID-303.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-j", "@type": "skos:Concept", "notation": "CRI-IM-J", "prefLabel": "Locked out in an emergency", "definition": "Locking the implant to authenticated programmers can stop an emergency team reading or adjusting it for an unconscious patient far from their clinic. Leaving it open to any programmer instead leaves it open to anyone. Either design can harm the patient.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Emergency access is a deliberate, narrow and logged path, designed with clinicians, not a side effect of weak authentication.", "measures": [ "Provide an emergency mode that needs close physical proximity, such as an inductive or magnet trigger, and expires quickly.", "Limit emergency mode to reading status and applying safe therapy settings.", "Record every emergency session in the implant and report it at the next follow-up.", "Give patients an ID card and publish the emergency procedure for emergency departments worldwide." ], "prompts": [ "How does an emergency team read this implant far from its clinic?", "What can emergency access change, and for how long?", "Where is an emergency session recorded, and who reviews it?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#D" ], "mds2": [ "EMRG", "AUDT", "PAUT" ], "standard": [ "ISO 14971:2019 Medical devices: application of risk management to medical devices", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/115.html", "https://cwe.mitre.org/data/definitions/636.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-10", "@type": "skos:Concept", "notation": "CRI-IM-10", "prefLabel": "Replayed programming sessions", "definition": "Programming messages carry no freshness check, so a recorded session can be played back later. A therapy change the patient once needed is reapplied when it is no longer safe, or a reset is repeated.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every programming command is fresh, bound to one session and useless if replayed.", "measures": [ "Bind commands to a session key agreed at the start of each authenticated session.", "Use counters or nonces so the implant rejects any message it has already processed.", "Expire sessions on a short timer and when the programmer moves out of range." ], "prompts": [ "What makes each programming command unusable a second time?", "How is a command tied to one programming session?", "Would the implant notice a recorded session played back next week?" ], "deck": "The Patient", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "TXIG", "NAUT" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/94.html", "https://cwe.mitre.org/data/definitions/294.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0830/", "https://emb3d.mitre.org/threats/TID-407.html", "https://emb3d.mitre.org/threats/TID-221.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-9", "@type": "skos:Concept", "notation": "CRI-IM-9", "prefLabel": "Magnet and test modes as backdoors", "definition": "Magnet modes, factory test commands and undocumented engineering functions stay reachable in released implants. They suspend shocks, force fixed-rate pacing or expose memory without any electronic authentication, and few clinicians know they exist.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every mode that changes therapy is documented, intended for clinical use and controlled; nothing from manufacturing survives in release.", "measures": [ "Remove or permanently lock factory test and debug commands before implantation.", "Document every magnet and special mode and its clinical effect in the labelling.", "Log entry into special modes and show it at the next interrogation.", "Test released firmware for undocumented commands as part of security verification." ], "prompts": [ "Which magnet, test or engineering modes remain in the released implant?", "Who knows these modes exist, and are they documented for clinicians?", "Can any of these modes be triggered without authentication?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "SAHD", "AUDT" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/36.html", "https://capec.mitre.org/data/definitions/121.html", "https://cwe.mitre.org/data/definitions/912.html", "https://cwe.mitre.org/data/definitions/1269.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0858/", "https://emb3d.mitre.org/threats/TID-224.html", "https://emb3d.mitre.org/threats/TID-401.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-8", "@type": "skos:Concept", "notation": "CRI-IM-8", "prefLabel": "Abandoned implants", "definition": "The manufacturer leaves the market, is sold or stops supporting a product. Patients keep an implant that no clinic can program, no one patches and no one answers for, and replacing it means surgery.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Support for an implant is planned for the life of the patient's device, including what happens if the manufacturer cannot provide it.", "measures": [ "Publish an end-of-support date and a support plan covering programmers, updates and vulnerability handling.", "Escrow programmer software, keys and specifications so a successor or regulator can support patients.", "Design implants to keep safe default therapy if their programmers and services disappear.", "Tell patients and clinicians early when support is ending, with options." ], "prompts": [ "Who programs and patches this implant if the maker stops supporting it?", "Is support promised for the full life of the patient's device?", "What would patients and clinics be told if the product were withdrawn?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "RDMP", "CSUP" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/682.html", "https://cwe.mitre.org/data/definitions/1277.html", "https://cwe.mitre.org/data/definitions/1329.html" ], "relatedMatch": [ "https://emb3d.mitre.org/threats/TID-210.html" ], "harm": "care", "seenIn": [ { "prefLabel": "Argus II retinal implant, 2020", "source": [ "https://spectrum.ieee.org/bionic-eye-obsolete" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-7", "@type": "skos:Concept", "notation": "CRI-IM-7", "prefLabel": "Battery drained by wake-ups", "definition": "The implant's radio can be woken by unauthenticated requests. Repeated wake-ups drain a battery that cannot be recharged, forcing early replacement surgery and, before that, possible loss of therapy.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Unauthenticated traffic cannot make the implant spend meaningful energy.", "measures": [ "Keep the radio asleep until a close-range, low-energy wake mechanism or a scheduled window.", "Rate-limit wake-ups and authentication attempts, and back off sharply after failures.", "Track energy spent on communication and raise an alert at follow-up if it is abnormal." ], "prompts": [ "Can an unauthenticated request wake the implant's radio?", "How much battery could repeated wake-ups cost over a month?", "Would the clinic notice unusual radio activity draining the battery?" ], "deck": "The Patient", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "CONN", "NAUT" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/125.html", "https://cwe.mitre.org/data/definitions/770.html", "https://cwe.mitre.org/data/definitions/799.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1499/", "https://emb3d.mitre.org/threats/TID-405.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-6", "@type": "skos:Concept", "notation": "CRI-IM-6", "prefLabel": "Silent remote follow-up", "definition": "The home transmitter stops sending, is unplugged, loses its connection or sends stale data, and the clinic treats no news as good news. Alerts for arrhythmias, lead faults or low battery are missed for weeks.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Loss of remote follow-up is itself an alert, raised to the clinic and the patient.", "measures": [ "Expect a heartbeat from every transmitter and alert the clinic when one is overdue.", "Timestamp and sequence readings so stale or repeated data is visible.", "Tell the patient on the transmitter or their phone when it cannot reach the service." ], "prompts": [ "How does the clinic learn that a transmitter has gone silent?", "Who is told when follow-up data stops or goes stale?", "Does no news get treated as good news anywhere in this process?" ], "deck": "The Patient", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "CONN", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/754.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0829/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-5", "@type": "skos:Concept", "notation": "CRI-IM-5", "prefLabel": "Clinic programmer as the weak link", "definition": "Clinic programmers run old operating systems, use shared logins and leave the building with field staff. They hold keys and patient data, and a stolen or compromised programmer can reprogram any implant of that make.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A programmer holds no secret that unlocks every implant, and its use is tied to a named, authorised clinician.", "measures": [ "Use per-device or per-session keys issued by a back end, not a fixed key shared by every programmer.", "Require clinician login on the programmer and revoke lost or stolen programmers remotely.", "Harden and patch the programmer's operating system, and encrypt patient data stored on it." ], "prompts": [ "What secrets does a clinic programmer hold, and could one unlock every implant?", "Who may use the programmer, and how is each use attributed?", "What happens when a programmer is lost or stolen?" ], "deck": "The Patient", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "PAUT", "PLOK", "SAHD" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/191.html", "https://cwe.mitre.org/data/definitions/321.html", "https://cwe.mitre.org/data/definitions/1104.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/", "https://emb3d.mitre.org/threats/TID-214.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-4", "@type": "skos:Concept", "notation": "CRI-IM-4", "prefLabel": "Telemetry reveals the patient", "definition": "Implant telemetry and home transmitter traffic travel unencrypted. Anyone nearby with a receiver learns the device serial, the patient's identity or diagnosis and their heart data.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Implant and transmitter traffic reveals nothing about the patient to a listener.", "measures": [ "Encrypt all telemetry carrying patient or device identifiers.", "Avoid sending names or diagnoses over the radio; use identifiers the clinic resolves.", "Verify encryption on the air during security testing, not only in the design." ], "prompts": [ "What can a listener learn from implant or transmitter traffic?", "Is the patient's identity or diagnosis visible on the radio link?", "Which links between implant, transmitter and cloud are encrypted?" ], "deck": "The Patient", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#L" ], "mds2": [ "TXCF" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/157.html", "https://cwe.mitre.org/data/definitions/319.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1040/", "https://emb3d.mitre.org/threats/TID-408.html" ], "seenIn": [ { "prefLabel": "Medtronic Conexus telemetry, 2019", "source": [ "https://cisa.gov/ics/advisories/ICSMA-19-080-01" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-3", "@type": "skos:Concept", "notation": "CRI-IM-3", "prefLabel": "Radio identifiers track the patient", "definition": "The implant or its transmitter broadcasts a fixed identifier. It can be used to detect that a person carries a cardiac or neurological implant and to follow them between places.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The radio does not let a stranger recognise or follow the patient.", "measures": [ "Advertise only when a session is wanted, and with rotating identifiers.", "Keep fixed serial numbers inside the encrypted session.", "Review radio behaviour against tracking during privacy impact assessment." ], "prompts": [ "Does the implant or transmitter broadcast a fixed identifier?", "Could a stranger tell that someone carries an implant?", "How would you stop the radio being used to follow a patient?" ], "deck": "The Patient", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#D" ], "mds2": [ "CONN", "TXCF" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/651.html", "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/#cri-im-2", "@type": "skos:Concept", "notation": "CRI-IM-2", "prefLabel": "No route for researchers' findings", "definition": "Researchers and patients who find flaws in an implant have no clear way to report them, so issues stay unfixed, reach the public without a fix, or are sold. Clinicians learn about them from the news.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/implants-and-programmers/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The manufacturer runs coordinated vulnerability disclosure and tells clinicians and patients what to do.", "measures": [ "Publish a vulnerability disclosure policy and a monitored contact, and acknowledge reports promptly.", "Agree timelines for fixes and advisories with regulators and reporters.", "Send clinicians clear guidance on clinical risk and actions when an advisory is issued." ], "prompts": [ "How does a researcher or patient report a flaw in this implant?", "Who tells clinicians and patients what to do about a reported flaw?", "How long does a reported implant flaw usually take to fix?" ], "deck": "The Patient", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R", "https://ostering.com/ns/stride#I" ], "mds2": [ "SGUD", "CSUP" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/188.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "@type": "skos:Concept", "notation": "CRI-BW", "prefLabel": "Body-worn and Home-use Devices", "definition": "Insulin pumps, CGMs and closed loops, patch and Holter ECG, pulse oximeters, BP cuffs, hearing aids and connected inhalers, and the phones that control them.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-a", "@type": "skos:Concept", "notation": "CRI-BW-A", "prefLabel": "Spoofed controller doses insulin", "definition": "The insulin pump accepts bolus and basal commands from a remote or phone app without strong pairing or authentication. A nearby attacker or rogue app can deliver a fatal overdose or quietly stop insulin.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A pump acts only on dose commands from a paired, authenticated controller, within limits it enforces itself.", "measures": [ "Require authenticated, encrypted pairing and verify every dose command's origin and integrity.", "Enforce maximum bolus and daily limits in the pump, whatever the controller asks.", "Ask for confirmation on the pump or the paired phone before large boluses.", "Alert the user on the pump when an unknown device tries to connect." ], "prompts": [ "Which controllers can send dose commands to the pump?", "What dose limits does the pump enforce on its own?", "How is a new controller paired, and who must confirm it?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "NAUT", "AUTH", "TXIG" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://capec.mitre.org/data/definitions/594.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/290.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0831/", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "Medtronic MiniMed insulin pumps, 2019", "source": [ "https://www.infosecurity-magazine.com/news/medtronic-insulin-pumps-recalled-1", "https://beckershospitalreview.com/supply-chain/medtronic-recalls-insulin-pumps-that-can-be-wirelessly-hacked.html" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-k", "@type": "skos:Concept", "notation": "CRI-BW-K", "prefLabel": "Closed loop trusts a spoofed sensor", "definition": "An automated insulin delivery algorithm doses from glucose sensor readings with no person in the loop. A spoofed, replayed or faulty reading drives it to overdose or withhold insulin, overnight, while the patient sleeps.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Automated dosing trusts only authenticated sensor data and stays within safe bounds when data looks wrong.", "measures": [ "Authenticate the sensor to the controller and protect readings against injection and replay.", "Check readings for physiological plausibility and rate of change before dosing on them.", "Fall back to a conservative basal rate and alert when sensor data is missing or implausible." ], "prompts": [ "How does the dosing algorithm know a sensor reading is genuine?", "What does the loop do when readings look implausible?", "What bounds stop the loop overdosing while the patient sleeps?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "NAUT", "IGAU" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/1293.html", "https://cwe.mitre.org/data/definitions/940.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-q", "@type": "skos:Concept", "notation": "CRI-BW-Q", "prefLabel": "Phone app as the controller", "definition": "The app that controls a pump or reads a sensor runs on a phone the manufacturer does not control: rooted, out of date, shared, full of other apps. Malware or an operating system change can alter doses or stop the app working.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A therapy-critical app assumes the phone may be hostile and keeps safety decisions on the medical device.", "measures": [ "Keep dose limits and safety checks on the pump, never only in the app.", "Check the phone's integrity and operating system version, and warn or degrade safely when unsupported.", "Publish a list of supported phones and versions, and test new operating system releases before users get them." ], "prompts": [ "Which safety decisions are made on the phone rather than the device?", "What happens to therapy if the phone is rooted or out of date?", "How does the app behave after an operating system update?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#D" ], "mds2": [ "MLDP", "RDMP", "SGUD" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle", "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/441.html", "https://cwe.mitre.org/data/definitions/1357.html", "https://cwe.mitre.org/data/definitions/602.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-j", "@type": "skos:Concept", "notation": "CRI-BW-J", "prefLabel": "Firmware pushed through the phone", "definition": "Device updates arrive through the companion app without the device verifying them, or install at a bad moment. A modified update takes control of therapy, and a failed one leaves the patient without insulin or monitoring at night.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The device verifies every update itself and installs only when therapy can safely pause or continue.", "measures": [ "Verify a manufacturer signature on the device; never rely on the app to check.", "Schedule installation with the user and keep therapy running from the previous image until the new one is proven.", "Prevent rollback to vulnerable versions and keep a recovery image." ], "prompts": [ "Does the device verify an update itself, or trust the app?", "When is an update allowed to install, and who decides?", "What does the patient do if an update fails overnight?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#E" ], "mds2": [ "CSUP", "IGAU" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://cwe.mitre.org/data/definitions/494.html", "https://cwe.mitre.org/data/definitions/347.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1495/", "https://emb3d.mitre.org/threats/TID-211.html", "https://emb3d.mitre.org/threats/TID-217.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-10", "@type": "skos:Concept", "notation": "CRI-BW-10", "prefLabel": "Cloud account takeover", "definition": "Manufacturer cloud accounts for patients and caregivers use reused passwords and no second factor. Taking one over exposes years of readings and, where the service allows, changes alarm thresholds or therapy settings remotely.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Cloud accounts that can see or change therapy are protected like clinical systems.", "measures": [ "Offer and encourage multi-factor authentication, and require it for any account that can change settings.", "Detect credential stuffing and unusual logins, and notify the patient of new devices.", "Require confirmation on the medical device for any remote settings change." ], "prompts": [ "What can a caregiver or patient cloud account change remotely?", "Do cloud accounts need a second factor before changing settings?", "Who is alerted when alarm thresholds change from the cloud?" ], "deck": "The Patient", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#DD" ], "mds2": [ "PAUT", "AUTH" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/600.html", "https://cwe.mitre.org/data/definitions/308.html", "https://cwe.mitre.org/data/definitions/307.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/", "https://attack.mitre.org/techniques/T1110/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-9", "@type": "skos:Concept", "notation": "CRI-BW-9", "prefLabel": "Alarms lost on the phone", "definition": "Low and high glucose or arrhythmia alerts travel through the phone. Battery optimisation, do-not-disturb, revoked permissions or an operating system update silence them, and nobody notices the alarm path has broken until a patient is harmed.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The alarm path is monitored end to end, and a broken path is itself loud.", "measures": [ "Use critical-alert channels where the platform offers them, and check permissions on every launch.", "Send a periodic test or heartbeat and warn the user when the app cannot raise alerts.", "Keep an audible alarm on the medical device itself for the most dangerous conditions." ], "prompts": [ "What on the phone could silence a low glucose alert?", "How would anyone know the alarm path had broken?", "Is there a second route for critical alerts besides the phone?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "SGUD", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/754.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0878/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-8", "@type": "skos:Concept", "notation": "CRI-BW-8", "prefLabel": "Radio stack crash stops therapy", "definition": "Malformed Bluetooth packets crash or hang the device's radio chip or stack. Readings stop, the pump or hearing aid freezes, and the device may not restart into a safe state until someone notices.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Faults in the radio stack cannot stop therapy or leave the device in an unsafe state.", "measures": [ "Isolate the radio from therapy logic so a radio fault cannot halt delivery or sensing.", "Use a watchdog that restarts the radio and alerts the user without interrupting therapy.", "Track vulnerabilities in the radio chip's software and fuzz the stack before release." ], "prompts": [ "What happens to therapy if the radio stack crashes or hangs?", "Does the device restart into a safe state on its own?", "Has the Bluetooth stack been tested against malformed packets?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "SAHD", "CSUP" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/666.html", "https://capec.mitre.org/data/definitions/28.html", "https://cwe.mitre.org/data/definitions/617.html", "https://cwe.mitre.org/data/definitions/754.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1499/", "https://emb3d.mitre.org/threats/TID-202.html", "https://emb3d.mitre.org/threats/TID-404.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "SweynTooth Bluetooth flaws, 2020", "source": [ "https://www.raps.org/resource/fda-warns-of-cybersecurity-vulnerabilities-in-pace.html", "https://www.hpnonline.com/healthcare-it/article/21128449/fda-informs-about-potential-cybersecurity-vulnerabilities-in-certain-medical-devices-with-bluetooth-low-energy" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-7", "@type": "skos:Concept", "notation": "CRI-BW-7", "prefLabel": "Weak pairing invites strangers", "definition": "Pairing uses fixed PINs, legacy modes or no confirmation, or lets a nearby device push the link down to weak encryption. A stranger pairs, listens in or injects readings and commands.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Pairing is deliberate, confirmed by the user and resistant to downgrade.", "measures": [ "Use authenticated pairing with out-of-band confirmation such as a code shown on the device.", "Refuse legacy pairing and keys shorter than current standards allow.", "Show paired devices to the user and let them remove any they do not recognise." ], "prompts": [ "How does pairing confirm the user really meant to pair?", "Can a nearby device force the link down to weaker encryption?", "Which pairing modes remain enabled that nobody needs?" ], "deck": "The Patient", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "NAUT", "TXCF" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/668.html", "https://capec.mitre.org/data/definitions/667.html", "https://capec.mitre.org/data/definitions/620.html", "https://cwe.mitre.org/data/definitions/1390.html", "https://cwe.mitre.org/data/definitions/326.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0860/", "https://emb3d.mitre.org/threats/TID-411.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "SweynTooth Bluetooth flaws, 2020", "source": [ "https://www.raps.org/resource/fda-warns-of-cybersecurity-vulnerabilities-in-pace.html", "https://www.hpnonline.com/healthcare-it/article/21128449/fda-informs-about-potential-cybersecurity-vulnerabilities-in-certain-medical-devices-with-bluetooth-low-energy" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-6", "@type": "skos:Concept", "notation": "CRI-BW-6", "prefLabel": "No supported way to automate", "definition": "With no supported way to automate their therapy, some patients build or download unofficial loops that drive older pumps through weak radio protocols. Nobody else knows what is dosing, and vulnerable pumps stay in service by choice.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patients have a supported, secure way to get the automation they need, and devices make unofficial control visible.", "measures": [ "Offer supported interoperability through authenticated, documented interfaces.", "Record on the device which controller issued each dose so clinicians can see it.", "Give clinicians guidance on reviewing patients who use unofficial controllers, without penalising them." ], "prompts": [ "Do patients have a supported way to automate their therapy?", "Would the device or clinic notice an unofficial controller dosing?", "Which older pumps stay in service because unofficial loops need them?" ], "deck": "The Patient", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#R", "https://ostering.com/ns/stride#E" ], "mds2": [ "RDMP", "CONN", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/1357.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-5", "@type": "skos:Concept", "notation": "CRI-BW-5", "prefLabel": "Home readings without provenance", "definition": "Readings from home blood pressure cuffs, pulse oximeters or ECG patches upload with no way to tell which device or person produced them. A family member's, replayed or edited values enter the record and shape treatment.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every home reading carries authenticated provenance: which device, which patient, when.", "measures": [ "Bind each device to one patient at enrolment and sign readings on the device.", "Show provenance and any manual edits beside the reading in the clinical record.", "Flag readings that arrive late, out of sequence or from an unbound device." ], "prompts": [ "How does the record know which device and patient produced a reading?", "Could a family member's or replayed reading enter the record?", "Which home readings change treatment without a clinician checking them?" ], "deck": "The Patient", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#I" ], "mds2": [ "IGAU", "NAUT" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/346.html", "https://cwe.mitre.org/data/definitions/1293.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-4", "@type": "skos:Concept", "notation": "CRI-BW-4", "prefLabel": "Own devices on the ward", "definition": "Patients bring their own pumps, sensors, hearing aids and phones into hospital. Staff cannot read or control them, they join the guest network or lose their cloud link, and nobody owns their security or the clinical decisions they drive.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The hospital has an agreed way to accept, use and support patients' own devices.", "measures": [ "Define a policy for patients' own devices covering who reviews them and how therapy is handed over.", "Provide a network path for them that keeps their cloud link without reaching clinical systems.", "Record in the patient's notes which personal devices are in use and their settings." ], "prompts": [ "What is the process for accepting a patient's own device on the ward?", "Who owns the security of patients' own devices while they are inpatients?", "Which network do patients' devices join, and what can they reach?" ], "deck": "The Patient", "rank": "4", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "CONN", "SGUD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/700.html", "https://cwe.mitre.org/data/definitions/1357.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-3", "@type": "skos:Concept", "notation": "CRI-BW-3", "prefLabel": "Companion apps sell health data", "definition": "Companion apps for inhalers, sensors and monitors carry analytics and advertising code that sends device identifiers and readings to third parties. Patients do not know, and the data links them to a condition for years.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Health data leaves the app only for the patient's care, and only with their informed agreement.", "measures": [ "Inventory every third-party SDK in the app and remove any that receive health or device data.", "Collect the minimum data and state each use in plain language before collection.", "Let patients see, export and delete what is held about them." ], "prompts": [ "Which third parties receive data from the companion app?", "Does the patient know what leaves the app, and agree to it?", "What analytics or advertising code ships inside the app?" ], "deck": "The Patient", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "MPII", "DIDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/569.html", "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/#cri-bw-2", "@type": "skos:Concept", "notation": "CRI-BW-2", "prefLabel": "Second-hand devices keep old data", "definition": "Devices that are resold, loaned, refurbished or reused across family phones keep the previous patient's data, pairings or cloud account link. The new user's readings flow to someone else's account or clinic.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/body-worn-and-home-use-devices/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every change of user wipes the device and breaks every old link.", "measures": [ "Provide a factory reset that erases data, pairings and account links, and verify it.", "Require fresh enrolment with the clinic before a reused device sends readings.", "Tell patients how to reset devices before passing them on." ], "prompts": [ "What is wiped when a device changes user or is refurbished?", "Which pairings and cloud links survive a change of owner?", "How would a new user notice data flowing to someone else?" ], "deck": "The Patient", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I" ], "mds2": [ "MPII", "STCF" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/675.html", "https://cwe.mitre.org/data/definitions/1266.html", "https://cwe.mitre.org/data/definitions/226.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "@type": "skos:Concept", "notation": "CRI-PM", "prefLabel": "Patient Monitoring", "definition": "Bedside monitors (ECG, SpO2, NIBP and invasive BP, heart rate, respiration, capnography, temperature), central stations, telemetry and early-warning feeds.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-a", "@type": "skos:Concept", "notation": "CRI-PM-A", "prefLabel": "False values on the monitor", "definition": "Monitors and central stations accept data from the monitoring network without checking its source or integrity. Altered values show normal SpO2, heart rate and blood pressure while the patient deteriorates, or alarming values for a stable one, and staff treat the screen.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Displayed vital signs come only from authenticated devices over integrity-protected links.", "measures": [ "Authenticate monitors to central stations and gateways, and protect each message for integrity.", "Show the source device and data age beside every value at the central station.", "Cross-check related signals, such as SpO2 pulse rate against ECG heart rate, and flag disagreement." ], "prompts": [ "How does the central station know data came from a genuine monitor?", "What protects vital signs in transit across the monitoring network?", "Would staff notice values that look normal but are false?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "TXIG", "NAUT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/194.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/924.html", "https://cwe.mitre.org/data/definitions/306.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0832/", "https://attack.mitre.org/techniques/T1565/002/", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "care", "seenIn": [ { "prefLabel": "MDhex, GE patient monitoring, 2020", "source": [ "https://www.helpnetsecurity.com/2020/01/24/vulnerabilities-patient-monitoring-devices/", "https://www.computerweekly.com/news/252477299/NHS-alerted-to-severe-vulnerabilities-in-GE-health-equipment" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-k", "@type": "skos:Concept", "notation": "CRI-PM-K", "prefLabel": "Alarms silenced from afar", "definition": "Alarm limits, volume and pause states can be changed from a central station, a remote viewer or the network without authorisation, and alarm forwarding can be turned off. Deterioration alarms never reach a nurse.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Changes to alarm behaviour are authorised, local where possible, visible and logged.", "measures": [ "Require clinician authentication for changes to alarm limits, volume or forwarding.", "Show any non-default alarm setting prominently on the bedside monitor.", "Log every alarm configuration change with who made it and from where.", "Prevent alarms being turned off entirely from remote stations." ], "prompts": [ "Who can change alarm limits, and from where?", "Does the bedside show a remote change, and who made it?", "Can anyone turn alarm forwarding off without a clinician knowing?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUTH", "AUDT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://cwe.mitre.org/data/definitions/862.html", "https://cwe.mitre.org/data/definitions/306.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0838/", "https://attack.mitre.org/techniques/T0878/", "https://emb3d.mitre.org/threats/TID-310.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-q", "@type": "skos:Concept", "notation": "CRI-PM-Q", "prefLabel": "Telemetry dropout looks quiet", "definition": "Wireless telemetry is jammed or drops out and the central station keeps showing the last value or no alarm, instead of a loud loss-of-signal. A patient walking off the ward or behind a lift shaft goes unmonitored.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Loss of monitoring is treated as an alarm in its own right.", "measures": [ "Raise a technical alarm as soon as telemetry is lost, with escalation if it persists.", "Mark stale values clearly and never show them as current.", "Survey wireless coverage and monitor the band for interference and jamming." ], "prompts": [ "What does the central station show when telemetry drops out?", "Where on the ward does telemetry coverage fail?", "Is loss of signal an alarm, or just a blank tile?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/601.html", "https://capec.mitre.org/data/definitions/604.html", "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/636.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0815/", "https://attack.mitre.org/techniques/T0829/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-j", "@type": "skos:Concept", "notation": "CRI-PM-J", "prefLabel": "Wrong patient on the monitor", "definition": "The link between monitor, bed and patient admission is wrong or can be changed without checks. Readings and alarms are charted to another patient, sent to the wrong nurse, and drive someone else's treatment.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every monitor-to-patient association is verified when made and visible all the time.", "measures": [ "Confirm association by scanning the patient's wristband at the monitor.", "Show the patient's name and identifier on the monitor and at the central station.", "Log association changes and alert when a monitor is reassigned while readings are flowing." ], "prompts": [ "How is a monitor linked to the right patient and bed?", "Who can change that link, and is the change checked?", "Where can staff see which patient a monitor belongs to?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "IGAU", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://cwe.mitre.org/data/definitions/1293.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-10", "@type": "skos:Concept", "notation": "CRI-PM-10", "prefLabel": "Early-warning score goes stale", "definition": "Vital signs feed early-warning and sepsis scores in the record. If the feed stops or lags, the score keeps its last value and no escalation is triggered, while staff believe the system is watching.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A score shows how fresh its inputs are and alerts when they are not.", "measures": [ "Timestamp every input and show its age with the score.", "Alert when expected observations are overdue for a patient.", "Monitor the interface feeding the score and page someone when it stops." ], "prompts": [ "How fresh are the inputs behind the early-warning score?", "What alerts staff when the vital signs feed stops?", "Would a stale score look any different from a current one?" ], "deck": "The Patient", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/1088.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0829/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-9", "@type": "skos:Concept", "notation": "CRI-PM-9", "prefLabel": "Monitors as network footholds", "definition": "Monitors and central stations run old embedded or desktop operating systems with exposed services that cannot be patched quickly. One compromised device becomes a route to other monitors and the clinical network.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Monitoring devices expose only what they need and sit where a compromise cannot spread.", "measures": [ "Disable unused services and ports, and document the rest for the hospital.", "Place monitors in their own network segment with traffic only to their central station and gateway.", "Publish patch and support timelines and validate security fixes quickly.", "Supply an SBOM so the hospital can track vulnerable components." ], "prompts": [ "Which services do monitors and central stations expose on the network?", "How quickly can a monitor vulnerability actually be patched?", "What else could a compromised monitor reach?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "SAHD", "CSUP", "SBOM" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/682.html", "https://cwe.mitre.org/data/definitions/1104.html", "https://cwe.mitre.org/data/definitions/1395.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0866/", "https://attack.mitre.org/techniques/T1210/", "https://emb3d.mitre.org/threats/TID-202.html", "https://emb3d.mitre.org/threats/TID-210.html" ], "harm": "care", "seenIn": [ { "prefLabel": "MDhex, GE patient monitoring, 2020", "source": [ "https://www.helpnetsecurity.com/2020/01/24/vulnerabilities-patient-monitoring-devices/", "https://www.computerweekly.com/news/252477299/NHS-alerted-to-severe-vulnerabilities-in-GE-health-equipment" ] }, { "prefLabel": "URGENT/11, 2019", "source": [ "https://healthcareitnews.com/node/544606" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-8", "@type": "skos:Concept", "notation": "CRI-PM-8", "prefLabel": "Monitor firmware phones home", "definition": "Monitor firmware contains hidden functions that send patient data to fixed external addresses or fetch and run files from them. Nobody at the hospital knows the function exists until it is reported.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A monitor connects only to destinations the hospital configured, and contains no hidden functionality.", "measures": [ "Review firmware and third-party components for undeclared network functions before purchase and release.", "Let the hospital configure, and see, every outbound destination.", "Block monitor traffic to the internet by default at the network edge." ], "prompts": [ "Which external addresses do the monitors contact?", "Who configured each destination a monitor connects to?", "How would the hospital discover hidden functions in monitor firmware?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U" ], "mds2": [ "CONN", "SBOM" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/443.html", "https://cwe.mitre.org/data/definitions/912.html", "https://cwe.mitre.org/data/definitions/506.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0862/", "https://emb3d.mitre.org/threats/TID-401.html" ], "harm": "care", "seenIn": [ { "prefLabel": "Contec CMS8000 patient monitors, 2025", "source": [ "https://cisa.gov/sites/default/files/2025-01/fact-sheet-contec-cms8000-contains-a-backdoor-508c.pdf", "https://thehackernews.com/2025/01/cisa-and-fda-warn-of-critical-backdoor.html" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-7", "@type": "skos:Concept", "notation": "CRI-PM-7", "prefLabel": "Service menus behind default passwords", "definition": "Service and configuration menus on monitors use default or shared passwords published in manuals. Anyone with the password changes alarm defaults, calibration or network settings, and the change looks like normal behaviour.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Service access needs individual credentials and leaves a trace.", "measures": [ "Ship without default service passwords and require a unique one at installation.", "Separate clinical configuration from engineering functions with different roles.", "Log service-mode entry and every configuration change." ], "prompts": [ "Who knows the service password, and is it the same everywhere?", "Is every change made through a service menu logged?", "Could a calibration change be told apart from normal behaviour?" ], "deck": "The Patient", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "PAUT", "AUTH", "AUDT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/70.html", "https://cwe.mitre.org/data/definitions/1392.html", "https://cwe.mitre.org/data/definitions/798.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/", "https://emb3d.mitre.org/threats/TID-311.html", "https://emb3d.mitre.org/threats/TID-328.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-6", "@type": "skos:Concept", "notation": "CRI-PM-6", "prefLabel": "Clocks drift apart", "definition": "Monitor and central station clocks are not synchronised, or their time source can be spoofed. Alarms, ECG strips, events and drug times land out of order in the record, misleading diagnosis and undermining the record as evidence.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every device keeps trusted, synchronised time, and the record shows when it did not.", "measures": [ "Synchronise clocks to an authenticated hospital time source.", "Alert when a device's clock drifts beyond a set tolerance.", "Record both device time and receipt time for each event." ], "prompts": [ "What time source do monitors and the central station use?", "Could that time source be spoofed or lost?", "How would the record show that a device clock was wrong?" ], "deck": "The Patient", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUDT", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1293.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-5", "@type": "skos:Concept", "notation": "CRI-PM-5", "prefLabel": "Remote viewing open to the internet", "definition": "Remote viewers let doctors watch live waveforms from home. Exposed to the internet with weak logins, they leak patients' data and, where they can silence alarms or change settings, give an outsider control.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Remote viewing is read-only by default and reachable only through the hospital's controlled remote access.", "measures": [ "Publish remote viewers only behind the hospital's remote access with multi-factor authentication.", "Make remote viewing read-only unless a specific, logged role needs control.", "Scan regularly for monitoring interfaces reachable from the internet." ], "prompts": [ "How do doctors reach remote viewing from outside the hospital?", "Can remote viewing silence alarms or change settings?", "Who reviews remote viewing logins and failed attempts?" ], "deck": "The Patient", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#S" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "PAUT", "RMOT", "AUTH" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/115.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/308.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1133/", "https://attack.mitre.org/techniques/T1190/", "https://emb3d.mitre.org/threats/TID-310.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-4", "@type": "skos:Concept", "notation": "CRI-PM-4", "prefLabel": "Waveform archives stolen in bulk", "definition": "Central stations and gateways store waveforms, ECGs and alarm histories unencrypted. Theft of the store reveals cardiac diagnoses for every patient monitored in years.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Stored monitoring data is encrypted and kept no longer than needed.", "measures": [ "Encrypt waveform and event stores at rest with keys held off the device.", "Set retention periods and delete data once it has been written to the record.", "Restrict export of waveform data to authorised roles and log it." ], "prompts": [ "Where are waveforms, ECGs and alarm histories stored, and is that encrypted?", "How long is stored monitoring data kept?", "Who can copy the whole monitoring archive?" ], "deck": "The Patient", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "STCF", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/545.html", "https://cwe.mitre.org/data/definitions/312.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-3", "@type": "skos:Concept", "notation": "CRI-PM-3", "prefLabel": "Spot checks under a shared login", "definition": "Portable vital-signs devices upload observations under a generic ward login. Nobody can tell who took a reading or entered a manual value, so mistakes and falsified observations cannot be traced.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every observation is attributed to the person who took it.", "measures": [ "Require badge-tap or quick login per user on spot-check devices.", "Mark manually entered values differently from measured ones in the record.", "Log who submitted each observation and from which device." ], "prompts": [ "Can you tell who took each observation?", "Which devices upload under a shared ward login?", "How would a falsified manual value be traced?" ], "deck": "The Patient", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#Nr" ], "mds2": [ "PAUT", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/778.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/#cri-pm-2", "@type": "skos:Concept", "notation": "CRI-PM-2", "prefLabel": "Discovery traffic maps the ward", "definition": "Monitors announce themselves on the network with patient names, bed numbers and demographics in discovery and multicast traffic. Anyone on that network can map who is in which bed and what is being monitored.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/patient-monitoring/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Network announcements carry no patient data.", "measures": [ "Remove patient identifiers from discovery and multicast messages.", "Encrypt traffic that must carry patient context.", "Keep monitor discovery traffic inside the monitoring segment." ], "prompts": [ "What patient data do monitors broadcast in discovery traffic?", "Who else shares the network segment where monitors announce themselves?", "Could the bed board be rebuilt from network traffic alone?" ], "deck": "The Patient", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#D" ], "mds2": [ "TXCF", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/292.html", "https://cwe.mitre.org/data/definitions/319.html", "https://cwe.mitre.org/data/definitions/359.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0846/", "https://emb3d.mitre.org/threats/TID-408.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "@type": "skos:Concept", "notation": "CRI-LS", "prefLabel": "Life Support and Therapy", "definition": "Ventilators and respirators, anaesthesia workstations, oxygen, defibrillators, dialysis, ECMO, neonatal incubators and surgical robots.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-a", "@type": "skos:Concept", "notation": "CRI-LS-A", "prefLabel": "Ventilation settings changed remotely", "definition": "The ventilator accepts changes to tidal volume, oxygen fraction, pressure or rate over the network or a connected gateway without a person at the bedside confirming them. A remote change can starve or injure a patient while the screen and the chart look normal.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Therapy-critical settings on life support change only with a local, deliberate action by a clinician at the device.", "measures": [ "Make network interfaces read-only for therapy parameters; any remote write path must be removed or disabled by default.", "Require on-device confirmation, showing old and new values, for every therapy change regardless of where it originated.", "Log every setting change with source, user and time, and alarm locally when a change arrives from outside the device." ], "prompts": [ "Which ventilator settings can change without someone at the bedside?", "What confirms a remote change before it reaches the patient?", "Would the screen and chart reveal a change made remotely?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "AUTH", "NAUT", "TXIG" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/137.html", "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/862.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0831/", "https://emb3d.mitre.org/threats/TID-310.html", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-k", "@type": "skos:Concept", "notation": "CRI-LS-K", "prefLabel": "Failure state that stops support", "definition": "When the ventilator, ECMO or heart-lung machine meets an unexpected message, crash or update, it reboots, stops or falls back to factory defaults instead of continuing the last safe therapy. A crafted packet or a faulty update can leave a dependent patient without support.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A life-support device keeps delivering its last verified therapy through software, network and update failures.", "measures": [ "Separate the therapy control function from networking and user interface software so a fault in one cannot stop the other.", "Define and test a continue-last-safe-therapy state for every fault, including malformed input and failed updates.", "Fuzz every network and data interface during verification, and treat any loss of therapy as a safety failure, not a bug." ], "prompts": [ "What does the device do after a crash, bad message or failed update?", "Does it resume the last safe therapy or factory defaults?", "How was the failure state tested with a patient connected?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "SAHD", "CSUP" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices", "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://capec.mitre.org/data/definitions/125.html", "https://cwe.mitre.org/data/definitions/636.html", "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/1088.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0814/", "https://attack.mitre.org/techniques/T0816/", "https://attack.mitre.org/techniques/T0880/", "https://emb3d.mitre.org/threats/TID-404.html", "https://emb3d.mitre.org/threats/TID-405.html", "https://emb3d.mitre.org/threats/TID-217.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-q", "@type": "skos:Concept", "notation": "CRI-LS-Q", "prefLabel": "Life-support alarms silenced", "definition": "Alarm volume, limits or delays on ventilators, anaesthesia machines and dialysis can be changed through a service menu, a configuration file or a remote profile. With alarms widened or muted, disconnection, low oxygen or a pressure fault goes unnoticed until the patient deteriorates.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Alarm limits that protect life have floors that no profile, file or remote command can go below.", "measures": [ "Enforce non-configurable minimum alarm settings for disconnection, apnoea and low oxygen in the device itself.", "Show a persistent indicator whenever any alarm is muted or widened, and limit mute duration.", "Sign alarm configuration profiles and reject unsigned or out-of-range profiles at load time." ], "prompts": [ "What is the lowest an alarm limit can be set, and by whom?", "Can a profile, file or remote command mute a life-support alarm?", "How would staff notice alarm settings had been widened?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "AUTH", "IGAU", "AUDT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://capec.mitre.org/data/definitions/75.html", "https://cwe.mitre.org/data/definitions/1188.html", "https://cwe.mitre.org/data/definitions/357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0838/", "https://attack.mitre.org/techniques/T0878/", "https://emb3d.mitre.org/threats/TID-224.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-j", "@type": "skos:Concept", "notation": "CRI-LS-J", "prefLabel": "Service mode open during treatment", "definition": "Engineering and service modes, meant for calibration and repair, can be entered while a patient is connected, by a default code, a key combination, a debug port or a remote service tool. In service mode, safety limits and interlocks may not apply.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Service functions are unreachable while the device is delivering therapy.", "measures": [ "Block entry to service and calibration modes unless the device detects it is not connected to a patient.", "Require individual, revocable service credentials, never a code shared across every unit of the model.", "Disable or physically protect debug ports in production units and record every service-mode entry." ], "prompts": [ "Can service mode be entered while a patient is connected?", "Which codes, ports or tools open service mode?", "Which safety interlocks stop working in service mode?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#T" ], "mds2": [ "AUTH", "PLOK", "RMOT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/121.html", "https://capec.mitre.org/data/definitions/554.html", "https://cwe.mitre.org/data/definitions/1244.html", "https://cwe.mitre.org/data/definitions/489.html", "https://cwe.mitre.org/data/definitions/798.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0858/", "https://emb3d.mitre.org/threats/TID-224.html", "https://emb3d.mitre.org/threats/TID-119.html", "https://emb3d.mitre.org/threats/TID-328.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-10", "@type": "skos:Concept", "notation": "CRI-LS-10", "prefLabel": "Anaesthesia workstation compromised", "definition": "Anaesthesia workstations run general-purpose operating systems and connect to the anaesthesia record and the network. Malware or tampering can change gas and agent delivery, freeze the displayed values, or falsify the anaesthesia record that later decisions rely on.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Gas and agent delivery are controlled independently of the networked computer that displays and records them.", "measures": [ "Keep delivery control on a separate, minimal controller that the record-keeping computer cannot command.", "Cross-check displayed and recorded values against an independent sensor and alarm on disagreement.", "Harden and allow-list the workstation software, and keep it on a segmented clinical device network." ], "prompts": [ "Is gas and agent delivery independent of the networked computer?", "What would a frozen display look like to the anaesthetist?", "How is the anaesthesia record protected from later tampering?" ], "deck": "The Patient", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#D" ], "mds2": [ "MLDP", "SAHD", "IGAU" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/441.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/1357.html", "https://cwe.mitre.org/data/definitions/451.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0832/", "https://attack.mitre.org/techniques/T0831/", "https://emb3d.mitre.org/threats/TID-204.html", "https://emb3d.mitre.org/threats/TID-205.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-9", "@type": "skos:Concept", "notation": "CRI-LS-9", "prefLabel": "Oxygen delivered differs from shown", "definition": "Connected oxygen blenders, high-flow systems and concentrators report flow and oxygen fraction from the same software that controls them. If that software is altered, the patient receives less oxygen than the display and the record say, and hypoxia is blamed on the illness.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Delivered oxygen is measured independently of the component that sets it.", "measures": [ "Measure delivered oxygen with a separate sensor and alarm when it departs from the set value.", "Verify firmware integrity at boot and refuse to run altered control software.", "For remotely managed home concentrators, restrict the manufacturer's cloud to reading status, not changing flow." ], "prompts": [ "What measures delivered oxygen independently of the controlling software?", "Would anyone notice the display overstating oxygen delivered?", "Who checks that set and measured oxygen agree?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "CSUP" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/186.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/494.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0832/", "https://attack.mitre.org/techniques/T0836/", "https://emb3d.mitre.org/threats/TID-201.html", "https://emb3d.mitre.org/threats/TID-211.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-8", "@type": "skos:Concept", "notation": "CRI-LS-8", "prefLabel": "Defibrillator ready status falsified", "definition": "Defibrillators and public-access AEDs report self-test results, battery and pad status to fleet dashboards. A tampered device or dashboard can show ready when the unit will not charge or shock, so the failure is found only during a cardiac arrest.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Readiness is reported from tamper-evident self-tests, and a missing or stale report is treated as not ready.", "measures": [ "Sign self-test reports on the device and verify them on the dashboard.", "Treat missing, late or unsigned reports as a fault that triggers an inspection.", "Keep a visible local readiness indicator that does not depend on the fleet service." ], "prompts": [ "How does the fleet dashboard know a defibrillator is really ready?", "What happens when a self-test report is missing or stale?", "Could a device show ready when it cannot charge?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "TXIG", "NAUT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/194.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/924.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0832/", "https://emb3d.mitre.org/threats/TID-407.html", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-7", "@type": "skos:Concept", "notation": "CRI-LS-7", "prefLabel": "Dialysis prescription tampered", "definition": "Dialysis machines load the patient's prescription, dialysate composition and fluid removal targets from a clinic system or a patient card. An altered prescription or card can remove too much fluid or deliver dialysate at the wrong conductivity or temperature.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Prescriptions loaded into a dialysis machine are authenticated and checked against safe ranges before treatment starts.", "measures": [ "Sign prescriptions in the clinic system and verify the signature on the machine.", "Hard-code physiological limits for conductivity, temperature and fluid removal that a prescription cannot exceed.", "Show the loaded prescription for a nurse to confirm against the order before starting." ], "prompts": [ "Where does the dialysis machine load its prescription from?", "How is a prescription checked against safe ranges before treatment?", "Could an altered patient card change fluid removal targets?" ], "deck": "The Patient", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#S" ], "mds2": [ "IGAU", "NAUT", "AUTH" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://capec.mitre.org/data/definitions/165.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/1284.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T1565/002/", "https://emb3d.mitre.org/threats/TID-111.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-6", "@type": "skos:Concept", "notation": "CRI-LS-6", "prefLabel": "Surgical robot command link disrupted", "definition": "A surgical robot's console sends motion commands to the arms over a cable, a network or, in remote surgery, a wide-area link. Injected, delayed or dropped commands can move an instrument inside the patient or stall it mid-procedure.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every motion command is authenticated, fresh and checked, and the arms stop safely when the link is in doubt.", "measures": [ "Authenticate and sequence-number every command between console and arms, rejecting stale or replayed messages.", "Stop motion and hold position safely when latency or loss exceeds a validated limit.", "Run remote surgery only over dedicated links with monitored quality and a local surgeon able to take over." ], "prompts": [ "How are motion commands between console and arms protected?", "What do the arms do when commands are delayed or lost?", "Which links does remote surgery depend on, and who runs them?" ], "deck": "The Patient", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#S" ], "mds2": [ "TXIG", "NAUT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/94.html", "https://capec.mitre.org/data/definitions/60.html", "https://cwe.mitre.org/data/definitions/294.html", "https://cwe.mitre.org/data/definitions/924.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0830/", "https://attack.mitre.org/techniques/T0831/", "https://emb3d.mitre.org/threats/TID-407.html", "https://emb3d.mitre.org/threats/TID-221.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-5", "@type": "skos:Concept", "notation": "CRI-LS-5", "prefLabel": "Neonatal incubator environment altered", "definition": "Networked incubators and warmers control air temperature, humidity and oxygen for premature babies and report them to a central station. Altered control or false readings can overheat, chill or over-oxygenate a baby who cannot signal distress.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Environmental limits for neonates are enforced in the incubator and verified by an independent sensor.", "measures": [ "Enforce fixed upper and lower temperature and oxygen limits in the incubator's own controller.", "Use an independent probe on the baby that alarms locally when it disagrees with the control sensor.", "Make central station connections read-only for environmental settings." ], "prompts": [ "Where are temperature and oxygen limits enforced for the baby?", "Does an independent sensor confirm the incubator's readings?", "What would the central station show if control were altered?" ], "deck": "The Patient", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "AUTH", "IGAU" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/137.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/862.html", "https://cwe.mitre.org/data/definitions/1284.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0832/", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-4", "@type": "skos:Concept", "notation": "CRI-LS-4", "prefLabel": "Consumable checks that block therapy", "definition": "Devices that authenticate circuits, cartridges, filters or licences refuse to run when the check fails, the licence server is unreachable or the clock is wrong. An attacker, an outage or a supplier change can stop ventilation, dialysis or surgery when no approved consumable is accepted.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Consumable and licence checks never stop life-sustaining therapy; they warn and record instead.", "measures": [ "Let therapy continue with a clear warning and a log entry when a consumable or licence check fails.", "Never make therapy depend on reaching a remote licence or activation service.", "Document a clinical override for emergencies and test it during verification." ], "prompts": [ "What happens to therapy if a consumable or licence check fails?", "Which outages could make the device refuse an approved consumable?", "Does a failed check warn and record, or stop treatment?" ], "deck": "The Patient", "rank": "4", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "EMRG", "RDMP" ], "standard": [ "ISO 14971:2019 Medical devices: application of risk management to medical devices", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/607.html", "https://cwe.mitre.org/data/definitions/636.html", "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0813/", "https://attack.mitre.org/techniques/T0814/", "https://emb3d.mitre.org/threats/TID-222.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-3", "@type": "skos:Concept", "notation": "CRI-LS-3", "prefLabel": "Setting history that proves nothing", "definition": "Life-support devices keep setting and event logs that are unsigned, editable by service tools, or stamped by an unsynchronised clock. After an incident nobody can tell whether a setting was changed by a clinician, a fault or an attacker, so the cause is never found.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Device event logs are complete, tamper-evident and trustworthy in time.", "measures": [ "Sign or hash-chain event logs on the device and protect them from service-tool edits.", "Synchronise device clocks to a trusted hospital time source and record clock changes.", "Export logs automatically to a central store the device cannot rewrite." ], "prompts": [ "Are device event logs signed and protected from service tools?", "Could investigators tell a clinician's change from an attacker's?", "Which clock stamps the setting history?" ], "deck": "The Patient", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#Nr" ], "mds2": [ "AUDT", "IGAU" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/268.html", "https://cwe.mitre.org/data/definitions/778.html", "https://cwe.mitre.org/data/definitions/117.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0872/", "https://emb3d.mitre.org/threats/TID-225.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/#cri-ls-2", "@type": "skos:Concept", "notation": "CRI-LS-2", "prefLabel": "Service log exports leak patients", "definition": "Service and error logs exported from ventilators, anaesthesia machines and dialysis units for vendor support include patient identifiers, settings and timestamps. Sent by email or left on service laptops, they disclose patient data outside the hospital.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/life-support-and-therapy/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Logs leaving the device carry only what the vendor needs, with patient identifiers removed.", "measures": [ "Strip or pseudonymise patient identifiers in every log export by default.", "Encrypt exported logs and send them through an approved, audited channel.", "Document in the security guide exactly what each export contains." ], "prompts": [ "What patient data is in exported service logs?", "Where do exported logs travel, and who keeps them?", "Can identifiers be removed before logs leave the device?" ], "deck": "The Patient", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#U" ], "mds2": [ "DIDT", "STCF", "MPII" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/497.html", "https://cwe.mitre.org/data/definitions/532.html", "https://cwe.mitre.org/data/definitions/359.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/", "https://emb3d.mitre.org/threats/TID-226.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "@type": "skos:Concept", "notation": "CRI-MD", "prefLabel": "Medication Delivery", "definition": "Infusion and PCA pumps, drug libraries, pump-EHR auto-programming, barcode administration, dispensing cabinets, pharmacy robots and controlled drug records.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-a", "@type": "skos:Concept", "notation": "CRI-MD-A", "prefLabel": "Drug library limits rewritten fleet-wide", "definition": "Drug libraries set the concentrations and hard dose limits for every infusion pump and are pushed to the whole fleet from one server. A tampered library raises or removes limits on every pump at once, so overdoses become possible across the hospital with no error on screen.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Drug libraries are authenticated end to end and every change is reviewed by pharmacy before it reaches a pump.", "measures": [ "Sign approved libraries in the pharmacy tool and have pumps verify the signature before loading.", "Require two-person pharmacy approval for any change that raises or removes a hard limit.", "Show the library version on each pump and alert centrally when pumps run an unapproved version." ], "prompts": [ "Who can change the drug library, and who reviews each change?", "How does a pump know a library came from pharmacy unchanged?", "Would a raised hard limit show anywhere before a patient is harmed?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "IGAU", "CSUP", "AUTH" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://capec.mitre.org/data/definitions/75.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/494.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0889/", "https://emb3d.mitre.org/threats/TID-213.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-k", "@type": "skos:Concept", "notation": "CRI-MD-K", "prefLabel": "Infusion pump reprogrammed over network", "definition": "An infusion pump that accepts commands over Wi-Fi or Ethernet without strong authentication can have its rate, volume or drug changed, or be stopped, by anyone on the network. The pump may show the change as a normal programme.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Pumps accept network commands only from authenticated systems, and dose changes need a clinician at the pump.", "measures": [ "Mutually authenticate the pump and its server, and refuse all commands from anything else.", "Disable network services the clinical workflow does not use, such as remote shells or diagnostic ports.", "Require confirmation at the pump for any change to rate, volume or drug." ], "prompts": [ "Which systems can send commands to a pump over the network?", "Can a rate or drug change without a clinician at the pump?", "How would a remote change look different from a normal programme?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "NAUT", "AUTH", "SAHD" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://capec.mitre.org/data/definitions/137.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/798.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0886/", "https://emb3d.mitre.org/threats/TID-310.html", "https://emb3d.mitre.org/threats/TID-328.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "Hospira Symbiq infusion pumps, 2015", "source": [ "https://www.mddionline.com/regulatory-quality/fda-stop-using-infusion-pump-vulnerable-to-hacking" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-q", "@type": "skos:Concept", "notation": "CRI-MD-Q", "prefLabel": "Unsigned pump firmware accepted", "definition": "Pumps that install firmware without verifying who built it can be given modified software through the update server, a service laptop or a USB port. Altered firmware can change dose calculation or alarms on every pump that takes the update.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Pumps run only firmware signed by the manufacturer and verified on the device.", "measures": [ "Verify a manufacturer signature at install and at every boot, with the key held in hardware.", "Block rollback to older, vulnerable firmware versions.", "Restrict update installation to an authenticated, logged service path." ], "prompts": [ "Where does the pump verify that firmware is genuine?", "Which routes can deliver firmware: update server, laptop, USB?", "How many pumps would one bad update reach?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "CSUP", "IGAU" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://capec.mitre.org/data/definitions/533.html", "https://cwe.mitre.org/data/definitions/494.html", "https://cwe.mitre.org/data/definitions/347.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0800/", "https://attack.mitre.org/techniques/T0862/", "https://emb3d.mitre.org/threats/TID-211.html", "https://emb3d.mitre.org/threats/TID-213.html", "https://emb3d.mitre.org/threats/TID-216.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-j", "@type": "skos:Concept", "notation": "CRI-MD-J", "prefLabel": "Auto-programming sends a wrong dose", "definition": "When the EHR programmes the pump directly from the order, nurses learn to trust the prefilled values. A tampered message, a mapping error between order units and pump units, or a spoofed integration server can load the wrong drug, rate or patient.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Pump-EHR messages are authenticated and every auto-programmed infusion is checked by a person against the order.", "measures": [ "Authenticate and integrity-protect messages between the EHR, the interoperability server and the pump.", "Match patient, drug and concentration by scanned identifiers before the programme is accepted.", "Show the full programme at the pump and require confirmation; never start automatically." ], "prompts": [ "How is an auto-programming message authenticated between EHR and pump?", "Where could order units and pump units be mapped wrongly?", "What makes the nurse check prefilled values against the order?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "TXIG", "NAUT", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/94.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/924.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://attack.mitre.org/techniques/T0830/", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-10", "@type": "skos:Concept", "notation": "CRI-MD-10", "prefLabel": "PCA limits loosened", "definition": "Patient-controlled analgesia pumps let patients give themselves opioid doses within a lockout and hourly limit. If those limits can be changed remotely, by a shared clinician code or through a weak key lock, a patient can receive a fatal dose.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "PCA limits change only with individual clinician authentication at the pump and stay within pharmacy-approved bounds.", "measures": [ "Require individual clinician authentication at the pump to change PCA limits.", "Enforce library hard limits on lockout and hourly dose that the bedside cannot override.", "Use a physical lock for the drug reservoir and alarm on door opening." ], "prompts": [ "Who can change PCA lockout and hourly limits, and how?", "Are clinician codes on PCA pumps individual or shared?", "What bounds does pharmacy set that no one can exceed?" ], "deck": "The Patient", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "PAUT", "AUTH", "PLOK" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/122.html", "https://capec.mitre.org/data/definitions/391.html", "https://cwe.mitre.org/data/definitions/1391.html", "https://cwe.mitre.org/data/definitions/1263.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://emb3d.mitre.org/threats/TID-311.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-9", "@type": "skos:Concept", "notation": "CRI-MD-9", "prefLabel": "Barcode checks quietly bypassed", "definition": "Barcode medication administration only protects patients when the scans are real. Relabelled drugs, copied wristbands, a scanner that accepts typed numbers, or a degraded mode that skips checks during an outage lets the wrong drug reach the wrong patient.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Bedside checks depend on scanned identifiers that cannot be typed or copied, and degraded modes are visible and recorded.", "measures": [ "Disable manual entry of drug and patient identifiers, or require a second clinician to witness it.", "Make any bypass or degraded mode visible on the ward and report bypass rates daily.", "Use tamper-evident wristbands and verify barcodes against the pharmacy dispensing record." ], "prompts": [ "Can a scanner accept a typed number instead of a scan?", "What happens to bedside checks when the system is down?", "How would copied wristbands or relabelled drugs be caught?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUDT", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/554.html", "https://cwe.mitre.org/data/definitions/807.html", "https://cwe.mitre.org/data/definitions/602.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1036/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-8", "@type": "skos:Concept", "notation": "CRI-MD-8", "prefLabel": "Compounding robot recipes altered", "definition": "Pharmacy robots and compounding systems prepare chemotherapy, parenteral nutrition and syringes from stored recipes and the order feed. An altered recipe or calibration produces many wrong-strength doses that look correctly labelled.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Recipes and calibration in compounding systems are controlled documents, and outputs are verified independently.", "measures": [ "Sign recipes and require pharmacist approval for each change, with version history.", "Verify each preparation by gravimetric or analytical check independent of the robot's own software.", "Restrict the robot's network access to the pharmacy system it serves." ], "prompts": [ "Who controls changes to compounding recipes and calibration?", "How is a prepared dose checked independently of the robot?", "How many doses would one altered recipe affect before anyone noticed?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "AUTH", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://capec.mitre.org/data/definitions/165.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/732.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-7", "@type": "skos:Concept", "notation": "CRI-MD-7", "prefLabel": "Pumps report infusing when stopped", "definition": "Central infusion views and alarm routing depend on status messages from pumps. A flood of traffic, a crashed pump stack or a forged status can stop an infusion of a vasoactive or sedative drug while the ward screen still shows it running.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Loss of infusion is detected and alarmed at the pump, not inferred from network status.", "measures": [ "Alarm locally at the pump on any stop or occlusion, independent of the network.", "Show stale or missing pump status as unknown at the central view, never as the last good value.", "Test pump network stacks against flooding and malformed traffic." ], "prompts": [ "How does the ward know an infusion has really stopped?", "Does the pump alarm locally, or only through the network?", "Could a forged status hide a stopped vasoactive infusion?" ], "deck": "The Patient", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#S" ], "mds2": [ "TXIG", "SAHD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/125.html", "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/770.html", "https://cwe.mitre.org/data/definitions/392.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0815/", "https://attack.mitre.org/techniques/T0814/", "https://emb3d.mitre.org/threats/TID-405.html", "https://emb3d.mitre.org/threats/TID-202.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "URGENT/11, 2019", "source": [ "https://healthcareitnews.com/node/544606" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-6", "@type": "skos:Concept", "notation": "CRI-MD-6", "prefLabel": "Dispensing cabinets fail closed", "definition": "Automated dispensing cabinets unlock drawers only after checking orders and users with a central server. During a network outage or ransomware the cabinets lock, and emergency drugs are out of reach on the ward.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Cabinets keep emergency drugs available offline, with access recorded for later reconciliation.", "measures": [ "Hold a cached order and user list on each cabinet with an offline emergency mode.", "Keep a sealed emergency key procedure and practise it in downtime drills.", "Record all offline access locally and reconcile it when the server returns." ], "prompts": [ "Can staff reach emergency drugs when the cabinet server is down?", "How is offline cabinet access recorded and reconciled later?", "When was cabinet failure last rehearsed on a ward?" ], "deck": "The Patient", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "EMRG", "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/607.html", "https://cwe.mitre.org/data/definitions/636.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0826/", "https://attack.mitre.org/techniques/T0813/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-5", "@type": "skos:Concept", "notation": "CRI-MD-5", "prefLabel": "Pharmacy labels misprinted", "definition": "Labels for prepared doses and patient medication are printed from pharmacy systems through shared print queues. Altered label templates or queue tampering can print the wrong strength, route or patient on correctly prepared doses.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "What is printed on a label is generated and checked from the verified dispensing record.", "measures": [ "Print labels only from the verified dispensing record, with the label content signed or check-summed.", "Isolate pharmacy label printers from general print queues.", "Scan the printed label back against the record before release." ], "prompts": [ "Where are label templates kept, and who can change them?", "Is the printed label checked against the dispensing record?", "Who else shares the print queues that pharmacy labels use?" ], "deck": "The Patient", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/75.html", "https://cwe.mitre.org/data/definitions/353.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-4", "@type": "skos:Concept", "notation": "CRI-MD-4", "prefLabel": "Controlled drug records falsified", "definition": "Electronic controlled-drug registers and cabinet logs can be edited by privileged users, shared accounts or service tools. Diversion of opioids is hidden, patients get substituted or short doses, and investigations cannot show who took what.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Controlled drug records are attributable to individuals and cannot be changed without trace.", "measures": [ "Require individual authentication and a witness for every controlled-drug transaction.", "Make the register append-only, with corrections as new entries.", "Analyse transactions for diversion patterns and review them routinely." ], "prompts": [ "Can every controlled drug entry be traced to one person?", "Who can edit the register, including service tools?", "How would opioid diversion show up in these records?" ], "deck": "The Patient", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#Nr" ], "mds2": [ "AUDT", "PAUT", "AUTH" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/268.html", "https://capec.mitre.org/data/definitions/122.html", "https://cwe.mitre.org/data/definitions/778.html", "https://cwe.mitre.org/data/definitions/862.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/", "https://attack.mitre.org/techniques/T1078/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-3", "@type": "skos:Concept", "notation": "CRI-MD-3", "prefLabel": "Pumps run stale drug libraries", "definition": "Pumps that are off the network, in storage or on loan never receive library updates, and nothing reports which version each pump holds. A withdrawn concentration or an unsafe old limit stays in use without anyone knowing.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every pump's library version is known, and outdated pumps are kept out of use.", "measures": [ "Report each pump's library version centrally and flag pumps that have not checked in.", "Block programming from a library older than an approved minimum version.", "Include library checks in the process for pumps returning from storage, repair or loan." ], "prompts": [ "How do you know which library version each pump holds?", "What happens to pumps in storage or on loan when libraries change?", "Can a pump with an outdated library still be used on a patient?" ], "deck": "The Patient", "rank": "3", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "CSUP" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://cwe.mitre.org/data/definitions/672.html" ], "relatedMatch": [ "https://emb3d.mitre.org/threats/TID-210.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/#cri-md-2", "@type": "skos:Concept", "notation": "CRI-MD-2", "prefLabel": "Infusion history leaks patient data", "definition": "Pumps and their servers keep infusion histories with drug, dose, time and often patient identifiers. Transmitted in clear, stored unencrypted on the pump, or left on decommissioned units, they reveal sensitive treatments such as chemotherapy or HIV therapy.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/medication-delivery/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Infusion histories are minimised, encrypted and wiped when a pump leaves service.", "measures": [ "Encrypt pump data at rest and in transit to the server.", "Keep only the identifiers the workflow needs on the pump itself.", "Wipe pumps verifiably before repair, resale or disposal." ], "prompts": [ "What patient details do pumps keep in their infusion history?", "Is infusion history encrypted on the pump and in transit?", "What is wiped before a pump leaves the hospital?" ], "deck": "The Patient", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#L" ], "mds2": [ "STCF", "TXCF", "MPII" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/117.html", "https://capec.mitre.org/data/definitions/675.html", "https://cwe.mitre.org/data/definitions/319.html", "https://cwe.mitre.org/data/definitions/359.html", "https://cwe.mitre.org/data/definitions/226.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0882/", "https://emb3d.mitre.org/threats/TID-408.html", "https://emb3d.mitre.org/threats/TID-108.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "@type": "skos:Concept", "notation": "CRI-IR", "prefLabel": "Imaging and Radiation", "definition": "X-ray, CT, MRI, fluoroscopy, ultrasound, mammography, nuclear medicine and radiotherapy, with their worklists, workstations, images and dose.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-a", "@type": "skos:Concept", "notation": "CRI-IR-A", "prefLabel": "Radiotherapy plan altered before delivery", "definition": "Treatment plans pass from the planning system through the oncology information system to the linac. A changed dose, field shape, gantry angle or patient position between approval and delivery can give a serious overdose or miss the tumour, and harm may appear only weeks later.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The plan delivered is provably the plan the clinicians approved.", "measures": [ "Sign the approved plan in the planning system and verify the signature at the treatment console.", "Run independent dose verification of the delivered plan before the first fraction.", "Log every plan modification with user and reason, and alert on changes after approval." ], "prompts": [ "How do you prove the plan delivered matches the plan approved?", "Which systems can change a plan between approval and the linac?", "Would a changed field or dose be caught before the first fraction?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "AUDT", "NAUT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/165.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/354.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/", "https://attack.mitre.org/techniques/T0836/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-k", "@type": "skos:Concept", "notation": "CRI-IR-K", "prefLabel": "Radiotherapy service halted", "definition": "Linacs depend on planning systems, oncology information systems and, increasingly, vendor-hosted cloud services. Ransomware at the hospital or the vendor stops treatment courses that must not be interrupted, and patients' cancers progress.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Radiotherapy can continue safely for a defined period when its supporting systems are lost.", "measures": [ "Hold an offline, verified copy of active treatment plans and schedules for each linac.", "Plan and rehearse transfer of patients to partner centres with compatible equipment.", "Require vendors to document continuity for cloud-hosted components in the contract." ], "prompts": [ "How long can radiotherapy continue without its planning and cloud systems?", "Which vendor services does treatment delivery depend on?", "Who decides which patients' courses continue during an outage?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "RDMP" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/607.html", "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1486/", "https://attack.mitre.org/techniques/T1490/" ], "harm": "care", "seenIn": [ { "prefLabel": "Elekta cloud outage, 2021", "source": [ "https://compliancy-group.com/healthcare-vendor-ransomware-attack-170-health-systems-hit/", "https://yaledailynews.com/blog/2021/04/27/ynhhs-pauses-radiotherapy-treatment-for-six-days-after-software-breach" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-q", "@type": "skos:Concept", "notation": "CRI-IR-Q", "prefLabel": "Image tampering adds or removes findings", "definition": "Images move from scanner to archive to reporting workstation, often without integrity protection. An attacker can add or remove a tumour, bleed or fracture in CT, MRI or X-ray images, leading to unnecessary surgery or missed treatment that radiologists cannot detect by eye.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Diagnostic images are integrity-protected from acquisition to reporting.", "measures": [ "Sign or hash images at the modality and verify them in the archive and on the viewer.", "Use TLS for all DICOM transfers inside the hospital, not only external ones.", "Alert when an image object is modified after acquisition and keep the original." ], "prompts": [ "Where are images integrity-protected between scanner and reporting?", "Could a radiologist tell that a finding had been added or removed?", "Who can write to the image archive?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "TXIG" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles", "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/94.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/319.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://attack.mitre.org/techniques/T1565/001/", "https://emb3d.mitre.org/threats/TID-408.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-j", "@type": "skos:Concept", "notation": "CRI-IR-J", "prefLabel": "Imaging dose protocols raised", "definition": "CT, fluoroscopy, mammography and X-ray dose depends on protocol libraries pushed to scanners. A tampered protocol raises tube current or exposure time across many patients, and the extra radiation is not noticed until audits or injuries appear.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Dose protocols are controlled, and dose outside reference levels is caught at the scanner.", "measures": [ "Sign protocol libraries and require physicist approval for changes.", "Enforce dose alerts and notifications at the scanner against reference levels.", "Monitor dose records centrally and alarm on shifts in average dose per protocol." ], "prompts": [ "Who can change scanner dose protocols, and is it reviewed?", "How is dose outside reference levels caught at the scanner?", "How long would raised doses go unnoticed across many patients?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "AUTH", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://capec.mitre.org/data/definitions/75.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/732.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-10", "@type": "skos:Concept", "notation": "CRI-IR-10", "prefLabel": "DICOM files carry malware", "definition": "DICOM image files can also be valid executables, and images arrive on CDs, USB drives, shares and from other hospitals. Malware hides in patient images, and anti-malware that quarantines the file deletes clinical evidence.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Imported images are parsed and checked in isolation before they reach clinical workstations.", "measures": [ "Import external media through an isolated gateway that validates DICOM structure and strips unexpected content.", "Disable autorun and execution of files from imaging import folders.", "Agree with the vendor how infected images are handled without losing the clinical record." ], "prompts": [ "Where are imported images parsed before they reach clinical workstations?", "What happens to an image file that anti-malware flags?", "Which routes bring outside images in: CD, USB, share, network?" ], "deck": "The Patient", "rank": "10", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "MLDP", "SAHD" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/636.html", "https://capec.mitre.org/data/definitions/457.html", "https://cwe.mitre.org/data/definitions/434.html", "https://cwe.mitre.org/data/definitions/1287.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1204/002/", "https://attack.mitre.org/techniques/T1027/009/", "https://emb3d.mitre.org/threats/TID-111.html" ], "seenIn": [ { "prefLabel": "DICOM files carrying malware, 2019", "source": [ "https://web.nvd.nist.gov/vuln/detail/CVE-2019-11687", "https://www.govinfosecurity.com/researchers-malware-be-hidden-in-medical-images-a-12388" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-9", "@type": "skos:Concept", "notation": "CRI-IR-9", "prefLabel": "Scanners stuck on unsupported systems", "definition": "CT, MRI and X-ray consoles often run operating systems the vendor certified years ago and that can no longer be patched. Ransomware spreading across the network shuts scanners down, and emergency imaging stops.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Imaging consoles that cannot be patched are isolated and kept recoverable.", "measures": [ "Place modalities in their own network segment allowing only DICOM traffic to named systems.", "Require vendors to commit to supported operating system lifetimes and validated patches.", "Keep a tested restore image for each console and practise recovery." ], "prompts": [ "Which imaging consoles run operating systems that can't be patched?", "What could reach those consoles if ransomware spread?", "How quickly could a scanner be rebuilt and back in service?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#E" ], "mds2": [ "RDMP", "CSUP", "SAHD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/682.html", "https://cwe.mitre.org/data/definitions/1104.html", "https://cwe.mitre.org/data/definitions/1329.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1210/", "https://attack.mitre.org/techniques/T1486/", "https://emb3d.mitre.org/threats/TID-210.html" ], "harm": "care", "seenIn": [ { "prefLabel": "WannaCry and the NHS, 2017", "source": [ "https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/", "https://www.gov.uk/government/news/foreign-office-minister-condemns-north-korean-actor-for-wannacry-attacks" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-8", "@type": "skos:Concept", "notation": "CRI-IR-8", "prefLabel": "Worklist mix-up assigns wrong patient", "definition": "Scanners take patient details from the modality worklist. A spoofed worklist server or altered entry puts images under the wrong patient, so a scan is reported for one person and acted on for another.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patient identity on images comes from an authenticated worklist and is confirmed at the scanner.", "measures": [ "Authenticate the worklist server to the modality and restrict who can query it.", "Confirm patient identity at the scanner against the wristband before acquisition.", "Reconcile acquired studies with orders and flag mismatches before reporting." ], "prompts": [ "How does the scanner know the worklist server is genuine?", "Where is patient identity confirmed before the scan starts?", "How would images filed under the wrong patient be spotted?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#I" ], "mds2": [ "NAUT", "IGAU" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/290.html", "https://cwe.mitre.org/data/definitions/346.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1557/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-7", "@type": "skos:Concept", "notation": "CRI-IR-7", "prefLabel": "MRI safety limits overridden", "definition": "MRI scanners limit gradient switching and radiofrequency energy to prevent burns and nerve stimulation, and manage helium and quench systems. Altered limits, monitoring software or service settings can burn a patient or damage the magnet.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patient safety limits in MRI are enforced in hardware or protected firmware, not configurable software.", "measures": [ "Enforce specific absorption rate and gradient limits in a protected controller.", "Separate quench and cryogen monitoring from the networked console.", "Restrict service settings to authenticated engineers with logged sessions." ], "prompts": [ "Are MRI safety limits enforced in hardware, firmware or settings?", "Who can change gradient, energy or quench settings?", "What alerts staff if a safety limit has been altered?" ], "deck": "The Patient", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "AUTH", "AUDT" ], "standard": [ "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://capec.mitre.org/data/definitions/121.html", "https://cwe.mitre.org/data/definitions/1244.html", "https://cwe.mitre.org/data/definitions/863.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0837/", "https://emb3d.mitre.org/threats/TID-224.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-6", "@type": "skos:Concept", "notation": "CRI-IR-6", "prefLabel": "Nuclear medicine activity misrecorded", "definition": "Dose calibrators and radiopharmacy software record the activity drawn for each patient. Altered calibration factors or records give patients the wrong radiation dose or invalidate scans.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Radiopharmaceutical activity is measured and recorded with verified calibration.", "measures": [ "Protect calibration factors from change without physicist approval.", "Check calibrators daily against a reference source and record the result.", "Keep activity records append-only and linked to the order." ], "prompts": [ "How are dose calibrator calibration factors protected and checked?", "Who can edit the activity recorded for a patient?", "Would a wrong dose show up before administration?" ], "deck": "The Patient", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "AUDT" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/165.html", "https://cwe.mitre.org/data/definitions/353.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-5", "@type": "skos:Concept", "notation": "CRI-IR-5", "prefLabel": "Imaging archive exposed online", "definition": "Image archives and DICOM nodes reachable from the internet, or from guest networks, answer queries without authentication. Millions of images and reports with names and dates of birth can be downloaded.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Image archives answer only authenticated, authorised systems on approved networks.", "measures": [ "Never expose DICOM services directly to the internet; use authenticated gateways for external sharing.", "Require node authentication and TLS for every DICOM association.", "Scan regularly for exposed imaging services." ], "prompts": [ "Can the image archive be queried from the internet or guest Wi-Fi?", "Which systems may query the archive, and how are they authenticated?", "When did anyone last check what the archive answers to?" ], "deck": "The Patient", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "NAUT", "TXCF", "AUTH" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles", "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/1.html", "https://capec.mitre.org/data/definitions/158.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/359.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1190/", "https://emb3d.mitre.org/threats/TID-310.html" ], "seenIn": [ { "prefLabel": "Open PACS servers, 2019", "source": [ "https://www.helpnetsecurity.com/2019/09/18/confidential-patient-data/", "https://www.hipaajournal.com/update-issued-on-unsecured-pacs-as-exposed-medical-image-total-rises-to-1-19-billion/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-4", "@type": "skos:Concept", "notation": "CRI-IR-4", "prefLabel": "Image metadata re-identifies patients", "definition": "Images shared for research, teaching or AI training keep patient details in headers, burned-in text or the anatomy itself. Head CT and MRI can be rendered into recognisable faces, so de-identified data identifies people.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Images leaving clinical use are de-identified in headers, pixels and anatomy, and checked.", "measures": [ "Apply a de-identification profile that covers headers, private tags and burned-in annotations.", "Deface head and neck studies before release.", "Check a sample of every release for residual identifiers." ], "prompts": [ "What patient details remain in images shared for research or AI?", "Is burned-in text removed from the pixels as well as headers?", "Could a head scan be rendered into a recognisable face?" ], "deck": "The Patient", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#DD" ], "mds2": [ "DIDT" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles", "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/497.html", "https://cwe.mitre.org/data/definitions/1230.html", "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-3", "@type": "skos:Concept", "notation": "CRI-IR-3", "prefLabel": "Portable imaging stores images unprotected", "definition": "Portable ultrasound and X-ray units and handheld probes paired to phones store images locally and upload to clouds. A lost device or an unencrypted upload discloses patient images.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Portable imaging keeps no more data than needed, encrypted, and uploads only to approved destinations.", "measures": [ "Encrypt local image storage and wipe images after confirmed transfer.", "Restrict uploads to the hospital archive or an approved, contracted service.", "Support remote wipe and inventory for portable units and their phones." ], "prompts": [ "What images stay stored on portable units and paired phones?", "Where do portable devices upload, and is that approved?", "What happens to images when a handheld probe is lost?" ], "deck": "The Patient", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "STCF", "TXCF", "PLOK" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/507.html", "https://cwe.mitre.org/data/definitions/359.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/#cri-ir-2", "@type": "skos:Concept", "notation": "CRI-IR-2", "prefLabel": "Viewer presets that hide findings", "definition": "Diagnostic viewers and displays rely on window settings, presets and calibration. Altered presets or display calibration can make a subtle finding invisible, and the radiologist reports a normal study.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/imaging-and-radiation/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Viewer presets and display calibration are controlled and checked.", "measures": [ "Manage presets centrally with change control and version history.", "Run regular display calibration checks and log results.", "Show when a non-standard preset is in use." ], "prompts": [ "Who can change viewer presets and window settings?", "How is display calibration checked, and how often?", "Would a changed preset be visible to the radiologist?" ], "deck": "The Patient", "rank": "2", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://cwe.mitre.org/data/definitions/451.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/003/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "@type": "skos:Concept", "notation": "CRI-LD", "prefLabel": "Laboratory and Diagnostics", "definition": "Analysers, LIS and middleware, point-of-care tests, blood bank, pathology and digital pathology, sequencers and outsourced lab services.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-a", "@type": "skos:Concept", "notation": "CRI-LD-A", "prefLabel": "Results altered before reaching the record", "definition": "Analyser results pass through middleware and the laboratory information system to the record with no end-to-end integrity check. A changed potassium, troponin or glucose value is filed as genuine, and clinicians treat, discharge or withhold treatment on it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A result must be provably the value the analyser measured, from instrument to record.", "measures": [ "Sign or hash each result at the analyser or middleware and verify it before filing in the record.", "Reconcile result counts and values between analyser logs and the record on a schedule, and alert on mismatches.", "Restrict who and what can edit a validated result, and keep every amendment visible with its reason." ], "prompts": [ "How do you prove a result is the value the analyser measured?", "Which systems between analyser and record could change a value?", "Would anyone notice a plausible but altered potassium result?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "TXIG", "AUDT" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle", "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://capec.mitre.org/data/definitions/385.html", "https://cwe.mitre.org/data/definitions/924.html", "https://cwe.mitre.org/data/definitions/353.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-k", "@type": "skos:Concept", "notation": "CRI-LD-K", "prefLabel": "Blood matched to the wrong patient", "definition": "Blood bank systems trust the group, antibody results and sample labels they are given. A changed group, a swapped sample identity or a forged crossmatch release leads to an incompatible transfusion, which can kill within minutes.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Transfusion safety must never rest on a single record that one person or system can change.", "measures": [ "Require two independent identity checks at sampling and at the bedside, enforced by the system, not by policy alone.", "Keep historical blood group records read-only and flag any new group that differs from them.", "Log and alert on every manual override of electronic crossmatch or issue rules." ], "prompts": [ "Which records must agree before blood is released for a patient?", "Could one person or system change a group or crossmatch alone?", "How is sample identity checked from bedside to blood bank?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#S" ], "mds2": [ "IGAU", "AUTH", "AUDT" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://capec.mitre.org/data/definitions/151.html", "https://cwe.mitre.org/data/definitions/1288.html", "https://cwe.mitre.org/data/definitions/863.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-q", "@type": "skos:Concept", "notation": "CRI-LD-Q", "prefLabel": "Outsourced pathology fails every hospital", "definition": "Many hospitals send their tests to one shared pathology provider. When its systems are encrypted or cut off, every hospital it serves loses blood tests, crossmatching and results at once, and operations, cancer care and emergency work stop across a region.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "No single laboratory service should be able to stop testing for a whole region.", "measures": [ "Design and contract for a fallback laboratory route, with tested result and request paths, for each critical test.", "Keep isolated, offline-capable blood bank and urgent testing capacity on each acute site.", "Rehearse a regional pathology outage with the provider and the hospitals it serves." ], "prompts": [ "Which hospitals stop testing if the shared provider goes down?", "What tests can run locally when the provider is unreachable?", "How would crossmatching continue during a regional outage?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1486/", "https://attack.mitre.org/techniques/T1199/" ], "harm": "care", "seenIn": [ { "prefLabel": "Synnovis pathology attack, London, 2024", "source": [ "https://www.theregister.com/2025/06/26/qilin_ransomware_nhs_death/", "https://www.digitalhealth.net/2025/06/patient-dies-as-a-result-of-cyber-attack-on-nhs-pathology-provider/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-j", "@type": "skos:Concept", "notation": "CRI-LD-J", "prefLabel": "Results stop flowing and nobody notices", "definition": "Interfaces between analysers, middleware and the record fail quietly: a stalled queue, an expired certificate, a dropped feed. Critical results sit undelivered while the ward assumes nothing abnormal came back.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Silence from the laboratory must never look the same as a normal result.", "measures": [ "Send heartbeats on every result interface and alarm to the laboratory and IT when one stops.", "Show pending and overdue results to the requesting clinician, with the time each was expected.", "Phone critical results by a defined route that does not depend on the interface working." ], "prompts": [ "How would anyone know results had stopped flowing to the record?", "What happens to a critical result stuck in a queue?", "Which certificates or feeds could expire silently?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "AUDT", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/778.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1489/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-10", "@type": "skos:Concept", "notation": "CRI-LD-10", "prefLabel": "Autoverification rules quietly loosened", "definition": "Laboratory systems release normal results automatically using rules, reference ranges and critical limits held in configuration. Changing those rules lets abnormal results release as normal, or suppresses critical-value calls, across every patient tested.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The rules that decide what a clinician sees must be controlled like the analyser itself.", "measures": [ "Put autoverification rules, reference ranges and critical limits under change control with two-person approval.", "Compare the live rule set against an approved baseline every day and alert on any difference.", "Sample auto-released results for manual review so a loosened rule shows up quickly." ], "prompts": [ "Who can change autoverification rules and critical limits?", "How is a rule change reviewed before it goes live?", "Would loosened rules be noticed across thousands of results?" ], "deck": "The Patient", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "AUTH", "AUDT", "IGAU" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/75.html", "https://capec.mitre.org/data/definitions/176.html", "https://cwe.mitre.org/data/definitions/15.html", "https://cwe.mitre.org/data/definitions/732.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-9", "@type": "skos:Concept", "notation": "CRI-LD-9", "prefLabel": "Bedside tests filed to wrong patient", "definition": "Glucose meters, blood gas analysers and other bedside tests rely on shared operator codes and patient barcodes that are easily bypassed. Results land on the wrong record, and the wrong patient is treated.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every bedside test must be tied to a verified operator and a verified patient.", "measures": [ "Require a patient wristband scan before testing, with no manual entry except a logged emergency route.", "Give each operator an individual credential and lock devices to trained users.", "Hold results that fail identity checks in a queue for review rather than filing them." ], "prompts": [ "How is each bedside test tied to an operator and a patient?", "Can staff bypass the patient barcode on a bedside meter?", "Are operator codes on bedside devices individual or shared?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#R" ], "mds2": [ "PAUT", "AUTH", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://cwe.mitre.org/data/definitions/308.html", "https://cwe.mitre.org/data/definitions/1390.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-8", "@type": "skos:Concept", "notation": "CRI-LD-8", "prefLabel": "Pathology slides swapped or edited", "definition": "Digital pathology stores whole-slide images that pathologists and AI read remotely. If images can be replaced, relabelled or edited, a cancer is missed or invented, and the error looks like a sound diagnosis.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A slide image must stay bound to its specimen and provably unchanged from scanner to report.", "measures": [ "Hash images at the scanner and check the hash whenever an image is opened for reporting.", "Bind each image to specimen and patient identifiers inside signed metadata, not filenames.", "Restrict write and delete rights on the image store to the scanning workflow." ], "prompts": [ "How is a slide image bound to its specimen?", "Who can replace or relabel stored slide images?", "Would a pathologist see that an image had been edited?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#S" ], "mds2": [ "IGAU", "AUTH" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/165.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/1230.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-7", "@type": "skos:Concept", "notation": "CRI-LD-7", "prefLabel": "Quality control records faked", "definition": "Quality control and calibration results show whether an analyser can be trusted. If they can be edited or skipped without trace, a drifting analyser keeps reporting wrong values and the laboratory's records say all was well.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Quality control evidence must be captured automatically and be impossible to rewrite quietly.", "measures": [ "Capture QC and calibration results directly from the analyser, not by manual entry.", "Block patient result release when QC has failed or is overdue, with a logged override.", "Keep QC history in an append-only store that analyser and laboratory staff cannot edit." ], "prompts": [ "Is quality control captured automatically or typed in?", "Can a QC result be edited or skipped without trace?", "Who reviews QC trends for a drifting analyser?" ], "deck": "The Patient", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUDT", "IGAU" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/268.html", "https://cwe.mitre.org/data/definitions/778.html", "https://cwe.mitre.org/data/definitions/223.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/", "https://attack.mitre.org/techniques/T1070/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-6", "@type": "skos:Concept", "notation": "CRI-LD-6", "prefLabel": "Analysers as a network foothold", "definition": "Analysers often run an old embedded operating system that the hospital may not patch, on the same network as everything else. One compromised analyser becomes a foothold for ransomware or a route to other laboratory and clinical systems.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "An analyser should reach only what it needs and nothing should reach it except its own systems.", "measures": [ "Place analysers in their own network zone with allow-lists limited to middleware and vendor service.", "Ask for an SBOM and a supported-until date before purchase, and plan replacement around it.", "Monitor analyser traffic for anything outside its normal pattern." ], "prompts": [ "What can each analyser reach on the network?", "Who patches analysers, and how long does it take?", "What reaches the analyser that isn't its own system?" ], "deck": "The Patient", "rank": "6", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#T" ], "mds2": [ "SAHD", "MLDP", "RDMP" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/310.html", "https://cwe.mitre.org/data/definitions/1104.html", "https://cwe.mitre.org/data/definitions/1329.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1210/", "https://emb3d.mitre.org/threats/TID-210.html", "https://emb3d.mitre.org/threats/TID-202.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-5", "@type": "skos:Concept", "notation": "CRI-LD-5", "prefLabel": "Analyser locked by reagent licensing", "definition": "Some analysers check reagent tags or licences against the manufacturer's cloud before running. When that link fails, is blocked or the vendor is attacked, testing stops even though reagents and staff are ready.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical testing must not depend on a vendor service being reachable at the moment of the test.", "measures": [ "Require offline grace periods for licence and reagent checks, written into the purchase contract.", "Test what the analyser does when its vendor link is cut, before go-live.", "Keep an emergency unlock procedure the laboratory can use without the vendor." ], "prompts": [ "Does testing stop if the vendor's licence service is unreachable?", "How long can analysers run without the manufacturer's cloud?", "Who is called when reagent checks block testing at night?" ], "deck": "The Patient", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "CONN", "RMOT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1489/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-4", "@type": "skos:Concept", "notation": "CRI-LD-4", "prefLabel": "Genomic data leaves the building", "definition": "Sequencers and analysis pipelines send genomic data to cloud services. Genomes identify patients and their relatives, cannot be reissued after a breach, and are often stored with weaker controls than the clinical record.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Genomic data must be treated as the most sensitive data the hospital holds.", "measures": [ "Encrypt genomic data at rest and in transit and keep keys under the hospital's control.", "Separate identifiers from sequence data and link them only inside an authorised service.", "Record every export and limit which destinations a sequencer can send data to." ], "prompts": [ "Where do sequencers and pipelines send genomic data?", "Are genomic data protected at least as well as the record?", "Who could link a stored genome back to a patient's relatives?" ], "deck": "The Patient", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#DD" ], "mds2": [ "STCF", "TXCF", "DIDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/359.html", "https://cwe.mitre.org/data/definitions/319.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1530/", "https://attack.mitre.org/techniques/T1567/002/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-3", "@type": "skos:Concept", "notation": "CRI-LD-3", "prefLabel": "Public health reports spoofed or suppressed", "definition": "Laboratories report notifiable infections to public health automatically. If that feed can be forged or blocked, an outbreak goes unseen, or a false one triggers costly responses and alarm.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Reports that drive public health action must be authenticated and their absence noticed.", "measures": [ "Authenticate both ends of the reporting link and sign each report.", "Reconcile reported cases with laboratory positives daily and investigate gaps.", "Alert when a reporting feed goes quiet for longer than its normal interval." ], "prompts": [ "How does public health know a notifiable report is genuine?", "Would anyone notice the reporting feed had stopped?", "Who checks that every required report was sent?" ], "deck": "The Patient", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "NAUT", "TXIG" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/924.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/#cri-ld-2", "@type": "skos:Concept", "notation": "CRI-LD-2", "prefLabel": "Laboratory exports leak in spreadsheets", "definition": "Results are exported to spreadsheets for audit, research and service reviews. Identifiable data spreads into shared drives and email, and formula content in exported cells can run when the file is opened.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/laboratory-and-diagnostics/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Data leaving the laboratory system should carry no more than the task needs.", "measures": [ "Pseudonymise exports by default and require approval for identifiable extracts.", "Neutralise formula characters in exported fields.", "Log every export with its requester, purpose and destination." ], "prompts": [ "What identifiable data goes into exported spreadsheets?", "Where do exported files end up, and who can open them?", "Are exported cells checked for formula content?" ], "deck": "The Patient", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#L" ], "mds2": [ "DIDT", "MPII", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1236.html", "https://cwe.mitre.org/data/definitions/212.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "@type": "skos:Concept", "notation": "CRI-CA", "prefLabel": "Clinical Software and AI", "definition": "Software as a medical device, decision support, dose calculators, early-warning and sepsis scores, imaging AI, AI scribes and the apps clinicians reach for.", "deck": "The Patient", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-a", "@type": "skos:Concept", "notation": "CRI-CA-A", "prefLabel": "Shared clinical knowledge base corrupted", "definition": "Decision support, drug interaction checks and order sets draw on a central rule base or a third-party drug database. One corrupted rule or update gives wrong advice to every prescriber at once, and the advice looks authoritative.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical rules must be changed and updated like a medical device, with independent verification.", "measures": [ "Verify the signature and provenance of every knowledge base update before loading it.", "Test each update against a fixed set of clinical cases and block it if any result changes unexpectedly.", "Keep the previous version ready to restore and record who approved each change." ], "prompts": [ "Who verifies changes to the clinical rule base before release?", "How many prescribers would one corrupted rule reach?", "How are third-party drug database updates checked?" ], "deck": "The Patient", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "CSUP", "AUDT" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes", "ISO 14971:2019 Medical devices: application of risk management to medical devices", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://capec.mitre.org/data/definitions/184.html", "https://cwe.mitre.org/data/definitions/494.html", "https://cwe.mitre.org/data/definitions/684.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/", "https://attack.mitre.org/techniques/T1195/002/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-k", "@type": "skos:Concept", "notation": "CRI-CA-K", "prefLabel": "Dose calculators trusted blindly", "definition": "Weight-based and infusion dose calculators accept whatever inputs they are given. A weight in the wrong unit, a moved decimal or a changed concentration produces a tenfold dose that looks correct on screen.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A calculator that sets a dose must check its inputs against what is plausible for the patient.", "measures": [ "Take weight and concentration from verified sources, not free text, and show their origin.", "Apply hard and soft limits by age, weight and drug, and require a reason to exceed them.", "Show units explicitly at every step and in the final result." ], "prompts": [ "What plausibility checks does the calculator apply to its inputs?", "Which units does each input expect, and is that shown?", "Would a tenfold dose look any different on screen?" ], "deck": "The Patient", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://cwe.mitre.org/data/definitions/1287.html", "https://cwe.mitre.org/data/definitions/1288.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-q", "@type": "skos:Concept", "notation": "CRI-CA-Q", "prefLabel": "Early-warning scores fed bad inputs", "definition": "Deterioration and sepsis algorithms score whatever vital signs and results reach them. Missing, delayed or altered inputs, or a raised threshold, mean a deteriorating patient is never flagged.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "An algorithm must know when its inputs are stale, missing or implausible and say so.", "measures": [ "Show the age and source of every input beside the score.", "Flag a score as incomplete when inputs are missing or late instead of treating them as normal.", "Control and audit threshold changes, with clinical sign-off." ], "prompts": [ "How does the algorithm show that inputs are stale or missing?", "Who can change scoring thresholds, and is it reviewed?", "What alerts staff when an expected input never arrives?" ], "deck": "The Patient", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "IGAU", "AUDT" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/1288.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-j", "@type": "skos:Concept", "notation": "CRI-CA-J", "prefLabel": "Imaging AI fooled by crafted images", "definition": "Triage and detection models read images that pass through many systems. Small, deliberate changes to an image can make a model miss a bleed or a tumour, or invent one, with no visible sign to a human reader.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "An imaging model must be tested against manipulated inputs and never be the only reader.", "measures": [ "Check image integrity from modality to model before inference.", "Test models with adversarial and corrupted inputs during validation and after every update.", "Keep a clinician read on every study the model triages as normal for the highest-risk findings." ], "prompts": [ "Has the imaging model been tested against manipulated images?", "Is the model ever the only reader of an image?", "How would a missed finding by the model be caught?" ], "deck": "The Patient", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://cwe.mitre.org/data/definitions/1039.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-10", "@type": "skos:Concept", "notation": "CRI-CA-10", "prefLabel": "Model updates change care unannounced", "definition": "Cloud-hosted software as a medical device can receive a new model version without the hospital knowing. Its performance on local patients shifts, and nobody compares outputs before and after.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A change to a clinical model must be visible to the hospital and checked on local data.", "measures": [ "Require notice and release notes for every model change in the supply contract.", "Display the model version with every output and record it in the patient record.", "Monitor agreement and alert rates locally, and alarm on a sudden shift." ], "prompts": [ "How does the hospital learn that a model version has changed?", "Are outputs compared on local patients before and after updates?", "Who can pause a model whose performance has shifted?" ], "deck": "The Patient", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "CSUP", "SGUD" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html", "https://cwe.mitre.org/data/definitions/684.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-9", "@type": "skos:Concept", "notation": "CRI-CA-9", "prefLabel": "Automation bias hides the failure", "definition": "Interfaces present algorithm outputs as certain, without confidence or evidence. Clinicians stop checking, so any error, drift or compromise in the software flows straight into treatment.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical software should show how sure it is and invite the clinician to check.", "measures": [ "Show confidence, the main inputs and known limits beside every recommendation.", "Design workflows so the clinician records a decision, not just an acceptance.", "Audit acceptance rates and investigate units where nearly every suggestion is accepted." ], "prompts": [ "Does the interface show how confident the algorithm is?", "What prompts the clinician to check an output before acting?", "How would drift or compromise in the software become visible?" ], "deck": "The Patient", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "SGUD" ], "standard": [ "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/451.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-8", "@type": "skos:Concept", "notation": "CRI-CA-8", "prefLabel": "AI scribes write errors into records", "definition": "Ambient and speech scribes, including agent-driven tools, turn conversations into notes, allergies and medication lists. Mishearing, prompt injection from spoken or pasted text, or invented details enter the record and drive later orders.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Nothing generated should enter the record until a clinician has checked and accepted it.", "measures": [ "Hold generated text as a draft that a named clinician must review and sign.", "Highlight generated content that changes allergies, medications or diagnoses for explicit confirmation.", "Tell patients when recording and generation are used and let them decline." ], "prompts": [ "Who checks a generated note before it enters the record?", "Could spoken or pasted text steer what the scribe writes?", "Which orders could be driven by an unreviewed generated entry?" ], "deck": "The Patient", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#DD" ], "mds2": [ "IGAU", "AUDT", "MPII" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1427.html", "https://cwe.mitre.org/data/definitions/1434.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-7", "@type": "skos:Concept", "notation": "CRI-CA-7", "prefLabel": "Models leak the patients they learned", "definition": "Models trained or fine-tuned on hospital data can reveal whether a person was in the training set, or reproduce fragments of their records, to anyone who can query them.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patient data used to build a model must not be recoverable from the model.", "measures": [ "Train on de-identified data wherever possible and test models for memorisation before release.", "Limit who can query models and how often.", "Record which datasets trained each model and the legal basis for using them." ], "prompts": [ "Could someone tell from the model whether a patient was in training?", "Who can query the model, and how often?", "Was the training data reduced or protected before use?" ], "deck": "The Patient", "rank": "7", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "DIDT", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-6", "@type": "skos:Concept", "notation": "CRI-CA-6", "prefLabel": "Unvalidated spreadsheets run clinical decisions", "definition": "Wards and pharmacies build their own calculators, macros and trackers. They have no version control or testing, a changed cell alters every result, and macro-enabled files are an easy way to deliver malware.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Any tool that informs a clinical decision needs an owner, a version and a test.", "measures": [ "Register local clinical tools, name an owner and validate them before use.", "Lock formulas and store approved versions in a controlled location.", "Block macros from untrusted locations on clinical workstations." ], "prompts": [ "Which local spreadsheets or macros inform clinical decisions?", "Does each one have an owner, a version and a test?", "Who could change a formula without anyone noticing?" ], "deck": "The Patient", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "IGAU", "MLDP" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/17.html", "https://cwe.mitre.org/data/definitions/1236.html", "https://cwe.mitre.org/data/definitions/15.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1204/002/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-5", "@type": "skos:Concept", "notation": "CRI-CA-5", "prefLabel": "Consumer apps used for clinical work", "definition": "Staff use unregulated apps for doses, wound photos and messaging because they are quick. Patient images and details sync to personal clouds, and app results carry no validation.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Make the approved tool the easiest one to use for the task.", "measures": [ "Provide approved apps for photos, calculations and messaging on managed devices.", "Keep clinical photos in a managed container that never syncs to personal storage.", "Publish which apps are approved for which clinical tasks." ], "prompts": [ "Which consumer apps do staff use for clinical work, and why?", "Where do photos and details from those apps sync?", "Is the approved tool as quick as the app staff prefer?" ], "deck": "The Patient", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#Nc", "https://ostering.com/ns/linddun#U" ], "mds2": [ "STCF", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/359.html", "https://cwe.mitre.org/data/definitions/922.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1567/002/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-4", "@type": "skos:Concept", "notation": "CRI-CA-4", "prefLabel": "Cloud clinical software unreachable", "definition": "Reporting, triage and decision software increasingly runs in a vendor's cloud. When the link, the vendor or its cloud is down, the pathway has no fallback and clinical work waits.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A clinical pathway must keep working, at a known reduced level, when its cloud software is gone.", "measures": [ "Define and rehearse a manual fallback for each cloud-dependent pathway.", "Require service levels and outage notice from the vendor, and monitor availability yourself.", "Keep essential reference data available offline." ], "prompts": [ "What happens to the pathway when the vendor's cloud is down?", "What reduced level of service is agreed, and rehearsed?", "How long can clinical work wait for the software to return?" ], "deck": "The Patient", "rank": "4", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "CONN", "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1498/", "https://attack.mitre.org/techniques/T1489/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-3", "@type": "skos:Concept", "notation": "CRI-CA-3", "prefLabel": "Alert overrides leave no trail", "definition": "Clinicians override drug interaction and allergy alerts many times a day. Without a recorded reason, nobody can tell a justified override from a dangerous one, or prove later what was shown.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every override of a safety alert should record who, what and why.", "measures": [ "Require a short coded reason for overriding high-severity alerts.", "Record the alert text shown, with its version, alongside the override.", "Review override patterns and retire alerts that are always overridden." ], "prompts": [ "Is a reason recorded each time a safety alert is overridden?", "Could you later prove what alert a clinician saw?", "Who reviews override patterns for dangerous habits?" ], "deck": "The Patient", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R" ], "mds2": [ "AUDT" ], "standard": [ "IEC 62304 Medical device software: software life cycle processes" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/778.html", "https://cwe.mitre.org/data/definitions/223.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/#cri-ca-2", "@type": "skos:Concept", "notation": "CRI-CA-2", "prefLabel": "Algorithms expose sensitive inferences", "definition": "Models infer pregnancy, HIV status, mental illness or addiction from routine data and show the inference to anyone viewing the patient. The patient never disclosed it and cannot see or contest it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-software-and-ai/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Inferred sensitive information deserves the same protection as information the patient disclosed.", "measures": [ "Classify inferred conditions with the same sensitivity as recorded ones and restrict their display.", "Label inferences as such and let clinicians suppress them.", "Tell patients which inference tools are in use." ], "prompts": [ "Which sensitive conditions can the models infer from routine data?", "Who can see an inference the patient never disclosed?", "Can patients see or contest what was inferred about them?" ], "deck": "The Patient", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U" ], "mds2": [ "AUTH", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/359.html", "https://cwe.mitre.org/data/definitions/1220.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "@type": "skos:Concept", "notation": "CRI-RC", "prefLabel": "Records and Patient Data", "definition": "The EHR and patient administration, orders and results, identity matching, sensitive categories, portals, research use and the audit trail.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-a", "@type": "skos:Concept", "notation": "CRI-RC-A", "prefLabel": "Allergies and medications rewritten", "definition": "Clinicians act on the allergy list, medication history, blood group and resuscitation status in the record. If these can be changed without strong control and visible history, a patient is given a drug they react to, or not resuscitated.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Safety-critical facts in the record must be hard to change and every change must be obvious.", "measures": [ "Require re-authentication and a reason to change allergies, resuscitation status or blood group.", "Show recent changes to safety-critical fields prominently to the next clinician.", "Alert on bulk or unusual edits to these fields across many patients." ], "prompts": [ "Who can change allergies, blood group or resuscitation status?", "How obvious is a recent change to a clinician opening the record?", "What review follows a change to a safety-critical fact?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "IGAU", "AUDT", "AUTH" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/1.html", "https://cwe.mitre.org/data/definitions/862.html", "https://cwe.mitre.org/data/definitions/863.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-k", "@type": "skos:Concept", "notation": "CRI-RC-K", "prefLabel": "Whole record stolen for extortion", "definition": "The record holds every patient's history in a few databases and reporting replicas. Attackers copy it in bulk, then extort the hospital and threaten to publish, and the data can never be taken back.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "No single account or system should be able to copy the whole patient record unnoticed.", "measures": [ "Limit bulk query and export rights to a few monitored service accounts.", "Detect and alarm on unusual volumes leaving reporting databases and backups.", "Encrypt replicas and backups with keys held separately from the systems that read them." ], "prompts": [ "Which accounts or systems could copy the whole record?", "Would a bulk export from a reporting replica raise an alarm?", "How are backups and replicas protected from the same theft?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "STCF", "AUDT", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/116.html", "https://cwe.mitre.org/data/definitions/359.html", "https://cwe.mitre.org/data/definitions/1220.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1213/006/", "https://attack.mitre.org/techniques/T1567/002/", "https://attack.mitre.org/techniques/T1657/" ], "seenIn": [ { "prefLabel": "Change Healthcare, 2024", "source": [ "https://www.beckershospitalreview.com/healthcare-information-technology/cybersecurity/change-healthcare-data-breach-toll-reaches-192-7-million", "https://www.fiercehealthcare.com/payers/unitedhealth-estimates-190m-people-impacted-change-healthcare-cyberattack" ] }, { "prefLabel": "NHS Dumfries and Galloway, 2024", "source": [ "https://www.helpnetsecurity.com/2024/03/28/nhs-scotland-ransomware/", "https://www.digitalhealth.net/2024/05/nhs-dumfries-and-galloway-working-with-ncsc-after-3tb-data-leak" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-q", "@type": "skos:Concept", "notation": "CRI-RC-Q", "prefLabel": "Patients extorted one by one", "definition": "Therapy notes, sexual health and other sensitive records are stored as readable text. Once stolen, attackers contact patients individually and demand payment to keep their notes private.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The most sensitive notes must be useless to anyone who steals them.", "measures": [ "Encrypt sensitive note categories at field level with separately held keys.", "Prepare a plan to warn and support patients quickly if notes are taken.", "Keep sensitive notes out of bulk extracts and reporting copies." ], "prompts": [ "Which notes would hurt a patient most if published?", "Are those notes stored as readable text?", "What support would patients get if their notes were stolen?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#L" ], "mds2": [ "STCF", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/312.html", "https://cwe.mitre.org/data/definitions/359.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1657/", "https://attack.mitre.org/techniques/T1005/" ], "seenIn": [ { "prefLabel": "Vastaamo psychotherapy records, Finland, 2020", "source": [ "https://en.wikipedia.org/wiki/Vastaamo_data_breach", "https://ny1.com/nyc/all-boroughs/ap-top-news/2024/04/30/finnish-hacker-gets-prison-for-accessing-thousands-of-psychotherapy-records-and-demanding-ransoms" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-j", "@type": "skos:Concept", "notation": "CRI-RC-J", "prefLabel": "Two patients become one record", "definition": "Patient matching merges records on name, date of birth and partial identifiers. A wrong merge or a stolen identity mixes another person's allergies, results and diagnoses into a patient's record, and both are treated on the wrong history.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Merging identities must be deliberate, reviewed and reversible.", "measures": [ "Require review of merges below a high matching confidence, by trained staff.", "Keep merges reversible with full history of which data came from which identity.", "Flag records where new data conflicts with established facts, such as blood group or sex at birth." ], "prompts": [ "Which identifiers does patient matching rely on?", "Who reviews a merge before it takes effect?", "How is a wrong merge undone, and who is told?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I" ], "mds2": [ "IGAU", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://cwe.mitre.org/data/definitions/1288.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-10", "@type": "skos:Concept", "notation": "CRI-RC-10", "prefLabel": "Sensitive categories open to every user", "definition": "Mental health, sexual health, HIV, abortion, gender identity and genetic records are visible to anyone who can open the patient. Where the law, family or employer is hostile, disclosure puts the patient at real risk.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Access to sensitive categories should follow the care relationship, not the login.", "measures": [ "Tag sensitive categories and restrict them to the treating team, with logged break-glass.", "Let patients choose additional restrictions where the law allows.", "Keep sensitive categories out of default printouts, summaries and shared feeds." ], "prompts": [ "Who can open mental health, sexual health or genetic records?", "Does access follow the care relationship or just the login?", "What extra step guards the most sensitive categories?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "AUTH", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1220.html", "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-9", "@type": "skos:Concept", "notation": "CRI-RC-9", "prefLabel": "Staff browse records without reason", "definition": "Insiders look up celebrities, colleagues, neighbours and former partners. Access is logged, but nobody reviews the logs, so curiosity and stalking go unnoticed and unpunished.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every look at a record should be attributable and reviewed against a care relationship.", "measures": [ "Analyse access logs automatically for patients with no care link to the viewer.", "Flag high-interest records and alert on access to them.", "Tell staff the logs are reviewed and act visibly on findings." ], "prompts": [ "Who reviews access logs, and how often?", "How would a colleague browsing a neighbour's record be detected?", "What happens to staff found looking without reason?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#D", "https://ostering.com/ns/linddun#I" ], "mds2": [ "AUDT", "AUTH" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/122.html", "https://cwe.mitre.org/data/definitions/778.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1213/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-8", "@type": "skos:Concept", "notation": "CRI-RC-8", "prefLabel": "Patient portal accounts taken over", "definition": "Portals let patients and their proxies read records and message clinicians. Reused passwords, weak recovery and loose proxy access let attackers, or a coercive partner or relative, read and change what the patient sees.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Portal access must be as strong as the data it shows, and proxies must be revocable by the patient.", "measures": [ "Offer phishing-resistant authentication and detect credential stuffing.", "Let patients see and revoke proxies, and alert them to new devices and proxy access.", "Make account recovery require more than details found in the record." ], "prompts": [ "How strong are portal logins and account recovery?", "Who can be granted proxy access, and can the patient revoke it?", "How would a coercive relative's access be noticed?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#L" ], "mds2": [ "PAUT", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/600.html", "https://cwe.mitre.org/data/definitions/308.html", "https://cwe.mitre.org/data/definitions/640.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1110/004/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-7", "@type": "skos:Concept", "notation": "CRI-RC-7", "prefLabel": "Health data shared beyond its purpose", "definition": "Tracking scripts on appointment and portal pages, research extracts and contracts with insurers or authorities move health data to parties the patient never expected. Once shared, it is linked with other data and cannot be recalled.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Each flow of patient data must have a stated purpose and the least data it needs.", "measures": [ "Remove third-party tracking from any page that shows or collects health data.", "Keep a register of data flows with purpose, legal basis and owner, reviewed yearly.", "Send only the fields each recipient needs." ], "prompts": [ "Which third parties receive data from portal and appointment pages?", "Does every data flow have a stated purpose?", "What does each extract contain beyond what its purpose needs?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#Nc", "https://ostering.com/ns/linddun#L" ], "mds2": [ "MPII", "DIDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/201.html", "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-6", "@type": "skos:Concept", "notation": "CRI-RC-6", "prefLabel": "De-identified data re-identified", "definition": "Research and analytics datasets have names removed but keep dates, postcodes, rare conditions and free text. Linking them with other data identifies patients, sometimes in seconds.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Treat de-identification as a risk to measure, not a step that is done.", "measures": [ "Assess re-identification risk for each release and generalise rare values.", "Remove or scrub free text before release.", "Release data inside a controlled research environment instead of handing out copies." ], "prompts": [ "Which quasi-identifiers remain in research datasets?", "Has anyone measured the re-identification risk?", "Who decides whether free text can leave the record?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#DD" ], "mds2": [ "DIDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-5", "@type": "skos:Concept", "notation": "CRI-RC-5", "prefLabel": "Audit trail can be edited", "definition": "System administrators and vendor support can change or delete audit records. Then nobody can prove who changed a record or viewed it, which matters in incidents, complaints and court.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The audit trail must be beyond the reach of the people and systems it records.", "measures": [ "Ship audit records to a separate, append-only store as they are written.", "Separate audit administration from system administration.", "Check the audit stream for gaps and alarm when it stops." ], "prompts": [ "Who can alter or delete audit records, including vendor support?", "Where is the audit trail kept, out of administrators' reach?", "Could you prove in court who viewed a record?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#Nr" ], "mds2": [ "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/268.html", "https://cwe.mitre.org/data/definitions/778.html", "https://cwe.mitre.org/data/definitions/223.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1070/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-4", "@type": "skos:Concept", "notation": "CRI-RC-4", "prefLabel": "Records released to impostors", "definition": "Records teams answer requests from patients, police, insurers and solicitors by phone, email and post. Someone posing as the patient or an official obtains a full record.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Release of records must verify who is asking and whether they are entitled.", "measures": [ "Verify identity through a channel already on file, not one given in the request.", "Send records through an authenticated portal rather than email or post.", "Review third-party requests for entitlement and release the minimum needed." ], "prompts": [ "How do records staff verify who is asking for a record?", "Which requests arrive by phone or email, and how are they checked?", "What would an impostor need to obtain a full record?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "PAUT", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/407.html", "https://capec.mitre.org/data/definitions/412.html", "https://cwe.mitre.org/data/definitions/1390.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1598/004/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-3", "@type": "skos:Concept", "notation": "CRI-RC-3", "prefLabel": "Printouts and caches left behind", "definition": "Shared workstations, browser caches, downloaded letters and downtime printouts hold patient data long after the task. Anyone using the next session, bin or printer tray can read them.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patient data should not outlive the task on shared equipment.", "measures": [ "Clear local caches and downloads when a clinical session ends.", "Use secure print release and confidential waste on wards.", "Lock or log off unattended sessions quickly, using tap-to-switch to keep it practical." ], "prompts": [ "What patient data stays on shared workstations after a session?", "Where do downtime printouts end up?", "Who clears browser caches and downloaded letters, and when?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "ALOF", "STCF" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/204.html", "https://cwe.mitre.org/data/definitions/524.html", "https://cwe.mitre.org/data/definitions/525.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/#cri-rc-2", "@type": "skos:Concept", "notation": "CRI-RC-2", "prefLabel": "Patients cannot see who looked", "definition": "Patients have no view of who accessed their record or where it was shared. They cannot notice misuse, object to a disclosure or correct what was sent.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/records-and-patient-data/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patients should be able to see how their record has been used.", "measures": [ "Show patients an access and sharing history in the portal.", "Let patients report access they do not recognise and track the response.", "Explain in plain language who routinely sees their record and why." ], "prompts": [ "Can patients see who accessed their record?", "How would a patient object to a disclosure?", "Where can patients see where their record was shared?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "AUDT", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/223.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "@type": "skos:Concept", "notation": "CRI-IN", "prefLabel": "Integration and Interoperability", "definition": "HL7 v2, FHIR, DICOM, integration engines, device integration middleware and regional exchange.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-a", "@type": "skos:Concept", "notation": "CRI-IN-A", "prefLabel": "Unauthenticated orders and results feeds", "definition": "Interfaces accept HL7 orders, results and admissions from any sender that can reach the port, with no check of who sent them. A forged potassium result or a cancelled allergy lands in the record looking genuine, and clinicians treat the patient on it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every interface accepts clinical messages only from authenticated senders over protected channels, and rejects everything else.", "measures": [ "Wrap HL7 v2 MLLP feeds in mutually authenticated TLS, or carry them over an authenticated tunnel between named endpoints.", "Allowlist sending applications and facilities per interface, and reject messages whose sender fields do not match the authenticated peer.", "Alert on messages from unexpected sources, and route clinically significant result changes for human review." ], "prompts": [ "Which senders can reach each interface port?", "How does an interface check who sent a message?", "What would a forged result look like when it reached the record?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "NAUT", "TXIG", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/594.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/940.html", "https://cwe.mitre.org/data/definitions/346.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://attack.mitre.org/techniques/T1557/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-k", "@type": "skos:Concept", "notation": "CRI-IN-K", "prefLabel": "Integration engine as master key", "definition": "The integration engine sees, transforms and routes every clinical message, and its routes can be edited by a handful of accounts. Whoever controls it can rewrite results, redirect orders or copy every message out, across every connected system at once.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The integration engine is treated as a safety-critical system: changes to routes and transforms are controlled, reviewed and detectable.", "measures": [ "Put route and transform changes through change control with two-person approval and versioned, signed configuration.", "Separate engine administration from ordinary IT accounts, with phishing-resistant MFA and a dedicated management network.", "Reconcile message counts and checksums between sending and receiving systems so silent rewrites show up.", "Keep a tested standby engine and a documented manual workaround for each critical feed." ], "prompts": [ "Who can edit routes and transforms in the integration engine?", "How are engine changes reviewed and detected?", "What could someone controlling the engine change across systems?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "AUTH", "AUDT", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/385.html", "https://capec.mitre.org/data/definitions/176.html", "https://cwe.mitre.org/data/definitions/732.html", "https://cwe.mitre.org/data/definitions/1220.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://attack.mitre.org/techniques/T1119/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-q", "@type": "skos:Concept", "notation": "CRI-IN-Q", "prefLabel": "Device data charted without integrity", "definition": "Device integration middleware writes vital signs, pump rates and ventilator settings into the record without proving which device produced them or that values were not changed in transit. Wrong values become the charted truth that drives early-warning scores and treatment decisions.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Device data entering the record carries proof of its source and integrity, and is validated before it is charted.", "measures": [ "Authenticate each device to the middleware and sign or MAC observations end to end, not only per network hop.", "Require clinician validation of device data before charting, with the device identifier shown alongside each value.", "Range-check and rate-check incoming values against physiology and the device's own reported limits." ], "prompts": [ "How does middleware prove which device produced a value?", "What validation happens before device data is charted?", "Which scores and decisions consume charted device data?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "NAUT", "TXIG" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/384.html", "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/924.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/940.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://emb3d.mitre.org/threats/TID-406.html", "https://emb3d.mitre.org/threats/TID-407.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-j", "@type": "skos:Concept", "notation": "CRI-IN-J", "prefLabel": "Open DICOM nodes", "definition": "Imaging systems accept DICOM store, query and retrieve requests from any node that knows an application title, which is usually guessable. Images can be pulled out in bulk, or new images inserted into a patient's study, including files that also carry executable code.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "DICOM associations are authenticated and limited to known peers, and every received object is checked before it reaches a study.", "measures": [ "Use DICOM TLS with certificates per node, and restrict associations to an allowlist of application titles and addresses.", "Never expose PACS or modality DICOM ports to the internet; reach remote sites through authenticated gateways.", "Scan received DICOM files for embedded executable content and quarantine objects arriving from unexpected sources." ], "prompts": [ "Which nodes can query or store to the imaging systems?", "Is any DICOM peer authenticated beyond its application title?", "How are received objects checked before joining a study?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "NAUT", "TXCF", "MLDP" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles", "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://capec.mitre.org/data/definitions/636.html", "https://capec.mitre.org/data/definitions/157.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/923.html", "https://cwe.mitre.org/data/definitions/434.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1190/", "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care", "seenIn": [ { "prefLabel": "Open PACS servers, 2019", "source": [ "https://www.helpnetsecurity.com/2019/09/18/confidential-patient-data/", "https://www.hipaajournal.com/update-issued-on-unsecured-pacs-as-exposed-medical-image-total-rises-to-1-19-billion/" ] }, { "prefLabel": "DICOM files carrying malware, 2019", "source": [ "https://web.nvd.nist.gov/vuln/detail/CVE-2019-11687", "https://www.govinfosecurity.com/researchers-malware-be-hidden-in-medical-images-a-12388" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-10", "@type": "skos:Concept", "notation": "CRI-IN-10", "prefLabel": "Identity mismatched across interfaces", "definition": "Each system keys patients differently and interfaces map identifiers with brittle rules. A mapping error, or a deliberate edit to a demographic message, merges two people or files results under the wrong patient, so treatment follows someone else's data.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patient identity is matched on multiple strong identifiers end to end, and every merge or mismatch is detected and reviewed.", "measures": [ "Use an enterprise master patient index and match on at least two independent identifiers in every interface.", "Hold and queue messages whose identifiers fail to match rather than guessing, and alert the owning team.", "Log and review every patient merge and unmerge, with the ability to trace and reverse filed results." ], "prompts": [ "Which identifiers do interfaces use to match a patient?", "Who reviews mismatches flagged between systems?", "How would results filed to the wrong patient be noticed?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I" ], "mds2": [ "IGAU", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/153.html", "https://cwe.mitre.org/data/definitions/694.html", "https://cwe.mitre.org/data/definitions/706.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-9", "@type": "skos:Concept", "notation": "CRI-IN-9", "prefLabel": "Over-broad scopes for FHIR apps", "definition": "Third-party and patient-facing apps get FHIR access through broad scopes or long-lived tokens granted once. A compromised or careless app can read whole populations' records through a legitimate API, and nobody notices because the calls look normal.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "API access is granted per purpose, minimal in scope and time, and monitored for unusual volume.", "measures": [ "Grant the narrowest SMART scopes needed, prefer patient-level over system-level access, and expire refresh tokens.", "Rate-limit and alert on bulk queries and access patterns outside an app's declared purpose.", "Review registered apps regularly and revoke those without an owner or current agreement." ], "prompts": [ "What scopes and token lifetimes do FHIR apps receive?", "Who approves a new app's access, and for what purpose?", "Would bulk reads through a legitimate API raise an alert?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "AUTH", "MPII", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/1.html", "https://capec.mitre.org/data/definitions/57.html", "https://cwe.mitre.org/data/definitions/1220.html", "https://cwe.mitre.org/data/definitions/863.html", "https://cwe.mitre.org/data/definitions/770.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1213/", "https://attack.mitre.org/techniques/T1567/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-8", "@type": "skos:Concept", "notation": "CRI-IN-8", "prefLabel": "Replayed and duplicated messages", "definition": "Interfaces cannot tell a new message from a resent one. A replayed medication order, admission or transfer is acted on twice: a second dose dispensed, a bed reassigned, a discharge triggered.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every clinical message is unique, ordered and processed once, and duplicates are caught before they act.", "measures": [ "Enforce unique message control IDs with sequence checking and reject duplicates within a defined window.", "Make order processing idempotent so a resent order updates rather than duplicates.", "Timestamp and sign messages so stale replays outside their validity window are refused." ], "prompts": [ "How does each interface recognise a duplicated message?", "Which repeated messages could cause harm if acted on twice?", "Where are message order and uniqueness enforced?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "TXIG", "IGAU" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/60.html", "https://capec.mitre.org/data/definitions/594.html", "https://cwe.mitre.org/data/definitions/294.html", "https://cwe.mitre.org/data/definitions/924.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://emb3d.mitre.org/threats/TID-221.html", "https://emb3d.mitre.org/threats/TID-407.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-7", "@type": "skos:Concept", "notation": "CRI-IN-7", "prefLabel": "Feeds that fail silently", "definition": "When an interface stops, queues fill quietly and the receiving system simply shows nothing new. Critical results, allergy updates or admissions stop arriving, and clinicians take the silence for normal.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every critical feed is monitored end to end, and staff are told when data stops flowing.", "measures": [ "Monitor queue depth and message age per critical feed, with alerts to an owner who is on duty around the clock.", "Send heartbeat messages and show a visible stale-data warning in receiving systems when they stop.", "Define and rehearse what wards do when a feed is down, including phoning critical results." ], "prompts": [ "How would anyone know a critical feed had stopped?", "Who is told when interface queues back up?", "What do clinicians see when no new data arrives?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/603.html", "https://cwe.mitre.org/data/definitions/392.html", "https://cwe.mitre.org/data/definitions/778.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1489/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-6", "@type": "skos:Concept", "notation": "CRI-IN-6", "prefLabel": "Exchange trusts every participant equally", "definition": "Regional and national record exchanges give every connected organisation the same reach. One compromised clinic, vendor or pharmacy can query or push records about patients it has never treated.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Access through exchanges is tied to a demonstrated care relationship, and each participant's use is monitored.", "measures": [ "Require a care-relationship or consent assertion per query and audit it against later activity.", "Apply per-participant quotas and anomaly detection, and suspend participants quickly when misuse shows.", "Sign pushed documents at source so receivers can check provenance before filing them." ], "prompts": [ "What can one participant query through the exchange?", "Is access tied to a care relationship with the patient?", "Who monitors each organisation's use of the exchange?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "AUTH", "AUDT", "NAUT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/21.html", "https://capec.mitre.org/data/definitions/122.html", "https://cwe.mitre.org/data/definitions/863.html", "https://cwe.mitre.org/data/definitions/346.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1199/", "https://attack.mitre.org/techniques/T1213/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-5", "@type": "skos:Concept", "notation": "CRI-IN-5", "prefLabel": "Malformed messages break the engine", "definition": "Parsers in engines and receiving systems trust message structure. Oversized fields, unexpected segments or crafted XML and JSON crash interfaces, inject content downstream, or exhaust resources, stopping clinical data flows hospital-wide.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every interface validates structure and content against a strict profile before processing.", "measures": [ "Validate messages against conformance profiles and reject or quarantine anything outside them.", "Disable external entity resolution and limit message size, nesting and field length in all parsers.", "Fuzz test interfaces before go-live and after upgrades." ], "prompts": [ "Does every interface validate messages against a strict profile?", "What happens to a malformed or oversized message?", "Could one bad message stop data flows hospital-wide?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "SAHD", "IGAU" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/28.html", "https://capec.mitre.org/data/definitions/221.html", "https://capec.mitre.org/data/definitions/153.html", "https://cwe.mitre.org/data/definitions/611.html", "https://cwe.mitre.org/data/definitions/776.html", "https://cwe.mitre.org/data/definitions/1284.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1499/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-4", "@type": "skos:Concept", "notation": "CRI-IN-4", "prefLabel": "Shared interface credentials and certificates", "definition": "Interface accounts, keys and certificates are hard-coded, shared across feeds and vendors, and tracked nowhere. One leaked secret opens many interfaces, and an expiring certificate stops several feeds at once without warning.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Each interface has its own managed credentials, with known owners, rotation and expiry monitoring.", "measures": [ "Issue a distinct credential or certificate per interface and peer, stored in a secrets manager rather than config files.", "Track expiry dates centrally and alert well before any certificate lapses.", "Rotate interface secrets on schedule and whenever a vendor engineer or integrator leaves." ], "prompts": [ "Which interface credentials are shared across feeds or vendors?", "Who owns each certificate, and who watches its expiry?", "How many interfaces would one leaked secret open?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#D" ], "mds2": [ "NAUT", "SGUD" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/560.html", "https://cwe.mitre.org/data/definitions/798.html", "https://cwe.mitre.org/data/definitions/298.html", "https://cwe.mitre.org/data/definitions/522.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1552/001/", "https://attack.mitre.org/techniques/T1078/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-3", "@type": "skos:Concept", "notation": "CRI-IN-3", "prefLabel": "Test interfaces wired to production", "definition": "Test and training systems are connected to live feeds for convenience. Test orders and dummy results flow into real records, or copies of real patient data sit in test systems with weaker controls.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Test and live environments are separated, and only synthetic or de-identified data crosses into test.", "measures": [ "Block network routes between test and production interfaces, and use distinct identifiers that live systems reject.", "Use synthetic or de-identified data in test, and approve any exception formally with an expiry date.", "Mark test messages clearly and alert if one ever arrives in production." ], "prompts": [ "Are any test or training systems connected to live feeds?", "Where could test orders reach a real patient's record?", "What real patient data sits in test environments?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "DIDT", "SAHD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://cwe.mitre.org/data/definitions/1269.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/#cri-in-2", "@type": "skos:Concept", "notation": "CRI-IN-2", "prefLabel": "Patient data in interface logs", "definition": "Engines keep full messages in logs, error queues and debug traces for troubleshooting, often for years. Support staff, vendors and anyone with log access can read complete patient records outside the controls of the clinical system.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/integration-and-interoperability/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Interface logs keep only what troubleshooting needs, for as short a time as possible, under the same protection as the record.", "measures": [ "Mask or truncate patient identifiers and clinical content in logs by default.", "Encrypt error queues and set retention limits that purge resolved messages.", "Restrict and audit access to logs, including vendor support access." ], "prompts": [ "How much patient data do engine logs and error queues keep?", "Who can read interface logs, including vendors?", "How long are full messages retained for troubleshooting?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "MPII", "STCF", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/497.html", "https://cwe.mitre.org/data/definitions/532.html", "https://cwe.mitre.org/data/definitions/312.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "@type": "skos:Concept", "notation": "CRI-NW", "prefLabel": "Networks and Wireless", "definition": "Segmentation, legacy systems inside devices, Wi-Fi, WMTS telemetry, Bluetooth, RTLS, device inventory and satellite sites.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-a", "@type": "skos:Concept", "notation": "CRI-NW-A", "prefLabel": "Life support on the office network", "definition": "Monitors, pumps, ventilators and imaging share flat network segments with office PCs and email. Ransomware or a worm landing on one desktop spreads to clinical devices, which stop or must be pulled off the network mid-care.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical devices sit in segments sized to their safety role, with only the flows they need allowed.", "measures": [ "Segment medical devices by function and criticality, and permit only documented flows to named systems.", "Block office-to-device traffic by default, including file sharing and remote desktop protocols.", "Design devices to keep delivering therapy and local alarms when network segments are isolated in an incident." ], "prompts": [ "Which clinical devices share a segment with office PCs?", "What flows does each clinical segment actually need?", "How would ransomware on one desktop reach a ventilator?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#E" ], "mds2": [ "CONN", "SAHD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/700.html", "https://cwe.mitre.org/data/definitions/653.html", "https://cwe.mitre.org/data/definitions/923.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1210/", "https://attack.mitre.org/techniques/T0866/" ], "harm": "direct", "seenIn": [ { "prefLabel": "WannaCry and the NHS, 2017", "source": [ "https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/", "https://www.gov.uk/government/news/foreign-office-minister-condemns-north-korean-actor-for-wannacry-attacks" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-k", "@type": "skos:Concept", "notation": "CRI-NW-K", "prefLabel": "Unpatchable systems inside devices", "definition": "Imaging, lab and monitoring devices run frozen, certified builds of old operating systems that cannot be patched or run endpoint protection without the manufacturer. Known, public exploits reach them as soon as anything else on their network is compromised.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Devices that cannot be patched are compensated for by the network around them, and replaced on a planned date.", "measures": [ "Place unpatchable devices behind dedicated enforcement points that allow only their documented protocols.", "Require manufacturers to state patch support periods and validated update timelines at procurement.", "Monitor these segments for exploit traffic and keep a replacement date on every device record." ], "prompts": [ "Which devices run operating systems that cannot be patched?", "What network controls compensate for each unpatchable device?", "When is each one due to be replaced?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#E" ], "mds2": [ "CSUP", "RDMP", "MLDP" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/310.html", "https://cwe.mitre.org/data/definitions/1104.html", "https://cwe.mitre.org/data/definitions/1329.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1210/", "https://emb3d.mitre.org/threats/TID-210.html" ], "harm": "care", "seenIn": [ { "prefLabel": "WannaCry and the NHS, 2017", "source": [ "https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/", "https://www.gov.uk/government/news/foreign-office-minister-condemns-north-korean-actor-for-wannacry-attacks" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-q", "@type": "skos:Concept", "notation": "CRI-NW-Q", "prefLabel": "Telemetry lost without an alarm", "definition": "Wireless telemetry and Wi-Fi monitors drop out when the spectrum is jammed, crowded or misconfigured. Ambulatory and cardiac patients go unmonitored while the central station shows stale or missing traces that nobody treats as an alarm.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Loss of a wireless monitoring link is itself an alarm, raised locally and centrally.", "measures": [ "Raise a technical alarm at the bedside and central station whenever a wireless link drops beyond a short threshold.", "Survey and manage the spectrum for telemetry bands and clinical Wi-Fi, with interference monitoring in ward areas.", "Define which patients cannot be on wireless-only monitoring and plan fallback to wired or observation." ], "prompts": [ "Where on site is wireless monitoring coverage weak?", "What raises an alarm when a wireless link drops?", "Who watches the spectrum used by telemetry?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/601.html", "https://capec.mitre.org/data/definitions/604.html", "https://cwe.mitre.org/data/definitions/754.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0815/", "https://attack.mitre.org/techniques/T0829/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-j", "@type": "skos:Concept", "notation": "CRI-NW-J", "prefLabel": "Clinical systems reachable from the internet", "definition": "PACS, device consoles and vendor service ports end up reachable from the internet through misconfigured firewalls, NAT rules or vendor cellular modems. Search engines index them, and anyone can find patient images or a way in.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "No clinical system is reachable from the internet except through an authenticated, monitored gateway.", "measures": [ "Scan the hospital's own address ranges from outside regularly and act on any clinical service found.", "Ban direct internet exposure of devices and route vendor access through a managed remote-access gateway.", "Inventory cellular modems and out-of-band links built into devices and close or monitor them." ], "prompts": [ "Which clinical systems could be found from the internet today?", "Which vendor modems bypass the hospital firewall?", "When was external exposure last checked, and by whom?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "CONN", "RMOT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/292.html", "https://capec.mitre.org/data/definitions/300.html", "https://cwe.mitre.org/data/definitions/1188.html", "https://cwe.mitre.org/data/definitions/923.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1190/", "https://attack.mitre.org/techniques/T1133/", "https://emb3d.mitre.org/threats/TID-310.html" ], "seenIn": [ { "prefLabel": "Open PACS servers, 2019", "source": [ "https://www.helpnetsecurity.com/2019/09/18/confidential-patient-data/", "https://www.hipaajournal.com/update-issued-on-unsecured-pacs-as-exposed-medical-image-total-rises-to-1-19-billion/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-10", "@type": "skos:Concept", "notation": "CRI-NW-10", "prefLabel": "Shared network stack flaws", "definition": "Many device types embed the same third-party network stack. One flaw in it lets a single malformed packet crash or take over pumps, monitors and imaging from many makers, and nobody knows which devices carry it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The hospital knows which components each device contains and can shield affected devices quickly.", "measures": [ "Require SBOMs at procurement and map them against the device inventory so stack flaws resolve to device lists.", "Keep network signatures and filtering ready to shield vulnerable device segments within hours.", "Require manufacturers to fuzz their network stacks and disclose affected models promptly." ], "prompts": [ "Which devices embed the same third-party network stack?", "How quickly could affected devices be shielded on the network?", "Where would you learn about a flaw in that stack?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#E" ], "mds2": [ "SBOM", "CSUP", "RDMP" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/28.html", "https://cwe.mitre.org/data/definitions/1395.html", "https://cwe.mitre.org/data/definitions/1104.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1210/", "https://attack.mitre.org/techniques/T0814/", "https://emb3d.mitre.org/threats/TID-202.html", "https://emb3d.mitre.org/threats/TID-405.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "URGENT/11, 2019", "source": [ "https://healthcareitnews.com/node/544606" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-9", "@type": "skos:Concept", "notation": "CRI-NW-9", "prefLabel": "Spoofed and shared Wi-Fi", "definition": "Medical devices join clinical Wi-Fi with one pre-shared key that never changes and is printed in service manuals. Anyone with the key can join, impersonate the network with an evil twin, or read and alter device traffic.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Devices authenticate to the network individually, and the network authenticates itself to devices.", "measures": [ "Use certificate-based 802.1X for devices that support it, and per-device keys for those that do not.", "Detect rogue and evil-twin access points in clinical areas and contain them.", "Rotate any shared keys on staff and vendor departures and remove them from documentation." ], "prompts": [ "How do devices authenticate to clinical Wi-Fi?", "When did the pre-shared key last change, and who knows it?", "How would devices detect an evil twin network?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "NAUT", "TXCF" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/94.html", "https://capec.mitre.org/data/definitions/616.html", "https://cwe.mitre.org/data/definitions/1391.html", "https://cwe.mitre.org/data/definitions/322.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1557/004/", "https://attack.mitre.org/techniques/T0860/", "https://emb3d.mitre.org/threats/TID-411.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-8", "@type": "skos:Concept", "notation": "CRI-NW-8", "prefLabel": "No list of connected devices", "definition": "Nobody can say which medical devices are on the network, where they are, what software they run or who owns them. Segmentation, patching, incident response and recalls all start by guessing.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every connected device is known, with its location, software, owner and risk recorded and kept current.", "measures": [ "Combine passive network discovery with the clinical engineering asset register and reconcile them continuously.", "Record software versions, SBOM, network flows and clinical criticality for every connected device.", "Make network connection depend on the device being registered." ], "prompts": [ "Can you list every connected device, its location and owner?", "How is the inventory kept current as devices move?", "How long would a recall search take today?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R" ], "mds2": [ "CONN", "SBOM" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/169.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-7", "@type": "skos:Concept", "notation": "CRI-NW-7", "prefLabel": "Bluetooth from the corridor", "definition": "Bedside and wearable devices accept Bluetooth connections with weak or no pairing. Someone in the corridor or next bed can crash them, read readings or send commands, and flaws in common Bluetooth chips affect many devices at once.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Bluetooth links to clinical devices are authenticated, encrypted and limited to the intended peer.", "measures": [ "Require authenticated pairing with numeric comparison or out-of-band exchange, never just-works for therapy devices.", "Accept connections only from bonded peers and disable advertising once paired where possible.", "Track chipset vulnerabilities through the SBOM and patch or shield affected models." ], "prompts": [ "Which bedside devices accept Bluetooth connections, and how?", "Could someone in the corridor connect to them?", "Which common Bluetooth chips do your devices share?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "NAUT", "TXCF" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/667.html", "https://capec.mitre.org/data/definitions/668.html", "https://capec.mitre.org/data/definitions/666.html", "https://cwe.mitre.org/data/definitions/940.html", "https://cwe.mitre.org/data/definitions/322.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1011/001/", "https://emb3d.mitre.org/threats/TID-406.html", "https://emb3d.mitre.org/threats/TID-408.html" ], "harm": "direct", "seenIn": [ { "prefLabel": "SweynTooth Bluetooth flaws, 2020", "source": [ "https://www.raps.org/resource/fda-warns-of-cybersecurity-vulnerabilities-in-pace.html", "https://www.hpnonline.com/healthcare-it/article/21128449/fda-informs-about-potential-cybersecurity-vulnerabilities-in-certain-medical-devices-with-bluetooth-low-energy" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-6", "@type": "skos:Concept", "notation": "CRI-NW-6", "prefLabel": "Clocks and names shared with devices", "definition": "Monitors, pumps and the record depend on hospital DNS, DHCP and time servers built for office IT. A failure or spoof misdirects device data or skews timestamps, so trends, alarms and drug timings are recorded out of order.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical devices rely on core network services that are hardened, redundant and authenticated.", "measures": [ "Provide dedicated, redundant DNS, DHCP and time sources for clinical segments.", "Use authenticated time and pinned server addresses for devices that support them.", "Alert on clock drift between devices and the record beyond a clinical tolerance." ], "prompts": [ "Which DNS, DHCP and time servers do devices depend on?", "Are those services redundant and protected from spoofing?", "How would skewed timestamps show up in the record?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "IGAU", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/142.html", "https://capec.mitre.org/data/definitions/697.html", "https://cwe.mitre.org/data/definitions/350.html", "https://cwe.mitre.org/data/definitions/346.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1557/003/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-5", "@type": "skos:Concept", "notation": "CRI-NW-5", "prefLabel": "Live ports in public areas", "definition": "Network ports in patient rooms, waiting areas and corridors are live and give full access to clinical networks. A visitor or patient plugs in a laptop or small device and reaches monitors and records.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Only known, authorised devices can use a network port, and public areas have none that reach clinical networks.", "measures": [ "Enforce network access control on every port, placing unknown devices in an isolated segment.", "Disable unused ports and patch only what each room needs.", "Alert on new devices appearing on clinical segments." ], "prompts": [ "Which network ports in public areas are live?", "What happens when an unknown device plugs in?", "Could a visitor's laptop reach a monitor or the record?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E" ], "mds2": [ "CONN", "PLOK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/390.html", "https://cwe.mitre.org/data/definitions/1263.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1200/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-4", "@type": "skos:Concept", "notation": "CRI-NW-4", "prefLabel": "Location tags leak movements", "definition": "Real-time location tags on patients, staff and equipment broadcast identifiers and feed location history to dashboards open to many users. Movements of vulnerable or high-profile patients can be tracked, and spoofed tags send staff looking in the wrong place.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Location data is collected for a stated purpose, protected like clinical data and limited to those who need it.", "measures": [ "Rotate tag identifiers and encrypt tag transmissions where the technology allows.", "Restrict location views by role and keep history only as long as its purpose needs.", "Tell patients and staff what is tracked and why." ], "prompts": [ "Who can see location history from RTLS dashboards?", "What purpose justifies tracking each patient or staff tag?", "How would spoofed tags be detected?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#D", "https://ostering.com/ns/linddun#U" ], "mds2": [ "MPII", "TXCF" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/619.html", "https://capec.mitre.org/data/definitions/612.html", "https://cwe.mitre.org/data/definitions/359.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-3", "@type": "skos:Concept", "notation": "CRI-NW-3", "prefLabel": "Patient and guest Wi-Fi not isolated", "definition": "Guest and patient Wi-Fi share infrastructure and routing with clinical networks. A patient's infected laptop, or a device bridging two networks, becomes a path into clinical systems.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Guest networks are isolated from clinical networks in design, not only by configuration.", "measures": [ "Route guest traffic straight to the internet on separate infrastructure or tunnelled VLANs with no internal routes.", "Enable client isolation on guest Wi-Fi.", "Test isolation after every network change." ], "prompts": [ "How is guest Wi-Fi separated from clinical networks?", "Could a device bridge guest and clinical networks?", "What shared infrastructure do both networks use?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#E" ], "mds2": [ "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/700.html", "https://cwe.mitre.org/data/definitions/653.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1599/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/#cri-nw-2", "@type": "skos:Concept", "notation": "CRI-NW-2", "prefLabel": "Satellite sites trusted completely", "definition": "Clinics, community sites and partner buildings connect over links with weaker controls, yet the main network trusts them fully. A compromise at the smallest site reaches the main hospital's devices.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/networks-and-wireless/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every site is treated as its own trust zone, with only required flows allowed into the main hospital.", "measures": [ "Terminate site links at enforcement points that filter to documented services.", "Apply the same device and identity standards at small sites, or limit what they can reach.", "Monitor inter-site traffic for unexpected protocols." ], "prompts": [ "What can a small clinic site reach in the main hospital?", "Which flows from satellite sites are actually required?", "How are controls at the smallest site checked?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#E" ], "mds2": [ "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/700.html", "https://cwe.mitre.org/data/definitions/653.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1199/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "@type": "skos:Concept", "notation": "CRI-CC", "prefLabel": "Clinical Communications", "definition": "Nurse call, alarm routing to handsets, pagers and bleeps, DECT and Wi-Fi phones, secure and shadow messaging, crash calls, switchboard and overhead paging.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-a", "@type": "skos:Concept", "notation": "CRI-CC-A", "prefLabel": "Alarms that never reach the nurse", "definition": "Monitor and pump alarms travel through middleware to nurses' handsets, with no end-to-end confirmation of delivery. When the middleware fails, is misconfigured or is tampered with, alarms vanish while every system shows normal.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every clinical alarm is confirmed as delivered and acknowledged, and escalates when it is not.", "measures": [ "Require acknowledgement within a set time and escalate unacknowledged alarms to another clinician and the central station.", "Monitor the middleware with end-to-end test alarms and alert on any failure to deliver.", "Keep audible bedside and central alarms active as a backstop whatever the middleware does." ], "prompts": [ "How is delivery of an alarm to a handset confirmed?", "What happens when an alarm is not acknowledged in time?", "Would anyone notice the middleware had stopped forwarding alarms?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/603.html", "https://cwe.mitre.org/data/definitions/392.html", "https://cwe.mitre.org/data/definitions/754.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0878/", "https://attack.mitre.org/techniques/T0815/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-k", "@type": "skos:Concept", "notation": "CRI-CC-K", "prefLabel": "Crash calls on one platform", "definition": "The cardiac arrest and rapid response call path runs on the same IP telephony and network as everything else. When ransomware or an outage takes it down, staff cannot summon the resuscitation team.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Emergency call paths have an independent fallback that works when the main network and telephony are down.", "measures": [ "Provide an independent backup for crash and emergency calls, such as dedicated lines, radios or hard-wired alarms.", "Test the emergency call path daily, end to end, and log the result.", "Train staff on the downtime method and display it at every call point." ], "prompts": [ "What carries a crash call from the handset to every team bleep?", "How does the caller know the team was reached?", "What is the fallback, and when was it last tested?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/603.html", "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1489/", "https://attack.mitre.org/techniques/T1498/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-q", "@type": "skos:Concept", "notation": "CRI-CC-Q", "prefLabel": "Nurse call failing silently", "definition": "IP nurse call systems sit on shared networks with default settings. A fault or attack stops patient calls from reaching staff, or marks them answered, and patients who cannot leave their bed have no other way to get help.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Nurse call is designed and monitored as a patient-safety system with a known fallback.", "measures": [ "Supervise every call point and alert on lost connections or stuck states.", "Isolate nurse call on its own segment and harden its servers and default accounts.", "Define ward procedures, such as increased rounding, for when nurse call is degraded." ], "prompts": [ "How would staff know nurse call had stopped working?", "What does a patient who can't leave the bed do if it fails?", "Who monitors nurse call as a safety system?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "SAHD", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/176.html", "https://cwe.mitre.org/data/definitions/1392.html", "https://cwe.mitre.org/data/definitions/754.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0814/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-j", "@type": "skos:Concept", "notation": "CRI-CC-J", "prefLabel": "False alarms and fake calls", "definition": "Handsets and paging accept alarms and messages from anything that can reach the messaging gateway. Injected false alarms or fake emergency calls send staff to the wrong bed, mask real alarms and wear down trust in the system.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Only authenticated systems can raise alarms and emergency calls, and staff can see where each came from.", "measures": [ "Authenticate every system that can send to the alarm and messaging gateway, and reject the rest.", "Show the source device, location and patient on every alarm so staff can judge it quickly.", "Alert on unusual alarm volumes or sources." ], "prompts": [ "Which systems can send alarms or calls to handsets?", "Can staff see where an alarm or emergency call came from?", "How would injected false alarms be spotted and stopped?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "NAUT", "TXIG" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/151.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/940.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-10", "@type": "skos:Concept", "notation": "CRI-CC-10", "prefLabel": "Pages read and spoofed by radio", "definition": "Pagers and bleeps carry patient names, conditions and locations unencrypted over radio. Anyone with a cheap receiver can read them, and anyone with a transmitter can send pages that look genuine.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Paging carries no patient-identifiable data in the clear, and pages that start clinical action are authenticated.", "measures": [ "Move clinical paging to encrypted, authenticated messaging, or strip patient details from pages.", "Use pages only as a call-back prompt, with clinical detail given on a verified channel.", "Plan retirement of unencrypted paging, keeping a resilient alert method in its place." ], "prompts": [ "What patient details appear in pager messages?", "Could a cheap receiver read your hospital's pages?", "How would a spoofed page be told from a genuine one?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "TXCF", "TXIG" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/157.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/319.html", "https://cwe.mitre.org/data/definitions/290.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1040/" ], "seenIn": [ { "prefLabel": "Leaking Beeps, 2016", "source": [ "https://documents.trendmicro.com/assets/threat-reports/wp-leaking-beeps-healthcare.pdf", "https://www.trendmicro.com/vinfo/us/security/news/cyber-attacks/are-pagers-leaking-your-patients-phi" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-9", "@type": "skos:Concept", "notation": "CRI-CC-9", "prefLabel": "Clinical care on consumer messaging", "definition": "When official tools are slow, clinicians share patient photos, results and decisions in consumer messaging groups on personal phones. Data sits outside the record and the hospital, with no audit, retention or way to remove it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Official clinical messaging is quicker than the shadow alternative, and decisions made in it reach the record.", "measures": [ "Provide an approved secure messaging app that handles photos and groups as easily as consumer apps.", "Write messaging decisions back to the record automatically or prompt for it.", "Set clear guidance, and remove clinical content from personal devices when staff leave." ], "prompts": [ "Why do clinicians reach for consumer messaging instead?", "How do decisions made in messages reach the record?", "What happens to patient photos on personal phones?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "MPII", "STCF" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/545.html", "https://cwe.mitre.org/data/definitions/359.html", "https://cwe.mitre.org/data/definitions/213.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1213/005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-8", "@type": "skos:Concept", "notation": "CRI-CC-8", "prefLabel": "Impersonating a clinician by message", "definition": "Secure messaging trusts the display name. Anyone with a hijacked account, or a lookalike profile, can send orders, ask for results or request a change in treatment, and the recipient acts on it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical instructions sent by message come from verified identities, and high-risk requests are confirmed on a second channel.", "measures": [ "Tie messaging accounts to verified staff identity, with phishing-resistant authentication.", "Show role and verification status clearly, and flag external or newly created accounts.", "Require a call-back or order entry for high-risk instructions such as drug or dose changes." ], "prompts": [ "How does a recipient verify who sent a clinical message?", "Which requests need confirming on a second channel?", "What could a hijacked messaging account ask for?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#R" ], "mds2": [ "PAUT", "AUTH" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://capec.mitre.org/data/definitions/98.html", "https://cwe.mitre.org/data/definitions/290.html", "https://cwe.mitre.org/data/definitions/308.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1566/003/", "https://attack.mitre.org/techniques/T1534/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-7", "@type": "skos:Concept", "notation": "CRI-CC-7", "prefLabel": "Switchboard and rota as weak link", "definition": "Switchboard, on-call rotas and contact directories decide who gets called. A tampered rota or a convincing caller sends emergency calls to the wrong person, or obtains direct numbers and patient whereabouts.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Rotas and directories are controlled data, and switchboard follows verification scripts.", "measures": [ "Restrict and log edits to on-call rotas and contact directories, with change alerts to the owning team.", "Give switchboard staff verification scripts for requests about patients or staff.", "Check critical rotas automatically against expected coverage before each shift." ], "prompts": [ "Who can edit on-call rotas and the staff directory?", "What verification does switchboard apply to unusual callers?", "How would a tampered rota be noticed during the night?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "AUTH", "AUDT" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/415.html", "https://capec.mitre.org/data/definitions/407.html", "https://cwe.mitre.org/data/definitions/732.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1566/004/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-6", "@type": "skos:Concept", "notation": "CRI-CC-6", "prefLabel": "Shared handsets with no owner", "definition": "Ward handsets are passed between staff without login. Whoever holds one sees patient alarms and messages and can acknowledge them, and there is no record of who did.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Each alarm acknowledgement is tied to the person holding the handset at the time.", "measures": [ "Require quick sign-in to handsets at shift start, by badge or code, and sign out on dock.", "Record who acknowledged every alarm and message.", "Hide message content on the lock screen and wipe handsets on return." ], "prompts": [ "How do you know who held a handset when an alarm was acknowledged?", "Do staff sign in to ward handsets at handover?", "What can someone holding a spare handset see and do?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#R", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#Nr" ], "mds2": [ "PAUT", "ALOF", "AUDT" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/122.html", "https://cwe.mitre.org/data/definitions/308.html", "https://cwe.mitre.org/data/definitions/1463.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-5", "@type": "skos:Concept", "notation": "CRI-CC-5", "prefLabel": "Overhead paging hijacked", "definition": "Overhead paging and public address systems are now IP-based and reachable from the wider network. A false emergency code or evacuation announcement can cause panic or disrupt care across a site.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Public address is reachable only from authorised consoles, and emergency announcements need authenticated sources.", "measures": [ "Isolate the PA system and permit only named consoles to broadcast.", "Require authentication for emergency and evacuation announcements.", "Log every broadcast and alert on unexpected sources." ], "prompts": [ "Which consoles and systems can trigger overhead announcements?", "How is an emergency announcement authenticated?", "What would a false evacuation code cost the site?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#D" ], "mds2": [ "AUTH", "CONN" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/306.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-4", "@type": "skos:Concept", "notation": "CRI-CC-4", "prefLabel": "Clinical apps on personal phones", "definition": "Staff run clinical messaging and record apps on their own phones without device management. Lost or shared phones expose patient data on lock screens, in backups and in notifications.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical apps protect their own data, whatever device they run on.", "measures": [ "Use app-level protection: separate PIN, encrypted storage and remote wipe of app data.", "Hide clinical content from notifications and exclude it from personal backups.", "Require a minimum operating system version and screen lock to run clinical apps." ], "prompts": [ "What patient data shows on lock screens and notifications?", "Do clinical apps protect their data on unmanaged phones?", "What happens to app data when a phone is lost?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "STCF", "ALOF" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/507.html", "https://cwe.mitre.org/data/definitions/312.html", "https://cwe.mitre.org/data/definitions/359.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-3", "@type": "skos:Concept", "notation": "CRI-CC-3", "prefLabel": "Status boards in public view", "definition": "Electronic whiteboards and patient status screens show names, diagnoses and risks where visitors can see them, and some can be edited from any ward PC without login.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Status displays show only what the audience needs, and edits are authenticated.", "measures": [ "Use initials or bed numbers on displays visible to the public.", "Require authenticated edits and log changes to patient status.", "Position screens and set privacy modes by location." ], "prompts": [ "What do status boards show that visitors can read?", "Who can edit a status board, and is a login required?", "Which details could be removed without hurting care?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#T" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "MPII", "AUTH" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/699.html", "https://cwe.mitre.org/data/definitions/359.html", "https://cwe.mitre.org/data/definitions/862.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/#cri-cc-2", "@type": "skos:Concept", "notation": "CRI-CC-2", "prefLabel": "Recordings with clinical detail", "definition": "Call recordings, voicemail and message archives hold clinical conversations, kept indefinitely and readable by telephony administrators and suppliers.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/clinical-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Communications records are kept for a defined purpose and period, under clinical data protection.", "measures": [ "Set retention limits for recordings and archives and purge on schedule.", "Encrypt recordings and limit access by role, with audit.", "Include telephony suppliers in data protection agreements." ], "prompts": [ "How long are call recordings and voicemail kept?", "Who can listen to archived clinical conversations?", "Do suppliers have access to communication archives?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "STCF", "MPII" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/545.html", "https://cwe.mitre.org/data/definitions/312.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1123/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "@type": "skos:Concept", "notation": "CRI-EC", "prefLabel": "Emergency and External Communications", "definition": "Ambulance dispatch, prehospital ECG and pre-alerts, emergency services radio, diversion, image transfer, telehealth, hospital-at-home hubs, staff call-in, patient SMS and backup links.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-a", "@type": "skos:Concept", "notation": "CRI-EC-A", "prefLabel": "Dispatch links fail without warning", "definition": "Ambulance dispatch, hospital status and handover links run over one integration path that nobody monitors end to end. When it fails or is taken down, crews and emergency departments keep working from stale information, ambulances queue or go to the wrong place, and no one notices until patients are harmed.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every link between dispatch and the hospital is monitored end to end and has a rehearsed fallback that does not share its failure.", "measures": [ "Send heartbeat messages across each dispatch and handover link and alarm in both control rooms when one goes quiet.", "Keep a voice and radio fallback for status and pre-alerts on separate infrastructure, with numbers held offline.", "Rehearse loss of the dispatch link jointly with the ambulance service at least yearly, including the switch back." ], "prompts": [ "Who monitors the dispatch link to the hospital end to end?", "How would both control rooms know the link had gone quiet?", "What fallback for status and pre-alerts shares none of its failure?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/582.html", "https://capec.mitre.org/data/definitions/607.html", "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/1320.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1489/", "https://attack.mitre.org/techniques/T1498/" ], "harm": "care", "seenIn": [ { "prefLabel": "Advanced and NHS 111, 2022", "source": [ "https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2025/03/software-provider-fined-3m-following-2022-ransomware-attack/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-k", "@type": "skos:Concept", "notation": "CRI-EC-K", "prefLabel": "Diversion status falsified or stale", "definition": "Regional capacity and diversion boards accept status changes from any logged-in user or unauthenticated feed. A false closed sends ambulances past the nearest capable hospital; a false open sends a stroke or trauma patient to a hospital whose scanner or theatre is down.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Diversion status is changed only by named, authorised people, is confirmed out of band, and shows its age.", "measures": [ "Require named authentication and a second confirmation by phone before a hospital's diversion status changes.", "Show the time and author of every status change on the board, and mark status older than a set period as stale.", "Publish service-level status (CT, cath lab, theatres) separately from whole-site diversion so crews route by capability." ], "prompts": [ "Who can change a hospital's diversion status, and how is it confirmed?", "Does the board show how old each status is?", "What happens when a status feed is unauthenticated or stale?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUTH", "AUDT", "IGAU" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/863.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/", "https://attack.mitre.org/techniques/T1078/" ], "harm": "care", "seenIn": [ { "prefLabel": "University Hospital Düsseldorf, 2020", "source": [ "https://www.technologyreview.com/2020/09/18/1008582/a-patient-has-died-after-ransomware-hackers-hit-a-german-hospital", "https://borncity.com/win/2020/11/18/ransomware-befall-in-uniklinik-dsseldorf-nicht-fr-todesfall-verantwortlich/" ] }, { "prefLabel": "Ascension, 2024", "source": [ "https://www.bleepingcomputer.com/news/security/ascension-health-data-of-56-million-stolen-in-ransomware-attack/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-q", "@type": "skos:Concept", "notation": "CRI-EC-Q", "prefLabel": "Prehospital ECG and pre-alert tampered", "definition": "Twelve-lead ECGs and stroke or trauma pre-alerts travel from the ambulance to the hospital by fax, email, messaging or a vendor cloud without integrity or patient binding. An altered, delayed or misattributed tracing means the cath lab or stroke team is not activated, or is activated for the wrong patient.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Prehospital clinical data is signed at source, bound to the patient and incident, and its delivery is confirmed by a person.", "measures": [ "Sign ECGs on the monitor or gateway and verify the signature before display in the hospital.", "Bind each transmission to an incident number and patient identifiers, and show both prominently to the receiving clinician.", "Require a spoken acknowledgement of time-critical pre-alerts and alarm the crew when none arrives in time." ], "prompts": [ "How is a prehospital ECG bound to the right patient and incident?", "Who confirms that a pre-alert has actually arrived?", "Which routes carry tracings: fax, email, messaging or vendor cloud?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#DD" ], "mds2": [ "TXIG", "TXCF", "NAUT" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/94.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/924.html", "https://cwe.mitre.org/data/definitions/319.html", "https://cwe.mitre.org/data/definitions/353.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://attack.mitre.org/techniques/T1557/", "https://emb3d.mitre.org/threats/TID-408.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-j", "@type": "skos:Concept", "notation": "CRI-EC-J", "prefLabel": "Emergency services radio jammed or spoofed", "definition": "Ambulance crews rely on one radio system for clinical advice, backup and handover, with no tested alternative. Jamming, a rogue transmitter or loss of the radio core leaves crews unable to call for help or receive changed instructions, and spoofed traffic can send them to false incidents.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Crews keep at least two independent ways to reach control, and voice instructions that change a destination are verified.", "measures": [ "Provide a second bearer, such as cellular with priority access or satellite, that does not share the radio core or sites.", "Detect and report interference by monitoring receiver noise at base sites and from vehicles.", "Verify destination changes received by voice through the vehicle's data terminal or a call-back procedure." ], "prompts": [ "What second way do crews have to reach control?", "How is a radio instruction that changes destination verified?", "What would crews do if the radio core went down?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#D" ], "mds2": [ "CONN" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/601.html", "https://capec.mitre.org/data/definitions/599.html", "https://capec.mitre.org/data/definitions/605.html", "https://cwe.mitre.org/data/definitions/940.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-10", "@type": "skos:Concept", "notation": "CRI-EC-10", "prefLabel": "Emergency call handoff flooded or faked", "definition": "The interface that passes calls and incident data from the emergency call centre to ambulance dispatch trusts every record it receives and has no limit on volume. A flood of fake calls or injected incidents exhausts call-takers and ambulances, and real emergencies wait.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Incident handoff between call centres and dispatch authenticates its source, limits volume and lets operators spot coordinated floods.", "measures": [ "Authenticate each system that can create incidents in dispatch and reject records from anything else.", "Rate-limit and alarm on surges of calls or incidents from one number range, route or interface.", "Keep a surge procedure that lets clinicians triage queued calls by risk when volume is abnormal." ], "prompts": [ "How does dispatch know an incident record came from the call centre?", "What limits the volume of incidents the handoff accepts?", "Could operators spot a coordinated flood of fake calls?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#D" ], "mds2": [ "NAUT", "AUDT" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/125.html", "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/770.html", "https://cwe.mitre.org/data/definitions/940.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1498/", "https://attack.mitre.org/techniques/T1499/003/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-9", "@type": "skos:Concept", "notation": "CRI-EC-9", "prefLabel": "Image transfer between hospitals unverified", "definition": "Image-sharing links between hospitals accept studies from any connected peer and import them straight into the local archive. A wrong-patient study, an altered image or a DICOM file carrying malware arrives with the trust of a referral, and when the link is down a time-critical neurosurgical or trauma referral stalls.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Images from other organisations are authenticated, matched to the patient by a person, and checked before they enter the local archive.", "measures": [ "Authenticate each sending organisation and node, and keep a list of peers allowed to send.", "Quarantine imported studies until patient identity is reconciled and files are scanned for embedded executable content.", "Keep a tested secondary route for urgent referrals, such as a separate image-sharing service, with known contacts." ], "prompts": [ "Which hospitals can push images straight into your archive?", "Who matches an incoming study to the right patient?", "What happens to a time-critical referral when the link is down?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#DD" ], "mds2": [ "NAUT", "IGAU", "MLDP" ], "standard": [ "DICOM PS3.15 Security and System Management Profiles" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/636.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/349.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://attack.mitre.org/techniques/T1204/002/" ], "harm": "care", "seenIn": [ { "prefLabel": "DICOM files carrying malware, 2019", "source": [ "https://web.nvd.nist.gov/vuln/detail/CVE-2019-11687", "https://www.govinfosecurity.com/researchers-malware-be-hidden-in-medical-images-a-12388" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-8", "@type": "skos:Concept", "notation": "CRI-EC-8", "prefLabel": "Hospital-at-home hub goes blind", "definition": "Virtual wards depend on one monitoring hub that gathers observations from patients' homes through a vendor platform and mobile networks. If the hub, platform or feed fails or is tampered with, deteriorating patients look stable and nobody is called, because silence reads as normal.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A virtual ward treats missing data as an alarm and keeps a way to reach every patient when the platform fails.", "measures": [ "Alarm on each patient whose readings stop arriving within the expected interval, not only on abnormal readings.", "Keep an offline list of virtual-ward patients with phone numbers and escalation plans, refreshed every shift.", "Restrict who can change alert thresholds and log every change with the reason and clinician." ], "prompts": [ "Does the virtual ward treat missing observations as an alarm?", "How would staff reach every patient if the platform failed?", "Which links between home and hub could fail silently?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "DTBK", "AUDT", "AUTH" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/607.html", "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/1320.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/", "https://attack.mitre.org/techniques/T1489/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-7", "@type": "skos:Concept", "notation": "CRI-EC-7", "prefLabel": "Staff call-in cascade abused", "definition": "Major-incident and staff call-in messages go out by SMS or automated calls that anyone can imitate, and the cascade platform has weak login. A false major incident pulls staff in and drains the next shift; a blocked or hijacked cascade leaves the hospital short when a real one starts.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Call-in messages are verifiable by staff, the cascade is protected like a clinical system, and a manual fallback exists.", "measures": [ "Tell staff how genuine call-ins look and give them a number or app to confirm one before travelling.", "Protect the cascade platform with multi-factor login and two-person activation for a major incident.", "Hold printed call-in trees and a switchboard procedure for when the platform is down." ], "prompts": [ "How can staff tell a genuine call-in message from a fake?", "Who can log in to the cascade platform, and how?", "What is the manual fallback if the cascade is blocked?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#D" ], "mds2": [ "PAUT", "AUTH" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/416.html", "https://cwe.mitre.org/data/definitions/308.html", "https://cwe.mitre.org/data/definitions/290.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1684/001/", "https://attack.mitre.org/techniques/T1078/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-6", "@type": "skos:Concept", "notation": "CRI-EC-6", "prefLabel": "Telehealth consult hijacked or impersonated", "definition": "Video and phone consultations use reusable links and no identity check on either side. Someone can join or take over a consult, impersonate the clinician to give harmful advice or extract details, or impersonate the patient to obtain prescriptions and records.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Both parties in a remote consultation are identified, and session links are single-use and bound to the appointment.", "measures": [ "Issue single-use, time-limited links bound to the appointment, and lock the room once both parties join.", "Verify the patient's identity at the start of each consult and record that it was done.", "Show the clinician's verified name and organisation in the client, and give patients a way to confirm it." ], "prompts": [ "How are the clinician and the patient each identified on a remote consult?", "Are session links single-use and tied to the appointment?", "Could someone join a consult without anyone noticing?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#D" ], "mds2": [ "PAUT", "TXCF" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/593.html", "https://capec.mitre.org/data/definitions/151.html", "https://cwe.mitre.org/data/definitions/308.html", "https://cwe.mitre.org/data/definitions/1467.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1684/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-5", "@type": "skos:Concept", "notation": "CRI-EC-5", "prefLabel": "Ambulance location depends on GNSS", "definition": "Ambulance location, nearest-vehicle allocation and timestamps on care records depend on GNSS. Jamming or spoofing near a station or along a route misplaces vehicles, sends a distant crew to a cardiac arrest, and leaves records with wrong times.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Vehicle location and time come from more than one source, and implausible positions are flagged before allocation.", "measures": [ "Combine GNSS with cellular location and vehicle odometry, and flag positions that jump or freeze.", "Let dispatchers override automated allocation when location quality is flagged as poor.", "Take care-record timestamps from a trusted network time source, with GNSS only as a fallback." ], "prompts": [ "What other source confirms ambulance position besides GNSS?", "How are implausible vehicle positions flagged before allocation?", "Which records take their timestamps from GNSS?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "IGAU" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/627.html", "https://capec.mitre.org/data/definitions/628.html", "https://capec.mitre.org/data/definitions/599.html", "https://cwe.mitre.org/data/definitions/348.html", "https://cwe.mitre.org/data/definitions/346.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-4", "@type": "skos:Concept", "notation": "CRI-EC-4", "prefLabel": "Patients trained to click hospital links", "definition": "Hospitals send appointment reminders, results notices and payment requests by SMS and email with links, from senders anyone can imitate. Patients learn to trust them, so fake messages, fake portals and fake public notices harvest credentials, take payments or tell people the emergency department is closed.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patients can tell genuine hospital messages from fakes, and messages never ask them to log in or pay through a link.", "measures": [ "Register sender IDs and domains, and publish how genuine messages look and what they will never ask for.", "Point patients to the portal or app by name instead of sending login links in messages.", "Monitor for look-alike domains, sender IDs and social accounts, and publish service status only on known channels." ], "prompts": [ "How can patients tell a genuine hospital message from a fake?", "Do any hospital messages ask patients to log in or pay by link?", "How would you warn the public about fake hospital notices?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/98.html", "https://capec.mitre.org/data/definitions/543.html", "https://capec.mitre.org/data/definitions/630.html", "https://cwe.mitre.org/data/definitions/451.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1566/002/", "https://attack.mitre.org/techniques/T1583/001/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-3", "@type": "skos:Concept", "notation": "CRI-EC-3", "prefLabel": "Ambulance care records leak or lag", "definition": "Electronic patient care records live on crew tablets and sync through a vendor cloud. When the sync fails at handover the emergency department works from a verbal summary, and a lost or poorly managed tablet exposes records of everyone the crew treated.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Prehospital records reach the receiving hospital reliably and are protected on the device for as long as they are held.", "measures": [ "Encrypt records on the tablet, enrol tablets in device management, and remote-wipe on loss.", "Hand over a printable or local copy of the record when the cloud sync has not completed.", "Purge records from the tablet once the hospital has acknowledged receipt." ], "prompts": [ "What happens at handover when the care record fails to sync?", "How are crew tablets protected if one is lost?", "How long do records stay on the tablet after handover?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#D" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "STCF", "TXCF", "DTBK" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/507.html", "https://cwe.mitre.org/data/definitions/312.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1005/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/#cri-ec-2", "@type": "skos:Concept", "notation": "CRI-EC-2", "prefLabel": "Backup radio and satellite never tested", "definition": "Satellite phones, backup radio and spare lines sit in a cupboard with flat batteries, expired subscriptions and outdated numbers. On the day every other channel fails, the hospital cannot reach the ambulance service, neighbouring hospitals or its own staff.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/emergency-and-external-communications/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Fallback communications are part of routine operations, tested on a schedule, and their directories are kept current offline.", "measures": [ "Test every fallback channel monthly with a real call to the ambulance service and a neighbouring hospital.", "Keep batteries charged, subscriptions in force, and a printed directory beside each device.", "Name who owns each fallback device and include its use in major-incident exercises." ], "prompts": [ "When were backup radio and satellite phones last used in anger or drill?", "Who keeps fallback directories current and offline?", "Are subscriptions, batteries and numbers checked on a schedule?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#D" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1329.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "@type": "skos:Concept", "notation": "CRI-FB", "prefLabel": "Facilities and Building Systems", "definition": "Medical gases, theatre and isolation ventilation, backup power, cold storage, water, sterile services, pneumatic tubes, lifts, infant security and building management.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-a", "@type": "skos:Concept", "notation": "CRI-FB-A", "prefLabel": "Medical gas alarms suppressed or altered", "definition": "Oxygen and other medical gas plant, pressure monitoring and area alarm panels are networked for remote monitoring with weak or no authentication. Changing pressures or suppressing alarms can starve a ward of oxygen or vacuum without anyone at the panel or on the ward being told.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Medical gas safety depends on local engineered protections and alarms that no network command can disable.", "measures": [ "Keep pressure relief, low-pressure alarms and manifold changeover hardwired, independent of the monitoring network.", "Make remote monitoring read-only, and route any remote control through an authenticated, logged path that operators approve.", "Alarm on loss of the monitoring link itself, and test area alarms against the plant on a schedule." ], "prompts": [ "Which medical gas alarms and pressures can be changed over the network?", "What local protection works whatever the network says?", "Would ward staff learn of a gas fault if the panel were silenced?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "AUTH", "AUDT" ], "standard": [ "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/636.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0838/", "https://attack.mitre.org/techniques/T0878/", "https://attack.mitre.org/techniques/T0836/", "https://emb3d.mitre.org/threats/TID-310.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-k", "@type": "skos:Concept", "notation": "CRI-FB-K", "prefLabel": "Theatre and isolation pressure reversed", "definition": "Building management controls the air changes and pressure regimes of theatres and isolation rooms. A changed setpoint or schedule turns a negative-pressure room positive or cuts theatre air changes, spreading airborne infection or raising surgical site infection, with displays still showing normal.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Critical-room pressure and air changes are monitored independently of the system that controls them, at the room.", "measures": [ "Fit independent pressure monitors with local alarms at each isolation room and theatre.", "Lock critical-room setpoints and schedules, requiring authenticated, logged changes with an engineering approval.", "Compare commanded and measured air changes daily and investigate any divergence." ], "prompts": [ "What measures room pressure independently of building management?", "Who can change setpoints or schedules for theatres and isolation rooms?", "Where would staff see that a negative-pressure room had reversed?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUTH", "AUDT" ], "standard": [ "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/862.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0832/", "https://attack.mitre.org/techniques/T0831/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-q", "@type": "skos:Concept", "notation": "CRI-FB-Q", "prefLabel": "Backup power controls disabled", "definition": "Generator, automatic transfer switch and UPS controllers are reachable from the building network or the internet, often with default credentials. Disabling the transfer or setting generators to manual means the next mains failure, accidental or engineered, takes theatres, ICU and life support down.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Changeover to backup power is protected locally and cannot be disabled from the network.", "measures": [ "Keep transfer and generator start logic local and hardwired, with network access read-only by default.", "Change default credentials, remove internet exposure and put power controllers in their own segment.", "Run load tests on a schedule and alarm when any controller leaves automatic mode." ], "prompts": [ "Can generator or transfer switch controls be reached from the network?", "Who would notice if backup power had been set to manual?", "When was a real changeover to backup power last tested?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "SAHD", "AUTH" ], "standard": [ "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/70.html", "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/1392.html", "https://cwe.mitre.org/data/definitions/306.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0816/", "https://attack.mitre.org/techniques/T0837/", "https://attack.mitre.org/techniques/T0858/", "https://emb3d.mitre.org/threats/TID-311.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-j", "@type": "skos:Concept", "notation": "CRI-FB-J", "prefLabel": "Cold storage excursions hidden", "definition": "Blood, vaccine, tissue and pharmacy fridges report to a central temperature monitoring system that can be edited or fed false readings. A heated or failed fridge looks normal, and patients receive spoiled blood products, vaccines or drugs.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Temperature evidence for stored blood, vaccines and drugs is tamper-evident and checked independently of the monitoring system.", "measures": [ "Use loggers that sign their readings, and keep an independent local display and alarm on each critical unit.", "Make recorded temperatures read-only after capture and log every acknowledgement and edit.", "Quarantine stock automatically when readings stop or gaps appear, until a person reviews them." ], "prompts": [ "How is fridge temperature evidence protected from editing?", "What independent check confirms blood and vaccines stayed in range?", "Would a failed fridge still look normal on the central system?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "AUDT" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://capec.mitre.org/data/definitions/268.html", "https://cwe.mitre.org/data/definitions/353.html", "https://cwe.mitre.org/data/definitions/778.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0832/", "https://attack.mitre.org/techniques/T0838/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-10", "@type": "skos:Concept", "notation": "CRI-FB-10", "prefLabel": "Water treatment controls changed", "definition": "Controllers for dialysis water treatment and hot water temperature are networked and maintained remotely. A changed setpoint or silenced quality alarm exposes dialysis patients to contaminated water, or lets Legionella grow in wards where patients are immunocompromised.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Water quality for dialysis and for vulnerable patients is protected by local interlocks and checked by independent testing.", "measures": [ "Interlock dialysis water production locally so out-of-specification water cannot reach the loop, whatever the network says.", "Restrict and log setpoint changes on water controllers, and alarm on any change outside a maintenance window.", "Keep independent sampling and temperature checks on a schedule that does not rely on the control system." ], "prompts": [ "What local interlocks protect dialysis water quality?", "Who can change hot water setpoints remotely?", "How often does independent testing confirm water quality?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "AUTH", "AUDT" ], "standard": [ "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/306.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0838/", "https://attack.mitre.org/techniques/T0880/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-9", "@type": "skos:Concept", "notation": "CRI-FB-9", "prefLabel": "Sterilisation cycle records falsified", "definition": "Washer-disinfectors and autoclaves record cycle parameters to a tracking system that releases instruments. Altered parameters or forged records release unsterile instruments to theatres, or force a recall of every set processed while records cannot be trusted.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Instrument release depends on cycle evidence that cannot be forged and on physical indicators the network cannot change.", "measures": [ "Have sterilisers sign their cycle records and have the tracking system verify them before release.", "Keep chemical and biological indicators as an independent check on every load.", "Restrict cycle parameter changes to authenticated engineers, logged and reviewed by sterile services." ], "prompts": [ "What releases instruments: the record, or physical evidence too?", "Who can change cycle parameters or tracking records?", "How would you recall sets if cycle records could not be trusted?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "AUTH" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/148.html", "https://cwe.mitre.org/data/definitions/353.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/", "https://attack.mitre.org/techniques/T0832/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-8", "@type": "skos:Concept", "notation": "CRI-FB-8", "prefLabel": "Pneumatic tube system stops or misroutes", "definition": "The pneumatic tube system carries samples, blood and drugs between wards, labs and pharmacy, under one networked controller with embedded stations. Stopping or misrouting it delays results across the hospital, and a compromised station is a foothold on the network.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The tube system's controller and stations are hardened, updated and isolated, and the hospital can run without it.", "measures": [ "Put tube controllers and stations in their own segment with only the connections they need.", "Require signed firmware for stations and keep them on supported versions.", "Keep a porter-run courier procedure for urgent samples and blood, and rehearse it." ], "prompts": [ "How would the hospital move samples and drugs without the tube system?", "What can a tube station reach on the network?", "Who patches the tube controller and its stations?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "IGAU", "SAHD" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://cwe.mitre.org/data/definitions/494.html", "https://cwe.mitre.org/data/definitions/306.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0814/", "https://attack.mitre.org/techniques/T0866/", "https://emb3d.mitre.org/threats/TID-211.html" ], "harm": "care", "seenIn": [ { "prefLabel": "PwnedPiper pneumatic tubes, 2021", "source": [ "https://www.theregister.com/2021/08/02/pwnedpiper_swisslog_pts/", "https://health-isac.org/armis-discovers-9-vulnerabilities-in-infrastructure-used-by-80-of-major-hospitals-in-north-america/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-7", "@type": "skos:Concept", "notation": "CRI-FB-7", "prefLabel": "Building management as a pivot", "definition": "Building management servers and controllers are maintained by contractors, often exposed to the internet, and sit on networks that reach clinical systems. Once inside the building network an attacker moves to device and clinical networks the hospital thought were separate.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Building systems are a separate zone with controlled conduits, and their remote access is treated like any other privileged access.", "measures": [ "Separate building systems from clinical and corporate networks, allowing only defined, monitored flows between them.", "Remove internet exposure and route contractor access through the hospital's managed remote access with multi-factor login.", "Include building controllers in the asset inventory and vulnerability management." ], "prompts": [ "What can the building management network reach in the clinical estate?", "How do contractors connect to building systems remotely?", "Is any building controller reachable from the internet?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#I" ], "mds2": [ "CONN", "RMOT" ], "standard": [ "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/700.html", "https://cwe.mitre.org/data/definitions/923.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0883/", "https://attack.mitre.org/techniques/T0866/", "https://attack.mitre.org/techniques/T0822/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-6", "@type": "skos:Concept", "notation": "CRI-FB-6", "prefLabel": "Infant security and door access defeated", "definition": "Infant tagging, maternity door locks and access control share controllers and credentials that can be cloned, overridden or disabled. Defeating them enables abduction, and a mass lock or unlock traps people in or opens secure areas during a fire or incident.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Secure doors fail safe for fire and fail secure for abduction, and their controllers resist cloning and remote override.", "measures": [ "Use access cards that cannot be cloned, and alarm on doors held or forced in maternity and paediatric areas.", "Make fire release hardwired and local, and log any remote lock or unlock command with who issued it.", "Test infant tag alarms and door interlocks on a schedule, including when the network is down." ], "prompts": [ "Can infant tags or door credentials be cloned or overridden remotely?", "What do secure doors do in a fire, and in an abduction alert?", "Who could trigger a mass lock or unlock?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#D" ], "linddun": [ "https://ostering.com/ns/linddun#I" ], "mds2": [ "PLOK", "AUTH", "AUDT" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/395.html", "https://capec.mitre.org/data/definitions/390.html", "https://cwe.mitre.org/data/definitions/1263.html", "https://cwe.mitre.org/data/definitions/294.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-5", "@type": "skos:Concept", "notation": "CRI-FB-5", "prefLabel": "Lift priority for patient transfers lost", "definition": "Lifts that move patients between emergency, theatre and intensive care are run from networked controllers with remote service. Stopping them or removing priority modes delays critical transfers and can trap a patient and team between floors.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Patient-transfer lifts keep their priority and safety functions locally, and remote service cannot take them out of service unannounced.", "measures": [ "Keep firefighter and bed-priority modes under local key control, independent of the network.", "Restrict remote service to read-only by default and log any command that changes lift mode.", "Plan alternative transfer routes and staffing for when priority lifts are out of service." ], "prompts": [ "Can remote service take patient-transfer lifts out of priority mode?", "What happens to a patient and team if a lift stops between floors?", "Who is told before a lift is taken out of service?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "RMOT", "AUTH" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/306.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0816/", "https://attack.mitre.org/techniques/T0858/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-4", "@type": "skos:Concept", "notation": "CRI-FB-4", "prefLabel": "Facilities alarms reach nobody", "definition": "Plant alarms for gases, power, fridges and ventilation are relayed to estates staff by email, SMS or a pager gateway that is unmonitored. When the relay fails, or is overwhelmed by nuisance alarms, a critical alarm sits unread while the plant fails.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Critical facilities alarms reach a person who acknowledges them, and failure of the relay is itself an alarm.", "measures": [ "Require acknowledgement of critical alarms and escalate automatically when none arrives in time.", "Send a heartbeat through the alarm relay and alarm locally when it stops.", "Review alarm volumes monthly and remove nuisance alarms so critical ones stand out." ], "prompts": [ "Who receives critical plant alarms, and must they acknowledge them?", "What tells estates staff that the alarm relay has failed?", "How many nuisance alarms bury the critical ones?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "CONN" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/607.html", "https://cwe.mitre.org/data/definitions/1320.html", "https://cwe.mitre.org/data/definitions/754.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0878/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-3", "@type": "skos:Concept", "notation": "CRI-FB-3", "prefLabel": "Engineering drawings and asset data exposed", "definition": "Drawings of gas, power and ventilation systems, asset registers and controller addresses are shared in tenders, contractor portals and project files. They tell an attacker exactly which controller feeds which theatre or ward.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Engineering information about critical building systems is shared on a need-to-know basis and tracked.", "measures": [ "Classify engineering drawings and asset data, and share them only through controlled portals with named access.", "Remove controller addresses and credentials from tender and handover documents.", "Require contractors to return or destroy engineering information at the end of a project." ], "prompts": [ "Where are drawings of gas, power and ventilation shared?", "Who can see which controller feeds which theatre?", "Is access to engineering information tracked and limited?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "mds2": [ "MPII" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/169.html", "https://capec.mitre.org/data/definitions/406.html", "https://cwe.mitre.org/data/definitions/552.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0882/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/#cri-fb-2", "@type": "skos:Concept", "notation": "CRI-FB-2", "prefLabel": "Energy optimisation darkens clinical areas", "definition": "Energy and lighting optimisation schedules, set centrally or by a vendor platform, apply office logic to clinical areas. A changed schedule switches off lighting, ventilation or heating in a ward, theatre or recovery area overnight.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/facilities-and-building-systems/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical areas are excluded from automated energy schedules unless clinicians have approved the rule.", "measures": [ "Tag clinical zones in the building system and block energy rules from applying to them by default.", "Log and review every schedule change, including those pushed by the vendor platform.", "Give each clinical area a local override that restores lighting and ventilation immediately." ], "prompts": [ "Which clinical areas do automated energy schedules touch?", "Who approves an energy rule that affects a ward or theatre?", "Could a vendor platform change lighting or ventilation overnight?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "AUTH" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/212.html", "https://cwe.mitre.org/data/definitions/1188.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0836/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "@type": "skos:Concept", "notation": "CRI-SV", "prefLabel": "Suppliers, Service and Lifecycle", "definition": "Vendor remote service, service laptops, manufacturer clouds, patching rights, end of support, procurement evidence, refurbished devices, disposal and vendor failure.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-a", "@type": "skos:Concept", "notation": "CRI-SV-A", "prefLabel": "One service password, every hospital", "definition": "A manufacturer uses the same service password, key or certificate on every unit it ships, and its engineers know it. Once it leaks, anyone can reach service functions on that model in every hospital at once, and the hospitals cannot change it.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Service credentials are unique per device, owned by the hospital, and changeable without the vendor.", "measures": [ "Require unique per-device service credentials at procurement, and refuse devices with shared or hard-coded ones.", "Let the hospital rotate service credentials and issue them to engineers for a visit, logged.", "Ask vendors to confirm in writing how service credentials are generated, stored and revoked." ], "prompts": [ "Is any service credential shared across every unit of this model?", "Can the hospital change service credentials without the vendor?", "What would one leaked service password open across your sites?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E" ], "mds2": [ "PAUT", "RMOT", "AUTH" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/70.html", "https://capec.mitre.org/data/definitions/191.html", "https://cwe.mitre.org/data/definitions/798.html", "https://cwe.mitre.org/data/definitions/1273.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/001/", "https://attack.mitre.org/techniques/T1199/", "https://emb3d.mitre.org/threats/TID-328.html", "https://emb3d.mitre.org/threats/TID-311.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-k", "@type": "skos:Concept", "notation": "CRI-SV-K", "prefLabel": "Always-on vendor remote service", "definition": "Vendors keep permanent tunnels, modems or remote-access tools into their devices for service, outside the hospital's control. Compromise of the vendor, or of one technician, opens a path into many hospitals' device networks at once.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Vendor remote access is brokered, approved per session, recorded, and closed when the work ends.", "measures": [ "Route all vendor access through the hospital's managed access service with multi-factor login and per-session approval.", "Remove cellular modems and vendor-installed remote tools that bypass the hospital's controls.", "Record sessions and review them against the service ticket." ], "prompts": [ "Which vendors hold permanent remote access into devices?", "Who approves each remote service session, and is it recorded?", "How would you know a vendor tunnel had been misused?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E" ], "mds2": [ "RMOT", "AUDT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/555.html", "https://cwe.mitre.org/data/definitions/923.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1133/", "https://attack.mitre.org/techniques/T1199/", "https://attack.mitre.org/techniques/T1219/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-q", "@type": "skos:Concept", "notation": "CRI-SV-Q", "prefLabel": "Care depends on the vendor's cloud", "definition": "Treatment planning, device configuration, remote follow-up or reporting run in the manufacturer's cloud. A ransomware attack or outage there stops care at every customer at once, and hospitals have no local fallback.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinically essential functions keep working, at least in a degraded mode, when the vendor's cloud is unavailable.", "measures": [ "Identify which clinical functions need the vendor cloud and require a documented local fallback for each.", "Keep local copies of plans, configurations and data needed to treat current patients.", "Include the vendor's incident notification and recovery commitments in the contract and exercise them." ], "prompts": [ "Which clinical functions stop if the vendor's cloud is down?", "What degraded mode keeps care running locally?", "When was a vendor cloud outage last rehearsed?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "RDMP" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1489/" ], "harm": "care", "seenIn": [ { "prefLabel": "Elekta cloud outage, 2021", "source": [ "https://compliancy-group.com/healthcare-vendor-ransomware-attack-170-health-systems-hit/", "https://yaledailynews.com/blog/2021/04/27/ynhhs-pauses-radiotherapy-treatment-for-six-days-after-software-breach" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-j", "@type": "skos:Concept", "notation": "CRI-SV-J", "prefLabel": "End of support with no exit", "definition": "Devices run operating systems and components the manufacturer no longer supports, and replacement is unaffordable or years away. Known vulnerabilities stay open in clinical use, and one worm can take out imaging, lab and monitoring together.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every device has a planned end of support, and devices past it are isolated and scheduled for replacement.", "measures": [ "Record end-of-support dates for each device and its third-party components at purchase.", "Isolate unsupported devices in restricted segments with only the flows they need.", "Budget replacement cycles from end-of-support dates, and report the unsupported estate to the board." ], "prompts": [ "Which devices are past their manufacturer's end of support?", "How are unsupported devices isolated until replacement?", "When is each unsupported device due to be replaced?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "RDMP", "SAHD" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/310.html", "https://cwe.mitre.org/data/definitions/1104.html", "https://cwe.mitre.org/data/definitions/1329.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1210/", "https://emb3d.mitre.org/threats/TID-210.html" ], "harm": "care", "seenIn": [ { "prefLabel": "WannaCry and the NHS, 2017", "source": [ "https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/", "https://www.gov.uk/government/news/foreign-office-minister-condemns-north-korean-actor-for-wannacry-attacks" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-10", "@type": "skos:Concept", "notation": "CRI-SV-10", "prefLabel": "Only the vendor may patch", "definition": "Hospitals are not allowed to patch validated devices, and manufacturers take months to validate updates, often without saying what to do meanwhile. Known exploited vulnerabilities stay open, and staff patch anyway and break the device's validated state.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Manufacturers commit to timelines for validated updates and give interim mitigations the hospital can apply safely.", "measures": [ "Contract for maximum times to validated security updates and for interim compensating controls.", "Ask for a list of operating system patches the hospital may apply without revalidation.", "Track each open vulnerability on clinical devices with its mitigation and review date." ], "prompts": [ "What timeline has the vendor committed to for validated updates?", "Which interim mitigations can the hospital apply safely?", "What happens when staff patch a validated device themselves?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "CSUP", "SGUD" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1329.html", "https://cwe.mitre.org/data/definitions/671.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1210/", "https://emb3d.mitre.org/threats/TID-210.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-9", "@type": "skos:Concept", "notation": "CRI-SV-9", "prefLabel": "Service laptops carry infection between hospitals", "definition": "Field engineers plug their laptops and USB drives into devices at hospital after hospital, using service software with full control. Malware or a tampered tool spreads from one site to the next and onto devices the hospital's protections never see.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Service tools and media are treated as transient assets: checked, controlled and recorded before they touch a device.", "measures": [ "Scan engineers' laptops and media at a kiosk before connection, and record the asset used.", "Offer hospital-owned service workstations for vendors where devices allow it.", "Require vendors to describe how service laptops are managed, patched and protected." ], "prompts": [ "How are service laptops and USB drives checked before touching a device?", "Who records which tools were used on which device?", "Could malware travel on an engineer's kit from another hospital?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "MLDP", "RMOT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/457.html", "https://cwe.mitre.org/data/definitions/829.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1091/", "https://attack.mitre.org/techniques/T0864/", "https://emb3d.mitre.org/threats/TID-303.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-8", "@type": "skos:Concept", "notation": "CRI-SV-8", "prefLabel": "Update channel delivers malicious updates", "definition": "Device and software updates arrive from the vendor's portal, a service engineer or a distribution server, and devices accept what they are given. A compromised vendor or update server pushes tampered firmware or software across the installed base.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Devices accept only updates signed by the manufacturer and verify them themselves, whatever the delivery route.", "measures": [ "Require signed updates verified on the device, with rollback protection.", "Verify update packages against published hashes before staging them in the hospital.", "Stage updates on a sample of devices and watch for unexpected behaviour before wider rollout." ], "prompts": [ "Does each device verify updates itself, whatever the delivery route?", "Which servers and people can deliver updates to devices?", "How many devices would one tampered update reach?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "IGAU", "CSUP" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://capec.mitre.org/data/definitions/669.html", "https://cwe.mitre.org/data/definitions/494.html", "https://cwe.mitre.org/data/definitions/347.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1195/002/", "https://emb3d.mitre.org/threats/TID-211.html", "https://emb3d.mitre.org/threats/TID-213.html", "https://emb3d.mitre.org/threats/TID-216.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-7", "@type": "skos:Concept", "notation": "CRI-SV-7", "prefLabel": "Bought without security evidence", "definition": "Devices and clinical systems are bought on clinical and price criteria alone, without a security disclosure, SBOM, support period or vulnerability handling commitment. Once installed, the weaknesses cannot be bought back.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Security evidence and lifecycle commitments are procurement criteria with the same weight as clinical ones.", "measures": [ "Require an MDS2, an SBOM, a support end date and a disclosure process in every tender.", "Include clinical engineering and security in evaluation, with the power to fail a bid.", "Write security update and notification obligations into the contract." ], "prompts": [ "Is security evidence scored alongside clinical criteria at purchase?", "Did the supplier commit to a support period and vulnerability handling?", "Which installed systems were bought without an SBOM?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#D" ], "mds2": [ "SBOM", "RDMP", "SGUD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-6", "@type": "skos:Concept", "notation": "CRI-SV-6", "prefLabel": "Refurbished and grey-market devices", "definition": "Refurbished, loaned and grey-market devices arrive with unknown firmware, counterfeit parts, another hospital's configuration and sometimes its patients' data. They can behave unpredictably and carry weaknesses or implants nobody checked for.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every device entering service is restored to a known configuration and its origin and firmware are verified.", "measures": [ "Buy refurbished devices only through manufacturer-authorised channels with documented provenance.", "Reset devices to factory configuration and verify firmware versions and hashes before clinical use.", "Check incoming devices for previous owners' data and network credentials, and remove them." ], "prompts": [ "How is a refurbished or loaned device restored to a known state?", "Who verifies a second-hand device's origin and firmware?", "Could a device arrive holding another hospital's patients or settings?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "IGAU", "MPII" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/535.html", "https://capec.mitre.org/data/definitions/530.html", "https://cwe.mitre.org/data/definitions/1357.html", "https://cwe.mitre.org/data/definitions/226.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1195/003/", "https://emb3d.mitre.org/threats/TID-113.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-5", "@type": "skos:Concept", "notation": "CRI-SV-5", "prefLabel": "Disposed devices leak patients and passwords", "definition": "Devices returned to the vendor, sold or scrapped still hold patient data, network keys and service credentials. Anyone who buys them on the second-hand market can read the data and use the keys to get onto the hospital's network.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every device leaving the hospital is sanitised to a recorded standard, and credentials it held are rotated.", "measures": [ "Wipe or destroy storage in every departing device using a method the manufacturer confirms, and keep a certificate.", "Rotate Wi-Fi keys, certificates and accounts the device held when it leaves service.", "Require vendors taking devices back to sanitise them and confirm it in writing." ], "prompts": [ "What standard is used to sanitise devices before they leave?", "Which credentials does a disposed device hold that need rotating?", "Who records that sanitisation actually happened?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#I" ], "mds2": [ "MPII", "STCF", "DIDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/675.html", "https://cwe.mitre.org/data/definitions/1266.html", "https://cwe.mitre.org/data/definitions/226.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1052/", "https://emb3d.mitre.org/threats/TID-108.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-4", "@type": "skos:Concept", "notation": "CRI-SV-4", "prefLabel": "Vendor collapses or changes hands", "definition": "A manufacturer goes bust, withdraws a product or is acquired, and support, cloud services, signing keys and spare parts go with it. Hospitals and patients are left with devices nobody can update, service or safely replace.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Hospitals plan for losing a supplier and contract for what happens to support, keys and data if they do.", "measures": [ "Contract for escrow of documentation, service tools and update capability if the vendor exits the market.", "Identify single-supplier devices and plan alternatives before they are needed.", "Require notice of product withdrawal and a support period after it." ], "prompts": [ "What happens to support, keys and spares if the vendor fails?", "Does the contract cover a change of ownership?", "Which devices depend on one vendor's continued existence?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "RDMP" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1329.html" ], "harm": "care", "seenIn": [ { "prefLabel": "Argus II retinal implant, 2020", "source": [ "https://spectrum.ieee.org/bionic-eye-obsolete" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-3", "@type": "skos:Concept", "notation": "CRI-SV-3", "prefLabel": "No SBOM, no answer", "definition": "When a vulnerability is announced in a common component, the hospital cannot tell which of its devices contain it, and the vendor takes weeks to say. Exposure is unknown while attackers already know where to look.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Hospitals hold current component lists for their devices and can match a new vulnerability to devices in hours.", "measures": [ "Require machine-readable SBOMs at purchase and with every update.", "Load SBOMs into the asset inventory and match them automatically against new vulnerability notices.", "Ask vendors for exploitability statements so effort goes where it matters." ], "prompts": [ "Can you match a new component vulnerability to your devices in hours?", "Which devices have no current component list?", "How quickly do vendors answer exposure questions?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "mds2": [ "SBOM", "RDMP" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1395.html", "https://cwe.mitre.org/data/definitions/1104.html" ], "relatedMatch": [ "https://emb3d.mitre.org/threats/TID-202.html" ], "seenIn": [ { "prefLabel": "URGENT/11, 2019", "source": [ "https://healthcareitnews.com/node/544606" ] }, { "prefLabel": "SweynTooth Bluetooth flaws, 2020", "source": [ "https://www.raps.org/resource/fda-warns-of-cybersecurity-vulnerabilities-in-pace.html", "https://www.hpnonline.com/healthcare-it/article/21128449/fda-informs-about-potential-cybersecurity-vulnerabilities-in-certain-medical-devices-with-bluetooth-low-energy" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/#cri-sv-2", "@type": "skos:Concept", "notation": "CRI-SV-2", "prefLabel": "Advisories never reach the ward", "definition": "Manufacturers' security notices go to a sales or procurement contact, not to clinical engineering, and hospitals have no published way to report problems. Fixes and warnings sit in an inbox while vulnerable devices stay in use.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/suppliers-service-and-lifecycle/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Security advisories have a named destination on both sides, and the hospital can report problems to the vendor.", "measures": [ "Register a monitored security contact with every device vendor and keep it current.", "Require vendors to run a coordinated vulnerability disclosure process and say how they notify customers.", "Route advisories to clinical engineering and track each to closure." ], "prompts": [ "Who at the hospital receives manufacturers' security advisories?", "How does the hospital report a problem to a vendor?", "How long does an advisory take to reach clinical engineering?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "mds2": [ "SGUD", "CSUP" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "@type": "skos:Concept", "notation": "CRI-AC", "prefLabel": "Identity and Access", "definition": "Clinician identities, default and hard-coded credentials, shared directories, shared logins, break-glass, session handover, privileged and temporary accounts, badges.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-a", "@type": "skos:Concept", "notation": "CRI-AC-A", "prefLabel": "Stolen clinician identity prescribes and signs", "definition": "A clinician's account can prescribe, sign results, discharge patients and change care plans from any workstation or remote session, with no stronger check for high-risk actions. A phished or reused password lets an attacker order, cancel or approve care under a trusted name.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "High-risk clinical actions need stronger proof of who is acting than reading a record does.", "measures": [ "Require step-up authentication, such as a smartcard tap or a second factor, for prescribing, signing results and changing allergies.", "Bind remote and off-site clinical sessions to managed devices and phishing-resistant authentication.", "Alert the clinician and their lead when orders are placed under their name from an unusual place or time." ], "prompts": [ "Which clinical actions need stronger proof than reading a record?", "How are remote clinical sessions authenticated?", "Who is told when orders appear under a clinician's name unusually?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#R" ], "mds2": [ "PAUT", "AUTH", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/560.html", "https://capec.mitre.org/data/definitions/98.html", "https://cwe.mitre.org/data/definitions/308.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/", "https://attack.mitre.org/techniques/T1566/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-k", "@type": "skos:Concept", "notation": "CRI-AC-K", "prefLabel": "Default and hard-coded device credentials", "definition": "Devices ship with default administrator passwords that nobody changes, or with credentials compiled into the firmware that cannot be changed. Anyone on the clinical network can log in and change settings, alarm limits or therapy, and the hospital has no way to close the door short of replacing the device.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "No device should be reachable with a credential the hospital did not set and cannot change.", "measures": [ "Force a unique credential to be set at installation before the device will run clinically.", "Remove hard-coded accounts; where an account must exist, make it changeable and disable it by default.", "Ask for default and hard-coded credentials in procurement (MDS2) and reject devices that cannot answer." ], "prompts": [ "Which devices still use default or hard-coded credentials?", "Can the hospital set and change every device credential?", "What could someone on the clinical network change with a default password?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#E" ], "mds2": [ "PAUT", "SAHD", "AUTH" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/70.html", "https://capec.mitre.org/data/definitions/115.html", "https://cwe.mitre.org/data/definitions/1393.html", "https://cwe.mitre.org/data/definitions/259.html", "https://cwe.mitre.org/data/definitions/798.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/001/", "https://attack.mitre.org/techniques/T0859/", "https://emb3d.mitre.org/threats/TID-311.html", "https://emb3d.mitre.org/threats/TID-328.html" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-q", "@type": "skos:Concept", "notation": "CRI-AC-Q", "prefLabel": "One directory for IT and devices", "definition": "Modality workstations, monitoring servers, lab middleware and pharmacy systems all join the same directory as office PCs. One stolen administrator account or one domain compromise reaches every clinical system at once, and ransomware spreads to the devices along with the desktops.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A compromise of the corporate identity system must not hand over the clinical device estate.", "measures": [ "Run clinical device systems in a separate identity domain with no trust from the corporate directory.", "Use separate administrator accounts and workstations for the device estate, never reused for email or browsing.", "Test that a fully compromised corporate domain cannot log in to any device or clinical server." ], "prompts": [ "Which clinical systems join the same directory as office PCs?", "What would one stolen domain administrator account reach?", "Could clinical devices keep running if the directory were lost?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#D" ], "mds2": [ "AUTH", "SAHD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/560.html", "https://capec.mitre.org/data/definitions/652.html", "https://capec.mitre.org/data/definitions/509.html", "https://cwe.mitre.org/data/definitions/266.html", "https://cwe.mitre.org/data/definitions/1220.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/002/", "https://attack.mitre.org/techniques/T1021/002/", "https://attack.mitre.org/techniques/T1486/" ], "harm": "care", "seenIn": [ { "prefLabel": "WannaCry and the NHS, 2017", "source": [ "https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/", "https://www.gov.uk/government/news/foreign-office-minister-condemns-north-korean-actor-for-wannacry-attacks" ] }, { "prefLabel": "Conti attack on Ireland's HSE, 2021", "source": [ "https://www.hse.ie/eng/services/publications/conti-cyber-attack-on-the-hse-full-report.pdf", "https://www.hhs.gov/sites/default/files/lessons-learned-hse-attack.pdf" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-j", "@type": "skos:Concept", "notation": "CRI-AC-J", "prefLabel": "Devices without their own identity", "definition": "Systems accept vital signs, results or images from anything on the network that speaks the right protocol. A rogue or spoofed node can pose as a monitor, analyser or modality and write false values into the record, which clinicians then act on.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every device that writes clinical data proves which device it is, and the receiver refuses data from unknown sources.", "measures": [ "Give each device a certificate or key at installation and require mutual authentication to gateways and interfaces.", "Keep a register of devices allowed to send to each interface and reject the rest.", "Alert clinical engineering when a new or unexpected source appears on a clinical feed." ], "prompts": [ "How does a receiving system know which device sent the data?", "What happens to data from an unknown or spoofed node?", "Could a rogue device pose as a monitor or analyser?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#T" ], "mds2": [ "NAUT", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/151.html", "https://capec.mitre.org/data/definitions/194.html", "https://cwe.mitre.org/data/definitions/306.html", "https://cwe.mitre.org/data/definitions/924.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/002/", "https://emb3d.mitre.org/threats/TID-406.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-10", "@type": "skos:Concept", "notation": "CRI-AC-10", "prefLabel": "Help-desk resets for urgent callers", "definition": "The service desk resets passwords and multi-factor enrolment for anyone who sounds like a busy consultant with a patient waiting. An attacker who knows names and rotas from public pages gets a clinician's or administrator's access in one phone call.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Urgency must never replace identity proofing for credential resets, and resets must be harder for privileged accounts.", "measures": [ "Verify callers through a second channel or in person before any reset, with a fast route for genuine emergencies.", "Require a manager or second approver for resets of privileged and remote-access accounts.", "Notify the account owner on every reset and enrolment change, through a channel the caller does not control." ], "prompts": [ "How does the service desk prove a caller's identity?", "Are privileged resets harder than ordinary ones?", "What public information would help an attacker sound convincing?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E" ], "mds2": [ "PAUT", "AUTH" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/407.html", "https://capec.mitre.org/data/definitions/416.html", "https://cwe.mitre.org/data/definitions/640.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1566/004/", "https://attack.mitre.org/techniques/T1098/005/", "https://attack.mitre.org/techniques/T1078/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-9", "@type": "skos:Concept", "notation": "CRI-AC-9", "prefLabel": "Break-glass becomes the normal route", "definition": "Emergency access to records and devices is so easy, or normal access so slow, that staff use break-glass every shift. Nobody reviews it, so snooping on records and unattributed changes hide in the noise, and the control meant for emergencies stops meaning anything.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Emergency access is quick in an emergency, rare in practice and reviewed every time it is used.", "measures": [ "Fix the routine access problems that drive break-glass use before adding more controls.", "Ask for a reason at break-glass and send every use to a reviewer within a day.", "Report break-glass rates by ward and role so routine use is visible and challenged." ], "prompts": [ "How often is break-glass used, and why so often?", "Who reviews each break-glass use, and how quickly?", "Is normal access slow enough to push staff to emergency access?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#R", "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#Nr", "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "EMRG", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002", "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/122.html", "https://cwe.mitre.org/data/definitions/778.html", "https://cwe.mitre.org/data/definitions/863.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-8", "@type": "skos:Concept", "notation": "CRI-AC-8", "prefLabel": "Generic and shared clinical logins", "definition": "Wards share generic accounts on workstations, devices and departmental systems because individual logins are too slow. Orders, results, settings and record views cannot be tied to a person, so mistakes and misuse go uninvestigated and leavers keep access through the shared password.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every clinical action is attributable to a person, without making shared devices slower to use.", "measures": [ "Replace generic accounts with fast individual sign-on, such as badge tap with a short PIN.", "Where a device must run under a shared account, record who is signed in to the session alongside it.", "Change shared passwords whenever a holder leaves and audit for generic account use on clinical systems." ], "prompts": [ "Which wards or devices still rely on generic accounts?", "Can every order and setting change be tied to a person?", "What would make individual login as fast as the shared one?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#Nr" ], "mds2": [ "PAUT", "AUDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/21.html", "https://cwe.mitre.org/data/definitions/286.html", "https://cwe.mitre.org/data/definitions/1220.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/003/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-7", "@type": "skos:Concept", "notation": "CRI-AC-7", "prefLabel": "Session handed to the next user", "definition": "Shared workstations on wheels and bedside terminals stay signed in as the last person. The next clinician prescribes, records or views under someone else's name, sometimes on the wrong patient's open record, and the record shows the wrong author for clinical decisions.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A shared screen always shows who is signed in and which patient is open, and switches user quickly and safely.", "measures": [ "Use fast user switching that closes the previous user's patient context.", "Show the signed-in user and patient prominently on every clinical screen.", "Lock idle sessions on a timeout suited to the area, shorter in public areas than in theatres." ], "prompts": [ "Does the shared screen always show who is signed in?", "How quickly can the next clinician switch user?", "Could someone prescribe on the wrong patient's open record?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#R" ], "linddun": [ "https://ostering.com/ns/linddun#Nr" ], "mds2": [ "ALOF", "PAUT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/593.html", "https://capec.mitre.org/data/definitions/60.html", "https://cwe.mitre.org/data/definitions/1463.html", "https://cwe.mitre.org/data/definitions/1464.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-6", "@type": "skos:Concept", "notation": "CRI-AC-6", "prefLabel": "Standing privilege for biomed and IT", "definition": "Clinical engineering and IT staff hold permanent administrator rights to every device console, monitoring server and integration engine. One phished or reused account gives an attacker the power to change any device or interface in the hospital, with nothing to approve or notice.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Privilege over clinical systems is granted for a task, for a time, and is seen by someone else.", "measures": [ "Grant device and integration admin rights just in time, with approval and expiry.", "Use phishing-resistant authentication for every privileged clinical account.", "Alert on privileged changes to device settings, alarm limits and interface routes outside change windows." ], "prompts": [ "Which biomed and IT accounts hold standing administrator rights?", "Is privilege granted for a task and seen by someone else?", "What could one phished engineer account change?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#E", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUTH", "AUDT", "PAUT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC 62443 Security for industrial automation and control systems" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/122.html", "https://capec.mitre.org/data/definitions/233.html", "https://cwe.mitre.org/data/definitions/250.html", "https://cwe.mitre.org/data/definitions/266.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/", "https://attack.mitre.org/techniques/T1098/007/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-5", "@type": "skos:Concept", "notation": "CRI-AC-5", "prefLabel": "Agency, locum and leaver accounts", "definition": "Agency nurses, locum doctors, students and contractors get accounts in a hurry and nobody removes them. Accounts outlive the people, are shared between shifts or reach remote access, giving former staff and anyone who buys their password a way into records and systems.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every account has an owner, an end date and a sponsor who answers for it.", "measures": [ "Give temporary staff accounts an end date at creation and require a sponsor to extend them.", "Feed starters and leavers from rostering and HR into account removal automatically.", "Review dormant and remote-capable accounts monthly and disable those unused for a set period." ], "prompts": [ "Who sponsors each agency, locum and contractor account?", "Does every temporary account have an end date?", "How quickly is access removed when someone leaves?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E" ], "linddun": [ "https://ostering.com/ns/linddun#I" ], "mds2": [ "AUTH", "PAUT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/560.html", "https://cwe.mitre.org/data/definitions/286.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/", "https://attack.mitre.org/techniques/T1133/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-4", "@type": "skos:Concept", "notation": "CRI-AC-4", "prefLabel": "Authentication friction drives workarounds", "definition": "Logins and multi-factor prompts that take too long in a resuscitation or theatre push staff to write passwords on monitors, share tokens, prop sessions open or disable locks. The workaround becomes the real control, and both security and care suffer.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Authentication is designed around clinical workflow, measured in seconds, and tested with clinicians.", "measures": [ "Time sign-in and switch-user on real wards and set a target in seconds.", "Use proximity or badge tap with risk-based step-up rather than repeated full logins.", "Watch for workarounds such as written passwords and fix the cause, not the person." ], "prompts": [ "How many seconds does login take in resuscitation or theatre?", "Which workarounds do staff use when authentication is slow?", "Were clinicians involved in testing the authentication design?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#S", "https://ostering.com/ns/stride#E" ], "mds2": [ "PAUT", "EMRG" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/416.html", "https://cwe.mitre.org/data/definitions/655.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-3", "@type": "skos:Concept", "notation": "CRI-AC-3", "prefLabel": "Credentials in service files", "definition": "Passwords, keys and interface credentials sit in plain text in device configuration backups, export files, service reports and installation notes. Whoever gets a copy, from a shared drive, an old laptop or a disposed device, gets the keys to the clinical systems they describe.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Secrets never appear in configuration exports, logs or documents that leave the device.", "measures": [ "Store device and interface secrets in a protected store and redact them from exports and service reports.", "Scan shared drives and ticket systems for clinical system credentials and rotate any found.", "Wipe credentials when devices are decommissioned, returned or sent for repair." ], "prompts": [ "Where do configuration backups and service reports keep credentials?", "Who can read exported device files on shared drives?", "Are secrets removed before files leave the device?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I", "https://ostering.com/ns/stride#E" ], "mds2": [ "STCF", "SAHD" ], "standard": [ "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/406.html", "https://cwe.mitre.org/data/definitions/256.html", "https://cwe.mitre.org/data/definitions/522.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1552/001/", "https://emb3d.mitre.org/threats/TID-329.html", "https://emb3d.mitre.org/threats/TID-226.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/#cri-ac-2", "@type": "skos:Concept", "notation": "CRI-AC-2", "prefLabel": "Badges cloned, shared and left in", "definition": "Proximity badges and smartcards give access to doors, drug rooms and clinical systems. Cards that are easy to clone, left in readers or lent to colleagues let someone else walk into restricted areas or act as the card holder on clinical systems.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/identity-and-access/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A badge proves who is present only when it is hard to copy and backed by a second factor where it matters.", "measures": [ "Use badges with cryptographic authentication rather than readable serial numbers.", "Require a PIN or biometric with the badge for controlled drugs, prescribing and restricted areas.", "Remove the session automatically when the card leaves the reader." ], "prompts": [ "How easily can your badges be cloned?", "Where is a second factor needed beyond the badge?", "What happens when a badge is left in a reader?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#S" ], "linddun": [ "https://ostering.com/ns/linddun#I" ], "mds2": [ "PAUT", "PLOK" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/390.html", "https://cwe.mitre.org/data/definitions/654.html", "https://cwe.mitre.org/data/definitions/308.html" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "@type": "skos:Concept", "notation": "CRI-CD", "prefLabel": "Continuity and Downtime", "definition": "Estate-wide ransomware, shared services, backups, restore validation, downtime procedures and copies, diversion, incident communications and extortion.", "deck": "The Hospital", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-a", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-k", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-q", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-j", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-10", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-2" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-a", "@type": "skos:Concept", "notation": "CRI-CD-A", "prefLabel": "Ransomware takes the whole estate", "definition": "Clinical and corporate systems share networks, accounts and management tools, so ransomware reaches records, imaging, labs, pharmacy and device servers at once. The hospital loses sight of its patients, diverts ambulances and cancels care for weeks while everything is rebuilt.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Design so that losing the corporate estate leaves a core of clinical care running.", "measures": [ "Segment clinical systems and devices so that a compromise of office IT cannot encrypt them.", "Define the minimum clinical service that must survive and engineer its systems to run in isolation.", "Rehearse an estate-wide outage with clinicians, not only IT, at least yearly." ], "prompts": [ "Which clinical services would keep running if the corporate estate fell?", "What do clinical and corporate systems share: accounts, tools, networks?", "How long would rebuilding the core clinical services take?" ], "deck": "The Hospital", "rank": "A", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "MLDP", "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/441.html", "https://cwe.mitre.org/data/definitions/1220.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1486/", "https://attack.mitre.org/techniques/T1489/", "https://attack.mitre.org/techniques/T1490/" ], "harm": "care", "seenIn": [ { "prefLabel": "WannaCry and the NHS, 2017", "source": [ "https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/", "https://www.gov.uk/government/news/foreign-office-minister-condemns-north-korean-actor-for-wannacry-attacks" ] }, { "prefLabel": "Conti attack on Ireland's HSE, 2021", "source": [ "https://www.hse.ie/eng/services/publications/conti-cyber-attack-on-the-hse-full-report.pdf", "https://www.hhs.gov/sites/default/files/lessons-learned-hse-attack.pdf" ] }, { "prefLabel": "Ascension, 2024", "source": [ "https://www.bleepingcomputer.com/news/security/ascension-health-data-of-56-million-stolen-in-ransomware-attack/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-k", "@type": "skos:Concept", "notation": "CRI-CD-K", "prefLabel": "A shared service stops many hospitals", "definition": "Pathology, imaging, radiotherapy planning or IT is provided by one company or one hub for many hospitals. When it is attacked, every hospital it serves loses that service together, with no local fallback, and operations, transfusions and cancer treatment stop across a region.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "No single supplier or hub should be able to stop a clinical service across a region without a tested fallback.", "measures": [ "Map which clinical services depend on a shared provider and what each hospital does without it.", "Contract for and test fallback capacity, such as mutual aid between laboratories or a second planning system.", "Require shared providers to show segregation between customers so one attack does not stop all of them." ], "prompts": [ "Which clinical services come from one supplier shared by many hospitals?", "What local fallback exists if that supplier is attacked?", "Who coordinates across the region when a shared service fails?" ], "deck": "The Hospital", "rank": "K", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1199/", "https://attack.mitre.org/techniques/T1486/" ], "harm": "care", "seenIn": [ { "prefLabel": "Synnovis pathology attack, London, 2024", "source": [ "https://www.theregister.com/2025/06/26/qilin_ransomware_nhs_death/", "https://www.digitalhealth.net/2025/06/patient-dies-as-a-result-of-cyber-attack-on-nhs-pathology-provider/" ] }, { "prefLabel": "Elekta cloud outage, 2021", "source": [ "https://compliancy-group.com/healthcare-vendor-ransomware-attack-170-health-systems-hit/", "https://yaledailynews.com/blog/2021/04/27/ynhhs-pauses-radiotherapy-treatment-for-six-days-after-software-breach" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-q", "@type": "skos:Concept", "notation": "CRI-CD-Q", "prefLabel": "Backups reachable from what they protect", "definition": "Backups of records, images and device configurations are online, writable and run by the same accounts as production. Attackers find and destroy them before encrypting, so restoring takes weeks of rebuilding rather than days of recovery.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "At least one copy of every clinical system's data and configuration survives a full compromise of the estate.", "measures": [ "Keep immutable or offline copies managed by separate credentials that the main directory cannot reach.", "Back up device configurations, drug libraries and interface definitions, not only databases.", "Test full restores of clinical systems on a schedule and time them." ], "prompts": [ "Which backups would survive a full compromise of the estate?", "Do backups use the same accounts as production?", "How long would a restore from the offline copy take?" ], "deck": "The Hospital", "rank": "Q", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/607.html", "https://cwe.mitre.org/data/definitions/732.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1490/", "https://attack.mitre.org/techniques/T1485/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-j", "@type": "skos:Concept", "notation": "CRI-CD-J", "prefLabel": "Restored data nobody has checked", "definition": "After an outage, systems are restored from backups and paper records are typed back in, but nobody checks that results, orders, allergies and medication histories are complete and unaltered. Missing or tampered clinical data flows back into care looking trustworthy.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Recovered clinical data is verified as complete and unaltered before clinicians rely on it.", "measures": [ "Hash and sign clinical data at backup so restored records can be checked for tampering.", "Reconcile results, orders and medication given during downtime against the restored record, with clinical sign-off.", "Flag records touched during the outage window so clinicians know to double-check them." ], "prompts": [ "How do you check that restored clinical data is complete?", "Who verifies records typed back in from paper?", "Could tampered data return with the restore unnoticed?" ], "deck": "The Hospital", "rank": "J", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "IGAU", "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/184.html", "https://cwe.mitre.org/data/definitions/354.html", "https://cwe.mitre.org/data/definitions/353.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1565/001/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-10", "@type": "skos:Concept", "notation": "CRI-CD-10", "prefLabel": "Downtime procedures nobody has practised", "definition": "Paper forms, manual ordering, handwritten labels and runners exist on paper but have never been tried at scale. When systems go down for weeks, staff improvise, errors multiply in prescribing, identification and results, and staff exhaust themselves keeping it running.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Manual working is a planned, practised and staffed mode of the hospital, not an improvisation.", "measures": [ "Keep downtime packs on every ward with forms, label stock and contact lists, checked monthly.", "Run downtime drills that include pharmacy, labs, imaging and portering, and record what failed.", "Plan rotas and extra staff for long outages so manual working is sustainable for weeks." ], "prompts": [ "When were downtime procedures last practised at scale?", "Who staffs runners, manual ordering and paper reconciliation?", "How long could manual working last before errors climb?" ], "deck": "The Hospital", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0826/" ], "harm": "care", "seenIn": [ { "prefLabel": "Synnovis pathology attack, London, 2024", "source": [ "https://www.theregister.com/2025/06/26/qilin_ransomware_nhs_death/", "https://www.digitalhealth.net/2025/06/patient-dies-as-a-result-of-cyber-attack-on-nhs-pathology-provider/" ] }, { "prefLabel": "Ascension, 2024", "source": [ "https://www.bleepingcomputer.com/news/security/ascension-health-data-of-56-million-stolen-in-ransomware-attack/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-9", "@type": "skos:Concept", "notation": "CRI-CD-9", "prefLabel": "Devices that stop without their server", "definition": "Devices need a licence server, drug library server, worklist or vendor cloud to start or keep working. When the back end is encrypted or cut off, pumps, modalities and analysers refuse to run or lock into unsafe defaults, though they could work alone.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "A device that can treat or diagnose safely on its own keeps doing so when its back end is gone.", "measures": [ "Require devices to keep working in a safe local mode, with their last good configuration, when servers are lost.", "Ask suppliers about back-end dependencies and grace periods in procurement and test them before go-live.", "Document how to run each critical device without its network, and practise it." ], "prompts": [ "Which devices refuse to start without their server or licence?", "What defaults do devices fall back to when the back end is gone?", "Could these devices treat or diagnose safely on their own?" ], "deck": "The Hospital", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "CONN" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/754.html", "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0826/", "https://attack.mitre.org/techniques/T0816/" ], "harm": "direct" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-8", "@type": "skos:Concept", "notation": "CRI-CD-8", "prefLabel": "Diversion overloads the neighbours", "definition": "A hospital that loses its systems diverts ambulances and transfers to nearby hospitals, which are already busy. Travel times rise for critically ill patients and the neighbours run short of beds and staff, so one attack degrades emergency care across a region.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Regional plans assume a hospital can be lost to a cyberattack and share the load before it lands.", "measures": [ "Agree cyber diversion triggers and capacity with neighbouring hospitals and ambulance services in advance.", "Keep a way to update diversion status that does not depend on the affected hospital's systems.", "Plan which time-critical services, such as stroke and cardiac care, must stay open and how." ], "prompts": [ "Which neighbouring hospitals absorb your patients if you divert?", "Do regional plans assume a hospital lost to a cyberattack?", "How is the extra load shared before it lands?" ], "deck": "The Hospital", "rank": "8", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0826/" ], "harm": "care", "seenIn": [ { "prefLabel": "University Hospital Düsseldorf, 2020", "source": [ "https://www.technologyreview.com/2020/09/18/1008582/a-patient-has-died-after-ransomware-hackers-hit-a-german-hospital", "https://borncity.com/win/2020/11/18/ransomware-befall-in-uniklinik-dsseldorf-nicht-fr-todesfall-verantwortlich/" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-7", "@type": "skos:Concept", "notation": "CRI-CD-7", "prefLabel": "One update takes the estate down", "definition": "A trusted security agent, operating system or management tool pushes a faulty or malicious update to every machine at once. Clinical workstations, servers and device consoles fail together, and the hospital cannot recover them faster than it can visit each one.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Updates reach critical clinical systems in stages, with a way to stop and roll back before all are affected.", "measures": [ "Stage updates to clinical systems in rings, holding critical areas back until earlier rings are healthy.", "Keep a tested way to recover machines in bulk without the failed tool, such as rebuild images on local media.", "Hold a minimum set of devices on a different platform or update channel for continuity." ], "prompts": [ "Which tools can push an update to every machine at once?", "Are updates staged so critical systems can be held back?", "How quickly could you stop and roll back a bad update?" ], "deck": "The Hospital", "rank": "7", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#T" ], "mds2": [ "CSUP", "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/186.html", "https://cwe.mitre.org/data/definitions/494.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1195/002/", "https://emb3d.mitre.org/threats/TID-217.html" ], "harm": "care", "seenIn": [ { "prefLabel": "CrowdStrike update outage, 2024", "source": [ "https://www.statnews.com/2024/07/19/microsoft-crowdstrike-outage-hospitals-cancellations/", "https://www.wbur.org/news/2024/07/19/boston-tech-outage-logan-mbg-microsoft" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-6", "@type": "skos:Concept", "notation": "CRI-CD-6", "prefLabel": "Downtime copies that go down too", "definition": "Read-only downtime viewers, medication lists and printed reports depend on the same network, directory or storage as the main record. When the outage comes they are encrypted or stale, and clinicians lose allergies, drug charts and care plans exactly when they need them.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Downtime copies are independent of the systems whose failure they cover.", "measures": [ "Keep downtime copies on standalone devices per ward, refreshed often and not joined to the main directory.", "Print or cache critical summaries such as medication charts and allergies on a schedule.", "Test that downtime copies open with the network, directory and main storage all unavailable." ], "prompts": [ "What do downtime viewers and printed reports depend on?", "Would downtime copies survive the same outage as the record?", "How current are the downtime copies at any moment?" ], "deck": "The Hospital", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "linddun": [ "https://ostering.com/ns/linddun#DD" ], "mds2": [ "DTBK", "STCF" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1486/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-5", "@type": "skos:Concept", "notation": "CRI-CD-5", "prefLabel": "Incident communications on compromised systems", "definition": "The incident plan relies on email, VoIP phones, paging and the intranet to call staff in and coordinate. Those same systems are down or untrusted, so command cannot reach staff, the ambulance service or the public, and attackers may read the response.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The hospital can command its response with systems that do not share the fate of the ones under attack.", "measures": [ "Provide out-of-band communications for incident command, such as separate phones, radios or a hosted service.", "Keep printed contact lists and call-in cascades that work without the directory.", "Assume email and chat are being read during an incident and move sensitive decisions off them." ], "prompts": [ "How would incident command reach staff with email and phones down?", "Which communication channels share fate with the systems under attack?", "Could attackers be reading the response?" ], "deck": "The Hospital", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#I" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1489/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-4", "@type": "skos:Concept", "notation": "CRI-CD-4", "prefLabel": "No planned restore order", "definition": "Nobody has worked out which systems must come back first and what they depend on. Teams restore systems that cannot run without the directory, DNS, integration engine or certificates, and clinical priorities wait behind whatever IT reaches first.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "The restore order follows clinical priority and real technical dependencies, both written down and tested.", "measures": [ "Map dependencies of each clinical system, including identity, DNS, time, integration and licences.", "Agree a restore order with clinical leads and keep it with the backups, offline.", "Rehearse restoring the top tier of clinical services from bare infrastructure." ], "prompts": [ "Which systems must be restored first for clinical care?", "What technical dependencies does each priority system have?", "When was the restore order last tested?" ], "deck": "The Hospital", "rank": "4", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1490/" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-3", "@type": "skos:Concept", "notation": "CRI-CD-3", "prefLabel": "Extortion deadlines rush the recovery", "definition": "Attackers set publication deadlines and contact staff, patients and the press while the hospital is still restoring. Under that pressure leaders skip validation, restore from unchecked backups or reconnect early, and the attackers' access or damaged data comes back with the services.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Recovery steps are decided on clinical and technical evidence, not on the extortion clock.", "measures": [ "Agree in advance who decides on reconnection and what evidence they need, independent of any ransom deadline.", "Prepare holding statements and patient lines so publication threats do not drive technical decisions.", "Rebuild from known-good images and verified backups even when that is slower than restoring in place." ], "prompts": [ "Who decides on reconnection, and on what evidence?", "How will publication threats be handled without driving technical choices?", "Will you rebuild from known-good images even if it is slower?" ], "deck": "The Hospital", "rank": "3", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1657/", "https://attack.mitre.org/techniques/T1486/" ], "harm": "care", "seenIn": [ { "prefLabel": "Conti attack on Ireland's HSE, 2021", "source": [ "https://www.hse.ie/eng/services/publications/conti-cyber-attack-on-the-hse-full-report.pdf", "https://www.hhs.gov/sites/default/files/lessons-learned-hse-attack.pdf" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/#cri-cd-2", "@type": "skos:Concept", "notation": "CRI-CD-2", "prefLabel": "Payments and claims stop flowing", "definition": "Claims, eligibility checks and pharmacy payments run through a single clearing service or payer platform. When it is attacked, providers cannot verify cover or get paid, pharmacies cannot dispense on account, and smaller practices run out of cash within weeks.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/continuity-and-downtime/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Clinical care continues when payment and eligibility services do not, and providers can survive a long payment outage.", "measures": [ "Agree with payers how care is authorised and paid when eligibility services are down.", "Keep a second route to submit claims and check cover, tested at least yearly.", "Plan financial reserves or emergency funding for a payment outage of several weeks." ], "prompts": [ "Which payment or eligibility service would stop dispensing or billing?", "How long could smaller providers survive without payments?", "Can care continue when cover cannot be checked?" ], "deck": "The Hospital", "rank": "2", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#D" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1486/" ], "seenIn": [ { "prefLabel": "Change Healthcare, 2024", "source": [ "https://www.beckershospitalreview.com/healthcare-information-technology/cybersecurity/change-healthcare-data-breach-toll-reaches-192-7-million", "https://www.fiercehealthcare.com/payers/unitedhealth-estimates-190m-people-impacted-change-healthcare-cyberattack" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "@type": "skos:Concept", "notation": "CRI-TR", "prefLabel": "Structural hazards", "definition": "Ten structural hazards of hospitals and medical devices as a whole. Both decks carry them, ranked 1 (highest) to 10.", "deck": "Both decks", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "topConceptOf": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "narrower": [ "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-1", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-2", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-3", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-4", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-5", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-6", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-7", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-8", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-9", "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-10" ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-1", "@type": "skos:Concept", "notation": "CRI-TR-1", "prefLabel": "Life before login", "definition": "Clinical urgency beats every control that slows care. Staff will bypass, share or switch off any security that delays treatment, so a design that only works when people comply fails on the busiest night, and a control that fails closed can harm a patient.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Design security so the safe and secure path is also the fastest path in an emergency.", "measures": [ "Time every security step in real clinical workflows and set targets in seconds.", "Provide accountable emergency access instead of hoping staff will not need it.", "Decide, per function, whether failure should be open or closed, and justify it in the safety case." ], "prompts": [ "Which security steps slow care in an emergency, and by how long?", "Is the secure path also the fastest one on the busiest night?", "Which controls fail closed where failing closed could harm a patient?" ], "deck": "Both decks", "rank": "1", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#E" ], "mds2": [ "EMRG" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software", "ISO 14971:2019 Medical devices: application of risk management to medical devices" ], "broadMatch": [ "https://capec.mitre.org/data/definitions/416.html", "https://cwe.mitre.org/data/definitions/655.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-2", "@type": "skos:Concept", "notation": "CRI-TR-2", "prefLabel": "The device outlives its software", "definition": "Medical devices stay in service for ten to twenty years, while their operating systems and components lose support in a few. Hospitals run certified builds that cannot change, so known weaknesses stay open for most of a device's life.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Plan the whole service life of a device's software at design and at purchase.", "measures": [ "Require a support roadmap for every third-party component and an end-of-support date in the contract.", "Design devices so components can be updated without replacing the clinical function.", "Budget and plan replacement or isolation before support ends, not after." ], "prompts": [ "How long will this device stay in service, and its software supported?", "What happens to it once its operating system loses support?", "Who plans the device's software life at purchase?" ], "deck": "Both decks", "rank": "2", "physicalSafety": true, "mds2": [ "RDMP", "SBOM", "CSUP" ], "standard": [ "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1104.html", "https://cwe.mitre.org/data/definitions/1329.html" ], "harm": "care", "seenIn": [ { "prefLabel": "Argus II retinal implant, 2020", "source": [ "https://spectrum.ieee.org/bionic-eye-obsolete" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-3", "@type": "skos:Concept", "notation": "CRI-TR-3", "prefLabel": "Nobody owns the bedside", "definition": "Clinical engineering, IT, the supplier and the ward each assume another owns a connected device's security. Patching, monitoring, configuration and incident response fall between them, and attackers find the gaps first.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Every connected device has a named owner for its security, across its whole life.", "measures": [ "Assign responsibilities for each device class in a written agreement between clinical engineering, IT and the supplier.", "Keep one inventory of connected devices, shared by all owners, with a named contact per device.", "Include connected devices in incident response playbooks with clear decision rights." ], "prompts": [ "Who owns the security of each connected device in this design?", "Where do clinical engineering, IT, vendor and ward responsibilities meet?", "Who responds first when a bedside device is compromised?" ], "deck": "Both decks", "rank": "3", "physicalSafety": true, "mds2": [ "SGUD" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/671.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-4", "@type": "skos:Concept", "notation": "CRI-TR-4", "prefLabel": "Safety cases assume accidents", "definition": "Risk files and safety cases model random failures and honest mistakes. An adversary chooses the worst moment, defeats several safeguards together and hides the evidence, so controls judged independent fail at once and residual risk is far higher than the file says.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Treat intentional misuse as a cause of hazards in the safety risk file, not a separate concern.", "measures": [ "Link security threats to hazards in the ISO 14971 risk file and score them together.", "Check that safeguards relied on as independent cannot be defeated by one compromise.", "Reassess the safety case whenever a new vulnerability or attack technique affects the device." ], "prompts": [ "Does the safety risk file treat an adversary as a cause of hazards?", "Which safeguards could one attacker defeat together?", "How would the residual risk change if failures were deliberate?" ], "deck": "Both decks", "rank": "4", "physicalSafety": true, "mds2": [ "IGAU" ], "standard": [ "ISO 14971:2019 Medical devices: application of risk management to medical devices", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "IEC TR 60601-4-5:2021 Medical electrical equipment: safety-related technical security specifications" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0880/", "https://attack.mitre.org/techniques/T0837/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-5", "@type": "skos:Concept", "notation": "CRI-TR-5", "prefLabel": "Alarm fatigue hides the attack", "definition": "Wards hear hundreds of alarms a shift, most of them false, so staff silence, widen or ignore them. Manipulated readings, suppressed alarms or a device behaving oddly blend into the noise and are noticed late, if at all.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Alarms are few, meaningful and protected from change, so an abnormal one gets attention.", "measures": [ "Reduce non-actionable alarms through tuning and clinical review before adding new ones.", "Protect alarm limits and routing from unauthorised change and log every change.", "Report alarm silencing and limit changes per device so unusual patterns are seen." ], "prompts": [ "How many alarms does each ward hear in a shift?", "Would a manipulated alarm stand out from the noise?", "Who can change alarm settings, and is that protected?" ], "deck": "Both decks", "rank": "5", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#T", "https://ostering.com/ns/stride#R" ], "mds2": [ "AUDT", "IGAU" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/778.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0832/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-6", "@type": "skos:Concept", "notation": "CRI-TR-6", "prefLabel": "One supplier, many hospitals", "definition": "A handful of suppliers provide the record systems, laboratories, imaging platforms, remote service tools and clouds for most hospitals in a region or country. One compromise or one failure at a supplier becomes an incident at every customer together.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Know where many hospitals share one supplier and keep a way to work without it.", "measures": [ "Map shared suppliers across the region and treat concentration as a risk to manage.", "Require suppliers to separate customers so one breach does not reach all of them.", "Plan mutual aid and fallbacks that do not use the same supplier." ], "prompts": [ "Which suppliers in this design also serve most nearby hospitals?", "What would one supplier's compromise do to every customer at once?", "How would you keep working without that supplier?" ], "deck": "Both decks", "rank": "6", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "RMOT" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1357.html" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1199/", "https://attack.mitre.org/techniques/T1195/002/" ], "harm": "care", "seenIn": [ { "prefLabel": "Synnovis pathology attack, London, 2024", "source": [ "https://www.theregister.com/2025/06/26/qilin_ransomware_nhs_death/", "https://www.digitalhealth.net/2025/06/patient-dies-as-a-result-of-cyber-attack-on-nhs-pathology-provider/" ] }, { "prefLabel": "Change Healthcare, 2024", "source": [ "https://www.beckershospitalreview.com/healthcare-information-technology/cybersecurity/change-healthcare-data-breach-toll-reaches-192-7-million", "https://www.fiercehealthcare.com/payers/unitedhealth-estimates-190m-people-impacted-change-healthcare-cyberattack" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-7", "@type": "skos:Concept", "notation": "CRI-TR-7", "prefLabel": "Patch means revalidate", "definition": "Changing a certified device's software means verification by the maker and sometimes the regulator, and hospitals are told not to patch themselves. Fixes arrive months or years after the weakness is public, and the hospital must defend a device it is not allowed to change.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Design and contract for timely, validated updates as part of the device, not an exception.", "measures": [ "Design devices so security updates can be verified quickly without re-certifying clinical function.", "Agree update timelines and compensating controls in the purchase contract.", "Isolate and monitor devices awaiting validated updates, with the supplier's guidance." ], "prompts": [ "How long does a validated fix take to reach this device?", "What may the hospital do while a fix is awaited?", "Does the contract commit the maker to timely validated updates?" ], "deck": "Both decks", "rank": "7", "physicalSafety": true, "mds2": [ "CSUP", "RDMP" ], "standard": [ "FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)", "ANSI/AAMI SW96:2023 Standard for medical device security: security risk management for device manufacturers", "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security: security activities in the product life cycle" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/1329.html" ], "relatedMatch": [ "https://emb3d.mitre.org/threats/TID-213.html" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-8", "@type": "skos:Concept", "notation": "CRI-TR-8", "prefLabel": "Every patient is a target", "definition": "Health records are permanent, deeply personal and valuable for fraud, extortion, discrimination and intelligence. Every patient is a data subject whose information can be sold, published or used against them, long after the care has ended.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Collect, keep and expose only what care needs, and protect the most sensitive data most strongly.", "measures": [ "Classify record categories by sensitivity and apply stronger controls to the most sensitive.", "Minimise copies of patient data in secondary systems, exports and test environments.", "Give patients a way to see who has accessed their record." ], "prompts": [ "What patient data does this design collect that care doesn't need?", "Which data would do most harm if sold or published?", "How long is patient data kept after care ends?" ], "deck": "Both decks", "rank": "8", "physicalSafety": false, "stride": [ "https://ostering.com/ns/stride#I" ], "linddun": [ "https://ostering.com/ns/linddun#L", "https://ostering.com/ns/linddun#I", "https://ostering.com/ns/linddun#DD", "https://ostering.com/ns/linddun#U", "https://ostering.com/ns/linddun#Nc" ], "mds2": [ "MPII", "STCF", "DIDT" ], "standard": [ "ISO 27799 Health informatics: information security management in health using ISO/IEC 27002" ], "broadMatch": [ "https://cwe.mitre.org/data/definitions/359.html" ], "seenIn": [ { "prefLabel": "Vastaamo psychotherapy records, Finland, 2020", "source": [ "https://en.wikipedia.org/wiki/Vastaamo_data_breach", "https://ny1.com/nyc/all-boroughs/ap-top-news/2024/04/30/finnish-hacker-gets-prison-for-accessing-thousands-of-psychotherapy-records-and-demanding-ransoms" ] } ] }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-9", "@type": "skos:Concept", "notation": "CRI-TR-9", "prefLabel": "The hospital never closes", "definition": "Hospitals run every hour of every day with no maintenance window. Patching, testing and recovery all compete with care, and the only way to switch a hospital off safely is to divert patients elsewhere.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Build maintenance and recovery into the design so they do not require stopping care.", "measures": [ "Design redundant clinical systems so one side can be updated while the other runs.", "Plan maintenance with clinical leads around activity, not around IT convenience.", "Treat the ability to recover without closing as a design requirement." ], "prompts": [ "When can this system be patched, tested or restored without stopping care?", "What does the design assume about maintenance windows?", "Is diversion the only way to take this service offline safely?" ], "deck": "Both decks", "rank": "9", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D" ], "mds2": [ "DTBK", "CSUP" ], "standard": [ "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T0826/" ], "harm": "care" }, { "@id": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/#cri-tr-10", "@type": "skos:Concept", "notation": "CRI-TR-10", "prefLabel": "Hospitals are strategic targets", "definition": "Hospitals are critical infrastructure. Criminals target them because they pay, and states may pre-position in them or disrupt them in a crisis or conflict to cause fear and overwhelm emergency response. Plans built for accidents and petty crime do not survive a determined adversary.", "broader": "https://ostering.com/taxonomies/hospitals-and-medical-devices/structural-hazards/", "inScheme": "https://ostering.com/taxonomies/hospitals-and-medical-devices/", "principle": "Plan for a patient, capable adversary who wants disruption, not only for criminals who want money.", "measures": [ "Include state-level scenarios, such as simultaneous attacks on several hospitals, in continuity planning.", "Share threat intelligence with sector bodies and national authorities and act on it.", "Hunt for long-term access in clinical and device networks, not only for ransomware." ], "prompts": [ "Does the design assume a patient, capable adversary or just criminals?", "What would a state actor gain by disrupting this system in a crisis?", "Which plans would fail against a deliberate, coordinated attack?" ], "deck": "Both decks", "rank": "10", "physicalSafety": true, "stride": [ "https://ostering.com/ns/stride#D", "https://ostering.com/ns/stride#E" ], "standard": [ "IEC 62443 Security for industrial automation and control systems", "IEC 80001-1:2021 Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software" ], "relatedMatch": [ "https://attack.mitre.org/techniques/T1078/", "https://attack.mitre.org/techniques/T1133/" ], "harm": "care" } ] }