Parce que… c’est l’épisode 0x318!
Shameless plug
19 septembre 2026 - Bsides Montréal
20 au 26 septembre 2026 - BruCON
13 novembre 2026 - DEATHCon
16 au 19 novembre - European Cyber Week
1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
24 et 25 février 2027 - SéQCure 2027
Description
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 progressivement, un peu comme les modèles de langage qui s’effondrent lorsqu’ils apprennent sur leurs propres données. Pour éviter ce piège, l’équipe conserve un échantillon de 5 à 10 % des données sur lequel le modèle n’agit jamais automatiquement — ces alertes sont envoyées aux analystes pour un triage normal, ce qui permet de mesurer en continu la performance réelle du modèle (faux négatifs, dérive) et de générer des données d’entraînement non biaisées pour les futurs modèles.
Étude de cas : détection d’un info stealer
Pour illustrer concrètement le pipeline, François présente un cas réel portant sur deux semaines de données : à partir de 9,7 billions d’événements, le filtrage complet aboutit à seulement 81 000 alertes, soit environ 50 par client. Pour le client étudié, seulement sept alertes émergent — deux de haute sévérité liées à un vol de mot de passe, et cinq autres jugées bénignes (vol d’identifiants légitime confirmé par le client).
Grâce au modèle de priorisation, les deux alertes à forte probabilité de menace sont sélectionnées, puis l’analyste ramène toutes les alertes liées au même utilisateur et à la même machine, incluant trois alertes de sévérité plus basse. L’ensemble reconstitue une chronologie claire : un exécutable déguisé en éditeur PDF s’exécute, établit une connexion réseau anormale vers un serveur de commande, puis déclenche des détections successives de vol de mots de passe et de données de navigateur — signature typique d’un info stealer. Isolément, chaque alerte de type « info stealer » génère énormément de faux positifs ; c’est la combinaison de plusieurs signaux corrélés dans le temps, pour la même entité, qui permet à l’analyste de conclure avec confiance à une véritable compromission et de recommander la réimagerie de la machine du client.
L’épisode se conclut sur l’idée que ce type de pipeline permet non seulement de filtrer efficacement le bruit à très grande échelle, mais aussi de reconstruire, a posteriori, une histoire cohérente de l’attaque à partir des données brutes.
Notes
A Needle in a Haystack - Identifying an Infostealer Attack Through Trillions of Events in a Large-scale Modern SOC
Collaborateurs
Nicolas-Loïc Fortin
François Labrèche
Crédits
Montage par Intrasecure inc
Locaux réels par nsec
Canada - english