It’s been 12 years since FDA started regulating cybersecurity in medical devices, and three years since Congress provided the agency the legal mandate to define and enforce cybersecurity in medical devices. 

What does this mean for those of you working on the latest device?

First, I suspect you have a tight schedule, maintaining commitments to investors, and are light on funding. In addition, you have absolutely no knowledge of what “medical device cybersecurity” means to FDA (and the understanding you do have is sketchy at best).

Over the last few years, FDA has streamlined its process to facilitate premarket reviews. Part of that involves the use of an electronic submission approach called eSTAR.¹ While this system offers some flexibility for other artifacts related to the approval of a premarket submission (e.g., hazard analysis, biocompatibility, etc.), FDA is extremely prescriptive in what it expects regarding cybersecurity. 

According to the agency, “If your medical device contains software, you need to provide all of the FDA-mandated cybersecurity documents.” While this statement has been repeated by regulators and security experts for years, I still need to repeat it on a weekly basis. Device makers insist, “This doesn’t apply to my medical device,” and offer an array of accompanying justifications for their position.

• There is only minor (or no) patient risk.
• Our communications are proprietary and therefore secure.
• Who would attack our device?
• We are good people. Why would someone attack us?
• We are a small company and can’t afford security.

Notice FDA’s statement presents no modifiers that might address patient risk, communication mediums, size of company, day of the week, or any other excuse a device maker may come up with.

What are these documents/artifacts mandated by FDA? The agency makes you work for this list; it certainly doesn’t convey it in its premarket cybersecurity guidance.² However, the list can be assembled by reviewing eSTAR itself. Further, since eSTAR gets modified, there are different versions (currently, we are at V6) and the quantity, type, and contents of these artifacts change across these versions.

The list of artifacts as of the current version of eSTAR includes:

• Security Risk Management Plan
• Threat Model Report
• Cybersecurity Risk Assessment Report
• Software Bill of Materials—This is a JSON machine-readable document
• SBOM Support Report
• Software Component Safety and Security Assessment Report
• Vulnerabilities with Uncontrolled Risk Report
• Unresolved Anomalies Risk Management Report
• Cybersecurity Metrics Report
• Cybersecurity Controls Report
• Architecture Views Report
• Cybersecurity Testing Report
• Cybersecurity Labeling
• Risk Management Report

Additionally, use the eSTAR help dialogs (click on the “?”) to determine what the minimum content should be for each document.

This represents the starting point for cybersecurity documentation in your submission. Beyond that, things can still go wrong. There are several best practices to use with these documents.

• Add a table of contents to each document.
• Have someone not involved with these documents read them for clarity.
• No document should consist of a single page.

Following is a list of the details FDA has been disclosing for the last two years (the list hasn’t changed) of the most frequent errors made in cybersecurity during a submission. I arranged these in a Top 10 order to represent my own observations as the most common mistakes. However, to be clear, all of these should be addressed in a submission regardless of the order.

No. 10: Attempting to remove connectivity to avoid being classed as a “cyber device”

A few years ago, this was a valid approach to avoiding FDA’s security requirements. In addition, I agree that without any form of communication functionality (e.g., Ethernet, Wi-Fi, USB, Bluetooth, serial, I2C, SPI, CAN, cellular baseband, LORA, satellite, IEEE 802.15, proprietary wireless, etc.), there isn’t an attack surface that can affect a large set of victims. However, FDA realized scoping this to only include devices with communication present was forcing manufacturers to remove communications from the device, and thus reduce the added features and functionality gained by supporting connectivity.

A common misconception is that by modifying your product it avoids being classed as a “cyber device” (as defined in the FD&C Act section 524b). Since FDA has interpreted the law in a stricter sense, you can safely ignore what 524b says, as FDA has included any 524b topics plus additional topics in its premarket cybersecurity guidance. That is what’s required to be satisfied to secure FDA approval.

No. 9: Overall lack of documentation clarity

The first person at FDA to view your submission is not the reviewer, but a person conducting a “technical review.” This individual is tasked with verifying all required documents are present and appear similar to the expected content. Failing this technical review results in a submission being rejected before it even reaches a reviewer.

Put yourself in the position of the reviewer; you have a limited amount of time to evaluate a cybersecurity submission. The author of the documents has mixed up all the contents, has not supplied part of what is required, and made references to documentation not included in the submission (including completely out of context tables and a plethora of references to other documents). What reaction other than frustration is the reviewer likely to experience? This is not the first impression you want to make. The goal should be to demonstrate expertise in cybersecurity, not frustrate the reviewer.

No. 8: The manufacturer doesn’t provide an assessment of findings and/or describe any changes made as a result of third-party penetration testing.

Set some ground rules for all testing, including work performed by any
third parties.

• Ensure the third-party penetration testers add traceable labels to every finding
• Ensure the third-party testers don’t draw conclusions about a finding
• In a manufacturer-created document that summarizes and traces to the third-party findings:
• Score the discovered vulnerabilities.
• Where scoring indicates a mitigating control is required, describe the control.
• Trace from these third-party findings to verification and validation testing to confirm the effectiveness of the mitigating controls. 

