Présentation des EDR et cas pratiques sur de grands parcs

MISC

n°

116

juillet 2021

Par

Ledoux (Mysterie) Florian

Malware

Sécurité système

Tag(s)

EDR

SOC

CSIRT

Réduire le temps de détection d'une attaque et sa remédiation est un enjeu crucial. Une technologie apportant de nouvelles solutions fait parler d'elle, son nom : EDR pour Endpoint Detection and Response. Mais qu'est-ce qu'un EDR, comment l'évaluer, le déployer ? Comment se démarque-t-il des autres solutions du marché ?

Avec le recours massif des entreprises au télétravail, leur exposition aux attaques informatiques s'étend. De plus, les menaces récentes rivalisent d'ingéniosité comme par exemple Emotet en 2020 [1]. Elles sont plus complexes à détecter, automatisées et servent parfois de plateforme de déploiement pour de potentiels ransomwares. Certains équipements de sécurité ne sont plus efficaces ou n'offrent pas de solution de réponse rapide. Une nécessité de détection et de remédiation rapide émerge pour éviter les situations critiques.

1. Qu'est-ce qu'un EDR ?

Pour répondre à cette question, il faut commencer par le E de EDR désignant « Endpoint ». Un endpoint ou terminal représente le poste de travail, serveur ou smartphone intégré au système d'information à protéger. Sur chaque terminal un agent est déployé. Son rôle est de récupérer des événements en temps réel : processus, connexions, utilisateurs connectés, métadonnées de fichiers, etc. Ces événements sont analysés par l'agent et envoyés à un serveur de détection appartenant à l'éditeur de la solution EDR. C'est ici qu'arrive le D pour « Detection ». Tous les événements du parc étant centralisés, la détection peut se faire sur des IOC « Indicator Of Compromise » classiques de type hash, IP, mais pas seulement. Des algorithmes plus ou moins complexes généralement basés sur du machine learning permettent de trouver des comportements déviants. Reste le R pour « Response ». L'agent ne se contente pas d'envoyer des données. Il peut recevoir des ordres de réponse à incident comme l'isolation d'un poste, le blocage d'une IP, d'un binaire. Ces actes unifiés et simplifiés pour l'utilisateur sont effectifs sur la globalité du parc en quelques minutes, ils sont même parfois réalisés automatiquement. L'aspect détection et réponse est au plus près des terminaux. Les attaques complexes peuvent être déjouées par le serveur de détection.

Autour du terme EDR gravitent beaucoup d'acronymes : EPP, UES, MDR, XDR. Rien de bien complexe, pour MDR il s'agit de « Managed Detection and Response ». Dans ce cas, l'éditeur ou une société externe gère le service à votre place (configuration, cycle de vie, traitement des alertes...). Le terme EPP « Endpoint Protection Platform » est généralement employé par les éditeurs d'antivirus nextgen étendant leur offre. Ils proposent des sécurités anti-ransomware, blocage de « fileless » malware, etc. Ensuite, l'UES pour « Unified Endpoint Security » définit une offre globale couvrant tout type de terminal même la partie mobile et tablette désignée MTD pour « Mobile Threat Defense ». Enfin, X pour « eXtended » : en plus des évènements bas niveau collectés via l’agent, les alertes de vos équipements de sécurité (pare-feu, proxy, DLP) sont elles aussi collectées afin d'enrichir la détection.

2. Quel scénario d'attaque l'EDR détecte-t-il par rapport aux solutions plus classiques ?

Impossible d'être exhaustif dans les scénarios d'attaques exposés, les plus impactant seront privilégiés ici. Les attaquants innovent, se faufilent de mieux en mieux à travers les bases de signatures. Le polymorphisme est privilégié dans le but de contourner temporairement les solutions qui se basent sur des IOC classiques. Soit via le packing de binaire pour les signatures se basant sur les hashs. Soit via des techniques de DNS fronting ou fast flux pour dissimuler les connexions réseaux.

