Threat Modeling - Impact, Unintended, and Intended Effect

Forget the color-coded heatmaps and theoretical risk matrices that look great in a board deck but do absolutely nothing to stop an attack. When we talk about threat modeling, we’re talking about one thing: figuring out exactly how your system can be weaponized before someone else does it for you.

When your architecture handles IoT medical devices, the stakes aren't just a GDPR fine or a bruised reputation. The impacts and harms – can be to the patient, or multiple persons - whether through intended operation, unintended effects and surprises, or even subverted intended effect

First, let’s tear down a high-stakes ecosystem:

I am making an FDA approved insulin pump. It has a SOC, RTOS kernel, minor file storage for configuration and patient data, GPIO for buttons and LEDS, internal sensors, a lithium battery and related battery logic/hardware, and a BLE/BT SOC/RF stack. It likely has a patient-facing mobile app, a technician’s provisioning app, and the backend clinic software housing the patient data.

Second, we need to define its “Intended Usage.”

The intended clinical usage of an FDA-approved insulin pump with this architecture is to provide continuous subcutaneous insulin infusion (CSII) for the management of diabetes.

Mechanically and computationally, it is designed to:

• Deliver highly precise micro-doses of basal insulin continuously, and larger bolus doses as triggered by the patient or a paired Continuous Glucose Monitor (CGM).

• Utilize the SOC/RTOS to execute deterministic control loops, ensuring precise timing for pump motor actuation.

• Store critical configuration states (e.g., personalized basal profiles, maximum bolus limits) and historical patient data (dosage logs) in local file storage.

• Use internal sensors to detect critical hardware states, such as fluid occlusion (blockage) or empty reservoirs.

• Manage power safely via the battery logic to ensure days or weeks of uninterrupted operation.

• Interface with external devices (smartphones, CGMs, clinical programmers) via the BLE/BT stack for remote monitoring, configuration, and data offloading.

• Provide local user feedback and manual overrides via GPIO (physical buttons for bolus delivery, LEDs/audio for critical alarms).

Third, we define the model: Subversion and Failure Modes:

Analyzing the system through a standard, general threat modeling methodology (evaluating Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) reveals several vectors for subversion—spanning malicious attacks, accidental misuse, and component failures.

1. Spoofing (Identity and Inputs)

• Malicious: An attacker near the patient spoofs a paired smartphone or clinical programmer via the BLE stack to send unauthorized "deliver bolus" commands. Alternatively, if the pump accepts sensor data via BT, an attacker could spoof a CGM to feed artificially high glucose readings, prompting the pump to over-deliver insulin.

• Failed Component: An internal sensor degrades and "spoofs" a normal state, failing to signal an occlusion in the infusion set.

2. Tampering (Data and Execution State)

• Malicious: An attacker exploits a vulnerability in the BLE stack to achieve remote code execution (RCE) on the SOC, allowing them to modify the configuration files in storage (e.g., quietly increasing the basal delivery rate by 20%).

• Accidental: During an OTA firmware update, the file storage is corrupted, leading the RTOS to load a default, non-personalized configuration file that does not match the patient's biological needs.

• Failed Component: Bit-flips in memory or failing storage blocks cause the RTOS to read an incorrect threshold for the maximum allowable bolus.

3. Repudiation (Logging and Audit Failures)

• Malicious: An attacker compromises the system, alters the delivery parameters, and subsequently wipes or corrupts the internal patient dosage logs. If an adverse event occurs, forensic analysis cannot determine whether the pump malfunctioned or the patient manually overdosed.

• Failed Component: The storage module reaches its write-cycle limit. The pump continues to deliver insulin but silently fails to log the events, preventing the patient or endocrinologist from reviewing accurate dosage history.

4. Information Disclosure

• Malicious: The BLE connection lacks mutual authentication or strong encryption. A passive adversary sniffs the RF traffic to extract sensitive Protected Health Information (PHI), such as real-time glucose trends, dosage schedules, or patient identifiers.

• Accidental: The pump is resold or recycled without a secure wipe mechanism, exposing the previous patient's medical data from the internal file storage.

5. Denial of Service (Availability)

