Dilok - stock.adobe.com

Comment SeLoger.com a choisi son EDR

Plus connu sous sa marque phare SeLoger.com, Aviv-Group vient de déployer l’EDR SentinelOne sur 3 000 postes de travail et 6 000 à 7 000 instances cloud en moyenne. Un choix d’outil qui a fait l’objet d’une étude particulièrement détaillée. L’équipe de sécurité a même testé de multiples ransomwares sur les EDR du marché.

Filiale d’Axel Springer, Aviv-Group est une holding qui détient plusieurs sites immobiliers en Europe, dont Seloger.com, le plus connu en France. Lorsque Gilles Lorrain, l’actuel CISO du groupe et responsable de l’infrastructure, prend son poste, le groupe qui s’est formé par acquisitions compte alors 6 antivirus différents, 5 fournisseurs cloud, de multiples datacenters. L’équipe sécurité décide alors de basculer sur une protection de nouvelle génération, un EDR. Se pose alors la question du choix d’une solution, parmi toutes celles qui sont disponibles sur le marché. « Nous n’avions qu’une confiance très faible dans les benchmarks des cabinets d’analystes. Donc nous avons préféré tester nous-même les solutions », résume le responsable.

« Ne cherchez pas une détection à 100 %. Personne ne détecte à 100 %, l’important est de tester quel sera l’impact d’un ransomware sur votre parc. »
Gilles LorrainCISO groupe et responsable de l’infrastructure, Aviv-Group

Pour mener à bien cette évaluation, l’équipe a sélectionné les 4 plus gros éditeurs du marché, puis a essayé de noter les qualités techniques de leurs offres, au moyen d’une énorme matrice multidisciplinaire comprenant toutes les fonctionnalités jugées pertinentes par l’équipe d’évaluation. 

« En août 2020, nous avons monté une équipe éphémère pour ce test, avec 2 personnes de l’équipe sécurité, 2 personnes venues de la production et 2 développeurs. Nous avons lancé ce démonstrateur en nous donnant 1 mois pour choisir, 3 mois pour contractualiser, régler les volets juridiques & procurement, et atteindre dès la fin du premier trimestre 70 % de couverture », raconte Gilles Lorrain.

Avec le recul, le CISO reconnaît que juger des solutions sur une énorme liste de critères était une erreur. « Installer 4 EDR sur des machines et évaluer l’ensemble de ces critères en 1 mois, cela ne passait pas. Par exemple, mesurer la RAM et le CPU consommés par l’EDR n’était pas un différenciant pertinent. Par contre, le vrai différenciant aujourd’hui, c’est le nombre des retours au Help Desk : combien d’utilisateurs vont appeler le support, car ils sont bloqués par un faux positif, etc. Nous nous sommes concentrés sur ce point, ainsi que les tests en conditions réelles. Je pense qu’il faut vraiment se concentrer sur les résultats, c’est à dire comment l’EDR me protège, et mener des tests réels pour le vérifier ».

Des malwares glanés sur le Darknet et un ransomware maison pour tester les EDR

Pour mener ces tests, l’équipe a réquisitionné une dizaine de PC, des vieux laptops initialement destinés au rebut. Ceux-ci ont été isolés du réseau sur un banc de test afin de pouvoir lancer les malwares sans risque de propagation intempestive. 

« Nous avons fait le choix de développer notre propre ransomware ; mais il existe des kits Open Source pour en générer gratuitement. Il s’agit de ransomwares qui ne sont évidemment pas malicieux, et je conseille vivement à vos équipes de le faire. »
Gilles LorrainCISO groupe et responsable de l’infrastructure, Aviv-Group

« Notre méthodologie de test était très simple : prendre des malwares connus que nous avons été chercher sur le DarkNet. Mais pour être vraiment sûrs de la validité de nos tests, nous avons voulu développer un maliciel maison », explique le CISO.

Un expert en logiciels malveillants dans l’équipe de Gilles Lorrain a alors codé un ransomware qui allait être, par nature, totalement inconnu des bases antimalware du marché. 

« Nous avons testé nos malwares et les résultats se sont avérés étonnants. Sur des malwares récents, les taux de détection atteignent 10 à 12 % seulement, avec peu de différences entre les produits testés. Nous avons trouvé plutôt étrange que des acteurs reconnus sur ce marché aient des taux de détection aussi faibles. Notre malware maison n’a pas été détecté, ce qui est normal puisque sa signature n’existait nulle part. Sous Windows, il n’y a quasiment aucune différence entre les produits. Les caractéristiques sont très proches, donc nous avons passé beaucoup de temps à tester pour rien. Ma conclusion est qu’il ne faut pas tester un EDR comme un antivirus ». 

Le CISO souligne que ces tests statiques sont peu concluants avec des EDR : c’est au moment où le malware se déclenche que l’on peut juger de sa réaction.

Les tests se sont concentrés sur la plateforme Windows qui représente l’essentiel du parc d’ordinateurs portables ainsi que beaucoup de serveurs, car historiquement SeLoger.com développe en .NET. « Nous avons aussi testé sous Linux et Mac. Tout se passait bien jusqu’à ce qu’on lance les malwares sous Linux. Nous avons obtenu 0 % de détection… Le problème fondamental avec Linux, c’est que le Kernel est différent d’une distribution à une autre. La compatibilité Red Hat ou Ubuntu ne suffit pas ; il faut vérifier la version du noyau qui est livrée avec la distribution et certaines solutions ne sont pas compatibles avec certaines versions de noyau Linux ».

