Un adversaire ayant obtenu un accès initial à un réseau militaire n'annonce pas sa présence avec des logiciels malveillants bruyants correspondant à des signatures. Il se déplace lentement, en utilisant des protocoles déjà présents, des crédentiels déjà valides et des chemins de communication qui existent déjà. L'analyse du trafic réseau (NTA) est la discipline qui rend ce mouvement visible : en comprenant à quoi ressemble le trafic normal sur un réseau classifié spécifique et en construisant une logique de détection autour des écarts par rapport à cette norme, les outils NTA font émerger les indicateurs comportementaux que les systèmes de détection d'intrusion basés sur les signatures manquent. Cet article couvre les méthodes techniques pour établir des référentiels, détecter les anomalies de protocole, identifier les modèles de mouvement latéral et intégrer la sortie NTA dans un SIEM d'une manière qui produit des alertes exploitables plutôt que du bruit.

Pourquoi le trafic des réseaux militaires présente des défis d'analyse uniques

Les réseaux militaires diffèrent des environnements d'entreprise de manière à affecter directement la façon dont les outils NTA doivent être configurés et réglés. La différence structurelle la plus significative est la segmentation par frontières de classification : le trafic entre les enclaves à différents niveaux de classification est strictement contraint par la politique, et tout flux franchissant une frontière qui n'a pas été explicitement autorisé est une anomalie immédiate de haute confiance. Cette prévisibilité est un atout analytique que les outils NTA d'entreprise ne sont pas conçus pour exploiter. Un outil conçu pour un réseau commercial où tout utilisateur peut atteindre n'importe quel point de terminaison SaaS génère une variation de référentiel bien plus importante que celui déployé dans une enclave où 90 % du trafic légitime transite entre un petit ensemble de serveurs d'applications et de postes de travail clients sur des ports définis.

La population de protocoles sur les réseaux militaires ajoute une autre couche de complexité. Les applications de commandement et contrôle héritées, les systèmes de messagerie STANAG, les passerelles vocales sécurisées et les intergiciels d'intégration de capteurs spécialisés coexistent avec les protocoles de domaine Windows standard. Un capteur NTA qui décode uniquement les protocoles d'entreprise communs classifiera une fraction substantielle du trafic d'applications militaires comme des flux UDP ou TCP inconnus, dégradant sa capacité à détecter les anomalies au sein de ces familles de protocoles. Un déploiement NTA efficace sur les réseaux militaires nécessite soit des décodeurs de protocoles personnalisés, soit une étroite intégration avec les propriétaires d'applications pour cartographier quels ports et caractéristiques de flux correspondent au comportement légitime de l'application.

La variation du tempo opérationnel crée des défis de référencement que les systèmes à seuils statiques ne peuvent pas accommoder. Un exercice d'entraînement sature le réseau avec du trafic de simulation. Une rotation de déploiement modifie temporairement la population d'utilisateurs et la combinaison d'applications. Un système NTA qui verrouille un référentiel pendant une période de garnison calme génèrera des faux positifs excessifs lors d'opérations à tempo élevé s'il ne peut pas adapter son modèle statistique au contexte opérationnel actuel. Les modèles de référentiel en flux continu qui se mettent à jour en permanence avec des paramètres d'inertie configurables sont plus appropriés aux environnements militaires que les approches à période de référence fixe.

Établissement des référentiels de trafic : à quoi ressemble la normalité dans un réseau classifié

Un référentiel de trafic n'est pas un chiffre unique. C'est un modèle statistique multidimensionnel qui capture la distribution typique des protocoles, des volumes de flux, des taux de connexion, des comptages d'octets par session et des relations entre paires de communication sur le réseau à différentes heures de la journée, jours de la semaine et phases opérationnelles. Construire un référentiel significatif nécessite de collecter la télémétrie de flux ou des données de paquets complets en continu pendant une période suffisamment longue pour capturer toute la variation de l'activité réseau légitime -- généralement quatre à huit semaines sur une enclave militaire. Durant cette période, le système NTA construit des profils par hôte, par enclave et par protocole qui forment la distribution de référence par rapport à laquelle les observations futures sont comparées.

