As practitioners increasingly rely on remote patient monitoring, telemedicine, and other IoMT-based remote care modalities, the chronic safety issue of connected medical devices is now a progressive systemic disease during the pandemic.

Threats within hospitals also abound, including those associated with traditional wired Ethernet medical systems, from anesthesia machines and MRIs to ventilators and infusion pumps. Mitigating these risks requires a multi-layered security design strategy across the interconnected ecosystem and use case.

From hospital inventory to home healthcare

IoMT devices 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 hospitals, it is increasingly popular to track equipment and critical assets to improve visibility and prevent out-of-stocks. This includes managing consignment inventories shipped to hospitals by suppliers, but only invoicing when products or equipment and related supplies are used. IoMT technology increases visibility for medical device manufacturers and hospitals and automates the ordering and billing process when items are used.

IoMT technology is also being used to simplify safety and security features in hospitals, for example, latex-intolerant patients will not receive lung catheters that contain rubber. IoMT technology simplifies the process of obtaining catheter lot numbers, serial numbers and expiration dates to ensure they are effective for implants. It can be used to confirm the authenticity of the device and maintain compliance with temperature and other environmental requirements. In the event of a recall, it expedites access to all necessary information about who may have received the product in question.

At the same time, legacy equipment in hospitals is also being pulled into IoMT. MRI and other wired Ethernet medical systems connected to hospital networks present a threat surface for hackers that can be exploited to compromise patient safety and the integrity of hospital operations. Once inside a hospital network, hackers have the ability to compromise legacy equipment through a variety of zero-day attacks.

Outside of hospitals, many defibrillators, insulin pumps, blood glucose meters, and other IoT-connected devices are at risk of being wirelessly hijacked and reprogrammed. For example, an attacker could access an insulin pump's wireless connection over short distances and direct it to deliver the wrong amount of insulin or control a pacemaker to disrupt a patient's heart rhythm. Hackers can also intercept telemetry data from these systems in transit and gain access to sensitive patient information.

Another home healthcare example is an IoMT-based smart blister pack that enables care providers to remotely manage and monitor patients' prescription drug adherence. Invented in the 1960s to protect medication and make it easier for patients to retrieve a single dose, blister packs now contain sensors and communicate via Bluetooth with home gateway devices with displays and cameras. The gateway device notifies the patient when the blister needs to be opened, then uses its cellular and Wi-Fi connections to push relevant drug delivery event data to the cloud. Caregivers are alerted when intervention is required, and gateways can also be used for good exams and other remote patient interactions.

In these and other applications, there is a growing demand for command and control functions using commercial smartphones. But inherent vulnerabilities must be addressed first, one of the most dangerous of which is your phone's wireless connectivity. Bluetooth, NFC, and LTE protect against some vulnerabilities, but not all. This also applies to Ethernet and other protocols. Mitigation requires that all system communications must be secured, every system element must be trusted, and there must be an “always-on” connection between smartphone apps and IoT devices and the cloud.

Security starts at the application layer

Application layer security defends against various malware and wireless channel network security attacks. Unlike typical transport layer (Layer 4) security that only protects message payloads as they move down the OSI stack and back, application layer security creates a secure tunnel between sender and receiver, To secure the entire communication channel between smartphone apps, medical devices and the cloud. Essentially, the application builds its own security rather than relying on the lower stack levels of the service.

Using this approach, the session can be authenticated and require that all messages be encrypted before they leave the application. Robust key exchange and key management capabilities enable recipients to decrypt and authenticate these messages before they are used by recipient applications. Each of these protections enhances existing Android and iOS security mechanisms, while also overcoming security vulnerabilities inherent in their communication protocols.

Next Steps: Authentication Layer Security

A second layer of security is critical for smartphone-controlled implantable devices and those that are at risk of counterfeiting and reverse engineering. This authentication layer security verifies the integrity of users, smartphone applications, cloud, consumables and any associated devices connected to the solution's communication systems and ensures that hackers cannot gain privileged "root access" for harmful purposes ".

This security layer also prevents counterfeiting. It protects patient safety and the privacy and integrity of health information by trusting every "thing" in an IoT solution. It also prevents reverse engineering by obfuscating the app code and ensuring that other smartphone apps don't interfere with the Connected Health app.

To achieve these goals, a root of trust for the authentication layer must be established on devices, clouds, consumer products, and smartphones using software or hardware. Hardware Security Modules (HSMs) can be supplied to medical devices at the factory to provide cryptographic keys and digital certificates for medical devices and consumables, which need to work like a Secure Element (SE) in the system.

The video below shows how this security layer works. In this simulation, an unauthorized attacker application on a smartphone is used to control a nearby IoT device demo board and its controller application. The hacking app sends fake temperature values ​​designed to change the color of the LED lights. In unsecured mode, the IoT demo device easily accepts LED change requests after sending it a series of false values ​​every 2.5 seconds. Immediately after activating application layer security using the onboard switch, the controller application recognizes that the attacker application's signature is invalid and rejects the LED change request. LED change requests are only accepted from trusted controller applications running application-layer security.

Last layer: persistent connections

A third layer of IoMT security ensures that the system can always receive the latest data and immediately change device operation to meet patient care requirements. This can be problematic for solutions controlled by handheld devices or smartphones, as they are highly susceptible to communication failures.

There are various ways to ensure this persistent connection. The first is through a software application that runs in the background of the iOS or Android operating system. The app stays in the background and collects IoT device data when its device is near a smartphone. No user intervention is required. The second method is hardware based. Small bridges use one communication protocol (usually only providing personal area coverage) to interact with IoT devices and another to communicate with the cloud. It can be configured to run continuously or only when the primary IoT-to-cloud path is unavailable (see Figure 2).

(Figure 2: In the event of 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 the Telephony Remote Socket (PRS) component.)

This third method of ensuring continuous connectivity is especially important for MRI machines and other traditional wired Ethernet medical systems that lead to most hospital attacks. A hardware gateway connected to Ethernet was placed in front of this vulnerable medical device to provide a separate channel dedicated to communicating with authenticated devices.

The cornerstone of continuous improvement

Today's connected health solutions no longer need to be developed from scratch, but can be implemented in building blocks using third-party software development kits (SDKs). This reduces the cost of adding security while increasing flexibility and enabling legacy designs and infrastructure to be retrofitted as needed. This approach also ensures that the implementation can be continuously improved at any point in the solution life cycle, including in conjunction with the use of HSMs.

Implementing all three IoMT safety layers would only add pennies to the cost of a patient's insulin pump or other system. At the same time, it offers suppliers the opportunity to differentiate their connected health offerings in a high-value way. Perhaps most importantly, this three-tiered approach protects healthcare providers from the immeasurable cost of breaches that could compromise patient privacy or even result in someone being injured or killed.

Reviewing Editor: Guo Ting

Leave a Reply

Your email address will not be published.