Le véritable problème de cette incompatibilité, c’est qu’elle est totalement silencieuse : l’EDR s’était bien installé sur la machine, son statut est « Vert », signe qu’il fonctionne de manière nominale ; or celui-ci est incapable de détecter quoi que ce soit, ne pouvant se connecter au noyau. « Nous avons totalement exclu ce concurrent, car il n’y a rien de plus dangereux que d’avoir cette fausse sensation de sécurité ».

Le malware « maison » réussit à chiffrer 1 000 fichiers avant d’être bloqué

Le malware, développé en interne par l’équipe sécurité, étant totalement inconnu des EDR, l’équipe de test avait la certitude qu’il allait pouvoir s’exécuter sur les machines de test avant d’être bloqué par l’EDR. Ce fut le cas, mais pas avant d’avoir fait quelques dégâts. 

« Ce que nous avons mesuré, c’est le nombre de fichiers qui allaient être chiffrés avant que le ransomware ne soit bloqué par l’EDR. »
Gilles LorrainAviv-Group

« Nous savions que notre ransomware allait être effectivement lancé sur les machines de test. Ce que nous avons mesuré, c’est le nombre de fichiers qui allaient être chiffrés avant que le ransomware ne soit bloqué par l’EDR. SentinelOne est intervenu à environ 1 000 fichiers chiffrés. Cela peut sembler beaucoup, mais cela ne représente que 0,1 seconde de traitement. Ces fichiers ont pu être récupérés grâce à une fonctionnalité de SentinelOne ».

Le cloud, un terrain de jeu un peu différent pour l’EDR 

L’EDR de SentinelOne sort vainqueur des évaluations et la signature avec l’éditeur est effective en décembre 2020. Si le CISO a été surpris par la simplicité du déploiement sur les datacenters internes, son équipe va se voir confrontée à un phénomène plutôt étonnant sur les instances AWS : installé le matin, l’agent SentinelOne disparaissait systématiquement dans la journée. 

L’origine du problème est rapidement identifiée : c’est l’autoscaling qui remplace systématiquement l’OS équipé de l’EDR par une image qui en est dénuée. « On ne peut déployer l’EDR dans le cloud comme on l’installe sur un parc de PC. En tant que RSSI j’ai besoin de savoir si la machine est conforme ou pas. La solution que nous avons trouvée, c’est qu’à chaque démarrage d’une instance, nous vérifions donc que la machine est bien conforme à notre image modèle et nous vérifions que les outils SentinelOne sont bien opérationnels. Un signal est envoyé à SentinelOne à chaque installation/décommissionnement ». 

Cette fonctionnalité a été développée en interne et n’a représenté qu’une journée de travail. Elle a été intégrée à tous les pipelines de développement : tout développeur qui veut créer une application dispose d’un pipeline complet sécurisé avec SentinelOne. En outre, des informations sont remontées au niveau de l’EDR via des tags. L’équipe de triage sait à quelle équipe projet appartient l’instance, quelle est l’application qu’elle porte, son niveau de sensibilité, etc. Ces informations permettent de classer un incident beaucoup plus rapidement.

« Contrôler un antivirus, et un EDR, par API, est aujourd’hui fondamental dans un environnement cloud. Un EDR ne se gère pas seul. »
Gilles LorrainAviv-Group

Un autre critère qui n’était pas dans le tableau initial du choix de l’EDR s’est finalement montré crucial. Il s’agit de la présence d’API. « Contrôler un antivirus, et un EDR, par API, est aujourd’hui fondamental dans un environnement cloud. Un EDR ne se gère pas seul. Même avec du support, le recours à des services managés, vous restez le seul à connaître votre environnement, et plus on va vers le cloud, plus on est obligé d’intégrer les méthodes de travail, les processus, les analyses de risque directement au plus près des actifs. Sans les API, c’est impossible. Avec le recul, c’est un “Must Have” absolu ».

Autre point d’attention dans le choix d’un EDR lorsqu’on s’appuie sur une grosse infrastructure dans le cloud public, le licencing. « C’était l’une de mes plus grandes craintes. Notre infrastructure passe fréquemment de 6 000 à 20 000 voire 30 000 machines en quelques secondes, lorsqu’une publicité passe à la télévision. Le nombre de machines est alors multiplié par 4 et, automatiquement, le nombre de licences augmente d’autant. Certains éditeurs facturent ce pic du nombre de machines, cela peut coûter extrêmement cher, même si ces machines ne fonctionnent que 5 minutes… ».

Si l’EDR s’impose de plus en plus comme indispensable pour sécuriser un parc de postes de travail et de serveurs, mais aussi que tous les éditeurs semblent converger vers les mêmes fonctionnalités et vantent leurs capacités de détection hors pair, soumettre ces solutions à la réalité du terrain peut toujours produire des résultats surprenants.

Propos recueillis à l’occasion de l’édition 2022 des Assises de la sécurité

Pour approfondir sur Protection du terminal et EDR

Close