La dimension analytiquement la plus utile d'un référentiel de réseau militaire est le graphe de communication : quels hôtes communiquent avec quels autres hôtes, en utilisant quels protocoles, à quels volumes moyens d'octets et taux de connexion. Sur une enclave militaire bien segmentée, le graphe de communication est clairsemé. La plupart des postes de travail communiquent avec un petit nombre de services d'infrastructure (contrôleurs de domaine, résolveurs DNS, serveurs d'applications, serveurs de fichiers) et rarement entre eux. Un nouvel arc dans ce graphe -- un poste de travail qui n'a jamais communiqué avec un serveur particulier ouvrant soudainement une connexion vers celui-ci -- est statistiquement significatif d'une manière qui ne le serait pas sur un réseau d'entreprise plat où la communication latérale est routinière. Les outils NTA qui modélisent explicitement le graphe de communication, plutôt que simplement des seuils volumétriques, fournissent une sensibilité de détection de mouvement latéral substantiellement meilleure sur les enclaves classifiées.

La qualité du référentiel dépend de manière critique de l'exhaustivité de la couverture des sondes pendant la période de collecte. Un référentiel construit uniquement à partir du trafic périmétrique sera aveugle aux flux est-ouest qui ne franchissent jamais le capteur périmétrique. Un référentiel construit à partir d'un port SPAN qui abandonne des paquets sous charge sous-comptera les protocoles à haut volume, amenant le modèle statistique à traiter ces taux de protocole comme anormalement élevés lors d'opérations normales. Avant de s'engager dans une période de référencement, vérifier la couverture des sondes par rapport au schéma de topologie réseau et confirmer que le capteur reçoit un trafic sans perte aux volumes attendus. Les lacunes découvertes après la période de référencement nécessitent un nouveau référencement à partir de ce point de sonde plutôt que de corriger le modèle avec des estimations.

Analyse des protocoles : détecter les usages de protocoles non autorisés ou anomaux

La détection des anomalies au niveau des protocoles fonctionne sur une logique plus simple que le référencement comportemental : si un protocole n'est pas censé être présent sur un segment réseau donné, toute instance de ce protocole est une alerte. Le défi consiste à définir la matrice de protocoles autorisés avec une granularité suffisante pour être opérationnellement significative. Une règle qui bloque tous les protocoles non-Windows-domaine sur un VLAN de postes de travail détectera SSH, Telnet et IRC utilisés comme canaux dissimulés, mais alertera également sur chaque application légitime utilisant des ports non standard à moins que ces applications ne soient énumérées et que leurs flux ne soient mis sur liste blanche par port et IP de destination. La matrice de protocoles autorisés est un document vivant qui doit être maintenu à mesure que les applications changent, et les outils NTA qui peuvent automatiquement détecter l'apparition d'un nouveau protocole dans un segment et proposer une mise à jour de la liste blanche réduisent la charge administrative du maintien de la matrice à jour.

Le tunnelage de protocoles -- encapsulation d'un protocole dans un autre pour contourner l'inspection -- est une technique persistante sur les réseaux militaires précisément parce que le protocole externe est souvent autorisé. Le tunnelage DNS encode des données arbitraires dans les enregistrements de requête et de réponse DNS, exploitant le fait que le trafic DNS est rarement bloqué aux périmètres militaires. Le tunnelage HTTP/HTTPS transporte du trafic de contrôle non HTTP à l'intérieur de sessions HTTP pour sortir via des proxies web. Le tunnelage ICMP encode des données dans le champ de charge utile des paquets d'écho ICMP. La détection NTA du tunnelage repose sur les signatures comportementales des protocoles plutôt que sur des règles basées sur les ports : un flux DNS avec des noms de requête inhabituellement longs, des taux de requête élevés depuis un seul hôte et des réponses transportant de grands enregistrements TXT ou AAAA est caractéristique du tunnelage DNS indépendamment du fait qu'il utilise le port 53. Les outils qui effectuent une inspection approfondie des paquets sur les protocoles autorisés pour vérifier que le trafic est conforme à la grammaire de protocole attendue sont significativement plus efficaces que les outils qui font confiance aux numéros de port comme identifiants de protocole.

