FDA Premarket Cybersecurity Guidance - 4 questions

#1
Hi, all

I have read the cybersecurity guidance ('Content of Premarket Submissions for Management of Cybersecurity in Medical Devices), and have some questions about it.

I want to ask about the following parts of this guidance that I do not clearly understand.

Q1. Page 13, (b)-(iii) of the guidance:
(Use cryptographically strong authentication resident on the device to authenticate personnel, messages, commands and as applicable, all other communication pathways)

I do not understand the word 'cryptographically strong authentication resident.' Does it mean like encryption keys or something?

Q2. Page 17, (g) of the guidance:
(The device design should provide a CBOM in a machine readable, electronic format to be consumed automatically)

2-1) Must I (manufacturer) document and maintain the CBOM (Cybersecurity BOM)?
2-2) What does 'machine-readable, electronic format' mean? Is it okay just to document and maintain those in 'Word', 'Excel', or any other commercial document format? Otherwise, other special formats should be required?

Q3. Page 16, (a) & (c)
((a): Implement design features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use. )
((c): Ensure the design enables forensic evidence capture. The design should include mechanisms to create and store log files for security events. Documentation should include how and where the log file is located, stored, recycled, archived, and how it could be consumed by automated analysis software (e.g. Intrusion Detection System, IDS). Examples of security events include but are not limited to configuration changes, network anomalies, login attempts, and anomalous traffic (e.g., sending requests to unknown entities).)


What is the difference between the requirement (a) & (c) exactly? If the device (or software) is designed to log some events (for example, logging the user login, time, or data export), does the design satisfy both requirements? Otherwise, does it just meet the (a) or (c)?

Q4. Page 16, (b)
(Devices should be designed to permit routine security and antivirus scanning such that the safety and essential performance of the device is not impacted. )

Should I verify that the program itself is not recognized as a malware or virus? In addition, is it necessary to verify that the operation of the device (or software) is working normally during vaccine scanning?

Many thanks for your opinions!
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
These are tough questions. I'll offer my thoughts if nothing more than to get the ball rolling.

First, you are referring the 2018 (draft) guidance, not to the 2014 ("final") guidance. FDA won't press you on following the draft. I'd say it does reflect more current thinking so it's good to consider.

Second, if you haven't already, do take a look at the postmarket management guidance as well. You want to consider the whole product lifecycle. Planning for downstream may drive some of the upstream.

Third, you might do well by getting a copy of UL 2900-1. That may clear some of this up for you. It's an FDA recognized consensus standard. And there's a companion, UL 2900-2-1 which takes some particulars further.

With that, here goes...

Q1. Page 13, (b)-(iii) of the guidance:
(Use cryptographically strong authentication resident on the device to authenticate personnel, messages, commands and as applicable, all other communication pathways)

I do not understand the word 'cryptographically strong authentication resident.' Does it mean like encryption keys or something?
As always with guidances, they can't dictate an approach but I would think encryption keys would be a reasonable method. You'll, of course, want to do a Cybersecurity risk assessment. Let the risk drive the type of controls. The item 'b' being addressed is "Authenticate and Check Authorization of Safety-Critical Commands" so if you're passing those safety-critical commands, how do you ensure they are authentic and accurate?

UL 2900-1 has a reference to acceptable security functions (which is a bunch of ISO references; e.g., 11770, 15946, etc.). (Honestly, if you had to purchase all the referenced docs, the company may go broke so be aware it's probably an unending string of references.)

Q2. Page 17, (g) of the guidance:
(The device design should provide a CBOM in a machine readable, electronic format to be consumed automatically)

2-1) Must I (manufacturer) document and maintain the CBOM (Cybersecurity BOM)?
2-2) What does 'machine-readable, electronic format' mean? Is it okay just to document and maintain those in 'Word', 'Excel', or any other commercial document format? Otherwise, other special formats should be required?
I'd say it's pretty much "state of the art" now to maintain a CBOM. And I think Word or Excel is acceptable. The end of that statement is "to be consumed automatically" so I'd guess Excel would be preferred (and maybe exportable to CSV).

