Scroll to discover
Schedule Live Demo
Skip to content

How to improve secure design habits for medical devices

Shift-left security is hard, especially for medical device makers

With around 430 million connected medical devices in use across the globe, technology is a mixed blessing, specially for medical device manufacturers. The same technologies that can improve the quality of life for many patients, can also be abused by cyber threat actors to potentially harm patients and critical infrastructures. Moreover, until very recently, Medical Device Manufacturers (MDMs) were focused primarily on providing function, not security, making them an easy target for potential cyberattacks. 

In its 2022 State of Healthcare IoT Device Security Report, Cynerio found that 53% of connected medical devices and other IoT devices in hospitals have a known critical vulnerability. In recent times, COVID has become a global game changer. The pandemic has caused a spike in the number of security incidents in hospitals, pharmaceutical companies and medical supply companies.

Software misconfigurations and poorly conceived software designs can also make for big medical device vulnerabilities. This became clear a long time ago. One of the first incidents related to poor software design practices in medical devices was the Therac-25 incident. Between June 1985 and January 1987 a Threrac-25 (a computer controlled radiation therapy machine), massively overdosed six people. Unlike earlier models, the Therac-25 relied almost exclusively on software to ensure safe operation. The incident investigation determined that the main reasons for this disaster were due to an incorrect software architecture and poor software development practices. One of the main conclusions was that the medical device manufacturer did not consider the design of the software (which was written in PDP-11 assembly language) during its assessment of how the machine might produce the desired results and what failure modes existed. 

A rough estimate is that half of all software security defects are the result of design flaws. The Adverse Event Terminology working group from the IMDRF (International Medical Device Regulators Forum) has a dedicated category to include problems traced to the design specifications (D01 - Cause Traced to Device Design). This main category, as can be seen in the following figure, also includes a dedicated subcategory to consider causes traced to the inadequate or inappropriate design of software components in medical devices (D0108 - Inadequate Software Design). 

Source: https://www.imdrf.org/working-groups/adverse-event-terminology/annex-d-cause-investigation-investigation-conclusion 

A completely connected secure device is a well known oxymoron. However, with a well planned and documented security design process, companies can raise the bar to increase their device’s security posture. At the same time, they’ll be able to provide  transparency and predictability for security activities that should be planned depending on the product risk profile.

Threat modeling as a keystone habit

Medical device manufacturers are starting to use recognized cybersecurity standards from the critical infrastructure sector to improve the medical device cybersecurity. That’s the case with IEC 62443. These series of standards were originally developed for Industrial Automation and Control Systems (IACS), but they can also be applied to critically analyze the entire attack surface of common IoMT (Internet of Medical Things) system architectures. The Threat Analysis practice required by the IEC 62443-4-1 includes the requirement of building a threat model for the system’s architecture as a crucial part in the application of risk management processes to design secure components. As defined in the Threat Modeling Manifesto, “Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics”. It’s a systematic way to think about security that could help to be proactive when including the necessary security controls earlier during the SDLC. But embedding threat modeling in the design phase of the SDLC is a habit change game that comes with a few challenges.

As commented by Charles Duhigg, in his splendid book The Power of Habit, one of the best ways to implement large scale changes is to focus on changing only one important habit, what Duhigg calls a keystone habit. This is brilliantly illustrated in the book with the story of Alcoa’s transformation. When Paul O'Neill was presented in October 1987 in front of a selected group of prominent Wall Street investors as the new CEO of Alcoa, his speech didn’t follow the preset conventions for such an event. He said:

“Our safety record is better than the general American workforce, especially considering that our employees work with metals that are 1,500 degrees and machines that can rip a man’s arm off. But it’s not good enough. I intend to make Alcoa the safest company in America. I intend to go for zero injuries.”

O’Neill wanted to concentrate his efforts on changing safe practices across the organization. He hoped that handling this influential, or keystone, habit first would have a cascade effect, causing many other habits to change too. Improving the overall company performance. As a matter of fact, only one year after this speech, Alcoa achieved peak profits. And 13 years later, by the time O'Neill decided to retire, Alcoa profits were five times greater than before his arrival. 

The habits that matter the most are the ones that, when they start to shift, create virtuous circles in all related processes. The same reasoning could be applied by Medical device manufacturers to embed security in the SDLC (Software Development Life Cycle). By changing the security design habits to include threat modeling many other key engineering processes will be improved across the organization. 

Threat modeling could be the keystone habit that will lead to an examination of inefficiencies in the development processes. Suboptimal engineering and organizational choices will come up to light, and will clearly expose gaps in communication between engineering and security teams.

Using a playbook to nurture threat modeling habits

"Habits are, simply, reliable solutions to recurring problems in our environment." 

—Jason Hreha 

A playbook could be a very valuable asset to internalize threat modeling habits in any organization. In simple words, a playbook could be defined as a document that includes a checklist of actions. Those actions are intended to complete tasks in a consistent way. We shouldn’t underestimate the power of checklists. Pilots have been using them for almost a century to ensure the safe and proper operation of aircrafts.

A good threat modeling playbook will allow you to focus more on the system (the threat modeling process) than on the desired goal (having more secure and resilient medical devices).

The Food and Drug Administration (FDA) has also recognized the value of having a good threat modeling playbook as a guide to improve the cybersecurity and safety of medical devices in a systematic way. Following this line of thinking, the MITRE and the Medical Device Innovation Consortium (MDIC) released a playbook for medical device threat modeling. This document follows Adam Shostack's 4 Question Frame for Threat Modeling to identify threats that could adversely impact the safety and security of a medical device and to take the most effective mitigation measures. Even though this playbook is not prescriptive, it provides a great resource for threat modeling training.

The playbook also presents some end-to-end fictional medical devices to demonstrate the application of threat modeling techniques with hand-on examples in a hospital environment.

One of these examples is the Ankle Monitor Predictor of Stroke (AMPS) device. This system is a home use medical device for a fictional stroke diagnostic technique. The overall scenario was constructed to highlight typical features encountered when threat modeling medical devices. The AMPS system consists of three main components:

  • The AMPS device. It’s a health monitoring system worn on a patient’s ankle when they are resting.
  • The AMPS app that resides on the patient’s cell phone and can be paired with the AMPS device via Bluetooth.
  • The AMPS Cloud Service. It’s a collection of virtual machines hosted in a cloud infrastructure to perform analysis of the patient data.

The diagram for the AMPS system architecture is depicted in the following figure:

Example Mid-Level architectural diagram for the AMPS Device.

Based on brainstorming sessions, the MDIC playbook illustrates an example of applying STRIDE to the AMPS device itself. Based on the diagram shown in the previous figure, the following threats were identified:

Description of STRIDE Threats against the AMPS Device.

Although threat modeling can be carried out manually, using a threat modeling tool could help to automate and scale the process. The following figure shows some of the threats generated by IriusRisk for the AMPS device:

Some of the IriusRisk’s threats for the AMPS Device.

Conclusion

As medical devices become increasingly connected, cybersecurity must be taken into account from the first design stages in order to protect patients’ health and personal data. Threat modeling could be an opportunity for medical device manufacturers to improve the software design process in a collaborative way and prevent future vulnerabilities. Embedding threat modeling in the SDLC is a habit change game and having an actionable playbook can make a difference in this cultural shift. The threat modeling playbook released by MITRE and MDIC could be a foundational resource to support healthcare organizations in increasing security design awareness and scale best practices in this area.