For decades, the design and development of medical devices has been based on a benevolent mindset – placing healthcare technology in the hands of trusted clinicians and physicians with the sole intention of improving diagnostic and therapeutic approaches, outcomes, and people’s health and well-being. However, the overall landscape has shifted from standalone specialty devices to connected, integrated systems-of-systems. This is largely due to the increasing number of innovative solutions that include cloud-based systems, mobile and wearable devices, the Internet of Medical Things (IoMT), patient portals and more. Our wish build things to improve people’s lives combined with increasing consumer demand for technology will further accelerate technological progress in healthcare.
This proliferation of connected medical devices and systems integrated into connected ecosystems is forcing a rethink of how software-intensive medical devices are designed and developed. What also needs to change is this benevolent mindset. Certainly the “good intentions” aspect is still important, but today’s connected healthcare landscape requires an assumption of more opposing perspective. This fundamental shift in thinking requires expanding the definition of “users” of these connected medical devices to include not only physicians and clinicians, but also patients, biomedical engineers, device manufacturers, service personnel, and IT personnel. Additionally, the definition of “users” must now also include unintended users or “bad actors”. Attackers range from attackers (hackers/script kiddies, organized crime) to competitors and even hostile insiders (intended users) who seek to gain and exploit unauthorized access to medical technology and information to gain competitive and financial advantage or to harm patients through cyber attacks -physical effects.
Why now? Plea for a change of perspective
Connected medical devices deployed in medical/healthcare facilities often have trust relationships within the hospital infrastructure (e.g. HL7, DICOM, LDAP servers) and provide broader exposure (e.g. potential attack vectors) to be exploited by an attacker can be used to disrupt services and potentially cause harm. Medical devices using wireless technologies such as Bluetooth and Wi-Fi provide additional opportunities to exploit vulnerabilities (e.g. BlueBorne, Bluetooth impersonation attacks (BIAS), FragAttacks, etc.) from the waiting room, the hospital parking lot, or anywhere wireless signals can reach. In turn, the use of an internally connected medical device can allow unintended horizontal access to the hospital infrastructure. This network backdoor access can result in botnets being set up behind hospital firewalls or ransomware being installed, all likely to bypass the logging and intrusion detection normally applied on the firewall/router.
Connected devices are increasingly being used as a means of compromising security certificates, stealing intellectual property and exposing sensitive patient data. Data from Cisecurity.org shows that there has been a 700% increase in COVID-related phishing emails targeting the healthcare sector and the general public, and that 12.6 million people (roughly twice the number of residents in Arizona ) 162 healthcare hacking incidents affected organizations within three months. According to a 2021 survey conducted by Security Intelligence, 42% of 597 hospitals surveyed have experienced at least two ransomware attacks. Per year 2022 report, Unit 42 researchers analyzed over 200,000 infusion pumps and found known vulnerabilities in 75% of them. These types of vulnerabilities could allow hackers to alter the drug dosage of unsuspecting patients, potentially even delivering a lethal dose. Other devices such as pacemakers are also prone to being compromised and controlled by cyber criminals who want to alter the device’s operation.
To date, our mindset has been benevolent. We trust our suppliers and employees and assume our firewalled internal networks are secure. We believe that we make few, if any, mistakes. We trust that everyone is using devices according to their label and that no misuse of the system is likely. As the hacks and breaches just mentioned show, that trust is misplaced. We can no longer trust or believe that everyone will do the right thing.
understanding of the contrary mindset
To begin combating this epidemic of threats, a new kind of Think around Medical device software development is key to detecting and mitigating how a device can be misused and/or compromised. We no longer have to think in terms of “intended use” alone, but start thinking like a potential attacker. We refer to this new perspective as opposing thinking.
Adversarial thinking involves understanding the attackers unconventional perspectives, arguments and working methods to identify what threats and vulnerabilities they might exploit and how. This way of thinking is not a new concept. It has been a critical component of the US Department of Defense (DoD) product development strategy for decades, influencing how they approach the design, implementation and deployment of military assets and critical infrastructure.
Contradictory thinking does not come naturally to most engineers. Good software engineering focuses on how things work properly, are easy to use and accessible, while the opposing mindset means thinking about how to bypass or circumvent security measures, how to manipulate data and leave no trace. This shift in mindset requires thinking about where the threats may come from within a hospital and beyond: the expected medical staff, the manufacturer’s operations and support staff, or the supply chain and shipping staff – as anyone in the chain can bring a vulnerability, that a hacker can create may exploit. A chain is only as strong as its weakest link.
Integrate Adversarial Thinking into your Security Risk Management process
Typical of regulated markets, the use of analytics, particularly adversarial thinking, is supported by FDA guidelines, industry standards, and structured processes. Capturing the results of this adversarial thinking process is now done as part of the security risk management process. If medical device OEMs adopt contrarian thinking when developing software and combine this new “security mindset” with their security risk management process, they will improve the information security and cybersecurity of their products; and better protect healthcare infrastructures from becoming a source or target of cyberattacks.
Medical device manufacturers must incorporate adversarial thinking into their implementation and execution of their safety risk management process. This process should encompass the entire device life cycle – from requirements and development to decommissioning and disposal. A comprehensive security risk management process must address insider, supplier, and competitor threats. Additionally, the threats assessed should include reasonably foreseeable abuse, which must account for many new and emerging threats given the current cyber vulnerability landscape.
Step 1: Develop a threat model: Identify the assets, threats and vulnerabilities
Consider the entire product lifecycle from supply chain through manufacturing, shipping, installation, maintenance, field service, decommissioning and destruction to create a threat model. Identify which threats and vulnerabilities apply to each asset. Analyze key data flows and identify potential asset exposures at every interface of the system.
Step 2: Conduct an exploits and impact analysis
Based on your threat model, consider what might happen to different assets at each lifecycle stage. What would happen if your medical device was disposed of at the end of its useful life and someone removed the hard drive? What would be disclosed? Would your certificates be compromised? Would your intellectual property be leaked? Would user credentials or patient data be leaked? If your product contains consumables, could that information be shared with someone who wants to make a counterfeit? Could some of your consumables, such as B. an RFID tag, recovered and reused in a counterfeit product to make it look 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 results of the exploit and impact analysis, determine the appropriate security risk control measures required to effectively control the identified risks. Then implement these risk controls in your product.
Step 4: Check the security risk controls
Development and implementation of a risk control review strategy. The audit must demonstrate that the risk controls are both effective and complete.
Step 5: Write the Security Risk Management Report
Finally, write down your report. The report should show the level of effectiveness of the risk controls and identify the residual risk.
An FDA submission requires objective evidence that your product has passed the rigorous requirements of your safety risk management process. It will also require evidence that vulnerabilities leading to potential vulnerabilities have been identified and incorporated into your security risk management process. The artifacts of the risk management process are your objective evidence and the reports provide an opportunity to demonstrate that the processes were fully and effectively executed.
For a medical device that contains software, adversarial thinking combined with early security risk analysis and security-centric software lifecycle practices can be a powerful way to identify and control security-related risks from the very beginning of a project. By designing security from the start, you minimize the security risk of your device and its software.