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.