Blog

Elastic et Defence Cyber Marvel 2026 : aperçu technique depuis la salle d’exercices

Présentation de l’infrastructure Elastic dédiée à la sécurité et à l’IA, déployée pour soutenir le Defence Cyber Marvel 2026, l’exercice phare du ministère britannique de la Défense en matière de cybersécurité.

James Garside
Opérations de sécurité

Par où commencer. Pour la quatrième année consécutive, Elastic a eu le privilège d’intervenir en tant que partenaire industriel de confiance lors de l’exercice Defence Cyber Marvel, la série d’exercices de cybersécurité 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 absolument ravis de pouvoir enfin vous parler de ce que nous avons construit, de la façon dont nous l’avons construit et de ce que nous avons appris.

Qu’est-ce que Defence Cyber Marvel ?

Pour ceux qui ne le connaissent pas, Defence Cyber Marvel (DCM) est la plus grande série britannique d’exercices militaires de cybersécurité, axée sur la défense des réseaux informatiques traditionnels, des environnements d’entreprise et des systèmes complexes de contrôle industriel dans des scénarios réalistes et sous haute pression. Elle met en avant une puissance cyber responsable tout en renforçant la préparation, l’interopérabilité et la résilience au sein de la Défense et des nations alliées. Aujourd’hui dans sa cinquième année, DCM est passé d’une initiative de l’Army Cyber Association à une opération interarmées dirigée par le Cyber and Specialist Operations Command (CSOC).

Le gouvernement britannique a publié un communiqué de presse officiel concernant le DCM26, qui offre un excellent aperçu de l’importance stratégique de l’exercice. Comme l’a souligné le haut-commissaire britannique à Singapour, l’exercice démontre la coopération étroite entre le Royaume-Uni et ses partenaires de confiance, rappelant la force des partenariats stratégiques partagés dans un contexte de sécurité de plus en plus complexe.

Par essence, le DCM est un exercice cyber force contre force : les Blue Teams en défense protègent les réseaux et l’infrastructure qui leur sont assignés contre les attaques des Red Teams, à l’aide d’un éventail de techniques. Les activités vont de la modification des mots de passe par défaut et du durcissement des pare-feu jusqu’au déploiement d’une cyberdéfense de niveau professionnel basée sur l’IA avec Elastic Security. Les activités de chaque équipe sont monitorées par la White Team pour établir un score prenant en compte la disponibilité du système, la détection des attaques, le reporting d’incidents et la restauration du système. Ce dispositif met à l’épreuve les équipes les plus expérimentées tout en offrant un mécanisme d’entraînement unique pour les équipes juniors lors de leur premier contact avec un environnement d’exercice cyber, et ce double objectif fait du DCM un exercice particulièrement précieux.

L’ampleur du DCM26

DCM26 a réuni plus de 2 500 personnes issues de 29 pays participants et de 70 organisations, sous la coordination d’un contrôle central de l’exercice (EXCON) basé à Singapour, EXCON accueillant plus de 600 participants. L’exercice s’est déroulé dans un environnement informatique hybride couvrant l’environnement d’exercice cyber CR14 et AWS, et hébergeant plus de 5 000 systèmes virtuels.

L’exercice en lui-même s’est déroulé sur cinq jours d’exécution (du 9 au 13 février 2026), précédé d’une préformation facultative dirigée par un instructeur et de vérifications de connectivité. Le scénario, basé sur l’Indo-Pacific Operating Environment du Defence Academy Training Environment (DATE), a placé les équipes en tant que Cyber Protection Teams défendant des systèmes militaires déployés lors d’une escalade de crise régionale. Les Blue Teams étaient géographiquement dispersées, certaines sur leurs sites d’origine au Royaume-Uni et à l’international, d’autres déployées à l’étranger, toutes se connectant à l’environnement d’exercice via VPN.

Parmi les participants figuraient des représentants de la Défense britannique, de services interministériels 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 accueilli pour la première fois le centre névralgique de l’exercice, reflétant l’engagement du Royaume-Uni à approfondir sa coopération avec ses partenaires de la région indopacifique face aux défis de sécurité communs.

En bref, il s’agit d’un exercice sérieux. Forte pression, force contre force, avec de réelles conséquences sur le score, et de véritables acquis d’apprentissage pour tous les participants.

Les déploiements : notre infrastructure Elastic

L’infrastructure de cette année a connu une évolution architecturale significative par rapport aux versions précédentes. Au lieu de déployer des clusters Elastic Cloud individuels pour chaque équipe, nous avons adopté un déploiement Elastic Cloud mutualisé unique, basé sur des espaces, pour les Blue Teams. Nous avons également mis à disposition des déploiements pour des fonctions en dehors des Blue Teams. Permettez-moi de détailler chaque déploiement et la raison de son existence.

Blue Teams : Elastic Security mutualisé

La pièce maîtresse de notre contribution était un déploiement Elastic Cloud unique desservant l’ensemble des 40 Blue Teams en défense, séparées à l’aide des espaces Kibana et des espaces de nom de flux de données. Chacune des 39 équipes 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 :

