Pourquoi cet article ?
Aujourd'hui, la plupart des organisations disposent d'une solution EDR. C'est devenu un standard. Pourtant, une confusion revient régulièrement. La présence d'un agent est souvent assimilée à un niveau de sécurité. Sur le terrain, ce raccourci est rarement aussi simple.
Lorsqu’une organisation déploie un EDR, un indicateur revient presque systématiquement dans les tableaux de bord : le taux de déploiement des agents.
92%, 95 %, 98 %. Ces chiffres sont rassurants.
Ils donnent le sentiment que le parc est désormais protégé. Pourtant, au fil des missions, j’ai constaté que cet indicateur répond surtout à une question simple : des agents sont-ils installés ?
Il ne répond pas toujours à la question qui intéresse réellement une équipe sécurité : ces endpoints sont-ils effectivement sécurisés ?
NOTE TERRAIN
À retenir : la présence d’un agent EDR indique qu’une couche de protection est en place. Elle ne suffit pas à qualifier à elle seule le niveau de sécurité réel d’un endpoint.
La confusion fréquente
Dans beaucoup d’environnements, le raisonnement implicite ressemble à ceci :
Agent installé → endpoint protégé →endpoint sécurisé.
Cette logique est compréhensible, mais elle est incomplète.
Un agent déployé signifie qu’une solution est présente sur le poste. Il ne dit pas tout de la politique réellement appliquée, des exclusions en place, des fonctionnalités activées, du niveau de patching ou de la configuration globale de la machine.
C’est souvent là que naît le faux sentiment de maîtrise.
Ce qu’un EDR apporte réellement
Les EDR modernes sont devenus des plateformes extrêmement puissantes.
- Détection comportementale
- Analyse des processus
- Investigation des événements système
- Isolement d’un poste compromis
- Blocage ou remédiation de certains comportements malveillants
- Support aux opérations SOC et aux investigations
Pourtant...
Ces capacités sont essentielles dans une stratégie de défense moderne. Mais elles ne remplacent pas les autres couches de sécurité.
POINT D’ATTENTION
Un EDR peut détecter ou bloquer certains comportements malveillants. Il ne corrigera pas un système non maintenu, une application vulnérable, des privilèges locaux excessifs ou une segmentation réseau insuffisante.
Ce que le terrain montre
À plusieurs reprises, je suis intervenu sur des environnements où la console affichait un excellent niveau de couverture.
Les agents étaient présents. Les machines communiquaient correctement. Les tableaux de bord étaient globalement au vert.
Sur le papier, tout semblait fonctionner.
Puis les premières analyses commençaient.
Retour terrain
Endpoint Security • Console au vert
En creusant un peu, les premiers écarts apparaissaient rapidement : exclusions créées plusieurs années auparavant, politiques différentes entre groupes pourtant similaires, protections désactivées pour résoudre un incident puis jamais réactivées, versions d’agents hétérogènes, ou équipements oubliés dans des groupes de test.
L’EDR faisait exactement ce qu’on lui demandait. Le problème venait surtout de tout ce qui s’était construit autour de lui.
- Agent présent
- Configuration hétérogène
- Protection réelle difficile à qualifier
Dans ce type de situation, le problème n’est pas nécessairement l’outil. Le problème est de demander à une console EDR de répondre à une question pour laquelle elle n’a jamais été conçue seule.
Un EDR indique qu’une couche de protection est en place. Il ne prouve pas que tout l’endpoint est sécurisé.
Un endpoint sécurisé repose sur plusieurs couches
La sécurité d’un endpoint repose sur une superposition de contrôles. La protection endpoint en fait partie, mais elle n’est qu’un élément de l’ensemble.
- Système d’exploitation maintenu à jour
- Applications corrigées régulièrement
- Privilèges locaux maîtrisés
- Configuration durcie
- Authentification protégée
- Segmentation réseau adaptée
- Supervision et capacité de réponse
- Protection endpoint efficace et correctement configurée
Si l’une de ces couches est fragile, le niveau de sécurité réel de l’endpoint peut rester insuffisant, même si l’agent de protection est présent.
Checklist opérationnelle
Aujourd’hui, lorsque je reprends une plateforme EDR, je regarde évidemment le taux de déploiement.
Mais je passe finalement assez peu de temps sur cet indicateur. Je préfère comprendre ce qui est réellement appliqué.
Ce que je vérifie au-delà du taux de déploiement
- Les agents sont-ils installés, actifs et correctement connectés ?
- Les bonnes politiques sont-elles appliquées aux bons groupes ?
- Certaines protections sont-elles en mode audit ou détection uniquement ?
- Les exclusions existantes sont-elles toujours justifiées ?
- Les versions d’agents sont-elles homogènes et maintenues ?
- Existe-t-il des groupes de test, d’exception ou d’héritage non maîtrisés ?
- Les endpoints inactifs ou absents sont-ils identifiés ?
- Les données EDR sont-elles croisées avec l’inventaire, la VM et l’IAM ?
Conclusion
Un EDR est une brique essentielle de la sécurité moderne. Il améliore la visibilité, la détection et la capacité de réponse.
Mais il ne transforme pas automatiquement chaque endpoint en système sécurisé.
Comme souvent en cybersécurité, le véritable travail commence après le déploiement de l’outil : maintenir les politiques, revoir les exclusions, mesurer les écarts, documenter les exceptions et adapter la configuration au contexte réel de l’organisation.
NOTE TERRAIN
Ce que le terrain m’a appris : je ne me demande plus seulement combien d’agents sont installés. Finalement, la question n'est peut-être pas : Avons-nous un EDR ?
La question est plutôt :
Si un attaquant compromettait un poste demain matin, suis-je réellement satisfait du niveau de protection qui lui est appliqué aujourd'hui ?
C'est rarement la même réponse.
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.