Design of Hack-Resistant Diabetes Devices and Disclosure of Their Cyber Safety

Parallels Between Cyber Security and Biology

Cyber security is clearly understood by engineers and techies - though seems obtuse if not over whelming to clinicians and patients. However, for anyone who understands the basics of infection, the major concepts are straightforward.

Computers and people both rely on perimeter defense, whether in the form of a firewall to block malware (malicious software, a term encompassing viruses, Trojans, worms, etc.) or skin to block microbes (bacteria, viruses, fungi), and neither survives without multiple levels of protection beneath that perimeter. For techies, the concept is defense in depth, which refers to the multiple ways to block, counterattack, and maintain vital functions just as is the way clinicians think of the immune system. Individuals and corporations are creating, testing, and marketing systems to recognize infiltration by malware. Biology provides the immune system for parallel functions.

One potential difference relates to the systems’ responses to infiltration. Tech systems typically are designed to be fail-safe, meaning that failure of a device component will not result in additional damage, or fail-secure, where component failure does not compromise the privacy of its information. In contrast, biologic systems are fail-operative, meaning their design ensures relatively normal activity even when a component of the system fails. Just as a device cannot be fully hack-proof, biologic systems cannot be truly fail-operative. The human response to a viral pneumonia provides insight into a fail-operative biologic system. In most cases, people can function and recover, with respiratory failure and/or death relatively uncommon.

As the term “cyber security” is used by the technically focused, “cyber safety” will be used herein to reflect the needs of the clinical community. And the proposal herein will focus on how to reduce the cyber risks, in part, by reducing the threat surface, or for clinicians and patients, the number of ways in which the devices can be infected with malware.

Malware Infiltration Concepts

Cyber compromise of medical devices is manifest in many ways, some easy and some quite difficult to detect initially. In the end, as the compromise spreads, device dysfunction becomes evident after significant damage. Presented here are two major types of compromise to illustrate the need for cyber safety.

One form of compromise relates to device function. Malware can hijack control, leading to a device performing unintended acts, such as administration of insulin even when not necessary clinically. Hijacking of sensing/monitoring can be just as problematic. A device that tells the user that glucose levels are adequate when they are not leads to inaction and potential danger. And when both the actuator (insulin infusion) and sensor (reporting glucose levels) are hijacked simultaneously, malice can be undetectable until too late. In addition, with powerful microprocessors embedded in medical devices, malware can cause a device to perform functions not intended by the developer/designer, such as transmitting the malicious code into a health IT system. Pivoting of malware from a device into an IT system would permit theft of personal and insurance information, highly valued for fraudulent pursuits. ¹²

Another form of compromise relates to data/information integrity. While medical devices are often manufactured, sold and used in a manner that means the manufacturer would be subject to HIPAA regulations, ¹³ encryption is not always part of such devices. Hackers would have a relatively easier time compromising the privacy of such information. One form of malware can encrypt the information within a device and/or system - whether it was encrypted inherently or not - and prevent the user from accessing the data it needs to access. This type of malware - ransomware - is increasingly common. ¹⁴

Compromised Cyber Safety

Several examples of cyber compromise outside of the medical arena are illustrative. The Target hack ¹⁵ (with theft of tens of millions of credit card credentials) was successful for several reasons, including poor system architecture, use of an insecure operating system, availability of unsecure communication ports and lack of proper surveillance. A contractor unknowingly transmitted malware into the Target network as part of communication for its servicing of HVAC systems. The system did not segregate these communications from its financial infrastructure. That enabled malware to migrate across the system to thousands of their point of sale credit card processing machines at stores across the country running a version of Windows that was over 10 years old - an operating system developed when the primary security concern was the Y2K bug. When a customer would swipe a card, the malware would record that information, and then use an open communications port to transmit that confidential information to remote servers where the information could be used or sold on the black market (the dark net). This scheme was active for months before it was recognized.

Amongst the lessons are two for consideration. First, architecture of critical systems must segregate critical and non-critical functions. In this case, financial records and project management should not freely communicate. The airplane industry understands this - segregating entertainment and WiFi networks from navigation and avionics systems. Second, use of an operating system that is built for flexibility inherently compromises cyber safety by providing access to unnecessary functions and communication ports. For relatively mature devices and/or systems, the flexibility of a state of the art microprocessor is not necessary—certainly one does not expect to need a quad-core state of the art chip to control an insulin pump. And that becomes relevant with a chip’s functions. With proper design of firmware and operating system, the multitude of communication ports can be disabled, providing limited access for infiltration and concentrating device capabilities on the actual resources needed to ensure proper operation. Subsetting operating system functions is a recognized but rarely used cyber security tactic, and can be extended to hardware capabilities.

The challenges of securing devices with vast power and capabilities were shown by separate groups that hacked an implanted defibrillator ³ and a diabetes system. ⁴ The compromise of diabetes devices was not limited to those with access to expensive tech - twice hackers reported successfully compromising insulin pumps.^5,7 In each of these cases, adequate security did not appear to be designed into the devices from the beginning, and gaps in communication, encryption and authentication proved exploitable.

In 2014, white-hat hacker Billy Rios evaluated a bedside infusion pump and learned that it could be controlled remotely via the Internet. ⁶ After several months, FDA and DHS ordered physical removal of the affected pump. ¹⁶ And while the agencies’ actions suggest that the problem was solved, Mr. Rios raised the possibility that the software vulnerability could exist in other models, based on his evaluation of available firmware. With no mechanism to require the company to disclose proof of successful cyber safety testing, and access to these devices limited, it is not possible to know whether the risk is sufficiently addressed by the actions do date.

