【公益译文】供应商安全评估

一、概述

网络设备安全是任何网络安全的关键。在选择将支持关键服务或关键基础设施的设备时，客户应对该设备的安全进行评估，并将此评估作为其采购和风险管理流程的一部分。

本指南就如何评估网络设备安全提供了建议。它指导公共电信运营商（公共电子通信网络和服务提供商）履行《2021年电信（安全）法案》规定的职责以及政府征求意见后在《2022年电子通信（安全措施）条例》中最终确定的职责。例如，条例草案3.(3)(e)要求网络提供商：

• 在设备的采购、配置、管理和测试中采取适当措施，确保设备的安全以及在设备上执行的功能的安全。

《电信安全实务守则》草案，特别是措施草案5.01和10.1中引用了本指南。虽然本指南预计不会构成该守则（最终敲定版）的一部分，不需要或不足以满足新的供应链法律要求，但它是供应商可以用来帮助其实现合规的重要建议。

本指南中的建议虽然旨在支持电信运营商，但对于依赖网络设备提供服务的其他关键服务或关键基础设施提供商也可能有用。英国国家网络安全中心（NCSC）承认，当网络设备支持关键服务时，本文件中建议的网络设备安全评估程度最合适。此外，为了有效进行本文件中所述的评估，客户可能需要适当的合同权利来进行建议的审计和测试。

在对网络设备进行选择决策时，应使用本指南。然而，如下文所述，安全是一项持续进行的活动。与其他表现领域一样，客户应持续评估并保留供应商在设备使用寿命期间的安全记录证据，为今后的安全评估提供参考。

本指南未考虑、也无法缓解由于供应链中特定供应商的其他风险而可能产生的威胁。这些风险包括供应商在多大程度上可能受到影响或被要求采取损害客户利益或其国家安全的行为。在这些情况下，可能需要对在考虑范围内的供应商进行其他控制。

二、评估方法总结

本文件就如何评估供应商的安全流程及其提供的网络设备提供了指导。该方法的目的是客观评估因使用供应商设备而产生的网络风险。这是通过收集关于供应商流程和网络设备安全的客观、可重复的证据来实现的。

评估因供应商产生的网络风险需要：

• 供应商自己提供的证据
• 通过测试来验证供应商的声明
• 第三方证据

对于本文件中的每个标准，可以进行一系列针对具体产品的抽查，并且可以直接从产品本身的实验室测试中获得证据。这三部分合在一起将有助于理解供应商构建新产品的能力。

然而，这种方法总是容易出错。虽然证据将以客户为导向，但它只能举例说明供应商的行为。为了达到效果，该方法和安全标准都需要维持多年，同时需要记录正面实践和反面实践，为今后的安全评估和采购决策提供参考。

在评估供应商安全实践时，NCSC建议运营商不要完全依赖供应商文档来评估供应商安全。安全评估应基于供应商实施的安全行为。这包括针对具体产品线的抽查以及从产品中获取的客观证据。

三、外部审计和国际计划

在评估网络设备安全时，最大的挑战之一是生产区域性产品或具体运营商产品的行业实践。如果供应商依照行业惯例，国际客户无论是通过相互合作还是通过国际测试计划，都不能分担获取产品质量或安全相关的证据或保障的责任。

可以依靠独立的外部来源提供一些所需的证据，前提是：

• 适用于客户的产品（特别是相同的硬件和代码库）
• 客户可以重新验证所有证据，并且随机选择了一些证据进行重新验证

通常，依赖供应商文档的供应商审计或评估不太可能提供有用的证据，除非能够核实审计是否与网络设备安全相关。出于同样的原因，如果审计背后的证据没得到广泛使用且不可测试，也不应考虑进行审计或评估。例如，根据目前的定义，根据全球移动通信系统协会（GSMA）的网络设备安全保障计划（NESAS）进行的私人纸质评估不太可能提供有用的证据来支持客户的产品安全评估。

四、安全研究界的支持

鉴于网络设备的范围、规模和复杂性，全球安全研究界（包括商业实验室和学术界）的参与对于帮助客户理解安全风险至关重要。因此，应鼓励供应商对其安全实践保持透明、公开，鼓励供应商支持负责任的独立安全研究人员进行自己的测试和分析。

为了促进日益安全和开放的电信设备的发展，英国数字、文化、媒体和体育部（DCMS）表示打算建立一个英国国家电信实验室（UKTL）。UKTL将是一个安全的研究基地，将电信运营商、现有供应商、新供应商、学术界和政府聚集在一起，创建具有代表性的网络，研究和测试提高安全性和互操作性的新方法。

