By Steven Hughes
Organizations in the health care and public health sectors are facing an increasing number of ransomware attacks, often leaving hospital networks vulnerable. The U.S. Department of Health and Human Services (HHS) received reports of data breaches from 578 health care organizations in 2021, impacting over 41.45 million individuals. In 2022 (as of this writing) 31,705,618 patient records have been exposed or impermissibly disclosed in 63 reported incidents of 500 or more records (with a 28.3% increase month over month with an average of 59 breaches a month of total breeches) indicating that cybercriminals intend to continue carrying out cyberattacks against the health care sector in 2023.
The majority of reported data breeches resulted from unpatched or unsupported systems of known vulnerabilities. One of the largest hurdles in HTM is keeping your current and legacy systems updated with the latest in patches and updates not only to the core operating system but also the applications that run on it and their background dependencies required to run that software. Having a real time inventory of this helps but is near impossible without having an installed agent or third-party software to track this. Most healthcare delivery organizations (HDOs) often have to rely on automatic patching if approved by the medical device manufacturer (MDM) and if patches are still available. To add another layer of complexity is that new equipment is being purchased and added to the hospital network without a policy in place to denote future support of the OS, software and their dependencies. This action can be problematic and produce further work in the future. Even worse, it can increase the risk of your organization to ransomware attacks, exposes patient data and risks to patient health.
GET IT IN WRITING
HTM should work with their C-suite management and contracting/purchasing department to develop contracting language to prohibit the procurement of systems with unsupported operating systems. Unsupported operating systems are OSes that are not supported by the manufacturer and have reached the end of the OS life cycle as published by the OS manufacturer (i.e., no further security patches will be released for the OS by the manufacturer after the OS end of life nor will be available by other methods such as extended warranty purchases from the OS manufacturer). In your contracting and purchase contract language there should be mention that, if a newly acquired medical device runs an unsupported OS, the medical device vendor must provide a support plan for the device (i.e. purchase of extended warranty from the OS manufacturer, an upgrade path to a supported OS during a set defined period of time, etc.) prior to deployment of the system. At the time of purchase, this information should be documented by the HDO’s information security officer (ISO) so they are aware and have that acceptance of risk until it meets resolution as stated in the contract before being allowed onto the hospital network.
USE ESTABLISHED BUSINESS PRACTICES
There are some great resources provided by Healthcare and Public Health Sector Coordinating Councils (HPH SCC). One is called the Model Contract-language for Medtech Cybersecurity at healthsectorcouncil.org developed by the Cybersecurity Working Group consisting of 30 organizations in health care delivery, medical technology manufacturing, group purchasing, servicing and consulting which was then reviewed by over 320 organizations for feedback and modifications.
The model contract language contains several security and privacy agreement clauses based on industry best practices where, “Both parties need to understand their responsibilities to each other in protecting the privacy and security of the health care systems they will connect and the information required to service, store and transmit. In addition to assigning specific responsibilities to MDMs, the model contract language outlines security safeguards, including security by design, medical device software maintenance, access, administrative, operational, technical requirements and transparency.”
Utilizing the model contract language provides HDOs contract terms that can be used as a standalone agreement of the HDO cybersecurity requirements for all contracted medical devices, services, connections and solutions. It can also be used as an addendum to already existing documents such as business associate agreement (BAA), master service agreement (MSA) and requests for proposals (RFP) for new and replacement medical systems if systems have reached end of support or end of life.
SUPPORT FOR THE UNSUPPORTED
Compensating controls (network isolation via ACLS/firewalls limiting network traffic in and out of the medical device to only devices needing connection using specified ports and protocols) should already be in place for medical equipment that runs an unsupported OS. However, it is expected that this equipment will be upgraded as soon as upgrade paths are available from the manufacturer or replaced by the end of its life cycle. For your existing systems that are running outdated or unsupported operating systems HDOs, you should develop plans when systems will be upgraded or replaced to supported OS/system as part of device life cycle planning. This should be reviewed minimally once a year with an outlook and planning based on future EOL/EOS dates that have known EOL/EOS dates and reviewed with management to make sure funding and resources are available.
Some medical devices may require extensive pre-planning especially if new construction or modification to building infrastructure is required as part of that upgrade/replacement and alternative temporary stop gap solutions like temporary trailers/buildings or outsourcing of clinical services must be factored in the upgrade cost and timeline of the project. On-premise software and hardware isn’t the only thing that needs to be considered. Potential cloud computing maintenance and end of life issues such as security and support from cloud service providers, Software as a Service (SaaS), Platform as a Service (PaaS) must also be considered and included in forecasting maintenance and life cycle management.
One thing to be keenly aware of is that most medical systems which run a version of Microsoft Windows must know that there are several different builds or feature pack updates associated with the Windows OS. Some of these builds are already end of life and no longer receive patches from Microsoft. Where possible, medical equipment running a Windows 10 OS should use the Windows 10 LTSC (Long Term Servicing Channel) version (the same holds true for Windows 10 IoT as well with Windows 10 IoT LTSC) which are guaranteed to receive patches and updates for 10 years after their initial release date. Your MDM should be able to confirm what version is safe to run on their system. It is good to keep up regular communications with your MDM when major releases of Windows become available.
Another consideration is inquiring with your MDM on a possible EOS extension contract allowing for continued software, OS and appliable hardware updates for an agreed upon duration and trade-in programs that can allow an HDO to replace medical devices partially or fully at discounted rates that helps mitigating life cycle costs and having knowledge of a known planned cost for future budgets.
If you are not doing this, you should also consider operating system support as part of life cycle planning for networked medical devices and systems. Operating system end of support should be a priority in your decision making when prioritizing the replacement of certain devices earlier than the standard equipment category life expectancy may indicate. This is akin to eating food with an expired expiration date or using medical supplies and medications beyond their date of safe use.
End-of-life hardware and software pose a huge cybersecurity risk to all organizations around the world. However, with an adequate understanding of the risks involved, advanced planning and help from medical device inventory tools can identify and migrate away from end-of-life hardware and software. You can have a plan for continued support of medical systems through an orchestrated response of established workflows and processes that will continue to evolve and grow with the organization.
Steven Hughes, FAC-COR FACP/PM VHA-CM, is a VISN 21 Biomedical Engineer in the VA Sierra Pacific Network.
