Skip to main content

2026 年第 2 季度 The Forrester Wave™ XDR 平台

访问报告
关于我们合作伙伴支持|登录
Elastic logo
开始免费试用联系销售人员

利用 Elastic 和 Tines 的自动化 SIEM 调查减少误报

By
Aaron Jewitt

SOC 团队面临的最大 SIEM 管理问题之一是，他们经常被误报淹没，导致分析师疲劳和可见性差距。除此之外，安全领域最严峻的挑战之一是在不增加误报问题的情况下，检测 SaaS 访问令牌何时遭到入侵。

在 Elastic，信息安全 (InfoSec) 团队通过使用 Tines 等工具自动处理 SIEM 告警调查，从而解决了这两个问题。本篇博客文章分享了我们如何简化工作流、减少误报，并赋能分析师专注于应对真正的威胁。

自动化 SIEM 告警的初步调查

在之前的一篇博客文章中，我们介绍了 Elastic 信息安全团队如何创建用于检测用户和实体行为分析 (UEBA)的规则包。随着我们将这些告警包扩展到包含更多数据源，我们发现由异常但良性的活动（例如，每月仅发生一次的 API 令牌活动或来自已知扫描器的活动）所导致的大量误报，使 SOC 分析师不堪重负。这导致了一个问题：我们必须决定是创建一个可能会因误报而产生大量噪音的检测规则，还是接受因缺乏该检测而导致的可见性缺口。由于分析师疲劳，产生大量误报的嘈杂检测本身也会造成一种可见性缺口。但这个问题引发了一个新思路：如果我们能自动化处理告警的初步调查，关闭已知的误报，并升级那些我们无法关闭的告警，会怎样？

我们发现，对于许多 SaaS 提供商和 UEBA 检测规则，如果活动来自受信任的设备（例如我们管理的某个工作站），我们就可以关闭该规则。在许多情况下，初步调查剧本的操作是使用原始告警中的一条信息（例如 source.ip），然后在 Elasticsearch 中针对该 source.ip 查询其他索引模式。如果查询有任何结果，则可以将该告警作为误报关闭。例如，如果您看到针对 AWS Secret Key 活动的 UEBA 告警，我们将运行以下一组查询来对告警进行分流，以查看该活动是否来自受信任的设备：

  • 是否有代理日志显示 Elastic Agent 已从具有该 source.ip 的工作站或服务器成功连接到我们的 Fleet Server？ 

  • 该 source.ip 是否属于我们管理和控制的 AWS、GCP 或 Azure 网络区域的公共 IP 范围？

  • 该 source.ip 是否属于 Okta、Terraform、Tines、Qualys 或 Snyk 等授权的第三方应用程序？

  • 在过去 2 小时内，是否有来自该 source.ip 的成功 FIDO2 单点登录身份验证？

如果后续的 Elasticsearch 查询返回任何结果，则我们可以认为此 AWS API 密钥活动可能已获得授权，并可以关闭警报。如果所有查询均未返回任何结果，则我们认为该活动可疑，因此将其上报给安全运营中心 (SOC) 团队成员进行进一步调查。以上所有 Elasticsearch 查询均可使用 ` _search` API 完成，我们可以使用Signals API关闭警报并添加标签，从而实现整个流程的自动化。

通过使用 告警操作 (Alert Actions) 功能，将我们的 SIEM 检测结果从 Elastic 发送到 安全编排、自动化和响应 (SOAR) 系统，我们可以利用 SOAR 针对每个适用的告警自动运行这些调查查询。根据查询结果，我们可以自动关闭告警或将其升级给分析师处理。

这种自动化分流能力使我们能够创建各类检测，如果要在没有大幅增加 SOC 人员的情况下调查这些检测，通常会产生过多的噪音。我们的自动化工作流目前每天在无需人工干预的情况下分流并关闭超过 3,000 条警报。经验丰富的分析师以同样方式分流每条警报需要超过 15 分钟（每条警报）。如果我们希望在没有这种自动化的情况下实现相同的检测，则需要额外增加 94 名全职员工。此图表显示了我们 SIEM 中过去 30 天的警报数据：

