Mini-SOC pour PME : passer d'une sécurité passive à une vraie détection, sans budget de grand groupe

C’est une phrase que j’entends souvent chez mes clients : “On a un antivirus et un firewall, on est tranquilles.” Sur le papier, c’est rassurant. Dans les faits, c’est un peu comme mettre une alarme sur sa porte d’entrée et ne jamais regarder les caméras de surveillance : vous êtes protégé contre ce qui essaie d’entrer bruyamment, mais aveugle à ce qui se passe une fois que quelqu’un est déjà dans la maison.

C’est exactement la différence entre une sécurité passive et une sécurité active. Et c’est là qu’intervient une notion qu’on associe presque toujours aux grands groupes : le SOC, ou Security Operations Center.

Un SOC, c’est réservé aux grandes entreprises ?

Historiquement, oui. Un SOC “classique”, c’est une équipe dédiée, des analystes qui surveillent des écrans 24h/24, des outils propriétaires coûteux, et des contrats de plusieurs dizaines de milliers d’euros par an. Pour une PME de 20, 50 ou même 200 salariés, c’est hors de portée — et souvent hors de propos : vous n’avez pas besoin d’une tour de contrôle aéroportuaire pour gérer un aérodrome local.

Mais l’idée derrière un SOC n’est pas réservée aux grandes structures. L’idée, c’est simple : savoir ce qui se passe sur son système d’information, et pouvoir réagir vite si quelque chose d’anormal se produit. Ça, n’importe quelle PME peut se l’offrir, à condition de l’adapter à sa taille. C’est ce qu’on peut appeler un mini-SOC.

Passif vs proactif : la vraie ligne de fracture

La plupart des PME ont une sécurité entièrement passive :

• un antivirus qui bloque les menaces connues,
• un firewall qui filtre les flux entrants,
• parfois une sauvegarde, pas toujours testée.

Ces outils ont un point commun : ils agissent avant l’intrusion, ou pas du tout. Une fois qu’un attaquant a un pied dans le système — via un poste compromis, des identifiants volés, une faille sur un serveur exposé — ces outils ne voient plus rien. Personne ne regarde les logs. Personne ne corrèle les événements. Personne ne remarque qu’un compte se connecte à 3h du matin depuis une IP inhabituelle, ou qu’un processus tente d’accéder à des fichiers qu’il n’a jamais touchés auparavant.

C’est précisément le trou que vient combler une approche proactive : la détection. Et la détection, contrairement à ce qu’on imagine, n’est pas hors de portée d’une PME.

À quoi ressemble un mini-SOC concrètement

Pas besoin d’un SIEM à 6 chiffres par an. Il existe des outils matures, éprouvés, et déployables à l’échelle d’une PME :

Wazuh, comme socle de détection. C’est un agent qui tourne sur vos serveurs et postes critiques, qui remonte les logs, détecte les modifications de fichiers suspectes, surveille les connexions, vérifie la conformité de vos configurations par rapport à des référentiels comme le CIS ou l’ANSSI, et centralise tout ça dans un tableau de bord unique. C’est littéralement le cœur d’un SOC, packagé pour être installé en quelques heures plutôt qu’en plusieurs mois — et c’est un projet réellement libre, sans surprise de licence.

GLPI, en complément, pour le suivi des incidents. Une alerte remontée par Wazuh, ce n’est utile que si quelqu’un la traite. Plutôt que de complexifier la stack avec un outil dédié dont le modèle a évolué vers des licences payantes pour un usage en production (TheHive, par exemple, réserve aujourd’hui sa licence gratuite aux seuls usages de test et de formation — la production nécessite une licence commerciale), il est souvent plus pragmatique de s’appuyer sur un outil que la PME possède déjà ou peut déployer librement. GLPI, largement utilisé en TPE/PME pour la gestion de parc et de tickets, permet très bien de transformer une alerte Wazuh en ticket structuré et assignable : qui a regardé, qu’est-ce qui a été fait, où en est-on. Ça évite le classique “on a vu l’alerte, on l’a oubliée trois semaines” — sans ajouter une brique supplémentaire à faire financer.

Autour de ce socle, on peut ajouter selon les besoins : Fail2ban pour bloquer automatiquement les tentatives de brute-force, Suricata pour la détection réseau, ou simplement des règles de corrélation ciblées sur les usages réels de l’entreprise plutôt que sur des cas d’école.

Le principe n’est pas de tout surveiller partout — c’est irréaliste pour une petite structure. Le principe est de surveiller ce qui compte vraiment : le serveur qui héberge les données clients, le poste de la direction, le VPN d’accès distant, l’ERP.

Pourquoi c’est le bon moment pour s’y mettre

Deux choses poussent les PME à se poser la question aujourd’hui :

D’abord, la directive NIS2 commence à redescendre en cascade sur les sous-traitants et partenaires des entités régulées : même sans être directement concernée, une PME peut se retrouver à devoir démontrer un minimum de maturité en cybersécurité pour continuer à travailler avec certains donneurs d’ordre.

Ensuite, les assurances cyber demandent de plus en plus de preuves concrètes de supervision avant d’indemniser un sinistre. “On avait un antivirus” ne suffit plus comme réponse face à un assureur qui demande si l’incident a été détecté, quand, et comment il a été traité.

Ce que ça change, concrètement

Une PME avec un mini-SOC bien calibré passe d’une posture “on espère que ça ne nous arrivera pas” à une posture “si ça arrive, on le sait dans l’heure, pas dans les trois mois.” C’est cette différence de délai — appelée souvent temps de détection — qui fait toute la différence entre un incident maîtrisé et une crise. Le coût moyen d’une intrusion ne vient que rarement de l’intrusion elle-même : il vient du temps qu’elle a eu pour se propager avant d’être repérée.

Par où commencer

Un mini-SOC ne se déploie pas d’un coup. La bonne approche, c’est d’y aller par étapes :

1. Identifier les 3 à 5 systèmes réellement critiques de l’entreprise.
2. Déployer Wazuh sur ces systèmes, avec des règles adaptées à votre contexte (pas les règles par défaut telles quelles).
3. Définir qui reçoit les alertes, et ce qu’on fait quand une alerte arrive — même une procédure simple vaut mieux qu’aucune.
4. Structurer le suivi des alertes dans un outil de tickets (GLPI ou équivalent) dès que le volume dépasse ce qu’un simple tableau partagé peut absorber.

C’est un projet qui se mesure en jours de mise en place, pas en mois, à condition d’avoir quelqu’un qui sait où mettre les curseurs — parce que le vrai risque d’un SIEM mal configuré, c’est de crouler sous les faux positifs et de finir par ignorer toutes les alertes, ce qui revient au point de départ.

Vous administrez votre infrastructure en interne et vous vous demandez si un mini-SOC a du sens pour votre PME ? Discutons-en — j’accompagne les TPE/PME dans le déploiement et le calibrage d’outils comme Wazuh, adaptés à la taille et aux enjeux réels de votre structure : pas une usine à gaz, un dispositif qui correspond à ce que vous avez vraiment à protéger.

UN PROJET SIMILAIRE ?

Discutons de votre infrastructure — audit, mise en conformité, ou accompagnement digitalisation.