终结告警洪流！Elastic推出AlertZero，AI原生重构安全运营中心

原创

玄月调查小组
玄月调查小组

玄月调查小组

2026年10月9日 01:09
上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

当 AI 把告警洪流冲向SOC，当零散的检测信号拼不出完整攻击链，当人手不足的团队只能任由告警堆积过期……

SOC 的普遍困局，终于迎来了 Agentic 范式的解法。

10 月 8 日，Elastic 介绍了即将发布的 Elastic Security 全新智能体层 AlertZero。包含四类各司其职的 Watch，目标是帮助 SOC 团队减少告警积压，让每一条告警都得到处理。

SOC 的至暗时刻：告警泛滥，攻击成链，人手不足

过去几年，安全团队面临的挑战正在指数级升级。

一方面，攻击者开始大规模使用 AI 工具，攻击的速度、规模、隐蔽性迈上新台阶，产生的告警数量和流速早已超出传统 SOC 的处理上限。

另一方面，正如 Hugging Face 事件所暴露的那样：如果不能将这些信号关联为同一次攻击，仍然不足以支撑有效调查

现实是，绝大多数团队只能靠人来覆盖安全范围，告警队列的内容决定了分析师的注意力优先级，大量告警无人处理就直接过期失效，更抽不出精力做主动防御。

AlertZero 登场：给 SOC 装上 Agentic 大脑

AlertZero 的定位很清晰：作为 Elastic Security 全新的Agentic层，它的目标就是带领 SOC 团队走向告警 “收件箱清零”—— 每一条告警都得到处理，每一处风险都得到响应。

它的核心逻辑是：通过大规模告警关联与上下文信息补充压缩现有队列、降低误报，自动给出处置建议，再进一步帮助团队创建和调优检测规则，形成从响应到防御的完整闭环。

四大 Watch，各司其职

即将推出的技术预览包含四类 Watch，分别对应 SOC 的不同核心职责。

每个 Watch 之下，还有更细粒度的Worker来执行具体任务。

比如 Triage Watch 下的 Attack Discovery Worker 负责把零散告警拼接成攻击叙事，Forensics Watch 下的 Endpoint Analysis Worker 负责端点行为深度分析。

所有 Watch 既可以由事件触发，也可以定时运行，互相之间没有强制的流水线依赖，可以根据团队的流程灵活组合。

AlertZero 是如何处理可疑登录会话的？

事件的开端是一条常见的 “不可能旅行” 告警：

在演示中，高管账户 cfo@corp 于 13:02 UTC 从美国波士顿登录。

39 分钟后，同一账户又从约 7000 公里外的托管／VPN 网络出现登录活动。

两次活动都显示满足 MFA 要求，但关键在于：第二次沿用了同一个会话 cookie，并未重新完成 MFA 验证。这使会话重放成为需要重点调查的方向。

放在传统 SOC 里，分析师可能先看到一条异地登录告警，然后自己去查登录日志、找会话信息、再跳去端点平台看进程，折腾半天才能判断是不是会话劫持。

但在 AlertZero 里，事情从一开始就不一样。

深度取证，补全端点证据

光有日志告警还不够，端点侧的证据是定性的关键。在分析师打开这项建议操作之前，Triage Watch 和 Forensics Watch 已经收集了支撑建议的调查发现。

终端侧也出现了值得关注的线索：一个未签名进程正在访问浏览器会话数据。结合异常登录和会话标识符复用的情况，这进一步支持了对会话重放的怀疑。但分析师仍需结合其他证据确认，并排查 VPN、代理使用及地理位置识别不准确等可能性。

• 可疑进程的启动链路
• 进程访问过的资源
• 事件覆盖的时间范围
• 受影响的资产清单

这些证据都被自动整理到调查报告里，和告警关联结果放在一起，不用分析师再去各个平台翻日志、拼信息。

人工审核模式下：处置建议经批准后执行

证据都齐了，处置建议也自动生成了：隔离受感染的端点。但这个动作不会直接执行，而是作为「建议动作（Proposed Action）」提交到待审核列表。

分析师点开就能看到：

• 处置的目标是什么
• 为什么要这么处置的完整理由
• 可能造成的业务影响
• 所有支撑的证据链

分析师可以直接批准，也可以驳回，还可以先问几个跟进问题，比如 “可疑登录后账号访问了什么？”“隔离主机会中断哪些业务？”，Agent会基于现有数据继续补充分析。

