Por dónde empezar. Por cuarto año consecutivo, Elastic ha tenido el privilegio de desempeñarse como un socio de confianza de la industria en Exercise Defence Cyber Marvel: la serie insignia de ejercicios cibernéticos del Ministerio de Defensa del Reino Unido. DCM26 fue, sin duda, la iteración más ambiciosa hasta ahora, y estamos muy entusiasmados de, finalmente, poder hablar sobre lo que construimos, cómo lo construimos y qué aprendimos en el camino.

¿Qué es Defence Cyber Marvel?

Para quienes no estén familiarizados, Defence Cyber Marvel (DCM) es la serie de ejercicios cibernéticos militares más grande del Reino Unido que se centra en defender redes de IT tradicionales, entornos corporativos y sistemas de control industrial complejos en escenarios realistas y de alta presión. Muestra un poder cibernético responsable, a la vez que mejora la preparación, la interoperabilidad y la resiliencia en todo el sector de Defensa y las naciones aliadas. Ahora en su quinto año, DCM ha evolucionado desde una iniciativa de la Army Cyber Association hasta convertirse en una operación tripartita de las tres fuerzas armadas dirigida por el Cyber and Specialist Operations Command (CSOC).

El Gobierno del Reino Unido publicó un comunicado de prensa oficial sobre DCM26, que ofrece una excelente visión general de la importancia estratégica del ejercicio. Como señaló el alto comisionado británico en Singapur, el ejercicio demuestra la profunda cooperación entre el Reino Unido y sus socios de confianza, un recordatorio de la solidez de las alianzas estratégicas compartidas en un panorama de seguridad cada vez más complejo.

En su núcleo, DCM es un ejercicio cibernético de fuerza contra fuerza: los equipos azules defensores protegen las redes e infraestructura asignadas de los equipos rojos atacantes mediante una variedad de técnicas. Las actividades abarcan desde cambiar las contraseñas predeterminadas y reforzar los firewalls hasta desplegar una defensa cibernética de nivel empresarial impulsada por AI con Elastic Security. El equipo blanco monitorea las actividades de cada equipo para establecer una puntuación que considera la disponibilidad del sistema, la detección de ataques, el reporte de incidentes y la restauración del sistema. Pone a prueba a los equipos más experimentados y, al mismo tiempo, facilita un mecanismo de capacitación único para los equipos junior en su primera exposición a un entorno de práctica de ciberseguridad, y ese doble propósito es lo que hace que DCM sea un ejercicio tan valioso.

La escala de DCM26

DCM26 reunió a más de 2500 personas de 29 países participantes y 70 organizaciones, coordinadas desde un Control del Ejercicio (EXCON) central con sede en Singapur, y EXCON albergó a más de 600 participantes. El ejercicio se ejecutó en un entorno de computación híbrido que abarcó el cyber range de CR14 y AWS, y albergó más de 5000 sistemas virtuales.

El ejercicio en sí se ejecutó durante cinco días (del 9 al 13 de febrero de 2026), precedido por una capacitación previa opcional dirigida por un instructor y por verificaciones de conectividad. El escenario, desarrollado sobre el entorno de operaciones Indo-Pacífico de Defence Academy Training Environment (DATE), posicionó a los equipos como equipos de protección de ciberseguridad para defender sistemas militares desplegados durante una creciente crisis regional. Los equipos azules estaban dispersos geográficamente, algunos en sus ubicaciones de origen en todo el Reino Unido e internacionalmente, y otros, desplegados en el extranjero, todos conectándose al entorno de pruebas a través de una VPN.

Entre los participantes, hubo representantes de Defensa del Reino Unido, departamentos intergubernamentales como la Agencia Nacional contra el Crimen, el Departamento de Trabajo y Pensiones, la Oficina del Gabinete y el Departamento de Negocios y Comercio, junto a socios internacionales que formaron hasta 40 equipos. Tras el éxito del ejercicio del año pasado en la República de Corea, Singapur sirvió como sede del ejercicio por primera vez, lo que refleja el compromiso del Reino Unido de profundizar la cooperación con socios del Indo-Pacífico en torno a desafíos de seguridad compartidos.

En resumen, es un ejercicio serio. Alta presión, fuerza contra fuerza, con consecuencias reales para el puntaje y resultados de aprendizaje reales para cada participante.

Los despliegues: nuestra infraestructura de Elastic

La infraestructura de este año representó una evolución arquitectónica importante respecto de las iteraciones anteriores. En lugar de desplegar clústeres individuales de Elastic Cloud por equipo, pasamos a un único despliegue multiinquilino de Elastic Cloud basado en espacios para los equipos azules. También proporcionamos despliegues para funciones fuera de los equipos azules. Desglosaré cada despliegue y por qué existe.

Equipos azules: Elastic Security multiinquilino

La pieza central de nuestra contribución fue un único despliegue de Elastic Cloud que daba servicio a los 40 equipos azules defensores, separados mediante espacios de Kibana y espacios de nombres de flujos de datos. Cada uno de los 39 equipos tenía su propio espacio de trabajo aislado, incluidos dashboards, agentes y reglas de detección.

Así es como se veía el recurso de Terraform para crear el espacio de cada equipo:

# Crear 40 espacios de equipos azules
resource "elasticstack_kibana_space" "blue_team" {
  count = var.team_count

  space_id    = local.space_ids[count.index]
  name        = "Equipo azul ${local.team_numbers[count.index]}"
  description = "Espacio aislado para equipo azul-${local.team_numbers[count.index]} con visibilidad de Fleet según el espacio"

  disabled_features = []
  color             = "#0077CC"
}

