Mitigating medical device risk

What is the proper level of security for today’s medical devices? Given their large electronic and software content and the value of medical information, these products are a natural target for hackers. The importance of device, network, and data security continues to increase as successive ransomware attacks on hospital information networks are reported.¹

On Oct. 2, 2016, the FDA issued the “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” guidelines. As an Oct. 10 article² reports, “This guidance has been developed by the FDA to assist industry by identifying issues related to cybersecurity that manufacturers should consider in the design and development of their medical devices as well as in preparing premarket submissions for these devices.”

As the article explains, the FDA guidance recommends “… that certain types of information are disclosed in a submission, including justification of the security functions chosen for … medical devices, a list of cybersecurity risks considered in the medical device’s design, a matrix that traces those risks considered to the appropriate controls, and a systematic plan for providing patches and updates to operating systems or medical device software.
“The agency also recommends that manufacturers keep in mind the following when developing apps:

assess device risks and vulnerabilities,
determine criteria for risk acceptance,
evaluate how risks could affect device functionality, and
measure the risk levels and create strategies to mitigate risk.”

In addition, manufacturers are encouraged to share security-related information through an information-sharing analysis organization (ISAO), which receives from and distributes information to its members. As described in a white paper,³ “ISAOs aggregate cybersecurity threat information from the public and private sectors so that threats are better understood and anticipated.” The FDA urges companies to use this information when developing broader incident-response plans to be used in the event of a crisis. Having well-reasoned plans ahead of the need to use them ensures a better response.

Nevertheless, security can be achieved at different levels. Should an implanted pacemaker be designed with a higher level of security than an infusion pump? What about a blood glucose meter? It is arguable that an incorrect meter reading could cause a short-term problem, but a malfunctioning pacemaker or infusion pump could kill you.

Some of the factors relating to patient safety are similar to those affecting networked devices in any number of industries. As discussed in a Deloitte white paper,⁴ “Networked medical devices and other mobile health technologies are a double-edged sword: They have the potential to play a transformational role in healthcare but also may be a vehicle that exposes patients and healthcare organizations to safety and security risks. Among the unintended consequences of healthcare’s digitization and increased networked connectivity are the risks of being hacked, being infected with malware, and being vulnerable to unauthorized access.”

Although the FDA’s guidance may become enforceable regulations in the future, at present it is just strong recommendations. It lacks specificity, which can make all the difference. A current claim of insufficient security in St. Jude Medical pacemakers is a good example. As an article in Bloomberg News⁵ explains, Carson Block, a short-sale investor and founder of research firm Muddy Waters, was contacted by cybersecurity company MedSec, which claimed to have found weaknesses in St. Jude pacemakers, the St. Jude home-based monitoring equipment called Merlin@Home, and the programmer a doctor would use to set the implantable device’s operating parameters. Muddy Waters published information from MedSec’s research in an effort to drive down the St. Jude share price.

Among the factors reported by MedSec were “… lack of encryption and authentication between devices, which could allow hackers to tap into implanted devices….”⁶ To verify this and other findings, MedSec and Muddy Waters hired Bishop Fox, a separate, unrelated cybersecurity company. It is the 27-page Bishop Fox preliminary report⁷ that makes interesting reading.

As part of the detailed discussion, the report states, “A system’s security requirements should always reflect the system’s exposure to risk, and, because of this, one would expect to see a high degree of sophistication in the security measures applied to the Merlin@home device ecosystem. This appears not to be the case with the Merlin@home and associated components, as during testing Bishop Fox observed fundamental security issues such as a flawed RF protocol, exposed JTAG headers and clearly labeled UART connectors on the Merlin@home circuit board, hard-coded cryptographic keys, and lack of basic protections against reverse engineering and exploitation.” St. Jude Medical refuted the claims and is suing Muddy Waters and MedSec for intentionally disseminating false information.

Regardless of how this particular case plays out, many online sources comment on the large gap between the medical device industry’s current implementation of cybersecurity safeguards and the much higher security level already reached in other industries. Reference 3 sums up the situation: “… the FDA seems to be in a constant state of offering subtle suggestions where regulatory enforcement is needed.”

References