Cybersecurity, secure channel

A Prescription for Curing Connected Medical Device Security

By Vinay Gokhale
Cybersecurity, secure channel

The more devices are connected, the more that targets are present for remote attackers.

Connecting medical devices within the Internet of Things (IoT) has enabled doctors to improve patient diagnoses and treatment, remotely monitor chronic diseases and cut costs while enhancing care outcomes among many other benefits. But the more devices that are connected, from CT and MRI scanners to patient monitors, ventilators and implants, the more targets there are for attackers who want to remotely take over, reprogram and/or disable a device, steal its data, or launch a denial of service attack.

Adding to these challenges, there is a push to further improve convenience and the patient experience by enabling medical devices to be controlled using commercial mobile phones. This introduces yet another threat vector, and the industry will need to address a variety of misconceptions about the security of commercial Bluetooth wireless connections in these types of applications. Also critical is determining whether there will be adequate “always-on” connectivity for sending and receiving data and commands to and from the cloud, even when the handheld device or smartphone becomes unavailable for this function.

Subscribe to the weekly MedTech Intelligence newsletter to stay up to date on the latest news and information on medical device development and regulation.

The only way to deal with these challenges and safely realize the benefits of connected medical devices is by applying proven best practices for end-to-end multi-layered security “by design.” These practices bring trust to all system elements at the time of manufacturing and beyond.

Growing Regulatory Scrutiny

As threats loom, evolve and multiply, regulatory and other bodies have stepped in with guidance.
In October 2018, the FDA released its long-awaited playbook on cybersecurity for medical devices. The playbook thoughtfully covered fundamental concerns for healthcare delivery organizations (HDOs) in managing cyberattacks on Healthcare and Public Health infrastructure. It followed other valuable reads on Premarket and Postmarket guidelines for submissions by medical device manufacturers for effective cybersecurity management.

A year later, the Medical Imaging & Technology Alliance (MITA) published its NEMA/MITA HN 1-2019, Manufacturer Disclosure Statement for Medical Device Security, also known as MDS2. In announcing the standard, the MITA said it “… recognizes that cybersecurity is a shared responsibility among all involved market participants,” and it requires HDOs “… especially to work collaboratively with manufacturers to ensure the use of best practices.” The organization added that the shared responsibility recognized by the standard is aligned with the position of the FDA as outlined in its playbook.

Clearly, cybersecurity has become a key, sustained focus for the FDA and other regulatory and trade organizations over the past few years. They have launched valuable discussions on cybersecurity preparedness, response, threat identification and risk assessment. The next step is threat prevention—perhaps the biggest issue that needs emphasis. But first, some misconceptions need to be cleared up.

Misconceptions Cloud Security Assessments for Millions of Deployed Devices

Estimates vary regarding how many people are using connected medical devices. Statista forecasts nearly 161 million healthcare IoT devices will be shipped worldwide for installation during 2020. As of September 2019, Business Insider Intelligence estimated there were already approximately 430 million connected medical devices in deployment worldwide.

Meanwhile, misconceptions about these devices abound. Their security is too often assumed to exist even when it does not. Worse, those who think security should be strengthened fail to act because they incorrectly believe it will be prohibitively expensive or complex to implement. Other HDOs believe that security can be handled as an afterthought, when solutions have already been deployed. These misconceptions have led to increasingly dangerous thinking, especially as the industry moves to a smartphone-based command-and-control model for safety-critical connected health applications.

One of the more widespread misconceptions is that the Bluetooth wireless connection provides adequate security. While it is true that Bluetooth, NFC, LTE, Ethernet and other protocols mitigate some breaches, they don’t defend against all threats. For instance, the widely publicized BlueBorne flaw has reportedly impacted more than 5 billion PCs, phones and IoT devices since September 2017, enabling attackers to take complete control of affected devices, steal data in transit and spread malware. In its 2019 Cyber Threat Outlook report, Booz Allen described “a wave of vulnerability disclosures and in-the-wild attacks targeting Bluetooth devices.”

The second misconception is equally persistent. Too often, HDOs believe that defending connected medical devices against today’s threats is prohibitively expensive or complex. On the contrary, it is possible to take a security-by-design approach to solution development that adds only a few pennies to the cost of a patient’s insulin pump or other connected health solution. As third-party IoT cybersecurity offerings become available, costs are substantially reduced as compared to having to create a solution from scratch. With these third-party solutions, capabilities are implemented in a building-block fashion that minimizes cost while simplifying the process of embedding connected-health solution security.

