The internet of medical things
On average, U.S. hospitals report 10 to 15 connected medical devices per patient bed. Some estimates note that more than 350,000 connected medical devices can be running concurrently in larger hospital systems and that within the next 10 years, more than 50 billion connected medical devices could be in use globally.
All this connectivity carries inherent risks. If hackers gain access to connected medical devices or their communication channels, they might be able to obtain patient data or negatively affect patient health. In fact, compromised devices potentially could cause severe injury or death. The U.S. Food and Drug Administration (FDA) has released several safety communications since 2013 highlighting instances in which connected medical devices were found to be vulnerable to hackers. The vulnerabilities included potential breach of patient data and risks to patients’ health. For example, in 2019, the FDA warned of a vulnerability affecting a number of devices from various manufacturers that could lead to the loss of patient data or prevent devices from functioning.
According to the FDA, when breaches occur, medical device manufacturers (MDMs) are responsible for the security of the devices they produce, healthcare delivery organizations (HDOs) are responsible for the security of their hospital systems, and both MDMs and HDOs share responsibility to address patient safety risks and to ensure the proper device performance. Those responsible for the security of the devices could face federal fines and class action lawsuits if security- and privacy-related events occur, and they ultimately could suffer from reputational damage if such issues become publicly exposed.
IoMT, data storage, and transmission risks
Connected medical devices house and process sensitive information of patients, caregivers, medical professionals, and many others, so technical data protection mechanisms are essential components of medical device security. Particular attention should be paid to the sensitive data storage and transmission risks that they present.
Some examples of these types of risks include accessing data stored locally in memory or storage, transmitting control information, and transmitting data to other systems, such as local systems (like a nurses’ station) or to cloud services and solutions. At each point in these chains, attack vectors exist that could allow malicious or unintentional leaking or access to highly sensitive information.
One of the most common functions a connected medical device performs is transmitting sensitive information to another device or dashboard where that data can be processed in an appropriate manner. Hackers approach the most common transmission protocols for this sensitive information to determine if they can gain unauthorized access to the protected health information via vulnerabilities with the transmission protocol. Healthcare providers most commonly use the transmission standard for sensitive data called Health Level Seven (HL7).
HL7 was developed by Health Level Seven International, a not-for-profit organization that provides frameworks and standards for administering electronic health information. Currently, two major versions of HL7 are in use: HL7v2 and HL7v3. HL7 has been implemented in more than 35 countries, and in the United States, 95% of healthcare organizations use HL7v2. HL7v3 is not as widely used, and it has yet to be formally approved by the American National Standards Institute. HL7v2 provides numerous customizable options when transmitting data; however, customization raises interoperability concerns when sharing data with other organizations. HL7v3’s main function is to provide more structure for the process, limiting the amount of customization needed in order to transmit the necessary information.
Because HL7 is the de facto standard for use in healthcare systems to transport sensitive patient data among different systems, connected medical devices need to have the capability to use HL7, even if that capacity is not by default. Organizations should be aware of HL7’s limits, however. Developed in 1989, HL7v2’s design did not include encryption as part of the protocol because the assumption is that encryption will be performed below the application layer. Therefore, native encryption should be implemented by organizations that adopt HL7 to prevent attackers from sniffing network traffic and extracting sensitive patient information out of the HL7 communication stream.
The HL7 protocol also does not perform integrity checking on data transported between devices. Integrity checking is important because it allows administrators to verify that the data being transmitted does not change when delivered. Without integrity checking, HL7 network traffic potentially could be captured and re-sent with incorrect or modified values of the data that is being transmitted. Falsified medical information sent from a connected medical device could lead to myriad issues for the patient down the line, including incorrect medical diagnoses or a false sense of security if medical data has been modified to make it seem that nothing is wrong.
In addition to HL7, connected medical devices can communicate using technologies such as Wi-Fi, Bluetooth, Zigbee, Z-Wave, radio-frequency identification, and near-field communication. These technologies allow devices to share information using application programming interfaces. They also can be used to manage devices from mobile apps or the cloud. Many connected medical devices, however, do not use the technologies to share sensitive information in a secure manner, including those that transmit patient data or have remote control functions for administering a treatment.
Risk assessments and medical device security
Ultimately, an ounce of prevention can help organizations strengthen connected medical device security and successfully interact with the evolving IoMT world. Through understanding how data and access flow through the devices, supporting applications, and the network and server infrastructure, organizations can mitigate the risk of data loss or exposure.
Each of these components can be assessed in a number of ways:
- First, a thorough risk assessment is critical in understanding where the risk lies for each step in the chain of data and access.
- From there, penetration testing and red team engagements allow specialists to step in and actually demonstrate the risk – that is, attempt to “break” or otherwise misuse the devices as an attacker would and try to capture data and gain inappropriate access.
- In between risk assessments and penetration testing, security technologies can be implemented to provide automated controls that can detect potential misuse or access.
- Lastly, a solid overall risk management strategy strings all of these pieces together and can provide a framework for continual evaluation and improvement to stay abreast of constantly changing security requirements.
Identifying and mitigating risk
Medical devices carry a lot of potential risk in an increasingly interconnected world. Focusing on three main areas – risk assessments and management, penetration testing and red team services, and security solution implementation – can identify gaps, address issues, and mitigate risk associated with these devices.
For related insights on regulations surrounding connected medical devices, read this article.
