近日，美国、德国、澳大利亚等国联合发布《通过设计和默认保护的技术指南》报告。NSA、网络安全和基础设施安全局(CISA)、联邦调查局(FBI)正在与多国网络安全机构合作（以下简称“联合小组”），鼓励技术制造商开发符合设计安全和默认安全要求的产品。本次联合小组发布了“改变网络安全风险的平衡：设计安全和默认安全的原则和方法”，该指南将提高认识并促进关于关键优先事项、投资、必要决策，通过国际对话促进制造安全、可靠和有韧性的技术。该指南将确保技术产品的构建和配置方式能够防止恶意网络行为者访问设备、数据、连接基础设施。多国网络安全机构包括：澳大利亚网络安全中心、加拿大网络安全中心、德国联邦信息安全办公室、英国国家网络安全中心、荷兰国家网络安全中心、新西兰的计算机应急响应小组和新西兰国家网络安全中心。

因设计而脆弱

技术几乎已经融入到日常生活的每一个方面。面向互联网的系统与直接影响我们的经济繁荣、生计、甚至健康的关键系统相连，从个人身份管理到医疗护理。仅举一例，网络漏洞已经导致医院取消了手术，并在全球范围内转移了病人护理。关键系统中不安全的技术和漏洞可能招致恶意的网络入侵，导致严重的潜在安全风险。

(资料图片仅供参考)

对技术制造商来说，现在比以往任何时候都更有必要将"设计中的安全"和 "默认的安全"作为产品设计和开发过程的重点。一些供应商已经取得了巨大的进步，推动了行业在软件保障方面的发展，而其他供应商则落后了。编写机构强烈鼓励每一个技术制造商以这样一种方式构建他们的产品，即防止客户不得不不断地对他们的系统进行监测、例行更新和损害控制，以减轻网络入侵。我们鼓励制造商在改善其客户的安全成果方面发挥主导作用。历史上，技术制造商一直依赖在客户部署产品后修复发现的漏洞，要求客户自费应用这些补丁。只有通过融入"设计中的安全"实践， 才能打破创建和应用修复程序的恶性循环。

为了实现这种高标准的软件安全，编写机构鼓励 制造商优先考虑产品安全的整合，将其作为产品功能和上市速度的一个重要前提条件。功能和上市速度。随着时间的推移，工程团队将能够建立一个新的稳态节奏，在这个节奏中，安全是真正的设计，并且需要更少的努力来维护。

为了反映这一观点，欧盟在《网络弹性法》中加强了产品安全的重要性，强调制造商应在产品的整个生命周期中实施安全，以防止制造商将脆弱的产品引入市场。

为了创造一个技术和相关产品对客户更安全的未来，编写机构敦促制造商修改他们的设计和开发计划，只允许向客户提供"设计中的安全"和 "默认"产品。通过设计实现安全的产品是那些将客户的安全作为核心业务目标的产品，而不仅仅是一个技术特征。设计中的安全产品在开发开始前就以这个目标为起点。默认安全的产品是那些"开箱即用"的安全产品，几乎不需要改变配置，而且安全功能无需额外费用。这两个原则结合在一起，将保持安全的大部分负担转移给了制造商，并减少了客户因错误配置、不够快速的补丁或许多其他常见问题而成为安全事件的受害者的机会。

网络安全和基础设施安全局（CISA）、国家安全局（NSA）、联邦调查局（FBI）和以下国际合作伙伴2提供本指南中的建议，作为技术制造商确保其产品安全的路线图：

澳大利亚网络安全中心(ACSC)

加拿大网络安全中心(CCCS)

英国国家网络安全中心(NCSC-UK)

德国联邦信息安全办公室(BSI)

荷兰的国家网络安全中心(NCSC-NL)

新西兰计算机应急响应小组（CERT NZ）和新西兰国家网络安全中心（NCSC-NZ）

编写机构承认许多私营部门的合作伙伴在推进"设计中的安全"和"缺陷中的安全"方面的贡献。本产品旨在推动关于关键优先事项、投资和决策的国际对话，以实现技术在设计和默认情况下是安全、可靠和有弹性的未来。为此，编写机构寻求有关各方对本产品的反馈，并打算召开一系列倾听会，以进一步完善、明确和推进我们的指导，实现我们的共同目标。

设计中的安全

