Assessing the Security of Connected Diabetes Devices

Abstract

This article discusses the assessment of the (cyber)security of wirelessly connected diabetes devices under the DTSEC standard. We discuss the relation between diabetes devices and hackers, provide an overview of the DTSEC standard, and describe the process of security assessment of diabetes devices.

Connected Diabetes Devices Need to Be Secure

It goes without saying that devices such as glucose meters, insulin pumps, and artificial pancreases need to be secure. That is, third parties (hackers) should not be able to falsify readings, drastically increase insulin doses, and so on, thereby endangering or even killing patients.

When diabetes devices are fully stand-alone, the risk is minimal. Hackers may be able to “borrow” a device, modify it, and return it to a patient, but this is cumbersome, as hackers have to get physical access to each and every device.

When the devices can be connected to computers or smartphones/tablets, to transfer readings from the device to the computer, change the settings of the device, or update the software, the risk increases. Hackers could infect those computers/smartphones/tablets and use that as a stepping stone to hacking the diabetes device.

When the connection to a computer/smartphone/tablet becomes wireless the risk increases even further: now hackers may be able to hack a diabetes device from a distance over the wireless connection. Depending on the type of connection this could be from meters away (for instance for devices connecting with Bluetooth Low Energy) to halfway across the world (for devices connecting through for instance GSM). Hackers can now potentially infect many different devices without spending effort for each device.

With this increased risk, comes an increased need to remove or mitigate these risks. For this reason, device developers add security measures to their devices: passwords, encryption, and so on.

However, it is hard for a device developer, who is not a security specialist as well, to know whether the security measures are sufficient and whether they have been correctly implemented. It is even harder for purchasers of the device to know whether their device is secure.

One of the ways to address this is through third-party security assessments. A third-party security assessment of a device consists of an inspection of the security aspects of that device by a party that is:

• - specialized in assessing security, and

• - independent from the developer

This assessment shows that the developer did not make easy to make mistakes, design errors, or flaws.

The third-party specialization in security is necessary because security assessment is a very complex and rapidly developing field. Third-party independence is required to ensure that there is no undue influence. Because different third parties may apply different methods and look at different security aspects of devices, there is also need of a standard for security assessment. This need was recognized by the Diabetes Technological Society, which released the DTSEC standard on May 23, 2016.

The DTSEC Standard

The DTSEC standard consists of 2 parts:

• - The standard itself ¹

• - A Protection Profile ²

The standard itself describes:

• - How connected diabetes devices can be certified, based on a third-party security assessment by a third party (security laboratory)

• - How certificates can be efficiently maintained when the devices are updated

• - How security laboratories are accredited; as of October 2016, 2 labs are accredited: Brightsight (located in the Netherlands) and Booz, Allen & Hamilton (located in the United States)

The Protection Profile (PP): a document that conforms to the ISO 15408 standard.^3-5 The PP lists:

• - The security functionality that the connected diabetes device must provide. This includes:

• ○ Software integrity: the device must monitor the integrity of its software, so when a hacker changes this software, this is detected;

• ○ Data integrity: the device must also monitor the integrity of any stored data (such as blood glucose readings) or settings (such as insulin doses), so that when a hacker changes this data or settings, this is detected;

• ○ Secure communication channel: when the device communicates with another device, it must be sure it is talking to the correct device, and it must not be possible for other parties to listen in into this communication or modify this communication.

• - The documentation that the device developer has to provide to the security laboratory. As medical device developers must also meet the IEC 62304 standard, ⁶ the PP is piggybacking on this and requires that the developer provides the documentation set required by IEC 62304:2006. ⁶ This is intended to minimize the impact of the evaluation on the developer in time and costs.

• - How to perform the security assessment: the actions that the security laboratory must undertake, on both the device and the documentation in order to determine whether the product passes or fails the assessment.

• - The maximum vulnerability rating: how “strong” the device must be. The DTSEC standard specifies that the device should resist experienced hackers, but is not expected to resist very prolonged attacks by very experienced hackers using very substantial resources.

Security Assessments Under the DTSEC Standard

A security assessment under the DTSEC standard proceeds in 5 steps

1. Check if the device has the security functionality required by the PP

2. Perform a vulnerability analysis

3. Rate the vulnerabilities

4. Perform penetration testing”

5. Reporting

Check If the Device Has the Required Security Functionality

As stated above, the PP states that connected diabetes devices must possess software integrity, data integrity and secure communication channel functionality. In order to show this, the developer must produce a so-called Security Target (ST) document that shows how this security functionality is implemented at a high level. The security laboratory examines this ST for completeness and feasibility, and if this is OK, examines the IEC 62304 documentation that the developer had to provide to see whether this documentation shows that the security functionality has indeed been implemented. If so, the assessment proceeds to the next phase.

Perform a Vulnerability Analysis

The security laboratory systematically analyses the device itself and the IEC 62304 documentation to determine whether there are any potential vulnerabilities in the device.

What Is a Vulnerability?

A vulnerability is a weakness of a device that would allow an hacker to “break” the device in such a way that it no longer has the required security functionality (as defined in the PP).

A typical example of vulnerability is where a user can personalize his insulin pump with his name, so that whenever he uses the pump, his name is shown on the display. To enter this name, he uses an app on his smartphone, the app checks whether this name is no longer than 16 characters, and then sends the characters to the pump. The pump places these characters in its memory. Because the pump developer thinks that hackers changing names on the pump are not a big risk, no security is added to this feature.

