Comment gérer les faux positifs au démarrage d'un SOC ?
Au démarrage d'un SOC, des activités légitimes déclenchent des alertes. Documenter, ajuster les règles, tracer : comment gérer les faux positifs.
Pour gérer les faux positifs au démarrage d’un SOC, il faut documenter dès le départ les outils et usages normaux du client, traiter chaque alerte injustifiée avec le SOC, ajuster la règle au plus juste (une machine, un compte, un outil) et garder une trace de chaque exception. Une revue planifiée après les premières semaines permet de consolider ces réglages.
Cet article fait partie de notre série sur la mise en œuvre d’un SOC managé. Pour la démarche complète, voir Comment mettre en place un SOC managé ?.
Pourquoi les faux positifs sont plus nombreux au démarrage
Un faux positif est une alerte déclenchée par une activité légitime. Au démarrage, le SOC ne connaît pas encore l’environnement du client. Plusieurs activités normales ressemblent à des comportements d’attaquant :
- les outils d’administration à distance utilisés par l’infogérant ;
- les scripts PowerShell d’automatisation ou d’inventaire ;
- les logiciels métier peu répandus, parfois anciens ou non signés ;
- les scanners de vulnérabilités et outils de sauvegarde, qui parcourent beaucoup de fichiers ;
- les connexions depuis l’étranger d’un collaborateur en déplacement.
Rien de cela n’est anormal pour le client. Mais une règle de détection ne peut pas le deviner : il faut le lui apprendre. Pour ce que le SOC regarde exactement, voir Que surveille un SOC managé ?.
Étape 1 : décrire l’existant avant la mise en service
La meilleure façon de réduire les faux positifs est de les anticiper. Au démarrage, l’infogérant transmet au SOC :
- la liste des outils d’administration et de sauvegarde utilisés ;
- les logiciels métier et serveurs sensibles ;
- les comptes de service et comptes à privilèges ;
- les pays depuis lesquels les collaborateurs se connectent habituellement ;
- les tâches planifiées connues (sauvegardes nocturnes, mises à jour).
Ces éléments font partie des informations à fournir au SOC au démarrage.
Étape 2 : traiter chaque alerte injustifiée
Quand une alerte s’avère liée à une activité légitime, le SOC et l’infogérant peuvent suivre un circuit simple :
- le SOC qualifie l’alerte et demande confirmation si le contexte manque ;
- l’infogérant confirme que l’activité est attendue, et par qui elle est faite ;
- le SOC ajuste la détection ;
- l’exception est notée, avec sa raison, sa date et la personne qui l’a validée.
Ce circuit évite deux dérives : laisser le bruit s’installer, ou créer des exceptions à la hâte que personne ne sait plus justifier.
Étape 3 : ajuster au plus juste
Une exception trop large crée un angle mort. La règle est simple : exclure le moins possible.
| Exception trop large | Exception ajustée |
|---|---|
| Ignorer tous les scripts PowerShell | Autoriser un script précis, sur les machines prévues |
| Ignorer un outil d’administration partout | L’autoriser depuis les postes de l’infogérant seulement |
| Ignorer les connexions depuis un pays | Les autoriser pour un compte, sur une période |
| Désactiver une règle | Exclure un dossier ou une machine identifiés |
Un attaquant utilise souvent les mêmes outils que les administrateurs. Une exception bien ciblée garde la détection sur le reste du parc.
Étape 4 : faire une revue après quelques semaines
Une fois la première vague passée, une revue avec le SOC permet de faire le point : alertes les plus fréquentes, exceptions ajoutées, questions restées ouvertes. C’est aussi le moment de vérifier que les exceptions prises dans l’urgence sont toujours justifiées.
Cette logique d’amélioration continue, où chaque alerte et chaque incident nourrissent les réglages suivants, est celle que recommande le NIST dans sa publication SP 800-61 révision 3 sur la réponse aux incidents.
Étape 5 : prévenir le SOC des changements
Les faux positifs reviennent à chaque changement notable : nouvel outil, migration vers le cloud, rachat d’une société, campagne de tests d’intrusion. Prévenir le SOC à l’avance lui permet de qualifier plus vite les alertes et d’éviter des actions de confinement inutiles.
Le bon objectif
L’objectif n’est pas zéro alerte : un SOC qui ne remonte plus rien a peut-être des réglages trop larges. L’objectif est que chaque alerte transmise à l’infogérant mérite d’être lue. Gérer les faux positifs fait partie du démarrage ; les ignorer fait partie des erreurs à éviter lors de la mise en place d’un SOC managé.
Faire le point avec un expert
Vos alertes SOC sont trop nombreuses ou trop peu lues ? 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
Un faux positif est-il le signe d'un mauvais SOC ?
Non. Quelques faux positifs au démarrage sont normaux : aucune règle de détection ne connaît d'avance les usages propres à chaque client. Ce qui compte, c'est la vitesse à laquelle ils sont traités et ne se reproduisent plus.
Qui décide d'ajouter une exception ?
Le SOC propose, l'infogérant confirme que l'activité est légitime, et l'exception est documentée. Une exception sans validation ni trace est un risque.
Faut-il désactiver une règle qui génère trop d'alertes ?
Rarement en entier. Mieux vaut l'affiner : exclure une machine, un compte ou un chemin précis, plutôt que perdre la détection pour tout le parc.
Les faux positifs reviennent-ils après le démarrage ?
Oui, à chaque changement notable : nouvel outil, migration, nouvelle filiale. Prévenir le SOC à l'avance évite une partie des alertes. Voir Comment construire une procédure d'escalade avec un SOC ?.
Cet article fournit des informations générales à titre indicatif. Il ne constitue ni un conseil juridique, ni un engagement contractuel de Cyna : les conditions de service sont celles du contrat conclu via votre infogérant partenaire. Pour toute question réglementaire, rapprochez-vous de votre conseil juridique.