"设计中的安全"是指技术产品的制造方式能够合理地防止恶意的网络行为者成功地获得对设备、数据和连接基础设施的访问。软件制造商应进行风险评估，以确定和列举对关键系统的普遍网络威胁，然后将保护措施纳入产品蓝图，以考虑不断变化的网络威胁情况。安全的信息技术（IT）开发实践和多层防御，即所谓的深度防御--也被建议用来防止对手活动破坏系统或获得对敏感数据的未经授权的访问。编写机构建议制造商在产品开发阶段使用定制的威胁模型，以解决系统面临的所有潜在威胁，并考虑到每个系统的部署过程。编写机构敦促制造商对其产品和平台采取全面的安全方法。设计中的安全开发需要软件制造商在产品设计和开发过程的每一层都投入大量的资源，这些资源不能在以后"栓"上。它需要制造商的最高业务主管的有力领导，使安全成为业务的优先事项，而不仅仅是一个技术特性。商业领袖和技术团队之间的这种合作从设计和开发的早期阶段一直延伸到客户部署和维护。我们鼓励制造商做出艰难的权衡和投资，包括那些对客户来说"看不见"的投资，如迁移到能消除普遍漏洞的编程语言。他们应该优先考虑保护客户的功能、机制和工具的实施，而不是那些看似吸引人但却扩大攻击面的产品部署过程。

编写机构敦促制造商对其产品和平台采取全面的安全方法。产品和平台采取全面的安全方法。通过设计进行安全开发需要软件制造商在产品设计和开发的每一层都投入大量的资源。厂商在产品设计和开发过程中的每一层都需要投入大量的资源。进程中投入大量的资源，而这些资源是不能在以后"栓"上的。它需要制造商的高层管理人员的强有力的领导 它需要制造商的最高业务主管的有力领导，使安全成为业务的优先事项，而不仅仅是一个技术特性。这种 商业领袖和技术团队之间的合作从设计和开发的早期阶段延伸到客户的部署和 设计和开发的早期阶段，直到客户部署和维护。制造商被鼓励 鼓励制造商做出艰难的权衡和投资，包括那些对客户来说"不可见"的投资，如迁移到客户电脑上。包括那些对客户来说"看不见"的投资，如迁移到能消除普遍存在的漏洞的编程语言。漏洞。他们应该优先考虑那些能够保护客户的功能、机制和工具的实施，而不是那些看起来很好的产品功能。他们应该优先考虑保护客户的功能、机制和工具的实施，而不是那些看起来很吸引人但却扩大了攻击面的产品功能。

没有单一的解决方案来结束恶意网络行为者利用技术漏洞的持续威胁，"设计安全"的产品将继续存在漏洞；然而，大量的漏洞是由相对较小的子集的根源造成的根本原因。制造商应该制定书面的路线图，使其现有的产品组合与更多的"按设计安全"的做法保持一致，确保只有在特殊情况下才会出现偏差。为客户承担安全结果的所有权并确保客户的安全水平可能会增加开发成本。

然而，在开发新技术产品和维护现有产品时，投资于"按设计安全"的做法，可以极大地改善客户的安全状况，减少被破坏的可能性。设计中的安全原则不仅可以加强客户的安全态势和开发商的品牌声誉，而且从长远来看，还可以降低制造商的维护和修补成本。

下面列出的对软件制造商的建议部分提供了一个清单，其中包括建议的产品开发实践和政策，供制造商考虑。

缺省安全

"默认安全"是指产品在开箱时就能抵御普遍的开发技术 开箱即用，无需额外收费。这些产品可以抵御最普遍的 威胁和漏洞，而终端用户无需采取额外措施来保护它们。默认安全产品的设计是为了让客户敏锐地意识到，当其偏离安全默认值时，除非实施额外的补偿控制，否则就会增加被破坏的可能性。安全的配置应该是默认的基线。默认安全产品会自动启用最重要的安全控制措施，以保护企业免受恶意网络行为的影响。企业免受恶意网络行为的影响，并提供使用和进一步配置安全控制的能力，而不需要额外的费用。额外成本的情况下，进一步配置安全控制。"默认安全"产品的制造商不会对实施额外的安全配置收取额外费用。相反，把其包括在基本产品中，就像所有新车中都包括安全带一样。安全不是一个奢侈的选择，而是更接近于每个客户应该期望的标准，而不需要协商或支付更多的费用。

对软件制造商的建议

本联合指南向制造商提供建议，以制定书面路线图，实施并确保IT安全。编写机构建议软件制造商实施以下各节概述的策略，通过"设计安全"和 "默认安全"原则，为其客户的安全结果负责。

