Eric Forte•Kseniia Ignatovych

作为代码的弹性检测工程师指南

时间轴和新功能

阅读时间：11 分钟产品更新
作为代码的弹性检测工程师指南

在不断变化的威胁环境中，安全运营正达到一个临界点。随着威胁的速度和复杂性的增加，团队不断扩大，管理的环境也成倍增加。通常，规则管理的人工方法会成为瓶颈。这就是 "代码检测"（DaC）的作用所在，它不仅是一种工具，也是一种方法。

DaC 作为一种方法，将软件开发实践应用于安全检测规则的创建、管理和部署。通过将检测规则视为代码，它可以实现版本控制、自动测试和部署流程，从而加强协作、一致性和应对威胁的灵活性。DaC 简化了检测规则的生命周期，通过同行评审和自动测试确保高质量的检测。这种方法还有助于遵守变更管理要求，并促进成熟的安全态势。

因此，我们非常高兴地与大家分享 Elastic检测规则的最新更新，这是我们用于编写、测试和管理 Elastic 安全检测规则的开放存储库，您还可以通过它创建自己的 "检测即代码"（DaC）框架。继续阅读，了解使用扩展功能的重点实施示例，以及 Elastic 免费 "检测即代码研讨会 "的公告。

弹性安全 DaC：从阿尔法到全面可用的历程

有了检测规则库现在提供的功能，用户可以将所有检测规则作为代码进行管理，审查规则调整，自动测试和验证规则，并在环境中自动部署规则。

2024 年前：Elastic 内部使用 DaC

Elastic 威胁研究和检测工程团队创建并使用检测规则库来开发、测试、管理和发布预建规则，并遵循 DaC 原则--以团队形式审查规则、自动测试和发布规则。该资源库还有一个用于创建规则的交互式 CLI，因此工程师可以在那里开始制定规则。

随着安全社区对 "作为代码 "原则的兴趣与日俱增，而且可用的 Elastic Security API 已允许用户实施其自定义的 "检测作为代码 "解决方案，Elastic 决定扩展检测规则库功能，使我们的用户能够从我们的工具中受益，并帮助他们创建 DaC 流程。

以下是 Elastic 以用户为中心的 DaC 开发从阿尔法到全面可用的关键里程碑。

2024 年 5 月"自定义 "新功能的阿尔法版本

我们的检测规则库可根据客户使用情况进行调整，允许管理自定义规则，根据用户需求调整测试套件，并允许在管理规则的同时管理操作和异常情况。

主要新增人员

  • 支持自定义规则目录
  • 根据要求选择要运行的测试
  • 例外情况和行动支持

我们还发布了一份内容广泛的 "检测即代码 "指南，其中包括使用检测规则库与 Elastic Security 一起实施的示例。

2024 年 8 月："自己动手 "功能测试版现已发布

该功能已扩展到允许在 Elastic Security 和存储库之间导入和导出自定义规则、更多配置选项以及扩展到自定义规则的版本功能。

新增功能

  • 批量导入/导出自定义规则（基于弹性安全 API）
  • 完全可配置的单元测试、验证和模式
  • 自定义规则的版本锁定

2025 年 3 月至 8 月：普遍可用并得到支持

将 DaC 与 Elastic Security 8.18 及更高版本一起使用：

  • 支持预制规则管理。您可以从 Elastic Security 导出所有预建规则，并将它们与自定义规则一起存储。
  • 增加了对导出规则过滤的支持。

在 DaC 工作的同时，我们还于 2025 年 10 月至 12 月发布了新的 Terraform 资源（V0.12.0和V0.13.0），允许 Terraform 用户管理检测规则和例外情况。

有了这个基础，让我们来探索一下可用于简化检测工程流程的强大功能。

检测规则 DaC 功能亮点

自我们上次出版 DaC 以来，又增加了一些有价值的内容，我们将在下文中详细介绍。

附加过滤器

从 Kibana 导出规则时可用的过滤器功能已得到扩展，使您可以精确定义要在 DaC 中同步的规则。下面是新的旗帜：

旗帜描述
-cro过滤导出，只包含用户创建的规则（不包括 Elastic 预建规则）。
-eq对导出的规则应用查询过滤器。

