Software in Medical Devices, by MD101 Consulting - Tag - CybersecurityBlog 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/248IEC 81001-5-1 was added to the list of recognized consensus standardsurn:md5:4c57c909d26dd3748dc55cdd5dff60ef2023-01-09T15:31:00+01:002023-01-09T17:49:15+01:00MitchRegulationsCybersecurityFDA <p>The FDA added late December 2022 IEC 81001-5-1 to the list of recognized consensus standards.<br />
That's it. After beating around the bush on this blog on whether UL 2900-x or IEC 81001-5-1 would be applicable to 510(k) submissions and other regulatory clearances, we now have the answer.<br />
<br />
We can use IEC 81001-5-1 as:</p>
<ul>
<li>A Secure Product Development Framework according 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">the latest draft FDA guidance on cybersecurity</a>,</li>
<li>A <a href="https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5">method of answer to GSPR on cybersecurity</a> of EU MDR and IVDR.</li>
</ul>
<p>A good way to make thing (a bit) more simple.<br />
<br />
Remark: UL 2900-x can still be applied in the US!</p>https://blog.cm-dm.com/post/2023/01/09/IEC-81001-5-1-was-added-to-the-list-of-recognized-consensus-standards#comment-formhttps://blog.cm-dm.com/feed/atom/comments/271NIS2 Directive: are you involved or concerned?urn:md5:19b7f5ddba4cf0ace27fb1bb8d1262942022-09-30T14:01:00+02:002022-12-28T21:49:23+01:00MitchRegulationsCE MarkCybersecurity<p>That’s the story of the pig and the hen for breakfast: the pig is involved (ham) and the hen is concerned (eggs). With the NIS2 directive in preparation, a medical device manufacturer will be in either situation.<br /></p> <p>A <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2020:823:FIN">proposal for the NIS2 directive</a> has been published in December 2020. Its goal is <em>ensuring a high level of cybersecurity within the Union</em>. Like any other regulation, it brings its own constraints and overhead to targeted organizations. Fortunately, it is not applicable to micro or small entreprises. However, some additional criteria exist. Let’s see how medical device manufacturers are involved or concerned.</p>
<h4>NIS directive and NIS2 directive</h4>
<p>By the way, subject matter experts call it the NIS2 directive. Its real official name is the <em>directive on measures for a high common level of cybersecurity across the Union</em>. It will replace the <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.194.01.0001.01.ENG&toc=OJ:L:2016:194:TOC">Directive on security of network and information systems</a> (aka NIS directive, <a href="https://blog.cm-dm.com/post/2016/10/24/Cybersecurity-in-medical-devices-Part-1-Regulations">mentioned on this blog 6 years ago</a>) in force since 2016. NIS2 is used as a nickname, reminder of the replacement of the NIS directive.</p>
<h4>Essential Entities and Important Entities</h4>
<p>The NIS2 directive defines two types of entities:</p>
<ul>
<li><strong>Essential Entities</strong>: Medical Device manufacturers of critical medical devices, according to Annex I of the NIS2 directive. The annex references the regulation on European Medicines Agency in crisis preparedness. It is in draft state, and defines what “critical” medical devices are,</li>
<li><strong>Important Entities</strong>: All medical device manufacturers, according to annex II of the NIS2 directive.</li>
</ul>
<p>We can conclude that all medical device manufacturers, other than small businesses, are at least in the scope of the NIS2 directive and categorized as Important Entities.<br />
<br />
However, some other criteria exist at article 2. Like if the manufacturer is the sole provider of a service in the EU or if it is of importance at regional or national level. Especially, the NIS2 directive references yet another regulation in preparation, the Resilience and critical entities directive, which defines a list of critical entities.<br />
<br />
If a manufacturer matches one of these criteria at article 2, it can be an Essential Entity or Important Entity. Small business or not.<br />
<br />
Examples of medical devices manufacturers, that could be in scope of the NIS2 Directive:</p>
<ul>
<li>A manufacturer of telehealth / teleradiology solution when their software is deployed at regional or national level (criteria at article 2),</li>
<li>A manufacturer of patient file management software, not a medical device but usually editors of such software have medical devices in their product portfolio, when their software is deployed at regional or national level (criteria at article 2),</li>
<li>A manufacturer of a cloud-based SaMD with a large user base, where a potential disruption of the service provided by the entity could have an impact on public safety (criteria at article 2),</li>
<li>A manufacturer of ventilators used to cure patients with covid-19, probably in the future list of critical devices of the EMA crisis preparedness regulation (criteria at annex I),</li>
<li>Another manufacturer of medical devices, not small business (criteria at annex II).</li>
</ul>
<p>To sum-up: to know if a manufacturer is an Essential Entity, or Important Entity, or none of these, it is necessary to read three documents:</p>
<ul>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2020:823:FIN">NIS2 directive</a>, with criteria defined at article 2,</li>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A52020PC0725">EMA crisis preparedness regulation</a>, referenced in annex I of the NIS2 directive,</li>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52020PC0829">Resilience of critical entities directive</a>, referenced in article 2 of the NIS2 directive.</li>
</ul>
<p>Piece of cake! Isn’t it?<br />
<br />
One important thing: The list of entities matching the criteria found in article 2 will be established by Member States. Thus, small businesses won’t decide by themselves if they match these criteria. Such list isn’t defined on the back of an envelope. Member States will need to collaborate with presumed entities to establish the list. Such entities will know well in advance that they will be in the list!<br />
This is also the case for the list of critical entities according to the EMA crisis preparedness regulation and the Resilience of critical entities directive.<br /></p>
<h4>You are Involved!</h4>
<p>If your company is in the scope of the NIS2 directive, you are involved. Essential Entity or Important Entity, you have to establish (article 1):</p>
<ul>
<li>A cybersecurity risk management process,</li>
<li>A reporting process,</li>
<li>An information sharing process.</li>
</ul>
<p>Article 18 defines the requirements on <em>Cybersecurity risk management measures</em>. Article 20, the <em>Reporting obligations</em>, and article 26 the <em>Cybersecurity information sharing arrangements</em>.<br />
<br />
To do so, technical specifications or methodological specifications can be adopted by the European Commission. The European Union Agency for Cybersecurity (<a href="https://www.enisa.europa.eu">ENISA</a>) can also publish guidelines. There is no mention of harmonized standards, though. Only a requirement for Member States to encourage the use of international or European standards. (articles 18 and 22).<br />
<br />
This is going to consume a significant part of enterprises resources. It is wise to put non-critical small businesses out of scope!<br />
These processes will be monitored by a Competent Authority, at Member State level. Obviously, different from the Competent Authority for MD/IVD. I don’t explain further the network of agencies in charge of cybersecurity and crisis management (ENISA, <a href="https://csirtsnetwork.eu" title="CSIRTS Network">CSIRT</a>, <a href="https://www.enisa.europa.eu/news/enisa-news/blue-olex-2020-the-european-union-member-states-launch-the-cyber-crisis-liaison-organisation-network-cyclone">CyCLONe</a>…).<br />
<br />
It is important to note that the NIS2 directive has an impact on entities’ organization. The most straightforward (and expensive) compliance pathway is an Information Security Management System (ISMS) implemented according to ISO 27001.<br />
<br />
MDR and IVDR target products with ISO 13485 and ISO 14971 (plus cybersecurity harmonized / recognized standards).<br />
Thus, a solution for MD manufacturers in the scope of the NIS2 directive could be to have an integrated QMS, compliant to ISO 27001 and ISO 13845.</p>
<h4>Difference between Essential Entities and Important Entities</h4>
<p>Accustomed to MDR/IVDR rules, we can see Important Entities a bit like class I, and Essential Entities as Class II+. This is visible in articles 29 and 30, about supervision of Essential Entities and Important Entities, respectively.<br />
<br />
Essential Entities are subject to <em>regular audits</em> and <em>random checks</em> (sort of unannounced audits). Important Entities can be subject to <em>ex-post</em> inspection by Competent Authorities, after a cyber adverse event occurred. No regular audit, then.<br />
<br />
The NIS2 directive also leaves the possibility to impose certification schemes to Essential Entities and Important Entities (article 21). Hello ISO 27001! Hello, also, future <a href="https://www.enisa.europa.eu/topics/standards/certification">certification schemes</a> that ENISA could elaborate or adopt.<br />
Curiously, the suspension of certification is a sanction only present for Essential Entities.</p>
<h4>You are Concerned!</h4>
<p>Even though a company doesn’t match any criteria of article 2 and isn’t in the scope of the NIS2 directive, it can be impacted by the supply chain. As a manufacturer, you are in the supply chain of healthcare providers, which <ins>will</ins> be essential or important entities, according to article 2. Keep reading, you are concerned!<br />
<br />
Article 18 requires to implement cybersecurity risk management measures in the <em>supply chain security including security-related aspects concerning the relationships between each entity and its suppliers or service providers</em>.<br />
Thus, as a medical device manufacturer, hardware, or software, or software as a service, we have to implement such measures, either in the QMS (for non-active devices), or in the QMS and the devices (for active devices). MDR CE marked devices shall already be compliant to general requirements at annex I of MD / IVDR.<br />
<br />
Article 18 also requires to implement <em>policies and procedures (testing and auditing) to assess the effectiveness of cybersecurity risk management measures</em>.<br />
It means that our clients, who are happy to be Essential or Important Entities, will audit our QMS and/or our products. They will verify that cybersecurity provisions in the QMS and in the device design and post-market are appropriate.<br />
<br />
Last, article 18 adds <em>entities shall take into account the vulnerabilities specific to each supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures</em>.<br />
Cherry on the cake, client’s audits will take into account vulnerabilities in products and the secure development process, like the one described in IEC 81001-5-1.<br />
<br />
That’s a bit like a sterilization service supplier, who is audited by its clients. As a supplier of devices or ICT services considered as critical by your clients, you will be audited by your clients. Of course, with auditors qualified in cybersecurity management.<br />
<br />
Here are some examples:</p>
<ul>
<li>A hospital, registered as Essential Entity, could audit their hardware MD suppliers, when these MD are considered as critical devices for patient care,</li>
<li>A big pharma company, registered as Essential Entity, could audit their suppliers of companion apps (qualified as SaMDs), when these companions apps deliver a service considered as critical for patient management,</li>
<li>A medical imaging manufacturer, registered as Important Entity, could audit their suppliers of medical imaging libraries (themselves MD or not), when these libraires are considered as a critical part of the integrated system.</li>
</ul>
<p>So, we are concerned!</p>
<h4>Consumer electronics is not left apart</h4>
<p>A last proposal for regulation as been issued in September 2022. This is the <a href="https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=COM:2022:454:FIN">Regulation on horizontal cybersecurity requirements for products with digital elements</a>. Its scope is <em>products with digital elements</em>. It excludes MD and IVD who are already regulated by the MDR and IVDR.<br />
However, the Annex I of this proposal contains a list of general requirements. It's worth reading them, to see what detailed requirements on cybersecurity could be for medical devices!<br />
<br />
We see with this last proposal for regulation that the EU takes cybersecurity seriously, by putting some pressure on all electronic devices.<br /></p>
<h4>And the MDR?</h4>
<p>Let's end with the running-gag of 2022 on this blog: some MDR-bashing!<br />
<br />
As of today, the MDR is a dead-end. It drains all the energies of medical devices manufacturers towards poorly useful QMS updates, technical files updates, and endless Notified Bodies reviews.<br />
<br />
But the geopolitical landscape has changed. Cybersecurity is a real concern. Probably a concern stronger than the safety and performance of medical devices.<br />
<br />
Practically speaking, I feel like I'm doing something useful when I work on securing the design of medical devices. And I feel like I'm doing something useless (even sometimes pointless), when I work on filling some heavy MDR technical file template.<br />
Fortunately, this is only sometimes true for new devices. Unfortunately, this is always true for legacy devices transitioning to the MDR.<br />
What a waste of manufacturers' resources!<br />
<br />
The MDR should be updated to alleviate the burden on MD manufacturers. Their resources shall be set in order of battle to strengthen the security of their products and processes. This is the purpose of a directive like NIS2. We’ve seen that it requires a lot of resources to do it right.<br />
<br />
<strong>We shall not fight the wrong battle: more Cyber, less MDR</strong><br />
<br />
<br />
<strong>Edit 2022/12/28</strong>: <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555">the NIS2 directive, named Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union </a> has been published the 2022/12/27. It shall be transposed in National law no later than September 2024. Articles of the draft version discussed above were shifted by 3 digits in the final version. E.g.: article 18 is now article 21.</p>https://blog.cm-dm.com/post/2022/09/30/NIS2-Directive%3A-are-you-involved-or-concerned#comment-formhttps://blog.cm-dm.com/feed/atom/comments/264Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissionurn:md5:b7a004729ef3260a2ab492e9093127b12022-06-10T13:47:00+02:002022-08-31T08:43:49+02:00MitchRegulationsCybersecurityFDAGuidanceIEC 62304<p>The FDA issued in April a new draft guidance on <em>Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions</em>. This guidance will supersede the guidance on <em>Content of Premarket Submissions for Management of Cybersecurity in Medical Devices</em> of 2014, when it is finalized. There’s no word about the draft guidance of 2018. We can suppose that one is obsolete.</p> <p>This is a long guidance, like every FDA guidance, you’d say. However, every word counts. This guidance is 45 pages long and contains 40 pages of recommendations in every other paragraph. That makes a lot of recommendations. A hell lot of recommendations.<br />
(Translation for beginners: recommendations = requirements, unless you’re feel wiser than the FDA to overlook these recommendations).<br />
<br />
These recommendations are very precise and were obviously written by cybersecurity experts, making this guidance of a quite high technical level. Meaning that you’ll need people qualified enough to understand these recommendations. That was not exactly the case with the previous guidance, where software design teams could evade the issue.<br />
<br />
If you want to implement this guidance the right way, you’d better take every recommendation seriously. A good option is to put the paragraphs of the guidance in a traceability table to your QMS procedures / instructions, DHF / DMR / DHR and 510(k) templates. Needless to say, it will take a hell lot of man-hours to implement it seriously.</p>
<h4>Secure Product Development Framework (SPDF)</h4>
<p>The keyword of this guidance is: SPDF. The FDA gives this definition: <em>An SPDF is a set of processes that reduce the number and severity of vulnerabilities in products throughout the device lifecycle.</em><br />
In short, a manufacturer has to integrate cybersecurity provisions in the QMS procedures covering the software lifecycle. E.g.: Software risk management, design, V&V, installation, support, maintenance, decommission. The SPDF also spreads its branches to customer complaints, and CAPA. The procedures generate cybersecurity documentation output recorded in the DHF, DMR, and DHR, as well as premarket submissions like section 16 of a 510(k) file.<br />
To do so, the FDA relies on the National Institute of Standards and Technology Framework Cybersecurity Framework (NIST CSF) and the Medical Device and Health IT Joint Security Plan (JSP). Both have the virtue to be freely accessible. This way, the FDA respects the basic cybersecurity principle to have free access to relevant cybersecurity information.</p>
<h5>Security risk management process</h5>
<p>Among all topics addressed by the guidance, the security risk management is probably the first one to implement. Relying of the AAMI TIR 57, the FDA recommends to conduct and document a security risk management file separated from the safety risk management file. Note that documents shall be separated, but not the safety and security risk management processes. Those two processes interact one another.<br />
<br />
There are also quite good discussions about Security Assessment of Unresolved Anomalies and TPLC Security Risk Management. E.g.: the magnitude of effects of unresolved anomalies in terms of security can be far higher than safety.</p>
<h5>Security architecture</h5>
<p>The draft guidance is prescriptive about what it expects in terms of documentation about security architecture. It recommends to document 4 specific types of architectural views:</p>
<ul>
<li>Global System View</li>
<li>Multi-Patient Harm View;</li>
<li>Updateability/Patchability View; and</li>
<li>Security Use Case View(s)</li>
</ul>
<p>It also recommends to document traceability between the elements found in these views and security requirements.<br />
<br />
That confirms the <a href="https://blog.cm-dm.com/post/2021/12/06/FDA-Draft-Guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">exit of Low Level of Concern / IEC 62034 class A documentation</a>.</p>
<h4>Link with European harmonized standards.</h4>
<p>Fortunately, the guidance also quotes the ISA 62443-4-1 standard as a possible framework to implement cybersecurity provisions throughout the SW life cycle.</p>
<h5>IEC 81001-5-1</h5>
<p>This allows us to bridge this draft guidance with <a href="https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5">the future European Harmonized standard: IEC 81001-5-1</a>. That standard actually stems from ISA 62443-4-1 and its structure is similar to the one of IEC 62304. Thus, IEC 81001-5-1 defines a SPDF over the software lifecycle framework of IEC 62304.<br />
That makes possible to have procedures encompassing both this FDA guidance and the EU harmonized standard at the same time. Especially, the section V.C Cybersecurity Testing defines a testing strategy very similar to IEC 81001-5-1.<br />
But some gaps remain. The draft guidance goes further than the standard on some subjects like architecture documentation, and vice-versa in IEC 81001-5-1, like secure software documentation acceptance criteria and reviews.</p>
<h5>IEC 60601-4-5</h5>
<p>The draft guidance doesn’t quote neither ISA 62443-4-2, nor IEC 60601-4-5. They’re not recognized standards. So that’s not surprising.<br />
Alternatively, the draft guidance contains a section V.B.1 <em>Implementation of security controls</em> and Appendix 1 on <em>Security Control Categories and Associated Recommendations</em>. We retrieve in this appendix a content roughly similar to ISA 62443-4-2. But in a more condensed manner. This content is also focused on medical devices, whereas the ISA standard comes from another industry.<br />
<br />
On the labeling side, IEC 60601-4-5 defines in clause 6 <em>Technical Description</em> a long list of information to communicate to users. The draft guidance does the same in the section A Labeling Recommendations for Devices with Cybersecurity Risk. Beware of the possible gaps between the two.<br />
<br />
We can wonder why neither ISA 62443-4-2, nor IEC 60601-4-5 are recognized standards. It's true that these two standards are applicable to medical devices with some drawbacks:</p>
<ul>
<li>IEC 60601-4-5 cannot be used without ISA 62443-4-2,</li>
<li>ISA 62443-4-2 itself references ISA 62443-3-3, the latter is needed to fully understand some security requirements,</li>
<li>The wording of ISA 62443-4-2 is oriented to industrial systems. This makes necessary a clumsy interpretation of its requirements body text to apply them to medical devices.</li>
</ul>
<p>I don't have the true reason with the FDA doesn't recognize these two standards. But these drawbacks are enough to explain the situation.</p>
<h4>And UL 2900-x?</h4>
<p>UL 2900-x are recognized standards. However, the draft guidance quotes them only in a footnote: <em>The following standards may partially meet the security testing recommendations in ANSI/UL 2900 Software Cybersecurity for Network-Connectable Products (...)</em>.<br />
The draft guidance just reserves a small folding seat to UL 2900. ISA 62443-4-1 takes the lion's share, quoted twice in the guidance. Especially in introduction to section V: <em>Frameworks from other sectors may also comply with the QSR, like the framework provided in ANSI/ISA 62443-4-1 (...)</em>.<br />
UL 2900 was in 2017 the first recognized standard about cybersecurity. It has been the reference about cybersecurity since them. The draft guidance changes the situation and fosters more the use of ISA 62443-4-1. UL 2900 is reduced to testing recommendations.<br />
<br /></p>
<h4>Conclusion</h4>
<p>Recognized standards or not recognized standards, this draft guidance open the Pandora's box to an SPDF. It will require a hell lot of work to be implemented in a correct manner. Prepare your Secure Software Design procedure, your Security Risk Management procedure, and all their siblings!</p>https://blog.cm-dm.com/post/2022/06/10/Cybersecurity-in-Medical-Devices%3A-Quality-System-Considerations-and-Content-of-Premarket-Submission#comment-formhttps://blog.cm-dm.com/feed/atom/comments/260IEC 81001-5-1, final version publishedurn:md5:2a3a188f567acb9d40816ab054c4962f2022-01-13T13:54:00+01:002022-01-13T13:54:00+01:00MitchStandardsCybersecurity <p>IEC 81001-5-1 was published in December 2021. We already talked about the draft version <a href="https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5">here</a>. Combined with IEC/TR 60601-4-5, published in February 2021, these two standards constitute the state of the art in cybersecurity of medical devices in Europe.<br />
<br />
The final version is very close to the draft version, apart from a few changes to the organizational requirements; formerly clause 10 present in the draft, but removed and copied to clause 4 in the final version.<br />
<br />
Be prepared to apply these two standards for your MDR CE Mark submissions, when they are harmonized. <a href="https://ec.europa.eu/growth/tools-databases/mandates/index.cfm?fuseaction=search.detail&id=599#">Most probably by 2024</a>.</p>https://blog.cm-dm.com/post/2022/01/13/IEC-81001-5-1%2C-final-version-published#comment-formhttps://blog.cm-dm.com/feed/atom/comments/253Cybersecurity standards: IEC 81001-5-1 and IEC/TR 60601-4-5urn:md5:d278dc91a1fdba4f51fda7d62aa5bdbf2021-07-09T13:37:00+02:002021-07-15T08:17:50+02:00MitchStandardsCybersecurity<p>The <a href="https://ec.europa.eu/growth/tools-databases/mandates/index.cfm?fuseaction=search.detail&id=599#">draft list of harmonized standards for the MDR regulation</a> was published in May 2021. In this document, we find the references to the following cybersecurity standards:</p>
<ul>
<li>IEC 80001-1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software - Part 1: Application of risk management,</li>
<li>IEC 81001-5-1 (not published): Health Software and health IT systems safety, effectiveness and security - Part 5-1: Security - Activities in the product lifecycle,</li>
<li>IEC/TR 60601-4-5: Medical electrical equipment - Part 4-5: Guidance and interpretation - Safety-related technical security specifications.</li>
</ul> <p>The date of adoption of these standards is set to May 2024 in this standardization request, which contains the list of harmonized standards for the MDR and IVDR.<br />
I put deliberately apart the IEC 80001-1, it deals with network security. In this post we focus on the two other standards, which deal with software design and maintenance. <br />
<br />
Standardization request with draft standards, this sounds far from being applicable. But if you’re a manufacturer of AIMD or electromedical devices, the lifecycle of your devices streches on several years. MD design can take ages! Thus, it’s worth having a look at these drafts, to see what the Notified Bodies’ expectations will be in 2024. So, for the next generation of your devices being currently designed.<br />
<br />
Given the design cycle of a MD, it is recommended that manufacturers designing connected devices look closely at these two standards, even if IEC 81001-5-1 is in draft status. Furthermore, there is no doubt that these standards will be recognized by the FDA. The secretary of the working group is in the US, suggesting that the FDA is in the loop.</p>
<h4>Impact on the design process of connected MDs</h4>
<p>IEC 81001-1-5: its title and structure are borrowed from IEC 62304. It is made for ease of reading by teams experienced in MD software design, but with poor or no experience in secure software lifecycle. IEC 81001-5-1 complements IEC 62304 with tasks related to cyber security.<br />
<br />
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC-81001-5-1-secure-SDLC-tasks.png" title="IEC 81001-5-1-secure SDLC tasks.png, Jul 2021"><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" style="display:table; margin:0 auto;" title="IEC 81001-5-1 secure SDLC tasks.png, Jul 2021" /></a>
<br />
IEC/TR 60601-4-5 defines a list of security requirements to be injected in your Hardware Requirement Specification (HRS), Software Requirement Specification (SRS), and accompanying documents.<br />
Here is an example of security requirements:<br />
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_60601-4-5-requirement-example.png" title="IEC/TR 60601-4-5 requirement-example.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_60601-4-5-requirement-example_m.png" alt="IEC/TR 60601-4-5 requirement example.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC/TR 60601-4-5 requirement example.png, Jul 2021" /></a>
<br />
These two standards work together. The first one defines secure software processes (the “how to”), the second the software security requirements (the “what”).</p>
<h4>Where do these two standards come from?</h4>
<p>Cybersecurity has been a concern for a long time is other industries, which were subject to digitization and interconnection earlier than healthcare. In our case, these two standards are a transposition of two standards named IEC 62443-4-1 and IEC 62443-4-2 for Industrial Automation and Control Systems (IACS).<br />
<br />
Why standards from IACS and not ISO 2700X, or other references coming from banking and finance (a sector where cybersecurity is a high concern)?<br />
Because IACS networks and HIS networks have strong similarities.<br />
<br />
Here is a copy of a diagram from IEC/TR 60601-4-5:<br />
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC-60601-4-5-entreprise-zone-conduits.png" title="IEC/TR 60601-4-5 entreprise zone conduits.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC-60601-4-5-entreprise-zone-conduits_m.png" alt="IEC/TR 60601-4-5 entreprise zone conduits.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC/TR 60601-4-5 entreprise zone conduits.png, Jul 2021" /></a>
We have an industrial firm with:</p>
<ul>
<li>Headquarters or administration offices,</li>
<li>Production plants,</li>
<li>production lines with machines and PLCs</li>
</ul>
<p>Similarly, we can have a similar structure in an healthcare center, where we find:</p>
<ul>
<li>Administration managing patients ins & outs and patients’ data,</li>
<li>Patients rooms with near-bed medical devices, some of which may be life-critical,</li>
<li>Intensive care rooms and Operating rooms with life-critical medical devices.</li>
</ul>
<p>This similarity in the structure advocates for transposing the IACS cybersecurity standards to the medical device sector. It is worth noting that the FDA has the same approach, hence IEC 62443-4-1 is <a href="https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=42309">a FDA recognized standard</a>.<br />
<br />
Industries have to protect their personnel from injury with industrial machinery, their data from theft, their IT systems from breakdown and their production lines from costly production stops. Likewise, healthcare centers have to protect their patients, their personnel, patient data, their HIS from life-threatening hazards, and their healthcare services from costly shutoff.<br />
<br />
Note: ISO 2700X family remains relevant for datacenters storing data (especially health data) and containing data management services.</p>
<h4>Content of IEC 81001-5-1</h4>
<p>The table of contents IEC 81001-5-1 is copied from the one of IEC 62304, organized in processes. The 6 processes of IEC 62304 are illustrated in the diagram below.
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC-62304-sections.png" title="IEC 62304 sections.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC-62304-sections_m.png" alt="IEC 62304 sections.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC 62304 sections.png, Jul 2021" /></a>
<br />
Likewise, IEC 81001-5-1 defines security processes throughout the software lifecycle.
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_81001-5-1-sections.png" title="IEC 81001-5-1 sections.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_81001-5-1-sections_m.png" alt="IEC 81001-5-1 sections.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC 81001-5-1 sections.png, Jul 2021" /></a></p>
<h4>No software safety class</h4>
<p>It’s worth noting that there is <ins>no equivalent of software safety class</ins> in IEC 81001-5-1. It means that, contrary to IEC 62304, all requirements of IEC 81001-5-1 are applicable for any software whatsoever.<br />
E.g.: requirements on detailed design present in IEC 81001-5-1 are applicable even if your software is in class A with IEC 62304.<br />
<br />
Fortunately, even if documentation of detailed design is required by IEC 81001-5-1, it doesn't go as deep as IEC 62304 where all software units shall be 100% documented. IEC 81001-5-1 only requires documenting secure design and secure interfaces. That can be reduced to a subset of all software units.<br />
So, the effort of software design documentation with IEC 81001-5-1 is higher than simple IEC 62304 class A software, but not so different from what is required for IEC 62304 class B.<br />
<br />
Instead of software safety class, IEC 81001-5-1 recommends using the concepts of security level (SL) and security capabilities (SC) found in IEC/TR 60601-4-5, and discussed below.<br /></p>
<h5>Origin of weaknesses</h5>
<p>A principle of secure software lifecycle is that security weaknesses can be introduced in every step of the software lifecycle:</p>
<ul>
<li>specifications: wrong behavior specified,</li>
<li>architecture: unsecured architecture,</li>
<li>detailed design: unsecured interface detailed design,</li>
<li>coding: language traps or wrong coding patterns,</li>
<li>make / build: unsecured generated binary or bytecode,</li>
<li>install, configure: wrong installation or configuration.</li>
</ul>
<p>This is why IEC 81001-5-1 requires to document all the steps of the secure SDLC, disregarding the concept of software safety class. This is also why it covers the full software lifecycle, like IEC 62304.</p>
<h4>Content of IEC/TR 60601-4-5</h4>
<p>I don't know what effect it has on you, but when I see a standard number with 60601 in it, I frown!<br />
Does it mean that we'll need a certificate from a security lab? Fortunately not! Because this standard is named with <ins>TR</ins>, which stands for Technical Report.<br />
However, we see some offers on cybersecurity testing blossoming from IEC 60601-1 accredited test labs. So, a TR is not a standard, but we could come up to a situation where, despite the TR, a test report from accredited test labs may be requested by the notified bodies or the FDA.<br />
<br />
IEC 60601 series is not applicable to standalone software. But in this technical report, the introduction mentions that: <em>MEDICAL DEVICE SOFTWARE, although not in the scope of IEC 60601 (all parts), can also make use of this document</em>. Thus, this technical report can be applied to standalone software! No, software editors, you can't escape like that!</p>
<h4>Definition of safety requirements for connected MDs</h4>
<p>The IEC/TR 60601-4-5 is based on the requirements of the IACS IEC 62443 family of standards, which is very engineering-intensive for its implementation.<br />
<br />
This guide defines Security Levels (SL) and Security Capabilities (SC), which depend on the impact of a security breach on the system. SL and SC are borrowed from the IEC 62443 family.<br />
The SLs are on a scale of 0 to 4 - Definition (IEC 62443-1-1):</p>
<ul>
<li>SL 0 - No prevention.</li>
<li>SL 1 - Prevent the unauthorized disclosure of information via eavesdropping or casual exposure.</li>
<li>SL 2 - Prevent the unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills and low motivation.</li>
<li>SL 3 - Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, medical device specific skills and moderate motivation.</li>
<li>SL 4 - Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, medical device specific skills and high motivation.</li>
</ul>
<p>Like IEC 62304 subsystems with different security classes, security zones can be defined with different SL. It means that a medical device can have more than one security zone, with different SL.<br />
This could be the case for a home-use device, with two security zones:</p>
<ul>
<li>one connected to the internet in SL3,</li>
<li>and one with life-critical functions in SL1, isolated from the first.</li>
</ul>
<p>Of course, like IEC 62034, the security zones shall be segregated. And of course, like IEC 62304, IEC/TR 60601-4-5 doesn't define the kind of technical measures required for an effective segregation!</p>
<h5>Foundational requirements</h5>
<p>IEC/TR 60601-4-5 defines a total of 7 Foundational Requirements (FRs), borrowed from the IEC 62443-1-1:</p>
<ul>
<li>Identification and authentication control (IAC)</li>
<li>Use Control (UC)</li>
<li>System Integrity (SI)</li>
<li>Data Confidentiality (DC)</li>
<li>Restricted Data Flow (RDF)</li>
<li>Timely Response to Events (TRE)</li>
</ul>
<p>These 7 FR are refined in 123 requirements. That's a lot of requirements!<br />
But not all requirements are always applicable. The 123 requirements are only applicable to software in SL4.
It can be easily seen that SL3 and SL4 are the SL with a higher overhead. For software in SL1, "only" 50 requirements are applicable.<br />
<br />
These security requirements found in IEC/TR 60601-4-5 can be seen a "reservoir" of secure product requirements to be refined in HRS and in a Secure SRS document or a security section in the SRS.<br /></p>
<h5>SL Vector</h5>
<p>IEC/TR 60601-4-5 § A.6 allows to define different SL, according to the types of foundational requirements applicable. For example, for a device that does not handle confidential data, the SL for data confidentiality (DC) will be set to 0, whereas the SL for the system is 4.<br />
This "SL vector" approach (the term used in the standard) is possible for any system. This is a way to make a lighter list of security requirements applicable to your device.</p>
<h4>IEC 81001-5-1 and IEC/TR 60601-4-5 work together</h4>
<p>IEC 81001-5-1 and IEC/TR 60601-4-5 work in combination, the former defining a secure software development process, the latter feeding this process with security requirements.<br />
This is illustrated in the following diagram, where IEC 81001-5-1 defines the secure SDLC, and IEC/TR 60601-4-5 "injects" security requirement at system level (above the horizontal dotted line) and at software level:
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_81001-5-1-and-IEC-60601-4-5-combined.png" title="IEC 81001-5-1 and IEC/TR 60601-4-5-combined.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_81001-5-1-and-IEC-60601-4-5-combined_m.png" alt="IEC 81001-5-1 and IEC/TR 60601-4-5 combined.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC 81001-5-1 and IEC/TR 60601-4-5 combined.png, Jul 2021" /></a>
<br /></p>
<h4>Conclusion</h4>
<p>Draft standards in a standardization request, the state-of-the-art is being constructed. IEC 81001-5-1 and IEC/TR 60601-4-5 are clearly paving the way to future conformity to cybersecurity requirements. In EU and in the US.
We can take the bets that their approved version will be soon recognized by the FDA and harmonized in 2024 as planned in the EU.<br />
<br />
Edit 2021/07/15: unofficial information, IEC 81001-5-1 should be published by the end of 2021 or early 2022.</p>https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5#comment-formhttps://blog.cm-dm.com/feed/atom/comments/245MDCG 2019-16 Guidance on cybersecurity for medical devicesurn:md5:410d3b034928e18ddbe5d0a05afe4b142020-05-03T14:20:00+02:002020-05-09T14:00:01+02:00MitchRegulationsCybersecurityGuidance<p>So we have a new guidance on cybersecurity for medical devices: the MDCG 2019-16. This is not the one we expected so quickly, but we're not going to complain about the existence of this guidance! It was published in December 2019. At last I found time to write a review.<br />
This guidance covers a broad range of topics applicable to all stakeholders in the medical device supply chains, and to end-users. It explains a bit why it is 46 pages long.</p> <h4>Section 1 - Introduction</h4>
<p>The first section of the guidance draws the link between regulatory requirements and cybersecurity processes / artifacts. The figures 1 & 2 are quite a good synthesis of the MDR requirements covering cybersecurity. Note that these figures could be duplicated with several other topics, like electrical security, biocompatibility (and so on), and state-of-the-art applicable standards.<br />
The topics listed in section 1.4 cover all topics where cybersecurity is involved. This list is very useful to assess where cybersecurity requirements shall be implemented in your QMS processes. E.g: design controls, post-market surveillance.<br /></p>
<h4>Section 2 - Basic cyber concepts</h4>
<p>If you've already read documents like AAMI TIR 57 or the 2 FDA guidances on cybersecurity, you will retrieve in this section some information common to these documents. The novelty in this MDCG guidance is the link between these concepts and the MDR General Safety and Performance Requirements (GSPR).<br />
We also retrieve in this section concepts of <em>defense in depth</em>, <em>good security hygiene</em> (basic security hygiene in FDA guidance), and the relationship between security risks and safety risks.<br />
Another concept is introduced, not so easily found in other guidance: the link between usability engineering and cybersecurity:<br />
<em>[a vulnerability] should be regarded as an enabler of reasonably foreseeable misuse </em>.<br />
If an exploit exists, an user will use it with a probability to assess, linked to the user's education level and the ease of exploitation based on use scenarios.<br />
<br />
The concept of joint responsibility is also introduced. All stakeholders in the supply chain shall take their part of the job: medical device integrators operators, and users. Manufacturers, don't be fooled by this <em>joint responsibility</em>: as usual, your responsibility will be engaged in case of adverse event. You shall have established processes to ensure the proper installation, deployment, configuration, and exploitation of your devices in a secure manner. Simply said, this joint responsibility doesn't exonerate manufacturers. Quite the opposite, it engages the responsibility of other stakeholders.</p>
<h4>Section 3 - Secure design and manufacture</h4>
<p>Section 3 delves into technical details (as far as a guidance can do, it's not a standard), with a list of good practices to ensure that the device is secure by design. These 6 best practices can be seen as the steps of processes found in IEC 62304 design and maintenance processes:</p>
<ol>
<li>Security management:
<ol>
<li>4.1 of ISO 13485, for the security risk management process</li>
<li>5.1 of IEC 62304: Software development plan</li>
<li>6.1 of IEC 62304: Software maintenance</li>
</ol></li>
<li>Specification of Security Requirements:
<ol>
<li>5.2 of IEC 62304: software requirements analysis</li>
</ol></li>
<li>Secure by design, including defense in depth:
<ol>
<li>5.3 of IEC 62304: software architecture</li>
</ol></li>
<li>Secure implementation:
<ol>
<li>5.4 of IEC 62304: software detailed design</li>
<li>5.5 of IEC 62304: software implementation and unit verification</li>
<li>and a precision on SOUP management</li>
</ol></li>
<li>Secure Verification and Validation
<ol>
<li>5.6 of IEC 62304: software integration testing</li>
<li>5.7 of IEC 62304: software system verification</li>
</ol></li>
<li>Management of security-related issues
<ol>
<li>6.2 of IEC 62304: Problem and modification analysis</li>
<li>9 of IEC 62304: Problem resolution</li>
</ol></li>
<li>Security update management
<ol>
<li>6.3 of IEC 62304: Modification implementation</li>
<li>8.2 of IEC 62304: Change control</li>
</ol></li>
<li>Security guidelines:
<ol>
<li>5.8 Software release</li>
<li>and also software documentation, see IEC 82304-1 section 7.</li>
</ol></li>
</ol>
<h5>Security Risk management</h5>
<p>Section 3.2 continues with recommendations on the security risk management process, especially the link between security risks and their impact on safety. A very important remark is present in this section, for the sake of clarity of safety risk management reports: <em>safety risk assessment might list generic security related hazards (...). This is to avoid detailing every possible attack vector</em>.<br />
This section also insists on the fact that compliance to GSPR 1 to 4 requires to assess security risks. Thus, cybersecurity isn't nested only in GSPR 17.2 on software, but is promoted to the first main GSPR's.</p>
<h5>Security capabilities</h5>
<p>Section 3.3 lists some possible security capabilities for software. This list is absolutely not exhaustive. This is a good starting point, though.<br />
Interestingly, this section also contains an analogy between the precedence of safety mitigation actions (section 6.2 of ISO 14971) and their security risk equivalent. Worth reading!<br />
This section ends with a remark on the need to maintain <em>safety and effectiveness but also performance requirements and efficiency of mitigation actions</em>, with security capabilities. New columns to your risk assessment matrices?</p>
<h5>Minimum IT requirements</h5>
<p>Section 3.6 gives an indicative list of IT security requirements. You can take this list as the equivalent of the annex C of ISO 14971:2009 (not 2019, you will have to pay twice but this is another subject).<br />
This section also gives recommendations on accompagnying documents about cybersecurity. It's funny to read that they recommend to have these instructions in electronic format (hello regulation 207/2012/EU, e-IFU isn't a risk, it's a mitigation action!).</p>
<h5>Verification and validation</h5>
<p>This rather short section, is actually too short! If you want to know everything about verification of security measures, go to UL 2900-1 and UL 2900-2-1.</p>
<h5>Lifecycle aspects</h5>
<p>This last sub section of section 3 covers the support processes with respect to cybersecurity. It is elaborated in section 5 of the MDCG guidance. The best method is to update your current software maintenance process and problem resolution process to add provisions about security feedback and problems. Likewise, the PMS report or PSUR shall contain a section about cybersecurity.</p>
<h4>Section 4 - Documentation on IFU</h4>
<p>This section deals with all GSPR 23.x, on how to see them from the point of view of security. It's a very useful section, to fill your answers to GSPR matrix template. The recommendations on information to the users also overlap with the requirements found in IEC 82304-1. Likewise, this section is useful to add new sections about cybersecurity in your IFU template.</p>
<h4>Section 5 - PMS and vigilance</h4>
<p>Section 5 makes the link between regulatory requirements on PMS / vigilance, and cybersecurity. It makes a short recall on PMS, incidents and serious incidents. Examples of security events that have to be considered as incidents are given in annex II. The best way to follow these recommendations is probably to update your PMS process (PMS plans, PSUR templates) to add provisions to manage security incidents, like any other incident.<br />
This section ends with a reference to the IMDRF reporting tool. But there is no explanation on why the MDCG relies on this tool, nor is there any reference to the IMDRF elsewhere in the guidance. Some other guidances are expected on reporting tools. The mystery remains...</p>
<h4>Conclusion</h4>
<p>Compared to FDA guidances, the MDCG 2019-16 covers of both premarket and post market FDA cybersecurity guidances. It is a good surprise in the regulatory landscape.<br />
In terms of compliance for manufacturers, I suggest to put this document in an excel sheet and do a traceability matrix to ensure the right application of all the recommendations (requirements!) contained in these 46 pages.</p>https://blog.cm-dm.com/post/2020/05/03/MDCG-2019-16-Guidance-on-cybersecurity-for-medical-devices#comment-formhttps://blog.cm-dm.com/feed/atom/comments/234Cybersecurity in medical devices: a short review of UL 2900-1urn:md5:c0d4a8261e44a1484ce72f99b4a590992019-08-16T13:44:00+02:002019-08-17T20:01:29+02:00MitchStandardsCybersecurity<p>We continue this series of articles on cybersecurity with a free and non-exhaustive review of UL 2900-1 standard.<br />
What is UL 2900-1? This standard was published in 2017 by Underwriters Laboratory (UL). It contains technical requirements on cybersecurity for network connectable products. A collateral UL 2900-2-1 focuses on connectable healthcare and wellness systems. UL 2900-1 and UL 2900-2-1 are FDA recognized standards. Thus, applicable to medical devices.</p> <p>Unlike other guides and standards, e.g. AAMI TIR 57 or ISO 27005 or FDA guidances, this standard doesn't contain requirements on a cybersecurity risk management process. It is more a set of requirements on cyber security measures to document, implement and verify.<br />
However, the section 12 of the standard requires to establish a security risk management process, with some specific requirements, like the use of classification schemes. E.g. <a href="https://capec.mitre.org">CAPEC</a> or <a href="https://cwe.mitre.org/cwraf/">CWRAF</a><br />
<br />
Thus, UL 2900-1 cannot be used alone, and you should rely on other standards or guidances to establish a security risk management process, before implementing UL 2900-1 requirements.</p>
<h4>Comparison with 60601 standard?</h4>
<p>Can we dare a comparison with 60601-1 standard?<br />
IEC 60601-1 Ed3 contains a (huge) set of technical requirements, with a link to safety risk management process. UL 2900-1 contains a set of technical requirements with a link to security risk management process.<br />
Like IEC 60601-1, evidences of compliance to requirements UL 2900-1 will be found in the device design and device verification plans and reports of the Design History File (FDA) or Technical File (CE mark) of the device.<br />
Like IEC 60601-1, UL 2900-1 is made for certification of products by accredited laboratories, as of today by UL only.</p>
<h4>Link with 62304 standard</h4>
<p>IEC 62304 defines requirements on software lifecycle <em>processes</em>: development, maintenance, configuration management, and risk management.<br />
UL 2900-1 defines requirements on <em>product</em>. Thus, UL 2900-1 will affect your software development and maintenance plans, as well as software requirement analysis, test plans and test reports required by IEC 62304.<br />
In a few words: IEC 62304 is a <em>process</em> standard, UL 2900-1 is a <em>product</em> standard.<br />
Remark: this is also true for IEC 82304-1</p>
<h4>Product documentation</h4>
<p>The standard begins with requirements on product documentation. A rough half of the documentation items listed in the standard are already required by regulations or other standards, like IEC 62304.<br />
The second half is specific to UL 2900-1, and is the output of the other requirements found in the standard.<br />
This product documentation will be reviewed by UL for evaluation and certification. If you want to get a certificate.</p>
<h4>Technical requirements</h4>
<p>The rest of the standard is composed of a set of technical requirements grouped by different topics:</p>
<ul>
<li>Risk controls applicable to software design,</li>
<li>Access controls, user authentication,</li>
<li>Use of cryptographically secure mechanisms,</li>
<li>Remote communication integrity and authenticity,</li>
<li>Confidentiality of sensitive data,</li>
<li>Product management in post-market: security updates, decommissioning</li>
<li>Validation of tools and processes from a security standpoint,</li>
<li>Vulnerabilities exploits and software weaknesses,</li>
</ul>
<p>The standards ends with requirements on testing strategies, code reviews, static and dynamic analysis, addressing the above topics.<br />
Some requirements are very specific, like:</p>
<ul>
<li>Minimum length of passwords shall be at least 6 characters,</li>
<li>The number of test cases in malformed input testing shall be 1 million cases or 8 hours.</li>
</ul>
<p>The testing strategies that have to be implemented cover all levels of software architecture: source code, unitary level, and GUI/architectural level.<br />
It demonstrates that being compliant to UL 2900-1 has a strong impact both on design phases and design verification phases (If by any chance you had a doubt :-).</p>
<h4>Conclusion</h4>
<p>UL 2900-1 is a set of prescriptive requirements applicable to the design, design verification and post-market phases of a medical device. It requires the implementation of a security risk management process, to ensure the compliance to its requirements.<br />
No security risk management process is documented in UL 2900-1. You have to go to AAMI TRI 57 and, more general, to ISO 27005, to find state-of-the-art security risk management processes.</p>https://blog.cm-dm.com/post/2019/08/16/Cybersecurity-in-medical-devices%3A-a-short-review-of-UL-2900-1#comment-formhttps://blog.cm-dm.com/feed/atom/comments/225Cybersecurity - Draft guidances from FDA and Health Canadaurn:md5:15090212dca076a23d5e68ce72b9d1dd2019-01-24T12:50:00+01:002019-01-28T18:47:21+01:00MitchRegulationsCybersecurityFDAGuidance<p>The US FDA published in October 2018 a new draft version of its <a href="https://www.fda.gov/MedicalDevices/DigitalHealth/ucm373213.htm">guidance on the content of premarket submissions for management of cybersecurity in medical devices</a>. Two months later, Health Canada published in December 2018 a <a href="https://www.canada.ca/en/health-canada/services/drugs-health-products/public-involvement-consultations/medical-devices/consutation-premarket-cybersecurity-profile/draft-guidance-premarket-cybersecurity.html">draft guidance document on pre-market requirements for medical device cybersecurity</a>.</p> <p>We are surrounded by draft guidances!<br />
<br /></p>
<h4>US FDA Draft Guidance</h4>
<p>To refresh your memory, this guidance defines the documentation to compile about cybersecurity for a premarket submission.
The new draft guidance brings three significant changes, compared to the previous guidance of 2014:</p>
<ul>
<li>The concept of trustworthy device,</li>
<li>A categorization of software: tier 1 and tier 2,</li>
<li>A list of recommended mitigation actions by design.</li>
</ul>
<p>Like the previous approved version, this draft guidance relies on the NIST Cybersecurity Framework to manage cybersecurity:</p>
<ul>
<li>Identify, protect,</li>
<li>Detect,</li>
<li>Respond,</li>
<li>Recover.</li>
</ul>
<p>That's a good thing, as this framework is freely and globally available on the NIST website for all medical devices manufacturers around the world. Free documentation is a good option when you want to promote security and protection from criminal organizations!</p>
<h5>Trustworthy device</h5>
<p>Cybersecurity introduces lots of new concepts for people who never rubbed their skin to cybersecurity. To make a parallel with patient safety, the concept of trustworthy device (you will find the definition in the guidance) is equivalent to the concept of validated device in terms of safety and clinical performance.<br />
If a device is clinically validated, you trust it for patient management. If a device is trustworthy in the meaning of this guidance, you trust it for cybersecurity protection.</p>
<h5>Tier 1 and Tier 2 devices</h5>
<p>The really good news is the introduction of a hint of explicit risk-based approach in this guidance. It defines two categories:</p>
<ul>
<li>Tier 1: <em>Higher Cybersecurity Risk</em>,</li>
<li>Tier 2: <em>Standard Cybersecurity Risk</em>.</li>
</ul>
<p>The level of evidence to bring to the FDA, to demonstrate that your device is a trustworthy one, is higher for tier 1 (full documentation) and lower for tier 2 (rationale-based partial documentation).<br />
Thus, introducing <a href="https://blog.cm-dm.com/post/2018/10/15/Cybersecurity-Part-5-Templates">cybersecurity risk assessment</a> in your risk management process is a good idea.</p>
<h5>List of recommended mitigation actions by design</h5>
<p>The other good news is the clarification of FDA's expectations on design for cybersecurity. The guidance lists no less than 37 design measures for cybersecurity management. It is striking that these measures are numerous and precise. There is probably a will of the FDA to promote the design of secure devices by directly pointing to the relevant measures.<br />
The drawback of this list is to limit or focus on a subset of measures, drawing the attention of the reader to these measures only. (I had to find a drawback, no ?)<br />
It is also worth noting that most of the recommendations can be found in the UL 2900-1 standard (to be reviewed in a next post).</p>
<h5>Labeling recommendations</h5>
<p>To end this quick tour of this guidance, just two remarks on labeling recommendations.<br />
<br />
Information on cybersecurity have to be disclosed to end-users. This is a basic principle of cybersecurity management that you will find in other documents like ISO 2700X standard family. The FDA follows this principle in their labeling recommendations.<br />
<br />
And I can't help but finish by this last comment on Cybersecurity Bill Of Material (CBOM). CBOM is the list of all off-the shelf software that are or could become susceptible of vulnerabilities. The CBOM shall be <em>cross referenced with the National Vulnerability Database (NVD) or similar known vulnerability database</em>.<br />
Do you like IEC 62304 requirements on SOUP periodic review? Trust me, you are going to love CBOM - NVD cross-reference!!!<br />
<br /></p>
<h4>Health Canada FDA Draft Guidance</h4>
<p>Like the US FDA guidance, this guidance gives recommendations on documentation to provide with medical device licence submission.<br />
The guidance recognizes that a cybersecurity strategy shall be defined for devices incorporating software, from class I to class IV. This strategy should include:</p>
<ul>
<li><em>Secure design</em></li>
<li><em>Risk management</em></li>
<li><em>Verification and validation testing</em></li>
<li><em>Planning for continued monitoring of and response to emerging risks and threats</em></li>
</ul>
<p>Unlike the US FDA Tier 1 and 2 categories, the full Canadian guidance is applicable to all regulatory classes. however, the documentation is only reviewed by Health Canada for class III and class IV medical device licence applications. Class I a simple registration, and class II doesn't require to submit the design dossier.</p>
<h5>NIST Cybersecurity Framework</h5>
<p>Like the US FDA guidance, the Canadian guidance relies on the NIST framework for cybersecurity management. Yes, you read it right, Canada references a document available on nist<mark>.gov</mark> website.</p>
<h5>Cybersecurity measures</h5>
<p>Like the US FDA guidance, the Canadian one gives a list of design measures to envision: no less than 17 measures are found in tables 1 and 3. It is worth noting that some of these measures come from UL 2900-1, referenced by the guidance.</p>
<h5>Safety risk vs security risk</h5>
<p>This draft guidance references AAMI TIR 57. It also contains screen shots (figure 2) of AAMI TIR 57 on the relationship between safety risk management and cybersecurity risk management.<br />
The table 2 gives <em>Examples of the relationship between cybersecurity risk management and patient safety management</em>. Beware if you read this table: you have to understand that each line is a chunk of a risk management process. E.g. the line <em>Security risk with a safety impact</em> contains <em>Not applicable</em> for <em>Security Control</em>, hence the line focusses on the risk, not the control.</p>
<h5>Medical Device Licence Application</h5>
<p>All in all, the main goal of this guidance is to give recommendations on the content of a medical device licence application for class III and IV devices, also applicable to class II and class I design files. It embraces the state-of-the-art in this discipline and defines how it should be documented.</p>
<h4>UL 2900-1 and AAMI TIR 57</h4>
<p>On the normative side, the Canadian guidance references a few standards and guidances. We find <a href="https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016">AAMI TIR 57</a>. It gives very good hints on the relationship between security risk and safety risk management.<br />
We have also UL 2900-1, the one and only standard addressing cybersecurity in medical devices design, up to now. UL 2900-1 overlaps partially with the two draft guidances. All design measures found in the guidances are found in UL 2900-1. Thus UL 2900-1 sets a common ground for the design on medical devices.<br />
We will see that in the next post.<br />
BTW, IEC 62304 and ISO 14971 are also referenced. Like everyday life!</p>
<h4>Conclusion</h4>
<p>North American agencies are strengthening their expectations on cybersecurity in regulatory submissions. Health Canada is the newcomer, with their guidance copyright Her Majesty the Queen in Right of Canada. (Who is also Her Majesty the Queen of the UK!).<br />
<br />
<strong>Hey European Commission, where is your guidance to answer to General Requirements #17 and #23.ab in Annex 1 of regulation 2017/745/UE?</strong></p>https://blog.cm-dm.com/post/2019/01/24/Cybersecurity-Draft-guidances-form-FDA-and-Health-Canada#comment-formhttps://blog.cm-dm.com/feed/atom/comments/218Cybersecurity - Part 5 Templatesurn:md5:f02ee9fa74fee8034a42fb26e99e32132018-10-15T14:58:00+02:002019-07-24T09:16:55+02:00MitchTemplatesCybersecurityrisk managementTemplate<p>Hi there! Long time no see once again. I dig up our series of <a href="https://blog.cm-dm.com/post/2016/10/24/Cybersecurity-in-medical-devices-Part-1-Regulations">posts on cybersecurity</a>.<br />
In this post I publish two new templates for cybersecurity risk management.</p> <p>The list of standards and guidances dealing with cybersecurity in medical devices has evolved a lot for the last two years:</p>
<ul>
<li>At first we had the FDA guidances on cybersecurity published in 2014-2016,</li>
<li>Then AAMI TIR 57 was released in 2016, it describes a security risk management process comparable to the safety risk management process of ISO 14971,</li>
<li>And in 2017, ANSI/UL 2900-1, and ANSI/UL 2900-2-x were released, they list requirements (sometimes very specific) to design and maintain a secure medical device.</li>
</ul>
<p>Note that a traceability exists between UL 2900-x standards and FDA guidances on cybersecurity. I think though, it's unofficial, I let you find it on the web.<br />
<br />
All these guidances and standards represent a good source of information to implement a cybersecurity risk management process. However, if we extend the scope to other industries, the risk management process described in ISO 27005 is also a good start.<br />
<br />
This is the approach I had in the past few years, begin with ISO 27005 process and add specific medical devices provisions based on recommendations from AAMI TIR 57 and requirements from ISO 14971.<br />
This risk management process is then fed with guidances found in informative part of ISO 27005, AAMI TIR 57, as well as provisions found in UL 2900-x.<br />
<br />
The two templates are based on this approach:</p>
<ul>
<li><a href="https://blog.cm-dm.com/public/Templates/security-risk-management-plan-template-2018.doc">Security Risk Management Plan template</a>,</li>
<li><a href="https://blog.cm-dm.com/public/Templates/security-risk-assessment-report-template-2018.doc">Security Risk Assessment Report template</a>.</li>
</ul>
<p>You will also find them in <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">the templates repository page</a>.<br />
<br />
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/2018/10/15/Cybersecurity-Part-5-Templates#comment-formhttps://blog.cm-dm.com/feed/atom/comments/217Cybersecurity in medical devices - Part 4 Impact on Software Development Processurn:md5:4ce8779c8fd7a433adba8829fa2750f92017-07-03T14:06:00+02:002017-07-04T21:34:52+02:00MitchRegulationsCybersecuritydevelopment process<p>We continue this series of posts on cybersecurity with some comments on impacts of cybersecurity on the software development documentation.</p> <h4>IEC 62304 class A software vs cybersecurity</h4>
<p>IEC 62304 defines a rather light set of constraints for class A software. Many connected objects or back-office servers processing medical data are low risk devices (when they’re qualified of medical devices). If we put apart the case of devices used for close-loop, or remote monitoring (or the like), most of standalone software in back-office (services) or used remotely (standalone web apps or mobile apps) will present failures with negligible consequences for the patient. As such, most of standalone software will be in class A (a conclusion that I verified empirically).<br /></p>
<h3>Cybersecurity documentation requirements</h3>
<p>For class A software, it’s usual to do the bare minimum to be compliant: software requirements, functional tests, a bit of risk assessment with acceptable risk prior to mitigation actions, a bit of SOUP management, and voilà! It won’t be enough to prove that standalone medical device software is secure.<br />
Thus, cybersecurity requires to bring additional documentation: security risk assessment, mitigation actions, and evidence of their effective implementation. Where are we going to find these evidences?<br />
In software requirements, of course, but also in architectural design, possibly in detailed design, and in unit/integration/verification tests. This sounds more like class B than class A.</p>
<h3>Special tests for cybersecurity</h3>
<p>More, we can mimic the section 5.5.4 of IEC 62304, applicable to class C only, by including additional cybersecurity tests requirements like application of <a href="https://www.owasp.org/index.php/Top_10_2013-Top_10">OWASP 13 Top-10</a> to verify good coding practices. For this kind of tests, tools like static analyzers or methods like peer code reviews are usually implemented. These tools and methods are more frequent for class C software development, than for class B and A.<br /></p>
<h4>Summary</h4>
<p>To sum-up, we have the following cases:</p>
<table style="text-align:center">
<tr style="background-color: #25ABA3">
<td>Type</td>
<td>SW embedded in MD (contributes to essential performance)</td>
<td>Standalone SW (diagnosis / treatment intended use)</td>
<td>SW embedded in MD (doesn't contribute to essential performance)</td>
<td>Standalone SW (no diagnosis / treatment intended use)</td>
</tr>
<tr>
<td>Usual SW safety class</td>
<td>C or B</td>
<td>C or B</td>
<td>A</td>
<td>A</td>
</tr>
<tr>
<td>Connected?</td>
<td>Usually no, but BTLE is appealing!</td>
<td>Usually yes, on PC or mobile connected to HCP or public network</td>
<td>Yes with BTLE or Wifi connected to HCP or public network</td>
<td>Usually yes, on PC or mobile connected to HCP or public network</td>
</tr>
<tr>
<td>Cybersecurity overhead</td>
<td>Null if not connected (beware of USB). Very high if connected, to prove that security breach won’t result in the degradation of essential performance.</td>
<td>Limited. Security breach will mostly result in data loss, rarely in non-serious harm (i.e. significant delay in diagnosis)</td>
<td>Null if not connected. Important if connected (data loss only, but class A documentation is not detailed enough)</td>
<td>Important if connected (data loss only, but class A documentation is not detailed enough)</td>
</tr>
</table>
<p>This comparison of different cases shows that we have a paradox:</p>
<ul>
<li>High safety risk devices will require a limited cybersecurity overhead. If essential performance relies on software, device connectivity will be limited. The cybersecurity documentation will represent a limited amount of work, compared to device safety documentation.</li>
<li>Low safety risk devices will require a significant cybersecurity overhead. Software safety documentation is poor, thus the cybersecurity overhead will represent a significant amount of work, compared to device safety documentation.</li>
</ul>
<p>This comparison is not valid for high-risk devices designed for connectivity, like an hypothetical close-loop system, which loop goes through a remote server. It's the worst case, reserved to manufacturers with enough resources to support the design and maintenance of such device.</p>
<h4>Conclusion</h4>
<p>Connecting a medical device to a network is not trivial, especially if that network is not a controlled network, like public or home network. The cybersecurity requirements established by the FDA guidances in the US, and in the new Medical Device Regulation in the EU have significant consequences on the cost of documentation to bring evidences of compliance.<br />
The cost is significant for IEC 62304 class A software, which requires documentation closer to class B than class A.</p>https://blog.cm-dm.com/post/2017/07/03/Cybersecurity-in-medical-devices-Part-4-Impact-on-Software-Development-Process#comment-formhttps://blog.cm-dm.com/feed/atom/comments/206Cybersecurity in medical devices - Part 3 AAMI TIR57:2016urn:md5:5adc4afffd7a08b5f11355939d648e6d2017-05-16T21:53:00+02:002017-05-16T22:46:46+02:00MitchStandardsCybersecurityGuidance<p>After a long pause, we continue this series about cybersecurity in medical devices with a discussion on AAMI TIR57:2016 Principles for medical device security — Risk management.</p> <p>This TIR is the one and only document available in the corpus on medical device-related standards and guidances, dealing with the application of cybersecurity principles and their impact on ISO 14971 risk management process. Yet, FDA guidances exist, but they’re not as direct as this TIR to show the impact of cybersecurity management process on risk management process.</p>
<h4>Structure of AAMI TIR57:2016</h4>
<p>The structure of sections 3 to 9 of this document is copied from ISO 14971 standard. It shows how the security risk management process can be modeled in a manner similar to the safety risk management process.<br />
If you’re at ease with ISO 14971, you’ll be at ease with AAMI TIR57. Your effort of understanding will be focused on security risk management concepts, not the process (risk identification, evaluation, mitigation and so on…) that you already know.<br />
We can bless the working group in charge of this TIR for this effort of presentation. The diagram below, extracted from the TIR, shows the analogy between both processes.</p>
<p><img src="https://blog.cm-dm.com/public/Cybersecurity/security-risk-safety-risk.png" alt="Relationships between the security risk and safety risk management processes" style="display:table; margin:0 auto;" title="Relationships between the security risk and safety risk management processes, May 2017" />
<br />
You've probably already seen this diagram elsewhere. And I bet that many articles or newsletters dealing cybersecurity in medical devices are going to reproduce it as well!</p>
<h4>Separation of processes</h4>
<p>The TIR recommends to separate the security and safety risk management processes. This looks as a good recommendation, as people involved in both processes are not all the same. Data security and clinical safety concepts are not managed by the same persons with the same qualifications.</p>
<h5>Cons</h5>
<p>This separation is going to remain very theoretical for most of small businesses. Practically, big companies can afford maintaining two processes and the needed qualified persons, but small businesses don’t.<br />
Small businesses will require the help of security experts to manage security risks. But they will be most probably hired as consultants. People who currently manage ISO 14971 process will manage both processes, without clear separation on a day to day basis.</p>
<h5>Pros</h5>
<p>The separation of processes is a good way to monitor efficiently security risk management. Keeping a security risk management file separated form the safety risk management file allows to document the outputs of the process without mixing concepts of security risk management (threats, vulnerabilities, assets, adverse impacts), with concepts of safety risk management (hazardous phenomenon, hazardous situation, hazard, harm).</p>
<h4>Annexes of AMMI TIR:57:2016</h4>
<p>The annexes found after section 9 are another wealth of information. They contain practical methods to implement a security risk management process. There is even a list of questions that can be used to identify medical device security characteristics, like the annex C of ISO 14971 for safety risks!<br />
The TIR ends with an example based on a fictional medical device: the kidneato system, with everything that a manufacturer shouldn’t do: an implanted part, a part connected to the public network, and a server storing medical data. Delicatessen for hackers!</p>
<h4>Multiplication of risk management files</h4>
<p>With the ongoing implementation of ISO 13485:2016 by medical device manufacturers, another consequence of security risk management is the multiplication of risk management files:</p>
<ul>
<li>QMS Process risk management,</li>
<li>Safety risk management,</li>
<li>Security risk management, and</li>
<li>Risk / opportunities management, for the fans of ISO 9001:2015.</li>
</ul>
<p>We can even try to draw a table of interactions between these processes (I skip ISO 9001:2015, but don’t conclude I’m not a fan :-))</p>
<table style="text-align:center">
<tr style="background-color: #25ABA3">
<td> </td><td>Affects</td><td rowspan="2">Safety</td><td rowspan="2">QMS Process</td><td rowspan="2">Security</td>
</tr>
<tr>
<td>Risks</td><td> </td>
</tr>
<tr>
<td colspan="2">Safety</td><td style="background-color: #dddddd">X</td><td>Safety risk mitigations implemented in QMS processes</td><td>Safety risks with potential impact on security. Safety controls affecting security</td>
</tr>
<tr>
<td colspan="2">QMS Process</td><td>Hazardous situations in QMS processes with impact on safety. QMS process controls affecting safety</td><td style="background-color: #dddddd">X</td><td>QMS process risk controls affecting security. Threats, vulnerabilities, assets found in processes to assess in security risk management</td>
</tr>
<tr>
<td colspan="2">Security</td><td>Security risks with impact on safety, Security controls affecting safety</td><td>Security risks with impacts on QMS processes (and possibly safety). Security controls affecting QMS processes</td><td style="background-color: #dddddd">X</td>
</tr>
</table>
<h4>Conclusion</h4>
<p>AAMI TIR75:2016 is an excellent source of information for newbies in security risk management. A must-read for people not qualified in security risk management, who need to manage the process, and anticipate its impact on other processes.<br />
<br />
In the next article, we’ll see the consequence of cybersecurity management on software development and maintenance processes.</p>https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016#comment-formhttps://blog.cm-dm.com/feed/atom/comments/204Final FDA Guidance on Postmarket Management of Cybersecurity in Medical Devices - Final version releasedurn:md5:a2c6398cc0958aea47e330959db3a5202017-02-10T14:20:00+01:002017-02-11T16:32:05+01:00MitchRegulationsCybersecurityFDAGuidance<p>This article is a follow-up of the previous article on the <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">Draft guidance on Postmarket Management of Cybersecurity in Medical Devices</a>.</p> <h4>Postmarket Management of Cybersecurity in Medical Devices</h4>
<p>The FDA released the final version of this guidance in December 2016. Let's see what changes the FDA made, compared to the draft version.<br />
This guidance underwent many changes, compared to the draft version. One of the most prominent is in the scope:</p>
<blockquote><p>This guidance applies to any marketed and distributed medical device including: 1) medical devices that contain software (including firmware) or programmable logic; and 2) software that is a medical device, including mobile medical applications. In addition, this guidance applies to medical devices that are considered part of an interoperable system and to “legacy devices,” i.e., devices that are already on the market or in use.</p></blockquote>
<p>Argh! Legacy devices! Good luck...<br />
Well, this scope was updated to cover any type of medical device with software or with data transmission functions (i.e. the presence of interoperable device) and to make it as articulate as possible.</p>
<h4>Essential Clinical Performance replaced by Patient Harm</h4>
<p>In the Definitions section, the essential clinical performance disappeared and was replaced by Patient Harm.
The concept of “essential clinical performance”, which was developed in the draft guidance, was removed in the final version.<br />
The definition of patient harm is fairly long and won't be copy-pasted here. It is aligned with the definition of patient harm in ISO 14971. The guidance stresses out the risk-based assessment of cybersecurity vulnerabilities, which can lead by a sequence of events to patient harm.<br />
<br />
Interestingly, the guidance excludes vulnerabilities compromising confidential data. It only recommends to protect devices from such situations, and refers to other regulations like HIPAA.</p>
<h4>Postmarket Considerations</h4>
<p>The posmarket considerations were updated to remove to recommendation to "Clearly [define] essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity risk". It was replaced by (emphasis added):</p>
<blockquote><p>Using threat modeling to clearly define how to maintain <ins>safety and essential performance</ins> of a device by developing mitigations that protect, respond and recover from the cybersecurity risk.</p></blockquote>
<p>The postmarket considerations were also augmented with the recommendation:</p>
<blockquote><p>Maintaining robust software lifecycle processes that include mechanisms for:<br />
o monitoring third party software components for new vulnerabilities throughout the device’s total product lifecycle;<br />
o design verification and validation for software updates and patches that are used to remediate vulnerabilities, including those related to Off-the-shelf software<br /></p></blockquote>
<p>We retrieve somewhat here the requirements on software maintenance of section 6 of IEC 62304, read through the lens of cybersecurity management.<br />
<br />
Talking about standards, the guidance mentions that the FDA has recognized <em>ISO/IEC 30111:2013: Information Technology – Security Techniques – Vulnerability Handling Processes</em>, and <em>ISO/IEC 29147:2014: Information Technology – Security Techniques – Vulnerability Disclosure</em>, which the FDA thinks may be useful for manufacturers.</p>
<h4>Maintaining Safety and Essential Performance</h4>
<p>In relation with the removal of essential clinical performance, the section on "Defining Essential Clinical Performance" was removed and replaced by "Maintaining Safety and Essential Performance".<br />
This section draws the link between cybersecurity risk management, safety and essential performance, threat modeling, and remediations (in cybersecurity vocabulary) / mitigation actions.</p>
<h4>Evaluation and control of risk patient harm</h4>
<p>Likewise, the section on "Evaluation of Risk to Essential Clinical Performance" was replaced by "Evaluation of Risk of Patient Harm", and the section on "Control of Risk to Essential Clinical Performance" was replaced by "Control of Risk of Patient Harm" <br />
The body text of both sections was almost left untouched, with a direct search-and-replace of essential clinical performance by patient harm. It makes their wording more in line with what QA/RA people have the habit to read: risk management addresses patient harm.<br />
These sections were also slightly updated, with recommendations on adopting a vulnerability disclosure policy, and recognizing that changes (mitigations / remediations) may have an impact on the performance of a medical device. In other words, a risk resulting of the mitigation action.</p>
<h4>Criteria for defining active participation by a manufacturer in an ISAO</h4>
<p>ISAO: Information Sharing Analysis Organization - see <a href="https://www.dhs.gov/isao-faq">ISAO FAQ</a> to better understand the purpose of these organizations.<br />.
This is a new section in the final guidance. It emphasizes the participation of manufacturers in an ISAO. Reading between the lines, this is the kind of recommendation, which can become a compulsory practice.</p>
<h4>Elements of an effective postmarket cybersecurity program</h4>
<p>To finish with this quick scan of the guidance, this appendix hasn't changed that much. We retrieve the direct search-and-replace of essential clinical performance by patient harm, along with small changes to the body text.</p>
<h4>Conclusion</h4>
<p>Compared to the draft guidance, this final guidance contains only small fixes and a clarification of management of cybersecurity vs patient harm. It doesn't reduce nor increase the burden of cybersecurity management. While reducing the burden could have been an expectation of some manufacturers, it is not feasible. Fortunately, it hasn't increased between the draft and the final guidance.<br />
<br />
With this final guidance on Postmarket Management of Cybersecurity in Medical Devices, and the <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices</a>, we now have a full set of recommendations for cybersecurity management over the medical device software lifecycle.<br />
<br />
We now have GCyP: Good Cybersecurity Practices.</p>https://blog.cm-dm.com/post/2017/02/10/FDA-Guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices-Final-version-released#comment-formhttps://blog.cm-dm.com/feed/atom/comments/202Final FDA Guidance on Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Typesurn:md5:367a465c647625aa1580d359f67c34d82017-02-10T14:19:00+01:002017-02-10T14:19:00+01:00MitchRegulationsCybersecurityFDAGuidance<p>This article is a follow-up of the article on the <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">Draft guidance on Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Types</a>.</p> <p>The FDA released the final version of two guidances in December 2016 (yes, I know, I'm a bit late. But you see, this blog is still alive...). One on the medical devices accessories and one on postmarket management of cybersecurity in medical devices.<br />
Let's see what changes the FDA made to the medical devices accessories guidance, compared to the draft version.</p>
<h4>Medical Device Accessories</h4>
<p>This guidance didn't suffer many changes. The guidance describes what the FDA considers an accessory to a medical device and how it regulates them. Accessories with risk profile different from their parent devices may fall within a different class than the device with which they're intended to be used.<br />
<br />
The truly interesting changes are those clarifying the status of software as a medical device:</p>
<blockquote><p>FDA intends for the risk- and regulatory control-based classification paradigm discussed in this guidance to apply to all software products that meet the definition of an accessory, including those that may also meet the definition of “Software as a Medical Device (SaMD).”</p></blockquote>
<p>Thus SaMD intended to support, supplement, and/or augment the performance of one or more parent devices are medical devices accessories and may fall within a class different from their parent devices. This actually opens the door to the De Novo clearance process for SaMD with no "easy" predicate.<br />
<br />
Another truly interesting change, compared to the draft version, is the examples on articles used in conjunction with the device, which do not fall in the definition of accessories:</p>
<blockquote><p>FDA would generally not consider a mobile phone that is used as a general platform for applications that include mobile medical applications that are medical devices or an off-the-shelf computer monitor used to display medical data as accessories unless they are specifically intended for use with such medical devices.</p></blockquote>
<p>Likewise:</p>
<blockquote><p>non-device-specific off-the-shelf replacement parts (e.g., batteries, USB cables, computer mouse, etc.) may be used with a medical device, but FDA does not intend to consider these products to be accessories or medical devices.</p></blockquote>
<p>These two examples are welcome. How many times newcomers in the world of SaMD have asked if these types of articles are medical devices. It's way better written in back and white.</p>
<h4>Conclusion</h4>
<p>Not so much new things compared to the draft guidance. The FDA confirms their approach on medical devices accessories, allowing to place accessories in a class different from their parent devices, and opening the gate to the De Novo process.<br />
Besides that, the examples found in this guidance about off-the-shelf hardware are very helpful to determine if such articles are accessories of software medical device or not.
<br />
<br />
The <a href="https://blog.cm-dm.com/post/2017/02/10/FDA-Guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices-Final-version-released">next article</a> is on postmarket management of cybersecurity in medical devices.</p>https://blog.cm-dm.com/post/2017/02/10/Final-FDA-Guidance-on-Medical-Device-Accessories%3A-Defining-Accessories-and-Classification-Pathway-for-New-Accessory-Types#comment-formhttps://blog.cm-dm.com/feed/atom/comments/201Cybersecurity in medical devices - Part 2 Stakeholdersurn:md5:fca5a3cf09fa3ba201eb625510e86f262016-12-20T12:51:00+01:002017-05-23T16:19:07+02:00MitchMiscCybersecurity<p>After a long interruption, we continue this <a href="https://blog.cm-dm.com/post/2016/11/01/IEC-82304-1%3A2016-Health-software-Part-1%3A-General-requirements-for-product-safety">series on cybersecurity</a> in medical devices with a review of stakeholders involved or concerned by cybersecurity requirements, and the consequences on architectural choices.</p> <p>The main characteristic of connected medical devices is to be ... connected. They can't fulfill their intended use alone and need a technical environment to work. This technical environment is never provided by the manufacturer alone. Thus several stakeholders are involved in the fulfillment of the intended use, directly or indirectly.</p>
<h4>Interested parties</h4>
<p>Borrowing the vocabulary of ISO 9001:2015, stakeholders are interested parties, and we have to <em>understand the needs and expectations of interested parties</em> (quote of 4.2 of ISO 9001:2015).<br />
<img src="https://blog.cm-dm.com/public/Cybersecurity/.cybersecurity_stakeholders_m.png" alt="cybersecurity_stakeholders.png" style="display:table; margin:0 auto;" title="cybersecurity_stakeholders.png, Dec 2016" /></p>
<h5>Cybercriminals</h5>
<p>The goal of cybercriminals is to break the security measures to steal medical or financial data (welcome to the depths of the internet), or to injure people (mostly in movies).<br />
<br />
<ins>Cybercriminals:</ins></p>
<ul>
<li>Needs: to have a better living whatsoever,</li>
<li>Expectations: to find devices and IT infrastructures with vulnerabilities.</li>
</ul>
<h5>Medical device manufacturers</h5>
<p>The goal of MD manufacturers is to design and place on the market secure devices, without vulnerabilities. To be more specific, without <em>known</em> vulnerabilities.<br />
<br />
<ins>Manufacturers:</ins></p>
<ul>
<li>Needs: to have the capabilities to design and maintain devices without vulnerabilities,</li>
<li>Expectations: to place connected devices on the market, compliant to regulations, safe and secure.</li>
</ul>
<h5>IT infrastructure providers</h5>
<p>We have two types of infrastructure providers: those who are aware of medical devices (MD) and health data (HD) regulations and standards, and the others who are not aware or deliberately won't set a foot in the constraints of e-health. The former usually build an offer of services compliant to MD and HD regulations, the latter don't or won't.<br />
For example, some cloud storage providers currently sell services compliant to HIPAA regulation in the US, and will sell services compliant to GDPR in Europe. Others are for example telco companies or general cloud service providers.<br />
<br />
<ins>MD and HD compliant service providers:</ins></p>
<ul>
<li>Needs: to have the capabilities to design and maintain IT platforms without vulnerabilities,</li>
<li>Expectations: to sell services compliant to MD and HD regulations.</li>
</ul>
<p><ins>Other IT service providers:</ins></p>
<ul>
<li>Needs: to have the capabilities to design and maintain IT platforms without vulnerabilities,</li>
<li>Expectations: to sell services while staying out of MD and HD regulations.</li>
</ul>
<h5>Governmental organizations</h5>
<p>These organizations have the mission to enforce regulations and to watch the market. We find organizations of the MD and HD world, like the FDA or the Department of Health & Human Services in the US, and like national authorities of member states in Europe.<br />
Specific to cybersecurity, we can also quote the Information Sharing and Analysis Organizations (ISAO) cited <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">in the FDA guidance on postmarket management of cybersecurity</a>.<br />
<br />
<ins>Governmental organizations:</ins></p>
<ul>
<li>Needs: to have a clear understanding of what other stakeholders do,</li>
<li>Expectations: to have devices and IT infrastructures compliant to regulations throughout their lifecycle.</li>
</ul>
<p>Additionally, we can quote the <a href="https://www.dhs.gov/topic/cybersecurity">US Department of Homeland Security</a> and <a href="https://www.gov.uk/government/policies/cyber-security">equivalent agencies</a> in other countries. But this is a bit out of the scope of this blog!</p>
<h5>End-Users</h5>
<p>We have here several type of end-users:</p>
<ul>
<li>Patients,</li>
<li>Medical and paramedical personnel,</li>
<li>Hospitals, healthcare centres.</li>
</ul>
<p>They have similar but not identical needs and expectations.<br />
<br />
<ins>Patients:</ins></p>
<ul>
<li>Needs: to have a better health or quality of life,</li>
<li>Expectations: secured devices/services, which are not labyrinthine systems.</li>
</ul>
<p><ins>Medical and paramedical personnel:</ins></p>
<ul>
<li>Needs: to cure or take care of patients,</li>
<li>Expectations: secured devices/services, which help them in their daily work.</li>
</ul>
<p><ins>Hospitals, healthcare centres:</ins></p>
<ul>
<li>Needs: to provide connected devices to their personnel (even if they're reluctant :-)),</li>
<li>Expectations: to buy secured devices/services.</li>
</ul>
<p><br />
End-users (patients and caregivers) have in common to be passive regarding cybersecurity. It is not their problem. When it becomes their problem, it is usually too late, data have already leaked.<br />
While it is preferable to have security by design, training of end-users is part of the measures of protection. It is difficult to make end-users actors of the cybersecurity but it is a mandatory and endless task.
<br /></p>
<h4>Architectural choices and constraints</h4>
<p>Coming back to technical considerations, we can see that the more the architecture of a connected object is complex, the more we have stakeholders involved in cybersecurity.<br />
Let's see an example, with a connected object used at home, which transfers data for monitoring/processing by medical personnel.<br />
<img src="https://blog.cm-dm.com/public/Cybersecurity/cybersecurity_medical_device_architecture_example.png" alt="cybersecurity_medical_device_architecture_example.png" style="display:table; margin:0 auto;" title="cybersecurity_medical_device_architecture_example.png, Dec 2016" /></p>
<h5>MD manufacturer</h5>
<p>In this case, the MD manufacturer has to build a technical and organizational solution, which is able to meet its expectations: a safe and secure connected medical device architecture.<br />
This is its responsibility. The implementation can be delegated to subcontractors. But the responsibility of the manufacturer cannot be "subcontracted".<br />
<br />
In the example of the schema above, the goal is to use patient data acquired by connected objects to help the caregivers in their work:</p>
<ol>
<li>Raw medical data of the connected medical devices are transferred to a gateway,</li>
<li>The gateway preprocesses data, like filtering or compression and send them to the application server,</li>
<li>Data are routed to the application server through the telco modem and the internet,</li>
<li>The application server stores health data in a database and processes data (syntheses, comparison to encyclopedic data...),</li>
<li>The medical/paramedical personnel can consult and assess data by the means of a care management interface.</li>
</ol>
<p>We consider here that the connected weight scale, blood pressure monitor, software on the application server, and care management interface belong to the same manufacturer. The gateway, the database, and the application server infrastructure (a server in a datacenter) are subcontracted.<br />
<br />
Let's see how the outsourced parts will have consequences on cybersecurity and on the constraints applied to the manufacturer.</p>
<h5>Database service providers</h5>
<p>In this example, the provider of the database storage service is a MD/HD compliant service provider. The provider is certified for storage of health data.<br />
Its goal is to ensure that the manufacturer won't compromise its own infrastructure. Thus it will add contraints in its service contract (and probably also in the technical solution and/or available APIs) to ensure that the security of its service remains at a validated level of security.<br />
<br />
As a consequence, the manufacturer won't have a lot of choices of technical implementation for its own solution, as the health data storage service providers are not so many on the market. It means also an effort of selection of the provider, to match the technical needs of the manufacturer with the capabilities of the platform of the provider.<br /></p>
<h5>Gateway service provider</h5>
<p>Let's assume in this example that the gateway is part of a MD/HD compliant service. The gateway is rented by its manufacturer, and is capable of managing secured wireless health data transfer over bluetooth and wifi.<br />
Likewise, the gateway service provider will add constraints to ensure that its device will remain safe and secure. As a consequence, the manufacturer will have to adapt the data protocols and interfaces on its connected objects and on the application server.</p>
<h5>Telco service providers</h5>
<p>Even if some telco firms begin to provide health data transportation and storage services, let's assume that we use a generic data transportation service. Their goal is to avoid any involvement in the management of health data. As a consequence, the manufacturer shall identify and implement technical measures ensuring a safe and secure data transfer over their infrastructure. While the telco providers already implement cybersecurity measures on their network, the manufacturer will probably have to ensure that the data transfer remains compliant with MD/HD regulations.</p>
<h5>Application server hardware provider</h5>
<p>Most application servers are now hosted in datacenters. Let's assume that the application server runs on a cloud server different from the database server. This cloud server is managed by a provider without compliance to MD/HD regulations.<br />
On the HD regulation side, the manufacturer shall ensure that health data will never be stored in the application server. They can be cached in memory during data processing but data are stored on the compliant database.<br />
On the cybersecurity side, the application server shall be secure, as well as its interfaces with the database server, the gateway and the care management interface. The server will be hosted in a secured datacenter, thus physical/hardware security measures will be implemented by the server hosting provider. But the manufacturer will have to implement software security measures.</p>
<h4>Risk management</h4>
<p>The message behind this example is the necessity to perform a risk management oriented to cybersecurity hazards. The manufacturer shall do this risk assessment, and identify the mitigation actions, which depend on the subcontractors.<br />
And the mitigation actions can heavily depend on qualified subcontractors.<br />
<br />
This is a bit new in the domain of software, as software MD manufacturers don't have the habit to outsource their critical processes when software is in production.<br />
This is also a bit new, as many cybersecurity risks and mitigation actions are "located" in the deployment, production and decommissioning phases of the software lifecycle.<br />
<br />
We can make a comparison with manufacturers of physical medical devices, which need to mitigate risks related to devices in contact with the patient, like biocompatibility. They depend a lot on specialized subcontractors for production processes like manufacturing, cleaning and sterilization.<br />
Likewise, manufacturers of connected objects or software on the cloud will more and more depend on qualified subcontractors to mitigate risks related to cybersecurity.<br />
<br />
<br />
The medical device business is changing with more complex and smarter devices, more stakeholders, new regulations brought by health data processing, and more work for the manufacturers to place compliant and secure devices on the market.<br />
<br />
<br />
<a href="https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016">Next time</a>, we will actually see risk management and cybersecurity.</p>https://blog.cm-dm.com/post/2016/12/20/Cybersecurity-in-medical-devices-Part-2-Stakeholders#comment-formhttps://blog.cm-dm.com/feed/atom/comments/197Cybersecurity in medical devices - Part 1 Regulationsurn:md5:5a4ae48b2cdba6f6b1831c276ba061d02016-10-24T16:50:00+02:002016-10-24T16:50:00+02:00MitchRegulationsCybersecurity<p>We begin today a series of posts on cybersecurity in medical devices. Cybersecurity was not a subject before the advent of computerized medical devices. Now that every manufacturer wants its connected medical device, cybersecurity matters!<br />
Let's start with the regulations.</p> <h4>Medical devices, e-health and personal data</h4>
<p>The main characteristic of connected medical devices is their ability to communicate health data. Though some devices may only communicate data on their status, which are not personal data, connected devices communicate above all personal data. Such data can be used for diagnosis or for historical purposes.<br />
Thus regulations applicable to connected devices include the regulations on medical devices but also on personal data, without forgetting regulations on data networks.</p>
<h4>Regulations on cybersecurity</h4>
<p>Following the short discussion above, regulations on cybersecurity cover medical devices, personal data and data networks. Let's see which regulations are applicable in Europe and in the USA.<br />
<br />
<img src="https://blog.cm-dm.com/public/Cybersecurity/.Cybersecurity_Regulations_m.png" alt="Cybersecurity_Regulations.png" style="display:table; margin:0 auto;" title="Cybersecurity_Regulations.png, Oct 2016" /></p>
<h4>USA</h4>
<p>In the USA, the context is simple (compared to Europe :-)). We two main regulations:</p>
<ul>
<li>The 21 CFR, mainly part 820 but also part 806 or part 803, on medical device lifecycle,</li>
<li>HIPAA/HITECH rules on electronic personal health information (e-phi) management</li>
</ul>
<p>The interpretation by the FDA on the implementation of cybersecurity for regulated medical devices can be found <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">in the guidance on the content of premarket submission files about cybersecurity</a> and <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">the guidance on postmarket management of cybersecurity</a>.<br />
These guidances mainly recommend (require?) that:</p>
<ul>
<li>Medical device safety and data privacy shall be addressed during design and development,</li>
<li>Post-market surveillance of medical devices shall include cybersecurity risks.</li>
</ul>
<p><br />
The HIPAA rules can be found <a href="http://www.hhs.gov/hipaa/for-professionals/index.html">here (have a look at the Combined Regulation Text)</a>. These rules are applicable to <a href="http://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html">covered entities and business associates</a>. Depending on the services provided with their medical devices, manufacturers or their subcontractors can be in the scope of business associates. E.g. if the device is used within a health plan. Manufacturers are indirectly impacted by the physical and technical safeguards of the HIPAA (see link to Combined Regulation Text above). These safeguards affect the design of medical devices with rules like:</p>
<ul>
<li>Unique user identification,</li>
<li>Automatic logoff,</li>
<li>Backup and restore,</li>
<li>Export of a copy of health data of a person.</li>
</ul>
<p><br />
Additional useful information on HIPAA is present on <a href="http://hipaacow.org">the HIPAA COW website (funny name but serious website)</a>.<br /></p>
<h4>European Union - present</h4>
<p>There are currently two regulations applicable in the European Union:</p>
<ul>
<li>the 93/42/EC directive on medical devices,</li>
<li>the 95/46/EC directive on data protection.</li>
</ul>
<p>The medical device directive is mute on cybersecurity. And there is no MEDDEV guidance on cybersecurity either.<br />
The data protection directive contains requirements on confidentiality and security of data processing, but not as precise as those of HIPAA.<br />
But these two directives are close to their end of life and will be replaced by new regulations.</p>
<h4>European Union - close future</h4>
<p>The new regulations, which will replace the current directives are:</p>
<ul>
<li>the Medical Device Regulation (MDR), it should be fully applicable in 2020,</li>
<li>the <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AL%3A2016%3A119%3ATOC">2016/679 General Data Protection Regulation</a> (GDPR), it will be fully applicable in May 2018.</li>
</ul>
<p>As seen before <a href="https://blog.cm-dm.com/post/2016/09/02/EU-Medical-Device-Regulation-changes-for-software">in this article</a>, the new MDR raises the bar on cybersecurity for medical device software.<br />
<br />
The GDPR is more stringent on personal data, with lots of requirements, and especially requirements for personal health data, like:</p>
<ul>
<li>the right of an individual to easily access to personal data, to rectify data, 'to be forgotten',</li>
<li>the obligation to conduct a data protection impact assessment (PIA),</li>
<li>the obligation to ensure data protection by design.</li>
</ul>
<p>This new regulation adds a considerable burden to agents manipulating personal data. See <a href="https://medicaldeviceslegal.com/2016/05/29/the-new-general-data-protection-regulation-impact-on-medical-devices-industry/">this excellent article on this blog</a> on how to set a plan to be compliant to this new regulation.<br />
<br />
A third regulation impacts very indirectly the medical devices manufacturers: the <a href="https://ec.europa.eu/digital-single-market/en/network-and-information-security-nis-directive (NIS Directive)">Directive on security of network and information systems</a>. This directive <q>provides legal measures to boost the overall level of cybersecurity in the EU</q>.<br />
Basically, member states shall identify vital IT networks and protect them against threats. Some healthcare networks can be considered vital and thus are in the scope of this directive. As a consequence, stringent cybersecurity measures are required on such networks. Since some connected medical devices can be found on these networks, they will be subject to the cybersecurity measures, that manufacturers will have to implement or follow.</p>
<h4>To sum-up</h4>
<p>Regulations on medical devices and health data are applicable to connected medical devices manipulating health data. Cybersecurity is a concept anterior to connected medical devices, but it is now included in the criteria of compliance to regulations pertaining to medical devices and personal health data.<br />
These regulations bring additional requirements, which affect the design and the post-market surveillance of medical devices. We will see in this series of posts how to implement processes to bring evidence of compliance to cybersecurity requirements.<br />
<br />
<br />
The next article will be on the stakeholders interested in cybersecurity.</p>https://blog.cm-dm.com/post/2016/10/24/Cybersecurity-in-medical-devices-Part-1-Regulations#comment-formhttps://blog.cm-dm.com/feed/atom/comments/196