软件产品安全原则

鼓励技术制造商采用一种优先考虑软件安全的战略重点。编写机构制定了以下三个核心原则，以指导软件制造商在开发、配置和运输其产品之前，将软件安全纳入其设计流程。

1.安全责任不应该只落在客户身上。软件制造商应该对客户购买的安全结果承担责任，并相应地发展产品；

2.全面推行透明度和问责制。软件制造商应以提供安全可靠的产品为荣，并根据自身能力在其他制造商群体中脱颖而出。这可能包括分享从客户部署中获取的信息，如默认情况下的强认证机制的采用。还包括一个强承诺，以确保漏洞公告和相关的常见漏洞和暴露（CVE）记录是完整和准确的。然而，要注意把CVE算作负面指标的诱惑，因为这种数字也是一个健康的代码分析和测试社区的标志。

3.建立组织结构和领导，以实现这些目标。虽然技术专题知识对产品安全至关重要，但高级管理人员是在组织中实施变革的主要决策者。软件制造商要将安全作为产品开发的一个关键要素，需要行政级别的承诺。

a.产品部署场景指导，以及量身定制的威胁模型

b.建议实施安全控制，以符合"默认安全"原则

c.根据公司规模制定的资源分配策略，以及用"按设计安全"的做法取代传统开发做法的能力。

d.需保持畅通沟通渠道，以获得内部和外部的反馈。应在内部论坛中强调软件安全（例如，全体员工或棕色袋子）、 在内部论坛（如全员参与或棕色袋子）以及外部产品营销和客户参与中，应强调软件安全。

e.衡量客户部署内的有效性。高级行政领导希望了解安全设计和默认情况下的如何投资以帮助客户缓安全补丁的速度，减少配置错误，并最大限度地减少攻击面。

为了实现这三个原则，制造商应该考虑几种操作策略来发展他们的开发流程。

与公司行政领导层召开例行会议，在组织内宣传"设计安全"和 "故障安全"的重要性。应该制定政策和程序来奖励那些开发出遵守这些原则的产品的生产团队。这包括对实施优秀软件安全实践的奖励，或对工作梯队和晋升标准的激励。围绕软件安全对商业成功的重要性进行操作。在开发过程中使用量身定做的威胁模型，以优先考虑最关键和影响大的产品。

通过设计实现安全的战术

安全软件开发框架（SSDF），也被称为美国国家标准与技术研究院（NIST）的SP 800-218，是一套核心的高级安全软件开发实践，可以被整合到软件开发生命周期（SDLC）的每个阶段。遵循这些实践可以帮助软件生产商更有效地发现和消除已发布软件中的漏洞，减轻利用漏洞的潜在影响，并解决漏洞的根本原因，防止今后再次发生。编写机构鼓励使用基于设计的安全策略，包括参考SSDF实践的原则。包括参考SSDF实践的原则。软件制造商应制定一个书面路线图，以便 在其产品组合中采用更多的“按设计安全”软件开发实践。以下是一个非详尽的清单。以下是一份非详尽的路线图最佳实践清单。

内存安全编程语言（SSDF PW.6.1）： 尽可能优先使用内存安全语言。尽可能地优先使用内存安全语言。编写机构认识到，其他 内存特定的缓解措施，如地址空间布局随机化（ASLR）、 控制流完整性(CFI)和模糊处理对于传统的代码库是有帮助的，但不足以被视为设计上的安全。但不足以被视为设计上的安全，因为它们不能充分地防止利用。现代内存安全语言的一些例子包括C#、Rust、Ruby、Java、Go和 Swift。阅读NSA的内存安全信息表了解更多；

安全硬件基础： 纳入能够实现细粒度内存保护的架构特征，例如那些由Capability Hardware Enhanced RISC指令（CHERI）所描述的那些功能，可以扩展传统的硬件指令集；

安全软件组件（SSDF PW 4.1）：获取和维护安全的 安全的软件组件（例如，软件库、模块、中间件、框架）。从经过验证的商业、开放源码和其他第三方开发商那里获得并维护安全良好的软件组件（如软件库、模块、中间件、框架），以确保消费者软件产品的强大安全性。消费品软件产品的安全性；

网络模板框架（SSDF PW.5.1）： 使用网络模板框架，实现用户输入的自动转义，以避免网络攻击，如跨站脚本攻击；

