Pourquoi cet article ?
Lorsque je reprends une plateforme EDR existante, il y a un élément que je consulte presque systématiquement avant même les tableaux de bord ou les détections.
Les exclusions.
Pourtant, c’est rarement le premier sujet évoqué lorsqu’on parle d’Endpoint Detection & Response.
Les discussions portent plus souvent sur les menaces détectées, les politiques de protection ou les performances de la solution.
Les exclusions, elles, restent discrètes.
Et c’est précisément ce qui les rend intéressantes.
NOTE TERRAIN
À retenir : une exclusion est souvent créée pour résoudre un problème légitime. Le risque apparaît lorsqu’elle continue d’exister plusieurs années après la disparition du problème initial.
Pourquoi les exclusions existent
Toutes les exclusions ne sont pas mauvaises.
Au contraire.
Dans certaines situations, elles sont parfaitement justifiées.
- Une application métier provoquant un faux positif
- Un pilote matériel spécifique
- Un logiciel de sauvegarde
- Un moteur de base de données
- Un outil d’administration
- Une application industrielle
L’objectif est simple : permettre au système de fonctionner correctement tout en limitant les impacts opérationnels.
Créer une exclusion n’est donc pas une erreur.
C’est une décision technique qui répond à un besoin précis.
Le problème n’est pas l’exclusion
Le véritable problème apparaît avec le temps.
Une exclusion est souvent créée dans un contexte précis.
Puis ce contexte évolue.
- L’application est mise à jour
- Le faux positif est corrigé par l’éditeur
- Le serveur est remplacé
- Le logiciel est supprimé
Mais l’exclusion, elle, reste présente.
Parfois pendant plusieurs années.
Le problème n’est pas forcément qu’une exclusion existe. Le problème est de ne plus savoir pourquoi elle existe encore.
Ce que je retrouve régulièrement sur le terrain
Retour terrain
Endpoint Security • Exclusions • Héritage
Lors de plusieurs reprises de plateformes EDR, j’ai retrouvé des exclusions dont personne ne connaissait encore l’origine.
Certaines avaient été créées plusieurs années auparavant.
D’autres étaient documentées comme temporaires.
Certaines concernaient des applications qui n’existaient plus.
Toutes avaient un point commun : personne n’était capable d’expliquer pourquoi elles étaient toujours actives.
Ce type de situation n’indique pas nécessairement qu’une plateforme est mal administrée.
Il montre surtout qu’une décision ponctuelle peut devenir un objet permanent lorsqu’aucun processus n’est prévu pour la réexaminer.
Pourquoi les exclusions vieillissent mal
Contrairement aux politiques de protection, les exclusions font rarement l’objet d’une revue régulière.
Elles sont souvent créées rapidement pour résoudre un incident de production.
Puis elles disparaissent progressivement du radar.
- Le temps passe
- Les équipes changent
- Les projets évoluent
- La documentation n’est plus à jour
Et les exclusions deviennent un héritage technique.
Le danger n’est pas forcément leur nombre.
Le danger est de ne plus connaître leur justification.
POINT D’ATTENTION
Une exclusion ne constitue pas automatiquement une faiblesse de sécurité. En revanche, une exclusion dont personne ne connaît l’origine mérite probablement d’être revue.
Ce que je vérifie systématiquement
Lorsque je reprends une plateforme EDR, je me pose toujours les mêmes questions.
- Les exclusions sont-elles documentées ?
- Existe-t-il un propriétaire identifié ?
- Une justification métier est-elle disponible ?
- Une date de création est-elle connue ?
- Le périmètre est-il le plus restreint possible ?
- Cette exclusion est-elle toujours nécessaire aujourd’hui ?
- Une revue périodique est-elle organisée ?
Une exclusion ancienne n’est pas nécessairement dangereuse. Une exclusion ancienne, non documentée et sans propriétaire est en revanche impossible à qualifier correctement.
Checklist opérationnelle
Avant de conserver une exclusion existante, je trouve utile de vérifier quelques éléments simples.
Revoir une exclusion EDR existante
- Confirmer que le besoin initial est toujours présent.
- Vérifier que l’application concernée existe encore.
- Tester la dernière version de l’application sans l’exclusion.
- Limiter le périmètre de l’exclusion au strict nécessaire.
- Documenter précisément sa justification.
- Identifier un propriétaire technique ou métier.
- Définir une date de prochaine revue.
Conclusion
Les exclusions font partie du fonctionnement normal d’une plateforme EDR.
Chercher à les supprimer toutes n’aurait aucun sens.
En revanche, les considérer comme définitives constitue souvent une erreur.
Comme beaucoup d’éléments de sécurité, une exclusion doit vivre avec le reste de la plateforme.
Elle mérite d’être revue, documentée et remise en question régulièrement.
Parce qu’au final, le risque n’est pas l’exclusion. Le risque est d’oublier pourquoi elle existe.
NOTE TERRAIN
Ce que le terrain m’a appris : lorsqu’une exclusion est ancienne et que personne n’est capable d’expliquer pourquoi elle existe encore, je considère qu’elle mérite d’être réévaluée.
Non pas parce qu’elle est forcément dangereuse, mais parce qu’en cybersécurité, une décision dont on a perdu le contexte mérite toujours d’être revisitée.
POINT D’ATTENTION
Cette Note de terrain est inspirée de situations rencontrées au cours de différentes missions. Les exemples présentés ont été volontairement anonymisés et généralisés afin de préserver la confidentialité des organisations concernées.