【国际视野】欧盟委员会联合研究中心与欧洲网络安全局联合联合发布《网络弹性法案要求标准映射》

CRA 建议书附件一第1 节中的产品网络安全要求；

CRA 建议书附件一第2 部分中的漏洞处理流程要求。

欧洲标准化委员会

欧洲标准化委员会

ETSI

国际标准化组织

国际电工委员会

国际电信联盟

应进行网络安全风险分析，并在产品的整个生命周期内进行监控

产品创建的每个步骤都应考虑到网络安全（如安全编码、安全设计原则等）

应针对产品的数字元素进行漏洞评估

应在产品发布前修复已知的可利用漏洞

如果默认配置包含初始/默认凭证，则应使用复杂和随机选择的密码，每个产品都应不同；

如果默认配置涉及网络安全项目，则应为每个项目采用合理的安全级别；

默认配置应置于不可擦除的存储器中；

应实现将产品配置重置为默认配置的功能；

应根据产品性质和风险分析中确定的相关风险，实施适当的认证和授权系统。

只有经过认证和授权的用户才能访问个人/受保护数据和管理/配置功能。

根据产品的性质和风险分析中确定的相关风险，应禁止未经授权的物理访问。

存储在产品内部存储器中的数据应使用当前的非过时技术进行静态加密

用于发送/接收数据的传输协议应支持加密通信，并在默认情况下启用加密通信

产品应采用对称或非对称加密方案（包括PKI），以确保交换数据的机密性得到保护

应使用当前的非过时技术（如哈希算法）确保存储在产品内部存储器中的数据、程序和配置的完整性。

用于发送/接收数据的传输协议应支持确保在传输过程中发现数据更改的方法（例如MAC）

产品应采用对称或非对称加密方案（包括PKI），以确保交换数据的完整性得到保护

产品应进行自检，以验证相关代码/信息（如固件）的完整性

一般来说，参考GDPR 最佳实践，如

o 不应要求用户提供对执行任务或请求服务并非绝对必要的数据

o 不再需要的数据应立即删除。

产品应加强抵御攻击，如分布式拒绝服务攻击，除其他外，可酌情采取以下措施：

o 反向代理网络分段

o 负载均衡

o 速度限制

o冗余和高可用性解决方案

o备份站点

o 灾难恢复计划

o 尽量减少提供的服务

产品应将外向网络连接限制在严格需要的范围内

产品应采取超时和异常处理等措施，避免向繁忙/无响应的服务发出多个请求

产品的硬件设计应限制所有非严格要求的连接和接口，以执行产品预期执行的各种任务。

如果风险评估要求，物理产品应包括防篡改功能

作为默认配置，产品/服务应关闭所有非必要的网络端口

数字产品中的软件在设计上应避免开放不必要的入口点（如应用程序接口）供外部未经授权的调用者使用

产品的设计应确保未经授权访问某项功能或数据不会自动导致完全访问产品的 所有功能和数据（深度防御原则）

存储在产品内部存储器中的敏感数据应进行静态加密

产品不应存储与执行任务无关或不必要的数据（数据最小化）

产品应包含网络安全相关事件的日志

应记录数据、服务或功能的访问或修改情况

有权限的用户应可访问此类日志

日志应防止未经授权的修改或损坏

分发产品或服务的公司应及时为以下用户提供产品或服务软件组件的安全更新 产品或服务的软件组件的安全更新。

应实现自动检查是否存在更新、安装更新或通知用户是否存在更新的功能。在适用情况下，这应该是默认的初始配置。初始配置。

产品应提供安装/实施更新的安全机制

分发产品的公司应通知用户是否有更新。

应监控整个供应链的网络安全状况，以获取产品所需的组件；

产品软件部分使用的所有库和外部组件，包括其版本号，都应在向用户提供的软件物料清单（SBOM）中列出；

此类软件物料清单(SBOM) 应符合相关标准（如ISO/IEC 5921:2021，也称为SPDX 或CycloneDX 标准）。

如果发现漏洞，应根据标准的严重程度 指标（如 CVSS）

公司可直接修复的漏洞应立即修复，并根据其严重性和所造成的影响 根据其严重性和所造成的风险立即修复

如果在产品的软件组件（包括库和第三方组件）中发现漏洞，应立即更新。如果发现产品的软件组件（包括库和第三方组件）存在漏洞，应尽快准备并发布更新

开发产品或服务的公司应订阅以下机构提供的更新信息 产品或服务的公司应订阅来自 CERT和网络安全组织的更新，并对其进行分析，以发现其产品中的漏洞 产品

