Le phénomène dont personne ne veut parler
L'édition 20 24 avrilde « Locked Shields 2026 » s'est achevée à Tallinn, , avec plus de 4 000 participants issus de 41 pays, répartis en 16 équipes multinationales, qui ont dû faire face à environ 8 000 cyberattaques en temps réel visant des infrastructures critiques : défense aérienne, vote électronique, 5G, gestion des satellites et un système de production d'électricité entièrement reproduit. Comme toujours, les communiqués officiels ont salué la capacité des participants à « détecter les cyberactivités malveillantes et y faire face ».
Cette interprétation est exacte. C'est également, année après année, l'aspect dont tout le monde aime parler, et qui masque discrètement une tendance moins flatteuse : les équipes bleues qui rencontrent des difficultés ne le font pas parce que leurs stratégies SOC étaient médiocres. Ils ont du mal parce que quelque chose s'est brisé sous leurs pieds et qu'ils ne l'ont pas vu venir. Ils levaient les yeux vers le niveau 7 , tandis que l'équipe rouge se trouvait déjà au niveau 2.
Si vous avez déjà fait partie d'une équipe bleue, vous connaissez bien ce genre de conversation. Un service cesse de fonctionner. On passe les dix premières minutes à s'en prendre au pare-feu. Les dix minutes suivantes se déroulent sur la console EDR. Au moment où quelqu'un exécute la commande « arp -a » ou consulte une table BGP, la manche est déjà à moitié terminée.
Cet article propose une présentation du modèle OSI, non pas parce que ce modèle à sept couches est sacro-saint, mais parce qu'il constitue la liste de contrôle la plus claire pour les ingénieurs qui ont pris l'habitude de raisonner de manière instinctive en termes de réponse aux incidents. Si votre première réaction face à un message indiquant que « le service est hors service » est de « vérifier le WAF », vous passez à côté de cinq couches de la surface d'attaque dans lesquelles l'équipe rouge s'est déjà infiltrée.
Table des matières
Pourquoi le modèle OSI a toujours sa place
Tous les deux ou trois ans, quelqu'un publie un article affirmant que « le modèle OSI est obsolète, utilisez plutôt le protocole TCP/IP ». Ils ont raison de dire que ce modèle est une abstraction : les couches 5 et 6 , en particulier, relèvent principalement de la gestion interne dans les piles modernes. Ils ont tort de penser que cela rend la chose inutile. OSI est un modèle de triage. Lorsqu'un élément est défectueux ou fait l'objet d'une attaque, parcourir les couches de bas en haut constitue le moyen le plus rapide de localiser l'origine de la défaillance, plutôt que de se limiter aux zones sur lesquelles vos outils ont justement une visibilité.
Les équipes rouges le savent bien. Ils choisissent la couche où votre détection est la plus faible. Dans un environnement Locked Shields, il ne s'agit presque jamais de la couche 7.
Couche 1 : Physique
Dans cet exercice, la couche physique est abstraite, mais le principe reste le même : gestion hors bande, serveurs de console, commutateurs KVM, interfaces de gestion à distance (iDRAC, iLO, IPMI). Ces appareils sont généralement configurés avec des identifiants par défaut ou connectés à des VLAN de gestion partagés, ce qui leur permet de contourner tous les contrôles de détection situés en amont.
L'échec franc de l'équipe bleue : , qui considère le réseau hors périmètre (OOB) comme « une infrastructure ne relevant pas du champ d'application ». Cela relève du champ d'application. Si le « red » parvient à atteindre votre iDRAC, le pare-feu situé en amont n'est qu'une simple façade.
Couche 2 : Liaison de données
C'est là que se produisent la plupart des dégâts, et c'est la couche à laquelle la plupart des défenseurs expérimentés ne prêtent plus attention, car « le commutateur s'en charge ». Le commutateur ne prend pas en charge cette fonction. Ce commutateur applique les paramètres que vous avez configurés, ce qui n'est souvent pas le cas.
Le catalogue des attaques « Layer 2 » n'est pas nouveau. C'est justement ça. Il ne s'agit en rien de recherches inédites :
- L'usurpation ARP/l'empoisonnement du cache fonctionne toujours sur tout segment ne disposant pas de l'inspection ARP dynamique. Permet à l'attaquant d'adopter une position d'« homme du milieu » invisible pour vos outils de niveau 3 et au-delà
- , une technique d'inondation de la table CAM, transforme un commutateur en concentrateur, diffusant ainsi des trames que l'attaquant peut intercepter
- « VLAN hopping » via le double balisage ou l'utilisation abusive du protocole DTP : il suffit d'un seul port trunk mal configuré pour que votre réseau « segmenté » devienne un réseau plat
- Pénurie de DHCP et DHCP non autorisé : attribuez votre propre passerelle et acheminez tout le trafic par celle-ci
- Les attaques STP prétendent être le pont racine, modifient la topologie L2 et font passer le trafic par votre tap
- s d'injection LLDP/CDP utiles pour la reconnaissance et, sur certaines plateformes, pour tromper les appareils voisins
Ces mesures de sécurité sont anciennes, bien documentées et systématiquement mises en œuvre de manière incomplète : sécurité des ports, surveillance DHCP, inspection ARP dynamique, BPDU Guard, Root Guard, désactivation du protocole DTP, séparation des VLAN de gestion. Aucun d'entre eux ne figure en couverture d'un livre blanc d'un fournisseur. Tous ces éléments déterminent l'issue des manches.
L'erreur honnête de l'équipe bleue : . Elle s'est fiée au fait que l'équipe réseau s'en était chargée en 2019 et n'a jamais vérifié par la suite. Effectuez les vérifications. Cela prend une heure.
Couche 3 : Réseau (et oui, le BGP)
La couche IP est le domaine dans lequel les défenseurs se sentent à l'aise, mais ce sentiment de sécurité n'a plus lieu d'être dès lors que l'on aborde les protocoles de routage.
Pour le routage interne (OSPF, EIGRP, IS-IS), le même schéma que celui décrit au paragraphe L2 se répète. L'authentification est facultative dans le protocole, obligatoire dans la pratique, et systématiquement désactivée « pour l'instant » dans les environnements de laboratoire et d'entraînement, ce qui finit par s'ancrer dans la mémoire musculaire en production. Un attaquant présent sur un segment de peering ne disposant pas d'authentification OSPF MD5/SHA peut injecter des routes, envoyer le trafic vers un trou noir ou le rediriger discrètement.
Et puis, il y a le BGP. Le BGP assure le fonctionnement d'Internet selon un modèle de confiance dont les origines remontent aux RFC 1105 et 1989, et les scénarios « Locked Shields » l'intègrent de plus en plus, car les adversaires réels le font également. La surface d'attaque concernée :
- Détournements de routes : : annoncer un préfixe plus précis dont vous n'êtes pas propriétaire afin d'attirer le trafic vers vous
- Fuites d'itinéraires : désignant la transmission, d'un nœud à un autre, d'itinéraires appris en violation de la politique, souvent par inadvertance, ce qui a le même impact opérationnel qu'un détournement
- Réinitialisation des sessions : « » utilise un trafic TCP spécialement conçu pour interrompre les sessions BGP. C'est la raison pour laquelle le protocole TCP-AO (RFC 5925), anciennement appelé TCP MD5, existe
- Manipulation des chemins : Ajout d'un préfixe AS-path et abus de communauté pour rediriger le trafic d'une manière que votre système de surveillance ne détecte pas, car les routes restent « valides »
Les mesures d'atténuation sont d'ordre opérationnel et ne concernent pas les produits : validation de l'origine via le RPKI, limites maximales de préfixes, filtres de préfixes sur chaque session eBGP, authentification des pairs, BGPsec lorsque cela est possible. Si votre réponse à la question « Sommes-nous exposés à une fuite de routage provenant de notre fournisseur en amont ? » est « Le pare-feu la bloquera », sachez que ce ne sera pas le cas. Le pare-feu détecte les paquets qui arrivent. Il ne se rend pas compte qu'ils sont arrivés par un chemin qui ne devrait pas exister.
L'échec franc de l'équipe bleue : considérer le routage comme un « problème relevant de l'équipe réseau », isolé de la sécurité. Que ce soit dans le cadre d'un exercice ou dans la réalité, le routage est synonyme de sécurité.
Couche 4 : Transport
Il y a moins de complications ici, mais les principes fondamentaux restent essentiels : protection contre les attaques par inondation SYN, délais d'expiration TCP raisonnables, prise de conscience du fait qu'une session TCP inactive peut être détournée en cas de fuite des numéros de séquence, et vecteurs d'amplification UDP sur tout service que vous exposez (DNS, NTP, memcached, CLDAP). La plupart des défenseurs s'en sortent très bien. L'erreur au niveau L4 n'est généralement pas liée à la détection. Il s'agit d'une exposition à « » :. Des services accessibles depuis des segments depuis lesquels ils ne devraient pas l'être.
Niveaux 5 et 6 : Session et présentation
Concrètement, il s'agit de « TLS et tout ce qui s'y rapporte ». Des algorithmes de chiffrement faibles, des certificats périmés ou mal validés, des erreurs de configuration de la reprise de session, un protocole TLS « mutuel » qui n'est en réalité pas mutuel, car le serveur ne vérifie pas la chaîne de certificats du client. Les scénarios « Locked Shields » intègrent systématiquement des configurations TLS incorrectes afin de créer un piège délibéré. Les responsables de la sécurité qui se contentent de vérifier que « le protocole HTTPS est activé » passent à côté de l'essentiel.
L'autre problème sous-estimé du L5/6 concerne la gestion des sessions d'application : des identifiants de session prévisibles, des jetons qui ne changent pas et des JWT non signés. Il s'agit de L7 vulnérabilités au sens de l'OWASP, mais elles se situent à la jonction entre la session et la présentation, et c'est grâce à elles qu'un attaquant ayant déjà pris pied parvient à s'implanter durablement en s'appropriant une identité.
Couche 7 : Application
C'est là que se trouvent la plupart des outils de défense, ce qui explique pourquoi la plupart des responsables de la sécurité ont naturellement tendance à se concentrer sur cet aspect. Vulnérabilités Web, comportement des logiciels malveillants, abus d'authentification, failles de logique des API. Rien de tout cela n'est sans importance, mais ce sont des aspects bien connus, et votre pile en tient déjà compte. Le biais à corriger est justement l'inverse : si, trente minutes après le début d'un incident, vous vous retrouvez toujours à chercher une explication « L7 » alors que les symptômes ne correspondent pas, remontez dans la pile.
Le pare-feu n'est pas le sujet
Une hypothèse de travail issue de nombreuses années de rapports post-exercice « Locked Shields » et des activités professionnelles quotidiennes qui les alimentent : l'ingénieur expérimenté moyen de l'équipe bleue accorde trop d'importance à la détection et pas assez à la configuration. C'est la détection qui fait le succès de leurs outils. C'est la configuration qui détermine si l'on gagne ou si l'on perd la manche.
A useful pre-engagement 5 step checklist for an experienced defender, in the order an attacker thinks about them:
- La couche 2 est-elle sécurisée sur chaque commutateur d'accès : sécurité des ports, surveillance DHCP, DAI, BPDU Guard, désactivation du DTP, VLAN de gestion séparé ?
- Les sessions des protocoles de routage sont-elles authentifiées, avec des filtres « max-prefix » et « prefix » sur chaque pair eBGP ? La validation RPKI est-elle réellement appliquée, ou simplement activée ?
- Les plans de gestion (OOB, iDRAC/iLO/IPMI, gestion des commutateurs, consoles d'hyperviseur) se trouvent-ils sur un segment auquel votre attaquant ne peut pas accéder à partir d'un terminal utilisateur compromis ?
- La configuration TLS est-elle vérifiée, et non pas simplement supposée : y compris la validation du certificat client lorsque le protocole mTLS est déclaré ?
- Ensuite, la pile L7 : règles WAF, couverture EDR, détections SIEM, guides d'intervention en cas d'incident.
L'ordre a son importance. C’est au niveau des quatre premiers points que l’on perd discrètement des tours avant même que la phase « » (IR) ne commence. Ce sont également les éléments les moins susceptibles d'apparaître dans une présentation de bilan trimestriel, car ils ne génèrent pas d'alertes lorsqu'ils fonctionnent correctement.
Le rôle de Tanium (une fois que les bases sont bien en place)
Je tiens à être franc quant à la portée de ce projet. Tanium n'authentifie pas vos pairs BGP. Cela ne configure pas l'inspection ARP dynamique sur vos commutateurs d'accès. Les quatre premiers points de la liste de contrôle ci-dessus relèvent de l'ingénierie réseau, et aucune plateforme de terminaux ne peut se substituer à ce travail.
Mais dès que vous remontez la pile, la situation change. En effet, une fois le plan réseau correctement configuré, la question suivante se pose : savez-vous réellement ce qui s'exécute sur chaque terminal ? A-t-il été mis à jour, sécurisé et configuré comme vous le pensez ? Fonctionner comme il se doit, sans plus ?
C'est à ce niveau que nous avons déployé Tanium lors de l'édition 2026 de Locked Shields. Pendant la période de diffusion en direct, la plateforme a proposé :
- Inventaire en temps réel de tous les hôtes du parc informatique pour Windows et Linux, y compris les segments que nous avons intégrés en cours d'exercice
- La liste des composants logiciels et la visibilité au niveau des bibliothèques couvrent tous les terminaux, jusqu'au niveau des composants et des versions
- Données relatives aux vulnérabilités directement liées à la correction : . Identifiez la bibliothèque vulnérable, puis déployez le correctif depuis la même console.
- Déploiement automatique de l'agent Tanium sur les hôtes nouvellement détectés, sans file d'attente d'intégration manuelle
- La distribution et la mise à jour des agents antivirus et EDR des partenaires sont effectuées en parallèle avec Tanium sur l'ensemble du parc informatique à partir d'une console unique
- Mise à jour à grande échelle des correctifs tiers pour les systèmes d'exploitation et les applications , , tels que les mises à jour cumulatives de Windows, les correctifs .NET, SharePoint, le noyau Linux et les bibliothèques
- Des scripts de renforcement de la sécurité ont été déployés et réappliqués sur l'ensemble du parc informatique, de sorte qu'aucun hôte ne soit resté non configuré
- La rotation des identifiants locaux a été mise en place à un rythme soutenu afin de limiter la durée de vie utile de tout mot de passe volé
- Solutions personnalisées de réponse aux incidents , élaborées dans l'urgence et déployées sur l'ensemble du parc informatique, couvrant le déploiement de règles de pare-feu, le nettoyage des traces de persistance et la suppression des implants
- de détection des menaces sur l'ensemble du parc de terminaux à partir d'une console unique
- de transmission des commandes par agents, servant de solution de secours en cas de dégradation des chemins réseau standard
Rien de tout cela ne remplace une bonne maîtrise de la couche 2 . Tout cela cesse de fonctionner si vous ne savez pas de quels points de terminaison vous disposez. Ces deux disciplines sont complémentaires. Les équipes qui obtiennent de bons résultats lors du concours « Locked Shields » exploitent ces deux éléments en parallèle : un plan réseau renforcé en arrière-plan et un parc de terminaux entièrement géré et totalement visible en avant-plan.
À retenir
« Locked Shields » est impressionnant, et les techniques d'IR qu'il met en avant sont bien réelles. Mais cet exercice ne cesse de démontrer, année après année, que ce sont les défenseurs expérimentés qui s'imposent aux niveaux fondamentaux. L'équipe qui a sécurisé les protocoles ARP et DHCP sur le segment d'accès, authentifié ses sessions de routage et segmenté son plan de gestion l'emportera, en moyenne, sur l'équipe disposant d'un guide d'intervention SOAR plus sophistiqué.
Si vous ne devez retenir qu'une seule chose de cet article : , la prochaine fois qu'un problème survient et que votre premier réflexe est d'ouvrir la console du pare-feu, commencez par exécuter les commandes suivantes : show mac address-table ou show ip bgp summary . La réponse se trouve plus souvent là que vous ne voulez bien l'admettre. Ensuite, une fois que la couche réseau est opérationnelle, assurez-vous de disposer d'une véritable plateforme de terminaux qui s'appuie sur celle-ci. Commençons par les bases. La plateforme, en deuxième lieu. Dans cet ordre.
Chiffres et citations relatifs à « Locked Shields 2026 » via , CCDCOE, , SHAPE OTAN, et détails du scénario de l'exercice confirmés via , SANS Institute.
Image en vedette : Blue Team 10 @ Locked Shields
