GAO Reports – Week of 12-16-23 – Medical Device Cybersecurity Oversight

This week the Government Accountability Office (GAO) published a report on “Medical Device Cybersecurity”. The report was required by last year’s consolidated spending bill (§3305 of PL 117-328, 136 STAT. 5832). That section added §524B, Ensuring Cybersecurity of Devices, to the Federal Food, Drug, and Cosmetic Act. Subsection (g) of that new section required the GAO to examine:

• Challenges for device manufacturers, health care providers, health systems, and patients in accessing Federal support to address vulnerabilities across Federal agencies,

• How Federal agencies can strengthen coordination to better support cybersecurity for devices, and

• Statutory limitations and opportunities for improving cybersecurity for devices.

The report identifies the agencies of the Federal government that share some level of responsibility for oversight of medical device cybersecurity with the Food and Drug Administration. In addition to various HHS agencies, these include CISA and the FBI.

While a number of agencies are named in this report, the GAO is only making recommendations to two agencies in this report. While there are two recommendations, they are actually two sides of the same one, for the FDA and CISA “to update the agencies’ agreement to reflect organizational and procedural changes that have occurred” since the current agreement was signed in 2018. 

FDA Issues Guidance on Management of Cybersecurity in Medical Devices

Today the Food and Drug Administration (FDA) published a notice in the Federal Register (79 FR 59493-59494) announcing that it had published a new guidance document about cybersecurity for medical devices; “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”. A draft version of this non-binding guidance document was released for public comment in June of 2013.

The document is designed to address cybersecurity issues to be addressed in premarket data submissions for “devices that contain software (including firmware) or programmable logic as well as software that is a medical device organized. It is divided into sections dealing with:

• Definitions;

• General Principles;

• Cybersecurity Functions;

• Cybersecurity Documentation; and

• Established Standards

General Purposes

After stating the obvious that “medical device security is a shared responsibility between stakeholders, including health care facilities, patients, providers, and manufacturers of medical devices” (pg 3) the FDA goes on to explain that:

“Manufacturers should address cybersecurity during the design and development of the medical device, as this can result in more robust and efficient mitigation of patient risks. Manufacturers should establish design inputs for their device related to cybersecurity, and establish a cybersecurity vulnerability and management approach as part of the software validation and risk analysis that is required by 21 CFR 820.30(g).” [Link added] (pg 4)

Cybersecurity Functions

In the only documented reference in this guidance to the recent NIST Cybersecurity Framework (CSF), the FDA identifies the five cybersecurity functions outlined in the CSF; Identify,

Protect, Detect, Respond, and Recover. Unfortunately, the FDA totally ignores the opportunity to reference the CSF as a way to identify cybersecurity activities, desired outcomes, and

applicable references that a medical device manufacturer could use to establish their cybersecurity management program.

Instead the Guidance document relies on two pages of bullet points of the ‘motherhood and apple pie’ variety. For example, under the ‘Limit Access’ category they include such earth shattering recommendations as:

• Limit access to devices through the authentication of users (e.g. user ID and password, smartcard, biometric); and

• Where appropriate, provide physical locks on devices and their communication ports to minimize tampering;

Cybersecurity Documentation

As you might expect for a guidance document that is focused on cybersecurity information that will be submitted to FDA as part of the device approval process, the most specific guidance is found under this heading. The FDA outlines five specific types of documentation that may be specifically required for the approval process. They are (pg 6):

• Hazard analysis, mitigations, and design considerations pertaining to intentional and unintentional cybersecurity risks;

• A traceability matrix that links your actual cybersecurity controls to the cybersecurity risks;

• A summary describing the plan for providing validated software updates and patches as needed throughout the lifecycle of the medical device;

• A summary describing controls that are in place to assure that the medical device software will maintain its integrity (e.g. remain free of malware) from the point of origin to the point at which that device leaves the control of the manufacturer; and

• Device instructions for use and product specifications related to recommended cybersecurity controls appropriate for the intended use environment.

Interestingly, in this section the FDA specifically abdicates responsibility for cybersecurity system updates, noting that: “The FDA typically will not need to review or approve medical device software changes made solely to strengthen cybersecurity.”

Public Comments

Even though this is the ‘final’ version of the Guidance document, the FDA is soliciting comments from the regulated and affected communities. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # FDA-2013-D-0616).

You can find copies of public responses to the draft guidance document published last year in the same docket. Unfortunately, there is nothing in today’s notice or final guidance document that provides any insight into how the FDA addressed the concerns outlined in the 26 public and industry responses to that draft document.

FDA Cybersecurity Workshop Scheduled

