作为从传统 SIEM 向 Elastic 更广泛的安全运营现代化的一部分，Visa 的网络安全工程团队在 SOC 中构建了首个智能体 AI 工作流：一个四阶段管道，通过使用受限的、人机交互的 AI 步骤来生成可用于 IR 的案例。对于以前需要人工进行第二次查询的高风险大型机检测，分类时间从 10-20 分钟缩短至几秒钟，而且相同的受控、可审计模式现在可以在其他检测中重复使用。
总结
Visa 正在从传统的 SIEM 系统迁移到 Elastic 系统，在此迁移过程中，网络安全工程团队构建了第一个 Elastic 工作流管道作为概念验证。所选的检测方式是一项高风险的大型机身份检测，过去分析人员需要从警报转向后续搜索以确定责任用户，而检测结果在很大程度上取决于分析人员对大型机日志的经验水平。团队将两个 Elasticsearch 查询语言 (ES|QL) 查询串联起来，添加了一个受限的 AI 步骤，用于为 IR 团队生成结构化摘要，并使用 Webhook 将案例直接发送至其 IR 工单系统。当警报触发时，分类现在只需几秒即可完成，而不再是 10 至 20 分钟，并且相同的四阶段模式现已可应用于其他检测。
当警报只是工作的开始
Visa 为全球最大的支付环境之一提供安全保障。作为从传统 SIEM 向 Elastic 进行更广泛现代化改造的一部分，网络安全工程团队着手构建 Visa 尚未大规模拥有的东西：一种可控且可防御的、在安全运营中使用 AI 的方式。标准是具体的。任何 AI 步骤都必须是可审计、范围明确的，并可验证地固定在团队控制的数据中。该标准首次测试的地方是一个高风险的大型机身份检测，事件响应团队每次警报都要花费 10 至 20 分钟手动收集上下文信息，之后才能开始调查。
当旧版 SIEM 系统触发该检测时，事件响应团队必须登录系统，运行第二次搜索，并找出是哪个用户在实施该活动。检测识别出了该事件。分析人员还需要确定此人的身份。
“警报将会发出。IR 团队会收到警报，然后他们需要登录旧系统并进行第二次搜索。仔细查看数据。确保他们为用户找到正确的终端。但我们不知道究竟是谁干的。所以你必须运行第二次搜索，然后找出最后使用该终端的人是谁，接着将结果交给大型机团队。这一切都太耗时了。”
团队的思路很简单：如果每个可操作的警报都需要第二次查询才能让 IR 团队采取行动，则该管道是不完整的。将第二个查询上移到管道本身，IR 团队就会得到一个已经过丰富、总结并准备移交给大型机团队进行审查的案例。
Visa 的发展历程：一次富有创造力的迁移
Visa 更广泛的项目是将检测逻辑从传统 SIEM 迁移到 Elastic。这种迁移往往只是机械地转换规则。团队特意为工程师留出了空间，以便在进行转换工作的同时尝试新的平台功能。
“现在，有了 Elastic，我们了解到我们可以走得更远。技术极限，我以前根本没考虑过。既然我们已经了解了该工具所能提供的功能，人们就可以发挥创造力，提出改进流程、提高效率的想法。
团队中的一名网络安全工程师参加了 Elastic 工作流培训，选择了一种他们已经很熟悉的检测方法，并与 Elastic 解决方案架构师合作构建了第一个版本。Elastic 团队根据工程师提供的样本生成了具有代表性的测试数据，从头开始构建了入门工作流，并将其作为模板返还给工程师以便后续扩展。
现有方法无法提供的是与数据位于同一安全平台内的原生自动化。在 Visa，SOAR 风格的编排由一个独立的自动化团队负责，并在与检测本身分离的平台上运行。借助 Elastic 工作流，整个管道在一个地方运行：检测、丰富、验证和交付，所有环节均原生支持，并全部集成在一个 YAML 文件中，工程师可以在一个屏幕上直接阅读和编辑该文件。
工作流程之所以成为正确的切入点，还有一个具体的原因。Visa 需要完全控制 AI 步骤接收的信息、生成的内容以及每个决策的验证方式。对于受监管的金融服务环境而言，可审计性是信任 AI，进行安全运营的前提条件。工作流为团队提供了一个可以完全量化和验证的模式，每个步骤都可在单一的 YAML 文件中显示，随后扩展到 Elastic 路线图中的其他智能体功能。
之前：先发出警报，然后进行二次搜索，最后进行交接
在之前的工作流中，顺序是先告警，然后进行调查。检测已启动。IR 团队登录了旧版 SIEM。他们运行了后续搜索，以将该事件关联回终端和用户。大型机日志对于这项工作来说并非一个宽容的环境。
此前，有三点导致成本高昂：
- 第二次搜索是不可避免的。一次只能分配一个人到终端，但终端值会被重复使用。为了确定被标记事件背后的用户，分析人员必须查询在事件发生前后，该终端在该主机分区上的最近一次登录记录。
- 分析师的技能非常重要。熟悉查询语言和大型机事件代码的经验丰富的分析师可以很快完成这项工作。经验较少的分析师，或者不太熟悉大型机日志的分析师，花费的时间明显更长。结果在时间和质量上都存在差异。
- 大型机事件代码非常复杂。没有单一路径可以将事件映射到结果。分析人员经常需要解读系统代码，而这些代码的含义取决于上下文，这减慢了工作速度，也使结果更难以标准化。
时间和质量都花在了第二次搜索上。检测已经识别出该事件；而分析人员仍在进行本应作为检测结果一部分的调查工作。
架构：一个按 5 分钟周期运行的四阶段管道
新管道在 Elastic 工作流中以四个环环相扣的阶段运行：
- 检测（主要 ES|QL 查询）：工作流以五分钟为周期，结合十分钟的回溯窗口，对主机日志执行快速且范围较小的 ES|QL 查询，以查找目标身份活动。该检测的精度是刻意设定的；团队预计每次运行最多只会检测到一到两次，而且从历史数据来看，警报每年仅会触发几次。
- 丰富（二级 ES|QL 查询）：对于返回的每个事件，工作流将运行一个后续的 ES|QL 查询，该查询获取主事件中的终端值和 LPAR（大型机分区），然后搜索该终端最近一次登录记录。由于终端可以重复使用，但一次只能分配给一个用户，因此最近一次登录的记录可确定当前活动的用户身份。验证过程很快，因为产生结果的相同查询就在那里，工程师可以直接进行检查。
- AI 验证：将经过丰富处理的事件传递给大型语言模型 (LLM) 支持的步骤。该模型会接收一个受限的提示：假设一次只能有一人使用终端，主要警报详情，以及二次查询的结果。它的任务是验证数据是否支持结论，并生成一份结构化摘要，其中包括用户的姓名和 ID、原始警报检测到的内容，以及为何认定此人即为识别出的行为者。模型本身并不会决定是否升级事件；IR 团队会做出决定。
- 交付 (Webhook)：摘要通过 Webhook 传递到 IR 工单系统。当工单创建完成时，IR 工程师正在阅读案例，而不是构建案例。
此处最重要的架构选择是整个管道在与安全数据相同的平台内原生运行。没有独立运行的 SOAR 系统，无需维护独立的编排系统，检测与工作流程之间也无需额外的连接。
技术亮点
- 每五分钟执行一次 ES|QL 主查询，回溯时间为十分钟
- ES|QL 二级查询从主事件中获取终端和 LPAR，并查找最近的一次登录记录
- 选择该检测是因为之前手动执行第二次查询步骤时，分析师的工作量较大
- LLM 支持的验证步骤采用受限、结构化的提示性分析，而非自由形式的分析
- 上下文窗口：仅将最近 5 至 15 分钟的相关记录传递给模型，从而减少发送的令牌数量并缩小模型的工作上下文范围
- Visa 正在更换服务提供商，且该平台与具体模型无关
- 工作流是一个单一的 YAML 文件，可以在 Kibana 的同一个界面中编写和测试，就像代码编辑器一样
- Webhook 将结构化摘要直接发送到 IR 工单系统
功能
在单个工作流中实现链式 ES|QL 检测和丰富
将检测和丰富视为一个连续的流程，而非两个由分析人员介入的独立步骤，正是这一做法使得后续的整个流程得以实现。ES|QL 的管道模型允许团队能够以声明方式表达流程：主查询用于识别已标记的事件，而二次查询则在终端到用户的映射中分层，以确定最有可能执行该操作的人员。两者之间没有分析师控制台会话，也没有第二个工具可供登录。现在，工作流的结构与分析师实际提出问题的结构相匹配（谁做了这件事？），而不再停留在“是否发生了什么？”的层面。
一种具有明确限定范围的受限 AI 步骤
AI 步骤正在执行一项特定任务：确认丰富数据支持结论，并生成 IR 团队可以在几秒钟内阅读的结构化摘要。它不会生成检测逻辑。它不会决定是否升级。该假设是分析的基础（同一时间只能有一人使用终端），并给出最近的先前登录信息，以便根据该假设进行评估。
“以前，IR 团队必须登录到另一个工具并运行其他搜索。现在他们只需获取包含所有可用数据的警报。所有内容都以非常简洁的方式总结出来了。”
这种局限性正是关键所在。团队的选择不是“让模型进行调查”，而是“让模型验证并总结查询已返回的内容。”管道中的每个 AI 决策都在评估团队可以看到的数据，并根据团队控制的标准进行评估。这正是验证过程可审计而非不透明的原因。
高效的令牌上下文窗口管理
该模型永远不会看到超出其需要的数据。该管道会筛选传入的记录，只保留与事件发生时间窗口（最后 5 到 15 分钟）相关的记录，以匹配检测的框架。其结果是上下文窗口更小，每次决策的令牌数更少，推理更严谨，因为模型不会试图解释与问题无关的记录。
安全平台内部的原生自动化
整个数据管道和数据都存储在 Elastic 中。无需维护单独的编排平台，无需在发生事故时维持脆弱的集成，也无需与第二个团队协调工作流程。使用 YAML 编写的工作流可以通过 HTTP 调用其他系统，因此该平台的覆盖范围得以扩展，同时又不失去其原生环境。对于 Visa 来说，这一点非常重要。目前，一个独立的自动化团队负责在与安全数据不同的平台上进行 SOAR 式编排。该团队已向 Elastic 申请了 API 访问权限，而网络安全工程团队也愿意使用工作流来承接目前由其他工具处理的响应工作。在 Visa 内部，将所有功能整合到单一原生自动化平台已不再是理论上的讨论。
在分析师专业知识各不相同的情况下实现标准化
最明显的结果是速度，但对运营而言更重要的结果是一致性。大型机日志解释曾是 Visa 故障排查中最不稳定的环节之一：经验丰富的分析人员能迅速完成第二次查询工作；而新手分析人员或对大型机事件代码不太熟悉的分析人员则需要更长时间，并且会产生更不稳定的结果。
“更有经验且精通传统查询语言的分析师可以很快找到答案。对于新手来说，这会比较困难。他们通常不太熟悉大型机日志。毕竟两者是不同的。这正是质量差异产生的原因，而我认为 AI 在这方面会大显身手。它能迅速帮他们理清头绪。”
通过将汇编和摘要推送到管道中，原本依赖于分析师对传统查询语言和大型机事件代码的熟练程度的工作流部分已不再是分析师的工作。IR 工程师会阅读结构化摘要，并判断是否采取行动。
实际操作模式
该检测本身很少触发，历史上每年仅触发几次。这是有意为之。团队之所以选择它，正是因为这是一个低频次、高风险的警报，对于此类警报而言，消除手动二次查询步骤所带来的每次触发成本显然是值得的。更重要的是，这是 Visa 首个此类生产工作流，它建立的四阶段模式现在可以应用于其他检测。
“过去分析人员需要花费 10 到 20 分钟才能完成的警报分析工作，现在只需几秒钟就能完成。IR 团队不再接收需要调查的原始信号。他们收到的警报包含完整的上下文信息，可用于决策。”
Visa 的 IR 工程师现在在收到此警报时会看到：一张包含原始事件、已识别用户（已命名并按 ID 识别）、原因以及返回底层数据的链接的工单。管道执行了第二次查询，LLM 进行了验证和总结，而 Webhook 则创建了工单。工程师的首要行动是判断，而非构建查询。
人类仍然是决策者。管道执行组装。AI 负责验证和汇总。工程师则做只有工程师才能做的事：判断、验证和上报。推送到上游的工作是可重复的工作。工程师留给自己的，是那些需要判断力的工作。
前后对比
| 之前 | 之后 | |
|---|---|---|
| 警报管理 | 需要后续搜索以识别用户的原始事件 | 经过丰富的由 AI 总结的工单已到达 IR，可直接用于决策 |
| 运维工作量 | 第二次搜索和大型机日志解释需要 10 至 20 分钟 | 端到端仅需数秒 |
| 调查流程 | 发出警报，然后在单独的工具中进行第二次查询 | 在单一的链式工作流中进行检测、丰富、验证和交付 |
| 分析师技能依赖性 | 经验丰富的分析师可以快速行动；新手分析师则因受限于传统的查询语言和大型机事件代码而进展缓慢 | 结构化摘要消除了对传统查询语言的熟练度依赖 |
| 工具边界 | 在旧版 SIEM 中发出警报，在旧版 SIEM 中跟进，在单独的编排工具中创建工单 | 检测、丰富、验证和交付均为 Elastic 原生功能，并可通过 Webhook 将事件转发至 IR 工单系统 |
| 分析师角色 | 手动汇编上下文、执行二次搜索、解释大型机日志 | 阅读结构化案例，判断结果，逐步升级 |
4 阶段模式的启示
这是 Visa 的第一个工作流项目，但绝不是最后一个，原因是这种四阶段模式具有可移植性。具体检测方式很特殊，但围绕这一检测方式的操作模式却并不罕见。在任何需要在分析人员采取行动前进行已知且可重复的后续搜索的情况下，都适用相同的四个阶段。
“这是他们操作手册中的已知部分。该管道只需完成这些初步步骤，即可将这些问题从 IR 团队需要调查的范围内排除。”
从此次构建中借鉴的三个原则适用于任何以第二次查询为瓶颈的检测场景。将运行手册中已知的部分自动化集成到流程本身中，因为如果后续操作总是以相同的方式运行，那就不是分析师的工作了。为 AI 步骤分配一个足够具体的任务，以便进行审计：一个受限的提示、一个结构化的输入、以及工程师可以根据数据进行验证的摘要。对上下文进行窗口化处理，使模型仅接收到与事件发生时间相关的数据，而非查询返回的全部数据。第一原则最具普遍性。另外两项则保证了 AI 的防御能力。
后续计划
四阶段模式（检测、丰富、验证、交付）是可移植的。该团队已经在迁移范围内识别出其他检测，这些检测将受益于相同的链式、AI 汇总、Webhook 传递的方法。该团队正在积极评估攻击发现功能，Martin 表示，正是这项功能最初吸引他们选择 Elastic。这种顺序是经过深思熟虑的：通过工作流，Visa 获得了一种可以完全量化和验证的模式，然后再扩展到内部运行更多关联逻辑的功能，这正是受监管的金融服务 SOC 应采取的正确路径。该团队正在同步构建用于威胁搜寻的 AI 智能体，并正在研究工作流如何能够承担目前由单独的自动化团队处理的响应工作。现在，跟上 Elastic 的发布节奏也是工作的一部分。
“你们不断发布新内容，让我分心，无法专注于其他事情。”
“攻击发现可能是我们首要考虑的事项。我们爱上 Elastic 的原因并不是工作流，而是“攻击发现”功能。我们正努力将这款工具定位为以 AI 为核心的 SIEM，并向 Visa 网络安全部门的各个团队推广 Elastic。
Visa 是全球最大的支付网络之一，其安全运营的规模也反映了这一点。您的组织目前可能还没有像 Visa 那样大规模地进行迁移，但无论您是在转换首次检测还是重建完整的 SOC，同样的原则都适用：如果在采取行动前需要再次查询警报，则说明管道尚不完整，而四阶段模式在各个规模层级的每一步骤中均有效。
了解 Elastic 工作流如何帮助您将调查上移到检测管道中。