Une organisation déploie une capacité de détection, interne ou managée. Six mois plus tard, le constat est le même : beaucoup d’alertes, peu d’effet. Le problème n’est presque jamais l’outil.
Voici ce qu’une détection ne fera jamais à votre place, quel que soit le budget.
Elle ne décidera pas d’isoler un système
Couper un serveur de production a un coût immédiat et certain. Le laisser tourner a un coût potentiel. Cet arbitrage engage l’entreprise, pas l’analyste.
La question à trancher avant l’incident : qui a le pouvoir d’isoler, à quelle heure, sans validation supplémentaire ? Sans réponse écrite, chaque incident perd deux heures en recherche du bon interlocuteur — et deux heures, dans une chronologie de rançongiciel, c’est la différence entre un poste et un domaine.
Elle ne corrigera pas la cause
Une détection signale qu’un compte de service a servi à se connecter à un serveur inhabituel. Elle ne réduira pas les privilèges de ce compte, ne le renommera pas, n’appliquera pas de rotation à son secret.
Sans équipe capable de traiter la cause, vous financez un dispositif qui vous rappelle chaque semaine un problème que personne ne corrige. C’est la principale source de lassitude sur ces projets.
Elle ne compensera pas une collecte incomplète
On ne détecte que ce qui est journalisé. Un parc dont une partie n’envoie rien produit une couverture partielle que le tableau de bord ne montre pas — l’absence d’alerte y ressemble au calme.
Le premier livrable utile d’un projet de détection n’est pas une alerte : c’est la cartographie de ce qui est couvert et de ce qui ne l’est pas. Voir ce qu’il faut collecter.
Elle ne remplacera pas l’inventaire
Une alerte sur une machine inconnue est ingérable : on ne sait ni ce qu’elle héberge, ni qui en est responsable, ni si on peut l’éteindre.
La priorisation contextuelle — qui distingue une alerte grave d’une alerte anecdotique — repose entièrement sur la connaissance des actifs. Sans inventaire, tout se vaut.
Elle ne fera pas la gestion de crise
Détecter et gérer une crise sont deux métiers. Le second suppose une cellule identifiée, des délégations écrites, des moyens de communication de secours et un porte-parole. Voir PCA, PRA et gestion de crise.
Un prestataire de détection vous préviendra. Il ne parlera pas à vos clients, ne décidera pas d’un arrêt de production et ne notifiera pas à votre place à l’autorité de contrôle.
Elle ne tiendra pas les délais réglementaires seule
Le RGPD impose 72 heures pour notifier une violation à l’autorité. NIS 2 prévoit une alerte précoce très rapide pour les incidents significatifs.
Tenir ces délais suppose de savoir qualifier l’incident, estimer le périmètre des données touchées et désigner qui signe la notification. Ce sont des décisions d’organisation, préparées à froid.
Les cinq prérequis avant de déployer
- Un inventaire des actifs, même imparfait, avec un responsable par système.
- Une cartographie de la couverture de journalisation.
- Une procédure d’escalade nommant les personnes, pas les fonctions.
- Un mandat d’isolement écrit : qui peut couper quoi, quand, sans demander.
- Une équipe ou un prestataire capable de traiter les causes, pas seulement les alertes.
Une organisation qui ne dispose d’aucun des cinq gagnera davantage à les construire qu’à souscrire un service de détection. Ce n’est pas ce qu’un prestataire a intérêt à dire, mais c’est ce que nous constatons.
Sources
- ISO/IEC 27002:2022, mesures 5.24 à 5.28 (gestion des incidents) et 8.16 (surveillance)
- Directive (UE) 2022/2555 (NIS 2), article 23 — notification d’incident
- Règlement (UE) 2016/679 (RGPD), article 33
Aller plus loin
Notre infogérance SOC commence systématiquement par ces prérequis. L’état des lieux préalable relève de l’audit 360.