We celebrated National Cybersecurity Awareness Month a few weeks ago by bringing you the FDA’s newly published Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook, with a promise to cover the Agency’s promised update on its Guidance for Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, which was first published in 2014.

Well, the Agency has now published the Draft Guidance (you can review it here), and it is really interesting for a few reasons.  First, the FDA continues to view medical device cybersecurity risks through the same lens as it views any other risk.  That is to say, treatment with any medical device presents potential risks, and premarket submissions for connected medical devices should permit analysis of cybersecurity risks compared against the device’s benefits.  Second, the Draft Guidance generally follows the philosophy and framework set forth in the FDA’s current guidance, but places considerably greater flesh on the bone.  Third, the Draft Guidance places a much greater emphasis on medical device warnings, including suggesting the inclusion of a long list of detailed information—so much information that we wonder about usefulness and feasibility.

So what does the Draft Guidance say?  The theme is that the increasing use of connected medical devices and portable media in medical devices makes effective cybersecurity more important than ever to ensure device functionality and safety.  The Draft Guidance’s mission is clear:  “Effective cybersecurity management is intended to decrease the risk of patient harm by reducing device exploitability which can result in in intentional or unintentional compromise of device safety and essential performance.”  (Draft Guidance, at p.3)  “Intentional or unintentional.”  In other words, we are talking here not only about bad actors and malicious attacks, but also accidents and other situations where no harm to a device’s function was intended at all.

One new feature is the creation of two tiers of medical devices:  A device is “Tier 1, Higher Cybersecurity Risk” if (1) the device is capable of connecting to another medical or non-medical product, or to a network, or to the Internet; AND (2) a cybersecurity incident affecting the device could directly result in patient harm to multiple patients.  All other devices are “Tier 2, Standard Cybersecurity Risk.”  (Id. at 10)  The catch-all nature of Tier 2 seems odd at first blush because it would appear to include devices for which there is no conceivable cybersecurity risk, such as orthopedic implants.  Also note that these tiers cut across the FDA’s existing statutory device classifications, such that a Tier 1 device could be Class II or Class III device.  They are separate criteria.  (Id.)

The consequence of falling into Tier 1 is that the Draft Guidance calls for considerably more exacting information in premarket submissions.  More specifically, premarket submissions for Tier 1 devices should “include documentation demonstrating how the device design and risk assessment” incorporate certain design controls that accomplish the following:

  • Identify and Protect Device Assets and Functionality – The focus here is on the design of “trustworthy” devices and the presentation of documentation demonstrating “trustworthiness.” A trustworthy device should prevent unauthorized use through sufficient authentication and encryption; should ensure the trustworthiness of content by maintaining “code, data, and execution integrity” through such measures as software/firmware updates and enabling secure data transfer; and should maintain confidentiality.  ( at 11-16)
  • Detect, Respond, Recover – As the Draft Guidance puts it, “appropriate design should anticipate the need to detect and respond to dynamic cybersecurity risks.” This includes designing the device to detect cybersecurity events promptly.  It also includes designing the device to respond to and contain the impact of cybersecurity incidents and to recover its capabilities.  This would be though such measure as routine security updates and patches, systems to detect and log security compromises, features that protect critical functionality, and measures for retention and recovery of system configurations.  It also includes something called a “CBOM”—a Cybersecurity Bill of Materials, essentially a list of hardware and software components that are or could become susceptible to vulnerabilities.  ( at 16-18)

Perhaps the most interesting part of the Draft Guidance is the recommendation for device labeling.  As product liability litigators, medical device labeling is near and dear to our hearts because a manufacturer’s potential liability often depends on the adequacy of the risk information and instructions for use.

