Threats to Critical Medical Monitoring Devices

Tuesday, August 17, 2010

Danny Lieberman

959779642e6e758563e80b5d83150a9f

What is more important – patient safety or the health of the enterprise hospital Windows network?  What is more important – writing secure code or installing an anti-virus?

A threat analysis was performed on a networked Windows-based embedded medical device used for patient monitoring.  The system helps hospital staff prevent crisis situations through ongoing supervision of patient status, early detection of warning signs, and alert notifications of changes in patient condition. 

The threat analysis used the PTA (Practical threat analysis) methodology, described in Appendix A of the full article reporting on the threat analysis of a medical device in PDF format.

Our analysis considered threats to three assets: medical device availability, the hospital enterprise network and patient confidentiality/HIPAA compliance. Following the threat analysis, a prioritized plan of security countermeasures is suggested in Section III. We devoted special interest to the issue of propagation of viruses and malware into the hospital network.

Our analysis shows that installing anti-virus software on a medical device is less effective than implementing other security countermeasures that mitigate the most severe threats – ePHI leakage, software defects and USB access to bedside units.

A detailed discussion appears in Section IV of this paper. Section V suggests segregating the bio-med functions from the hospital enterprise IT.  Section VI provides a summary of the analysis and its findings.

A novel benefit of our approach is derived by providing the analytical results as a standard threat model database, which can be used by the medical device manufacturers and hospital customers to model changes in risk profile as technology and customer environment evolve. The threat model can be downloaded here and the threat modelling software can be downloaded here.

I. Introduction

A threat analysis was performed on a networked medical device that performs real time patient monitoring at the bedside. The analysis considers the security implications of deploying the devices inside a hospital network. A key concern for hospital IT management is whether the medical devices create new entry points for viruses and malware in the enterprise network.

System configuration

The system configuration consists of fan-less, diskless embedded devices, with a touch screen and an Intel processor running Windows XP.  Flash storage is used for the operating system and application software. The devices have two Ethernet ports, a USB port and are networked using a proprietary TCP socket protocol to nursing stations that provide a management console function. The devices are not members of a Microsoft Active Directory domain and do not have Internet connectivity.

The process

A data collection phase employed face to face interviews with software and hardware developers and directly examined the medical device software and hardware. We identified potential attackers, entry points, threats, vulnerabilities and security countermeasures (those already implemented and those that might be implemented).  Following data collection, we performed a threat analysis using the PTA (Practical Threat Analysis) methodology summarized in Appendix A and described at length on the PTA Technologies web site.

Threat model entities

Our threat model uses four base classes; mapping assets to vulnerabilities, threats that exploit vulnerabilities and countermeasures that mitigate vulnerabilities.

For example:

Threat T1 – a networked nursing station may serve as a gateway for injection of malicious software to bedside units and impact

Asset A1 –the availability of critical patient monitoring.

Vulnerability V1 – Nursing station has external network connectivity

Countermeasure C1 – Segregate the networks

Countermeasure C2 – Operate a standalone nursing workstation

The key assets were medical device availability, the hospital enterprise network and patient confidentiality. We received input from hospital IT management regarding annual rates of occurrence of virus and malware attacks (rare) and phishing attacks on hospital employees (the usual email-borne pharmacy scams etc…).

II. Top unmitigated threats

After building the threat model with the four base classes and their relationships, we estimated the probability of threat occurrence, percent damage to assets and risk mitigation effectiveness.  

Trusted insider information leakage event frequency was estimated as twice/year in the threat model, while virus, denial of service and malware attacks frequency were estimated to be rare (less than once every 3 years). 

Hospital IT were primarily concerned with the health of their enterprise network (as opposed to the availability of the medical devices) – described in threat T017.