La détection des canaux dissimulés s'étend au-delà des techniques de tunnelage connues à l'analyse statistique de l'entropie des champs de protocole et des modèles de synchronisation. Un canal dissimulé qui encode des données dans les bits d'ordre inférieur des numéros de séquence TCP ou dans les champs de rembourrage des en-têtes IP ne produira pas de violations inhabituelles de la grammaire des protocoles, mais il produira des anomalies statistiques : des distributions de numéros de séquence qui ne sont pas aléatoires, des valeurs de champs de rembourrage qui corrèlent entre les connexions, ou un timing inter-paquets qui correspond à un schéma d'encodage connu. Ces détections nécessitent des modules d'analyse statistique dédiés plutôt qu'une détection générique des anomalies et sont les plus pratiques lorsqu'elles sont appliquées aux segments réseau à haute valeur plutôt qu'à la couverture réseau complète.

Détection des mouvements latéraux : indicateurs d'abus de SMB, WMI et Kerberos

Le mouvement latéral sur les réseaux militaires basés sur Windows suit des chemins de protocole prévisibles car l'écosystème Windows offre un ensemble limité de mécanismes d'exécution distante intégrés. SMB (Server Message Block, port 445) est le plus fréquemment détourné car il prend en charge non seulement le partage de fichiers mais aussi la communication par canaux nommés utilisée par DCOM, la création de services via le Gestionnaire de contrôle des services, et la manipulation des tâches planifiées -- qui permettent tous à un adversaire d'exécuter du code sur un hôte distant en utilisant uniquement des crédentiels valides et un accès réseau. La détection SMB au niveau NTA se concentre sur le graphe de communication : les connexions SMB pair-à-pair entre postes de travail sans historique de référence d'une telle communication, les connexions vers des partages administratifs (C$, ADMIN$) depuis des hôtes qui n'accèdent normalement pas à ces partages, et les modèles de relais SMB où un hôte reçoit une connexion SMB entrante et initie immédiatement un SMB sortant vers un troisième hôte, caractéristique des attaques de relais NTLM.

Le mouvement latéral via WMI (Windows Management Instrumentation) est plus difficile à détecter uniquement à partir du trafic réseau car la connexion DCOM initiale sur le port 135 est suivie d'un port dynamique négocié qui transporte la charge utile WMI réelle. Les outils NTA doivent corréler la connexion port 135 avec la connexion de port dynamique ultérieure depuis la même source pour reconnaître la session WMI complète et la classifier comme un événement d'exécution WMI distante. L'indicateur comportemental clé est la synchronisation : l'activité WMI légitime des plateformes de gestion se produit selon des horaires prévisibles avec des paires source-destination stables. Les connexions WMI spontanées de postes de travail vers des serveurs à des moments irréguliers, ou les connexions WMI depuis des hôtes sans historique de référence d'initiation de sessions WMI, sont des indicateurs de mouvement latéral de haute confiance que les outils NTA doivent faire remonter sans nécessiter un déchiffrement complet de la charge utile.

