Teknik - Le CI/CD pour piéger les développeurs
09 juillet 2026
Parce que... c'est l'épisode 0x330!
PME - Retour d'expérience de la seconde cohorte de l'UQTR FORCE
11 juin 2026
Parce que... c'est l'épisode 0x32F!
Actu - 16 août 2026
16 août 2026
Parce que... c'est l'épisode 0x32E!
Teknik - Breaking the Backbone of Global ISP Networks (Troopers)
20 juillet 2026
Parce que... c'est l'épisode 0x32D!
Teknik - Pas besoin d'être un Mythos pour faire de l'offensif (leHACK)
30 juillet 2026
Parce que... c'est l'épisode 0x32C!
H'umain - identroad ou l'application de le souveraineté numérique au Québec (Propolys)
11 juin 2026
Parce que... c'est l'épisode 0x32B!
Actu - 09 août 2026
09 août 2026
Parce que... c'est l'épisode 0x32A!
PME - Impact de l'intelligence artificielle sur la cybersécurité et la fraude
02 juin 2026
Parce que... c'est l'épisode 0x329!
H'umain - Crypto-surprise (leHACK)
24 juillet 2026
Parce que... c'est l'épisode 0x328!
PME - Résilience et fermeture de crise
21 mai 2026
Parce que... c'est l'épisode 0x327!
Actu - 02 août 2026
02 août 2026
Parce que... c'est l'épisode 0x326!
PME - Résilience et préparation du nombril
21 mai 2026
Parce que... c'est l'épisode 0x325!
Teknik - N8ive by design - one leaked key, three attack chains (leHACK)
02 juillet 2026
Parce que... c'est l'épisode 0x324!
Peter Thiel et bro selon Cyber Citoyen et Polysécure
21 juillet 2026
Parce que... c'est l'épisode 0x323!
Actu - 26 juillet 2026
26 juillet 2026
Parce que... c'est l'épisode 0x322!
H'umain - Le futur s'invente avant-hier (nsec)
07 juillet 2026
Parce que... c'est l'épisode 0x321!
Spécial - Le 800e aka l'état de la recherche cybersécurité au Québec
12 août 2026
Parce que... c'est l'épisode 0x320!
PME - Résilience et eau bouillante
21 mai 2026
Parce que... c'est l'épisode 0x31F!
Actu - 19 juillet 2026
19 juillet 2026
Parce que... c'est l'épisode 0x31E!
Teknik - De Nessus à Bromure (SSTIC)
05 juin 2026
Parce que... c'est l'épisode 0x31D!
Teknik - La curiosité source de toutes les croissances en cybersécurité
08 juin 2026
Parce que... c'est l'épisode 0x31C!
Teknik - Posture de l'IA défensif ou comment nous apprenons de l'IA offensif
10 juillet 2026
Parce que... c'est l'épisode 0x31B!
Actu - 12 juillet 2026
12 juillet 2026
Parce que... c'est l'épisode 0x31A!
Teknik - Génération des mots de passe par LLM
03 juin 2026
Parce que... c'est l'épisode 0x319!
Teknik - A Needle in a Haystack - Identifying an Infostealer Attack Through Trillions of Events in a Large-scale Modern SOC
15 mai 2026
Parce que... c'est l'épisode 0x318!
Parce que… c’est l’épisode 0x318!
Shameless plug
- 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
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
Collaborateurs
Crédits
- Montage par Intrasecure inc
- Locaux réels par nsec
Tags: edr, endpoint, ia, nsec
Tweet
