Principles and Practices for the Cybersecurity of Legacy Medical Devices
文件编号: IMDRF/CYBER WG/N70
INFO
This content has been machine-translated from the English original.
全文
遗留医疗设备网络安全原则和实践
Document Number: IMDRF/CYBER WG/N70
Source: https://www.imdrf.org/documents/principles-and-practices-cybersecurity-legacy-medical-devices
最终文档
IMDRF/CYBER WG/N70FINAL:2023 遗留医疗设备网络安全原则和实践 编写组 医疗设备网络安全工作组
前言
© 2023年国际医疗器械监管论坛 版权所有。
本作品受版权保护。在遵守本条款和条件的前提下，您可以下载、显示、打印、翻译、修改和复制本作品的全部或部分内容，用于您个人的使用、研究、教育目的，或如果贵组织是组织，则用于贵组织的内部使用，但前提是您或贵组织不得将复制用于任何商业目的，并且保留所有版权声明。如果您使用本作品的任何部分，必须包含以下声明（删除不适用的内容）：
“[翻译或改编]自[插入出版物名称]，[出版年份]，国际医疗器械监管论坛，经国际医疗器械监管论坛授权使用。国际医疗器械监管论坛不对本[改编/翻译]的内容或准确性负责。”
除上述内容外，所有权利均保留，未经国际医疗器械监管论坛（IMDRF）事先书面许可，不得以任何方式（包括电子方式）复制或使用本材料的全部或任何部分。有关复制和权利的请求和咨询应发送给 IMDRF 秘书处。
将本文件（部分或全部）纳入其他文档，或将其翻译成其他语言，并不代表IMDRF的认可。
安德烈·里斯，IMDRF主席
内容
1. 简介 5
2. 范围 6
3. 定义 7
4. 总体原则 11
4.1. 完整产品生命周期框架 11
4.2. 通信 11
4.3. 共享风险管理 11
5. IMDRF 完整产品生命周期框架对医疗设备网络安全的概述 13
5.1. 开发（第一阶段） 14
5.2. 支持（第二阶段） 14
5.3. 有限支持（第三阶段） 14
5.4. EOS（第四阶段） 15
5.5. 评估风险并触发过渡到不同生命周期阶段的框架 15
6. 产品生命周期阶段：责任/期望 17
6.1. 通信 17
6.2. 风险管理 17
6.3. 责任转移 18
7. 支持生命周期阶段：责任/期望 19
7.1. 通信 19
7.2. 风险管理 21
7.3. 责任转移 25
8. 有限支持生命周期阶段：责任/期望 27
8.1. 沟通 27
8.2. 风险管理 28
8.3. 责任转移 29
9. EOS 生命周期阶段：责任/期望 31
9.1. 沟通 31
9.2. 风险管理 32
9.3. 责任转移 32
10. 医疗器械 TPLC 风险管理责任/期望总结 33
11. EOS 阶段后，医疗器械的补偿控制措施考虑 34
11.1. 补偿风险控制措施 34
11.2. 教育 35
12. 参考文献 36
12.1. IMDRF 文档 36
12.2. 标准 36
12.3. 监管指导和草案指导 37
12.4. 其他资源和参考文献 38
1. 简介
《医疗器械网络安全（IMDRF/CYBER WG/N60 最终版：2020，以下简称“IMDRF N60 指南”）》阐述了贯穿医疗器械整个产品生命周期（TPLC）的基础安全原则和最佳实践。在全球范围内采用该指南的前提是，必须成功且一致地实施其中包含的建议。对于该指南中的一些特定挑战，需要特别关注，这对于实现上述目标至关重要，并且是进一步提高医疗器械网络安全在整个 TPLC 范围内的韧性的自然发展。
虽然现代医疗器械的设计受益于改进的网络安全考虑，但今天使用的许多设备——甚至有些设备的使用寿命已经超过制造商的预期寿命——并未针对这些相同的考虑进行设计。这些设备可能对患者构成风险，并且无法通过（例如，修复或更新）来充分缓解这些风险，正如当前的最佳实践所建议的。它们可能缺乏足够的或根本没有安全控制，或者它们在部署时可能具有最先进的安全控制，但——由于医疗技术的长期使用——现在面临无法防御的意外威胁。这些设备，通常被称为“老旧医疗器械”，通常需要不同的方法来在整个 TPLC（医疗器械生命周期管理）中维护网络安全。然而，需要注意的是，设备的使用寿命并不是决定设备是否为“老旧”的唯一因素。换句话说，即使是较新的设备，如果无法合理地防御当前的网络安全威胁，无论其使用寿命如何，在网络安全方面仍然会被认为是“老旧”的。在缺乏足够的人力和资源来有效执行 TPLC 计划的组织中，这种情况并不罕见，这些“老旧”设备及其相关的风险可能会永久存在。
由于“老旧”医疗器械仍在今天提供医疗服务，因此它们可能会对患者安全构成重大威胁。在此背景下，本指南的目的是将 IMDRF N60 指南中阐述的“老旧”设备概念框架转化为可操作的框架，包括为医疗器械制造商（MDMs）和医疗保健提供者（HCPs）等利益相关者提供的详细建议。在此指南的语境下，HCPs 包含医疗服务机构。
本指南旨在为利益相关者提供明确的方法，以识别潜在的旧设备，并提供可行的、可行的方法来维护旧医疗设备的网络安全。本指南旨在为利益相关者提供多种选择，以便在不扭曲任何司法管辖区的监管系统的情况下实施，并且本工作旨在作为 IMDRF N60 指南的补充。
有关旧设备网络安全风险管理的更多建议，请参阅美国健康部门协调委员会 (HSCC) 的《健康行业网络安全——管理旧技术安全 (HIC-MaLTS)》。
2. 范围
本文件旨在提供具体的建议，说明如何将 TPLC 应用于旧设备，以帮助实施前述 IMDRF N60 指南中提出的框架。本文件是 IMDRF N60 指南的补充，相关的医疗设备（包括体外诊断 (IVD) 医疗设备）的范围，以及对潜在的患者伤害的关注保持不变。
它考虑了旧医疗设备中的网络安全，这些设备要么包含软件，包括固件和可编程逻辑控制器（例如，起搏器、输液泵），要么仅存在于软件中（例如，软件为医疗设备 (SaMD)）。需要注意的是，由于大多数监管机构对医疗设备的安全和性能具有管辖权，因此本指南的范围仅限于考虑潜在的患者伤害。例如，影响性能、损害临床运营或导致诊断或治疗错误的威胁均属于本文件的范围。虽然其他类型的损害，例如与数据隐私泄露相关的损害，也很重要，但它们不属于本文件的范围。
| 遗旧设备此前在 IMDRF N60 指导中被定义为无法合理地抵御当前网络安全威胁的医疗设备。因此，本文件仅针对遗旧设备在网络安全方面的应用，而并非所有可能被认为是“遗旧”的设备（例如，医疗设备的旧型号）。
鉴于上述对“遗旧”的定义，目前许多正在使用的设备都将被视为遗旧设备。为了将现状过渡到更理想的未来状态，IMDRF N60 指导建议为遗旧设备制定 TPLC 框架，该框架在本文件中进一步阐述。该框架的一个关键特征是 MDM 和医疗专业人员之间有效的沟通，以便及时且有计划地引入和退役设备，从而最大限度地减少剩余的遗旧设备数量。虽然本指南的范围之外，但 MDM 和医疗专业人员应向患者提供相关的信息，以告知设备的使用生命周期阶段。经销商（例如，重新贴标签的公司）也不在本指南的适用范围内，因为他们通常没有与 MDM 相同的监管义务。
具体来说，本文旨在：
在 TPLC 框架（开发、支持、有限支持和终结支持）的背景下，明确解释医疗器械的传统网络安全，并为 MDM（医疗器械制造商）和 HCP（医疗保健专业人员）在每个阶段明确定义责任；
为 MDM 和 HCP 提供关于沟通（包括漏洞管理）、风险管理和将责任转移给 HCP 的建议；
为 MDM 和 HCP 提供关于终结支持后补偿控制的建议；
为 MDM 和 HCP 提供关于如何处理在 TPLC 框架之前开发的、用于医疗器械网络安全的现有设备，并仍在使用的建议。
正如前文 IMDRF N60 指导所强调的，本文继续认识到网络安全是所有利益相关者（包括但不限于 MDM 和分销商、HCP、用户、监管机构和软件供应商）共同的责任。
需要注意的是，不同类型的医疗器械和监管辖区可能会导致需要考虑特定情况。
3. 定义
本文的用途，IMDRF/GRRP WG/N47 FINAL:2018 和 IMDRF/CYBER WG/N60FINAL:2020 中给出的术语和定义，以及以下定义适用。
应用程序软件：1. 旨在帮助用户执行特定任务或处理特定类型问题的软件，与控制计算机本身的软件不同；2. 解决应用程序问题的特定软件或程序 [ISO/IEC 2382:2015]。
_资产：_对个人、组织或政府具有价值的实体（物理或数字）（ISO/IEC JTC 1/SC 41 N0317, 2017-11-12）。
_可用性：_被授权实体按需可访问和使用的属性（ISO/IEC 27000:2018）。
_补偿性风险控制措施（同义词：补偿性控制）：_一种在替代或缺少作为设备设计的一部分实施的风险控制措施的特定类型（AAMI TIR97:2019）。
注意：补偿性风险控制措施可以是永久性的或临时性的（例如，直到制造商能够提供包含额外风险控制措施的更新）。
- _组件：_一组系统资源，(a) 是系统的一部分（物理或逻辑），(b) 具有明确的功能和接口，并且(c) 被视为独立于系统其他部分（例如，通过政策或规范）（ISO 81001-1:2021）。
注意：在医疗设备领域，组件包括任何旨在作为成品、包装和标记设备的原材料、物质、部件、软件、固件、标签或组装。
_保密性：_信息不会被未经授权的个人、实体或流程访问或披露的属性（ISO/IEC 27000:2018）。
_配置：_信息处理系统的硬件和软件的组织和互连方式（ISO/IEC 2382:2015）。
_配置管理：_协调的活动，用于指导和控制配置（ISO/IEC TR 18018:2010）。
_协调性漏洞披露（CVD）：_研究人员和其他相关方与制造商合作，以找到减少与漏洞披露相关的风险的过程（AAMI TIR97:2019）。
注意：此过程包括报告、协调和发布有关漏洞及其解决方案的信息。
网络安全： 指信息和系统免受未经授权的活动（如访问、使用、披露、中断、修改或破坏）的保护，使得相关的保密性、完整性和可用性风险在整个生命周期内保持在可接受的水平。（ISO 81001-1）
停用： 从实际使用中移除（ASTM E3173-18）。
部署： 项目的阶段，在此阶段，系统投入使用，并解决切入问题（ISO/IEC/IEEE 24765:2010）。
产品生命周期结束（EOL）： 产品生命周期中的一个时间点，从制造商不再销售该产品，且该产品已通过正式的EOL流程，包括通知用户，开始。
注意：产品生命周期结束（EOL）的时间点触发了“有限支持”阶段。
- 产品生命周期结束（EOS）： 产品生命周期中的一个时间点，从制造商终止所有服务支持活动开始，并且在此时间点之后，服务支持将不再提供。
注意：产品生命周期结束（EOS）的时间点触发了“产品生命周期结束（EOS）”阶段。
- 基本性能： 临床功能，除了与基本安全相关的功能之外，如果因损失或退化超过制造商规定的限制，会导致不可接受的风险（IEC 60601-1:2005+AMD1:2012）。
注意：为了维持基本性能，可能需要进行维护、修理或升级（例如，安全或网络安全方面的修改）。
利用（Exploit）: 通过利用漏洞，以一种有定义的方式，破坏信息系统的安全（ISO/IEC 27039:2015）。
固件（Firmware）: 一组指令和相关数据，以功能上独立于主存储的方式存储，通常存储在只读存储器（ROM）中（ISO/IEC 2382:2015）。
完整性（Integrity）: 数据自创建、传输或存储以来，未被未经授权的方式修改的属性（ISO/IEC 29167-19:2016）。
遗留医疗器械（Legacy Medical Device）: 无法合理地保护免受当前网络安全威胁的医疗器械。
生命周期（Life cycle）: 产品或系统的所有阶段，从最初的概念到最终的报废和处置。 (ISO 81001-1:2021)。
对患者的危害: 患者的身体损伤或健康损害（改编自 ISO/IEC 指南 51:2014）。
患者安全: 从不合理的风险中获得患者健康自由（改编自 ISO/IEC 指南 51:2014）。
隐私: 在个人数据被不当或非法收集和使用时，个人生活或事务不受侵犯的自由（ISO/TS 27799:2009）。
产品: 组织可以生产的输出，无需组织与客户之间发生任何交易（ISO 81001-1:2021）。
弹性：一个功能单元在出现故障或错误时，继续执行所需功能的能力（ISO/IEC 2382:2015）。
风险管理：系统地应用管理政策、程序和实践，以分析、评估、控制和监测风险。 (ISO/IEC 指南 63:2019)。
风险转移：将管理风险因素的责任转移给能够更好地减轻该风险因素的另一组织或功能实体（ISO/IEC/IEEE 24765:2017）。
安全策略：1. 在每个项目组织级别，关于需要知道和访问信息的规则；2. 一组规则，限制一个或多个活动的、一个或多个对象的集合（ISO/IEC 10746-3:2009）。
安全测试：一种测试，用于评估测试项目、相关数据和信息是否受到保护，以防止未经授权的人员或系统使用、读取或修改它们，并且授权人员或系统无法被阻止访问（ISO/IEC/IEEE 29119-1:2013）。
软件材料清单 (SBOM)：列出一个或多个已识别的组件、它们之间的关系以及其他相关信息。
注意：对于没有依赖关系的单个组件，SBOM 只是该组件的清单。“软件”可以被解释为“软件系统”，因此，真硬件（非固件）和非常低级别的软件（如 CPU 微码）也可以包含在内。（NTIA Framing 软件组件透明度：建立通用的软件材料清单 (SBOM) 2021-10-21）。
- 软件组件：一个通用的术语，用于指代一个软件系统或一个元素，例如模块、单元、数据或文档。（IEEE 1061）
注意：一个软件组件可能包含多个单元，或包含多个低级别的软件组件。
- 第三方软件：由被认可为独立于相关方的个人或机构提供的软件。（改编自 ISO/IEC 25051:2014）
注意：通常，相关方是指供应商（“第一方”）和购买方（“第二方”）的利益。
威胁：安全可能被违反的潜在风险，当存在可能违反安全并造成损害的情况、能力、行为或事件时（ISO/IEC 指南 120）。
威胁建模：探索性过程，旨在揭示任何可能对系统造成损害（如破坏、数据泄露、数据修改或服务中断）的情况或事件（改编自 ISO/IEC/IEEE 24765-2017）。
总产品生命周期 (TPLC)：医疗器械生命周期的开发、支持、有限支持和终结支持阶段。
注意：一些司法管辖区可能使用不同的术语来表示这些阶段。
- 更新：对医疗器械软件进行的纠正、预防、适应性或完善性修改。
注意 1: 来源于 ISO/IEC 14764:2006 中描述的软件维护活动。
注意 2：更新可能包括补丁和配置更改。
注意 3: 适应性和完善性修改是软件的增强。这些修改不是医疗器械的设计规范。
升级：用更新或更好的版本，或添加新功能，替换设备或设备组件。
漏洞：资产或控制的弱点，可被一个或多个威胁利用（ISO/IEC 27000:2018）。
漏洞管理：识别、分类、优先排序、修复和缓解软件漏洞的循环实践。
4. 总体原则
本部分提供适用于所有利益相关者的通用原则，用于考虑在开发、监管、使用和监控医疗设备时。这些通用原则，可以在本指南文件中找到，是改善全球医疗系统（包括旧设备）的网络安全态势的基础。
整个产品生命周期框架
与网络安全威胁和漏洞相关的风险应在医疗设备的整个生命周期中（从开发到EOS）各个阶段进行考虑。 实践表明，临床使用寿命可能超过EOS，在这种情况下，如果医疗专业人员决定在EOS之后继续使用设备，则可能在EOS之后进行报废。 许多情况下，医疗设备的临床实用性超过了其支持性。 所有利益相关者应认识到，一个医疗设备应具有计划的网络安全生命周期，该生命周期包括开发、支持、有限支持和结束支持（EOS）四个阶段。
有限的支持是一个过渡期，旨在让MDM和医疗保健专业人员协调并为最终过渡到不再支持或产品升级/替换做好准备。EOS被认为是医疗设备网络安全责任主要转移到医疗保健专业人员的时间点。在EOS之后，MDM可能仍然负责某些需要根据管辖区法规执行的市场活动（参见第7.2.1.3节以获取更多详细信息）。在医疗设备EOS之前，将会有许多与沟通、风险管理和责任转移相关的活动，以确保MDM和医疗保健专业人员能够充分为每个生命周期阶段做好准备。
沟通
有效的保护免受威胁需要利益相关者之间开放和透明的沟通。MDM应为EOL和EOS做好规划。MDM应尽早告知用户，何时可以预期EOL和EOS，即使在设备采购和安装过程中。及早了解可以帮助用户根据MDM提供的信息，合理地规划EOL和EOS日期，从而了解下一步关于设备维护的措施。在这种情况下，医疗保健专业人员可以选择报废设备，或者承担维护其安全性的额外责任。
在本文档中，与MDM或医疗保健专业人员相关的沟通建议都应被理解为需要这些方或其它利益相关者之间的积极互动和/或参与。提供或传达的信息应主动地发送给对方，或者对方应被积极地告知这些信息是可检索的。不建议，并在可能的情况下应避免使用，只提供信息的沟通政策和程序，而无需主动通知。
共同风险管理
医疗器械网络安全是利益相关者之间的共同责任，特别是制造商（MDM）和医疗保健专业人员（HCP）之间的责任。 在处理遗留设备时，这种共同责任尤为重要。
为了合理管理遗留设备的风险，制造商应设计其设备，以在支持阶段优化网络安全，并在未来 EOS 后最大限度地减少安全风险。 制造商应按照本文件第 7、8 和 9 节对设备进行支持。 医疗保健专业人员应积极与制造商合作，获取 SBOM（软件清单），确保设备按照制造商（包括相关 IT 基础设施）的建议，具有适当的网络安全保障，并确保这些保障得到维护，以及计划设备的 EOS 日期。 那些不再由制造商提供支持的设备，很可能会受到当前和未来的威胁的影响，因此医疗保健专业人员应考虑升级这些设备，使用制造商支持的型号。 欲了解有关 SBOM 的更多信息，请参阅 IMDRF/CYBER WG/N73。
5. IMDRF TPLC 框架概述（医疗器械网络安全）
为了有效地管理网络安全风险的动态性，风险管理应贯穿 TPLC 整个过程，在 TPLC 的各个部分（包括但不限于设计、制造、测试和上市后监测活动）中，对网络安全风险进行评估和缓解。 认识到需要平衡安全和安全。 在整合网络安全控制和缓解措施时，制造商必须确保设备的安全性和基本性能得到维护。
IMDRF N60 指南解释了医疗设备网络安全，并将其置于四个（4）TPLC 阶段的背景下：开发、支持、有限支持和EOS（图 1）。 某些司法管辖区可能使用不同的术语来表示这些阶段。 但是，每个阶段描述的概念应具有普遍适用性。 此外，请注意，TPLC 阶段可能持续不同的时间（例如，支持阶段可能比有限支持阶段更长）。
图 1：作为产品生命周期总计，医疗设备网络安全的高层概念框架
请注意图 1：此外，“客户”一词应理解为在本文中“医疗保健专业人员”的含义。
开发（第一阶段）
第一阶段（开发阶段）是一个上市前阶段，医疗设备制造商（MDMs）被期望采用“安全设计”原则。 医疗设备制造商应进行风险评估、识别威胁、执行安全测试，并减轻风险，以确保设备在整个生命周期内安全有效地运行。 第一阶段的另一个结果是与产品相关的安全文档，以帮助用户安全地操作设备。 产品开发最佳实践不属于本文范围。 参考文献包括但不限于：
(IEC 62443-4-1 (产品生命周期)
IEC 62443-3-2 (安全风险评估)
NIST 800-12
NIST 安全软件开发框架
IEC 81001-5-1: 2021
IEC TR 60601-4-5: 2021
IEC TR 80001-2-8:2016
IEC 62443-4-2:2019
欲了解更多标准，请参阅 IMDRF/CYBER WG/N60 指南。
支持（第二阶段）
[术语表 - 在出现这些术语时，请使用这些确切的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
处于支持阶段（第 2 阶段）的设备定义为：
用于提供患者护理，并且
可以在市场上获得，并且
包含主要软件、固件或可编程硬件组件（例如 CPU），这些组件均由其供应商提供支持[1]。
第 2 阶段的设备应获得全面的网络安全支持，例如软件补丁、软件和硬件更新，以及根据需要提供的支持。
虽然这些设备可能被市场视为“新”或“最先进”，但它们可以在设计中表现出广泛的安全功能。 产品设计中安全最佳实践的整合程度将决定 MDM 能够遵循本文档中概述的支持实践的难易程度。
一个关键的做法是在这一阶段确立的是，通过协调漏洞披露（CVD）流程，识别和通知漏洞。根据支持协议，医疗设备制造商（MDM）还可以通过提供额外的服务（例如，安全监控、备份/恢复等）来支持安全。
并非所有第 2 阶段的支持实践都会在后续的遗留阶段中延续。
有限支持（第 3 阶段）
在有限支持阶段（第 3 阶段），医疗设备应被定义为：
用于提供患者护理，并且
已经被 MDM 宣布为终结生命（EOL）的产品，并且目前不由其 MDM 销售或提供，或者
包含软件、固件或可编程硬件组件（例如，CPU），这些组件 a) 不由其开发者支持，并且 b) 其对设备安全性和有效性的风险已得到缓解，从而使设备能够****合理地保护免受当前的网络安全威胁。
在第 3 阶段，设备 MDM 应该尽可能提供网络安全支持。例如，MDM 可能无法开发其软件的更新或补丁，但他们仍然可以尽可能地应用第三方组件或软件补丁。
这类设备在设计中可能表现出广泛的安全能力。产品设计中安全最佳实践的整合程度将决定 MDM 遵守支持阶段中所概述的支持实践的难易程度。
MDM 应该向用户告知受限制、潜在威胁以及需要由医疗保健专业人员实施的安全保护措施。
[术语表 - 在这些术语出现时，请使用这些确切的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
在第 3 阶段的设备通常需要额外的补偿控制，例如网络控制，与第 2 阶段的设备相比。在第 3 阶段，医疗器械制造商（MDM）和提供者应继续遵循任何可以合理实现的第 2 阶段的实践。
EOS (第 4 阶段)
在 EOS 阶段（第 4 阶段）的设备被定义为：
用于提供患者护理，并且
已经由 MDM 声明为 EOS，并且目前未由其相应的 MDM 销售或推广，或者
包含软件、固件或可编程硬件组件（例如 CPU），这些组件 a) 不受其开发商的支持，并且 b) 其对设备安全性和有效性的风险未得到缓解，导致该设备无法在当前网络安全威胁中得到合理保护。
MDM 应告知用户，在设备进入第 4 阶段之前，他们无法再保证对设备的支持。这些沟通应识别用户可能继承的潜在风险，以及缓解策略和升级机会。
所有医疗设备最终都会进入 EOS 状态。为这一事件做好准备是 MDM 和其客户之间的共同责任，因为设备在超过其网络安全 EOS 的情况下安全使用，很大程度上取决于其部署环境的安全能力。
评估风险以触发过渡到不同生命周期阶段的框架
医疗器械及其软件和其他数字组件，这些组件构成了其组成部分，会随着时间的推移达到终身支持（EOL）/最终状态（EOS）。 经常情况下，这些EOL/EOS日期不会同步：第三方软件组件可能会在销售设备时，明知其支持寿命较短，或者在MDM宣布的EOS日期之前，突然被宣布不再支持。 当第三方软件组件的支持情况在预先已知的情况下，MDM应制定适当的计划，以应对设备设计中组件阶段过渡所带来的风险。 为了管理可能因突然、不一致的EOL/EOS声明和组件状态而产生的风险，MDM可以利用以下框架来评估可能触发不同生命周期阶段过渡的风险：
如果一个设备内的单个组件达到生命周期结束（EOL）/终点（EOS），则这会触发医疗器械制造商（MDM）进行风险评估，以确定是否存在患者安全风险，以及风险类型。
如果没有对患者安全的潜在影响，则该设备将保持在当前生命周期阶段（即，支持或有限支持），并且用户将被告知该部件已达到终身支持（EOL）/终身维护（EOS）状态。
如果存在患者安全影响，且该设备处于支持阶段，则医疗器械制造商（MDM）应尝试通过更新或其它设计变更来降低未支持组件的风险。 在支持阶段，更新或设计变更的目标是，用已支持的替代组件或其它设计变更来替换未支持组件的功能，从而使该设备能够安全地维持其预期用途，直至该设备达到预定的终身支持期（EOS）。 医疗器械制造商的风险评估，以及来自更广泛领域的任何相关威胁信息，应作为决定当前是否适合进行阶段过渡的依据。
如果通过不使用不受支持的组件来降低风险，从而使设备能够得到合理保护，则设备仍可保留在支持阶段。
如果通过降低风险使设备能够得到合理保护，但该降低风险的方法包括使用不受支持的组件，则MDM应将设备过渡到有限支持阶段。 使用利用不受支持的组件的降低风险方法不被认为是最佳实践，应作为最后的手段。 预计MDM应公开沟通这一过渡，并提供必要的详细安全文档，以促进过渡（有关此沟通的更多具体信息，请参见第8.1.1.5节）。
如果存在患者安全影响，且设备处于有限支持阶段，则MDM应尝试降低不受支持组件的风险（例如，通过设计更改或补偿控制）。 MDM的风险评估，以及来自更广泛医疗领域的任何相关威胁信息，应决定在此时是否适合将设备过渡到TPLC阶段。
如果风险得到合理降低，设备可以保留在有限支持阶段，并且用户应知悉该组件已达到EOL/EOS。
如果无法合理降低风险，则设备应过渡到EOS，预计MDM应公开沟通这一过渡（有关此沟通的更多具体信息，请参见第9.1.1.2节）。
上述框架旨在应对突然的第三方组件EOL/EOS声明。 通常，为设备维护提供的软件层面的支持在设备维护计划中进行说明。 软件组件的EOS日期也可能包含在SBOM中，这有助于在TPLC范围内进行医疗设备风险管理。
欲了解有关如何在设备报废（EOL/EOS）后继续使用设备以平衡风险的更多信息，请参阅HSCC HIC-MaLTS的责任转移框架。
6. 产品开发生命周期阶段：责任/期望
本文档的这一部分详细说明了在产品开发生命周期阶段，利益相关者在沟通、风险管理和责任转移方面的责任。
沟通
与旧设备相关的最重要和最被认可的挑战之一是缺乏信息。这种信息缺乏可能与设备的特定技术特征相关，例如安全控制、软件供应链或支持状态。它也可能与组织性挑战相关，例如在组织内部，包括MDM和医疗保健专业人员（HCP）双方，谁负责其持续维护，以及何时、如何以及向谁沟通其安全状态信息。因此，与旧设备相关的MDM、HCP和其他相关方的沟通至关重要。为了满足这一需求，组织应在设备TPLC的多个阶段建立和实施旧设备沟通策略。
MDM的建议
来自不同生命周期阶段的HCP的反馈可以帮助MDM设计未来的设备和设备升级。与后续TPLC阶段相关的额外沟通部分提供建议，以解决在医疗设备被HCP采购和部署后，需要考虑的问题。
医疗保健专业人员的建议
HCP可以在这一TPLC阶段提供关于其临床和网络安全需求和期望的反馈，从而影响MDM的设备开发。
风险管理
MDM的建议
基础安全控制：医疗设备制造商应设计其产品，使安全在整个设备生命周期中得到整合和维护。这可以通过使用安全开发框架来实现。适当的控制领域和具体建议可能包括：
- 基于医疗设备预期用途的安全设计和控制，以及：
安全风险评估
威胁建模
安全测试
面向客户的产品安全文档和沟通
对网络安全漏洞的能力进行售后监控，例如：
漏洞识别
基于设备安全设计、控制和缓解措施的网络安全漏洞风险识别
根据设备风险确保安全补丁和缓解措施的可获得性，例如通过：
与所有受影响用户进行协调和明确的沟通，关于漏洞及其相应的缓解措施
在无法获得安全补丁时，识别其他缓解选项
第三方组件考虑：医疗设备制造商应考虑，第三方供应商对组件的支持可能在医疗器械的使用寿命内结束，这可能会 adversely 影响制造商支持设备安全运行的能力。
医疗保健专业人员的建议
由于他们尚未开始采购流程，因此对医疗器械用户的风险管理建议尚不适用。
责任转移
由于MDM尚未将设备提供给医疗专业人员，因此在此阶段尚无转移责任的建议。知识和支持的传递将在采购讨论期间开始。
7. 售后生命周期阶段：责任/期望
本部分对文件中的利益相关者在售后生命周期阶段的责任，以及与沟通、风险管理和转移责任相关的内容进行了详细说明。
沟通
本部分提供关于医疗器械生命周期支持阶段，医疗器械与医疗机构（MDM）之间应交换的各种类型沟通的建议，以确保持续的安全运行。具体而言，在支持阶段的沟通必须全面。当进入此阶段时，组织应确定需要哪些文档和其他信息，以及何时需要这些信息。这些要求应向对方传达并达成一致。虽然不同组织的具体文档需求可能有所不同，但以下部分提供一般性建议。关于现有或缺失的医疗器械安全能力，一种可能的沟通策略已在 IEC TR 60601-4-5 中描述。
MDM的建议
提供产品安全文档：MDM应在生命周期的开始以及整个阶段提供产品安全文档，以帮助医疗专业人员（HCP）在采购和部署医疗器械时进行风险管理。适当的文档可能包括：
医疗器械安全制造商披露声明（MDS2）；
软件清单（SBOM）（有关 SBOM 最佳实践的更多信息，请参见 IMDRF N73）；
安全测试报告摘要、第三方安全认证或类似文件；
客户安全文档（例如，技术说明，以确保安全部署、操作和维护，包括有关接口、通信协议和网络、云或系统依赖关系的信息）。
提供产品生命周期文档：MDM应在采购和安装过程中，明确说明设备的关键生命周期里程碑，包括（如果可用）设备的网络安全EOL和EOS日期。MDM应尽早提供这些信息。目前的做法建议至少提前2年提供信息，以最好地支持医疗专业人员。MDM可以通过清晰地沟通以下信息来支持医疗专业人员和用户：
受影响的设备
设备的操作系统（们）
部署的设备版本
软件组件的识别
预计的服务变更日期
在变更后可用的任何维护的范围
额外的补偿控制
提供相关更新的产品安全和生命周期文档：随着设备的生命周期，其相关的产品安全或生命周期文档（如第6.1.1节中关于开发阶段的沟通所讨论的）可能会发生变化。在这种情况下，MDM应向医疗专业人员提供相关的更新文档（可能为电子形式），以便他们根据需要调整其风险管理策略，以应对新的或已改变的风险。
提供漏洞和补丁信息：如果发现漏洞，MDM应提供相关漏洞信息，包括适当的缓解措施（例如，软件补丁）。应优先处理高风险漏洞，并及时沟通，以防止对患者或设备造成损害。此外，还应向设备操作人员提供缓解方法（例如，通过空中更新、派遣服务人员安装）和实施说明。
提供第三方组件的积极沟通：医疗设备内的软件和其他数字组件可能在设备本身之前达到EOL/EOS。在这种情况下，对这些组件的支持不足可能会给设备带来风险。为了弥补这些风险，MDM应：
- 跟踪设备中使用的第三方组件的支持状态。
评估如果和当这些第三方组件失去支持时，可能存在的风险。
向医疗保健专业人员沟通新的风险以及可用的缓解措施。
向患者提供沟通：虽然这超出了本文档的范围，但MDM和医疗保健专业人员应在相关情况下，向患者提供EOL/EOS日期和信息。
医疗保健专业人员的建议
识别信息需求：对于所有设备（包括旧设备），医疗保健专业人员应确定他们认为需要哪些信息，以便适当维护和保护设备（详见下文），以及他们应该如何、从哪里获取这些信息，以及向谁提供这些信息。
例如，医疗保健专业人员（HCP）可能会决定，对于特定旧设备，他们需要了解该设备是否会收到更新，更新的持续时间以及何时可能收到这些更新。 从而，HCP 可能会决定，应向医疗保健专业人员的安全和临床工程团队提供信息，以便这些团队能够做出适当的运营和维护决策。
医疗保健专业人员在制定运营策略时，应特别考虑的是责任转移。 在某些情况下，医疗保健专业人员可能会继续使用超过医疗设备管理（MDM）宣布的EOL或EOS日期后的设备。 为了确保设备在安全有效的情况下使用，医疗保健专业人员应主动向MDM询问，关于将未受支持的设备从一方转移到另一方的风险责任。
采购前沟通： 为了让医疗保健专业人员在设备在其设施内的使用期间管理安全，在购买和安装设备之前，MDM应与医疗保健专业人员共享信息，以促进适当的入职和管理。 医疗保健专业人员可能需要要求以下信息：
EOL日期（如果已知）
EOS日期（如果已知）
设备的软件组件（例如，操作系统、第三方软件、应用程序软件）升级策略
设备正常运行所需的端口和服务
可以利用的防火墙规则，用于隔离设备并保持功能
反恶意软件能力以及适当的定义（可扫描的内容）
安全扫描能力以及适当的扫描定义（如何扫描）
安全日志功能
设备备份和恢复程序
接收漏洞通知的方法
管理账户以及通过权限管理工具进行管理的权限
持续沟通： 一旦设备安装并投入使用，需要MDM与医疗保健专业人员（HCP）之间的沟通，以确保设备在其整个生命周期内进行适当的运营和风险管理。在设备生命周期内，HCP应准备接收以下沟通：
漏洞披露，描述评估的风险，并根据需要通过推送机制进行更新
针对已知漏洞的缓解建议
可能会出现在设备上的或通过网络监控可能被发现的，表明已受到攻击的指标
在设备整个生命周期内，以机器可读格式更新的SBOM
在达到不再支持之前，尽快解决过时的软件组件（例如，操作系统、第三方软件）的选项
风险管理
MDM的建议
第三方风险管理： 尽管医疗设备可能处于这些生命周期的任何阶段，但可能存在已过期的组件，甚至不再提供支持。 风险评估应确定对安全、基本性能和网络安全的总体影响。
[术语表 - 在这些术语出现时，请使用这些精确的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
即使存在未受支持的组件且存在可利用的漏洞，医疗设备内部或外部的其他补偿控制措施也可能显著降低被利用的可能性。例如，网络防火墙可以阻止或限制对医疗设备上的网络端口的访问，从而阻止网络漏洞的利用。虽然防火墙是一种选择，但MDM应避免仅依赖防火墙或分段来解决漏洞和控制风险，因为这样做可能会影响患者护理。
- 沟通期望：当医疗设备接近EOL日期时，MDM应向医疗专业人员和监管机构提供清晰的沟通，说明EOL和EOS日期，并向医疗专业人员提供充分的信息，以便他们为EOS生命周期阶段进行规划。除了第7.1.1节中提到的信息外，此生命周期信息还可能包括升级选项。
这些额外的信息可用于支持医疗专业人员继续使用医疗设备所需的风险管理活动。
上市后期望：对于医疗设备，MDM在上市后应完成某些活动，这些期望也适用于医疗设备网络安全。具体而言，这些期望包括：
收集、记录和处理客户投诉（包括维修）
按照监管机构的要求报告不良事件/事故（例如，因设备问题导致死亡、严重受伤，或可能在再次发生时导致死亡或严重受伤的事件）
在必要时执行现场安全纠正措施（例如，召回、修改、更改说明书等）。
在某些情况下（例如，取决于产品生命周期阶段），根据监管要求，MDM可能不会采取正式行动，而是可能只是告知存在网络安全漏洞以及已知的缓解措施。
对于直接连接到患者的医疗设备（例如，持续血糖监测仪），MDM应根据管辖区要求，沟通召回和移除信息。
积极进行风险管理，包括漏洞管理（例如，使用工具、资源和人员，持续监测、解决并沟通对设备安全和安全风险产生影响的网络安全问题）
积极进行风险管理，包括漏洞管理（例如，针对需要时，整合使用工具、资源和人员来解决和沟通重要的安全和安全风险）
持续监测： 在EOS之前，MDM应持续监测医疗设备风险状况的变化，并将这些变化告知医疗专业人员和监管机构，因为这些变化可能会影响安全性、时间表、预算、活动，甚至医疗设备的持续使用。在有限支持阶段，医疗专业人员是否还会收到组件的软件更新，这取决于MDM与医疗专业人员之间的具体协议以及MDM延长EOL日期的能力。
医疗保健专业人员的建议
随着设备在TPLC（产品生命周期）中不断发展，重要的是要考虑围绕风险和漏洞管理不断变化的需求，以及医疗保健专业人员（HCP）如何实施最佳实践以减轻这些风险。 随着威胁环境的不断变化，行动和实践也可能需要相应地改变和发展。 如果没有仔细的规划，遗留设备所带来的风险以及潜在后果会随着时间的推移而增加。 尽管医疗设备的安全是共享责任，但随着设备在其生命周期中，从其传达的EOL（不再支持）和EOS（不再服务）日期开始，医疗保健专业人员可能需要承担更大的责任，以实施围绕设备的安全措施。
基础安全考虑：在支持阶段，基础安全建议变得至关重要。 医疗保健专业人员（HCP）的基础安全建议可能包括：
通过风险评估过程，对设备进行网络安全控制，评估设备的优先级和重要性
进行风险评估，以识别关键设备，这可能还需要额外的网络和物理控制以及定期监控
与MDM（医疗设备管理）保持积极沟通，以获取支持和补丁建议
采用配置管理，以识别所有当前资产、数据流，并跟踪未来的配置更改
维护IT安全监控和补丁流程，以支持网络安全和漏洞修复
通过逻辑和物理安全控制，防止未经授权的访问
网络安全培训和意识项目。
漏洞管理
运行环境考虑： 适当的设备风险和漏洞管理取决于具体的设备及其运行环境。关于访问控制和监控的考虑，请参见下面的段落。
访问控制： 重要的是，设备应仅限于访问 HCP 网络中需要的部分，以便执行其功能。 实施设备访问控制可能会限制设备与网络之间的信息和命令流动，这可能超过必要的范围。 尽管这些控制可能会根据设备类型、其他网络功能以及设备在 TPLC 中的位置而演变，但现有的工具，如下一代防火墙，允许基于一组定义的规则进行动态的网络分割和系统策略执行。
网络分割： 网络还可以根据安全要求和业务需求进行分割。 但是，分割网络可能会限制在任何部分被攻破的情况下，网络内部的任何横向移动。 如果实施网络分割，应考虑分割（包括使用防火墙）对设备功能的影响。
请注意： 许多设备都是设计和制造的，以便与临床应用程序和电子健康记录集成。 通过分割或防火墙来控制遗留设备中的漏洞，会带来管理负担，并可能对患者护理产生负面影响，并降低预期的集成效益。 因此，MDM 应该避免仅依赖分割或防火墙来解决漏洞和控制风险。
多因素身份验证： 实施多因素身份验证，可以强制执行基于角色的网络或设备功能访问。然而，身份验证的模式和速度必须在医疗环境中加以考虑。
监控： 监控网络上设备的活动，可以帮助医疗专业人员防止被入侵，并在发生入侵时提供支持。在设备整个生命周期中，医疗专业人员应实施某种活动监控系统，该系统能够跟踪联网设备的活动，并在某些情况下提供有关潜在异常行为的信息。
注意：这可能的形式包括入侵检测系统、入侵防御系统、系统日志或防火墙日志系统。对于拥有更成熟网络安全态度的医疗专业人员，这些可以纳入安全信息和事件管理系统。医疗专业人员应与 MDM 合作，就使用这些系统的方式进行适当的讨论，因为这可能会影响设备的预期用途。考虑到遗留设备的性质，在设备本身安装和添加监控软件可能不可行，尤其是在使用实时操作系统的情况下。但是，有工具可用于监控与外部设备之间的信息流动，从而可以收集适当的设备行为信息。
- 资产考虑： 关于 EOS 的主动规划应在设备采购讨论中开始，无论 EOS 日期是否已知。使用强大的资产管理系统可以有所帮助。一个易于使用、准确且实时的资产管理系统，将使医疗专业人员组织有足够的时间主动规划任何即将到来的 EOS 日期。对于库存中的每个资产，最好包含以下信息：
当前产品生命周期阶段
预计EOL日期
SBOM (请参阅IMDRF N73，了解有关SBOM最佳实践的更多详细信息)
漏洞状态和软件补丁状态
运行环境（网络图）
维护计划
尽可能自动化某些任务，也有助于临床人员专注于医疗服务。 这种强大的库存管理系统对于医疗服务组织决定在EOL日期之后继续使用该设备也至关重要。 在计划和EOL日期之后，医疗专业人员应了解并接受继续使用该设备的风险。 医疗专业人员应考虑定期进行临床效益/风险分析，将使用EOL日期之后的旧设备与购买新设备或升级设备进行比较，并采取风险补偿措施。
漏洞管理注意事项：如IMDRF N60指导中所述，医疗专业人员应采用基于风险的方法来管理医疗设备网络安全。 这一过程应应用于：
- IT基础设施的开发、维护和升级
考虑设备连接的网络非常重要，并且任何网络设计和架构都应考虑到网络中可能存在的各种设备（包括旧设备），包括实施零信任架构协议，从而提高设备安全性，同时又不阻碍医疗专业人员在需要时及时提供援助。
获取和使用SBOM
医疗器械的架构和设计特性意味着它可能包含来自多个不同来源和供应商的软件和硬件（包括但不限于嵌入式系统、数据记录和硬件组件）。对于将任何设备集成到其网络基础设施中的 HCP 来说，请求 SBOM 非常重要。如果可用，SBOM 将使客户更好地了解设备可能在其 TPLC（产品生命周期）中发展的情况，以及如何更有效地应用风险控制措施和缓解策略。
某些类型的软件或子系统可能存在漏洞，这些漏洞会影响包含它们的任何系统。SBOM 将使 HCP 能够检查设备是否可能受到与设备组件相关的已披露漏洞的影响，而不是整个设备。
随着设备接近 EOL（最终生命周期）和 EOS（最终服务生命周期）日期，对于 HCP 来说，建立一个系统来监控已披露的漏洞及其对正在使用的设备的潜在影响至关重要。
任何新设备在网络上的集成和安装
在将新设备集成到现有网络之前，可能需要进行风险评估。这可能包括决定设备在网络分段中存在、应用访问控制以及对设备活动进行网络监控。
对任何网络设备（包括但不限于医疗设备和连接设备，如笔记本电脑和服务器）的更新/更改。
IMDRF N60 指导提供了多个建议的标准，HCP 可以选择在应用风险管理流程时参考这些标准。
HSCC HIC-MaLTS“挑战与建议”部分包含针对许多这些挑战的具体建议，包括库存管理和SBOM。
报废注意事项：IMDRF N60指南的第6.6.2节概述了医疗设备在TPLC期间的一系列安全建议。当设备接近其EOL时，对于医疗保健专业人员来说，至关重要的是调查是否应该报废该设备，或者承担其持续使用的网络安全风险。
责任转移
随着产品的老化和在TPLC中的流动，重要的是识别从支持和有限支持阶段，到EOS阶段将医疗设备维护（MDM）/医疗保健专业人员（HCP）安全责任转移的过程。 除非设备组件意外被宣布不再支持，否则EOL声明会触发有限支持阶段，该阶段作为MDM/HCP协调的过渡期。有关过渡到不同生命周期阶段的更多信息，请参见第5.5节）。第7.3节提供了针对MDM和HCP的实施建议。
MDM的建议
时间表考虑：作为最佳实践，将安全责任转移给HCP的过程，应在EOS之前大约2-3年开始。 向HCP提供2-3年的通知，有助于HCP进行评估、规划和预算，以进行设备更换。
- 过渡到新/升级支持设备：在支持阶段结束之前，MDM和HCP应协调并为最终过渡到EOS和/或产品升级/更换做好准备。 过渡到支持设备，将维持MDM和HCP之间的共同安全责任。
对于无法由MDM支持且尚未被HCP更换的设备，安全责任将转移给HCP。 为了使HCP能够识别所有可用选项，MDM应识别以下信息：
- 关于因过渡到有限支持阶段以及最终过渡到EOS阶段受影响的医疗设备（s）的详细信息
在EOL/EOS阶段可实施的可配置安全选项
HCP可用的升级选项
软件 (s/w)
部分 - 软件和硬件 (h/w)
完全更换
更换选项和策略
可用的设备型号和功能
医疗保健专业人员的建议
在支持阶段，医疗机构可能希望：
评估他们从网络安全和临床使用角度管理设备的的能力。
识别可能可用的第三方支持，以帮助管理设备。
评估设备更换的机会。
识别可用的其他资源，以支持设备。
8. 有限支持生命周期阶段：责任/期望
本节详细说明了在有限支持生命周期阶段，利益相关者的责任，以及与沟通、风险管理和责任转移相关的内容。
沟通
在有限支持阶段，MDM 与医疗机构之间的沟通应增加。 应向医疗机构提供风险信息，以便他们能够就他们继承的风险做出明智的决定。 还应提供有关缓解和设备更换选项的信息。
MDM的建议
发布客户通知，表明进入有限支持：MDM 应发布客户通知（例如，通过公司网站进行公开披露或直接通知给医疗机构），以表明在网络安全 EOS 日期后，设备将继续提供有限支持，在此日期之后，设备将被视为不可支持且处于遗留状态。 此客户沟通的时间应在接近 EOL 日期时进行，从而为医疗机构提供设备停用和业务连续性规划的提前通知。
发布公开信息，表明转向有限支持：MDM应发布公开通知（例如，通过公司网站或其他永久可用资源进行公开披露），以说明该设备的支持状态。如果设备进入不同的阶段，应更新此通知，以便相关方（包括经销商和可能寻求购买二手设备的组织）能够了解继续使用此类设备可能存在的风险。
继续提供来自支持阶段（第 7.1.1 节）的文档和服务，只要可行且适当。这包括漏洞信息。
提供产品生命周期规划信息：MDM应继续沟通网络安全EOL（最终停止支持）的日期，以便为客户提供充足的时间来为EOL和相关的客户责任做准备。可能的沟通包括：
- 警报，表明某些维护已停止，因为医疗设备（即设备软件）不再提供支持
安全通知和建议
关于补偿控制的设备特定信息
任何因生命周期阶段变化而产生的预期使用限制
提供产品安全文档：除了在支持阶段提供推荐的安全文档（如第 7.1.1.1 和 7.1.1.3 节所述），MDM 还需要提供以下文档：
更新后的安全文档，说明鉴于减少的支持，推荐的补偿控制，这可能包括：
防火墙
VPN
网络隔离
针对设备部署环境的期望。
医疗保健专业人员的建议
应继续 7.1.2.3 中的沟通，并要求 HCP 咨询 MDM 任何关于他们收到的额外和更详细的信息（即 8.1.1）的问题。由于 HCP 可能会评估是否购买二手设备，他们也可能想询问是否有额外的支持，例如通过延长合同或第三方支持。
风险管理
MDM的建议
MDM 应继续执行支持阶段（第 7.2.1 节）中的售后期望和监控活动。然而，主动漏洞管理作为风险管理活动的一部分，其频率和所需的工作量可能会降低。
医疗保健专业人员的建议
在评估是否购买二手或翻新设备时，请考虑 EOL/EOS 风险：HCP 可能会选择购买二手或翻新设备。为了管理任何潜在的网络安全风险，他们应采取以下措施：
调查目标设备是否处于有限支持状态（即，已达到 EOL 日期）或处于 EOS 状态。
如果是这样，医疗专业人员应仔细考虑使用已达到EOL/EOS日期设备的风险。
如果医疗专业人员选择购买该设备，他们应：
确定是否有支持，例如通过延长合同或第三方服务。
如果有支持，医疗专业人员应在与供应商组织的合同中包含要求和/或包含支持的条款。如果供应商无法提供支持，医疗专业人员应考虑如何支持该设备。
- 医疗专业人员在接近EOL时应考虑的问题：
在EOL之后，医疗专业人员将通过MDM的积极沟通以及库存管理系统的通知，了解到设备的EOL日期即将到来。医疗专业人员应进一步为EOL做好准备，并应考虑以下问题，以帮助确定在没有支持的情况下，该设备运行的风险是否得到充分控制。以下问题清单并非详尽无遗。
该设备预计在超出预期使用寿命的时间内用于临床护理的时间跨度是多少？
在该设备预计用于临床护理的时间内，是否有维护成本？
维护成本与升级设备相比如何？
新设备或升级后的设备如何同时改善临床护理并提高网络安全？
医疗专业人员是否有能力维护该设备的安全性？
医疗专业人员是否有足够的财务资源来维护该设备的安全性？
医疗专业人员是否有能力维护该设备的安全性？
如果该设备受到威胁，患者将面临哪些风险？
如果因该设备受到组织影响，患者将面临哪些风险？
如果不使用该设备，并用替代方案替换，患者将面临哪些风险？
该设备是否可以在不连接网络的情况下安全运行？
还可以采取哪些其他控制措施？
为了获取更多建议和考虑，医疗专业人员可以参考HSCC HIC-MaLTS中的责任转移框架。
责任转移
此有限支持阶段为MDM和医疗专业人员提供一个过渡期，以便协调和为最终过渡到终身支持或产品升级/更换做好准备。在此期间，双方评估设备和支持选项，并提出建议，以实现未来的状态。有限支持安排可能适用于在过渡期间保持共同的安全责任。有限支持的可用性和范围可能会有所不同，并且各方应充分理解并认可。如果未来的状态保持不变，并且不受支持的产品继续使用，且无法由MDM提供支持，那么安全责任将由医疗专业人员承担，以支持该设备的持续使用和维护。
网络安全支持责任将转移给医疗专业人员。如果医疗专业人员无法承担某些责任，MDM可以考虑在可行的情况下逐步转移责任。
MDM的建议
为了确保安全责任的平稳转移给医疗专业人员，应审查和评估以下考虑事项：
识别可用的软件更新，以便客户能够应用所有可用的更新（或在EOL/EOS里程碑时提供给客户）。
由MDM提供的安全文档应为医疗保健专业人员提供有用的信息，以便实施网络安全控制。
识别的网络需求，为医疗保健专业人员提供有关设备所需端口和IP地址的信息。
网络需求允许医疗保健专业人员“加强”并阻止所有不必要的端口和IP地址访问医疗设备（从网络）。
可用的产品安全文档（包括SBOM）。
其他相关信息，如有，与医疗设备网络安全最佳实践相关，这有助于客户的网络安全态势。
沟通有限的支持选项，这些选项可能包含：
如果可用，硬件组件的更换（例如，显示器、机柜、硬盘驱动器等）
重新加载软件、恢复设备系统状态
如果可用，添加网络硬件安全设备（与医疗设备分开）
医疗保健专业人员的建议
为了确保安全责任的平稳转移给医疗专业人员，应审查和评估以下考虑事项：
医疗设备的网络安全监控
漏洞管理
实施补偿控制，包括物理和逻辑访问控制
确保部署环境适合充分安全地部署EOS设备
实施事件响应计划
建立业务连续性计划
按照医疗保健专业人员的风险管理流程，定期进行风险评估
9. EOS生命周期阶段：责任/期望
[术语表 - 在这些术语出现时，请使用这些确切的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
本节内容详细说明了在生命周期阶段，利益相关者在与沟通、风险管理和责任转移相关的 EOS 阶段中的责任。EOS 是设备生命周期的重要里程碑，医疗器械制造商（MDM）应了解何时将额外的网络安全责任转移给他们，并相应地做好准备。
沟通
MDM的建议
在设备进入 EOS 阶段时，MDM 应该已告知 HCP 关于 EOS 日期以及设备何时进入 EOS 阶段。在此阶段，额外的网络安全支持责任可能会转移给 HCP。如果 HCP 无法承担某些责任，MDM 可以考虑在可行的情况下逐步转移责任。
提供产品安全信息以进行安全维护：MDM 应该向 HCP 提供相关产品安全信息，以便他们能够在不依赖 MDM 的情况下，更好地管理设备的网络安全风险。这些信息可能包括：
HCP 将承担的任何额外的责任，以确保设备保持安全，这可能包括特定于网站的控制（例如防火墙、网络隔离、VPN）。
在网络安全 EOS 日期之后可用的支持。
设备的可用升级路径。
报废信息：MDM 应该提供信息，使 HCP 能够在未来日期报废设备。
发布公开信息，表明已进入 EOS 阶段：MDM 应该发布公开通知（例如，通过公司网站或其他永久可用资源进行公开披露），以解释设备的支持状态。该通知应定期更新，以便相关方（包括经销商和可能正在寻找购买二手设备的组织）能够了解继续使用此类设备可能存在的风险。
通过主动漏洞管理，适当地向患者告知在上市后获得的风险信息。
医疗保健专业人员的建议
医务人员应向MDM提出关于他们收到的信息的所有疑问（见 9.1.1）。由于医务人员可能正在评估是否购买二手或翻新设备，他们也可能想询问是否有额外的支持，例如通过延长合同或第三方支持。
风险管理
MDM的建议
在上市后，MDM仍然负责根据管辖区法规执行的某些上市后活动（见 7.2.1.3）。如果存在对患者安全的重大风险，例如在勒索软件场景（例如 WannaCry）中，可能需要采取额外的主动风险管理措施[例如，在 7.2.1.3 中所强调的措施]。
医疗保健专业人员的建议
在评估是否购买二手或翻新设备时，应考虑EOL/EOS风险（参见 8.2.2.1）
医务人员在使用设备超过EOL时应考虑的事项：如果医务人员决定使用超过EOL的医疗设备，建议他们：
确保实施一个强大的、合格的、有足够资源（即，能够管理不断增加的风险）的网络安全计划，并获得高级管理层的认可。
确保实施一个完善的库存管理系统，如果可能，应采用自动化。
将旧设备纳入组织的持续风险管理活动中。
主动监控可信的信息来源，例如信息共享分析组织、信息共享和分析中心、信息传播机构（如计算机应急响应团队（CERT））、监管机构、漏洞数据库（例如第三方组件的数据库）等。
增强防护措施，包括但不限于网络分段、用户访问角色、安全测试、网络监控和与网络的断开连接。
定期评估可用的替代产品，并重新评估在设备过时后继续使用的决定。
为了获取更多建议和考虑，医疗专业人员可以参考HSCC HIC-MaLTS中的责任转移框架。
责任转移
MDM的建议
在此阶段，将责任转移给用户的过程已完成。MDM已告知用户该设备已过时，并且已完成责任转移。
医疗保健专业人员的建议
承担/风险接受或过渡到新/升级设备：在各种情况下，医疗专业人员（HCP）经常会继续使用超出预期寿命的医疗设备。 在许多情况下，用户可以清楚地看到设备出现故障或无法按照预期工作，从而触发内部维护或报废。 在其他不太明显的案例中，保护免受威胁的支持也可能消失。 在两种情况下，都存在患者受到伤害的潜在风险。 医疗专业人员必须建立完善的库存管理系统，并且在每个医疗设备的EOS（设备终身）日期临近时，应仔细考虑该旧设备所带来的风险，以及组织内网络安全项目的成熟度。
10. 网络安全TPLC责任/期望总结
上述第6-9节提供了关于MDM和医疗专业人员在网络安全四个阶段（开发、支持、有限支持和EOS）中的责任和期望的详细信息，尤其是在风险管理、沟通和责任转移方面。 此外，第6-9节还描述了MDM在TPLC的各个阶段，对医疗设备网络安全的特定活动，这些活动是MDM应完成的。 图2显示了网络安全TPLC的总结，显示了根据TPLC中责任和期望的转移，所需要的努力程度。
网络安全与产品全生命周期
图2：根据产品生命周期，旧设备框架
11. EOS后对医疗设备的补偿控制考虑
补偿性风险控制措施（也称为“辅助控制”）是一种特定类型的风险控制措施，在设备设计中实施的风险控制措施的替代或缺失情况下使用（AAMI TIR97:2019）。如果发现存在健康和安全风险或其他不符合情况，则MDM应实施进一步的纠正措施、纠正措施以及，如果适用，预防措施，以使设备符合要求。
一旦设备达到MDM宣布的EOL（不再支持），医疗机构（HCP）可能会决定继续使用该设备，尽管存在使用过时技术的风险以及MDM缺乏安全支持。继续使用的理由可能包括但不限于：当设备的使用时间超过其支持期限、市场上没有可行的替代方案或存在预算限制等情况。
如果医疗机构决定在EOL后继续使用该设备，应查阅MDM在有限支持和EOL阶段提供的产品安全文档，该文档描述在第8和第9节中，应查阅MDM在有限支持和EOL阶段提供的产品安全文档，该文档包括适用于该设备本身和运行IT环境的最低补偿性风险控制措施。
补偿性风险控制措施
实施补偿性风险控制措施可能会给医疗机构带来显著的成本，包括技术方面的投入和资源。因此，医疗机构应考虑补偿性风险控制措施的成本与购买新设备的成本和收益进行比较。
表 1 包含通用补偿控制的建议。虽然这些建议是在 EOS 的背景下提供的，但实施的可行性将取决于具体的设备及其使用环境，并且不得损害设备的临床和预期用途。列出的控制措施并非详尽，因此可能需要使用一种或多种控制措施，或将多种控制措施结合使用。在实施补偿风险控制措施时，还应考虑技术创新。
| 控制类型 | 弥补风险控制措施 |
|---|---|
| 物理访问 | 仅允许授权人员访问设备，通过将设备放置在指定区域，并采取适当的物理访问控制措施来限制物理访问。 适当地使用防篡改密封。 |
| 可移动介质 | 通过系统基本输入输出系统/统一扩展固件接口论坛（BIOS/UEFI）、操作系统策略或物理方式，限制使用诸如 USB 驱动器的可移动介质。 |
| 网络隔离 | 将设备与医院网络隔离。 |
| 网络隔离 | 为设备和设备与其他基础设施/服务设置虚拟局域网（VLAN）。 |
| 监控 | 使用入侵检测系统、入侵防御系统或安全信息和事件管理来监控设备和网络，以检测可疑活动。 |
| 远程访问 | 从设备中移除远程访问功能。 |
| 防火墙 | 将设备放置在物理或虚拟防火墙后面，仅为严格必要的网络通信打开防火墙端口。 |
| 反恶意软件 | 在咨询制造商后，在设备上安装反恶意软件解决方案。 对于与网络隔离的设备（独立设备），使用不需要定义更新的解决方案，例如基于人工智能（AI）的反恶意软件解决方案。 |
| 备份和恢复 | 实施备份和恢复程序，以防止因灾难而导致的数据丢失。 |
表 1：弥补风险控制措施的示例
教育
虽然实施技术和物理的补偿控制措施可以帮助在设备退役后保持设备更安全，但同样重要的是，经过培训的员工能够保护医疗专业人员免受网络安全威胁。因此，建议医疗专业人员提供网络安全培训，以在所有用户中提高安全意识并推广网络安全行为。这应包括有关以安全方式操作医疗设备（例如，仅将设备连接到安全的网络）以及如何识别和报告任何异常设备行为（例如，随机关闭/重启、安全软件已禁用）的培训。此外，临床人员应了解设备在被宣布退役后，其安全限制，以及在操作设备时应遵循的最佳安全实践，以降低风险。
12. 参考文献
IMDRF 文档
医疗设备网络安全软件 Bill of Materials 的原则和实践 IMDRF/CYBER WG/N73FINAL:2020 (2022 年 4 月)
医疗设备网络安全 (IMDRF/CYBER WG/N60FINAL:2020 (2020 年 4 月)
软件作为医疗设备：可能的风险分类框架及其相关考虑 IMDRF/SaMD WG/N12:2014 (2014 年 9 月)
医疗设备和 IVD 医疗设备的安全性与性能的必要原则 IMDRF/GRRP WG/N47 FINAL:2018 (2018 年 11 月)
标准
AAMI TIR57:2016 医疗器械安全——风险管理原则
AAMI TIR 97:2019, 医疗设备安全——设备制造商的上市后风险管理
IEC 60601-1:2005+AMD1:2012，医疗电气设备 - 第 1 部分：基本安全和基本性能的通用要求
IEC 62304:2006/AMD 1:2015，医疗器械软件——软件生命周期流程
IEC 62366-1:2015，医疗器械 - 第 1 部分：将可用性工程应用于医疗器械
IEC 62443-3-2:2020, 工业自动化和控制系统 - 第 3-2 部分：系统设计中的安全风险评估
IEC 62443-4-1:2018, 工业自动化和控制系统 - 第 4-1 部分：安全产品生命周期要求
IEC 81001-5-1:2021，健康软件和健康信息系统安全、有效性和安全性——第5-1部分：安全性——产品生命周期内的活动
IEC 80001-1:2021，应用在包含医疗设备的IT网络中的风险管理——第1部分：连接的医疗设备或连接的健康软件的实施和使用中的安全、有效性和安全性
IEC TR 80001-2-2:2012，包含医疗器械的 IT 网络中的风险管理 - 第 2-2 部分：关于披露和沟通医疗器械安全需求、风险和控制的指导
- IEC TR 80001-2-8:2016，包含医疗器械的 IT 网络中的风险管理——第 2-8 部分：应用指导——关于 IEC 80001-2-2 中识别的安全能力的标准指导
ISO 13485:2016，医疗器械——质量管理系统——用于监管目的的要求
ISO 14971:2019，医疗器械——将风险管理应用于医疗器械
ISO/TR 80001-2-7:2015，应用在包含医疗设备的IT网络中的风险管理——应用指南——第2-7部分：关于医疗保健组织（HCP）如何评估其符合IEC 80001-1
ISO/IEC 27000 系列 - 信息安全管理系统
ISO/IEC 27035-1:2016，信息技术——安全技术——信息安全事件管理——第一部分：事件管理原则
ISO/IEC 27035-2:2016，信息技术——安全技术——信息安全事件管理——第二部分：事件响应规划和准备指南
ISO/IEC 29147:2018，信息技术——安全技术——漏洞披露
ISO/IEC 30111:2013，信息技术——安全技术——漏洞处理流程
ISO/TR 24971:2020，医疗器械——应用 ISO 14971 的指导
UL 2900-1:2017，适用于可连接网络的产品的软件网络安全标准，第1部分：通用要求
UL 2900-2-1:2017，适用于可连接网络的产品的软件网络安全标准，第2-1部分：医疗保健和健康系统可连接组件的特定要求
监管指导和草案指导
ANSM (草案)：医疗器械在生命周期中集成软件的网络安全（2019年7月）
中国：医疗器械网络安全审查的预先审查指南（2022年3月）
欧盟委员会：2017/745号关于医疗器械的欧盟议会和理事会法规，于2017年4月5日通过，修订指令2001/83/EC、法规（EC）第178/2002和（EC）第1223/2009，并废除理事会指令90/385/EEC和93/42/EEC（2017年5月）
欧盟委员会：2017/746号关于体外诊断医疗器械的欧盟议会和理事会法规，于2017年4月5日通过，并废除指令98/79/EC和委员会决定2010/227/EU（2017年5月）
FDA（草案）：医疗器械的网络安全：质量系统考虑和预先提交内容（2022年4月）[本指南在N73出版时为草案，不适用于实施。它将被最终指南取代。]
FDA：包含离架软件的联网医疗设备的网络安全（2005年1月）
FDA：为家庭使用的设备的设计考虑（2014年11月）
FDA：联网医疗设备的网络安全事后管理（2016年12月）
德国：联网医疗设备的网络安全要求（2018年11月）
德国（BSI）- 电子健康应用的安全要求技术指南（BSI TR-03161）（2020年4月）
Health Canada：医疗器械的网络安全预先要求（2019年6月）
日本：确保医疗设备的网络安全：PFSB/ELD/OMDE通知第0428-1（2015年4月）
日本：关于确保医疗器械网络安全的指导：PSEHB/MDED-PSD 通知第 0724-1 (2018 年 7 月)
医疗器械协调组 (MDCG) 2019-16：关于医疗器械网络安全的指导 (2019 年 12 月)
新加坡标准委员会技术参考 67：医疗器械网络安全 (2018)
TGA：面向行业的医疗器械网络安全指导 (2019年7月)
TGA：面向用户的医疗器械网络安全信息 (2019年7月)
其他资源和参考
- CERT® 协调漏洞披露指南
https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
- NIST 网络安全框架
https://www.nist.gov/cyberframework
- NIST 的安全软件开发框架 (SSDF)
- NIST 特别出版物 800-12 修订版 1：信息安全简介 (2017年6月)
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-12r1.pdf
- 医疗器械与健康信息技术联合安全计划 (2019年1月)
https://healthsectorcouncil.org/wp-content/uploads/2019/01/HSCC-MEDTECH-JSP-v1.pdf
- MITRE 医疗器械网络安全 playbook (2018年10月)
- MITRE CVSS 医疗领域指南
https://www.mitre.org/publications/technical-papers/rubric-for-applying-cvss-to-medical-devices
- 医疗行业网络安全实践：管理威胁和保护患者 (HICP)
https://www.phe.gov/preparedness/planning/405d/documents/hicp-main-508.pdf
- 医疗行业网络安全：管理遗留技术安全 (HIC-MaLTS)
- 开放网络应用程序安全项目 (OWASP)
https://www.owasp.org/index.php/Main_Page
- 医疗器械安全制造商披露声明 (MDS2)
- ECRI 将 NIST 框架应用于医疗器械的方法
- 美国国家电信与信息管理局 (NTIA) / 美国商务部，漏洞披露态度与行动：NTIA 意识与采用小组的研究报告
免责声明
本文件由国际医疗器械监管论坛制作。对本文件的复制或使用没有限制；然而，将本文件（部分或全部）纳入其他文件，或将其翻译成其他语言，并不代表国际医疗器械监管论坛的认可。
2021 年由国际医疗器械监管论坛版权所有。
- 如果在第 2 阶段意外地宣布某个软件组件为“不再支持/不再维护”，则 MDM 应将设备更新为受支持的版本或替代受支持的组件，以防止过早的阶段过渡。有关此生命周期管理方面的更多信息，请参见第 5.5 节 ↑