Sur un serveur de production qui héberge une application métier maison, une politique de Critical System Protection (CSP) trop stricte bloque un script de sauvegarde nocturne. L’alerte remonte comme tentative d’exécution non autorisée, l’astreinte est réveillée, et le diagnostic prend une heure avant de conclure à un faux positif. Ce scénario, on le retrouve sur la plupart des déploiements où les politiques par défaut n’ont jamais été ajustées au contexte réel de l’infrastructure.
Réduire les faux positifs sur un outil de protection des systèmes critiques ne se résume pas à baisser la sensibilité des règles. Il s’agit de construire des politiques qui reflètent l’activité normale de chaque machine, puis de maintenir cette cohérence dans le temps.
Baseline d’activité : le socle que les politiques CSP doivent refléter
La première source de faux positifs, c’est l’absence de référentiel d’activité légitime. Quand on déploie une politique CSP sans avoir documenté les processus, les ports ouverts et les comptes de service qui tournent sur un système, chaque comportement normal devient suspect aux yeux de l’outil.
La CISA a souligné en 2026 que les équipes qui formalisent des baselines sur les systèmes critiques (OT, ICS, SI métiers vitaux) réduisent suffisamment le bruit pour détecter les attaques réelles plus rapidement. Ce n’est pas un simple conseil de paramétrage : une baseline formalisée est un facteur corrélé à la détection d’incidents majeurs.
Concrètement, on commence par une phase d’observation. On passe la politique en mode audit (ou monitor-only) pendant deux à quatre semaines sur chaque groupe de machines homogènes. On collecte les événements générés sans blocage, puis on trie :
- Les exécutables métier légitimes qui déclenchent des alertes de type « processus non autorisé » (scripts de maintenance, agents de supervision, tâches planifiées).
- Les connexions réseau sortantes vers des serveurs internes (bases de données, NAS, serveurs de mise à jour) signalées comme trafic anormal.
- Les modifications de fichiers système provoquées par des mises à jour applicatives ou des rotations de logs, interprétées comme des altérations suspectes.
Ce tri produit une liste blanche initiale. Elle n’est pas définitive, mais elle élimine la majorité du bruit dès l’activation du mode blocage.
Politiques CSP granulaires : cibler par rôle serveur plutôt que par parc
Appliquer une politique unique à l’ensemble du parc est la deuxième erreur classique. Un contrôleur de domaine, un serveur web et un poste d’administration n’ont pas les mêmes flux légitimes. Une règle qui interdit l’exécution de PowerShell est pertinente sur un serveur de fichiers, mais génère des dizaines d’alertes quotidiennes sur une machine d’administration.
Chaque rôle serveur mérite sa propre politique CSP. On regroupe les machines par fonction (serveurs applicatifs, bases de données, contrôleurs de domaine, postes d’exploitation OT) et on adapte les règles à chaque groupe. Sur un serveur de base de données, on autorise explicitement les binaires du moteur SQL et ses processus enfants. Sur un serveur web, on restreint les exécutables autorisés au strict nécessaire (serveur HTTP, interpréteur PHP ou Java, agent de supervision).
Cette granularité demande un effort initial de cartographie. Les retours varient sur ce point : certaines équipes y consacrent quelques jours, d’autres plusieurs semaines selon la taille du parc. L’investissement se récupère rapidement en volume d’alertes éliminées.
Gestion des exceptions sans affaiblir la détection
Créer des exceptions est inévitable, mais chaque exception mal encadrée ouvre une brèche potentielle. On applique trois principes pour garder le contrôle :
D’abord, toute exception porte sur un triplet précis : processus, chemin, compte utilisateur. Autoriser « PowerShell » globalement n’est pas une exception, c’est une désactivation de règle. Autoriser « powershell.exe lancé par le compte svc_backup depuis C:\Scripts\backup.ps1 » est une exception maîtrisée.
Ensuite, chaque exception a une date de révision. On fixe un rappel à 90 jours pour vérifier que le processus exempté existe encore et fonctionne toujours de la même manière. Les applications évoluent, les scripts changent de chemin, les comptes de service sont parfois supprimés puis recréés sous un autre nom.
Enfin, on journalise les exceptions dans un registre centralisé (un simple tableau partagé suffit au départ). Ce registre permet à un auditeur ou à un analyste SOC de comprendre pourquoi telle règle ne s’applique pas sur tel périmètre, sans fouiller dans la console CSP.
Couche de triage IA entre détection CSP et analystes SOC
Même avec des politiques bien calibrées, un volume résiduel de faux positifs persiste. Les retours d’expérience publiés en 2025-2026 montrent que les SOC qui ajoutent une couche d’IA de triage entre les flux de détection et les analystes obtiennent une baisse d’environ 30 % des faux positifs par rapport à un fonctionnement sans cette couche.
Le principe : les alertes CSP remontent vers un moteur de corrélation (SIEM ou XDR) où un modèle de machine learning évalue la probabilité qu’une alerte corresponde à un vrai incident. Le modèle se nourrit de l’historique des alertes déjà qualifiées (vrai positif ou faux positif) et pondère chaque nouvel événement en fonction du contexte (heure, machine, compte, fréquence).
Ce n’est pas un remplacement des politiques CSP. C’est un filtre supplémentaire qui priorise les alertes pour les analystes. Les règles de détection restent inchangées, seul l’ordre de traitement évolue. Un faux positif récurrent sur un serveur connu finit classé en priorité basse automatiquement, tandis qu’une alerte similaire sur une machine inhabituelle remonte en tête de file.
Maintenir les politiques CSP dans le temps : revue et mise à jour
Une politique CSP optimisée à l’instant T devient une source de faux positifs six mois plus tard si personne ne la met à jour. Les mises à jour applicatives, les migrations de serveurs et les changements d’architecture réseau modifient en permanence ce qui constitue l’activité normale.
On intègre la revue des politiques CSP dans le cycle de gestion des changements (change management). À chaque déploiement applicatif majeur ou changement d’infrastructure, on repasse les politiques concernées en mode audit le temps de valider que les nouvelles activités sont couvertes par les exceptions existantes.
Un indicateur utile : le ratio faux positifs par politique par semaine. Si ce ratio augmente brutalement sur un groupe de machines, c’est le signal qu’un changement non documenté a eu lieu. On investigue le changement avant d’ajouter une exception à l’aveugle.
La réduction des faux positifs sur un outil de protection des systèmes critiques repose sur un travail continu de documentation, de segmentation et de révision. Les politiques CSP ne sont pas un paramétrage qu’on pose une fois : elles vivent au rythme de l’infrastructure qu’elles protègent.