El espacio de cada equipo obtuvo un conjunto exclusivo de tres políticas de agente de Fleet : el día 1, una política de red desplegada; el día 2, una política de red Host Nation; y, finalmente, una política PacketCapture para el monitoreo del tráfico de red. El control de acceso por fases fue elegante en su simplicidad: configurar enable_hostnation_network = true en nuestro terraform.tfvars y ejecutar terraform apply amplió los permisos de rol de cada equipo e hizo que su política de agente de Host Nation fuera visible en su espacio. El ejercicio pasó de una red a dos sin un solo clic manual en Kibana.

El aislamiento de datos se basaba en espacios de nombres de flujos de datos. Cada política de agente se escribe en espacios de nombres específicos del equipo, como bt_01_deployed y bt_01_hostnation, lo que genera flujos de datos que siguen este patrón:

logs-system.auth-bt_01_hostnation
logs-system.syslog-bt_01_hostnation
metrics-system.cpu-bt_01_hostnation
logs-endpoint.events.process-bt_01_hostnation
logs-windows.forwarded-bt_01_hostnation
logs-auditd.log-bt_01_hostnation

El rol de seguridad de Kibana de cada equipo se limitó entonces únicamente a esos flujos de datos mediante bloques dinámicos de privilegios de índices:

# Flujos de datos desplegados (siempre otorgados)
índices {
  nombres = [
    "logs-*-${local.deployed_namespaces[count.index]}",
    "metrics-*-${local.deployed_namespaces[count.index]}",
    ".fleet-*"
  ]
  privilegios = ["read", "view_index_metadata"]
}

# Flujos de datos de HostNation (conditional on enable_hostnation_network)
dynamic "indices" {
  for_each = var.enable_hostnation_network ? [1] : []
  content {
    nombres = [
      "logs-*-${local.hostnation_namespaces[count.index]}",
      "metrics-*-${local.hostnation_namespaces[count.index]}"
    ]
    privilegios = ["read", "view_index_metadata"]
  }
}

La autenticación se gestionó mediante el inicio de sesión único de Keycloak, con los mappings de roles de Elasticsearch que conectaban los grupos de Keycloak con los roles de Kibana:

resource "elasticstack_elasticsearch_security_role_mapping" "blue_team" {
  count = var.team_count

  name    = "bt-${local.team_numbers[count.index]}-keycloak-mapping"
  enabled = true

  roles = [
    elasticstack_kibana_security_role.blue_team[count.index].name
  ]

  rules = jsonencode({
    field = {
      groups = "${local.keycloak_groups[count.index]}"
    }
  })
}

Las políticas de integración predeterminadas eran simples por diseño. Cada equipo recibió: System para la telemetría del núcleo del sistema operativo, Elastic Defend para la detección y respuesta de endpoints, reenvío de eventos de Windows, Auditd para logs de auditoría de Linux e integraciones de Captura de paquetes de red. Son más de 400 políticas de integración administradas como código a través del proveedor de Terraform de Elastic Stack.

Una nota sobre Elastic Defend: debido a la eficacia de la protección de endpoints de Elastic, en la que confían en producción el Departamento de Defensa y la Comunidad de Inteligencia de EE. UU.; obtén más información aquí, y al hecho de que nadie en su sano juicio utiliza exploits de día cero en un ejercicio de entrenamiento, nos vemos obligados a limitar Elastic Defend desactivando el modo de prevención y dejándolo en modo de solo detección. Los equipos reciben alertas cuando sucede algo malo, pero sin mitigación automática. También desactivamos por completo la prevención y detección de amenazas de memoria, ya que esta detecta la mayoría de los implantes y balizas del equipo atacante, lo que arruinaría el juego para los equipos rojos. Hacia el final del ejercicio, permitimos a los equipos usar Elastic Defend en toda su capacidad, pero no antes de dejar que los equipos rojos establecieran una posición sólida.

También preinstalamos las reglas de detección predefinidas de Elastic en cada espacio de equipo: el conjunto completo de Elastic Security Labs, actualizado continuamente en un repositorio abierto. Estas reglas se configuraron para garantizar que solo consultaran índices que los permisos con alcance de espacio de nombres del equipo permitían, lo que previene cualquier filtración de datos entre equipos en la ejecución de las reglas de detección.

Además, cada espacio de equipo tenía configurado el índice predeterminado de Security Solution para limitar las reglas de detección únicamente a los flujos de datos de ese equipo, en lugar del patrón amplio predeterminado. Esto se gestionó mediante un null_resource de Terraform que llamó a la API de configuración interna de Kibana para establecer securitySolution:defaultIndex para cada espacio.

En su punto máximo, este despliegue estaba ingestando 800 000 eventos por segundo (EPS) en los 40 equipos. Es una cantidad importante de datos, y el cluster la gestionó con comodidad gracias a las capacidades de escalado automático de Elastic Cloud. Dicho esto, en 2018, procesábamos 5 millones de eventos por segundo con eBay.

El ciclo de vida de los datos se administró mediante una política de gestión del ciclo de vida de los índices (ILM) que realizaba el rollover de los índices después de un día o 50 GB (lo que ocurriera primero), los movía a una fase cálida después de dos días para optimización de solo lectura y fusión forzosa, y luego eliminaba los datos después de diez días. Como resultado, los costos de almacenamiento se minimizaron mientras se mantenían los requisitos de la ventana de ejercicio. A continuación, se muestra un ejemplo de cómo se implementó la política de ILM.

