Un EDR ne remplace pas un SIEM

Opérer un SIEM est perçu comme coûteux en temps et en ressources : construire et maintenir des flux de collecte, écrire et faire évoluer des règles, optimiser l’ensemble pour limiter les coûts de licences, tout cela contribue à un délai de mise en œuvre allongé pour une efficacité de détection difficile à maintenir dans la durée.

La tentation est donc grande de se limiter à une approche centrée sur les terminaux, et à se reposer sur les promesses des EDR : un déploiement rapide, peu de modifications sur les infrastructures, des capacités de réponse directement intégrées et des règles de détection pertinentes sur étagère.

Quand on part de zéro, il est évident que commencer par un EDR offrira un niveau de couverture précieux en un temps record. Mais de nombreuses limitations poussent généralement à compléter le dispositif par une collecte, centralisation et corrélation de logs :

• Couverture du parc : l’EDR ne sera déployé que sur les actifs connus et managés centralement. Des systèmes isolés ou sur lesquels les outils de gestion de parc sont défaillants peuvent rester invisibles.
• Couverture technologique : les attaquants se refugient de plus en plus sur des systèmes Unix/Linux, des équipements réseau ou autres appliances exotiques. Comme il n’y a pas encore d’EDR pour routeurs, la seule possibilité pour surveiller ces équipements reste la collecte de leurs logs ou de traces réseau.
• Scénarios applicatifs : non couvrables
• Corrélation entre équipements : une authentification ratée sur un serveur n’a généralement rien de suspect. Une authentification ratée sur 150 équipements et réussie sur 5 est possiblement une action de latéralisation. Un EDR applique ses régles à l’échelle d’un actif et ne pourra donc pas identifier ce comportement.
• Corrélation entre sources : faire le lien entre une réception de mail, une alerte mineure de l’EDR sur une chaine d’exécution suspecte et la connexion via le proxy à un domaine jamais vu dans tout l’historique ne pourra se faire qu’avec un SIEM (et beaucoup d’efforts !)
• Centralisation : les éléments de télémétrie d’un EDR restent généralement stockés sur l’actif supervisé, seules les alertes remontent dans le serveur central. Un attaquant pourrait donc effacer des signaux faibles utiles en cas d’investigation (n’avoir ne serait-ce que les commandline des processus lancés à l’échelle d’un SI dans son SIEM change généralement la vie en réponse à incidents)
• Rétention : la télémétrie des EDR, très précise et verbeuse, ne peut être gardée généralement que quelques semaines. C’est souvent un peu trop court pour investiguer une attaque discrète.

En fonction du niveau de détection qu’on souhaite atteindre, la corrélation de logs reste encore aujourd’hui un mécanisme indispensable.