S 1656 Introduced – Medical Device Cybersecurity

Last month Sen. Blumenthal (D,CT) introduced S 1656, the Medical Device Cybersecurity Act of 2017. The bill would provide enforceable cybersecurity standards for medical devices.

The bill would amend the Food, Drug, and Cosmetics Act by adding a new §502A, Cybersecurity for Devices. The new section would address the following:

• Definitions;

• Transparency of risk prior to marketing;

• Protecting remote access to managed solutions;

• Cybersecurity fixes or updates; and

• End-of-life device;

Additionally, the bill would give the DHS ICS-CERT specific responsibilities with respect to the cybersecurity of medical devices.

Definitions

Section 520A(a) provides definitions for two new terms; ‘cyber device’ and ‘cybersecurity fix or update’. Both definitions rely on the existing definition of device in 21 USC 321(h) for ‘device’ which is broadly “an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article” with established and recognized medical applications.

With that starting point a ‘cyber device’ is any device that has network or Internet connectivity, connects to an external storage device or external media, or has any other cyber capability. The term ‘cyber capability’ or even just ‘cyber’ is not defined. Similarly, a ‘cybersecurity fix or update’ is “any modification to a cyber device that addresses a software, firmware, or hardware error or known vulnerability, or a security update, and does not change the therapeutic or diagnostic function of the device” {§520A(a)(2)}.

Transparency of Risk Prior to Marketing

Section 520A(b) would require the FDA to develop a ‘report card’ that describes the cybersecurity functions of cyber devices. That report card would include {§520A(b)(2)}:

• Information pertaining to all essential elements described in the most recent version of the Manufacturer Disclosure Statement for Medical Device Security;

• A traceability matrix, accepted by the Secretary, that establishes design components and traces such components to design compensating controls;

• A description of any manufacturer compensating controls that effectively address known common vulnerabilities and exposures;

• A description of any cybersecurity evaluation conducted on the device, including any testing, validation, or verification of the device;

• A cybersecurity risk assessment conducted by the manufacturer, or a third party, explaining the risk of the device to patient safety and clinical hazards; and

• An indication of whether the device is capable of being remotely accessed along with an indication of any security measures and access protocols the device has in place to secure any such access if the capable.

The Department of Health and Human Services would be required to make a copy of the report card available to “any health care industry entity, consisting of any provider, device manufacturer, the Federal Government, health care information security researchers, and health care academia” {§520A(b)(3)(B)(ii)(I)}.

Protecting Remote Access to Managed Solutions

Section 520A(c) establishes standards for remote access to cyber devices. First it requires that manufacturers “obtain consent for such access from the provider owning or operating the device and from any patient on which the device is used” {§520A(c)(1)(A)}. That consent may be documented in the sales agreement between the manufacturer and the provider. Second, the manufacturer is required to provide notification to the provider when such access is made. This notification can be made via provider accessible access logs.

Finally, the paragraph would establish cybersecurity standards for devices capable of remote access. Those standards would include requirements to {§520A(c)(1)(C)}:

• Implement multi-factor authentication for accessing any cyber capability of the device;

• Secure data in motion and data at rest with data encryption, and other best practices, approved by the National Institute of Standards and Technology;

• Install automated tools to track access, or identify attempts at unauthorized access, to any cyber capability of the device;

• Adopt whitelisting approaches and changeable passwords for accessing any cyber capability of the device; and

• Comply with the remote access provisions recommended by the National Institute of Standards and Technology, in the document entitled ‘Security for Telecommuting and Broadband Communications (NIST Special Publication 800–46)’, published in August 2002 [emphasis added].

Cybersecurity fixes or updates

Section 520A(d) provides guidance on the usage of ‘cybersecurity fixes or updates’. First it provides that generally “any cybersecurity fix or update shall not require a new notification under section 510(k) or application for premarket approval under section 515(c)” {§520A(d)(1)}. Finally, it provides that such fixes or updates will be provided free of charge until a date specifically agreed upon between the manufacturer and the provider, or 10 years after “the manufacturer discontinues marketing the device” {§520A(d)(2)(B)} if no such agreement is documented.

