Reducing false positives with automated SIEM investigations from Elastic and Tines

通过 Elastic 和 Tines 的自动化 SIEM 调查减少误报 | Elastic 博客

通过 Elastic 和 Tines 的自动化 SIEM 调查减少误报

作者： Aaron Jewitt

2024年5月31日

• 在 Twitter 上分享
• 在 LinkedIn 上分享
• 在 Facebook 上分享
• 通过电子邮件分享
• 打印本页

安全运营中心（SOC）团队面临的最大 SIEM 管理问题之一是，他们经常被误报淹没，导致分析师疲劳和可见性空白。此外，安全领域最棘手的挑战之一是检测 SaaS 访问令牌是否被泄露，同时又不增加误报问题。

在 Elastic，我们的信息安全部门通过使用 Tines 等工具自动化 SIEM 警报调查，解决了这两个问题。本文将分享我们如何优化工作流程、减少误报，并让分析师能够专注于真正的威胁。

自动化 SIEM 警报初步调查

在之前的博客文章中，我们曾介绍过 Elastic 信息安全部门如何创建检测用户和实体行为分析（UEBA）的规则包。随着我们扩展这些警报包以包含更多数据源，我们发现 SOC 分析师被大量误报所淹没，这些误报源于异常但无害的活动——例如每月仅发生一次的 API 令牌活动，或来自已知扫描器的活动。这导致了一个问题：我们不得不在创建可能因误报而产生噪音的检测规则，或接受因缺乏该检测而产生的可见性空白之间做出抉择。大量误报的检测规则会因分析师疲劳而产生另一种类型的可见性空白。但这个问题激发了一个新思路：如果我们能够自动化警报的初步调查，关闭已知的误报，并将无法关闭的警报升级处理，会怎样？

我们发现，对于许多 SaaS 提供商和 UEBA 检测规则，如果活动来自受信任的设备（例如我们的托管工作站），我们就可以关闭该规则。在许多情况下，初步调查流程的第一步是使用原始警报中的信息（例如 source.ip），然后在 Elasticsearch 中查询其他索引模式以获取该 source.ip 的相关信息。如果查询结果有任何返回，就可以将警报标记为误报并关闭。例如，如果我们看到一个关于 AWS 密钥活动的 UEBA 警报，我们会运行以下查询组来判断活动是否来自受信任设备，从而进行警报分类：

• 是否有代理日志显示 Elastic Agent 成功从具有该 source.ip 的工作站或服务器连接到我们的舰队服务器？
• 该 source.ip 是否属于我们管理和控制的 AWS、GCP 或 Azure 网络区域的公共 IP 范围？
• 该 source.ip 是否属于 Okta、Terraform、Tines、Qualys 或 Snyk 等授权的第三方应用程序？
• 在过去的 2 小时内，该 source.ip 是否有成功的 FIDO2 SSO 登录记录？

如果这些后续的 Elasticsearch 查询中任意一个返回了结果，我们可以认为该 AWS API 密钥活动可能是经过授权的，从而关闭警报。如果所有查询均未返回结果，我们认为该活动存在可疑之处，需要将其升级给 SOC 团队成员进行进一步调查。上述所有 Elasticsearch 查询都可以通过 _search API 完成，我们可以使用 Signals API 来关闭和标记警报，从而实现整个流程的自动化。

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

这种自动化初步处理能力使我们能够创建大量检测规则，这些规则在没有大幅增加 SOC 人员数量的情况下，通常会因噪音过大而难以手动调查。目前我们的自动化工作流程每天可以处理超过 3000 个警报，且无需任何人工干预。如果由经验丰富的分析师手动处理这些警报，每个警报需要至少 15 分钟。若要实现相同检测效果但不使用自动化，我们需要额外增加 94 名全职员工。下图展示了我们 SIEM 系统过去 30 天的警报数据：

30 天的警报数据

虽然可以通过自定义脚本创建此自动化流程，但本文将展示如何使用 Tines 构建此自动化。我们选择这种方式是因为这是 Elastic 信息安全部团队使用的工具，而且简单来说，它比编写脚本更容易。我们发现 Tines 可以在没有专门开发团队的情况下轻松构建和修改自动化流程。