• Malicious (Battery Depletion): An attacker continuously pings the BLE interface or intentionally floods the device with malformed BT packets. This forces the SOC to wake from sleep states frequently or operate in an unsustainable fashion, draining the lithium battery in hours rather than weeks.

• Malicious (RF Jamming): A localized jammer disrupts the BT frequency, preventing the pump from receiving critical high-glucose alerts from a paired CGM or stopping the patient from using their smartphone to control the pump.

• Failed Component: A race condition in the RTOS kernel causes a hard crash or infinite loop. The watchdog timer fails to reset the system, leading to a complete cessation of insulin delivery.

6. Elevation of Privilege

• Malicious: An attacker uses a physical vector (e.g., holding specific GPIO buttons while applying a specific voltage to a charging pin) to bypass the standard user interface and drop the pump into a high-privilege manufacturer "diagnostic" mode, unlocking the ability to alter hard-coded safety limits.

• Failed Component: A short circuit on the GPIO lines registers as a continuous button press, accidentally elevating the user interface into a configuration menu that the patient is not trained to navigate, leading to unintentional parameter changes.

Forth, we define the Worst-Case Scenarios - Patient Harm

Disclaimer – I am not an expert in this field, nor am I medical professional; this is for illustrative purposes (and another reason why you do not blindly follow the Internet or AI). 

In medical device security, the ultimate impact is against the patient - it would be (probably) negligent to think otherwise. The failures noted above basically cascade into 2 primary kinetic harms:

1. Severe Hypoglycemia (Over-delivery): This is the most acute and immediately life-threatening scenario. It occurs if the pump is maliciously commanded to dump its reservoir, if the RTOS motor control loop fails and leaves the actuator open, or if tampered configuration files drastically increase the basal rate. The patient's blood sugar drops fatally low.

2. Diabetic Ketoacidosis / DKA (Under-delivery): This occurs if the system fails completely (DoS), if the battery logic hardware catastrophically fails and shuts down the SOC, or if a physical occlusion occurs and the internal sensors fail to detect it. The lack of insulin causes blood sugar and blood acids (ketones) to rise to toxic levels over hours or days.

But perhaps that was too technical to start, so here is a simplified version:

Here is how you actually model this threat landscape without the fluff.

0. What is in scope, and under my control?

Don't boil the ocean, but also realistically and pragmatically divide and conquer it. If you try to threat-model the entire universe, you’ll paralyze your engineering team so begin by drawing a hard perimeter around your blast radius.

In Scope & Under Your Control:

• The Pump Firmware: You own the code executing on the metal.

• The Patient & Tech Apps: You wrote the binaries. You control the certificate pinning, the local storage mechanisms, and the API calls they make.

• The Clinic Backend & APIs: The cloud infrastructure, the database, and the endpoints listening for telemetry.

Out of Scope (But Must Be Survived):

• The Patient’s Mobile Device: Assume it's a rooted, malware-ridden Android phone from 2019. We don't control the OS, but the app has to survive with these realities - often even side loaded...

• The Bluetooth Protocol (BLE) itself: We didn't invent BLE, you just use it, either through the phone, the app, or the SOC's implementation. It is unlikely we can fix its inherent protocol flaws, but we can control what data you push through it, as well as our target product's dependency on it, or what is possible through this media.

1. The Happy Path For Intended Operations

Before you can break the machine, you have to know what it looks like when it's purring.

• The Pump: Continuously monitors glucose levels (if integrated) and injects basal/bolus insulin doses. It talks exclusively to the Patient App via BLE.

• The Patient App: Acts as the bridge. It pulls telemetry from the pump, displays pretty graphs to the user, sends manual bolus commands to the pump, and syncs historical data up to the Clinic Backend over HTTPS.

• The Tech App: God mode on an iPad. Used in the clinic to pair a new pump to a patient, update firmware, and set hard baseline dosage limits.

• The Clinic Software: The mothership. Stores PHI (Protected Health Information), historical telemetry, and pushes configuration updates or firmware payloads down to the apps.

2. The Nightmare: Subversion & Exploitation

This is where the intended effect gets hijacked. What happens when the ecosystem is exploited in unintended ways?

