HL7 Data Interfaces in Medical Environments

Ask healthcare IT professionals where the sensitive data resides, and most will inevitably direct your attention to a hardened server or database with large amounts of protected health information (PHI). Fortunately, there is likely nothing wrong with the data at that point in its lifetime. But how did those bits and bytes of healthcare data get to that hardened server? Typically, in a way you would ever expect… 100% unencrypted and unverified. Beyond the headlines involving medical device insecurities and hospital breaches, healthcare communication standards are in need of better security. A fundamental design flaw places patient data at risk in nearly every healthcare organization worldwide. Without protections in place, a hospital visit today could become a patient’s worst nightmare tomorrow. Welcome to the world of HL7, an often overlooked messaging standard used throughout healthcare which could benefit from stronger built-in security features.

Sensitive Data Everywhere

In comparison to other industries, healthcare contains some of the most sensitive and valuable data to an attacker. As found in Cybercrime and Other Threats Faced by the Healthcare Industry, electronic health record (EHR) data is unique in a way that it includes protected identifiable information (PII) along with medical, insurance and financial information. Medical records contain full names, physical addresses, Social Security Numbers, driver’s license information, email addresses, and even “answers” to frequently used security questions, e.g., past addresses and phone numbers, place of birth, relatives, and employer information. As such, a single EMR/EHR contains the data necessary for nearly every conceivable illegal activity ranging from identity theft to fake prescription refills.

Medical records for sale on the now-defunct AlphaBay (dark web), image source - Deep.Dot.Web

Role of HL7 in Healthcare

An overwhelming amount of healthcare data is mishandled every day, if not every second, due to a fundamental communications flaw. HL7 [or Health Level 7] is a relatively obscure standard that provides most of the system-to-system communications. It allows disparate systems in a hospital environment to speak a similar language. Unfortunately, nearly all the previously mentioned sensitive data is transmitted as clear-text, HL7 messages. And because HL7 is the standard that keeps disparate hospital systems in sync, even a smaller healthcare facility might have thousands of HL7 messages sent and received daily. But why are so many messages necessary? Nearly every “event” that occurs in a hospital sends a different HL7 message. For instance, separate messages might trigger during an admission, and another when ordering lab tests or receiving results, ordering drugs, sending charges, etc. A single hospital or clinic visit might result in hundreds of HL7 messages for an individual patient alone.

Screen-Shot-2017-09-20-at-6.18.16-PM.png

Example HL7 Admissions, Discharge, and Transfer (ADT) message

Insecurity Built-in

Despite the value of stolen health records and HL7 carrying some of our most private information, HL7 lacks built-in security – no encryption, no message verification, and no real security controls. It might come as some surprise that HL7 provides a similar level of security as the poster children for insecurity, Telnet, or FTP. However, unlike those known insecure protocols, HL7 does not require any authentication, nor is there any way to include authentication when establishing a connection. Essentially, those protocols are avoided entirely in most environments due to numerous security concerns, yet almost every healthcare facility uses HL7 for some of the most sensitive data imaginable even though it is a security nightmare.

Attacks on HL7

As with any insecure and unauthenticated protocol, there are numerous opportunities to attack the underlying communications. This issue is further compounded by HL7 often residing on a common network segment along with other standard traffic such as end-user workstations. A successful phishing email might be the only barrier between an attacker and PHI. In one scenario, an attacker could launch a denial of service (DoS) attack on HL7 interfaces by simply leaving the TCP connection requests open. In another, an attacker could send fraudulent messages from any system to a receiving HL7 interface. Fraudulent messages would allow an attacker to update patient records or even order drugs with a relatively basic knowledge of the environment. A third scenario is likely the most troubling. Once a foothold is established on a networked system, ARP (address resolution protocol) spoofing/poisoning is relatively easy to perform. ARP spoofing allows an attacker to intercept all communications between various systems [with HL7 interfaces] such as an interface engine and a lab system. The attacker could gather PHI or even modify network traffic in real-time with potentially fatal outcomes. Targeted attacks such as removing patient allergies and subsequently ordering severely allergic drugs move from the realm of Hollywood hacker plot to real-life.

ARP Spoofing Attack of HL7

Improving Security

What can be done to improve the security of existing HL7 interfaces without altering the complex, underlying components? After all, HL7 interfaces were frequently multi-month projects requiring extensive configuration and testing. There are numerous ways to improve the security of HL7 with minimal impact on the interfaces themselves, and each have their own varying degrees of success. For example, while network segmentation will inevitably improve security, it will not mitigate the risk entirely. If an attacker could gain access to a network switch, the HL7 data would still transmit as clear-text. Meanwhile, host-based or network-based firewall rules eliminate the potential for errant messages but once again do nothing to protect data on the wire. The same goes for static ARP entries not preventing unauthorized access or protecting the integrity of the network communications. Encryption is clearly the answer. If HL7 messages receive any encryption-based protections, a VPN is the most common means. The issue is that interfaces typically only utilize VPN solutions when the data is sent over the Internet or shared with a different location, i.e., not for internal communications. This goes back to the common [and still widely held] belief that internal networks are “trusted.” Regardless, a site-to-site VPN provides encryption between the tunnel endpoints, but it does nothing to protect the data before reaching the point of encryption. One cannot overlook the security of the HL7 data pre-encryption when analyzing the risks associated with handling insecure data. Another alternative to securing HL7 data without an interface overhaul is SSH tunneling. SSH tunneling is easily implemented because SSH is built into most modern operating systems. Even on Windows-based systems, the Win32-OpenSSH PowerShell package could be used. Not only is SSH tunneling straightforward to implement; it is also free aside from time. In addition, the configuration requires very few changes to either endpoint and zero changes to the actual HL7 configuration. In most cases, the only required change is the ‘localhost’ redirection on the sending side since the other particulars are handled by SSH.

HL7 Over SSH Tunnel Comparison

Focus on the Problem

Healthcare communications such as HL7 need security measures added for both existing and new installations. Protecting medical record data or any medical device for that matter is nothing more than a pipedream unless secure communications become the standard in healthcare. Without significant improvements, healthcare will continue to be low-hanging fruit with high rewards. Healthcare needs to do more to protect data and that change needs to happen now. Interface architects and defenders cannot ignore the extraordinary amount of damage an attacker can cause by collecting HL7 data or using it for more nefarious purposes. Sensitive HL7 and patient medical data cannot continue sitting in the open, waiting for the next major breach to occur. Our data is too valuable.