End-of-Life Devices

Section 520A(e) sets forth the requirements that manufacturers must conform to when they stop marketing a cyber device. This includes requirements to:

• Provide any provider owning or operating the device with the report card, as most recently updated;

• To the extent practicable, inform any provider owning or operating the device that the manufacturer will no longer be manufacturing such device;

• Provide notice to any provider owning or operating the device of the date on which the last cybersecurity fix or update will be provided by the manufacturer; and

• Notify the Secretary of such declaration;

Additionally, the manufacturer is required to provide the following information to the provider owning or operating the device {§520A(e)(5)}:

• Compensating controls on how to securely configure the cyber device if the device stays in operation past the date on which the manufacturer stops providing cybersecurity fixes or updates;

• Documentation on secure preparation for recycling and disposal of the device;

• Specific guidance regarding supporting infrastructure architecture, including network segmentation and device isolation requirements; and

• Instructions on how to delete any personally identifiable information, protected health information, or other site-specific sensitive data such as configuration files.

ICS-CERT and Cyber Devices

Separate from the §520A language, the bill also address the role of the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) in medical device cybersecurity. Section 2c of the bill would require DHS to expand the role of ICS-CERT to include {§520A(c)(2)}:

• Investigating cybersecurity vulnerabilities of cyber devices that may cause harm to human life or significant misuse of personal health information; and

• Coordinating device-specific responses to cybersecurity incidents and vulnerabilities with respect to cyber devices

The bill would also require DHS to establish rules concerning coordinated disclosure of cybersecurity vulnerabilities in cyber devices. Those regulations would {2(c)(4)}:

• Outline the roles and responsibilities of ICS–CERT and manufacturers and providers of cyber devices;

• Provide timelines for all required actions; and

• Provide for the enforcement of cooperation between ICS–CERT and manufacturers and providers of cyber devices

Moving Forward

Blumenthal is not a member of the Senate Health, Education, Labor, and Pensions Committee to which this bill was assigned for consideration. This means that the Committee is not likely to act on this bill; effectively killing it as a stand-alone measure. We could potentially see a version of this bill offered as an amendment to a Senate FDA authorization bill when that reaches the floor.

Commentary

While there is much to like in this bill, there are too many problems that would make the resulting regulations unworkable. I’ll mention just a few.

First and foremost, the bill completely dodges the issue of ownership of implantable cyber devices. Throughout the bill there is reference to ‘the provider owning or operating the device’ as it this person (or organization) is the only entity that has an interest in the cybersecurity of the device. The only mention of the patient is where the provider informs the patient of the agreement between the provider and the manufacturer providing the manufacturer with permission to remotely access the device. Ignoring the rights of wearers of implantable devices has got to stop.

Next, while the bill attempts to specify a fairly comprehensive set of guidelines for remote access, it completely ignores the issue of who has responsibility for periodically checking the device logs to determine if/when unauthorized attempts were made to access the device or what actions should be taken when such access attempts are noted.

That same section of the bill makes a very rookie mistake when it specifies the date of a NIST publication that will be used as a standard for remote access requirements. This particular case is particularly egregious since there have been two updates to that specific standard since the date specified.

In §520A(e)(5) we see three specific actions that manufacturers are supposed to take at device end-of-life that really should have been required when devices are first authorized to be sold. These are the requirements to provide information on:

• Documentation on secure preparation for recycling and disposal of the device;

• Specific guidance regarding supporting infrastructure architecture, including network segmentation and device isolation requirements; and

• Instructions on how to delete any personally identifiable information, protected health information, or other site-specific sensitive data such as configuration files.

Not requiring that this information be provided until the end-of-life point of the cyber device is one of the most ludicrous problems with this bill.

Finally, the provisions regarding the role of ICS-CERT in the cyber device vulnerability disclosure process completely ignores the role of the security researchers that find most of the vulnerabilities in these devices. The way the paragraph reads it almost seems as if Blumenthal expects ICS-CERT to undertake the research necessary to find the vulnerabilities. If that is the case, the bill would certainly need to provide authorization for the funding and manpower needed to realistically undertake that mission.