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)}:
• 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.
Posts