The FDA seems to agree that device labeling is important.  After citing the governing statutes and regulations, the Agency counsels that “when drafting labeling for inclusion in a premarket submissions, a manufacturer should consider all applicable labeling requirements and how informing users through labeling may be an effective way to manage cybersecurity risks.”  (Id. at 18-19)  The Draft Guidance then lists 14 separate factors that it recommends for inclusion in the labeling.  We paraphrase them below not because we expect you to study them, but more so you can get a sense of how exacting these recommendations could be.  Here goes:

  • Device instructions and product specifications related to recommended cybersecurity controls appropriate for the intended use environment;
  • A description of the device features that protect critical functionality;
  • A description of backup and restore features;
  • Specific guidance to users regarding supporting infrastructure requirements;
  • A description of how the device is or can be hardened using secure configuration;
  • A list of network ports and other interfaces that are expected to receive and/or send data, and a description of port functionality and whether the ports are incoming or outgoing;
  • A description of systematic procedures for authorized users to download version-identifiable software and firmware;
  • A description of how the design enables the device to announce when anomalous conditions are detected (e., security events);
  • A description of how forensic evidence is captured, including but not limited to any log files;
  • A description of the methods for retention and recovery of device configuration;
  • Sufficiently detailed system diagrams for end users;
  • “A CBOM including but not limited to a list of commercial, open source, and off-the-shelf software and hardware components to enable device users . . . to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the device (and the connected system), and to deploy countermeasures to maintain the device’s essential performance”;
  • Where appropriate, technical instructions to permit secure network deployment and servicing, and instructions on how to respond upon detection of a cybersecurity vulnerability or incident; and
  • Information, if known, concerning device cybersecurity end of support, e., the time when the manufacturer may no longer be able to reasonably provide software patches and updates.

We support providing adequate information to device users, and we doubly support taking medical device cybersecurity seriously.  These recommendations, however, raise several questions.  For one thing, who is the intended audience?  The learned intermediary doctrine in most every state holds that medical device warnings are for the prescribing physicians—and no one else.  Is this information to be written for physicians, or IT professionals, or even patients?  We don’t know.

We also wonder about whether it is feasible to provide all this information, or even useful.  Maybe it would be both, or maybe neither.  But we think it is fair to ask whether providing “sufficiently detailed system diagrams” and lists of “commercial, open source, and off-the-shelf software and hardware components” is the most helpful information for protecting patient health and safety.  What is a “CBOM”?  We also wonder how the adequacy of this information would be judged.  Unlike medical risk information, this information is beyond what most physicians (the learned intermediaries) would readily appreciate.  In the so-far-extremely-unlikely event that a cybersecurity incident results in harm to a patient, will we have a new category of experts to depose?

To round it out, the Draft Guidance recommends including design documentation and risk management documentation that demonstrates device trustworthiness and the design’s connection to “threat models, clinical hazards, mitigations, and testing.”  (Id. at 21-22)

The above questions and more can be presented to the regulators as they consider the Draft Guidance and put it in final form.  Comments and suggestions are currently due sometime next March, although these deadlines tend to slip.  We will eagerly see what people have to say.  Stay tuned.

Did you know that October is National Cybersecurity Awareness Month?  Neither did we, until we started poking around the FDA’s recent press release announcing that it intends to update its guidance on medical device cybersecurity within the next few weeks.  We also learned that National Cybersecurity Awareness Month has been observed each October since its inception in 2004.  Observed by whom?  We’re not exactly sure.  We picture our IT consultants walking office to office handing out hats and stickers with catchy slogans like “A password is like underwear. Change it!”  Or some lame pun involving the work “phishing.”  If it were up to us, we would default to the simple and classic “Ctrl-alt-delete before you leave your seat.”

All kidding aside, cybersecurity threats have moved in recent years from theoretical to very real, and while there remains no reported instance of anyone hacking into a medical device being used to treat a patient, the potential vulnerability is one to which we need to pay attention.

That includes the FDA.  The FDA has published guidance on cybersecurity with regard to both premarket submissions and post-market submissions.  (You can see our take on the postmarket guidance here)  Based on the FDA’s press release, updates are coming to the premarket guidance, specifically to “highlight the importance of providing customers and users with a ‘cybersecurity bill of materials,’ or in other words, a list of commercial and off-the-shelf software and hardware components of a device that could be vulnerable to attack.”  This jibes with the FDA’s general approach to cybersecurity, which is to undertake a risk-based analysis that identifies vulnerabilities, assesses the potential frequency and severity of the risk, identifies mitigations, and proceeds accordingly.  Such a risk-based analysis should be familiar to anyone who operates in the medical device space, where risks and benefits are weighed on a daily basis.