让我们举个例子，当你希望按数据源组织规则，并希望将 AWS 规则导出到特定文件夹时。在这种情况下，让我们使用标签过滤数据源，并导出带有Data Source AWS 标签的所有规则：

python -m detection_rules kibana export-rules -d dac_test/rules #add rules to the dac_test/rules folder
-sv #strip the version fields from all rules
-cro #export only custom rules
-eq "alert.attributes.tags: "Data Source: AWS"" # export only rules with "Data Source: AWS" tag

有关此处使用的底层 API 调用的查询字符串过滤，请参阅 Kibana 文档；有关构建查询过滤器的可用字段示例，请参阅列出所有检测规则 API 调用。

自定义文件夹结构

在检测规则软件仓库中，我们使用基于平台、集成和 MITRE ATT&CK 信息的文件夹结构。这有助于我们的组织和规则制定。这绝不是唯一的组织方法。例如，您可以按客户、日期或来源来组织规则。这将根据您的使用情况而有很大不同。

无论是使用导出程序还是手动组织，一旦将规则保存在自己喜欢的位置或文件夹结构中，即使在重新导出规则时，也能保持这种本地结构。需要注意的是，新规则需要手动放置到所需位置。本地规则加载机制会检测规则放置的位置，以便知道应将它们放在哪里。如果该规则不存在，它将使用指定的输出目录来放置新规则。要使用本地规则加载更新现有规则，请在kibana export-rules 和import-rules-to-repo 命令中使用--load-rule-loading / -lr 标志。通过这些标记，您可以使用config.yaml 中指定的本地文件夹。

让我们以文件夹中的规则为例，看看它们是如何组织的：

rule_dirs:
- rules
my_test_rule.toml
- another_rules_dir
high_number_of_process_and_or_service_terminations.toml

我们将在config.yaml 文件中指定以下内容：

rule_dirs:
- rules
- another_rules_dir

有了新的-lr 选项，Kibana 的规则更新现在将使用这些附加路径，而不是直接导出到指定目录。

运行python -m detection_rules kibana --space test_local export-rules -d dac_test/rules/ -sv -ac -e -lr,将从test_local 空间导出规则，my_test_rule.toml 将被写入 dac_test/rules/，因为它已经在那里的磁盘上，high_number_of_process_and_or_service_terminations.toml 将被写入dac_test/another_rules_dir/.

如果不同的客户在不同的子文件夹配置中使用相同的规则，这将特别有用。例如，假设您的规则按平台和集成进行了细分，类似于 Elastic 的预建规则文件夹结构。对于客户、SOC 或威胁猎杀团队来说，在这些平台/集成文件夹下组织规则可能是他们管理规则的最有用机制。不过，您的信息安全团队或主要检测工程团队可能希望按倡议或规则作者管理规则，以便将特定个人或团队负责的所有规则集中在一处。现在有了本地规则加载标志，你只需在每个结构中拥有两个配置文件和重复的规则。在导出规则更新时，可以使用环境变量选择相应的配置文件并导出规则更新。然后，这些更新将应用于现有的规则，保持目录结构不变。

杂项本地加载更新

除上述功能外，我们还增加了两个较小的新功能，旨在帮助用户在检测规则 TOML 文件和模式中添加本地信息。具体如下

  1. 支持本地文件中的本地日期，本地日期将从原始文件中保留下来
  2. 升级自动生成功能，从现有模式中继承已知类型。

当需要对文件中的日期字段进行更多手动控制时，本地日期组件会非常有用。如果不使用覆盖，日期将基于导出 Kibana 规则内容的时间。使用--local-creation-date 标志，重新导出文件内容时将不会更新日期。

更新了自动模式生成功能，以便在存在其他索引/集成的情况下继承它们的类型。这可能会提供更准确的模式，并减少事后手动更新的需要。例如，您有一条使用索引 "new-integration*"的规则，其中包含以下字段：

  • host.os.type.new_field
  • dll.Ext.relative_file_creation_time
  • process.name.okta.thread

这些字段不是以默认类型添加到模式中，而是从现有模式中继承其类型。在这种情况下，dll.Ext.relative_file_creation_time 和process.name.okta.thread 的类型是继承的。

