This is a piece I wrote a while back on my medical device security blog – Cybersecurity for medical devices.
One of the biggest challenge of using connected medical devices in clinical trials is near real-world usage of devices that are not commercially-ready.
We have a couple of customers that are performing clinical trials of medical devices in the ER and ICU. The tradeoffs between cybersecurity and patient safety are not insignificant.
What takes precedence? GCP or hospital network security?
Data quality, protocol compliance and patient safety are the 3 main pillars of GCP.
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?
In order to answer these question, we performed a threat analysis on a medical device being studied in intensive care units. The threat analysis used the PTA (Practical threat analysis) methodology.
Risk analysis of a medical device
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 was built and implemented including the issue of propagation of viruses and malware into the hospital network (See Section III below).
Installing anti-virus software on a medical device is less effective than implementing other security countermeasures that mitigate more severe threats – ePHI leakage, software defects and USB access.
A novel benefit of our approach is derived by providing the analytical results as a standard threat model database, which can be used by medical device vendors and customers to model changes in risk profile as technology and operating environment evolve. The threat modelling software can be downloaded here.
I. Introduction
A threat analysis was performed on a medical device used in intensive care units. The analysis considers the security implications of deploying the devices inside a hospital network. Different stakeholders have different security and compliance concerns and therefore different agendas.
- Hospital IT management – do the medical devices create new entry points for viruses and malware in the enterprise network?
- Medical device vendor and patient care staff – can we assure availability and integrity of the monitoring data?
- Hospital management – can we comply with HIPAA and reduce the risk of data leakage?
System configuration
The embedded system configuration is based on an Intel processor running Windows XP Embedded. The devices are not members of a Microsoft Active Directory domain and do not have Internet connectivity.
The threat analysis 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 – an attacker may obtain monitoring information and impact Asset A1–patient privacyVulnerability V1– Central management stations may have Internet connectivityCountermeasure C1 – Encrypt ePHI |
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 Id | 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 become 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 medical device screen and at a central management 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/Security countermeasures |
| T002 – Trusted insiders may leak ePHI to interested parties (insurance companies etc…) |
| C061 – Remove ePHI (protected health information) from the 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 and QA review |
| 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 the report writer application at the central management station that uses .NET to produce PDF reports |
| T017 – The Windows-based medical devices may be infected by a USB device and propagate malware/viruses back to the hospital enterprise network |
| C048-Implement an IO-board hardware toggle for disabling USB ports |
| C039-Implement a procedure for ensuring clean device version update media |
| 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 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 central management station |
Patch management
The question of patch / update management always arises in the course of a threat analysis of medical devices; 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 an ICO medical device 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 medical device itself.
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:
- Can the medical devices be infected from the enterprise network?
- Can the medical devices be infected via USB devices?
- Can infected medical devices propagate malicious software back into the enterprise network?
Can the medical devices be infected from the enterprise network?
The short answer is no.
The medical device analyzed in the study uses Windows XP Embedded and a proprietary TCP/IP messaging protocol in order to communicate with a central management station.
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 cost of the attack. In this particular medical device, considering the hardware configuration and use of a proprietary messaging protocol; we felt that the medical device was not particularly vulnerable to such attacks.
- 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 recommended migration to Linux – with no USB auto-run functions (see next section).
- 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 systems typically use Microsoft Windows; for an embedded medical device, we highly recommend using Linux due to its ease of maintenance and resistance to USB exploits and worms such as Conficker that exploit Windows software. A suggested minimal configuration should consist of an up-to-date Linux kernel, QT, touch-screen, network 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. See the excellent article “The Top 10 mistakes embedded Linux developers make for some guidelines“.
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. In addition, a decision was taken to migrate the medical device OS platform to embedded Linux to eliminate typical Microsoft Windows network and removable device vulnerabilities.
About the author
Danny Lieberman is an expert in helping medical device vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments. He is the founder and CEO of Flaskdata.io – a digital platform that speeds time to regulatory submission with automated patient compliance detection and response.
