Chapter 6

Victor Frankenstein Audits an IoT Insulin Pump

Victor Frankenstein, Bio-Tech Security Engineer at Geneva Labs, is leading the security audit for a next-generation networked insulin pump before FDA submission. The device runs custom firmware on an ARM SoC, communicates over Bluetooth Low Energy with a clinician's tablet, and pulls signed firmware updates from Geneva's CI/CD pipeline.

Three concerns dominate Victor's review. First, the development team built the firmware-signing key into the build server's environment variables — Victor wants the key generation, storage, and signing operations all to happen inside dedicated tamper-resistant hardware. Second, an attacker with brief physical access to the pump should not be able to swap in a malicious firmware image; the device must verify firmware integrity before each boot, and the boot chain itself must be measured so a remote attestation server can detect tampering after the fact. Third, the company's CI/CD pipeline must catch vulnerable open-source dependencies and produce a machine-readable inventory that hospitals can ingest into their own vulnerability programs — particularly relevant after the Log4Shell scramble two years ago.

Victor also has to plan for the day this pump model reaches end-of-life, and he must defend against a known class of attacks where a small device is wedged between a USB port and a peripheral to silently capture data.

Complete Victor's hardware-assurance review by selecting the correct concept for each blank.

To remove the firmware-signing key from the build server, Victor will move all signing operations into an — a dedicated, tamper-resistant device whose private keys never leave the boundary in plaintext. For per-device measurements and remote attestation of the pump itself, each unit will ship with a that stores boot-stage hashes in tamper-evident registers.

The boot process must verify the cryptographic signature on each stage before executing it; this is . To additionally record what was actually loaded — so a remote server can later confirm the device booted clean firmware — Victor will enable , which extends measurements into the platform module's PCRs.

In the CI/CD pipeline, Victor will add to flag vulnerable open-source components, and the pipeline will publish a alongside each release so hospitals can match component versions against future CVEs without reverse-engineering the firmware.

To catch insecure code patterns before the binary is even built, Victor will run against the source tree. To find runtime issues such as authentication bypasses on the BLE interface, the QA team will run against built firmware in a hardware-in-the-loop rig.

For the day the pump model is retired, Victor will publish a documented so hospitals know exactly when security updates will stop and can budget for replacement. Finally, to defend against a malicious device wedged between a USB port and a legitimate peripheral, Victor will warn clinicians in the operations manual about and require port covers on the charging dock.