Software in Medical Devices, by MD101 Consulting - Tag - IEC 81001-5-1Blog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearTemplates: Security Risk Management Plan and Security Risk Assessment Reporturn:md5:abc5bd7326231134c454fa05e34777a82024-03-08T13:47:00+01:002024-03-08T13:47:00+01:00MitchTemplatesCybersecurityFDAIEC 81001-5-1<p>Cybersecurity guidances and standards have quite evolved the last few months.<br>
It's time to push new templates!</p> <p>I updated the two templates for security risk management process: the <a href="https://blog.cm-dm.com/public/Templates/security-risk-management-plan-template-2024.doc">Security Risk Management Plan</a> and the <a href="https://blog.cm-dm.com/public/Templates/security-risk-assessment-report-template-2024.doc">Security Risk Assessment Report</a>.</p>
<p><strong>I gather all my templates on the <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">templates page</a>.</strong> You'll find them all there.</p>
<p>Please, feel free to give me feedback on my e-mail contact@cm-dm.com</p>
<p>I share this template with the conditions of <a href="https://blog.cm-dm.com/post/2011/11/04/License">CC-BY-NC-ND license</a>.</p>
<br />
<br />
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/3.0/fr/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/">Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License</a>.
https://blog.cm-dm.com/post/2024/03/08/Templates%3A-Security-Risk-Management-Plan-and-Security-Risk-Assessment-Report#comment-formhttps://blog.cm-dm.com/feed/atom/comments/280IEC 81001-5-1 Right Here Right Nowurn:md5:cd5939e387b1c296a2b7e100844c81082024-02-23T14:21:00+01:002024-03-04T12:46:45+01:00MitchStandardsCybersecurityIEC 81001-5-1<p>IEC 81001-5-1 is now the standard for cybersecurity in medical devices. But is this standard asking too much for?</p> <h4>Impact of the standard</h4>
<p>IEC 81001-5-1 requires to unroll a full set of cyber activities throughout the software life cycle and more precisely the software development lifecycle. This can represent quite an overhead, on top of existing IEC 62304 provisions.</p>
<h5>Cyber design</h5>
<p>Firstly, at design, the steps required by IEC 81001-5-1 supplement those of IEC 62304:<br>
<img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC-81001-5-1-secure-SDLC-tasks_m.png" alt="IEC-81001-5-1-secure-SDLC-tasks.png, Jul 2021" class="media-center" title="IEC-81001-5-1-secure-SDLC-tasks.png, Jul 2021">
<br>
A short list of artifacts includes (but not limited to…):</p>
<ul>
<li>A bunch of new documents or document sections on architecture, detailed design (or new sections in existing documents)</li>
<li>New design review criteria,</li>
<li>A cybersecurity risk management file (cyber risk management plan and cyber risk assessment report),</li>
<li>A software development platform (or a toolchain, name it as you prefer) with specific tools, which can lead to heavy license costs:
<ul>
<li>Static source code analysis,</li>
<li>software composition analysis,</li>
<li>fuzzers (e.g.: DICOM fuzzers for medical imaging),</li>
<li>black box common vulnerability scanning,</li>
<li>Dynamic Application Security Testing tools,</li>
<li>and some other specific to your software technology…</li>
</ul></li>
<li>The need to perform pen tests with an independent organization. That means paying for the services of such a gang of security consultants,</li>
</ul>
<h5>Cyber maintenance</h5>
<p>After software release, it adds the need to monitor cyber issues in post-market phase. And update the cybersecurity risk management file.<br>
<br>
It also requires to have people qualified in security: Security Advisor(s). A person, who takes this role, shall have appropriate evidence of qualification.
<br>
<br>
This list is only a subset of IEC 81001-5-1 provisions. Just to demonstrate the magnitude of the overhead. Practically speaking, IEC 81001-5-1 can be seen as a “second IEC 62304” in terms on work effort.<br>
<br>
<strong>Do you remember the effort it took to implement IEC 62304 for the first time in your processes?</strong><br>
<strong>IEC 81001-5-1 will represent the same level of effort!</strong><br>
<br></p>
<h4>FDA risk-based approach</h4>
<p>If we look at the US side, IEC 81001-5-1 is a recognized standard. It is also quoted as a possible Secure Product Development Framework (SPDF) in the <a href="https://blog.cm-dm.com/post/2023/10/06/Final-2023-FDA-Premarket-Cybersecurity-guidance-released">FDA guidance on cybersecurity premarket documentation</a>. More, this guidance describes activities and documentation deliverables very similar to IEC 81001-5-1 provisions.<br>
Thus, at first sight, IEC 81001-5-1 shall also be fully applied to generate cyber documents shipped in a 510(k) submission.<br>
<br>
However, the FDA accepts to apply a risk-based approach. If you can assert that your device:</p>
<ol>
<li>Has a low cyber risk profile, and</li>
<li>Cyber risk don’t lead to unacceptable safety risks,</li>
</ol>
<p>Then it is possible to reduce the documentation to an acceptable minimum.<br>
<br>
This shall be backed with:</p>
<ol>
<li>A documented threat model,</li>
<li>And, traceability between security risks and safety risks,</li>
</ol>
<p>Giving evidence that your device has actually a low cyber risk profile.<br>
<br>
That minimum set of documentation should include:</p>
<ul>
<li>A threat model,</li>
<li>A security risk management plan,</li>
<li>A security risk assessment report, with traceability to safety risks, when needed,</li>
<li>Secure software requirement specifications (including security risk control measures),</li>
<li>Test plans and reports with test cases covering these secure software requirements,</li>
<li>Independent pen test plan and report,</li>
<li>A Software Bill of Materials (SBOM),</li>
<li>Warnings on secure software use in the Instructions for use,</li>
<li>Secure operations guidelines in accompanying documentation (targeting end-users or people with a more technical background),</li>
<li>A post-production surveillance on SOUPS, and security issues coming from the field.</li>
</ul>
<p>The diagram below sums-up this course of action:
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/Medical_Device_Cyber_Crash_Action_Plan.png" title="Medical Device Cyber Crash Action Plan.png, Feb 2024"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.Medical_Device_Cyber_Crash_Action_Plan_m.png" alt="Medical Device Cyber Crash Action Plan.png, Feb 2024" class="media-center" title="Medical Device Cyber Crash Action Plan.png, Feb 2024"></a></p>
<p>Note that the above list is a return on experience on 510(k)’s submitted the last few years. But FDA thinking may change on these matters in the near future. Don’t blame this blog if this doesn’t work with your device! And rub twice your threat model to the latest threat landscape in healthcare!<br>
<br>
By the way, FDA's approach doesn't pop out of nowhere. <a href="https://www.congress.gov/bill/117th-congress/house-bill/2617/text">FD&C Act SEC. 524B</a> says that [Manufacturers shall] <em>design, develop, and maintain processes and procedures to provide a <strong>reasonable assurance</strong> that the device and related systems are cybersecure</em> (emphasis by me).
<br></p>
<h4>Transitional Health software</h4>
<p>It is worth noting that the FDA low risk profile approach described above is close to the Transitional Health software approach found in annex F of IEC 81001-5-1. <br>
This is depicted in the diagram below:<br>
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_81001-5-1_Transitional_Health_Software.png" title="IEC 81001-5-1 Transitional Health Software.png, Feb 2024"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_81001-5-1_Transitional_Health_Software_m.png" alt="IEC 81001-5-1 Transitional Health Software.png, Feb 2024" class="media-center" title="IEC 81001-5-1 Transitional Health Software.png, Feb 2024"></a>
<br>
Transitional Health Software is a kind of IEC-62304-class-A-ish secure SDLC. Tasks at architectural and detailed design are skipped. However, some architecture-level documentation, like Data Flow Diagrams, are helpers for a sound threat model. But not the whole architecture, required by the full IEC 81001-5-1.<br>
<br>
A major difference with FDA risk-based approach, however: transitional health software requires to implement the full secure software testing strategy found in 5.7 of IEC 81001-5-1. This testing strategy is per se quite an overhead!<br>
And a second difference: “transitional” means that you shall have plans to be fully compliant to IEC 81001-5-1 in a further release of your software.</p>
<h4>EU Notified Body binary approach</h4>
<p>Today, IEC 81001-5-1 is not harmonized. Yet, it is considered as state-of-the-art (see <a href="https://www.ig-nb.de/veroeffentlichungen">IG NB questionnaires on cybersecurity (fortunately in English)</a> and <a href="https://www.team-nb.org/wp-content/uploads/2022/10/Team-NB-PositionPaper-CyberSecurity-V1-20221005.pdf">TEAM-NB position paper on cybersecurity</a>).<br>
<br>
But:<br>
NB auditors are still at the bottom of a steep Everest-like learning curve. Being able to audit a QMS implementing IEC 81001-5-1 processes or evaluating cyber sections of technical files is still out of reach of (most of) NB personnel.<br>
That will change in the near future. For sure.<br>
<br>
That should (shall?) be the case in 2028, when IEC 81001-5-1 is harmonized.<br>
<br>
So, to sum-up Notified Body thinking:</p>
<ul>
<li>Today: Manufacturer, thou shalt apply MDCG 2019-16 and give me a bare minimum (anyway, I don’t have qualified personnel to audit more than that),</li>
<li>2028: Manufacturer, thou shalt apply IEC 81001-5-1. From Genesis to Apocalypse. Otherwise, you’re non-compliant to The Cyber Writings and I'll put you a major non-conformity.</li>
</ul>
<p>More: IEC 81001-5-1 quotes IEC/TR 60601-4-5 is its body text. For those of you who have experience with Notified Bodies, you know how it can be hard to disregard a document (be it a Tech Report), if it is quoted in a standard!<br>
Thus, be prepared to have a traceability matrix between IEC 60601-4-5 high-level requirements and your secure software requirements. An additional overhead, compared to the FDA approach. Btw, IEC 60601-4-5 isn't recognized.<br>
<br>
That will be the binary (stubborn, not risk-based, still regulatory oriented …) approach of Notified Bodies. Thus, you shall be fully compliant to IEC 81001-5-1 by 2028. Or your QMS and possibly your devices will be at regulatory risk.<br>
<br>
That will probably be the last epic of the MDR – IVDR transition for medical device software.</p>
<h4>Is IEC 81001-5-1 asking to much for?</h4>
<p>No matter the risk profile of your device (the security level, if you follow the recommendations of IEC 60601-4-5), IEC 81001-5-1 is fully applicable.<br>
<br>
The working group had in mind the following goals, when writing this standard:</p>
<ul>
<li>Weaknesses and vulnerabilities can be introduced at every step of the software lifecycle, and especially in the SDLC,</li>
<li>Thus, every step of this lifecycle shall contain provisions to identify, evaluate, and track to closure weaknesses and vulnerabilities,</li>
<li>This legitimate goal leads to a heavy secure SDLC, and more general to a heavy secure software lifecycle.</li>
</ul>
<p><br>
However, it can be called into question: is it necessary to apply all provisions for a low cyber risk profile device? Or is it possible to alleviate the burden in case of low cyber risk profile? And still claiming that we do our best effort, proportionate to the cyber risk profile?<br>
<br>
State-of-the-art says that software development rigor shall be commensurate to the software risk profile. That's why we have:</p>
<ul>
<li>Software safety class in IEC 62304,</li>
<li>Documentation levels (which replaced level of concern) in <a href="https://blog.cm-dm.com/post/2023/06/16/Final-FDA-guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">FDA guidance on premarket documentation for device software function</a>,</li>
<li>And, not official but practical, a risk-based approach accepted by the FDA provided that manufacturers's cyber documents give a reasonable assurance that the device is secure.</li>
</ul>
<p>Yet, cybersecurity cannot be something only tested at the end, being ignored during design.<br></p>
<h4>Proposition to update IEC 81001-5-1</h4>
<p>This state-of-the-art advocates for such risk-based approach applied in IEC 81001-5-1 normative clauses.<br>
<br>
Proposition:
To add to IEC 81001-5-1 a system similar to IEC 62304 software safety class, based on the Capability Security Level (SL-C) claimed by the manufacturer, from the Intended Context of Use.<br>
With:</p>
<ul>
<li>For SL-C 1 and 2: a lighter secure SDLC similar to the Transitional Health Software annex:
<ul>
<li>SDLC clauses 5.1, 5.2, 5.7.1, 5.7.2, 5.7.4 and 5.8 are applicable,</li>
<li>Clauses 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.7, 4.2, 6, 7, 8, and 9 are applicable,</li>
<li>Other clauses aren't applicable.</li>
</ul></li>
<li>For SL-C 3 and 4:
<ul>
<li>The full text.</li>
</ul></li>
</ul>
<p><br>
This would lead to an approach similar to IEC 62304 class B, or FDA Basic Documentation Level, for software in SL-C 1 or SL-C 2.<br>
<br>
<br>
Hope it helps...</p>https://blog.cm-dm.com/post/2024/02/23/IEC-81001-5-1-Right-Here-Right-Now#comment-formhttps://blog.cm-dm.com/feed/atom/comments/279Final 2023 FDA Premarket Cybersecurity guidance releasedurn:md5:eb954de98536ffc711a22831b88adf7e2023-10-06T14:09:00+02:002023-10-06T14:09:00+02:00MitchRegulationsCybersecurityFDAGuidanceIEC 81001-5-1risk management<p>The final version of the FDA guidance titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions was published the 27th September 2023.</p> <p>The draft had been issued in 2022, and had been subject to <a href="https://blog.cm-dm.com/post/2022/06/10/Cybersecurity-in-Medical-Devices%3A-Quality-System-Considerations-and-Content-of-Premarket-Submission">a review in this article</a>.<br />
<br />
Amongst a long list of minor changes, the final version contains the following majors changes in the body text:</p>
<ul>
<li>IEC 81001-5-1 is know referenced as a possible Secure Product Development Framework, this is good news for manufacturers selling their devices in EU and the USA,</li>
<li>AAMI TIR57 is recommended to document <em>the security risk management activities for a medical device system</em>. It's worth noting that <a href="https://blog.cm-dm.com/post/2023/09/08/AAMI-SW96-2023-The-keystone-of-security-risk-management-for-medical-devices">AAMI SW96</a> isn't mentioned (yet),</li>
<li>The above bullet is found in a new section V.A.2. Cybersecurity Risk Assessment. Its content is broadly aligned with AAMI SW96,</li>
<li>A new section V.A.3 on <em>Interoperability considerations</em>. In short, security controls are required when exchanging information with other software or devices (MD or non-MD),</li>
<li>Manufacturers should provide SBOM in machine readable format, something which is going to be made systematic for all software in the US in the coming years,</li>
</ul>
<p>And the last major change is the Appendix 4 <em>General Premarket Submission Documentation Elements and Scaling with Risk</em>.<br />
It summarizes in table 1 the documentation expected by the FDA in premarket submissions. The documentation should scale with the cyber risks of your devices.<br />
<br />
Of course, we find the usual guidance warning: <em>This table is not intended to serve as merely a deliverable checklist</em>.<br />
But, gosh, yes, you are going to use it as a checklist. I am going to use it as a checklist. FDA reviewers are going to use it as a checklist!<br />
<br />
<br />
All in all, the message delivered by the FDA in this final guidance doesn’t change, compared to the draft version. Cybersecurity shall be taken seriously.<br />
<br />
Prepare your security risk management files, your secure SDLC documents and your cyber PMS!</p>https://blog.cm-dm.com/post/2023/10/06/Final-2023-FDA-Premarket-Cybersecurity-guidance-released#comment-formhttps://blog.cm-dm.com/feed/atom/comments/277Maintained software, Supported software, Required software, and SOUPurn:md5:bbb5f84c6e4f1aeff52ccfaedd569c522023-02-20T13:56:00+01:002023-02-26T00:56:03+01:00MitchStandardsCybersecurityIEC 62304IEC 81001-5-1SOUP<p>These three concepts come from IEC 62443 and were adopted in IEC 80001-5-1. SOUP isn't present in IEC 81001-5-1.<br />
What are the differences between SOUP and Maintained software, Supported software, and Required software?</p> <h4>Definitions</h4>
<p>You will find the definitions of SOUP in IEC 62304 and Maintained software, Supported software, Required software in IEC 81001-5-1:</p>
<ul>
<li><em>SOUP</em>: software of unknown provenance. Practically speaking, if you want to integrate some 3rd party sw in your medical device, that hasn't been developed with IEC 62304, that's SOUP,</li>
<li><em>Maintained software</em>: software item for which the manufacturer will assume the risk related to security,</li>
<li><em>Supported software</em>: software item for which the manufacturer will notify the customer regarding known risks related to security,</li>
<li><em>Required software</em>: software item for which the manufacturer will consider security-related risks known before release of the health software.</li>
</ul>
<h4>Required software</h4>
<p>The case of required software is easy to manage with medical device software. The definition tells us that the <em>manufacturer will consider security-related risks known before release of the health software</em>. Thus, not after release of the health software.<br />
That contradicts ISO 14971 requirement on post-production activities and more generally requirements on post-market surveillance of regulations.<br />
Thus, that's not possible to have required software in medical devices.<br />
That's possible to have required software in health software not qualified as medical devices, but this is another story outside the scope of this blog.</p>
<h4>Supported software</h4>
<p>With supported software, <em>the manufacturer [notifies] the customer regarding known risks related to security</em>. That's a way to manage risks, so that's possible to do so with ISO 14971 and MD regulations. Provided that risks are acceptable, doing it that way.<br />
Practically speaking, if we only notify about risks, that means that supported software isn't integrated into the medical device. If it were integrated in the medical device, we'd not only notify but also provide the customer with a new version of our software.</p>
<h4>Maintained software</h4>
<p>With maintained software, <em>the manufacturer [assumes] the risk related to security</em>. That's the only way to manage risks when some software is integrated into the medical device.<br />
We retrieve here a similarity between our plain old SOUP and maintained software! With SOUP integrated in our medical device software, we have to assume the risks in the design process (IEC 62304 clause 7.1) and in the maintenance process (IEC 62304 clause 6.1).<br />
Practically speaking, when some issue (bug or vulnerability) is found in a SOUP in design, we fix it. When it is found in maintenance, we fix it (usually upgrading SOUP version and rebuilding software) and we release a new version of our software.<br />
<br />
Maintained software could be expanded to software not integrated into the medical device, thus not SOUP. That's a possibility. We could sum up that by SOUP ≤ Maintained software.<br />
But, if we want to keep things simple, we can consider that the two concepts are applicable to the same set. We could sum up that by SOUP = Maintained software.<br /></p>
<h4>Some examples</h4>
<p>The sketch of theory above deserves some examples.</p>
<h5>Mobile app or PC application</h5>
<p>All 3rd party libraries (not developed and maintained according to IEC 62304) linked to these kind of apps at build time are SOUP and maintained software.<br />
The operating system (PC platform or mobile platform) is a supported software.<br />
We cannot place the OS in required software. If we become aware of some unacceptable risk coming from the OS, we would notify the customer.<br />
Conversely, the operating system is not maintained software. We don't update it, we only notify the customer to update their OS.</p>
<h5>Software embedded in hardware medical device</h5>
<p>Once again, all 3rd party libraries (not developed and maintained according to IEC 62304) linked to our embedded binary at build time are SOUP and maintained software.<br />
The operating system (PC platform or mobile platform) is also a maintained software. If we become aware of some unacceptable risk coming from the OS, we would provide the customer with a new version of our embedded software (logistics can be tricky, but that doesn't affect the concept) with a new OS version.<br /></p>
<h5>Web application - front</h5>
<p>All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.<br />
The operating system (PC platform or mobile platform) and the browser are supported software. We cannot place them in required software. If we become aware of some unacceptable risk coming from the OS or the browser, we would notify the customer.<br /></p>
<h5>Web application - back-end, and cloud software</h5>
<p>All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.<br />
Here, we have a question about where we draw the line between SOUP and not SOUP. See the article <a href="https://blog.cm-dm.com/post/2021/03/26/When-Web-meets-SOUP">When web meets SOUP</a> about the possible answers on SOUP, OTSS, which is not SOUP, and infrastructure.<br />
We have to place the OTSS and underlying infrastructure (be it containerization or virtualization) in maintained software. We cannot place them neither in required software, nor in supported software. If we become aware of some unacceptable risk coming from one of these, we would upgrade the infrastructure version.</p>
<h5>Two software devices by two different manufacturers</h5>
<p>Let's assume we develop and maintain a medical device software, which integrates another medical device software developed by another manufacturer.<br />
Here the 3rd party software is a medical device (we assume that the manufacturer did their homework with IEC 62304), thus not a SOUP. If that other manufacturer becomes aware of some issue, they will notify us and provide us with a software update (as per IEC 62304 clause 6.1). Likewise we will update our software with this dependency update. Thus, that other medical device software is for us a maintained software.<br />
That's a peculiar case where maintained software ≠ SOUP. It is shown in this article to demonstrate that maintained software and SOUP are different concepts. But, to keep it simple, in the vast majority of cases, maintained software = SOUP.</p>
<h4>Conclusion</h4>
<p>One interesting consequence of new definitions brought by IEC 81001-5-1 is to help us understanding wether to place 3rd party software in SOUP or not in SOUP. It's frequent that design teams hesitate to place an OS in SOUP. The concepts of maintained software and supported software, are not equivalent to SOUP (the word <em>incorporated</em> appears in SOUP definition, not in required / supported / maintained software definitions). But, if we simplify by assuming that maintained software = SOUP, then we have criteria to place OS, and some other borderline cases, in SOUP or not.</p>https://blog.cm-dm.com/post/2023/02/20/Maintained-software%2C-Supported-software%2C-Required-software%2C-and-SOUP#comment-formhttps://blog.cm-dm.com/feed/atom/comments/248