The Challenges Series - Part 1: Different Perspectives = Different Priorities

Introduction

In an earlier post, we discussed some of the challenges facing Biomedical Engineering departments when dealing with cybersecurity. In a series of posts, starting with this one, we’ll delve deeper into the challenges faced by clinical engineering departments when addressing cybersecurity for medical devices. Hopefully, by identifying some of the issues, we can move towards solutions and improved security for the medical technology we support.

The Biomed-IT divide

One of the fundamental and ongoing challenges is the difference between traditional IT-cybersecurity and Biomedical/Clinical engineering cybersecurity. We have many unique aspects to our operational reality and this can lead to significant differences in how we prioritize our responses to the same threat when compared to our colleagues in IT-security.

The CurveBall vulnerability, CVE-2020-0601, provided a real-world example of this disconnect and offers a good case study to demonstrate why traditional IT cybersecurity usually does not fit for medical devices.

The Vulnerability

I won’t delve into a lot of technical detail here, as it is better covered by some of the references and links below, but will outline the basics of this vulnerability to provide some context for the following discussion.

Microsoft Windows provides a library, crypt32.dll, that allows for the processing of certificates as part of public key cryptography (asymmetric cryptography) used to determine trust and authenticity. The vulnerability in this library made it possible to spoof certificates and have malicious communications or content appear to be from trusted sources. This vulnerability seriously undermined the security provided by using public key cryptography (PKI). In short, this flaw could allow for malicious activity like “Man-in-the-middle-attacks” and installation of malicious content that appears to be from trusted sources. Further, shortly after the vulnerability was announced, proof-of-concept code was available on GitHub, and exploitation in the wild was first reported in July 2021 (or November 2021 according to CISA’s kev catalog).

IT-security’s approach

For a health organization’s IT-security group, CurveBall was a high risk vulnerability with a CVSS score of 8.1. It received significant attention (even the NSA weighed in) and likely was expedited for patching efforts to IT infrastructure and endpoints. This makes sense. You have a significant number of devices that are communicating with unknown sites and devices on the internet and may well be downloading and storing content. All these functions in the absence of a fully working encryption system, or worse yet one that can be erroneously exploited, is fraught with disaster. Furthermore, because spoofed certificates were deemed to be “trusted,” this also makes it difficult for many traditional antimalware tools to perceive malicious files or activity. Though it does appear that some EDR (Endpoint detection and response) solutions can detect potential exploits even on unpatched systems.

So, for a whole host of reasons, the CurveBall vulnerability had IT-cybersecurity departments pulling out all the stops to patch and put mitigations in place until patching was significantly completed. This took significant time and resources to offset this operational risk for devices that fall into the realm of traditional IT. What about medical devices?

Biomed Perspective

First a caveat before starting into the deeper discussion below – we at cy4med.ca are strong proponents of patching any and all medical devices IF a patch is available and the vendor has validated it OR the risk is significant enough to proceed without vendor validation (VERY special case) . Now that’s out of the way let’s continue…

If we take a practical, well-considered, and risk-based look at the threat from a medical device perspective with a good working understanding of the vulnerability, what do we find?

For the broadest case scenario for most of the medical technology that Biomedical Engineering supports, the following list of criteria is usually true:

Medical devices should not connect to the internet.
Have well-defined and constrained communication – all endpoints are known and limited in number and on the hospital’s internal network.
Often function in a “system” with all network communication limited to members of the system and all located on the hospital’s internal network.
Should not be installing software/files with any regularity and NOT from sources other than the OEM.
Any software installation usually done using external media – USB, DVD and not downloaded directly from the internet.

Again, for the broadest case, we can see that these operational criteria serve to mitigate most of the risk associated with this vulnerability. Is exploitation still possible? Of course. Especially if the above criteria are not followed (these will be part of another series on cybersecurity strategies for medical devices).

However, if we have taken reasonable steps to ensure we have implemented basic principles of cybersecurity, specifically tailored to the clinical usage environment, we will have successfully reduced a significant level of risk associated with the CurveBall vulnerability.

This is particularly important for a few reasons:

Workload Impact – Everyone seems to be strapped for resources. Adding emergent cybersecurity patching for a significant volume of medical technology supported by Biomed would add significant workload to already stretched staff.
Buying Time – Medical device vendors take time to perform patch validation and release to their install base. By having lower operational risk to this vulnerability, we have additional time for vendors to perform their internal processes and for Biomed staff to apply patches.
Inventory Review – This will allow us to further reduce our workload impact as many devices we support will not be susceptible or should have significant mitigations in place such that patching can be deferred until routine maintenance is performed.

Conclusion

As we have seen due to the unique nature of the technology we support, with basic security principles in place, the operational reality is that for Biomedical engineering departments, the CurveBall vulnerability was significantly less critical and time-sensitive than for our IT-security colleagues.

Though the result of this particular example was that medical devices should be at lower risk for the CurveBall vulnerability, what was really demonstrated was the difference in operational realities between IT-security and Biomed-cybersecurity. It is only with a good understanding of cybersecurity principles, the medical technology within healthcare organizations, and the threat under investigation that we can make the appropriate risk-based decisions. Traditional IT-security is not best positioned to make those judgments, as this case study demonstrates. Only Biomedical/Clinical Engineering departments with a sound cybersecurity foundation are best positioned to address these daily operational realities.

We would love to hear what you think. Please leave comments below or reach out to us via email. We love to talk security 🙂

Need Help with Cybersecurity? We’re here to help