Por dónde empezar. Por cuarto año consecutivo, Elastic tuvo el privilegio de ser un socio de confianza en la industria del Ejercicio Defence Cyber Marvel, el serial emblemático de ejercicios cibernéticos del Ministerio de Defensa del Reino Unido. DCM26 fue, sin duda, la iteración más ambiciosa hasta la fecha, y estamos encantados de poder hablar por fin sobre lo que construimos, cómo lo hicimos y lo que aprendimos en el camino.
¿Qué es Defence Cyber Marvel?
Para quienes no lo conozcan, Defence Cyber Marvel (DCM) es el mayor serial de ejercicios militares cibernéticos del Reino Unido que se centra en defender redes informáticas tradicionales, entornos corporativos y complejos sistemas de control industrial en escenarios realistas y de alta presión. Demuestra un poder cibernético responsable mientras mejora la preparación, la interoperabilidad y la resiliencia en Defensa y naciones aliadas. Ahora en su quinto año, el DCM evolucionó de una iniciativa de la Asociación de Ciberseguridad del Ejército a una operación tri-servicios liderada por el Mando de Operaciones Cibernéticas y Especializadas (CSOC).
El Gobierno del Reino Unido publicó un comunicado de prensa oficial para el 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 socios de confianza, recordando la fortaleza de las alianzas estratégicas compartidas en un panorama de seguridad cada vez más complejo.
En esencia, DCM es un ejercicio cibernético de fuerza contra fuerza: defender a los Equipos Azules protege sus redes e infraestructuras asignadas de ataques a los Equipos Rojos, empleando una variedad de técnicas. Las actividades abarcan desde cambiar contraseñas predeterminadas y reforzar firewall hasta desplegar defensa cibernética de nivel empresarial impulsada por IA con Elastic Security. Las actividades de cada equipo son monitorizadas por el Equipo Blanco para establecer un puntaje que tenga en cuenta la disponibilidad del sistema, la detección de ataques, la notificación de incidentes y la restauración del sistema. Pone a prueba a los equipos más experimentados y facilita un mecanismo de formación único para equipos junior en su primer contacto con un campo de tiro cibernético, y ese doble propósito es lo que hace que el DCM sea un ejercicio tan valioso.
La escala de DCM26
DCM26 reunió a más de 2.500 personas de 29 países y organizaciones 70 participantes, coordinadas desde un Control Central de Ejercicios (EXCON) con sede en Singapur, con EXCON acogiendo a más de 600 participantes. El ejercicio se desarrolló en un entorno de cálculo híbrido que abarcó la gama cibernética CR14 y AWS, albergando más de 5.000 sistemas virtuales.
El ejercicio en sí duró cinco días de ejecución (9–13 de febrero de 2026), precedidos por preentrenamiento opcional dirigido por un instructor y comprobaciones de conectividad. El escenario, basado en el Entorno de Entrenamiento de la Academia de Defensa (DATE) Entorno Operativo Indo-Pacífico, situaba a los equipos como Equipos de Protección Cibernética defendiendo sistemas militares desplegados durante una crisis regional en escalada. Los Equipos Azules estaban geográficamente dispersos, algunos en sus ubicaciones de origen por todo el Reino Unido e internacionalmente, otros desplegados en el extranjero, todos conectados al rango mediante VPN.
Entre los participantes se encontraban 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 con socios internacionales que formaban 40 equipos. Tras el éxito del ejercicio del año pasado en la República de Corea, Singapur sirvió por primera vez como centro de ejercicios, reflejando el compromiso del Reino Unido de profundizar la cooperación con socios indo-pacíficos en 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 Elastic
La infraestructura de este año representó una evolución arquitectónica significativa respecto a ediciones anteriores. En lugar de desplegar clústeres individuales de Elastic Cloud por equipo, pasamos a un único despliegue de Elastic Cloud multi-tenant basado en espacio para los Blue Teams. También proporcionamos despliegues para funciones fuera de los Blue Teams. Déjame desglosar cada despliegue y por qué existe.
Blue Teams: Seguridad Elástica Multi-inquilino
El eje central de nuestra contribución fue un único despliegue de Elastic Cloud que sirviera a todos 40 equipos Blue que defendieran, separados mediante Kibana Spaces y espacios de nombres de flujo de datos. Cada uno de los equipos de 39 tenía su propio espacio de trabajo aislado, incluyendo paneles, agentes y reglas de detección.
Así es como se veía el recurso de Terraform para crear el espacio de cada equipo:
# Create 40 Blue Team spaces
resource "elasticstack_kibana_space" "blue_team" {
count = var.team_count
space_id = local.space_ids[count.index]
name = "Blue Team ${local.team_numbers[count.index]}"
description = "Isolated space for BT-${local.team_numbers[count.index]} with space-aware Fleet visibility"
disabled_features = []
color = "#0077CC"
}Cada espacio de equipo recibió un conjunto dedicado de tres políticas de agentes de flota : el día 1a Política de red desplegada, el día 2, una política de red para el país anfitrión y, finalmente, una política de PacketCapture para la monitorización del tráfico de red. El control de acceso por fases era elegante en su simplicidad: establecer enable_hostnation_network = true en nuestro terraform.tfvars y ejecutar terraform apply amplió las licencias de rol de cada equipo e hizo visible su política de agentes de la Nación Anfitriona en su espacio. El ejercicio pasó de una red a dos sin un solo clic manual en Kibana.
El aislamiento de datos dependía de espacios de nombres de flujo de datos. Cada política de agente se escribe en espacios de nombres específicos de equipo como bt_01_deployed y bt_01_hostnation, produciendo flujos de datos siguiendo el 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_hostnationEl rol de seguridad Kibana de cada equipo se limitó entonces a aquellos flujos de datos empleando bloques de privilegio de índice dinámico:
# Deployed data streams (always granted)
indices {
names = [
"logs-*-${local.deployed_namespaces[count.index]}",
"metrics-*-${local.deployed_namespaces[count.index]}",
".fleet-*"
]
privileges = ["read", "view_index_metadata"]
}
# HostNation data streams (conditional on enable_hostnation_network)
dynamic "indices" {
for_each = var.enable_hostnation_network ? [1] : []
content {
names = [
"logs-*-${local.hostnation_namespaces[count.index]}",
"metrics-*-${local.hostnation_namespaces[count.index]}"
]
privileges = ["read", "view_index_metadata"]
}
}La autenticación se gestionaba mediante Keycloak SSO, con mapeos de roles de Elasticsearch que conectaban grupos de Keycloak con roles 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 telemetría del sistema operativo principal, Elastic Defend para detección y respuesta de endpoints, reenvío de eventos de Windows, registro de auditorías Auditd para Linux e integraciones de captura de paquetes de red. Eso es más de 400 políticas de integración gestionadas como código a través del proveedor Elastic Stack Terraform.
Una nota sobre Elastic Defend: debido a la efectividad de la protección de endpoint de Elastic —que es confiable en producción por el Departamento de Defensa de EE. UU. y el IC, lee más sobre ello aquí — y al hecho de que nadie en su sano juicio está quemando exploits de día cero en un ejercicio de entrenamiento, nos vemos obligados a limitar Elastic Defend desactivando el modo Preven, dejándolo solo en modo Detect. Teams recibe alertas cuando ocurre algo malicioso, pero sin una mitigación automática. También desactivamos completamente la Prevención y Detección de Amenazas de Memoria, ya que esto detecta la mayoría de los implantes y balizas del equipo atacante, lo que dañaría el juego para los Equipos Rojos. Hacia el final del ejercicio, permitimos a los equipos la libertad de usar Elastic Defend al máximo, pero no sin antes dejar que los Equipos Rojos lograran una fuerte posición.
También preinstalamos las reglas de detección preconstruidas de Elastic en cada espacio de equipo: el conjunto completo de Elastic Security Labs, actualizado continuamente en un repositorio abierto. Estas reglas se establecieron para cerciorar que solo consultaran índices que permitían las licencias con alcance de espacio de nombres del equipo, evitando 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 su índice predeterminado de Solución de Seguridad configurado para que las reglas de detección se ajustaran únicamente a los flujos de datos de ese equipo, en lugar del patrón general predeterminado de forma general. Esto se gestionaba mediante un null_resource de Terraform que llamaba a la API interna de configuración Kibana para establecer securitySolution:defaultIndex para cada espacio.
En su punto álgido, este despliegue consumía 800.000 eventos por segundo (EPS) en todos los 40 equipos. Es una cantidad considerable de datos, y el clúster lo gestionó cómodamente gracias a las capacidades de autoescalado de Elastic Cloud. Eso sí, en 2018 hacíamos 5 millones de eventos por segundo con eBay.
El ciclo de vida de los datos se gestionaba mediante una política de Gestión del Ciclo de Vida de Índices (ILM) que transfería los índices tras un día o 50 GB (lo que ocurriera primero), los trasladaba a una fase cálida tras dos días para optimización de solo lectura y fusión forzada, y luego eliminaba los datos a los diez días. Como resultado, los costos de almacenamiento se minimizaron manteniendo 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 del fragmento: Demostrar multi-tenencia a gran escala
Antes de comprometernos con esta arquitectura para un ejercicio militar en tiempo real, necesitábamos demostrar que podría cumplir con nuestros requisitos y disponer de un failover adecuado en caso de problemas. Pasar de despliegues individuales a un único clúster multi-inquilino introdujo riesgos reales: contención de recursos, cuellos de botella de ingestión, fuga de datos entre espacios debido a una mala configuración, grandes conteos de conexiones TCP en los nodos de Elasticsearch y un número de fragmentos significativamente mayor, ya que cada equipo genera su propio conjunto de índices.
Así que construimos un equipo de pruebas dedicado. El plan era sencillo: desplegar 50 Kibana Spaces, crear una política de agente en cada espacio, lanzar 6.000 instancias EC2 (120 por inquilino, en seis subredes en tres zonas de disponibilidad) y hacer pruebas de carga en el lote. Monitorizamos todo con AutoOps y Stack Monitoring.
El flujo de despliegue funcionaba así: Terraform creaba la VPC y las subredes en tres zonas de disponibilidad, aprovisionaba los 50 Kibana Spaces y sus políticas de flota con alcance espacial, generaba tokens de inscripción y luego lanzaba instancias EC2 en lotes. Cada instancia instalaba Elastic Agent al arrancar y se registraba contra su token específico de espacio.
Nos encontramos con algunos retos interesantes por el camino. El proveedor estándar de Terraform Elastic Stack no soportaba operaciones de flota conscientes del espacio en ese momento, así que lo bifurcamos y agregamos el manejo de ID de espacio a los recursos de la flota; sin esa modificación, cada agente se inscribió en el espacio predeterminado independientemente de la asignación de políticas. No era la primera vez que teníamos que extender el proveedor para un ejercicio; hace dos años, para DCM2, agregamos la elasticsearch_cluster_info fuente de datos. Afortunadamente, el proveedor upstream agregó desde entonces support for space_ids en la versión 0.12.2.
También nos encontramos con límites de tasa de la API de AWS EC2 al intentar poner en marcha las 6.000 instancias simultáneamente, así que agrupamos despliegues en 500 instancias con periodos de enfriamiento de cinco minutos entre lotes.
Los resultados fueron tranquilizadores. Los 6.000 agentes solían inscribir en 20 minutos tras el despliegue. En nuestras pruebas, el aislamiento de espacio funcionó como se esperaba, sin filtraciones de datos observadas entre inquilinos. Las actualizaciones de políticas de flota se propagaban a todos los agentes en 60 segundos. Las consultas de búsqueda con alcance a espacios individuales se mantenían rápidas bajo carga completa. Y la distribución multi-AZ demostró ser resistente durante fallos simulados en zonas de disponibilidad.
Estas pruebas nos dieron la confianza para comprometernos con la arquitectura del ejercicio en tiempo real.
Equipos rojos: Observabilidad del implante C2
Se estableció un despliegue separado y dedicado de Elastic para los Equipos Rojos, centrado en la observabilidad del implante de Mando y Control (C2). Esto daba a los equipos atacantes visibilidad de sus propias operaciones, incluyendo el estado del implante, las llamadas de baliza y el progreso operativo, sin riesgo de polinización cruzada con los datos del Equipo Azul. Los equipos rojos usaron Tuoni como su C2, que es un marco desarrollado por Clarified Security para el red teaming. En DCM3, trabajamos con Clarified Security para cerciorarnos de que soportara correctamente el Esquema Común de Elastic, facilitando mucho la integración futura con Elastic.
NSOC: Centro de Operaciones de Seguridad de Red de Ejercicios
El ejercicio principal, Centro de Operaciones de Seguridad de Red (NSOC), se desarrolló con su propio despliegue Elastic, proporcionando al personal de control del ejercicio una visión global del estado del rango, la monitorización de seguridad en toda la infraestructura y, de manera crítica, el registro de auditorías de todos los servicios de IA que desplegamos. Cada invocación de la API de Bedrock estaba registrada en CloudWatch y era observable en este despliegue, lo que significaba que el NSOC tenía visibilidad completa sobre lo que se pedía a los agentes de IA y por quiénes lo hacían . Más sobre esto en la sección de IA más abajo.
Automatización de infraestructuras: Terraform y Catapult
Todo lo que viste antes se gestiona 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 gestionada por Terraform fue considerable: un despliegue de Elastic Cloud con escalado automático, 40 Kibana Spaces, políticas de agentes 120 Fleet (tres por equipo), 400+ políticas de integración, roles de seguridad 40 Kibana, mapeos de roles 40 Keycloak, políticas ILM para retención de datos 41 usuarios AWS IAM para conectores GenAI de Bedrock (uno por espacio de equipo más un predeterminado). 41 conectores de acción Kibana GenAI, barreras AWS Bedrock, túneles Cloudflare Zero Trust para acceso a Tines, conectores de acción Tines por espacio de equipo, cuentas de servicios de detección almacenadas en HashiCorp Vault y configuración predeterminada de índice de Security Solution por espacio. Todo el estado se almacenaba en un backend S3 cifrado.
Para el despliegue de agentes y proxy en los sistemas reales de rango, usamos Catapult, una excelente herramienta de código abierto creada por el equipo de Clarified Security. Catapult envuelve Ansible con un modelo de ejecución basado en contenedores diseñado específicamente para despliegues en rangos cibernéticos. Se encargaba de la instalación e inscripción de Agentes Elásticos en toda la infraestructura del campo. La configuración de los servidores proxy (cada equipo tenía un proxy Squid dedicado para su red desplegada, esto era para simular un único punto de emisión, tal como sería en el mundo real). El tráfico se enrutaba a través de puntos finales como http://elastic-proxy.dsoc.XX.dcm.ex:3128), y el despliegue de túneles Cloudflare para la conectividad Tines.
Durante la provisionación, Terraform escribió lo siguiente en HashiCorp Vault y fue consumido por Catapult: credenciales, tokens de inscripción, claves API, configuraciones de proxy, credenciales de cuentas de servicio Tines... Las rutas de Vault seguían una estructura consistente como dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployed y dcm/gt/elastic/tines-sa/tines-sa-btXX, lo que facilitaba que los libros de jugadas de Catapult obtuvieran las credenciales adecuadas para cada equipo.
Formación: preparar equipos para el éxito
Desplegar la plataforma es una cosa; Cerciorar de que la gente pueda usarlo realmente es otra cosa. Proporcionamos formación en el campo de práctica, dirigida por un instructor, a los Equipos Azules durante la fase previa al ejercicio. Esto abarcaba los fundamentos de Elastic Security , cómo navegar por su espacio de equipo en Kibana, trabajar con las reglas de detección predefinidas, usar Discover para análisis de registros y búsqueda de amenazas, crear paneles personalizados, entender las alertas de Elastic Defend y familiarizar con la herramienta de investigación Timeline.
La instrucción del ejercicio señalaba que esta formación era opcional pero "altamente recomendada", y por lo que vimos, los equipos asistentes empezaron a trabajar con fuerza desde el primer día de la ejecución. La formación y la habilitación son tan importantes como el propio despliegue tecnológico. Entregar a un equipo herramientas de seguridad de nivel empresarial que no saben usar no fue útil para nadie.
El servicio de IA en el campo de tiro: cumple, auditado, protegido
Este año marcó nuestro debut proporcionando acceso por IA a la gama DCM. Proporcionamos un servicio de IA conforme directamente en la gama, respaldado por modelos AWS Bedrock con contrato en Reino Unido, concretamente Claude 3.7 Sonnet que funciona en la región eu-west-2 (Londres). Esto no era IA por el bien de la IA; era un servicio cuidadosamente diseñado con barandillas, registro completo de auditorías y controles de acceso compatibles con RBAC. Se nos confió la gestión de este servicio debido a la experiencia de Elastic en el ámbito de la IA.
El servicio de IA tenía varios usuarios en el campo, y esta es una distinción importante. El conector Bedrock conforme que proporcionamos en el espacio de cada equipo no solo alimentaba a nuestros agentes personalizados, sino que también impulsaba las funciones nativas de IA de Elastic, específicamente:
Elastic AI Assistant para Security
El Asistente de IA Elástico estaba disponible en todos los espacios de Blue Team, conectado a nuestro conector Bedrock en el rango. Esto proporcionó a los equipos una interfaz de chat contextual directamente dentro de Elastic Security, donde podían hacer preguntas sobre sus alertas y recibir ayuda para escribir ES|Consultas QL, investiga procesos sospechosos y recibe pasos guiados de remediación. El Asistente de IA emplea Generación Aumentada por Recuperación (RAG) con la función Base de Conocimiento de Elastic, que está prepoblada con artículos de Elastic Security Labs. Los equipos también podían agregar sus propios documentos, como procedimientos operativos estándar específicos por rango, inteligencia de amenazas o notas del equipo, a la Base de Conocimiento para fundamentar aún más las respuestas del asistente en su contexto operativo.
Lo que hacía esto especialmente valioso en el contexto del ejercicio era la capacidad del Asistente de IA para ayudar a analistas menos experimentados a entender lo que estaban viendo. Un analista junior que se enfrenta a su primera baliza de implante activa podría pedir 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 cercioraba que los valores sensibles de los campos pudieran ser ofuscados antes de enviarlos al proveedor del LLM.
Descubrimiento de ataques elásticos
Attack Discovery fue otro consumidor importante de nuestro servicio de IA en rango. El Descubrimiento de Ataques emplea LLMs para analizar alertas en el entorno de un equipo e identificar amenazas correlacionando alertas, comportamientos y rutas de ataque. Cada "descubrimiento" representa un posible ataque y describe las relaciones entre múltiples alertas: indicando a los equipos qué usuarios y anfitriones están implicados, cómo se corresponden las alertas con la matriz MITRE ATT&CK y qué actor de amenaza podría ser responsable.
Para un ejercicio cibernético en el que los Red Teams lanzaron activamente ataques coordinados, Attack Discovery fue transformador. En lugar de triar manualmente cientos de alertas individuales, los Equipos Azules podrían ejecutar el Descubrimiento de Ataques para sacar a la luz las narrativas de ataque de alto nivel, por ejemplo, "estas alertas 15 forman parte de una cadena de movimiento lateral del anfitrión X al anfitrión Y, probablemente por el actor de amenaza Z", y centrar su tiempo de investigación donde más importaba. Es el tipo de capacidad que reduce directamente el tiempo medio de respuesta y combate la fatiga de alerta, que es precisamente lo que necesitas cuando estás bajo ataque sostenido durante cinco días seguidos.
Los agentes de IA personalizados: Elastic Agent Builder
Más allá de las funciones nativas de Elastic AI, creamos tres agentes de IA a medida usando Elastic Agent Builder. Agent Builder es el framework de Elastic para crear agentes de IA personalizados que combinan instrucciones de LLM con herramientas modulares y reutilizables, cada una de ellas un ES|Consulta QL, una capacidad de búsqueda integrada, ejecución de flujo de trabajo o una integración externa mediante MCP. Los agentes analizan las solicitudes en lenguaje natural, seleccionan las herramientas adecuadas, las ejecutan e iteran hasta que puedan proporcionar una respuesta completa, todo ello mientras gestionan el contexto con los datos dentro de Elasticsearch. Puedes leer más sobre el framework en la documentación de Agent Builder y en la investigación profunda 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 persona, capacidades y límites de comportamiento del agente. Cada agente tiene un 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 emplean para buscar, recuperar y manipular datos de Elasticsearch. Construimos ES| personalizadosHerramientas QL que consultaban índices específicos que contenían documentación de ejercicios, manuales e reportes.
Chat de agentes: La interfaz conversacional —tanto la interfaz integrada de Kibana como la API programática— que los participantes empleaban para interactuar con los agentes.
Las configuraciones de agentes y herramientas se definen como JSON y se gestionan a través de las APIs de Agent Builder, haciendo que todo el ciclo de vida del agente —desde la ingeniería de prompts hasta la asignación de herramientas— sea reproducible y controlable por versión. Compartiremos la configuración de los agentes de GrantPT y las definiciones de herramientas en una publicación de seguimiento para quienes quieran replicar este enfoque: estén atentos.
Esto es lo que hizo cada agente:
1. GrantPT - El asistente de propósito general
Disponible para los ~2.500 participantes del ejercicio, GrantPT fue nuestro agente principal de IA y la mejor demostración de lo sencillo que es crear un asistente capaz y específico para cada dominio. La configuración del agente consistía en un objeto JSON que definía su indicador de sistema, persona y una matriz de IDs de herramientas asignados, y nada más. No hay código de aplicación personalizado, ni capa API a medida, solo configuración declarativa.
Lo que dio profundidad a GrantPT fue la herramienta. Definimos una combinación de herramientas de plataforma integradas y ES| personalizadoHerramientas QL, cada una registrada con una descripción, una consulta parametrizada y definiciones de parámetros tipados. Por ejemplo, la herramienta de base de conocimiento aceptaba un target_index y un parámetro query semántico, ejecutando un ES| parametrizadoConsulta QL contra nuestros índices de dcm5-grantpt-* con clasificación semántica en búsqueda:
FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10Una herramienta separada de descubrimiento de índices permitía al agente enumerar dinámicamente los índices disponibles de la base de conocimiento 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; simplemente los descubriría en la siguiente interacción.
También desarrollamos una herramienta de integración con Jira que realizaba búsqueda semántica en tiquetes de soporte ingeridos, permitiendo a GrantPT sacar a la luz el contexto relevante de resolución de problemas de solicitudes de soporte previas. Esto fue especialmente útil para los Analistas de HelpDesk, que podían preguntar a GrantPT sobre problemas recurrentes y obtener respuestas basadas en el historial real de tiquetes en lugar de en una guía genérica.
El comportamiento de respuesta adaptado a RBAC surgió de una combinación del prompt del sistema del agente, que le indicaba contextualizar las respuestas según el rol del usuario, y el modelo de seguridad subyacente de Elasticsearch. Porque el ES| de cada herramientaLa consulta QL 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 por los procedimientos de ejercicio obtendría resultados asignados a los índices accesibles de su equipo, mientras que un analista de HelpDesk vería resultados de índices específicos del helpdesk. El agente no necesitaba una lógica explícita de cambio de roles; La seguridad nativa a nivel de documento de Elasticsearch gestionaba el alcance, y el agente simplemente trabajaba con los resultados que se devolvían. Esto es una de las cosas que hace que Agent Builder sea realmente elegante: al heredar el modelo de seguridad de Elasticsearch, obtienes una IA compatible con RBAC sin necesidad de escribir ni una sola línea de código de autorización.
2. REDRock - El colega del adversario
Este agente estaba disponible exclusivamente para Red Teams. REDRock siguió el mismo patrón de Agent Builder, un prompt dedicado al sistema que definía su persona adversarial, vinculado a su propio conjunto de ES| personalizadosHerramientas QL consultando índices específicos de Red Team. Estos índices contenían los libros de jugadas del Equipo Rojo, documentación de Tuoni C2, vulnerabilidades conocidas del sistema dentro del entorno de rango e información sobre los servicios desplegados. Las definiciones de las herramientas reflejaban el mismo patrón de búsqueda semántica parametrizado usado por GrantPT, pero estaban restringidas a índices accesibles solo para roles del Red Team. Los operadores del Red Team podían consultar vectores de ataque, comprobar debilidades conocidas en los sistemas objetivo y obtener orientación contextual sobre sus planes operativos. Era, francamente, como dar a los atacantes un oficial de operaciones extremadamente bien informado.
3. RefPT - La herramienta del árbitro
Diseñado específicamente para el Equipo Blanco (los árbitros y evaluadores del ejercicio), RefPT estaba vinculado a herramientas que consultaban índices que contenían reportes del Equipo Azul, eventos de escenarios y criterios de puntaje. Su propósito era garantizar un puntaje uniforme y justo en los equipos de 40+. El prompt del sistema del agente se ajustó para cruzar los reportes enviados con eventos de escenario conocidos y rúbricas de puntaje, ayudando a los evaluadores a identificar inconsistencias o lagunas. Cuando tienes evaluadores evaluando decenas de equipos simultáneamente, contar con una IA que pueda correlacionar reportes con un índice de puntaje estructurado es realmente transformador para la coherencia.
Tines: automatización de flujos de trabajo impulsada por IA
Tines también fue consumidor del servicio de IA en el rango de juego. Cada Equipo Azul tenía una instancia dedicada de Tines, con conectores de acción de Tines provisionados en su espacio Kibana. Tines podría aprovechar las capacidades de IA respaldadas por Bedrock para la automatización inteligente de flujos de trabajo, como el enriquecimiento automatizado de alertas, decisiones de triaje asistidas por IA, resúmenes en lenguaje natural en flujos de trabajo de notificaciones y creación de flujos de trabajo en lenguaje natural. El conector Tines se configuraba por equipo con las 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: Medidas de seguridad y auditoría
Cada interacción con IA entre todos estos consumidores estaba regida por estrictas Baserock Guardrails de AWS. Desplegamos barreras de seguridad con filtrado de contenido (odio, insultos, contenido sexual y violencia en los umbrales de MEDIUM), protección de la PII (bloqueo de direcciones de email, 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 temático para evitar la discusión de operaciones clasificadas reales y filtrado de palabrotas. Aquí tienes un fragmento de la configuración de la barandilla de nuestro Terraform:
resource "aws_bedrock_guardrail" "dcm5_elastic" {
name = "dcm5-prod-elastic-guardrail"
description = "Guardrails for DCM5 Prod Elastic Kibana GenAI connectors"
content_policy_config {
filters_config {
input_strength = "MEDIUM"
output_strength = "MEDIUM"
type = "HATE"
}
# ... additional content filters for INSULTS, SEXUAL, VIOLENCE
}
sensitive_information_policy_config {
pii_entities_config {
action = "BLOCK"
type = "UK_NATIONAL_INSURANCE_NUMBER"
}
pii_entities_config {
action = "BLOCK"
type = "IP_ADDRESS"
}
# ... additional PII filters
}
topic_policy_config {
topics_config {
name = "classified-information"
definition = "Discussions about actual classified operations, current real-world military activities, or operational intelligence."
type = "DENY"
}
}
}Cada espacio de Blue Team tenía su propio usuario IAM para el acceso a Bedrock, y la configuración genAiSettings:defaultAIConnectorOnly Kibana se aplicó para evitar que los equipos configuraran sus propios conectores. Esto significaba que cada llamada a la API podía rastrear hasta un equipo específico a través de CloudWatch, y el NSOC tenía total visibilidad de auditoría. El grupo de registro de CloudWatch /aws/bedrock/grantpt-prod/invocations capturado cada evento de invocación y barrera de seguridad.
Las cifras de todos los consumidores de IA hablan por sí mismas: 3 agentes de IA personalizados, 2.797 conversaciones y 785 millones de tokens de IA consumidos durante todo el ejercicio.
Monitorización 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 campo. Cada Equipo Azul tenía su propio canal, la posibilidad de enviar mensajes directos a cualquiera que estuviera en el ejercicio y la libertad de crear nuevos canales según fuera necesario. Lo más crítico para la tradición DCM fue que esto incluía el canal de memes: la columna vertebral espiritual de todas las bromas internas y el humor creativo que eleva la moral y que inevitablemente surge cuando pones bajo presión a unos pocos miles de operadores cibernéticos durante una semana.
Todos estos datos de comunicación representaron una brillante ventana en tiempo real sobre la salud del rango, el sentimiento del equipo y los temas que se están moviendo en el ejercicio. Se sentía demasiado bien como para dejarla pasar, así que absorbimos todo el corpus de conversación de RocketChat en tiempo real en Elastic y lo pusimos a trabajar.
Análisis de sentimiento y reconocimiento de entidades nombradas
Para el reconocimiento de entidades nombradas, desplegamos el modelo dslim/bert-base-NER de Hugging Face en un nodo de aprendizaje automático en el despliegue NSOC usando el cliente Elastic ELAND. Esto se conectaba a una tubería de ingesta de Elasticsearch por la que pasaba cada mensaje de RocketChat al ingerir. Tomamos las entidades extraídas y pusimos a la luz las más comunes como temas de panel de control, dándonos una visión en directo del flujo y reflujo de los temas de conversación a lo largo del ejercicio.
También analizamos la actividad del grupo, las estadísticas de usuarios y los patrones generales de comunicación para construir 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 adaptadas por usuarios individuales. En conjunto, nos dio una visión realmente interesante de lo que ocurría en el campo de tiro en tiempo casi real. Por ejemplo, cuando cambiamos Elastic Agent a modo Preven, una nube de palabras en nuestro panel de control se iluminó inmediatamente con "Elastic" como el tema más comentado en todos los canales: los Equipos Azules hablando de su efectividad, los Equipos Rojos lamentando la pérdida de sus beacons. Bastante satisfactorio, eso.
Análisis de memes (sí, de verdad)
Por fin —y este levantó algunas cejas— seleccionamos todos los memes enviados a los canales, vectorizamos las imágenes y realizamos evaluaciones de vecinos más cercanos para agrupar memes y temas similares. También los pasamos por el modelo de inferencia NER de disparo cero para generar descripciones temáticas del contenido de cada meme. La lógica era que estas salidas podrían ser útiles más adelante para filtrar, moderar u otras interacciones dentro del juego. Si el análisis de memes produjo inteligencia operativamente crítica es discutible. Si fue divertido o no.
Cortar problemas de raíz
Por mucho que esperáramos que todo funcionara bien durante la semana de ejercicio, inevitablemente las cosas se dañan, no se entienden del todo o necesitan personalizaciones adicionales para adaptar a cómo quiere usarlas un equipo en individuo. Para esto, teníamos nuestra propia subsección del helpdesk de in-range donde cualquier equipo podía plantear solicitudes específicas de Elastic y GenAI.
Gestionamos este soporte durante toda la duración del ejercicio, proporcionando orientación, documentación, depuración de incidencias y recomendaciones específicas por rango. Ese último punto merece la pena ampliarlo. A veces, lo que un Equipo Azul veía en Elastic no era realmente un problema de Elastic, sino que Elastic mostraba fielmente algo en el campo que merecía una investigación más profunda (los Equipos Rojos pueden causar un caos absoluto, y la telemetría no miente). A lo largo del ejercicio, cubrimos 125 solicitudes individuales de soporte de equipos que aplicar específicamente ayuda a nosotros en Elastic.
Depuración preventiva con Tines
Más allá de visitar equipos a través de VTC o en persona en EXCON, también trabajamos con Tines para probar algo un poco más proactivo. Extrajimos el cuerpo de tiquetes de las solicitudes entrantes, intentamos categorizar el problema, ejecutamos la categorización contra nuestro corpus de tiquetes previamente resueltos y pedimos a GenAI que produjera una respuesta resumida de primer paso destinada a resolver el problema del usuario antes de que el triaje lo llevara a nuestra cola.
Este es en realidad un patrón que tomamos prestado de nuestra propia organización de soporte en Elastic, donde proporcionamos una capacidad similar empleando nuestra amplia base de conocimientos de problemas previamente resueltos como repositorio para el contexto de soporte de AI Agent. La idea es sencilla: usar soluciones anteriores para dar un primer intento generado por la máquina e informado para resolver un problema, y cortar la necesidad de que un ingeniero de soporte responda manualmente a cada tiquete. No lo solucionó todo; Algunos problemas realmente necesitaban un humano con contexto de alcance, pero eso redujo significativamente la presión en la cola y consiguió respuestas más rápidas a los equipos que las necesitaban. Esto fue un éxito tan grande con nuestros propios tiquetes y cola específicos que en la última parte del ejercicio extendimos el mandato a todo el helpdesk, ayudando a reducir la carga sobre los otros grupos del equipo Verde que apoyaban el ejercicio.
Alianzas con la industria: Mejor juntos
Una de las cosas de las que más orgullosos estamos es de cómo nuestro ecosistema de colaboración creció año tras año. DCM no es solo un programa elástico; Es una auténtica coalición de socios industriales, cada uno aportando algo único a la plataforma de seguridad.
Año 1 (DCM2) - Elastic se unió como socio industrial, proporcionando la plataforma de monitorización de seguridad y detección de endpoints.
Año 2 (DCM3) - Incorporamos Endace, que proporciona capacidad de captura de paquetes 1:1. La captura completa de paquetes junto con la visibilidad de red de Elastic dio a los equipos la capacidad de realizar análisis forenses profundos que el análisis basado en registros por sí solo no puede proporcionar.
Año 3 (DCM4) - Tines se unió a la familia, aportando la automatización de flujos de trabajo a la mesa. Blue Teams podía ahora construir manuales de respuesta automatizada, flujos de trabajo de triaje y cadenas de notificaciones, todo integrado directamente en su entorno Elastic a través del conector nativo de Tines.
Año 4 (DCM26, anteriormente DCM5) - AWS se incorporó, proporcionando acceso a Bedrock para nuestros agentes de IA y contribuyendo con fondos para los despliegues de Elastic. Esto fue un hito importante; tener un hiperescalador invertido directamente en el éxito del ejercicio desbloqueaba capacidades (como inferencias de IA conformes y con contratos británicos y control total de control) que simplemente no fueron posibles de otro modo. La integración de Tines este año también se vio reforzada con la incorporación de acceso en campo a los LLM. El serial DCM también alcanzó un hito este año, pasando de ser una iniciativa de la Army Cyber Association a convertir en un programa financiado oficialmente bajo el Mando de Operaciones Cibernéticas y Especializadas.
A los equipos de Endace, Tines y AWS, muchas gracias. Este ejercicio es mejor gracias a vuestras contribuciones, y todos los equipos están mejor equipados gracias a la plataforma que construimos juntos. Ya estamos planeando para DCM27. Salud por todos vosotros.
Cultura, momentos destacados y las partes que lo hacen merecedor
Las Monedas Desafío
Teníamos monedas de desafío personalizadas acuñadas para DCM26. Si sabes, sabes, las monedas de desafío son una tradición militar de larga data, y que una fuera hecha para el ejercicio me pareció la forma correcta de conmemorar nuestro cuarto año de participación.
La fiesta de cóctel
También agradecimos ser invitados a la fiesta de cóctel de la Alta Comisión organizada por el Alto Comisionado británico en Singapur. Hay algo bastante surrealista en hablar sobre el conteo de fragmentos de Elasticsearch y la gestión del estado de Terraform mientras sostienes un gin tonic por invitación del embajador. Fue una velada brillante, un recordatorio genuino de que estos ejercicios existen en la intersección entre tecnología y diplomacia, y que las relaciones que aquí se construyen van mucho más allá de lo técnico.
Wrapping up
La arquitectura multi-inquilino demostró ser eficaz bajo carga sostenida; las funciones nativas de Elastic AI (AI Assistant y Attack Discovery) daban a los equipos capacidades que hace unos años fueron ciencia ficción; y los agentes de IA personalizada superaron nuestras expectativas de adopción. El modelo de asociación sigue 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 iteración emblemática de un ejercicio que sigue creciendo en ambición, complejidad e impacto. Para Elastic, confiar en que proporcione la plataforma central de seguridad defensiva para 40 Equipos Azules de 29 países, y este año también la capacidad de IA, es algo que no tomamos a la ligera. El ejercicio desarrolla habilidades reales para personas reales que luego defenderán redes reales, y formar parte de esa misión es realmente significativo.
Como expresó el comunicado de prensa del Gobierno del Reino Unido , la DCM demuestra el valor práctico de escenarios reales que refuerzan las asociaciones internacionales. No podríamos estar más de acuerdo.
Volveremos el año que viene, y sospecho que tendremos aún más de qué hablar. Mientras tanto, seguiremos mejorando el producto para que el soporte para entornos como Defence Cyber Marvel destaque año tras año.
Nos vemos en el campo de tiro.
Sigue la historia de DCM26 en redes sociales:
Facebook (en inglés) | LinkedIn (en inglés) | Instagram
Lecturas adicionales
Seguridad elástica e IA
- Elastic Security - La plataforma que impulsa los despliegues del Blue Team
- AI Assistant for Security - Chat de IA consciente del contexto dentro de Elastic Security
- Descubrimiento de Ataques - Correlación de alertas y generación de narrativas de amenazas impulsadas por LLM
- Agent Builder - Marco para crear agentes de IA personalizados con Elasticsearch
Infraestructura y herramientas
- Proveedor de Terraform de Elastic Stack - Infraestructura como código para la pila elástica
- Elastic Fleet Guide - Gestión centralizada de Agentes Elásticos a gran escala
- Catapulta por Clarified Security - Provisión de rango cibernético basada en Ansible
Contexto del ejercicio
- Comunicado de prensa DCM26 del Gobierno del Reino Unido - Resumen oficial del ejercicio