将警报发送到任意 SOAR 系统

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

在配置检测规则时，有一个选项可以添加规则操作（Rule Action）。从这里您可以选择所需的连接器类型。

规则操作连接器选择视图

将警报发送到 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 连接器，并在配置中使用以下 mustache 语法将完整警报以 ndjson 格式发送到 Webhook。

Alert Action to Webhook 配置

使用标签路由自动化流程

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

Triage 标签列表

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

• Triage: All 会通过资产、PMFA 和工作站的自动化分类路径处理警报，如果任何查询返回 true，警报将被关闭。如果所有查询均未返回 true，警报将被升级。

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

• Triage: PMFA 会检查 Okta 审计日志中使用防钓鱼多因素认证（如通过 Okta Verify 或 Windows Hello 的密钥）的成功认证。我们使用 Okta 集成来收集 Okta 审计日志。

• Triage: Workstation 会检查我们的 nginx 代理日志，查看 Elastic Defend 是否成功连接到我们的舰队服务器的 IP 地址。Elastic 是一家分布式公司，员工可在全球任何地方工作，但他们的 Elastic Defend 代理会定期连接，因此我们通常能发现 Elastic 员工的受管工作站是从生成警报的相同 IP 地址连接的。

• Triage: New Employee 会检查我们的资产数据库，该数据库包含从 HR 系统导出的所有员工每日报告，以确定用户是否为新员工。这对于某些检测规则类别（如通常在新员工配置账户时触发但很少对现有员工发出警报的 Slack UEBA）非常重要。

• Triage: 1h 会指示 Tines 暂停警报处理 1 小时，然后再执行其余分类操作。这对于用户配置全新工作站等场景可能很有用，如果工作站已正确注册到我们的终端管理系统（安装 Elastic Defend 的系统），警报可以关闭。

• Triage: 24h 会指示 Tines 暂停警报处理 24 小时后再进行处理。这可能需要某些分类路径，例如数据仅每日更新的部分（如收集所有计算机、用户和云账户每日清单的资产数据库部分）。

• Triage: Custom 用于任何可能需要的自定义分类路径。一个很好的例子是，当我们向第三方（如 Okta）提供高度特权的 API 密钥用于在 Azure 中创建或禁用账户时，如果该 API 令牌从未属于 Okta 的 IP 地址使用，我们希望收到警报。此警报和自动化分类使我们能够“信任但验证”，以防 Okta 存储的我们的 API 密钥被泄露并在 Okta IP 空间之外使用。

自动化构建模块

现在我们已经将完整的警报作为JSON发送到SOAR，可以将其通过我们的分诊流程，然后发送到Slack或Pagerduty等其他来源。在Tines中，有七种不同类型的行动可用于构建故事：

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

• 发送电子邮件行动会根据行动选项中指定的收件人发送电子邮件。

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

• 事件转换行动有多种模式，可以修改接收到的事件内容。这些行动非常灵活且功能强大。

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

• 触发行动会将传入事件中的字段内容与预定义的规则进行比较，当规则匹配时，会触发事件发出。这可以看作是一种“如果...那么...”的逻辑行动。

• 发送到故事行动会将事件发送到另一个Tines故事（子故事）。子故事完成其行动后，发送到故事行动将触发事件。发送到故事行动类似于代码中的函数或库，您可以在多个地方重复使用这些行动。

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

示例简化自动化分诊流程：

Tines分诊故事

在这个自动化故事中，我们处理通过Webhook传入的新警报，使用事件转换行动将ndjson解析为更易于引用的对象，然后使用触发行动确定警报应走哪条分诊路径。

大多数HTTP请求行动都是对Elasticsearch _search API的查询。在这些后续查询中，我们使用原始警报中的字段（如source.ip或user.email）对警报进行分诊。

