Dealing with an internet of medical threats

New approaches are needed to tackle cybersecurity risks – and a collaborative spirit in which both industry and healthcare providers acknowledge their responsibility and act accordingly.
By Philipp Grätzel von Grätz
08:36 am

Let’s face it, healthcare IT is no longer about having a bunch of clearly defined information systems communicating smoothly with each other. Today, CT and MRI machines, patient monitors, IV and subcutaneous pumps, ventilators, and even implants, are becoming computers, and are increasingly being connected to an ever more complex IT infrastructure. This ‘internet of medical things’ or IoMT, as it is it sometimes called, has many merits, but it comes at a price. In the old days, cybersecurity was about monitoring a number of clearly defined ports and interfaces, and IT devices could be protected by installing security umbrellas that consisted of anti-virus software and firewall.

This is much more difficult with the IoMT. One reason is that medical devices often don’t feature up-to-date operating systems, but older ones like Windows XP or Windows 95. Many of them use communication protocols that cannot be called modern anymore either. Furthermore, certified medical devices cannot simply be “upgraded” by a hospital with, say, an anti-virus software, because this could interfere with its clinical function and with regulatory approval. 

Manufacturers have to take responsibility

As always with cybersecurity, there is not one solution to tackle the problem of cyber threats in an internet-of-medical-things age. There is an obvious responsibility on the manufacturer, of course. This was illustrated this summer, when Medtronic announced that a number of its insulin pumps feature software problems that make them vulnerable for cyber-attacks. Among the affected pumps were several Minimed pumps with older software versions that are used by ‘loopers’, i.e. type 1 diabetics who connect insulin pumps and blood sugar monitoring devices to open source dosing algorithms in a do-it-yourself fashion in order to build semi-autonomous insulin delivery systems.

In principle, the weaknesses could have led to a situation in which a hacker reprogrammed the insulin pump – a potentially life-threatening event. Nothing like this has occurred, or at least it hasn’t become known. But Medtronic nevertheless recommended replacing the pumps with newer ones. Interestingly enough, this recommendation was only issued in the US. In Europe, the approach was different. In Germany, for example, patients were advised to not pass the serial number of their pump on to others and to not connect the device to third-party software solutions. 

What does that teach us? It teaches us that medical technology providers are willing to take responsibility in case of cyber-threats related to medicinal products. But it also shows that ‘risk for the patient’ is not the only criterion that determines how a company reacts. Local regulatory aspects seem to play a role too. Or is the risk for a diabetic patient in the US bigger than the risk for a diabetic patient in Europe? Presumably not.

The case of the fake lung nodes

With the insulin pumps, there is a clear responsibility on the manufacturer. There is also a certain responsibility on the side of the patient –as is illustrated by Medtronic’s recommendations to users. In other cases, the medical institution is in the driving seat in terms of responsibility to avoid cyber-attacks. Again, there is a good recent example. Israeli security expert Yisroel Mirsky from Ben Gurion University in Beer-Sheva showed early this year that he was able to use artificial intelligence algorithms to modify CT scans of the lung in real-time.

Mirsky went into the CT room of a radiology department and installed a Wi-Fi port that grabbed the CT datasets on their way from the scanner to the digital picture archive. The “hacker”, i.e. researcher, with his computer was sitting in the hospital lobby, and the algorithm that was installed on the computer added or deleted lung metastases to the CT datasets within seconds, before any radiologist had a chance to even take a look at the pictures.

So who is responsible in this case? One possibility to avoid this type of attack is encrypting the data on their way from scanner to picture archive. This encryption is offered by many medical technology companies, but it is rarely used by customers because it takes time and makes radiological workflows more inconvenient. In this case, the responsibility seems to be with the hospital. It could have used encryption but decided to not use it.

Patient safety is about more than cybersecurity

There is a different angle to this latter story though. How realistic is the threat posed by a hacker installing a Wi-Fi port in the CT room? Is the likelihood of this happening high enough to justify a measure that interferes with diagnostic workflows or makes them slower? This question was asked by the German Zentralverband Elektroindustrie (ZVEI), a national industry association of the electronic industry. It issued a position paper in June in response to the recent cybersecurity discussions around imaging equipment, including the Mirsky publication. 

In this paper, ZVEI argues that patient safety has many dimensions, with cybersecurity being only one of them. A gain in cybersecurity can be outweighed by a loss in clinical patient safety if the cybersecurity measure interferes too much with critical processes or slows them down too severely. In other words, risks and benefits of individual cybersecurity measures have to be analysed rigorously before implementing any measure. In the case of the fake lung nodes on CT scans, a proper identity and access management that makes sure only authorised persons can enter the CT room might do the job. It would prevent a hacker from installing a Wi-Fi port without having to active encryption for short-distance data transport between device and digital archive.

Towards platforms and strategies

On a higher level, there are also platform-based solutions that address the issue of connected medical device cybersecurity. Several innovative companies are developing solutions that act as institution-wide early warning systems for cyber-threats related to medical devices. The buzz word for these kinds of tools is security information event management (SIEM), which is about analysing event data in real-time for early detection of cyberattacks.

This approach is taken by some of the ‘big players’ in information and security technology, but also by specialised startups that focus explicitly on the IoMT and on medical providers. An example is Manhattan-based Cynerio that offers a dedicated network-based solution for healthcare providers. It analyses all communication that is getting in and out of connected medical devices in order to understand what the individual device does at any given moment and to detect anomalies. 

In summary, what is true for cybersecurity in general is also true for IoMT cybersecurity. Being aware of potential problems is the first step and implementing a proper cybersecurity strategy is the second one. In a recent web essay on InsideDigitalHealth, Jon Rabinowitz from CyberMDX recommended to assemble cross-functional teams of healthcare and IT professionals to raise awareness for IoMT threats and for security best practices. After having prepared a complete inventory of connected medical devices and their individual risk levels, this team should draw on security professionals to profile normal network traffic activity and to implement controls to detect and prevent threats. Most importantly, every medical institutions needs to be aware that cybersecurity in an age of connected medical devices is not a goal that can be reached, but a process that has to run on an ongoing basis.

This article was first published in the newest issue of HIMSS Insights, which looks at cybersecurity in healthcare. MobiHealthNews and HIMSS Insights are HIMSS Media publications.


The latest news in digital health delivered daily to your inbox.

Thank you for subscribing!
Error! Something went wrong!