# Créer 40 espaces Blue Team
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 = "Espace isolé pour BT-${local.team_numbers[count.index]} avec visibilité Fleet tenant compte des espaces"

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

L’espace de chaque équipe a reçu un ensemble dédié de trois Fleet politiques d’agent : au jour 1, une politique réseau Deployed, au jour 2, une politique 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 élégante simplicité : définir « enable_hostnation_network = true » dans notre « terraform.tfvars » et exécuter « terraform apply » a étendu les autorisations de rôle de chaque équipe et rendu leur politique d’agent Host Nation 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 reposait sur les espaces de nom des flux de données. Chaque stratégie d’agent est enregistrée dans des espaces de nom propres à chaque équipe, comme « bt_01_deployed » et « bt_01_hostnation », produisant des flux de données selon le schéma suivant :

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<sub></sub>
logs-windows.forwarded-bt_01_hostnation
logs-auditd.log-bt_01_hostnation

Le rôle de sécurité Kibana de chaque équipe a ensuite été restreint à ces seuls flux de données à l’aide de blocs de privilèges d’index dynamiques :

# Flux de données déployés (toujours accordés)
indices {
  names = [
    "logs-*-${local.deployed_namespaces[count.index]}",
    "metrics-*-${local.deployed_namespaces[count.index]}",
    ".fleet-*"
  ]
  privileges = ["read", "view_index_metadata"]
}

# Flux de données HostNation (conditionné par 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 était gérée via l’authentification unique Keycloak, les mappings de rôles Elasticsearch associant 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 de base de l’OS, Elastic Defend pour l’Endpoint Detection and Response, le transfert d’événements Windows, Auditd pour le logging d’audit Linux, et les intégrations Network Packet Capture. C’est plus de 400 politiques d’intégration gérées en tant que code via le fournisseur Terraform Elastic Stack.

Une remarque sur Elastic Defend : en raison de l’efficacité de la protection des endpoints d’Elastic, à laquelle le DoD et la communauté du renseignement américains font confiance en production, pour en savoir plus, cliquez ici, et du fait que personne de sensé ne gaspille d’exploits « zero-day » lors d’un exercice d’entraînement, nous sommes contraints de brider Elastic Defend en désactivant le mode Prevent pour ne conserver que le mode Detect-only. Les équipes reçoivent des alertes dès qu’une activité malveillante se produit, mais sans aucune neutralisation automatique. Nous désactivons également complètement la fonctionnalité Memory Threat Prevention and Detection, car elle découvre la majorité des implants et des balises de l’équipe attaquante, ce qui gâcherait le jeu des Red Teams. Vers la fin de l’exercice, nous avons laissé aux équipes la liberté d’exploiter tout le potentiel d’Elastic Defend, mais pas avant d’avoir laissé les Red Teams s’implanter solidement.

Nous avons également préinstallé les règles de détection prédéfinies d’Elastic dans l’espace de chaque équipe, l’ensemble complet d’Elastic Security Labs, mis à jour en continu dans un référentiel ouvert. Ces règles ont été configurées pour garantir qu’elles n’interrogent que les index autorisés par les autorisations limitées à l’espace de noms, empêchant ainsi toute fuite de données entre les équipes lors de l’exécution des règles de détection.

De plus, l’index par défaut de la solution Security de chaque espace d’équipe était configuré pour limiter le périmètre des règles de détection aux seuls flux de données de cette équipe, plutôt qu’au modèle large par défaut. Cela était géré par une « null_resource » Terraform qui appelait l’API des paramètres internes de Kibana afin de définir « securitySolution:defaultIndex » pour chaque espace.

Au pic d’activité, ce déploiement ingérait 800 000 événements par seconde (EPS) pour l’ensemble des 40 équipes. Cela représente une quantité considérable de données, et le cluster l’a gérée sans difficulté grâce aux capacités de scaling automatique d’Elastic Cloud. Cela étant dit, en 2018, nous traitions 5 millions d’événements par seconde avec eBay.

Le cycle de vie des données était géré par une politique de gestion du cycle de vie des index (ILM) qui renouvelait les index au bout d’un jour ou de « 50 » Go (selon la première éventualité), les déplaçait vers une phase warm après deux jours pour l’optimisation en lecture seule et le force-merging, puis supprimait 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 liées à la fenêtre d’exercice. Voici un exemple de la façon dont la politique ILM a été mise en œuvre.

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 partitions : prouver le multi-tenant à grande échelle

Avant de nous engager dans cette architecture pour un exercice militaire en conditions réelles, nous devions prouver qu’elle serait en mesure de répondre à nos exigences et de disposer d’un basculement approprié en cas de problème. Le passage de déploiements individuels à un cluster multi-tenant unique a introduit de réels risques : conflits de ressources, goulots d’étranglement lors de l’ingestion, fuite 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 de partitions nettement plus important étant donné que chaque équipe génère son propre ensemble d’index.