开发产品或服务的公司应随时了解库或第三方软件的新版本发布情况。库或其产品/服务中包含的第三方软件组件的新版本发布的最新情况 并在新版本包含安全更新时更新相关软件。

应定期进行漏洞评估，特别是针对那些风险最高的组件 子要求：应定期进行漏洞评估，特别是针对风险最高的组件

在开发或维护软件组件时，应执行自动测试 在开发或维护软件组件时，每当准备新的提交/构建/版本时，都应执行自动测试。集成/持续部署(CI/CD) 技术

每当所分析的某个维度发生重大变化（新威胁、新问题、新挑战）时，都应重新评估风险评估。新威胁、新漏洞等）或发布新产品时，都应重新评估风险评估。

新的 CVE指标应在相关安全更新发布或实施后立即公开发布和传播。

公司应采用并执行CVD 政策

分销产品/服务的公司应该有一个专门用于收集在其产品/服务中发现的漏洞相关信息的联络点。如果公司有联络点，则该联络点应是公司的PSIRT。

分销产品/服务的公司应告知任何相关机构（如国家计算机应急小组/CSIRT）如何及时联系到他们，以便处理与漏洞相关的问题。

应通过自动分发、弹出窗口、通讯等方式让用户了解安全更新的存在。

通知应包含有关修复问题的信息和如何应用更新的说明

安全更新应免费发布

总体而言，现有标准至少部分涵盖了所有CRA 要求。这为我们在考虑已发现差距的基础上再接再厉奠定了坚实的基础；

一般来说，"横向"标准，即不针对特定的使用案例或市场部门，最能满足不同 要求的目的。唯一的例外是 EN IEC 62443系列（与工业控制系统相关）和物联网（IoT）中的一些标准，尽管我们认为针对物联网领域的标准主要是横向标准，因为如今大多数数字设备都与物联网相关；

虽然某些选定的标准与产品设计/开发没有直接关系（例如，EN ISO/IEC 27002 与启动、实施或维护信息安全管理系统的建议控制有关），但它们可能与CRA 有关，因为组织实施这些标准的情况也会反映在该组织生产的产品中；

关于 CRA 附件I 第一份清单中与产品相关的安全要求，认为ETSI EN 303 645标准是最相关的标准之一，为此专门尝试将其与所有要求进行了比对，结果发现该标准在某种程度上涵盖了所有要求，即使存在一些差距。还需注意的是，该标准是专门针对物联网系统的，因此，即使现在许多数字产品具有与物联网环境类似的不同功能，也不能想当然地认为该标准自动适用于所有类别的产品（另见下文关于要求3g 的评论）。就要求的覆盖范围而言，另一个相关标准是EN ISO/IEC 27002（信息安全控制），涵盖了13 项要求中的6 项。此外，EN IEC 62443 系列也提供了相当大的覆盖范围，但它专门针对工业控制系统。

对于漏洞处理要求，附件中的第二个清单EN ISO/IEC 30111（漏洞处理流程）是最相关的，涵盖了8 项要求中的5 项，EN ISO/IEC 29147（漏洞披露）也涵盖了4 项相同的要求。所有这些标准在应用方面都是"横向"的；

在某些情况下，如要求3(b)（通过适当的控制机制，包括但不限于身份验证、身份或访问管理系统，确保防止未经授权的访问），所选标准非常通用，而其他一些标准则更详细地涵盖了特定的使用案例。选择通用性较强的标准，可使当前和未来的使用案例更具灵活性，覆盖面更广。另一方面，具体的和部门性的标准可能更能满足特定领域的特殊限制和要求；

在其他情况下，如3(f)（保护基本功能的可用性，包括抵御和减少拒绝服务攻击），所确定的文件的重点更多的是基础设施要素，而不是用户产品或服务。尽管这些基础设施是提供服务和某些设备功能的核心，但仍需要更具体的标准规定。物联网设备已具备这些标准，但仍处于较高水平；

要求3(g)的重点是最大限度地减少对其他设备或网络所提供服务的可用性的负面影响，物联网领域的相关标准专门解决了这一问题，但同时也提出了这些标准是否具有更广泛适用性的问题。在物联网领域设备高度互联的背景下，这些标准具有明显的相关性。然而，对于其他领域，以物联网为重点的网络安全标准的具体适用性可能需要进一步评估。虽然互联性也是当今多个领域的一个特点，但具体要求、法规和风险可能各不相同，因此有必要采取量身定制的方法或额外措施，以确保充分满足网络安全需求。