Medical devices may not be the first priority when healthcare organizations address cybersecurity, but risk managers should make sure they are included in defensive efforts, say cybersecurity experts.

Because of the pressures they face competing for cybersecurity talent and capability investment, hospitals are forced to prioritize only the most critical security functions, leaving them vulnerable to cyberattack when the threat environment changes quickly, says Michael Figueroa, executive director of Advanced Cyber Security Center in Bedford, MA.

Protecting medical devices is difficult because devices rarely are updated due to patient safety concerns and tend to have long-expected lifespans, he explains. Taking a more collaborative approach to cyberdefense would give hospitals more timely awareness of the threats to those devices and help them to incorporate shared intelligence from peers and the broader community to augment limited information from device manufacturers, he says.

In New England, several hospital security directors have established an informal email group list to share their threats and effective practices, Figueroa notes. Engaging with local chapters of security-oriented professional organizations and threat-sharing cooperatives would provide more support, he says.

When more formal legal frameworks are needed to prevent nondisclosure of sensitive security information, hospitals also can join community-level consortia such as the Advanced Cyber Security Center (ACSC) to build private local peer relationships and sector-specific threat-sharing organizations, such as the National Health Information Sharing and Analysis Center, to gain broader situational awareness, he suggests.

End-to-end authentication is the solution to much of the device risk, says Mike Nelson, vice president of IoT security at DigiCert, a company in Lehi, UT, that addresses the validity of all digital connections from secure system login for nurses and doctors to communications between devices, the network, and external databases such as electronic health records (EHRs).

“These connections are two parts in a single system. On the front end, you must verify the identity of any person using a device or accessing patient data, such as doctors and nurses,” he says. “On the back end, it’s just as crucial to authenticate connections between devices and the servers, EHRs, drug libraries, and other resources with which they interact.”

One solution in use involves a public key certificate, also known as a digital certificate or identity certificate. This is an electronic document used to authenticate users, systems, and devices without the need for tokens, password policies, or other cumbersome user-initiated factors. This decentralizes authentication and allows it to happen across disparate systems, Nelson explains.

Security providers can offer single sign-on, multifactor authentication and patient identification to establish trust between users, technology, and the data transmitted throughout the healthcare ecosystem, he notes.

On the back end, some certificate authorities have built infrastructure capable of deploying billions of certificates to connected devices. In addition to providing identity assurance for devices connecting to servers, systems, and databases, these authorities offer solutions for ensuring the integrity of code and the reliability of software updates, Nelson says.

“End-to-end authentication won’t come to fruition in the healthcare industry until device manufacturers, hospitals, insurance companies, software vendors, and security providers recognize their shared responsibility and begin working collaboratively,” Nelson says. “Some leading manufacturers are looking to address the problem before things get too painful or regulation occurs.”

Nelson offers these recommendations to improve medical device security:

• Never run unsigned code. All software running on a medical device should be signed to ensure authenticity.

• Never trust unauthenticated connections. Any service that connects to a medical device should be properly authenticated.

• Encrypt sensitive data. Any patient data generated by the device and transmitted to another location needs to be encrypted to ensure the data are handled in a confidential way.

There is another risk associated with hackers accessing medical devices, says Jonathan Langer, CEO of Medigate, a cybersecurity company based in Tel Aviv, Israel. That risk involves the damage an IoT device breach can do to a hospital’s or health system’s network.

This danger often comes from advanced persistent threat (APT) groups, sophisticated hackers often working for a specific entity like a political group.

“Recent cyberattacks prove that APTs are actively targeting the healthcare sector. We expect to continue seeing such attacks, and therefore it would come as no surprise to see these actors targeting medical devices in order to reach sensitive information or even disrupt patient care,” Langer says. “The healthcare sector should plan and revamp its dedicated cyberdefenses in order to mitigate these emerging threats.”

Anything connected to your network is a potential attack vector for sophisticated hackers, warns Troy Kent, threat researcher with Awake Security in Sunnyvale, CA.

“All that a person with malicious intent needs is one unsecured entry point to then move laterally and access medical devices and systems holding PHI. By the same token, any IoT or connected device, such as personal devices, that’s brought onto the network could become a gateway for hacking medical devices, potentially leading to physical harm to a patient,” he says.

“At the most basic level, security practices like multifactor authentication and network segmentation are necessary. But also enabling hospital security teams to identify and respond to threats quickly,” he says “The challenge here is that these teams are often blind to nontraditional attacker targets like the medical devices.”

It is not always simple to spot malicious intent.

“For instance, how do you differentiate between malicious tinkering with an insulin pump vs. a legitimate change ordered by a medical professional? It all looks the same to the untrained eye, and putting the broader context together takes time and skill,” Kent says. “The good news is a new breed of network traffic analysis tools can identify and profile these devices and then automate the behavioral analytics and threat-hunting needed to spot attacks.”

The Manufacturer Disclosure Statement for Medical Device Security (MDS2) can be valuable in this effort to protect devices, but only if manufacturers fill it out in great detail, says Stephanie Domas, vice president of research and development at MedSec, a healthcare cyber security research company in Miami.

The MDS2 form focuses on security capabilities of connected medical devices. It provides medical device manufacturers with a means for disclosing to healthcare providers the security-related features of the medical devices they manufacture.

The form consists of a series of 84 yes/no questions about 19 security capabilities for the device, with a possibility to add notes at the end of each.

“The form becomes near useless to hospitals if a medical device manufacturer simply fills out the form by answering the yes/no questions, and not populating the notes fields,” Domas says.

For example, with the question “Can the device display private data?” a simple yes/no answer is not particularly useful, she says. The way the form is designed, the need for a related note if the answer is “yes” is not obvious, and even manufacturers with good intentions often treat it as a yes/no exercise with no additional information.

However, when a manufacturer answers “yes” and then populates the notes field with something like “The device displays the patient age on the main screen, and the patient name can be viewed after entering nurse’s credential,” the form is starting to be useful, Domas says.

“The questions in the MDS2 form are good questions that aim to uncover key pieces of cybersecurity functionality a connected medical device may have. But manufacturers who simply provide yes/no answers aren’t providing the hospital with the information they truly need,” Domas says.

“Question 17-1 asks, ‘Can the device encrypt data at rest?’ Many MDS2 forms have been filled out with a simple yes or no, and no associated notes to clarify. While knowing that a device can encrypt data, it’s critical for a hospital to know details such as ‘Does it decrypt data by default? What type of encryption does it use? Is the key unique per system?’”


• Stephanie Domas, Vice President of Research and Development, MedSec, Miami. Phone: (305) 396-6900.

• Michael Figueroa, Executive Director, Advanced Cyber Security Center, Bedford, MA. Phone: (781) 271-5173.

• Troy Kent, Threat Researcher, Awake Security, Sunnyvale, CA. Phone: (833) 292-5348.

• Jonathan Langer, CEO, Medigate, Tel Aviv, Israel.

• Mike Nelson, Vice President of IoT Security, DigiCert, Lehi, UT. Phone: (801) 701-9600.