Como parte de uma modernização mais ampla de suas operações de segurança, migrando de um SIEM legado para a Elastic, a equipe de engenharia de segurança cibernética da Visa construiu seu primeiro fluxo de trabalho de IA agêntica no SOC: um pipeline de quatro estágios que utiliza uma etapa de IA restrita, com intervenção humana, para gerar casos prontos para resposta a incidentes. Para uma detecção de mainframe de alto risco que antes exigia uma segunda consulta manual, o tempo de triagem caiu de 10–20 minutos para segundos, e o mesmo padrão controlado e auditável agora é reutilizável em outras detecções.
Resumo
A Visa está migrando de um SIEM legado para a Elastic e, durante essa migração, a equipe de engenharia de segurança cibernética construiu seu primeiro pipeline do Elastic Workflows como prova de conceito. A detecção escolhida, uma detecção de identidade de mainframe de alto risco, anteriormente exigia que os analistas mudassem do alerta para um buscar de acompanhamento para identificar o usuário responsável, com resultados que variavam significativamente conforme a experiência dos analistas com log de mainframe. A equipe encadeou duas consultas Elasticsearch (linguagem de consulta) (ES|QL), adicionou uma etapa de IA restrita que produz um resumo estruturado para a equipe de RI e usou um webhook para entregar o caso diretamente ao sistema de chamados de IR. Quando o alerta é acionado, a triagem agora é concluída em segundos, em vez de 10 a 20 minutos, e o mesmo padrão de quatro estágios agora está pronto para ser aplicado em outras detecções.
Quando o alerta é apenas o começo do trabalho
A Visa garante um dos maiores ambientes de pagamento do mundo. Como parte de uma modernização mais ampla, de um SIEM legado para a Elastic, a equipe de engenharia de segurança cibernética buscou construir algo que a Visa ainda não tinha em escala: uma forma controlada e defensável de usar IA dentro das operações de segurança. O critério era específico. Qualquer etapa de IA precisava ser auditável, de escopo restrito e comprovadamente ancorada nos dados controlados pela equipe. O primeiro lugar onde esse critério foi testado foi uma detecção de identidade de mainframe de alto risco, onde cada alerta custava à equipe de resposta a incidentes de 10 a 20 minutos de coleta manual de contexto antes mesmo de a investigação começar.
Quando essa detecção foi acionada no SIEM antigo, a equipe de resposta a incidentes precisou fazer log, executar uma segunda busca e descobrir qual usuário estava por trás da atividade. A detecção identificou o evento. O analista ainda precisava identificar a pessoa.
"O alerta acontecia. A equipe de RI recebia o alerta e tinha que fazer login no sistema legado e executar uma segunda busca. Analisar os dados. Certificar-se de que eles encontrem o terminal correto para o usuário. Mas não sabemos quem realmente tinha feito isso. Então tínhamos que executar e buscar pela segunda vez, descobrir quem foi a última pessoa a estar naquele terminal, e então essa pessoa iria para a equipe do mainframe. Tudo isso consumia muito tempo."
A estrutura da equipe foi simples: se todo alerta acionável precisar de uma segunda consulta antes que a equipe de RI possa agir, o pipeline fica incompleto. Mova a segunda consulta para o pipeline em si, e a equipe de RI receberá um caso que já está enriquecido, resumido e pronto para ser entregue à equipe de mainframe. para análise.
Como a Visa chegou aqui: uma migração com espaço para ser criativa
O projeto mais amplo da Visa é a migração da lógica de detecção de um SIEM legado para a Elastic. Esse tipo de migração tende a ser uma conversão focada de regras. A equipe reservou espaço deliberado para que os engenheiros experimentassem novos recursos da plataforma junto com o trabalho de conversão.
"Agora, com a Elastic, aprendemos que podemos ir ainda mais longe. O limite técnico, eu nem tinha considerado antes. Desde que vimos o que a ferramenta pode oferecer, uma pessoa pode ser criativa e ter ideias, como melhorar nossos processos, como podemos ser mais eficientes.
Um engenheiro de segurança cibernética da equipe fez um treinamento do Elastic Workflows, escolheu uma detecção que já conhecia bem e trabalhou com o arquiteto de solutions da Elastic para construir a primeira versão. A equipe da Elastic gerou dados de teste representativos a partir de amostras fornecidas pelo engenheiro, criou um fluxo de trabalho inicial do zero e o devolveu como um modelo que o engenheiro poderia ampliar.
O que as abordagens existentes não podiam oferecer era automação nativa que vivesse dentro da mesma plataforma de segurança dos dados. Na Visa, a orquestração no estilo SOAR é propriedade de uma equipe de automação separada e é executada em uma plataforma separada das próprias detecções. Com o Elastic Workflows, todo o pipeline é executado em um só lugar: detecção, enriquecimento, validação e entrega, tudo nativo, tudo em um arquivo YAML que o engenheiro pode ler e editar em uma tela.
O Workflows também foi o ponto de partida certo por um motivo específico. A Visa precisava de controle total sobre o que a etapa de IA recebia, o que produzia e como cada decisão poderia ser verificada. Para um ambiente de serviços financeiros regulados, essa auditabilidade é prerequisito para confiar na IA nas operações de segurança. O Workflows deu à equipe um padrão que podiam quantificar e defender plenamente, com cada etapa visível em um único arquivo YAML, antes de se estenderem para outras capacidades de agente no roadmap da Elastic.
Antes: alerta, depois a segunda buscar, depois a transferência.
No fluxo de trabalho anterior, a sequência era alertar e depois investigar. A detecção disparou. A equipe de RI se conectou ao SIEM legado. Eles executaram a busca subsequente para mapear o evento de volta a um terminal e a um usuário. Logs de mainframe não são um ambiente implacável para esse tipo de trabalho.
Três fatores encareceram o estado anterior:
- A segunda busca foi inevitável. Apenas uma pessoa pode ser atribuída a um terminal por vez, mas os valores do terminal são reutilizados. Para identificar o usuário por trás de um evento sinalizado, um analista precisava consultar o login anterior mais próximo desse terminal, nessa partição de mainframe, na época do evento.
- A habilidade do analista era extremamente importante. Analistas experientes que conheciam a linguagem de consulta e os códigos de eventos do mainframe podiam fazer isso rapidamente. Analistas mais novos, ou menos familiarizados com logs de mainframe, demoravam visivelmente mais. O resultado foi variação tanto no tempo quanto na qualidade.
- Códigos de eventos do mainframe são complicados. Não existe um único caminho para mapear um evento para um resultado. Os analistas geralmente precisavam interpretar códigos de sistema cujo significado dependia do contexto, o que atrasava o trabalho e dificultava a padronização do resultado.
Tanto o tempo quanto a qualidade foram destinados ao segundo busca. A detecção havia identificado o evento; o analista ainda estava fazendo a investigação que deveria ter feito parte da saída da detecção.
Arquitetura: um pipeline de 4 estágios executado a cada 5 minutos
O novo pipeline executa em quatro etapas encadeadas dentro do Elastic Workflows:
- Detecção (consulta ES|QL primária): em um intervalo de cinco minutos com uma janela de retrospectiva de dez minutos, o fluxo de trabalho executa uma consulta ES|QL rápida e restrita nos logs do mainframe, procurando pela atividade de identidade alvo. A detecção é intencionalmente precisa; a equipe não espera mais do que um ou dois acertos por executar e, historicamente, o alerta é acionado apenas algumas vezes por ano.
- Enriquecimento (consulta ES|QL secundária): para cada evento retornado, o fluxo de trabalho executa uma consulta ES|QL subsequente que utiliza o valor do terminal e a LPAR (partição do mainframe) do evento primário e, em seguida, busca o login anterior mais próximo desse terminal. Como terminais são reutilizados, mas apenas um usuário é designado por vez, o login anterior mais próximo identifica o usuário responsável pela atividade. A verificação é rápida porque as mesmas consultas que produziram o resultado estão disponíveis para o engenheiro inspecionar.
- Validação por IA: o evento enriquecido é passado para uma etapa baseada em um modelo de linguagem de grande porte (LLM). O modelo recebe um prompt restrito: a suposição de que apenas uma pessoa pode usar um terminal por vez, os detalhes do alerta principal e o resultado da consulta secundária. Seu trabalho é verificar se os dados apoiam a conclusão e produzir um resumo estruturado que inclua o nome e o ID do usuário, o que o alerta original detectou e por que essa pessoa é o ator identificado. O modelo não decide se deve escalar; a equipe de RI decide.
- Entrega (webhook): o resumo é entregue via webhook ao sistema de emissão de tickets de RI. Quando o ticket é criado, o engenheiro de RI está analisando um caso, não elaborando um.
A escolha arquitetônica que mais importa aqui é que todo o pipeline executar nativamente dentro da mesma plataforma que os dados de segurança. Não há SOAR ao lado, nenhum sistema de orquestração separado para manter, e não há conector entre a detecção e o fluxo de trabalho.
Destaques técnicos
- A consulta ES|QL primária em um temporizador de cinco minutos com uma janela de recuo de dez minutos
- A consulta ES|QL secundária pega terminal e LPAR do evento primário e encontra o login anterior mais próximo
- Detecção escolhida pelo alto custo de análise da segunda etapa manual de consulta que antes exigia
- A etapa de validação apoiada por LLM recebe um prompt estruturado e restrito, não uma análise livre
- Janelas de contexto: apenas os últimos 5–15 minutos de registros relevantes são passados ao modelo, reduzindo tokens enviados e apertando o contexto de trabalho do modelo
- A Visa está migrando entre provedores e a plataforma é independente do modelo
- O Workflows é um único arquivo YAML criado e testado em uma única tela do Kibana, como um editor de código
- O webhook entrega o resumo estruturado diretamente no sistema de tickets IR
As capacidades
Detecção e enriquecimento ES|QL encadeados em um único fluxo de trabalho
Tratar a detecção e o enriquecimento como um fluxo em cadeia único, em vez de dois passos mediados por analistas, foi o que tornou possível o restante do pipeline. O modelo encadeado do ES|QL permite que a equipe expresse o fluxo de forma declarativa: a consulta primária identifica o evento sinalizado, e a consulta secundária adiciona o mapeamento de terminal para usuário que determina quem provavelmente fez isso. Não há sessão de console de analistas entre eles, e não há uma segunda ferramenta para fazer log. A estrutura do fluxo de trabalho agora corresponde à estrutura da pergunta real do analista (quem fez isso?) em vez de parar em algo aconteceu?
Um passo de IA com escopo deliberadamente restrito
A etapa de IA está realizando um trabalho específico: confirmar que os dados de enriquecimento é compatível com a conclusão e produzir um resumo estruturado que a equipe de RI pode ler em alguns segundos. Ela não gera lógica de detecção. Ela não decide se deve encaminhar. Recebe-se o pressuposto que ancora a análise (apenas uma pessoa pode usar um terminal de cada vez) e o login anterior mais próximo para avaliar esse pressuposto.
"Antes, a equipe de RI precisava fazer login em outra ferramenta e executar outras buscas. Agora, eles só recebem o alerta com todos os dados disponíveis. Tudo é resumido para eles de forma muito clara.
Essa estreiteza é o ponto. A escolha da equipe não foi "deixar o modelo investigar", mas "deixar o modelo verificar e resumir o que as consultas já retornaram." Cada decisão de IA no pipeline está avaliando dados que a equipe pode ver e contra critérios que a equipe controla. Isso é o que torna a validação auditável, e não opaca.
Janelas de contexto eficientes em tokens
O modelo nunca recebe mais dados do que o necessário. O pipeline filtra os registros passados para incluir somente aqueles relevantes para a janela de tempo do evento, nos últimos 5 a 15 minutos, conforme o enquadramento da detecção. O resultado é uma janela de contexto menor, menos tokens por decisão e um raciocínio mais focado, porque o modelo não está tentando interpretar registros que não têm nada a ver com a pergunta.
Automação nativa na plataforma de segurança
Todo o pipeline está na Elastic, junto com os dados. Não há uma plataforma de orquestração separada para manter, nenhuma integração frágil para se manter operacional durante um incidente e nenhuma segunda equipe com a qual coordenar o fluxo de trabalho. Fluxos de trabalho criados em YAML podem chamar outros sistemas via HTTP, então o alcance da plataforma se estende sem abrir mão do ambiente nativo. Especificamente para a Visa, isso é consequente. Uma equipe separada de automação atualmente é responsável pela orquestração no estilo SOAR em uma plataforma diferente dos dados de segurança. Essa equipe já solicitou acesso à API da Elastic, e a equipe de engenharia de segurança cibernética está aberta a usar fluxos de trabalho para absorver o trabalho de resposta que atualmente está na outra ferramenta. O argumento para consolidar em uma única plataforma nativa de automação já não é teórico dentro da Visa.
Padronização onde a expertise dos analistas variou
O resultado mais visível é a velocidade, mas o resultado operacionalmente importante é a consistência. Antes, a interpretação de log do mainframe era uma das partes mais variáveis da triagem na Visa: um analista experiente conseguia concluir rapidamente o trabalho da segunda consulta; um analista mais novo, ou menos familiarizado com os códigos de eventos do mainframe, levava significativamente mais tempo e produzia resultados mais variáveis.
"Analistas mais experientes, que eram proficientes na linguagem de consultas legada, poderiam encontrar a resposta rapidamente. Para alguém mais novo, isso pode ser difícil. Geralmente, eles não conhecem tão bem o log do mainframe. Eles são apenas diferentes. É aí que surgem diferenças de qualidade, e é aí que achei que a parte da IA seria realmente valiosa. Isso pode esclarecer as coisas rapidamente para eles."
Ao empurrar a montagem e o resumo para o pipeline, a parte do fluxo de trabalho que dependia da proficiência do analista em linguagens de consulta legadas e códigos de eventos do mainframe deixa de ser função do analista. O engenheiro de RI lê um resumo estruturado e exerce julgamento sobre se deve agir ou não.
O modelo operacional na prática
A detecção em si é acionada raramente, historicamente apenas algumas vezes por ano. Isso é intencional. A equipe o escolheu justamente porque é um alerta de baixo volume e alto risco, em que claramente valia a pena eliminar o custo por acionamento da etapa manual da segunda consulta. O ponto principal é que este é o primeiro fluxo de trabalho de produção desse tipo da Visa, e o padrão de quatro estágios estabelecido agora está pronto para ser aplicado em outras detecções.
"O que antes exigia de 10 a 20 minutos de esforço de analista por incêndio agora se completa em segundos." A equipe de RI não está mais recebendo um sinal bruto que exija o início da investigação. Eles estão recebendo um alerta totalmente contextualizado e pronto para tomada de decisão."
O que um engenheiro de RI da Visa agora vê quando esse alerta dispara: um ticket com o evento original, o usuário identificado, nomeado e identificado por ID, o raciocínio e o link de volta para os dados subjacentes. O pipeline fez a segunda consulta, o LLM verificou e resumiu, e o webhook criou o ticket. A primeira ação do engenheiro é a avaliação, não a construção da consulta.
O humano ainda é o tomador de decisão. O pipeline faz a montagem. A IA faz a verificação e o resumo. O engenheiro faz o que só ele pode fazer: julgar, verificar e escalar. O trabalho que é transferido para etapas anteriores é o que era repetível. O trabalho que permanece com o engenheiro é aquele que exige julgamento.
Antes e depois
| Antes | Depois | |
|---|---|---|
| Gestão de alertas | Evento não processado que requer uma busca de acompanhamento para identificar o usuário | Chamado enriquecido e resumido por IA chega ao RI pronto para decisão |
| Esforço operacional | 10–20 minutos por execução na segunda busca e interpretação do log do mainframe | Segundos, de ponta a ponta |
| Fluxo de investigação | Alerta e, em seguida, uma segunda consulta em uma ferramenta separada. | Detecção, enriquecimento, validação e entrega em um único fluxo de trabalho encadeado |
| Dependência de habilidade do analista | Analistas experientes podiam agir rápido; analistas mais novos eram desacelerados pela linguagem de consulta legada e pelos códigos de eventos do mainframe | O resumo estruturado elimina a dependência de proficiência em linguagens de consulta legadas. |
| Limites de ferramentas | Alerta no SIEM legado, acompanhamento no SIEM legado, ticket em uma ferramenta de orquestração separada | Detecção, enriquecimento, validação e entrega, tudo nativo da Elastic, com transferência por webhook para o sistema de tickets RI |
| Função de analista | Montagem manual de contexto, execução da segunda buscar, interpretação do log do mainframe | Ler o caso estruturado, julgar o resultado, escalar |
O que o padrão de 4 estágios ensina
O motivo de este ser o primeiro, mas não o último, projeto da Visa no Workflows é que o formato de quatro etapas é portátil. A detecção específica é incomum; o padrão operacional em torno dele não é. Em qualquer lugar em que uma detecção exija buscar de acompanhamento conhecida e repetível antes que um analista possa agir, as mesmas quatro etapas se aplicam.
"É uma parte conhecida do manual deles. O pipeline pode simplesmente fazer esses primeiros passos e eliminá-los do que a equipe de RI precisa investigar.
Três princípios transferidos desta construção se aplicam a qualquer detecção onde a segunda consulta seja o gargalo. Automatize as partes conhecidas do runbook no próprio pipeline, porque se o acompanhamento sempre executa da mesma forma, não é trabalho de analista. Dê à etapa de IA uma tarefa restrita o suficiente para ser auditável: um prompt restrito, uma entrada estruturada, um resumo que o engenheiro possa verificar com base nos dados. Limite o contexto para que o modelo receba apenas o que é relevante para o momento do evento, em vez dos dados completos retornados pelas consultas. O primeiro princípio é o mais generalizável. Os outros dois são o que mantém a IA defensável.
O que vem depois
O padrão de quatro estágios (detecção, enriquecimento, validação, entrega) é portátil. A equipe já identificou outras detecções no escopo da migração que se beneficiariam da mesma abordagem encadeada, resumida por IA e entregue por webhook. A equipe está avaliando ativamente o Attack Discovery, que Martin descreve como a capacidade que os atraiu para a Elastic em primeiro lugar. O sequenciamento foi deliberado: os fluxos de trabalho deram à Visa um padrão que pôde quantificar e verificar completamente antes de ampliar as capacidades com mais lógica de correlação rodando internamente, que é o caminho certo para um SOC regulado de serviços financeiros. A equipe está paralelamente criando um agente de IA para caça a ameaças e está analisando como os fluxos de trabalho podem absorver o trabalho de resposta atualmente realizado por um grupo de automação separado. Acompanhar o ritmo de liberação da Elastic também faz parte do trabalho agora.
"Vocês continuam lançando mais e mais coisas novas, e estão me distraindo de tudo isso."
"A Descoberta de Ataques provavelmente está no topo da nossa lista. O motivo pelo qual nos apaixonamos pela Elastic não foram os fluxos de trabalho, foi a parte da Descoberta de Ataques. Estamos tentando divulgar essa ferramenta como um SIEM com foco em IA e evangelizar a Elastic para muitos grupos dentro do setor cibernético da Visa.
A Visa é uma das maiores redes de pagamentos do mundo, e o redimensionar de suas operações de segurança reflete isso. Sua organização pode não estar migrando na escala da Visa hoje, mas os mesmos princípios se aplicam, quer você esteja convertendo sua primeira detecção ou reconstruindo um SOC completo: se o alerta exigir uma segunda consulta antes que uma ação possa ser tomada, o pipeline está incompleto, e o padrão de quatro estágios funciona em todos os níveis da escala.
Veja como o Elastic Workflows permite que você incorpore a investigação ao seu pipeline de detecção.