FDA-eSTAR网络安全风险管理报告撰写要点

一、基本要求

报告递交位置

路径：eSTAR系统 → 网络安全模块 → Risk Management → Report

该报告与安全风险管理报告相互独立，需分别提交，结论须保持逻辑一致

核心原则：

FDA 2026版指南明确区分Safety Risk Management与Security Risk Management：

Safety：评估事故发生的概率

Security：评估漏洞被利用的可能性（攻击者具有主观故意性）

两项流程并行开展、分别记录、结论互联

二、六大核心板块

（一）威胁建模（Threat Model）

常见问题：仅提供数据流图，缺少方法论说明。

规范要求：

明确标注所采用的方法论（如STRIDE、攻击树、DREAD等）

覆盖产品全生命周期：设计→生产→部署→运维→报废

纳入供应链安全：第三方组件、外包开发、生产环节

声明前提假设（如“假定医院网络环境为敌对环境”）

确保正文与eSTAR系统附件内容一致

（二）网络安全风险评估（Cybersecurity Risk Assessment）

常见问题：沿用安全风险评估的概率模型（如“预计每年发生X次”）。

规范要求：

聚焦漏洞的可利用性（Exploitability） ，而非发生概率

建议采用CVSS评分体系或同等效力的评估方法

明确风险接受准则：何种等级可接受、何种等级须强制修复

参照AAMI TIR57，说明安全风险向网络安全风险的转移逻辑

（三）SBOM及组件风险评估

常见问题：SBOM单独提交，报告正文未做评估说明。

规范要求：

概述SBOM覆盖范围及组件构成

重点针对CISA“已知被利用漏洞目录”中的相关项进行评估

对存在漏洞的第三方组件明确处置方案（补丁修复/补偿控制）

若第三方组件已停止厂商支持，须专项说明风险处置策略

（四）未解决异常评估（Unresolved Anomalies）

常见问题：仅从功能安全角度评估缺陷，未纳入网络安全视角。

规范要求：

对每个未修复的异常，补充网络安全视角的评估

评估维度：该异常若被恶意触发可能导致的安全后果（如拒绝服务、权限提升）

提供每个异常的处理准则及理由说明

（五）安全控制措施汇总

常见问题：描述过于笼统（如仅写“采用加密技术”）。

规范要求：

概述八大安全控制类别的实施情况：

身份认证、访问授权、数据加密

完整性保护、保密性保障、日志审计

系统弹性、安全更新

关键控制须说明具体技术实现（如“传输层采用AES-256加密”）

采用补偿控制替代标准控制时，须详细阐述其合理性与充分性

（六）全生命周期视角及可追溯性

常见问题：报告仅覆盖上市前阶段。

规范要求：

说明上市后风险监测与应对机制

提供文档间可追溯性说明：

威胁模型 → 风险评估 → SBOM评估 → 安全测试报告

明确声明该报告为持续更新文档，非一次性交付物

三、重点注意事项

1. Safety与Security报告不得混用

评估逻辑与控制目标均不相同，不能简单替换标题或复制内容。

2. 文档间可追溯性是审评重点

FDA审评员会进行交叉核对，各文档之间的逻辑对应关系须完整一致。

3. 全生命周期管理意识须贯穿始终

撰写阶段即应考虑上市后的漏洞监测、补丁更新及风险再评估。

四、自查清单

递交前建议逐项核对：

1 报告递交路径是否正确（网络安全模块→Risk Management→Report）

2 威胁建模是否标注方法论并覆盖全生命周期

3 网络安全风险评估是否聚焦可利用性而非概率

4 SBOM是否在报告中做了评估说明

5 未解决异常是否补充了网络安全视角

6 安全控制措施是否具体而非笼统

7 报告是否体现了全生命周期管理意识

8 各文档之间的可追溯性是否明确