8 月 3 日，我们发布了 Protections-artifacts，作为我们开放性计划的一部分 🎉。生成开放且透明的安全内容的好处之一是有机会与伟大的安全专家社区合作。在 2020 年，我们讨论了开放我们的检测规则 - 为了继续秉承这种精神，这里深入了解我们在 Elastic 的威胁研究和检测工程 (TRaDE) 团队中使用的三个可用资源，以帮助我们的检测工程研究和开发工作流程。

TRaDE 负责为 Elastic 的 XDR 功能提供支持的检测和端点行为安全规则。虽然我们的检测规则提供对攻击者行为的可见性，但端点行为规则具有阻止攻击的能力。这些规则提供 Elastic Endpoint Security 使用的保护逻辑，以阻止 Windows、Linux 和 MacOS 端点上的威胁。总的来说，Elastic Security 支持各种平台和数据源（例如，核心云服务提供商、K8s、核心操作系统等）。

这两个规则集：a) 检测规则和 b) 端点行为规则，考虑不同的用例并相互补充，以提供强大的覆盖范围。比较表突出显示了两者在保护设计目标、数据处理方式以及处理哪些数据方面的独特差异。

检测规则- 设计目标：利用所有可用的数据源，为所有威胁提供最强大的检测覆盖范围。预计会根据特定于组织的特定环境对规则进行一些调整。- 数据流：将搜索堆栈中每个规则的所有指定索引。- 引擎处理：批量处理。

端点行为- 设计目标：在每个规则的基础上，以误报为代价，提供非常高的置信度、以预防为重点的最小调整。我们希望每个组织都能够启用行为保护，并开箱即用地获得出色的体验，而无需进行少量调整。- 数据流：代理搜索端点上的数据。- 引擎处理：实时数据流。

在 TRaDE 幕后，我们利用公开可用的工具来开发和测试我们的规则集。如果您想要了解有关编写事件查询语言 (EQL) 规则的入门知识，想要生成可疑活动以确定您的 Elastic 驱动的检测的基线，或从 Elasticsearch 中快速导出这些可疑事件，您可能会受益于我们使用的一些工具。第 1 节通过 EQLPlayground 介绍我们的安全 SIEM 功能，第 2 节讨论我们的规则测试功能 RTA，第 3 节重点介绍我们的 detection-rules CLI 和我们使用的一些有价值的命令。

EQLPlayground

开发 EQL 的目的是表达事件之间的关系，并且与 ECS 结合使用时，有能力快速关联不同数据源的事件。无论您是想使用 EQL 执行简单的搜索、利用高级数据堆叠和筛选来发现异常，还是定义复杂的基于假设的搜索查询，EQL 作为一种语言的灵活性都可以在许多方面帮助提高您团队的效率。除了其他几种语言选项（使用户能够利用最相关和适用的功能）之外，该语言在我们的 detection-rules 存储库和 端点行为工件中被广泛使用，以检测攻击者行为并表达事件之间的关系。

虽然我们努力在端点和 elasticsearch EQL 实现之间尽可能实现功能对等，但由于架构实现，存在细微的功能差异。

虽然阅读有关 EQL 的信息很有帮助，但使用查询语言是一种更有趣和互动的学习体验！感谢 Elastic 的 James Spiteri，您可以立即进入 Elastic Cloud Stack 并使用 EQLPlaygound 进行学习。Playground 利用了原生 Security Timeline 的相关功能，并提供了说明以启用 EQL 学习。Playground 是一个公开可用的 Elastic Security 实例，预先填充了来自 Sofacy 组 有效负载生成的异常事件。访问该站点您只需要一个浏览器！

基本上，您会看到一个代表威胁活动的数据集，类似于我们用来构建检测规则和端点工件的数据集。然后，可以利用此事件数据来生成您自己的检测逻辑。它还简要介绍了 Elastic Security Stack，并让您有机会使用一些可用的炫酷功能（例如，分析器）。视觉事件分析器显示进程树的图形表示，其中包含我们 Elastic Security Endpoint 检测到的警报和可疑事件，并说明了可在查询中使用的进程沿袭。

我们可以使用此信息来了解攻击者的行为方式，并开发能够识别未来恶意活动的查询。例如，Outlook 是否应该生成 explorer.exe 子进程？探索 EQLPlayground、EQL 语法和 API。在 Elastic Security 7.12 中引入的相关视图中，您将有机会插入 EQL 并开发具有您特殊技巧的查询，以检测我们已执行的恶意行为。您还可以查看每个可用的字段，以及在您的 Stack 中捕获这些事件所需的数据流。

如您所见，此处有一个示例占位符查询，但是您可以完全访问根据捕获的完整事件修改查询，并提出最佳检测方法。进程树有什么可疑之处吗？事件序列呢？rundll32.exe（一种常用的 执行代理）进行外部网络调用有什么可疑之处吗？

