Medical Device Security: The Basics and 4 Best Practices

What is Medical Device Security?

Medical device security refers to practices and techniques that can prevent attacks against medical devices. Attacks may involve unauthorized access or control of medical devices, or exposure of the sensitive data they generate.

A good starting point for securing medical devices are the FDA guidelines for medical device safety, and guidelines by the European Union Agency for Cybersecurity (ENISA). These are not formal compliance requirements—they are provided as recommended best practices.

Information security for medical devices can be considered a subcategory of IoT security. However, there are significant differences between regular Internet of Things devices and medical devices:

• Attackers gaining control of medical devices can do great harm, and in some cases may be life-threatening.
• Information on medical devices is extremely sensitive, and in most cases constitutes protected health information (PHI), which in the USA is regulated by the HIPAA standard.
• Medical devices are long-lived, and it can be extremely difficult to upgrade them or install security patches, as this may interrupt the critical functioning of the device.
  

In this article, you will learn:

• Who is Responsible for Medical Device Security?
• Medical Device Security Challenges
• Best Practices for Medical Device Security
• ‍Endpoint Protection
• ‍Identify and Access Management
• ‍Asset Management
• ‍Vulnerability Management

Who is Responsible for Medical Device Security?

In a large healthcare organization, the IT department is generally responsible for the security of medical software and devices. However, IT staff need the expertise of biomedical engineers to understand the clinical use and operational parameters of the devices. When devices are outsourced, this communication becomes more complex.

A new trend is that biomedical engineers become part of the IT department, which fosters collaboration. Some healthcare organizations are establishing a new position—medical device security engineers, who are supposed to assume responsibility for device security across the organization.

However, in reality, even a dedicated security engineer role cannot have complete knowledge of medical devices in all departments—fields like radiology, oncology, cardiology, and pediatrics have their own specialized devices. This makes it difficult to define and implement a consistent security strategy.

Medical Device Security Challenges

A medical device is very different from a standard PC. It is a fixed-function device with customized software—installing new software on a field system typically requires a special upgrade process or is not supported at all.

Medical devices are optimized to reduce processing cycles and memory usage, and so they often lack the resources to run additional software beyond their core functions. Security solutions designed for PCs are, in most cases, not applicable to medical devices.

When securing medical devices, here are some of the main challenges:

• Devices are critical—many medical devices are life-supporting, affect critical patient care or manage highly sensitive data.
• Standardized configuration—unlike PCs, which may have different software or hardware configuration, a medical device is typically produced in thousands or millions of units with exactly the same software and hardware setup. A successful attack on one of these devices can be repeated across all devices.
• Non-secure design—many medical devices were engineered under the assumption that products are not exposed to security threats, and security was not seen as a top priority.
• Patching restrictions—updating medical devices is not easy. After deployment, they will typically only run the initial factory-installed software, and any change must be performed carefully in consultation with the manufacturer.
• Long living devices—medical devices are often deployed for as long as 10-20 years, far more than the average lifetime of a PC. Even if security was taken into consideration when the device was built, it is difficult to protect against security threats decades into the future.
• Insider threats—medical devices are regularly accessed by medical staff, and a malicious insider, or a compromised user account, can lead to theft of data on the device, or illicit control over the device.
• Deployment outside security perimeter—some medical devices are moved to other locations or deployed in patient’s homes, outside the protection of the corporate network.

4 Best Practices for Medical Device Security

Follow these best practices to improve the security of medical devices in your organization.

Endpoint Protection

Security is important not only for medical devices themselves but also for information systems and endpoints they connect to. For example, MRI machines typically connect to several workstations that enable operators to work with MRI images. The MRI, its workstations, and other integrated systems like a picture archiving and communication system (PACS) may be vulnerable to attack.

To protect these endpoints, medical device manufacturers must directly support antivirus software. If antivirus cannot be used, alternative measures should be taken, for example to require an extended SBOM integrity verification each time the device is sent for maintenance before it is reconnected back to the network.

Medical device data must be encrypted, both at rest and in transit. If the device has removable storage, and removable storage cannot be encrypted, it is recommended to prohibit the use of removable storage media. There are also dedicated security solutions like endpoint detection and response (EDR) and XDR that can help introduce visibility and protection.

Identify and Access Management

If supported by the manufacturer, the device must bind authentication to the corporate authentication system. This will automatically control access to the device using appropriate user roles. Ensure that passwords are always changed from the default, and ensure users set long, secure passwords specific to each medical device. If possible, limit the number of retries on login failure.

Asset Management

The organization should maintain an inventory of medical devices, listing critical devices, their operational properties and maintenance schedules. In addition, there should be a software component inventory, including vendor-developed software components and operating systems, indicating version numbers.

Based on this inventory, take risk-based decisions about devices or software that are nearing the end of support or have significant security vulnerabilities. Consider replacing such devices as part of the organization’s purchasing cycle.

If financial or other obstacles prevent the organization from replacing old equipment, take other measures to protect the device, such as isolating it from the network or establishing monitoring to detect cyber attacks.

Vulnerability Management

The organization should review vulnerability disclosures by vendors, and conduct their own vulnerability assessment of the software deployed on medical devices, using sources like the national vulnerability database (NVD). Note that vulnerability scanning typically cannot be conducted when a device is operational, and it is best to perform it when the device is first procured as part of SCA and SBOM analysis. Once SCA is performed the security posture of the device is determined and it is imperative to continue monitoring the vulnerabilities affecting the SBOM.

Assess the risk of vulnerabilities on operational devices, and work with manufacturers to correct or mitigate each vulnerability based on the level of risk. If a vulnerability cannot be addressed, steps should be taken to isolate or otherwise protect the device.

Unmanaged risks should be reported to relevant stakeholders at the medical organization, such as legal and compliance departments.

Medical Device Security with Cybeats

Looking at embedded devices is quite different than looking at servers in the IT space, it is common that there is no packages or information on the device to tap into for identification of assets to perform security analysis. Based on our vision that follows the FDA recommendations, medical device security has 2 main phases, the first phase is pre-market and the second is post-market. The approach to device security is fundamentally different at every phase. It is imperative to have proper mechanisms and controls built-in and not bolt on the device from the early stages to mitigate the risks of every phase in the device’s lifecycle, especially if the device is mission critical and human lives might be at stake due to its failure.

During the development phase of the device, security focus is required on multiple aspects such as hardware security, identity of the device, cryptography and vulnerability analysis and assessment activities of its components. Companies are using various tools and open source projects to achieve results on this multiple aspects. To get to significantly successful results is complex when we don’t have unlimited resources and effort we can put into this part of the development work. The first stage in a successful security program is to gain visibility into the device’s SBOM (Software Bill of Material) and runtime context as fundamental capabilities.

Once we achieve that we can advance to continuous vulnerability monitoring, security gap assessment, and most important vulnerability prioritization aka VPT. We can’t stop here. We need to be able to perform this every time when we change even one line of code in our application or change in a library and it has to be done for every device model in our product lines and every build of the firmware we are talking about potentially hundreds of such assessments per day. This can be achieved by DevSecOps approach and adding this to the CI/CD pipeline continuously modeling the device’s security posture while correlating the data with threat intelligence and vulnerability information and mostly deep knowledge of the device’s operational context to understand the threat relevance.