Pacemaker Ecosystem Fails its Cybersecurity Checkup

Pacemakers and pacemaker programmers lack authentication and are plagued with thousands of software vulnerabilities across leading manufacturers.

Pacemakers continue to be the front line of medical device security debates after a research paper published this week described a frightening list of cybersecurity issues plaguing devices built by leading manufacturers, including a lack of authentication and encryption, and the use of third-party software libraries ravaged by thousands of vulnerabilities.

Pacemakers are implantable cardiac devices used to regulate abnormal heart rhythms, and most are updateable by physicians and technicians either in proximity of the device or remotely. No area related to medical device security has received more attention in the last year, fueled mainly by MedSec disclosure of vulnerabilities in Abbott Laboratories-owned St. Jude Medical devices and its Merlin@home RF transmitter used to monitor implanted defibrillators.

Researchers Billy Rios and Jonathan Butts of WhiteScope IO this week published their examination of seven different pacemaker programmers from four different manufacturers. The programmers are devices used in clinical settings to monitor how implantable devices are working and set therapy parameters. Rios and Butts said their research concentrated mainly on four of the programmers that rely on more modern radio frequency communication, rather than proximity telemetry wands used by other devices.

Given the life-saving nature of the devices, Rios and Butts’ investigation casts a darker shadow on the security of these implants the infrastructure supporting them. They also demonstrate where patient care and cybersecurity are at loggerheads. For example, models don’t require physicians to authenticate to a programmer, and the programmer devices themselves don’t authenticate to implantable pacemaker devices.

“Any pacemaker programmer can reprogram any pacemaker from the same manufacturer,” the researchers wrote in a post summarizing the full report.

All of the pacemaker systems examined also had unencrypted file systems on removable media. And as far as the software goes, Rios and Butts discovered more than 8,000 known vulnerabilities in third-party libraries used across the programmers from each manufacturer. The researchers said all issues were, or will be, reported to the Department of Homeland Security’s Industrial Control System CERT.

“As seen in other medical device verticals, keeping devices fully patched and updated continues to be a challenge,” Rios and Butts said. “Despite efforts from the FDA to streamline routine cybersecurity updates, all programmers we examined had outdated software with known vulnerabilities.”

The 8,000 vulnerabilities were strewn across the four manufacturers’ devices and illustrate an industry-wide challenge related to patching systems and keeping them current. Some of the devices, meanwhile, were not only hackable, but were also a privacy concern because they stored unencrypted patient data on the programmer, including Social Security numbers and medical history.

“The patient data belonged to a well-known hospital on the east coast and has been reported to the appropriate agency,” Rios and Butts wrote. “These types of issues highlight the need for strong device disposal policies from hospitals.” The researchers said they bought the devices they examined from auction websites, even though they are supposed to be returned to the manufacturer after a hospital is through with them.

The programmers—one of four components in modern pacemaker deployments along with the pacemaker, home monitoring system and the update infrastructure—lack authentication likely to expedite patient care. All of the programmers studied by Rios and Butts booted directly into the programming software without requiring authentication; the programmers also do not authenticate to the implantable device.

“Proximity is the primary criteria for pacemaker programming,” they wrote. “This is an area where is appears that patient care has influenced the cybersecurity posture of the pacemaker programmer.”

The software running in the programmers, meanwhile, supports a core app used to initialize the hardware and interfaces, and the telemetry structure that retrieves data and reprograms the pacemaker, the paper says.

“We did not observe any cryptographically signed pacemaker firmware.  Given pacemaker firmware are not cryptographically signed, it would be possible update the pacemaker device with a custom firmware,” Rios and Butts wrote. “Obviously, compromise of a pacemaker programmer is a serious matter.  The by-design capabilities of pacemaker programmers is significant and compromise of a pacemaker programmer would result in situations where alteration of therapy is possible.”

Rios and Butts said they will next study home monitoring systems, and in their report provide questions vendors can use in evaluating their security controls.

“The findings are relatively consistent across the different vendors, highlighting the need for all vendors to perform an in-depth and holistic evaluation of implemented security controls,” Rios and Butts said. “By ensuring appropriate security controls are implemented, vendors can help protect against potential system compromises that may have implications to patient care.”

Suggested articles