当一个漏洞不可被利用时，它是否可以被利用?

在我的最后帖子我描述了一个关于VEX的重要问题，这个问题还没有在任何公开的文档中讨论过(但应该讨论):如何处理这样一个事实，即用户如何解释一个产品中的漏洞是否可以利用的声明(当然这是VEX的目的)将在很大程度上取决于他们认为他们面临的攻击者的类型。这一点很重要，因为如果用户对黑客技能水平的假设与供应商的假设有很大差异，那么当供应商指定产品中的漏洞为可利用或不可利用时，他们可能会得出完全错误的结论。

还有另一个问题，就像第一个问题一样，根本没有在印刷中讨论过，但也很重要(尽管在ntia -现在的cisa VEX工作组中讨论过很多次，就像黑客技能水平问题一样):供应商在准备VEX声明时，应该如何考虑它安装的环境，尤其是任何安全控制。以下是出现这个问题的几种形式:

1. 假设一个漏洞通常是不可利用的，除非更改了默认配置设置。如果用户做出了这样的更改(无论是有意还是无意)，这是否意味着产品中的漏洞可以被利用，意味着它在VEX语句中的状态应该受到“影响”?
2. 现在让我们假设一个本来可以利用的漏洞，将被供应商书面建议的产品配置设置(但不是默认配置的一部分)呈现为不可利用的漏洞。供应商是否应该将产品中该漏洞的VEX状态列为“受影响”?毕竟，用户可能不会听从他们的建议。
3. 如果供应商建议他们的产品不要连接到互联网，并说某个特定的漏洞是不可利用的，但用户还是将产品连接到互联网，并通过利用该漏洞而受到威胁，这是否意味着该漏洞实际上是可利用的?
4. 如果供应商说，如果他们的产品没有连接到互联网，就无法利用漏洞，但由于产品的操作方式，如果没有连接，就很难有效地使用产品，该怎么办?如果漏洞被利用，用户因此遭受损失，这是供应商的错还是用户的错?毕竟，该供应商表示，如果产品没有连接到互联网，这个漏洞就不会被利用。
5. 如果供应商建议安全部署他们的产品，但没有说明这意味着什么，而用户错误地没有将产品置于防火墙后，该怎么办?如果产品因为缺乏防火墙而受到损害，这是供应商没有明确说明需要防火墙的错误吗?
6. 如果供应商假定用户通常会安装web应用程序防火墙，但却没有在安装说明中明确说明，该怎么办?用户有一个正常的有状态检查防火墙，但没有WAF，他们会通过WAF保护的漏洞受到威胁。这是他们的错还是供应商的错?或者这两者都不是错?
7. 如果供应商发布了针对漏洞的补丁怎么办?该漏洞是否可以利用?

以下是我认为应对这种情况的规则(这种情况经常出现):供应商应该假设a)用户已经遵循了供应商书面建议的任何配置或环境设置，和B)用户没有更改任何默认设置;和c)用户已经遵循了基本的安全最佳实践(尽管供应商不必确切地说明他们认为这些最佳实践是什么)。

然而，当供应商认为用户可能对产品应该如何配置有任何疑问，或者在特定情况下什么构成安全最佳实践时，他们应该始终采取额外的步骤，明确地说明他们的想法。以下是我对每个问题的回答:

1. 默认配置设置构成了供应商强烈的建议，他们希望用户保留该设置，这意味着供应商有理由相信用户不会更改该设置。因此，该漏洞将处于“未受影响”(即不可利用)的VEX状态。但是，如果供应商在其文档中明确指出需要配置设置来防止该漏洞的利用，并且如果用户更改了该设置，则可能会因其操作而面临被泄露的风险，那么这肯定会为供应商和客户省去很多麻烦。
2. 这与第一个问题非常相似，但不同之处在于，在这种情况下，配置设置只是推荐的，而不是默认配置的一部分。然而，在我看来，供应商有理由假设用户遵循了建议。因此，VEX状态应该是“不受影响”。同样，如果供应商在他们的文档中明确指出，更改这个默认设置可能会使他们容易受到攻击，这将有所帮助。
3. 这实际上和第二个问题是一样的。供应商已经提出了安装建议，并有理由假设它将被遵循。同样，漏洞的状态应该是“不受影响”。
4. 从表面上看，这与第三个问题相同，但实际上非常不同。我希望没有供应商会采取这种愤世嫉俗的方法，要求用户做一些使他们的产品无法使用的事情，但我相信有一些供应商能够并且将会这样做。在这种情况下，供应商分配了一个“不受影响”的状态，但他们是基于用户不会像预期那样使用产品的假设——这显然是马粪。如果客户不止一次看到类似的事情发生，可能会重新评估他们是否希望继续与该供应商合作。谁知道他们还会采取什么见不得人的行动?
5. 在我看来，防火墙是基本的安全最佳实践。任何供应商都不应该告诉他们的用户安装防火墙。因此，供应商应该声明该漏洞不可利用(“未受影响”)。
6. 我不认为WAF是一种基本的安全最佳实践。如果供应商认为需要一个保护他们的产品，他们应该明确地说明，而不仅仅是假设。因此，供应商应将漏洞的状态列为“受影响”，并将WAF列为漏洞的缓解措施。
7. 重要的是要记住，问题从来不是产品本身是否容易受到攻击，而是产品的某个特定版本是否容易受到攻击。如果产品A版本2.0.0易受CVE-2023-12345攻击，但已针对该漏洞发布了补丁，则补丁版本必须具有新的版本字符串，例如v2.0.1。此外，如果用户将补丁应用于v2.0.0，则其实例的版本应该更改为2.0.1。这对于VEX的工作和支持都是必需的，因为如果多个代码库具有相同的版本号，则产品将变得不受支持。因此，v2.0.0的状态应该是“受影响的”，而v2.0.1的状态应该是“固定的”或“不受影响的”。v2.0.0的“受影响”状态的缓解措施可能是“升级到v2.0.1”或“应用补丁XYZ，在(URL)可用”，或者两者都有。

这个问题，以及我在上一篇文章中讨论的黑客技能水平问题，都是需要讨论和记录的问题。对于这两个问题，都没有一个“正确”的答案，但确实需要一些明确的立场，以便供应商和用户都能正确地解释状态设置。为了解决这样的问题，我们需要一本VEX手册。它可能由中钢协VEX工作组开发;它可能由SBOM论坛开发;或者它可能是由其他小组开发的，在那里人们与SBOM和VEX讨论问题。但它需要发展。

在这篇博客文章中表达的任何观点严格来说都是我的，并不一定与Tom Alrich LLC的任何客户共享。如果你想对你在这里读到的东西发表评论，我很乐意听到你的声音。请电邮至tom@tomalrich.com。