Software "Nonconformances"

[sagai]

Just an FYI, Hospital groups now require $5M in cybersecurity insurance. It used to be just $1M but ransoms are popular.

I know large, reputable med device company with class III devices on the market doing a lot for paperwork, but nothing useful for the design on cybersecurity.
Doing something that is also useful, would require a complete system redesign that I really do not know which meddev willing to take.

 

[colinkmorgan]

Here is a quick list of what should be done and planned for related to cybersecurity of a medical device:

• Cybersecurity Plan – document what you are going to be doing for cybersecurity for the device, what methodologies are going to be followed and if there are any industry standards you are aligning to
• Clear architecture and data flow diagrams – document all of the components in the device from network connections all the way down to I/O ports on a microcontroller. There also now needs to be multiple views showing the architecture during development and manufacturing (ensure malware wasn’t introduced to the product software from a developer’s laptop), operational use, service and support use and how the device receives updates and patches
• Threat model – for all of the components in the design, threats need to be evaluated to understand what could go wrong from a cybersecurity standpoint. Microsoft STRIDE is an example
• Security requirements – each threat should be traced to a specific system/software level cybersecurity requirement. In essence, there should be a traceability matrix of the threat to the requirement and details on how the requirement is being met. These requirements can also be tied to a higher-level user need statement, if necessary. Here is a quick example:
  • User Need – The product shall adequately protect data, including patient information, configuration files, settings, etc in storage and in transit
    • Requirement – The product shall be configured with AES256 – GCM mode encryption.
      • How is this met – Bitlocker is configured and running in the Windows OS
    • Requirement – The product shall be configured with TLS1.3 and the following cipher suites for data in transit
      • How is this met – API configuration that only TLS1.3 is enabled with the correct cipher suites
• Requirements Testing – these requirements need to be tested to verify they are implemented correctly and validated that they are functioning properly. What does that mean for cybersecurity?
  • Verify – show screenshots of configurations for Bitlocker; run a scanner to show the TLS settings on the device
  • Validate – perform penetration testing, vulnerability scanning, fuzz testing on the device and interfaces to show there are no vulnerabilities
• Other Security Testing – testing of all custom source code (SAST) and the software bill of materials (SCA) needs to be done, pen testing, fuzz testing, vuln scanning, web application, scanning, etc.
• Residual Cybersecurity Risk Assessment – all devices have residual cybersecurity risk and this needs to be documented and evaluated using something like CVSS. Risk that may impact patient safety, need to move over to FMEA/HHE
• Cybersecurity Report – report summarizing everything done, including key details on the secure architecture in place. This report also needs to include very detailed information on the post market cybersecurity management including what actions are being taken, who is responsible for them, the timeframes being followed and what the communication plans are for customers (it is recommended this information be contained in a SOP in the QMS and just copied/referred to in the report)
• Product Labeling – MDS2 form plus information in the IFU/Users guide is critical and this information needs to explain what was done for cybersecurity and where the responsibilities lie. E.g., who is responsible for deploying/installing security patches, setting up user accounts, etc

The list and expectations of regulators keeps growing as this space matures. The amount of information required and the follow up questions from the regulatory authority may differ based on the submission type (e.g., deNovo, 510K, PMA, etc)

Thanks,
Colin
Managing Director
Apraciti, LLC | Medical Device Cybersecurity
[email protected]

 

[Fadila19821982]

Dear Colin,
Thanks for the list; it's quit clear as medical device companies are not used to cybersecurity field.
I have a question please; we chalenge our system during cybersecurity audits and some vuleravbilties are recorded.
As Quality manager, how should I register them in our QMS? as non conformtities? improvements? Do you have any idea?
Thanks
Fadila

 

[Ronen E]

Dear Colin,
Thanks for the list; it's quit clear as medical device companies are not used to cybersecurity field.
I have a question please; we chalenge our system during cybersecurity audits and some vuleravbilties are recorded.
As Quality manager, how should I register them in our QMS? as non conformtities? improvements? Do you have any idea?
Thanks
Fadila

If there are clear cybersecurity requirements that have been specified, vulnerabilities (breaches?) can be counted as nonconformities, yes.
In my opinion a good place to document such audits/challenges and their outcomes it the software validation.

 

[yodon]

medical device companies are not used to cybersecurity field.

Sadly true.. and scary.

I don't think it matters much whether you record them as NCs or improvements. Getting them recorded and taking appropriate actions is the most important thing. I would lean towards not calling them NCs since we're on "shifting sand" (new vulnerabilities, new attack vectors that you couldn't have foreseen).

 

[colinkmorgan]

Hi Fadila,

If you are talking about an already approved and marketed medical device, then vulnerabilities need to be properly handled and there should be an SOP in your QMS that covers how you manage them. These are a few of the key activities that should be considered:

• Performing a cybersecurity risk assessment (CRA) on the identified vulnerabilities. This should be done using a common scoring system like the common vulnerability scoring system (CVSS) or the Healthcare CVSS Rubric created by MITRA (and recognized by FDA). One important note is that the FDA wants manufacturers to considered exploitability (how easy/hard is it to take advantage of the vulnerability) and NOT probability/likelihood.
• The outcome of the CRA should drive your actions for the vulnerability.
  • Low Risk – document and may be considered acceptable to remain.
  • Medium Risk – may require a patch or remediation during the next software release (could be a CAPA, Non-Conformance, Change Control, etc)
  • High Risk – should require a more immediate patch (could be a CAPA, Non-Conformance, Change Control, etc)
  • Safety Risk – the CRA should feed your fmea/hhe process to have certain cybersecurity risks (e.g. high cvss risks) evaluated for potential impact to patient safety. If there is potential impact to patient safety, then the US FDA Post Market Cybersecurity guidance should be followed in terms of notifying customers within 30 days of being aware of the risk and having a fix ready within 60 days

The CRA should be developed following a process in your QMS and the CRA should be part of your DHF and be a living document throughout the total-product-lifecycle.

Thanks,
Colin