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 节重点介绍了我们的检测规则 CLI 和我们使用的一些有价值的命令。

EQLPlayground

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

尽管我们努力在端点和 Elasticsearch EQL 实现之间实现功能上的同等性，但在架构实现方面仍然存在细微的功能差异。

阅读有关 EQL 的信息可能非常有益，但使用这种查询语言进行操作是一种更有趣、更具互动性的学习体验！感谢 Elastic 自己的 James Spiteri，您可以立即深入到 Elastic Cloud Stack 中，并使用 EQLPlaygound 进行学习。该游乐场利用了原生 Security 时间线 关联功能，并提供了注释以帮助学习 EQL。该游乐场是一个公开可用的 Elastic Security 实例，预先填充了从 Sofacy 小组 有效载荷 生成的可疑事件。访问该网站只需要一个浏览器！

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

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

如您所见，这里有一个示例占位符查询，但您可以完全访问基于捕获的完整事件修改查询并提出最佳检测方案。进程树中是否有可疑之处？事件序列呢？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 指南并提交 新规则。现在，我们将使用此查询使用检测规则 CLI 创建规则。

红队自动化 (RTA)

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

有时，人们会向我们的团队索取示例数据、生成可疑事件以建立配置基线的方法，或一个已在 Elastic Stack 中生成许多警报的测试环境。我们还会对规则进行回归测试，以验证添加到 SIEM 或端点代理的新功能、基于规则调整的任何修改或维护。对于数百条规则在多个堆栈版本中进行测试，此过程可能会变得非常耗时。

在最新的 8.4 开发周期中，我们花了一些时间生成了新的 macOS、Linux 和 Windows RTA。与开放主题保持一致，我们将端点行为测试迁移到 Detection Rules 存储库 供社区使用！当前的 RTA 开发重点是端点行为，我们将继续使用新的 RTA 扩展规则集的覆盖范围，因此请期待在不久的将来出现更多 RTA。

克隆 detection-rules 代码库后，您就可以列出所有可用的测试。每个 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 的一些很酷的功能之一是能够使用 collect-events 命令在测试 RTA 时下载数据。

开始收集事件后，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 中与我们聊天，并在我们的 Discuss 论坛 中提问！