resource "elasticstack_elasticsearch_index_lifecycle" "dcm5_10day_retention" {
  name = "dcm5-10day-retention"

  hot {
    min_age = "0ms"

    set_priority {
      priority = 100
    }

    rollover {
      max_age                = "1d"
      max_primary_shard_size = "50gb"
    }
  }

  warm {
    min_age = "2d"

    set_priority {
      priority = 50
    }

    readonly {}

    forcemerge {
      max_num_segments = 1
    }
  }

  delete {
    min_age = "${var.data_retention_days}d"

    delete {
      delete_searchable_snapshot = true
    }
  }
}

La prueba de estrés de shards: demostración de multitenancy a escalar

Antes de comprometernos con esta arquitectura para un ejercicio militar en vivo, debíamos demostrar que sería capaz de cumplir con nuestros requisitos y contar con una conmutación por error adecuada en caso de problemas. Pasar de despliegues individuales a un único cluster multiinquilino introdujo riesgos reales: contienda de recursos, cuellos de botella en la ingesta, filtración de datos entre espacios debido a una configuración incorrecta, una gran cantidad de conexiones TCP en los nodos de Elasticsearch y una cantidad de shards significativamente mayor, ya que cada equipo genera su propio conjunto de índices.

Por eso, creamos un entorno de pruebas exclusivo. El plan era sencillo: desplegar 50 espacios de Kibana, crear una política de agente en cada espacio, lanzar 6000 instancias de EC2 (120 por inquilino, en seis subredes de tres zonas de disponibilidad) y realizar pruebas de carga de todo el conjunto. Supervisamos todo con AutoOps y Stack Monitoring.

El flujo de despliegue funcionó así: Terraform creó la VPC y las subredes en tres zonas de disponibilidad, aprovisionó los 50 espacios de Kibana y sus políticas de Fleet con alcance de espacio, generó tokens de inscripción y luego lanzó instancias de EC2 en batches. Cada instancia instaló Elastic Agent al iniciar y se inscribió con su token específico del espacio.

Nos encontramos con algunos desafíos interesantes en el camino. El proveedor estándar de Terraform de Elastic Stack no admitía operaciones de Fleet compatibles con espacios en ese momento, por lo que creamos una bifurcación y agregamos el manejo de ID de espacios a los recursos de Fleet. Sin esa modificación, cada agente se habría registrado en el espacio predeterminado, independientemente de la asignación de políticas. Esta no fue la primera vez que tuvimos que extender el proveedor para un ejercicio; hace dos años, para DCM2, habíamos agregado la fuente de datos elasticsearch_cluster_info. Afortunadamente, desde entonces, el proveedor principal agregó support for space_ids en la versión 0.12.2.

También nos encontramos con los límites de frecuencia de la API de AWS EC2 al intentar activar las 6000 instancias simultáneamente, por lo que realizamos los despliegues en batches de 500 instancias con períodos de enfriamiento de cinco minutos entre batches.

Los resultados fueron tranquilizadores. Por lo general, los 6000 agentes se inscribían dentro de los 20 minutos posteriores al despliegue. En nuestras pruebas, el aislamiento de espacios funcionó como se esperaba, sin fugas de datos observadas entre inquilinos. Las actualizaciones de las políticas de Fleet se propagaron a todos los agentes en un plazo de 60 segundos. Las consultas de búsqueda delimitadas a espacios individuales se mantuvieron rápidas con carga plena. Y la distribución multi-AZ demostró ser resistente durante fallas simuladas de zonas de disponibilidad.

Estas pruebas nos dieron la confianza para comprometernos con la arquitectura para el ejercicio en vivo.

Equipos rojos: observabilidad de implantes de C2

Se preparó un despliegue independiente de Elastic y exclusivo para los equipos rojos, enfocado en la observabilidad de implantes de comando y control (C2). Esto les brindó a los equipos atacantes visibilidad sobre sus propias operaciones, incluido el estado de los implantes, los callbacks de balizas y el progreso operativo, sin ningún riesgo de contaminación cruzada con los datos del equipo azul. Los equipos rojos usaron Tuoni como su C2, que es un marco de trabajo desarrollado por Clarified Security para red teaming. En DCM3, trabajamos con Clarified Security para asegurarnos de que admitiera adecuadamente Elastic Common Schema, lo que facilitará mucho la futura integración con Elastic.

NSOC: Ejercicio del Centro de Operaciones de Seguridad de Red

El ejercicio principal, Centro de Operaciones de Seguridad de Re (NSOC), se ejecutó en su propio despliegue de Elastic, lo que brindó al personal de control del ejercicio una vista general del estado del alcance, monitoreo de seguridad en toda la infraestructura y, fundamentalmente, logs de auditoría para todos los servicios de AI que desplegamos. Cada invocación a la API de Bedrock se registró en CloudWatch y se observó en este despliegue, lo que significa que el NSOC tuvo visibilidad completa de lo que se preguntaba a los agentes de AI y quién lo hacía. Más sobre este tema en la sección de AI a continuación.

Automatización de infraestructuras: Terraform y Catapult

Todo lo que viste arriba se gestionó como infraestructura como código. Nuestro provider.tf da una idea del ecosistema de proveedores que estábamos orquestando:

