作者：来自 Elastic James Spiteri
AlertZero 通过四个各司其职的 AI Agent，为 Elastic Security 引入 AI 驱动的安全运营中心（SOC）自动化能力，让告警队列不再主导你的工作优先级。未经你的批准，系统不会对你的环境进行任何更改。
过去几个月里，我们一直在与安全团队深入交流，并针对你们提出的、因 AI 加速发展而带来的安全挑战构建解决方案。其中一个突出问题是，随着攻击者开始利用 AI，安全告警的数量和产生速度都在急剧增加，让安全团队不堪重负。
Hugging Face 安全事件揭示了安全运营中心（SOC）面临的另一个核心挑战：即使检测到了所有安全信号，如果无法将这些信号关联起来，识别出它们属于同一次攻击，检测本身仍然远远不够。
这些问题叠加在一起，迫使大多数安全团队只能根据人员规模来决定能够覆盖多少安全事件。结果，告警队列中的内容决定了哪些问题能够得到关注，而其余告警则随着时间推移，在未经调查的情况下逐渐被忽略。在这种情况下，投入时间开展主动防御就显得更加困难。
今天，我们将首次向大家展示 AlertZero，这是 Elastic Security 全新的 Agentic AI 智能体层。
AlertZero 的核心理念非常简单：帮助 SOC 团队实现类似"收件箱清零"（Inbox Zero）的告警管理目标，让每一条告警都得到处理。
为实现这一目标，AlertZero 通过大规模告警关联分析和信息增强，减少现有告警队列及其中的误报，并提出相应的处置建议，进而帮助安全团队创建和优化检测规则。
AlertZero 包含多个称为 Watches 的智能体，每个 Watch 都有明确的职责：分诊（Triage）、威胁狩猎（Hunt）、检测（Detection）或取证（Forensics）。
这些 Watches 可以根据触发条件或预设计划运行，并基于证据提出结论和建议操作，称为 Proposed Actions（建议操作）。分析师可以选择批准、修改、升级处理或驳回这些建议。
每个 Watch 会根据其自主级别向分析师呈现需要决策的事项。自主级别包括手动（Manual）、辅助（Assisted）和监督（Supervised）三种模式。无论采用哪种模式，所有具有实质性影响的操作都必须先提交给分析师审批。
AlertZero 延续了 Elastic Security 一贯的 "开放式设计"（Open by Design） 理念。
你可以根据团队需求自由选择最适合的 大语言模型 ，包括专有模型和开源模型。无论是在 Elastic Cloud、企业自行管理的部署环境，还是完全物理隔离的环境中，都可以使用相同的产品及功能。
AlertZero 并非一夜之间诞生的产品，而是建立在 Elastic Security 过去三年生成式 AI（GenAI）创新成果的基础之上。
2023 年，Elastic AI Assistant 首先引入了对话式 AI 辅助能力。
2024 年，Attack Discovery 将这一能力扩展到专门的安全调查任务，通过关联相关告警，构建完整的攻击过程叙述。
随后，Elastic Agent Builder 和 Security Skills 引入了能够调用工具并运用领域专业知识的 AI Agent ，而 Elastic Workflows 则提供了可重复执行的自动化工作流。
AlertZero 将这些能力整合在一起，并针对 SOC 的核心职责进行了专门设计。
AlertZero Watches 各司其职，专注做好自己的工作
AlertZero 中的每个 Watch 都直接对应 SOC 的一项核心职责，并且可以自定义其自主运行级别。
在每个 Watch 内部，Workers（工作单元） 负责执行具体任务。
例如，Triage Worker 会运行 Attack Discovery，将相关告警关联起来，形成完整的攻击过程描述；而 Forensics Worker 则负责检查端点活动。
安全团队可以控制每个 Worker 在无需人工审核的情况下能够执行哪些操作，从而根据团队最迫切的需求，灵活配置各个 Watch 的工作方式。
即将推出的技术预览版将包含四种 Watches：
| Watch 名称 | 帮助安全团队完成的工作 |
|---|---|
| Triage（分诊） | 评估安全告警、关联相关活动，并识别需要重点关注的调查结果。 |
| Hunt（威胁狩猎） | 利用威胁研究成果，在现有遥测数据中主动寻找攻击证据。 |
| Detection（检测） | 调查产生大量噪声的检测规则和检测覆盖盲区，并准备检测规则变更，供安全团队审核。 |
| Forensics（取证） | 分析端点活动，还原事件经过，并识别有证据支持的响应操作。 |
!\[\](https://i-blog.csdnimg.cn/direct/c3003b0bd0764af483574a816abd9023.png) 图 1. 四种 Watches 将自动化安全任务与 SOC 团队熟悉的核心职责相对应。分析师可以自主选择要执行的任务，以及将多少工作委托给 AI Agent。
威胁狩猎可以从最新的威胁研究成果开始，检测分析可以由反复出现的误报触发，而端点分析则可以从需要进一步调查的安全发现入手。所有 Watches 都可以根据触发条件或预设计划运行。Watches 并不构成一个必须按顺序执行的固定流水线。
AlertZero 如何处理可疑登录会话
以下示例展示了 Triage（分诊）和 Forensics（取证）两种 Watches 如何协同工作。
我们将从 Proposed Actions（建议操作） 页面开始。在这个页面中，等待人工审批的 Watches 会先展示其分析结果和拟执行的操作，供分析师审核，然后才会执行相应操作。
图 2. AlertZero 的建议操作（Proposed Actions）列表，按照等待人工审核的操作类型进行分类展示。
建议操作（Proposed Actions）会根据等待人工审核的操作类型进行分组。
在这个具体场景中，Respond（响应） 类别下有一条针对高管账户 cfo@corp 的"不可能旅行"（Impossible Travel）异常登录发现，并提出了一项等待审核的端点隔离操作。
在我们打开这个页面之前，Triage Watch（分诊智能体） 和 Forensics Watch（取证智能体） 就已经收集了支持该操作建议的相关调查结果和证据。
点击该条目后，即可查看关联的 Investigation（调查） 及其支持证据。
图 3. 分析师打开与建议操作（Proposed Action）关联的调查（Investigation），查看支持该操作建议的相关证据。
在这个示例中，该账户最初在波士顿处于活跃状态，随后仅过了 39 分钟，就从一个地理位置遥远的托管网络再次出现活动。两次活动使用了相同的会话标识符，而且没有发生新的多因素身份验证（MFA）事件。
端点调查结果提供了更多上下文信息：一个未经数字签名的进程正在访问浏览器会话数据。
如有必要，我们还可以进一步调查该进程是如何启动的、与哪些目标建立了连接，以及相关活动发生的时间范围。
为了全面了解安全事件的影响范围，除了端点调查结果之外，我们还可以在同一个侧边详情面板（Flyout）中查看相关告警和受影响的实体。
在这个案例中，这些异常行为表明有必要进一步调查是否存在会话重放攻击（Session Replay）。与此同时，还需要考虑虚拟专用网络（VPN）、代理服务器的使用，以及地理位置定位不准确等其他可能的解释。
在 Investigation（调查） 的对话界面中，我们可以在决定下一步如何处理之前，继续提出以下问题：
-
该账户在可疑登录发生后访问了哪些资源？
-
如果隔离该端点，会中断哪些业务活动或操作？
这些问题也会触发进一步的分析，而此前已经收集的调查结果可以直接作为上下文使用。
图 4. 审核从建议操作（Proposed Action）开始。分析师可以在做出决策前查看相关证据并提出问题；对于已批准的操作，系统会记录其执行结果。
在这个场景中，端点响应被设置为人工审核模式。因此，在确认目标对象、操作依据以及可能产生的影响后，我们可以选择批准或拒绝该建议操作（Proposed Action）。
如果批准，系统将通过 Elastic Defend 执行主机隔离操作。
为了满足审计和可追溯性要求，Investigation（调查）会分别记录审批决策和操作执行结果。
当某个 Investigation（或一组 Investigations）需要协调一致且范围受控的响应措施时，分析师可以创建一个 Escalation（升级处置），并将相关的 Investigations 关联起来。
图 5. 团队成员与关联的 Investigation（调查）共享同一个 Escalation（升级处置）对话。
团队成员可以共同讨论相关证据，并在同一个对话中向 AI Agent 提出后续问题。对于特别敏感的情况，团队也可以选择完全不调用 AI Agent。
除了告警分诊，AlertZero 还能做什么？
通过大规模告警关联分析和信息增强来减少告警队列中的待处理事项，只是解决方案的一部分。
另一方面，我们也致力于帮助安全团队完成那些在没有紧急安全事件发生时需要开展的工作，例如主动威胁狩猎和持续优化检测能力。
让威胁狩猎快人一步
在威胁狩猎方面，Hunt Watch（威胁狩猎智能体） 能够：
-
持续监控你的环境。
-
将环境中观察到的技术和暴露面与相关威胁进行关联。
-
主动提出威胁狩猎任务、调查发现、检测覆盖改进建议或升级处置建议。
其核心目标是回答这样一个问题：
"我的环境中是否存在这种威胁的证据？"
而且，你无需手动发起威胁狩猎，也不必主动提供威胁情报。
即使尚未触发任何检测告警，Hunt Watch 也能基于威胁研究成果，主动帮助安全团队开展威胁狩猎。
它会将威胁研究成果与当前环境及可用的遥测数据关联起来，搜索相关威胁指标，同时分析能够支持判断的行为证据。
最终生成的调查结果会明确说明搜索了哪些内容，以及发现了什么。
将误报和检测覆盖盲区转化为规则优化
为了提升针对特定环境的安全防御能力，威胁狩猎的调查结果可以为 Detection Watch（检测智能体） 提供参考，帮助其判断现有检测规则是否能够识别相关行为。
假设某个合法的管理工具反复触发一条检测规则。
将这些告警关闭并标记为误报，本身就是有价值的反馈。但仍然需要有人将多次告警处置决策关联起来，识别出它们是否源于同一条规则中的共同问题。
这正是 Detection Watch 可以发挥作用的地方：它能够利用这些误报关闭记录作为额外的上下文信息，进一步分析问题。
Detection Watch 会检查相关告警示例和现有检测逻辑，然后根据分析结果，准备一项附带诊断依据的规则修改建议，例如添加一条例外规则。
随后，检测工程师可以评估：是否能够通过范围足够精确的例外条件，排除正常的管理操作，同时保留对攻击者恶意使用同一工具的检测能力。
例如，Detection Watch 可以执行如下 Elasticsearch 查询语言（ES|QL） 查询：
ini
`
1. FROM .alerts-security.alerts-*
2. | WHERE @timestamp >= NOW() - 7 days
3. AND kibana.alert.workflow_status == "closed"
4. AND kibana.alert.workflow_reason == "false_positive"
5. | STATS false_positives = COUNT(*)
6. BY kibana.alert.rule.uuid, kibana.alert.rule.name
7. | SORT false_positives DESC
8. | LIMIT 20
`AI写代码Detection Watch 会根据近期被关闭并标记为误报的告警数量，对检测规则进行排序，然后识别误报数量较高的规则，以便进一步调查。
误报数量较高并不一定意味着检测规则本身存在缺陷。 分析过程仍然需要检查具体的告警示例及其被关闭的原因，因为如果某条告警被错误地标记为误报，就可能进一步导致生成错误的排除规则。
在这个示例中，Detection Watch 的 Rule Tuning Worker（规则调优工作单元） 被设置为手动模式。
分析师授权开展分析后，系统生成的 Proposed Action（建议操作） 会汇总诊断结果、触发此次调优的相关告警、现有检测逻辑、建议修改后的检测逻辑，以及回测结果。
这样，检测工程师不仅能够评估一项具体的规则修改建议，还可以查看支持该建议的相关证据，了解其形成依据。
图 6. 规则调优建议操作（Proposed Action）包含告警示例、当前及建议修改后的检测逻辑，以及回测结果。在此示例中，5 条样本告警在调优后降至 0 条；但仅凭这一结果，还不足以证明对攻击行为的检测覆盖能力未受到影响。
通过这项修改建议，我们可以看到，原先的 5 条误报样本已经不再匹配修改后的查询条件。
我们可以打开 Proposed Action（建议操作） 查看具体变更，并在关联的 Investigation（调查） 中继续提出问题，例如：
"这条例外规则还会抑制哪些其他活动的检测？"
由于此次回测仅涵盖正常活动样本，因此在批准修改之前，分析师仍然需要通过团队现有的测试流程，验证修改后的规则能否继续检测已知的恶意活动。
如果建议获得批准，系统就会应用相应的规则变更；如果建议被拒绝，原有规则将保持不变。
你可以自主决定委托多少工作给 AI
你可以自行选择运行哪些 Watches，以及每个 Watch 能够执行到什么程度，并且可以针对每个 Worker（工作单元） 单独配置自主运行级别。
我们在 AlertZero 中引入这一设计，是因为不同安全团队的组织方式各不相同。
有些团队采用分层安全运营模式，有些采用小组协作模式（Pods），许多团队没有专职的检测工程师，而大多数团队也无法安排足够的人员覆盖夜间时段。
无论团队采用何种组织结构，不同任务本身也具有不同的风险，因此需要能够灵活配置自主运行级别。
例如，评估一条安全告警与直接对端点采取响应操作，两者的风险显然不同。
你可以将常规分析工作委托给 AI 自动完成，同时对于可能影响主机运行的操作，采取更加谨慎的审批策略。
举例来说，Triage Watch（分诊智能体） 中的 Worker 负责运行 Attack Discovery，而 Forensics Watch（取证智能体） 中的 Worker 则负责执行端点分析。
每个 Worker 都以 Elastic Workflow 的形式运行，并调用 Agent Builder 中的 Agents 和 Skills 完成分析任务。
对于 Attack Discovery 判断为真实威胁（True Positive） 或结论不明确（Inconclusive） 的情况，手动审核模式允许分析师决定是关闭 Investigation，还是请求进一步开展端点分析。
在监督模式（Supervised） 下，如果 Attack Discovery 将事件判断为真实威胁，系统可以自动继续执行端点分析，而无需等待人工批准。
但如果分析结果仍然不明确，则必须由人工做出决定。
端点分析具有独立的控制机制。
在手动模式（Manual） 下，系统会将有证据支持的响应操作提交给分析师审核。
在监督模式（Supervised） 下，系统的设计允许直接执行主机隔离、进程终止和进程挂起等操作，而无需对每项操作再次单独审批。
不过，检测规则的修改仍然需要人工批准。
因此，安全团队可以选择自动化执行整个处理流程中的某些环节，同时保留对其他环节的人工审核，从而在自动化效率与安全控制之间取得平衡。
图 7. 端点分析具有独立的自主运行级别控制机制；此处选择的是手动审核模式。
每条告警都得到处理，每项决策都由你掌控
作为帮助推动安全调查持续开展的 AI 能力，AlertZero 将那些过去经常在工作交接环节中断的任务连接起来。
在告警分诊过程中收集的证据，可以指导后续的端点分析，并为响应决策提供依据。同时，这些证据也为团队成员提供了一个共同协作、继续深入调查的基础。
安全团队可以自主决定哪些工作交由 AI 完成，以及哪些环节仍然需要人工判断。
如果你希望及时了解 AlertZero 的最新动态，可以订阅产品更新。
AlertZero 即将面向所有 Elastic Security 用户推出。
术语表（Glossary）
AlertZero： Elastic Security 的 Agentic AI 智能体层，将告警分诊、威胁狩猎、检测工程和端点取证等安全运营工作连接起来。
Watch（智能体）： 围绕特定安全职责组织的一组自动化任务。首批推出的四种 Watch 分别是 Triage（分诊）、Hunt（威胁狩猎）、Detection（检测）和 Forensics（取证）。
Worker（工作单元）： 通过 Elastic Workflows 中的工作流实现的特定任务，利用 Agents 和 Skills 生成调查发现、收集证据，并提出有依据的操作建议。
Proposed Actions（建议操作）： 附带支持证据和理由的建议变更。在需要人工审核的情况下，这些建议会提交给分析师审批。
Investigation（调查）： 用于记录和管理某项调查的共享工作空间，汇总调查发现、受影响实体、相关证据以及建议操作（Proposed Actions）。
Escalation（升级处置）： 由人员创建的协作对话，用于协调与多个关联 Investigations 相关的工作。团队成员可以在其中讨论证据，并向 AI Agent 提出问题。对话的可见性可以设置为公开或私有。
Autonomy Setting（自主运行设置）： 针对每个 Worker 独立配置的控制选项，用于决定哪些工作可以在无需人工审核的情况下执行。其具体行为取决于任务类型。
Consequential Action（具有实质性影响的操作）： 会对实际环境产生更改的操作，例如隔离主机或修改检测规则。
Elastic Defend： Elastic 的端点安全防护能力，提供受支持的端点响应操作。
Attack Discovery（攻击发现）： 一项能够将相关告警关联起来、识别潜在攻击的功能。Triage Watch 使用该功能，为每个识别出的攻击创建一个 Investigation（调查）。
Elastic Agent Builder、Elastic Workflows： 构建 Watches 的可扩展基础组件。其中，Agent Builder 提供 Agents、工具和 Skills，而 Elastic Workflows 负责协调和执行工作流。
原文：AI SOC automation: Inbox zero for your alert queue | Elastic Security Labs