Welcome to the final installment of our breakdown of the new FDA cybersecurity standards In this post, we’ll look at required documentation manufacturers need to include in their premarket submissions.
The first item needed is written documentation that addresses each of the design requirements in section 5 of the Guidance, if the device has been classified as “Tier 1”.
(If its classification is “Tier 2”, then a manufacturer can leverage risk-benefit assessments, such as those described in ISO 14971, in place of descriptions of the implemented mitigations for each of the standards found in section 5 as would normally be required if the device is a Tier 1.)
This documentation must be sufficiently detailed to permit understanding of how the section 5 elements are incorporated into the design. Manufacturers will be required to add more clarification than is requested for labeling, such as how are keys exchanged, what cryptographic encryption methods are being used (AES 128), what integrity controls are being used on the data (hashing, signed certificates, etc.) and so on.
Submissions must also include description of how the software updated on the device. This should also include specifics on how the data is encrypted, how integrity is ensured, how the device verifies that the incoming software update package is an upgrade and not a downgrade. We recommend referencing the Department of Commerce’s NTIA guidance document on how to implement secure updates.
To avoid confusion, it’s best we define a few terms:
- Vulnerabilities are weaknesses within a device and its code
- Threats are exploitations of a specific vulnerability
- Exploitability is a metric of how easy it is to take advantage of a vulnerability. Vulnerabilities can exist, but are they hidden beneath multiple layers of security?
- Severity is the scale at which we measure the result of a vulnerability being attacked. Can a patient be killed? Can the device’s safety, efficacy, or performance be reduced?
This new guidance mandates that the metrics of exploitability and severity be included with each vulnerability. We recommend that manufacturers take advantage of the industry-standard CVSS (Common Vulnerability Scoring System) rubric, which includes these attributes plus a few more that deepen insight into a vulnerability.
We consider the AAMI TIR57 security risk management report to be the most actionable and applicable standard for risk management. When following this report as a guideline, a submission will include a security management report and a threat model, which will include supply chain and deployment. For supply chain, this would cover policies at the manufacturer level that prohibit components purchased from the so-called “grey market,” limiting sources to only certified vendors.
In terms of deployment, how are the product artifacts, e.g. software and hardware, supplied to the manufacturing facility? Could they have been corrupted during the delivering process or during manufacturing? If you are using an internal manufacturing process or a contract manufacturer, how is your company ensuring the integrity of these components?
A list of all cybersecurity risks and a detailed methodology, such as the STRIDE decomposition methodology, including justifications and traceability to requirements, must be included as well in order to show how risks were considered.
Furthermore, a list of all cybersecurity controls and their justifications and traceability to requirements need to be documented. These traceability requirements must have a list of vulnerabilities that are associated with the mitigations created to solve them, a written justification for why the mitigation is effective, and the traceability into the requirements documentation to show that the mitigation was actually a requirement and was implemented into the system. Moreover, both a code (SAST/DAST) and boundary analysis, as well as penetration testing, must be performed in order ensure the mitigations put in place are working as intended.
In order to tie back into all the cybersecurity controls pertaining to traceability, a traceability matrix will be required to connect all the document structures together. This should be an integral part of the artifacts that are created and traced through the development lifecycle.
In other words: Bring security into the mainstream of product development documentation.
Finally, a software SBoM needs to be cross-referenced to a vulnerability database, such as the NVD, as a manufacturer will want to show that currently there are no known vulnerabilities. Failing to include this risks a pre-market submission rejection.
This concludes our full breakdown of the new draft guidance put forth by the FDA for Cybersecurity in medical devices for premarket submissions. If any part of this material has been helpful to you, please let us know by emailing Ben Trombold and providing your feedback. Always be sure to sign up for our email alerts so you can be notified when new content is posted!
To learn more about Christopher Gates and his background in medical devices and cybersecurity,click here.