The other news of the press release is the publication of a Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook, which “describes the types of readiness activities that’ll enable HDOs [healthcare delivery organizations] to be better prepared for a cybersecurity incident involving their medical devices.”  This Playbook was prepared by the MITRE Corporation, a government-sponsored research and development organization.  You can get a copy of the Playbook here, and you can that it is aimed at healthcare providers and critical healthcare infrastructure in which medical devices operate.

The purpose of the Playbook is to help HDOs get ready for cybersecurity threats affecting medical devices that could impact continuity of care and patient safety.  More specifically, the playbooks objectives are to:

  • Provide baseline medical device cybersecurity information that can be incorporated into an HDO’s emergency preparedness and response framework;
  • Outline roles and responsibilities for responders to clarify lines of communication “across HDOs, medical device manufacturers (MDMs), state and local governments, and the federal government”;
  • Describe a standardized approach to response efforts;
  • Serve as a basis for enhanced coordination activities among medical device cybersecurity stakeholders;
  • Inform decision making and the need to escalate response;
  • Identify resources HDOs can leverage as a part of preparedness and response activities; and
  • “Serve as a customizable regional preparedness and response tool for medical device cyber resiliency that could be broadly implemented.”

We put that last one in quotes because we’re not exactly sure what “cyber resiliency” means, but we assume it means the ability to fend off a cybersecurity event or at least mitigate its impact.  Toward that end, the Playbook suggests a four phase approach:  (1) Preparedness; (2) Detection and Analysis; (3) Containment, Eradication, and Recovery; and (4) Post Activity.

“Preparedness” means exactly what it says, with an emphasis on mindfulness of cybersecurity when procuring medical devices and keeping an inventory such that the HDO is always aware of what connected devices it has on hand.  HDOs should engage in “hazard vulnerability analysis” (again, a focus on risk) and plan for communicating and responding during an event.  That includes medical device manufacturers, whom the Playbook places squarely within the communication loop with the HDO and the FDA.

“Detection and Analysis” focuses on identifying when an incident has occurred and assessing its priority on a numerical scare that strangely assigns “Emergency” events to “Category 0.”  Analysis and documentation are important parts of the process, too.

The core of the response falls under “Containment, Eradication, and Recovery,” which appropriately focused on patient safety.  Is the device safe to use?  Is there a reliable way to test the device and confirm it is working correctly?  Are there spare or backup devices?  How quickly can the problem be fixed, and has there been collateral damage to the broader healthcare system?  These are the questions that HDO should be asking.

Finally, the “Post Activity.”  The Playbook recommends attention to lessons learned, including possibly retaining a digital forensics expert and updating the plan.

As we have said before, medical device cybersecurity is here to stay, and the FDA has been busy.  In addition to the Playbook (which is not an FDA document, but still, you get the gist), the FDA has entered into memoranda of understanding to form information sharing analysis organizations (“ISAOs”), which are “groups of experts that gather, analyze and disseminate important information about cyber threats.”  The Agency has participated in cybersecurity exercises and summits, and has engaged discussions with other government agencies, including the Department of Homeland Security.  It has proposed a Center of Excellence for Digital Health, which “would help establish more efficient regulatory paradigms, consider the building of new capacity to evaluate and recognize third-party certifiers, and support a cybersecurity unit to complement the advances in software-based devices.”  We will keep you posted.

We were not affected by the recent ransomware attack that disabled computers worldwide, including in multiple public hospitals in the UK. At least not yet.  For those who have never had the pleasure or who otherwise do not follow cybersecurity news closely, “ransomware” refers to an attack on a computer system that encrypts the user’s data—making it unavailable—and then informing the user where it can send payment in exchange for the encryption key.  It’s diabolical, and it preys upon users who have an immediate and urgent need for their data—such as healthcare providers in the process of providing life-saving and life-improving care.  The topic is of particular interest to us because healthcare data presents the classic data security conundrum:  Access to healthcare information improves patient care, yet the private nature of health information mandates tight control to prevent unauthorized access.

So it got us to thinking, what about the government? What are federal agencies doing to protect the enormous volumes of private information that they hold?  Regulators such as FDA, the FTC, and the Department of Homeland Security have stridently and justifiably insisted that our clients have policies in place regarding the protection of private information.  We would expect no less.  But is what’s good for the goose also good for the gander?