Tines附带了数百个预构建的行动模板，包括多个与Elasticsearch交互的模板。您可以使用“查询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 地址每天可能会多次变化。我们通过在 InfoSec 基础设施前面的 nginx 代理上部署 Elastic Agent，来可靠地识别这些工作站在全球范围内移动时的公网 IP 地址。

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

以下是我们在 Tines 故事中用于从源 IP 检查受管理工作站或服务器的路径。触发操作的虚线表示当触发操作未返回 true 时故事的流程路径。

工作站故事分支

关闭告警发送到故事

您可能已经注意到，每次我们想要关闭告警时，都会在 Tines 中使用“发送到故事”操作。此操作会通过 Webhook 将我们选择的字段发送到 Tines 中的新故事，然后我们在那里关闭并标记告警。通过使用“发送到故事”操作，我们可以使主故事更易于维护，并且可以添加其他功能，例如根据信号 ID 去重，以避免从两个不同的初步处理分支尝试关闭同一告警，以及使用节流操作以防止大量告警同时到达时压垮 API。

我们还使用 Signals API 更新规则标签，这对指标和跟踪告警状态非常有用。我们通过自动化初步处理工作流程关闭的所有告警都会标记为“自动化初步处理”，这样我们可以跟踪每月处理的告警数量，并在 SIEM 界面中轻松查看告警是被自动化关闭还是被分析师关闭。

关闭告警发送到故事

将未处理告警升级到 Slack

随着我们通过各种自动化分诊路径并行发送警报，我们还会将故事发送到另一条路径，该路径会在处理过程中暂停5分钟。这5分钟的暂停时间可以让其他分支完成处理，并关闭来自可信源IP地址的警报。5分钟暂停结束后，我们会向信号搜索API发送请求，检查警报是否仍然处于开启状态。如果警报仍然开启，我们会向警报Slack频道发送消息，通知SOC分析师有警报未被自动分诊。

将未处理的警报升级到Slack

如果你想为这个故事添加更多功能，Tines可以轻松地为故事创建另一个分支以添加额外功能。例如，如果你有SLA要求必须在特定时间内确认关键或高严重性警报，你可以添加逻辑等待一小时，然后检查Elastic SIEM中警报是否已被确认。如果警报仍然开启且未分配给任何人，你可以通过向PagerDuty发送警报或向另一个团队发送第二条Slack消息来升级处理。

升级到PagerDuty

Tines还包含与Elastic Security中的案件协作的模板——通过这个分支添加几个额外操作，你可以创建新案件、分配给值班分析师，并将警报详细信息添加到案件中。

我们遇到的挑战

安全领域没有完美无缺的方案，对于每一个安全控制措施，威胁行为者都有绕过它们的方法。但正因为如此，这并不意味着这些措施不值得投入。一个显而易见的弱点是这些警报对内部威胁的检测效果有限，如果威胁行为者通过被入侵的工作站、服务器或企业VPN连接进行横向移动，他们可以使用已知的可信IP地址，对于具有自动化分诊工作流程的规则，警报将被自动关闭。

我对此有两个论点：第一，如果没有这种自动化，大多数这些检测几乎不可能部署，除非增加数百名员工。即使存在这些弱点，这些自动化检测仍能提供比没有时更好的可见性。分诊后的警报可用于威胁狩猎，并包含针对主机或用户多个不同检测规则的检测，它们仍然可以提供价值。

第二，如果我们能迫使威胁行为者改变战术——例如迫使他们通过我们的工作站或服务器进行入侵和横向移动——这将大大增加被检测到的可能性。我们的工作站和服务器高度部署了Elastic Defend，并已配置了超过一千条检测规则。我们观察到，大多数情况下，当威胁行为者入侵SaaS凭证或API密钥令牌时，他们通常会直接从自己的基础设施连接到服务，而不是通过被入侵的主机。

在构建这些检测时，另一个重大挑战是影子IT以及现代IT系统中所有与第三方的互连和信任关系。影子IT是指公司内部团队在未经过所有适当流程将系统添加到资产清单并安装Elastic Agent或auditbeat的情况下自行搭建IT系统。