A hacker in range of the pump has an app identical to the original app, except it does not check the number of characters. The hacker sends a name of 1 million characters. The pump places all 1 million characters into its memory. The first 16 characters are stored where the name is supposed to be stored, but all the other characters are stored as well, and overwrite whatever data were there, such as pump settings, other data, program code, and so on. A hacker knowing exactly how the pump uses its memorymay be able to use this attack to replace the pump program with a program of his own choosing, and, for instance, inject much more insulin than requested, potentially killing the patient.

This vulnerability can of course easily be fixed by ensuring that the pump itself, instead of the app, checks whether the name is not too long, but shows that even small and innocent features can be used to attack a device with potentially fatal consequences.

The security laboratory checks for 3 types of vulnerabilities:

• - vulnerabilities associated with specific standard protocols

• - vulnerabilities associated with third-party components.

• - vulnerabilities which are specific for the product

Vulnerabilities Associated With Specific Standard Protocols

If a device wants to communicate with other devices, it generally uses standard protocols, such as Bluetooth or IEEE802.11 (Wi-Fi). Some versions of these standard protocols have vulnerabilities that are inherent to those protocols, and any device that uses these versions will be inherently vulnerable. The vulnerabilities are often described in literature and therefore readily accessible to potential hackers.

An example is Ryan, ⁷ who explains that the Bluetooth Low Energy 4.0 protocol has a vulnerability in that if a hacker can listen in on the “pairing” between 2 devices (when 2 devices make contact for the very first time), that hacker can then intercept and modify all future communication between these devices.

During a security assessment, the laboratory examines the device for these versions of standard protocols and determines any vulnerabilities that result from their use.

Vulnerabilities Associated With Third-Party Components

Developers rarely build devices from scratch, but instead buy hardware and software components from other developers and use these components as part of their device. These third-party hardware and software components may have their own vulnerabilities, and these vulnerabilities are often available from on-line databases such as http://nvd.nist.gov ⁸ and http://vuldb.com ⁹ (see for instance http://vuldb.com/?id.92437 ¹⁰ for an example of a vulnerability in an insulin pump). Often, when a third-party component developer is told about vulnerabilities in the developer’s component, that developer brings out an improved component, but this may be too late for products using the vulnerable component as these are already out in the field.

During a security assessment, the laboratory examines the product for the use of third-party components, and searches databases, such as http://nvd.nist.gov ⁸ and http://vuldb.com, ⁹ for vulnerabilities in these components.

Vulnerabilities That Are Specific for the Product

Finally, there may be vulnerabilities in the device itself, which were inadvertently created by the programmers and designers of that product and are therefore unique to that product. These are the hardest to find during a security assessment.

During a security assessment, the laboratory thoroughly examines the device, its source code, and other information on the product, and the findings depend strongly on the experience of the security laboratory.

Rate the Vulnerabilities

In the previous step, vulnerabilities were derived from 3 sources. In this step, each vulnerability is assessed as to whether it is in scope, that is, can be performed by an experienced hacker or beyond

The security laboratory examines each vulnerability and determines that in order to apply it:

• - How much expertise it would take to find and exploit the vulnerability. Is it a simple one that can be found by anyone, or will it take a highly-skilled expert?

• - How much knowledge of the specific device is needed to find and exploit the vulnerability. Some vulnerabilities can be found without any knowledge of the device, while some require the hacker to somehow obtain the source code.

• - How much opportunity a hacker needs to find and exploit the vulnerability. Some attacks can be done with a single access of the device, and others may require millions of attempts, so the hacker has to have weeks of access.

• - How much equipment is needed. Some attacks may require just a smartphone with basic software, while other attacks require advanced transmission and detection equipment.

• - How much time is needed to find and exploit the vulnerability. Does a hacker need hours, days, weeks or even months?

Based on all of these factors, the security laboratory determines a numerical rating for each vulnerability, using a calculation formula in ISO 15048:2008 ¹¹ and compares this with the maximum vulnerability rating in the PP.

If the rating of the vulnerability is higher than the maximum vulnerability rating in the PP, the vulnerability is considered to be out-of-scope and is labeled a residual risk.

If the rating is lower or equal, the vulnerability is in scope and must be tested.

Perform Penetration Testing

In this stage, the lab will try out all the vulnerabilities that are in scope to see if they can lead to breaking the device.

If one of them works, the developer fails the assessment. The developer has to modify the device and then the whole process is repeated.

If none of the attacks is successful, the assessment is successful and proceeds to the final stage.

Reporting

Upon successful completion of the assessment, the security laboratory creates a report that describes:

• The work that was done under the assessment

• The vulnerability analysis that was performed

• The residual risks

• The tests that were done and their outcome

• The judgment of the laboratory

This report is then submitted to the DTSEC Working Group who, based on this report, make the final decision on certifying the device. Once certified, the DTSEC Working group places the device on the public certified product list, so that potential purchasers of the device know that they are purchasing a secure product.

Summary

In this article we have described the need for third-party security assessments of wirelessly connected diabetes device and outlined the procedure of doing so under the DTSEC standard:

1. Check if the device has the security functionality required by the PP

2. Perform a vulnerability analysis

3. Rate the vulnerabilities

4. Perform penetration testing

5. Reporting

This could be used to ensure that one purchases a secure diabetes device.