Voici 4 red flags à repérer sur son contrat SOC
#3 Vous ne lisez pas les CGU d'habitude? Vous n'avez pas ce luxe ici.
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.
La détection comportementale construit une baseline de ce à quoi ressemble un utilisateur “normal” dans votre SI, et remonte une alerte dès que quelque chose dévie. C’est de la customisation by design.
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.
Cherchez dans votre contrat un engagement explicite sur la fréquence de tuning. Si ce n’est pas écrit, ce n’est pas explicitement prévu.
🚩 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.”
Ce qu’il faut chercher dans le contrat : la définition exacte du “critique”, l’existence d’une clause de requalification, et un SLA explicite sur la qualification - pas seulement sur la prise en compte.
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.
Si votre prestataire n’est pas incité (contractuellement, j’entends) à optimiser les logs collectés, il n’aura aucun véritable intérêt à dépenser du temps pour le faire.
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.