AccueilIA et apprentissage automatiqueDétecteur d'Intrusion Réseau — Score d'Anomalie en Direct

🚨 Détecteur d'Intrusion Réseau — Score d'Anomalie en Direct

Un flux de trafic réseau simulé passe devant un modèle de détection d'anomalies qui note chaque connexion selon son risque d'intrusion, signalant les scans de ports et les schémas d'exfiltration de données à mesure qu'ils apparaissent.

IA et apprentissage automatique3DAvancé60 FPS
ai-cybersecurity-intrusion-detection ↗ Ouvrir en autonome

À propos du Détecteur d'Intrusion Réseau

Les systèmes modernes de détection d'intrusion réseau se répartissent en deux grandes familles. Les systèmes à signatures (Snort, Suricata, la plupart des pare-feux commerciaux) comparent le trafic à un catalogue de schémas connus comme malveillants et ne peuvent détecter que ce qui a déjà été observé et inscrit dans une règle. Les systèmes basés sur les anomalies construisent au contraire un modèle statistique de ce à quoi ressemble un trafic « normal » pour un réseau — débits de paquets typiques, durées de connexion, ports touchés — et signalent tout ce qui s'en écarte fortement, ce qui leur permet de détecter des schémas d'attaque véritablement inédits au prix d'un taux de faux positifs plus élevé. Cette simulation met en œuvre directement l'approche par anomalie : un flux en direct de connexions synthétiques, chacune décrite par quatre caractéristiques de flux (paquets/s, octets/paquet, durée de connexion, et ports de destination distincts touchés), est noté par rapport à une distribution de référence elle-même réestimée à la volée à partir du trafic récent non signalé.

Le score d'anomalie de chaque connexion est la norme euclidienne de ses quatre scores z par rapport à cette référence en direct — une forme simplifiée, à covariance diagonale, de la distance de Mahalanobis. Un curseur de sensibilité fixe le seuil de score au-delà duquel une connexion est signalée ; une fois signalée, la simulation examine quelles caractéristiques pilotent l'anomalie pour distinguer un scan de ports (de nombreux ports distincts, durée très courte) d'une exfiltration de données (octets par paquet importants se déplaçant régulièrement à travers très peu de ports sur une longue session). Comme chaque connexion synthétique porte secrètement une étiquette de vérité terrain, la simulation peut calculer en direct la précision, le rappel et la matrice de confusion complète à mesure que vous déplacez le seuil — rendant directement visible et ajustable le compromis de fatigue des alertes au cœur de tout centre d'opérations de sécurité réel.

Questions fréquentes

Qu'est-ce que la détection d'intrusion basée sur les anomalies, et en quoi diffère-t-elle d'un IDS à signatures ?

Les systèmes à signatures comme Snort ou Suricata comparent le trafic à une base de données de schémas d'attaque connus — une séquence d'octets spécifique, une IP connue comme malveillante, une forme de paquet particulière — et ne peuvent détecter que des attaques déjà observées et cataloguées. La détection par anomalie construit à la place un profil statistique de ce à quoi ressemble le trafic « normal » pour un réseau donné — débits de paquets typiques, durées de connexion, ports touchés — et signale tout ce qui s'écarte fortement de ce profil, que l'attaque exacte ait déjà été vue ou non. Cela permet aux détecteurs d'anomalies de repérer des schémas d'attaque inédits ou de type zero-day, au prix d'un taux de faux positifs plus élevé, puisqu'un comportement inhabituel mais légitime (une tâche de sauvegarde, un nouveau service) peut aussi déclencher une alerte. Les déploiements réels combinent généralement les deux approches.

Quelles caractéristiques cette simulation utilise-t-elle pour décrire une connexion, et pourquoi ces quatre-là ?

Chaque connexion simulée est décrite par quatre caractéristiques : paquets par seconde (pps), octets par paquet (bpp), durée de connexion en secondes, et le nombre de ports de destination distincts touchés pendant la session. Ces quatre caractéristiques ont été choisies parce qu'elles séparent nettement les deux familles d'attaques modélisées ici sans nécessiter d'inspection profonde des paquets : un scan de ports se traduit par de nombreux ports distincts touchés en très peu de temps avec de petits paquets (bpp faible, pps élevé), tandis que l'exfiltration de données se traduit par une session de longue durée déplaçant des octets par paquet anormalement élevés à travers très peu de ports. Les vrais systèmes de détection d'intrusion réseau utilisent des dizaines voire des centaines de telles caractéristiques de flux (variance du temps entre arrivées, ratios de drapeaux TCP, entropie des octets), mais quatre suffisent à rendre pleinement visibles les statistiques sous-jacentes — et le compromis faux positifs/faux négatifs qui en résulte.

Comment le score d'anomalie est-il réellement calculé ?

Chacune des quatre caractéristiques est convertie en score z : zᵢ = (xᵢ − moyenneᵢ) / écart-typeᵢ, en utilisant une moyenne et un écart-type estimés en direct à partir d'une fenêtre glissante des connexions les plus récentes qui ne sont pas actuellement signalées comme anormales. Le score d'anomalie est alors la norme euclidienne du vecteur de scores z, score = √(z₁² + z₂² + z₃² + z₄²) — équivalent à une distance de Mahalanobis sous l'hypothèse simplificatrice que les quatre caractéristiques ne sont pas corrélées (une matrice de covariance diagonale), plutôt que la matrice de covariance complète qu'un système de production estimerait. Une connexion est signalée dès que son score dépasse le seuil de sensibilité fixé par le curseur.