In this context, it was not surprising when MedSec reported that a defibrillator lacked sufficient cyber safety. ¹⁷ Remarkably, the manufacturer chose to counter the allegation by filing suit for false and misleading statements, rather than present results of its successful vulnerability or penetration testing. The most effective way to combat allegations of risk would be the disclosure of testing that shows the devices to have acceptable systems to block hijacking and/or malware injection, rather than pursuit of legal action without such disclosure, exemplified by the contrast between the behavior of the defibrillator manufacturer (St. Jude Medical) and that of Johnson & Johnson disclosing a vulnerability in their diabetes device. ¹⁸

Whether the MedSec analysis is verified or not, the lack of prompt disclosure by the manufacturer of its cyber security testing at least serves as a testament to the lack of transparency that clinicians and providers deserve.

Assessing Cyber Safety

Cyber security is assessed via vulnerability and penetration testing. For the former, a relatively consistent approach is used, with tools readily available. Identification of open communication ports or inadequate encryption security are relatively straightforward to evaluate. Penetration testing is more cumbersome and requires different skills and tools. Here, the assessment does not rely on cookbook approaches or standard processes, rather, depends on the operators’ assessments, creativity and technical skills. Vulnerability testing can be thought of as a system scan, akin to anti-virus software, while penetration testing is performed by individuals using unique tools to creatively probe a device and/or system.

These assessments are performed by hackers who seek to improve security, and therefore, are often referred to as white-hat hacker testing. Companies are more frequently offering bounties to the public to perform as white-hat hackers and find vulnerabilities.

Recently, the state of Michigan’s Merit network established a secure, isolated sandbox, where software, devices and/or systems could be tested for cyber security without risk of problems affecting systems in use elsewhere. ¹⁹

A major problem facing interested manufacturers is the lack of accepted standards for conducting or reporting the testing. Thus, until such standards are in place, the best solution is for medical device manufacturers to transparently report the testing performed and the degree to which their device(s) passed those tests. As the Diabetes Technology Society points out, a higher level of cyber safety assurance is possible with the addition of third party testing. ²⁰

A Cyber Safety Framework for Diabetes Devices

Recognizing the impossibility of providing advanced functions in medical devices and complete cyber safety, this proposal focuses on three steps possible to implement in device design now to be in use clinically in the near term. If employed, such tactics will render the medical devices sufficiently more difficult to hack - with a markedly reduced threat surface - that they will become less desirable targets - reinforcing their safety by reducing the number of attacks.

First, diabetes devices must use end to end encryption (E2Ee), which would ensure that any data collected and information stored would be encrypted at the moment it enters the device, be that at the factory, via user input or from connected sensors. All information stored in the device memory and when transmitted would be encrypted, with decryption possible at its intended destination. The method of encryption would be determined by the manufacturer and could use SHS, AES, or another algorithm. Often this approach is avoided owing to the requisite power consumption of ongoing encryption in a battery-powered device. ²¹ However, when using worn devices, batteries can be recharged or replaced easily, and this inconvenience must be accepted for the sake of cyber safety.

Second, diabetes devices must use secure firmware and operating system. Relying on open source Linux is likely better than an older version of Windows, and using the Department of Defense’s version of secure Linux is even superior.^22,23 Alternatives would be to use any OS with only the subset of functions permitted that are necessary to device/system function or use a custom OS, such as a real time OS. By moving from less secure and more flexible firmware and OS to ones selected and configured to permit exactly the necessary functional capacity - and no more - cyber safety will improve.

Third, the memory of devices must be protected. Tech experts are familiar with vulnerabilities that allow for access to memory, either to read (SQL injection) or write/execute commands (buffer overrun). For each, methods implemented early in the design process can obviate either, ¹² but manufacturers do not document proper prevention/mitigation tactics. And given that many medical devices in use are modified versions of devices first designed at least 10 years ago, it does not appear likely that such mitigations are in place.

Another memory protection tactic is remarkably simple - though again it must be part of the design process from the early stages. When designing a system, a powerful way to ensure cyber safety is to prevent a device from writing any malicious code or erroneous data to sensitive memory locations. Consider the typical function of a computer - it dynamically allocates its memory (RAM) as it is needed - either for storing code, a variable value or data for later analysis, as examples. But that approach is based on the limited memory available from the time of the first general purpose computer in the 1940s (ENIAC), and called von Neumann Architecture. Today, memory is cheap. Therefore, RAM can be allocated for specific purposes, for computer code or data, for example, and each such region can be irreversibly set to allow execution of code or not, to read or write only, to read and write, etc. Creating non-executable memory regions to where the computer can store information means that even if a hacker tells the device to write malware to memory, it will only go to a region where that code cannot be executed. This would exemplify fail-operative design—wherein a device fails to protect against malware written to its memory but there is no alteration in device function.

There is an ill-defined concern that better security would hamper care in an emergency situation. However, for wearable diabetes devices, this is not a relevant risk as the device can be disconnected and standard medical treatment provided.

Conclusion

Proposed is a three-part approach to assuring better cyber safety, use of end-to-end encryption, secure firmware/OS and memory protection. Critically, these or any other approach cannot be mandated - and developing standards will take years. Thus, the regulatory bodies should welcome manufacturers to include in their product label the security testing performed and what architectures are used to ensure safety. In parallel, clinicians and patients should conclude that the lack of information reflects a product with a lack of cyber safety.

Realistically, these tactics are unlikely to be implemented by medical device companies without a catalyst. Will this be a disruptive new entity? Can professional societies trigger a sea change? ²⁰ Would the FDA be considering such steps already? Or perhaps the Department of Homeland Security plans to serve as a government convener as part of its focus on medical device cyber security? If lessons from Christensen’s “The Innovator’s Dilemma” are to be applied, then hopefully there is a person or group poised to launch a product or program as a market disruptor, and move diabetes devices into a state of cyber safety as they move to usable, effective tools to manage diabetes.