Nous avons donc mis en place un banc d’essai dédié. Le plan était simple : déployer 50 espaces Kibana, créer une politique d’agent dans chaque espace, lancer 6000 instances EC2 (120 par tenant, réparties sur six sous-réseaux dans trois zones de disponibilité), et tester la charge de l’ensemble. Nous avons tout monitoré avec AutoOps et Stack Monitoring.

Le flux de déploiement fonctionnait ainsi : Terraform a créé le VPC et les sous-réseaux sur trois zones de disponibilité, a provisionné les 50 espaces Kibana et leurs politiques Fleet limitées aux espaces, a généré des jetons d’enrôlement, puis a lancé les instances EC2 par lots. Chaque instance a installé Elastic Agent au démarrage et s’est enregistrée à l’aide de son jeton spécifique à l’espace.

Nous avons rencontré des défis intéressants en cours de route. Le fournisseur Terraform Elastic Stack standard ne prenait pas en charge les opérations Fleet tenant compte des espaces à l’époque, nous l’avons donc forké et avons ajouté la gestion des ID d’espace aux ressources Fleet. Sans cette modification, chaque agent aurait été inscrit dans l’espace par défaut, quelle que soit l’attribution des politiques. 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é la « 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 en tentant de lancer l’ensemble des 6000 instances simultanément. Nous avons donc procédé aux déploiements par lots de 500 instances, avec des périodes de pause de cinq minutes entre les lots.

Les résultats ont été rassurants. Les 6 000 agents ont été généralement enregistrés dans les 20 minutes suivant le déploiement. Lors de nos tests, l’isolation des espaces a fonctionné comme prévu, sans fuite de données observée entre les entités. Les mises à jour des politiques Fleet étaient transmises à tous les agents en 60 secondes. Les requêtes de recherche limitées à des espaces individuels restaient rapides à pleine charge. Et la distribution sur plusieurs zones de disponibilité s’est avérée résiliente lors de simulations de défaillances de zones de disponibilité.

Ces tests nous ont donné confiance pour nous engager sur cette architecture pour l’exercice en conditions réelles.

Red Teams : observabilité des implants C2

Un déploiement Elastic distinct et dédié a été mis en place pour les Red Teams, axé sur l’observabilité des implants de commande et de contrôle (C2). Cela a offert aux équipes d’attaque une visibilité sur leurs propres opérations, notamment sur l’état des implants, les rappels de balises et la progression opérationnelle, sans aucun risque de contamination croisée avec les données de la Blue Team. Les Red Teams ont utilisé Tuoni comme C2, un framework développé par Clarified Security pour le red teaming. Dans DCM3, nous avons collaboré avec Clarified Security pour nous assurer qu’il prenait correctement en charge l’Elastic Common Schema, facilitant grandement toute intégration future avec Elastic.

NSOC : exercice du centre des opérations de sécurité réseau

L’exercice principal, le Network Security Operations Centre (NSOC), s’exécutait sur son propre déploiement Elastic, offrant ainsi à l’équipe de contrôle de l’exercice une vue globale sur l’état de santé de l’environnement d’exercice, le monitoring de la sécurité sur l’ensemble de l’infrastructure et, élément essentiel, le logging d’audit pour tous les services d’IA que nous avons déployés. Chaque appel de l’API Bedrock était consigné dans CloudWatch et observable dans ce déploiement, le NSOC disposait donc d’une visibilité totale sur ce qui était demandé aux agents d’IA et par qui . Plus d’informations à ce sujet dans la section consacrée à 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 fichier « provider.tf » donne un aperçu de l’écosystème de fournisseurs que nous orchestrions :

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 dimensionnement automatique, 40 espaces Kibana, 120 stratégies d’agent Fleet (trois par équipe), plus de 400 stratégies d’intégration, 40 rôles de sécurité Kibana, 40 mappings de rôles Keycloak, des stratégies ILM pour la rétention des données, 41 utilisateurs AWS IAM pour les connecteurs d’IA générative Bedrock (un par espace d’équipe plus un par défaut), 41 connecteurs d’action d’IA générative Kibana, des garde-fous AWS Bedrock, des tunnels Cloudflare Zero Trust pour l’accès à Tines, des connecteurs d’action Tines par espace d’équipe, des comptes de service de détection stockés dans HashiCorp Vault et une configuration d’index par défaut pour Security Solution par espace. L’ensemble de l’état était stocké dans un back-end S3 chiffré.

Pour le déploiement de l’agent et du proxy sur les systèmes réels de l’environnement d’exercice cyber, nous avons utilisé Catapult, un excellent outil open source conçu par l’équipe de Clarified Security. Catapult encapsule Ansible dans un modèle d’exécution basé sur des conteneurs, spécialement conçu pour les déploiements d’environnement d’exercice cyber. Il a pris en charge l’installation et l’inscription des Elastic Agents dans toute l’infrastructure de l’environnement d’exercice cyber. 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 était acheminé via des endpoints tels que http://elastic-proxy.dsoc.XX.dcm.ex:3128), et des tunnels Cloudflare étaient déployés pour la connectivité Tines.