Les indicateurs d'abus Kerberos sont visibles dans le trafic d'authentification même lorsque la charge utile de mouvement latéral réelle est chiffrée. Le Kerberoasting -- la technique consistant à demander des tickets de service pour tous les noms principaux de service (SPN) énumérables afin de les craquer hors ligne -- produit une rafale de messages TGS-REQ depuis un seul poste de travail, demandant des tickets pour un grand nombre de SPN dans une courte fenêtre. Ce modèle est statistiquement distinguable de l'activité Kerberos légitime, où un poste de travail demande des tickets pour les services spécifiques dont il a réellement besoin. Les attaques pass-the-ticket et overpass-the-hash produisent des messages Kerberos AS-REQ qui utilisent des types de chiffrement inhabituels ou proviennent d'hôtes sans historique de référence d'authentification auprès du service ciblé. L'établissement d'un référentiel des volumes de requêtes Kerberos par hôte et de la diversité des requêtes SPN fournit la distribution de référence par rapport à laquelle ces modèles d'attaque deviennent statistiquement visibles.

Analyse du trafic chiffré : extraire des indicateurs sans déchiffrement

La proportion du trafic des réseaux militaires qui est chiffré a considérablement augmenté à mesure que TLS 1.3 devient la norme pour les protocoles de la couche application et que les protocoles hérités en clair sont remplacés par des alternatives chiffrées. Cela crée une lacune de détection pour les outils NTA qui reposent sur l'inspection de la charge utile : le contenu d'une session chiffrée est inaccessible sans capacité de déchiffrement. L'analyse du trafic chiffré (ETA) comble cette lacune en extrayant des caractéristiques de métadonnées de la négociation TLS et des caractéristiques comportementales de la session qui restent visibles même lorsque la charge utile est chiffrée. Le message TLS client hello, envoyé en clair avant l'établissement des clés de chiffrement, contient la version TLS, la liste des suites de chiffrement, les extensions prises en charge et -- jusqu'à l'indication du nom de serveur chiffrée de TLS 1.3 -- l'indication du nom de serveur. L'empreinte JA3 réduit ces données de négociation à un hachage compact qui caractérise l'implémentation du client TLS, permettant d'identifier des familles de logiciels malveillants spécifiques ou des cadres C2 par leur comportement de négociation TLS caractéristique sans inspecter aucune charge utile chiffrée.

Au-delà de la négociation, les caractéristiques comportementales des sessions chiffrées portent un signal de classification. Les distributions de longueur de paquets diffèrent entre les sessions humaines interactives (variables, en rafales) et le trafic de balise automatisé (intervalles réguliers, tailles de paquets cohérentes). Le timing d'arrivée inter-paquets des paquets chiffrés révèle le modèle de communication sous-jacent : une balise Cobalt Strike avec un intervalle de veille de 60 secondes produit une distribution d'arrivée inter-paquets reconnaissable même via TLS. Les comptages d'octets de session et la durée des flux séparent les transferts de données en masse des maintiens de canal de contrôle. Les outils NTA qui combinent les empreintes JA3 avec les caractéristiques comportementales des flux peuvent classifier les sessions chiffrées avec une précision comparable à la classification basée sur la charge utile pour les familles de logiciels malveillants connues, tout en détectant également les menaces inconnues dont l'empreinte comportementale s'écarte de tout référentiel établi.

La limitation pratique de l'ETA sur les réseaux militaires est la diversité du trafic chiffré légitime. Une enclave classifiée peut exécuter des dizaines d'applications, chacune avec des caractéristiques d'implémentation TLS distinctes, produisant un référentiel complexe d'empreintes JA3 légitimes et de profils de comportement de session. Maintenir une liste d'autorisation précise des empreintes TLS légitimes nécessite une gestion active à mesure que les applications mettent à jour leurs bibliothèques TLS. L'approche la plus pratique sur le plan opérationnel consiste à établir un référentiel de la distribution des empreintes JA3 par enclave et par plage d'IP de destination, en alertant sur les empreintes qui apparaissent pour la première fois plutôt que de maintenir une liste blanche gérée manuellement. Les nouvelles empreintes sont examinées par rapport à une base de données de référence connue et classées comme légitimes, suspectes ou malveillantes en fonction de leur provenance.

Corrélation des alertes avec le SIEM : réduire le bruit tout en préservant la fidélité de détection

