Alerte, dépassement journalier 180Go au lieu de 20Go du firewall
180 Go/jour : autopsie d’un dérapage XDR et remediation
Contexte: Centraliser sans saturer : le défi XDR du groupe
L’entreprise est un groupe industriel international dont le siège se situe à Toulouse. Présente sur plusieurs sites en Europe, elle emploie environ douze mille personnes. Son organisation centralisée mais étendue rend la coordination entre les entités critique, notamment pour tout ce qui touche aux outils de cybersécurité et à la supervision technique.
Initialement, l’entreprise avait déployé une solution EDR sur l’ensemble de son parc, avec une gouvernance bien structurée. Face à l’augmentation des menaces et à la pression réglementaire, la direction a décidé d’étendre progressivement la couverture vers un XDR, afin de centraliser la détection et la corrélation sur l’ensemble des sites européens.
L’intervention débute lorsqu’une alerte signale un dépassement massif de données collectées : près de 180 Go par jour au lieu des 20 Go habituels. Le volume hors norme attire immédiatement l’attention du RSSI, inquiet d’un dysfonctionnement ou d’une erreur de configuration pouvant compromettre la stabilité et les coûts du projet XDR.
Problème: Un seul firewall, 180 Go/jour : le pilote part en vrille
L’analyse révèle qu’un seul site, équipé d’un unique firewall déjà connecté à l’XDR, génère à lui seul l’explosion du volume de logs. Les vingt-neuf autres sites ne sont pas encore intégrés, ce qui rend la situation d’autant plus critique : un pilote censé valider la solution devient la source du dépassement.
L’équipe découvre qu’aucune véritable maîtrise n’existe sur la nature des événements envoyés vers la plateforme XDR. Tous les flux du firewall sont collectés sans filtrage ni hiérarchisation. Les logs techniques, les flux applicatifs et même certains paquets inutiles sont intégrés, provoquant une charge disproportionnée et un bruit opérationnel permanent.
Ce dérapage remet directement en cause la feuille de route triennale du programme XDR. Prévu pour s’étendre à trente sites, le projet voit sa crédibilité entamée dès la phase pilote. Les équipes locales doutent de la pertinence de la solution, et la direction s’interroge sur la viabilité financière du déploiement global.
Parcours :Reprise de contrôle : la méthode en 7 étapes
Vérifier les chiffres : recouper XDR / firewall / collecteurs
La première étape consiste à vérifier les chiffres. Avant toute conclusion hâtive, l’équipe décide de valider les volumes de logs observés. L’objectif : distinguer ce qui relève d’une erreur de lecture, d’un doublon de collecte ou d’un véritable excès. Cette approche factuelle permet d’éviter les interprétations biaisées et de restaurer la confiance du RSSI. Les données sont croisées entre le XDR, le firewall et les collecteurs intermédiaires pour confirmer que la hausse provient bien d’un envoi massif de journaux réseau non filtrés.
Cartographier les flux : documentation réseau à jour
L’objectif est désormais de reprendre la maîtrise complète du périmètre. Notre équipe rassemble toute la documentation disponible : schémas réseau, listes de flux et procédures de collecte. L’architecture initiale s’avère peu formalisée, issue d’initiatives locales rarement documentées. Nous complétons alors les éléments manquants et mettons à jour la description des flux entre les firewalls et les outils de supervision. Cette remise à plat offre enfin une vision claire et partagée, indispensable avant toute action technique.
Aligner avec les risques : définir les événements utiles
Pour aller plus loin, notre équipe s’appuie sur l’analyse de risques organisationnelle existante afin d’identifier les événements redoutés réellement nécessaires. L’objectif est d’éviter la collecte massive sans finalité claire. En confrontant les scénarios de risques aux sources de logs disponibles, nous déterminons les événements à conserver et ceux à exclure. Cette approche rationnelle redonne du sens à la supervision : seuls les flux utiles à la détection ou à la conformité sont maintenus, réduisant ainsi le bruit et le volume quotidien transmis vers le XDR.
Intercaler FluentD : filtrer, normaliser, tracer
Une fois les périmètres clarifiés, nous déployons FluentD pour reprendre le contrôle de la collecte. L’outil est installé sous forme de conteneurs, configuré pour agréger, filtrer et normaliser les flux issus des firewalls avant leur envoi vers le XDR. Cette étape marque un tournant : elle réintroduit une couche d’intelligence entre la source et la plateforme. FluentD permet de limiter la charge, tracer les erreurs et vérifier la cohérence du format. Les premiers tests montrent déjà une réduction importante des volumes journaliers, sans perte de visibilité sur les événements critiques.
Connecter progressivement : tester site par site
Une fois FluentD opérationnel, nous entamons la connexion progressive des flux depuis les firewalls. Le travail est minutieux : chaque lien doit être testé, documenté et validé pour garantir la stabilité. Les configurations varient selon les sites, imposant des ajustements manuels et plusieurs itérations. Les équipes passent en revue les formats de messages, les niveaux de verbosité et les délais de transmission. Rien n’est automatique à ce stade : chaque flux intégré est un petit succès en soi. Au fil des jours, la chaîne complète du firewall à FluentD puis au XDR prend forme de manière contrôlée et robuste.
Écrire les parsers : rendre les logs exploitables
Une fois les flux stabilisés, nous créons les parsers nécessaires à l’exploitation des données. Chaque type de message issu des firewalls doit être interprété correctement pour être exploitable dans le XDR. Ce travail patient consiste à décoder les champs, corriger les formats et enrichir les métadonnées utiles à la détection. L’objectif est de garantir une lecture uniforme, quel que soit le site d’origine. Ces parsers deviennent un actif stratégique : ils traduisent la complexité technique en signaux clairs, directement exploitables par les analystes pour la supervision et la détection d’incidents.
Valider par scénarios : éliminer le faux positif, garder le signal
La dernière étape consiste à tester l’ensemble du dispositif. Nous générons volontairement plusieurs scénarios d’alertes de sécurité afin de vérifier la chaîne complète, depuis la détection sur le firewall jusqu’à la réception dans le XDR. Ces tests mettent en évidence la cohérence du paramétrage et la qualité du parsing. Ils permettent aussi d’ajuster les seuils et les filtres pour éliminer les faux positifs. Ce travail de validation est essentiel : il démontre que la supervision n’est pas seulement fonctionnelle, mais réellement opérationnelle, capable de détecter les événements critiques sans saturer la plateforme.
Recommandations: Trois règles d’or pour un XDR soutenable
Avant toute intégration, il est indispensable d’analyser les flux à collecter. Injecter directement l’ensemble des événements dans un XDR conduit inévitablement à des volumes ingérables et à une supervision inefficace. Chaque source doit être évaluée selon sa valeur ajoutée en détection et en conformité. Cette discipline évite le bruit, préserve la performance et assure une exploitation réellement utile des capacités analytiques du XDR.
Mettre en place une instance intermédiaire dédiée à la régulation des flux est essentiel pour éviter les débordements. Cette couche technique agit comme un tampon entre les firewalls et le XDR. Elle filtre, normalise et hiérarchise les événements avant leur envoi. Hébergée sous forme de conteneurs FluentD, elle reste simple à maintenir et à adapter. Sa mise en place demande du temps et de la rigueur, mais elle constitue un point de passage indispensable pour garantir la stabilité et la cohérence du dispositif.
Les parsers développés constituent une véritable valeur technologique. Ils traduisent la connaissance du terrain en logique exploitable pour la détection. Les confier à des prestataires externes ferait perdre cette maîtrise fine des formats et des comportements. Les conserver en interne garantit la cohérence, la sécurité et la capacité d’évolution du dispositif. Leur maintenance devient un savoir-faire clé, au même titre que l’administration du XDR lui-même.
Conclusion
La cybersécurité vit une transformation profonde : tout devient service, tout s’achète à la consommation. Le modèle SaaS simplifie, mais pousse à la démesure. Derrière chaque Go stocké ou transmis, il y a un coût bien réel. Garder de vieux réflexes d’optimisation, hérités du monde on-premise, redevient une force. Mesurer, filtrer, prioriser : ces gestes simples rappellent qu’une architecture sobre reste le meilleur moyen de maîtriser ses budgets sans sacrifier la sécurité.
Ressources CyberLead
Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités :
PROMPTS IA CYBERLEAD
Je vous partage mon paramétrage que vous pouvez réutiliser pour passer votre IA en mode Expert Cyber :
1 -> Aller dans Personnalisation
2 -> Activer « Activer les instructions personnalisées ».
3 -> Copier-coller le prompt ci-dessous :
“Tu es un expert cybersécurité qui vérifie systématiquement les faits, remet en question les évidences et croise les sources, en t’appuyant avant tout sur les standards et référentiels reconnus (ANSSI, NIST, ISO, IEC). “
Je partage aussi en mode Beta Test la liste des 12 prompts que j’utilise le plus.
CVTHEQUE CYBERLEAD
Pour être efficace en cybersécurité il faut surtout les bonnes personnes au bon endroit. C’est pour cela que je lance la CVthèque Cyberlead dédiée à la cybersécurité. Celle-ci a pour but de connecter les candidats et les recruteurs au moyen de fiches standardisées, de tags de compétences, de niveaux d’expérience, de la localisation et de la disponibilité.
A la recherche d’une nouvelle opportunité ?
REX CYBERLEAD
Il y a quelques temps j’ai accompagné une structure dans le cadre d’attaque d’une ligne de métro. Aujourd’hui j’ai décidé de partager avec vous les leçons apprises pendant un atelier REX anonymisé “Décontamination d’une ligne de métro”.
Ce REX est exclusivement réalisé sur site.