By Sean M. Houle, CISSP
One of the biggest factors in the adoption of electronic health records is a common standard of communication that allows dissimilar systems to be able to communicate with one another in a meaningful way. This is where the Health Level Seven or HL7 messaging standard is a true champion.
The messaging standard creates a much more efficient environment of care for patients as it greatly reduces the amount of paperwork for patients, health care providers, administrative staff and others to complete in the course of care. Once the initial information has been collected from the patient and entered into the electronic health record, that same information can be used when ordering medications, diagnostic lab tests or radiology images. It can also be used for transferring the results of those tests back to the health record for the health care provider to review and to become part of the patient’s permanent health record. This allows providers to spend more time caring for patients and less time with paperwork. It also helps prevent clerical errors by using information that has already been entered into the system. All this data can even be transferred to another health care facility to provide continuity of care.
As we take a deeper look into HL7 from a security perspective, we’ll focus on the HL7 version 2 (V2) messaging standard. According to the HL7 organization, 95% of U.S. health care organizations use HL7 v2.x and it is used by more than 35 countries. HL7 V2 was first released in 1987 as an application protocol for electronic data exchange in health care environments. The seven in the name HL7 is derived from the OSI network model, being an application layer, or layer 7 protocol. Being an application layer protocol released in 1987 with no direct end user interaction, security was not part of the design, instead relying on lower layers of the OSI model to handle security of the data being transmitted. As such, HL7 messaging protocol had no inherent authentication, confidentiality or integrity on its own.
One aspect of no confidentiality is that the information being transmitted is done so in plain text. To demonstrate, I setup a lab with one computer acting as the HL7 engine sending messages and another computer acting as the receiving client. I captured the network traffic on the client PC using Wireshark. As you can see from the packet capture (Figure 1), the data came across in plain text which included patient name, date of birth, address, phone number, patient ID number, health history and more. In our case, all of this data is fictitious. In day-to-day operations it is data that could be up for sale to the highest bidder.
For further investigation I set up a third computer in the lab, one that would play the role of bad actor (Figure 2). This computer was in the same network as the sender and receiver. I used a freely available security tool to conduct ARP poisoning, that is I sent messages throughout the local area network telling other hosts on the network that messages intended for the IP of the client machine should be sent to the MAC address of the hacker machine.
Once the attacker machine was actively poisoning the network, Wireshark was set to capture packets as they came across the network interface of the attacker machine. The transmission was started between the HL7 server and the HL7 client and within a matter of seconds the sample patient data showed up in the captured packets just as we saw in our last test (Figure 3). The attacker retained a copy of all the data and also forwarded the data to the client so that the system would continue to operate as normal.
Theft of patient information is bad, but the consequences of an attack like this could be far more devastating. As the middleman in the network traffic flow between the two computers, the attacker machine could have altered the message in transit resulting in incorrect data at the receiving end. This could mean things like a different medication or dosage than what was ordered, or perhaps the removal of allergy information. This is because there is no integrity control built into HL7 v2, or in other words no way to check to see if the message received is the same as the message that was sent.
One thing that I didn’t mention earlier is that to receive the messages, I did not have a fancy HL7 integration software. I used the very simple program Netcat. Netcat is built into most Linux distributions and is available as freeware for Windows. Without a method for authentication, I simply setup a listener on the port that the HL7 server was sending messages out on and collected the data. In this case, I output it to the screen to see immediate results, but the data can be easily piped out to a file as in the example (Figure 4).
Now how do we address this? We can’t cover all the details in this article but hopefully you can find some things to investigate and see if it would be a good fit for your network. Proper network segmentation is important in many ways and one of those is to help prevent ARP poisoning attacks. ARP messages do not travel beyond the local subnet so it can only affect machines within the same subnet. Many managed switches can support Dynamic ARP inspection to identify suspicious ARP packets. Next, encrypt data in transit whenever you can. This will render captured data useless to attackers as well as prevent the messages from being changed in transmission. One method that works well for in-house transmissions is SSH tunneling. If you are transferring HL7 data across the WAN outside of your organization, then a site-to-site VPN could be a good solution. Finally, good technology hygiene is important. When you decommission systems make sure you decommission everything related to them including HL7 links. Implementing these steps are good security practices beyond securing just HL7 and every step you take adds another layer to your defense in depth approach.
– Sean Houle, CISSP, is an Information Systems Biomedical Equipment Support Specialist (IS-BESS) with the Department of Veterans Affairs in Louisville, Kentucky.
