How to Hack Your Own Medical Device

Companies are turning to simulated cyber attacks to ensure the security of their medical devices.

September 15, 2014

8 Min Read
How to Hack Your Own Medical Device

By Daniel Hamburg, David Surber, and Brian Nolan

The growth of data networking technology employed by hospitals to transport data throughout their facilities has dramatically improved the quality of care for patients. Today, doctors can access x-rays and health reports quicker than ever before, and specialists can even provide live assistance during an operation from anywhere in the world.

Patient data is managed electronically, and ever-greater volumes of information are digitally stored, processed, and disseminated across both internal and external communication networks. On top of this, there has been growth in connections to external locations, secondary key personnel, cooperation partners, IT suppliers, and home offices for background or weekend services—all of which help guarantee interruption-free communication.

However, this advancement in data sharing brings with it additional risks—primarily, the theft of sensitive patient information and the potential malfunction of devices as a result of system or network hacking. Medical devices are often easy targets for hackers. By exploiting vulnerabilities within the software or security loopholes within the wider network, devices can be made to malfunction or stop operating, and patient data can be accessed and stolen. Another gateway for cyber attacks is inadequately secured mobile devices, such as tablets and smartphones, that are increasingly deployed in healthcare settings to control medical devices as well as brought in by visitors.

To date, there is no known case of a patient actually suffering harm as a result of a cyber attack, but because the opportunity is growing, it is likely to happen at some point.

FDA has recognized the threat posed by cyber attacks and recently issued guidelines that recommend that manufacturers of medical devices provide evidence that they have included cyber security in their risk analysis and management plans, and that they consider cyber security during the design phase of their devices. Specifically, the guideline recommends that manufacturers define and document the following components:

  • Identification of assets, threats, and vulnerabilities.

  • Impact assessment of the threats and vulnerabilities on device functionality.

  • Assessment of the likelihood of a threat and of a vulnerability being exploited.

  • Determination of risk levels and suitable mitigation strategies.

  • Residual risk assessment and risk acceptance criteria.

This article will introduce two tools that can be employed to help in this process: IT security analysis and penetration testing.

IT Security Analysis or Penetration Test?

Technical security analysis and penetration tests (pentests) are key components of a sustainable security protection framework. The aim is to determine the current level of security of the device software and to identify security-critical vulnerabilities in software design and/or implementation. Risks can be uncovered and practical measures taken to eliminate the vulnerabilities or to reduce the risk to a level acceptable for the organization without taking chances with the wellbeing and safety of the patient.

In both IT security analysis and pentests, security analysts determine possible technical threats to the IT systems, infrastructure, or applications used within the organization. In doing so, experts use the same strategies and tools as actual hackers, although for a different end. Their aim is to uncover vulnerabilities and loopholes, and close them before an actual hacker discovers them. IT security analysis and pentest projects have different goals and objectives, which are complementary.

The goal of an IT security analysis is to discover all of the vulnerabilities and security weaknesses related to the in-scope systems, while the goal of the pentest is to validate the effectiveness of existing security controls and to demonstrate risk through the exploitation of vulnerabilities. The IT security analysis is applied horizontally and is focused on finding as many back-door entry points (vulnerabilities) as possible through the medical device’s interfaces and/or its software.

A pentest is intended to simulate real-world attack scenarios by a dedicated and skilled attacker and demonstrate the impact of security weaknesses in human, procedural, and technical defenses that constitute the overall security of the environment. It may be possible to combine the information or access provided by several noncritical vulnerabilities to gain unauthorized access to critical data or systems. Thus, penetration testing can often reveal risks that are not evident through IT security analysis reports. Further, by clearly demonstrating how vulnerabilities can be exploited to lead to unauthorized access of critical systems and confidential data, the penetration testing report can often provide the management team with a greater insight into the risks to the organization. Often, the pentest is also designed to evaluate the organization’s security awareness, intrusion detection, and incident response capabilities. Both types of projects should be performed periodically as part of an organization’s vulnerability management program.

A Three-Step Process

In a nutshell, both IT security analysis and pentests follow a three-step process:

  1. Gather information.

  2. Identify security weaknesses.

  3. Exploit security weaknesses.

