网络安全评价要提交什么检测证据

结论：证据要能说明「识别了什么风险、做了什么控制、验证了控制有效」

网络安全的证据不是几份扫描报告，它应当构成一条完整的论证链：

识别。 通过威胁建模识别出产品面临的安全风险。

控制。 针对识别出的风险设计安全措施。

验证。 通过测试证明这些措施确实有效。

维护。 上市后持续监测和响应新出现的问题。

只提交扫描报告而没有前后文，审查方无法判断扫描覆盖了什么、漏掉了什么、发现的问题怎么处理了。 这是常见的证据组织问题。

威胁建模的作用

威胁建模是整条链的起点，它回答：产品有哪些资产需要保护、有哪些入口可能被利用、可能受到什么威胁。

要识别的内容包括：

资产。 患者数据、设备配置、控制指令、密钥。

入口点。 网络接口、无线连接、物理端口、可移动介质、用户界面、更新通道。

信任边界。 哪些部分是可信的，数据跨越边界时要做什么。

威胁类型。 身份伪造、篡改、否认、信息泄露、拒绝服务、权限提升。

攻击者能力假设。 假设攻击者有什么条件和能力。

「入口点清单」要做全。 容易被漏掉的包括调试端口、维护接口、第三方组件引入的通道、以及物理可及的接口。漏掉的入口就是没有被评估的风险。

安全控制措施

针对识别的威胁，常见的控制措施类别：

「调试端口关闭」在量产产品上是基本要求，但实际中遗留开放的调试接口并不少见——开发时为方便留着，量产时忘了关。这是一个成本为零但效果明显的控制措施。

验证活动

证明控制措施有效，需要的验证活动包括：

功能验证。 安全功能是否按设计工作——认证是否真的拦截未授权访问、加密是否真的启用。

漏洞扫描。 对产品和其第三方组件做已知漏洞扫描。

渗透测试。 模拟攻击者尝试突破防护。

模糊测试。 向接口输入异常数据，看是否导致崩溃或异常行为。

配置审查。 出厂配置是否安全——默认密码、开放端口、不必要的服务。

第三方组件分析。 组件清单及其已知漏洞状态。

「默认密码」是配置审查的重点。 使用统一默认密码且不强制修改的产品，等于没有认证。这一项应当在验证中明确检查。

证据的组织

建议按论证链组织证据：

威胁建模文档。 识别的资产、入口、威胁。

安全需求。 针对威胁确定的安全要求。

设计说明。 安全措施如何实现。

验证报告。 各项验证活动及结果。

追溯表。 威胁—控制—验证的对应关系。这张表是证据链完整性的直接体现。

剩余风险说明。 未完全消除的风险及其可接受性论证。

上市后计划。 监测、响应、更新的安排。

「追溯表」建议一定要做。 有了它，审查方能快速确认每个识别出的威胁都有对应的控制和验证；没有它，就要在多份文档间反复对照。

第三方组件的管理

现代软件大量使用第三方组件，它们是漏洞的主要来源之一：

建立组件清单。 所有组件及其版本，包括间接依赖。

持续监测漏洞。 组件的新漏洞会不断披露。

评估影响。 新漏洞是否影响本产品（取决于是否使用了受影响的功能）。

更新策略。 发现影响时的处理流程和时限。

生命周期管理。 组件停止维护时的替代计划。

「间接依赖」容易被漏掉。 直接引入的组件又依赖其他组件，这些间接依赖同样可能带来漏洞。清单要覆盖完整的依赖树。

上市后的持续要求

网络安全与其他安全属性的一个区别是：威胁环境是动态的。 今天安全的产品，明天可能因为新漏洞的披露而变得不安全。

所以上市后的要求包括：

漏洞的持续监测；影响评估与响应；安全更新的发布机制；用户的通知方式；以及对已发现问题的处理记录。

「安全更新的发布机制」要在设计阶段就考虑。 产品如果没有安全的更新通道，发现漏洞后就无法修复，只能召回或者接受风险。更新机制本身也要保证安全——更新包要签名、更新过程要防止被利用。

与说明书的关系

用户资料中应当包含网络安全相关的内容：

安全配置的指引；默认密码的修改要求；网络部署的建议；备份与恢复；发现安全问题时的联系方式；以及产品的安全支持期限。

「安全支持期限」建议明确给出。 产品在什么时间之后不再提供安全更新，用户需要知道，以便规划替换。

常见的证据不足情形

只有扫描报告。 没有威胁建模，扫描的覆盖面没有依据。

扫描发现的问题未处理说明。 报告里有中高危漏洞但没说怎么处理的。

第三方组件清单不全。 缺少间接依赖。

安全功能未实测。 设计文档说有认证和加密，但没有验证证据。

默认配置未审查。 默认密码、开放端口的状态不明。

上市后计划缺失。 没有说明如何持续监测和响应。

「扫描发现的问题未处理说明」是最容易被追问的。 提交的扫描报告里列着若干漏洞，却没有说明每个漏洞的影响评估和处理决定，审查方必然要问。

与风险管理的关系

网络安全风险应当纳入产品的整体风险管理：

威胁建模的输出进入风险分析。 识别出的威胁是风险源。

安全控制作为风险控制措施。 在风险文件中体现。

验证作为控制有效性的证据。

剩余风险的可接受性论证。

上市后信息纳入风险管理的更新。

