Cybersecurity in medical devices

The U.S. Food and Drug Administration (FDA) now requires cybersecurity in connected medical devices. Even if your device only has a USB interface, it’s considered connected – it’s easy to add a Wi-Fi dongle if there’s a USB connector.

It happened fast. In a session in December 2022, just before Congress wrapped up for the holidays, legislation was passed giving the FDA a powerful new tool: Section 524B of the Food, Drug, and Cosmetic Act. With that change, the U.S. became a leading nation in the world in terms of making sure our medical devices are cyber-safe.

The FDA was ready to assume the responsibility to mandate, specify, and enforce cybersecurity in medical devices. They moved fast. Within 90 days they had issued what they call their Refuse to Accept policy, which declared that starting in October 2023, any new device submission lacking a comprehensive cybersecurity plan would be denied – no security, no market access.

But the FDA didn’t stop there. In September 2023, they provided information on what cybersecurity content to include in a pre-market submission with the release of Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions – Guidance for Industry and Food and Drug Administration Staff.

Don’t be fooled by the word “guidance” in the title of their new document or the mention of nonbinding recommendations, as cybersecurity is absolutely required by the FDA. One-sized security doesn’t fit all is the reason for mentioning guidance and nonbinding. The FDA is concerned that without these terms, companies are going to implement exactly what’s in the document. The FDA’s intent isn’t to mandate specific security controls; instead they want companies to follow a process, consider the cyber risks their devices face, and scale the amount of cybersecurity given the level of risk. For example, a Bluetooth thermometer needs a much different level of cybersecurity compared to a digital X-ray.

By October 2023, the FDA was up and running, reviewing cybersecurity for new market submissions and sending rejection letters to those that didn’t have adequate cybersecurity. In 10 months, cybersecurity went from being recommended to required. That’s warp speed for a regulatory agency the size of the FDA and the level of impact this change is having.

Yet, the FDA’s commitment to medical device safety goes beyond speed. They recognize cybersecurity is an integral part of overall device safety, and have included security in their quality system regulations. So, if you’re familiar with medical device safety, you already have a good idea of the processes, work involved, and documentation the FDA requires.

What do you need to do to meet the FDA’s expectations for cybersecurity? Below are 8 steps to follow, in order, if you’re starting out on a new design.

1. Follow a cybersecurity process – The FDA calls this a Secure Product Development Framework (SPDF). They’re looking for a cybersecurity process that covers the life cycle from conception to device end-of-life. If you don’t already have one, find a standard process that’s a good fit for your company and ideally is recognized by the FDA. There are many out there. You don’t have to use an FDA recognized standard, but it’s the easier path. Using an unrecognized standard can lead to more questions and time as the FDA reviewer will most likely not be familiar with it. IEC 81001-5-1 is a good option for a SPDF as it’s lightweight, an FDA recognized standard, and specifically referred to in their cybersecurity documents.

2. Evaluate product risk – The FDA requires a threat assessment and risk analysis. Again, there’s plenty of preexisting material you can leverage. STRIDE is a commonly used threat assessment approach. Once you’ve identified the threats, analyze the risks. Here, the FDA recognizes AAIM SW96:2023, which nicely integrates with the processes outlined in IEC 81001-5-1.

3. Security by design & defense in depth – As the FDA mentions, security should be built in and not bolted on. This is what’s meant by security by design. Consider security right from the beginning. A nice result of the time and effort of doing a risk assessment is it’ll help you determine just the right amount of security needed. Your technical security specification will flow naturally from the risk assessment. You can expect a good risk assessment will conclude defense in depth is needed. That means you’re not just relying on one level of security. There are two types of companies, those that have been hacked and those that will. The point is all systems will get hacked at some point. A defense-in-depth approach will have additional levels of security hackers must overcome after an initial breach.

4. Consider security controls the FDA is checking for – In Appendix 1 of the FDA’s premarket cybersecurity document is a list of security controls the FDA recommends. They are:

• Authentication
• Authorization
• Cryptography
• Code, data, and execution integrity
• Confidentiality
• Event detection and logging
• Resiliency and recovery
• Updatability and patchability

Refer to this list when considering cybersecurity features to reduce identified risks. There’s a good chance the FDA will ask if you don’t include these controls, or you don’t provide a rationale why they aren’t included.