参数化查询（SSDF PW 5.1）： 使用参数化查询而不是在查询中包括用户输入，以避免SQL注入攻击；

静态和动态应用程序安全测试（SAST/DAST）（SSDF PW.7.2, PW.8.2）： 使用这些工具来分析产品源代码和应用行为，以检测易出错的做法。这些工具涵盖了从内存的不当管理到容易出错的数据库查询结构等问题。这些工具涵盖了从内存的不当管理到容易出错的数据库查询结构的问题。SAST和DAST工具可以被纳入到开发过程中，并作为软件开发的一部分自动运行。SAST和DAST 应补充其他类型的测试，如单元测试和集成测试、 以确保产品符合预期的安全要求。当发现问题时，制造商应进行根本原因分析，以系统地解决漏洞；

代码审查（SSDF PW.7.1, PW.7.2）： 确保产品中的代码要经过其他开发者的同行评审，以确保更高的质量；

软件材料清单（SBOM）（SSDF PS.3.2, PW.4.1）： 纳入SBOM3的创建，以提供进入产品的软件集的可见性；

漏洞披露计划（SSDF RV.1.3）： 建立漏洞披露计划允许安全研究人员报告漏洞并获得法律上的安全港。作为其中的一部分，供应商应建立程序来确定漏洞的根本原因。这些程序应包括确定 确定采用本文件中的任何安全设计实践（或其他类似的实践）是否可以防止漏洞的引入；

CVE的完整性：确保公布的CVE包括根本原因或常见的漏洞列举（CWE），以便对软件安全根源进行全行业分析。虽然确保每个CVE的正确性和完整性可能需要额外的时间，但它可以让不同的实体发现行业的根源。允许不同的实体发现行业趋势，使所有制造商和客户受益。

深度防御：设计基础设施，使单一安全控制的破坏不会导致整个系统的破坏。另外，软件沙箱技术可以隔离一个漏洞以限制对整个应用程序的破坏。

满足网络性能目标（CPG）： 设计符合基本安全惯例的产品。CISA的网络安全性能目标概述了组织应实施的基本的、基线的网络安全措施。它与CISA的CPG有相似之处。如果一个制造商不能满足CPG的要求，例如不要求所有员工进行抗网络钓鱼的多因素认证，那么就不能被视为提供了安全保障，不能被视为提供 "按设计安全 "的产品。

应根据关键性、复杂性和业务影响来确定引入的优先次序。在某些情况下，某个产品的关键性和风险状况可能值得加快采用这些实践的时间表。在其他情况下，可以将这些实践引入到传统的代码库中，并随着时间的推移进行补救。

安全的战术

除了采用"按设计安全"的开发实践外，建议软件制造商在其产品中优先考虑"默认安全"的配置。除了采用"按设计进行安全开发"的做法外，编写机构还建议软件制造商在其产品中优先考虑"按默认进行安全配置"的做法。这些厂商应努力更新产品，以便在产品更新时符合这些惯例。

取消默认密码： 产品不应该带有默认的密码 。为了消除默认密码，建议产品要求管理员在安装和配置时设置一个强密码；

o 强密码：产品不应带有普遍共享的默认密码；

o对特权用户强制实行多因素认证（MFA）。许多企业的部署是由管理员管理的，没有用MFA保护账户。鉴于管理员是高价值的目标，产品应该让MFA选择退出，而不是选择加入。此外，系统应该定期提示管理员注册MFA，直到在自己的账户上成功启用；

单一登录（SSO）： IT应用应通过现代开放标准实施单点登录技术。现代开放标准。例子包括安全断言标记语言（SAML）或OpenID连接。(SAML)或OpenID连接(OIDC)。这种能力应该在默认情况下提供，无需额外费用；

安全日志：向客户提供高质量的审计日志，不收取额外费用。审计日志对于检测和升级潜在的安全事件至关重要。它们也在调查疑似或确认的安全事件时也很关键。请考虑最佳做法，如提供与安全信息和事件管理（SIEM）系统的轻松集成，并提供应用编程接口（API）访问；诸如提供与安全信息和事件管理（SIEM）系统的简易集成，并提供应用编程接口（API）访问，该接口使用协调的世界时（UTC），并在安全信息和事件管理系统中使用；

软件授权简介： 软件供应商应提供关于授权配置文件角色及其指定的使用情况。制造商应该包括一个预警，通知客户如果偏离了建议的配置文件授权，将使风险上升。建议的配置文件授权；