In the postmarket guidance, they get into forming a consortium to keep everyone up to speed and help in monitoring. I expect this is something to support that.

Q3. Page 16, (a) & (c)
((a): Implement design features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use. )
((c): Ensure the design enables forensic evidence capture. The design should include mechanisms to create and store log files for security events. Documentation should include how and where the log file is located, stored, recycled, archived, and how it could be consumed by automated analysis software (e.g. Intrusion Detection System, IDS). Examples of security events include but are not limited to configuration changes, network anomalies, login attempts, and anomalous traffic (e.g., sending requests to unknown entities).)


What is the difference between the requirement (a) & (c) exactly? If the device (or software) is designed to log some events (for example, logging the user login, time, or data export), does the design satisfy both requirements? Otherwise, does it just meet the (a) or (c)?
Item a would be detecting, for example, consecutive failed login attempts and taking ACTION to prevent further attempts after so many. Item c would be to log all that, capturing data like the user attempting, location of attempt, etc. Maybe you maintain a checksum on critical data and if you get a checksum fail, for a you take action to shut down the application; whereas for c, you're just logging each change and who made it, etc.

Q4. Page 16, (b)
(Devices should be designed to permit routine security and antivirus scanning such that the safety and essential performance of the device is not impacted. )

Should I verify that the program itself is not recognized as a malware or virus? In addition, is it necessary to verify that the operation of the device (or software) is working normally during vaccine scanning?
Actually, you would want to ensure your code doesn't contain constructs that antivirus software would flag and prevent further use! (A couple of our developers routinely get flagged by our AV software regarding programs they compile - hasn't prevented use but you don't want your application causing flags to be raised.) But I don't think that's the intent of this. The section heading is "Design the Device to Detect Cybersecurity Events in a Timely Fashion" so I think these are the AV controls YOU implement. You want them running frequently enough to detect potential breaches but you don't want to impact the performance of the software so as to affect safety or efficacy.

Hope that helps. And I hope I'm correct! :)
 
#3
Thank you for your kind reply, yodon! and I'm sorry for my late response.
Your answers definitely have helped me a lot!

Furthermore, I want to share the FDA's replies from my overall questions received 2 weeks ago.


Q1. Page 13, (b)-(iii) of the guidance:
(Use cryptographically strong authentication resident on the device to authenticate personnel, messages, commands and as applicable, all other communication pathways)

I do not understand the word 'cryptographically strong authentication resident.' Does it mean like encryption keys or something?

FDA_A1: Cryptographically strong authentication refers to ensuring you have an authentication scheme that uses some form of encryption. The strength of the authentication is based on the time and resources necessary to reverse engineer the authentication algorithm. This can be something like a public/private key implementation but other alternatives exits.



Q2. Page 17, (g) of the guidance:
(The device design should provide a CBOM in a machine readable, electronic format to be consumed automatically)

2-1) Must I (manufacturer) document and maintain the CBOM (Cybersecurity BOM)?
2-2) What does 'machine-readable, electronic format' mean? Is it okay just to document and maintain those in 'Word', 'Excel', or any other commercial document format? Otherwise, other special formats should be required?

FDA_A2: A cybersecurity bill of materials (CBOM) or software bill of materials (SBOM) should be maintained as part of the configuration management of the software/device and recorded as part of the Device Master Record and Design History File. For format we would recommend you consult industry best practices for machine-readable formats like those recommended by the National Telecommunications and Information Administration’s (NTIA’s) work on SBOM content and format.



Q3. Page 16, (a) & (c)
((a): Implement design features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use. )
((c): Ensure the design enables forensic evidence capture. The design should include mechanisms to create and store log files for security events. Documentation should include how and where the log file is located, stored, recycled, archived, and how it could be consumed by automated analysis software (e.g. Intrusion Detection System, IDS). Examples of security events include but are not limited to configuration changes, network anomalies, login attempts, and anomalous traffic (e.g., sending requests to unknown entities).)


What is the difference between the requirement (a) & (c) exactly? If the device (or software) is designed to log some events (for example, logging the user login, time, or data export), does the design satisfy both requirements? Otherwise, does it just meet the (a) or (c)?

