「安全设计」68家国内外科技巨头和安全巨头参与了CISA发起的安全设计承诺，包含MFA、默认密码、CVE、VDP等七大承诺目标

本文主要是介绍「安全设计」68家国内外科技巨头和安全巨头参与了CISA发起的安全设计承诺，包含MFA、默认密码、CVE、VDP等七大承诺目标，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

美国网络安全和基础设施安全局（CISA，CyberSecurity & Infrastructure Security Agency）于2024年5月开始呼吁企业是时候将网络安全融入到技术产品的设计和制造中了，CISA于近期发起了安全设计承诺行动，该承诺旨在补充和建立现有的软件安全最佳实践，包括 CISA、NIST、其他联邦机构开发的最佳实践以及国际和行业最佳实践。 CISA 继续支持采用补充措施，以推进安全的设计态势。目前国外主流安全厂商（如Veracode、Sonatype、Qualys）、知名企业（如Microsoft、Google、Cisco）纷纷参与了此次承诺行动，国内也有企业已经参与其中（如联想、趋势科技等）。

在这里插入图片描述

1. CISA介绍

CISA 与合作伙伴合作抵御当今的威胁，并协作为未来构建更安全、更有韧性的基础设施。
CISA 是联邦网络安全的运营领导者以及关键基础设施安全和韧性的国家协调员，主要职责是协作与伙伴关系，承担降低国家网络和物理基础设施风险的分层使命。

使命：我们领导国家努力了解、管理和降低网络和物理基础设施的风险。
愿景：为美国人民提供安全、有韧性的关键基础设施。

2. 呼吁安全设计的时代背景

作为美国的网络防御机构，CISA 负责保护美国免受不断演变的网络威胁，并了解、管理和降低美国人每天所依赖的网络和物理基础设施的风险。但是，随着我们在生活中引入更多不安全的技术，这变得越来越困难。 网络安全负担不成比例地落在消费者和小型组织的肩上，而非技术生产者和开发越来越多地运行我们数字生活的产品的人。

美国人需要一种新的模式来弥补网络安全方面的差距，在这种模式中，消费者可以信任他们每天使用的技术的安全性和完整性。即每个技术提供商都必须在执行层面掌握所有权，以确保其产品在设计上是安全的。

3. 通过设计确保安全意味着什么

安全设计产品是将客户的安全视为核心业务需求而不仅仅是技术功能的产品：

应在产品开发生命周期的设计阶段实施“设计安全”原则，以在将产品引入市场广泛使用或消费之前大幅减少可利用缺陷的数量。
产品应该可以安全地开箱即用，默认启用安全配置，并且无需额外付费即可使用多重身份验证 (MFA)、日志记录和单点登录 (SSO) 等安全功能。

4. 计保证安全承诺行动

4.1. 概述

这是一项专注于企业软件产品和服务的自愿承诺，包括本地软件、云服务和软件即服务 (SaaS)。物联网设备和消费产品等实体产品不在承诺范围内，但欢迎希望展示这些领域进展的公司这样做。

通过参与该承诺，软件制造商承诺在来年做出真诚的努力，实现下列目标。

如果软件制造商能够在实现目标方面取得可衡量的进展，则制造商应公开记录他们如何在签署承诺后的一年内取得此类进展。
如果软件制造商无法取得可衡量的进展，则鼓励制造商在签署承诺后一年内与 CISA 分享制造商如何努力实现目标以及面临的任何挑战。

该承诺有七个目标。 每个目标都有制造商承诺努力实现的核心标准，以及实现目标和展示可衡量进展的背景和示例方法。为了实现多种方法，参与承诺的软件制造商可以自行决定如何最好地满足和展示每个目标的核心标准。展示制造商产品的可衡量进展可以采取多种形式，例如对制造商的所有产品采取行动，或者选择一组产品首先解决并发布其他产品的路线图。

本着彻底透明的精神，鼓励制造商公开记录他们的方法，以便其他人可以学习。该承诺是自愿的，不具有法律约束力。

4.2. 承诺目标

以下承诺目标来自于《CISA 安全设计承诺》，若想了解承诺的具体细节，可以参阅如下官方文档：

CISA 安全设计承诺.pdf（访问密码：6277） - 7页，919 KB

在这里插入图片描述

4.2.1. 多重身份验证 (MFA)