Dans le cas d'Emotet [1], tout commence par un courriel d’hameçonnage. La victime reçoit un mail d'un destinataire externe compromis. Le mail contient une ancienne conversation légitime et une pièce jointe malveillante. La victime ouvre le document attaché, et parfois active la macro. Dans ce cas, celle-ci exécute différents scripts généralement via des utilitaires système existants comme powershell pour minimiser l'utilisation du disque. Cette attaque se base sur les lolbas [2] (Living Off The Land Binaries and Scripts). Toute l'attaque est automatisée, chaque script et binaire utilisé sont en partie générés aléatoirement, le but étant de contourner toute détection basée sur une signature. Il faudra généralement quelques heures voire jours pour que l'Antivirus ou l'IDS réactualise sa base de signature et finisse par détecter la menace. Entre-temps Emotet a déjà muté plusieurs fois. L'attaquant, quant à lui, a l'information du nombre de machines infectées. Si elles sont assez nombreuses, un ransomware est déployé.

L’EDR de son côté surveille tous les processus et leurs enchaînements. Outlook lance Word qui, lui-même, exécute un script powershell avec une ligne de commandes encodée. Cela va générer une alerte (ou même un blocage). Car cet événement est rare sur le parc et le risque de phishing, avec cet enchaînement, est élevé. Dans le cas où ce script n'est pas détecté, les actions de persistance sur le poste auront de grandes chances de générer une alerte. Que ce soit via une tâche planifiée ou une clef de registre, là encore le comportement suspect sera détecté.

Un autre cas est celui d’un poste utilisé dans le cadre du télétravail ou encore en entreprise, connecté à Internet d'une façon détournée. Alors certains flux réseaux ne passeront pas forcément par le VPN ou le pare-feu en place là où l'EDR, étant basé sur le terminal, voit passer tous les flux, peu importe la méthode de connexion, limitant les angles morts.

Comme évoqué précédemment, un scénario demandant une détection et réponse rapide est le ransomware. Encore une fois, ce type de malware peut être révélé par son comportement. Par exemple, une surveillance des écritures sur le disque est effectuée pour chaque processus. Leur récurrence sur le parc ainsi que leur entropie sont analysées. L'EDR contrôle également les changements de configuration comme la désactivation du chiffrement, la modification de snapshots ou backup d'un disque. Une autre stratégie proche du « honeypot » est le dépôt de documents « canaries » à différents endroits du système de fichiers. Si plusieurs de ces documents sont modifiés alors le processus fautif sera bloqué. Ces documents peuvent être cachés de l'utilisateur. Si une suppression manuelle survient, ce comportement moins déviant ne lèvera pas d'alertes. Une option de « rollback » ou remédiation est même parfois proposée sur certains produits.

3. Apport de l'EDR selon les utilisateurs

Selon les profils, cette nouvelle solution peut susciter différents attraits. Les préoccupations d'un analyste SOC ou d'un administrateur système sont différentes.

3.1 Utilisateur orienté MCO (Administrateur système)

L'adoption d'une solution peut être facilitée par une interface simple d'utilisation, fournissant des indicateurs probants. Un autre facteur est le niveau d'expertise ainsi que le coût nécessaire pour le maintien en condition opérationnelle (traité au chapitre 5). Son déploiement peut parfois remplacer d'autres solutions de sécurité désuètes. Une vigilance particulière est nécessaire pour surveiller l'impact de l'EDR sur les terminaux. Les performances varient en fonction du produit et de l'activité du poste, avec en moyenne :

Entre 1 et 5% de cycle CPU ;
Entre 200 et 400 Mo de consommation de mémoire vive ;
Entre 10 et 20 Mo échangés par jour sur le réseau.

Un exemple : le CPU ne dépasse pas 5% sauf dans le cas d'un scan de fichiers. Généralement, ces scans sont lancés quand l'utilisateur est inactif ou sur des heures bien définies.