It just so happens that President Trump signed an executive order last week calling for federal agencies to get their cybersecurity houses in order. In its Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, the administration set forth three cybersecurity priorities:  (1) Cybersecurity of Federal Networks, (2) Cybersecurity of Critical Infrastructure, and (3) “Cybersecurity for the Nation.”  We put the last one in quotes because it is so broad that it could mean anything.  You can link to the executive order here.  You can also take a look at what our colleagues at Reed Smith’s Technology Law Dispatch have to say about the executive order here.

The executive order directs federal agencies to take stock of their systems and prepare reports to be submitted ultimately to the Assistant to the President for Homeland Security and Counterterrorism, a position that has existed in some form since about a month after the attacks of September 11, 2001. Lots of reports.  By our count, the executive order calls for more a dozen categories of reports prepared by federal agencies on such topics as risk mitigation, budget concerns, the transition of computer systems, and authorities and capabilities that can be deployed against cyberattack.  It’s a lot, and on an extremely aggressive time schedule—the first of the reports are due in less than 60 days.

The section on Cybersecurity of Federal Networks starts with certain findings, including this one: “The executive branch has for too long accepted antiquated and difficult-to-defend IT.”  We know from the Jason Bourne movies and any number of television shows about super-secret government agencies that the federal government has multiple windowless rooms filled with slick computer systems that know all and can do all, and look really cool in the process.  We also know from our very brief sojourns into government service that reality does not match the movies.  Technology is certainly better now than it was when we last plied government halls, but we would describe the available technology then as piecemeal, even haphazard.  It’s like when the government renovated the Pentagon years ago and found multiple antennas on the roof that no one what they did or to whom they transmitted.  The technology had outlived the people who implemented it.

The Trump administration wants to fix that. The first and maybe the most important provision is that, effectively immediately, all government agencies will use the Framework for Improving Critical Infrastructure Cybersecurity developed by the National Institute of Standards and Technology.  The NIST Framework is a published framework for computer security that is highly regarded and widely referenced in private industry.  It dates back to 2014, and its hallmark is proactive risk management.  As we reported here, the FDA has recommended that medical device manufacturers adopt parts of the Framework in designing their own cybersecurity programs.

It therefore came as a surprise that the government has not already itself widely adopted the NIST Framework. Nor will all federal agencies be able to do so “immediately.”  The NIST published its draft Implementation Guidance for Federal Agencies just the other day, and the comment period remains open through June 30, 2017.

Timing aside, adoption of the NIST Framework is a welcome development. It addition, each agency head (including presumably the FDA head) has to prepare a risk management report within 90 days that sets forth the agency’s direction and its plan to implement the Framework.  Then within another 60 days, the President wants an overall plan.  Again, these are very aggressive time frames, and we will see if they permit any real analysis or viable plans of action.

The executive order also makes it’s the policy of the executive branch to build and maintain a “modern, secure, and more resilient executive branch IT structure.” Agency heads “shall show preference” to shared IT services, and a committee of officials will prepare a report, again within 90 days, on transitioning federal agencies to shared IT services.  This provision seeks to make the government technology bureaucracy reasoned and consistent.  Reality may get in the way.  We are not sure that every agency head will even be capable of surveying and describing his or her agency’s systems within 90 days, but it is nice that they now have to try.

The section on Cybersecurity of Critical Infrastructure pledges the government’s support for the cybersecurity risk management of the owners and operators of the nation’s critical infrastructure, and it calls for additional assessment, reporting, and plans. The deadlines given for these efforts are characteristically short—ranging from 90 to 240 days.  The seemingly all-encompassing section on “Cybersecurity for the Nation” is really about one thing:  Promoting an open, interoperable, reliable, and secure Internet for all.  The Internet is at the center of everyday business and living, and it will only get more pervasive.  We heard on this morning’s news that Google is developing “ambient” networking technology, under which the Internet will be all around us.  A device in your home will, for example, monitor your schedule and tell you when you take your meds, whether your flight is delayed, or whether you need to leave extra time to pick up your spouse at the train station.  The potential for inconvenient attacks, or worse, clearly exists.

The executive branch aims to secure the Internet from cyber threats through protection against adversaries, cooperation with international allies and other partners, and development of a domestic workforce trained and equipped to promote these ends. Of course, there will be more reports, and we will be interested to see what the various agency heads will have to say.