五、评估方法

评估供应商的安全方法包括四个层级：

评估

评估供应商提供的“安全声明”。“安全声明”应该说明供应商的安全方法以及供应商对其客户作出的安全承诺。为了发展安全生态系统，NCSC建议供应商公开发布其“安全声明”。“安全声明”使客户相信供应商对所有客户和产品线提供的方法都是一致的，允许更多的安全社区参与安全讨论。

检查

针对特定的、独立选择的产品版本，对供应商实施的安全流程进行抽查。由于供应商在自己的系统内随时可以获取所有细节信息，因此无需提前通知供应商有哪些抽查项。

分析

对设备进行实验室测试。要么对所有设备进行测试，要么从供应商提供的设备中随机选择设备进行测试。在可能的情况下，实验室测试应该是自动化的，这样就可以很容易地以低成本进行重复测试。不受客户影响的实验室测试应针对客户使用的相同产品版本路径、硬件、软件、固件和配置。

维持

在客户与供应商的整个合作过程中，确保供应商遵守“安全声明”中的标准。客户应分析问题的根本原因，并记录供应商的安全表现，以确保今后的评估具有严谨的证据。

下面给出了应用这四层方法的建议。

六、评估供应商的安全表现

在评估供应商安全实践时，一个重要的数据源是供应商的安全表现。客户应考虑供应商的安全文化和行为。安全文化和行为具体表现为：

• 供应商风险评估和安全评估流程的成熟度
• 供应商的透明度、开放性以及与安全研究社区的协作
• 供应商对安全漏洞和事件进行的评估、管理和客户支持
• 供应商遵守安全义务和要求的情况
• 供应商对产品和组件的支持方法

安全事件本身并不表明存在不规范的安全实践。所有大公司都可能受到安全事件的影响。客户应考虑是否可以合理规避安全事件，或是否可以合理减轻安全事件的影响。

同样，产品安全漏洞或问题本身也并不表明存在不规范的安全实践。这是因为所有产品都会出现此类问题。然而，如果问题过于简单化，或者由于产品管理或维护不善，就可能表明存在不规范的安全实践。

七、供应商安全评估标准

下表可用于帮助评估供应商及其网络设备的安全流程。该表描述了客户在“安全声明”中应期望的信息、收集证据时应考虑的“抽查”以及客户或第三方应考虑对设备进行的“实验室测试”。对于“抽查”和“实验室测试”，假设客户将获得充分的权限访问供应商流程和设备，以便在根据此评估作出决策之前进行有效评估。

当使用第三方时，客户应确信第三方具有足够的独立性和技术能力、已获得有关供应商日常实践的充足信息，从而向其提供所需的可靠证据。

主题	安全期望	为什么重要	评估：安全声明	评估：客户或第三方抽查	评估：客户或第三方实验室测试
V.A: 产品生命周期管理
V.A: 总体目标	供应商的产品在产品的整个生命周期内都得到了适当的支持。	使人们相信，产品将由供应商进行成熟的管理，并在产品受支持的生命周期内获得更新和安全关键修复。	在“安全声明”中，供应商描述了产品受支持情况。	–	–
V.A.1: 产品生命周期流程	供应商清楚地确定了每个产品的生命周期。 供应商应制定停产政策，详细说明产品在停售后将得到多长时间的支持。	使人们相信，产品在特定日期前都能得到支持。此外，供应商的支持日期全局适用，这意味着供应商可能会在此期间继续投资于产品维护。	供应商在“安全声明”中描述了其产品的生命周期。 对于产品线中的每个版本，供应商在其网站上公布了适用的停售日期。停产政策应详细说明在宣布停售日期后，产品将得到多长时间、何种方式的支持。“安全声明”中提到了此信息的位置。	检查产品发布历史记录。探索供应商如何更新组件。	–
V.A.2: 软件维护	每个产品在其公示的生命周期中都得到维护。此维护至少包括产品的安全修复。	使人们相信，产品在其受支持的整个生命周期内都可以针对产品中发现的安全问题得到修补。	供应商清楚地描述了他们将如何在产品生命周期内支持产品，包括他们将在每个支持类别下提供什么支持。	查看显示应用于产品的安全修复历史记录，包括解决突出漏洞的路线图。	为客户选定的产品挑选一个已知漏洞的样本，并根据供应商的政策检查漏洞是如何修补的、何时修补的。（见V.A.7）。
					测试产品以验证设备不再存在漏洞或漏洞变体。
