工程

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 规则创建指南或贡献指南中的规则元数据总结

detection-rules-repo-blog-msbuild.png

“MsBuild Making Network Connections”规则支持文件预览

如何将这些规则导入检测引擎?

如果您使用的是 Elastic Cloud 管理服务或是支持全套免费功能的 Elastic Stack 软件默认分发包,当您首次导航进入检测引擎时,便会看到最新规则。需要升级时,检测引擎会识别规则的增加或变更并发出提示,让您决定是否升级这些规则。升级后依照步骤操作即可获取最新规则。

detection-rules-repo-blog-msbuild-network-connections.png

“MsBuild Making Network Connection”相同规则已载入检测引擎

谁可以使用该存储库?

在该存储库中,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 支持多种语言,我们的规则自然也要体现出这一点。查询语言的开发通常是为了解决不同类型的问题,如果存在另外一种效果更好的语言,我们就不应限制规则开发人员只使用某一种语言。目前我们的存储库中已有 KQLLucene 规则,以及使用 机器学习异常检测作业的规则。我们正在努力实现将 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 频道联系我们。