当您构建这些分诊工作流程并定义“已知良好IP”时，不可避免会发现一些API令牌正以授权方式从不属于您公司的IP地址使用。这些令牌通常用于各种第三方自动化工具（如GitHub Actions）或扫描应用（如Qualys或Snyk）。追踪这些令牌并建立例外规则可能需要时间，但一旦识别并移除Shadow IT，其价值将非常显著。

在某些情况下，第三方供应商（如Okta、GitHub或Elastic Cloud）会公开其IP地址段，您可以基于此构建额外检查规则以过滤这些IP的活动。如果您使用的是Tines云租户，可通过https://<tenant-domain>/info获取当前租户的公网IP。

示例检测

这些自动化方案最初是为单一检测规则设计，但我们在实践中发现它们在多种场景下都极具价值。对于许多检测规则，您可以自问：“如果该警报是由我们确认属于自身的IP地址触发，我们的SOC团队会关闭该警报吗？”我们发现这一情况对大多数基于行为的第三方服务检测规则都成立，因此它们是自动化分诊的理想候选对象。

以下是我们为这些检测规则实施初始分诊自动化的部分示例，供您参考该工作流程可构建的检测方向。其中一些检测是专为配合此自动化分诊流程而设计的自定义规则，而许多则是我们通过添加Triage标签到现有检测规则中以消除部分误报的规则。

• Okta 高风险认证
• 非Okta IP发起的Okta支持活动
• 新IP发起的Okta API活动
• Okta UEBA：同一邮箱和IP触发多个不同警报
• Okta：单个dt哈希关联多个邮箱地址
• 未使用防钓鱼MFA的成功用户登录（Okta）
• 新IP发起的MFA豁免账户认证（Okta）
• Okta用户密码重置或解锁尝试次数异常高
• 代理后同一设备令牌哈希关联多个Okta用户认证事件
• Okta用户会话伪装
• Okta用户会话从不同地理位置发起
• 尝试暴力破解Okta用户账户
• Slack UEBA：同一Slack用户触发多个不同警报
• 新IP发起的GCP门户登录
• 新IP发起的GCP IAM活动
• 新IP发起的Buildkite网页活动
• 新IP发起的Buildkite API活动
• GitHub：同一GitHub PAT触发多个UEBA警报
• GitHub UEBA：同一GitHub账户触发多个警报
• GitHub：私有仓库克隆用户激增
• Hashicorp Vault：同一Vault用户触发多个UEBA警报
• Azure Active Directory高风险认证
• 新IP发起的Azure门户登录
• 新IP发起的Azure Active Directory PowerShell登录
• Azure Active Directory设备代码认证
• Azure Active Directory未使用MFA的成功登录
• 新IP发起的AWS IAM活动
• AWS Key UEBA：同一AWS密钥触发多个不同警报
• AWS User UEBA：同一AWS账户触发多个不同警报
• 新IP发起的AWS控制台认证
• AWS S3存储桶枚举或暴力破解尝试
• 尝试暴力破解Microsoft 365用户账户
• O365单点登录错误激增
• 潜在成功的SSH暴力破解攻击
• 源IP触发的成功登录事件激增

• 从互联网访问 VNC（虚拟网络计算）

• 从 VNC（虚拟网络计算）连接到互联网

实现更高层次的保护

在这篇博客文章中，我向您展示了 Elastic 信息安全团队如何使用 Tines 来自动化我们许多警报的初步分类工作。这种自动化使我们能够获得更好的可见性并提高效率，让我们能够将时间投入到调查真正的威胁中。通过使用 Tines，我们在过去 30 天内成功调查并关闭了超过 5 万个警报。每个警报在触发后几秒钟内都得到了彻底的调查和关闭。如果没有这种自动化，我们网络中的保护水平将无法达到如此高度。

如果您想亲自尝试，可以使用 Elastic Cloud 的 14 天免费试用和始终免费的 Tines 社区版，亲身体验这些工作流程对您的强大之处。

本文中描述的任何功能或功能的发布时间和时机均由 Elastic 完全自主决定。任何当前不可用的功能可能无法按时或根本不会交付。

分享