Como parte de una modernización más amplia de sus operaciones de seguridad, que pasa de un SIEM heredado a Elastic, el equipo de ingeniería de ciberseguridad de Visa creó su primer flujo de trabajo de IA agéntica en el SOC: un pipeline de cuatro etapas que emplea un paso de IA restringido y con intervención humana para producir casos listos para IR. Para una detección de mainframe de alto riesgo que antes requería una segunda búsqueda manual, el tiempo de clasificación bajó de 10-20 minutos a segundos, y el mismo patrón controlado y auditable ahora es reutilizable en otras detecciones.
Resumen
Visa está migrando de un SIEM heredado a Elastic, y durante esa migración, el equipo de ingeniería de ciberseguridad construyó su primer pipeline de Elastic Workflows como prueba de concepto. La detección elegida, una detección de identidad de mainframe de alto riesgo, requería anteriormente que los analistas cambiaran de la alerta a una búsqueda de seguimiento para identificar al usuario responsable, con resultados que variaban significativamente según la experiencia del analista con los log del mainframe. El equipo encadenó dos consultas de lenguaje de búsqueda de Elasticsearch (ES|QL), agregó un paso de IA restringido que produce un resumen estructurado para el equipo de IR y usó un webhook para entregar el caso directamente en su sistema de tickets de IR. Cuando se activa la alerta, el triaje se completa en segundos en lugar de 10 a 20 minutos, y el mismo patrón de cuatro etapas está listo para aplicar en otras detecciones.
Cuando la alerta es solo el comienzo del trabajo
Visa asegura uno de los entornos de pagos más grandes del mundo. Como parte de una modernización más amplia, que pasa de un SIEM heredado a Elastic, el equipo de ingeniería de ciberseguridad se propuso crear algo que Visa aún no tenía y que pudiera escalar: una forma controlada y defendible de usar IA dentro de las operaciones de seguridad. La barra era específica. Cualquier paso de IA tenía que ser auditable, de alcance limitado y estar anclado de forma verificable en los datos controlados por el equipo. El primer lugar donde se probó la barra fue en una detección de identidad de mainframe de alto riesgo donde cada alerta le costaba al equipo de respuesta a incidentes de 10 a 20 minutos de recopilación manual de contexto antes de que pudiera comenzar la investigación.
Cuando esa detección se activó en el SIEM heredado, el equipo de respuesta a incidentes tenía que iniciar sesión, ejecutar una segunda búsqueda y averiguar qué usuario estaba detrás de la actividad. La detección identificó el evento. El analista aún tenía que identificar a la persona.
"La alerta tendría lugar. El equipo de IR obtendría la alerta y tendrían que iniciar sesión en el sistema heredado y ejecutar una segunda búsqueda. Revisa los datos. Asegúrate de que encuentren el terminal correcto para el usuario. Pero no sabemos quién lo hizo realmente. Así que tienes que ejecutar la segunda búsqueda, averiguar quién fue la última persona en estar en esa terminal y luego van al equipo de mainframe. Todo eso fue más bien una pérdida de tiempo".
El encuadre del equipo fue simple: si cada alerta procesable necesita una segunda búsqueda antes de que el equipo de IR pueda actuar, el pipeline está incompleto. Mueve la segunda búsqueda hacia arriba, dentro del pipeline mismo, y el equipo de IR obtiene un caso que ya está enriquecido, resumido y listo para entregar al equipo de mainframe para revisión.
Cómo llegó Visa hasta aquí: una migración con espacio para la creatividad
El proyecto más amplio de Visa es la migración de la lógica de detección de un SIEM heredado a Elastic. Ese tipo de migración tiende a ser una conversión de reglas concentrada. El equipo dejó espacio deliberadamente para que los ingenieros probaran nuevas funcionalidades de la Platform en paralelo al trabajo de conversión.
"Ahora, con Elastic, aprendimos que podemos ir aún más lejos. Ni siquiera consideraba el límite técnico antes. Desde que vimos lo que la herramienta puede ofrecer, se puede ser creativo y generar ideas sobre cómo mejorar nuestros procesos y cómo podemos ser más eficientes."
Un ingeniero de ciberseguridad en el equipo tomó el entrenamiento de flujos de trabajo de Elastic, eligió una detección que ya conocía bien y trabajó con su arquitecto de soluciones de Elastic para crear la primera versión. El equipo de Elastic generó datos de prueba representativos a partir de muestras que el ingeniero proporcionó, creó un flujo de trabajo inicial desde cero y la devolvió como una plantilla que el ingeniero podría ampliar.
Lo que los enfoques existentes no podían ofrecer era automatización nativa que conviviera dentro de la misma Platform de seguridad que los datos. En Visa, la orquestación al estilo SOAR es propiedad de un equipo de automatización separado y se ejecuta en una Platform distinta a las propias detecciones. Con los flujos de trabajo de Elastic, todo el pipeline se ejecuta en un solo lugar: detección, enriquecimiento, validación y entrega, todo nativo, todo en un archivo YAML que el ingeniero puede leer y editar en una sola pantalla.
El flujo de trabajo también fue el punto de partida adecuado por una razón concreta. Visa necesitaba un control completo sobre lo que el paso de la IA recibía, lo que producía y cómo se podía verificar cada decisión. Para un entorno de servicios financieros regulados, esa auditabilidad es el requisito previo para confiar en la IA en las operaciones de seguridad. Los flujos de trabajo le dieron al equipo un patrón que podían cuantificar y defender completamente, con cada paso visible en un solo archivo YAML, antes de extenderse a otras capacidades agénticas en el roadmap de Elastic.
Antes: alerta, segunda búsqueda y luego entrega
En el flujo de trabajo anterior, la secuencia fue alerta, luego investigación. La detección se activó. El equipo de IR inició sesión en el SIEM heredado. Ejecutaron la búsqueda de seguimiento para mapear el evento con un terminal y un usuario. Los log de mainframe no son un entorno permisivo para ese trabajo.
Tres cosas encarecieron el estado anterior:
- La segunda búsqueda era inevitable. Solo se puede asignar una persona a un terminal a la vez, pero los valores del terminal se reutilizan. Para identificar al usuario detrás de un evento marcado, un analista tenía que buscar el inicio de sesión anterior más cercano a ese terminal, en esa partición del mainframe, alrededor del momento del evento.
- La habilidad del analista era muy importante. Los analistas experimentados que conocían el lenguaje de búsqueda y los códigos de eventos del mainframe podrían hacerlo rápidamente. Los analistas más nuevos, o los menos familiarizados con los log de mainframe, tardaban notablemente más. El resultado fue una variación tanto en tiempo como en calidad.
- Los códigos de eventos de mainframe son complicados. No existe un único camino para relacionar un evento con un resultado. Los analistas a menudo tenían que interpretar códigos del sistema cuyo significado dependía del contexto, lo que ralentizaba el trabajo y dificultaba la estandarización del resultado.
Tanto el tiempo como la calidad se destinaban a la segunda búsqueda. La detección había identificado el evento; el analista seguía haciendo la investigación que debería haber sido parte de la salida de la detección.
Arquitectura: una pipeline de 4 etapas que funciona con un programa de 5 minutos
La nueva pipeline se ejecuta en cuatro etapas encadenadas dentro de Elastic Workflows:
- Detección (búsqueda ES|QL primaria): en un temporizador de cinco minutos con una ventana retrospectiva de diez minutos, el flujo de trabajo ejecuta una consulta ES|QL rápida y estrecha en los log del mainframe y busca la actividad de identidad específica. La detección es intencionalmente precisa; el equipo no espera más de una o dos detección por ejecutar e, históricamente, la alerta se activa solo unas pocas veces al año.
- Enriquecimiento (búsqueda ES|QL secundaria): para cada evento devuelto, el flujo de trabajo ejecuta una consulta ES|QL de seguimiento que toma el valor del terminal y el LPAR (partición de mainframe) del evento principal y luego realiza una búsqueda del inicio de sesión anterior más cercano a ese terminal. Como los terminales se reutilizan pero solo se asigna un usuario a la vez, el inicio de sesión previo más cercano identifica al usuario detrás de la actividad. La verificación es rápida porque las mismas consultas que produjeron el resultado están ahí para que el ingeniero las inspeccione.
- Validación de IA: el evento enriquecido se pasa a un paso respaldado por un modelo de lenguaje grande (LLM). El modelo recibe una solicitud restringida: la suposición de que solo una persona puede usar una terminal a la vez, los detalles de la alerta principal y el resultado de la búsqueda secundaria. Su función es verificar que los datos respalden la conclusión y producir un resumen estructurado que incluya el nombre y el ID del usuario, lo que detectó la alerta original y por qué esta persona es el actor identificado. El modelo no decide escalar; el equipo de IR sí lo hace.
- Entrega (webhook): el resumen se entrega vía webhook al sistema de tickets de IR. Para cuando se crea el ticket, el ingeniero de IR está leyendo un caso, no armando uno.
La elección arquitectónica que más importa aquí es que todo el pipeline se ejecute de forma nativa dentro de la misma Platform que los datos de seguridad. No hay un SOAR aparte, no hay un sistema de orquestación separado que mantener y no hay un conector entre la detección y el flujo de trabajo.
Aspectos técnicos destacados
- Búsqueda principal de ES|QL en un temporizador de cinco minutos con un periodo de revisión de diez minutos
- ES|La búsqueda secundaria QL toma terminal y LPAR del evento principal y encuentra el inicio de sesión previo más cercano
- Es una detección elegida por el alto costo para el analista del paso manual de segunda búsqueda que antes se requería
- El paso de validación respaldado por LLM recibe un aviso restringido y estructurado, no un análisis de forma libre
- Ventana de contexto: solo los últimos 5–15 minutos de registros relevantes se pasan al modelo, lo que reduce los tokens enviados y ajusta el contexto de trabajo del modelo
- Visa se mueve entre proveedores y la Platform es independiente del modelo
- El flujo de trabajo es un único archivo YAML creado y probado en una pantalla de Kibana, como un editor de código
- Webhook entrega el resumen estructurado directamente en el sistema de tickets IR
Las capacidades
Detección y enriquecimiento de ES|QL encadenados en un solo flujo de trabajo
Tratar la detección y el enriquecimiento como un flujo encadenado, en lugar de dos pasos mediados por analistas, es lo que hizo posible el resto del pipeline. El modelo encadenado de ES|QL permite al equipo expresar el flujo de manera declarativa: la búsqueda principal identifica el evento marcado y la búsqueda secundaria incluye el mapping de terminal a usuario que determina quién probablemente lo hizo. No hay ninguna sesión intermedia en la consola del analista, ni tampoco una segunda herramienta en la que iniciar sesión. La estructura del flujo de trabajo ahora coincide con la estructura de la pregunta real del analista (¿quién hizo esto?) en lugar de detenerse en ¿sucedió algo?
Un paso de IA limitado con alcance deliberadamente estrecho
El paso de IA es hacer un trabajo específico: confirmar que los datos de enriquecimiento respaldan la conclusión y producir un resumen estructurado que el equipo de IR pueda leer en unos segundos. No genera lógica de detección. No decide si escalar o no. Se le indica la suposición que ancla el análisis (solo una persona puede usar un terminal a la vez) y se proporciona el inicio de sesión previo más cercano para evaluar esa suposición.
"Antes, el equipo de IR tenía que iniciar sesión en otra herramienta y ejecutar otra búsqueda". Ahora simplemente reciben la alerta con todos los datos disponibles. Tienen todo resumido de una manera muy clara y concisa".
Esa estrechez es el punto. La elección del equipo no fue "dejar que el modelo investigue" sino "dejar que el modelo verifique y resuma lo que las búsquedas ya devolvieron". Cada decisión de IA en el pipeline evalúa los datos que el equipo puede ver y los criterios que controla. Eso es lo que hace que la validación sea auditable en lugar de opaca.
Ventana de contexto eficiente en tokens
El modelo nunca ve más datos de los que necesita. El pipeline filtra los registros recibidos para conservar solo aquellos relevantes para la ventana temporal del evento, los últimos 5 a 15 minutos, lo que coincide con el marco de la detección. El resultado es una ventana de contexto más pequeña, menos tokens por decisión y un razonamiento más ajustado, porque el modelo no está intentando interpretar registros que no tienen nada que ver con la pregunta.
Automatización nativa dentro de la plataforma de seguridad
Todo el pipeline vive en Elastic, junto con los datos. No hay una plataforma de orquestación separada que mantener, ni una integración frágil que mantener viva durante un incidente, ni un segundo equipo con el que coordinar el flujo de trabajo. Los flujos de trabajo creados en YAML pueden llamar a otros sistemas vía HTTP, por lo que el alcance de la Platform se extiende sin renunciar al hogar nativo. En el caso específico de Visa, esto tiene consecuencias importantes. Un equipo de automatización separado actualmente gestiona la orquestación de estilo SOAR en una plataforma diferente a la de los datos de seguridad. Ese equipo ya ha solicitado acceso a la API de Elastic y el equipo de ingeniería de ciberseguridad está abierto a usar flujos de trabajo para absorber el trabajo de respuesta que actualmente se encuentra en la otra herramienta. En Visa, la idea de consolidar la automatización en una única plataforma nativa ya no es teórica.
Estandarización donde la experiencia de los analistas varía
El resultado más visible es la velocidad, pero lo que realmente importa operativamente es la consistencia. La interpretación de los log de mainframe era anteriormente una de las partes más variables de la clasificación en Visa: un analista experimentado podía terminar rápidamente el trabajo de la segunda búsqueda; un analista más nuevo, o uno menos familiarizado con los códigos de eventos de mainframe, tardaba considerablemente más y producía resultados más variables.
"Los analistas más experimentados y competentes en el lenguaje de búsqueda heredado podrían encontrar la respuesta rápido". Cualquiera persona que sea más nueva tendría dificultades. Generalmente no están tan familiarizados con los log del mainframe. Simplemente son diferentes. Alí es donde se notan las diferencias en calidad y pensé que la parte de IA sería realmente valiosa. Podría aclararles las cosas rápidamente".
Al introducir el ensamblado y el resumen en el pipeline, la parte del flujo de trabajo que dependía del dominio de los analistas en lenguajes de búsqueda heredados y códigos de eventos de mainframe ya no es tarea del analista. El ingeniero de IR lee un resumen estructurado y ejerce su juicio sobre si actuar o no.
El modelo operativo en la práctica
La detección en sí se activa raramente, históricamente solo unas pocas veces al año. Eso es intencional. El equipo lo eligió precisamente porque se trata de una alerta de bajo volumen y alto riesgo, en la que el costo por alerta del paso manual de segunda búsqueda claramente valía la pena eliminar. La historia más importante es que este es el primer flujo de trabajo de producción de Visa de su tipo y el patrón de cuatro etapas que estableció ahora está listo para aplicarse en otras detecciones.
"Lo que antes requería entre 10 y 20 minutos de esfuerzo de analista por incendio ahora se completa en segundos. El equipo de IR ya no recibe una señal sin procesar que requiera iniciar una investigación. Están recibiendo una alerta completamente contextualizada que está lista para la toma de decisiones".
Lo que un ingeniero de IR en Visa ve ahora cuando se activa esta alerta es: un ticket con el evento original, el usuario identificado, nombrado e identificado por ID, el razonamiento y el enlace de vuelta a los datos subyacentes. La pipeline hizo la segunda consulta, el LLM verificó y resumió, y el webhook creó el ticket. La primera acción del ingeniero es la evaluación, no la construcción de la búsqueda.
El humano sigue siendo quien toma las decisiones. El pipeline se encarga del ensamblaje. La IA realiza la verificación y el resumen. El ingeniero hace lo que solo el ingeniero puede hacer: juzgar, verificar y escalar. El trabajo que se traslada a una etapa previa es el trabajo que era repetible. El trabajo que permanece con el ingeniero es el que requiere juicio.
Antes y después
| Antes | Después | |
|---|---|---|
| Gestión de alertas | Evento sin procesar que requiere una búsqueda de seguimiento para identificar al usuario | El ticket enriquecido y resumido por IA llega a IR listo para decisión |
| Esfuerzo operativo | 10-20 minutos por disparo en la segunda búsqueda e interpretación de logs de mainframe | Segundos, de extremo a extremo |
| Flujo de investigación | Alerta, luego la segunda consulta en una herramienta separada | Detección, enriquecimiento, validación y entrega en un único flujo de trabajo encadenado |
| Dependencia de habilidades del analista | Los analistas experimentados podían moverse rápido; los analistas más nuevos se ralentizaban por el lenguaje de búsqueda heredado y los códigos de eventos de mainframe | El resumen estructurado elimina la dependencia de la competencia en los lenguaje de búsqueda heredados |
| Límites de herramientas | Alerta en SIEM heredado, seguimiento en SIEM heredado, ticket en una herramienta de orquestación separada | Detección, enriquecimiento, validación y entrega, todo nativo de Elastic, con transferencia por webhook al sistema de tiquetes IR |
| Rol de analista | Ensamblado manual de contexto, ejecución de segunda búsqueda, interpretación de logs de mainframe | Leer el caso estructurado, juzgar el resultado, escalar |
Lo que enseña el patrón de cuatro etapas
La razón por la que este es el primer proyecto de flujos de trabajo de Visa, pero no el último, es que la forma de cuatro etapas es portable. La detección específica es inusual; el patrón operativo que lo rodea no lo es. En cualquier lugar donde una detección requiera una búsqueda conocida y repetible antes de que un analista pueda actuar, se aplican las mismas cuatro etapas.
"Es una parte conocida de su libro de jugadas. El pipeline puede hacer esos primeros pasos y eliminarlos de lo que el equipo de IR tiene que investigar".
Tres principios transferidos de esta compilación se aplican a cualquier detección en la que la segunda búsqueda sea el cuello de botella. Automatiza las partes conocidas del runbook en el propio pipeline, porque si el seguimiento siempre se ejecuta de la misma manera, no es trabajo de analista. Asigna al paso de IA un trabajo lo suficientemente estrecho como para que sea auditable: un prompt restringido, una entrada estructurada, un resumen que el ingeniero pueda verificar con los datos. Limita el contexto, para que el modelo reciba solo lo que es relevante para la hora del evento en lugar de los datos completos que devolvieron las búsquedas. El primer principio es el más generalizable. Las otras dos son las que hacen que la IA sea defendible.
Lo que viene después
El patrón de cuatro etapas (detección, enriquecimiento, validación, entrega) es portátil. El equipo ya ha identificado otras detecciones en el alcance de la migración que se beneficiarían del mismo enfoque encadenado, resumido por IA y entregado por webhook. El equipo está evaluando activamente Attack Discovery, que Martin describe como la capacidad que les atrajo a Elastic en primer lugar. La secuenciación fue deliberada: los flujos de trabajo le dieron a Visa un patrón que pudo cuantificar y verificar completamente antes de extender a capacidades con más lógica de correlación que funcionan internamente, que es el camino correcto para un SOC regulado de servicios financieros. El equipo está construyendo un agente de IA de forma paralela para la búsqueda de amenazas y está evaluando cómo los flujos de trabajo pueden absorber el trabajo de respuesta que actualmente maneja un grupo de automatización separado. Mantenerse al día con el ritmo de lanzamientos de Elastic ahora también es parte del trabajo.
"Ustedes siguen lanzando más y más cosas nuevas, y me están distrayendo de todo esto."
"Attack Discovery probablemente esté en la parte superior de nuestra lista. La razón por la que nos enamoramos de Elastic no fueron los flujos de trabajo, sino la pieza de Attack Discovery. Estamos tratando de comercializar esta herramienta como un SIEM con IA como prioridad y de evangelizar Elastic a muchos grupos dentro del área de ciberseguridad en Visa".
Visa es una de las redes de pagos más grandes del mundo y el escalar sus operaciones de seguridad lo refleja. Es posible que tu organización no esté migrando a la escalar de Visa en la actualidad, pero los mismos principios se aplican tanto si estás convirtiendo tu primera detección como si estás reconstruyendo un SOC completo: si la alerta requiere una segunda búsqueda antes de que se pueda actuar, el pipeline está incompleto y el patrón de cuatro etapas funciona en cada paso de la escalar.
Ve cómo los flujos de trabajo de Elastic te permite mover la investigación hacia una etapa previa en tu pipeline de detección.