目标：在签署承诺后一年内，展示为显着增加制造商产品中多因素身份验证的使用而采取的行动。
背景：多重身份验证是针对基于密码的攻击（例如撞库和密码盗窃）的最佳防御。事实证明，任何形式的 MFA 都会显着降低此类攻击的成功率，而更安全的 MFA 形式（例如防网络钓鱼 MFA）可以针对针对性攻击提供更多保护。制造商应寻求全面增加客户的 MFA 注册人数，重点是尽可能采用防网络钓鱼的 MFA 并增加管理员的注册人数。

注意：其他防网络钓鱼形式的身份验证（例如密钥）也符合此定义，即使它们是唯一的身份验证形式。

实现这一目标的示例方法：

默认为用户和管理员启用MFA（例如，首次注册时，要求用户和管理员配置MFA）。
在产品中实施“安全带铃声”，以推动用户启用 MFA。例如，这可能包括横幅或插页式广告，通知用户或管理员 MFA 未启用，或建议管理员启用防网络钓鱼 MFA。
在产品的基线版本中支持基于标准的单点登录 (SSO)，允许客户配置自己的支持 MFA 的身份提供商。

展示进展的示例：

发布一段时间内 MFA 采用情况的汇总统计数据，按用户类型（例如标准用户、管理员）和 MFA 类型（例如 SMS、TOTP、FIDO2）细分。
发布博客文章，描述所取得的可衡量进展，例如默认启用 MFA 的情况，并强调存在障碍的地方。
参与论坛以推进有关 MFA 或身份验证的长期标准，并展示这些标准将如何为实现这一目标带来可衡量的进展。

注意：为了实现这一目标，制造商可以通过客户行为的结果（例如在其产品中更改 MFA 的使用）或通过对产品本身的更改（例如默认启用 MFA）来展示可衡量的进展。

4.2.2. 默认密码

目标：在签署承诺后的一年内，展示在减少制造商产品的默认密码方面取得的可衡量的进展。
背景：默认密码（CISA 定义为产品中默认存在的普遍共享密码）继续引发破坏性网络攻击。该项目旨在减少可利用的默认密码的百分比，以减少攻击，特别关注面向互联网的产品。默认密码应替换为更安全的身份验证机制，如下面的示例所示（最好是如上所述的 MFA）。在配置结束时，只有客户应该拥有其身份验证凭据。

实现这一目标的示例方法：

为产品提供随机的、实例唯一的初始密码。
要求安装产品的用户在安装过程开始时创建强密码。
提供有时限的设置密码，这些密码会在设置过程完成后自行禁用，并需要配置安全密码（或更安全的身份验证方法，例如防网络钓鱼的 MFA）。
需要物理访问来进行初始设置和实例唯一凭证的规范。
开展活动或提供更新，将现有部署从默认密码转换为更安全的身份验证机制。

展示进展的示例：

发布一篇博客文章，描述制造商如何在各种产品线中超越（或已经消除）默认密码。
随着时间的推移，发布具有默认密码的产品数量。
发布有关客户数量的详细信息从默认密码转变为更安全的身份验证机制。

4.2.3. 减少整个类别的脆弱性

目标：在签署承诺后的一年内，展示为显着降低制造商产品中一个或多个漏洞类别的普遍性而采取的行动。
背景：当今绝大多数被利用的漏洞都是由于通常可以大规模预防的漏洞类别造成的。示例包括 SQL 注入、跨站点脚本和内存安全漏洞，如下所述。软件制造商降低客户风险的有效方法是努力大规模减少其产品中的漏洞类别。软件制造商可以选择一个或多个漏洞类别来承诺在一年内努力减少漏洞。有关可大规模预防的漏洞类别的更多信息，请参阅 CISA 的安全设计警报系列。

实现这一目标的示例方法：

始终强制使用参数化查询来防止 SQL 注入攻击。
采用具有内置跨站点脚本漏洞保护功能的 Web 模板框架。
制定内存安全路线图，以优先顺序过渡到内存安全语言，并使用内存安全语言编写新产品。
为开发人员提供安全默认设置，例如通过提供安全函数和库的“构建块”，使引入某种类型的漏洞变得不可能（或明显更加困难）。

展示进展的示例：

发布博客，介绍制造商在过去一年中如何努力显着降低一类或多类漏洞的发生率。这可能包括对制造商产品中 CVE 随时间变化的根本原因 (CWE) 进行分析。 CISA 指出，成功实现这一目标实际上可能会导致 CVE 的短期增加，因为制造商致力于减少此类漏洞 - 如果从长远来看减少此类漏洞，这应该被视为成功。
发布内存安全路线图，或针对其他类别的漏洞的类似路线图。

4.2.4. 安全补丁