{
  "new-integration*": {
    "dll.Ext.relative_file_creation_time": "double",
    "host.os.type.new_field": "keyword",
    "process.name.okta.thread": "keyword"
  }
}

要了解如何在自定义数据类型中使用此功能，请参阅本博客 "实施示例 "部分中的 "自定义模式用法"章节。

扩展使用示例

以下是更多 DaC 实施实例，这些实例并不侧重于新功能的添加，而是深入探讨我们在社区中讨论的主题。

值得注意的是，"检测即代码 "功能是作为组件提供的，可用于为您选择的流程和架构构建自定义实施。在生产环境中实施 DaC 时，应将其视为工程流程并遵循最佳实践。

用 Gitlab 实现 DaC

我们在研究 DaC 的实施时，通常会围绕使用某种形式的 CI/CD 产品来自动执行基于给定触发器的规则管理。根据所需的设置，特别是规则的权威来源和版本控制系统 (VCS) 的所需状态，这些触发器会有很大不同。有关其中一些考虑因素的更深入探讨，请参阅我们的DaC 参考资料。下面是一个使用 Gitlab 作为 VCS 提供商并通过 Gitlab Actions 使用其内置 CI/CD 的简单示例。

stages:                # Define the pipeline stages
  - sync               # Add a 'sync' stage

sync-to-production:    # Define a job named 'sync-to-production'
  stage: sync          # Assign this job to the 'sync' stage
  image: python:3.12   # Use the Python 3.12 Docker image
  variables:
    CUSTOM_RULES_DIR: $CUSTOM_RULES_DIR    # Set custom rules env var
  script:                                  # List of commands to run 
    - python -m pip install --upgrade pip  # Upgrade pip
    - pip cache purge                      # Clear pip cache
    - pip install .[dev]                   # Install package w/ dev deps
    - |  # Multi-line command to import rules                                        
      FLAGS="-d ${CUSTOM_RULES_DIR}/rules/ --overwrite -e -ac"
      python -m detection_rules kibana --space production import-rules $FLAGS
  environment:
    name: production   # Specify deployment environment as 'production'
  only:
    refs:
      - main           # Run this job only on the 'main' branch
    changes:
      - '**/*.toml'    # Run this job only if .toml files have changed

这与其他基于 Git 的 VCS（如 Gitlab 和 Gitea）内置的 CI/CD 非常相似。主要区别在于确定触发事件的语法。无论使用哪种 VCS，DaC 命令（如kibana import-rules ）都是一样的。在本示例中，我们将把检测规则仓库中的规则同步到 Kibana 生产空间。这是基于之前做出的一些决定，例如要求在合并规则更新前通过单元测试，以及主程序已准备就绪可用于 prod 的规则。如需在 Github 上了解这种特殊方法的注意事项，请观看我们的演示视频。

自定义单元测试技巧和示例

在考虑将 DaC 作为一种功能添加到您的检测工具包时，应将建立 CI/CD 和基础架构视为提高规则质量和实用性的持续过程的第一步。拥有 "代码 "工具的关键目的之一，是增加根据需求和环境进一步定制工具的能力。

其中一个例子就是规则的单元测试。除基本功能测试外，现有的其他一些关键单元测试还围绕规则性能和优化以及元数据和标记的组织实施特定于 Elastic 的考虑因素。这有助于检测工程师和威胁研究人员在制定规则时保持一致。在此示例的基础上，我们可以考虑根据具体需求添加自定义单元测试。

为了说明这一点，以安全运营中心（SOC）的环境为例，该环境中有许多负责不同领域和任务的分析师。当 SIEM 中发出警报时，可能无法立即确定由谁来处理补救措施，或需要将事件通知哪个团队。用团队标签标记规则：例如Team: Windows Servers 与 Elastic 为数据源使用标签的方式类似，它可以在警报中直接为 SOC 提供一个联络点，以帮助其进行修复。