3.2 Utilisateur orienté détection (SOC)

Pour un analyste habitué au traitement d'alertes sécurités, de nouvelles innovations permettent un traitement plus efficace des incidents. L'investigation d'une alerte est simplifiée par l'agrégation des différents événements bas niveau collectés liés à celle-ci. Donnant la possibilité de faire du « hunting » soit via les éléments de l'alerte ou dans une interface dédiée permettant d'investiguer des éléments spécifiques (hash, IP, ligne de commandes). La notion de « process tree » est aussi d'une grande aide, permettant de visualiser l'enchaînement des processus père et fils.

Figure 1

Cela permet ainsi une levée de doute rapide à l'échelle de tout le parc. L'extraction d'une liste d'utilisateurs ou de machines impactées par une attaque se fait en quelques clics.

Une autre capacité intéressante est celle du regroupement d'alertes pour ne pas noyer l'analyste sous les notifications. Ainsi, une infection se produit sur plusieurs machines, une seule alerte est levée et la liste des machines touchées est agrégée dynamiquement dans l'alerte. Une « timeline » peut parfois aussi être associée à l'alerte pour suivre le moment précis des différentes infections et de la réponse.

Une composante vitale pour le « Security Operation Center » est la bonne intégration de l'EDR à une solution de type SIEM (Security Information and Event Management). Dans le même ordre d'idée, l'intégration à un SOAR (Security Orchestration, Automation and Response) aide grandement dans l'automatisation et donc la rapidité de traitement d'un incident. L'existence d'une API (Application Programming Interface) pour s'interfacer facilement à cet écosystème est un atout primordial. L'efficacité de l'EDR est également grandement liée à son intégration dans les process et l'expertise des équipes qui l'opèrent. Ainsi, la configuration du produit aide grandement à réduire les faux positifs et les blocages inopinés. Comme sur un antivirus, la notion d'exclusion est présente. Il est parfois possible d'exclure un comportement complexe ou au contraire d'ajouter des règles de détection sur-mesure. Dans le cas d'un déploiement cloud, les serveurs de détection sont calibrés dynamiquement par l'éditeur via différents data lake, algorithme de machine learning, intégration CTI (Cyber threat intelligence) propriétaire. Ces outils lui permettent d’avoir des détections pertinentes sur la globalité de leurs clients.

3.3 Utilisateur orienté réponse (CSIRT)

Pour une équipe de réponse à incident, la préoccupation première va être l'installation facile et rapide (cf. chapitre 5) afin de contenir la menace. Un poste infecté peut potentiellement leurrer la solution, d'où le besoin d'avoir un agent qui s'intègre profondément au système d'exploitation. Les solutions offrant du « multi tenant » donnent la possibilité de gérer rapidement plusieurs interventions. Les préoccupations et besoins du CSIRT sont communs avec le SOC, gravitant autour de la détection et l'intégration rapide d'IOC ou de règles de détection sur mesure.

Le besoin autour des actions de réponse sera plus prononcé, elles peuvent être parfois automatisées. On y retrouve les classiques : mise en quarantaine, suspension de processus, mais aussi une partie prévention. C'est-à-dire le blocage d'un élément suspect comme une IP sur l'ensemble du parc. L'isolation d'un poste est généralement une fonction incluse par défaut. Dans ce cas, le poste ne communique plus qu'avec le serveur de détection. Ce dernier offre parfois la possibilité, après isolation, d'avoir un shell interactif ou de lancer des actions d'investigation : analyse de RAM, de la chaîne de démarrage, DFIR ORC [3].

La recherche de la cause première est primordiale en réponse à incident pour ne pas remonter une infrastructure avec les mêmes failles ou chemins d'attaque ayant permis à un attaquant de rentrer. Les fonctions permettant des analyses forensiques intégrées dans un EDR sont un plus appréciable.