30 天的警报
30 天的警报

此自动化分类工作流可以使用自定义脚本创建，但本篇博文将向您展示如何使用 Tines 构建此自动化。我们决定以这种方式进行探索，因为这是 Elastic InfoSec 团队所使用的方法，简而言之，它比编写脚本更简单。我们发现，Tines 使得在没有专门开发团队的情况下也能轻松构建和修改自动化流程。

将告警发送至任何 SOAR

如上所述，第一步是将告警内容从 Elastic Security 导出并传输到您选择的 SOAR 解决方案中。为此，我们使用 Elastic Security 中的 Alert Actions 功能，它会在每次触发告警时执行自定义操作。

配置检测规则时，可以选择添加规则操作。在此处，您可以选择所需的 连接器类型。

规则操作连接器选择视图
规则操作连接器选择视图

将告警发送至 Tines 的最简单方法是配置并使用 Elastic 中内置的 Tines 连接器，它会将您的告警发送至 Tines 故事进行处理。   

另一种选择是使用 Webhook 连接器，它非常灵活，因为允许您以 ndjson 格式将部分警报或警报的全部内容发送到监听的 Webhook。在 Tines 连接器出现之前，我们就在 Elastic 内部使用 Tines，因此我们的大多数自动化流程仍在使用 Webhook 连接器。您可以将警报逐个发送到 Webhook，也可以将它们全部合并在一个 ndjson 中发送。如果您使用的是自定义脚本，则可以使用此连接器来接收和处理警报，它也适用于 Tines Webhook 操作。要将警报的全部内容发送到 Webhook，您需要配置 Webhook 连接器以使用 POST 操作，并将内容类型设置为 application/x-ndjson; charset=utf-8。

Webhook 连接器配置设置
Webhook 连接器配置设置

在向规则添加操作时，请选择已配置的 Webhook 连接器，并在配置中使用以下 mustache 语法，以将完整告警作为 ndjson 发送至 Webhook。

告警操作至 Webhook 配置
告警操作至 Webhook 配置

使用标签来路由自动化

在构建这些自动化流程时，我们最初是为每个告警单独构建自定义自动化路径，但很快发现这种方法无法扩展。我们的解决方案是改用检测规则中的自定义标签，将规则路由到适当的分类路径。我们将完整的告警发送给 Tines，其中包含 signal.rule.tags 字段中的数组形式的标签。我们决定使用 Triage:{option} 的命名约定来描述将对规则执行哪些自动化检查。检测规则可以拥有多个不同的标签。

分类标记列表
分类标记列表

以下是我们正在使用的自动化分类标签说明：

  • 分类：所有 告警都将通过资产、PMFA 和工作站自动化分类路径进行路由；如果任何查询返回 true，则告警关闭。如果没有任何查询返回 true，则告警升级。

  • 分类：资产 将检查各种索引模式，以确定源 IP 是否来自 Elastic 以某种方式拥有或管理的资产。这包括我们存储在 Elastic 中的内部资产数据库、内部网络区域、我们的Elastic Cloud 公共 IP、CI/CD 系统以及 Okta 或 Tines 等授权第三方系统的公共 IP 空间。

  • 分类：PMFA 将查看我们的 Okta 审计日志，以确认是否使用防钓鱼 MFA（例如使用 Okta Verify 或 Windows Hello 的通行密钥）成功进行了身份验证。我们使用 Okta 集成来收集我们的 Okta 审计日志。

  • 分类：工作站 将检查我们的 Nginx 代理日志，以查看从该 IP 地址到我们 Fleet 服务器的成功连接。Elastic 是一家分布式公司，员工可以在世界任何地方工作，但他们的 Elastic Defend 代理会定期连接，因此我们通常可以看到 Elastic 员工受管理的工作站是从生成告警的同一个 IP 连接的。

  • 分类：新员工 将检查我们的 资产数据库，其中包含从我们人力资源系统导出的所有员工的每日报告，以查看该用户是否为新员工。这对于某些类别的检测规则（例如 Slack UEBA）非常重要，这些规则通常在新员工配置其帐户时触发，但很少针对现有员工发出告警。

  • 分类：1 小时 将指示 Tines 在执行其余分类操作之前，暂停告警分类 1 小时。这对于某些事件非常有用，例如用户正在配置一台全新的工作站，如果该工作站已正确加入并注册到我们安装了 Elastic Defend 的终端管理系统中，则可以关闭该告警。

  • 分类：24 小时 将指示 Tines 在处理前将警报分类暂停整整 24 小时。对于某些数据仅每日更新的分类路径，这可能是必需的，例如我们资产数据库中收集所有计算机、用户和云账户每日清单的部分。

  • 分类：自定义适用于告警可能需要的任何自定义分类路径。一个很好的例子是：我们向 Okta 等第三方提供了高权限 API 密钥，用于在 Azure 中创建或禁用账户，如果我们希望在任何时候该 API 令牌从不属于 Okta 的 IP 地址被使用时收到告警。这种告警和自动化分类让我们能够“信任但验证”，以防 Okta 对我们 API 密钥的存储遭到破坏并在 Okta IP 空间之外被使用。