The 5 most severe unmitigated threats in our model (shown below), are derived using the PTA calculative method (http://www.ptatechnologies.com/?action=4pta), which takes into account estimated asset value, threat probability and  percent damage due to a threat event.

The TXXX identifiers in the left hand column refer to the entities in our model.

Entity Ids and Threats

T002      Trusted insiders may leak ePHI to interested parties (insurance companies etc…)

T019     Software defects and/or configuration changes may cause the units to become unresponsive and incapable of providing the patient monitoring service

T017     The Windows-based medical devices may be infected and propagate malware/viruses to the hospital enterprise network

T001     Malicious agents may access the system from inside the hospital network in order to steal, modify data or disrupt operation.

T021     Hardware defects may cause the units to become unresponsive and incapable of providing the monitoring service

Removing electronic Protected Health Information (ePHI) from the medical device

Unauthorized disclosure of ePHI (T002) was nominally the most severe threat at the start of the analysis due to compliance (HIPAA) / patient privacy concerns.

Protected health information (PHI) is any information in the medical data set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment.

Following the threat analysis, it was decided to remove all personally identifying information and use an alphanumeric designator, displayed on the bedside unit screen and at the nursing station.

Nurses can respond quickly to alarms of changes in patient signs (heart/respiratory rate) reported by a particular bedside unit without being exposed to personally identifiable information.

After removing ePHI, the risk assessment changed and the threat of the medical device infecting the hospital enterprise network (T017) then became our primary concern.

III.  Recommended countermeasure plan

Using the PTA quantitative threat model, we then calculated a prioritized plan of security countermeasures as shown in the following table. The below table is sorted according to recommended priority of implementation in terms of risk mitigation effectiveness. After implementing the below countermeasures, the calculative model estimates a residual risk of less than 3% to system assets.

Security countermeasures plan

The TXXX and CXXX numeric identifiers refer to threat and countermeasure entities in our threat model.

Threats and Security Countermeasures

T002 – Trusted insiders may leak ePHI to interested parties (insurance companies etc…)

C061 – Remove all ePHI (protected health information) from the patient monitoring system

T019  – Software defects and/or configuration changes may cause the units to become unresponsive and incapable of providing the patient monitoring service

C014-Perform software security assessment of relevant module/component/functions

C041-Set write permissions at start of upgrade procedure

C055-Perform post-install, post-software update validation check

C057-Use updated .NET framework from Microsoft and upgrade dependencies

T017 – The Windows-based medical devices may be infected and propagate malware/viruses to the hospital enterprise network

C039-Implement a procedure for ensuring clean version distribution media

C048-Implement an IO-board hardware toggle for disabling USB ports

T001 – Malicious agents may access the system from inside the hospital network in order to steal, modify data or disrupt operation.

C001-Block enterprise network access to bedside monitoring units

C047- Configure communications software to validate  and discard invalid messages

C052-Implement system tcp/ip data messages in binary format that are relatively difficult to decode via sniffing

C061 – Remove all ePHI (protected health information) from the patient monitoring system

T021 – Hardware defects may cause the units to become unresponsive and incapable of providing the monitoring service

C058-Provide system health check and expose alert to nursing station Patch Management

Patch management

The question of patch / update management arose during the study – the results are perhaps counterintuitive for typical IT managers:

  • IT policy of running automated Windows Update on Windows PCs in the office is not necessarily a relevant countermeasure for embedded medical devices.
  • Although FDA 510(K) recertification of the medical device may not be necessary when applying security patches – running Windows Update is practically impossible in an embedded device that does not have Internet access. The medical device vendor would typically apply patches to the embedded image as part of ongoing device field maintenance.

We note that the bedside monitoring system is a specialized (not COTS) embedded device that does not have Internet or removable device connectivity. The device does not run MS Office, does not run IE and is not connected to the Internet and therefore has a much smaller threat surface than a typical Windows PC installed on the hospital network.

For these reasons, we focused our efforts on security countermeasures that would reduce the most severe threats – ePHI leakage, software defects and USB access to the bedside units.

IV. Propagation of viruses/malware in the enterprise network

One of the key security concerns when operating networked, Windows-based embedded medical devices is whether new entry points for viruses and malware are created in the enterprise network.

We sub-divided this concern into 3 separate threat scenarios:

  1. Can the medical devices be infected from the enterprise network?
  2. Can the medical devices be infected via USB devices?
  3. Can infected medical devices propagate malicious software back into the enterprise network?

The short answer is no.

The medical device analyzed in the study uses Windows XP/SP3 and run a proprietary TCP/IP messaging protocol in order to communicate with the nursing station. The data flow using TCP/IP sockets follows the following high-level message flow:

A bed pressure sensor sends a signal via RS232 to a thread that acquires data and sends the data to a DSP sub-system via an exported function interface that returns heart rate (HR) and respiratory rate (RR) metrics based on patient movement. The bedside unit operator can set thresholds for alerts.

A local TCP/IP socket that binds to localhost is used to send trend data and alerts to the local bedside unit GUI.  Heart rate and respiratory rate data is averaged and accumulated into a local binary event log at a sampling frequency of 2hz.

A remote socket is used by the bedside unit to send alert data to the remote GUI at the nursing station.  The nursing station uses the remote socket to request reports from the bedside unit, which responds by sending a report file in PDF format.

The TCP/IP port numbers are defined in a configuration file included in the factory installation package. As noted above, there are internal and external sockets, two external sockets are used, one for transferring binary data and the other for transferring XML text; these sockets are in the range 3030-3035. The TCP/IP message format contains a 2 byte guard prefix, a size field, a 2 byte guard suffix and a checksum. The TCP/IP listeners validate the message using the guard fields, the checksum and length, enforcing a maximum message length of 2K although most messages are about 200bytes.

The operating system itself is hardened, does not run Windows shell, does not run IE and shuts down all unneeded services such as SMB and RPC. In addition, it runs a Windows Firewall instance that blocks all ports except the TCP/IP listener ports.

Although a dedicated attacker with the right skill set might be able to sniff traffic, reverse engineer the protocol and fuzz there is always the question of whether or not the value of the asset justifies the attack. In  this configuration – where the bedside units use guard fields, validate message lengths and contain numeric heart rate and respiratory rate data we felt that the medical device software is not particularly vulnerable to such attacks.

  1. 2. Can the medical devices be infected via USB devices?

The short answer is yes – potentially by anyone who inserts an infected USB removable storage device.

We have addressed this vulnerability in countermeasure C048 – “Implement an IO-board hardware toggle for enabling/disabling USB ports”. We also strongly recommend migration to Linux – with no USB auto-run functions (see next section).

The bedside unit uses an IO board with a hardware toggle on the USB lines. The USB lines are normally disabled (i.e. the gate is normally open). When a device technician needs to perform an update, he enters a maintenance password and the medical device software enables USB access temporarily.

  1. 3. Can USB-infected medical devices propagate malicious software back into the enterprise network?

The short answer is yes.

Although the proprietary request/response communications protocol used by the units cannot be used to transport files to other Windows PCS, a worm such as Conficker can exploit vulnerabilities in Windows services, disable the Windows firewall and propagate from the source computer to the hospital network on an arbitrary port between 1024 and 10000.

V. Future: segregation of bio-med and IT domains

While hospital IT typically uses Microsoft Windows; for embedded networked medical devices, we suggest using Linux due to its ease of maintenance and resistance to USB exploits and worms such as Conficker that exploit Windows software.  

The suggested configuration would consist of an up-to-date Linux kernel, touch-screen support and a main loop to run the medical device application.  A more detailed discussion of the proposed Linux implementation is beyond the scope of this article.

VI. Summary

A threat analysis of a networked medical device was performed and a mitigation plan of countermeasures was produced, including recommended priority of implementation.

As a result of the analysis, it was decided to modify the medical device design and not to store ePHI. This is obviously the most effective countermeasure possible for HIPAA compliance and protecting patient privacy.

Attack vectors using infected USB storage devices remain a concern and need to be addressed by migrating from Windows XP to Linux.

Cross-posted from Israeli Software

Possibly Related Articles:
15900
HIPAA
HIPAA HITECH
Post Rating I Like this!
0959a7ebfae15af185490b3a2c849c68
g b Why wasn't the NIST 800-53 utilized to evaluate these systems?
1325191987
959779642e6e758563e80b5d83150a9f
Danny Lieberman There are a number of reasons why we did not use NIST 800-53 for the threat analysis:

The first and most compelling reason not to use NIST 800-53 is that the standard defines control priorities in advance.

Neither does NIST consider the concept of asset value which means that it's impossible to calculate the cost of damage. But then again, in the NIST model it's not necessary to calculate value at risk, since the control priorities are legislated into the standard.

There is no point of doing a threat analysis if you know the prioritized security countermeasure plan in advance.

In the medical device and healthcare space, HIPAA (and common business sense) dictates a top-down risk analysis that fits the business situation between the HIPAA business associate (the device vendor) and the HIPAA covered entity (the hospital, doctor or clinic).

As comprehensive as it is, in my opinion, NIST is just like FISMA - the equivalent of counting rivets on an F-16 J and declaring it safe because the number of rivets comply with the Federal standard.
1325403665
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.