Lors du provisionnement, les éléments suivants ont été écrits dans HashiCorp Vault par Terraform et utilisés par Catapult : identifiants, jetons d’inscription, clés API, configurations de proxy, identifiants de compte de service Tines. Les chemins Vault suivaient une structure cohérente telle que « dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployedetdcm/gt/elastic/tines-sa/tines-sa-btXX », ce qui permettait aux playbooks Catapult de récupérer facilement les bons identifiants pour chaque équipe.

Formation : garantir la réussite des équipes

Déployer la plateforme est une chose. S’assurer que les utilisateurs peuvent réellement s’en servir en est une autre. Nous avons dispensé une formation avec formateur sur l’environnement d’exercice cyber aux Blue Teams pendant la phase de pré-exercice. Cela couvrait les principes fondamentaux d’Elastic Security, la navigation dans l’espace de leur équipe dans Kibana, l’utilisation des règles de détection préconfigurées, l’utilisation de Discover pour l’analyse des logs et la recherche des menaces, la création de tableaux de bord personnalisés, la compréhension des alertes Elastic Defend et la prise en main de l’outil d’investigation Timeline.

Les instructions de l’exercice indiquaient elles-mêmes que cette formation était facultative, mais « vivement recommandée », et d’après ce que nous avons constaté, les équipes qui y ont participé ont été immédiatement opérationnelles dès le premier jour d’exécution. La formation et l’accompagnement sont tout aussi importants que le déploiement technologique lui-même. Fournir à une équipe des outils de sécurité professionnels qu’elle ne sait pas utiliser n’aurait été utile à personne.

Le service d’IA de l’environnement d’exercice : conforme, audité, doté de garde-fous

Cette année a marqué nos débuts en matière de fourniture d’accès à l’IA pour l’environnement d’exercice DCM. Nous avons fourni un service d’IA conforme directement sur l’environnement d’exercice, soutenu par des modèles AWS Bedrock hébergés au Royaume-Uni, en particulier Claude 3.7 Sonnet exécuté dans la région eu-west-2 (Londres). Il ne s’agissait pas d’utiliser l’IA pour le simple plaisir d’utiliser l’IA. C’était un service soigneusement conçu, avec des garde-fous, un logging d’audit complet et des contrôles d’accès prenant en compte RBAC. Nous avons été chargés d’exploiter ce service grâce à l’expérience d’Elastic dans le domaine de l’IA.

Le service d’IA comptait plusieurs utilisateurs sur l’environnement d’exercice, et il s’agit là d’une distinction importante. Le connecteur Bedrock conforme que nous avons provisionné dans l’espace de chaque équipe ne servait pas seulement à alimenter nos agents personnalisés : il alimentait également les fonctionnalités d’IA natives d’Elastic, plus précisément :

Elastic AI Assistant pour la sécurité

L’Elastic AI Assistant était disponible dans chaque espace Blue Team, connecté à notre connecteur Bedrock sur l’environnement d’exercice cyber. Cela offrait aux équipes une interface de chat contextuelle directement dans Elastic Security, où elles pouvaient poser des questions sur leurs alertes, obtenir de l’aide pour rédiger des requêtes ES|QL, analyser des processus suspects et bénéficier d’étapes de remédiation guidées. L’assistant IA utilise la génération augmentée de récupération (Retrieval-Augmented Generation, RAG) avec la fonctionnalité Base de connaissances d’Elastic, préremplie d’articles provenant d’Elastic Security Labs. Les équipes pouvaient également ajouter leurs propres documents, tels que des SOP spécifiques à l’environnement d’exercice cyber, des renseignements sur les menaces ou des notes d’équipe, à la base de connaissances afin d’ancrer davantage les réponses de l’assistant dans leur contexte opérationnel.

Ce qui s’est avéré particulièrement précieux dans le contexte de l’exercice, c’est la capacité de l’Assistant IA à aider les analystes moins expérimentés à comprendre ce qu’ils observaient. Un analyste junior confronté pour la première fois à une balise d’implantation active pouvait 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 garantissaient que les valeurs des champs sensibles pouvaient être masquées avant d’être envoyées au fournisseur de LLM.

Elastic Attack Discovery

Attack Discovery était un autre utilisateur important de notre service d’IA de l’environnement d’exercice. Attack Discovery utilise des 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 concernés, comment les alertes correspondent à la matrice MITRE ATT&CK, et quel acteur malveillant pourrait être responsable.

Pour un exercice de cybersécurité dans lequel les Red Teams ont activement lancé des attaques coordonnées, Attack Discovery a changé la donne. Au lieu de trier manuellement des centaines d’alertes individuelles, les Blue Teams pouvaient exécuter Attack Discovery pour mettre en évidence les scénarios d’attaque globaux, par exemple : « ces 15 alertes font toutes partie d’une chaîne de déplacement latéral de l’hôte X à l’hôte Y, probablement causée par le pirate Z », et concentrer leur temps d’investigation là où c’était le plus important. C’est le genre de fonctionnalité qui réduit directement le temps moyen de réponse, et lutte contre la fatigue liée aux alertes, ce qui est précisément ce dont vous avez besoin lorsque vous subissez des attaques soutenues pendant cinq jours d’affilée.

