Teknik - A Needle in a Haystack - Identifying an Infostealer Attack Through Trillions of Events in a Large-scale Modern SOC - Parce que... c'est l'épisode 0x318!

• 6 au 9 août 2026 - Las Vegas, USA - - DEFCON 34
• 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026
• 22 septembre 2026 - Belgique - - BE-Cyber
• 24 au 25 septembre 2026 - Belgique - - BruCON
• 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon
• 13 et 14 novembre 2026 - Worldwide - - DEATHCon
• 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026
• 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada

Contexte

Dans cet épisode spécial, l’animateur reçoit François Labrèche, scientifique de données, pour discuter de la façon dont son entreprise traite l’immense volume de signaux de sécurité générés par son SOC à grande échelle (managed XDR). Contrairement à un SOC traditionnel, François travaille en back-end et a accès aux données de tous les clients, ce qui lui permet de construire des modèles et des filtres globaux applicables à l’ensemble des alertes. L’objectif de l’épisode est double : expliquer le pipeline de filtrage des données, puis illustrer son fonctionnement à l’aide d’un cas réel.

Le pipeline de filtrage

Étape 1 — Les détecteurs

Le point de départ, ce sont des billions d’événements bruts. La première étape repose sur des règles de détection simples et peu coûteuses en calcul : correspondances avec des IOC (indicateurs de compromission), domaines ou IP malveillants, ainsi que des règles de corrélation basiques détectant des anomalies (par exemple, un utilisateur qui se connecte pour la première fois à une machine de développement). Ces règles ne prouvent rien de malveillant en soi, mais elles servent à isoler tout ce qui sort de l’ordinaire pour l’envoyer plus loin dans le pipeline. Après cette étape, il ne reste que 0,03 % des données initiales — un filtre énorme, mais qui représente encore 2,6 milliards d’événements sur deux semaines, un volume toujours impossible à traiter manuellement.

Étape 2 — Déduplication et corrélation

La deuxième étape combine deux mécanismes. La déduplication regroupe les alertes générées en grand nombre par une même attaque (comme un déni de service ou un scan) visant la même cible, réduisant ainsi des dizaines de milliers d’alertes en une seule. La corrélation, elle, relie des alertes distinctes provenant de détecteurs différents mais concernant la même activité (par exemple, plusieurs signaux liés à un même utilisateur et une même machine). Pour rendre ce travail possible, une équipe dédiée normalise en amont tous les signaux — qu’ils proviennent des senseurs propriétaires ou de fournisseurs tiers — dans un format standardisé, en capturant les éléments clés (nom de l’alerte, entités impliquées, IP, nom d’hôte, etc.). La corrélation s’appuie sur une fenêtre d’analyse fixe (environ un mois) et sur des bases de données de comptage historique, sans recours au machine learning à ce stade.

Étape 3 — La suppression

Cette étape cible des cas précis, propres à un client ou une situation donnée. Certaines alertes sont bénignes uniquement dans un contexte particulier : par exemple, un client qui effectue des scans de vulnérabilité hebdomadaires de façon planifiée, ou du trafic DNS provenant de Cloudflare, connu comme légitime. Ces règles de suppression sont paramétrées en collaboration avec le client ou l’ingénieur qui le supporte, et nécessitent une connaissance fine de son environnement. Des règles similaires sont aussi créées lorsque les équipes de recherche de menaces identifient des indicateurs malveillants publiés par erreur, afin de bloquer ces faux indicateurs pour l’ensemble des clients.

Étape 4 — La priorisation

C’est ici qu’intervient le machine learning. Les alertes sont divisées en deux groupes selon leur sévérité : haute et moyenne/basse. Un modèle supervisé, entraîné chaque semaine sur des données historiques (les décisions passées des analystes), est appliqué aux alertes de sévérité élevée pour prédire une probabilité de menace réelle. Ce modèle sert à deux fins : fermer automatiquement les alertes jugées très peu probables (réduisant le bruit pour les analystes), ou ajuster la sévérité des alertes jugées menaçantes. Les alertes de sévérité plus basse ne sont pas ignorées : elles sont réutilisées pour enrichir le contexte autour d’une menace identifiée par le modèle, en allant chercher toutes les alertes liées au même utilisateur et à la même machine durant la même période.

Un point important soulevé dans la discussion concerne la dégradation des modèles : si un modèle supervisé était réentraîné sur ses propres prédictions (sans validation humaine), il se dégraderait progres