• The Clinic Software (The Loot): If an attacker finds a Broken Object Level Authorization (BOLA) vulnerability in your API, they don't just dump PHI. They can modify configurations. Imagine an attacker changing the basal rate configuration for Patient A, which then syncs down to the Patient App, and pushes to the pump. You just weaponized the cloud.

• The Tech App (The Keys to the Kingdom): Technicians are notorious for reusing static credentials. If an attacker decompiles the Tech App and finds a hardcoded API key, or steals a technician's tablet, they bypass the patient entirely and gain direct administrative control over device provisioning.

• The Patient App (The Pivot): If the app trusts user input implicitly, an attacker could reverse-engineer the Bluetooth payload and write a malicious script to bypass the app entirely, spamming the pump with "dispense" commands directly from a rogue device.

• The Patient Device (The Oh No): If the device is directly or indirectly attacked, or legitimate functionality is accessed, utilized, or some other scenario occurs - the device should not be able to do a monumental and irreversible harm to the patient.

3. The Arsenal: Mechanisms of Disruption

How do threat actors actually engage with those subversions or interrupt the happy path? Here are some examples.

To Interrupt (Denial of Service & Disruption):

• BLE Jamming/Resource Exhaustion: Flooding the pump's Bluetooth receiver with garbage packets. The pump drops the connection to the Patient App. The intended operation (monitoring and remote dosing) is completely severed. Alternatively, packets and broadcasts drain the battery of the device causing it to cease operation or possess a limited window of operation thereby effecting the patient.

• Ransomware on the Clinic DB: The database is locked. The Patient App can't sync, the Tech App can't provision new devices, and doctors are flying blind. However, a disconnected patient device may be ok and able to operate in isolation.

To Engage (Exploitation & Integrity Loss):

• Man-in-the-Middle (MitM) & Replay Attacks: If the BLE traffic between the app and the pump isn't encrypted with a rolling, time-stamped nonce, an attacker sitting on a bench next to the patient can sniff the "dispense 2 units" command, save it, and blindly replay it 50 times an hour later.

• Firmware Downgrade Attacks: If the pump doesn't strictly validate the cryptographic signature and version number of a firmware update, an attacker can push an older, vulnerable firmware version from a compromised Tech App to re-open patched exploits.

• And many more other ways of course....

4. From Theory to Brutality: The Ecosystem Re-Evaluated

So at this point, I can probably sense - great - we’ve established the blast radius. Now we move from the abstract into the rigorous, mathematical breakdown of exactly how it goes wrong, and exactly how we stop it.

Then, when you look at the matrix below, you are seeing the translation of my thought exercise into hard engineering constraints:

• The BLE Connection is the Primary Battleground: The connection between the Patient App and the Pump is the soft underbelly. Attackers don't need to break AES encryption to kill the patient; they just need to spam the BLE stack until the battery dies (DoS), or bypass "Just Works" pairing to send unauthorized bolus commands. The fix isn't "better software"—its about reducing the impact or possibility that this exposed interface could render the scenarios we do not want to happen.

• The Tech App and OTA Updates are God Mode: If the Firmware Update Mechanism is hijacked, the pump must be physically hardened. We're talking a Memory Protection Unit (MPU) and a dual-bank bootloader to reject unsigned code before the RTOS even wakes up.

• The Clinic Backend Demands Forensic Immutability: If a patient dies, regulators pull the log datastore. If an attacker (or a bug) wipes those logs to hide an overdose, you are liable. The matrix dictates Write-Once-Read-Many (WORM) storage at the hardware flash controller level. Software cannot be trusted to police itself.

• Hardware Failures are Security Failures: Cybersecurity isn't just about hackers in hoodies; it's physics. Environmental degradation or a patient dropping the pump in the sink can cause the hardware to hallucinate a button press. We mitigate this through Triple Modular Redundancy (TMR) and conformal coating. We also have battery charging loops and LEDs to indicate levels, or hard circuits to prevent certain types of administrations. ETC ETC ETC.

How I forged this matrix:

Starting with what I knew, what I could Google, what I read and highlighted in FDA cybersecurity documentation, experienced with OT, IoT, and embedded syystems, and even threat modeling - I looked at this adversarial like. Then I chained everything together:

