Un cambrioleur cagoulé entre dans une banque. Il ouvre le coffre-fort et repart. Le lendemain, le directeur rassure tout le monde : "On a changé toutes les serrures. Problème réglé." Vous lui diriez sûrement : "OK, mais il a volé quoi ?"

Nouvelle alerte : Compte user compromis sur le SI principal du client. L’analyste du prestataire fait son boulot, envoie ses conclusions au client et ferme le ticket.

Dans les délais. Rien à redire sur le papier.
Sauf que dix jour plus tôt, il y a eu une crise cyber et une dizaine de comptes compromis sur un autre SI (industriel). Identités non monitorées par le SOC.

C’était le même attaquant. L’analyste n’a pas fait le lien avec la compromission d’il y a dix jours. Celle qui touchait un périmètre que le SOC ne supervisait même pas.

Je ne lui jette pas la pierre. Il avait un SLA qui tournait, le délai de traitement prévu au contrat. Le genre de chrono qui ne laisse pas vraiment le temps de remonter le fil et prendre le temps de bien faire les choses.

Et je le vois souvent. Pressé par les délais, l’analyste accélère et balance au client une conclusion un peu rapide. Des fois, il se dit qu’il complétera le ticket plus tard. Ce « plus tard » n’arrive jamais : le ticket urgent suivant est déjà là, et le précédent finit noyé dans la masse.

J’appelle ça la dette d’investigation

Tout ce qu’un SOC choisit de ne pas creuser, faute de temps, de moyens ou de compétences.

Un analyste, même expérimenté, qui a deux incidents dans sa journée prend le temps de bien faire les choses. Quand il en a vingt, il fait au plus efficace.

Accès non autorisé ? Je reset le password, le MFA et je révoque la session. Fin.

Le fisc vient d’en faire les frais. Dans son rapport sur les attaques de cet été contre la DGFiP, l’ANSSI recense près d’une trentaine de comptes compromis par des infostealers (des logiciels espions qui aspirent les mots de passe enregistrés sur un PC).

Une phrase m’a frappé dans le rapport : l’analyse systématique des activités « est très chronophage et ne peut être assurée de manière exhaustive ».

Fin juin, un partenaire signale un compte compromis. La DGFiP répond le jour même : on est au courant, le compte est réinitialisé. Petit problème, ce compte avait servi à exfiltrer des données cinq jours plus tôt. Et les analyses du SOC ne l’avaient pas vu passer.

Cerise sur le gâteau : le SOC ne supervisait pas le portail ADER, celui par lequel l’attaquant sortait les données.

Un périmètre pas supervisé, des resets à la chaîne, personne pour faire le lien. Ça ne vous rappelle rien ? C’est mon anecdote. Mêmes faits. Pure coïncidence par contre, je n’ai jamais mis les pieds à Bercy !

Mais je ne vais pas leur taper dessus. Cette réalité, on la retrouve à des degrés différents dans quasiment tous les SOC. Je le sais, vous le savez.

Pourquoi votre MSSP ne vous en parlera pas

Côté client, ce que vous voyez, ce sont des tickets fermés dans les temps et un dashboard tout vert. Un reset de mot de passe, ça se boucle vite. Personne ne viendra vous dire que l’investigation s’est arrêtée là.

Et je comprends le prestataire. Écrire dans un reporting « celui-là, on l’a traité à moitié », c’est donner au client le bâton pour se faire battre.

Tant que le contrat récompense la vitesse et sanctionne l’aveu, on n’ira pas bien loin.

Une dette avec une date de péremption

Sous mon post LinkedIn de la semaine dernière, Samir Cherbani (Head of SecOps et CTI chez HPS, au Maroc) a mis le doigt sur ce qui me manquait. Cette dette expire. Et c’est justement ce qui la rend plus dangereuse que la dette technique.

Les logs, vos journaux d’événements, ne sont gardés qu’un temps. Chez les boites que je croise, c’est entre 3 et 6 mois. Une fois ce délai passé, vous ne saurez jamais ce que l’attaquant a fait pendant qu’il avait la main. Même en y mettant tout le budget du monde.

Samir rappelle aussi qu’un reset ne fait pas tout le ménage. Exemple : règles de transfert créées dans la boîte mail, applis tierces (OAuth) que l’attaquant a autorisées, cookies de session toujours présent, infostealer encore déployé.

La DGFiP l’a appris à ses dépens. D’après l’ANSSI, le reset du 24 juin n’a coupé ni la session de l’attaquant ni l’exfiltration en cours. Qui a continué comme si de rien n’était.

« C’est un symptôme »

Aurélien Cuvelier, incident responder senior chez Mastercard, n’était pas tout à fait d’accord. Pour lui, la dette d’investigation est d’abord un symptôme. Si l’analyste manque de temps, il faut traiter la cause : affiner les règles quand il y a trop d’alertes, enrichir et automatiser une partie du tri quand elles sont trop longues à analyser, et renforcer l’équipe quand la charge est trop élevée, tout simplement.

Ce qu’il décrit est juste. C’est l’état de l’art du SOC, disons.

Dans la vraie vie, on n’y est pas toujours, et pas sur toutes les règles en même temps. Une règle fine-tunée depuis cinq ans et une règle toute neuve sur un nouveau scope, ça ne fait pas le même bruit. Et une crise, ça ne prévient pas.

C’est comme la ceinture et l’airbag. Ce n’est pas parce que tout le monde conduit bien que tu t’en passes. Il y a toujours des imprévus, même avec les meilleurs analystes et outils du marché.

Ma proposition

Un tag « Clôturé en mode dégradé » dans l’outil de ticketing du prestataire. L’analyste le coche quand il ferme un incident confirmé sans avoir investigué toute la période d’exposition.

Dit comme ça, ça paraît simple. Mais sans quelques règles autour, ce tag ne servira à rien.

Règle 1 : cocher la case ne coûte aucune pénalité. Ça s’écrit dans le contrat. Sinon personne ne la cochera, et vous aurez un joli 0 % qui ne veut rien dire.

Règle 2 : chaque ticket tagué a une échéance, fixée selon sa priorité. Quand la charge retombe, un analyste reprend ces tickets à froid, en commençant par ceux dont les logs vont expirer en premier. L’idée, c’est de rembourser la dette avant que les preuves disparaissent.

Règle 3 : le taux de dégradé passe en comité de pilotage, tous les mois. Au-delà de 25 % des incidents confirmés, je commencerais à m’inquiéter. À ce niveau-là, on a dépassé le simple coup de bourre : le problème est structurel. Et c’est là que les leviers d’Aurélien entrent en jeu (tuning des règles, automatisation, renfort).