FDA: There is some overlap between the expectations identified in parts a and c however there are some differences as there might be jurisdictional requirements for forensic capture practices that may be required for logging of forensic events versus standard operating logging and event detection particularly around ensuring the authenticity, integrity, and availability of forensic logs.



Q4. Page 16, (b)
(Devices should be designed to permit routine security and antivirus scanning such that the safety and essential performance of the device is not impacted. )

Should I verify that the program itself is not recognized as a malware or virus? In addition, is it necessary to verify that the operation of the device (or software) is working normally during vaccine scanning?

FDA_A4: This would depend on the device itself and its context of use. Some embedded products that use real time operating systems (RTOS) would not support antivirus software as they may not be susceptible to common operating system viruses. In terms of running the scans while the device is operating, that would depend on the environment of use. If it is a multiparameter monitor or life supporting/life sustaining product, then it may need to run while the device is functioning as downtime of the device could present patient harm. If it is a device that does not have such use requirements, it could be designed such that the device could be idle while performing the scan.



I hope this helps you understand.
Have a great day!
 
#4
Here are some additional points to consider:
  • As mentioned above, the 2018 guidance is still "draft" and the FDA has made several statements that the guidance has been re-written and will be re-released as a draft at some point. They have also stated that the CBOM will change to SBOM (software bill of materials) and the tiering will be removed from the guidance. They have previously stated that an updated draft would come out this year; however, covid seems to have impacted their plans
  • The questions above are technical in nature, but also make sure you are considering the following for cybersecurity, as this may be looked for in a submission
    • Threat Model - Microsoft STRIDE is a good methodology to evaluate
    • Cybersecurity Risk Assessment - Common Vulnerability Scoring System (CVSS) is commonly used
    • Design Input & System Cybersecurity Requirements - document all requirements, as mentioned above UL2900 is a good starting point
    • V&V - make sure requirements are traced and tested
    • Cybersecurity testing - static application security testing (SAST) for all custom software, software composition analysis (SCA) for the SBOM, vulnerability scanning for network devices and penetration testing when a full device is ready
    • Labeling - a completed Manufacturers Disclosure Statement on medical device security (MDS2) form
  • Also consider having a security professional review or develop the design and data flow diagrams to ensure cybersecurity is properly considered
Please let me know if you have any additional questions.

Thanks,
Colin Morgan
Managing Director

Apraciti, Medical Device Cybersecurity
[email protected]
 

Ed Panek

QA RA Small Med Dev Company
Trusted Information Resource
#5
Would we be able to use the risk analysis work we completed for GDPR as part of the evidence?
 
#6
Would we be able to use the risk analysis work we completed for GDPR as part of the evidence?
It depends on what that file looks like; however, GDPR is primarily focused on privacy rather then security. It may cover some aspects of the cybersecurity risk assessment, but probably not all of them.
 