4. Différentes façons d'évaluer un EDR

Les éditeurs sont nombreux pour un marché en plein essor. Pour se faire un avis, certains privilégient le retour d'expérience terrain de différents RSSI. D'autres préfèrent le magic quadrant du Gartner ou le Forrester. Un organisme, le MITRE [4], propose d'évaluer la détection de différents éditeurs via une attaque grandeur nature souvent basée sur un APT (Advanced Persistent Threat). Ces tests sont réalisés chaque année permettant ainsi de suivre l'évolution des éditeurs. Ces résultats sont basés sur un référentiel, le MITRE ATT&CK regroupant sous forme de matrices les techniques d'attaque (exemple : scan de ports) et les tactiques (exemple : reconnaissance). Une tactique est constituée de différentes techniques. Chaque tactique représente les phases d'une attaque, représentant une killchain, par exemple : Reconnaissance, Initial Access, Lateral Movement, Exfiltration.

Figure 2

L'évaluation se base sur le nombre de techniques d'attaque détectées, si elles sont contextualisées, sur quelles données se base la détection. Il est à noter que la participation à l'évaluation MITRE ou au Gartner peut avoir un coût d'entrée élevé. Ainsi, la liste des éditeurs représentés n'est pas exhaustive. Pour l'évaluation du MITRE, il n'y a pas non plus de notion de faux positifs, difficile donc de différencier un produit qui détecte au bon moment, d'un produit trop sensible qui génère beaucoup d’alertes non pertinentes.

Se renseigner sur l'historique de l'éditeur peut donner d'autres perspectives. Est-il un « pure player » centré sur une seule activité : le développement d’un EDR ? Ou bien une société d'antivirus ajoutant quelques capacités d'EPP ou d'EDR à sa solution existante ?

4.1 Différentes certifications

Comme tout éditeur de sécurité, ces solutions sont certifiées. Une compliance au GDPR et certification SOC2 permet de s'assurer que vos données sont en sécurité même dans le cas d'un fournisseur SaaS (Software As A Service). Pour les produits français, l’ANSSI a mis en place une démarche de certification de sécurité de premier niveau (CSPN) permettant d’obtenir des informations sur le niveau de sécurité des produits audités.

Des audits de code et de configuration doivent être réalisés pour ne pas rajouter une surface d'attaque sur les terminaux. De plus en plus d'éditeurs choisissent aussi une base en langage Rust pour éviter certaines classes de vulnérabilités plus difficiles à contourner avec une conception en C ou C++. Une stratégie additionnelle est de minimiser le volume de code dans le noyau du système d'exploitation.

4.2 Payant ou gratuit, international ou souverain ?

En dehors des principaux acteurs internationaux, tous payants, il est possible de trouver des éditeurs qui proposent des versions d'essai ou encore des versions gratuites et open source. Certaines se basent sur un couple sysmon [5] et auditd [6] pour la collecte des événements de sécurité. Pour la détection, on peut retrouver des règles sigma [7] et quelques algorithmes maison ; et pour finir une stack elastic [8] pour le stockage et la représentation des données. Dans tous les cas, des composants gratuits, mais qui ont fait leurs preuves. Hélas, il existe peu de solutions à la fois matures et gratuites.

La question d'une solution souveraine peut se poser. Un grand nombre d’éditeurs propose une partie de leur infrastructure dans le cloud. C'est même parfois la seule possibilité, pas d'offre « on premise ». Dans ce cas, les datacenters européens seront choisis pour éviter aux données de quitter le continent. Cela leur permet de garder le contrôle sur l'intelligence de leur produit (le serveur de détection) et simplifie aussi grandement le maintien en condition opérationnelle. À l'inverse, il existe aussi des éditeurs français proposant un service « on premise » ou dans un cloud français.

5. Mise en place, MCO, coût humain