Le mode d'échec le plus courant du déploiement NTA dans les environnements militaires n'est pas une sensibilité de détection insuffisante -- c'est la surcharge d'alertes. Un capteur NTA qui surveille un réseau classifié chargé peut générer des milliers d'alertes d'anomalies à faible confiance par jour, dont la plupart sont des faux positifs provenant de trafic légitime qui s'écarte marginalement du référentiel. Lorsque ces alertes affluent dans un SIEM sans logique de corrélation, les analystes font face à une charge de triage qui dépasse la capacité du personnel disponible, et les alertes de haute confiance qui représentent de vraies menaces sont noyées dans le bruit. La solution n'est pas d'augmenter les seuils de détection -- ce qui réduit la sensibilité et permet aux vraies attaques de passer inaperçues -- mais de construire une logique de corrélation dans le SIEM qui promeut les alertes NTA isolées à faible confiance en incidents de haute confiance uniquement lorsqu'elles sont corroborées par des preuves indépendantes provenant d'autres sources de données.

Les modèles de corrélation les plus efficaces combinent les alertes d'anomalies NTA avec la télémétrie d'authentification, les données de détection des points de terminaison et les journaux DNS. Une seule alerte NTA pour une activité SMB anomale est de faible confiance seule -- il pourrait s'agir d'une application mal configurée ou d'une action administrative ponctuelle. La même alerte NTA corrélée avec un échec d'authentification Kerberos depuis le même hôte source dans les cinq minutes, et un événement de connexion Windows Event ID 4624 sur l'hôte de destination utilisant un compte qui ne se connecte normalement pas à cet hôte, crée une corroboration à trois sources qui porte une haute confiance en tant qu'indicateur de mouvement latéral. Les règles de corrélation SIEM qui définissent ces chaînes de preuves multi-sources pour les techniques d'attaque les plus critiques (mouvement latéral, extraction de crédentiels, mise en scène de données, commandement et contrôle) réduisent considérablement le volume d'alertes tout en préservant la couverture de détection pour les menaces prioritaires les plus élevées.

Point clé : Le volume d'alertes NTA ne doit pas être interprété comme une mesure de la qualité de la détection. Un déploiement NTA qui génère 5 000 alertes par jour et produit 2 incidents confirmés a un taux de faux positifs de 99,96 % et est opérationnellement inutilisable. Le même réseau surveillé avec un modèle de référentiel plus serré et des règles de corrélation SIEM qui exigent une corroboration multi-sources avant de promouvoir une alerte en incident peut générer 50 alertes par jour et produire les mêmes 2 incidents confirmés -- un taux de faux positifs de 96 % qui est toujours élevé mais gérable avec une équipe de deux analystes. L'objectif de réglage n'est pas zéro faux positif ; c'est un taux de faux positifs suffisamment bas pour que chaque alerte reçoive une révision humaine dans la bande passante de dotation en personnel disponible.

La suppression des alertes par le contexte des actifs réduit le bruit sans dégrader la détection. Une alerte NTA pour un modèle de connexion semblable à un scan depuis un hôte étiqueté dans l'inventaire des actifs comme scanner de vulnérabilités est automatiquement supprimée. Une alerte pour un trafic sortant inhabituel depuis un hôte étiqueté comme diode de données est immédiatement promue car les diodes de données ne devraient jamais initier de connexions sortantes. L'intégration du pipeline d'alertes du capteur NTA avec un inventaire des actifs maintenu -- même un simple fichier plat mappant les adresses IP aux rôles des hôtes -- permet à une fraction significative des alertes à faible confiance d'être automatiquement clôturées ou escaladées selon que le comportement observé est plausible pour ce type d'hôte. Sur les réseaux militaires où les rôles des hôtes sont relativement stables par rapport aux environnements d'entreprise dynamiques, la suppression par contexte des actifs peut réduire le volume des faux positifs de 40 à 60 % sans surcharge de configuration au-delà du maintien de la liste des actifs.