terraform {
  required_version = ">= 1.5"

  required_providers {
    elasticstack = {
      source  = "elastic/elasticstack"
      version = "~> 0.13.1"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    vault = {
      source  = "hashicorp/vault"
      version = "~> 3.20"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5.15.0"
    }
  }

  backend "s3" {
    bucket  = "elastic-terraform-state-dcm5"
    key     = "prod/terraform.tfstate"
    region  = "eu-west-2"
    encrypt = true
  }
}

La huella total de recursos administrada por Terraform fue considerable: un despliegue de Elastic Cloud con escalado automático, 40 espacios de Kibana, 120 políticas de agentes de Fleet (tres por equipo), más de 400 políticas de integración, 40 roles de seguridad de Kibana, 40 mappings de roles de Keycloak, políticas de ILM para la retención de datos, 41 usuarios de AWS IAM para conectores de GenAI de Bedrock (uno por espacio de equipo más uno predeterminado), 41 conectores de acción de GenAI de Kibana, barreras de protección de AWS Bedrock, túneles de Cloudflare Zero Trust para el acceso a Tines, conectores de acción de Tines por espacio de equipo, cuentas de servicio de detección almacenadas en HashiCorp Vault y configuración de índices predeterminada de Security Solution por espacio. Todo el estado se almacenó en un backend cifrado de S3.

Para el despliegue del agente y el proxy en los sistemas reales del entorno, usamos Catapult, una excelente herramienta open source desarrollada por el equipo de Clarified Security. Catapult envuelve a Ansible con un modelo de ejecución basado en contenedores diseñado específicamente para despliegues de entornos de ciberseguridad. Gestionó la instalación y la inscripción de Elastic Agents en toda la infraestructura del entorno. La configuración de servidores proxy (cada equipo tenía un proxy Squid dedicado para su red desplegada, esto fue para simular un único punto de egreso como sucedería en el mundo real. El tráfico se enrutaba a través de endpoints como http://elastic-proxy.dsoc.XX.dcm.ex:3128), y el despliegue de túneles de Cloudflare para la conectividad de Tines.

Durante el aprovisionamiento, Terraform escribió lo siguiente en HashiCorp Vault y Catapult lo consumió: credenciales, tokens de inscripción, claves de API, configuraciones de proxy, credenciales de cuenta de servicio de Tines. Las rutas de Vault seguían una estructura coherente como dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployed y dcm/gt/elastic/tines-sa/tines-sa-btXX, lo que facilitaba que los manuales de Catapult obtuvieran las credenciales correctas para cada equipo.

Capacitación: preparar a los equipos para el éxito

Desplegar la plataforma es una cosa; asegurar que las personas realmente puedan usarla es otra. Brindamos capacitación en el entorno de entrenamiento, impartida por un instructor, a los equipos azules durante la fase previa al ejercicio. Esto abarcó los fundamentos de Elastic Security, la navegación por el espacio de su equipo en Kibana, el trabajo con las reglas de detección predefinidas, el uso de Discover para el análisis de logs y la búsqueda de amenazas, la creación de dashboards customizados, la comprensión de las alertas de Elastic Defend y la familiarización con la herramienta de investigación Timeline.

Las instrucciones del ejercicio indicaban que esta capacitación era opcional pero "muy recomendada", y, por lo que vimos, los equipos que asistieron comenzaron a rendir al máximo desde el primer día de ejecución. La capacitación y la habilitación son tan importantes como el despliegue de la tecnología en sí. Darle a un equipo herramientas de seguridad de nivel empresarial que no sabe cómo usar no habría sido útil para nadie.

El servicio de AI dentro del entorno: compatible, auditado y con barreras de protección

Este año marcó nuestro debut en brindar acceso a la AI a la gama de DCM. Ofrecimos un servicio de AI que cumple con las normativas directamente en el entorno, respaldado por modelos de AWS Bedrock alojados en el Reino Unido; específicamente Claude 3.7 Sonnet ejecutándose en la región eu-west-2 (Londres). Esto no fue IA por el simple hecho de usar IA; fue un servicio cuidadosamente diseñado con barreras de protección, logs de auditoría completos y controles de acceso compatibles con RBAC. Se nos confió la ejecución de este servicio gracias a la experiencia de Elastic en el ámbito de la AI.

El servicio de AI tenía varios consumidores en el rango, y esta es una distinción importante. El conector de Bedrock compatible que aprovisionamos en el espacio de cada equipo no solo impulsaba nuestros agentes personalizados, sino que también impulsaba las características de IA nativas de Elastic, específicamente:

Elastic AI Assistant para Security

El Elastic AI Assistant estaba disponible en cada espacio de los equipos azules y conectado a nuestro conector Bedrock en el entorno de práctica. Esto proporcionó a los equipos una interfaz de chat con reconocimiento de contexto directamente en Elastic Security, donde podían hacer preguntas sobre sus alertas, obtener ayuda para escribir consultas ES|QL, investigar procesos sospechosos y recibir pasos guiados para la corrección. El asistente de AI usa Retrieval-Augmented Generation (RAG) con la característica de base de conocimientos de Elastic, que está precargada con artículos de Elastic Security Labs. Los equipos también podían agregar sus propios documentos, como procedimientos operativos estándar específicos del entorno, inteligencia de amenazas o notas del equipo, a la base de conocimientos para fundamentar aún más las respuestas del asistente en su contexto operativo.

Lo que hizo que esto fuera especialmente valioso en el contexto del ejercicio fue la capacidad del AI Assistant de ayudar a los analistas con menos experiencia a comprender lo que estaban viendo. Un analista junior que se enfrente a su primera señal de baliza de implante activa podría pedirle al asistente que explique la alerta, sugiera pasos de investigación e, incluso, ayude a redactar el reporte del incidente. La configuración de anonimización de datos garantizaba que los valores de los campos confidenciales pudieran ofuscarse antes de enviarse al proveedor de LLM.

Attack Discovery de Elastic

Attack Discovery fue otro consumidor importante de nuestro servicio de AI dentro del entorno. Attack Discovery usa los LLM para analizar alertas en el entorno de un equipo e identificar amenazas mediante la correlación de alertas, comportamientos y rutas de ataque. Cada "detección" representa un posible ataque y describe las relaciones entre múltiples alertas: indica a los equipos qué usuarios y hosts están involucrados, cómo se mapean las alertas a la matriz MITRE ATT&CK y qué actor de amenazas podría ser el responsable.

Para un ejercicio de ciberseguridad en el que los equipos rojos lanzaron activamente ataques coordinados, Attack Discovery fue transformador. En lugar de clasificar manualmente cientos de alertas individuales, los equipos azules podían ejecutar Attack Discovery para visibilizar las narrativas de ataque de alto nivel; por ejemplo, "estas 15 alertas forman parte de una cadena de movimiento lateral del host X al host Y, probablemente, provocada por el actor de amenazas Z", y enfocar el tiempo de investigación donde más importaba. Es el tipo de capacidad que reduce directamente el tiempo promedio de respuesta y combate la fatiga por alertas, que es, precisamente, lo que necesitas cuando estás bajo un ataque sostenido durante cinco días seguidos.

Los agentes de AI personalizados: Elastic Agent Builder

Más allá de las características nativas de Elastic AI, creamos tres agentes de AI personalizados con Elastic Agent Builder. Agent Builder es el marco de trabajo de Elastic para crear agentes de AI personalizados que combinan instrucciones de LLM con herramientas modulares y reutilizables, donde cada herramienta es una búsqueda de ES|QL, una capacidad de búsqueda integrada, la ejecución de un flujo de trabajo o una integración externa a través de MCP. Los agentes parsean solicitudes en lenguaje natural, seleccionan las herramientas adecuadas, las ejecutan e iteran hasta que pueden brindar una respuesta completa, todo mientras gestionan el contexto con datos dentro de Elasticsearch. Puedes obtener más información sobre el marco de trabajo en la documentación de Agent Builder y en el análisis detallado de Elasticsearch Labs.

Los tres componentes clave de Agent Builder que aprovechamos fueron:

Agentes: instrucciones personalizadas de LLM y un conjunto de herramientas asignadas que definen la personalidad, las capacidades y los límites de comportamiento del agente. Cada agente tiene un aviso del sistema que controla su misión, las herramientas a las que puede acceder y la estructura de sus respuestas.

Herramientas: funciones modulares que los agentes usan para buscar, recuperar y manipular datos de Elasticsearch. Creamos herramientas de ES|QL personalizadas que consultaban índices específicos que contenían documentación de ejercicios, manuales y reportes.

Chat del agente: La interfaz conversacional —tanto la UI integrada de Kibana como la API programática— que los participantes usaron para interactuar con los agentes.

Las configuraciones del agente y de las herramientas se definen como JSON y se gestionan a través de las API de Agent Builder, lo que hace que todo el ciclo de vida del agente —desde la ingeniería de prompts hasta la vinculación de herramientas— sea reproducible y controlable por versiones. Compartiremos la configuración del agente GrantPT y las definiciones de herramientas en una próxima publicación para quienes quieran replicar este enfoque. Estén atentos.

Esto es lo que hizo cada agente:

1. GrantPT: El asistente de uso general

Disponible para los ~2500 participantes del ejercicio, GrantPT fue nuestro principal agente de AI y la mejor demostración de cómo facilita Agent Builder implementar un asistente capaz y específico para el dominio. La configuración del agente consistía en un objeto JSON que definía su mensaje de sistema, personalidad y un arreglo de ID de herramientas vinculadas; eso era todo. Sin código de aplicación personalizado ni capa de API a medida, solo configuración declarativa.

Lo que le dio a GrantPT su profundidad fueron las herramientas. Definimos una combinación de herramientas integradas de la plataforma y de herramientas personalizadas de ES|QL, cada una registrada con una descripción, una búsqueda parametrizada y definiciones de parámetros con tipo. Por ejemplo, la herramienta de base de conocimiento aceptaba un parámetro target_index y un parámetro semántico query, lo que ejecutaba una búsqueda ES|QL parametrizada en nuestros índices dcm5-grantpt-* con clasificación de búsqueda semántica:

FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10

Una herramienta independiente de detección de índices le permitió al agente enumerar de forma dinámica los índices de la base de conocimiento disponibles al inicio de cada conversación, lo que significaba que podíamos agregar nuevos índices de documentación durante el ejercicio sin reconfigurar el agente; solo los descubriría en la siguiente interacción.

También creamos una herramienta de integración de Jira que realizaba búsquedas semánticas en los tickets de soporte técnico ingestados, lo que permitía a GrantPT mostrar contexto relevante de resolución de problemas a partir de solicitudes de soporte anteriores. Esto fue especialmente útil para los analistas de HelpDesk, quienes podían consultarle a GrantPT sobre problemas recurrentes y obtener respuestas fundamentadas en el historial real de tickets, en lugar de una orientación genérica.

El comportamiento de respuesta adaptado a RBAC provino de una combinación del prompt del sistema del agente, que le indicaba contextualizar las respuestas en función del rol del usuario, y el modelo de seguridad subyacente de Elasticsearch. Debido a que la búsqueda ES|QL de cada herramienta se ejecuta dentro del contexto de seguridad del usuario, el agente solo puede mostrar documentos accesibles para el rol del usuario. Un miembro del equipo azul que preguntara sobre procedimientos de ejercicios obtendría resultados limitados a los índices accesibles de su equipo, mientras que un analista de HelpDesk vería resultados de índices específicos de HelpDesk. El agente no necesitó una lógica explícita de cambio de roles; la seguridad a nivel de documento nativa de Elasticsearch gestionó la delimitación y el agente simplemente trabajó con los resultados que se devolvieron. Esta es una de las cosas que hace que Agent Builder sea genuinamente elegante: al heredar el modelo de seguridad de Elasticsearch, obtienes IA basada en RBAC sin escribir una sola línea de código de autorización.

2. REDRock - El compañero del adversario

Este agente estaba disponible exclusivamente para los equipos rojos. REDRock siguió el mismo patrón de Agent Builder, un prompt del sistema dedicado que definía su perfil adversario, vinculado a su propio conjunto de herramientas ES|QL personalizadas que realizaban búsquedas en índices específicos de los equipos rojos. Estos índices contenían los manuales de los equipos rojos, documentación de Tuoni C2, vulnerabilidades conocidas del sistema dentro del entorno del campo de entrenamiento e información sobre los servicios desplegados. Las definiciones de las herramientas reflejaban el mismo patrón de búsqueda semántica parametrizada utilizado por GrantPT, pero se limitaban a índices accesibles únicamente para los roles de los equipos rojos. Los operadores de los equipos rojos podían consultar vectores de ataque, verificar debilidades conocidas en los sistemas de destino y obtener orientación contextual sobre sus planes operativos. Francamente, fue como darles a los atacantes un oficial de operaciones sumamente bien informado.

3. RefPT: la herramienta del árbitro

Creado específicamente para el equipo blanco (los árbitros y evaluadores del ejercicio), RefPT se vinculó a herramientas que consultaban índices que contenían reportes de los equipos azules, eventos de escenarios y los criterios de puntuación. Su propósito era garantizar una puntuación uniforme y justa en los más de 40 equipos. El prompt del sistema del agente se ajustó para cotejar los reportes enviados con eventos de escenarios conocidos y rúbricas de puntuación, lo que ayudó a los evaluadores a identificar inconsistencias o brechas. Cuando tienes evaluadores que evalúan decenas de equipos de forma simultánea, contar con una AI que pueda correlacionar reportes con un índice de puntuación estructurado resulta verdaderamente transformador para la consistencia.

Tines: automatización de flujos de trabajo impulsada por AI

Tines también era un consumidor del servicio de AI dentro del entorno del ejercicio. Cada equipo azul tenía una instancia dedicada de Tines, con conectores de acciones de Tines aprovisionados en su espacio de Kibana. Tines podía aprovechar las capacidades de AI respaldadas por Bedrock para la automatización inteligente de flujos de trabajo, como el enriquecimiento automatizado de alertas, decisiones de clasificación asistidas por AI, resúmenes en lenguaje natural en flujos de trabajo de notificación y la creación de flujos de trabajo en lenguaje natural. El conector de Tines se configuró por equipo con credenciales almacenadas en Vault:

resource "elasticstack_kibana_action_connector" "tines_bt" {
  count = var.team_count

  name              = "BT-${local.team_numbers[count.index]}-Tines"
  connector_type_id = ".tines"
  space_id          = local.space_ids[count.index]

  config = jsonencode({
    url = "https://tines.dsoc.${local.team_numbers[count.index]}.dcm.ex/"
  })
}

Garantizar el cumplimiento: barreras de protección y auditoría

Cada interacción de AI en todos estos consumidores estuvo regida por estrictas barreras de protección de AWS Bedrock. Desplegamos barreras de protección con filtrado de contenido (odio, insultos, contenido sexual y violencia en umbrales MEDIUM), protección de PII (bloqueo de direcciones de correo electrónico, números de teléfono, nombres, direcciones, números de la seguridad social del Reino Unido, números de tarjetas de crédito y direcciones IP), filtrado basado en temas para prevenir la discusión de operaciones clasificadas reales y filtrado de lenguaje soez. Aquí tienes un fragmento de la configuración de las barreras de protección de nuestro Terraform:

resource "aws_bedrock_guardrail" "dcm5_elastic" {
  name        = "dcm5-prod-elastic-guardrail"
  description = "Barreras de protección para conectores de GenAI de DCM5 Prod Elastic Kibana"

  content_policy_config {
    filters_config {
      input_strength  = "MEDIUM"
      output_strength = "MEDIUM"
      type            = "HATE"
    }
    # ... filtros de contenido adicionales para INSULTOS, SEXUAL, VIOLENCIA
  }

  sensitive_information_policy_config {
    pii_entities_config {
      action = "BLOCK"
      type   = "UK_NATIONAL_INSURANCE_NUMBER"
    }
    pii_entities_config {
      action = "BLOCK"
      type   = "IP_ADDRESS"
    }
    # ... filtros adicionales de PII
  }

  topic_policy_config {
    topics_config {
      name       = "classified-information"
      definition = "Discusiones sobre operaciones clasificadas reales, actividades militares actuales del mundo real o inteligencia operativa."
      type       = "DENY"
    }
  }
}

Cada espacio de los equipos azules tenía su propio usuario de IAM para acceder a Bedrock, y se aplicó la configuración de Kibana genAiSettings:defaultAIConnectorOnly para evitar que los equipos configuraran sus propios conectores. Esto significaba que cada llamada de API podía rastrearse hasta un equipo específico mediante CloudWatch, y el NSOC tenía visibilidad completa de auditoría. El grupo de logs de CloudWatch /aws/bedrock/grantpt-prod/invocations capturó cada evento de invocación y de barrera de protección.

Los números para todos los consumidores de AI hablan por sí mismos: 3 agentes de AI personalizados, 2797 conversaciones y 785 millones de tokens de AI consumidos a lo largo del ejercicio.

Monitoreo en tiempo real dentro del juego

Dentro del escenario del ejercicio, cada equipo tenía acceso a RocketChat como su cliente de mensajería en el entorno. Cada equipo azul obtuvo su propio canal, la posibilidad de enviar mensajes directos a cualquier participante del ejercicio y la libertad de crear nuevos canales según fuera necesario. Y lo más importante para la tradición del DCM, esto incluía el canal de memes, la columna vertebral espiritual de todas las bromas entre equipos y el humor creativo para levantar la moral que surge inevitablemente cuando pones a unos miles de operadores cibernéticos bajo presión durante una semana.

Todos estos datos de comunicación representaban una excelente ventana en tiempo real al estado del campo de entrenamiento, el sentir del equipo y los temas en tendencia durante el ejercicio. Era una oportunidad demasiado buena como para dejarla pasar, así que ingestamos todo el corpus de conversaciones de RocketChat en Elastic en tiempo real y lo pusimos a trabajar.

Análisis de sentimiento y reconocimiento de entidades con nombre

Para el reconocimiento de entidades con nombre, desplegamos el modelo de Hugging Face dslim/bert-base-NER en un nodo de machine learning en el despliegue de NSOC mediante el cliente de Elastic ELAND. Esto luego se conectó a un pipeline de ingesta de Elasticsearch por el que pasaba cada mensaje de RocketChat durante la ingesta. Tomamos las entidades extraídas y presentamos las más comunes como temas de dashboard, lo que nos brindó una vista en tiempo real del ir y venir de los temas de conversación a lo largo del ejercicio.

También analizamos la actividad de los grupos, las estadísticas de usuarios y los patrones generales de comunicación para crear una imagen de los patrones de vida de cada equipo: participantes más activos, volumen de mensajes a lo largo del tiempo y tendencias de sentimiento desglosadas por usuarios individuales. En definitiva, nos brindó información realmente interesante sobre lo que sucedía en el campo de pruebas casi en tiempo real. Cuando cambiamos Elastic Agent al modo de prevención, por ejemplo, una nube de palabras de nuestro dashboard se iluminó de inmediato con "Elastic" como el tema más comentado en todos los canales: los equipos azules debatían su eficacia y los equipos rojos lamentaban la pérdida de sus balizas. Eso es bastante satisfactorio.

Análisis de memes (sí, de verdad)

Por último —y esto hizo que más de uno arqueara las cejas— recopilamos todos los memes enviados a los canales, vectorizamos las imágenes y ejecutamos evaluaciones de vecinos más cercanos para agrupar memes y temas similares. También los procesamos con el modelo de inferencia de NER de zero-shot para generar descripciones temáticas del contenido de cada meme. La lógica era que estas salidas podrían resultar útiles más adelante para el filtrado, la moderación u otras interacciones dentro del juego. Es debatible que el análisis de memes haya producido inteligencia de importancia crítica para las operaciones. Que haya sido divertido no está en duda.

Cortar los problemas de raíz

Por mucho que esperábamos que todo se ejecutara sin problemas durante la semana de ejercicios, inevitablemente las cosas fallan, no se comprenden por completo o necesitan mayor personalización para adaptarse a la forma en que un equipo en particular quiere usarlas. Para esto, teníamos nuestra propia subsección del servicio de asistencia técnica dentro del entorno, donde cualquier equipo podía presentar solicitudes específicas de Elastic y GenAI.

Nos ocupamos de este servicio de asistencia durante toda la duración del ejercicio, brindando orientación, documentación, depuración de problemas y recomendaciones específicas para el entorno de pruebas. Vale la pena profundizar en ese último punto. A veces, lo que un equipo azul veía en Elastic no era en absoluto un problema de Elastic, sino que Elastic mostraba fielmente algo en el entorno de pruebas que ameritaba una mayor investigación (los equipos rojos pueden causar un caos absoluto, y la telemetría no miente). A lo largo del ejercicio, atendimos 125 solicitudes de soporte individuales de equipos que solicitaron específicamente nuestra ayuda en Elastic.

Depuración preventiva con Tines

Además de visitar a los equipos por videoconferencia o en persona en EXCON, también trabajamos con Tines para probar algo un poco más proactivo. Extraíamos el cuerpo del ticket de las solicitudes entrantes, intentábamos categorizar el problema, ejecutábamos la categorización en nuestro corpus de tickets resueltos anteriormente y hacíamos que GenAI generara una respuesta resumida inicial orientada a resolver el problema del usuario antes de que el triaje lo llevara a nuestra cola.

De hecho, este es un patrón que tomamos prestado de nuestra propia organización de soporte de Elastic, donde ofrecemos una funcionalidad similar utilizando nuestra amplia base de conocimientos de problemas resueltos con anterioridad como repositorio para respaldar el contexto del agente de AI. La idea es sencilla: usar soluciones anteriores para brindar un primer intento informado y generado por máquina para resolver un problema, y evitar la necesidad de que un ingeniero de soporte atienda cada ticket manualmente. Esto no resolvió todo; algunos problemas realmente necesitaban a un ser humano con contexto amplio, pero redujo de forma significativa la presión en la cola y brindó respuestas más rápidas a los equipos que las necesitaban. Esto tuvo tanto éxito con nuestros propios tickets y cola específicos que, en la última parte del ejercicio, ampliamos el alcance a toda la mesa de ayuda, lo que sirvió para reducir la carga de los otros grupos del equipo verde que apoyaba el ejercicio.

Alianzas del sector: Mejor juntos

Una de las cosas que más nos enorgullece es cómo ha crecido nuestro ecosistema de socios año tras año. DCM no es solo un show de Elastic; es una verdadera coalición de socios de la industria, donde cada uno aporta algo único a la plataforma de seguridad.

Año 1 (DCM2) - Elastic se unió como socio de la industria, proporcionando la plataforma de monitoreo de seguridad y detección de endpoints.

Año 2 (DCM3): Incorporamos Endace, lo que proporcionó una capacidad de captura de paquetes 1:1. La captura completa de paquetes junto con la visibilidad de red de Elastic brindó a los equipos la capacidad de realizar análisis forenses detallados que el análisis basado únicamente en logs no puede proporcionar.

Año 3 (DCM4): Tines se unió a la familia, aportando la automatización del flujo de trabajo. Los equipos azules ahora podían crear manuales de respuesta automatizada, flujos de trabajo de clasificación y cadenas de notificación, todo integrado directamente en su entorno de Elastic mediante el conector nativo de Tines.

Año 4 (DCM26, antes DCM5): Se sumó AWS, lo que brindó acceso a Bedrock para nuestros agentes de AI y aportó financiamiento para los despliegues de Elastic. Este fue un hito significativo; contar con un hiperescalador directamente involucrado en el éxito del ejercicio desbloqueó capacidades (como inferencia de la AI conforme a las normas en un entorno del Reino Unido, barreras de protección completas y logs de auditoría) que, simplemente, no habrían sido posibles de otro modo. La integración de Tines este año también se vio mejorada gracias a la incorporación de acceso dentro del entorno a los LLM. La serie DCM también alcanzó un hito este año, al pasar de sus orígenes como una iniciativa de la Army Cyber Association a un programa financiado oficialmente en virtud del Cyber and Specialist Operations Command.

A los equipos de Endace, Tines y AWS: sinceramente, gracias. Este ejercicio es mejor gracias a sus aportes, y todos los equipos están mejor equipados gracias a la plataforma que construimos juntos. Ya estamos planificando el DCM27. ¡Saludos a todos ustedes!

Cultura, aspectos destacados y lo que hace que valga la pena

Las monedas de desafío

Hicimos acuñar monedas de desafío personalizadas para DCM26. El que sabe sabe: las monedas de desafío son una tradición militar de larga data, y mandar a hacer una para el ejercicio pareció la manera adecuada de marcar nuestro cuarto año de participación.

El cóctel

También estuvimos muy agradecidos de haber sido invitados al cóctel de la High Commission organizado por el alto comisionado británico en Singapur. Es extraño hablar de la cantidad de shards de Elasticsearch y la administración del estado de Terraform mientras tienes un gin-tonic en la mano por invitación del embajador. Fue una velada brillante, un auténtico recordatorio de que estos ejercicios existen en la intersección de la tecnología y la diplomacia, y de que las relaciones construidas aquí van mucho más allá de lo técnico.

Resumen

La arquitectura multiinquilino demostró su eficacia bajo una carga sostenida; las características nativas de Elastic AI (AI Assistant y Attack Discovery) les dieron a los equipos capacidades que habrían parecido ciencia ficción hace unos años; y los agentes de AI personalizados superaron nuestras expectativas de adopción. El modelo de asociación continúa demostrando que la participación de la industria en ejercicios de defensa genera resultados que ninguna organización podría lograr por sí sola.

Defence Cyber Marvel 2026 fue una edición emblemática de un ejercicio que sigue creciendo en ambición, complejidad e impacto. Para Elastic, que se nos confíe proporcionar la plataforma central de seguridad defensiva para 40 equipos azules de 29 naciones y, este año, también con la capacidad de AI, es algo que no tomamos a la ligera. El ejercicio desarrolla habilidades reales para personas reales que defenderán redes reales, y formar parte de esa misión es muy significativo.

Tal como el comunicado de prensa del Gobierno del Reino Unido lo expresó, DCM demuestra el valor práctico de las situaciones de la vida real que refuerzan las asociaciones internacionales. No podríamos estar más de acuerdo.

Volveremos el próximo año y sospecho que tendremos aún más de qué hablar. Mientras tanto, continuaremos mejorando el producto para que el soporte para entornos como Defence Cyber Marvel se destaque año tras año.

Nos vemos en el campo de práctica.

Sigue la historia de DCM26 en las redes sociales:

Facebook | LinkedIn | Instagram

Lecturas adicionales

Elastic Security y AI

• Elastic Security - La plataforma que impulsa los despliegues de los equipos azules
• AI Assistant para Security - Chat de AI consciente del contexto dentro de Elastic Security
• Attack Discovery - Correlación de alertas impulsada por los LLM y generación de narrativas de amenazas
• Agent Builder - Marco de trabajo para crear agentes de AI personalizados con Elasticsearch

Infraestructura y herramientas

• Proveedor de Terraform de Elastic Stack - Infraestructura como código para Elastic Stack
• Guía de Elastic Fleet - Gestión centralizada de Elastic Agents a escala
• Catapult by Clarified Security - Aprovisionamiento del entorno de ciberseguridad basado en Ansible

Contexto del ejercicio

• Comunicado de prensa sobre DCM26 del Gobierno del Reino Unido - Visión general oficial del ejercicio