Comment la simulation distingue-t-elle un scan de ports d'une exfiltration de données une fois qu'une connexion est signalée ?

Une fois le score au-dessus du seuil, la simulation examine quels scores z individuels pilotent l'anomalie. Si le score z des ports distincts est fortement positif tandis que le score z de durée est fortement négatif, la signature correspond à de nombreux ports touchés en très peu de temps — classé comme scan de ports. Si les scores z des octets par paquet et de la durée sont tous deux fortement positifs tandis que les ports distincts restent bas, la signature correspond à un transfert de données important, soutenu et étroit — classé comme exfiltration. Tout ce qui est signalé sans correspondre clairement à l'une ou l'autre signature est étiqueté comme anomalie générique. Cela reflète la façon dont les analystes SOC réels trient une alerte : le score d'anomalie brut indique que quelque chose est inhabituel, mais la décomposition par caractéristique indique quel genre d'anomalie il s'agit.

Comment le curseur de seuil de sensibilité affecte-t-il les faux positifs et les faux négatifs ?

Abaisser le seuil signale davantage de connexions : le rappel augmente (moins de véritables intrusions passent inaperçues en tant que faux négatifs) mais la précision diminue (davantage de trafic ordinaire est signalé à tort comme faux positif, un effet que les analystes appellent la fatigue des alertes). Relever le seuil fait l'inverse — moins d'alertes, une précision plus élevée, mais un risque croissant que de véritables scans ou sessions d'exfiltration passent inaperçus. Il n'existe pas de réglage universellement correct : le SOC d'une banque pourrait tolérer un taux de faux positifs plus élevé pour intercepter davantage de menaces réelles, tandis qu'un service avec une petite équipe de sécurité pourrait relever le seuil simplement parce qu'il ne peut pas trier un déluge d'alertes.

Pourquoi le modèle recalcule-t-il ses statistiques de référence à partir d'une fenêtre glissante en direct plutôt que d'un ensemble d'entraînement fixe ?

Le vrai trafic réseau dérive constamment — une nouvelle application est déployée, un calendrier de sauvegarde change, le télétravail modifie le profil horaire du trafic — un phénomène appelé dérive conceptuelle. Un détecteur entraîné une seule fois sur le trafic du mois dernier et jamais mis à jour se décalibrera lentement : soit en signalant de plus en plus de comportements normaux mais nouveaux comme faux positifs, soit (pire) en traitant une attaque lente et délibérée comme la nouvelle normalité parce qu'elle s'est infiltrée progressivement. Recalculer la moyenne et l'écart-type à partir d'une fenêtre glissante de connexions récemment non signalées permet à la référence de suivre la dérive légitime tout en résistant aux attaques qui arrivent en rafale soudaine, au prix d'une vulnérabilité face aux attaquants qui montent délibérément en puissance assez lentement pour être absorbés dans la référence — une limitation bien connue parfois appelée empoisonnement de la grenouille bouillie.

Quelles sont les limites de cette approche à covariance diagonale par rapport à un système de détection d'intrusion en production ?

Traiter les quatre caractéristiques comme non corrélées (en additionnant des scores z indépendants) ignore les corrélations réelles — par exemple, un débit de paquets élevé et de faibles octets par paquet ont tendance à coexister naturellement dans les requêtes courtes normales, si bien qu'une matrice de covariance complète tracerait une région normale elliptique et inclinée au lieu de la région alignée sur les axes de cette simulation, et signalerait moins de ces points naturellement corrélés comme anormaux. Les systèmes de production vont encore plus loin : les forêts d'isolement, les auto-encodeurs et d'autres modèles d'apprentissage automatique capturent une structure non linéaire et d'ordre supérieur à travers des dizaines de caractéristiques, et sont généralement combinés à des règles de signature, des flux de renseignement sur les menaces, et une revue humaine par des analystes plutôt que de reposer sur un unique score statistique isolé.

Pourquoi les faux négatifs et les faux positifs coûtent-ils si différemment dans un vrai SOC ?

Un faux négatif — une intrusion manquée — peut signifier que des données quittent réellement le réseau ou qu'un point d'ancrage passe inaperçu, avec des coûts mesurés en remédiation de brèche, exposition réglementaire et atteinte à la réputation. Un faux positif coûte du temps d'analyste : quelqu'un doit ouvrir l'alerte, extraire les journaux, et conclure qu'elle était bénigne. Comme le temps des analystes est limité et que chaque SOC réel reçoit bien plus d'alertes qu'il ne peut en investiguer entièrement, un détecteur réglé uniquement pour le rappel (tout intercepter) peut se retourner contre lui-même s'il enterre de vraies alertes sous un déluge de fausses — ce qui explique exactement pourquoi le compromis précision/rappel exposé par le curseur de seuil de cette simulation est la décision opérationnelle centrale dans la détection d'intrusion réelle, et non une simple curiosité statistique.

⚙ Sous le capot

Des connexions simulées défilent devant un détecteur d'anomalies en direct : la moyenne et l'écart-type de quatre caractéristiques de flux sont réestimés à partir d'une fenêtre glissante de trafic récemment non signalé, chaque nouvelle connexion est notée par la norme euclidienne de ses scores z, et les connexions signalées sont classées comme scan de ports, exfiltration ou anomalie générique selon les caractéristiques qui pilotent le score.

Canvas 2DDétection d'anomaliesDétection de scan de portsExfiltration de donnéesPrécision/Rappel

3D · Moteur de rendu Three.js / WebGL · Cible 60 FPS · fonctionne entièrement côté client, sans installation

Qu'avez-vous constaté ?

Ajouter des étapes de reproduction (facultatif)