Thread starter Similar threads Forum Replies Date
M Medical Device News FDA Releases Draft Recommendations on Premarket Submissions for Management of Cybersecurity in Medical Devices Other US Medical Device Regulations 0
M Medical Device News FDA news -11-09-18 - Review of Cybersecurity into Premarket Review Other US Medical Device Regulations 0
M Informational US FDA Final Guidance – Special Premarket Notification [510(k)] Pathway Medical Device and FDA Regulations and Standards News 0
M Informational US FDA Final Guidance – Consideration of Uncertainty in Making Benefit-Risk Determinations in Medical Device Premarket Approvals, De Novo Classificati Medical Device and FDA Regulations and Standards News 0
M Informational US FDA Final guidance – Metal Expandable Biliary Stents – Premarket Notification (510(k)) Submissions Medical Device and FDA Regulations and Standards News 0
Ronen E FDA News FDA issues guidance on bench testing in premarket submissions Other US Medical Device Regulations 0
S Is Software code documentation required for FDA premarket submissions? IEC 62304 - Medical Device Software Life Cycle Processes 2
M Medical Device News FDA news 14-09-18 - Use of Voluntary Consensus Standards in Premarket Submissions Other US Medical Device Regulations 3
K FDA Premarket Submissions for Embedded Software - Level of Concern Other US Medical Device Regulations 4
P FDA - Evaluating Substantial Equivalence in Premarket Notifications 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
S FDA CDRH Premarket Review Submission Cover Sheet - adding more products 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
bio_subbu US FDA issues Draft Guidance on Premarket Approval (PMA) Acceptability Other US Medical Device Regulations 0
R FDA CDRH Premarket Review Requirements - Submission Cover Sheet 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
Michael Malis FDA issued modifications to the list of standards used in Premarket Review Process US Food and Drug Administration (FDA) 0
P FDA Approved Product Contact Parts ISO 13485:2016 - Medical Device Quality Management Systems 6
O Clarifying FDA definition of "finished device" and “capable of functioning” 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
A FDA guidance on non-sterile Medical Device Packaging Medical Device and FDA Regulations and Standards News 4
JoCam FDA Registration for Sub-contract manufacturers Medical Device and FDA Regulations and Standards News 2
M FDA News FDA Releases Draft Guidance Clarifying Application of ISO 10993-1 Biocompatibility Standard Medical Device and FDA Regulations and Standards News 0
M Is IEC 60601-1-2 required by FDA for all electronic medical devices? IEC 60601 - Medical Electrical Equipment Safety Standards Series 1
E Contract manufacturer FDA requirements foreign company US Food and Drug Administration (FDA) 6
P Choice of FDA reviewer US Food and Drug Administration (FDA) 6
J Is Device Tracking Card an actual requirement under FDA regulation? Other US Medical Device Regulations 0
T Definition Human Use (FDA) Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 7
K FDA 510k electrosurgery 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
J Leveraging FDA 510k Clearance for International Registrations Other Medical Device Regulations World-Wide 2
shimonv FDA News FDA guidance on Multiple Function Device Products (8/2020) Other US Medical Device Regulations 1
N FDA UDI - Label vs. Labeling - Does the insert need to include UDI? Other US Medical Device Regulations 0
J FDA notification of address change US Food and Drug Administration (FDA) 2
N Usability testing required for FDA IDE (investigational device exemption)? Human Factors and Ergonomics in Engineering 3
A FDA Class Classification for a cabinet 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
L FDA Biocompatibility Requirements - Transitory Contact Other US Medical Device Regulations 1
Edward Reesor FDA DM and /or Class I Life Saving US Food and Drug Administration (FDA) 0
Watchcat FDA will not tolerate fraud…meaning what, exactly? Other US Medical Device Regulations 6
gunnyshore Form FDA 3500A MedWatch eSubmitter 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
Watchcat FDA Webinar Series - N95 Respirators Other US Medical Device Regulations 0
M Off-Label Use - Clarification of FDA Policy US Food and Drug Administration (FDA) 1
J Sub-supplier change from manual to automated process - same specs - Report to FDA? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
C FDA Establishment registration - Buying some medical devices from another manufacturer Medical Device and FDA Regulations and Standards News 5
I How to classify a medical device based on FDA? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
dinaroxentool Question about FDA Classification of a Device 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
S The US FDA requirements on Disposal of a medical device US Food and Drug Administration (FDA) 1
S FDA Requirements for Medical Device Label Reconciliation 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
S What is considered a "core algorithm"? (From an FDA guidance document) Medical Information Technology, Medical Software and Health Informatics 4
B FDA-Medical Device Reporting (MDR )procedure compliant with 21CFR section 803 US Food and Drug Administration (FDA) 0
Stoic Are any medical device companies using the 2011 FDA process validation guidance instead of GHTF/SG3/N99-10:2004? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
D ISO 13485, FDA 21 CFR 820 and Auditing the Accounting Department ISO 13485:2016 - Medical Device Quality Management Systems 5
S FDA's E submitter - For clinical electronic thermometer Medical Device and FDA Regulations and Standards News 6
J FDA wants electrical safety testing on battery powered medical device US Food and Drug Administration (FDA) 11
A FDA and NB audit of Engineering Drawings in DHF and DMR. Medical Device and FDA Regulations and Standards News 1

Similar threads

Top Bottom