首席信息安全官对欧盟《网络弹性法案》的全面解析
by Canonical on 26 September 2024
强有力的、影响广泛的监管政策可以为社会提供安全保障,但也可能带来不确定性。事实证明,《网络弹性法案》(Cyber Resilience Act,CRA)也并不例外。在开源领域乃至更广泛的技术领域,人们对该法案的推行一直有着各种不同的反应——或是担忧,或是焦虑,或是充满希望。
但哪些方面会让人担心呢?CRA 真的会给开源领域带来变化吗?您的团队应该如何针对这项法规做好准备?在本文中,笔者将深入探讨 CRA 及其目的、要求和对开源领域的影响,并就对于 CRA 的准备给出个人的网络安全建议。
什么是《网络弹性法案》(CRA)?
CRA 是欧盟即将出台的一项法规,旨在通过对欧盟 IT 行业实施更严格的网络安全、文档和漏洞报告要求,提高设备安全性。该法规将适用于硬件、设备、软件、应用程序和其他“具有数字连接元素的产品”的开发商、分销商、制造商和零售商。CRA 的要求、规则和规定将覆盖这些产品的整个生命周期。
CRA 旨在为购买或使用具有数字组件的产品或软件的消费者和企业提供保障。随着对此类产品的制造商和零售商作出强制性网络安全要求,并将安全保护延伸至整个产品生命周期,该法案的推行将使安全功能不足这一问题成为过去式。
欧盟《网络弹性法案》
该法案将:
- 针对具有数据组件的产品或软件的上市制定统一规则;
- 针对此类产品的规划、设计、开发和维护建立网络安全要求框架,并明确价值链各个阶段须履行的义务;
- 规定在此类产品的整个生命周期内的谨慎注意义务。
如果您想先自行阅读,则可阅读完整的 CRA 草案文件;如果您只是想查看最相关的要点和要求清单,以及它们如何适用于您,建议阅读 CRA 附录。
下面我们来看一下 CRA 的主要目的,这将有助于理解特定的要求是如何发挥作用的。
CRA 的主要目的是什么?
CRA 有以下四个目的:
- 确保制造商自设计和开发阶段乃至整个生命周期内提高具有数字元素的产品的安全性。
- 确保一致的网络安全框架,促进硬件和软件生产商达到合规性要求。
- 提高具有数字元素的产品的安全属性透明度。
- 确保企业和消费者安全使用具有数字元素的产品。
对于这些受监管产品的制造商和开发商而言,这具体意味着:
- 制造商必须在设备制造前以及销售后确保设备的安全性。
- 公开出售的硬件和软件必须符合新的欧盟合规性标准。
- 硬件和软件必须具有更加清晰明了的关于其组件、设计和安全性的信息和文档。
- 制造商和发行商需报告其产品中的关键漏洞。
- 受监管硬件、软件和数字设备的名单还在增加。
CRA 对您来说意味着什么?
这完全取决于 CRA 中对产品的分类,法案中对企业所生产的数字设备或所提供的服务有诸多分类。最常见的“具有数字元素的产品”将不属于重要类别 I 和 II,这样即可自行完成评估,而重要类别则需要第三方验证,且在某些情况下还需要认证。不管什么类别,都意味着以下 4 个重要方面:
- 您的产品在设计和更新方面必须在整个生命周期中都要满足严格的新安全标准。
- 您将需要遵循一系列新要求,包括风险评估、文档访问、符合性评估和漏洞报告等要求。
- 时间紧迫。
- 如果未遵循这些新要求,则可能面临严重处罚和罚款。
需要遵循的网络安全新标准
CRA 的核心是建立一套新的、更严格的针对软件和数字产品的“欧盟标准”。这些标准(在不同程度上)适用于开发商、制造商、进口商和分销商。
这些新的安全标准简述如下:
- 您需要确保您所构建的产品尽可能安全。产品必须具有最小攻击面。
- 您的设备或产品需要加固。这意味着:其中不存在未经授权的访问;其数据得到加密或保护;其数据和命令无法被拦截或操纵。同时也意味着:您的产品即使受到 DoS 攻击也能继续工作;它不会中断其他设备,即使受到攻击;它还可以通过监控或记录设备中发生的变化来提供安全数据。
- 您的产品需能接收安全更新或回滚。其中包括直接或远程更新,关于更新的用户通知,以及回滚更新或将产品恢复出厂/默认设置的能力。
除此之外,您还需要:
- 遵循新的文档要求,并围绕该文档访问途径加强沟通与交流。
- 提供更透明的软件供应链和正式规范的软件物料清单(SBOM)。您的 SBOM 需具备可访问性和机器可读性。
- 您还需要对您的产品进行风险评估,并完成产品的符合性评估。
- 您还需要制定一套明确的产品安全更新计划和流程,并将产品中的漏洞告知用户和相关欧盟当局。
- 在最长 5 年(或产品生命周期,以较短者为准)的期限内,您需按照要求召回或撤回未达到 CRA 符合性标准的产品。
设计、文档和一致性方面的新要求
CRA 规定了四项义务:
- 风险评估
- 文档
- 符合性评估
- 漏洞报告
I. 风险评估
制造商/开发商必须对其产品进行网络安全风险评估。简单说来,该风险评估用以确定:
- 我们能否交付没有任何已知可利用漏洞的产品?
- 我们能否交付具有“默认安全”配置的产品?
- 产品是否处理尽可能少的数据?
- 产品是否具有最小攻击面?
- 产品是否提供安全更新并通知用户更新?
如果您的设备或产品属于“非重要”类别,则可以自行完成评估。但是,类别 I 和类别 II 的产品必须由独立的第三方进行评估。
II. 文档
CRA 引入了新的文档和产品信息要求。一般而言,制造商或开发商需按要求提供:
- 设计、开发和漏洞处理流程的说明。
- 网络安全风险评估。
- 产品所符合的欧盟统一网络安全标准清单。
- 已签署的阐明符合上述基本要求的“欧盟符合性声明”。
- 记录产品中漏洞和组件的软件物料清单(SBOM)。
III. 符合性评估
根据设备或产品所属的类别,产品需要进行符合性评估,以确保产品符合 CRA 中规定的所有要求。
产品类别 | 要求 |
非重要产品 | 制造商/开发商可以自行完成符合性评估。 |
类别 I 和类别 II 产品 | 评估必须由 “指定机构”,即由欧盟认证的独立审核机构完成。 |
IV. 报告和漏洞处理
根据 CRA 的规定,软件和硬件生产商需按要求在 24 小时内将漏洞报告至欧盟网络安全局(ENISA)。
他们还规定了一系列与产品网络安全漏洞的持续测试、更新和文档相关的其他要求。开发商必须:
- 识别并记录影响到产品或产品中包含的漏洞。并应就产品提供一些明确的地址供用户报告潜在漏洞。
- 拥有 SBOM,其中至少涵盖其顶级依赖项。该 SBOM 需具备可访问性和机器可读性。
- 确保设备可以针对新的漏洞进行安全更新。所提供的更新必须是免费的,且应在发现漏洞后立即发送出去,同时向用户提供有关他们应该采取什么行动的信息。
- 定期测试产品,并及时修复漏洞。一旦完成修复,需要公开披露所修复的漏洞内容(根据 CRA 规定的需制定的新协调公开披露策略进行披露)。您需要提供:
- 漏洞及其严重性的说明。
- 能够有助于用户识别受影响的具有数字元素的产品的相关信息。
- 漏洞的影响。
- 有助于用户修复漏洞的信息。
时间紧迫
为 CRA 新要求做准备的时间已所剩无几。CRA 于 2024 年在官方公报上公布后的第 20 日生效(预计为 5 月初)。法案生效后,硬件和软件产品制造商、进口商和分销商将有最多 36 个月的时间来适应新要求,但制造商的事故和漏洞报告义务方面例外设置了更加有限的 21 个月宽限期。36 个月听起来很长,但您的产品和运营越复杂,要求就越高。
违规行为的处罚和罚款新规
如果发现您违反要求或者未达到要求,您将面临罚款。各个成员国的罚款金额会有所不同,因为每个国家可以自行决定罚款金额并报至 ENISA。然而,当前各国的罚款标准是 500 万至 1500 万欧元或者企业全球年营业额的 1% 至 2.5%(以金额最高者为准),具体取决于违规的严重程度。有关详细信息,请参阅 CRA 第七章第 52 和 53 条“保密与处罚”。
CRA 会影响到哪些设备或产品?
CRA 的影响范围很广,其影响将取决于设备或软件的分类。设备和软件按照其网络安全风险因素以及其访问权限级别或与敏感基础架构、网络、系统的连接级别分为三类,分别是:
- 非重要:根据 CRA 的规定,约 90% 的产品为非重要类别。例如:智能音箱、硬盘、游戏和一些高级编程语言(Python 和 React)。
- 重要类别 I(低风险):密码管理器、防火墙、微控制器、VPN、网络或应用程序管理和配置系统、网络浏览器、远程访问软件、身份管理系统等等。
- 重要类别 II(高风险):操作系统、微处理器、工业防火墙、CPU、容器运行时系统、公钥基础架构和数字证书签发程序、硬件安全模型等等。
如果您想要查看更详尽的特定产品名单及其分类详情,可阅读 CRA 附录 3。
乍看之下,这样的列表可能会让您认为自身的产品不会归属于重要类别,但要注意的是,CRA 对漏洞采取了非常宽泛的描述,其中规定:
“在特定情况下,大型电子信息系统中集成的或所连接的所有具有数字元素的产品都可能成为恶意行为者的攻击媒介。”
这意味着您并没有完全摆脱危险:即使是低级别的硬件或软件,理论上也可能 “助长” 对它们所连接的大型设备或网络的攻击。
因此,即使您生产的是不那么重要的产品,也应该意识到自己要合理地按照 CRA 的要求来设计产品。如果您的产品依赖于其他技术、产品或服务,这些技术、产品或服务在其他方面是安全的或符合法规要求的,但漏洞利用链可能会通过这些技术、产品或服务影响到您的用户,您就更加应该具备这样的意识。
我的产品必须披露或记录哪些信息?
正如上面所提到的,CRA 将要求您记录和披露有关产品或服务的大量信息。大多数此类信息需要在产品上提供。如果无法提供,您需要将信息包含在产品包装或文档中。可以采用新产品贴纸和警示标签的形式,也可以通过在 readme.txt 或用户手册中添加新的章节来阐明相关信息。
最低要求为,如果您的产品具有 “数字元素”,则需要记录并告知以下信息:
- 制造商名称或注册商标。
- 制造商的联系地址。
- 报告或接收产品网络安全漏洞信息的途径。
- 识别产品、用户和安全信息所需的所有信息(如批号或序列号)。
- 产品的预期用途及其基本功能。
- 产品的安全信息和属性。
- 潜在的重大网络安全漏洞风险。
- 产品的软件物料清单及其访问途径。
- 产品的欧盟符合性声明证明。
- 完整的制造商支持和安全更新信息。
- 有关以下内容的详细信息(说明书中或网站上提供):
- 确保产品安全使用的必要措施;
- 产品的变化如何影响数据安全性;
- 如何安装与安全相关的更新;
- 关于如何从设备中删除数据/报废设备的说明。
我需要为 CRA 新要求做哪些准备?
与您的首席信息安全官以及负责安全与合规性的团队一起阅读该法案
与任何 CVE 漏洞或网络安全漏洞一样,您无法为自己未完全了解的情况做好准备。您首先要做的应该是,与法律团队、合规团队及工程师一起,了解已发布 CRA 的最终措辞,并确定 CRA 规定可能适用的领域。不要害怕高估您的监管风险:最好是做好充分准备,并制定具体细致的文档记录和网络安全原则,而不是一味地陷入“安全”赌注,即“措辞不够准确,对我们没有影响”。
做好文档记录
文档记录至关重要。它可以让您的客户知悉您的软件来源、组成和安全性(及其保持安全的方式)。至少,您需要记录以下内容并供公众和欧盟当局访问:
- 设计、开发和漏洞处理流程的说明
- 网络安全风险评估
- 产品所符合的欧盟统一网络安全标准清单
- 已签署的符合上述基本要求的欧盟符合性已签署的阐明符合上述基本要求的“欧盟符合性声明”
- 记录产品中漏洞和组件的软件物料清单(SBOM)
分析并反思自己的网络安全措施
现如今,安全问题不容商量。这样很好,因为这意味着大多数值得信任的开发企业通过履行当前 NIS2、ISO27001 等规定的义务就有可能满足 CRA 的基本网络安全要求。
不过,现在正是深入审视您的评估、规划以及网络安全流程和设计标准的最佳时机。即使您无需根据 CRA 的规定不得不提高自身的网络安全标准,像 CRA 这样的法规也是趋势的一个标志。各种软件、设备和产品的生产商都面临着压力,他们需要展现出安全性、低漏洞且用户和买家可以绝对信任的基础。
制定可靠的内部漏洞报告流程
您需要制定清晰的漏洞报告流程,一经发现立即报告。报告流程应该纳入到您的内部团队章程和政策中。您应该组建一支团队(或者理想情况下,由对漏洞报告有着明确期望的特定团队成员组成的核心队伍),以便在发生最坏的情况时,也不会忘记通知 EU CRA 权威机构,并承担罚款风险。
做好合规性和符合性评估准备
无论您是接受外部测试还是自行评估,都需要制定清晰的内部流程以及编制合规性和符合性评估文档。您需要考虑自身认证和文档的公开访问方式,以及在哪里(readme.txt、产品信息表或者设备上均可)公布可访问地址。
总之,CRA 即将生效,您需要做好准备。根据您产品所属的类别,您和您的团队可能还需要满足额外的评估、安全、文档、补丁、合规性和报告要求。弄清您的数字产品或服务所归属的类别,重新审视您的网络安全实践和设计标准,并深入审视您的内部流程,从而确定如何有效、及时地宣传您的软件供应链和产品信息以及报告新的漏洞。
订阅博客文章
查看更多内容
Charmed PostgreSQL 全面上市
值得信赖的企业级 PostgreSQL Canonical 正式发布 Charmed PostgreSQL,这是一款企业级解决方案,有助于确保安全性,可自动完成 PostgreSQL 数据库在私有云和公共云上的部署、维护和升级。 PostgreSQL 是一个开源数据库管理系统。已在 IT 领域应用超过 30 年。成熟的技术、活跃的社群使其始终成为开发人员的首选 DBMS。 Canonical 推出的 Charmed PostgreSQL 便以此为基础进行构建并提供额外的功能,能够满足您的一切企业需求: 长达 10 年的安全维护和支持 订阅 Ubuntu Pro,即可购买 Charmed PostgreSQL 安全与支持服务。Ubuntu Pro 订阅提供长达 10 年的安 […]
Canonical 为任何 open source Docker 镜像提供 12 年长期支持
“Everything LTS 计划”— Canonical 将根据客户的规格要求构建 distroless Docker 镜像,其中包括 Ubuntu 中未打包的上游组件,并在 24 小时内修复关键的 CVE 漏洞,在 RHEL、Ubuntu、VMware 或公共云 K8s 上畅享长达 12 年以上的支持。 Canonical 将其 LTS 产品扩展到 Ubuntu 的 “deb” 包以外,并推出了一项新的 distroless Docker 镜像设计与构建服务,该项服务为任何开源应用程序或依赖项均提供 12 年的安全维护,无论该软件是否是 Ubuntu 中已打包的软件。 「Everything LTS 计划意味着 CVE 维护将覆盖您的整个开源依赖项树,包括 Ubun […]
您每隔多久会在 Linux 上安装一次安全补丁?
定期应用补丁对于维护安全的环境至关重要,但对于确保 Linux 资产的安全性,并不存在一劳永逸的办法。那么,如何平衡更新频率和运行稳定性呢?有一些策略可通过合规且安全的方式实现安全补丁自动化,甚至适用于限制和监管最严格的环境。在确定安全补丁策略时,有必要了解 Canonical 软件更新发布时间表和安全补丁覆盖周期时间窗口等重要信息。笔者在近期主持的一场在线研讨会和安全问答活动中,解释了如何尽量减少补丁应用频率或尽量缩短未修复漏洞被利用的时间。本篇文章将概述笔者在这次网络研讨会上的主要观点,并说明确定更新计划时最重要的考虑因素。 针对 Linux 内核的安全补丁 Ubuntu 中有两种类型的内核,这些内核有两种打包方式。两种内核类型为通用版(GA)内核和变体内核。两种打 […]