批准之后，系统才会通过 Elastic Defend 执行主机隔离，并且把决策过程、执行结果都单独记录下来，满足审计要求。

协同升级：多事件联动，一个窗口搞定

如果同一时间有多起相关事件需要协同处置，分析师不用分别处理，直接开一个「升级（Escalation）」，把相关的调查都链进来。

团队成员可以在同一个升级会话里讨论证据、向Agent提问、同步进度，特别敏感的场景还可以选择完全不调用Agent，全程人工处理。

Detection Watch：自动从误报里挖优化点

AlertZero 的 Detection Watch，就是专门干规则优化这个活的。

以误报为由关闭的告警数量较高，只是进一步调查的线索，并不直接证明规则有缺陷。Detection Watch 还需要核对具体样本和关闭理由，避免把错误的误报标记转化为错误的排除条件。在示例中，规则调优 Worker 采用手动模式，经分析师授权后开展分析，并生成包含诊断、现有逻辑、建议逻辑及回测结果的变更提案。

自动定位高误报规则

首先，它会用 ES|QL 统计最近 7 天内，被标记为 “误报” 而关闭的告警，按规则维度聚合计数，排出误报最多的规则 TOP20。

FROM .alerts-security.alerts-*
| WHERE @timestamp >= NOW() - 7 days
    AND kibana.alert.workflow_status == \"closed\"
    AND kibana.alert.workflow_reason == \"false_positive\"
| STATS false_positives = COUNT(*)
    BY kibana.alert.rule.uuid, kibana.alert.rule.name
| SORT false_positives DESC
| LIMIT 20

深度分析误报原因

定位到规则之后，它不会简单粗暴地 “直接放宽规则”，而是去抽样具体的误报告警，分析到底为什么误报： 是规则本身写得太宽泛？还是某个合法的运维工具 / 脚本刚好命中了规则特征？

比如有一条捕获进程事件的规则，因为写得太宽泛（只匹配event.category:\"process\"），导致合法的系统进程、管理工具都触发告警。 Detection Watch 会逐条分析样本：

• 涉及哪些主机、哪些用户、哪些进程
• 有没有集中在特定实体上
• 触发的具体特征是什么

然后判断最优的优化方式：是加白名单？还是收窄规则逻辑？

生成优化方案，自带回测

分析完原因，Detection Watch 会生成具体的规则修改建议，并且自带回测结果。 比如前面那条宽泛的进程规则，它会给出优化后的查询：在原有条件里，精确排除掉 5 个已经确认是误报的进程 + 命令行组合。

同时它会用历史数据做回测：在误报样本的时间范围内，优化后的规则是不是还会触发这些误报。 官方示例里的结果是：原来的 5 条误报，优化后全部消失。

Hunt Watch 则负责在没有告警触发时主动开展威胁狩猎。

它会持续观察环境，将观测到的技术栈和暴露风险与威胁研究关联起来，在可用遥测数据中寻找相关指标和行为证据，并提出狩猎发现、检测覆盖改进建议或升级协作事项。

不是一蹴而就：三年的AI 技术沉淀

最近，很多身边的朋友很焦虑，甚至陷入了虚无主义。万事万物，AI 好像都可以搞定。但AlertZero也不是凭空冒出来的产品，它是Elastic在安全领域近三年AI技术积累的整合：

• 2023 年，Elastic AI Assistant 上线，开启了安全领域的对话式 AI 辅助
• 2024 年，Attack Discovery 推出，把零散告警关联成完整攻击叙事
• 随后，Elastic Agent Builder 与安全技能（Skills）体系落地，让 AI Agent能调用工具、应用领域专业知识
• Elastic Workflows 则提供了可重复的自动化执行能力

AlertZero 把这些能力全部整合起来，按照 SOC 的职责重新组织，最终形成了面向安全运营的完整 Agent 体系。

SOC 的下一站，是Agent化

AlertZero 的出现，标志着 Elastic Security 正式迈入Agentic SOC 时代。

它没有用 AI 取代分析师，而是把重复、繁琐、高并发的关联、分诊、初筛、规则调优工作交给Agent，把人的判断力留给最关键的决策环节。

当告警队列不再堆积，当分析师不用再困在告警海洋里，安全团队才能真正从 “被动响应” 转向 “主动防御”。 而 “收件箱清零”，或许就是下一代 SOC 的第一个里程碑。

参考资料：https://www.elastic.co/security-labs/blog/ai-soc-automation-alertzero