Les agents IA personnalisés : Elastic Agent Builder

Au-delà des fonctionnalités natives d’Elastic AI, nous avons créé trois agents IA sur mesure avec Elastic Agent Builder. Agent Builder est le framework d’Elastic permettant de créer des agents IA personnalisés combinant des instructions LLM avec des outils modulaires et réutilisables, chaque outil étant une requête ES|QL, une fonctionnalité de recherche intégrée, l’exécution d’un workflow, ou une intégration externe via MCP. Les agents analysent les requêtes en langage naturel, sélectionnent les outils appropriés, les exécutent, et itèrent jusqu’à pouvoir fournir une réponse complète, tout en gérant le contexte avec les données dans Elasticsearch. Pour en savoir plus sur le framework, consultez la documentation d’Agent Builder et l’analyse approfondie d’Elasticsearch Labs.

Les trois composants clés d’Agent Builder que nous avons exploités sont les suivants :

Agents : instructions LLM personnalisées et ensemble d’outils attribués qui définissent le persona, les capacités et les limites de comportement de l’agent. Chaque agent dispose d’un prompt 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 créé des outils ES|QL sur mesure qui interrogeaient 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 des agents et des outils sont définies en JSON et gérées via les API d’Agent Builder, rendant l’ensemble du cycle de vie de l’agent (de l’ingénierie de prompt à la liaison d’outils) reproductible et contrôlable par gestion de versions. Nous partagerons la configuration de l’agent GrantPT et les définitions d’outils dans un prochain article pour ceux qui souhaitent reproduire cette approche : restez à l’écoute !

Voici ce que chaque agent a fait :

1. GrantPT - L’assistant à usage général

Accessible à l’ensemble des ~2500 participants à l’exercice, GrantPT était notre agent IA principal et la meilleure démonstration de la facilité avec laquelle Agent Builder permet de mettre en place un assistant performant et adapté à un domaine particulier. La configuration de l’agent se composait d’un objet JSON définissant son invite système, son persona et un tableau d’identifiants d’outils associés, rien de plus. Aucun code d’application personnalisé, aucune couche API sur mesure, simplement une configuration déclarative.

Ce qui a donné à GrantPT sa profondeur, c’était l’outillage. Nous avons défini une combinaison d’outils de plateforme intégrés 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 acceptait 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 par recherche sémantique :

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

Un outil distinct de recherche d’index permettait à l’agent d’énumérer dynamiquement les index de base de connaissances disponibles au début de chaque conversation, ce qui nous permettait d’ajouter de nouveaux index de documentation au cours de l’exercice sans reconfigurer l’agent : il les découvrait simplement lors de l’interaction suivante.

Nous avons également conçu un outil d’intégration Jira qui effectuait une recherche sémantique parmi les tickets d’assistance ingérés, permettant à GrantPT de faire remonter un contexte de dépannage pertinent à partir de demandes de support technique antérieures. Cela s’est avéré particulièrement utile pour les analystes du support technique, qui pouvaient interroger GrantPT sur les problèmes récurrents et obtenir des réponses fondées sur l’historique réel des tickets plutôt que des conseils génériques.

Le comportement de réponse adapté au RBAC résultait d’une combinaison de l’invite système de l’agent, qui lui ordonnait de contextualiser les réponses en fonction du rôle de l’utilisateur, et du modèle de sécurité sous-jacent d’Elasticsearch. 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 remonter que les documents accessibles au rôle de l’utilisateur. Un membre de la Blue Team se renseignant sur les procédures d’exercice obtiendrait des résultats limités aux index accessibles à son équipe, tandis qu’un analyste HelpDesk verrait les résultats provenant d’index spécifiques au helpdesk. L’agent n’avait pas besoin de logique explicite de changement de rôle : la sécurité au niveau du document native d’Elasticsearch a géré le périmètre, et l’agent a simplement fonctionné avec les résultats qui lui ont été renvoyés. C’est l’un des éléments qui rend Agent Builder véritablement élégant : en héritant du modèle de sécurité d’Elasticsearch, vous bénéficiez d’une IA prenant en compte le RBAC sans écrire une seule ligne de code d’autorisation.

2. REDRock - Le compagnon de l’adversaire

Cet agent était exclusivement accessible aux Red Teams. REDRock a suivi le même modèle Agent Builder, avec un prompt système dédié définissant son persona offensif, associé à son propre ensemble d’outils ES|QL personnalisés interrogeant des index spécifiques à la Red Team. Ces index contenaient les playbooks de la Red Team, la documentation de Tuoni C2, les vulnérabilités système connues au sein de l’environnement d’exercice, et des informations sur les services déployés. Les définitions d’outils reproduisaient le même modèle de recherche sémantique paramétrée utilisé par GrantPT, mais étaient limitées aux index accessibles uniquement aux rôles Red Team. Les opérateurs Red Team pouvaient interroger des vecteurs d’attaque, vérifier les faiblesses connues dans les systèmes cibles, et obtenir des conseils contextuels sur leurs plans opérationnels. C’était, très franchement, comme donner aux attaquants un directeur des opérations extrêmement bien briefé.

