Internet of Medical Things: Combatting Connected Health Security Threats
Guest WriterGuest Writer
The healthcare industry increasingly relies on IoT networks to securely connect a growing variety of medical devices and equipment. These connected devices are transforming processes and the continuum of care in applications ranging from a hospital’s consignment inventory management to remotely controlling insulin pumps, heart-rate monitors, and other implantable devices using smartphones.
With the Internet of Medical Things (IoMT) applications, device security is often neglected. This challenge can be solved through a three-tiered “security-by-design” strategy.
In these and other Internet of Medical Things (IoMT) applications, device security is often neglected. Some solution providers mistakenly believe that security cannot be implemented cost-effectively, which is hazardous thinking. The industry moves to a command-and-control model using commercial smartphones whose built-in security mechanisms are generally not adequate for safety-critical applications. These and a wide variety of other IoMT challenges can be solved through a three-tiered “security-by-design” strategy that protects all communication between system elements, brings trust to each system element, and ensures “always-on” connectivity between smartphone apps, the IoMT devices, and the cloud.
Cyberattacks or IoMT integrity issues for connected implantable medical devices have unfortunately become more and more prevalent. One of the first examples occurred in May 2019 when a Type 1 diabetes patient re-programmed his insulin pump to customize his treatment and landed in the hospital. He had exploited a security flaw in his commercially available, FDA-authorized device that, according to the FDA’s safety warning, could pose significant risks if patients did not correctly implement their own treatment customization.
This same type of safety flaw also provides an open door to hackers, enabling them to access a device whether to cause harm or steal sensitive health information. Some of these same devices require the patient to change a device component, or “consumable,” over the device's lifetime. The consumable itself poses a new threat opportunity in terms of counterfeit replacement or integrity.
Another popular application for IoMT solutions is hospital asset tracking so that equipment is always available and accessible, and one of the most promising is consignment inventory management. Vendors increasingly sell products, equipment, and associated consumables to hospitals on consignment, issuing invoices only when items are used.  Further, OEMs need to ensure that the consigned inventory is maintained to the OEM requirements such as temperature, humidity, and other environmental factors before being utilized in inpatient care.Â
In the past, all information about these items was manually entered, from their receipt at the hospital to their use and re-stocking. Adopting an IoMT solution for these processes reduces errors while improving efficiency, but security is critical for ensuring the integrity of the supply chain and all financial transactions.
Equally, if not more, important is the authenticity of this hospital inventory. Johnson & Johnson said in its June 2020 document, “Position on Counterfeit Healthcare Products,” that “Counterfeits cover the spectrum of medicines, both prescription and OTC, as well as different forms of medical devices and surgical instruments and a range of consumer products...” The company went on to say that, in many cases, the fake or counterfeit products”...are indistinguishable to patients, consumers, and healthcare professionals, so detection by specialists is needed.”
A high-profile example is personal protective equipment (PPE), whose supply has been plagued by counterfeiting during the global pandemic. Healthcare providers must defend themselves against this risk while also ensuring the proper use of all legitimate medical equipment and consumables, whether they be controlled substances that must be correctly dosed to the intended individual or x-ray plates that must be used with a given imaging system for a specified patient.
Every piece of connected equipment inside the hospital is also a cybersecurity threat surface. Cybercriminals can use legacy equipment like MRIs and other wired Ethernet medical systems ranging from anesthesia machines to ventilators and infusion pumps as a means into the hospital’s core communications network. Many of these systems were produced long before cybersecurity was a critical consideration. Connecting them to the hospital network can open the door to a variety of cybersecurity attacks.
The danger grows with the adoption of commercial smartphones for controlling connected-health solutions. The devices’ Bluetooth wireless connection does not provide adequate security. Mitigating these threats requires a multi-layered, security-by-design approach that minimizes cost while simplifying deployment.
Each of the applications described thus far requires multiple layers of protection, especially those that use smartphones for command and control in life-critical situations. While it is true that Bluetooth, NFC, LTE, Ethernet, and other protocols mitigate some breaches, they do not defend against all threats. Therefore, it is necessary to start at the application layer, protecting the communications channel between the smartphone app, the medical device, consumable (if applicable), and the cloud from various malware and wireless channel cybersecurity attacks.
Unlike typical transport layer security that only protects the message payload as it moves down the OSI stack and back, application-layer security creates a secure tunnel between the sender and receiver. It essentially enables the application to natively build its own security rather than rely solely on the lower stack levels. The session can be authenticated and require all messages to be encrypted before they leave the app. Robust key exchanges and key management functions enable the recipient to decrypt and validate these messages before utilizing the recipient app.
The second layer of security, for authentication, is essential for smartphone-based control of implantable devices. It helps protect both the application and the platform upon which the app is running, mitigating the risk of attack through connectivity to the solution’s cloud services, smartphone apps, and other IoT devices. This layer can handle authentication of the user, the smartphone app, cloud, consumable, and any associated devices connected to the solution’s communication system while validating their integrity to ensure hackers cannot gain “root access” to privileges that enable them to do harm. The authentication layer is particularly important for connected-health solutions that are at risk of counterfeiting. It brings trust to each “thing” in an IoT solution to protect patient safety and the privacy and integrity of their information.
To implement the authentication layer, each system element must have a unique digital cryptographic identity and have attestation capabilities so it can validate the authority and privileges of the other elements. This ensures there is a root of trust within and between all components in the system so all remain uncompromised and invulnerable to the latest cyber threats. The authentication layer thus ensures that only authorized and trusted sources can send information and issue commands. It can also prevent reverse engineering by obfuscating the application code and ensures other smartphone applications cannot interfere with the connected-health application.
The authentication layer’s root of trust needs to be established on each system element, including the device, cloud, consumable, and smartphone. Depending on the element, either software or hardware may be used to establish the root of trust. In the factory, Hardware Security Modules, or HSMs, may be used to provide both the medical device and the consumable with cryptographic keys and digital certificates to behave like secure elements (SE) in the system. The trusted cloud issues digital certificates over the air that identify the apps and devices as trusted and handles all the solution’s identity lifecycle management. Lastly, even the user may be authenticated based on third party databases and phone resources to verify fingerprints, facial images, document scans, and the like.
The last layer of this three-tiered security-by-design architecture addresses the challenge of ensuring seamless connectivity. Whether it’s an asset tracking and consignment inventory management or wearable injection device, it is critical to have “always-on” connectivity between the Thing and the Cloud to exchange data, change operating profiles, and update firmware over-the-air, or administering alerts. Too often, solutions depend exclusively on a handheld device or smartphone for cloud connectivity and cannot ensure that the system always has the most recent device data and can immediately change device performance.
One way to solve this problem on the smartphone is with security software that runs in the OS background. After the smartphone user starts the app and configures it for continuous operation, this layer can continue to harvest the device’s IoT data whenever the devices are in proximity to the smartphone.
A second solution for this layer takes a hardware-based approach to the problem. A small-form-factor bridge can implement one communications protocol for interaction with the IoT device and another to communicate with the cloud. The first protocol usually features only personal area coverage. This solution can be configured either for continuous operation or only when the primary IoT-to-cloud path is unavailable.
The third approach to implementing this authentication layer is protecting legacy equipment such as MRI machines and other wired Ethernet medical systems. In this case, a hardware gateway is used to connect to the Ethernet network. It is placed in front of this vulnerable medical equipment to provide a separate channel for communicating only with authenticated devices.
A system that combines the capabilities of smartphones, bridges, and hardware gateways, as described above, ensures the always-on feature that most IoMT deployments need.
Connected-health security solutions were previously built from the ground up. Today’s offerings can still be implemented in a modular fashion to meet a wide range of application scenarios using third-party software developer kits (SDKs). This provides users with a building-block approach to adding security at a lower cost and greater flexibility than in the past. The approach also makes it possible to retrofit robust security measures into legacy designs and infrastructures as needed and continuously improve them, up to and including incorporating HSMs later in a solution’s lifecycle to optimize how the application layer’s root of trust is implemented.
Solutions like these add small incremental cost to IoMT-based consignment inventory management systems, connected legacy medical equipment, and smartphone-controlled implantable healthcare devices, but the benefits they deliver are manifold. They significantly improve security while providing the opportunity to differentiate IoMT offerings based on the incalculable benefit of protecting patients from injury or death.
New Podcast Episode
Recent Articles