目标：在签署承诺后一年内，展示为显着增加客户安装安全补丁而采取的行动。
背景：根据第一个“设计安全”原则，软件制造商应该对其客户的安全结果负责——即使在产品发货后也是如此。除了从源头上根除整类漏洞（如上所述）之外，软件制造商还有能力让客户更轻松地安装安全补丁，例如通过向用户广泛提供安全补丁支持并启用功能用于自动更新。

实现这一目标的示例方法：

提供允许在可能的情况下自动安装软件补丁的功能，并在适当的情况下默认启用此功能。
为客户广泛提供安全补丁支持。
在产品生命周期结束且不再支持安全补丁的情况下，在销售时清楚地传达预期生命周期，并在产品生命周期结束时向客户清楚地传达这一点，并投资于配置功能以简化客户过渡到支持的版本。
对于云或 SaaS 产品，应用补丁，这样客户就不会承担打补丁的负担。

展示进展的示例：

发布一段时间内产品补丁采用情况的汇总统计数据（例如，使用每个产品的不同版本的用户百分比）。
发布博客文章，展示为促进用户更好地部署安全补丁或减轻客户补丁负担而采取的措施。

注意：为了实现这一目标，制造商可以通过客户行为的结果（例如产品不同版本的用户百分比的变化）或通过产品本身的更改（例如自动软件的功能）来展示可衡量的进展补丁）。

4.2.5. 漏洞披露政策

目标：签署承诺后一年内，发布漏洞披露政策（VDP）
在签署承诺后一年内，发布漏洞披露政策 (VDP)，授权公众对制造商提供的产品进行测试，承诺不建议或对任何真诚努力遵循 VDP 的人采取法律行动，提供了一个清晰的漏洞报告渠道，并允许根据协调的漏洞披露最佳实践和国际标准公开披露漏洞。
背景：协调漏洞披露已成为与安全研究人员合作的互惠互利的规范。软件制造商受益于安全研究社区的帮助，这可以让他们更好地保护他们的产品。安全研究人员除了获得报告漏洞的明确渠道外，还获得根据该政策进行测试的授权。有关漏洞披露政策和安全港语言的示例，请参阅 CISA 的漏洞披露政策模板和 Disclose.io Policymaker。

注意：由于本项目的特殊性，不包括实现此目标的示例。

展示进展的示例：

发布符合上述标准的公开漏洞披露政策。
发布漏洞披露策略的机器可读描述（例如 security.txt 文件），以便研究人员更好地发现。
发布博客文章，回顾漏洞披露政策的调查结果和吸取的教训。

4.2.6. CVE

目标：签署承诺后一年内，展现漏洞报告的透明度
在签署承诺后的一年内，通过在制造商产品的每个通用漏洞和暴露 (CVE) 记录中包含准确的通用弱点枚举 (CWE) 和通用平台枚举 (CPE) 字段，展示漏洞报告的透明度。此外，至少针对所有关键或高影响漏洞（无论是内部发现还是由第三方发现）及时发布 CVE，这些漏洞需要客户采取行动来修补或有主动利用的证据。

虽然此目标并非必需，但我们鼓励公司通过针对因下述原因不符合这些标准的其他漏洞提交 CVE 来超越这一目标。还鼓励公司探索其他方法来丰富其 CVE 记录，以帮助客户更好地响应漏洞。
背景：除了作为一种标准化方式来传达客户应采取的防止漏洞的行动之外，及时、正确和完整的 CVE 记录还可以使漏洞趋势随时间的公开透明。这对各个公司及其客户以及整个软件行业都有好处，使软件开发人员能够随着时间的推移更好地了解最紧迫的漏洞类别。及时报告 CVE（尤其是那些经常被利用的 CVE）对于确保客户了解他们应该采取的行动至关重要。 CISA 警告不要将 CVE 的仅仅存在解释为负面信号，因为随着软件制造商实施安全设计原则，报告的 CVE 数量可能会在短期内上升 - 更全面的 CVE 报告使每个人受益。

注意：由于本项目的特殊性，不包括实现此目标的示例。

展示进展的示例：

在制造商产品的每个 CVE 记录中发布 CWE 和 CPE 字段。
公开描述制造商发布 CVE 时的政策。

4.2.7. 入侵的证据

目标：在签署承诺后的一年内，证明客户收集影响制造商产品的网络安全入侵证据的能力显着提高。
背景：组织必须有能力检测已发生的网络安全事件并了解所发生的情况。软件制造商可以通过提供收集入侵证据（例如客户的审核日志）的工件和功能来帮助其客户实现这一点。在此过程中，软件制造商体现了“设计安全”原则，即掌控客户的安全成果。