As medical device cybersecurity has become a more popular topic of conversation among healthcare vendors, Healthcare Delivery Organizations (HDOs) and regulators, several organizations have taken on a “box checking” approach to the solution.
Organizations often feel as if they have achieved cybersecurity when they are able to point to the existence of a device feature or configuration that satisfies each FDA cybersecurity requirement. Nonetheless, there are a handful of crucial areas of cybersecurity in connected medical devices where simple box-checking can leave critical vulnerabilities that can be very expensive to remedy. Here are four areas of cybersecurity where your organization should not take shortcuts.
1) User Authentication: When a vulnerability is identified in a medical device, it is captured in the ICS-CERT database. MedCrypt’s assessment of all medical device vulnerabilities in the ICS-CERT databases found that 43 percent of medical device vulnerabilities were caused by issues with User Authentication. The FDA’s Premarket Cybersecurity Guidance requires that device vendors “limit access to trusted users only,” which is best accomplished by comprehensive user identity and password policies. Past vulnerability disclosures cited issues such as hardcoded user credentials and default passwords.
What device vendors can do: Design devices to use commercial, third-party user authentication systems, like those sold by Microsoft or Okta. This will decrease the probability of vulnerability resulting from poor user authentication.
What healthcare providers can do: Ensure the medical devices on your network are not using default passwords. If you find a default password that the system doesn’t allow you to change to something unique, contact the medical device vendor.
2) Code Review: Another 23 percent of vulnerability disclosures released by medical device vendors between 2013 and 2018 stemmed from “code defects,” including memory leaks, buffer overflows and other inadvertent errors in device performance. Many of these types of software quality problems can be detected during testing - through engineering practices like Code Reviews or by software tools like Synopsys’ Coverity, which performs Static Code Review. While an organization can never completely eliminate these kinds of quality issues, they can be made much less frequent by using proper engineering techniques.
What device vendors can do: Add internal Code Reviews as part of your product lifecycle management process and include Static Code Analysis as part of your product testing cycle.
What healthcare providers can do: Ask vendors to ensure devices you are purchasing have been penetration tested by a third party. These kinds of code defects are the first thing penetration testers search for. As you partner with medical device vendors, ask them for the results of penetration testing and how findings have been resolved - both at the beginning of an implementation and with subsequent updates.
3) Software Patch Management: Most connected medical devices rely on software components not developed by the medical device manufacturer, like Windows or OpenSSL. Vulnerabilities are found in these pieces of software regularly, leading to software upgrades. When medical device vendors fail to patch these vulnerabilities, or when providers fail to install them, this can leave devices vulnerable to non-healthcare specific security problems, such as 2017’s WannaCry Ransomware attack.
What device vendors can do: Ensure that patches for software components (like operating systems and open source libraries) are included as part of your regular software update releases.
What healthcare providers can do: Ask medical device vendors for a Software Bill of Materials (SBOM) and monitor the CVE database for vulnerabilities relating to the component software in your devices.
Note: The benefit of a SBOM has been debated by cybersecurity experts, and having HDOs compare each SBoM line item to the CVE database is almost an impossible task. I hope to see device vendors take a proactive approach to releasing software patches, and HDOs be diligent about applying them. This is a much more scalable approach to the problem.
4) Enabling Encryption: Few would disagree that data sent over a hospital network, as well as data stored on devices, should be encrypted wherever possible. Many devices have begun using encryption through a communication protocol like HTTPS/TLS, or the latest Bluetooth implementation. The challenge becomes ensuring that these technologies are implemented properly, and that vulnerabilities in the underlying technologies are patched regularly.
What device vendors can do: Use commercial encryption tools, like those sold by MedCrypt, and ensure you are not using self-signed certificates. Be sure you are generating unique keys on each device, and not using the same encryption key(s) on every device.
What Healthcare Providers can do: Ask medical device vendors about the encryption features of their devices during the purchasing process. Let vendors know that security is a feature you care about, and not simply a regulatory requirement.
No computer system is 100 percent secure, and it’s tough to know when you’ve done enough to fully secure any given device. With this in mind, we can find hope in looking back at the common denominators of medical device cybersecurity vulnerability disclosures over the last five years to help us understand the best areas to place our focus, ensuring we do everything in our power to keep our devices secure.