Elastic 安全开放公共检测规则存储库
Elastic 相信开源的力量，重视社区的价值。我们以社区为先，确保为用户提供最优质的产品。Elastic 安全的两大核心目标分别是阻止大规模威胁，和赋能每一位分析师。今天，我们又开放了一个全新的 GitHub 存储库 elastic/detection-rules，致力于与安全社区一道，阻止更大规模的安全威胁。
Elastic 安全检测引擎的发布将在 Elastic Stack 中实现自动威胁检测。自检测引擎首次发布起，Elastic 安全情报和分析团队已增加了 50 多条规则，提高了在 Linux、macOS 和 Windows 操作系统中对攻击者技术的可视性。我们将继续拓宽检测覆盖范围，未来将涉足云服务、用户行为等诸多新兴领域。
在过去的版本中，我们采用内部存储库来管理检测引擎规则。针对 Kibana 查询语言 (KQL) 句法、模式用法和其他元数据的最新贡献规则，我们已添加自动测试予以验证，借此迭代完善测试流程。受益于现有的成熟规则开发体系，我们 无需 另起炉灶就能一往无前。
通过开放 elastic/detection-rules GitHub 存储库，Elastic 安全将与社区共同开发开放规则，并欢迎您晒出自己的社区驱动型检测。这为我们所有人创造了相互分享知识、彼此交流学习，以及协作实现变革的宝贵机会。
新存储库中有哪些内容？
elastic/detection-rules GitHub 存储库提供 Elastic 安全规则，覆盖多项 MITRE ATT&CK® 技术。当前规则逻辑主要使用 KQL 编写，而利用 Elastic Common Schema (ECS)，我们只需创建一次规则即可。通过使用 ECS 中定义的字段和分类，规则将自动适用于正确映射到 ECS 的 Beats 日志和其他数据源。
在 rules/ 文件夹下，规则会以 TOML 文件格式存储，并按照平台分组。我们尽量使用精简的扁平化层次结构，以便查找和添加新规则。如果您正在查找仅 Windows 环境下的规则，请导航进入 rules/windows。如果在查找某个规则时遇到困难或者想要跨规则检索，不妨借助我们的 CLI 运行 python -m detection_rules rule-search 指令，包含符合要求的元数据的文件将立即呈现。
除了查询外，每条规则还有多个元数据字段。其中采集了诸如题目、描述、噪音级别、ATT&CK 映射、标签以及调度间隔等信息。我们还有其他字段帮助分析师分拣信息、描述已知误报或调查的有用步骤。更多规则适用元数据信息，请查看 Kibana 规则创建指南或贡献指南中的规则元数据总结。
如何将这些规则导入检测引擎？
如果您使用的是 Elastic Cloud 管理服务或是支持全套免费功能的 Elastic Stack 软件默认分发包，当您首次导航进入检测引擎时，便会看到最新规则。需要升级时，检测引擎会识别规则的增加或变更并发出提示，让您决定是否升级这些规则。升级后依照步骤操作即可获取最新规则。
谁可以使用该存储库？
在该存储库中，Elastic 安全情报和分析团队会开发规则、创建问题、管理 Pull Request 和目标版本。开放存储库后，我们就可以邀请所有外部贡献者加入此工作流。如此一来，贡献者将有机会了解我们的开发过程，掌握通过检测引擎发布规则的清晰路径。
如果您准备好加入贡献者团队，请签署 Elastic 贡献者许可协议 (CLA)。作为所有 Elastic GitHub 存储库的使用准则，签署该协议即意味着我们可以将您贡献的代码自由分发给 Elastic 用户。
如何执行威胁检测？
一般来说，我们更倾向于围绕敌对行为执行检测。换言之，我们专注于 ATT&CK 技术。这意味着我们需要在创建规则之前，投入更多的精力调查、研究某项技术是如何运作的。正是基于这种方式，我们才能够更好地检测、阻止当前和未来威胁，而非止步于应对已有威胁。
从行为着手也意味着我们需要多种类型的规则。一些会用于检测原子事件，另一些则可以请求聚合多个事件或查找超过某一阈值的异常值。借助事件查询语言 (EQL)，我们可以创建用于查找涉及多个事件行为序列的规则。
当然，我们理解有时某一项技术可能对于所有用户来说，都很难从行为角度予以检测。因此您可以随时添加针对某种特定行为或工具的规则，其本质上可能更近似于一种签名。
如果想要更深入探讨如何创建成熟检测，请阅读检测规则存储库理论。
为什么需要新存储库？
如果您曾分享过公共规则，可能会对其他知名 GitHub 存储库有所了解，例如 MITRE 网络分析存储库 (CAR)、Sigma 或是基于 Elastic EQL 的EQL 分析库。您可能在想：我们为什么需要新存储库？为什么不使用现有存储库呢？
会有这种想法很正常，但在回答这一问题前首先要解决另外一个问题：为什么会存在其他存储库？CAR 和 Sigma 都是刻意不区分语言或平台的，而且有时也不分数据来源。相反，EQL 分析库则是以某种特定语言创建的。
立足于全新检测规则存储库，我们正在尝试实现一个不太一样的目标。我们希望为 Elastic 安全用户提供适用于不同数据源的最佳检测。依托出色的 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。我们准备了详细的操作说明，指导您导航进入存储库，分叉、克隆以及创建规则。其中批量编辑文件的命令行工具可以让新规则创建更加便捷。当您准备好向存储库内添加新规则时，运行 python -m detection_rules create-rule，然后您将收到所需元数据的提示。我们建议您尽可能使用 CLI，从而减少在重复使用其他规则或模板中的 TOML 文件内容时出现复制粘贴错误。
规则准备就绪后，您可以运行 python -m detection_rules test 命令，从而执行本地单元测试，以验证句法、模式用法等。接下来，创建 Pull Request，随后情报和分析团队成员会审核您贡献的规则。如我方需要改动，会和您一起协作，完成推荐的改动。
如果您对某一规则有不错的思路，但想与我们就此进行合作或获得反馈，您可以创建一个新规则问题。我们期待能为您提供帮助，一起集思广益！
更多信息，请查阅贡献指南。
未来发展？
欢迎加入我们的新规则存储库和工作流！我们欢迎您贡献规则，期待在 rule.author 字段中看到您的姓名。检测规则存储库将继续与 Elastic 安全功能一起优化更新，对于未来我们充满期待。
如果您想要追踪堆栈中 EQL 开发情况，欢迎订阅 GitHub 问题。或者您也可以查看进度记录，了解 Elasticsearch 团队动向。
如果您在规则创建或全新检测规则 GitHub 存储库导航方面有任何反馈或问题，请在 GitHub 中创建问题并添加 detection-rules 标签，以访问讨论论坛寻求帮助，或者在 Elastic Slack 社区 #detection-rules 频道联系我们。