Petit bonus pour vérifier que le tag est honnête : tirez trois tickets au hasard chaque mois et demandez au prestataire la chronologie complète de ce qu’a fait l’attaquant. Vous verrez vite si son 0 % tient la route.

Mon avis

Il faut adapter nos indicateurs à la réalité du terrain. Accepter que la charge de travail dégrade la qualité des investigations. Et tracer ça pour pouvoir s’améliorer.

Un SOC qui m’affiche 0 % de dégradé, ça ne me rassure pas du tout. Soit il est surdimensionné, soit il cache sa dette. Et des SOC surdimensionnés, je n’en ai jamais croisé.

Alors, si vous demandiez ce taux à votre SOC demain matin, il vous répondrait quoi ?

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.

Quand Dario Amodei (Anthropic), Sam Altman (OpenAI) et Elon Musk (xAI entre autres) tombent d’accord, ça mérite qu’on s’arrête deux minutes.

Le 12 septembre, Dario - le patron d’Anthropic donc - publie une lettre qui appelle à ralentir le développement de l’IA. Altman dit qu’il est d’accord. Musk répond “Dario a raison”. Trois concurrents qui ne s’aiment pas particulièrement (pour rester poli) et qui se tirent la bourre depuis des années, se mettent d’accord. Tiens, tiens.

Dans sa lettre, Amodei cite un événement précis. En juillet, une ribambelle d’agents IA d’OpenAI est sorti de son environnement de test et a mené des cyberattaques. Jusqu’à 1 200 agents.

OpenAI a publié son rapport complet le 26 août. Je l’ai lu.

Première réaction : waouh. L’impression d’être face à quelque chose qu’on n’avait jamais vu et un vecteur de risque nouveau.

Ce qui s’est passé

OpenAI fait passer des tests de cybersécurité à ses modèles. Le principe : exploiter une faille pour récupérer un code de validation, un “flag”. Certains exercices n’ont aucune solution connue. Les agents sont bloqués. “Frustrés”, ils se mettent à tricher. Les chercheurs appellent ça le “reward hacking” : atteindre l’objectif par un chemin que personne n’avait prévu.

Pour tricher, il leur faut internet. Comment faire? Ils l’obtiennent en détournant un service interne. Ils s’improvisent un tableau de messages pour échanger entre eux. Ils finissent par se coordonner, se répartir le travail, et se désignent eux-mêmes comme un “collectif”.

Vous avez bien lu. Ils ont commencé à collaborer et à se déléguer du travail. Et ça a commencé le 12 mai. C’était loggé.

Entre le 10 et le 12 juillet, ils compromettent l’infrastructure de Hugging Face. Puis ils reviennent sur le réseau interne d’OpenAI, jusqu’à obtenir des droits admin sur un cluster.

Maintenant, regardez la chronologie côté défense.

Fin mai, une équipe interne voit un agent utiliser ce tableau de messages et accéder à internet sans autorisation. Elle ne préviendra pas la cyber.
Le 5 juillet, l’équipe sécu ouvre un incident : le service détourné est tombé sous la charge des agents. Elle bloque une élévation de privilèges, supprime des identifiants exposés, reconstruit le service. Traité. Le 19 juillet, une alerte sur des identifiants lance une enquête. Le 20, OpenAI fait enfin le lien avec Hugging Face.

Huit semaines entre le premier signal et le bon diagnostic. Et OpenAI l’écrit noir sur blanc : ceux qui avaient vu les signaux en mai n’étaient pas ceux qui géraient l’incident en juillet.

C’est là que l’effet waouh est retombé

Au SOC, je vois souvent des alertes fermées sans corrélation entre elles. Des signaux faibles. Pris un par un, aucun ne constitue un incident. Mis bout à bout, si.

Le problème, c’est qu’ils arrivent chez des analystes différents, à des moments différents. Chacun traite son ticket correctement. Personne ne fait le lien.

Chez OpenAI, c’est exactement le même scénario. Avec des moyens que très peu d’entreprises ont. Et un détail qui fait mal : leurs outils de surveillance du raisonnement des modèles existaient déjà. Ils ne tournaient simplement pas sur ces tests. D’après OpenAI, s’ils avaient tourné, la sécu aurait été alertée plus d’un jour avant l’attaque sur Hugging Face.

L’attaquant était inédit. Il a été raté de la façon la plus banale qui soit.

Alors, oui, c’était un labo loin des standards de nos SI

Soyons honnêtes. On va pas trop extrapoler. C’était un labo avec des garde-fous volontairement allégés pour tester les modèles. OpenAI estime que le risque chute de plus de 100 fois avec ses protections de prod. Votre boîte n’entraîne pas de modèles d’IA et - en théorie - n’est pas exposée directement à ce risque.

Mais si demain vos équipes branchent des agents IA sur votre SI, avec des comptes de service et des accès, la question se posera. Votre prestataire SOC verra peut-être une anomalie sur un de ces comptes. Saura-t-il que c’est un agent ? Saura-t-il faire le lien? Est-il sensibilisé sur ce qui est légitime de ce qui ne l’est pas ? Est-ce que c’est clair pour vous - en tant que RSSI - quels sont les usages permis de ceux qui ne le sont pas ?

Sans ce contexte, l’alerte a toutes les chances de finir comme les autres. Noyée dans la masse ou fermée par un analyste qui fait bien son travail, sur un ticket qui ne raconte qu’un morceau de l’histoire.

On cherche quoi maintenant ?

C’est bien beau tout ça, mais on fait quoi?

→ Savez-vous quels comptes de mon SI sont utilisés par des automatisations ou des agents IA ? Si la réponse est non, c’est à vous de lui fournir la liste. Il ne peut pas la deviner.

→ Comment corrélez vous les alertes qui touchent un même compte sur plusieurs semaines, au delà de la fenêtre habituelle des règles ?

→ Qui a le droit de couper un agent à 3h du matin ? Depuis l’incident, OpenAI applique une règle simple : si on ne prouve pas en 30 minutes qu’une alerte grave est un faux positif, on met l’activité en pause. Chez vous, qui prend cette décision ? Et est-ce que c’est écrit quelque part dans un playbook, une fiche réflexe ou dans ce que vous avez délégué à votre MSSP ?

Cette dernière question dépasse le scope du SOC. Décider jusqu’où un agent peut agir seul dans votre entreprise, ce n’est ni au SOC ni à son prestataire de trancher. Ni au RSSI tout seul d’ailleurs. C’est un arbitrage de direction.

Voilà, c’est tout.