1. STRIDE: Microsoft’s model for classifying attacker goals (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). It dictates the category.

2. CAPEC (Common Attack Pattern Enumeration and Classification) & CWE (Common Weakness Enumeration): MITRE's exact, documented mechanisms of how the attack is executed at the code or protocol level.

3. CVSS v3.1 (Common Vulnerability Scoring System): The standard for scoring severity. We calculate the Initial Score (naïve build) and the Mitigated Score (after controls are applied).

4. Regulatory & Safety Frameworks: Cross-referencing legal and safety controls:

   • FDA Premarket Cybersecurity Guidelines: Secure boot, hard biological bounds, append-only logs.

   • EU CRA (Cyber Resilience Act): Secure defaults, isolated blobs, crypto-agility.

   • MISRA C: Motor-industry standards for safe, predictable C code.

   • RED (Radio Equipment Directive): European standards for RF comms.

I recognize that this document, or any that you build through threat modeling - they are not a write once and bury in a Confluence graveyard. They are living, and you have to own these, and trigger when something major occurs and enable them to evolve.

4. The Fix: What should I do next?

Then, as part of the fixing, and there would be a significant endeavor to evaluate the possibility, as well as validate every hypothesis - this is intrinsically different than threat modeling a standard web app. The FDA does not care about your elegant microservices or your Agile burn-down charts. They care about one thing effectively: preventing kinetic HARM to a human body.

In medical IoT, security is safety, and in engineering - its basically your oath. Your architecture must be designed to isolate the patient from a compromised cloud, gracefully degrade when dependencies vanish, and fail completely safe when the hardware inevitably rots:

1. Embed Biological Hard Bounds (Zero Trust on the Metal): The pump firmware must treat the Patient App, the Tech App, and the entire Clinic Backend as actively hostile. You need hardcoded, un-overridable biological sanity checks physically baked into the pump's execution logic (FDA-4). It must absolutely refuse to dispense a lethal dose, even if the cloud demands it with a valid API token. Furthermore, if your software scheduler freezes in a loop, an independent hardware Watchdog Timer (WDT) on a separate power domain must violently cut power to the motor (FDA-9). Do not trust software to police software.

2. Cryptographic Proof of Life (Kill the "Just Works" connection): Banish implicit trust. Implement Mutual TLS (mTLS) for every cloud connection—the Clinic API must cryptographically verify the exact instance of the app talking to it. For the local layer, mandate physical Out-of-Band (OOB) NFC taps to establish Bluetooth pairing (RED-5). Once paired, every single BLE command must require a unique, time-sensitive cryptographic nonce. If an attacker replays a packet, or tries to spoof the phone without the physical NFC handshake, the pump drops the payload into the void.

3. Engineer for Isolation (The "Open-Loop" Fallback): Assume your dependencies will die. The phone battery dies, an attacker jams the Bluetooth frequency, or the cloud gets hit with ransomware. When the pump is isolated, it cannot panic, and it cannot stop working. It must gracefully degrade into a localized "open-loop" state (RED-3). It falls back to baseline, pre-programmed safe basal rates and triggers aggressive, localized auditory alarms. You are relying on the patient as the ultimate biological backup. Isolation cannot equal paralysis.

4. Anticipate Hardware Rot & Forensics: Hackers aren't your only enemy; physics is. Flash memory wears out (Hardware Exhaustion). Cosmic rays and environmental degradation flip bits in RAM. Liquid breaches the chassis. You must implement Triple Modular Redundancy (TMR) for your critical safety thresholds in RAM so the hardware outvotes single-bit corruption. And when things go catastrophically wrong, your logs cannot be mutable. Force a Write-Once-Read-Many (WORM) architecture at the hardware flash controller level (FDA-3). If the storage drive is failing, the pump halts delivery rather than operating blindly.

A compromised app is an IT problem. A pump dumping 50 units of insulin because it trusted that app is a fatality. Secure what makes sense, engineer to control and ultimately prevent, and design the metal for the patient - intended vs. unintended.

If this article resonates with you, your job role, or you want to see what it is we do - reach out!