- NETSCOUT to Support HL7 Health IT Standards with nGeniusONE
- HL7 Calls for Further Build-out of Interoperability Infrastructure
Unfortunately, the HL7 standards are frequently implemented in an unsecure way, which results in unauthenticated, unvalidated, and plaintext transmission of sensitive data across networks. This could lead to data privacy breaches as well as patient injury, the researchers from UC San Diego and UC Davis Medical Center warned.
“In the absence of encapsulating encryption and authentication, the protocol poses a prime target for attack,” the researchers observed in their paper.
The researchers developed a tool to carry out an automated man-in-the-middle (MITM) attack that exploited encryption and authentication vulnerabilities in most HL7 implementations. They were able to change lab results from normal values to those observed in serious illness, which could lead to clinical staff misdiagnosing a patient and causing the patient harm.
The researchers constructed a testbed consisting of an open-source electronic health record system, an HL7 connection integration engine, a laboratory information system, and a blood gas analyzer machine. The testbed was designed to mimic systems deployed in clinic environments by using devices and software currently deployed to care for patients.
The simulated attacker carried out an MITM attack using the researchers’ Pestilence tool. “Pestilence initiates arp-poisoning against targets found through either dynamic (monitors network traffic and determines targets) or static (preconfigured from configuration files) runtime configurations,” the researchers related.
The attacker was able to corrupt blood gas analyzer results for a patient suffering from viral gastroenteritis or dehydration to mimic the results of a patient suffering from diabetic ketoacidosis (DKA). Treatment for DKA, IV fluid replacements and insulin infusion, could cause seizures, coma, and heart attack in a patient not suffering from DKA.
“The integrity attack outlined in this paper is just one of the many possible given the current vulnerable surface area of hospital technological infrastructure. It follows that HL7 … is a symptom of a more fundamental problem in contemporary healthcare IT; the protocol’s prevalence demonstrates the flawed, legacy-device foundations of the current patient care environment,” the researchers explained.
They recommended three security strategies to increase security and data integrity in clinical environments:
- Network segmentation, virtual local area networks, and firewall controls: “By restricting the attack surface of vulnerable devices to Ethernet networks inaccessible to outside influence, the potential for attack is largely mitigated.”
- Proper network configuration: “In situations where the hospital network cannot be made completely secure through use of network segmentation, the alternative is proper configuration of servers and devices that support encryption.”
- Security conscious protocols and ecosystems: “Moving forward, device manufacturers, care providers, standards organizations, and policy makers must push to incorporate newer protocols and ecosystems where strong security guarantees are built in, and actively look for these guarantees.”
An example of increased security consciousness is HL7’s Fast Healthcare Interoperability Resource (FHIR) standard, which includes encryption and authentication provisions.
FHIR “is not a security protocol, nor does it define any security related functionality. However, FHIR does define exchange protocols and content models that need to be used with various security protocols defined elsewhere,” explained the FHIR Infrastructure Work Group.
FHIR users and clients must be authenticated, and FHIR defines a security label infrastructure to support access control management. Exchange of data is carried out using the transport layer security (TLS) protocol.
“A production FHIR system will need some kind of security sub-system that administers users, user authentication, and user authorization. Where this subsystem fits into the deployment architecture is a matter for system design,” the work group explained.