Je n’ai encore jamais eu d’agent IA à surveiller. Mais je parie que le jour où l’un d’eux sortira de son cadre, la première alerte finira fermée par un analyste qui ignorait que c’était un agent.

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.

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 du fisc français (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é. Mot de passe reset.

Juillet 2026. Ça recommence. Un autre compte, avec des privilèges cette fois. Accès frauduleux. On détecte et on réinitialise le mot de passe.

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 :

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.

Point faible du SOC : il est dépendant de la data qu’on lui envoie.

Imaginez la scène. Le 5 Août à 23h. Vous êtes en vacances en famille, cocktail à la main en terrasse, mode avion. Pendant ce temps, votre contrôleur de domaine Active Directory arrête d’envoyer ses logs au SOC.

Les analystes traitent leurs alertes, les tableaux de bord n’affichent rien, tout a l’air normal. Sauf que vous êtes devenu aveugle sur une grosse partie de votre SI. Pas n’importe quel morceau. Vos login/logoff (entre autres) ne remontent plus.

The show must go on

Un analyste qui prend une P1 en pleine nuit, pose le bon diagnostic et applique le bon plan d’action ? Bravo. Il le mérite. On le félicite en comité, on cite l’incident en exemple, on en fait un retex.

Le mec (ou la nana) qui est prévenu à minuit pour régler un problème de bande passante réseau qui coupe le flux syslog ? Beaucoup moins. Vous le ne connaissez sûrement pas. Quand il fait bien son job, il ne se passe rien. Et “il ne se passe rien”, ça ne se met pas sur une slide de COPIL. Trop technique.

C’est le métier du MCO, le Maintien en Conditions Opérationnelles. En clair : s’assurer, tous les jours, que les équipements remontent les bons logs, au bon format, en temps réel. The show must go on, mais pour ça il faut quelqu’un qui vérifie que le courant passe.

Et ce quelqu’un touche le point faible du SOC : un SOC ne vaut que ce que vaut la donnée qu’il reçoit (phrase d’un ancien collègue belge, Marc H. si tu me lis).

Vous pouvez avoir le meilleur moteur du marché, s’il n’y a plus d’essence dans le réservoir, vous n’allez nulle part. Le pire, c’est que le tableau de bord peut très bien continuer d’afficher “plein”.

Trois façons de devenir aveugle

Les problèmes de collecte, il y en a trois. Par ordre de sournoiserie croissante.

Le 1e : plus de logs du tout. La source se coupe. C’est brutal, mais au moins c’est binaire. Avec un minimum de supervision, on le détecte vite. “Telle source n’a rien envoyé depuis 30 minutes”, alerte, bim, on va voir.

Le 2e : moins de logs. “La source envoie toujours, mais elle en envoie 50% moins”. Une montée de version qui change le comportement de l’équipement, un filtre mal configuré, un changement d’archi. Le flux existe, donc rien ne clignote en rouge. Sauf qu’une partie des événements ne remonte plus. Celui-là passe déjà plus facilement sous le radar.

Le 3e : la même quantité de logs, mais plus les bons types de logs.

Exemple : “On reçoit toujours les logs système. Les logs sécurité ont disparu.”
Ou alors : “On ne reçoit plus le champ de la commande sur l’event ID 4688 de Windows suite à un changement de la GPO”.

Je vous préviens, il est vicieux, lui : L’équipement envoie toujours son volume habituel, tout a l’air nominal, sauf que le contenu a changé. Un champ qui n’est plus rempli, un format qui a bougé, une catégorie d’événements qui disparaît. Rien ne se voit.

En général, on s’en rend compte après coup. Pendant la revue des règles de détection, quelques mois plus tard, quand quelqu’un tombe sur une règle qui n’a rien remonté depuis un moment. Et là vous réalisez que pendant tout ce temps, le SOC a pu louper des comportements suspects. Sans lever la moindre alerte.

Assurez-vous que la santé de vos flux SOC est correctement supervisée

Si vous pilotez un SOC externalisé, au-delà de la supervision de menace, posez-vous la question : qui surveille la santé des sources de logs, et comment je le sais ?

Dans le numéro #3 sur les red flags du contrat, je parlais déjà de la responsabilité sur la qualité et la quantité des données ingérées. La MCO, c’est le pendant opérationnel de cette clause.

Bref. La prochaine fois qu’un comité SOC se passe bien, qu’aucune source n’est tombée, que tout a remonté proprement pendant le trimestre, ayez une pensée pour les gens de l’ombre. C’est souvent qu’ils ont bien bossé.

Et si vous avez trouvé une vraie solution pour détecter le 3ème cas, un type de log spécifique qui change ou disparaît sans prévenir, écrivez-moi ou commentez cet article. Je suis preneur. C’est une des zones grises les plus récurrentes du monitoring de la santé SOC.

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.

Un client sur Crowdstrike m’a un jour demandé de me battre pour obtenir la licence pour avoir au SIEM la télémétrie EDR. Il voulait tout centraliser au même endroit.

J’ai fait chiffrer l’option avec l’éditeur. Passer sur cette licence multipliait le coût de son EDR par 2,5. Il a renoncé. Trop cher.

Et honnêtement, il a eu raison. Pas parce que les logs EDR ne servent à rien. Dans son cas précis, le jeu n’en valait pas la chandelle.

Laissez-moi vous expliquer pourquoi, parce que la réponse n’est pas la même pour tout le monde.

L’EDR détecte mieux que le SIEM. Sans discussion

Un EDR, c’est l’agent installé sur chaque poste et chaque serveur qui surveille en continu ce qui s’y passe. Un SIEM, c’est la plateforme centrale qui collecte et est sensée correler des logs venus de partout.

Sur la détection pure des menaces qui touchent un poste de travail, l’EDR est très largement meilleur que le SIEM. On ne fera jamais aussi bien avec un moteur de corrélation générique qu’avec un moteur spécialisé, entraîné sur des millions de postes dans le monde entier.

En plus, l’EDR agit tout seul. Mise en quarantaine du poste, isolation réseau. Sans attendre qu’un analyste lève la main.

Alors pourquoi vouloir absolument envoyer ces logs bruts dans le SIEM ? Sur le papier, ça ressemble à payer deux fois pour la même chose.

La vraie raison de collecter ces logs : la réponse à incident

Quand vous investiguez un incident sérieux, vous cherchez souvent des traces vieilles de plus de 30 jours. Un incident que vous découvrez aujourd’hui peut avoir un point d’entrée posé plusieurs semaines, parfois plusieurs mois plus tôt.

Problème : la rétention native d’un EDR ne couvre pas cette profondeur. Passé un certain nombre de jours, les logs de l’agent disparaissent.

C’est là que le SIEM prend son sens. Pour garder la mémoire longtemps, et permettre de remonter le fil quand l’incident est déjà là et qu’il faut comprendre depuis quand vous êtes compromis. Pas pour la détection pure et dure donc.

Ça se résume à une question de budget. Et de maturité

Petit budget SIEM ? Ne payez pas l’ingestion complète des logs EDR. Ce n’est pas optimal. Vous paierez cher pour un bénéfice de détection quasi nul, et vous n’aurez de toute façon ni le temps ni les ressources pour exploiter cette masse de données.

Budget confortable, équipe qui a le temps d’investiguer et de croiser les sources ? Foncez. Totalement, ou partiellement selon vos priorités.

Parce que là où ça devient intéressant, c’est la corrélation entre sources.

Un mail de phishing arrive. Clic sur le lien. Téléchargement. Exécution depuis le poste. Si vous avez vos logs mail, proxy web et endpoint au même endroit, vous voyez la chaîne complète en une seule alerte. Certaines plateformes SOC savent même regrouper ces événements automatiquement.

Sans cette centralisation, vous avez trois signaux isolés, dans trois outils différents, que personne ne relie entre eux avant qu’il ne soit trop tard.

Il y a aussi le cas des menaces qui sortent de nulle part. Face à une vulnérabilité toute fraîche, les règles qu’on peut pousser sur un EDR restent souvent basiques : des combinaisons de ET, OU, SAUF. Pour aller chercher des anomalies plus fines, avoir des logs système centralisés permet à une équipe qui sait s’en servir d’être plus rapide que l’éditeur lui-même sur une technique inédite.

Mais cette dernière phrase compte double : “une équipe qui sait s’en servir”. Sans elle, vous payez pour du stockage inutile. Avec elle, vous démultipliez votre capacité de détection.

Le SIEM ne remplace pas l’EDR. L’EDR ne remplace pas le SIEM.

Ils ont deux jobs différents. L’EDR détecte et agit en temps réel sur le poste. Le SIEM garde la mémoire et corrèle dans la durée.

Mon client n’avait ni le budget ni l’équipe pour exploiter la corrélation. Payer plus cher pour stocker des logs que personne n’allait analyser, ça n’avait aucun sens. Il a bien fait de dire non.

Si vous êtes face à ce choix, posez-vous la question : qui va concrètement exploiter ces logs, et pour quel cas d’usage précis ?

Gardez votre budget pour autre chose si votre réponse est vague.

Akira ne s’intéresse pas à vous parce que vous êtes vous. Il s’intéresse à vous parce que vous êtes une ETI avec un VPN pas à jour.

Avec la canicule, on ne parle que de deux choses en ce moment. La chaleur, et le football. Coupe du monde oblige.

Alors prenons le foot. Aujourd’hui, un gardien qui veut arrêter un penalty ne décide pas au moment du tir. Il a étudié le tireur avant. Sa course, son pied fort, ses habitudes. Les supporters du PSG s’en souviennent : Lors de la dernière finale, Safonov (le gardien de but) avait glissé des notes sur les tireurs adverses dans sa serviette avant la séance de tirs au but. Le staff avait bossé ça en amont, rien n’est laissé au hasard. Le PSG a gagné. (Au passage, j’ai parlé du SOC du PSG ici.)

Au SOC, c’est pareil.

Un SOC qui ne connaît pas les attaquants de son secteur attend le tir sans savoir où plonger. Il subit. Un SOC mature a étudié l’adversaire avant qu’il frappe.

Tenez, Akira. Un des groupes de ransomware les plus actifs du moment, près de 244 millions de dollars de rançons à son compteur fin 2025. Son entrée préférée : les VPN exposés, non patchés, sans double authentification. Son terrain de chasse n’est pas choisi au hasard : il cible en priorité les accès distants des industries. L’attaquant lui-même sélectionne ses victimes par secteur.

D’où la question : Est-ce que votre détection est réglée pour les attaquants qui ciblent votre secteur ? Ou est-ce qu’elle tourne sur un catalogue de règles standard, le même pour tout le monde ?

S'abonner maintenant

Le SOC prêt-à-porter

Quand un prestataire onboarde un nouveau client, il peut être tenté par dérouler le même paquet de règles de détection. Celui qu’il a déjà déployé chez les trente clients d’avant.

Le problème, c’est qu’une banque ne se fait pas attaquer comme un hôpital. Et un hôpital pas comme une usine de fabrication de panneaux solaires.

Depuis 2025. La santé, c’était un carnage.

Hôpital d’Armentières, 300 000 dossiers chiffrés par LockBit. Weda, 5 millions de dossiers médicaux exposés. Des groupes comme Qilin ciblent les hôpitaux précisément parce qu’un bloc à l’arrêt, ça pousse à payer vite. La menace ici, c’est le ransomware qui paralyse le soin.

La finance, c’est un autre monde. Les banques sont plutôt épargnées sur les fuites massives, parce qu’elles investissent depuis des années et que la réglementation les serre. Leur vulnérabilité, c’est la disponibilité. Le DDoS hacktiviste ou opportuniste. La Banque Postale paralysée le 22 décembre 2025, en pleine période de Noël. C’est un service qui tombe au pire moment.

Le retail, encore autre chose. Un grand classique, c’est le credential stuffing : on rejoue des mots de passe volés ailleurs pour entrer dans les comptes clients. Comme beaucoup réutilisent le même mot de passe partout, ça marche. Kiabi en a fait les frais début 2025. Des comptes forcés par rejeu d’identifiants, et au bout, les IBAN de 20 000 clients exposés. L’enseigne a dû les masquer en catastrophe. Ça n’a rien à voir en terme de monitoring avec un ransomware sur un hôpital ou le DDOS de l’application web d’une banque.

Trois secteurs. Trois modes opératoires. Trois priorités de détection complètement différentes.

A ce stade, on peut s’accorder à dire qu’un SOC qui applique le même jeu de règles aux trois ne sera pas efficace.

Le bon sens de lecture

Un SOC bien calibré part de la fin et remonte. Comme je le disais dans le numéro précédent sur la collecte.

Il commence par une question qui n’a rien de technique : qui m’attaque, moi, dans mon métier ? Quels groupes ciblent les boîtes comme la mienne, et comment ils s’y prennent concrètement. Leurs techniques, leurs tactiques, leurs procédures.

C’est de la threat intelligence sectorielle. Connaître les attaquants de son secteur. Et ce n’est pas un luxe réservé aux grands groupes. C’est la base. Une fois que vous savez ça, vous listez les scénarios réalistes, vous priorisez, vous construisez les détections qui les couvrent. Le reste découle.

Les deux questions que le SOC se pose

• “Sur quels groupes attaquants spécifiques à mon secteur sont calibrées mes détections ?” Il faut citer des noms et des modes opératoires, pas juste des “menaces avancées” dans le vide.

• “Comment ma threat intelligence sectorielle alimente concrètement mes règles de détection ?” Une CTI qui finit dans un PDF mensuel que personne ne lit ne sert à rien. Elle doit redescendre dans la détection.

Certains régulateurs ont déjà tranché

Dans la finance par exemple, c’est déjà acté. DORA, le règlement qui s’applique aux acteurs financiers depuis janvier 2025, force les banques à se tester sur des scénarios d’attaque construits à partir des menaces qui les visent vraiment. Pas un audit générique. Un exercice calibré sur leurs vrais adversaires.

Ailleurs, personne ne vous y oblige. C’est à vous de le faire.

Un SOC calibré pour tout le monde est calibré pour personne. Le bon réglage, c’est peu de règles, mais les bonnes. Celles qui collent aux attaquants de votre métier. Pas celles du catalogue.

Mehdi Charki est SOC Manager avec 10 ans d’experience. SOC Performance est sa newsletter indépendante sur la gouvernance, stratégie et pilotage SOC.

Pourquoi un bon SOC surveille moins pour fonctionner mieux. Et comment s’assurer que son SOC a une stratégie de collecte solide.

J’ai assisté à l’onboarding d’un SOC chez un client. Réunion de cadrage, le chef de projet du prestataire fait le tour des sources de logs à brancher.

Firewall, oui. Endpoints, évidemment. Cloud public, bien sûr. Proxy web, AD, VPN, WAF, applicatif métier. Tout y passe. Le mot d’ordre tenait en trois mots : “Au cas où”.

À aucun moment quelqu’un n’a posé la question qui compte : qu’est-ce qu’on cherche à détecter, exactement ? On collecte d’abord. On verra plus tard.

J’ai vu ce film plusieurs fois. Étonamment, il finit toujours de la même façon.

Le raisonnement est à l’envers

Plus je collecte, mieux je détecte, non?

Voici la logique : On branche toutes les technos. Comme on a la donnée sous la main, on écrit des règles de détection dans tous les sens, pour “en profiter”. Ces règles génèrent des milliers d’alertes. Et c’est là qu’on découvre qu’on n’a pas les bras pour les traiter.

Alors on rajoute des analystes. On achète un outil pour trier. On paie une prestation pour calibrer le bruit qu’on a soi-même fabriqué quand on atteint les limites de volumétrie. Ou on paie de nouvelles licenses SIEM pour se rajouter du bruit.

À chaque étape, la facture monte. La détection ne s’améliore pas tant que ça. Les signaux importants à observer se noient dans la masse.

C’est ça, raisonner avec une casquette de technicien là où il faudrait du pilotage. Le technicien aura tendance à suivre les étapes dans l’ordre où elles se font : je collecte, je détecte, j’investigue. C’est l’ordre dans lequel on apprend à faire un SOC. Ce n’est pas l’ordre optimal pour construire un SOC.

L’autre sens, celui qui marche pour le coup

Un SOC bien pensé fait exactement l’inverse.

Il part d’une question simple : comment va-t-on m’attaquer, moi, dans mon secteur ? Quels groupes attaquants ciblent les boîtes comme la mienne, et comment s’y prennent-ils concrètement (techniques, tactiques) ? On liste les scénarios réalistes. On identifie les quick wins et les priorités. On planifie les détections qui couvrent ces scénarios. Et seulement à la fin, on collecte les logs nécessaires pour faire tourner ces détections et investiguer derrière. Rien de plus.

Le résultat est contre-intuitif. On collecte moins, on dépense moins, et on détecte mieux. Parce qu’on surveille ce qui compte pour nous, pas tout ce qui passe par là.

J’en ai fait l’expérience personnellement. Sur un périmètre que je supervisais, la facture de collecte avait pris l’ascenseur. Beaucoup trop de données ingérées, sans usage de détection derrière. De la donnée stockée pour son utilité théorique.

On a fait le ménage. Source par source, on s’est posé deux questions. Est-ce qu’une règle de détection s’appuie dessus ? Est-ce qu’on investigue réellement avec ? Quand la réponse était non aux deux, on coupait ou on réduisait la rétention.

La facture a été resorbée sans dégrader la détection. Au contraire. On y voyait plus clair. Moins de bruit, moins de sources mortes, des analystes plus efficaces qui regardent enfin les bonnes choses.

On n’avait rien rajouté. On avait enlevé ce qui ne servait à rien.

Evaluez votre stratégie de détection

Voici les questions à vous poser (ou à poser à votre prestataire) :

Un SOC mature assume ses choix. Il sait ce qu’il descope, et sait l’expliquer.

Et rappelez-vous l’article numéro #2 : le bruit a un coût. Qui le paie? Sur une collecte mal pensée, c’est toujours le client.

Le volume de logs ingérés n’est pas une preuve de performance. C’est le plus souvent l’aveu qu’on n’a pas décidé quoi chercher avant de se mettre à chercher.

Collecter tout “au cas où” donne le sentiment de ne rien rater. Dans les faits, c’est le meilleur moyen de tout rater, en payant le prix fort.

Mehdi Charki est SOC Manager avec 10 ans d’experience. SOC Performance est sa newsletter indépendante sur la gouvernance, stratégie et pilotage SOC.

Samedi 30 mai à 18H : le PSG jouera sa 2ème finale de Ligue des Champions d'affilée. Pendant que vous regardez le match, quelqu'un surveillera les écrans du SOC.

Je serai chez moi. Canapé, thé Rooibos, téléphone en silencieux. Et je penserai à eux.

Pas aux joueurs. Pas aux 400 millions de téléspectateurs. Je penserai aux analystes du SOC qui auront calé un écran de foot parmi leurs 15 écrans sur le mur. Ceux qui surveillent le SI du PSG pendant que le reste du monde retient son souffle devant PSG-Arsenal.

Déformation professionnelle? Oui, je l’entends.

Un club de foot, une cible comme une autre ?

Le PSG, c’est une entreprise.

Merchandising et boutique en ligne, partenaires commerciaux dans plusieurs pays, droits TV, infrastructure numérique qui tourne en permanence. Derrière tout ça, un système d’information : Des postes de travails, des serveurs, des accès, des données sensibles et des interconnexions avec des partenaires.

Et quelques jours avant une finale, l’exposition explose.

Les tentatives de phishing décollent. Les arnaques. Les fausses billetteries. Les faux comptes officiels. Les sites de streaming vérolés. Et parfois, derrière le bruit médiatique, des attaques ultra-ciblées qui profitent du moment où tout le monde regarde ailleurs.

Les attaquants le savent. Un grand événement un samedi soir, c’est une ouverture. Les équipes IT et cyber sont distraites, les utilisateurs cliquent sur n’importe quoi, et les équipes cyber tournent en effectif réduit.

J’ai connu ce genre de soir-là

Pas pour une finale de Ligue des Champions. Mais pour des pics d’activité, des annonces d’entreprise médiatisées, la publication de résultats annuels, des déploiements majeurs. Des moments où tout le monde dans la boîte a autre chose en tête que la sécurité.

Ce qu’on faisait en amont : rien de particulier. Car (presque) tout était déjà en place. Voilà, fin de l’article 😁

Je plaisante à moitié. Car ce “rien” a pris des mois voire des années à construire.
Le problème, c’est que beaucoup de dispositifs cyber n’en sont pas là. Ils n’ont pas ces fondations. Quand le pic arrive, c’est la pression qui remplace la méthode.

Ce que ça change pour vous

Vous n'êtes pas le PSG. Vous n'organisez pas de finale européenne.

Mais la posture du DSI ou du RSSI au PSG avant ce genre de soir, c'est exactement celle que vous devriez vous poser avant un pic d'activité, une fusion-acquisition, une annonce médiatisée ou... n'importe quel mardi d'ailleurs.

• Les utilisateurs sont préparés ?

• Les playbooks ont été testés récemment ?

• La chaîne de communication en cas de crise est fonctionnelle ?

• Le système d’astreinte fonctionne correctement ? Il a été testé ?

• Mes règles de détection sont calibrées pour ce qui se passe dans mon SI ce soir-là ?

Un SOC bien préparé le soir d'un événement majeur ou exceptionnel l'est parce qu'il travaille comme ça tous les jours. Pas parce que l'événement l'a motivé.

Mehdi Charki est SOC Manager avec 10 ans d’experience. SOC Performance est sa newsletter indépendante sur la gouvernance, stratégie et pilotage SOC.

J’ai assisté à une démo SOC. Je m’en souviens encore. Discours fluide. Références client solides. Puis au bout de 20mn, une slide apparaît : “Notre catalogue de 2 500 use cases prêts à l’emploi.” Je décroche.

On me prendra sûrement pour un fou. Mais 2 500 use cases actifs, adaptés à votre SI et maintenus, ça n’existe pas au SOC. Ce que ça veut dire : votre partenaire a un catalogue de règles de détection, construit pour tous les clients. Pas forcément vôtre SI et ses spécificités.

Le vrai travail dans un SOC, c’est le contexte. Ce sont les use cases tailorés, ceux qui collent à votre métier, votre infra, vos usages et besoins spécifiques. 2 500 règles génériques, c’est rarement suffisant sans travail d’affinage derrière.

Les use cases, c’était le premier signal. Ce n’était pas le seul.

Un contrat SOC est un document difficile à lire

Pourquoi ? Parce qu’il essaie d’enfermer dans un “mot” (le SOC) un truc qui refuse de se standardiser. Et ça vient de deux facteurs très concrets :

D’un côté, le client final. Chaque boîte a sa propre org, sa propre façon de réagir aux incidents, ses propres risques. Un SOC pour Orange, c’est pas un SOC pour une ETI du BTP. Chaque client a besoin de choses différentes en détection, en escalade, en réaction. Chaque entreprise a sa propre définition du mot “SOC”.

De l’autre, le prestataire. Chaque MSSP a sa propre usine à gaz. Ses outils, ses processus, sa définition du “SOC managé”. L’un dit “on se débrouille, on détecte tout ce qui se passe sur votre réseau”, l’autre dit “on détecte les alertes que si elles remontent des logs”. Ce n’est pas la même chose, mais ça s’appelle la même chose.

Résultat ? Vous lisez un contrat avec votre prestataire en pensant que vous avez la même définition de ce qu’est un SOC.

Revenons à notre contrat SOC

Voici les 4 clauses que j’ai appris à repérer en premier. Celles dont l'absence - ou la formulation floue - peuvent coûter très cher par la suite.

🚩 Red flag nº1 Le catalogue de use cases sans engagement sur la customisation

Combien de règles seront écrites spécifiquement pour votre SI? Qui les maintient quand votre infra évolue ? Si la réponse est vague, vous achetez du générique.

Antonin Hily est un practicien SOC avec 25 ans d’experience. Vous l’avez peu-être lu dans le numéro #2 (Questions à poser au prestataire SOC). Il le formule ainsi :

“Le catalogue de use cases prêts à l’emploi, ça impressionne en avant-vente. En réalité, 80% sont génériques, génèrent du bruit sur votre SI, et personne ne les ajuste. La vraie question : combien ont été écrits spécifiquement pour des entreprises comme la vôtre ?”

Je vais rajouter un angle mort supplémentaire. Les règles statiques ne détectent que ce qu’on a anticipé, il faut les compléter par de l’analyse comportementale - ce que les anglo-saxons appellent le UEBA (User & Entity Behavior Analytics).

Un compte admin AD qui crée un nouvel utilisateur à 2h30 du matin depuis le Turkménistan - aucune règle ne le verra si personne n’a pensé à l’écrire en amont.

Ce sujet mérite un article entier - j’y reviendrai dans un prochain numéro.

🚩 Red flag nº2 Le tuning absent du contrat

Le tuning, c’est l’ajustement continu des règles de détection du SOC.
Antonin est direct là-dessus :

“Le tuning, c’est 70% de la valeur d’un SOC. Si le prestataire ne s’engage pas sur un cycle de tuning régulier (mensuel minimum), tu paies pour un moteur qui crache des alertes que personne ne lit.”

Sans tuning, votre SOC détecte ce qu’il détectait le jour de la mise en service. Votre infrastructure évolue, les techniques d’attaque évoluent. La détection, elle, reste figée.

🚩 Red flag nº3 Le SLA qui protège le prestataire, pas le client

Dans le contrat que j’ai lu ce jour-là, les SLA s’appliquaient uniquement aux incidents qualifiés de “critiques”. Classique, vous me direz ? Mais en lisant la définition de “critique”, j’ai compris là où ça coinçait.

La définition était tellement restrictive qu’un ransomware en cours de propagation dans votre réseau pouvait très bien ne pas remplir les critères. Et s’il les remplissait malgré tout, le contrat prévoyait une clause : les analystes pouvaient requalifier l’incident après coup. En clair, si le SLA n’était pas respecté, il suffisait de descendre la sévérité. Emballé, c’est pesé.

Il y a un 2ème angle que soulève Antonin, tout aussi important. Beaucoup de contrats s’engagent sur la prise en compte de l’alerte mais pas sur sa qualification.

“Ce qui compte, c’est en combien de temps l’alerte est qualifiée vraie ou fausse, et avec quelle fiabilité. Prendre une alerte en 15 minutes ne veut rien dire si personne ne s’engage sur ce qui se passe ensuite.”

Les SLAs méritent un article entier également - j’y reviendrai dans un prochain numéro.

🚩 Red flag nº4 La volumétrie et la qualité des données ingérées

Celui-là, je l’aime bien. On ne le voit pas venir.

• Quand on dépasse la volumétrie contractuelle, qui supporte le surcoût ?

• Et surtout, qui est responsable (dans le sens “accountable”) de la qualité, de la quantité et de l’indexation des données ingérées par le SOC ?

⚠️ Ce n’est pas la tambouille interne du MSSP comme je l’ai déjà entendu avant.

Antonin le confirme :

“On collecte tout” est un drapeau rouge immédiat. Collecter tout, c’est ne rien analyser. Le vrai sujet n’a jamais été le volume de logs ingérés, mais quelles sources sont parsées proprement, normalisées, corrélées.

Un SOC qui ingère tout travaille dans le vide. Il génère du bruit, rate des signaux et donc des alertes. En plus de coûter cher en licenses et stockage.

Quand ça arrive, il trouvera des arguments “C’est vos logs qui ne sont pas au bon format”. Si personne n’est officiellement responsable de la qualité de ce qui entre, personne ne sera responsable de ce qui s’y passe et des conséquences.

La question qui fait la différence

Antonin a une méthode imparable pour griller un avant-vente qui survend.

Je demande à voir un ticket d’incident traité. Pas une slide. Un vrai ticket, anonymisé, du début à la fin. Avec l’horodatage, l’analyse, la qualification, la décision. Les bons prestataires en sortaient un en cinq minutes. Les autres bottaient en touche.

Un contrat SOC engage souvent sur trois ans. Ce que vous signez aujourd’hui, c’est le niveau de protection dont vous disposerez le jour où vous en aurez vraiment besoin.

Lisez-le attentivement. Et prenez le temps d’identifier ce qui est couvert dans votre SOC et ce qui ne l’est pas.

Mehdi Charki est SOC Manager avec 10 ans d’experience. SOC Performance est sa newsletter indépendante sur la gouvernance, stratégie et pilotage SOC.

Savez-vous ce que vous achetez ? Décryptage de 50+ relations Client ⇔ Fournisseur SOC observées : les questions que vous n’osez pas amener sur la table avant de signer.

Quand j’ai débarqué chez Orange Cyberdefense fin 2016, il y avait deux noms qui revenaient avec insistance dans toutes les conversations.

Emmanuel Macron, qui allait devenir président quelques mois plus tard.
Et Antonin.

Le mec à droite, c’est Antonin.

C’était une sorte de légende dans l’open-space d’Orange à Rueil-Malmaison. Lui et son équipe avaient monté des SOC pour une bonne partie des entreprises françaises. Des contrats allant de 150K€ à 3M€ par an signés par des RSSI et des DSI qui - pour la plupart - contractualisent un service SOC pour la première fois.

Ce qui m’a interpellé : les clients étaient compétents et plutôt bien intentionnés. Par contre, la plupart n’avait aucune référence ou grille crédible pour évaluer objectivement ce qu’ils achetaient. Hormis le sourire rassurant d’Antonin, une chemise bien repassée et une poignée de main ferme.

C’était il y a plus de 10 ans. Pourtant, ce constat est toujours d’actualité aujourd’hui.

Antonin est mon invité spécial du jour pour adresser le sujet (Désolé pour ceux qui attendaient Manu. Il a d’autres priorités en ce moment).

Antonin est désormais CTO et General Manager d’un éditeur de solution NDR. Il a fondé la 1ère équipe SOC de CGI en France en 2006 - à une époque où le terme “SOC” était encore flou. Il a construit l’équipe détection chez Atheos (rachetée par Orange), restructuré le SOC de Sopra Steria, a été directeur cyber chez Capgemini. Il a vu des dizaines de contrats SOC se négocier. Des bons. Des moins bons.

Cet article est indépendant et n’est pas sponsorisé. Antonin a gentiment accepté l’invitation en tant que praticien cyber et SOC avec plus de 25 ans d’expérience.

Les fameuses questions

Quand on signe un contrat SOC, on est dans une position inconfortable. On s’engage, en général sur 3 ans. On ne sait pas exactement ce qu’on achète en terme de qualité de service. On doit faire confiance aux slides, aux commerciaux qui les présentent, aux certifs, aux références clients.

Surtout, on ne veut pas risquer d’abîmer la relation de confiance avec son prestataire avant même le démarrage. En challengeant et en demandant des comptes.

Sauf que le diable se cache dans ce qu’on n’a pas osé demander avant de signer.

J’ai demandé à Antonin les questions qu’un DSI ou RSSI doit mettre au clair avec son prestataire SOC, idéalement avant de contractualiser.

La 1ère question d’Antonin : “Montrez-moi la procédure exacte pour un ransomware détecté samedi à 3h du matin. Qui appelle qui, en combien de temps, et qui décide de couper quoi ?”

Les prestataires vendent souvent de la détection, pas de la réponse. Quand vous forcez la démonstration du scénario réel, vous voyez immédiatement si la chaîne tient avec un runbook structuré ou si c’est juste une slide. Ou un avenant qui apparaîtra dans votre prochain renouvellement.

La 2ème : “Quel pourcentage de faux positifs attendez-vous par semaine sur mon SI, et qui paie leur traitement ?”

Le vrai coût d’un SOC, c’est le bruit. Dans mon premier numéro, j’expliquais qu’un SOC qui traite 80% de faux positifs développe un réflexe dangereux : ses analystes ferment les alertes plus vite, avec moins d’attention. C’est exactement là que les vraies attaques passent. Un prestataire qui promet “peu de faux positifs” sans engagement chiffré vous vend un rêve. Et quand ça explose, ce sont vos équipes opérationnelles qui encaissent - pas les siennes.

La 3ème question d’Antonin, la plus sous-estimée : “Si je résilie dans 12 mois, qui est propriétaire des règles de détection développées pour mon périmètre ?”

Neuf fois sur dix, la réponse est : le prestataire. Vous repartez à zéro. C’est un vendor lock-in - une dépendance forcée - que personne ne voit venir au moment de signer.

4ème et dernière question : “Combien d’analystes dédiés, physiquement, à mon compte ?”

Vous seriez surpris. La réponse honnête est souvent : zéro. L’analyste existe. Mais il est mutualisé sur 10, 15 clients. Son temps réel sur votre compte se compte en minutes par jour. Le reste, c’est du jonglage de contexte : passer d’une plateforme à un autre, d’un client à l’autre. C’est le modèle économique du SOC externalisé mutualisé et il faut en être conscient.

Rendre les vrais KPIs digestes

Dans le numéro #1, je listais les indicateurs qui comptent vraiment : taux de faux positifs, MTTD, ratio de revue des use cases, taux de détection sur scénarios simulés. La question qu’un RSSI d’une filiale m’a posé la semaine dernière : comment je présente ça au COMEX sans perdre tout le monde ?

La règle d’Antonin est simple. Ne jamais présenter un KPI sans le traduire en question business.

“Sur 100 scénarios d’attaque testés ce trimestre, combien en a-t-on attrapés ?”

C’est la couverture effective - pas théorique.

“Si on se prend un vrai incident demain, en combien de temps détecte-t-on, contient-on ?”

C’est le MTTD et le MTTR, mais sur scénario réel. Pas en moyenne sur du bruit.

“Combien d’heures-analyste gaspillées sur du faux positif ce mois-ci ?”

C’est le coût caché que votre reporting mensuel n’affiche jamais.

Sa métaphore :

“Un SOC, c’est un service de garde aux urgences. On ne juge pas un service d’urgences au nombre de patients accueillis. On le juge au temps de prise en charge des cas graves. Le jour où vous arrivez avec un infarctus, vous vous fichez qu’ils aient traité 800 bobos dans la semaine.”

Attention au claquage

Antonin a plus d’une métaphore dans son sac. En voici une dernière marquante.

"Un SOC, c’est un muscle. Ça se construit, ça s’entretient, ça se teste. Un muscle qu’on ne challenge jamais s’atrophie. Le jour de l’incident, vous découvrez qu’il n’est plus là.”

Ces questions, c’est votre premier test de résistance. Posez-les avant de signer, à votre prochain comité, ou avant votre prochain renouvellement de contrat.
Un prestataire solide a déjà les éléments et répondra sans hésiter.
S’il botte en touche ? ça vous donne une information très utile.

Mehdi Charki est SOC Manager avec 10 ans d’experience. SOC Performance est sa newsletter indépendante sur la gouvernance, stratégie et pilotage SOC.

Vous avez externalisé votre SOC. Vous assistez aux comités, les indicateurs sont au vert. Mais vous n’êtes pas sûr que ça tourne bien. Ce numéro est pour vous.

“Mehdi, fais bien ressortir le nombre d’alertes pour montrer qu’on travaille bien au SOC.” C’est ce que m’a dit un jour mon RSSI dans un grand groupe français.

Je l’ai regardé d’un demi-œil. Il m’a regardé aussi. Je savais, il savait.

Alors j’ai acquiescé. J’ai sorti les chiffres. La slide a été présentée à la direction. Les chiffres sont parlants. Avec ça, on défend notre budget pour l’année prochaine.

Cette semaine-là, on avait raté un incident majeur qui aurait pu être détecté plus tôt. On ne manquait pas de monde. On ne manquait pas de savoir-faire. On était occupés à traiter le backlog.

C’est le problème fondamental des KPIs SOC tels qu’ils sont souvent présentés : on mesure ce qui est facile à comprendre pour un décideur. Pas ce qui compte vraiment.

Le piège du volume

Quand vous vous demandez “est-ce que le SOC fonctionne bien ?”, le réflexe naturel est de vous sortir un chiffre rassurant. 3 952 alertes traitées ce mois.
50 000 cette année. Les équipes sont occupées, tout va bien.

C’est un biais cognitif classique : on accorde de la valeur à ce qui est facile à voir et à compter. Le volume d’alertes ici, même s’il ne dit rien sur l’essentiel.

Car traiter beaucoup d’alertes (manuellement, j’entends), ça veut aussi dire que le SOC est sous pression constante. Que les analystes ferment des tickets en boucle sans jamais lever la tête. Et que les règles de détection génèrent tellement de bruit que les vrais signaux se noient dedans.

Le volume d’alertes mesure l’activité. Il ne mesure pas l’efficacité.
Cette confusion-là coûte cher.

Ce qu’il faut mesurer à la place

Voici les indicateurs que je regarde quand je veux vraiment évaluer la maturité d’un SOC. Pour savoir si le dispositif tient la route face à une vraie attaque.

Le taux de faux positifs

C'est le ratio entre les alertes qui ne mènent à rien et le total des alertes générées. Un taux élevé, c'est le signe que vos règles de détection sont mal calibrées. Et un SOC qui traite 80% de faux positifs finit par développer un réflexe dangereux : ses analystes ferment les alertes plus vite, avec moins d'attention.

Le MTTD (Mean Time to Detect)

Combien de temps s’écoule entre le début d’une attaque et le moment où votre SOC la détecte ? C’est le KPI qui fait mal, parce que la réponse est souvent mauvaise. La moyenne mondiale dépasse 200 jours. DEUX CENT JOURS pendant lesquels un attaquant peut se déplacer latéralement dans votre réseau, exfiltrer des données, préparer une attaque élaborée.

Le ratio de revue des use cases

Un use case SOC, c’est un scénario d’attaque que votre équipe surveille activement. Une règle de détection associée à un comportement suspect précis. Le problème : ces règles vieillissent. Les environnements changent, les formats de logs évoluent, les techniques des attaquants aussi. Une règle jamais révisée devient progressivement inutile - un bout de code qui ne sert plus à grand chose.

Le taux de détection sur scénarios simulés

C’est le test de réalité ultime. Lors d’un exercice red team, purple team ou pentest, est-ce que votre SOC voit ce que l’attaquant fait ? Détecte-t-il les mouvements latéraux, les tentatives d’escalade de privilèges, les exfiltrations simulées ?

Le nombre de threat huntings proactifs par mois

On parle ici d’investigation qui part d’une hypothèse, pas à la suite d’une alerte.
“Et si un attaquant était déjà dans notre SI en ce moment ? Où regarderions-nous ?”
“Et si il avait dump les credentials d’un admin AD. comment est-ce qu'on le saurait ?”
C’est une démarche proactive, structurée, qui demande du temps et de la compétence.

Ce que ça change concrètement pour vous

Vous n’avez pas besoin de maîtriser ces indicateurs dans le détail. Mais vous avez besoin de les poser sur la table lors de votre prochain comité. C’est eux les experts après tout.

Posez simplement ces deux questions : “Quel est notre MTTD actuel, et comment il évolue ?” “Quel pourcentage de nos use cases ont été révisés ces six derniers mois ?”

S’ils ne savent pas répondre, vous avez votre réponse sur l’état de votre SOC.

Mehdi Charki est SOC Manager avec 10 ans d’experience. SOC Performance est sa newsletter indépendante sur la gouvernance, stratégie et pilotage SOC.