开放式的 Elastic 安全：利用预构建的保护措施让安全团队如虎添翼

面向检测工程师提供的检测内容

现在，Elastic 安全为 Elastic 安全用户提供了 1,100 多条预构建的检测规则，以便于他们尽快完成设置并启动检测和安全监测。在这 1,100 多条规则中，有 760 多条规则是考虑到多个日志源的 SIEM 检测规则，其余规则在利用适用于终端的 Elastic 安全的终端上运行。

Elastic 致力于保持安全社区的透明度和开放性，这也是我们与所有感兴趣的人员开展协作来公开构建和维护检测逻辑的主要原因。我们认为，将我们的研究、规则和其他调查结果分享给安全社区是非常重要的，这样便于大家从中学习并有助于进一步的改善。

所有这些内容除了内置在 Elastic 安全中并立即可用外，还会通过公共 GitHub 存储库（SIEM 检测规则、终端规则）提供。

我们并不回避与其他专注于检测的产品进行比较，所以您也可以在 Tidal Cyber 平台上找到 Elastic 安全。

我们为什么要提供安全内容？

我们非常清楚，并不是每家公司都有资源来研究新威胁以及利用最新技术和可用功能来进行检测。这正是 Elastic 安全可以发挥所长并为您的安全团队提供额外资源的地方。

Elastic TRADE（威胁研究和检测工程）团队负责对新出现的威胁和商品威胁进行研究，从而为我们的用户开发和维护检测规则及预防规则。此外，这个团队还会提供反馈，以改进用于支持安全用例的各种查询语言。TRADE 团队与我们的内部 InfoSec 团队以及其他各种工程团队密切合作，确保整合所有反馈以实现持续改进。

这篇博文的其余部分将重点介绍如何利用 SIEM 检测规则和附带的安全内容，以及如何创建这些规则。下面就让我们一探究竟！

Elastic 规则创建过程

1. 确定主题

规则开发过程首先是根据研究计划、当前威胁形势、情报分析和覆盖面分析来确定我们想要关注的主题。此外，我们还需要考虑可用和常用的集成、用户需求和趋势。

2. 研究主题

一旦确定了我们想要关注的技术、威胁或策略，我们就会着手进行研究。请查看针对 Google Workplace 进行这类分析的示例。我们对架构和所提供的服务都有深入的了解，并可确定潜在敌手使用的技术 — 通常可对应到 MITRE ATT&CK 框架®。

3. 创建实验室

为了开发规则，我们可能需要一个实验室环境来模拟威胁，从而生成创建和测试检测逻辑所需的数据。在上面的示例中，您可以看到为 Google Workplace 创建这类实验室的幕后情况。对于我们创建的规则所覆盖的所有数据源，也适合采用同样的方法来创建和维护实验室环境。

4. 规则制定方面的工作

一般来说，规则制定者会确定要使用的规则类型；遵循最佳实践来创建高性能、低误报率的检测逻辑；对规则进行测试；创建具有所有必要元数据字段的规则文件。TRADE 的理念是成为正确开发和测试规则的核心。

5. 进行同行评审

接下来，规则将接受同行评审。当然，评审人员也需要了解新检测所涉及的技术和威胁。对于同事来说，评估现有的检测逻辑以找出逻辑可能存在缺陷的边缘用例是至关重要的。规则过松，会被威胁绕过，规则过严，会让客户环境变得误报频频。因此，找到一个平衡点也十分重要。

6. 覆盖范围注意事项

当寻求改进检测覆盖范围时，我们还会检查是否可以调整任何现有规则来适应新的检测，以及在安全分析师调查生成的告警时，从他们的角度来判断这是否合理。这可让规则制定者更加专注于定性与定量的规则制定。

有时候，在这个过程中，我们查明规则会产生太多误报的情况下，最终会将它搁置，以作为构建块规则进行发布。还有时候，我们在发现数据覆盖范围中存在差距并有碍我们创建有效检测逻辑的情况下，就会与 Elastic 中的其他团队合作，推迟创建规则，消除这些差距。

我们理解并预见到，开箱即用型检测规则覆盖范围或许并不能完美适合所有人的环境，所以在 Kibana 中对规则采用了分叉设计，以防您需要对规则进行修改。一种更简单的方法是通过添加异常来微调规则，以根据您的威胁模型和环境的具体情况来更新规则。请阅读更多关于我们开发规则的方法，以便进一步了解这些规则会给您带来什么效果。

您可以在检测规则存储库中关注我们的规则开发情况。如果您有想与其他 Elastic 用户共享的规则，也可以像其他人那样，通过我们的存储库将规则开放给社区。

等一下！整个过程还不只是创建新规则！

除了创建规则的工作之外，团队还需要花费大量时间来监测和微调现有规则。我们有时也会废弃那些不再符合相关标准的规则。

