Medical Device Security in a Hospital Network

Thursday, July 28, 2011

Danny Lieberman

959779642e6e758563e80b5d83150a9f

Medical devices are everywhere today.  In your doctors office measuring your blood pressure, at your cosmetician (for hip reduction…) and in the hospital for everything from patient monitoring to robot-assisted surgery.

The people that develop embedded medical devices based on Intel platforms know that Windows is vulnerable.

Lacking embedded Linux know-how, medical device developers often end up adopting Windows and Visual Studio as a default. Using Windows is a security-blanked for developers who grew up the Microsoft monoculture and are scared of the Linux command line.

But – make no mistake using Windows in networked embedded medical devices is a mistake.

This is big mistake #1.

The top 2 threats to a medical device are software defects and software updates. Consider the implications of updating patient monitoring devices in a hospital with an infected USB stick or an infected Windows notebook.

In product development (and medical device are  no exception),  the support and version update process  is often something  left for the end of the project. At that point, when the product manager asks how are we going to update the software in the field – the hands raise in favor of  USB memory stick updates as an “interim” solution.

It is crucial to use threat analysis on systems of networked medical devices in order to arrive at the right, cost-effective countermeasures (apropos the management challenge of large number of VLANS…). Threat analysis must be an integral part of the SDLC (software development life cycle) – done early in the process and validated from time to time whenever there are significant design, configuration or environmental changes.

Threat analysis enables a medical device vendor and the hospital security team to have an objective discussion on balancing the need to protect the hospital network asset with protecting the availability of the medical device  itself and concomitantly – the safety of patients that are dependent on the device – patient monitoring is the first example that comes to mind.

Unfortunately many device vendors and their hospital customers use a system management model based on Microsoft Windows and business IT management practices. This is big mistake #2.

Medical device vendors need to assess their software security and not assume that an embedded medical device running Windows XP  is no different from any other Windows PC on the network running Office 2007.

To use an analogy from the world of real time embedded systems – consider avionics as key to safety of the pilot and success of the mission. Avionics are not managed like a network of Windows PCs and neither should medical devices on the hospital network.

A medical device in a hospital network – whether it monitors patients, assists in surgery or analyzes EEGs – is an embedded device in a extremely heterogeneous and hostile environment that should simply not be vulnerable to Microsoft Windows malware.

Embedded medical devices should be based in embedded Linux – and not a stock version of Red Hat – but rather built ground up from the latest Linux kernel, with the minimum set of services and software (Qtk etc…) needed to run the application.  The software update process should be part of the design – not something bolted on after the implementation.

Developing for embedded Linux is not copy and paste from Windows. It requires expertise to setup the basic infrastructure.  But – once that infrastructure is up, the medical device developer and it’s hospital customer can be confident that they are standing on a secure platform and not a house of glass built on a foundation of sand.

Cross-posted from Israeli Software

Possibly Related Articles:
16399
Network->General
Healthcare Provider
Windows Linux Healthcare Network Security Medical Devices Hospital
Post Rating I Like this!
Default-avatar
Chris Dorr " But – once that infrastructure is up, the medical device developer and it’s hospital customer can be confident that they are standing on a secure platform and not a house of glass built on a foundation of sand"

Er...no. Unless it is deeply audited at the beginning. And never patched. And never modified. And never deeply hooked into by an application.

I love Linux and use it daily, and have (long ago) developed for both. but the reality is that it is security design and coding practices that drive the security of the end system, not the OS per se. Despite the protestations of fanboys, when developed and managed properly, Windows (including WinCE), Linux, OSX and most other mainstream systems are basically equally secure.

Developing based on a secure embedded Linux core is great. I fully agree. But there are security tradeoffs everywhere...make it difficult to communicate among medical applications (I currently work in Healthcare IT), and the user does what users always do...they move to an easier way. So suddenly, that very secure multi-factor authentication infrastructure you designed gets replaced by a quick email, because the nurse forgot her token.

Security is a process. While I am not disagreeing with your emphasis, medical devices in a network ARE part of a network. They exist to do something with information and move it somewhere. The "most" secure application is one running on a locked system, in a vault, in a locked bank, connected to nothing. But as soon as the information that system captures has to be communicated, then you have security problems, regardless of whether it is developed on Windows 98 or Bastille Linux.
1312212044
959779642e6e758563e80b5d83150a9f
Danny Lieberman Chris

Note my use of the word "platform". By adopting Linux for an embedded medical device, we have a much better chance of creating a secure basis for the application.

I totally agree that security is a process. If you make changes, open ports, introduce connectivity and software bugs, the application acquires new vulnerabilities that can be exploited by new threats.

I am familiar with the argumentation that one can develop a secure application in Windows and indeed we have done so a few times in the past. It can be extremely difficult and expensive and certain things that can be done relatively easily in Linux (like building an embedded system on the kernel and a main loop) cannot be done at all in Windows.

Because medical devices are part of the network, they need to be designed to be devices that can function on their own, securely and reliably in a hostile environment without all kinds of third party anti-viruses and systems management software.

Unfortunately, the Microsoft monoculture has deeply influenced the way systems are not only developed but also maintained.

And as I noted in my post, it's incorrect to maintain embedded medical devices in a heterogeneous hospital network using IT management techniques.

Medical device vendors need to put survivability and ruggedness of their devices in front of the ease of development canard that Microsoft Visual Studio developers have fallen for.

The security of the device is in a very simplified way, a function of 3 basic layers: the OS, the software application itself and the software update process. It would be incorrect to look only at the OS and say "Sure I can build a hardened version of XP embedded"

1312221014
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.