ARTICLE · 1104426
CE医疗器械网络安全技术文档应该准备哪些?
对于包含软件、网络通信、无线连接、远程访问或其他数字功能的医疗器械，网络安全技术文档已经成为CE符合性评价的重要组成部分。
但企业在准备资料时经常遇到一个问题：
MDR没有给出一份统一的“Cybersecurity Documentation Checklist”，那到底应该准备哪些文件？
MDCG 2019-16 Rev.1给出的答案并不是固定的文件名称，而是要求制造商能够证明：
网络安全要求已经被识别、风险已经被评价、安全控制已经实施并经过验证，同时相关信息能够持续进入上市后监督和技术文档更新。
MDCG明确指出，技术文档应包含用于证明符合GSPR的网络安全相关信息，并对所采用的解决方案提供相应的justification、verification和validation。
因此，一套合理的CE网络安全技术文档，应围绕整个网络安全生命周期建立。
01
「 产品架构和网络安全边界」
Product Architecture and Cybersecurity Boundaries
网络安全分析的第一步不是漏洞扫描，而是先明确产品本身，制造商需要知道：
实际项目中，这部分通常会形成：
对于网络连接设备，MDCG特别提出，相关安全文档可以包括完整的网络数据流信息，例如协议类型、数据流来源和目的地、地址方案等。
这类文件的目的不是单纯画图，而是明确后续风险分析的Attack Surface，例如：
Ethernet
Wi-Fi
Bluetooth
USB
Cloud
Web Interface
Mobile App
API
Remote Access
第三方服务器
如果产品架构和数据流不清晰，后面的Threat Modeling和Penetration Testing也很难证明其完整性。
02
「 网络安全需求」
Safety, Security, and Effectiveness
Must Be Considered Together
明确产品架构以后，需要进一步定义产品应该具备哪些网络安全能力。
MDCG将“Specification of Security Requirements”作为Secure by Design的重要实践之一，相关安全能力可能包括：
Authentication
Authorization
Encryption
Audit
Data Integrity
Backup and Recovery
Malware Protection
System Hardening
Transmission Integrity
Security Update
Transmission Confidentiality
MDCG还给出了较完整的Security Capabilities示例，包括：
实际项目中，可以将这些要求形成：
Cybersecurity Requirements Specification
或者纳入现有的：
Software Requirements Specification / System Requirements Specification
核心要求不是文件名称，而是这些安全需求能够继续追溯到：
风险 → 设计实现 → Verification&Validation
03
「 Threat Modeling与网络安全风险管理」
Threat Modeling and Cybersecurity Risk Management
这是整个网络安全技术文档的核心。
MDCG指出，Threat Modeling可以用于系统性识别攻击路径、资产以及潜在漏洞，并从攻击者视角分析可能的攻击方式,实际项目中，通常需要形成：
风险分析中通常需要回答：
有哪些资产？
有哪些威胁？
攻击路径是什么？
可能利用哪些漏洞？
可能造成什么Security Impact？
是否进一步造成Safety Impact？
需要什么安全控制措施？
控制后剩余风险是否可以接受？
MDCG明确提出，网络安全风险管理应包括：
04
「 网络安全风险与ISO 14971的关联」
Cybersecurity Risk and Its Link to ISO 14971
这一点在技术文件中非常重要。
网络安全风险不能完全脱离医疗器械传统风险管理,例如未经授权修改输液参数，首先是Cybersecurity问题；但最终可能导致错误输注,就进一步形成患者Safety Risk。
因此需要建立：
Cybersecurity Risk Management和ISO 14971 Safety Risk Management之间的接口。
MDCG Annex IV专门用流程图描述了两套风险管理过程之间的关系：网络安全风险如果可能影响Safety，需要进入安全风险分析；反过来，Safety Control如果对Cybersecurity产生影响，也需要回到网络安全风险管理中重新评价。
所以，在技术文档中非常关键的一点是：
不能同时存在两套完全独立、互不关联的风险文件。
05
「 SBOM及第三方软件组件管理」
SBOM and Third-Party Software Component Management
现代医疗器械软件通常不会全部由制造商自行开发,产品中可能包含：
因此需要清楚知道：产品到底使用了哪些软件组件。
MDCG在安全相关技术信息中明确提到了：Software Bill of Materials（SBOM）,实际项目中，这部分通常建议形成：
对于识别出的漏洞，需要进一步判断：
是否适用于当前产品？
是否可以被利用？
攻击条件是什么？
现有安全控制是否足够？
是否产生新的Safety Risk？
是否需要补丁或其他风险控制？
因此：
SBOM只是起点，不是网络安全组件管理的终点。
06
「 安全设计和风险控制措施」
Security Design and Risk Control Measures
风险识别完成后，需要明确如何进行控制。
MDCG要求网络安全措施尽可能首先通过产品设计实现，而不是完全依赖用户环境，其基本逻辑是：
通过安全设计降低风险
无法完全消除时采取适当保护措施
剩余风险通过安全信息、警告或用户措施进行控制
实际文件中，可以通过一下一些形式体现：
Security Architecture
Security Design Specification
Risk Control Traceability
例如：
这条追溯关系非常重要。
07
「 网络安全Verification & Validation文件」
Cybersecurity Verification & Validation Documentation
设计了安全控制措施以后，还需要证明它真正有效，MDCG明确指出，网络安全Verification & Validation的主要方式之一是测试，可采用：
因此技术文件中通常需要包括：
Cybersecurity V&V Plan
Security Feature Test Report
Vulnerability Scan Report
Penetration Test Report
Fuzz Testing Report
以及针对测试发现问题形成的：
Vulnerability Evaluation / Remediation Evidence
但测试报告不能独立存在，审核真正关注的是：
所以V&V文件最好能够建立清晰的Traceability。
08
「运行环境与Minimum IT Requirements 」
Operating Environment and Minimum IT Requirements
有些产品的安全运行不仅取决于设备本身，还取决于医院或用户的IT环境，MDR Annex I 17.4要求制造商规定软件运行所需的最低：
Hardware
IT Network Characteristics
IT Security Measures
MDCG进一步指出，这些要求应来源于产品风险评估，并清楚记录和传递给用户，可能涉及：
| Firewall
| Encryption
| Anti-malware
| Backup
| Strong Password
| Access Management
| Patch Management
| Traffic Filtering
| Operating System Hardening
| Network Segmentation
这里尤其需要区分：
产品自身必须实现的安全能力和用户运行环境需要满足的安全条件。
MDCG也强调，运行环境中的安全措施通常不应被用于简单弥补产品本身的安全漏洞。
09
「IFU和Security Documentation」
IFU and Security Documentation
网络安全信息最终还需要传递给用户，MDCG提出，IFU和相关用户文档可以包括：
安全配置
操作系统要求
运行环境
网络端口
通信协议
日志
云端数据保护
初始密码修改
安全更新部署
Failsafe Mode
网络安全告警处理
Firewall&Anti-virus建议
Backup / Restore
用户角色及权限
根据产品复杂程度，这些内容可以分别放在以下等文件中：
MDCG还提到，MDS2可以作为向医疗机构提供设备安全信息的一种方式。
10
「上市后网络安全文件」
Postmarket Cybersecurity Documentation
网络安全技术文件不能在CE审核完成后冻结。
MDCG要求制造商持续收集：
Security Incidents
产品漏洞
第三方软硬件漏洞
Threat Landscape变化
并对相关安全风险和Safety Risk进行重新评价。
因此上市后还需要建立相应机制，例如：
Cybersecurity Vulnerability Monitoring
Security Incident Response
Vulnerability Evaluation
Security Update / Patch Management
Post-Market Cybersecurity Surveillance
并根据结果更新：
Risk Management
Verification&Validation
Benefit-Risk
PMS / PSUR
Technical Documentation
MDCG明确要求网络安全内容成为PMS体系的一部分，并通过上市后信息持续更新风险管理和技术文档。
11
「一套完整的网络安全技术文档，
应形成什么逻辑？」
What Should the Logic of a Complete Cybersecurity
Technical Documentation Set Look Like?
从CE审核角度看，真正重要的不是“有多少份文件”，而是这些文件能否形成完整证据链：
因此，企业准备CE网络安全技术文档时，不建议简单套用一份固定模板。
更合理的方式是根据产品的软件架构、通信方式、运行环境、第三方组件和实际网络安全风险，确定适合自身产品的技术文档和验证策略。
[ END ] .
联系我们
Contact us
网络安全服务
Cybersecurity Services
