Multi-Layered Security is Best Antidote Against Internet of Medical Things (IoMT) Cyberattacks
April 30, 2021
Story
The chronic security ills of connected medical devices have now become a progressive, systemic disease during the pandemic as practitioners grow increasingly reliant on remote patient monitoring, telemedicine and other long-distance IoMT-based care models.
Threats abound inside the hospital, too, including those related to legacy wired Ethernet medical systems ranging from anesthesia machines and MRIs to ventilators and infusion pumps. Mitigating these risks requires a multi-tiered security-by-design strategy across the entire spectrum of interconnected ecosystems and use cases.
From Hospital Inventory to Home Healthcare
IoMT devices both inside and outside the hospital share a common set of vulnerabilities and associated risks, each of which can be mitigated using the same basic cybersecurity principles.
Inside the hospital, it is increasingly popular to track equipment and critical assets to improve visibility and prevent stock outs. This includes managing consignment inventory that vendors ship to hospitals but only invoice when the product or equipment and associated consumables are used. IoMT technology improves visibility for both the medical device manufacturer and the hospital and automates the ordering and invoicing process whenever an item is used.
IoMT technology is also used to streamline a hospital’s safety assurance functions so that, for instance, a latex-intolerant patient does not receive a lung catheter with rubber content. IoMT technology simplifies the process of acquiring the catheter’s lot number, serial number, and expiration date to ensure it is valid for implant. It can be used to confirm that the equipment is authentic and maintained to temperature and other environmental requirements. In the event of a recall, it speeds acquisition of all necessary information about who may have received the product in question.
Meanwhile, legacy equipment inside the hospital is also being pulled into the IoMT. MRIs and other wired Ethernet medical systems that are connected to the hospital network give hackers a threat surface that can be exploited to threaten patient safety as well as the integrity of hospital operations. Once inside the Hospital network, the hacker has the ability to compromise legacy equipment with a variety of zero-day attacks.
Outside the hospital, many heart defibrillators, insulin pumps, glucose meters, and other devices connected to the IoT are at risk of being wirelessly hijacked and reprogrammed. Attackers can gain short-range access to an insulin pump’s wireless connection, for instance, and direct it to deliver the wrong amount of insulin or take control of a pacemaker to disrupt a patient’s heart rhythms. Hackers also can intercept these systems’ telemetry data during transmission and acquire sensitive patient information.
Another home healthcare example is IoMT-based smart blister packs that enable care providers to remotely manage and monitor their patients’ prescription medication adherence. Invented in the 1960s to protect medications and make it easy for patients to retrieve single doses, blister packs now incorporate sensors and communicate via Bluetooth to a home gateway device featuring a display and camera. The gateway device notifies patients when it is time to open a blister and then pushes the associated dosing event data to the cloud using its cellular and Wi-Fi connections. Caregivers are alerted when they need to intervene and can also use the gateway for well checks and other remote patient interactions.
(Figure 1: IoMT-based medication adherence solutions feature sensor-based smart medication blister packs that communicate via Bluetooth to a home gateway device with a display and camera. They remind patients when to open a blister and notify caregivers when they need to intervene.)
In these and other applications, there is growing demand to use commercial smartphones for command-and-control functions. But inherent vulnerabilities must first be addressed, one of the most dangerous being the phone’s wireless connections. Bluetooth, NFC and LTE may defend against some breaches but not all. This is also true for Ethernet and other protocols. Mitigation requires that all system communications must be protected, each system element must be trusted, and there must be “always-on” connectivity between smartphone apps and the IoT devices and cloud.
Security Starts at the Application Layer
Application-layer security defends against a variety of malware and wireless channel cybersecurity attacks. Unlike typical transport layer (Layer-4) 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 to protect the entire communications channel between the smartphone app, the medical device and the cloud. In essence, the application natively builds in its own security rather than relying on the lower stack levels for that service.
Using this approach, sessions can be authenticated and require that all messages be encrypted before they leave the app. Robust key exchanges and key management functions enable the recipient to decrypt and validate these messages before they are utilized by the recipient app. Each of these safeguards augments existing Android and iOS security mechanisms while also overcoming the security vulnerabilities that are inherent in their communications protocols.
Next Step: Authentication-Layer Security
The second layer of security is vital for smartphone-controlled implantable devices and those that are at risk of counterfeiting and reverse-engineering. This authentication-layer security validates the integrity of the user, smartphone app, cloud, consumable and any associated devices that are connected to the solution’s communication system and ensures that hackers cannot gain “root access” to privileges for harmful purposes.
This security layer also defends against counterfeiting. It protects patient safety and the privacy and integrity of health information by bringing trust to each “thing” in an IoT solution. It also prevents reverse engineering by obfuscating the application code and ensuring other smartphone applications cannot interfere with the connected-health application.
To accomplish these goals, the authentication layer’s root of trust must be established on the device, cloud, consumable and smartphone, using either software or hardware. Hardware Security Modules (HSMs) may be provisioned to medical devices at the factory to give both the medical device and the consumable the cryptographic keys and digital certificates they need to behave like secure elements (SE) in the system.
The video below shows how this security layer works. In this simulation, an unauthorized attacker app on a smartphone is used to take control of a nearby IoT device demonstration board and its controller app. The hacker app sends fake temperature values aimed at changing the color of an LED light. In unsecured mode, the IoT demonstration device easily accepts an LED change request after a series of fake values are sent to it every 2.5 seconds. After application-layer security is activated using an onboard switch, the controller application immediately discerns that the attacker application’s signature is not valid and rejects the LED change request. LED change requests are only accepted from a trusted controller application running the application-layer security.
Healthcare Secure Connectivity Demonstration
Final Layer: Continuous Connectivity
The third IoMT security layer ensures systems can always receive the most recent data and immediately change device operation to meet the patient’s care requirements. This can be problematic with solutions that are controlled by a handheld device or smartphone since they are extremely vulnerable to communications lapses.
There are multiple ways to ensure this continuous connectivity. The first is via a software app running in the iOS or Android OS background. The app remains in the background and harvests IoT device data whenever its device is near the smartphone. No user intervention is needed. The second approach is hardware-based. A small-form-factor bridge uses one communications protocol (generally providing only personal area coverage) to interact with the IoT device, and a second to communicate to the cloud. It can be configured either for continuous operation or for use only when the primary IoT-to-cloud path is unavailable (see figure 2).
(Figure 2: If there is a Wi-Fi failure, the IoT communication and security stack can be used to send/receive data between the firmware remote socket (FRS) component and phone remote socket (PRS) component.)
The third way to ensure continuous connectivity is particularly important for MRI machines and other legacy wired Ethernet medical systems that have been responsible for most hospital attacks. A hardware gateway connected to the Ethernet is placed in front of this vulnerable medical equipment to provide a separate channel that is used exclusively for communicating with authenticated devices.
Building Blocks for Continuous Improvement
Today’s connected-health solutions no longer must be developed from scratch but can be implemented using third-party software developer’s kits (SDKs) in a building-block approach. This reduces the cost of adding security while improving flexibility and enabling legacy designs and infrastructures to be retrofitted as needed. This approach also ensures that implementations can be continuously improved at any point in a solution’s lifecycle, including incorporating the use of an HSM.
Implementing all three IoMT security layers adds only a few cents to the cost of a patient’s insulin pump or other system. At the same time, it offers opportunities for providers to differentiate their connected-health offerings in high-value ways. Perhaps most importantly, this three-tiered approach protects healthcare providers from the incalculable cost of a breach that could jeopardizes patient privacy and even lead to someone’s injury or death.