sequence by process.entity_id with maxspan=10s
[process where process.name : "rundll32.exe" and event.type == "start"]
[network where process.name : "rundll32.exe" and not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8")]

我们很乐意看到您提出的酷炫且巧妙的查询，如果您有关于新规则的想法，请查看我们的 CONTRIBUTING.md 指南并提交新规则。现在，我们将在使用 detection-rule CLI 创建规则时使用此查询。

红队自动化 (RTA)

我们自动化测试 Elastic 规则集的方法之一是启动模拟威胁行为的 RTA 脚本。如果您不熟悉 RTA，它是一个开源工具，TRaDE 使用它来生成可疑活动并在多个 Stack 版本中进行单元测试规则。我们建议您查看 Devon Kerr 在 2018 年发布的文章，其中介绍了此功能。

有时候，人们会向我们的团队请求示例数据、生成可疑事件以建立基准配置的方法，或者一个在 Elastic Stack 中已经生成大量警报的测试环境。我们还会对规则进行回归测试，以验证添加到 SIEM 或 Endpoint Agent 的新功能、基于规则调整的任何修改或进行维护。这个过程可能非常耗时，因为需要跨多个 Stack 版本测试数百条规则。

在最新的 8.4 开发周期中，我们花了一些时间生成新的 macOS、Linux 和 Windows RTA（运行时活动）。秉持开放的主题，我们将端点行为测试迁移到 Detection Rules repo，供社区使用！当前的 RTA 开发主要集中在端点行为上，我们将继续使用新的 RTA 来扩展我们的规则集覆盖范围，所以请期待在不久的将来看到更多 RTA。

克隆 detection-rules repo 后，您将能够列出所有可用的测试。每个 RTA 都包含有用的元数据，例如 RTA 支持的平台、将触发警报的规则以及在目标系统上生成可疑活动的 Python 代码。common 导入包含许多有用的函数，可以简化新 RTA 的创建。例如，它提供了辅助功能，可以临时编辑 Windows 注册表、检查所需的操作系统是否正在运行 RTA，甚至可以执行终端命令。本质上，它抽象了 RTA 集中所需的许多常见活动，从而简化了新 RTA 的开发，特别是对于那些不太熟悉 Python 的人。RTA 库的设计仅使用 stdlib Python 包，因此不需要外部依赖项。仅使用核心库在分段环境中进行测试时非常有利。

在上面的示例中，RTA 生成活动以触发 Suspicious Emond Child Process SIEM 和 Potential Persistence via Emond 端点行为规则。RTA 创建一个由名为 emond 的父进程派生的 bash shell 进程。我们的目标是创建可重复且无损的测试用例，以便尽可能在单元测试之间重用测试基础设施。有很多方法可以生成触发这些规则的可疑事件，因此如果您想贡献您的创意，请随时提交拉取请求到 detection-rules！

Detection Rules CLI

detection-rules CLI 是一个开发工具瑞士军刀，我们用它来管理和测试我们的规则是否通过验证，但也有一些有用的命令，您可以使用它们来加快您自己环境中的规则测试。如果您熟悉 Python3，则只需几个步骤即可开始使用 Detection Rules CLI 命令。它有诸如 view-rule 之类的有用命令，该命令以 Kibana 期望的格式显示规则作为 JSON 对象。方便的是，该命令在加载时也会进行验证；如果您想快速测试您的 TOML 文件是否与我们的架构匹配，可以使用此命令。

在安装了软件包 依赖项 和您的凭据配置后，您就可以使用 CLI 了。使用 CLI 的一个很酷的地方是能够在测试 RTA 时使用 collect-events 命令下载数据。

一旦您开始收集事件，CLI 命令将保持空闲状态，直到您准备好保存事件为止。在您等待期间，您有机会跳到目标机器上、执行 RTA、引爆恶意软件样本或启动任何有效负载来触发警报。这些事件可以离线存储，并在以后的自动化测试过程中重复使用。使用 collect-events 命令，您可以应用多个选项来限定您的导出范围，例如指定索引和目标系统的特定 host.id。一旦命令启动，它将收集与主机相关的所有事件，直到您准备好停止收集为止。

如您所见，可以运行 collect-events 命令，在目标系统上生成恶意活动（例如，使用 RTA），并在本地下载事件以供审查。一些用户按原样导出和使用这些事件，但我们打算存储这些事件以帮助自动化和简化我们的端到端测试过程。

除了 es (Elasticsearch) 函数外，我们还经常使用其他几个选项，例如使用 toml-lint 对我们的规则集进行 lint，使用 validate-all 验证我们的规则，甚至使用我们开发 CLI 部分深处隐藏的开发中命令（如 rule-survey）对我们的规则集进行警报调查。如果您有兴趣阅读有关其他可用字段的更多信息，请参阅我们的 使用 CLI 创建规则 指南或 CLI.md。与往常一样，如果您有任何疑问或需要帮助，请随时提交问题。

诸如 EQLPlaygound、RTA 和 detection-rules CLI 之类的工具分别是开始使用 EQL、威胁搜寻和检测工程的绝佳资源。结合 detection-rules CLI 和 RTA，这些工具为安全研究工程师提供了即时反馈，以开始管理他们的自定义 Elastic 检测规则。无论您使用的是云 Elastic Stack、本地部署，还是使用我们新发布的 Elastic Container Project 设置实验室环境，我们都能满足您的需求。这些只是我们使用的一些工具，欢迎您尝试将它们用于内部工作流程，它们每天都帮助我们测试和创建规则。

在 TRaDE craft 的后续文章中，我们将介绍我们如何跨 EQL 或 KQL 等语言验证我们的规则，以及我们如何自动化我们的端到端流程。此外，如果您有兴趣了解我们在 Tines 的合作伙伴如何集成 Elastic 检测逻辑，请查看他们的博客 Automating Detection-as-Code，其中介绍了 Elastic SIEM、检测内容开发 CI/CD、警报管理和响应处理。

我们始终有兴趣听取这些用例和工作流程，因此，一如既往，请通过 GitHub 问题 与我们联系，在我们的 社区 Slack 中与我们聊天，并在我们的 讨论论坛 中提问！