Step 1: Gather Information. During this step, detailed information about the networks and systems in scope is collected. The following tasks are typically carried out:

  • Passive analysis of the network packets received at the network interface.

  • Identification of available systems, interfaces and services within the scope of the analysis.

The objective of this step is to collect as much information as possible about the systems in scope. This information is used to carry out targeted and efficient attacks in the second and third steps.

As logical as this step is, it often has surprising results. For example, the identification of active interfaces not included in the system specification or administrative interfaces without proper user authentication. Hence, even this simple step gives the assessor a first impression of whether the system was developed with security principles in mind.

Step 2: Identify Security Weaknesses. During the second step, the available services are verified for security weaknesses that permit access to the affected system or the collection of more information. The following aspects are typically evaluated:

  • Detection of the patch level or old software and system versions.

  • Insufficient system and service hardening.

  • Protection against malicious software.

  • Access and user management.

Step 3: Exploit Security Weaknesses. During the third step, the security weaknesses that were identified in step two are exploited. The objective is to identify the impact of the security weakness (i.e., to which extent an attacker would be able to access data or systems). The actual tests highly depend upon the systems, interfaces, and services used in the device. Examples are the handling of invalid input data— both on protocol and on application level—and application and protocol specific aspects (for example, SQL-injection, XML-injection, or cross-site-scripting (XSS) attacks against Web-based applications).

As an example, let’s assume that during the information-gathering phase, a security assessor finds several active network services on a network-attached medical device such as a HTTP-based administrative Web interface. The penetration tester will then focus on this interface because he or she knows that Web interfaces are a common entrance point of attackers and are often error-prone.

The tester will continue by trying to login to the interface using standard username and password combinations, and hence proceed to step two and three of the test to identify and exploit vulnerabilities. If this approach does not succeed, the tester may try to execute SQL-injections against form fields of the interface. If the injection is successful and the tester gains unauthorized access to the interface, the next step will probably be to gain administrative access rights to the system, thus trying to penetrate the system as deeply as possible.

If the security tester is performing a security analysis, he or she will keep the HTTP-based administrative Web interface in mind for further testing but will first proceed with the information gathering. The tester will start the identification of vulnerabilities of the interface only after completing step one.

Creative Ways to Hit the Target

As mentioned previously, IT security analysis and pentesting complement each other. IT security analysis reveals significantly more about the product’s direct vulnerability to attacks; however, the sequence of a pentest can also demonstrate the effectiveness of the security measures implemented at subsequent levels.

Using the above example of the Web interface, a pentest may prove that the interface can be misused to gain administrative control of the whole system and manipulate it at will. On the other hand, due to limitations of the testing time, the pentester may not find other active services that also have vulnerabilities.

Like the pentest, the technical security analysis should not be confused with automated vulnerability assessments, which use software to check known vulnerabilities automatically at regular intervals. This type of analysis is comparable to an automated execution of step one and two of security analysis and pentest.

Security analysts use tools to perform their tests; however, they must independently develop and implement hacking targets and scenarios within the organization under testing conditions that are as realistic as possible. This requires in-depth knowledge of the current threat scenarios and the latest technological advances. If they come up against unexpected obstacles during an attack, then, just like a malicious hacker, they must find a creative diversion around those obstacles—even in the unknown terrain of a medical device or application—to reach their target. No automated vulnerability assessment can achieve this creative thinking. In the battle against actual cyber attacks, IT security analysis and pentests implemented by security analysts are key tools because, unlike any other method, they allow for the realistic simulation of a human attacker in a dynamic environment.

Nevertheless all three tests—vulnerability assessments, security analysis, and pentesting—are necessary tools to improve the security of medical devices.

Daniel Hamburg, Ph. D. is head of security engineering at TÜV Rheinland i-sec.Reach him at [email protected].

David Surber is vice president of medical products at TÜV Rheinland Group. E-mail him at [email protected].

Brian Nolan is practice director for Security Services at OpenSky. Contact him at [email protected].

[image courtesy of CHANPIPAT/FREEDIGITALPHOTOS.NET] 

Sign up for the QMED & MD+DI Daily newsletter.

You May Also Like