自动化的构建基块

既然我们已经将完整告警作为 JSON 发送到我们的 SOAR，我们就可以通过分类路径将其发送到其他源，例如 Slack 或 PagerDuty。在 Tines 中，有七种不同类型的 操作 可用于构建您的故事：

  • Webhook 操作将发出它通过 Webhook（HTTP 回调）接收到的事件。这是将事件发送到 Tines 中的故事的主要方法。

  • 发送电子邮件 操作会将电子邮件发送给操作选项中指定的收件人。

  • 接收电子邮件操作（正式名称为 IMAP 操作）会在检测到 IMAP 服务器上有新邮件，或有邮件发送到唯一生成的电子邮件地址时发出事件。

  • 事件转换操作具有多种模式，可修改所接收事件的内容。这些操作极其灵活且功能强大。

  • HTTP 请求操作 使用各种方法向指定的 URL 发送 HTTP 请求。

  • 触发器 操作会将传入事件中某个字段的内容与预定义规则进行比较，当规则匹配时，就会触发事件发送。这可以被视为一种“如果……那么……”的逻辑操作。

  • “发送到故事”(Send to Story) 操作会将事件发送到另一个 Tines 故事（子故事）。在子故事完成其操作后，“发送到故事”操作将发出一个事件。“发送到故事”操作类似于代码中的函数或库，您可以在多个地方重复使用这些操作。

使用这些操作，我们可以构建自动化流程，每月为我们节省数千小时的工作时间。

自动化优先级分类工作流示例：

Tines 分类故事
Tines 分类故事

在这个自动化案例中，我们处理进入 Webhook 的新告警，使用事件转换操作将 ndjson 解析为我们可以更轻松引用的对象，然后使用触发操作来确定告警应遵循的分流路径。

大多数 HTTP 请求操作都是针对 Elasticsearch _search API 的查询。在这些后续查询中，我们使用原始告警中的字段（例如 source.ip 或 user.email）来对告警进行分类处理。

Tines 附带数百个预构建的操作模板，其中包括多个用于与 Elasticsearch 交互的模板。您可以使用 “Query an Elasticsearch index for all records”（查询 Elasticsearch 索引以获取所有记录） 模板，然后修改有效负载，使用来自警报的源 IP 添加您的查询。由于大多数查询都在查找来自特定 任何 事件 source.ip。我建议在您的查询中添加 ”size”: 1 选项，以提高速度和性能。如果 Elasticsearch 在过去 4 小时内找到与 source.ip 匹配的结果，此操作将返回该结果。

{
  "size": 1,
  "query": {
    "bool": {
      "must": [],
      "filter": [
        {
          "bool": {
            "should": [
              {
                "match_phrase": {
                  "source.ip": "<<extract_source_ip.source_ip>>"
                }
              }
            ]
          }
        },
        {
          "range": {
            "@timestamp": {
              "format": "strict_date_optional_time",
              "gte": "now-4h",
              "lte": "now"
            }
          }
        }
      ],
      "should": [],
      "must_not": []
    }
  }
}