在我们的 DaC 环境中，我们可以快速创建一个新的测试模块，在所有自定义规则（或预置规则）上强制执行这一点。在本次测试中，我们将对所有非 Elastic 编写的生产规则强制执行Team: <some name> 标签。在检测规则软件仓库中，我们的测试是通过名为pytest 的 Python 测试套件进行的，因此单元测试被组织到tests/ 文件夹下的 Python 模块（文件）和这些文件中的后续类和函数中。要添加测试，只需在现有文件中添加类或函数，或者创建一个新文件。一般来说，我们建议创建新的测试文件，这样就能从 Elastic 收到对现有测试的更新，而不必合并差异。

首先，我们将在tests/ 目录下新建一个名为test_custom_rules.py 的 python 文件，内容如下：

# test_custom_rules.py

"""Unit Tests for Custom Rules."""

from .base import BaseRuleTest


class TestCustomRules(BaseRuleTest):
    """Test custom rules for given criteria."""

    def test_custom_rule_team_tag(self):
        """Unit test that all custom rules have a Team: <team_name> tag."""
        tag_format = "Team: <team_name>"
        for rule in self.all_rules:
            if "Elastic" not in rule.contents.data.author:
                tags = rule.contents.data.tags
                if tags:
                    self.assertTrue(
                        any(tag.startswith("Team: ") for tag in tags),
                        f"Custom rule {rule.contents.data.rule_id} does not have a {tag_format} tag",
                    )
                else:
                    raise AssertionError(
                        f"Custom rule {rule.contents.data.rule_id} does not have any tags, include a {tag_format} tag"
                    )

现在，每条非弹性规则都必须在指定模式中为负责补救的团队设置一个标签。例如 Team: Team A.

自定义模式的使用

Elastic 自带数据类型的能力也扩展到了我们的 DaC 功能。例如，让我们来看看一些网络协议的自定义模式。当然，规则可以查询堆栈中的各种数据，我们还希望利用适用的验证和测试功能，对这些数据类型的任何自定义规则进行验证和测试。这就是自定义模式的用武之地。

在验证查询时，我们会将查询解析为相应的字段，并将这些字段的类型与给定模式中提供的类型进行比较（例如："......"）。ECS 模式、AWS 数据的 AWS 集成等）。对于自定义数据类型，则遵循相同的验证路径，并能从本地定义的自定义模式中提取数据。这些模式文件可以手工构建为一个或多个 json 文件；不过，如果你的堆栈中已经有一些样本数据，你可以利用这些数据作为验证，并自动生成模式。

假定您已经配置了自定义规则文件夹（如果没有，请参阅说明），您可以通过在配置文件中添加auto_gen_schema_file: <path_to_your_json_file> 来开启自动模式生成功能。这将在指定位置生成一个模式文件，用于为每个字段和索引组合添加条目。该文件将在根据模式验证规则内容的任何命令中更新，包括 import-rules-to-repo、kibana export-rules、view-rule 等。当使用自定义规则目录和配置时，这也会自动将其添加到堆栈模式图文件中。

有了这种能力，规则审核人员的责任也随之增加，因为查询中使用的任何字段都会被立即假定为有效并添加到模式中。降低风险的方法之一是利用可访问数据的开发空间。在 PR 中，我们可以通过对数据类型的堆栈级验证，将成功执行的查询连接起来。一旦获得批准，就可以将auto_gen_schema_file 添加到配置中，现在您就拥有了基于自定义数据的已知有效模式。这就为其他规则制定者提供了一个基线，使他们可以根据需要在此基础上进行改进，并保持类型检查验证。

了解 DaC 的更多信息并亲自试用

您可以通过我们的交互式Instruqt 培训亲身体验 Elastic Security 的 "代码即检测"（DaC）功能。该培训提供了一种在预先配置的测试环境中探索 DaC 核心功能的直接方法，无需手动设置。试试吧

如果您正在实施 DaC，请在社区松弛DaC 频道上分享您的经验、提出您的问题并帮助他人。

试用弹性安全

要体验 Elastic 为检测工程师提供的全部优势，请开始免费试用 Elastic Security。请访问elastic.co/security了解更多信息。

本博文所描述的任何特性或功能的发布及上市时间均由 Elastic 自行决定。当前尚未发布的任何特性或功能可能无法按时提供或根本无法提供。

分享这篇文章

XFacebookLinkedInReddit