Quelles erreurs éviter lors de la mise en place d'un SOC managé ?

Les erreurs les plus courantes lors de la mise en place d’un SOC managé sont organisationnelles : un périmètre incomplet, une procédure d’escalade floue, des contacts d’astreinte qui ne répondent pas, des faux positifs non traités et un client mal informé de ce qui change. Elles s’évitent en préparant le démarrage, puis en planifiant une revue après les premières semaines.

Cet article complète notre guide Comment mettre en place un SOC managé ?, qui décrit la démarche étape par étape.

Erreur 1 : raccorder une partie du parc et l’oublier

Un SOC ne surveille que ce qui lui est raccordé. Un serveur ancien, un poste de direction resté sur un autre antivirus, un locataire Microsoft 365 secondaire : chaque oubli devient un angle mort, souvent celui qu’un attaquant trouve en premier.

Comment l’éviter : partir d’un inventaire à jour, comparer le nombre d’agents remontés au nombre de machines réelles, et suivre l’écart jusqu’à ce qu’il soit nul. Les éléments à préparer sont listés dans Quelles informations fournir au SOC au démarrage ?.

Erreur 2 : négliger les sources autres que les postes

L’EDR est la base, mais beaucoup d’attaques passent par les identités : vol de mot de passe, connexion depuis un pays inhabituel, règle de transfert de messagerie. Ne raccorder que les postes revient à ignorer une partie du chemin de l’attaquant.

Comment l’éviter : raccorder dès le départ la messagerie et la suite collaborative (Microsoft 365 ou Google Workspace) et, si possible, le pare-feu. Chez Cyna, des connecteurs sont prêts pour Microsoft 365, Google Workspace et les pare-feux Stormshield et Fortinet. Voir aussi Faut-il un EDR pour un SOC managé ?.

Erreur 3 : une procédure d’escalade floue

Le SOC détecte une attaque à 2 heures du matin. Qui appelle-t-il ? A-t-il le droit d’isoler le poste ? Si ces questions n’ont pas de réponse écrite, le confinement attend, et l’attaque progresse.

Comment l’éviter : écrire avant la mise en service les niveaux de gravité, les actions autorisées sans accord préalable et la chaîne de contacts, puis la tester. La méthode est détaillée dans Comment construire une procédure d’escalade avec un SOC ?.

Erreur 4 : des contacts d’astreinte qui ne répondent pas

Un numéro générique qui bascule sur messagerie la nuit, un contact parti de l’entreprise, une liste jamais mise à jour : la procédure existe, mais personne ne décroche.

Comment l’éviter : prévoir un titulaire et un suppléant, vérifier les numéros lors d’un exercice, et rendre la mise à jour des contacts obligatoire à chaque changement d’équipe.

Erreur 5 : ignorer les faux positifs du démarrage

Les premières semaines, le SOC découvre l’environnement : outils d’administration, scripts internes, logiciels métier peu courants. Certaines activités légitimes déclenchent des alertes. Si personne ne les traite, les équipes se lassent et finissent par ne plus lire les alertes.

Comment l’éviter : documenter les outils et usages normaux dès le démarrage, et planifier une revue d’ajustement avec le SOC. Voir Comment gérer les faux positifs au démarrage d’un SOC ?.

Erreur 6 : ne pas expliquer le changement au client

Le client final voit un poste isolé ou une session coupée sans prévenir, et appelle le support pour une « panne ». Ou il croit qu’avec un SOC, plus rien ne peut arriver.

Comment l’éviter : présenter au client ce que fait le SOC, ce qu’il ne fait pas, ce qui peut se produire en cas d’alerte et qui le préviendra. Un SOC managé ne remplace ni les sauvegardes, ni les correctifs, ni la sensibilisation des utilisateurs. Pour une entité soumise à NIS2, ces mesures font partie d’un ensemble plus large défini à l’article 21 de la directive.

Erreur 7 : ne jamais relire les rapports

Les rapports mensuels d’activité et de vulnérabilités ne servent que s’ils sont lus. Les vulnérabilités signalées et non corrigées restent ouvertes, et le client ne voit pas la valeur du service.

Comment l’éviter : prévoir un point régulier, interne puis avec le client, pour passer en revue les incidents traités et les vulnérabilités à corriger. Chez Cyna, ces rapports sont exportables en CSV ou en PDF, en marque blanche, pour que l’infogérant les présente à ses clients.

En résumé

Erreur	Parade
Parc partiellement raccordé	Inventaire et suivi de l’écart
Postes seulement	Identités, messagerie, pare-feu dès le départ
Escalade floue	Procédure écrite et testée
Contacts injoignables	Titulaire, suppléant, exercice
Faux positifs ignorés	Revue d’ajustement planifiée
Client non informé	Présentation du service et de ses limites
Rapports non lus	Point régulier avec le client

Faire le point avec un expert

Vous préparez la mise en place d’un SOC managé et voulez éviter ces écueils ? Si vous travaillez avec un infogérant partenaire de Cyna, parlez-en d’abord avec lui. Vous êtes infogérant, ou vous n’avez pas encore de partenaire ? Contactez-nous.

Questions fréquentes

Peut-on démarrer un SOC managé sur une partie du parc seulement ?

Oui, pour un pilote. Mais il faut l'assumer comme tel, avec une date pour étendre au reste du parc, et le dire au client : les machines non couvertes ne sont pas surveillées.

Combien de temps dure la phase d'ajustement ?

Elle dépend de la taille et de la diversité du parc. L'important est de planifier une revue avec le SOC après les premières semaines. Voir Comment gérer les faux positifs au démarrage d'un SOC ?.

Faut-il prévenir les utilisateurs finaux du client ?

Il est utile de leur expliquer qu'un poste peut être isolé ou une session coupée en cas d'alerte, et qui appeler dans ce cas. Cela évite qu'une action de confinement soit prise pour une panne.