Are you checking off medical device security in your hospital with anti-virus: falling for security theater; feeling secure and enjoying the show, but in fact being less secure?
A medical device is not an office PC
The most commong security countermeasure in use today is anti-virus software for Windows-based workstations to protect the Windows PC from malicious software from removable devices, email, and Web channels. ( I will refrain from religious debate on Mac vs. Windows vs. Linux).
However – the traditional consumer/IT enterprise anti-virus is not an effective security countermeasure for medical devices in a hospital.
The majority of medical devices on a hospital network don’t have network connectivity.
Without network connectivity, ongoing update of AV software and signatures is impractical for the medical device vendor since it require regression testing and update of units in the field.
Without network connectivity, the devices cannot be managed by a central system like McAfee ePO and in a best case run outdated engine and AV signatures. In these cases the anti-virus is worthless, and the result is security theater: feeling secure and enjoying the show, but in fact being less secure. Without central endpoint or network monitoring we do not even know if the medical device was infected.
What do hospitals and medical device vendors do?
Some hospitals are sticky about a particular AV package and as a result big device vendors like GE have gone to the trouble to validate all major AV vendors on their networked devices.
Other hospitals take a more calculated and risk-driven approach with their medical device vendors and evaluate the threats and vulnerabilities.
A risk-driven approach, based on achieving cost-effective medical device security is precisely what the FDA requires in it’s latest draft guidance for medical device cyber security
However, the business case for a customized security countermeasure portfolio for each medical device vendor is weak to say the least and it is a fair assumption that both medical device vendors and hospital security and compliance groups prefer a vendor-neutral standards-based solution for preventing malicious software that attacks the medical device on their hospital network.
While an anti-virus is standard, it is not vendor-neutral and even when installed it is probably worthless since the medical device doesn’t have network connectivity.
In broad terms – there are 2 key use cases for medical device security:
Embedded medical devices such as bedside monitors
An embedded medical device vendor may select Linux (for example Debian or Ubuntu) as the target operating system and by deactivating USB access and controlling the code carefully – may create a secure medical device which is extremely hardened to Windows-based malicious software. In this case – medical device security doesn’t require an anti-virus.
System level medical devices such as MRI that run Windows
These are many larger Windows-based medical devices that integrate a large software application with special hardware and integrated interfaces to other systems on the hospital network (such as PACS) – examples are MRI.
A medical device that runs Windows will definitely need to deal with threats of malicious software attacking the medical device via USB and launching an attack on the hospital network – attacking patient privacy and availability of resources such as PACS servers.
Manual anti-virus updates are a threat to medical devices
Since the device doesn’t have Internet or enterprise hospital network access, IT administration will need to manually update the devices’ anti-virus engine and signature file using removable media – which creates an additional vulnerability of a infected Flash disk devices infecting the device and propagating malicious software back into the hospital network. So – manual updates are a bad idea.
Effective protection against malicious software in medical devices should work without requiring centralized network connectivity (unrealistic for the hospital) and installation of anti-virus agents (unrealistic for the medical device).
If you are developing an embedded device – you are better off with Linux.