What to Do About the New FDA Requirements: A CTO's Perspective

Finally, after a mere four and a half years in draft form, the FDA has released updated cyber security requirements for new (medical) devices seeking approval this fall. These updated requirements highlight how medical devices are falling far behind other industries and are currently in a game of catch up. In what’s sure to be a fast paced and slightly chaotic version of catch up, medical device makers are currently faced with a slightly guided version of “choose your own adventure”, which let’s be honest here, is both good and bad. In the good column, device manufactures aren’t forced to use specific technologies or methodologies (unlike some other industries). However, on the bad column device makers are left in a bit of void with designing for security, essentially starting with nothing and needing to quickly come up to speed on various security offerings. We should expect this initial guidance to really be the start of many new regulations and standards, ultimately promoting more secure devices in the (distant) future.

Before I dig into the specific cybersecurity guidance from the FDA, I want to take a quick step back and talk about some generalized attack flows and threat models as they will help us work through the guidance and the implications for system design.

Whether it’s ransomware, a beachhead into the enterprise, cyptominers, or even malicious intentions for the medical device itself, most attacks can be roughly reduced to this:

System or device reconnaissance – the attacker needs to know “what” they are working with
The attacker needs some form of execution on the device
Privilege Escalation – Maybe for persistence, maybe to add new functionality, maybe to execute the real goal or maybe to pivot
The attack “end game”

Quick thought exercise – can you identify how these steps work or don’t work with the FDA’s cybersecurity guidance? As part of the thought exercise, you can also download our free Kevlar System Inspector tool and analyze your system to see how well it stacks up to this flow.

Backing up a step further, one thing missing from the FDA guidance, and medical devices as a whole, is a threat model. What specifically are the FDA and medical device manufacturers concerned with? Is the concern ensuring the device continues to operate as designed? (This would suggest cyber resiliency is important, which requires slightly different security design decisions). Protecting user / patient data? (This would suggest a greater emphasis needs to be placed on confidentiality to include encryption and key management).

The new FDA cybersecurity guidance is short - very short. It’s effectively two bullets, with some slight expansion on the first area. One thing of note before looking at the technical requirements, the term “reasonable” appears three times in those bullets, suggesting initially there will likely be some early adopter test cases, a lot of room for industry wiggle, and likely a throw of the dice as to which evaluation team is used for a given device submission.

The first real requirement is the ability to report vulnerabilities and patch fielded systems. The important point here is that previously medical devices were not required to support updates (of either software, firmware, or possibly hardware). Updates are a very important step for preventing initial execution (after it’s been identified) and preventing privilege escalation. The guidance doesn’t say whether updates have to be done over the air, or locally, providing some flexibility for system design. As with any security functionality, the hard part of providing updates is doing it securely – how do you integrate it into secure boot? How do you ensure the updates are authentic and have not been modified or even rolled back? How do you handle keys and certificates?

Of course, we here at Star Lab are a little biased , especially as it relates to updates. Updates are a very reactive security posture – whereas our work helps companies to design systems that are inherently secure. As part of this inherent security, we enable fundamental mitigations and threat model assumptions, hopefully narrowing the scope of any future reactive updates. Some updates though, such as to the OS kernel or processor microcode / firmware are critical, as they may remove or address lower-level security concerns.

The new regulations differentiate between “emergency” out of cycle updates (maybe the so called second category from above), and routine, scheduled updates. Using a combination of secure design principles, defense in depth, and tools such as Star Lab’s Kevlar Embedded Security, various mitigations can be integrated into the system – enabling more routine patch cycles and fewer “emergency” updates. Eliminating the constant churn of security and updates and being able to plan routine updates is beneficial to all parties. You never know, being proactive with security and submitting designs to the FDA that contain more than the bare requirements might set the bar for future regulations and give you a significant head start over your competitors! Of course, it doesn’t hurt to implement inherently secure designs if you care about your organization’s reputation.

The last requirement the FDA provides is developing complete (Software) Bill of Materials (SBOM) for all components and products of a device. This requirement is helping to lead device manufacturers towards identifying and patching vulnerabilities. A simplified case here, does your device use Log4j? How about if your device incorporates 3rd party packages which themselves include Log4j? The premise here is the device maker needs to know what all is in the device, such that if a vulnerability (i.e. initial access or privileged escalation) is identified in Log4J, it can be determined if that vulnerability impacts a given a device. Continuing with Log4j, it was frequently bundled with other software components making the impact of the CVE / vulnerability greater, as it often went undetected and wasn’t patched everywhere in a system, because device and software vendors didn’t have a complete BOM of all their components.

It’s probably no surprise that here at Star Lab, we’re a little biased on this as well, namely that if you build inherently secure systems and assume the worst case, then even vulnerabilities such as Log4j have mitigations already in place on the deployed system. Which, you guessed it, means a routine patch / update cycle helps remove the threat and an emergency update to prevent execution / spread isn’t required. This saves your organization time, money and helps with reputation.