Architecture de déploiement : placement des sondes, ports SPAN et évolutivité des capteurs

Une couverture NTA efficace nécessite que le trafic parvienne au capteur sans perte. Les deux méthodes principales pour délivrer le trafic à un capteur NTA sont les sondes optiques passives et les ports SPAN (Switched Port Analyzer). Les sondes optiques passives divisent le signal optique sur une liaison fibre et en délivrent une copie au capteur sans introduire de latence ni créer un point de sonde visible sur le réseau. Elles sont la méthode préférée pour les liaisons à haute valeur car elles ne peuvent pas être désactivées par des modifications de configuration du commutateur et n'affectent pas les performances de liaison sous aucune charge de trafic. Les ports SPAN, configurés sur un commutateur géré, copient le trafic d'un ou plusieurs ports sources ou VLAN vers un port de surveillance désigné. Les ports SPAN sont plus flexibles et moins coûteux que les sondes physiques mais ont des limitations importantes : de nombreuses plateformes de commutateurs abandonnent des paquets sur le port SPAN sous forte charge, et la configuration SPAN est visible dans la configuration du commutateur et peut être inadvertamment modifiée lors de changements réseau de routine.

L'évolutivité des capteurs sur les dorsales militaires à haut débit nécessite du matériel de courtier de paquets entre la sonde et le capteur. Une liaison inter-enclave de 10 Gbps peut transporter 2 à 5 Gbps de trafic réel sous charge de pointe -- bien dans la capacité de traitement d'un seul capteur NTA -- mais une liaison dorsale de 100 Gbps nécessite soit des capteurs distribués, soit un courtier de paquets qui filtre, équilibre la charge et déduplique le trafic avant de le transmettre au niveau des capteurs. Les courtiers de paquets permettent également l'agrégation des sondes : un seul capteur peut recevoir du trafic depuis plusieurs sondes via un courtier qui fusionne les flux et applique des règles de filtrage pour réduire le volume que le capteur doit traiter. Pour les enclaves classifiées où le matériel physique doit répondre à des exigences de sécurité strictes, des appliances de courtier de paquets dédiées validées pour le niveau de classification pertinent sont disponibles auprès d'un petit nombre de fournisseurs spécialisés.

La stratégie de placement des capteurs doit prendre en compte à la fois les exigences de couverture et l'architecture de segmentation du réseau. L'ensemble minimal de sondes viable pour une enclave militaire couvre le périmètre (trafic entrant et sortant de l'enclave), le point de routage inter-VLAN (trafic est-ouest entre les segments de l'enclave) et le segment serveur hébergeant l'infrastructure d'authentification et les serveurs d'applications critiques. Cette architecture à trois points fournit une couverture de toutes les menaces externes et des chemins de mouvement latéral interne les plus conséquents avec un nombre de capteurs opérationnellement gérable. La couverture complète de chaque segment de commutateur d'accès nécessite significativement plus de capteurs et de bande passante mais fournit une visibilité sur le mouvement latéral intra-segment que l'architecture à trois points manque. La décision basée sur le risque sur la profondeur de couverture doit peser la probabilité d'attaques intra-segment par rapport au coût opérationnel d'une infrastructure de capteurs supplémentaire et du volume d'alertes sur l'enclave en question, éclairée par des évaluations des risques de menace interne spécifiques à l'organisation.

Corrélez les anomalies réseau avec le renseignement opérationnel

Corvus SENSE corrèle les anomalies du trafic réseau avec les flux de capteurs et de renseignements, donnant aux équipes de cyberdéfense un contexte exploitable plutôt que des alertes isolées provenant d'outils de surveillance individuels.

Explorer Corvus SENSE → Réserver une séance de présentation

Cette analyse a été préparée par les ingénieurs de Corvus Intelligence qui développent des applications ISR critiques et des applications de terrain pour les organisations de défense et gouvernementales. En savoir plus sur notre équipe →