La newsletter reprend son rythme normal après les vacances d’Août et surtout un événement personnel heureux, avec des sujets d’article que j’ai hâte de partager.
Mais avant ça, j’ai été intrigué comme vous par cette news. Je ne vais pas refaire le procès de la DGFiP (bien que j’en serai tenté, je le conviens). Ce qui m’intéresse, c’est le mécanisme derrière et les enseignements pour un décideur cyber.
Juin 2026. Un mec se connecte au SI de la DGFiP avec des identifiants qui ne lui appartiennent pas. Une alerte sonne. Le compte est repéré. Accès coupé.
Juillet 2026. Ça recommence. Un autre compte, avec des privilèges cette fois. Accès frauduleux. On détecte et on bloque.
Sur le papier, ça ressemble à un SOC qui fait son travail, non?
Pourtant, le 14 Août, la DGFiP nous apprend qu’elle vient de perdre dans la nature les données fiscales et cadastrales de 678 000 contribuables. Grâce à une alerte de l’ANSSI et surtout à la revendication du hacker en question.
Il a a exfiltré les données en restant sous les radars sur plusieurs semaines. Ca s’est fait petit à petit, sans dépasser les seuils de détection définis par la DGFiP.
Ce type de loupés, je l’ai déjà vu plus d’une fois.
On ferme le ticket. Et puis s’en va.
Un compte compromis, détecté puis bloqué : dans la plupart des SOC, ça se traduit par un ticket qualifié “vrai positif”, une action de containment, et une clôture avec le sentiment du devoir accompli.
Mais. Car il y a toujours un “mais” : Combien de temps est-il resté actif avant l’alerte ? Qu’est-ce qui a été consulté pendant cette fenêtre ? Est-ce que l’attaquant a rebondi ailleurs avant d’être coupé ?
Bloquer l’accès frauduleux répond à une urgence. Ça ne répond à aucune de ces questions. Et c’est précisément là que ça a dû coincer pour la DGFiP : la fenêtre de compromission a été traitée comme un incident ponctuel à refermer, pas comme une période à investiguer dans son intégralité.
Je l’ai vu régulièrement chez les SOC chez qui j’ai travaillé. Un SOC mesure son efficacité sur le temps de prise en compte, le temps de qualification, le taux de clôture. Rarement sur la profondeur de l’investigation une fois le blocage fait. Parce que ça ne rentre dans aucun tableau de bord standard, et que ça prend du temps. Temps qu’un MSSP ne sait facturer, qu’un responsable SOC ne sait pas quantifier et qu’un analyste ne sait pas valoriser.
J’ai un très bon exemple chez un SOC Grand groupe chez qui j’ai travaillé : Un analyste passait du temps à approfondir des tickets qui le nécessitaient mais qui traitait moins le backlog que les autres analystes de l’équipe (Clément, si tu me lis). A la fin du mois, il se fait tout de même incendier par son SOC manager car il semble en faire moins que ses collègues.
Le SOC n’est pas un helpdesk qui fait du ticketing
Le problème de fond, c’est la façon dont on pense le rôle du SOC. Beaucoup de directions, techniques ou pas, le voient comme un service qui traite les tickets et alertes relatifs à la cyber.
Le SOC est un enquêteur. Une enquête qui s’arrête au blocage du symptôme, sans remonter à ce qui a été fait pendant que le symptôme était actif, n’en est pas une.
C’est le même réflexe qu’un médecin qui traite la fièvre sans chercher l’infection. La fièvre baisse, le patient se sent mieux, tout le monde rentre chez soi. Trois semaines plus tard, l’infection a fait son chemin ailleurs.
La DGFiP a des moyens
Nos impôts, tiens. Et elle a quand même raté cette étape.
Alors pour un RSSI ou DSI d’une ETI, qui pilote un SOC externalisé, avec peu de budget, sans équipe technique en interne pour challenger le prestataire, la tentation de juger sur ce qu’il voit (les SLAs, le nombre d’alertes) est plus forte.
Ces indicateurs qu’on vous reporte disent que le SOC travaille. Ils ne disent rien sur la profondeur du travail une fois l’alerte confirmée.
Une question à poser à votre responsable SOC ou partenaire SOC :
“Sur une identité ou une machine compromise, quel est votre processus pour reconstituer l’activité de l’attaquant pendant la fenêtre de compromission ?” En pratique, pas la théorie. Avec le mode opérationnel, les outils et le temps analyste réellement alloués à cette étape.
Si la réponse s’arrête à “on reset le mot de passe / on isole et remasterise la machine et on ferme le ticket”, vous avez votre réponse : C’est un modèle de gouvernance SOC qui n’a pas prévu d’allouer de l’effort sur cette étape.
C’est ça, pour moi, le vrai enseignement de cette affaire d’un point de vue SOC. Un SOC qui détecte bien peut quand même laisser passer l’essentiel, si personne ne lui demande d’aller jusqu’au bout de l’histoire.
Mehdi Charki est SOC Manager avec 10 ans d’expérience. SOC Performance est sa newsletter indépendante sur la gouvernance, la stratégie et le pilotage SOC.