FDA Premarket Cybersecurity Guidance - 4 questions

K

Kyunghwan Kim

Registered
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!
 
Y

yodon

Leader
Super Moderator
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...

Kyunghwan Kim said:
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?
Click to expand...

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.)

Kyunghwan Kim said:
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?
Click to expand...

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.

Kyunghwan Kim said:
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)?
Click to expand...

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.

Kyunghwan Kim said:
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?
Click to expand...

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! :)
 
K

Kyunghwan Kim

Registered
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!
 
C

colinkmorgan

Managing Director
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

Ed Panek

QA RA Small Med Dev Company
Leader
Super Moderator
Would we be able to use the risk analysis work we completed for GDPR as part of the evidence?
 
C

colinkmorgan

Managing Director
Ed Panek said:
Would we be able to use the risk analysis work we completed for GDPR as part of the evidence?
Click to expand...

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.
 
You must log in or register to reply here.
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
S Transitional Adolescent A and B - "CDRH PREMARKET REVIEW SUBMISSION COVER SHEET FORM FDA 3514" Medical Device and FDA Regulations and Standards News 1
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
Ed Panek Looking for help... FDA Pre Sub, IVD, Investigational level experience US Medical Device Regulations 0
U How should we build the FDA inspection preparedness team for FDA inspections at factories? General Auditing Discussions 0
D FDA combo product-need to define direct & indirect impact regarding safety,quality & regulatory.Can anyone point me in right direction-SupplierMgmt 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
B What is meant by "post production" if the device is yet to receive FDA approval? ISO 14971 - Medical Device Risk Management 5
B FDA Requirements for medical device to be used for training purposes only US Food and Drug Administration (FDA) 9
M Class III IVD PMA Amendment to FDA Medical Device and FDA Regulations and Standards News 1
L Verification of wireless QoS and coexistence during FDA certification of medical devices Medical Device and FDA Regulations and Standards News 1
W Notify FDA of Change of Ownership? US Food and Drug Administration (FDA) 2
G FDA requirements for risk analysis US Food and Drug Administration (FDA) 2
V Anyone have templates for FDA GMP Guidelines for supplement manufacturers? US Food and Drug Administration (FDA) 0
N FDA mechanical bench testing Manufacturing and Related Processes 5
V Regulatory consultants for US FDA ANDA - pharma / drug products Consultants and Consulting 0
M Clinical evaluation process of FDA and MDR Medical Device and FDA Regulations and Standards News 2
S Is it possible to obtain FDA clearance (510k) without meeting QSR? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
P Biocompatibility testing ISO-10993 for FDA submission Other Medical Device Related Standards 7
Ed Panek FDA Submission Question US Medical Device Regulations 3
Y The day after the FDA US Food and Drug Administration (FDA) 2
U FDA foreign inspection and COVID19 US Medical Device Regulations 4
Y Convenience pack FDA US Food and Drug Administration (FDA) 3
B FDA regulations medical device prescription fulfillment DME question US Medical Device Regulations 0
N FDA medical devices US Food and Drug Administration (FDA) 1
R US FDA 510k Australia TGA US Food and Drug Administration (FDA) 0
B How FDA define a new variant/generation or a new device US Medical Device Regulations 11
G FDA Annual Registration and Listing US Food and Drug Administration (FDA) 7
T Book Excerpt: Drugs and the FDA: Safety, Efficacy, and the Public’s Trust Book, Video, Blog and Web Site Reviews and Recommendations 0
E The FDA regulations (21 CFR 312.3): Is it allowable that IND sponsor involves more than one individual or organization? Pharmaceuticals (21 CFR Part 210, 21 CFR Part 211 and related Regulations) 0
P Looking for Korean FDA Drug Master File requirements for packaging systems. Other Medical Device and Orthopedic Related Topics 1
M IEC 62366 Hazard-related Use Scenario vs FDA Critical Task EU Medical Device Regulations 3
N Free sale and FDA US Food and Drug Administration (FDA) 1
N FDA class 1 US Food and Drug Administration (FDA) 6
G UDI in EU vs FDA EU Medical Device Regulations 1
S Initial Audit FDA US Medical Device Regulations 3
T FDA PMA review process - advisory panel timing? Other Medical Device and Orthopedic Related Topics 0
E FDA & Internal Audits US Medical Device Regulations 3
N Importing into US without 510K/FDA Clearance US Medical Device Regulations 1

Similar threads

Top Bottom