前瞻性安全高于后向兼容性：很多时候，向后兼容的遗留功能被包括在产品中，而且经常被启用，尽管这对产品的安全有风险。对产品安全造成风险。优先考虑安全性而不是后向兼容性、授权安全团队删除不安全的功能，即使这意味着造成破坏性变化。

跟踪并减少 "加固指南 "的大小：减少为产品制作的 "加固指南 "的规模，并努力确保随着软件新版本的发布，其规模会逐渐缩小。将 "加固指南 "的组件整合为产品的默认配置。编写机构认识到缩短的加固指南是与现有客户持续合作的结果，包括许多产品团队的努力，包括用户体验（UX）。

考虑到安全设置的用户体验后果： 每一个新的设置都会增加终端用户的认知负担，应该结合其带来的商业利益进行评估。理想情况下，一个设置不应该存在；相反，最安全的设置应该集成到 最安全的设置应该以默认方式集成到产品中。当配置是必要的，默认选项应该是广泛安全的，以预防常见的威胁攻击，编写机构承认这些变化可能会对软件的使用方式产生影响。软件的使用方式产生影响。因此，在平衡操作和安全方面，客户的意见是至关重要的。考虑。编写机构认为，制定书面的路线图和行政支持，将这些想法优先纳入企业最重要的产品。

因此需要制定书面路线图和行政支持，将这些想法优先纳入组织最重要的产品中，在向安全软件开发实践转变的第一步。制造商要为客户创造有意义的激励措施，使其保持最新状态，而不是让其无限期地存在漏洞。

加固与松动的指南

加固指南也可以成为对手确定和利用不安全功能的路线图。许多组织不知道加固指南，因此使其设备配置设置处于非安全状态。与其开发列出产品安全方法的加固指南，这些机构建议软件制造商将其转变为“安全指南”。建议软件制造商通过提供松动指南，转向“默认安全”的方法。通过提供松动指南。这些指南用通俗易懂的语言解释了决策的商业风险，并可以提高组织对恶意网络入侵风险的认知。

建议

作为这项工作的一部分，建议组织的管理人员优先考虑购买"按设计安全"和 "按故障安全"的重要性。购买"设计即安全"和 "默认即安全"的产品。这可以通过以下方式体现出来 建立政策，要求IT部门在购买制造商的软件之前对其安全性进行评估。软件，并授权IT部门在必要时进行反击。必要时进行反击。IT部门应被授权制定采购标准，以强调"设计即安全"和 "默认即安全"的重要性。本文件中概述的做法和组织制定的其他做法。此外，IT在采购决策中执行这些标准时，IT部门应该得到执行管理层的支持采购决定。组织决定接受与特定技术产品相关的风险，应正式记录在案。支持组织安全态势的关键企业IT服务，如：企业网络、企业身份和访问管理。企业网络、企业身份和访问管理以及安全操作和响应能力等支持组织安全态势的关键企业IT服务，其资金来源应与它们对组织安全的重要性相一致。以配合其对组织的任务成功的重要性。各组织应制定一个计划，以升级这些能力，利用组织应该制定一个计划来升级这些能力，以利用那些接受"按设计安全"和 "按故障安全"做法的制造商。

在可能的情况下，组织应该努力与其主要IT供应商建立战略伙伴关系。这种关系包括组织中多个层面的信任，并提供解决问题和确定共同优先事项的工具。安全应该是这种关系的一个关键因素，组织应该努力在关系的正式层面（如合同或供应商协议）和非正式层面加强"设计安全"和 "默认安全"的重要性。组织应该期望其技术供应商在其内部控制状况以及他们采用"按设计安全"和 "按故障安全"实践的路线图方面具有透明度。

除了使默认安全成为企业内部的优先事项外，IT领导者应该 与业界同行合作，了解哪些产品和服务最好地体现了这些设计原则。这些设计原则。这些领导者应该协调他们的要求，以帮助制造商 优先考虑其即将推出的安全计划。通过合作，客户可以帮助提供厂商提供意见，并激励其优先考虑安全问题。在利用云系统时，组织应确保其了解与技术供应商的共责模式。也就是说，厂商应该明确供应商的安全责任，而不仅仅是客户的责任。组织应优先考虑那些对其安全状况、内部控制和能力具有透明度的云供应商。组织应优先考虑那些对其安全状况、内部控制和履行其在共同责任模式下的义务的能力透明的云供应商。