Preventing connected medical devices from threatening security
Vinay Gokhale, vice president of business development with Thirdwayv, explains how connected medical devices can be prevented from being compromised.
In the rapidly expanding Internet of Medical Things (IoMT), many connected devices unintentionally create life-threatening security risks and jeopardise hospital operations. From decades-old legacy hospital equipment to the latest implantable products controlled by smartphones, these devices share common vulnerabilities. But while many mistakenly believe that IoMT security requires that each of these devices incorporate built-in security from the ground up, today’s third-party software solutions enable a building-block approach for flexibly adding the necessary security safeguards. This reduces cost and enables legacy designs and infrastructures to be retrofitted as needed.
Securing the latest medtech innovations
Many heart defibrillators, insulin pumps, Continuous Glucose Monitors (CGMs) and other devices connected to the IoMT can be wirelessly hijacked and reprogrammed. Attackers gain short-range access to an insulin pump’s wireless connection, for instance, and direct it to deliver an incorrect insulin dose or disrupt a patients’ heart rhythms after taking control of their pacemakers.
Artificial Pancreas systems are an excellent example of the challenge. The latest solutions include a waterproof, insulin pump and a CGM that are both worn by a patient. The insulin pump communicates directly with the CGM to adjust insulin delivery based on glucose levels and trends, while a smartphone app can be used by patients’ parents and caregivers to monitor status in real time and deliver additional insulin doses when needed. The systems have undergone successful trials and are moving closer to commercial availability for the treatment of Type 1 diabetes. They have demonstrated the ability to add hours per day within a healthy blood sugar range, lower average glucose readings and overall HbA1c levels, and cut periods of low blood sugar nearly in half. They are also being studied for use by Type 2 diabetes patients.
A key feature of these systems is the ability to control them using commercial smartphones, but this also poses the risk that cybercriminals could take over these devices. Already, CGM systems that use purpose-built, non-commercial remote-control devices have been recalled based on this vulnerability. In October 2021, one manufacturer issued what the FDA identified as a Class I recall -- the most serious type involving the risk of serious injuries or death. The company said that unauthorised people “could potentially record and replay the wireless communication between the remote and the insulin pump.” They could instruct the pump “to either over-deliver insulin to a patient, leading to low blood sugar (hypoglycaemia), or stop insulin delivery, leading to high blood sugar and diabetic ketoacidosis, even death.”
Moving to commercial mobile phones for CGM command and control will require even greater scrutiny of this security vulnerability. One of the biggest issues is the phone’s wireless connections. Bluetooth, NFC and LTE do not defend against all types of breaches. Nor do Ethernet or other protocols. To help mitigate these threats, three security layers are required:
1) all system communications must be protected at the application layer;
2) each system element must be trusted through authentication; and
3) the “always-on” connectivity channels between smartphone apps, IoT devices and cloud need to be secured.
Application-layer security protects the entire communication channel between the smartphone app, the medical device, and the cloud. It defends against a variety of malware and wireless channel cybersecurity attacks. Rather than simply rely on the lower stack levels and be subject to mobile phone operating system vulnerabilities, the application natively builds in its own security. It creates a secure tunnel between the sender and receiver. Sessions can be authenticated and require that all messages be encrypted before they leave the app. Before messages are used by the recipient app, robust key exchanges and key management functions facilitate their decryption and validation.
Authentication provides the second layer of security. It is used to validate the integrity of the user, smartphone app, cloud, consumable, and any associated devices that are connected to the solution’s communication system. In short, authentication ensures that hackers cannot gain “root access” to privileges that enable them to inflict harm. Either software or hardware can be used to establish the authentication layer’s root of trust on the device, cloud, consumable, and smartphone. 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 final layer of IoMT security enables systems to receive the most recent data and immediately change device operation to meet a patient’s care requirements. This is especially important for connected medical devices that are controlled by a handheld device or smartphone and therefore subject to potential communications lapses. One way to ensure continuous connectivity is via a software app running in the smartphone’s background that harvests IoT device data whenever it the device is near the smartphone. A second approach is to use additional “bridge” hardware that communicates with the wearable device and the cloud. This bridge can be configured either for continuous operation or for use only when the primary IoT-to-cloud path is unavailable.
Securing legacy equipment
There is a third way to ensure continuous connectivity, and it also solves the vulnerability problem of legacy wired Ethernet medical systems such as MRIs, ventilators, and infusion pumps. Legacy equipment has been responsible for the majority of hospital cybersecurity attacks and created a very large threat surface for hackers to exploit, either to threaten patient safety or to launch zero-day attacks against hospital operations.
The American Hospital Association (AHA) has acknowledged that legacy equipment was “…not built with cybersecurity in mind and may use outdated or insecure software, hardware, and protocols, leaving them vulnerable to attack.” The FDA has also weighed in on the issue, defining legacy devices in a June 2021 discussion paper as “those that cannot be reasonably protected against current cybersecurity threats” and pointing readers to a March 2020 International Medical Device Regulators Forum (IMDRF) document suggesting that these devices “should be decommissioned.” At this point, the IMDRF said, the responsibility for maintaining device security and assumption of risk for its ongoing use would transfer “to the customer; e.g., the healthcare provider.”
The AHA has called decommissioning financially infeasible and pointed out that many hospitals are only able to replace about 10% of devices in a given year. Rather than decommissioning this equipment, providers should consider another option. Health systems can instead install a gateway in front of this vulnerable equipment and connect it to the Ethernet network. The gateway acts a security shield for the legacy device but also allows the device to be continuously connected.
A modular approach to medtech security
Implementing all three IoMT security layers solves the problem of vulnerable CGMs and other connected medical devices at an incremental cost of only a few cents per unit. Likewise, installing a hardware gateway in front of each piece of legacy wired Ethernet equipment is much less expensive for a health system than decommissioning tens of thousands of imaging systems and other high-value items. Regardless of the IoMT use case, a multi-layered security strategy protects healthcare providers from the incalculable cost of a breach that could jeopardize patient privacy and even lead to injury or death.