Virta Labs Blog


FDA's Draft Guidance: The Long and the Short Of It

Posted by Ben Ransford on Jan 20, 2016 11:28:41 AM
Find me on:


People have been asking us all week for our opinions on the FDA's new postmarket cybersecurity draft guidance.  All three of Virta Labs' founders have been active in this area, with extensive research in applied security and longstanding support for collaborative efforts:

... among other things.  And we're thrilled to see that the FDA has taken the significant step of issuing this document.

We read the draft guidance so that you could tl;dr and get back to your own job.  Here are the highlights, as we see them.

Overall, these recommendations are important for two main reasons: the FDA owns the floor, and you'd be hard pressed to find a more careful organization.  As with everything, the FDA has taken a methodical approach to understanding the risks of security problems and what can be done to mitigate exposure.  

The industry — and practitioners actually using medical devices in the field — will always move faster than the regulators, but when the FDA speaks, everyone stops to listen.  And the clearer the FDA's message, the harder it will be for stakeholders to rely on misinterpretations.

As others have pointed out, the recommendations in the draft guidance are voluntary and represent the FDA's current thinking about these issues; these are not new laws or regulations.  But to make a bad pun (we can't not): this draft shows that the winds are blowing in the right direction.

Now to our summary of the contents!

Who's responsible for the security of medical devices?

The short answer is that security is a shared responsibility.  Quoting the draft guidance, the responsibilities are spread among:

the medical device manufacturer, the user, the Information Technology (IT) system integrator, Health IT developers, and an array of IT vendors that provide products that are not regulated by the FDA.

This language represents a big win for users (owners and operators), who for a long time were the only ones expected to address medical-device security, albet with limited tools such as firewalls.  Perimeter security is circling the drain as computing environments become more fluid — employee phones coming and going, applications moving to the web, guest networks pegging border routers — which means that wiring closets full of elaborately configured routers & firewalls are becoming less useful.  FDA's guidance keeps the other stakeholders, the ones who can actually design and support good products, on the hook.

(One valid response to the draft guidance [articulated by our own Kevin Fu] is that it needs to take a holistic view of threats rather than focusing on specific modalities such as networked attacks that a firewall could prevent.)

To make it as easy as possible for stakeholders to get security right, this draft guidance advocates for information sharing through organizations such as NH-ISAC.  Now that there's something around which people can nucleate, we should see more movement on information-sharing practices.

Is it now clear what manufacturers should do?

Much clearer now, yes.  Actually, the non–medical-specific elements of the recommendations have been clear for a while.  Design and development processes should include security thinking at every stage.  There should be a clear upgrade path for devices after they're released.  Third-party software such as operating systems and libraries must be kept up to date along with application software.  Systems should follow the principle of least privilege, perform input sanitization, and implement many more "best practices" to follow other industries that are building security in.

What's different about medical devices is that, until recently, device makers were able to argue that their devices were special because of the need for extra assurance (true) and were not possible to maintain like other computers because updates would have to be reapproved by the FDA (false, though it was unclear for a while).  Unfortunately, some manufacturers used the lack of clear recommendations from the FDA as an excuse to avoid updating systems in the field or to push back when clinical IT folks asked for information about product security.

The draft guidance hints that manufacturers ought to get better at:

  • Understanding threats and whether they're relevant to the devices they build.  This means investing in ongoing monitoring of information sources such as CERT and perhaps security conferences.
  • Being able to handle & investigate reports of security problems.  Savvy customers and researchers who report problems should no longer be ignored or stonewalled.
  • Ensuring the quality of components in the supply chain.  Device makers are already very good at designing whole systems, but occasionally they come to rely on third parties for software libraries or new hardware-enabled functions.  Manufacturers should prepare to keep communication open with their suppliers and work to solve problems rather than passing the buck when security problems appear.  (At least one company has suggested that it plans to include a software "bill of materials" in MDS2 responses.)
  • Patching systems promptly for security vulnerabilities, most of which would likely fall in the cybersecurity routing update and patch category.

What should practitioners (such as healthcare IT administrators) do?

The major theme is: report problems and expect manufacturers to be more responsive than they have been.  Keep conducting routine scans.  If a vulnerability scan knocks a device offline, for example, report it to the manufacturer and expect to be taken seriously.

Manufacturers who follow the recommendations in this draft guidance will be better about documenting their systems' security-relevant properties, e.g., open ports, and so should be better able to equip customers with correct & complete information.  Don't be shy about asking security questions.

Do be patient as manufacturers catch up to the FDA's guidance.  Change doesn't happen overnight.  Manufacturers may offer compensating controls (temporary workarounds) to address security problems — but these should not be permanent.

To what extent does this guidance affect legacy devices?

Here the present draft guidance is a bit fuzzy.  What of devices put into operation before this document and its precursors appeared?  Manufacturers are on the hook to provide compensating controls (e.g., temporary workarounds such as disabling a noncritical function) when risks warrant them, but the recommendations in this document seem largely to concern devices that are new to the market.

What's the upshot?  What happens next?

There's clearly a lot of work for stakeholders to do.  Creating a culture of information sharing will run counter to the practice of extreme secrecy that most medical-device companies follow now.  But it's also clear that the industry's performance by most security metrics has been abysmal.  The FDA's draft guidance points the way toward practices that will likely yield better performance in the future.  (As Ann likes to mimic me saying, it's "combing the vector field in the right direction.")

If you want to keep an eye on only one healthcare security metric this year, look at breach-detection time.  Healthcare trails other industries that take on average more than 200 days to identify a breach, and as the value of personal health data trends upward, longstanding breaches will hurt more and more.  With a combination of necessary process improvements (the focus of the draft guidance), information sharing, and accompanying tools & technology, we hope to see faster response time across the industry.

Medical-device companies have amazing engineering capabilities.  Just look at how much engineering — and regulatory scrutiny — goes into failsafe mechanisms for patient-connected devices and you'll understand what we mean.  Or crack open a medical device (actually, don't) and compare the quality of the electronics to a garden-variety consumer device.  We think these companies have the potential to lead other industries by taking security seriously at every level.  People who spend money on medical devices are now more likely to be heard as well, and they should consider themselves stakeholders.

Many of the people with horses in this race are at this week's "Moving Forward: Collaborative Approaches to Medical Device Cybersecurity" workshop at FDA's White Oak campus in Silver Spring and/or tweeting with the #FDACyber hashtag.

Speaking of horses in the race, what's ours?

We've been passionate about these challenges & opportunities for years, and we're excited that so much is happening now.  Our PowerGuard product, which nonintrusively monitors devices for unusual behavior, helps address the detection aspect of healthcare security.  Detection is a major pillar of the NIST cybersecurity framework on which the FDA's draft guidance relies.  Get in touch to hear more about our product and service offerings for the healthcare sector.

Topics: FDA, Healthcare Cybersecurity, Medical Device Security, Clinical Engineering, Healthcare IT, Clinical Information Security