The third misconception—that security can be added after the fact, perhaps in response to a breach or increased regulatory pressure—is perhaps the most counterproductive for HDOs dedicated to protecting patient safety and privacy. Only at the beginning of the solution development cycle can the required levels of security be added for safety-critical applications. This is because a critical element of the ideal approach is that a hardware security module (HSM) be provisioned to each medical device in the factory. This is a foundational piece for any secure connected-health solution that is developed using security-by-design best practices.

Connected Health Best Practices

Ensuring that a connected medical device can defend patients against cyber threats requires multiple layers of protection and security defenses. These layers are especially critical when a smartphone will be used for command and control.

Secure communications, cybersecurity
Figure 1. The privacy and integrity of a patient’s information is protected by creating a secure tunnel at the application layer. This secure communications channel eliminates the need to rely on underlying transport-mechanism security that may or may not exist.

The first layer is the creation of a secure communications channel between the smartphone app, the medical device and the cloud (see Figure 1). This communications channel plugs gaps that exist in the built-in shared transport layer security mechanisms of a commercial smartphone’s Android or iOS operating systems. While the smartphone’s Bluetooth capability is used to automatically connect authorized devices to intermediate hardware gateways or smartphone apps that are within communication range, the secure communications channel is what ensures that the connected health solution will be resistant to malware and wireless channel cybersecurity attacks. An example of this approach is an IoT security platform from Thirdwayv that has been used in the Insulet Corp. Omnipod DASH Insulin Management System. This solution was cleared by the FDA in June 2018 and has also received both the ISO 27001and DTSec Cybersecurity Standard for Connected Diabetes Devices certification.

The second layer is reliable user and device authentication, identity management, and attestation of one system component to the other (see Figure 2). This layer brings trust to the entire connected health system. It ensures that only authorized and trusted sources can originate information and commands. With this layer in place, each element of the system validates the authority and privileges of any other element in the system. There is a “root of trust” within and between all system elements. The smartphone app, cloud and other devices connected to the solution’s communication system are authenticated using a unique digital cryptographic identity. The digital certificates and cryptographic keys that are used for authentication are stored in an HSM that is factory-provisioned to each medical device. The trusted cloud infrastructure uses the HSM to verify the integrity and authenticity of all smartphone apps and medical devices. It then issues digital certificates over the air that identify the apps and devices as trusted and is responsible for all associated identity lifecycle management.

Cybersecurity, secure channel
Figure 2. The secure channel includes a scalable platform for protecting against malicious apps that reside on a smartphone. In addition to validating the phone and app integrity, this platform defends against the threat of a “rooted” operating system used by hackers to gain “root access” to privileges so they can modify the device’s software code or install other software.

Another important capability is reliably maintaining uninterrupted operation of a connected-health system’s life-critical functions. The system must always be able to receive the most recent data so it can immediately change device operation based on patient requirements. This is impossible with solutions that depend exclusively on a handheld device or smartphone for continuous cloud connectivity and are therefore susceptible to service lapses that cut off access to vitally important data and commands. The solution is to use traditional fixed gateways and have the smartphone serve as a companion software gateway.

HDOs have numerous options for implementing the security-by-design approach in their connected-health solutions. With today’s third-party security software suites and HSM factory-provisioning services, HDOs can implement one or more security layers using a risk-appropriate building block approach. The availability of software development kits (SDKs) with application programming interfaces (APIs) speeds the incorporation of these software suites and services into a complete solution.

Ensuring that all device programming and final test are tightly controlled during manufacturing gives the HDO and its customers the confidence that all devices are pre-programmed to interact only with approved gateways in the field. The devices can be safely on-boarded into a system, and they will be extremely difficult for a hacker to reverse-engineer. They also will be highly resistant to tampering and counterfeits since contract manufacturers will not be able to build any more units than authorized.

Multiple misconceptions have held back the critically important adoption of risk-appropriate security-by-design defenses in today’s connected-health solutions. As industry and regulatory pressures mount, though, HDOs are increasingly turning to device manufacturers and third-party security solution providers to help them ensure patient safety and security. Today’s IoT security solutions eliminate the previously prohibitive cost and complexity of protecting connected healthcare products and systems from increasingly dangerous cybersecurity threats.

Related Articles

About The Author

Vinay Gokhale, Thirdwayv