网络安全风险管理
医疗器械网络安全风险管理决定威胁和漏洞如何影响安全性、有效性和性能。威胁模型、SBOM、漏洞扫描或渗透测试可以支持评估,但任何一个都不是风险评估本身。
风险管理连接安全和性能
FDA 将安全风险管理视为质量体系和器械生命周期的一部分。它不同于 ISO 14971 安全性风险管理,因为安全失效可能是蓄意的,可利用性会随时间变化,伤害也可能通过可用性、完整性、保密性或控制权丧失间接产生。两个过程仍必须相互接口,因为安全问题可能造成患者伤害。
MDCG 2019-16 对欧盟文件采取同样的实际立场:当安全问题可能影响安全性或有效性时,网络安全属于风险管理系统;如果安全控制过弱或过严,安全控制本身也可能产生安全性影响。
患者伤害
FDA 上市后指南把核心患者伤害问题定义为对患者健康的损伤,包括死亡,而不是只看商业影响。
安全性和性能
EU MDR 和 MDCG 证据应解释安全如何影响器械的预期运行、安全性、性能、可用性和用户信息。
威胁建模输入风险评估
威胁模型是识别资产、行为者、数据流、信任边界、接口、威胁、假设、缓解措施和攻击路径的结构化分析。FDA 期望威胁建模支持风险分析活动,而不是成为一项孤立画图工作。
- 威胁模型识别什么可能出错,以及攻击者或意外触发因素在哪里能够到达系统。
- 网络安全风险评估评价风险、控制、剩余风险和接受准则。
- 当利用会影响患者伤害、临床性能或安全运行时,安全性风险过程接收这些安全风险。
- 当新漏洞、部署变化、新接口或新攻击技术改变风险图景时,上市后过程更新模型。
可利用性会改变分析
网络安全风险评估不能只依赖历史概率。FDA 解释,安全风险评估关注可利用性:漏洞被利用的可行性、难易度和技术手段。因此,测试发现的漏洞、CISA Known Exploited Vulnerability、变化的网络路径或新的公开 exploit,即使尚未发生患者事件,也可能改变评估。
上市前评估应把威胁模型连接到网络安全风险评估、安全架构、控制选择、接受准则和测试证据。FDA 允许提交方假设最坏情况可利用性,或在整个产品生命周期内说明合理可利用性评估。
上市后评估从真实信号开始,例如 CVE、研究人员报告、供应商通知或观察到的利用。FDA 上市后指南围绕可利用性、患者伤害严重度、补偿控制,以及剩余患者伤害风险是 controlled 还是 uncontrolled 作决定。
SBOM 不是风险评估
SBOM 识别软件组件和依赖关系。它帮助制造商发现已知组件漏洞、支持状态和受影响版本的暴露。它不显示脆弱组件是否可达、控制是否阻止利用、临床性能是否变化,或剩余患者伤害风险是否可接受。
An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.
NTIA, Framing Software Component Transparency, 2021
SBOM 的贡献
组件身份、版本、供应商、依赖和支持数据帮助识别暴露,并支持漏洞管理。
风险分析的贡献
架构、威胁建模、可利用性、控制证据和患者伤害分析决定暴露对器械意味着什么。
记录之间必须能相互解释
当记录彼此指向时,风险文件最有力。FDA 建议威胁模型、网络安全风险评估、SBOM 和测试文件之间保持追溯关系。欧盟文件应把同一条链转换为 MDR 或 IVDR 技术文件、风险管理、验证、确认、IFU、PMS 和警戒记录。
- 没有剩余风险决定的威胁模型不是完整风险证据。
- 没有架构上下文的风险评估不能显示可达性或控制布置。
- 干净的漏洞扫描结果不能取消对可预见误用、支持状态、更新路径和现场配置的评估。
- SBOM 中的高严重度 CVE 是评估信号,不会自动等于 uncontrolled patient-harm risk。
主要来源
Sources
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final guidance, February 2026
- FDA, Postmarket Management of Cybersecurity in Medical Devices, final guidance, December 2016
- European Commission, MDCG 2019-16 Guidance on Cybersecurity for medical devices
- NTIA, Framing Software Component Transparency: Establishing a Common Software Bill of Materials