在 Elastic，我们相信开源的力量，并理解社区的重要性。通过将社区放在首位，我们确保为用户创造最佳产品。借助 Elastic Security，我们的两个核心目标是大规模阻止威胁和武装每一位分析师。今天，我们正在开放一个新的 GitHub 存储库 elastic/detection-rules，与安全社区一起工作，以更大的规模阻止威胁。
Elastic Security 中检测引擎的发布为 Elastic Stack 带来了自动化威胁检测。自检测引擎最初发布以来，Elastic Security 情报与分析团队已添加了 50 多条额外的规则，从而提高了 Linux、macOS 和 Windows 操作系统上的攻击者技术的可见性。随着我们不断扩大覆盖范围，您将看到检测范围的扩大，覆盖云服务和用户行为等新领域。
在过去的几个版本中，我们使用内部存储库来管理检测引擎的规则。我们通过为新贡献添加自动化测试来验证 Kibana 查询语言 (KQL) 语法、架构用法和其他元数据，从而迭代地改进了我们的测试程序。我们的规则开发已经成熟，因此我们可以快速行动，而不会破坏任何东西。
通过开放我们的 elastic/detection-rules GitHub 存储库，Elastic Security 将与社区一起公开开发规则，我们欢迎您提供社区驱动的检测。这是一个让我们所有人分享集体知识、互相学习并通过共同努力产生影响的机会。
这个新存储库中有哪些内容？
在 elastic/detection-rules GitHub 存储库中，您可以找到为 Elastic Security 编写的规则，其中涵盖了许多 MITRE ATT&CK® 技术。我们当前的规则逻辑主要用 KQL 编写，并且通过利用 Elastic Common Schema (ECS)，我们只需要编写一次规则。通过使用 ECS 中定义的字段和类别，规则会自动与 Beats 日志以及其他正确映射到 ECS 的数据源一起使用。
在 rules/ 文件夹中，规则存储在 TOML 文件中，并按平台分组。我们试图保持简单，使用扁平的层次结构，以便更容易查找和添加新规则。如果您正在查找仅限 Windows 的规则，请导航到 rules/windows。如果您仍然难以找到规则或想要搜索规则，可以使用我们的 CLI 运行命令 python -m detection_rules rule-search，这将显示具有匹配元数据的文件。
除了查询本身之外，每个规则还包含几个元数据字段。这捕获了诸如标题、描述、噪声级别、ATT&CK 映射、标签和调度间隔等信息。我们还有一些额外的字段来帮助分析师进行分类，描述已知的误报或调查的有用步骤。有关与规则相关的元数据的更多信息，请参阅Kibana 规则创建指南或我们贡献指南中规则元数据摘要。
“MsBuild 建立网络连接”规则背后的文件预览
这些规则如何进入我的检测引擎？
如果您正在使用我们的 Elastic Cloud 托管服务或包含完整免费功能集的 Elastic Stack 软件的默认发行版，您将在首次导航到检测引擎时获得最新规则。当您升级时，检测引擎会识别出已添加或更改了规则，并提示您决定是否要升级这些规则。升级后按照步骤操作，您将获得最新版本的规则。
加载到检测引擎中的相同规则 — “MsBuild 建立网络连接”
谁将使用此存储库？
此存储库是 Elastic Security 情报与分析团队将开发规则、创建问题、管理拉取请求和定位发布的地方。通过公开存储库，我们邀请所有外部贡献者加入此工作流程。这将使贡献者可以了解我们的开发过程，并为规则与检测引擎一起发布提供明确的途径。
当您准备好贡献时，请签署 Elastic 的贡献者许可协议 (CLA)。这是所有 Elastic GitHub 存储库的标准做法，这意味着我们可以自由地将您的代码分发给 Elastic 用户。
我们如何进行威胁检测？
一般来说，我们倾向于选择关注对手行为的检测。这通常意味着我们专注于 ATT&CK 技术。这可能意味着在创建规则之前需要进行更多的研究和努力来弄清楚技术是如何工作的。但是通过采用这种方法，我们可以更好地检测和阻止当今和未来的攻击，而不仅仅是昨天的攻击。
采用行为方法还意味着我们需要各种类型的规则。有些可能检测原子事件，另一些可能需要聚合多个事件或查找高于阈值的偏差。借助事件查询语言 (EQL)，我们将能够编写查找跨多个事件的行为序列的规则。
当然，我们知道有时对于所有用户来说，在行为上检测一种技术可能很困难。在那种情况下，请随时添加一个在本质上更像签名且针对特定行为或工具编写的规则。
有关构成成熟检测的更长讨论，请阅读检测规则存储库的理念。
为什么我们需要一个新的存储库？
如果您之前共享过公共规则，您可能知道其他著名的 GitHub 存储库，例如 MITRE 的 网络分析存储库 (CAR)、Sigma，甚至是基于 Elastic 的 EQL 的 EQL 分析库。您可能想知道：为什么我们需要另一个存储库？为什么不使用已经存在的存储库？
毫不奇怪，这个问题的最佳答案以另一个问题开始：为什么其他存储库存在？ CAR 和 Sigma 都特意不考虑语言或平台，有时也不考虑数据源。另一方面，EQL 分析库是针对特定语言编写的。
我们新的检测规则存储库旨在服务于略有不同的目的。我们的目标是为 Elastic Security 用户提供在各种数据源上都能工作的最佳检测。 我们使用 ECS 作为模式的伟大均衡器，从而可以编写一次规则，并将其应用于多个数据源。
由于 Elastic Stack 支持多种语言，我们的规则也应该反映这一点。查询语言通常是为了解决不同类型的问题而开发的，如果另一种语言能更好地完成工作，我们不应将规则开发者限制为单一语言。目前，我们的存储库中有 KQL 和 Lucene 规则，以及使用 机器学习异常检测 作业的规则。我们正在 努力 将 EQL 引入 Elastic Stack 和我们的存储库。
我们还可以确保遵循最佳实践，以获得最佳的 Elasticsearch 性能。例如，搜索 process.path:*\\cmd.exe 需要执行通配符检查，这比简单的关键字检查成本更高。我们可以建议使用 process.name:cmd.exe 来代替包含前导通配符的搜索，这将带来更好的性能和最准确的结果。与此类似，ECS 还包含 process.args 字段，它是 process.command_line 的解析版本。我们建议使用解析后的字段，因为它能带来更好的性能，并且意味着我们更不容易受到微不足道的空格或基于引号的规避的影响。双赢。
我可以从其他存储库添加规则吗？
在您自己的环境中，只要您的 Kibana 角色具有正确的权限，您就可以将规则添加到您自己的检测引擎中。如果您想将规则添加到 elastic/detection-rules 存储库中，答案并不令人意外：这要看情况...。 只要规则可以根据 Elastic 许可证进行再许可，就可以这样做。大多数情况下，要求都相当简单 — 在 rule.author 数组中保留原始作者，并相应地更新 NOTICE.txt 文件，以归功于原始作者。我们不想将别人的工作据为己有，因此请帮助我们做到彻底！
有关我们如何在存储库中处理许可的更多信息，请查看 README 的许可部分。
我如何贡献？
迫不及待地想分享您的规则逻辑？请访问 GitHub 上的 elastic/detection-rules。我们在那里提供了有关如何浏览存储库、fork 和克隆以及创建规则的详细说明。我们包含了一个命令行工具，用于批量编辑文件，并使创建新规则更加容易。当您准备好向存储库添加新规则时，运行 python -m detection_rules create-rule，系统会提示您输入所需的元数据。我们建议尽可能使用 CLI，因为它减少了从另一个规则或模板的 TOML 文件中重复使用内容时发生的复制粘贴错误。
当您的规则处于良好状态时，您可以运行命令 python -m detection_rules test 以在本地执行单元测试，这将验证语法、模式用法等。然后，创建拉取请求，情报和分析团队的某个人将审查贡献。如果我们要求进行任何更改，我们将与您合作进行建议的更改。
如果您对规则有很好的想法，但想就此想法与我们合作或获得反馈，请随时创建新规则问题。我们期待与您一起提供帮助和集思广益！
有关更多信息，请查看贡献指南。
接下来是什么？
欢迎来到我们新的规则存储库和工作流程！我们鼓励您做出贡献，并且期待在 rule.author 字段中看到您的名字。检测规则存储库将与 Elastic Security 的其他部分一起不断发展，我们对未来充满期待。
如果您想跟踪 EQL 在堆栈中的开发，请订阅此 GitHub 问题。或者，请查看正在进行的文档，以了解 Elasticsearch 团队正在做什么。
如果您在编写规则或浏览我们新的 检测规则 GitHub 存储库时有任何反馈或问题，请在 GitHub 中创建一个问题，在讨论论坛上使用 *detection-rules* 标签进行联系，或在Elastic Slack 社区的 *#detection-rules* 频道中找到我们。