3. RefPT - L’outil de l’arbitre

Conçu spécialement pour la White Team (les arbitres et évaluateurs de l’exercice), RefPT était relié à des outils interrogeant des index contenant les rapports de la Blue Team, les événements du scénario et les critères de notation. Son objectif était de garantir une notation uniforme et équitable pour l’ensemble des plus de 40 équipes. Le prompt système de l’agent a été ajusté pour croiser les rapports soumis avec les événements connus du scénario et les grilles d’évaluation, aidant ainsi les évaluateurs à identifier les incohérences ou les lacunes. Lorsque vous avez des évaluateurs qui notent simultanément des dizaines d’équipes, disposer d’une IA capable de corréler les rapports avec un index de notation structuré transforme véritablement la donne en matière de cohérence.

Tines : automatisation des workflows alimentée par l’IA

Tines était également utilisateur du service d’IA dans l’environnement d’exercice. Chaque Blue Team disposait d’une instance Tines dédiée, avec des connecteurs d’action Tines provisionnés dans son espace Kibana. Tines pouvait exploiter les capacités d’IA basées sur Bedrock pour une automatisation intelligente des workflows, notamment l’enrichissement automatisé des alertes, les décisions de tri assistées par l’IA, les résumés en langage naturel dans les workflows de notification et la création de workflows en langage naturel. Le connecteur Tines était 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/"
  })
}

Assurer la conformité : garde-fous et audit

Chaque interaction avec l’IA parmi l’ensemble de ces utilisateurs était régie par des garde-fous AWS Bedrock stricts. Nous avons déployé des garde-fous avec un filtrage de contenu (haine, insultes, contenu sexuel et violence à des seuils MOYENS), une protection des données personnes identifiables (blocage des adresses e-mail, des numéros de téléphone, des noms, des adresses, des numéros d’assurance nationale britanniques, des numéros de carte bancaire et des adresses IP), un filtrage thématique pour empêcher toute discussion sur des opérations réellement classifiées et un filtrage des vulgarités. Voici un extrait de la configuration des garde-fous issue de notre code Terraform :

resource "aws_bedrock_guardrail" "dcm5_elastic" {
  name        = "dcm5-prod-elastic-guardrail"
  description = "Garde-fous pour les connecteurs d’IA générative Elastic Kibana DCM5 Prod"

  content_policy_config {
    filters_config {
      input_strength  = "MEDIUM"
      output_strength = "MEDIUM"
      type            = "HATE"
    }
    # ... filtres de contenu supplémentaires pour LES INSULTES, LE CONTENU SEXUEL, LA VIOLENCE
  }

  sensitive_information_policy_config {
    pii_entities_config {
      action = "BLOCK"
      type   = "UK_NATIONAL_INSURANCE_NUMBER"
    }
    pii_entities_config {
      action = "BLOCK"
      type   = "IP_ADDRESS"
    }
    # ... filtres PII supplémentaires
  }

  topic_policy_config {
    topics_config {
      name       = "classified-information"
      definition = "Discussions portant sur des opérations classifiées réelles, des activités militaires réelles actuelles, ou le renseignement opérationnel."
      type       = "DENY"
    }
  }
}

Chaque espace Blue Team disposait de son propre utilisateur IAM pour l’accès à Bedrock, et le paramètre Kibana « genAiSettings:defaultAIConnectorOnly » était appliqué pour empêcher les équipes de configurer leurs propres connecteurs. Ainsi, chaque appel d’API pouvait être attribué à une équipe spécifique via CloudWatch, et le NSOC bénéficiait d’une visibilité d’audit complète. Le groupe de logs CloudWatch « /aws/bedrock/grantpt-prod/invocations » capturait chaque événement d’invocation et de garde-fou.

Les chiffres pour l’ensemble des utilisateurs d’IA parlent d’eux-mêmes : 3 agents d’IA personnalisés, 2797 conversations, et 785 millions de tokens d’IA consommés tout au long de l’exercice.

Monitoring en temps réel en jeu

Dans le cadre du scénario d’exercice, chaque équipe avait accès à RocketChat comme client de messagerie dans l’environnement d’exercice. Chaque Blue Teal disposait de son propre canal, pouvait envoyer des messages directs à toute personne participant à l’exercice, et était libre de créer de nouveaux canaux selon les besoins. Plus important encore pour la tradition DCM, cela incluait le canal des mèmes, pierre angulaire spirituelle de toutes les taquineries entre équipes et de l’humour créatif qui remonte inévitablement le moral lorsqu’on soumet quelques milliers d’opérateurs cyber à la pression pendant une semaine.

