Elastic Workflows está generalmente disponible en la versión 9.4. Es la capa de automatización integrada directamente en Elastic, que corre donde se encuentran tus datos en Seguridad, Observabilidad y Búsqueda. Aunque esta publicación se centra en una profundización en seguridad, las mismas capacidades de flujo de trabajo se aplican a todas las soluciones, sin una plataforma separada que desplegar ni datos que mover. Cuando se activa una alerta o se activa un calendario, se ejecuta un flujo de trabajo: consulta a Elasticsearch, enriquece con información sobre amenazas, crea casos, llama a APIs externas y notifica a tu equipo. Defínyelo en YAML o descríbelo en lenguaje natural y deja que la IA genere el flujo de trabajo.
La Tech Preview de la 9.3 introdujo la base para la automatización nativa en Elastic. La versión 9.4 lo lleva a disponibilidad general con estabilidad en producción y capacidades significativamente ampliadas. La gestión de casos cuenta con 25 pasos dedicados de automatización que cubren todo el ciclo de vida. El humano en el bucle se convierte en una primitiva de flujo de trabajo de primera clase. La autoría en lenguaje natural pasa a Vista previa Técnica. La plataforma gana más primitivas de control de flujo (while, switch, control de iteraciones), pasos de transformación de datos para trabajar con colecciones, una integración más profunda de IA con Agent Builder y disparadores más amplios y orientados a eventos. Automatización lista para producción en Elastic.
Automatización de casos a gran escala
La mayor novedad para los equipos de seguridad es la gestión de casos. En la Vista Previa Tecnológica, trabajar con los casos implicaba cuatro pasos genéricos: crear, recuperar, actualizar y comentar. Cualquier cosa más allá de eso requería llamadas a API en bruto.
Ahora hay 25 pasos dedicados cases.* que cubren todo el ciclo de vida: crear, encontrar, encontrar similares, actualizar, cerrar, asignar, desasignar, agregar alertas, agregar observables, agregar comentarios, agregar etiquetas, establecer severidad, establecer estado y más. Cada paso está tipeado, validado y aparece en el autocompletado del editor YAML, lo que significa que la autoría en lenguaje natural también puede generarlos con precisión.
Así es como es un flujo de trabajo realista de triaje. Se activa una alerta. El flujo de trabajo comprueba si ya existe un caso para esta alerta. Si no, crea uno, anexa la alerta y los observables, asigna al analista de guardia y enruta la gravedad según el puntaje de riesgo:
El código siguiente muestra un ejemplo de un flujo de trabajo descrito usando 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: trueEl flujo de trabajo gestiona automáticamente la deduplicación, la inserción de evidencias, el enriquecimiento observable, el manejo eficiente de campos faltantes y la asignación de analistas. El analista abre a Kibana y ve un caso con todo el contexto ya presentado.
Los 25 nuevos pasos de cases.* incluyen crear, encontrar, encontrar similares, actualizar, cerrar, eliminar, asignar, desasignar, agregar/eliminar alertas, agregar/eliminar observables, agregar/actualizar/eliminar comentarios, agregar/eliminar etiquetas, establecer severidad, establecer estado, obtener por ID, obtener por ID de alerta y más para campos personalizados, acciones de usuario y métricas. Cada paso se tipifica y valida. Si usas autoría en lenguaje natural, la IA puede generarlos con precisión porque forman parte del esquema.
A medida que los flujos de trabajo maduren, verás más pasos específicos de dominio para la gestión de reglas de detección, acciones de respuesta de endpoints y operaciones de inteligencia de amenazas.
Puntos de control humanos en flujos de trabajo automatizados
La automatización de casos se encarga del trabajo mecánico, pero no todas las decisiones deben estar completamente automatizadas. La IA puede clasificar una alerta y recopilar contexto, pero el analista debe decidir si escalar. La cuestión es cuánto trabajo mecánico hay antes de que tomen esa decisión.
waitForInput pausa un flujo de trabajo para obtener el juicio humano. El Flujo de Trabajo lleva a cabo la investigación, recopila pruebas, clasifica la alerta con IA y se detiene. Presenta hallazgos estructurados y espera. El analista revisa, aprueba o redirige, agrega notas y luego el flujo de trabajo se reanuda según su aportación.
Como muestra la siguiente imagen, la automatización se encarga de la investigación, pero el analista toma la decisión antes de que la automatización la ejecute.
Clasifica las alertas entrantes con IA, pausa para la revisión y aprobación de los analistas, y solo escala los casos aprobados creando un incidente de alta gravedad con contexto tanto del modelo como del analista.
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-reviewedHoy en día, waitForInput funciona a través de la vista de ejecución Kibana y la API REST. Slack, Teams y canales de entrega de emails están llegando para que los analistas puedan revisar y aprobar sin cambiar de contexto. Esto es especialmente importante para flujos de trabajo definidos como herramientas en Agent Builder, donde las investigaciones impulsadas por agentes se benefician de puntos de control humanos antes de actuar.
Construcción de flujos de trabajo a partir de lenguaje natural
Con los patrones de automatización implementados, el siguiente desafío es hacerlos accesibles. Elegimos YAML como lenguaje de flujo de trabajo porque es declarativo, revisable y portátil. Pero también fue una elección estratégica: YAML es texto estructurado, y los grandes modelos de lenguaje son muy buenos generando texto estructurado. Un esquema de flujo de trabajo bien tipado es un objetivo ideal para la autoría impulsada por IA. En 9.4, esa apuesta da resultado. La autoría en lenguaje natural está disponible en Tech Preview.
Dentro del editor de flujos de trabajo, describe qué debe ocurrir: "Cuando se active una alerta de malware, comprueba el hash del archivo con VirusTotal, crea un caso de alta gravedad, anexa la alerta y los observables, y notifica al canal SOC." El asistente de IA genera el YAML. Revisas, refinas y despliegas.
El YAML es totalmente inspeccionable y editable. Si sabes lo que debería pasar pero no eres experto en YAML, esto te lleva de la intención a un flujo de trabajo funcional. Si eres experto en YAML, puedes empezar en lenguaje natural y refinar en el editor.
La experiencia de creación seguirá evolucionando. La edición visual es un modo complementario. La autoría que se extiende a Slack y otras herramientas que emplea tu equipo. El objetivo es reunir con los equipos de seguridad dondequiera que trabajen.
Flujos de trabajo componibles
A medida que tu biblioteca de automatización crece, la organización se vuelve fundamental. La automatización de seguridad se vuelve complicada rápidamente. Empiezas con un único flujo de trabajo de triaje y luego te das cuenta de que diferentes tipos de alertas necesitan distintos pasos de investigación. Agregas condicionales, luego más condicionales, y de repente tu flujo de trabajo es de cientos de líneas con lógica anidada que es difícil de seguir y más difícil de cambiar.
workflow.execute Te permite crear flujos de trabajo reutilizables con entradas y salidas tipadas. En lugar de integrar toda la lógica de investigación en un solo lugar, creas flujos de trabajo enfocados para escenarios específicos y los compones juntos. Actualiza tu flujo de trabajo de investigación de malware una vez, y cada flujo de trabajo que lo llame se beneficia. La lógica se mantiene organizada, los cambios se mantienen contenidos y tu automatización escala sin volver frágil.
Así es como se ve esto en la práctica. Clasifica la alerta y luego enruta el flujo de trabajo especializado según el tipo de amenaza:
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] }}Cada flujo de trabajo es evaluable de forma independiente. La mayoría de los equipos comienzan con un único flujo de trabajo y extraen subflujos a medida que surgen patrones. La composición es algo en lo que se crece.
La biblioteca de plantillas se trasladará eventualmente al producto para que puedas descubrir e instalar flujos de trabajo predefinidos directamente en Kibana.
Donde ya trabajan los analistas
Los flujos de trabajo son más útiles cuando están disponibles y donde se toman decisiones. Las primitivas y patrones están en su lugar, pero la automatización solo aporta valor si los analistas pueden acceder a ella sin cambiar de herramienta. Estamos invirtiendo en hacer que los flujos de trabajo sean accesibles durante toda la experiencia del analista de seguridad, empezando por la tabla de alertas y el Descubrimiento de Ataques. Los analistas pueden enviar alertas o ataques completos directamente a un flujo de trabajo, activando la lógica de investigación que construyeron sin salir de su contexto actual. Esta integración seguirá expandir para que la automatización de flujos de trabajo se convierta en una parte fluida del trabajo diario del analista, y no en un destino separado.
"Ejecutar flujo de trabajo" en la tabla de alertas te permite hacer clic derecho en una alerta (o seleccionar varias) y activar un flujo de trabajo directamente. El contexto de alerta pasa automáticamente.
Esto es el principio. Los flujos de trabajo seguirán expandir a más partes de la experiencia de seguridad, haciendo que la automatización sea accesible donde los analistas la necesiten.
Más control, más flexibilidad
Más allá de las características principales, el propio lenguaje de flujo de trabajo se volvió más capaz. Las nuevas primitivas de control de flujo te dan formas más limpias de manejar lógica compleja. while bucles te permiten consultar condiciones o esperar a cambios externos de estado. switch proporciona ramificación multivía para que puedas enrutar alertas por categoría sin condiciones anidadas. loop.break y loop.continue te dan control estándar de iteración.
Los pasos de transformación de datos a nivel de pasos gestionan el filtrado, la búsqueda, la agregación y las operaciones JSON en colecciones, por lo que puedes procesar listas de alertas, consultas IOC y respuestas de enriquecimiento sin scripting personalizado.
Los pasos de IA (ai.prompt, ai.classify, ai.summarize, ai.agent) son más estables y ahora soportan salidas estructuradas, facilitando el uso de clasificaciones y resúmenes generados por IA en la lógica de flujo de trabajo posterior.
El plantado de LiquidJS también se expandió. Ahora puedes establecer variables y acceder a ellas a lo largo del flujo de trabajo, facilitando la referencia de valores calculados a lo largo de varios pasos.
Fiabilidad y controles de producción
Todo esto solo es útil si es fiable. Cada paso soporta on-failure configuración: reintentar para fallos transitorios, continuar cuando un paso no es crítico y abortar cuando los pasos posteriores dependen del resultado. Los detalles de los errores están disponibles en steps.<step-id>.error para ayudar a evitar fallos.
Los controles de concurrencia evitan que tormentas de alerta generen cientos de ejecuciones paralelas. Las barandillas de los lazos evitan la ejecución descontrolada. Los límites de profundidad de composición evitan la recursión infinita.
Elastic 9.4 introduce disparadores impulsados por eventos, comenzando por workflows.failed. Cuando la ejecución de un flujo de trabajo falla, puede desencadenar un flujo de trabajo separado para el manejador. Crea un flujo de trabajo de notificaciones que avise a tu equipo cuando la automatización se cae. Llegan más tipos de disparadores: cambios en el estado de los casos, transiciones de estado de alerta y actualizaciones de reglas de detección, haciendo que los flujos de trabajo sean reactivos a lo que ocurre en tu entorno de seguridad.
Cada ejecución se registra en el historial de ejecuciones con resultados paso a paso, incluyendo las decisiones de los analistas de waitForInput pasos. Esta es tu herramienta de depuración y tu historial de auditoría.
Los flujos de trabajo están habilitados por defecto en la 9.4 con una licencia Enterprise. El RBAC granular controla quién crea, edita, ejecuta y visualiza los flujos de trabajo. Cada operación de gestión escribe en el registro de auditoría de seguridad. La importación/exportación mueve flujos de trabajo entre entornos con referencias de conectores intactas.
Licencias y precios
Workflows está disponible con una licencia empresarial en despliegues alojados y autogestionados de Elastic Cloud, y con la categoría Complete en Elastic Cloud Serverless para proyectos de seguridad.
La versión 9.4 introduce un modelo unificado de precios basado en la ejecución para todos los tipos de despliegue.
En Serverless, Elastic Cloud Hosted y autogestionado, los precios se basan en las ejecuciones de flujos de trabajo, con descuentos por volumen a gran escala. Cada mes incluye una asignación base de ejecuciones de flujo de trabajo que no se facturan. El uso que supera esta asignación se factura por ejecución, aplicar descuentos basados en volumen a medida que aumenta el uso.
Elastic Cloud Serverless comienza a aplicar este modelo el 1de mayo de 2026. El uso más allá de las ejecuciones mensuales no facturadas se cobra por ejecución, con descuentos en volúmenes mayores. Consulta los detalles completos de precios.
Los despliegues alojados y autogestionados de Elastic Cloud siguen el mismo modelo de precios, pero actualmente están en un periodo promocional con cargos de ejecución aún no aplicados. Esto permite a los equipos crear y ejecutar flujos de trabajo, establecer patrones de uso y preparar para la transición a la facturación basada en la ejecución en una futura versión.
Empieza a construir ahora. Los flujos de trabajo que crees hoy seguirán funcionando a medida que los precios se adapten al modelo unificado.
Cómo empezar
Los flujos de trabajo están activados por defecto en la versión 9.4. Abre Kibana, navega a Flujos de trabajo y empieza a construir.
Si eres nuevo en los flujos de trabajo, la publicación de Vista Previa Técnica te explica cómo construir tu primer flujo de trabajo de triaje. El flujo de trabajo de Chrysalis APT muestra la integración de Agent Builder en acción. La documentación incluye la referencia completa del tipo de paso. La Biblioteca de Flujos de Trabajo Elástico tiene plantillas listas para usar.
Empieza con el flujo de trabajo que ahorraría más tiempo a tu equipo esta semana. Si puedes describirlo, puedes construirlo.
El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a discreción exclusiva de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.