分开做两套文件容易不一致，建议把网络安全风险作为风险管理的一个部分来组织。

我们的做法

承接联网产品的委托时，我们会先看威胁建模文档和安全需求，据此确定验证的范围。 没有威胁建模就做扫描，扫描的覆盖面就没有依据。

验证项目上，我们建议把「出厂配置审查」作为必做项——默认密码、开放端口、调试接口这三项检查成本很低，但它们是实际攻击中最常被利用的入口。

如果你有联网产品需要做网络安全相关的验证，想先理清证据范围，可以把产品架构和接口清单发过来一起讨论，或者直接联系：132 4819 8029。能力范围见服务介绍，送检要求见送检要求，其他问题见常见问题。

English version

Conclusion. Cybersecurity evidence is not a handful of scan reports; it should form a complete chain of reasoning. Identification, through threat modelling, establishes the security risks the product faces. Control designs security measures addressing those risks. Verification demonstrates through testing that the measures work. And maintenance continues monitoring and responding to newly emerging problems after launch. Submitting scan reports without that context leaves a reviewer unable to judge what the scanning covered, what it missed and how findings were addressed. This is the common problem in how evidence is organised.

The role of threat modelling. Threat modelling begins the chain, answering which assets need protecting, which entry points might be exploited and what threats could arise. Identify assets, covering patient data, device configuration, control commands and keys. Identify entry points, covering network interfaces, wireless connections, physical ports, removable media, user interfaces and update channels. Identify trust boundaries, establishing which parts are trusted and what must happen when data cross a boundary. Identify threat types, covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. And state assumptions about attacker capability. Make the entry point list complete: debug ports, maintenance interfaces, channels introduced by third-party components and physically accessible interfaces are all easily missed, and a missed entry point is an unassessed risk.

Security controls. Common categories addressing identified threats include identity and access, covering authentication, authorisation, session management and privilege levels; data protection, covering encryption in transit and at rest and integrity checking; communication security, covering protocol selection, certificate management and port management; software integrity, covering firmware signing, secure boot and update verification; logging and audit, covering security event recording and log protection; resilience, covering exception handling, degraded operation and recovery; and physical security, covering interface protection and disabling debug ports. Disabling debug ports is a basic requirement for production units, yet open debug interfaces left in place are not rare, retained for development convenience and forgotten at production. It is a control costing nothing with an obvious effect.

Verification activities. Demonstrating that controls work requires functional verification, confirming that security functions operate as designed, that authentication genuinely blocks unauthorised access and that encryption is genuinely enabled. Vulnerability scanning covers the product and its third-party components against known vulnerabilities. Penetration testing simulates an attacker attempting to defeat the protections. Fuzz testing feeds malformed data to interfaces to see whether crashes or abnormal behaviour result. Configuration review examines whether the factory configuration is secure, covering default passwords, open ports and unnecessary services. And third-party component analysis covers the component list and the vulnerability status of each. Default passwords are the focus of configuration review: a product with a uniform default password and no enforced change effectively has no authentication, and this should be checked explicitly.

Organising the evidence. Organise it along the chain of reasoning. A threat model document covering assets, entry points and threats. Security requirements derived from the threats. A design description of how the measures are implemented. Verification reports covering each activity and its results. A traceability table linking threat to control to verification, which demonstrates the completeness of the chain directly. A residual risk statement covering risks not fully eliminated and why they are acceptable. And a post-market plan covering monitoring, response and updates. The traceability table is worth producing: with it, a reviewer quickly confirms that every identified threat has a corresponding control and verification, and without it the reviewer must cross-reference several documents repeatedly.

Managing third-party components. Modern software uses third-party components heavily and they are a principal source of vulnerabilities. Build a component list covering all components and versions including indirect dependencies. Monitor vulnerabilities continuously, since new ones are disclosed constantly. Assess impact, determining whether a new vulnerability affects your product, which depends on whether the affected functionality is used. Define an update policy with a process and timescale for responding. And manage lifecycle, planning replacements when components cease to be maintained. Indirect dependencies are easily missed: components you include depend on others, and those can carry vulnerabilities too, so the list must cover the full dependency tree.

Continuing obligations after launch. Cybersecurity differs from other safety attributes in one respect: the threat environment is dynamic. A product secure today may become insecure tomorrow through disclosure of a new vulnerability. Post-market obligations therefore include continuous vulnerability monitoring; impact assessment and response; a mechanism for releasing security updates; a means of notifying users; and records of how identified problems were handled. Consider the update mechanism during design: a product without a secure update channel cannot be fixed once a vulnerability is found, leaving recall or risk acceptance as the only options. The update mechanism must itself be secure, with signed packages and a process that cannot be exploited.

Relationship to the instructions. User documentation should include security configuration guidance; the requirement to change default passwords; network deployment recommendations; backup and recovery; contact details for reporting security problems; and the product's security support period. State the support period explicitly: users need to know when security updates will cease so that they can plan replacement.

How we handle it. For connected products we review the threat model and security requirements first and set the verification scope from them. Scanning without a threat model leaves the coverage without a basis. On verification items we suggest making factory configuration review a standing item: checking default passwords, open ports and debug interfaces costs very little, and those are the entry points most often exploited in real attacks.

Send us the product architecture and interface list and we will work through the evidence scope. Phone or WeChat: +86 132 4819 8029.