Medical devices: Embedded product security

In working as an security architect, I’m occasionally shocked at what I find.  I interacted with some families of clinics that were purchased. After purchase their clinic applications were integrated into the parent healthcare firms security and IT infrastructure.  The clinics then adopted security processes and tools of the parent healthcare firm. The clinics have a variety of generally older IT solutions, EMR applications, medical devices, and low bandwidth broadband access. Let’s focus on clinic vulnerabilities.

One set of vulnerabilities related to clinics was frightening.  It was the prevalence of medical devices that are on open networks.  Some of these applications are running very old versions of Windows. The medical devices were tested and debugged with these vulnerable operating systems years ago. Upgrading the operating system could lead to some risk – could it make that application unstable?  It is possible that the application needs to be rewritten to run on a newer operating system and network protocols.  Would the application need to be certified again?  Also, would all of devices deployed all over the global need to be upgraded?

Proper network scanning of all corporate networks leads to interaction with medical devices on corporate networks. There is a fear that scanning, which is like a network probe, could knock a medical device offline. So scanning is recommended for offline hours so that it cannot happen when a patient is using the device. But foreign agents that are attacking these networks can compromise a medical device during the day potentially affecting a patient in real-time!

Also the medical devices that were developed by outside vendors often have a private network that allows for vendor access to each device. Depending on how this network is integrated, it is possible that a vendor could access the main corporate network behind the firewalls. I’ve discussed this weakness with a Red Team white hat hacker friend and I would recommend two different solutions: isolate medical devices on the vendor’s network and keep them disconnected from all other corporate networks. There should be no access to the parent company’s corporate network.

What about connecting to medical products that have communication systems that run in the body? Minneapolis/St Paul has many medical product vendors and some vendors have medical devices that can be accessed via RF technologies. Medical device vendors want to communicate with critical devices all the time so they can see patterns of medical device operation that may be detrimental to a patient’s health. Protecting this ongoing HIPAA patient data is a challenge. A PKI expert friend of mine designed real-time protection of a medical device’s patient data many years ago so that sensitive data can be protected properly.

I read on a blog that when Vice President Dick Cheney was in office the national Secret Service team was concerned about RF attacks because he had a pacemaker. Imagine dealing with that responsibility. Early in my career I wrote software, I was approached by a major medical device vendor about writing portions of the kernel for their embedded devices. I was unnerved about having life or death possibilities being impacted by the quality of code I wrote, so I turned them down. Knowing more about how the hardware would assist in keeping the device in operation, I would now be willing to write the software.

We’re entering the wild, wild west when facing medical device security. The last thing I want to see is hastiness in regards to medical device operations. We could use some leadership in this arena from medical device vendors, network and wireless communication vendors, and entities that use the medical devices. We can’t afford to make InfoSec mistakes in this arena because lives are surely on the line. Let’s proceed with caution.