从一开始，Elastic detection-rules 仓库不仅包含 Elastic 的预构建检测规则，还包含用于检测规则管理的额外工具——例如 Elastic 威胁研究与检测工程（TRaDE）团队使用的一套测试、CLI 命令和自动化脚本。

Elastic 的 TRaDE 团队多年来一直遵循检测即代码（Detections as Code，DaC）实践，支持我们针对 Elastic 预构建检测规则和端点规则的内部开发与发布流程。客户过去主要使用 detection-rules CLI，它提供了 Kibana API（应用程序编程接口） 封装和 CLI 命令，以便通过 Elastic SIEM 进行规则管理，但要求用户采用 Elastic 的内部流程和严格限制。

随着 DaC 日益主流化，并且我们持续践行对开放性的承诺，我们正在努力让用户更容易使用 Elastic 的 detection-rules 仓库来启动自己的 DaC 流程，以进行规则管理。这一 DaC 扩展将基于此前的检测规则功能，为检测工程师提供端到端体验。

这种方法增强了安全团队之间的协作，简化了更新流程，并有助于更敏捷地响应不断演变的威胁。从根本上说，我们致力于通过开放更多内部能力供客户嵌入其流程，来提升客户的检测工程成熟度。

为什么采用检测即代码？

如果你听说过基础设施即代码（Infrastructure as Code，IaC）这样的 DevOps 概念，那么检测即代码应该会让你感到熟悉。IaC 侧重于通过代码管理和配置基础设施，而 DaC 则将类似原则应用于将安全检测规则作为代码进行管理。检测即代码希望采用编码最佳实践进行检测管理，使用同行评审流程和工具以及自动化 CI/CD 流水线。

DaC 的好处包括高质量检测、检测部署的灵活性和规模，以及对变更管理要求的合规性。

DaC 的采用由以下几个因素驱动：

• 推动安全团队成熟：实施 DaC 鼓励在安全团队内开发成熟、可重复的流程。它通过系统化的同行评审和严格测试，支持维护高质量检测。

• 不断增长的规则集：随着规则数量增加，不使用 DaC 维护检测规则将变得难以为继。

• 不断扩大的威胁态势：防御新兴威胁所需的覆盖广度，要求采用适合多样化技能组合的可扩展方法。

• 自动化的更广泛采用：技术环境中更广泛的自动化趋势，例如 IaC 原则的采用，要求安全团队使用的所有工具具备更强的自动化能力。DaC 通过将规则管理集成到自动化工作流中与这一趋势保持一致，确保一致性、效率以及快速响应新威胁的能力。

• 合规与治理要求：许多组织正在采用 DaC，以满足同行评审、变更控制和 SIEM 检测灾难恢复方面的认证合规要求。实施 DaC 可确保安全规则按照严格的治理标准进行开发、评审和维护，并提供可审计的合规证据。

DaC 方法和当前开发重点

由于 DaC 实际上是一种方法，而我们的用户有不同的基础设施和流程需求，因此在你的组织中使用 Elastic Security 架构和实施 DaC 有多种方式。但关键组件保持不变，用户需要：

• Elastic Security 解决方案

• 自选的版本控制系统

• 包含检测内容的仓库

• 用于连接所有组件、自动化关键流程并提供用户界面的工具

我们最初的重点是为客户提供这些组件，以加速 DaC 开发，在第一阶段，我们专注于将 detection-rules 仓库作为主要构建块。

让我们进入 alpha 阶段！

我们与多位用户进行了交流，了解他们在 DaC 方面的需求和优先事项。根据收到的反馈，我们进行了以下增强：

• 增强 1：在第一阶段，我们专注于让 detection-rules 仓库更易于用于您的自定义规则管理。我们的目标是尽量减少用户在使用 fork 的 detection-rules 仓库进行自定义规则管理时的合并冲突。我们现在提供了一个配置，用于指定自定义规则目录，供用户使用我们内置的规则加载器 schema 验证器进行加载。

• 增强 2：我们实现了可配置哪些 Elastic 提供的单元测试应在您的自定义规则上运行，哪些应被跳过。我们理解一些客户希望使用我们的一些单元测试并遵循我们的最佳实践，而其他测试则是专为 Elastic 规则管理设计的。您现在可以在配置文件中指定要运行的测试。

