The FDA released draft guidance for cyber security of medical devices on October 18th, 2018, that if instituted, is going to be an enormous change for the industry, including both medical device manufacturers and healthcare providers. The guidance is aimed at medical device manufacturers and gives recommendations for what the FDA states should be included documentation provided by the manufacturer to the FDA in the 510k certification process (the process required for a new medical device to be approved by the FDA for sale).
The changes are substantial, and the document has some opportunities for improvement, which are expected of a draft. SRA will be submitting questions for clarification and comments for improvement to the FDA, though there are some expectations that the final version of this document could be instituted by January of 2019. We are going to focus on a few key changes, but we will be releasing more materials in the future, including some enhancements to VECTR (https://vectr.io) to support the documentation and security testing processes in a robust and repeatable manner!
Devices must be classified as “Tier 1” or “Tier 2”
Tier 1 indicates that it is 1) a networked device, that 2) if compromised, could directly result in harm to multiple patients. Tier 2 is essentially “everything else”, so non-networked, or would not result in direct harm to multiple patients. The FDA hasn’t yet defined “direct harm”, but the working assumption is that “direct harm” implies that it could actually directly harm patients, without any intervention from a clinician. If a device reports data in a decision-making process (ex: a medical imaging device) through a clinician, then any harm would be considered indirect, and possible to be detected and prevented by a human interpreting the results.
- FDA questions: It was noted that the exact language used to describe Tier 1 references a single device harming multiple patients. Was the singular device and plural patients reference on purpose? For example, a networked pacemaker device could directly harm a single patient (because it was in Homeland!). Would that qualify as a Tier 1 device, or a Tier 2 device? Based on the exact wording, it would appear that it would qualify as “Tier 2” since it can only harm a single patient.
Based on the Tier of your device, you must do the following:
- Tier 1: You must address all areas of design requirements and risk assessment process in your documentation
- Tier 2: You must either address all design requirements or provide a risk-based analysis of why that design requirement is not appropriate or necessary for this device.
Device Design Requirements (the most notable ones)
- No hardcoded credentials, and role-based access control
- Devices should “deny by default” all connections (network, usb, etc)
- Application Whitelisting by Signatures
- Runtime application execution integrity checks
- Devices should support security and virus scanning without impact to the device
- Design should enable forensic data capture
- Cyber security bill of materials (CBOM) for all hardware, firmware, and software
- Have a certificated, built-in software patching / support mechanism
- Provide logging to external logging systems
- Be able to restore a compromised system to original configuration in a secure fashion
- FDA Questions: For detective controls, there is much detail about how logging must be enabled for cyber security monitoring. The way it is written is ambiguous about who is the responsible party for monitoring those logs. Is there an expected responsible party for doing security monitoring? Should logs be shipped to the healthcare provider, or is there an expectation that the manufacturer should be monitoring security of its devices in the field?
Risk Management Documentation Requirements (the most notable ones)
- Threat Modeling – A system level threat model that takes into account all phases of the lifecycle of the device, to help identify security controls for implementation in the device design.
- Risk Considerations – Documentation of all risks considered in the design process, including impact and likelihood / exploitability.
- Controls List – a list of all verifiable controls identified and implemented in the final design.
- Testing Evidence and Documentation – detailed test results showing efficacy of all controls implemented. (Contact us for a VECTR-enabled version for this)
- Mapping of controls implemented to risks identified – tying together threats and risks, to those controls implemented in the device.
- Hardening instructions
- Network behavior (ports and services) manifest
- Directions for restoration of original configuration
- Cyber security bill of materials (machine readable)
We hope this was helpful. Please take a read through the full requirement at the link above, as there is much more. Reach out to us with any questions at email@example.com, or directly to the FDA and provide your feedback and comments at https://www.regulations.gov/ or CyberMed@fda.hhs.gov
Stay tuned as we will be updating this as the guidance evolves, and will share any responses we get from the FDA.