No. 7: Absent or inadequate vulnerability testing (i.e., malformed and unexpected inputs). 

The premarket cybersecurity guidance goes into significant detail regarding the security testing needed to be performed. Once again, these are not optional. 

As a simple checklist:

• Secure the design through “Input Validation.”
• Check the correct format, length, units, and type of data (i.e., alpha vs. numeric).
• Not just client side, but server side as well
• Check out the OWASP input validation cheat sheet.³
• Testing
• Boundary Value Analysis—Stress testing outside the range of expected values
• Fuzz Testing—Random data in structured formats, usually targeting digital interfaces
• Syntax Testing—Stressing the expected format of data (i.e., different date formats)
• SQL Injection Testing—Input SQL statements into fields

No. 6: Use of a vulnerability scanner (e.g., Nessus) in place of penetration testing

Nessus is a great tool, but it is just one step in penetration testing. Using a vulnerability scanner would be part of the research phase of penetration testing, not the entire process.

Penetration testing is a process that simulates a hacker attempting to get into a medical device system through research, physical means, and the exploitation of vulnerabilities. Penetration testers are paid to search for weaknesses and then try to prove they can be exploited, using an extensive variety of tools and methods.

No. 5: Issues with traceability, security risk control mitigations not adequately traced to security requirements, and testing reports 

The premarket cybersecurity guidance² said it best:

• “Provide traceability between the threat model, cybersecurity risk assessment, SBOM [software bill of materials], and testing documentation as discussed later in this guidance as well as other relevant cybersecurity risk management documentation.”
• “Establish traceability of architecture elements to user and medical device system security requirements. Such traceability should exist throughout the cybersecurity risk management documentation.”
• “Traceability of the asset to the SBOM component described in Section V.B.2, above, for proprietary and third-party code, when appropriate.”

Manually creating and updating tracing is extremely laborious and costly, and should be avoided if at all possible. Traceability is not unique to cybersecurity issues and needs to be performed across most of the artifacts in the premarket submission.

However, Word and Excel, out of the box, do not offer a good way of providing this type of tracing, and there is only one vendor I know of that has an add-in to support tracing.⁴ I am unaware of any open-source add-ins that can perform tracing.

Where possible, I suggest using a dedicated tool for document management, such as Requirement Managers, ALM, PLM, etc. 

No. 4: Failure to implement adequate security controls

Appendix 1 of FDA’s premarket cybersecurity guidance provides a list of security mitigations and recommendations for the use of cryptographically strong controls to achieve them. One hard and fast rule is not to try to create your own mitigations; these are always impossible to justify and very difficult to prove their effectiveness.

No. 3: Cybersecurity risk assessments score security risks using probability

Do not use likelihood or probability in any of the security scoring rubrics. The premarket cybersecurity guidance is clear on this point. FDA has also expressed this in many presentations. 

“Accordingly, cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling (also known as a ‘probabilistic manner’).” 

Don’t not use them in any manner, such as probability of occurrence or probability of harm, as utilized in “safety” scoring rubrics.

No. 2: Use of inappropriate security risk control mitigations or assumptions 

This is very similar to number 4, but it can manifest itself in a different manner, where attempts at weak justifications are utilized in place of cryptographic solutions. For example: 

• We are deep into the development cycle and don’t have time for security
• We didn’t have to secure the last medical device we created
• Our device is only used in the Cath Lab, so it is in a secure environment
• Our SaMD is just a server that doesn’t directly treat patients

The solutions are the same as for number 4—use strong cryptographic primitives.

No. 1: The SBOM is missing the minimum baseline attributes elements (i.e., relationship between components) and improper formatting

A machine-readable SBOM is not an Excel spreadsheet. Neither is a CSV nor a flat text file. Rather, a machine-readable SBOM is a file formatted in compliance with one of the two standards (CycloneDX or SPDX), usually expressed as a JSON file.

Refer to NTIA’s “The Minimum Elements For a Software Bill of Materials” standard to gain clarity on what content is required to be in the SBOM.⁵ Also, leverage free and open-source tools such as sbomqs (to evaluate the completeness of your SBOM)⁶ and parlay (to improve any missing content in your SBOM)⁷.

References
¹ tinyurl.com/mpo260381
² tinyurl.com/mpo260382
³ tinyurl.com/mpo260383
⁴ tinyurl.com/mpo260384
⁵ tinyurl.com/mpo260385
⁶ tinyurl.com/mpo260386

⁷ tinyurl.com/mpo260387

MORE FROM THIS AUTHOR: Selecting a Medical Device Cybersecurity Consultant

Christopher Gates is the founder and CEO of arsMedSecurity, a medtech cybersecurity consulting firm. He is a recognized thought leader in medical device cybersecurity and the current co-chair for H-ISAC’s MDSC. Gates has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, and Bluetooth SIG.