Toutes ces données de communication représentaient une formidable fenêtre en temps réel sur la santé de l’environnement d’exercice, le moral des équipes, et les sujets tendance tout au long de l’exercice. L’opportunité était trop belle pour la laisser passer, nous avons donc ingéré l’intégralité du corpus de conversations RocketChat dans Elastic en temps réel, et l’avons mis à profit.

Analyse du moral et reconnaissance d’entités nommées

Pour la reconnaissance d’entités nommées, nous avons déployé le dslim/bert-base-NER modèle de Hugging Face sur un nœud de machine learning du déploiement NSOC à l’aide du client Elastic ELAND. Celui-ci a ensuite été intégré à un pipeline d’ingestion Elasticsearch par lequel passait chaque message RocketChat lors de l’ingestion. Nous avons utilisé les entités extraites et mis en évidence les plus courantes sous forme de thèmes de tableau de bord, nous offrant ainsi une vue en direct du flux et de l’évolution des sujets de conversation tout au long de l’exercice.

Nous avons également analysé l’activité des groupes, les statistiques des utilisateurs et les schémas généraux de communication afin de dresser un tableau des modes de vie de chaque équipe : participants les plus actifs, volume de messages au fil du temps et tendances du moral ventilées par utilisateur. Tout bien considéré, cela nous a donné un aperçu véritablement intéressant de ce qui se passait sur l’environnement d’exercice presque en temps réel. Lorsque nous avons, par exemple, basculé Elastic Agent en mode Prévention, un nuage de mots sur notre tableau de bord s’est immédiatement animé, avec « Elastic » comme thème le plus discuté sur l’ensemble des canaux, les Blue Teams discutant de son efficacité, les Red Teams déplorant la perte de leurs balises. C’est plutôt satisfaisant.

Analyse des mèmes (oui, vraiment)

Enfin, et cela en a surpris plus d’un, nous avons récupéré chaque mème envoyé sur les canaux, vectorisé les images, et exécuté des évaluations des plus proches voisins afin de regrouper les mèmes et les sujets similaires. Nous les avons également soumis au modèle d’inférence NER zero-shot afin de générer des descriptions thématiques du contenu de chaque mème. L’idée était que ces sorties 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 d’importance cruciale sur le plan opérationnel. En revanche, il ne fait aucun doute que cela a été très amusant.

Étouffer les problèmes dans l’œuf

Même si nous espérions que tout se déroulerait sans problème pendant la semaine d’exercice, certains éléments tombent inévitablement en panne, ne sont pas totalement compris ou nécessitent une personnalisation supplémentaire pour s’adapter aux besoins d’utilisation d’une équipe particulière. Pour cela, nous disposions de notre propre sous-section au sein du centre d’assistance de l’environnement d’exercice, où les demandes spécifiques à Elastic et à l’IA générative pouvaient être soumises par n’importe quelle équipe.

Nous avons assuré la permanence de ce service d’assistance pendant toute la durée de l’exercice, en fournissant des conseils, de la documentation, du débogage des problèmes et des recommandations spécifiques à l’environnement d’exercice. Ce dernier point mérite d’être approfondi. Il arrivait que ce qu’une Blue Team observait dans Elastic ne soit pas du tout un problème Elastic, mais plutôt qu’Elastic fasse fidèlement remonter un élément de l’environnement d’exercice qui méritait une enquête plus approfondie (les Red Teams peuvent semer un chaos absolu, et la télémétrie ne ment pas). Au cours de l’exercice, nous avons traité 125 demandes individuelles de support technique émanant d’équipes qui sollicitaient spécifiquement l’aide d’Elastic.

Débogage préemptif avec Tines

Au-delà des visites aux équipes par visioconférence ou en personne lors de l’EXCON, nous avons également collaboré avec Tines pour tester une approche un peu plus proactive. Nous avons extrait le corps du ticket des demandes entrantes, tenté de catégoriser le problème, confronté la catégorisation à notre corpus de tickets précédemment résolus, et demandé à l’IA générative de produire une première réponse résumée visant à résoudre le problème de l’utilisateur avant que le triage ne l’oriente vers notre file d’attente.

Il s’agit en fait d’un modèle que nous avons emprunté à notre propre organisation de support technique chez Elastic, où nous proposons une fonctionnalité similaire en utilisant notre vaste base de connaissances de problèmes précédemment résolus comme référentiel pour alimenter le contexte de l’agent d’IA. L’idée est simple : s’appuyer sur les solutions passées pour proposer une première ébauche éclairée, générée automatiquement, afin de résoudre un problème et éviter qu’un ingénieur du support technique doive traiter manuellement chaque ticket. Cela n’a pas tout résolu ; certains problèmes nécessitaient véritablement une intervention humaine avec un contexte étendu, mais cela a considérablement réduit la pression sur la file d’attente et permis d’apporter des réponses plus rapides aux équipes qui en avaient besoin. Ce fut un tel succès pour nos propres tickets et notre file d’attente que nous avons finalement étendu le périmètre à l’ensemble du centre d’assistance dans la seconde partie de l’exercice, contribuant ainsi à réduire la charge sur les autres groupes de l’équipe Green participant à l’exercice.

