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.

The FDA released its final Guidance on Postmarket Management of Cybersecurity in Medical Devices during the week between Christmas and New Year. You can link to a full copy here, and we gave you our detailed take on the draft Guidance here. You can also click here to see what our data privacy and security colleagues wrote about the final Guidance on Reed Smith’s Technology Law Dispatch, as they beat us to the presses.

The final Guidance resembles the draft, with a few refinements. We see two guiding principles in the final Guidance.  First, the final Guidance continues to follow a risk-based approach.  As we observed before, the FDA could not have taken a different tack.  Medical devices always present both benefits and risks, and the goal of regulators when it comes to cybersecurity is to assess and mitigate risks without overly compromising a device’s benefits.  Second, the FDA recognizes that managing medical device cybersecurity takes a village.  Or, in the Agency’s words, “FDA recognizes that medical device cybersecurity is a shared responsibility among stakeholders including health care facilities, patients, providers, and manufacturers of medical devices.”  Guidance, at 12.

The final Guidance therefore recommends the implementation of cybersecurity risk management programs.  Such  programs would include monitoring reported adverse events under current regulations.  The FDA also recommends incorporating elements consistent with the National Institute for Standards and Technology’s Framework for Improving Critical Infrastructure Cybersecurity.  Guidance, at 14.  We commented in our prior post that the FDA was combining familiar medical device elements with others borrowed from the cybersecurity world.  The citation to NIST’s Framework is a perfect example of the wedding between those two worlds.

More specifically, a cybersecurity risk management program would include:

  • Monitoring cybersecurity information sources for identification and detection of cybersecurity vulnerabilities and risk;
  • Maintaining robust software lifecycle processes;
  • Understanding, assessing and detecting presence and impact of a vulnerability;
  • Establishing and communicating processes for vulnerability intake and handling;
  • Using threat modeling to define clearly how to maintain safety and essential performance of a device by developing mitigations that protect, respond and recover from the cybersecurity risk;
  • Adopting a coordinated vulnerability disclosure policy and practice; and
  • Deploying mitigations that address cybersecurity risk early and prior to exploitation.

Continue Reading What You Need To Know About the FDA’s Guidance on Postmarket Cybersecurity

We have been tracking the issue of medical device cybersecurity for quite some time now.  We wrote here on how medical device hacking is both the stuff of Hollywood storytelling and also a genuine concern to which the FDA and medical device manufacturers are paying attention.  In June 2013, the FDA issued a Safety Communication entitled “Cybersecurity for Medical Devices and Hospital Networks,” and the agency finalized a guidance document in October 2014 on how to address cybersecurity in medical device premarket submissions.  In that guidance the FDA set forth a risk-based model, under which device manufacturers are to identify and assess both risks and strategies to mitigate the risks in preparing their premarket applications.  To complete the backstory, the FDA took the unusual step in July 2015 of issuing a Safety Communication regarding a specific cybersecurity vulnerability in a network-connected pain pump.  We wrote about that in our prior post, too.

The new development is the FDA’s release on January 15, 2016, of a draft guidance on postmarket management of cybersecurity in medical devices.  You can link to the draft guidance (which actually bears today’s date, January 22, 2016) here.  Again, the FDA is taking a risk-based approach, i.e., guiding manufacturers to identify, assess, and mitigate risks that emerge after a product has been introduced to market.  Come to think of it, the agency could hardly take a different approach, given that all medical devices present both benefits and risks and that risks cannot be complete mitigated in any device.  The draft guidance puts it this way:  “Because cybersecurity risks to medical devices are continually evolving, it is not possible to complete mitigate risks through premarket controls alone.  Therefore, it is essential that manufacturers implement comprehensive cybersecurity risk management programs . . . .”  (Draft Guidance, at 11)

Continue Reading Medical Device Cybersecurity: FDA’s New Draft Guidance

We have been meaning for a while to write about LabMD’s epic data privacy fight against the FTC.  We’re sure you have read about the action, and particularly about the administrative order dismissing the government’s Administrative Complaint in November 2015.  The noteworthy part of the order is its holding that the government has to prove actual injury to consumers, not merely a theoretical “risk” of future harm, in data privacy enforcement actions.  We like the sound of that.  It reminds us of the old days of medical monitoring class actions, otherwise known as “money for nothing,” where uninjured plaintiffs would claim compensation for future medical surveillance, even though they had never experienced any actual complication.  We don’t see those much anymore, but a similar battle has gone on in the context of data privacy.  The vast majority of data security breaches result in no tangible harm to anyone, but plaintiffs still sue, and they still want money for the theoretical risk that someone, someday might use their private information to cause them harm—fraud, identity theft, and the
like.

But back to LabMD.  The FTC has gone after many companies for allegedly lax data security practices, and in almost every case, the target comes to a negotiated resolution, usually involving a fine and a consent decree requiring certain measures to better protect private information.  What makes LabMD different is that, once it found itself in the FTC’s crosshairs, it fought back.  That decision was bad for business—the company announced in 2014 that the government’s action essentially closed it down—but it resulted in a complete win at the administrative level and a landmark order pinning back the government’s ears.  The action has been going on for years, but here is what you really need to know:

Why do we care?  The issue is data privacy and security, and the drug and device industry holds reams of private information—employee data, customer data, consumer data, patient data, etc.  The FTC remains the biggest bully in the schoolyard when it comes to data privacy, and the LabMD order is a landmark in delimiting the FTC’s usually unchallenged regulatory prerogative.

Continue Reading All You Need to Know About LabMD’s Big Win in/over the FTC

Dick Cheney famously disclosed a few years ago that he had the wireless function of his pacemaker disconnected while he was Vice President because he was concerned that hackers might fiddle with the device remotely and do him harm.  We at the Drug and Device Law Blog can’t help but wonder whether the Veep placed himself ahead of or behind the risk-benefit curve.  Sure, he mitigated the risk that some malicious and very clever hacker would successfully target him.  But he also disabled an important feature of a device that was intended to protect and extend his life.

Was he better or worse off?  We don’t know.  We do know that when we first learned about wirelessly connected implanted medical devices, we were amazed by technology that appeared straight out of Star Trek.  You know, like when Bones would treat some befallen Enterprise crew member in a color-coded T-shirt by waving a handheld device over his or her clothed skin.  That’s how we pictured connected devices like cardiac defibrillators—capable of transmitting telemetry, issuing warnings, accepting software upgrades, taking commands, and otherwise treating human frailty—remotely and without the need for any invasive procedure.

The potential benefits to health are tremendous, and wireless connectivity is now common in numerous types of medical devices, implanted and not.  But what about the potential risks?  We are told that Cheney’s paranoia became the basis for an episode of Homeland, a show we have never seen, but that apparently involved a fictional Vice President harmed by pacemaker hackers with malice aforethought.  (Although we have never watched Homeland, we have seen every episode of Veep, which stars Julia Louis Dreyfus as a different fictional Vice President (and later President) and is wickedly funny, but so profane that our mother-in-law elected to leave the room rather than watch it.  But we digress).

Continue Reading Medical Device Cybersecurity: Maybe Dick Cheney Was Not So Paranoid After All