Internet of Medical Things (IoMT) technology is central to healthcare delivery in applications ranging from connected implantable devices to streamlining the supply chain. Device security in these and other applications is often neglected, which is particularly dangerous as the industry moves to an Internet of Things (IoT) device command-and-control model. Using commercial smartphones with built-in security mechanisms aren’t always robust enough for safety-critical applications. Inadequate device security has the potential of putting the hospitals at risk, from counterfeits as well as threats to the reliable management of high-value medical asset inventory.
These and other IoMT challenges can be solved through a three-tiered “security-by-design” strategy that protects all communication between system elements and brings trust and “always-on” connectivity to each.
The consignment inventory challenge
One IoMT application is hospital asset tracking, so that equipment is always available and accessible. Another is consignment inventory management. Vendors sell their product, equipment and associated consumables to hospitals on consignment, issuing invoices only when the items are used. IoMT technology gives both the medical device manufacturer and the hospital better visibility while automating all ordering and invoicing process as each item is used.
IoMT technology also streamlines safety assurance functions that unique device identification (UDI) labels and barcodes traditionally perform. Consider a latex-intolerant patient about to receive a lung catheter. The nursing staff typically obtains the catheter’s lot number, serial number and expiration date to ensure it is valid for implant. IoMT technology simplifies this process and makes it easier to ascertain device pricing and other information, such as rubber content.
Likewise, IoMT technology makes any device recall information readily available. If a pacemaker manufacturer, for instance, discovers an issue related to one or more batches of a specific model, hospitals that receive a recall notice will immediately have all necessary information about who may have received one of the devices. IoMT technology also eliminates error-prone manual processes for ensuring that consigned inventory is maintained to temperature and other environmental requirements.
These and other benefits can only be realized if IoMT solutions are secure. Healthcare providers must defend themselves against IoMT counterfeits and ensure 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. Any item of consigned inventory that has not been authenticated is a potential counterfeit.
Cybersecurity threats are equally dangerous. Legacy equipment like MRIs connected to the hospital network can provide an entry point for hackers, as can any wired Ethernet medical system, whether it be an anesthesia machine, ventilator or infusion pump. Many of these systems were produced long before cybersecurity was a critical consideration. Each piece of connected equipment is a potential threat to patient safety and the integrity of hospital operations.
Mitigating these threats requires a multi-layered, security-by-design approach that minimizes cost while simplifying deployment.
Multi-layered security by design
IoMT solutions must include multiple layers of protection, especially those that use smartphones for command and control in life-critical equipment. Bluetooth, near-field communication, LTE, Ethernet and other protocols mitigate some, but not all, breach threats. Security starts at the application layer, protecting the communications channel between the smartphone app, the medical device, consumable (if applicable) and the cloud from malware and wireless channel cybersecurity attacks.
Unlike typical transport layer security that only protects the message payload as it moves down the open systems interconnection stack and back, application-layer security creates a secure tunnel between the sender and receiver. The application essentially natively builds in its own security rather than relying on the lower stack levels. The session can be authenticated and requires 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 being utilized by the recipient app.
The second authentication layer is particularly important for smartphone-based control of devices. It validates the integrity of the user, smartphone app, cloud, consumable and any associated devices connected to the solution’s communication system, while ensuring hackers cannot gain “root access” to privileges for harmful purposes. This layer also prevents counterfeiting by bringing trust to each “thing” in the solution, preventing reverse engineering by obfuscating the application code and ensuring 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 many be used to establish the root of trust. In the factory, hardware security modules (HSMs) may be used to provision both the medical device and the consumable with cryptographic keys and digital certificates, so they behave like secure elements (SE) in the system.
The third security layer ensures the seamless connectivity that is critical whether the application is asset tracking and consignment inventory management or a wearable injection device. The IoMT device and the cloud must be able to exchange of data, change operating profiles, update firmware over-the-air and administer alerts. If not, there is no way to ensure that the system always has the most recent device data and is able to 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 is to use a small-form-factor bridge to implement one communications protocol for interaction with the IoT device, and another to communicate with the cloud. A third approach protects legacy equipment such as MRI machines and other wired Ethernet medical systems—a hardware gateway connected to the Ethernet network is placed in front of this vulnerable medical equipment to provide a separate channel for communicating only with authenticated devices.
Modular deployment
Connected-health security solutions were previously built from the ground up, but today’s offerings can be implemented in a modular fashion to meet a wide range of application scenarios using third-party software developer kits. The approach also makes it possible to retrofit robust security measures into legacy designs and infrastructures and continuously improve them, up to and including incorporating hardware security models later in a solution’s lifecycle to optimize how the application layer’s root of trust is implemented.
Solutions like these significantly improve security and device authenticity while adding small incremental cost to consignment inventory management systems, connected legacy medical equipment and smartphone-controlled implantable healthcare devices.