我们喜欢用数据说话，所以查看了过去 600 个对检测规则存储库的拉取请求，以便看一看我们在检测规则方面都做了哪些类型的工作。正如您在下面图表中所看到的，调整和维护的数量超过了新规则的创建，因为我们希望提供高质量的检测和最新信息。

Elastic Security Labs 研究人员会定期审查遥测数据，以根据告警的普遍性和特定规则的参数，查看哪些规则需要进行微调。

Elastic 安全的遥测数据由我们用户自愿共享，并用于提高产品性能和功能效能。顺便说一句，最近的 Elastic 全球威胁报告就是基于我们用户共享的数据作出的。在这份威胁报告中，我们分享了对威胁形势的全球观测和背景信息，可在您创建定制规则时作为指导。

在审查遥测数据来查看规则有效性的同时，威胁识别也是优先考虑的事项，工程师会从研究者的角度去审查真正的 (TP) 告警。TP 遥测需要自己单独的分流工作流，但可能需要开发新规则或进行更深入的调查。此外，TRADE 团队还会为 Elastic Security Labs 提供研究和高级分析，尤其是技术性较强的分析，如恶意软件反向工程、敌手特征分析、基础架构发现和原子指标收集。我们经常会与其他内部研究团队协作开展这项研究。

面向安全分析师的检测内容

检测规则不仅可供检测工程师使用，而且也可供从事告警分流和调查的安全分析师使用。

对于安全分析师来说，我们会通过使用调查指南等附加信息来扩充规则，从而提供具有操作性的威胁背景信息。规则制定者会添加有关攻击/行为、调查要点、误报、分析和补救步骤的信息。这些信息对于分析师来说非常有用，便于他们查看告警并快速了解触发告警的原因和确定后续步骤。调查指南也可以在 Elastic 安全解决方案的告警界面中进行查看。

我们同时也建议为您的定制规则创建调查指南，这些指南对安全团队来说是一种宝贵的资源。

我们正在努力实现威胁检测规则与调查指南的全覆盖。在这篇博文发布时，所有预构建规则中大约有 30% 带有调查指南。您可以使用“Investigation Guide”（调查指南）标签轻松筛选带有指南的预构建规则。

产品遥测数据也会被用来确定开发指南的优先级。我们会找出用户最常用的规则，在对客户最有用的地方提供信息。

我们的路线图包括对分流和补救建议方面调查指南的持续改进，以及功能改进。例如，在 Elastic Stack 8.5+ 版本中，调查指南可能会包含定制可用的 Osquery 搜索，以用于查询终端来获取额外的遥测数据，这些遥测数据在分析或分流过程中可能会有所帮助。

如果您对调查指南有反馈或建议，请开立 GitHub 问题来告知我们。我们非常重视社区贡献！

虽然高质量的检测逻辑是帮助识别潜在威胁的核心，但我们也理解与特定威胁相关的额外背景信息的重要性，这些背景信息可能对分析师很有用。通过预构建的检测规则，Elastic 努力提供尽可能多的关于规则本身的背景信息。

除了调查指南外，我们还会将所有规则映射到其特定的 MITRE ATT&CK 矩阵，并为您确定告警的严重程度和风险。此外，虽然在选择适用的规则时，采集各种数据源可能会令人困惑，但我们可帮助确定哪些集成对特定规则是必需的。您可以使用“Related Integrations”（相关集成）字段来导航到相关集成，对其进行设置，并根据需要启用相关规则，以确保采集正确的数据集。

包括附加背景信息的规则更新会定期进行带外发布，并将在 Elastic 安全解决方案中直接提供给用户。我们建议将您的 Stack 升级到最新版本，以便充分利用依赖于新安全功能的规则。

其他内容？

TRADE 团队还致力于开发检测规则的功能，并发布了一项名为红队自动化 (RTA) 的功能。这项用 Python 编写的功能有助于进行规则测试。RTA 脚本可用于生成良性 TP，并帮助团队针对多个版本的 Elastic 安全解决方案自动进行检测规则的回归测试。您还可以将已发布的 RTA 脚本用于测试之用，或者也可以为定制规则创建新脚本。

如需更深入了解 RTA 和 TRADE 团队提供的其他工具，请阅读这篇博文。

未来会推出更多的功能，敬请期待

正如您所看到的，我们的目标是在整个检测工作流和规则生命周期（从规则的创建到使用，再到维护和测试）中提供预构建的内容。而且，所有这些内容均在产品内提供，并通过 GitHub 与社区公开共享。

我们一直致力于让客户的系统更安全，让他们团队的工作更轻松。请随时联系我们，分享您的想法和痛苦。您可以通过我们的 Slack 社区或在我们的讨论论坛上发帖来联系我们。