WannaCry ransomware reminded healthcare organizations how vulnerable they are to cyber threats and how unprepared they are to handle and recover from them. The immediate reaction most had was to disconnect all devices from the network and use downtime procedures. However, it became obvious almost immediately that clinical practice is heavily dependent on certain automatic workflows and that hospitals aren’t ready to reverse back to manual procedures for more than few hours and take the hit on the decrease of revenue.
Most healthcare technology management (HTM) departments weren’t prepared for this increase in workload that was prompted by this worldwide attack. Very few have medical device security specialists or have enough resources to perform the remediation work that was required. In addition, no healthcare regulatory body has dictated any recommendations to HTM departments about medical device security akin to Joint Commission regulations for alarm management and medical equipment preventive maintenance. The primary focus has always been on projects, daily operation and trying to keep legacy devices that have outdated operating systems and software running until funds are secured to replace them.
In addition, clinical engineering often doesn’t have the necessary security documentation about medical devices that are brought into the organization, which should have been collected before the medical device is bought and placed into production by the organization.
However, when WannaCry infected a Medrad injector in the United States, it made medical device cybersecurity a reality. It reminded health care organizations how vulnerable they are and how unprepared the medical device industry is.
Health care organizations have taken different approaches as a response to WannaCry. The first line of defense for most was to disconnect networked medical devices if there is no impact on patient care or workflow such as the case of the injector.
Some chose to perform a network scan to determine vulnerable medical devices prioritizing high risk equipment. If the network scanning tool used is based on IP addresses provided by the HTM department, scanning Dynamic Host Configuration Protocol (DHCP) networked devices can be time consuming since the medical device need to be powered on and capture an IP address that then gets handed to the network security team for network scanning. For devices that are determined to be vulnerable, manufacturers were contacted for released patches. For the vulnerable devices with no available patch, the network security team had either decided to put them behind a firewall or use other mitigation tools such as network segmentation.
Some organizations have bypassed network vulnerability scanning, grouped their devices by critically meaning impact on patient if the devices are infected (high, medium, low). They then contacted vendors to determine impacted medical devices and when a patch will be released starting with high-risk category. After patch installation or the use of mitigationtools, residual risk was presented to senior leadership for risk acceptance.
Others determined that the risk of infection was too high and chose to accept the risk and install available patches prior to having the approval from medical device manufacturer and could have experienced some issues with malfunctions. Disabling port 445 with or without manufacturer’s approval is one thing that was done if it has been determined that there was no impact on the operation of the medical device. In summary, each health care organization has a different comfort level with the risk that they are willing to accept.
This incident demonstrated that applying security patches to medical devices can be challenging. It is often unclear who is responsible for performing software patches for medical devices (Biomed or OEM). In addition, when a patch is released for an operating system, it’s oftentimes not validated to be used with the software version running on the medical device. In many cases, the patches cannot be installed until the manufacturer validates and tests the patches. In this case, most device manufacturers didn’t have their patches tested and deployed in a timely manner in order to address this vulnerability even though it has been known since March 2017. Clearly identifying patching responsibilities in contracts and service agreements will help clarify Biomed versus OEM responsibility.
Based on this incident, how many health care organizations will move toward having a more elaborate medical device security plan?
Inhel Rekik is the Clinical Engineering Manager at MedStar Georgetown University Hospital.