在每个查询操作之后，我们都有一个触发操作来检查是否找到了任何结果。如果命中数大于零，我们使用 Signals API 来关闭告警。如果结果为零，我们继续处理并执行下一个操作。如果所有操作返回的结果均为零，我们随后会将告警发送至 Slack，以通知分析师进行调查。

这些是用于检查查询结果的触发器操作的示例设置：

触发操作设置
触发操作设置

通过运行 Elasticsearch 查询并在有结果时关闭告警的逻辑，我们可以将这些操作串联起来，构建出完整的场景，从而关闭来自已知安全 IP 地址的告警。

受管工作站分类示例

在下方的示例故事分支中，我们将关闭任何来自我们所管理的工作站或服务器的警报。Elastic 是一家全球分布式公司，我们的大多数员工都在家办公，因此我们无法预测他们会通过哪个 IP 地址连接到互联网，而且在许多情况下，他们的公共 IP 地址每天可能会更改多次。我们针对这些工作站随员工在全球各地移动时如何可靠地获取其公共 IP 的解决方案是：将 Elastic Agent 部署到位于我们信息安全基础架构前端的 Nginx 代理上。

利用这些数据，我们现在可以识别通过代理发送 Elastic Agent、Auditbeat 或 Endgame 流量到我们集群的成功连接。我们所有的云服务器系统都安装了 Auditbeat 或 Elastic Agent，因此这些查询也将检测到我们服务器系统的公网 IP 地址，这些系统会定期使用密钥来运行 CI/CD 和 DevOps 管道。

以下是我们在 Tines 故事中用于检查源 IP 是否来自受管工作站或服务器的路径。如果触发操作未返回 true，则来自触发操作的虚线即为故事流经的路径。

工作站案例分支
工作站案例分支

关闭告警并发送至 Story

您可能已经注意到，每次我们想要关闭告警时，都会在 Tines 中使用“发送到故事”操作。此操作将通过 Webhook 把我们选择的字段发送到 Tines 中的一个新故事，随后我们在该故事中关闭并标记该告警。通过使用“发送到故事”操作，我们使主故事更易于维护，并且可以添加额外功能，例如按信号 ID 进行去重，这样我们就不会尝试从两个不同的分类分支中两次关闭同一个告警；同时使用节流操作，这样如果大量告警同时涌入，我们也不会使 API 过载。

我们还使用 Signals API 来更新规则标签，这对于指标和跟踪告警状态非常有用。我们通过自动化分流工作流关闭的所有告警也会被标记为 Automated Triage，以便我们能够跟踪每月分流的告警数量，并能轻松地在 SIEM UI 中查看告警是由自动化流程还是分析师关闭的。

关闭告警 发送至 Story
关闭告警 发送至 Story

将未处理的告警升级至 Slack

当我们并行通过各种自动化分类路径发送警报时，我们还会将该事件发送到一条暂停处理 5 分钟的路径。这 5 分钟的暂停让其他分支有时间完成并关闭任何来自受信任源 IP 的警报。5 分钟暂停后，我们向 signals search API 发送请求，以检查警报是否仍处于打开状态。如果警报仍处于打开状态，我们会向我们的警报 Slack 通道发送消息，通知 SOC 分析师该警报未被自动分类。

将未处理的告警升级至 Slack
将未处理的告警升级至 Slack

如果您想为这个故事添加更多功能，Tines 可以让您轻松地为该故事创建另一个分支，以添加额外的功能。例如，如果您有 SLA 要求您在一定时间内确认严重或高危告警，您可以添加逻辑来等待一小时，然后检查该告警是否已在 Elastic SIEM 中得到确认。如果告警仍处于打开状态且未分配给任何人，您可以通过向 PagerDuty 发送告警或向其他团队发送第二条 Slack 消息来进行升级。

升级至 PagerDuty
升级至 PagerDuty

Tines 还包含用于处理 Elastic Security 中案例 (Cases) 的模板——通过此分支中的几个额外操作，您可以打开一个新案例，将其分配给值班分析师，并将告警详细信息添加到该案例中。

我们遇到的挑战

