By Vinay Gokhale, VP Business Development, Thirdwayv
Connecting insulin pumps, heart-rate monitors, and other medical devices in the internet of things has transformed patient care. But the security of these solutions is, in too many instances, not considered carefully enough. Worse, some solution providers believe that security simply cannot be implemented cost-effectively. This becomes particularly dangerous thinking as the industry moves to a command-and-control model using commercial smartphones whose built-in security mechanisms are frequently not robust enough for safety-critical applications.
These challenges can be solved through a three-tiered “security by design” strategy that protects all system communications, brings trust to each system element, and ensures “always on” connectivity between smartphone apps and the IoT devices and cloud.
Danger is growing
One of the first examples of how dangerous connected-health threats can be occurred in May 2019, when a Type 1 diabetes patient re-programmed his insulin pump to customize his treatment. The man, who ended up in the hospital, 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.
Even worse, this same type of safety flaw provides an open door to hackers, enabling them to gain access to a device to cause harm or steal sensitive health information. For example, a hacker that gained unauthorized access to a pacemaker could disrupt the patient’s heart rhythms or acquire sensitive health information by intercepting the device’s telemetry data.
The danger grows as solution providers embrace the convenience of using smartphones to control connected-health solutions and mistakenly believe that the Bluetooth wireless connection provides adequate security. While it is true that Bluetooth, NFC, LTE, Ethernet, and other protocols mitigate some breaches, they do not defend against all threats. Mitigating these threats requires a multi-layered, security-by-design approach that minimizes cost while simplifying deployment.
Multi-layered security by design
Robust security begins at the application layer, protecting the communications channel between the smartphone app, the medical device, and the cloud from a variety of malware and wireless channel cybersecurity attacks. This protection layer creates a secure tunnel between the sender and receiver, essentially enabling the application to natively build in its own security rather than rely solely on the lower-stack levels for that service.
This contrasts with the typical Layer 4 security, which protects the message payload at or below this layer only as they move down the OSI stack on the sending side and back up on the receiving side. The session is authenticated, and all messages are encrypted before they leave the app, which exchanges keys with the recipient so that its app can decrypt the messages. Each of these safeguards augments existing Android and iOS security mechanisms while also overcoming the security vulnerabilities that are inherent in their communications protocols.
The second security layer helps to 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 handles authentication of the smartphone app, cloud, and any associated devices that are connected to the solution’s communication system, validating their integrity while ensuring that hackers cannot gain “root access” to privileges that enable them to modify the device’s software code or install other software.
A unique digital cryptographic identity is given to all system elements, each of which has attestation capabilities to validate the authority and privileges of the other elements. This creates a root of trust within and between all components in the system, ensuring that the smartphone has not been compromised or rooted and is not running an outdated version of the OS that is vulnerable to the latest threats. The layer ensures that only authorized and trusted sources can send information and issue commands, obfuscates the application code to combat reverse engineering, and protects the application from interference from any other applications on the smartphone.
Ideally, this authentication layer’s root of trust should be implemented using a hardware security module (HSM) that operates like a secure element (SE). Provisioned to each medical device at the factory, the HSM stores and manages cryptographic keys and digital certificates and is used by the trusted cloud to verify the integrity and authenticity of all smartphone apps and medical devices. The cloud issues digital certificates over the air that identify the apps and devices as trusted and handles all of the solution’s identity life-cycle management. Fig. 1 illustrates this authentication layer, using either an SE or the software equivalent that provides protection but not to the same degree as the hardware version.
Fig. 1: A secure tunnel is created at the application layer that protects the privacy and integrity of a patient’s information, overcoming vulnerabilities of underlying transport-mechanism security.
The third and final layer of this security architecture improves the ability of IoT devices to send data to the cloud and receive commands from it in applications that demand “always on” connectivity. This ensures that systems can always get the most recent device data and immediately change device performance.
This contrasts with solutions that depend exclusively on a handheld device or smartphone to deliver this cloud connectivity and cannot always achieve the high level of continuous data availability and device control required for mission-critical applications. The security software for this layer runs in the smartphone’s iOS or Android OS background, and as long as the smartphone user starts the app once and configures it for continuous operation, it will stay in the background and harvest data from the IoT device without any further user intervention whenever the device is in proximity to the smartphone.
Additionally, the use of nimble, multi-bridge technology creates a secondary path for the IoT device to communicate to the cloud when its primary network connection (over LTE or Wi-Fi) is inoperative. This small-form-factor bridge utilizes one communication protocol to interact with the IoT device (most of which feature only personal area coverage) and another to communicate to the cloud.
Streamlining deployment
While connected-health security solutions previously were created from scratch, today’s offerings can be implemented using third-party software developer kits (SDKs) that provide a building-block approach to adding security at a lower cost and with a high level of flexibility. Robust security measures can be effectively retrofitted into legacy designs and infrastructures as needed, and there is an easy path to the continuous improvement that is critical for good security practices, including incorporating the use of an HSM later in a solution’s life cycle to boost security as needed.
With today’s third-party IoT solutions for connected-health applications, security adds only a few pennies to the cost of a patient’s insulin pump or other system. Solutions like these also provide the opportunity to differentiate connected-health offerings based on high-value security at a low incremental additional cost. Making this investment also enables health-care providers to protect themselves from the additional costs of a breach and the risk of injury or death.
Advertisement
