弹性工作流已在 9.4 中全面推出。它是直接内置在 Elastic 中的自动化层，可在您的数据所在的安全、可观察性和搜索领域运行。虽然这篇文章侧重于安全方面的深入探讨，但同样的工作流程功能适用于各种解决方案，无需单独部署平台，也无需移动数据。当警报触发或计划触发时，就会执行工作流：查询 Elasticsearch、使用威胁情报进行充实、创建案例、调用外部 API 并通知团队。用 YAML 定义或用自然语言描述，然后让人工智能生成工作流程。
9.3 技术预览版为 Elastic 的本机自动化奠定了基础。9.4 版使其具有生产稳定性和显著扩展的功能，并已全面投入使用。病例管理可通过 25 获得涵盖整个生命周期的专用自动化步骤。人在回路中成为一流的工作流程原型。自然语言编写功能进入技术预览版。该平台获得了更多的流程控制原语（while 、switch 、迭代控制）、用于处理集合的数据转换步骤、与Agent Builder 更深入的人工智能集成，以及更广泛的事件驱动触发器。跨 Elastic 的生产就绪自动化。
大规模案件自动化
对安全团队而言，最大的新增功能是案件管理。在技术预览版中，处理案例涉及四个通用步骤：创建、检索、更新和注释。除此之外的任何操作都需要调用原始 API。
现在， 25 专门的cases.* 步骤涵盖了整个生命周期：创建、查找、查找类似、更新、关闭、分配、取消分配、添加警报、添加观测值、添加注释、添加标签、设置严重性、设置状态等。每个步骤都经过键入和验证，并显示在 YAML 编辑器的自动完成中，这意味着自然语言编写也能准确生成这些步骤。
下面是一个现实的分流工作流程。警报响起。工作流程会检查该警报是否已有案例。如果没有，它就会创建一个，附加警报和可观测数据，指定值班分析员，并根据风险评分确定严重程度：
下面的代码展示了一个使用 YAML 描述工作流程的示例：
name: Triage Workflow
enabled: true
triggers:
- type: alert
steps:
- name: check_existing
type: cases.getCasesByAlertId
with:
alert_id: "{{ event.alerts[0]._id }}"
- name: route
type: if
condition: "steps.check_existing.output : ''"
steps:
- name: update_existing
type: cases.addComment
with:
case_id: "{{ steps.check_existing.output[0].id }}"
comment: |
Correlated alert: {{ event.rule.name }}
Source: {{ event.alerts[0].source.ip | default: "unknown" }}
Risk score: {{ event.alerts[0].kibana.alert.risk_score }}
else:
- name: create_case
type: cases.createCase
with:
owner: securitySolution
title: "{{ event.rule.name }} - {{ event.alerts[0].host.name }}"
description: |
Auto-created from detection rule: {{ event.rule.name }}
Host: {{ event.alerts[0].host.name }}
Source IP: {{ event.alerts[0].source.ip | default: "N/A" }}
severity: high
tags:
- auto-triage
- "{{ event.rule.name }}"
- name: attach_evidence
type: cases.addAlerts
with:
case_id: "{{steps.create_case.output.case.id}}"
alerts:
- alertId: "{{ event.alerts[0]._id }}"
index: "{{ event.alerts[0]._index }}"
- name: add_observables
type: cases.addObservables
with:
case_id: "{{steps.create_case.output.case.id}}"
observables:
- typeKey: observable-type-ipv4
value: "{{ event.alerts[0].source.ip }}"
- typeKey: observable-type-file-hash
value: "{{ event.alerts[0].file.hash.sha256 }}"
on-failure:
continue: true工作流程可自动处理重复数据删除、证据附件、可观测的丰富化、缺失字段的优雅处理以及分析师分配。分析师打开 Kibana，就会看到一个包含所有上下文的案例。
25 cases.* 新步骤包括创建、查找、查找类似、更新、关闭、删除、分配、取消分配、添加/删除警报、添加/删除观测值、添加/更新/删除注释、添加/删除标记、设置严重性、设置状态、通过 ID 获取、通过警报 ID 获取，以及更多用于自定义字段、用户操作和度量的步骤。每个步骤都经过打字和验证。如果使用自然语言编写，人工智能就能准确生成它们，因为它们是模式的一部分。
随着工作流的成熟，您将看到更多针对特定领域的检测规则管理、端点响应操作和威胁情报操作步骤。
自动化工作流程中的人工检查点
案件自动化处理的是机械性工作，但并非每个决策都应完全自动化。人工智能可以对警报进行分类并收集上下文，但分析人员应决定是否升级。问题是，在他们做出这个决定之前，要进行多少机械加工。
waitForInput 暂停工作流程，供人工判断。工作流程会运行调查、收集证据、利用人工智能对警报进行分类，然后停止。它提出了有条理的结论和等待。分析师进行审查、批准或重定向，并添加注释，然后工作流程根据他们的输入继续运行。
如下图所示，自动化系统会处理调查，但分析师会在自动化系统执行之前做出决定。
利用人工智能对收到的警报进行分类，暂停供分析师审查和批准，并通过创建一个具有模型和分析师背景信息的高严重性事件，仅升级已批准的案例。
name: HITL Example
enabled: true
triggers:
- type: alert
steps:
- name: classify
type: ai.classify
connector-id: Anthropic-Claude-Sonnet-4-6
with:
includeRationale: true
input: ${{ event.alerts[0] }}
categories:
- true_positive
- false_positive
- needs_investigation
- name: approval_gate
type: waitForInput
with:
message: |
Alert: {{ event.rule.name }}
Classification: {{ steps.classify.output.category }}
Rationale: {{ steps.classify.output.rationale }}
Review the classification and approve to escalate.
schema:
type: object
properties:
approved:
type: boolean
title: Approve escalation
notes:
type: string
title: Analyst notes
required:
- approved
- name: escalate
type: if
condition: "steps.approval_gate.output.approved : true"
steps:
- name: create_escalated_case
type: cases.createCase
with:
owner: securitySolution
title: "[Escalated] {{ event.rule.name }}"
description: |
Escalated by analyst after AI classification.
Classification: {{ steps.classify.output.category }}
Notes: {{ steps.approval_gate.output.notes }}
severity: high
tags:
- escalated
- analyst-reviewed如今，waitForInput 可通过 Kibana 执行视图和 REST API 运行。Slack、Teams 和电子邮件交付渠道即将推出，分析师无需切换上下文即可进行审核和批准。这对于在代理生成器中定义为工具的工作流尤为重要，因为在代理驱动的调查中，采取行动前的人工检查点对调查大有裨益。
利用自然语言构建工作流程
有了自动化模式，下一个挑战就是如何让这些模式便于使用。我们选择 YAML 作为工作流语言，是因为它具有声明性、可审查性和可移植性。但这也是一种战略选择：YAML 是结构化文本，而大型语言模型非常擅长生成结构化文本。类型完善的工作流程模式是人工智能驱动的编写工作的理想目标。在 9.4 中，这个赌注得到了回报。技术预览版提供自然语言创作功能。
在工作流程编辑器中，描述应该发生的事情："当恶意软件警报触发时，根据 VirusTotal 检查文件哈希值，创建高严重性案例，附加警报和可观察项，并通知 SOC 频道。"人工智能助手会生成 YAML。审查、完善和部署。
YAML 可完全检查和编辑。如果你知道应该发生什么，但又不是 YAML 专家，这可以让你从意图变成工作流程。如果您是 YAML 专家，可以从自然语言开始，然后在编辑器中进行细化。
创作体验将不断发展。视觉编辑是一种补充模式。可扩展到 Slack 和团队使用的其他工具的创作。我们的目标是，无论安全团队在哪里工作，我们都能满足他们的需求。
可组合的工作流程
随着自动化图书馆的发展，组织工作变得至关重要。安全自动化变得非常复杂。开始时，您使用单一的分流工作流程，然后发现不同的警报类型需要不同的调查步骤。你添加了条件，然后又添加了更多的条件，突然间，你的工作流程就变成了数百行嵌套逻辑，难以遵循，也难以更改。
workflow.execute 可让你通过输入和输出类型构建可重复使用的工作流。您不需要将所有调查逻辑嵌入到一个地方，而是针对特定场景创建重点工作流，并将它们组合在一起。更新一次恶意软件调查工作流程，每个调用该流程的工作流程都会受益。逻辑保持有序，变更保持受控，自动化扩展不会变得脆弱。
实际情况是这样的。对警报进行分类，然后根据威胁类型转到专门的工作流程：
steps:
- name: dispatch
type: switch
expression: "{{ steps.classify.output.category }}"
cases:
- match: malware
steps:
- name: run_malware
type: workflow.execute
with:
workflow-id: ${{ consts.malware_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
- match: phishing
steps:
- name: run_phishing
type: workflow.execute
with:
workflow-id: ${{ consts.phishing_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
default:
- name: run_generic
type: workflow.execute
with:
workflow-id: ${{ consts.generic_triage_id }}
inputs:
alert: ${{ event.alerts[0] }}每个工作流程都可独立测试。大多数团队从单一的工作流程开始，然后根据出现的模式提取子工作流程。构图是你成长的过程。
模板库最终将移至产品中，这样您就可以直接在 Kibana 中发现和安装预建工作流。
分析师已经工作的地方
工作流程最有用的地方，是在做出决策的地方。基本原理和模式已经到位，但只有当分析师无需切换工具就能实现自动化时，自动化才能带来价值。从警报表和 "攻击发现 "开始，我们将在整个安全分析体验中对工作流的可访问性进行投资。分析师可以直接向工作流发送警报或整个攻击，触发他们建立的调查逻辑，而无需离开当前的上下文。这种整合将继续扩大，使工作流程自动化成为分析师日常工作的一个无缝组成部分，而不是一个单独的目标。
"在警报表中运行工作流程" 可让您右键单击警报（或选择多个警报）并直接触发工作流程。警报上下文自动通过。
这就是开始。工作流程将继续扩展到安全体验的更多部分，使分析人员在需要的地方也能实现自动化。
更多控制，更大灵活性
除了主要功能外，工作流语言本身也变得更加强大。新的流量控制基元为您提供了处理复杂逻辑的更简洁方法。while 循环让你可以轮询条件或等待外部状态变化。switch 提供多向分支，因此您可以按类别发送警报，而无需嵌套条件。loop.break 和loop.continue 为您提供标准的迭代控制。
步骤级数据转换步骤可处理集合上的过滤、查找、聚合和 JSON 操作，因此无需自定义脚本即可处理警报列表、IOC 查询和增强响应。
人工智能步骤 (ai.prompt,ai.classify,ai.summarize,ai.agent) 更加稳定，现在支持结构化输出，从而更容易在下游工作流程逻辑中使用人工智能生成的分类和摘要。
LiquidJS 模板也得到了扩展。现在，您可以设置变量并在整个工作流程中访问它们，从而更轻松地在多个步骤中引用计算值。
可靠性和生产控制
所有这些只有在可靠的情况下才有用。每个步骤都支持on-failure 配置：瞬时故障时重试，步骤不重要时继续，下游步骤依赖于结果时中止。错误详细信息可通过steps.<step-id>.error 获取，以帮助绕过故障。
并发控制可防止警报风暴产生数百个并行执行。环形护栏可防止执行失控。合成深度限制可防止无限递归。
Elastic 9.4 引入了事件驱动触发器，从workflows.failed 开始。当工作流执行失败时，它可以触发一个单独的处理程序工作流。建立一个通知工作流程，在自动化出现故障时向团队发出警报。更多触发器类型即将推出：案例状态更改、警报状态转换和检测规则更新，使工作流能够对整个安全环境中发生的情况做出反应。
每次执行都会记录在执行历史中，并提供逐步结果，包括来自waitForInput 步骤的分析师决策。这是你的调试工具和审计线索。
在 9.4 中，企业许可证默认启用工作流。细粒度的 RBAC 可控制谁来创建、编辑、执行和查看工作流。每次管理操作都会写入安全审计日志。导入/导出可在环境之间移动工作流程，并保持连接器引用不变。
许可和定价
工作流在 Elastic Cloud Hosted 和自我管理部署上可使用企业许可证，在 Elastic Cloud Serverless 上可使用完整层安全项目许可证。
9.4 版在所有部署类型中引入了统一的基于执行的定价模式。
在无服务器、弹性云托管和自主管理方面，定价基于工作流的执行情况，规模越大，折扣越多。每个月都包括未计费工作流程执行的基线分配。超出这一分配额度的用量按每次执行计费，用量增加时按用量折扣计费。
Elastic Cloud Serverless于 5 月1 开始应用这种模式，2026 。每月不计费执行次数以外的使用按次收费，执行次数越多越优惠。查看全部定价详情。
弹性云托管部署和自主管理部署采用相同的定价模式，但目前正处于促销期，尚未收取执行费用。这使团队能够构建和运行工作流，建立使用模式，并为在未来版本中过渡到基于执行的计费做好准备。
现在就开始建设。当定价过渡到统一模式时，您现在创建的工作流程将继续运行。
开始使用
工作流程在 9.4 中默认启用。打开 Kibana，导航至工作流，然后开始构建。
如果您是工作流程的新手，技术预览文章将引导您建立第一个分流工作流程。Chrysalis APT 工作流程展示了 Agent Builder 集成的实际效果。文档中有完整的步骤类型参考。弹性工作流程库有随时可用的模板。
从本周能为团队节省最多时间的工作流程开始。如果你能描述它，你就能建造它。
本博文所描述的任何特性或功能的发布及上市时间均由 Elastic 自行决定。当前尚未发布的任何特性或功能可能无法按时提供或根本无法提供。