What I Learned Today: The Complexities of Medical Device Security

With the help of Health-ISAC and Claroty, I hosted an incredibly insightful panel discussion this week on a critical topic, cybersecurity for medical devices. We spoke for the full hour and broadcast the discussion live as an online webinar. We covered important topics such as the: 

• SBOM's growing role in reducing risk and promoting software transparency
• Impact of the FDA's draft guidance and what it means to medical device security
• Steps we can take now to grow cooperation between device manufacturers and HDOs to reduce software supply chain risk 

It's not everyday you get a group of experienced and insightful thought leaders in a specific vertical market and cybersecurity discipline who can navigate an incredibly insightful conversation on a critical topic – medical device cybersecurity. In fact, I am not sure how we fielded such an incredible collection of domain experts!

Our panelists included the H-ISAC's Director of Medical Device Security, Phil Englert, the Director of the H-ISAC Threat Operations Center, Zach Nelson, Claroty's Global Head of Manufacturer Alliances, Steve Baum, as well as Peter Fonash, a Chief Technology Officer and Justin Heyl, a Director of Enterprise Risk Management, each with deep roots and experience in the medical device cybersecurity space.  

The discussion inspired me to create this new series of posts, titled “What I Learned”. In this case, I learned a lot!!!

Takeaway 1: In a Sea of Complicated Cyber Initiatives, Medical Device Security is Perhaps the Most Complicated 

No other area of cyber comes so close to our individual human existence. In many areas, lives may be on the line, but when the target of a cyberattack is the very device we entrust with our lives and health, the threat instantly becomes very real, and very personal.

There’s so much riding on how medical devices are built, how the underlying software and firmware are compiled and how those components integrate (or don’t) within the device(s) as they interact with potentially unregulated applications in environments that aren’t necessarily the easiest to maintain, update or patch into. 

The panelists talked about the complexity of OT and IoT networks, and how to stand up programs, teams and workflows to optimize efforts to reduce risk for medical device manufacturers and asset owners (those who buy, deploy and manage connected medical devices). 

What I learned is that the participants, all with operational know-how in this area, stated that if you can achieve three things, you can improve the process and the results of your program: 

1. Weighting risk by risk factors including: Will this harm humans? 
2. Will this introduce unforeseen risk and diminish the cybersecurity function's visibility into the connected device?
3. And how does that connected device enable the continuous improvement of patient care?

Standards are only good if you use them and adapt your modeling, workflow and team to proven standards that enable you to reduce significant risk. 

It's an interesting discussion when you are making decisions that not only affect patient care, but that make teams re-think WHY they are performing specific tasks that are cyber-related even when they have a long-tail impact into saving and maintaining life. 

Think about that. 

Takeaway 2: No One Standard or Governing Body Owns the Whole Enchilada 

CISA. ISO. The FDA. Health-ISAC. Who owns HOW we are supposed to apply cybersecurity to the management of medical devices for usage at HDOs, and / or…who should be the governing force that device manufacturers look to when they structure their testing, assessment and validation initiatives in order to ship secure medical devices on time, and with protocols for users where patching is clearly defined, and where resilience is paramount? 

Who owns HOW we are supposed to apply cybersecurity to the management of medical devices?  Who should be the governing force that device manufacturers look to when they structure their testing, assessment and validation initiatives? 

It was suggested on the panel that perhaps Health-ISAC should own this from an industry standpoint. However, then we went down the path of whether or not the government should dictate or mandate standards, and there seemed to be agreement from the panel that the government should really follow industry, and not dictate to industry. 

All this time, I’ve always thought that these regulatory initiatives and mandates typically are spun out of the Fed and then implemented. Learning is really cool….

Takeaway 3: No One National or Global Mandate Will Spur Action 

The panel pointed out the reality that every company with a stake in medical device security can benefit from adopting CISA and the FDA draft guidance on medical device security. 

What I learned is that it's truly incumbent on the organization – whether it's an HDO or a device manufacturer – to assess their readiness as an organization to implement, integrate and deploy a given device based on the maturity of their program, their ability to assess risk well and whether or not they’re leveraging the expertise necessary to manage third-party products, or to produce connected products with a priority on cybersecurity. 

The latter means the device manufacturer literally has to build cyber as a priority into its AppSecOps, (SAST, DAST) its binary analysis of the full device build (via SBOM or raw firmware analysis) and its ability to respond should the next Wannacry or Log4j vulnerability appear that ultimately sends teams and organizations into a panic or tailspin, or both. Knowing how to incorporate the elements of risk vs benefit, and the right action based on the right mix of mandates and standards is an art, not a science. 

Takeaway 4: The SBOM Might Be the Vehicle, But It's Not a Panacea

It's true that the SBOM – and any organization who can easily produce one – is essential today and is growing in importance. In fact, without the SBOM, the panel pointed out that there’s a fundamental lack of visibility into most, if not all, medical devices from a software and firmware standpoint. 

On average, only 15% of an IoT device’s code is first-party built. What this means is that 85% of the rest of that device is likely a jumble of compiled open source, component, sub-component, chip and binary builds that you, as the device manufacturer, have little control over from a cybersecurity perspective. 

Further, the third-party software and components that exist in medical devices are there for a reason – they help the device do what it's supposed to do. Pump insulin. Monitor an irregular heartbeat. Measure a patient’s lifeblood during surgery. 

The downside according to the panel discussion is that controlled patching can be challenging based on how the devices are configured, where they are connected, what their compositional makeup is, and at what volume they are deployed and connected. 

In summary, I learned quite a bit just asking questions and assembling people to bring such an important issue to the forefront. I am privileged to be in the position where I get to ask people to come together for the benefit of this industry and explore its hard questions. 

If you missed this webinar live, you can catch the entire discussion here.

If you want to pull down parts of the discussion, you can also check our LinkedIn page for regular updates, and you can also check our Twitter feed (@finitestateinc).