Dans la majorité des cas, le déploiement du serveur de détection est réalisé par l'éditeur. Les agents ont besoin de savoir où envoyer leurs données. En règle générale, les agents envoient leurs données vers un FQDN fourni par l'éditeur. Il faudra donc ouvrir les flux des terminaux vers celui-ci, qu'il soit dans le cloud ou « on premise ». Les solutions matures gèrent l'encapsulation SSL en cas de proxy ne laissant passer que le protocole HTTPS. Pour les grands parcs, il peut y avoir plusieurs serveurs de détection et une notion de load balancing.

Reste la phase de déploiement des agents sur les terminaux. On retrouve souvent un exécutable ou MSI pour Windows, déployable via SCCM ou GPO par exemple, pour Linux des packages préconfigurés et pour la partie mobile les solutions MDM courantes. Difficile de rentrer dans la subtilité des déploiements « mobile » ou « IoT ». Dans certains cas, il existe aussi la notion de découverte de machine. L’agent va analyser le réseau de façon passive ou active afin de détecter des terminaux ne disposant pas de la solution. Ceci dans le but d'aider à avoir une vue détaillée et exhaustive du déploiement. Une fois la solution mise en place, l'inventaire du parc est généralement accessible en quelques clics. On y retrouve par exemple les versions de chaque agent par poste, aidant ainsi à surveiller les migrations ou mises à jour. De plus, quand un agent ne communique plus avec le serveur central pendant une période de temps donnée, celui-ci passe dans un état « stale » ou inactif. Cela permet de surveiller les pertes de connectivité potentielles. Il existe parfois des utilisateurs (ou attaquants) qui tenteront de désinstaller cette solution, cela lèvera bien évidemment une alerte !

Une autre fonctionnalité commune aux solutions EDR est la notion de politique de sécurité, permettant un ajustement des protections en fonction des types de postes et leurs criticités. Une politique passive permet d'éviter le blocage de programmes légitimes. Après quelques semaines de déploiement et un ajout des applicatifs métiers ou faux positifs à une liste d'exclusion, les agents seront passés dans une politique de blocage moins permissive. Elle peut s'ajuster en temps réel de façon dynamique.

Plus subtile, la notion de supervision de la solution n'est pas toujours disponible. Il faut être vigilant lors du déploiement, l’installation d’agents trop intensive peut dépasser les capacités du serveur central. Un agent mal configuré sur un serveur peut avoir des effets de bord. Une bonne pratique est de tester la bonne chaîne d'alerte via le déploiement d’une machine de test avec l’EDR activé sur celle-ci. D’exécuter des charges plus ou moins malveillantes afin de s'assurer de la bonne remontée des alertes.

L'accès au portail d'administration de la solution, généralement découpé par utilisateur, doit garantir une sécurité minimum. Il peut être protégé par mot de passe et OTP. On peut aussi imaginer exposer le portail qu'à certaines plages d'IP dans le cas d'un déploiement cloud. Chaque utilisateur peut avoir un niveau de privilège plus ou moins élevé. Certains ne peuvent pas effectuer d'actions de blocage ou d'exclusion par exemple.

Le coût annuel de la solution est chiffré au nombre d'agents déployés modulo les options de détection activées. Le choix du cloud pour la partie réception et analyse des logs est souvent privilégié. Dans le cas d'un besoin « on prem » le coût de déploiement et MCO peut être bien plus élevé.

Conclusion

Le sujet est vaste. Chaque équipe, budget, contexte et infrastructure varie. À l'image des menaces qui évoluent, de nouvelles solutions innovantes voient le jour. De plus en plus adoptées, elles ne remplacent pas une équipe d'experts sécurité, mais offrent des capacités de détection et de réponse efficaces. L'XDR (EDR combiné aux alertes d'autres équipements de sécurité) va-t-il concurrencer les solutions standards et éprouvées de type SIEM ? L'avenir nous le dira.