Securing Your Medical Devices: Best Practices for the New Age of High-Scale, High-Volume Devices

The need for medical device security is obvious: The consequences of an attack on a device like a pacemaker could be catastrophic. And the stakes are especially high since private medical information is potentially quite valuable.

Of course, this reality doesn’t make the challenge of securing these all-important devices any easier.

So what does it take to secure your medical devices properly? This was the topic of discussion in a recent webinar featuring Ellen Boehm, SVP of IoT Strategy and Operations at Keyfactor, and Spencer Frye, VP of Growth Strategy and Operations at nTropy. Specifically, they covered challenges and risks with the current security landscape for medical devices as well as solutions and best practices for improving security. Watch the full webinar here or read on for the highlights from the conversation.

The number of connected medical devices available to us today to make our day-to-day lives easier is incredible. And they come with so many benefits: Imagine the parent whose child has diabetes who can now monitor their sugar levels anytime, from a distance, and jump in to help as needed. That level of information can make all the difference.

But for all the benefits these devices offer – and there are many – they come with risks too. Any time you introduce a connected device, you open risks around data privacy breaches. But the benefits are too high not to take advantage of these devices, so using them securely comes down to establishing trust that no one is intercepting data, whether to read it or change it in any way.

This type of trust is also important when it comes to protecting financial records and systems associated with medical information. Consider the case of someone who just had a major surgery at a regional facility and is now being transferred to a local hospital. Medical teams at both locations need access to patient records to provide the right care, but those records contain sensitive information that requires protection.

And the challenge is real. Not only does healthcare account for 79% of reported breaches but connected medical devices are expected to grow an additional 42% by 2025, making for even more opportunities for attacks.

To help, the FDA released both pre-market and post-market cybersecurity guidance several years ago that provides insight into unique identities, firmware signing, and other ways to embed security in medical devices. Notably, there continue to be constant discussions around this guidance to continue improving security standards.

Many wearable medical devices, such as cardiovascular monitors, only have a short validity period in which someone wears them, say two weeks. And organizations produce hundreds of millions of these devices, which presents a unique challenge around how to authenticate and encrypt the information they hold.

On the flip side, many other devices might live in the field for 15 to 20 years, which requires a different set of questions around how to continue to update the technology within it and ensure it adheres to security standards long term.

In a lot of these cases, processes are very manual, with individuals going in to provide security materials. However, this manual intervention is prone to mistakes. It also means that policies are subject to interpretation and may differ based on department or product line. All of this matters because a single mistake could result in hundreds of thousands of devices not being viable.

This situation makes automation an essential piece of the equation going forward. Automation can help solve these problems by not only eliminating human error, but also by introducing a global, standardized system for all devices. This standardization is important because medical devices don’t exist in a silo. Each device typically has several points of connection, and this requires thinking about the big picture when it comes to managing devices and their key material consistently.

Once again, this is where the FDA’s release of guidelines around algorithms, protocols, and cryptography plays a role. The FDA pre-market guidelines, in particular, can help organizations select industry-standard algorithms and protocols as well as appropriate key generation, distribution, management, and protection approaches.

While the guidance from the FDA is helpful, it’s still quite broad, as it provides the “what” but is not prescriptive with the “how” for implementing certain solutions.

Many organizations still have questions like: How do we implement these protocols? What does this look like compared to our current ecosystem? And how do we make the necessary modifications and adjustments without completely changing our entire infrastructure?

There are three steps to get started:

This is often harder than it sounds. Whether you’re a startup or an established company, it’s important to understand the end goal of what you’re creating, including what it needs to connect to, what it needs to trust, and what it needs not to trust. Every device has endpoints that are making decisions, and you need to understand the architecture of the entire device and what its boundaries are. Having at least a rough plan of how you want it to work provides a template that you can apply to different products, and having that plan written down on paper makes it easy to remember what’s most important.

If you do have an existing PKI or other way to issue certificates, take the time to understand what that is. In some cases, larger companies tap into their existing enterprise PKI from their IT team, and while it’s okay to use some of that thinking, it’s always best to keep the security of the products you’re selling separate from your internal enterprise security. That’s because you never want your products in the market to be compromised by or be an access point into something inside your enterprise.

Clearly define the business impact of what you’re doing, including what might be impacted if something goes wrong. For example, would your brand reputation be damaged, or could a competitor take an edge in the market if you have a breach? These are all things you can’t overlook because they really impact your long-term business success.

From there, it’s time to dig in with the actual security setup. To do so, you need to:

First, you must identify regulatory requirements and define your corporate policies to ensure standardization across the entire ecosystem from implementation to enforcement. This should also help you determine how you want to approach PKI. 

From there, you can overlay those goals with your existing functionality. Ultimately, you don’t need to completely re-haul all of your internal infrastructure; rather, it might require small modifications that can end up making a big difference. These modifications include making sure you have separate, secure environments for the enterprise vs. your devices and separating your keys into distinct areas for development, staging, and production. 

It’s also important to remember that security with key material is a two-way street: It’s no longer just generating certificates and sending them to whomever. You also have to consider how partners, customers, manufacturing sites, and more will consume your key material. Understanding what that looks like will help you structure the right implementation for your needs. 

Finally, make sure your Certificate Practice (CP)/Certificate Policy Statements (CPS) are clearly defined in terms of what they are, how they’re being applied, and where they’re utilized – and that it’s all consistent across the organization.

Provisioning device identities requires the ability to embed X.509 certificates into every device. This certificate has to be quite small in the case of a wearable device like a pacemaker (vs. a large device like an MRI).

Creating and embedding the certificate requires several steps based on each device’s purpose. This requires thinking through the lifecycle of the device because once it’s operational in the field, it can’t just exist in that state forever. Just like we need to renew our passports, it’s important to renew these device identities to validate authority and make other updates as needed. As a result, automation becomes especially important here to ensure identities don’t expire unexpectedly and ensure consistency in how certificates get renewed.

When it comes to securing medical devices, there are so many different nuances to keep in mind. The new age of medical devices is high scale and high volume, and that comes with unique challenges. This scale and volume make it particularly important to be mindful of device limitations and how you’ll store and protect key material. Along the way, ask questions like: How will we issue certificates? Can we inject key material in real time at the manufacturing site?

And once those certificates are live within devices, you need to consider how they’ll be consumed, remembering that communications are now a two-way street, with customers, partners, manufacturers, and more sending communications to these devices.

To that end, one of the approaches that Keyfactor and nTropy have used recently is a process that allows you to batch generate hundreds of millions of certificates and store them on an HSM that sits onsite at the contract manufacturing site that way, you never have latency issues and can inject key material in real time. This process is based on the understanding that several unique ways exist to structure the storage and management of key materials. 

Ultimately, there are now many options available, and the most important piece of the puzzle is clearly understanding what your organization is trying to accomplish based on the requirements and then building a solution that meets those needs according to security best practices like those outlined above.

Ready to learn more? Get in touch – the Keyfactor team is ready to help.