Today the Food and Drug Administration published a notice in the Federal Register (79 FR 56814-56816) announcing a public workshop on “Collaborative Approaches for Medical Device and Healthcare Cybersecurity”. The notice also serves as a request for comments on the same topic. The two day workshop will be held on October 21^st in Arlington, VA.

Recognizing the increasing interconnectedness of medical devices, diagnostic tools, individual medical records and health care administrative functions the FDA is holding this workshop to look at how the health care community and the Healthcare and Public Health (HPH) Sector can collaboratively increase cybersecurity and implement the Cybersecurity Framework (CSF) developed by NIST.

The two day workshop will address the following themes:

● Envisioning a collaborative environment for information sharing;

● Overcoming barriers to create a community of `shared ownership and shared responsibility' within the HPH Sector;

● Gaining situational awareness of the current cyber threats to the HPH Sector, especially to medical devices;

● Identifying cybersecurity gaps and challenges;

● Adapting and implementing the Framework to support management of cybersecurity risks involving medical devices;

● Developing tools and standards to build a comprehensive cybersecurity;

● Leveraging the technical subject matter expertise of the cybersecurity researcher community; and

● Building potential solutions.

Additionally, the FDA is looking for input on five specific cybersecurity related questions:

● Are stakeholders aware of the “Framework for Improving Critical Infrastructure Cybersecurity”?

● How can we establish partnerships within the HPH Sector to quickly identify, analyze, communicate, and mitigate cyber threats and medical device security vulnerabilities?

● How might the stakeholder community create incentives to encourage sharing information about medical device cyber threats and vulnerabilities?

● What lessons learned, case studies, and best practices (from within and external to the sector) might incentivize innovation in medical device cybersecurity for the HPH Sector? 

● How do HPH stakeholders strike the balance between the need to share health information and the need to restrict access to it?

In addition to responses from workshop participants about these themes and questions, the FDA is soliciting written comments on these topics. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # FDA-2014-N-1286). Comments need to be submitted by October 7^th. That is a very short deadline, but the FDA is going to attempt to use these comments to guide their presentations at the workshop.

Because of limited seating availability the FDA is requiring advanced registration to attend the workshop. You are supposed to be able to register for this on-line via the FDA Workshop and Conferences (Medical Devices) web page, but as of 05:00 am CDT this workshop was not listed on that page. This workshop will also be web cast. Registration for the web cast is also supposed to be via the same web site. The registration deadline for both is October 14^th.

ICS-CERT Publishes Medical Product Advisory

Earlier today the DHS ICS-CERT published their first advisory for a specific vulnerability for a medical application, the Philips Xper application. The heap-based buffer overflow vulnerability was reported by Billy Rios in a coordinated disclosure.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability and execute arbitrary code on the affected device. According to the Philips web site, the Xper application is used in a variety of medical monitoring, diagnostic and medical work-flow devices.

Phillips has produced a an update for XperConnect that Billy Rios has confirmed mitigates the reported vulnerability.

If past history is any guide (and I certainly expect it to be) then this will be just the first of many medical device or application advisories that will be published by ICS-CERT.

Medical Malware – Detection Techniques

There is an interesting article over at TechnologyReview.com about cybersecurity and medical devices. A lot of it is a rehash of things we’ve been hearing out of the black hat community for a couple of years now and is reflected in the recent FDA draft guidance on cybersecurity. There are two interesting new items that I hadn’t seen discussed before; a new method of detecting medical malware and a discussion about the use of anti-virus software on medical devices.

Power Detection of Malware

The article contains a link to a journal article (in the Proceedings of USENIX Workshop on Health Information Technologies, 2013) about a power monitoring system (WattsUpDoc) that can be used to detect the unusual power consumption associated with a malware attack on a medical device. The authors noted that if one has an accurate history of a devices normal power consumption patterns that changes in those patterns could be used to detect when a device has been compromised by a cyber-attack. Their paper also claims to have validated the technique in an industrial scale SCADA system.

I’ll leave the technical evaluation of the technique to people with the appropriate expertise, but it would seem to me that this technique might be particularly valuable in safety systems because of the vary constrained outputs of those systems.

Medical Anti-Virus Problems

Sorry, I couldn’t resist that heading. 

The article explains that many medical devices cannot use commercial anti-virus software because they are running on proprietary operating systems. The ones that are using variations of a Microsoft OS might be able to use off-the-shelf AV software, but device manufacturers do not allow (or support) the use of third party software (or I suspect even the update of the MS-OS) because of the very real potential for unexpected conflicts with the device software.

This is not an unknown problem for many control systems, but a software lockup on ones’ pacemaker could be even more troublesome than the shutting down of a production line. But with the rise of hackers actively looking at medical device control systems, it seems to me that there is a significant need to come up with a workable solution to the AV problem.