V.A.3: 软件版本控制	每个产品都有一个版本控制的代码库，用于记录每次代码修改。该审计日志将详细说明： -修改、添加或删除了哪些代码 -变更原因 -变更人 -变更时间 -发布的产品中内置了哪个版本的代码。	确保供应商能够准确追踪产品中部署的代码。这对于有效调查供应链攻击至关重要。	供应商描述了其如何维护代码库的完整性。	供应商演示如何根据正常流程进行变更，以及如何拒绝通过其他方式进行的变更。 探索变更并验证是否遵循了流程。
V.A.4: 软件发行	每个产品都要经历严格的软件发行周期，包括内部测试，然后才能发行正式可用的版本。如果软件不符合下面详述的安全工程要求，则不予发行。每个产品应由独立的第三方定期进行外部测试。	该要求旨在使人们相信，供应商能够测试其软件版本，并验证其内部安全工程流程是否得到遵守。 测试还应确保以前解决的安全漏洞不会再次出现。	供应商描述了他们的软件发行周期，包括网关和执行的测试。	审查构建与测试流程。 审查针对客户选定的产品线和版本执行的测试。检查测试工具是否配置良好，并查看测试结果。验证以前解决的漏洞和问题检查中否包含测试。 供应商证明，由于测试失败，问题已得到正确修复。	通过在客户或第三方实验室重复测试，检查一组供应商测试结果的准确性。
V.A.5: 开发流程与功能开发	该产品有一个主要的发行系列。 尽量减少新版本的复刻。必要时，将提供针对具体客户的功能作为可选模块。	该要求旨在使人们相信，供应商正在向他们提供产品的通用版本，这样他们就知道可以使用通用支持路线在产品的整个生命周期内为其提供支持。	“安全声明”描述了供应商的开发流程，包括新产品版本发行的方式和时间，以及如何将版本数量保持在可管理的水平。
	在标准开发路线图期间，任何新功能都会被引入到主产品线中。	供应商不太可能很好地支持针对具体功能的产品版本的激增。
V.A.6: 国际发行与复刻	供应商为每个产品维护一个单一的全球版本线。其他版本的产品数量很少（理想情况下没有）。	该要求旨在使人们相信，产品得到全球支持，并且发现的任何问题都可以轻松缓解。 供应商不太可能很好地支持针对具体客户的产品版本的激增。	供应商发布其产品的所有发行版本的详细信息，包括二进制哈希。预计这些信息将出现在供应商的网站上。 供应商在其“安全声明”中引用其产品版本的公开列表。	供应商描述了产品的完整发行系列，包括创建每个版本的原因。	根据供应商发布的信息或其他信息，测试供应商提供的产品版本是否为“全球”版本，是否具有匹配的二进制哈希。
V.A.7: 工具、软件和库的使用	对产品开发中使用的第三方工具（例如代码编译器）软件组件和软件库进行了清点。对供应商软件安全至关重要的上述任何一项都在软件的整个生命周期内得到维护。	不受支持的工具、软件组件、软件或库不太可能使用现代安全功能。如果缺乏保护，可能会导致产品中嵌入已知漏洞。 必须修补产品关键安全保护中的漏洞，将漏洞攻击的影响降至最低。	“安全声明”描述了如何维护第三方软件组件，明确说明了（假如可以的话）何时将不受支持的组件囊括在产品版本中，并说明了理由。	对于客户选定的产品，供应商提供对产品安全至关重要的第三方组件列表（例如，通过接口暴露的组件）。验证这些组件是否仍能得到积极维护、是否有产品生命周期的支持计划。	扫描产品接口，清点已知的第三方工具，确定这些工具是否正在维护中。 检查产品，验证供应商的组件列表是否准确。
V.A.8: 软件文档	供应商在提供产品新版本的同时，提供最新的、符合技术规范的文档。该文档至少应详细说明如何安全地配置、管理和更新产品。	这为客户提供了所需的信息，帮助客户在其网络中对产品进行全生命周期的安全部署和管理、独立评估该配置的安全性。 这有助于减少客户对供应商的持续依赖。	“安全声明”承诺向客户发布产品文档。		使用文档，在没有供应商支持的情况下设置、操作、配置和更新产品。
V.B: 产品安全管理
V.B: 总体目标	产品将以“默认安全”的方式开发。	这些要求旨在使人们相信部署的产品是采用标准安全缓解措施和安全编码技术开发的。
V.B.1: 安全文化	供应商有一种安全文化，确保遵守安全原则。	这使人们相信，公司内的开发人员通常会遵守安全原则和开发要求。	“安全声明”描述了供应商内部安全文化的高级所有权，以及允许员工提出安全问题的机制。	–	–
V.B.2: 安全开发生命周期	供应商有一个安全开发生命周期，将安全性嵌入产品开发。所有开发团队都遵循并可以证明他们遵循了安全开发生命周期流程。	这使人们相信，安全已嵌入到开发流程中，并且公司内部有一种一致的安全文化。	“安全声明”描述了供应商如何开发安全产品，包括供应商如何验证其安全编码标准是否得到遵守。	供应商演示了他们如何确信开发人员采用了安全开发生命周期。 供应商描述了他们如何确保其代码具有高质量。验证产品开发流程中包含的安全控制示例。	看看安全开发生命周期中包含的供应商安全控制是否有效（例如，子组件是否能够拒绝格式错误的输入）。
V.B.3: 内部组件管理	内部共享的组件或库都是最新的，并且只使用最新的、稳定的、受支持的版本。这些组件和库不会因特定版本受到修改，并且在产品的生命周期内受支持。	这使人们相信，产品中使用的内部共享组件将在主要产品的整个生命周期内得到维护。	“安全声明”明确承诺维护内部组件。	对于客户选定的产品，供应商可以列出产品的软件和硬件组件。 验证是否仅使用了最新版本的内部共享组件和库。 探索产品线是否复刻了共享库。	在实验室中，验证发布的产品是否只包含每个内部软件组件或库的一个版本、所有内部组件是否都是最近构建的。
V.B.4: 外部组件管理	产品中仅使用受支持的外部组件。供应商监控外部组件的变更日志，以便在产品中仅使用最新的、稳定的、受支持的版本。	这使人们相信，供应商选择使用的任何第三方组件当前都将得到支持，并且发现的任何安全问题都将得到修补。	“安全声明”明确承诺使用受支持的外部组件。	对于客户选定的产品版本，验证其是否仅使用受支持的外部组件和库版本。 探索这些组件在停产时将如何更新。	在实验室中，验证发布的产品是否仅使用所有外部组件的完全支持版本。 找到证据，说明内部复刻的外部组件或库是存在的。
	此外，供应商监控外部组件的安全公告，整合安全修复措施，并通过安全更新将其集成到产品中。	延期的支持合同可能会增加安全风险，应予以避免。		探索产品线是否复刻了外部开发的代码，如果存在复刻，探索如何维护该产品线。
