IMDRF/CYBER WG/N60FINAL:2020 医疗器械网络安全的原则和实践
2022-09-13 09:09:08 2 举报
IMDRF/CYBER WG/N60FINAL:2020 Principles and Practices for Medical Device Cybersecurity 医疗器械医疗器械网络安全的原则和实践 标准学习笔记
作者其他创作
大纲/内容
上市前部分：主要针对医疗器械制造商
上市后部分：包括对所有利益相关者的建议
介绍
包括独立软件和软件组件的网络安全
仅限于考虑对患者造成伤害的可能性
范围外：企业网络安全不在本文档范围之内
GDPR介绍
GDPR.EU
GDPR.模板.检查表
GDPR.模板.隐私通知
GDPR.模板.删除请求表单的权利
GDPR.模板.数据处理协议
范围外：其他类型的危害（例如与破坏数据隐私相关的危害）很重要，但不属于本文档的范围
范围
对个人，组织或政府有价值的实体或数字实体
3.1 \t资产
尝试销毁，暴露，更改，禁用，窃取或未经授权访问资产或未经授权使用资产的行为
3.2 \t攻击
提供有关实体所声称的特征正确的保证
3.3 \t认证方式
实体所声称的属性
3.4 \t真实性
授予特权，包括授予访问数据和功能的特权
3.5 \t授权
授权实体可按需访问和使用的属性
3.6 \t可用性
替代或不作为设备设计一部分实施的风险控制措施，而部署的特定类型的风险控制措施
3.7 \t补偿风险控制措施（同步补偿控制）
补偿性风险控制措施可以是永久性或临时性的，例如，直到制造商可以提供包含其他风险控制措施的更新
不向未经授权的个人，实体或过程提供或披露信息的财产
3.8 \t保密
研究人员和其他有关方面与制造商合作，以寻找降低与漏洞披露有关的风险的解决方案的过程
3.9 漏洞披露机制（CVD）
一个声明保护信息和系统免受未经授权的活动（例如访问，使用，公开，破坏，修改或破坏）的程度，以使与机密性、完整性和可用性相关的风险，在整个生命周期中保持在可接受的水平。
3.10 \t网络安全
产品的生命周期阶段，从制造商不再销售产品开始，超过制造商定义的使用寿命，产品已经过正式的EOL流程，包括通知用户。
3.11 \t寿命终止（EOL）
产品的生命周期阶段 从制造商终止所有服务支持活动开始，并且服务支持不会超出此范围。
3.12 \t终止支持（EOS）
除了基本安全性以外的临床功能的性能，其中损失或降级超出制造商指定的限制会导致不可接受的风险。
3.13 \t基本性能
定义的通过漏洞破坏信息系统安全的方法
3.14 \t利用
属性，自创建，传输或存储以来，未经授权就不得更改数据
3.15 \t诚信
无法合理防御当前网络安全威胁的医疗设备
3.16 \t陈旧医疗设备（同步旧版设备）
证明要求保护的事件或动作及其原始实体的发生的能力
3.17 \t不可否认
人身伤害或对患者健康的损害
3.18 \t病人危害
当入侵，是由于不当或非法收集和使用有关该人的数据，而导致的侵犯其私生活或事务的自由
3.19 \t隐私
潜在的违反安全性的情况，当存在可能违反安全性并造成伤害的情况，能力，动作或事件时存在
3.20 \t威胁
探索过程，以破坏，泄露，修改数据或拒绝服务的形式暴露任何可能对系统造成损害的情况或事件
3.21 \t威胁建模
对医疗设备软件进行的纠正性，预防性，适应性或完善性修改
3.22 \t更新
通过提供客观证据确认已满足特定预期用途或应用的要求
3.23 \t验证
通过提供客观证据确认已满足指定要求
3.24 \t确认
可以被一种或多种威胁利用的资产或控件的弱点
3.25 \t漏洞
CERT：计算机应急响应小组
CSIRT：计算机安全事件响应小组
ISAO：信息共享分析组织
CVSS：通用漏洞评分系统
定义
从最初构想到EOS，应在医疗设备生命周期的各个阶段都考虑与网络安全威胁和漏洞相关的风险。
在TPLC的各个阶段中评估和缓解网络安全风险，包括但不限于设计、制造、测试和上市后监测活动。
医疗器械网络安全是制造商、医疗保健提供商、用户、监管者和漏洞发现者等利益相关者之间的共同责任。
所有利益相关者必须了解自己的责任，并与其他利益相关者密切合作，以在TPLC中持续监视、评估、缓解、交流和应对潜在的网络安全风险和威胁。
网络安全信息共享是TPLC处理安全医疗设备的基本原则
鼓励所有负责任的利益相关者积极参与ISAO组织，以促进网络安全事件、威胁和漏洞的协作和交流
一般原则
在设计阶段主动解决网络安全威胁，这些设计输入可以来自产品生命周期的各个阶段，例如需求捕获，设计验证测试或上市前和上市后的风险管理活动，还有确定安全需求
应考虑该设备如何与其他设备或网络接口通讯
应考虑可验证所有输入（不只是外部）的设计功能，并考虑与仅支持不太安全的通信的设备和环境的通信，
应考虑如何确保与设备之间的数据传输安全，以防止未经授权的访问，修改或重放。
1.安全通讯
例如连接到家庭网络设备或旧式设备。
有线连接、无线通信；接口方法包括：Wi-Fi、以太网、蓝牙、USB等
例如，设备/系统之间的通信将如何相互认证；如果需要加密，如何防止未经授权的重复先前发送的命令或数据；如果在预定时间后终止通信会话是否合适。
应考虑存储在设备上或从设备传输的安全相关数据，是否需要某种级别的保护
应考虑是否需要采取机密性风险控制措施，来保护通信协议中的消息控制/排序字段，或防止损害加密密钥材料。
2.数据保护
例如加密；例如密文存储密码
应评估系统级体系结构，以确定是否需要设计确保数据不可否认性的功能
应考虑设备完整性的风险
应考虑使用诸如反恶意软件之类的控件来防止病毒、间谍软件、勒索软件、以及在设备上执行的其他形式的恶意代码。
3.设备完整性
例如支持审核日志记录功能
例如未经授权对设备软件进行修改
应考虑用户访问控制，以验证谁可以使用该设备，或允许将特权授予不同的用户角色，或在紧急情况下允许用户访问。
此外，不应在设备和客户之间共享相同的凭据。
4.用户认证
身份验证或访问授权的示例包括密码，硬件密钥或生物识别信息，或其他设备无法产生的意图信号。
应建立并传达用于实施和部署定期更新的过程
应考虑如何更新或控制操作系统软件，第三方软件或开源软件
应计划如何响应超出其控制范围的软件更新或过时的操作环境
应考虑如何更新设备，以防止新发现的网络安全漏洞。例如，可以考虑更新是需要用户干预还是由设备启动，以及如何验证更新以确保对设备的安全性和性能没有不利影响。
5.软件维护
例如可能在不安全的OS版本上运行的医疗器械软件
概要
应考虑采取控制措施，以防止未经授权的人员访问设备。
6.物理访问
例如，控件可能包括物理锁；或物理上限制对端口的访问；或者不允许在不需要身份验证的情况下使用物理线缆进行访问。
应考虑允许设备检测，抵抗，响应并从网络安全攻击中恢复的设计功能，以保持其基本性能。
7.可靠性和可用性
《设计其产品时应考虑的一些设计原则》
5.1 安全要求和架构设计
在医疗设备风险管理过程中，也应考虑影响设备安全和基本性能，对临床操作产生负面影响或导致诊断或治疗错误的网络安全风险。
网络安全风险管理流程图
AAMI TIR57：2016中的安全风险管理流程
有关可能的映射，请参见ISO / TR 24971：2020附件F。
可以是作为整体风险管理的一部分执行的专门风险管理过程；也可以是ISO 14971：2019风险管理过程的组成部分，并适当地映射了漏洞，威胁和其他与安全相关的术语。
a.网络安全漏洞的可利用性；
b.如果要利用该漏洞的患者伤害的严重性；
这些分析还应考虑补偿性控制措施和风险缓解措施。
风险分析：应着重于通过考虑以下因素评估患者伤害的风险：
制造商应在整个产品生命周期中考虑网络安全风险，威胁和控制。
如果适用，则可以将网络安全要求与特定设备的网络安全威胁和漏洞交叉引用，前提是这些要求可以缓解已确定的危害。
安全风险评估
威胁建模是用于识别，枚举和缓解设备和系统中潜在威胁所带来的风险的过程。
a.我们在建什么？
b.有什么问题吗？
c.我们该怎么办？
d.我们做得足够好吗？
在生成威胁模型和根据OWASP的指导时，设备制造商应考虑回答与网络安全有关的四个基本问题：
例如，如何对其进行攻击
在确定，威胁建模期间，可能出问题的地方时，制造商应考虑软件和硬件的意外或恶意配置错误
威胁建模包括对风险的考虑，包括但不限于与供应链（例如，系统组件），设计，生产，部署（例如，进入医院环境）和维护有关的风险。此外，创建足够详细的系统图有助于理解如何将网络安全设计元素合并到设备中，从而进一步帮助进行威胁建模。
威胁建模
例如，将设备连接到并非旨在这样做的Internet
在设计和开发中发现的已知常见漏洞和暴露（CVE）应该使用一致的漏洞评分方法进行分析和评估。
文字介绍
中文介绍
3.1版评分方法
漏洞公布举例
网页捕获_16-5-2021_14750_nvd.nist.gov.jpeg
打分截图
举例
常见漏洞公布平台
将严重性与 “风险” 混淆
CVSS 及其相关标准和示例是为企业信息技术系统开发的，没有充分反映临床环境和潜在的患者安全影响。
局限性
将 CVSS 应用于医疗设备的标尺
基于 Web 的在线计算工具
将 CVSS 应用于医疗设备的专栏
CVSS介绍
TSRC.pdf
腾讯TSRC
360SRC
其他评分系统（仅供参考）
漏洞评分
例如，通用漏洞评分系统（CVSS）或任何将来广泛采用的漏洞评分系统
风险评估将设计与威胁建模，患者伤害，缓解和测试联系起来。因此，重要的是建立安全的设计架构，以便可以适当地管理风险。此评估中可以利用许多工具和方法，包括但不限于：
5.2 TPLC的风险管理原则
AAMI TIR57：2016，
IEC TR 80001-2-2，IEC TR 80001-2-8，
ISO 27000系列以及NIST发布的资源（例如NIST的安全软件开发框架）
安全测试是安全开发框架的组成部分；有关测试注意事项的其他详细信息可以以下标准中找到。
a.在开发过程中，在软件组件/模块上执行目标搜索，以查找已知漏洞或软件弱点
b.进行技术安全分析（例如，渗透测试）
c.完成漏洞评估
《设计其产品时应考虑的一些高级注意事项》
例如，定期安全测试可以包括： 静态代码分析； 动态分析； 健壮性测试； 漏洞扫描； 或软件组成分析
例如，这些工作包括：通过模糊测试来识别未知漏洞的工作； 或检查替代入口点，例如通过读取隐藏文件，配置，数据流或硬件寄存器
这包括对漏洞对其他内部产品的影响分析（即变体分析），对策的确定以及漏洞的补救或缓解
5.3 安全测试
包括：主动监控，识别和解决漏洞和漏洞利用；在产品开发的上市前阶段应制定计划，并在整个制造商组织中保持理想状态
a.TPLC警惕性
b.漏洞披露
c.更新和修复
d.恢复
e.信息共享
该计划应解决：
主动监视和识别新发现的网络安全漏洞，评估其威胁并采取适当的措施
一个正式的过程，用于从漏洞发现者那里收集信息，制定缓解和补救策略，并向利益相关者披露存在的漏洞以及缓解或补救方法
概述如何更新软件，或如何应用其他补救措施，以定期或响应已发现的漏洞，来维护设备的持续安全性和性能的计划
针对制造商、用户或两者的恢复计划，以在网络安全事件发生后将设备恢复到正常运行状态。
ISAO
参与信息共享分析组织（ISAO）或信息共享和分析中心（ISAC），以促进有关安全威胁和漏洞的更新信息的通信和共享
5.4 TPLC 网络安全管理计划
a.与适用于预期使用环境的建议网络安全控制相关的，设备说明和产品规格
b.有关备份和还原功能，以及重新获得配置的过程的说明。
c.预期将接收和/或发送数据的网络端口和其他接口的列表，以及端口功能的描述，以及端口是传入还是传出的
d.面向最终用户的、足够详细的，系统图
应包括以下元素：
例如：反恶意软件；网络连接配置；防火墙的使用
请注意，应禁用未使用的端口
5.5.1 标签
a.针对用户的支持基础架构要求的特定指南，以便设备可以按预期运行。
b.使用安全配置对设备进行或可以对其进行加固的说明。
c.在适当的地方，允许安全网络（连接）部署和服务的技术说明，以及关于用户如何在检测到网络安全漏洞或事件后做出响应的说明。
d.在可行的情况下，当检测到异常情况（即安全事件）时，设备或支持系统将如何通知用户的说明。
e.对经过身份验证的特权用户，保留和恢复设备配置的方法的说明。
f.适用时，安全风险和安全配置或使用环境更改的后果-授权用户从制造商下载和安装更新的系统过程的说明。
g.有关设备网络安全支持终止的信息（如果已知）（请参阅第6.6节，旧版医疗设备）。
h.软件物料清单（SBOM），用于通知和支持操作员有关医疗设备中包含的商业，开源或现成软件组件的网络安全性。
安全配置可能包括端点（end point）保护，例如反恶意软件，防火墙/防火墙规则，白名单，安全事件参数，日志记录参数，物理安全检测等。
类似于常见故障的应对方法对照表
安全事件类型可以是： 配置更改 网络异常 登录尝试 异常流量（例如，向未知实体发送请求）
1.SBOM通过一个列表来创建必要的透明度，该列表通过名称，来源，版本和内部版本来标识每个软件组件。2.SBOM使设备操作员（包括患者和医疗保健提供者）有效地管理其资产和相关风险，了解已识别的漏洞对设备（和连接的系统）的潜在影响，并部署对策以维护设备的安全性和基本性能。3.设备运营商可以使用SBOM来促进与设备制造商的合作，以识别可能存在漏洞，更新要求，并执行适当的安全风险管理。4.SBOM还可以通过向潜在购买者提供应用程序中使用的组件的可见性，并确定潜在的安全风险来帮助指导购买决策。5.制造商应利用行业最佳实践来部署SBOM所使用的格式，语法和标记。6.由于SBOM会显示有关医疗设备的敏感信息，因此建议通过可信任的通信渠道进行分发。公认的是，制造商将确定将SBOM与操作员进行通信的可信方式。
5.5.2 客户安全文档
5.5 标签和客户安全文档
描述设备的文档，包括任何接口或通信路径或组件（硬件和软件），以及为减轻与患者伤害有关的网络安全风险而包括的所有设计功能，
5.6.1 设计文档
例如上文第5.1节中概述的那些功能（尤其是原理和假设）导致选择用于访问控制，加密，安全更新，日志记录，物理安全性等的措施。
清楚描述网络安全威胁和漏洞的文档，相关风险的估计，减轻这些风险的现有控制措施的描述以及证明这些控制措施已经过充分测试的证据。
具体而言，应向监管机构提交与网络安全相关的风险管理文档，并参考相关标准（例如AAMI TIR57：2016，AAMI TIR97：2019），结果应与ISO 14971：2019的总体要求保持一致，以确保可以将输出用作整体风险管理的输入。
与网络安全有关的风险管理文件可以包括：• 全面的风险管理文档，例如风险管理报告或安全风险管理报告，其中应包括任何威胁模型以及已识别的网络安全威胁。• 讨论减轻安全风险对其他风险管理的影响。
5.6.2 风险管理文档
测试报告总结了为验证设备的安全性和所有安全控制措施的有效性而执行的所有测试。
特定测试的详细信息，例如交叉引用软件组件或具有已知漏洞数据库的子系统，可以在上面的5.3节中找到，
a.测试方法、结果和结论；
b.安全风险、安全控制和测试之间的可追溯性矩阵，以验证这些控制；
c. 任何标准和SOP/文档的引用。
所有测试文档都应包含：
5.6.3 安全测试文档
设备维护计划的摘要，描述了上市后的流程，制造商将通过这些流程来确保设备在其整个生命周期内的持续安全性和性能。
这些计划的流程可能包括： a.TPLC警惕性、计划或纠正的更新； b.漏洞披露机制； c.信息共享
详见5.4
5.6.4 TPLC 网络安全管理计划文档
5.6.5 标签和客户安全文档
5.6 法规提交文件
详见5.5
上市前注意事项
a.医疗保健提供者采用的网络安全最佳做法
b.针对所有用户的培训教育
6.1.1 医疗保健提供者和患者
除了产品标签和客户安全文档（详见5.5）的信息外，以确保设备的最佳部署和配置
6.1.2 医疗器械制造商
6.1 预期使用环境中的操作设备
a.与医疗设备安全性有关的信息，应与需要该信息的任何人共享
b.共享的信息应保持平衡，以便对不同的利益相关者有意义、可消耗且可操作
c.信息应自由共享，并在适当的时候真诚地进行共享
d.确保尽可能在全球范围内（视情况而定）同步共享全球一致的信息
6.2.1 关键原则
例如：用户，患者，其他制造商，分销商，医疗保健提供者，安全研究人员和公众
例如：有关更安全的芯片组的信息在制造商之间可能很重要，但该信息可能不会为设备的最终用户带来任何好处
不是以考虑商业利益为目的，而是提高患者的安全性
以使各个辖区中的利益相关者能够做出相应的响应
与医疗设备安全性相关的信息的主要接收者，并且经常参与信息传播。
应旨在建立鼓励及时披露与医疗设备网络安全有关的信息的流程，包括在监管机构之间共享信息，以促进全球协调响应。
a.监管者
无论漏洞信息来自何处，都应识别、评估和共享漏洞信息。鼓励制造商共享任何有助于监管机构管理期望并促进监管要求的信息
应旨在同步分发受影响产品的所有监管机构的通知，以确保全球一致的信息，并在适当时确保全球一致的响应。
应该以通俗易懂的语言为目标用户提供适当的阅读水平，以传达有关医疗设备网络安全漏洞和威胁的可行信息。这可能需要包括有关与部署更新或补偿在更新可用之前所需的控制相关的临床收益和风险的信息。
b.医疗器械制造商
c.医疗保健机构
（例如临床医生，患者，护理人员和消费者）
通常是最终决定是否执行更新或其他更正。因此，他们需要清晰而有意义的信息，以便可以做出明智的决定。
d.用户
执法部门、国家安全部门和其他政府机构可能需要，在政府各部门之间共享医疗设备网络安全威胁和漏洞信息，以保护医疗保健和其他关键基础设施。
收集或共享信息或提供安全建议或专业知识的实体，也可以是安全信息和支持资源的重要来源。
可能是政府或私人组织。
e.其他利益相关者，包括政府和信息共享实体
示例包括：信息共享网络（例如，ISAO，ISAC） 传播机构（例如，计算机紧急响应小组（CERT））等。
6.2.2 主要利益相关者
a.有关受漏洞影响的产品及其受影响方式；
b.有关其他产品中使用的组件漏洞的信息；
c.有关可能影响医疗设备安全性的IT设备的信息；
d.有关利用代码攻击、潜在攻击和漏洞可用性的信息；
e.事件确认（例如，“您也看到吗？”）；
f.补丁和其他安全缓解措施（如补偿控件）的可用性；
g.关于使用和集成医疗设备作为临时措施的附加说明
还应包括可能减轻威胁的做法和方法
共享的信息可能包括但不限于：
例如，如何配置IT设备以减轻影响医疗设备的漏洞，或应对已知漏洞的方法。
6.2.3 信息类型
必要时应达成书面协议，共享信息以提高安全性和患者安全；共享信息不得用于获得商业利益；鼓励信息共享的一种方法是提供匿名共享
6.2.4 可信沟通
6.2 信息共享
CERT®协调漏洞披露指南
CVD机制
国家互联网应急中心（CNCERT/CC）
国家信息安全漏洞共享平台（CNVD）
考虑国内情形参考网络安全技术审查指导原则
政府监管机构提供的CVD
漏洞信息来源
漏洞数量不是制造商网络安全状况的指标，而是其响应的一致性和及时性
经制造商评估后，应通过客户公告、通知或其他方式及时开发和分发信息
监视网络安全信息源识别和检测网络安全漏洞
CVD的实践（ISO/IEC 29147）
要求：清晰、一致、可重复
建立和交流漏洞获取和处理流程（ISO/IEC 30111）
根据已建立的安全性(如CVSS)和临床风险评估方法(如ISO 14971)。
漏洞评估
制定补救措施，或
制定漏洞缓解措施和/或补偿控制措施（包括建立报告部署失败和回滚更改的方法）
与监管机构合作（在需要时）
包括范围，影响，基于制造商当前的了解的风险评估，并描述漏洞缓解措施和/或补偿控制措施。
利益相关者应随着情况的变化而更新
向利益相关者传达有关漏洞的描述
制造商应：
6.3.1 医疗器械制造商
6.3.2 监管者
Step1.发现漏洞
Step2.直接向相关制造商或协调的第三方（例如适当的政府实体）报告
Step3.制造商会在评估和补救过程中协调漏洞发现者并与之沟通
Step4.漏洞发现者和制造商应协调公开披露漏洞
只要制造商对发现者做出响应，并且没有证据表明存在使用该漏洞的野蛮攻击，那么CVD意味着该漏洞的发现者只有在修复或采取其他缓解措施后才披露它。
如果发现者在修复之前先披露了漏洞，则发现者和制造商至少应：协调描述可能的缓解措施，使包括医疗保健提供者和/或患者在内的用户，处于最有权力的地位，以使安全可靠地操作其设备
根据美国国家电信和信息管理局（NTIA）/美国商务部的规定，
6.3.3 漏洞发现者
6.3 漏洞披露机制CVD
ISO 14971实践应用于评估漏洞的网络安全风险，然后，通过建立与风险管理相关的网络安全风险管理流程，来确定制造商和监管机构对患者安全的影响。然后，可以制定并商定在患者安全方面具有扎实基础的补救策略。应该在监管机构和制造商之间共享信息
制造商还需要考虑其他利益相关者（不太清楚相关风险管理和相关法规）所感知的风险
a.风险管理
是医疗设备供应链的关键部分，无论软硬件
第三方组件上市后影响医疗器械安全性，制造商需要管理此风险
制造商对第三方组件中漏洞的响应应与对第一方漏洞的响应相同
b.第三方组件
解决漏洞的时间表（例如何时提供修复程序）；
解决机制（例如，补丁部署将如何发生）；
漏洞评分，例如CVSS评分；
可利用性指数（例如，低技能水平）和方法（例如，远程）
临时风险缓解措施
沟通应包括以下关键信息：
例如，在等待更永久解决之前应采取哪些措施，包括使用补偿性控制措施
c.沟通
1.符合当地法规要求；
2.遵守安全和基本性能原则；
3.与利益相关者共享信息，以减少对患者和用户的风险；
5.及时修复相关的风险
所有漏洞修复措施都应遵循以下原则：
当设备缺乏足够的基本或固有保护措施，并且更新不可行时，应采用降低风险的替代方法作为补偿性控制措施
以免阻碍或延迟制造商的补救活动。
可以有足够的时间启动任何监管流程或所需的措施，同时支持便捷的补救措施，并协助管理利益相关者及其期望
制造商应及早告知监管机构，
制造商应协调多个市场的信息发布和补救工作，以最大程度地减少时间间隔
制造商的协调应扩展到与受影响产品经销的所有监管机构的主动沟通
需要补救漏洞的全局协调策略
d.补救措施
示例可能包括在设备和医疗IT网络之间安装防火墙，或从医疗IT网络中删除设备。这些补偿控制通常由医疗保健提供者根据制造商提供的信息来实施。
6.4.1 医疗器械制造商
a.更新
b.注意事项（医疗机构环境）
c.注意事项（家庭医疗环境）
6.4.2 医疗保健提供者和患者
6.4.3 监管者
6.4 漏洞修复
应建立可扩展的事件响应管理策略，根据其产品组合建立事件响应团队
制定详细的事件响应计划
建立事件响应团队
例行测试和执行事件响应
通过汲取的教训来不断提高此功能
所需的活动
参考标准：ISO/IEC 27035-1:2016
基本要求
目的是提供适当的能力，以评估，响应网络安全事件；并从中学习、提供必要的协调、管理、反馈和沟通，以在下一次事件期间及时采取相关行动。
信息技术 安全技术 信息安全事件管理 第1部分:事件管理原则
职责：领导并做出有关网络安全事件响应的重大问题的决策
a）对事件响应的承诺和支持，包括提供必要的资源（人力，财力和物力）
b）审查和批准事件响应政策和计划，并监督实施
c）审查和修订事件响应计划
d）团队的内部和外部协调
主要活动：
Manager小组
职责：操作事件响应
a）建立和计划安全策略；
b）实施安全流程；
c）调整风险优先级；
d）与上级组织和其他第三方组织进行沟通；
e）支持管理；
f）讨论/注册/批准有关目标组织的漏洞报告；
g）执行Manager指导的其他活动。
Planning小组
职责：执行实时安全监控活动
a）日常监控和操作；
b）入侵检测，事件登记和第一响应；
c）执行安全更新；
d）实施安全策略和备份管理；
e）服务台；
f）设施管理；
Monitoring小组
职责：提供诸如实时响应，技术支持之类的服务
a）传播和报告事件；
b）监测系统之间的相关性分析；
c）事件调查和恢复支持；
d）对目标事件的脆弱性分析；
e）执行Manager指导的其他活动。
Responding小组
a）分析事件响应要求；
b）确定事件响应策略和级别；
c）实施事故响应政策和计划；
d）计划事故响应计划；
e）总结事故响应工作和报告；
f）部署和使用事件响应资源；
Implementation小组
职责：执行事件分析
a）为团队和制造商计划漏洞分析；
b）改进安全分析工具和清单；
c）完善监控规则；
d）发行通讯；
Analysing小组
事件响应团队
a.角色和职责
提供制造商的联系信息
事件响应团队应尽可能快速地(考虑当地监管要求)向受事件影响的所有利益相关者提供更新
调查过程中发现犯罪活动应通知当地适用的执法机构
应联系CERT和ISAO，以就全球网络安全攻击和事件进行进一步的协调。
b.沟通期望
6.5.1 医疗器械制造商
a.政策与角色
b.角色训练
c.分析与回应
6.5.2 医疗保健机构
6.5.3 医疗器械监管者
6.5 事件响应
陈旧设备：无法通过更新和/或补偿性控制，合理保护免受当前网络安全威胁影响的医疗设备
遗留设备与网络安全生命周期
陈旧设备与网络安全产品全生命周期
说明
设计和开发期间就开始关注医疗设备网络安全。
1.医疗器械生命周期支持需考虑组成设备的软件和硬件；
为了提供全面支持，MDM应能从相应的软硬件供应商那里获得支持，以解决质量、性能和安全问题的软件/固件更新
MDM应预见在整个使用过程中需要支持产品安全性和有效性的需求
MDM应考虑，在医疗保健提供商预计的设备使用期限内，第三方供应商对组件的支持可能终止，这可能会对制造商支持设备安全运行的能力产生不利影响
2.在安全的开发框架下设计和开发设备，以最大程度地减少将来的陈旧设备数量。
开发阶段
1.监视医疗设备是否存在风险不可接受的漏洞，提供尽力而为的响应，并保持风险管理文件
2.清晰的传达关键生命周期里程碑，包括网络安全EOL，在这些时间点，客户责任应整合到沟通中
MDM发布的EOL之前，应持续提供与当前网络安全威胁相适应的支持
3.主动通知客户第三方供应商对设备组件的支持终止
4.通知客户，在网络安全EOS日期之前持续但有限的支持，超过该日期将作为陈旧设备不再支持。客户沟通的时机应在接近EOL时进行，MDM应通知客户，EOL之后仍可提供的有限支持，并明确告知网络安全EOS日期并将作为医疗保健提供商启用“设备停用/淘汰和业务连续性计划”的提前通知。清晰地沟通有助于医疗保健组织了解其职责以及设备风险，以便他们可以计划设备的退役、更换以及相应的预算。
支持阶段
1.继续传达网络安全EOS日期的时间表，以使客户有足够的时间准备EOS和相关的客户责任。
2.继续执行上述“支持阶段”的1.和3。
监管机构酌情鼓励MDM利用补偿性控制措施，来解决EOL之后的设备安全挑战；以便MDM没有进一步的安全支持时，有足够的时间让医疗保健机构针对EOS进行业务连续性计划。
存在可用且成功部署的补偿控制措施，则不会被视为陈旧设备
有限支持阶段
从MDM到客户的全部责任转移。在此之后，用户不应期望获得任何级别的支持。
支持终止阶段
各阶段的建议
6.6.1 医疗器械制造商MDM
6.6.2 医疗保健机构
6.6 陈旧设备
上市后注意事项
IMDRFCYBER WGN60FINAL2020.pdf
医疗器械网络安全的原则和实践IMDRF/CYBER WG/N60FINAL:2020.03.18
0 条评论
回复 删除
下一页