Partenariats sectoriels : l’union fait la force

L’une des choses dont nous sommes le plus fiers est la croissance de notre écosystème de partenaires d’année en année. DCM n’est pas seulement une initiative d’Elastic. C’est une véritable coalition de partenaires du secteur, chacun apportant quelque chose d’unique à la plateforme de sécurité.

Année 1 (DCM2) - Elastic a rejoint le projet en tant que partenaire industriel, fournissant la plateforme de surveillance de la sécurité et de détection aux endpoints.

Année 2 (DCM3) - Nous avons fait appel à Endace, offrant une capacité de capture de paquets 1:1. La capture complète de paquets, associée à la visibilité réseau d’Elastic, a permis aux équipes de mener des analyses forensiques approfondies que la seule analyse basée sur les logs ne peut fournir.

Année 3 (DCM4) - Tines a rejoint la famille, apportant l’automatisation des workflows. Les Blue Teams pouvaient désormais créer des playbooks de réponse automatisés, des workflows de tri et des chaînes de notification, le tout directement intégré à leur environnement Elastic via le connecteur natif Tines.

Année 4 (DCM26, anciennement DCM5) - AWS a rejoint l’initiative, en fournissant un accès à Bedrock pour nos agents IA et en contribuant au financement des déploiements Elastic. Il s’agissait d’une étape importante : le fait qu’un hyperscaler investisse directement dans la réussite de l’exercice a permis de débloquer des capacités (telles qu’une inférence IA conforme, hébergée au Royaume-Uni, avec des garde-fous complets et un logging d’audit) qui n’auraient tout simplement pas été possibles autrement. L’intégration de Tines a également été améliorée cette année grâce à l’ajout d’un accès aux LLM dans l’environnement d’exercice. La série DCM a également franchi une étape importante cette année, passant de ses origines en tant qu’initiative de l’Army Cyber Association à un programme officiellement financé relevant du Cyber and Specialist Operations Command.

Aux équipes d’Endace, de Tines et d’AWS : de sincères remerciements. Cet exercice est encore plus réussi grâce à vos contributions, et toutes les équipes sont mieux équipées grâce à la plateforme que nous avons bâtie ensemble. Nous préparons déjà DCM27. Un grand bravo à vous tous !

Culture, points forts, et ce qui en fait tout l’intérêt

Les Challenge Coins

Nous avons fait frapper des challenge coins (pièces commémoratives) personnalisés pour le DCM26. Les connaisseurs le savent bien : les « challenge coins » sont une tradition militaire de longue date, et en faire fabriquer un spécialement pour cet exercice nous a semblé être la meilleure façon de marquer notre quatrième année de participation.

La soirée de cocktail

Nous avons également été très honorés d’être invités au cocktail du haut-commissariat organisé par le haut-commissaire britannique à Singapour. Il y a quelque chose d’assez surréaliste à discuter du nombre de partitions Elasticsearch et de la gestion de l’état Terraform tout en tenant un gin tonic à l’invitation de l’ambassadeur. Ce fut une excellente soirée, un véritable rappel que ces exercices se situent au croisement de la technologie et de la diplomatie, et que les relations nouées ici vont bien au-delà de l’aspect technique.

Pour conclure

L’architecture mutualisée a fait ses preuves sous une charge soutenue, les fonctionnalités natives d’Elastic AI (AI Assistant et Attack Discovery) ont offert 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 produit des résultats qu’aucune organisation ne pourrait atteindre seule.

Defence Cyber Marvel 2026 a été une édition marquante d’un exercice qui ne cesse de gagner en envergure, en complexité et en impact. Pour Elastic, le fait qu’on nous confie la fourniture de la plateforme de sécurité défensive centrale pour 40 Blue Teams issues de 29 nations, et cette année également les fonctionnalités d’IA, est quelque chose que nous prenons très au sérieux. L’exercice permet de développer de véritables compétences pour des personnes réelles qui défendront ensuite des réseaux bien réels, et participer à cette mission a un sens tout particulier.

Comme le communiqué de presse du gouvernement britannique l’indique, DCM démontre la valeur concrète de scénarios réels qui renforcent les partenariats internationaux. Nous partageons tout à fait cet avis.

Nous serons de retour l’année prochaine, et je pense que nous aurons encore plus de sujets à aborder. En attendant, nous continuerons à améliorer le produit afin que le support technique pour des environnements tels que Defence Cyber Marvel excelle d’une année sur l’autre.

Au plaisir de vous retrouver sur le terrain.

Suivez l’histoire de DCM26 sur les réseaux sociaux :

Facebook | LinkedIn | Instagram

Lecture complémentaire

Elastic Security et IA

Infrastructure et outillage

Contexte de l’exercice

Ce contenu vous a-t-il été utile ?

Signaler un problème