• 增强 3：我们认识到需要将异常和操作等附加规则设置与检测规则一起管理，因此我们添加了支持，以便在仓库中灵活管理这些内容。

概念的层次结构与术语体系

这项计划的主要成果之一是我们对思路和考量的文档化。尽管我们已经重构了 detection-rules 仓库，使其对外部用户更加灵活，但我们认识到 DaC 不仅仅是一个可以安装的工具。它是安全规则管理方式的根本性转变。

我们创建了概念的层次结构与术语体系，并将其文档化，供您在实施任何具体的 DaC 工作流之前参考。

在参考文档和幻灯片中，您可以了解更多关于 DaC 核心组件的内容：

• 在版本控制系统（VCS）中维护规则

• 将规则从 VCS 同步到各自的平台

• 在平台中管理规则

• 将规则从平台同步到 VCS

此外，我们还记录了使用以下方式治理 DaC 核心组件的不同模型：

• 以 VCS 为权威来源

• 以平台为权威来源

• VCS 与平台之间的双向同步

根据所需的方法，我们提供了不同层次的细节，距离 Elastic Security 解决方案越远，内容就越抽象。

我们还提供了什么？

最近在 BsidesOK24 上，我们讨论了 Elastic 的 DaC 方法，以及如何利用我们 alpha 分支中的 detection-rules 仓库。虽然我们可以将其拆分为关于如何实施 DaC 的迷你系列，但这些建议纯粹是推测性的，关于实施如何最适合你的环境。因此，我们分享的是将检测规则作为代码（detections as code）的核心原则。

幻灯片：这些幻灯片展示了高层组件、工作流和划分。它还涉及使用 detection-rules 仓库的好处以及一个快速入门的端到端参考示例。

参考文档：这份参考文档包含了开发、部署和管理检测规则（尤其是在 Elastic Security 环境中）的考虑因素、优缺点。它特别适用于：

• 希望利用自动化实现更高效的规则管理并更快速响应新兴威胁的安全分析师

• 寻找简化检测逻辑开发、测试和部署方法的检测工程师

• 希望在其团队中实施规则版本控制、协作和质量保证最佳实践的安全团队负责人

• 参与将安全实践集成到 CI/CD 管道中的 DevOps 工程师，旨在在其工作流中实现更协调和自动化的安全方法

• 探索将 as-code 原则纳入安全运营以增强敏捷性、可重复性和可靠性的 IT 安全架构师

对于希望获得更明确方向的人，我们确实对 detection-rules 方法有所偏好。请注意，alpha detection-rules 分支、这些幻灯片中的内容以及本参考指南可能会发生变化。一旦我们最终将更改迁移到 `main` 分支，我们将相应地更新内容。

总结和后续步骤

简而言之，在第一阶段，我们专注于使 detection-rules 仓库更易于用于你的自定义规则管理。我们的目标是最大限度地减少用户在使用分叉的 detection-rules 仓库进行自定义规则管理时的合并冲突。我们还启动了一份 DaC 生活指南，其中包含优缺点考虑，以配合仓库更改，让你能够快速上手。最后，我们开始在 BsidesOK 上分享我们的方法，包括可能适用于你的自定义设置的具体命令和用例。

现在我们处于 alpha 阶段，我们请求感兴趣的用户在我们的 detection-rules/DAC-feature 分支上进行测试并提供反馈！如需更多信息，请随时在我们的 Community Slack 的 #security-rules-dac 频道上联系我们，或更直接地在我们的 detection-rules 问题跟踪器上联系我们。

本文章中描述的任何功能或功能的发布和时间安排均由 Elastic 自行决定。当前不可用的任何功能或功能可能无法按时交付或根本无法交付。

注册 Elastic Cloud 免费试用

在你选择的云提供商上启动一个完全加载的部署。作为 Elasticsearch 背后的公司，我们将我们的功能和支持带到你在云中的 Elastic 集群。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Elastic Blog

原创地址：https://www.elastic.co/blog/detections-as-code-elastic-security