利用 Elastic 和 Tines 的自动化 SIEM 调查减少误报
内容提要
Elastic信息安全团队利用Tines自动化SIEM告警初步调查，通过Elasticsearch查询源IP是否来自受信设备、授权应用或防钓鱼MFA，自动关闭误报，否则升级给分析师。该工作流每天自动分流关闭超3000条告警，30天处理超5万条，减少分析师疲劳，提升真实威胁可见性。
延伸解读
自动化分诊的运作机制
Elastic 团队利用 Tines 构建自动化工作流，对 SIEM 告警进行初步调查。核心逻辑是：提取告警中的 source.ip 等字段，在 Elasticsearch 中查询多个索引，判断该 IP 是否来自受管设备、授权应用或防钓鱼 MFA 认证。若任一查询返回结果，则自动关闭告警；否则升级给分析师。这种基于查询结果的分诊方式，将大量误报在几秒内处理完毕，显著减轻了分析师负担。
标签驱动的可扩展路由
为应对不同告警类型，团队采用自定义标签（如 Triage:Asset、Triage:PMFA）将告警路由到相应的自动化路径。每个标签对应一组检查，例如资产标签验证 IP 是否属于内部资产，PMFA 标签检查 Okta 日志中的防钓鱼 MFA 认证。这种设计避免了为每条规则单独编写自动化，使工作流易于扩展和维护，同时支持多标签组合，实现灵活的分诊策略。
成效与内部威胁局限
该自动化每天关闭超过 3000 条告警，30 天处理超 5 万条，若人工处理需额外 94 名全职员工。然而，文章也指出其局限：对于内部威胁，若攻击者通过受感染的工作站或 VPN 横向移动，使用合法 IP，告警可能被自动关闭。团队认为，即便如此，自动化仍提供了更好的可见性，并迫使攻击者改变策略，增加被其他检测规则发现的机会。
实施中的挑战与应对
构建自动化分诊时，团队遇到影子 IT 和第三方互连的挑战。一些 API 令牌被非公司 IP 授权使用，需追踪并添加例外。部分第三方提供商会公布公共 IP 空间，便于过滤。此外，工作流需处理告警去重和 API 限流，避免重复关闭或过载。这些实践表明，自动化分诊并非一劳永逸，需持续维护和调整，才能保持有效性。
Q&A
Elastic 信息安全团队如何利用 Tines 自动化 SIEM 告警的初步调查？
他们通过 Tines 自动化工作流，对 SIEM 告警执行一系列 Elasticsearch 查询，检查源 IP 是否来自受信设备、授权应用或防钓鱼 MFA。如果任何查询返回结果，则自动关闭告警为误报；否则升级给分析师进一步调查。
自动化分流工作流每天能处理多少告警？节省了多少人力？
该工作流每天自动分流并关闭超过 3,000 条告警，30 天内处理超过 5 万条。如果由分析师手动处理，每条告警需超过 15 分钟，相当于需要额外增加 94 名全职员工。
Tines 自动化分类中使用了哪些标签来路由告警？
使用的标签包括：Triage:All（所有告警都经过资产、PMFA 和工作站路径）、Triage:Asset（检查源 IP 是否属于受管资产）、Triage:PMFA（检查防钓鱼 MFA 认证）、Triage:Workstation（检查工作站代理连接）、Triage:NewHire（检查新员工）、Triage:1hour（暂停 1 小时）、Triage:24hour（暂停 24 小时）和 Triage:Custom（自定义路径）。
自动化分类工作流存在哪些主要挑战或局限性？
主要挑战包括：对内部威胁效果有限，因为威胁行为者可能通过受感染的工作站或 VPN 使用合法 IP 地址；影子 IT 问题，即未登记的第三方系统使用授权 IP 导致误判；以及需要持续跟踪和构建例外情况。
如何将 Elastic Security 的告警发送到 Tines 进行处理？
可以通过 Elastic Security 的 Alert Actions 功能，配置规则操作并使用内置的 Tines 连接器或 Webhook 连接器。Webhook 连接器支持以 ndjson 格式发送完整告警，需设置 POST 方法和内容类型为 application/x-ndjson; charset=utf-8。
自动化分类工作流中，如何判断一个告警是否应被关闭？
工作流会执行多个 Elasticsearch 查询，例如检查源 IP 是否来自受管工作站、授权第三方应用或成功防钓鱼 MFA。如果任何查询返回结果（命中数大于零），则使用 Signals API 关闭告警并标记为误报；如果所有查询均无结果，则升级给分析师。
