Les EDR ou le débat conceptuel

Ne vous posez pas la question de savoir s’il faut isoler vos VLAN internes avec un firewall, il le faut.
Ne vous posez pas la question de la sécurisation de vos comptes à privilèges, de vos sauvegardes, de vos accès fournisseurs.

Mais pour ce qui est des EDR (Endpoints Detection and Response), c’est une autre histoire. Précision : la différence entre EDR, XDR et SIEM n’est pas l’objet du présent article. Pas certain d’ailleurs que tout le monde y comprenne la même chose. Lors de réunions de RSSI (il en faut forcément), si le débat semblait tranché il y a peu, c’est beaucoup plus nuancé maintenant, et le sujet est rendu plus flou par les évolutions des antimalwares sur les endpoints, qui finissent peu ou prou par embarquer certaines fonctionnalités des EDR.

Mais ce qui interroge surtout, c’est le concept. Un antimalware, une fois que vous avez compris la notion de signature (hash) et d’heuristique (comportement), vous avez fait le tour de la question. On bloque des exécutables dont le hash est dans une base de signatures ou en cas de comportement anormal (genre chiffrer des tonnes de fichiers sur un partage). Et, dans les deux cas, on est en mode blocage et pas écoute.

Pour un EDR, l’idée est de collecter des événements à différents endroits du SI pour détecter des signaux d’attaque. Il s’agit de la déclinaison plus ou moins affichée du concept de Mitre Att&ck[1], selon lequel les modes d’attaque suivent des patterns à peu près identiques, voire déclinés selon les équipes de hackers.

Sauf qu’il y a plusieurs éléments largement sujets à discussion. Tout d’abord le mode écoute/blocage : on est dans le même registre d’outils que les sondes IDS, et que ceux qui ont mis la leur en mode blocage lèvent la main SVP ! Bref, les EDR sont souvent en mode écoute à cause du sempiternel souci de la présence de faux positifs. Ensuite, un EDR est supposé être connecté à un centre d’analyse en temps réel (SOC), et, sauf à externaliser, quasi aucun CHU en France ne dispose de budget pour un SOC interne, ce qui d’ailleurs ne réglerait pas la question de la remédiation qui devrait aussi se dérouler en 24-365, bon courage…

En dehors du fait que j’attends toujours que l’on m’explique pourquoi il faudrait déployer un outil de plus sur les endpoints (qui disposent déjà tous d’un AV, sans même parler du coût des licences), la dernière question que j’ai posée à mon éditeur d’AV est la suivante : Pourquoi déployer un EDR sur tous les endpoints alors que, par définition, tout attaquant devra passer par des points de passage obligés (AD, console VMware, serveur de sauvegarde, etc., cf. Mitre) ? Et donc qu’il suffit de déployer un EDR sur ces assets névralgiques et basta ? Les réponses ont été plutôt évasives, du genre « en déployant sur tous les endpoints on peut corréler plus d’événements », sauf que quand je demande une preuve, une étude, un schéma technique : bernique et peau de balle. Même une tentative d’élévation locale de privilèges sur un endpoint se verra sur l’AD, et encore plus si cette tentative se déroule sur un serveur (à moins que vos comptes admin sur vos serveurs soient locaux, mais là on ne peut rien pour vous).

À ce stade, vous avez deux solutions : soit vous vous dites « autant prendre le max » et n’avez aucun souci de chéquier, soit vous vous dites qu’argumenter auprès de la DAF va être compliqué et vous prévoyez de passer sur la version minimale. Cela étant, à vouloir pousser à fond des solutions sans preuves réelles et objectivées de leur efficience, certains fournisseurs sont en train de scier méthodiquement la branche de l’arbre.

[1] https://attack.mitre.org/matrices/enterprise/ 

L'auteur 

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.