Le modèle dont personne ne veut parler
Locked Shields 2026 s’est conclu à Tallinn le 24 avril, avec plus de 4 000 participants de 41 nations formant 16 équipes multinationales contre environ 8 000 cyberattaques en temps réel sur des infrastructures critiques : défense aérienne, vote électronique, 5G, gestion satellite et un système de production d’énergie entièrement construit. Les communiqués officiels, comme toujours, ont salué la capacité des participants à « détecter et répondre aux cyberactivités malveillantes ».
Ce cadrage est vrai. C’est également, année après année, la partie dont tout le monde veut parler, et cela inonde discrètement un modèle moins flatteur : les équipes bleues qui luttent ne luttent pas parce que leurs manuels SOC étaient faibles. Ils ont du mal parce que quelque chose s’est brisé en dessous d’eux et ils n’ont jamais vu cela venir. Ils regardaient vers la couche 7 alors que l’équipe rouge était déjà à la couche 2.
Si vous avez siégé dans une équipe bleue, vous connaissez la conversation. Un service devient sombre. Les dix premières minutes sont passées à crier sur le pare-feu. Les dix suivantes sont dépensées sur la console EDR. Lorsque quelqu’un exécute arp -a ou regarde un tableau BGP, le tour est terminé à moitié.
Cette publication est une présentation du modèle OSI, non pas parce que le modèle à sept couches est sacré, mais parce qu’il s’agit de la liste de contrôle la plus propre pour les ingénieurs qui se sont détournés vers la réflexion IR réflexe. Si votre réponse instinctive au « service est en panne » est « vérifiez le WAF », vous sautez cinq couches de surface d’attaque dans lesquelles l’équipe rouge a déjà emménagé.
Table des matières
Pourquoi le modèle OSI gagne toujours sa place
Tous les quelques années, quelqu’un publie une prise « le modèle OSI est mort, utilisez TCP/IP ». Ils ont raison que le modèle est une abstraction : les couches 5 et 6 en particulier sont principalement comptables dans les piles modernes. Ils ont tort que cela le rend inutile. L’OSI est un cadre de triage. Lorsque quelque chose est cassé ou sous attaque, parcourir les couches de bas en haut est le moyen le plus rapide de savoir où se trouve la défaillance, au lieu de savoir où votre outillage se trouve avoir de la visibilité.
Les équipes rouges le savent. Ils choisissent la couche où votre détection est la plus fine. Dans un environnement Locked Shields, ce n’est presque jamais la couche 7.
Couche 1 : physique
Dans l’exercice, la couche physique est abstraite, mais la leçon se traduit par : gestion hors bande, serveurs de console, KVM, interfaces de gestion des lumières éteintes (iDRAC, iLO, IPMI). Ils sont systématiquement laissés sur les informations d’identification par défaut ou les VLAN de gestion partagée, et ils offrent un chemin qui contourne chaque contrôle de détection au-dessus d’eux.
L’échec honnête de l’équipe bleue : traiter le réseau OOB comme « infrastructure, pas dans le champ d’application ». C’est dans le champ d’application. Si le rouge peut atteindre votre iDRAC, le pare-feu au-dessus est décoratif.
Couche 2 : liaison de données
C’est là qu’une quantité disproportionnée de dommages se produit, et c’est la couche à laquelle les défenseurs les plus expérimentés ont cessé de penser parce que « le switch le gère ». Le switch ne le gère pas. Le switch applique ce que vous avez configuré, ce qui n’est souvent rien.
Le catalogue des attaques de la couche 2 n’est pas nouveau. C’est l’intérêt. Aucune de ces recherches n’est nouvelle :
- L’usurpation d’ARP/empoisonnement de cache fonctionne toujours sur n’importe quel segment sans inspection ARP dynamique. Donne à l’attaquant une position d’homme au milieu invisible pour vos outils L3+
- L’inondation de la table CAM transforme un commutateur en hub, diffusant des trames que l’attaquant peut renifler
- Saut VLAN via double marquage ou abus DTP : votre réseau « segmenté » est un port de jonction mal configuré éloigné du plat
- DHCP famine et DHCP indésirable distribue votre propre passerelle, achemine tout le monde à travers celle-ci
- Les attaques STP prétendent être le pont racine, remodeler la topologie L2 , forcer le trafic via votre tap
- Injection LLDP/CDP utile pour la reconnaissance et, sur certaines plateformes, pour tromper les appareils voisins
Les défenses sont anciennes, bien documentées et chroniquement à moitié déployées : sécurité des ports, surveillance DHCP, inspection ARP dynamique, protection BPDU, protection racine, désactivation de DTP, séparation des VLAN de gestion. Aucun d’entre eux ne figure en couverture d’un livre blanc du fournisseur. Tous décident des tours.
L’échec honnête de l’équipe bleue : faire confiance à l’équipe réseau en 2019 et ne plus jamais le vérifier. Exécutez les vérifications. Elles prennent une heure.
Couche 3 : réseau (et oui, BGP)
La couche IP est l’endroit où les défenseurs se sentent à l’aise, et ce confort est égaré une fois que vous passez aux protocoles de routage.
Pour le routage interne (OSPF, EIGRP, IS-IS), le même modèle que L2 se répète. L’authentification est facultative dans le protocole, obligatoire en réalité et systématiquement désactivée « pour l’instant » dans les environnements de laboratoire et d’exercice qui finissent ensuite dans la mémoire musculaire de production. Un pirate informatique sur un segment de peering sans authentification OSPF MD5/SHA peut injecter des itinéraires, du trafic en trou noir ou le rediriger silencieusement.
Puis il y a BGP. BGP exécute Internet sur un modèle de confiance dont les racines remontent à la RFC 1105 en 1989, et les scénarios Locked Shields l’incluent de plus en plus parce que les adversaires du monde réel le font également. La surface d’attaque pertinente :
- Détournements d’itinéraire : annonce d’un préfixe plus spécifique que vous ne possédez pas pour attirer le trafic vers vous
- Fuites d’itinéraire : annonce des itinéraires appris d’un pair à un autre en violation de la politique, souvent accidentellement, avec le même impact opérationnel qu’un détournement
- Réinitialisations de session : utilisation du trafic TCP conçu pour supprimer les sessions BGP. C’est pourquoi TCP-AO (RFC 5925), ou historiquement TCP MD5, existe
- Manipulation du chemin : chemin AS en attente et abus communautaire pour déplacer le trafic de manière à ce que votre surveillance ne détecte pas, car les itinéraires sont toujours « valides »
Les atténuations sont opérationnelles, et non en forme de produit : validation de l’origine RPKI, limites de préfixe max, filtres de préfixe sur chaque session eBGP, authentification peer, BGPsec où vous pouvez l’obtenir. Si votre réponse à « sommes-nous vulnérables à une fuite d’itinéraire en amont » est « le pare-feu va l’attraper », ce ne sera pas le cas. Le pare-feu voit les paquets qui arrivent. Il ne peut pas voir qu’ils sont arrivés via un chemin qui ne devrait pas exister.
L’échec honnête de l’équipe bleue : traiter le routage comme un « problème d’équipe réseau » isolé de la sécurité. Dans un exercice, et en réalité, le routage est la sécurité.
Couche 4 : Transport
Moins dramatique ici, mais les bases restent importantes : protection contre les inondations SYN, délais d’expiration TCP sensibles, prise de conscience qu’une session TCP inactive peut être détournée si des numéros de séquence fuient, vecteurs d’amplification UDP sur tout service que vous exposez (DNS, NTP, mise en mémoire, CLDAP). La plupart des défenseurs couvrent cela avec compétence. L’erreur à L4 n’est généralement pas détectée. C’est l’ exposition. Services accessibles à partir de segments dont ils ne devraient pas être joignables.
Couches 5 et 6 : session et présentation
En pratique, il s’agit de « TLS et tout ce qui l’entoure ». Chiffreurs faibles, certificats expirés ou incorrectement validés, erreurs de configuration de reprise de session, TLS mutuel qui n’est pas réellement mutuel car le serveur ne vérifie pas la chaîne de certification du client. Les scénarios Locked Shields intègrent régulièrement un TLS mal configuré comme piège délibéré. Les défenseurs qui vérifient uniquement que « HTTPS est activé » le manquent.
L’autre problème L5/6 sous-évalué est la gestion des sessions d’application : identifiants de session prévisibles, jetons qui ne tournent pas, JWT signés sans aucun. Il s’agit de L7 vulnérabilités au sens de l’OWASP, mais elles vivent au niveau de la phase de session/présentation, et c’est ainsi qu’un attaquant ayant une présence pivote vers une identité à long terme.
Couche 7 : Application
C’est là que la plupart des outils défensifs vivent réellement, c’est pourquoi la plupart des défenseurs pensent par défaut ici. Vulnérabilités Web, comportement malveillant, abus d’authentification, défauts de logique d’API. Rien n’est sans importance, c’est tout simplement très fréquent, et votre pile y prête déjà attention. Le biais à corriger est l’inverse : si vous vous retrouvez trente minutes dans un incident poursuivant toujours une explication L7 lorsque les symptômes ne correspondent pas, redescendez dans la pile.
Le pare-feu n’est pas l’histoire
Une hypothèse de travail d’années de rapports de post-action Locked Shields, et des tâches quotidiennes qui les alimentent : l’ingénieur d’équipe bleu expérimenté médian l’emporte sur la détection et l’alourdit sur la configuration. La détection est ce que vendent leurs outils. La configuration est ce qui perd ou gagne le tour.
Une liste de contrôle d’étape 5 utile avant l’engagement pour un défenseur expérimenté, dans l’ordre dans lequel un attaquant y pense :
- La couche 2 est-elle renforcée sur chaque commutateur d’accès : sécurité des ports, surveillance DHCP, DAI, protection BPDU, aucun DTP, VLAN de gestion séparé ?
- Les sessions de protocole de routage sont-elles authentifiées, avec des filtres de préfixe max. et de préfixe sur chaque peer eBGP ? La validation RPKI est-elle réellement appliquée, pas seulement activée ?
- Les plans de gestion (OOB, iDRAC/iLO/IPMI, gestion des commutateurs, consoles d’hyperviseur) sont-ils sur un segment que votre pirate informatique ne peut pas atteindre à partir d’un endpoint utilisateur compromis ?
- La configuration TLS est-elle vérifiée, non supposée : y compris la validation du certificat client où mTLS est revendiqué ?
- Puis la pile L7 : règles WAF, couverture EDR, détections SIEM, playbooks IR.
La commande est importante. Les quatre premiers éléments sont là où les rondes sont perdues silencieusement avant même le début de la phase IR . Ce sont également les éléments les moins susceptibles d’être sur une diapositive d’examen trimestriel, car ils ne génèrent pas d’alertes lorsqu’ils travaillent.
Où Tanium s’inscrit (une fois que les bases sont correctes)
Je veux être honnête sur la portée. Tanium n’authentifie pas vos pairs BGP. Il ne configure pas l’inspection ARP dynamique sur vos commutateurs d’accès. Les quatre premiers éléments de la liste de contrôle ci-dessus sont l’ingénierie réseau, et aucune plateforme d’endpoint ne remplace ce travail.
Mais dès que vous remontez la pile, l’image change. Parce qu’une fois le plan réseau configuré correctement, la question suivante est : savez-vous réellement ce qui s’exécute sur chaque endpoint ? Correctif, renforcé, configuré comme vous le pensez ? Exécuter les services qu’il devrait, et rien de plus ?
C’est la couche où nous avons déployé Tanium à Locked Shields 2026. Pendant la fenêtre en temps réel, la plateforme a fourni :
- Inventaire en temps réel de chaque hôte sur le domaine pour Windows et Linux, y compris les segments que nous avons intégrés à mi-exercice
- La nomenclature logicielle et la visibilité au niveau de la bibliothèque couvrent chaque endpoint, jusqu’aux composants et aux versions
- Données de vulnérabilité directement liées à la remédiation : trouvez la bibliothèque vulnérable, déployez le correctif à partir de la même console
- Déploiement automatique de l’agent Tanium sur les hôtes nouvellement découverts, sans file d’attente d’intégration manuelle
- Distribution et mise à jour des agents AV et EDR partenaires poussées aux côtés de Tanium sur l’ensemble de la flotte à partir d’une console unique
- Correctifs du système d’exploitation et tiers à grande échelle , tels que les mises à jour cumulatives Windows, .NET, SharePoint, le noyau Linux et les correctifs de bibliothèque
- Renforcement des scripts déployés et réappliqués dans l’ensemble du domaine, de sorte qu’aucun hôte n’est resté non configuré
- Rotation des informations locales déployée à une courte cadence pour limiter la durée de vie utile de tout mot de passe volé
- Packages personnalisés de réponse aux incidents créés sous pression et envoyés à la flotte, couvrant le déploiement de règles de pare-feu, le nettoyage de persistance, le retrait des implants
- Recherche des menaces sur l’ensemble du parc d’endpoints à partir d’une console unique
- Livraison de commande basée sur agent en tant que repli lorsque les chemins réseau standard ont été dégradés
Aucun de ces éléments ne remplace l’obtention de la bonne couche 2 . Tout cela cesse de fonctionner si vous ne savez pas quels endpoints vous avez. Les deux disciplines sont complémentaires. Les équipes qui fonctionnent bien chez Locked Shields fonctionnent en parallèle : un plan réseau renforcé en dessous et un parc d’endpoints entièrement géré et entièrement visible en haut.
Les points à retenir
Les boucliers verrouillés sont impressionnants et le travail IR qu’ils présentent est réel. Mais l’exercice continue également de montrer, année après année, que les défenseurs ont connu la victoire dans les couches fondamentales. L’équipe qui a verrouillé ARP et DHCP sur le segment d’accès, authentifié ses sessions de routage et segmenté son plan de gestion va, en moyenne, battre l’équipe avec le manuel SOAR plus précis.
Si vous prenez une chose de cette publication : la prochaine fois que quelque chose se casse et que votre réflexe est d’ouvrir la console du pare-feu, d’ouvrir Afficher la table d’adresses mac ou d’ afficher d’abord le résumé ip bgp . La réponse est plus souvent là que vous ne le souhaitez. Ensuite, une fois que le plan réseau est sonore, assurez-vous d’avoir une véritable plateforme d’endpoint située au-dessus. Les bases en premier. Deuxième plateforme. Dans cet ordre.
Shields verrouillés 2026 chiffres et citations via CCDCOE, SHAPE NATO et détails du scénario d’exercice confirmés via SANS Institute.
Image présentée par : Blue Team 10 @ Locked Shields
