Par où commencer ? Pour la quatrième année consécutive, Elastic a eu le privilège d'être un partenaire industriel de confiance dans le cadre de l'exercice Defence Cyber Marvel, la série d'exercices cybernétiques phare du ministère britannique de la défense. DCM26 a été, sans aucun doute, l'itération la plus ambitieuse à ce jour, et nous sommes ravis de pouvoir enfin parler de ce que nous avons construit, de la manière dont nous l'avons construit et de ce que nous avons appris en cours de route.
Qu'est-ce que la défense Cyber Marvel ?
Pour ceux qui ne connaissent pas, Defence Cyber Marvel (DCM) est la plus grande série d'exercices cybernétiques de l'armée britannique qui se concentre sur la défense des réseaux informatiques traditionnels, des environnements d'entreprise et des systèmes de contrôle industriel complexes dans des scénarios réalistes et sous haute pression. Il met en avant une cyberpuissance responsable tout en améliorant la préparation, l'interopérabilité et la résilience au sein de la défense et des nations alliées. Le DCM, qui en est à sa cinquième année d'existence, est passé d'une initiative de l'association cybernétique de l'armée à une opération tripartite dirigée par le commandement des opérations cybernétiques et spécialisées (CSOC).
Le gouvernement britannique a publié un communiqué de presse officiel pour DCM26, qui donne un excellent aperçu de l'importance stratégique de l'exercice. Comme l'a fait remarquer le haut-commissaire britannique à Singapour, cet exercice témoigne de la coopération étroite entre le Royaume-Uni et des partenaires de confiance, et rappelle la force des partenariats stratégiques partagés dans un contexte de sécurité de plus en plus complexe.
Au fond, le DCM est un exercice cybernétique force contre force : les équipes bleues qui se défendent protègent les réseaux et les infrastructures qui leur ont été attribués contre les équipes rouges qui attaquent, en utilisant toute une série de techniques. Les activités vont de la modification des mots de passe par défaut et du renforcement des pare-feux au déploiement d'une cyberdéfense de niveau entreprise, alimentée par l'IA, avec Elastic Security. Les activités de chaque équipe sont contrôlées par l'équipe blanche afin d'établir un score tenant compte de la disponibilité du système, de la détection des attaques, du signalement des incidents et de la restauration du système. Il met à l'épreuve les équipes les plus expérimentées tout en facilitant un mécanisme de formation unique pour les équipes juniors lors de leur première exposition à un champ de tir cybernétique, et c'est ce double objectif qui fait de la DCM un exercice si précieux.
L'échelle de DCM26
Le DCM26 a rassemblé plus de 2 500 personnes provenant de 29 pays participants et de 70 organisations, sous la coordination d'un centre de contrôle de l'exercice (EXCON) basé à Singapour, EXCON accueillant plus de 600 participants. L'exercice s'est déroulé dans un environnement informatique hybride couvrant la zone cybernétique CR14 et AWS, hébergeant plus de 5 000 systèmes virtuels.
L'exercice proprement dit s'est déroulé sur cinq jours (du 9 au 13 février 2026), précédé d'une formation préalable facultative dispensée par un instructeur et de vérifications de la connectivité. Le scénario, basé sur l'environnement opérationnel indo-pacifique de l'académie de formation à la défense (DATE), plaçait les équipes en tant qu'équipes de protection cybernétique défendant les systèmes militaires déployés au cours d'une crise régionale qui s'intensifiait. Les équipes bleues étaient géographiquement dispersées, certaines dans leur pays d'origine au Royaume-Uni et à l'étranger, d'autres déployées à l'étranger, toutes connectées au champ de tir via un VPN.
Parmi les participants figuraient des représentants de la défense britannique, de départements intergouvernementaux tels que la National Crime Agency, le Department for Work and Pensions, le Cabinet Office et le Department for Business and Trade, ainsi que des partenaires internationaux formant jusqu'à 40 équipes. Après le succès de l'exercice de l'année dernière en République de Corée, Singapour a servi de plaque tournante à l'exercice pour la première fois, reflétant l'engagement du Royaume-Uni à approfondir la coopération avec les partenaires de l'Indo-Pacifique sur les défis communs en matière de sécurité.
En bref, il s'agit d'un exercice sérieux. Haute pression, force contre force, avec des conséquences réelles pour la notation et des résultats d'apprentissage réels pour chaque participant.
Les déploiements : Notre infrastructure Elastic
L'infrastructure de cette année a représenté une évolution architecturale significative par rapport aux itérations précédentes. Plutôt que de déployer des clusters Elastic Cloud individuels par équipe, nous avons opté pour un déploiement Elastic Cloud unique, basé sur l'espace, avec plusieurs locataires, pour les équipes bleues. Nous avons également assuré des déploiements pour des fonctions en dehors des équipes bleues. Permettez-moi d'analyser chaque déploiement et sa raison d'être.
Blue Teams : Sécurité Elastique Multi-tenant
La pièce maîtresse de notre contribution a été un déploiement Elastic Cloud unique desservant toutes les équipes bleues défendant 40 , séparées à l'aide d'espaces Kibana et d'espaces de noms de flux de données. Chacune des équipes 39 disposait de son propre espace de travail isolé, comprenant des tableaux de bord, des agents et des règles de détection.
Voici à quoi ressemblait la ressource Terraform pour créer l'espace de chaque équipe :
# 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"
}L'espace de chaque équipe a reçu un ensemble dédié de trois politiques d'agent de la flotte: le jour 1, une politique de réseau déployé, le jour 2, une politique de réseau Host Nation, et enfin une politique PacketCapture pour la surveillance du trafic réseau. Le contrôle d'accès progressif était d'une simplicité élégante : l'installation de enable_hostnation_network = true sur notre site terraform.tfvars et l'exécution de terraform apply ont permis d'étendre les autorisations de rôle de chaque équipe et de rendre la politique de l'agent de la nation hôte visible dans leur espace. L'exercice est passé d'un réseau à deux sans un seul clic manuel dans Kibana.
L'isolation des données repose sur les espaces de noms des flux de données. Chaque politique d'agent est écrite dans des espaces de noms spécifiques à l'équipe, tels que bt_01_deployed et bt_01_hostnation, produisant des flux de données suivant le modèle :
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_hostnationLe rôle de sécurité Kibana de chaque équipe a ensuite été limité à ces flux de données à l'aide de blocs de privilèges d'indexation dynamiques :
# 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"]
}
}L'authentification a été gérée via Keycloak SSO, avec des mappages de rôles Elasticsearch reliant les groupes Keycloak aux rôles 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]}"
}
})
}Les politiques d'intégration par défaut étaient simples de par leur conception. Chaque équipe a reçu : System pour la télémétrie du système d'exploitation principal, Elastic Defend pour la détection et la réponse aux points d'extrémité, le transfert d'événements Windows, Auditd pour l'enregistrement des audits Linux et les intégrations de Network Packet Capture. Cela représente plus de 400 politiques d'intégration gérées en tant que code via le fournisseur Elastic Stack Terraform.
Une note sur Elastic Defend : en raison de l'efficacité de la protection des points finaux d'Elastic - qui est utilisée en production par le Département de la défense et le Comité international de la défense des États-Unis, pour en savoir plus, cliquez ici - et du fait que personne de sensé ne brûle des exploits de type "zero-day" lors d'un exercice d'entraînement, nous sommes obligés d'adapter Elastic Defend en désactivant le mode "Prevent" et en le laissant en mode "Detect-only" (Détection uniquement). Les équipes reçoivent des alertes lorsque quelque chose de malveillant se produit, mais aucune mesure d'atténuation automatique n'est prévue. Nous désactivons également complètement la prévention et la détection des menaces en mémoire, car elles permettent de découvrir la majorité des implants et des balises de l'équipe attaquante, ce qui risquerait de gâcher la partie pour les équipes rouges. Vers la fin de l'exercice, nous avons donné aux équipes la liberté d'utiliser Elastic Defend au maximum de ses capacités, mais pas avant d'avoir laissé les équipes rouges prendre pied.
Nous avons également préinstallé les règles de détection prédéfinies d'Elastic dans chaque espace d'équipe - l'ensemble complet d'Elastic Security Labs, continuellement mis à jour dans un référentiel ouvert. Ces règles ont été configurées de manière à ce qu'elles n'interrogent que les index que les autorisations de l'espace de noms de l'équipe autorisent, afin d'éviter toute fuite de données entre les équipes lors de l'exécution des règles de détection.
En outre, l'index par défaut de la solution de sécurité de chaque espace d'équipe a été configuré pour étendre les règles de détection aux seuls flux de données de cette équipe, au lieu du modèle général par défaut. Cela a été géré par un Terraform null_resource qui a appelé l'API des paramètres internes de Kibana pour définir securitySolution:defaultIndex pour chaque espace.
À son apogée, ce déploiement a ingéré 800 000 événements par seconde (EPS) pour l'ensemble des équipes de 40 . Il s'agit d'une quantité importante de données, et le cluster l'a gérée confortablement grâce aux capacités de mise à l'échelle automatique d'Elastic Cloud. Cela dit, à l'époque, sur 2018 , nous faisions 5 millions d'événements par seconde avec eBay.
Le cycle de vie des données a été géré par une politique de gestion du cycle de vie des index (ILM) qui a permis de renouveler les index au bout d'un jour ou de 50 Go (selon la première éventualité), de les faire passer à une phase chaude au bout de deux jours pour une optimisation en lecture seule et une fusion forcée, puis de supprimer les données au bout de dix jours. Par conséquent, les coûts de stockage ont été minimisés tout en maintenant les exigences de la fenêtre d'exercice. Vous trouverez ci-dessous un exemple de mise en œuvre de la politique d'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
}
}
}Le test de résistance des barrettes : La preuve de la multi-location à l'échelle
Avant de nous engager dans cette architecture pour un exercice militaire réel, nous devions prouver qu'elle serait en mesure de répondre à nos exigences et qu'elle disposerait d'un basculement approprié en cas de problèmes. Le passage de déploiements individuels à un seul cluster multi-locataires a introduit des risques réels : contention des ressources, goulets d'étranglement au niveau de l'ingestion, fuites de données entre les espaces en raison d'une mauvaise configuration, nombre élevé de connexions TCP sur les nœuds Elasticsearch, et un nombre beaucoup plus important de shards puisque chaque équipe génère son propre ensemble d'indices.
Nous avons donc construit un banc d'essai dédié. Le plan était simple : déployer 50 Kibana Spaces, créer une politique d'agent dans chaque espace, lancer 6 000 instances EC2 (120 par locataire, sur six sous-réseaux dans trois zones de disponibilité) et tester la charge du lot. Nous avons tout surveillé avec AutoOps et Stack Monitoring.
Le flux de déploiement s'est déroulé comme suit : Terraform a créé le VPC et les sous-réseaux dans trois zones de disponibilité, a provisionné les espaces Kibana 50 et leurs politiques Fleet adaptées à l'espace, a généré des jetons d'inscription, puis a lancé des instances EC2 par lots. Chaque instance a installé Elastic Agent au démarrage et s'est inscrite par rapport à son jeton spécifique à l'espace.
Nous avons rencontré des difficultés intéressantes en cours de route. Le fournisseur Terraform Elastic Stack standard ne prenait pas en charge les opérations de flotte tenant compte de l'espace à l'époque, nous l'avons donc forké et avons ajouté la gestion des identifiants d'espace aux ressources de la flotte - sans cette modification, chaque agent se serait inscrit dans l'espace par défaut sans tenir compte de l'affectation de la politique. Ce n'était pas la première fois que nous devions étendre le fournisseur pour un exercice ; il y a deux ans, pour DCM2, nous avions ajouté la source de données elasticsearch_cluster_info. Heureusement, le fournisseur en amont a depuis ajouté support for space_ids dans la version 0.12.2.
Nous nous sommes également heurtés aux limites de débit de l'API AWS EC2 lorsque nous avons essayé d'activer les 6 000 instances simultanément. Nous avons donc procédé à des déploiements par lots à l'adresse 500 , avec des périodes de refroidissement de cinq minutes entre les lots.
Les résultats sont rassurants. Les 6 000 agents ont généralement été inscrits dans les 20 minutes suivant le déploiement. Lors de nos tests, l'isolation de l'espace a fonctionné comme prévu et aucune fuite de données n'a été observée entre les locataires. Les mises à jour de la politique de la flotte sont propagées à tous les agents dans un délai de 60 secondes. Les requêtes de recherche portant sur des espaces individuels sont restées rapides à pleine charge. De plus, la distribution multi-zones s'est avérée résistante lors de simulations de défaillances de zones de disponibilité.
Ce test nous a donné la confiance nécessaire pour nous engager dans l'architecture pour l'exercice en direct.
Équipes rouges : L'observabilité de l'implantation C2
Un déploiement Elastic distinct et dédié a été mis en place pour les équipes rouges, axé sur l'observabilité des implantations de commandement et de contrôle (C2). Cela a permis aux équipes d'attaque d'avoir une visibilité sur leurs propres opérations, y compris l'état des implants, les rappels de balises et les progrès opérationnels, sans risque de pollinisation croisée avec les données de l'équipe bleue. Les équipes rouges ont utilisé Tuoni comme C2, un cadre développé par Clarified Security pour les équipes rouges. Dans le DCM3, nous avons travaillé avec Clarified Security pour nous assurer qu'il supportait correctement le schéma commun Elastic, facilitant ainsi l'intégration future avec Elastic.
NSOC : Exercice du centre d'opérations de sécurité du réseau
L'exercice principal, le Centre d'opérations de sécurité du réseau (NSOC), a fonctionné sur son propre déploiement Elastic, fournissant au personnel de contrôle de l'exercice une vue d'ensemble de la santé de la gamme, une surveillance de la sécurité sur l'ensemble de l'infrastructure et, surtout, un enregistrement d'audit pour tous les services d'intelligence artificielle que nous avons déployés. Chaque invocation de l'API Bedrock était enregistrée dans CloudWatch et observable dans ce déploiement, ce qui signifie que le NSOC avait une visibilité complète sur ce qui était demandé aux agents d'IA et par qui. Vous trouverez plus d'informations à ce sujet dans la section sur l'IA ci-dessous.
Automatisation de l'infrastructure : Terraform et Catapult
Tout ce que vous avez vu ci-dessus a été géré en tant qu'Infrastructure as Code. Notre site provider.tf donne une idée de l'écosystème de fournisseurs que nous avons orchestré :
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
}
}L'empreinte totale des ressources gérées par Terraform était considérable : un déploiement Elastic Cloud avec autoscaling, 40 Kibana Spaces, 120 Fleet agents policies (trois par équipe), 400+ integration policies, 40 Kibana security roles, 40 Keycloak role mappings, ILM policies for data retention, 41 AWS IAM users for Bedrock GenAI connectors (one per team space plus a default), 41 connecteurs d'action GenAI Kibana, garde-fous AWS Bedrock, tunnels Cloudflare Zero Trust pour l'accès à Tines, connecteurs d'action Tines par espace d'équipe, comptes de service de détection stockés dans HashiCorp Vault, et configuration de l'index par défaut de la solution de sécurité par espace. Tous les états ont été stockés dans un backend S3 crypté.
Pour le déploiement de l'agent et du proxy sur les systèmes de la gamme, nous avons utilisé Catapult, un excellent outil open-source conçu par l'équipe de Clarified Security. Catapult intègre à Ansible un modèle d'exécution basé sur des conteneurs, spécialement conçu pour les déploiements dans le domaine cybernétique. Il a pris en charge l'installation et l'enrôlement des agents élastiques dans l'infrastructure de la gamme. La configuration des serveurs proxy (chaque équipe disposait d'un proxy Squid dédié pour son réseau déployé, afin de simuler un point de sortie unique comme dans le monde réel). Le trafic passait par des points d'extrémité tels que http://elastic-proxy.dsoc.XX.dcm.ex:3128), et le déploiement de tunnels Cloudflare pour la connectivité de Tines.
Pendant le provisionnement, les éléments suivants ont été écrits dans HashiCorp Vault par Terraform et consommés par Catapult : informations d'identification, jetons d'inscription, clés API, configurations de proxy, informations d'identification du compte de service Tines... Les chemins d'accès à Vault suivent une structure cohérente comme dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployed et dcm/gt/elastic/tines-sa/tines-sa-btXX, ce qui permet aux playbooks de Catapult d'extraire facilement les bonnes références pour chaque équipe.
Formation : préparer les équipes à la réussite
Déployer la plateforme est une chose, s'assurer que les gens peuvent réellement l'utiliser en est une autre. Nous avons dispensé aux équipes bleues une formation sur le terrain avec instructeur pendant la phase précédant l'exercice. Cela couvrait les fondamentaux d'Elastic Security, la navigation dans leur espace d'équipe dans Kibana, le travail avec les règles de détection préconstruites, l'utilisation de Discover pour l'analyse des logs et la chasse aux menaces, la construction de tableaux de bord personnalisés, la compréhension des alertes Elastic Defend, et la familiarisation avec l'outil d'investigation Timeline.
L'instruction de l'exercice elle-même indiquait que cette formation était facultative mais "fortement recommandée," et, d'après ce que nous avons vu, les équipes qui y ont participé ont été tout à fait opérationnelles dès le premier jour d'exécution. La formation et l'habilitation sont tout aussi importantes que le déploiement de la technologie elle-même. Donner à une équipe un outil de sécurité de niveau entreprise qu'elle ne sait pas utiliser n'aurait été utile à personne.
Le service On-Range AI : Conforme, audité, protégé
Cette année, nous avons commencé à fournir un accès AI à la gamme DCM. Nous avons fourni un service d'IA conforme directement sur la gamme, soutenu par des modèles AWS Bedrock loués au Royaume-Uni - en particulier Claude 3.7 Sonnet fonctionnant dans la région eu-west-2 (Londres). Il ne s'agissait pas d'IA pour l'amour de l'IA ; il s'agissait d'un service soigneusement architecturé avec des garde-fous, une journalisation d'audit complète et des contrôles d'accès compatibles avec RBAC. L'expérience d'Elastic dans le domaine de l'IA nous a permis de gérer ce service.
Le service d'IA avait plusieurs consommateurs sur la plage, et c'est là une distinction importante. Le connecteur Bedrock conforme que nous avons provisionné dans l'espace de chaque équipe n'alimentait pas seulement nos agents personnalisés - il alimentait également les fonctions d'IA natives d'Elastic, en particulier :
Elastic AI Assistant pour la sécurité
L'assistant Elastic AI était disponible dans chaque espace Blue Team, connecté à notre connecteur Bedrock à portée de main. Les équipes disposent ainsi d'une interface de discussion contextuelle directement au sein d'Elastic Security, où elles peuvent poser des questions sur leurs alertes, obtenir de l'aide pour rédiger des requêtes ES|QL, enquêter sur des processus suspects et être guidées dans les étapes de remédiation. L'assistant IA utilise la méthode RAG (Retrieval-Augmented Generation) avec la fonction Base de connaissances d'Elastic, qui est pré-remplie d'articles provenant des laboratoires de sécurité d'Elastic. Les équipes peuvent également ajouter à la base de connaissances leurs propres documents, tels que les SOP spécifiques au champ de tir, les renseignements sur les menaces ou les notes de l'équipe, afin de mieux ancrer les réponses de l'assistant dans leur contexte opérationnel.
La capacité de l'assistant IA à aider les analystes moins expérimentés à comprendre ce qu'ils regardent a été particulièrement précieuse dans le contexte de l'exercice. Un analyste débutant confronté à sa première balise d'implantation en direct peut demander à l'assistant d'expliquer l'alerte, de suggérer des étapes d'investigation et même de l'aider à rédiger le rapport d'incident. Les paramètres d'anonymisation des données ont permis d'obscurcir les valeurs des champs sensibles avant de les envoyer au fournisseur de LLM.
Découverte d'attaques élastiques
La découverte d'attaques est un autre consommateur important de notre service d'IA à distance. Attack Discovery utilise les LLM pour analyser les alertes dans l'environnement d'une équipe et identifier les menaces en corrélant les alertes, les comportements et les chemins d'attaque. Chaque découverte "" représente une attaque potentielle et décrit les relations entre plusieurs alertes - indiquant aux équipes quels utilisateurs et hôtes sont impliqués, comment les alertes se rapportent à la matrice MITRE ATT& CK, et quel acteur de la menace pourrait être responsable.
Dans le cadre d'un exercice cybernétique au cours duquel les équipes rouges lançaient activement des attaques coordonnées, Attack Discovery a joué un rôle déterminant. Au lieu de trier manuellement des centaines d'alertes individuelles, les équipes bleues pourraient exécuter Attack Discovery pour mettre en évidence les récits d'attaque de haut niveau, par exemple, "ces alertes 15 font toutes partie d'une chaîne de mouvement latéral de l'hôte X à l'hôte Y, probablement par l'acteur de la menace Z", et concentrer leur temps d'investigation là où c'est le plus important. C'est le genre de capacité qui réduit directement le temps moyen de réaction et qui combat la fatigue de l'alerte, ce qui est précisément ce dont vous avez besoin lorsque vous subissez une attaque soutenue pendant cinq jours d'affilée.
Les agents d'intelligence artificielle personnalisés : Elastic Agent Builder
Au-delà des fonctionnalités natives d'Elastic AI, nous avons construit trois agents d'IA sur mesure à l'aide d'Elastic Agent Builder. Agent Builder est le cadre d'Elastic pour la construction d'agents d'IA personnalisés qui combinent des instructions LLM avec des outils modulaires et réutilisables, chaque outil étant une requête ES|QL, une capacité de recherche intégrée, l'exécution d'un flux de travail ou une intégration externe via MCP. Les agents analysent les demandes en langage naturel, sélectionnent les outils appropriés, les exécutent et itèrent jusqu'à ce qu'ils puissent fournir une réponse complète, tout en gérant le contexte avec des données dans Elasticsearch. Pour en savoir plus sur le framework, consultez la documentation Agent Builder et l'étude approfondie d'Elasticsearch Labs.
Les trois éléments clés de l'Agent Builder que nous avons exploités sont les suivants :
Agents : Des instructions LLM personnalisées et un ensemble d'outils assignés qui définissent la personnalité de l'agent, ses capacités et les limites de son comportement. Chaque agent dispose d'une invite système qui contrôle sa mission, les outils auxquels il peut accéder et la structure de ses réponses.
Outils : Fonctions modulaires que les agents utilisent pour rechercher, récupérer et manipuler les données Elasticsearch. Nous avons construit des outils ES|QL personnalisés qui ont interrogé des index spécifiques contenant de la documentation sur les exercices, des playbooks et des rapports.
Agent Chat : L'interface conversationnelle - à la fois l'interface utilisateur Kibana intégrée et l'API programmatique - que les participants ont utilisée pour interagir avec les agents.
Les configurations de l'agent et de l'outil sont définies en JSON et gérées via les API de l'Agent Builder, ce qui rend l'ensemble du cycle de vie de l'agent - de l'ingénierie de l'invite à la liaison de l'outil - reproductible et contrôlable par version. Nous partagerons la configuration de l'agent GrantPT et les définitions des outils dans un article de suivi pour ceux qui souhaitent reproduire cette approche - surveillez cet espace.
Voici ce que chaque agent a fait :
1. GrantPT - L'assistant polyvalent
Disponible pour les quelque 2 500 participants à l'exercice, GrantPT était notre principal agent d'IA et la meilleure démonstration de la simplicité avec laquelle Agent Builder permet de mettre en place un assistant compétent et spécifique à un domaine. La configuration de l'agent consistait en un objet JSON définissant son invite système, son persona et un tableau d'ID d'outils liés - c'est tout. Pas de code d'application personnalisé, pas de couche d'API sur mesure, juste une configuration déclarative.
Ce qui a donné à GrantPT sa profondeur, c'est l'outillage. Nous avons défini une combinaison d'outils intégrés à la plate-forme et d'outils ES|QL personnalisés, chacun étant enregistré avec une description, une requête paramétrée et des définitions de paramètres typés. Par exemple, l'outil de base de connaissances a accepté un paramètre target_index et un paramètre sémantique query, exécutant une requête ES|QL paramétrée sur nos index dcm5-grantpt-* avec un classement de recherche sémantique :
FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10Un outil distinct de découverte d'index permet à l'agent d'énumérer dynamiquement les index de la base de connaissances disponibles au début de chaque conversation, ce qui signifie que nous avons pu ajouter de nouveaux index de documentation au cours de l'exercice sans reconfigurer l'agent ; il les découvrira simplement lors de l'interaction suivante.
Nous avons également développé un outil d'intégration Jira qui effectue une recherche sémantique dans les tickets d'assistance ingérés, permettant à GrantPT de faire apparaître un contexte de dépannage pertinent à partir de demandes d'assistance antérieures. Cela s'est avéré particulièrement utile pour les analystes du service d'assistance, qui ont pu interroger GrantPT sur des problèmes récurrents et obtenir des réponses fondées sur l'historique des tickets plutôt que sur des conseils génériques.
Le comportement de réponse adapté au RBAC provient d'une combinaison de l'invite système de l'agent, qui lui demande de contextualiser les réponses en fonction du rôle de l'utilisateur, et du modèle de sécurité Elasticsearch sous-jacent. Comme la requête ES|QL de chaque outil est exécutée dans le contexte de sécurité de l'utilisateur, l'agent ne peut faire apparaître que les documents accessibles au rôle de l'utilisateur. Un membre de l'équipe bleue posant des questions sur les procédures d'exercice obtiendra des résultats correspondant aux indices accessibles de son équipe, tandis qu'un analyste du service d'assistance obtiendra des résultats provenant d'indices spécifiques au service d'assistance. L'agent n'avait pas besoin d'une logique explicite de changement de rôle ; la sécurité native au niveau du document d'Elasticsearch gérait le cadrage, et l'agent travaillait simplement avec les résultats renvoyés. C'est l'une des choses qui rend Agent Builder véritablement élégant - en héritant du modèle de sécurité d'Elasticsearch, vous obtenez une IA compatible RBAC sans écrire une seule ligne de code d'autorisation.
2. REDRock - Le compagnon de l'adversaire
Cet agent était exclusivement disponible pour les équipes rouges. REDRock a suivi le même modèle d'Agent Builder, un prompt système dédié définissant son personnage d'adversaire, lié à son propre ensemble d'outils ES|QL personnalisés interrogeant des indices spécifiques à l'équipe rouge. Ces index contenaient les manuels de jeu de l'équipe rouge, la documentation C2 de Tuoni, les vulnérabilités connues des systèmes dans l'environnement du champ de tir et des informations sur les services déployés. Les définitions de l'outil reflétaient le même modèle de recherche sémantique paramétré que celui utilisé par GrantPT, mais elles étaient limitées à des indices accessibles uniquement aux rôles de l'équipe rouge. Les opérateurs de l'équipe rouge peuvent interroger les vecteurs d'attaque, vérifier les faiblesses connues des systèmes cibles et obtenir des conseils contextuels sur leurs plans opérationnels. En toute franchise, cela revenait à donner aux attaquants un officier d'opérations extrêmement bien informé.
3. RefPT - L'outil de l'arbitre
Conçu spécifiquement pour l'équipe blanche (les arbitres et les évaluateurs de l'exercice), RefPT était lié à des outils d'interrogation d'index contenant les rapports de l'équipe bleue, les événements du scénario et les critères de notation. L'objectif était de garantir une notation uniforme et équitable pour l'ensemble des 40 équipes et plus. Le système d'invite de l'agent a été réglé de manière à croiser les rapports soumis avec les événements connus du scénario et les rubriques de notation, aidant ainsi les évaluateurs à identifier les incohérences ou les lacunes. Lorsque vous avez des évaluateurs qui évaluent des dizaines d'équipes simultanément, le fait de disposer d'une IA capable de corréler les rapports avec un indice de notation structuré est une véritable transformation pour la cohérence.
Tines : Automatisation du flux de travail par l'IA
Tines était également un consommateur du service d'IA à distance. Chaque équipe bleue disposait d'une instance Tines dédiée, avec des connecteurs d'action Tines provisionnés dans leur espace Kibana. Tines pourrait exploiter les capacités d'IA soutenues par Bedrock pour l'automatisation intelligente des flux de travail, comme l'enrichissement automatisé des alertes, les décisions de triage assistées par l'IA, les résumés en langage naturel dans les flux de travail de notification, et la création de flux de travail en langage naturel. Le connecteur Tines a été configuré par équipe avec des identifiants stockés dans 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/"
})
}Garantir la conformité : Garde-fous et audit
Chaque interaction de l'IA avec l'ensemble de ces consommateurs a été régie par des garde-fous AWS Bedrock stricts. Nous avons déployé des garde-fous avec filtrage du contenu (haine, insultes, contenu sexuel et violence à des seuils MOYENS), protection des IPI (blocage des adresses électroniques, des numéros de téléphone, des noms, des adresses, des numéros d'assurance nationale du Royaume-Uni, des numéros de carte de crédit et des adresses IP), filtrage par sujet pour empêcher toute discussion sur des opérations classifiées réelles, et filtrage des blasphèmes. Voici un extrait de la configuration du garde-corps de notre 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"
}
}
}Chaque espace Blue Team avait son propre utilisateur IAM pour l'accès à Bedrock, et le paramètre genAiSettings:defaultAIConnectorOnly Kibana a été appliqué pour empêcher les équipes de configurer leurs propres connecteurs. Cela signifie que chaque appel d'API pouvait être retracé jusqu'à une équipe spécifique via CloudWatch, et que le NSOC disposait d'une visibilité d'audit complète. Le groupe de journaux CloudWatch /aws/bedrock/grantpt-prod/invocations a capturé chaque invocation et chaque événement de garde-corps.
Les chiffres concernant l'ensemble des consommateurs d'IA parlent d'eux-mêmes : 3 agents d'IA personnalisés, 2 797 conversations et 785 millions de jetons d'IA consommés tout au long de l'exercice.
Suivi en temps réel du jeu
Dans le cadre du scénario de l'exercice, chaque équipe avait accès à RocketChat comme client de messagerie à distance. Chaque équipe bleue dispose de son propre canal, de la possibilité d'envoyer des messages directs à toute personne participant à l'exercice et de la liberté de créer de nouveaux canaux en fonction des besoins. Plus important encore pour la tradition DCM, il s'agissait du canal des mèmes - l'épine dorsale spirituelle de toutes les plaisanteries entre équipes et de l'humour créatif qui remonte le moral des troupes et qui émerge inévitablement lorsque vous mettez quelques milliers de cyberopérateurs sous pression pendant une semaine.
Toutes ces données de communication représentaient une brillante fenêtre en temps réel sur l'état de l'aire de répartition, le sentiment de l'équipe et les sujets en vogue au cours de l'exercice. Nous avons donc ingéré l'ensemble du corpus de conversations de RocketChat dans Elastic en temps réel et nous l'avons mis au travail.
Analyse des sentiments et reconnaissance des entités nommées
Pour la reconnaissance des entités nommées, nous avons déployé le modèle dslim/bert-base-NER de Hugging Face dans un nœud d'apprentissage automatique sur le déploiement NSOC en utilisant le client Elastic ELAND. Il a ensuite été connecté à un pipeline d'ingestion Elasticsearch que chaque message RocketChat a traversé lors de l'ingestion. Nous avons pris les entités extraites et avons fait apparaître les plus courantes sous forme de tableaux de bord thématiques, ce qui nous a permis d'avoir une vision en direct du flux et du reflux des sujets de conversation tout au long de l'exercice.
Nous avons également analysé l'activité des groupes, les statistiques des utilisateurs et les modèles généraux de communication afin de dresser un tableau des modes de vie de chaque équipe - participants les plus actifs, volume des messages au fil du temps et tendances des sentiments pivotés par les utilisateurs individuels. Au final, cela nous a donné un aperçu vraiment intéressant de ce qui se passait sur le champ de tir en temps quasi réel. Lorsque nous avons mis Elastic Agent en mode prévention, par exemple, un nuage de mots sur notre tableau de bord s'est immédiatement éclairé avec "Elastic" comme thème le plus discuté sur tous les canaux - les équipes bleues discutant de son efficacité, les équipes rouges se lamentant sur leurs balises perdues. C'est plutôt satisfaisant.
Analyse des mèmes (oui, vraiment)
Enfin - et ce point nous a fait froncer les sourcils - nous avons extrait tous les mèmes soumis aux chaînes, vectorisé les images et effectué des évaluations du plus proche voisin pour regrouper les mèmes et les sujets similaires. Nous les avons également fait passer par le modèle d'inférence NER "zero-shot" pour générer des descriptions thématiques du contenu de chaque mème. La logique était que ces résultats pourraient s'avérer utiles ultérieurement pour le filtrage, la modération ou d'autres interactions dans le jeu. On peut se demander si l'analyse des mèmes a permis d'obtenir des renseignements essentiels sur le plan opérationnel. La question de savoir si c'était une bonne partie de plaisir ne se pose pas.
Tuer les problèmes dans l'œuf
Même si nous espérions que tout se passerait bien pendant la semaine d'exercice, il arrive inévitablement que certaines choses se cassent, ne soient pas entièrement comprises ou nécessitent une adaptation plus poussée pour correspondre à la manière dont une équipe particulière souhaite les utiliser. Pour cela, nous avions notre propre sous-section du helpdesk in-range où les demandes spécifiques à Elastic et GenAI pouvaient être soulevées par n'importe quelle équipe.
Nous avons géré ce service d'assistance pendant toute la durée de l'exercice, en fournissant des conseils, de la documentation, en résolvant les problèmes et en formulant des recommandations spécifiques aux champs de tir. Ce dernier point mérite d'être développé. Parfois, ce qu'une équipe bleue voyait dans Elastic n'était en fait pas du tout un problème Elastic, mais plutôt Elastic qui remontait fidèlement quelque chose sur le champ de tir qui justifiait une enquête plus approfondie (les équipes rouges peuvent causer un désordre absolu, et la télémétrie ne ment pas). Au cours de l'exercice, nous avons couvert 125 demandes d'assistance individuelles émanant d'équipes demandant spécifiquement de l'aide à Elastic.
Débogage préemptif avec Tines
Outre la visite des équipes par VTC ou en personne lors de l'EXCON, nous avons également travaillé avec Tines pour essayer quelque chose d'un peu plus proactif. Nous avons extrait le corps du ticket des demandes entrantes, tenté de catégoriser le problème, comparé la catégorisation à notre corpus de tickets précédemment résolus, et demandé à GenAI de produire une réponse résumée de premier passage visant à résoudre le problème de l'utilisateur avant que le triage ne l'amène dans notre file d'attente.
Il s'agit en fait d'un modèle que nous avons emprunté à notre propre organisation de support chez Elastic, où nous fournissons une capacité similaire en utilisant notre vaste base de connaissances de problèmes précédemment résolus comme un référentiel pour soutenir le contexte de l'agent d'IA. L'idée est simple : utiliser des solutions antérieures pour donner à une machine une première tentative de résolution d'un problème, en toute connaissance de cause, et éviter qu'un ingénieur du service d'assistance n'ait à prendre en charge chaque ticket manuellement. Cela n'a pas tout résolu ; certaines questions nécessitaient vraiment un humain avec le contexte de la gamme, mais cela a permis de réduire de manière significative la pression de la file d'attente et d'apporter des réponses plus rapides aux équipes qui en avaient besoin. Le succès a été tel avec nos propres tickets et files d'attente que nous avons étendu le mandat à l'ensemble du service d'assistance dans la dernière partie de l'exercice, ce qui a permis de réduire la charge des autres groupes de l'équipe verte qui soutenait l'exercice.
Partenariats industriels : Mieux ensemble
L'une des choses dont nous sommes le plus fiers est la façon dont notre écosystème de partenariat s'est développé d'année en année. DCM n'est pas un simple salon Elastic ; il s'agit d'une véritable coalition de partenaires industriels, chacun apportant quelque chose d'unique à la plateforme de sécurité.
Année 1 (DCM2 ) - Elastic a rejoint le groupe en tant que partenaire industriel, fournissant la plateforme de surveillance de la sécurité et de détection des points d'extrémité.
Année 2 (DCM3 ) - Nous avons fait appel à Endace, qui fournit une capacité de capture de paquets 1:1. La capture complète des paquets, associée à la visibilité du réseau d'Elastic, a permis aux équipes d'effectuer des recherches approfondies que l'analyse des journaux ne peut pas fournir à elle seule.
Année 3 (DCM4) - Tines a rejoint la famille, apportant l'automatisation du flux de travail. Les Blue Teams peuvent désormais créer des playbooks de réponse automatisés, des workflows de triage et des chaînes de notification, le tout intégré directement dans leur environnement Elastic via le connecteur Tines natif.
Année 4 (DCM26, anciennement DCM5) - AWS est entré en jeu, fournissant l'accès à Bedrock pour nos agents d'intelligence artificielle et contribuant au financement des déploiements d'Elastic. Il s'agissait d'une étape importante ; le fait qu'un hyperscaler soit directement investi dans la réussite de l'exercice a permis de débloquer des capacités (telles que l'inférence d'IA conforme et sous contrat avec le Royaume-Uni, avec des garde-fous complets et une journalisation d'audit) qui n'auraient tout simplement pas été possibles autrement. Cette année, l'intégration de Tines a également été renforcée par l'ajout d'un accès à la gamme de LLM. La série DCM a également franchi une étape importante cette année, passant d'une initiative de la Cyber Association de l'armée à un programme officiellement financé par le Commandement des opérations cybernétiques et spécialisées.
Aux équipes d'Endace, de Tines et d'AWS, nous adressons nos sincères remerciements. Cet exercice est meilleur grâce à vos contributions, et toutes les équipes sont mieux équipées grâce à la plateforme que nous avons construite ensemble. Nous planifions déjà le DCM27. Je vous salue tous.
Culture, faits marquants, et ce qui en vaut la peine
Les Challenge Coins
Nous avons fait frapper des pièces de monnaie personnalisées pour le DCM26. Si vous connaissez, vous savez que les pièces de monnaie sont une tradition militaire de longue date, et en faire fabriquer une pour l'exercice nous a semblé être la bonne façon de marquer notre quatrième année d'engagement.
Le cocktail
Nous avons également eu la chance d'être invités au cocktail de la Haute Commission organisé par le Haut Commissaire britannique à Singapour. Il y a quelque chose de surréaliste à discuter du nombre de shards d'Elasticsearch et de la gestion des états de Terraform en buvant un gin tonic à l'invitation de l'ambassadeur. Ce fut une soirée brillante, un véritable rappel que ces exercices existent à l'intersection de la technologie et de la diplomatie, et que les relations construites ici s'étendent bien au-delà de la technique.
Wrapping up
L'architecture multi-locataires a fait ses preuves sous une charge soutenue ; les fonctions natives d'Elastic AI(AI Assistant et Attack Discovery) ont donné aux équipes des capacités qui auraient relevé de la science-fiction il y a quelques années ; et les agents d'IA personnalisés ont dépassé nos attentes en matière d'adoption. Le modèle de partenariat continue de démontrer que l'implication de l'industrie dans les exercices de défense permet d'obtenir des résultats qu'aucune organisation ne pourrait atteindre seule.
Defence Cyber Marvel 2026 a été une itération historique d'un exercice dont l'ambition, la complexité et l'impact ne cessent de croître. Elastic ne prend pas à la légère le fait qu'on lui fasse confiance pour fournir la plateforme de sécurité défensive de base pour 40 Blue Teams de 29 nations, et cette année, la capacité d'IA également. L'exercice permet de développer des compétences réelles pour des personnes réelles qui défendront ensuite des réseaux réels, et le fait de participer à cette mission est véritablement significatif.
Comme l'indique le communiqué de presse du gouvernement britannique, le DCM démontre la valeur pratique de scénarios réels qui renforcent les partenariats internationaux. Nous sommes tout à fait d'accord.
Nous reviendrons l'année prochaine, et je pense que nous aurons encore plus de choses à nous dire. Entre-temps, nous continuerons à améliorer le produit pour que le soutien aux environnements tels que Defence Cyber Marvel soit excellent d'une année sur l'autre.
A bientôt sur le champ de tir.
Suivez l'histoire du DCM26 sur les médias sociaux :
Facebook | LinkedIn | Instagram
Lecture complémentaire
Sécurité élastique & AI
- Elastic Security - La plateforme qui alimente les déploiements de l'équipe bleue
- AI Assistant for Security - Chat IA contextuel au sein d'Elastic Security
- Découverte d'attaques - Corrélation d'alertes et génération de récits de menaces alimentées par LLM
- Agent Builder - Cadre de travail pour la création d'agents d'IA personnalisés avec Elasticsearch
Infrastructure & Outillage
- Elastic Stack Terraform Provider - Infrastructure as Code pour Elastic Stack
- Elastic Fleet Guide - Gestion centralisée des agents Elastic à l'échelle
- Catapult by Clarified Security - Approvisionnement de la gamme cybernétique basé sur Ansible
Contexte de l'exercice
- Communiqué de presse du gouvernement britannique sur le DCM26 - Aperçu officiel de l'exercice