V.B.5: 不安全函数	供应商发布的代码中没有使用不安全函数。不安全函数通常与安全漏洞相关，或被行业最佳实践认为不安全。	这些函数通常是导致产品漏洞的原因。	“安全声明”明确说明供应商的代码库中是否使用了不安全函数。	要求对不安全函数的使用进行代码度量。
V.B.6:	在供应商的源代码树中，冗余或重复代码数量有限。	冗余代码使产品更难理解和维护，使对安全至关重要的变更更不可能影响产品访问。	“安全声明”明确说明了供应商如何生成代码来降低复杂度、提高可维护性。	要求对源代码树中存在多少重复代码进行代码度量。
V.B.7:	在供应商的源代码树中，代码复杂度最小，函数执行单一、清晰的操作。	代码清晰度降低了错误或漏洞风险，使问题更容易被发现。	“安全声明”明确说明了供应商如何生成代码来降低复杂度、提高可维护性。
V.B.8: 调试功能	供应商发布的产品中没有可能削弱或绕过产品安全机制的工程调试功能。	攻击者可能利用工程调试功能对产品进行攻击。	“安全声明”明确声明，要确认产品的发布版本中不存在工程调试功能。	请供应商证明在发布版本中包含调试功能会导致构建失败。
V.B.9:	源代码树中包含合适的、可理解的注释，解释了代码的用途以及其执行操作的原因。	添加注释有助于确保产品在未来可以得到轻松支持，并加快漏洞修复。	“安全声明”明确说明了供应商如何生成代码来降低复杂度、提高可维护性。
V.C: 受保护的开发环境和构建环境
V.C: 总体目标	NCSC希望该产品的开发是在安全的环境中进行的。	安全的环境有助于保持产品的完整性，并降低供应链攻击风险。	“安全声明”描述了供应商如何通过保护开发环境和构建环境来保持其产品的完整性。
V.C.1: 开发环境隔离	开发环境与公司网络隔离，并且不受互联网影响。	这可以保护开发环境免受直接攻击的危害。		要求查看渗透测试或红队演练的详细信息，目标是修改供应商的代码库或开发环境。
V.C.2: 构建环境隔离	构建环境与公司网络隔离，并且不受互联网影响。很少有人能进行变更。	这可以保护构建环境免受直接攻击的危害。		要求查看渗透测试或红队演练的详细信息，目标是修改供应商的代码库或开发环境。
V.C.3: 构建环境与自动化	构建环境很简单，构建流程是自动化的。	简单的构建环境和自动化的构建流程使产品构建更易于理解、不太可能出现错误，并降低了入侵风险。	“安全声明”描述了如何理解和维护供应商构建流程。	对于客户选定的产品版本，供应商解释了构建环境及其依赖关系，演示了执行构建的自动化流程。
V.C.4: 基于角色的访问	只有有需要的个人才能访问内部代码库，并且访问权限根据角色进行控制和限制。	尽量减少访问，降低内部恶意人员的影响。	“安全声明”描述了供应商如何对其开发环境和构建环境实施基于角色的访问控制。	供应商证明，对开发环境和构建环境的访问是受限的。
V.C.5: 代码审查	所有代码在验收前均经过独立审查。 存在反馈流程。	代码审查对于维护编码标准和减少恶意内部人员造成的风险至关重要。	“安全声明”描述了供应商进行内部代码审查和审计的方式和时间。	对于代码的任何更改，供应商可以演示如何对该更改进行审查或审计。	–
V.C.6: 可复用的构建版本	可以在将来复制已发行软件的所有构建版本。	复制的构建版本使供应商可以证明过去构建版本中包含的组件。 追踪每个构建版本，看看内置了哪些组件以及使用了哪些版本的组件，对于验证构建版本的完整性至关重要。	“安全声明”明确说明了供应商如何维护其构建环境和代码库，以实现具有最少差异的重复构建，并对每个差异进行解释。	供应商复制了以前的构建版本，并确认其功能与发布的版本相同。 供应商证明其保留了构建版本所需的外部依赖项的副本。	比较发行的构建版本和复制的构建版本，验证功能等效性。
V.D: 漏洞利用缓解措施
V.D: 总体目标	供应商实施现代产品中使用的标准安全缓解措施。	每种缓解措施都有助于缓解众所周知的漏洞，从而对产品的安全性产生明显的积极影响。现代化平台、操作系统、开发语言、库和开发工具定期提供安全增强技术，最大限度地减少安全缺陷的出现，并在安全缺陷出现时将其影响降至最低。	“安全声明”描述了供应商关于使用防御性安全技术的策略。
V.D.1: 堆保护	供应商利用现代堆保护缓解措施来帮助防止针对产品的基于堆的内存损坏攻击。	广泛用于使攻击者更难利用安全问题。	“安全声明”说明供应商的产品是否使用堆保护。		通过（自动）检查产品，验证是否启用了堆缓解措施。
V.D.2: 栈保护	供应商只提供使用现代栈缓解措施编译的可执行代码。	广泛用于使攻击者更难利用安全问题。	“安全声明”说明供应商的产品是否使用栈保护。		通过（自动）检查产品，验证是否启用了栈缓解措施。
V.D.3: 数据执行保护	供应商支持硬件强制的数据执行保护（例如DEP或NX）。	广泛用于使攻击者更难利用安全问题。	“安全声明”说明供应商的产品是否使用硬件强制的数据执行保护。		通过（自动）检查产品，验证是否启用了数据执行保护缓解措施。
V.D.4: 地址空间布局随机化	供应商只提供使用现代地址空间布局随机化（ASLR）技术编译的可执行代码。	广泛用于使攻击者更难利用安全问题。	“安全声明”说明供应商的产品是否使用地址空间布局随机化技术。		通过（自动）检查产品，验证是否启用了地址空间布局随机化缓解措施。
V.D.5: 内存映射保护	供应商的产品不允许将内存页默认映射为“可写”和“可执行”文件。这不包括即时代码编译所需的代码区域。	广泛用于使攻击者更难利用安全问题。	“安全声明”说明供应商的产品是否有读写内存页。如果需要即时代码编译，则应在“安全声明”中对此进行描述。		通过（自动）检查产品，验证不存在将内存页映射为可写和可执行的可执行文件。
V.D.6: 最小特权代码	供应商在其产品中开发和执行代码时遵循“最低特权”方法。 供应商确保其产品仅以实现其广告目的所需的最低特权级别运行或只需要实现其广告目的所需的最低特权级别。如果需要更高的权限级别，则产品将实施隔离，以提升特定任务的权限。	以高于要求的权限级别运行的产品可以为攻击者利用主机系统提供路径。	“安全声明”说明了供应商的“最低特权”方法。		验证在供应商平台上运行的可执行代码是否以所需的最低权限级别运行。 验证有特权的可执行文件是否在完成其特权任务后放弃特权。
V.D.7: 安全改进和安全执行环境	该供应商制定了计划，以继续提高其产品的安全性。 例如，这可能包括详细说明其计划用何种方式、在何时实施安全执行环境。	产品安全需要继续提升，以适应不断变化的威胁环境。		探索供应商未来的安全路线图，讨论供应商的产品安全性将如何随着时间的推移而提高。
V.E: 安全更新和软件签名
V.E: 总体目标	在设备上运行的代码的源头是已知的，设备上代码的更改机制设备是安全的。	降低供应商代码编写和交付到设备之间的供应链攻击风险。
V.E.1: 软件和固件签名	供应商的软件和固件经过数字签名。	软件和固件的签名有力地说明了代码是由开发人员编写的。	“安全声明”描述了软件和固件是否经过数字签名，以及允许客户部署自己的代码的流程。		通过自动检查每个文件，使用供应商的公共代码签名证书对交付的可执行代码（二进制文件、脚本等）进行数字签名的测试。
V.E.2: 签名验证	在执行二进制文件之前验证软件签名。	允许设备检查代码源。	“安全声明”描述了在代码执行之前如何检查签名。说明该检查是否有硬件支持。		测试有签名的二进制文件的修改是否会导致设备拒绝运行该二进制文件。
V.E.3: 安全更新	更新通过设备和更新服务器之间相互验证的安全通道交付。	使用安全通道可以降低攻击者利用更新机制的风险。	“安全声明”描述了更新机制的安全属性。		执行更新流程，验证更新是否通过安全通道交付。
V.E.4 降级保护	当软件在安装过程中降级时，内置检测功能会发出警报。	旧版本产品中的已知漏洞是导致漏洞利用和入侵的常见原因。	“安全声明”描述了供应商如何防止降级攻击。		测试系统管理员是否可能看到早于当前安装版本的签名更新生成的日志消息或其他警报。
V.F: 硬件信任根与安全启动
V.F: 总体目标	供应商在其产品中使用安全的硬件信任根。硬件信任根通常有以下几种：可信执行环境（TEE）、可信平台模块（TPM）或专用安全组件（DSC）。	硬件信任根使供应商能够使用现代安全缓解措施，如安全启动和代码签名。	“安全声明”描述了供应商提供硬件支持的安全性的方法。
V.F.1: 硬件信任根	设备包含用于身份标识和存储的硬件信任根。	硬件信任根对于提供攻击者无法远程修改的硬件支持功能是必要的。	“安全声明”说明了产品的硬件信任根的存在和属性。	–	测试与身份标识或设备机密相关的私钥是否未以明文形式存储在文件系统中。
V.F.2: 安全启动	每个产品都支持安全启动流程。安全启动流程由硬件信任根（V.F.1）发起，旨在使设备在重启时进入已知的正常状态。	安全启动使对设备的入侵在电源循环后更难为继。 如果设备受到入侵，则需要安全启动来恢复对设备的信任。 否则，可能需要报废设备。	“安全声明”描述了供应商对安全启动的支持，以及在发生入侵时如何将供应商的产品恢复到已知的正常状态。	–	验证产品是否可以恢复到已知的正常状态。 测试如果在启动过程中使用的一个或多个签名的二进制文件或脚本被修改，设备是否无法启动。
V.F.3: 确保联合测试行动组（JTAG）的安全	产品上的每个计算元素都有访问已禁用的调试接口（如JTAG和通用异步收发器）。	通过物理访问，像JTAG这样的调试接口可以用来规避产品的完整性或窃取设备机密。			测试JTAG设备是否无法与系统的任何JTAG TAP控制器建立通信。
V.G: 安全测试
V.G: 总体目标	供应商在产品发布前严格测试其产品的安全性。	通过安全测试与解析，产品中的漏洞数量减少了，漏洞利用风险降低了。	“安全声明”描述了供应商在其产品范围内进行安全测试的方法。
V.G.1: 自动化测试	一旦制定了安全测试措施，就会对所有版本的适用产品自动运行广泛的安全测试。	这确保了测试的规模与攻击者所采用的规模相当。	“安全声明”描述了针对每个产品版本运行的自动化测试。	对于客户选定的产品版本，要求查看自动化测试的测试结果。	客户或第三方在可能的情况下应用他们自己的自动化测试。
V.G.2: 测试严谨性	开发人员不能修改构建环境来隐藏或忽略构建问题或自动化测试检测到的问题。 失败的构建将自动被拒绝。 因此，已发布产品中使用的代码在构建期间不会产生任何编译器错误或与安全相关的警告。	如果允许的话，开发人员可能会试图绕过检查，从而导致产品更容易受到攻击。	“安全声明”说明是否可以绕过测试。	对于客户选定的产品版本，要求查看构建结果。验证结果是否没有凸显不应在发行的构建版本中接受的问题。
V.G.3: 安全测试	对安全功能进行测试，证明操作正确。	如果安全功能实施不当，设备可能会受到攻击。	“安全声明”说明是否执行安全测试以验证正确的操作。	对于客户选定的产品版本，要求查看安全测试的结果。验证问题是否已解决，包括根本原因。	重复安全功能测试。
V.G.4: 负面测试	对每一个产品版本都进行了广泛的负面测试，包括各种潜在故障案例、不适当的消息排序和格式错误的消息。	通过使用大量负面测试用例进行测试，供应商更有可能发现易于检测的问题。	“安全声明”说明是否执行了负面测试，并描述了该测试的规模。	对于客户选定的产品版本，要求查看负面测试的测试结果。验证问题是否已解决，包括根本原因。	对产品进行负面测试，最好使用供应商的不同工具集。
V.G.5: 模糊测试	模糊测试是针对产品执行的，尤其关注跨越安全边界的接口。该方法足够复杂，可以确保很大一部分代码都接受了测试。	供应商根据随机生成的错误数据测试其产品，以发现易于检测的问题。这是一种特定形式的负面测试。	“安全声明”说明是否执行了模糊测试，并指出了该测试的范围。	对于客户选定的产品版本，要求查看模糊测试的测试结果以及代码覆盖率数据。验证问题是否已解决，包括根本原因。	对产品进行模糊测试，最好使用供应商不熟悉的工具集。
V.G.6: 外部测试	外部安全研究团队针对选定的主要产品版本进行测试。其中一些测试没有确定范围。	将设备交由外部第三方，更容易检测和修复漏洞。	“安全声明”中明确地详述了供应商如何与外部实验室和学术机构合作、确保其产品安全经过了独立测试。	要求查看外部测试的结果。验证问题是否已解决，包括根本原因。
V.G.7: 动态应用程序安全测试（DAST）	供应商将DAST解决方案集成到供应商的测试流程中。	在测试期间应用DAST可以识别不同类型的漏洞。这些漏洞与模糊测试和负面测试的漏洞不同。	“安全声明”说明了供应商如何执行动态应用程序安全测试。	要求查看DAST套件的结果。验证问题是否已解决，包括根本原因。	对产品进行动态应用程序安全测试，最好使用供应商不熟悉的工具集。
V.H: 安全管理与配置
V.H: 总体目标	任何产品都可以轻松设置、实现安全运行。	配置不安全的产品更有可能被利用。	“安全声明”描述了供应商帮助运营商安全配置产品的方法。这包括产品是否以“安全”配置发布。
V.H.1: 产品加固	该产品可以轻松加固、实现安全配置。 有文件可帮助客户执行该加固流程。如果设备脱离加固状态，则会创建警报。	配置不安全的产品更有可能被利用。	“安全声明”声明说明产品是否可以轻松加固、实现安全配置。	验证是否为供应的产品提供了安全配置指南。	测试加固指南是否可以在不影响必要的功能的情况下按原样轻松部署到产品上。   测试设备脱离加固状态时是否会创建警报。
V.H.2: 协议标准化	配置产品，使其仅使用标准化协议。	专有协议不允许进行彻底、独立的安全测试，也不允许客户理解正确的行为。			分析来自设备的流量，以确保没有使用专有协议。
V.H.3: 管理面板安全	默认情况下，产品配置为仅在管理面板上使用最新的安全协议。	如果没有安全协议和基于用户的访问，就不可能安全地管理设备并将管理更改与特定管理员关联。	“安全声明”确认产品默认情况下是否仅使用安全管理协议。		测试管理面板上是否未启用弱安全协议或已弃用的安全协议。
V.H.4: 管理访问权限	对管理面板的访问是基于用户的，并且支持基于非对称密钥的访问（例如X.509证书或SSH密钥）。	这允许客户限制管理权限并调查潜在的恶意更改。 使用基于非对称密钥的身份验证提高了身份验证的安全性，有助于降低密码共享的风险。			测试管理面板是否为管理员提供了基于用户的访问、是否支持基于非对称密钥的身份验证。
V.H.5: 没有未加密的协议	尽可能使用安全协议（例如SSH和HTTPS）。如果启用了未加密的协议，并且存在安全的替代方案，则产品会向管理员发出警告，并提供创建安全警报的选项。	防止使用不安全的协议，因为使用不安全的协议会增加漏洞利用的风险。			测试产品上是否没有默认启用的未加密协议和服务。 测试在产品上启用未加密的协议是否会产生适当的警告和警报。
V.H.6: 没有非法的管理机制	该产品没有任何非法的管理员帐户。非法的管理员帐户包括但不限于硬编码密码、访问密钥对（SSH密钥）或其他管理访问令牌。	在客户不知道的情况下，非法的管理帐户可能会被利用。	“安全声明”明确说明了产品上是否有任何非法的管理帐户。		搜索已发行产品中存在非法的管理员帐户的证据。
V.H.7: 没有非法的管理功能	该产品没有任何非法的管理功能。	在客户不知道的情况下，非法的管理功能可能会被利用。	“安全声明”明确说明了产品上是否有任何非法的管理功能。		搜索已发布产品中存在非法的管理员功能的证据。
V.H.8: 没有默认凭据	初始设置后，设备上没有保留默认密码。 为清楚起见，这也意味着管理帐户没被编入供应商的软件中。	如果未禁用任何非唯一或硬编码帐户，则设备极易被利用。	“安全声明”明确说明了如何从所有设备中删除默认凭据、是否存在硬编码的管理帐户。		测试初始设置后设备上是否没有默认凭据。 扫描产品以查找潜在的硬编码密码字符串。
V.H.9: 良好实践指南	供应商清楚其试图缓解及没有缓解的的设备威胁。供应商提供了关于如何在网络中保护设备的详细配置和说明。	通过帮助理解供应商做出的安全决策、安全地设置设备，就不太可能出现安全错误。	“安全声明”描述了供应商进行安全分析的方法，以及供应商如何帮助客户将风险降至最低。	对于客户选定的产品，探索供应商的产品安全分析，并考虑供应商是否了解风险环境并制定了适当的缓解措施。
V.J: 漏洞与问题管理
V.J: 总体目标	存在有效的流程来管理安全问题和漏洞。这些问题得到了快速有效的解决。	从发现问题到修补问题，产品最容易受到攻击。 有效的问题管理减少了这种风险。	“安全声明”描述了供应商解决问题的方法。
V.J.1: 问题跟踪和补救	供应商有发布补救措施的流程。这确保了该漏洞在所有受影响的产品中都得到了修复。在适当的时间范围内修补漏洞。	如果问题没有在所有产品线的所有版本中得到解决，那么同一问题可能会继续在某个产品版本中被利用。	“安全声明”提供了供应商解决安全问题的计划表，描述了供应商如何跟踪所有产品的漏洞。	假设软件组件易受攻击，要求查看包含该组件的所有产品。	测试以前报告和解决的漏洞是否仍可能在一系列产品中被利用。
V.J.2: 问题理解	对于问题，供应商确定问题的根因分析，并能够详细说明漏洞的来源。	妥善的漏洞管理要求供应商了解自己的产品并快速评估漏洞的影响。		对于客户选定的漏洞，供应商可以提供漏洞的详细信息、漏洞的根本原因以及正确修复漏洞的方式和时间。
V.J.3: 漏洞报告	供应商提供了公开的安全问题披露途径，该途径与漏洞管理流程相关联。	这允许外部人员和组织负责地向供应商披露安全问题。	“安全声明”描述了如何向供应商报告漏洞。	探索供应商如何解决以前报告的问题。
V.J.4: 问题透明度	供应商在安全问题的修补方面保持透明。	在该领域，大多数安全问题都是在客户没有意识到其存在的情况下修补的。这为客户判断风险带来了困难。	“安全声明”提供了报告和解决的安全问题的指标。 可以获取产品中所有修补的安全问题列表。
V.J.5: 产品安全事件响应团队（PSIRT）	供应商已在其组织内建立了PSIRT结构。	产品安全不限于研发。PSIRT将研发、质量管理、技术支持中心、公共安全办公室集合在一起，负责客户的安全产品操作。	“安全声明”描述了如何联系供应商的PSIRT团队。	要求供应商提供所选版本的产品安全事件响应计划。	在实验室测试期间发现漏洞时，将其报告给PSIRT团队，并验证供应商的响应是否有效。

【免责声明】

该文章原文版权归原作者所有。文章内容仅代表原作者个人观点。本译文仅以分享先进网络安全理念为目的，为业内人士提供参考，促进思考与交流，不作任何商用。如有侵权事宜沟通，请联系littlebee@nsfocus.com邮箱。

【译者简介】

小蜜蜂翻译组公益译文项目，旨在分享国外先进网络安全理念、规划、框架、技术标准与实践，将网络安全战略性文档翻译为中文，为网络安全从业人员提供参考，促进国内安全组织在相关方面的思考和交流。