安全领域没有完美的事物，对于每一种安全控制措施，威胁行为者都有办法绕过它们。但仅仅因为某件事不完美，并不意味着它不值得付出努力。一个明显的弱点是，这些告警对于内部威胁的效果有限；如果威胁行为者通过受入侵的工作站、服务器或企业 VPN 连接进行横向移动，他们就可以使用已知的合法 IP 地址，而对于具有自动分类工作流的规则，告警会被自动关闭。

对此我有两个论点：首先，如果没有这种自动化，大多数检测在没有数百名额外员工的情况下是不可能部署的。即使存在缺陷，这些自动化检测也比没有检测时提供了更好的可见性。经过分类的告警可用于威胁狩猎，并包含在针对主机或用户的多个不同检测规则发出告警的检测中，从而确保持续提供价值。

其次，如果我们能迫使威胁行为者改变策略（例如迫使他们通过我们的工作站或服务器进行入侵和横向移动），这将大大增加被检测到的几率。我们的工作站和服务器都通过 Elastic Defend 进行了高度监测，并部署了超过一千条检测规则。我们发现，大多数情况下，当威胁行为者窃取 SaaS 凭据或 API 密钥令牌时，他们通常会直接从自己的基础架构连接到服务，而不是通过受感染的主机。

在构建这些检测功能时，另一个巨大的挑战是 影子 IT (Shadow IT)，以及现代 IT 系统中与第三方之间的所有互连和信任关系。影子 IT 是一个术语，用于描述公司内部团队在未通过所有正规渠道将系统添加到资产清单并安装 Elastic Agent 或 Auditbeat 的情况下，自行建立 IT 系统的行为。

当您构建这些分类工作流并定义什么是“已知良好 IP”时，您不可避免地会发现，有些 API 令牌正被不属于您公司的 IP 地址以授权方式使用。这些令牌通常用于各种第三方自动化（例如 GitHub Actions），或由 Qualys 或 Snyk 等扫描应用程序使用。追踪这些问题并构建例外情况可能需要时间，但当您识别并消除影子 IT 时，这也会非常有价值。

在某些情况下，诸如 Okta、GitHub 或 Elastic Cloud 等第三方提供商会发布其公共 IP 空间，以便您构建额外的检查来过滤来自这些 IP 的活动。如果您正在使用 Tines 云租户，则可以从 https://<tenant-domain>/info 获取您租户当前的公共 IP。

检测示例

这些自动化功能最初是作为单一检测规则的解决方案而开发的，但我们发现它们对于许多不同的场景都极具价值。对于您的许多检测规则，您可以问自己：“如果此告警是由我们确认属于我们的 IP 地址触发的，我们的 SOC 会关闭该告警吗？”我们发现，对于大多数针对第三方服务的基于行为的检测规则而言，情况确实如此，这使它们成为自动化分类的理想选择。    

 

以下是我们实现初始分流自动化的部分检测列表，希望能为您使用此工作流构建检测提供一些思路。其中一些检测是为配合此自动化分流工作流而构建的自定义检测，但许多检测是现有的检测，我们为其添加了“分流”(Triage) 标签，以消除部分误报。

 

实现更高水平的保护

在这篇博客文章中，我向您展示了 Elastic InfoSec 团队如何使用 Tines 来自动处理我们许多警报的初步分类。这种自动化使我们能够获得更好的可见性，同时提升效率，并让我们能够将时间花在调查真正的威胁上。通过使用 Tines，我们在过去 30 天内成功完成了超过 5 万条告警的调查和关闭工作。这些警报中的每一个都在触发后的几秒钟内得到了彻底调查并关闭。如果没有这个，我们的网络就不可能达到同等水平的保护。 

如果您想亲自尝试，可以免费进行 14 天的 Elastic Cloud 试用，并结合始终免费的 Tines 社区版，看看这些工作流能为您带来多大的助力。

本文中描述的任何功能或功能性的发布和时间均由 Elastic 自行决定。当前尚未发布的任何功能或功能性可能无法按时提供或根本无法提供。

注册 Elastic Cloud 免费试用版

在您所选的云服务提供商平台上迅速完成全套技术栈的部署。作为 Elasticsearch 的开发公司，我们为您在云端的 Elastic 集群提供多项功能和贴心支持。

开始免费试用