Stephanie Domas, MedSec
MEDdesign

Snowflake Syndrome Creates Cybersecurity Roadblocks

By Stephanie Domas
No Comments
Stephanie Domas, MedSec

There are too many unique needs on the part of both manufacturers and providers. More collaboration is needed.

Medical device cybersecurity has come a long way over the past few years. I have the unique privilege of working with both medical device manufacturers and healthcare delivery organizations on cybersecurity of medical devices, so I get to see the situation from a lot of unique angles. One of the questions I get asked often is, “what are the current struggles or roadblocks we face in addressing cybersecurity for medical devices?”. Right now, the biggest roadblock I see is that both medical device manufacturers and healthcare providers are suffering from special snowflake syndrome. Everyone is overrun with too much uniqueness, on both sides.

Stephanie Domas will be speaking during the Medical Cybersecurity & Patch Management conference | May 1 – 2, 2018 | Learn moreLet’s start with the device manufacturer perspective. Have you ever heard the phrase, “if you’ve seen one hospital, you’ve seen one hospital”? It is estimated that there are 5,500 hospitals in the United States, and most of them are approaching cybersecurity of medical devices in their own unique way. What this means to manufacturers is an avalanche of unique stakeholder needs. If you ever find yourself talking to the head of product security for a manufacturer, ask them how much of their day they spend filling out hospital security questionnaires, then watch as the look of exhaustion and defeat spreads across their face. Hospitals, filled with good intentions, have developed in-depth cybersecurity questionnaires to gather information about the medical devices they are considering for purchase. The intention is great, but the issue is they all use their own unique form, forcing manufacturers to repeatedly fill out similar but different forms with sometimes upward of 100 questions. While there has been an attempt at standardizing this form with the MDS2, the form is often found inadequate by hospitals, causing the slurry of unique questionnaires.1 There is a desperate need for hospitals to come together to unify around a standard set of questions, so manufacturers can not only have pre-produced in-depth responses to them, but it establishes a consistent baseline of what’s important to hospitals, which helps manufacturers guide security design decisions.

The unique questionnaires may take up insubstantial amounts of product security officers’ time, but what about the struggles in actually designing more secure medical devices? Well, the same avalanche of unique stakeholder needs makes this difficult, too. I was recently working with a manufacturer on a system design, and based on discussions with a dozen of their largest customers, they had gathered that they had to support five different types of wireless authentication, to satisfy all of them. Several of those authentication mechanisms we’re deprecated years ago due to known security flaws. To satisfy customer needs, this manufacturer chose to build in support for all five unique authentication methods, creating a tremendous amount of extra software coding and maintenance work for the manufacturer, while simultaneously forcing insecure technologies on hospitals with cutting edge wireless security. But what’s a manufacturer to do? Networking equipment is expensive, and hospitals can’t go around buying the latest and greatest every time a new solution comes out. Providing patient care is, after all, the reason we’re here, so until some minimum security bar can be set for hospital systems, I agreed with the manufacturers decision to support all five. This is just one example of many that I’ve been involved with, where the unique stakeholder needs forced redundancy in capabilities and insecure technologies to be supported.

But let’s shift perspectives and look at this from the healthcare providers viewpoint. The Mayo Clinic recently released some statistics regarding their medical devices, so I will use them as my example. At the Mayo Clinic, they have 25,000 networked medical devices, with more than 6,000 unique makes and models. To quote Kevin McDonald, Mayo Clinic director of clinical information security, he and his team are “buried under an avalanche of medical device special snowflakes”. Even if every single one of those 6,000 unique models was designed to meet the highest of security standards, there are still usability, maintenance and scalability issues. With regards to usability, if every single system followed industry best security practices, healthcare workers would be required to have a unique 20-character password for every system they touched that locked them out after 10 minutes of inactivity, and needed to be changed every 30 days. This is not realistic. My job is cybersecurity, and even I get frustrated with having to remember several passwords—imagine how a healthcare worker feels, whose number one job is to care for patients, when they are routinely blocked from doing their job by password prompts. Authentication is just one example of the dreaded cybersecurity and usability tradeoff.

What about the maintenance side of having 25,000 medical devices? With so many devices, and the physical portability of them, it’s a near impossible task for a hospital to tell you at any given time what medical devices are on their network, where they are, are they running an out of date version of software, what information is the medical device sharing on the network, who it’s sharing it with, and is it doing it in a secure manner? Traditional enterprise security tools don’t work well in these situations, leaving a need in the industry for medical device specific solutions, and increased uniformity among medical device manufacturers on how to maintain their systems. Taking software updates as an example, the method by which updates are distributed for each medical device may be different. How does the hospital become aware there is an update? Does the device have the ability to download an update itself? Does the hospital need to go to the manufacturer’s website to download it? Then how do they get it on the system? A USB drive? Do they have to call the manufacturer to have a technician sent out? Looking at 10 different medical devices, you’ll likely get 10 different sets of answers.

For the past few years there have been great strides made in tackling cybersecurity across the healthcare space, I don’t want to discredit the incredible lengths we’ve come so far. But cybersecurity is never done; we need to continue to grow. There have been pockets of collaboration amongst the industry, but much of what’s been accomplished has been in isolation with manufacturers and healthcare delivery organizations tackling problems on their own. To continue to push cybersecurity we need to increase collaboration amongst hospitals, amongst manufacturers, and both sides together.

In my new role as vice president of research of MedSec, I’m excited to be joining a great team of professionals who have built a strong reputation for expertise and quality within the healthcare industry. We will continue to partner with healthcare manufacturers and providers to develop solutions and service that protect the healthcare community and patients from cyberharm.

References

  1. NEMA. (n.d.). Retrieved from Manufacturer Disclosure Statement for Medical Device Security: https://www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-Medical-Device-Security.aspx

About The Author

Stephanie Domas, MedSec

Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

If you agree to these terms, please click here.