There are thousands of medical devices in use today vulnerable to hacking. Hospitals, outpatient centers, healthcare practices and even patients in their homes use high-tech equipment every day to monitor care, improve patient outcomes, and save lives. However, these connected devices (and the data housed within them) are at risk for exploitation without proper authentication and encryption.
Speaking at the DigiCert Security Summit this week, Darin Andrew, senior PKI and solutions architect at DigiCert, and Scott Erven, senior managing director at PwC, ran through three common scenarios that leave these critical pieces of infrastructure wide-open to hackers—and how some of the danger can be mitigated using public key infrastructure (PKI).
In the first scenario, a healthcare provider has rolled out medical device integration that connects critical systems like ventilators, anesthesia pumps and infusion systems to the backend electronic health record (EHR) system. With federal mandates in place that require electronic record-keeping, this is an increasingly common IT practice. Within the integration, devices connect to middleware, which then passes diagnostic information between the medical devices and the EHR.
The problem is that all too often, SSL encryption and digital certificates are not deployed for that data transmission—and, session management tends to be nonexistent when it comes to middleware. That leaves a gaping security hole through which attackers can perform a man-in-the-middle (MITM) attack to grab the information from the middleware system. From there, they can view the information, or modify or replace it with malicious diagnostics that the middleware then dutifully passes on to the EHR.
The lack of data integrity here has two implications: It compromises privacy, but can also lead to patient safety issues.
“A lot of these integrations also do hard-coded API calls in clear text,” Erven added. “We need to learn from these failed practices and do things in a better way.”
The best-practice “better way” objective in this case is to implement an approach where it’s possible to positively identify both the sender and recipient, and encrypt the data so it can’t be modified or viewed. To do that, healthcare providers can create a trusted root that’s distributed to both the medical device and the middleware, then create a key pair for both. This binds the identification of both the medical device and the middleware to the public key—with a certificate signed using the trusted root. The end result is that as a connection occurs, the middleware checks the identity of the device and vice versa. And without that trust established, a connection is not allowed and the attackers have no opportunity to insert themselves.
It’s also important to issue a unique key for each session, so that an old key can’t be used for a new attack.
In the second scenario, a medical device manufacturer is following recent FDA guidelines to allow for over-the-air (OTA) updates of connected medical devices—and has designed a scalable system to enable just that. However, a common failing is that they don’t deploy code signing for those application and security updates. So, all it takes is for an attacker to compromise the centralized OTA server or infrastructure, perhaps via a phishing attack, which would allow attackers to forge a malicious update that can be deployed to all of the endpoints in the environment.
Those malicious software updates can install malware that allows for remote access—which would give the attackers the ability to modify the configuration of devices on a significant scale.
So, what’s the mitigation? The goal is to protect the OTA server and the endpoints, and prevent attackers from running code on devices. This can be done by implementing PKI to verify that the code is authentic before the endpoint agrees to run it.
Any code pushed OTA should be signed with a certificate issued with a trusted root, so that it can be identified as “trusted” via a mutual authentication connection.
The idea is to create a trusted root that can be recognized by both the server and the endpoint as authoritative—and then issue the cert from that root to sign the code,” explained Andrew. “Both the server and the devices check the signature on the code, and if it’s not validated, the device won’t run it.”
Erven added that this is only one layer of security, however.
“PKI infrastructure authenticates the actual validity of the update going out,” he said. “But you still need to be careful that you’re enabling two-factor authentication on that server box. It holds the keys to the kingdom—and if an attacker can compromise that, he can still compromise the system. So you need to keep in mind that additional layer, or you can have a really bad day.”
The third scenario also has to do with hardware manufacturers: protection of the source code/firmware that runs the devices. Attackers can extract and modify code, then push it back to all like devices.
“Attackers have no trouble popping a device open and quickly reverse-engineering the firmware,” Erven said. “Once they’ve done that, they can quickly then push new firmware to gain control of the devices.”
In the aftermath, the system and network are compromised, as is the intellectual property contained in source code. Attackers also gain remote access and can escalate to administrative access.
The objective here is to verify whether the source code or firmware is authentic before running it—and to prevent code from running that will compromise intellectual property and network resources.
Manufacturers can implement the use of Secure Boot to check the signature of boot image before allowing device to boot. Also, it’s critical to sign the firmware/source code with a trusted certificate, and then use that signature to check for authentic code before booting.
In all of these cases, it’s important to remember that other best practices must also be adhered to, Erven and Andrew noted. For instance, administrators often implement shared keys for all endpoints—offering attackers a “single throat to choke,” so to speak. Or, looking to minimize operational overhead, IT departments might ask for the keys to not expire for 25 or 30 years.
“PKI done wrong isn’t going to help,” Erven said.