For example, as part of your threat assessment and risk analysis you may consider the configuration changes, accessible via an Ethernet interface, impacting patient radiation dosage in an X-ray machine. Because network accessibility and risks to patient safety are so high, to mitigate the risk to an acceptable level, detection of cyber-attacks in real-time could be identified as essential. An effective control would be intrusion detection software (IDS) such as BG Networks’ AnCyR IDS. This IDS detects attacks, software changes, and configuration changes immediately. Another reasonable conclusion in a high-risk device is any cyber-critical software should run in a Trusted Execution Environment (TEE) such as Kinibi from Trustonic. A TEE uses a combination of software and security features built into the embedded processor silicon (e.g., ARM Trust Zone) to isolate and protect software or data, such as an IDS, personally identifiable information, security related secrets (i.e., keys), or financial information. The IDS falls into the category of event detection and logging, while a TEE provides code, data, and execution integrity. These are two of the security controls the FDA is looking for. Then it’s just a matter of clearly documenting these categories have been addressed, describing the security control implemented for each category, and linking the feature to testing.

5. Fixing vulnerabilities: SBOMs-software updates-monitoring – The FDA has really focused on post-market vulnerability management for medical devices, wanting medical devices in the field to be fixed if cybersecurity vulnerabilities are identified. Their specific recommendations include the ability to receive secure software updates, maintain comprehensive software bills of materials (SBOMs), and continuously monitor for vulnerabilities. These three go hand in hand and need to be considered and added during the design stage as part of a defense-in-depth approach.

Why are these three crucial? An accurate SBOM acts as a detailed inventory of device software components, allowing for quick identification of vulnerable components when reported or detected from threat intelligence (a.k.a. monitoring for vulnerabilities). Secure software updates then become the vital tool for patching these vulnerabilities and ensuring device security. This continuous cycle of monitoring, identifying, and patching weaknesses, strengthens the device’s overall cybersecurity posture, ultimately protecting patient well-being.

6. Cyber-testing – The FDA emphasizes robust software development practices, including rigorous verification testing. Good verification testing also applies to cybersecurity. By following your usual software verification process you’ll also address the first sort of cybersecurity testing the FDA is looking for. Cybersecurity testing that’s not part of a typical software testing flow, which you’ll most likely need to add, is validation testing and penetration testing (pen-testing). Cybersecurity validation testing is crucial to confirm the effectiveness of implemented controls. Pen-testing simulates real-world hacking attempts by independent security experts, uncovering exploitable vulnerabilities. Quite often vulnerability scanning and fuzzing would be used as part of a pen-test. A more advanced level of security testing will include vulnerability scanning and fuzzing earlier in the development and will be part of continuous integration and continuous delivery (CI/CD) processes (a.k.a. shifting left).

7. Labeling/documentation – The FDA has specific requirements on device labeling and end user documentation, making it clear to the end user their responsibilities to ensure the medical device remains secure throughout its lifetime.

8. Post-market activities – Ensuring robust cybersecurity requires diligent post-market activities, including vulnerability monitoring, incident response, and continuous patching. Most likely a different team, from the design team that included these features in the medical device design as part of a defense-in-depth approach, will have responsibility. Here’s how to navigate this crucial phase:

Vulnerability monitoring: Maintaining updated SBOMs is important; they allow you to promptly identify software in devices at risk from newly discovered vulnerabilities. Automation tools to generate SBOMs and monitor for vulnerabilities can help. This includes open-source tools such as OWASP Dependency Track to monitor the National Vulnerability Database (NVD) and several commercial offerings. There are many options for gathering threat intelligence – vulnerabilities. This includes paid-for threat intel services, information sharing organizations such as the Health ISAC and the Health ISAO, and direct customer reporting. Make it very clear to your customers how they should report vulnerabilities to you – they will be one of the most important sources of information for identifying vulnerabilities.

Incident response: Swift and decisive action is key in the face of a reported vulnerability. Possess a well-documented and regularly practiced incident response plan, clearly outlining roles, responsibilities, and communication protocols within your team and outside the company. This ensures coordinated and rapid response.

Upon receiving a vulnerability report, quickly assess its impact on the devices, prioritizing based on exploitability and risk. Remember, transparency is paramount. Promptly inform customers and the FDA about identified vulnerabilities and mitigation plans.

About the author: Colin Duggan is founder and CEO of BG Networks.

BG Networks
https://bgnetworks.com