By Inhel Rekik & John Rasmussen
May and June 2017 brought additional focus to the security of biomedical devices with the arrival of the WannaCry and Petya/NotPetya ransomware. These malware packages targeted vulnerabilities in the Microsoft operating system including Windows XP, 7 and 8. Many biomedical devices utilize these operating systems and without proper patching or controls in place could have become infected by this malware. Device manufacturers may send notifications to hospitals, or they may receive notification from NH-ISAC or ISC-CERT, alerting them to the risk and providing them with mitigation strategies which included turning off the devices. For hospitals and health systems, shutting off the devices is not an option for many reasons, first and foremost is patient safety. The security of these devices became an imminent threat, causing clinical engineering and information technology departments to shift into high gear to develop mitigation strategies.
This article will demonstrate the importance of medical device security, identify some of the challenges to securing medical devices, recommend strategies and tools for addressing security on these devices, and discuss some of the long term implications of utilizing legacy medical equipment.
Biomedical devices can be used for monitoring patients, delivering direct care, or supporting the patient care process (beds using embedded operating systems are an example). In order to support these functions, the clinical engineering and information technology (IT) departments must ensure the confidentiality, integrity and availability of electronic information stored and utilized by these devices.
Some devices can contain large amounts of protected health information (PHI) which must be protected (confidentiality) in accordance with the Health Insurance Portability and Accountability Act (HIPAA). The Officer for Civil Rights, which enforces HIPAA, provided guidance in July 2016 that ransomware is considered a “breach.” Thus, an infection like WannaCry may require a hospital to notify patients of the breach of their PHI.
The integrity of data on these devices is of utmost importance when provisioning care. A provider relies on the data to be true and accurate from these devices so they can make the appropriate decisions about patient care. Malware infecting a device can accidentally or purposefully alter the data. As more devices feed or receive data directly into the electronic health record, the accuracy of this data becomes more important in the long term care of a patient. An example of this is integrated infusion management where the dose delivered to the patient depends on the patient data the infusion pump received from the electronic medical record (EMR). Corrupted patient information received by the infusion system, such as incorrect patient weight, can result in the wrong volume of drugs being delivered to the patient.
The most important aspect of biomedical device security is “availability.” A device must be available, meaning operating in a normal manner. For devices like ventilators, infusion pumps and defibrillators, their availability is essential for patient safety.
Many devices can be operated as “stand alone” or networked. An incident impacting a hospital network may force medical devices to operate in “stand alone” mode, interrupting an automatic workflow that’s already in place. As a result, clinical staff will need to do a lot of manual data entry and use their downtime procedures. This has the potential of limiting the number of patients that can be treated which results in a loss in revenue and delay in proving care and the appropriate documentation.
Challenges in medical device security
There are many challenges to supporting medical device security; among them are regulatory certification for biomedical devices, vendor support for systems and the lifespan of medical devices.
In the Postmarket Cybersecurity final guidance issued on January 2016, the FDA states that the majority of updates and patches that are released to address cybersecurity concerns are considered device enhancement for which the FDA doesn’t need to be notified. However, if the medical device manufacturer releases corrections to cybersecurity vulnerabilities that can result in patient harm, they need to notify the agency.
This statement can be a source of confusion, however it’s important to understand that the instances where the manufacturer needs to notify the FDA are very rare and that in most cases health care organizations can expect the manufacturer to correct cybersecurity vulnerability in a timely manner.
Other medical devices belong to the category of Internet of Things (IoT) and these bring a whole new set of challenges since they are more vulnerable to cybersecurity hacks
Oftentimes healthcare technology management (HTM) departments don’t support the entire medical device system. HTM does support the medical device but not the entire system which may include servers, infrastructure and information systems that may be supported by IT, third-party vendors or both. If part of the infrastructure is supported by the vendor, the hospital may need to validate that security updates are applied to maximize the security of the system. It’s important to note that if a high availability infrastructure is not set up and in place, a downtime needs to be scheduled at a time with less impact on patient care for security updates to be applied.
In addition, hospitals keep medical equipment in use beyond its supported lifespan. Like other computer equipment, a device that has outlived the lifespan of support will not be patched or supported by the vendor. Special attention needs to be paid to these devices and additional controls applied to protect them from threats.
Building a process to protect devices
A hospital, health system or physician practice should have a sustainable program for biomedical device security. This program must include the HTM department, Information Technology, providers and medical device vendors to ensure a partnership and understanding of the impact of a program. The program must begin with the procurement process and be sustained throughout the medical device lifecycle. It must also take into consideration a rapidly changing IT landscape.
The program should contain elements that include: asset management, contract review, ongoing risk assessment and management, application of security controls and incident response planning.
Asset management is the foundation of an effective medical device security program. HTM departments need to have an accurate inventory of their medical devices that are updated regularly as medical devices are added or removed from service. In addition, some additional data needs to be collected in the asset management system such as whether the medical device has a wireless or wired network connection in addition to the wireless protocol used such 802.11 a, b, g and n. Open ports and communications protocols could be added as well if data is available. Some additional network information such as device network ID, firmware version, software version, MAC address and underlying operating system need to be collected as well. This data allows health care organizations to quickly identify affected devices when vulnerability is known. Knowing which software version is installed on the medical devices can also assist in locating devices that are affected by a recall that affects a certain software version. Barcoding and asset tracking can also help ease maintenance.
Integrating the asset management and asset tracking system will add the location of the medical device to the database. This is especially helpful when locating mobile devices for preventive maintenance or patch/software updates. It is also important to record whether the medical device stores PHI.
Providing expertise to the contracting process will help “built in” rather than “bolt on” security. Legal and contracting departments may not understand the scope of work or contract language around security so it is important to have someone with biomedical and IT security experience review new contracts and contract renewals to ensure that security controls and responsibilities are included and shared with the vendor. When reviewing contracts that are up for renewal the program should consider changes in the security landscape and add them to the contract when applicable. This process will also help identify the responsibilities of the IT department and clinical engineering in securing devices, thus keeping you from scrambling if there is an imminent threat that must be addressed. For example, a clause can be added to the contract to identify the responsible party for installing security patches and updates as well as a replacement strategy when operating system are out of support.
Risk assessment and risk management is an integral part of procurement and of the device lifecycle management. As the environment of the medical devices change, risks should be periodically reevaluated. The HTM department needs to add the cyber risk classification to the basic risk classification as high risk and non-high risk detailed in The Joint Commission Revised Equipment Maintenance Requirements, EC.02.04.01 EP2.
Risk assessment includes evaluating the product upon procurement to determine if administrative, technical or physical safeguards need to be put in place to mitigate the risks. Risk assessments will look at the technology being used and its current vulnerabilities, as well as the type of data and operational use of the equipment. A risk assessment will ask about patching, password management, local data storage, Internet connectivity, device interoperability, remote support, etc. An important part of the risk assessment will be the Manufacturer’s Disclosure Statement of Medical Device Security (MDS2), which should be provided to clinical engineering prior to procurement. The Medical Device Innovation, Safety and Security Consortium can provide health care organizations with a good starting point of the medical device cyber risk and answers the MDS2 form questions. The cyber risk can further be evaluated by looking at all the points listed above.
The risk assessment should also include scanning the device for vulnerabilities and open ports prior to deploying the medical device. Vulnerability scanning should be done periodically within the environment to assess new risks; however, care should be taken to ensure vulnerability scanning is not done when the device is being actively used for care.
Application of security controls should be done as a partnership between clinical engineering, IT and the medical device vendor. This will ensure that there are layers of defense to prevent infection.
EDITOR’S NOTE: This article will continue with Demystifying Medical Device Security, Part II in the February 2018 issue of TechNation.