令人振奋的消息！我们对 detection-rules 存储库的“检测即代码”(DaC) 改进现已推出测试版。今年 5 月，我们分享了关于通过 Elastic Security 自行部署“检测即代码”研究的 Alpha 阶段。Elastic 正在努力在 Elastic Security 中支持 DaC。虽然未来 DaC 将集成到 UI 中，但当前的更新侧重于 main 分支上的检测规则存储库，以允许用户快速设置 DaC 并通过可用的测试和命令与 Elastic Security 的集成来获得即时价值。我们有大量的文档和示例，但让我们快速了解一下这对我们的用户意味着什么。
为何选择 DaC？
从验证和自动化到增强跨供应商内容，使用 DaC 方法进行规则管理有多种先前讨论过的原因。我们的检测工程师团队已经使用检测规则存储库来测试和验证我们的规则一段时间了。现在，我们可以以更容易访问的方式提供我们执行的相同测试和验证。我们的目标是通过在我们的检测规则存储库中添加简单的 CLI 命令来增强用户的能力，以帮助管理版本控制系统 (VCS) 和 Kibana 之间完整规则生命周期的规则。这允许用户使用 CI/CD 管道在一个命令中轻松移动、单元测试和验证他们的规则。
提高流程成熟度
安全组织面临着同样的底线，即我们不能依赖静态的开箱即用签名。DaC 的核心是一种将软件开发实践应用于安全检测规则的创建和管理的方法，从而在安全检测的开发和部署中实现自动化、版本控制、测试和协作。单元测试、同行评审和 CI/CD 使软件开发人员对其流程充满信心。这有助于在错误和效率低下影响客户之前将其捕获。检测工程也应如此。为了符合此声明，这里有一些我们正在支持的新功能的示例。有关完整文档，请参阅我们的 DaC 参考指南。
批量导入和导出自定义规则
现在可以使用 kibana import-rules 和 kibana export-rules 命令在 Kibana 中批量移动自定义规则。此外，可以使用 import-rules-to-repo 和 export-rules-from-repo 命令在 TOML 格式和 ndjson 之间批量移动它们。除了规则之外，这些命令还支持使用适当的标志移动例外和例外列表。ndjson 方法的优点是，它允许工程师在单个文件中管理和共享规则集合（由 CLI 或从 Kibana 导出），这在不允许访问其他 Elastic 环境时非常有用。使用这些方法中的任何一种移动规则时，除非另有指定，否则规则会通过架构验证，以确保规则包含适当的数据字段。有关这些命令的更多信息，请参阅检测规则中的 CLI.md 文件。
可配置的单元测试、验证和架构
有了这项新功能，我们现在可以配置使用配置文件的单元测试和架构验证的行为。在这些文件中，您现在可以设置要跳过的特定测试，指定仅运行特定测试，以及针对特定规则的架构验证。您可以通过运行 make test 随时运行此验证和单元测试。此外，您现在可以将您的架构（JSON 文件）带入我们的验证过程。您还可以指定将哪些架构用于您的堆栈的哪些目标版本。例如，如果您有仅适用于 8.14 版本中的规则的自定义架构，而您有应使用于 8.10 版本的不同架构，现在可以通过配置文件进行管理。有关更多信息，请参阅我们的示例配置文件，或使用我们的 custom-rules setup-config 命令从检测规则存储库中为您生成一个示例。
自定义版本控制
我们现在提供使用与 Elastic 内部团队用于管理我们的规则以进行发布相同的版本锁定逻辑来管理自定义规则的功能。这是通过版本锁定文件完成的，该文件检查规则内容的哈希并确定它们是否已更改。此外，我们还提供了一个配置选项来禁用此版本锁定文件，以允许用户使用替代的版本控制方法，例如直接使用 git 存储库。有关更多信息，请参阅我们文档的版本控制部分。请注意，您仍然可以依赖 Kibana 的版本控制字段。
拥有这些系统可以为维护安全规则提供可审计的证据。采用部分或全部这些最佳实践可以显着提高维护和开发安全规则的质量。
更广泛地采用自动化
虽然质量至关重要，但安全团队和组织面临着不断增长的规则集，以应对不断扩展的威胁形势。因此，通过提供快速部署和执行来减轻安全分析师的压力同样至关重要。对于我们的存储库，我们有一个一站式商店，您可以在其中设置配置，专注于规则开发，并让自动化处理其余的事情。
降低准入门槛
首先，只需克隆或派生我们的检测规则存储库，运行 custom-rules setup-config 以生成初始配置，然后导入您的规则。从这里开始，您现在可以使用单元测试和验证。如果您使用的是 GitLab，您可以快速创建 CI/CD，将最新的规则推送到 Kibana 并运行这些测试。这是一个示例，说明它可能是什么样子
高灵活性
虽然我们使用 GitHub CI/CD 来管理发布操作，但这绝不意味着这是管理检测规则的唯一方法。我们的 CLI 命令除了 Python 要求之外没有任何依赖项。也许您已经开始实施一些 DaC 实践，并且您可能希望利用我们提供的 Python 库。无论如何，我们都希望鼓励您尝试在工作流程中采用 DaC 原则，并且我们希望提供灵活的工具来实现这些目标。
为了说明一个示例，假设我们有一个组织已经使用 VCS 管理自己的规则，并构建了自动化来在部署环境之间来回移动规则。但是，他们希望根据他们正在收集并存储在数据库中的遥测数据来增强这些移动的测试。我们的 DaC 功能已经提供了可以按规则运行的自定义单元测试类。实现此目标可能就像 fork 检测规则存储库并编写一个单元测试一样简单。下图显示了这可能是什么样子的示例。
这个新的单元测试可以利用我们的单元测试类和规则加载来提供脚手架，以便从文件或 Kibana 实例加载规则。接下来，可以针对每个规则 ID 创建不同的集成测试，以查看它们是否通过了组织期望的结果（例如，规则是否识别出正确的行为）。如果通过，则 CI/CD 工具可以按原计划继续进行。如果失败，则可以使用 DaC 工具将这些规则移动到“需要调整”文件夹和/或将这些规则上传到“调整”Kibana 空间。通过这种方式，可以使用我们工具和自己工具的混合来维护一个最新的 Kibana 空间（或 VCS 控制的文件夹），其中包含需要更新的规则。在进行更新并解决问题后，它们也可以在各个空间之间不断同步，从而形成一个更具凝聚力的环境。
这只是关于如何在您的环境中使用我们新的 DaC 功能的一个想法。实际上，有无数种不同的使用方式。
实践
现在，让我们看看如何将这些新功能整合到统一的 DaC 策略中。提醒一下，这不是规定性的。相反，这应该被认为是一个可选的、入门级的策略，可以以此为基础来达到您的 DaC 目标。
建立 DaC 基线
在检测工程中，我们希望协作成为默认而不是例外。检测规则是一个公共存储库，正是出于这个考虑。现在，它可以成为社区和团队成员不仅与我们协作，而且彼此协作的基础。让我们以下图为例，说明其可能的样子。
从左到右阅读，我们有初始计划和优先级排序，以及驱动检测工程的后续威胁研究。对于每个用户来说，此过程看起来会有很大不同，因此我们不会在此处花费太多时间来描述它。但是，结果将在很大程度上相似，即创建新的检测规则。这些规则可以采用各种形式，例如 Sigma 规则（稍后在博客中介绍更多内容）、Elastic TOML 规则文件，或直接在 Kibana 中创建规则。无论格式如何，一旦创建这些规则，就需要进行暂存。这将在 Kibana、您的 VCS 或两者中进行。从 DaC 的角度来看，目标是同步规则，以便该过程/自动化了解这些新添加的内容。此外，这还提供了对这些添加进行同行评审的机会，这是协作的第一步。
这很可能发生在您的版本控制系统中；例如，在 GitHub 中，可以使用带有必需批准的 PR，然后再合并回充当已审查规则权威来源的主分支。下一步是进行测试和验证，此步骤还可以在同行评审之前进行，这在很大程度上取决于所需的实施方案。
除了任何其他内部发布流程之外，通过遵守此工作流程，我们可以降低错误规则和错误到达我们的客户和社区的风险。此外，拥有证据工件、通过单元测试、架构验证等，可以激发信心并为每个用户提供选择他们愿意承担的风险的控制权。
部署和分发后，可以在 Kibana 中监视规则性能。可以直接从 Kibana 或通过 VCS 对这些规则进行更新。这将在很大程度上取决于实施细节，但在任何情况下，都可以将这些规则视为与新规则非常相似，并且会经历相同的同行评审、测试和验证过程。
如上图所示，这可以提供一种统一的方法来处理来自社区、客户或内部反馈的规则更新。由于规则最终以版本控制文件的形式存在，因此有一个专用的格式真实来源可用于合并和测试。
除了流程质量改进之外，拥有权威的已知状态还可以增强额外的自动化。例如，不同的客户可能需要不同的测试或不同的数据源。无需手动解析规则，我们提供统一的配置体验，用户只需引入自己的配置和架构，就可以确信满足了他们的特定要求。所有这些都可以通过 CI/CD 自动管理。通过完全自动化的 DaC 设置，可以完全从 VCS 和 Kibana 利用此系统，而无需编写其他代码。让我们看一个示例，说明其可能的样子。
示例
在此示例中，我们将扮演一个希望通过 DaC 管理 2 个 Kibana 空间的组织的角色。第一个是规则作者将用来编写检测规则的开发空间（因此，让我们假设已经有一些预先存在的规则）。还将有一些开发人员直接以 TOML 文件格式编写检测规则并将其添加到我们的 VCS 中，因此我们需要管理这些规则的同步。此外，该组织希望强制执行单元测试和架构验证，并可以选择对将部署到同一 Kibana 实例中生产空间的规则进行同行评审。最后，该组织希望所有这些都以自动方式进行，而无需在本地克隆检测规则或在 GUI 之外编写规则。
为了实现此目标，我们需要使用检测规则中的一些新 DaC 功能并编写一些简单的 CI/CD 工作流程。在此示例中，我们将使用 GitHub。此外，您可以在 此处 找到此示例的视频演练。请注意，如果要跟随操作，您需要 fork 检测规则存储库并使用我们的 custom-rules setup-config 命令创建初始配置。此外，有关如何使用 DAC 功能的常规逐步说明，请参阅此 快速入门指南，其中包含多个示例命令。
开发空间规则同步
首先，我们将从 Kibana -> GitHub (VCS) 进行同步。为此，我们将使用 kibana import-rules 和 kibana export-rules 检测规则命令。此外，为了保持规则版本的同步，我们将使用锁定的版本文件，因为我们希望我们的 VCS 和 Kibana 都能够使用最新版本覆盖彼此。对于此设置，这不是必需的，可以使用 Kibana 或 GitHub (VCS) 作为权威，而不是锁定的版本文件。但是，为了方便起见，我们将使用它。
第一步是让我们创建一个手动分发触发器，该触发器将根据请求从 Kibana 中提取最新规则。在我们的设置中，这可以自动完成；但是，我们希望让规则作者控制何时将规则移动到 VCS，因为 Kibana 中的开发空间正在积极用于开发，并且新规则的存在并不一定意味着该规则已准备好用于 VCS。手动分发部分可能如下所示 示例
有了这个触发器，我们现在可以编写 4 个额外的作业，这些作业将在工作流程分发时触发。
- 从所需的 Kibana 空间中提取规则。
- 更新版本锁定文件。
- 创建 PR 请求以供审阅，以便合并到 GitHub 中的主分支中。
- 设置 PR 的正确目标。
这些作业也可能如下所示，来自同一个 示例
现在，一旦我们运行此工作流程，我们应该期望看到一个 PR 打开，其中包含来自 Kibana Dev 空间的新规则。我们还需要将规则从 GitHub (VCS) 同步到 Kibana。为此，我们需要在拉取请求上创建一个触发器
接下来，我们只需要创建一个作业，该作业使用 kibana import-rules 命令将给定 PR 中的规则文件推送到 Kibana。请参阅第二个 示例 以获取完整的工作流程文件。
完成这两个工作流程后，我们现在可以在 GitHub 和 Kibana Dev 空间之间同步规则。
生产空间部署
在开发环境同步后，现在我们需要处理生产环境。提醒一下，为此，我们需要强制执行单元测试、模式验证、对合并到主分支的 PR 提供同行评审，并在合并到主分支时自动推送到 Kibana 的生产环境。为了实现这一点，我们需要两个工作流文件。第一个将在所有拉取请求和推送到版本化分支时运行单元测试。第二个会将合并到主分支的最新规则推送到 Kibana 的生产环境。
第一个工作流文件非常简单。它有一个 on push 和 pull_request 触发器，其核心工作是运行下面显示的 test 命令。有关完整的工作流，请参阅此示例。
通过这个 test 命令，我们正在使用配置文件中指定的参数，对所有自定义规则执行单元测试和模式验证。现在我们只需要工作流将最新规则推送到生产环境。此工作流的核心是 kibana import-rules 命令，只是将生产环境作为目标。但是，此工作流还提供了一些额外的选项，这些选项不是必需的，但在本示例中很不错，例如覆盖和更新异常/异常列表以及规则的选项。核心作业如下所示。请参阅此示例以获取完整的工作流文件。
有了它，通过这 4 个工作流文件，我们就拥有了一个同步的开发环境，其中的规则通过了单元测试和模式验证。我们可以通过使用拉取请求进行同行评审，这可以在 GitHub 中设置为要求，然后再允许合并到主分支。在 GitHub 中合并到主分支时，我们还会自动推送到 Kibana 生产环境，从而建立了已通过我们组织要求并准备好使用的规则基线。所有这些都是在不编写额外 Python 代码的情况下完成的，只需在 GitHub 工作流中使用我们新的 DaC 功能即可。
结论
既然我们已经达到了这个里程碑，您可能想知道接下来会发生什么？我们计划在接下来的几个周期中继续测试极端情况，并将社区的反馈纳入我们日常的冲刺中。我们还有一个功能请求考虑事项的积压，因此如果您想表达您的意见，请查看标题为 [FR][DAC] Consideration: 的问题，或者如果没有记录，请打开一个类似的新问题。这将有助于我们优先考虑对社区最重要的功能。
我们一直有兴趣听到像这样的用例和工作流，因此一如既往，请通过 GitHub 问题与我们联系，在我们的 security-rules-dac Slack 频道中与我们聊天，并在我们的讨论论坛中提问！