Hospital Networks are the next big target for hackers?

Medical Device Security in a Hospital Network

Medical devices are everywhere today. In your doctors office measuring your blood pressure, at your cosmetician (for hip reductio) 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.