Norman Martel, and Jeff Zampieron, of MedAcuity

For decades, the design and development of medical devices have been grounded in a benevolent mindset—to put healthcare technology in the hands of trusted clinicians and doctors with the sole intention of improving diagnostic and therapeutic approaches, outcomes, and the health and wellbeing of people. However, the overall landscape has shifted from stand-alone specific-purpose devices to connected, integrated systems-of-systems. This is largely due to the rising number of innovative solutions that include cloud-based systems, mobile and wearable devices, the Internet of Medical Things (IoMT), patient portals, and more. Our desire to build things to improve people’s lives coupled with rising consumer demand for technology will continue to accelerate technological advancements in healthcare.

This proliferation of connected medical devices and systems integrated into network ecosystems is forcing a change in thinking about how software-intensive medical devices are designed and developed.  What must also change is that benevolent mindset. Certainly, the “good intentions” aspect is still essential, however, today’s connected healthcare landscape calls for the adoption of a more adversarial perspective. This fundamental mindset change requires extending the definition of “users” of these connected medical devices to not only doctors and clinicians, but also patients, biomedical engineers, device manufacturers, service personnel, and IT staff. Furthermore, the definition of “users” must now also include unintended users or “bad actors.” Bad actors range from adversaries (hackers/script kiddies, organized crime) to competitors and even hostile insiders (intended users) who are looking to gain and exploit unauthorized access to medical technology and information for competitive and financial gain or to cause patient harm through cyber-physical effects.

Why Now? Making the Case for a Change in Perspective

Connected medical devices deployed within medical/healthcare facilities frequently have trust relationships within hospital infrastructure (i.e., HL7, DICOM, LDAP Servers), providing wider exposure (i.e., potential attack surfaces) that can be leveraged by an adversary to disrupt services and potentially cause harm. Medical devices containing wireless technologies such as Bluetooth and Wi-Fi provide further opportunities to exploit vulnerabilities (e.g., BlueBorne, Bluetooth Impersonation Attacks (BIAS), FragAttacks, etc.) from the waiting room, hospital parking lot, or anywhere wireless signals can reach. Exploiting an internally connected medical device may in turn provide unintended horizontal access to the hospital infrastructure. This network back door access can lead to establishing botnets behind the hospital firewalls or to the installation of ransomware, all of which are likely to bypass logging and intrusion detection that is normally applied at the firewall/router.

Connected devices are increasingly used as a means for compromising security certificates, theft of intellectual property, and disclosure of sensitive patient information. Data from Cisecurity.org reflects that there has been a 700% increase in COVID-themed phishing emails directed toward the healthcare sector and the public, and 12.6 million individuals (about twice the population of Arizona) have been affected by 162 hacking incidents on healthcare entities within a three-month period. According to a 2021 survey conducted by Security Intelligence, 42% of 597 hospitals surveyed have experienced at least two ransomware attacks. Per a 2022 report, Unit 42 researchers analyzed over 200,000 infusion pumps and found known security gaps in 75% of them. These types of vulnerabilities could allow hackers to alter the medication dosage of unsuspecting patients, potentially even delivering a lethal dose. Other devices like pacemakers are also susceptible to being compromised and controlled by cybercriminals wishing to alter the operations of the device.

To date, our mindset has been one of benevolence. We trust our suppliers and employees and take for granted that our firewalled internal networks are safe. We believe that we make few if any, mistakes. We trust that everyone will use devices according to their labeling and that no abuse of the system is likely to occur. As demonstrated by the hacks and breaches just mentioned, this trust is misplaced. We can no longer trust or believe that everyone will do the right thing.
 

Understanding the Adversarial Mindset

To begin addressing this epidemic of threats, a new way of thinking about medical device software development is key to anticipating and mitigating how a device may be misused and/or compromised. We must no longer only think along the lines of “intended use,” but also begin thinking like a prospective attacker. We refer to this new perspective as adversarial thinking.

Adversarial thinking involves understanding attackers’ unconventional perspectives, reasoning, and work methods to identify what threats and vulnerabilities they might target to exploit and how. This type of thinking is not a new concept. It has been a critical component of the Department of Defense (DoD) product development strategy for decades and influences how they approach the design, implementation, and deployment of military assets and critical infrastructure.

Adversarial thinking is not natural for most engineers. Good software engineering focuses on how to make things work correctly, be easy to use, and accessible whereas the adversarial mindset means thinking about how to work around or bypass security measures, how to tamper with data and leave no trace. This mindset shift requires thinking about where the threats can come from within a hospital and beyond: the expected medical staff, the manufacturer’s operations, and support staff, or supply chain and shipping personnel–as anyone in the chain can introduce a weakness that a hacker may exploit. A chain is only as strong as its weakest link.

Integrating Adversarial Thinking into Your Security Risk Management Process

Typical for regulated markets, the application of analysis, specifically adversarial thinking, is backed by FDA guidance, industry standards, and structured processes. Capturing the output of this adversarial thought process is now done as part of the security risk management process. As medical device OEMs adopt adversarial thinking when developing software and combine that new ‘security mindset’ with their security risk management process, they will improve the information security and cybersecurity of their products; and better protect healthcare system infrastructures from being either a launch point or target for cyber-attacks.

Medical device manufacturers must integrate adversarial thinking into their implementation and execution of their security risk management process. This process should include the full device lifecycle—from requirements and development through to decommissioning and disposal. A comprehensive security risk management process needs to include threats from insiders, suppliers, and competitors.  Additionally, the threats assessed should include reasonably foreseeable misuse, which given the current cyber vulnerability landscape, must consider many new and emerging threats.

Step 1: Develop a Threat Model: Identify the Assets, Threats, and Vulnerabilities

Look at the full product lifecycle from the supply chain, manufacturing, shipping, installation, maintenance, field service, to decommissioning and destruction, to build a threat model. Identify what threats and vulnerabilities apply to each of the assets. Analyze key data flows and identify the potential exposure of assets at each interface of the system.

Step 2: Perform an Exploits and Impact Analysis

Using your threat model, consider what might happen to various assets at each of the lifecycle phases. What would happen if your medical device were discarded at its useful end-of-life, and someone removed the hard drive? What would be disclosed? Would your certificates be compromised? Would your intellectual property be leaked? Would any user credentials or patient data be leaked? If your product includes consumables, could any of those items leak information to someone looking to make a knock-off? Could any part of your consumable such as an RFID tag be reclaimed and reused in a knock-off product to make it appear genuine? As you think through these scenarios, document each potential exploit and document the impact analysis.

Step 3: Identify and Implement Security Risk Controls

Using the exploits and impact analysis outputs, determine the appropriate security risk control measures required to effectively control the identified risks. Then, implement these risk controls in your product.

Step 4: Verify the Security Risk Controls

Develop and execute a risk control verification strategy. The testing needs to prove that the risk controls are effective as well as complete.

Step 5: Write the Security Risk Management Report

Lastly, write up your report. The report should demonstrate the level of effectiveness of the risk controls and identify the residual risk.

An FDA submission will require objective evidence that your product has undergone the rigors of your security risk management process. It will also require evidence that security risks leading to potential safety risks have been identified and incorporated into your safety risk management process. The risk management process artifacts are your objective evidence, and the reports are the opportunity to demonstrate that the processes have been fully and effectively executed.

Conclusion

For a medical device containing software, adversarial thinking, when combined with early security risk analysis and security-centric software lifecycle practices, can be an effective means of identifying and controlling security-related risks from project inception. By designing security from the start, you minimize the security exposure of your device and its software.