A pro explains how to UPGRADE patch management in healthcare

The UPGRADE tool suite from a Department of Health and Human Services agency has the chance to help hospitals improve their patch management plans, i.e., how facilities apply necessary software fixes to their (many) internet-connected devices.

One minor issue with the Universal Patching and Remediation for Autonomous Defense proposed this spring: It doesn’t exist yet.

In May, the Advanced Research Projects Agency for Health (ARPA-H) called for ideas to build “a semi-autonomous cyber-threat mitigation platform that enables proactive, scalable, and synchronized security updates, adaptable to any hospital environment, and across a wide array of the most vulnerable equipment classes.”

The core of the UPGRADE effort relies upon a digital replica, or “twin,” of a hospital’s cyber environment—a kind of “gym” for testing the effects of any proposed device changes, according to Andrew Carney, program manager at ARPA-H.

“You can move through the multiverse of modifications you might make to your network before you deploy. And then ideally, UPGRADE will assist with that deployment,” he said.

In its solicitation request, ARPA-H noted that hospital cyberattacks typically begin through IT system weaknesses. A March report from the cybersecurity company Claroty found 23% of the firm’s studied medical devices—which included “imaging devices, clinical IoT [internet-connected] devices, and surgery devices”—have at least one “known exploited vulnerability.”

ARPA-H, which hosted an informational virtual event on June 20 for interested participants, is accepting UPGRADE proposals until September 18.

Carney spoke with Healthcare Brew about goals the agency has for the effort and how soon he expects the ideas to become a digital reality.

The interview has been edited for length and clarity.

What is challenging about patch management in a healthcare setting?

We rely on a wide array of varied technologies to provide patient care from a variety of vendors, and managing this kind of ecosystem is extremely challenging—uniquely so, especially when combined with the high availability requirements that healthcare facilities typically have.

When you’re presented with a patch, even from a vendor, the question of “Do I patch or not?” is not an easy one to answer. You have to allocate resources; someone may have to manually go to a set of devices to upgrade them. Even if the vendor has approved a patch…there’s not necessarily evidence that in your particular configuration with your other devices from other vendors, that that patch will not disrupt things. We see an extremely long time to patch in healthcare relative to other critical infrastructure sectors, and I think we need to tighten that up. We need to go from a year plus to patch to days.

Years from now, how do you envision this system improving healthcare IT systems?

There’s a whole other space—autonomous medical devices—where to have confidence to train any sort of automation that would be involved, you want a gym. You want a place where you can test and iterate very rapidly and scale without necessarily having to have all of the hardware…if we’re able to emulate our devices, if we’re able to do this at scale, then it really just becomes a question of: How much compute do you want to buy? How much time do you want to buy in the cloud or in your on-prem cluster to simulate and move through whatever you’re testing, whether that’s the performance of a new product that you’re purchasing, or if you want red teamers to be able to, properly, with the gloves off, assess the security of your system?

Who will you be working with to achieve this?

I’m really hoping to bring together a coalition of clinical engineers, folks that understand the managing services, the devices themselves…and how they’re used in the hospitals and clinics. Combine those folks with vulnerability researchers, reverse engineers, people that understand systems at a very deep level without necessarily having the benefit of source code or other development artifacts that the vendor would have privately. And [finally], human factors engineers who are looking at how people use the systems…we’re not looking to take people out of the equation. People will be the deciders. People will be making these decisions, but we can help them make those decisions more effectively. And we can certainly help them execute faster and more consistently.