Rappel sur les capacités de surveillance des EDR

Méthodes basées sur l’espace utilisateur vs. l’espace noyau

Sous Windows, les logiciels EDR utilisent principalement deux catégories de techniques pour surveiller les actions effectuées par les processus : les mécanismes côté espace utilisateur (« userland », ou « userspace »), tel que le hooking de fonctions, qui ciblent chaque processus individuellement, et ceux côté noyau (« kernel land », « kernel space »), qui s’appuient sur les fonctions fournies par le système d’exploitation pour collecter des données de télémétrie sur l’activité des processus à l’échelle du système.

Les techniques de la première catégorie peuvent souvent être techniquement contournées par un processus malveillant, à condition qu’il connaisse les moyens exacts employés par l’EDR. En effet, le code de surveillance et le code surveillé s’exécutent souvent dans le même « espace », la mémoire du processus, ce qui revient à un jeu du chat et de la souris entre le logiciel malveillant et l’EDR, étant donné que chacun peut interagir ou modifier le code de la « partie adverse ».

Pour la deuxième catégorie, le code de surveillance s’exécute dans l’espace du noyau Windows, qui n’est directement accessible par aucun processus, quel que soit son niveau de privilège. Cependant, ces capacités de surveillance sont fournies par Windows lui-même aux produits de sécurité installés, et tous les logiciels EDR sont obligés de les utiliser de manière presque identique pour obtenir une télémétrie des activités des processus (la manière de détecter une activité malveillante à partir de ces informations dépend évidemment de chaque logiciel EDR).

Pour approfondir le sujet, ces deux types de mécanismes ont notamment été décrits dans notre article de la 116^ème édition du magazine MISC. Aussi, pour mieux comprendre les enjeux de ce qui suit dans le présent article, nous recommandons aux lecteurs de consulter notre autre article sur les contournements de surveillance EDR dans la 118^ème édition du magazine MISC, ainsi que le README de notre outil, EDRSandblast.

Event Tracing for Windows – Threat Intelligence

Parmi les mécanismes susmentionnés, Event Tracing for Windows – Threat Intelligence (abrégé en ETW-Ti dans cet article) permet de générer des événements lors d’opérations du noyau critiques pour la sécurité, telles que la création de processus, la lecture/écriture de mémoire entre processus, la création de mémoire exécutable, etc. (voir notre article dans MISC 116 pour plus de détails).

Le flux d’événements produit par le mécanisme n’est normalement « consommable » que par les produits de sécurité, qui doivent être des processus protégés (PROTECTED_ANTIMALWARE_LIGHT), signés cryptographiquement comme tels par Microsoft.

La création de ces événements de sécurité est gérée par le noyau Windows et est mise en œuvre par de simples appels à des fonctions EtwTi* dédiées, intégrées à chaque fonction du noyau présentant un intérêt. L’image suivante montre l’appel à EtwTiLogReadWriteVm à l’intérieur de la fonction MiReadWriteVirtualMemory, cette dernière étant responsable des lectures et écritures de mémoire entre les processus.

Nos constats

Une exception bien commode

En examinant le graphique du flot de contrôle de la fonction ci-dessus, nous constatons que l’appel à la fonction de journalisation de l’ETW-Ti est toujours effectué lors d’un appel réussi à MiReadWriteVirtualMemory, à moins que PsIsProcessLoggingEnabled ne renvoie la valeur FALSE.

Cette dernière fonction, qui n’est mentionnée nulle part dans la littérature consacrée au reverse engineering de Windows, permet d’effectuer les opérations suivantes (note : les commentaires, les noms et les types de variables ont été obtenus par reverse engineering et/ou déduits des symboles de débogage publics) :

Figure 2: Code source de PsIsProcessLoggingEnabled obtenu par reverse-engineering

Comme nous pouvons le voir, la fonction vérifie l’état d’un flag parmi EnableReadVmLogging, EnableWriteVmLogging, EnableThreadSuspendResumeLogging et EnableProcessSuspendResumeLogging, indiquant si l’action en cours (parmi une lecture de mémoire interprocessus, une écriture de mémoire, une suspension/reprise de thread ou une suspension/reprise de processus, respectivement) doit être effectivement enregistrée par ETW-Ti. Ces flags se trouvent dans différents bitfields de la structure _EPROCESS du processus ciblé.

Accès aux flags de journalisation

En recoupant l’utilisation des flags susmentionnés dans le noyau, nous avons constaté que les fonctions NtQueryInformationProcess et NtSetInformationProcess étaient utilisés pour obtenir ou définir les bits spécifiques correspondant à ces flags de journalisation (logging).

Bien que la plupart du temps non documentées, ces fonctions ont été examinées de près par les reverse-engineers s’intéressant aux mécanismes internes de Windows (et par les développeurs de logiciels malveillants) depuis longtemps, car elles gèrent les appels système éponymes accessibles à partir de l’espace utilisateur. Le projet System Informer (anciennement connu sous le nom de Process Hacker) abrite une base de données impressionnante de prototypes de fonctions, de structures et d’enums liés aux mécanismes internes de Windows.

Le prototype de la fonction NtSetInformationProcess est le suivant :

Figure 3: Prototype de la fonction NtSetInformationProcess

Cette fonction gère une centaine de cas d’utilisation, selon la valeur du paramètre ProcessInformationClass. La fonction est implémentée à l’aide d’une énorme instruction switch, et le code spécifique concernant les flags de journalisation est situé dans les cases ProcessEnableReadWriteVmLogging et ProcessEnableLogging (constantes non documentées, nommées ainsi par les développeurs de System Informer).

Figure 4: Code source de NtSetInformationProcess obtenu par reverse-engineering

Le comportement du code ci-dessus peut être réduit aux points suivants :

• La cohérence de l’argument ProcessInformationLength est vérifiée par rapport à la structure ProcessInformation attendue (c’est-à-dire que les flags sont stockés dans un BYTE ou dans un DWORD, voir les structures attendues pour ProcessEnableReadWriteVmLogging et ProcessEnableLogging) ;
• Les privilèges du processus sont vérifiés : l’appel n’est accepté que si au moins l’un des privilèges SeDebugPrivilege ou SeTcbPrivilege est détenu par le processus appelant ;
• L’objet noyau (_EPROCESS) du processus cible est récupéré, tout en vérifiant que son handle possède bien le droit d’accès PROCESS_SET_LIMITED_INFORMATION ;
• Différents flags (provenant des champs Flags2 et Flags3 de la structure _EPROCESS) sont mis à jour, sur la base de la structure ProcessInformation

Les flags qui peuvent être mis à jour par cette méthode sont les suivants :

• EnableProcessSuspendResumeLogging (ou EnableThreadSuspendResumeLogging) : détermine si un événement ETW-Ti est généré lors de la suspension ou de la reprise d’un processus (ou d’un thread). Ces opérations sont utilisées dans les techniques de process hollowing, par exemple ;
• EnableReadVmLogging : détermine si un événement ETW-Ti est généré lors de la lecture de la mémoire d’un processus par un autre. Ces opérations sont généralement utilisées dans les techniques de dump de processus (LSASS, notamment) ;
• EnableWriteVmLogging : idem, pour les écritures en mémoire entre processus. Ces opérations sont utilisées dans la plupart des techniques d’injection de processus.

Du point de vue offensif

En résumé, si le mécanisme ETW-Ti ne peut pas être désactivé globalement sur le système depuis l’espace utilisateur (c’est-à-dire par un processus), certaines de ses fonctionnalités peuvent être désactivées par un processus disposant du privilège SeDebugPrivilege ou SeTcbPrivilege, ce qui peut être le cas de n’importe quel processus élevé.

Comme indiqué précédemment, le flux d’événements de l’ETW-Ti n’est normalement accessible qu’aux produits de sécurité tels que les EDR. Cependant, dans la fonction ci-dessus, nous voyons que n’importe quel processus non protégé peut désactiver certaines fonctions de journalisation d’un autre processus sans prouver au système qu’il est un consommateur légitime du flux ETW-Ti (ex. un EDR).

Il est important de noter que les EDR mettent souvent en corrélation plusieurs événements pour créer des alertes, afin de ne pas générer de résultats faussement positifs. Par exemple, un dump du processus LSASS est souvent divisé en plusieurs étapes :

• L’ouverture d’un handle au processus exe ayant un accès PROCESS_VM_READ ;
• La lecture effective de toutes les plages de mémoire concernées ;
• La création d’un fichier minidump.

Si seul l’événement de création d’un handle existe, mais que les événements de lecture ne sont pas enregistrés par ETW-Ti et que le fichier minidump est chiffré ou n’a jamais été écrit sur le disque, l’EDR peut ne pas émettre d’alertes concernant le dump du processus LSASS, faute de preuves.

Versions de Windows affectées

Différences entre Windows 10 et Windows 11

La même analyse a été effectuée sur le code NtSetInformationProcess du noyau de Windows 11.

Figure 5: Code source de NtSetInformationProcess obtenu par reverse-engineering sous Windows 11

Le code présente deux différences principales. La première, et la plus importante : le niveau de protection du processus appelant NtSetInformationProcess est vérifié comme étant « dominant » par rapport au niveau ANTIMALWARE_LIGHT, à l’aide de l’appel à EtwCheckSecurityLoggerAccess. Pour information, on dit qu’un niveau de protection en domine un autre si les deux affirmations suivantes sont vraies :

• Le type de protection (Protected, Protected light ou non protégé) est identique ou plus fort que l’autre niveau de protection (Protected est « plus fort » que Protected light, qui est évidemment plus fort que non protégé).
• Le signataire (signer) domine celui de l’autre niveau de protection, selon des règles codées en dur dans le noyau Windows (analysées de la structure RtlProtectedAccess). Le graphique suivant décrit ces règles :

Figure 6: « Domination » des processus protégés entre les différents signataires

Cela signifie que seul un processus protected ou protected light dont le signataire est WinSystem, WinTcb, Windows ou Antimalware (c’est-à-dire un composant système ou un produit de sécurité signé cryptographiquement par Microsoft en tant que tel) est autorisé à utiliser l’API NtSetInformationProcess pour désactiver les fonctions de journalisation ETW-Ti sous Windows 11. Il s’agit d’une amélioration importante, car elle établit une frontière cohérente entre les produits et fonctions de sécurité d’une part, et les autres processus d’autre part.

La deuxième différence entre les implémentations de NtSetInformationProcess sous Windows 10 et Windows 11 est que de nouveaux flags de journalisation ETW-Ti semblent être modifiables avec l’API : EnableProcessLocalExecProtectVmLogging et EnableProcessRemoteExecProtectVmLogging, apparemment utilisés pour activer/désactiver la surveillance des opérations rendant la mémoire exécutable.

À titre d’information, cette fonctionnalité semble toutefois être boguée ou n’est pas encore complètement implémentée, puisque dans le code présenté plus haut, les bits correspondant ne sont pas mis à zéro par l’opération AND bit-à-bit (InterlockedAnd), les fonctionnalités correspondantes ne peuvent donc pas être désactivées à l’aide de cette API.

Périmètre exact des versions affectées

L’analyse de diverses versions du noyau dans différentes versions de Windows a montré que la première version disponible de Windows 11 (21H2, version 10.0.22000.194) met déjà en œuvre le contrôle de sécurité effectué par EtwCheckSecurityLoggerAccess décrit plus haut.

En revanche, dans la dernière version disponible de Windows 10 au moment de la rédaction (22H2, version 10.0.19041.3393), la vérification de sécurité est toujours absente, alors que cette version est plus récente de 2 ans. Cela indique selon toute vraisemblance que Microsoft est bien conscient du problème et ne corrige pas la faiblesse volontairement, probablement pour des raisons de rétrocompatibilité.

Les différents flags de journalisation et leur traitement associé par NtSetInformationProcess sont apparus progressivement au cours de la vie du produit Windows 10. Le tableau suivant résume les versions concernées :

: La fonction de journalisation ETWTi n’existe pas encore
: La journalisation ETWTi peut être désactivée
: La journalisation ETWTi ne peut pas être désactivée

Le mot de la fin

En conclusion, le mécanisme décrit dans cet article permet de fait à un programme malveillant s’exécutant avec des privilèges élevés et souhaitant effectuer des actions néfastes (injection de processus, dump LSASS, process hollowing, etc.) de désactiver soigneusement la télémétrie associée avant de le faire, supprimant ainsi des preuves critiques de la surveillance EDR, ce qui améliore grandement ses chances de ne pas être détecté.

De nombreux éléments montrent que Microsoft est conscient de la faiblesse, mais ne modifie pas le comportement de l’API rétroactivement sur Windows 10, probablement en raison de problèmes de rétro-compatibilité.

Cet article Un bypass EDR universel découvert dans Windows 10  est apparu en premier sur RiskInsight.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

Pour plus de détails sur les solutions EDR, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (1/3) est apparu en premier sur RiskInsight.

Face à cela, les outils historiques ne semblent pourtant que trop peu adaptés aux nouvelles menaces, de plus en plus volatiles (40% des attaques ne s’appuient sur aucun fichier déposé sur un poste compromis, d’après une étude de l’institut Ponemon pour Barkly). En conséquence, un nouveau type de solution de sécurité est apparu, mêlant efficacité de détection et remédiation adaptative, les Endpoint Detection & Response (EDR).

AUX ORIGINES : LES ANTIVIRUS

A l’heure du trentième anniversaire de la première annonce de neutralisation d’un virus, les antivirus figurent aujourd’hui parmi les solutions les plus utilisées dans la protection des équipements terminaux que sont les serveurs et les postes de travail. Seulement, de nouvelles stratégies de défense viennent aujourd’hui consolider les fortifications de nos systèmes d’information, afin de faire face à un spectre plus large d’attaques et de menaces.

Une réponse toujours nécessaire face aux attaques connues

Que ce soit pour nettoyer un support de stockage USB ou un serveur critique, les antivirus bénéficient d’une réputation d’outils indispensables grâce à leur stratégie, allant de la détection de fichiers à signatures virales connues à la remédiation, ainsi qu’à leur faible taux de faux-positif.

Aujourd’hui largement employés par l’ensemble des acteurs numériques, certains antivirus efficaces permettent un investissement minime face à des conséquences majeures. Pour exemple, les coûts de l’attaque massive Wannacry sont estimés à près d’un milliard de dollars – mais la somme aurait pu être beaucoup plus élevée. En effet, comme l’a démontré le groupe de recherche MRG Effitas, certains antivirus peuvent bloquer les attaques les plus notables émanant de la faille EternalBlue, par détection de signatures au travers du réseau.

Partant de ce constat, certaines solutions antivirales semblent répondre à la majorité des attentes d’une entreprise « connectée », à savoir détecter les menaces les plus massives. Cependant, la recrudescence des attaques ciblées et sur-mesure laisse envisager une banalisation du contournement de ces défenses traditionnelles. Ces attaques peuvent conduire à une intrusion dans les  systèmes d’information les plus critiques, dans un environnement où le nombre d’infrastructures augmente et devient par conséquent plus complexe à maitriser. De plus, l’efficacité des antivirus reste dépendante de la multiplicité des attaques, et par conséquent d’une récolte efficace et complète des signatures virales.

Des mécanismes insuffisants face à l’évolutivité des cyber attaquants

Deux limites sont aujourd’hui mises en cause pour juger de la légitimité des antivirus à l’avenir. Elles sont majoritairement liées à la collecte et au stockage des bases antivirales perpétuellement alimentées.

1. Le délai de mise à jour des bases virales
   Dans un environnement constamment modelé par les cyber-attaquants, une première limite est la durée de mise à jour des banques de signatures virales. Comme rappelé par F-Secure à Gartner, « il y aura toujours un délai entre l’acquisition d’un échantillon, son analyse, et la création de la détection ». Il en découle un délai conséquent d’alimentation et d’adaptation des bases de signatures, pouvant conduire à la détection d’un virus plusieurs jours après infection.

2. Une détection principalement basée sur la recherche d’attaques connues
   Les attaques de type zero-day se caractérisent par l’absence de publication et de réponse connue à leur encontre, souvent due à leur récente réalisation. Pouvant pourtant partager des comportements avec des attaques connues, elles ne figurent pas dans le périmètre de détection des antivirus. Et bien que des mécanismes IDS (Intrusion Detection System) et de machine learning se soient greffés afin d’élargir les comportements détectés, ceux-ci ne représentent que peu de challenge pour un attaquant et sont potentiellement sources de faux-positifs.

En définitive, aucun attaquant censé ne s’est jamais entendu dire :

“D*mn there is an antivirus… Oh well too bad…”

Mais comment se prémunir face a ces attaques ?

Annoncée en préambule, la technologie EDR fait son apparition en 2013 et fonde sa stratégie sur la prévention d’attaques avancées, via l’utilisation de schémas de compromission connus. Pour cela, la clé de l’efficacité d’un EDR se trouve dans la collecte d’un maximum d’informations en continu.

A travers ses fonctions principales, un outil de Endpoint Detection and Response répond à trois besoins majeurs des équipes de sécurité des entreprises :

1.Détection    2.Investigation   3. Remédiation

Voici ci-dessous une vue globale des fonctionnalités possibles :

• Une détection intelligente en temps-réel :

• Une investigation intuitive et complète :
  • Recherche exhaustive d’indicateurs de compromission (IOC) sur l’ensemble des équipements terminaux distants (hash, nom de fichiers, date de création, taille, autres attributs) ;
  • Timeline (ou Kill-Chain) des évènements déroulés lors d’une attaque. Elle peut contenir des informations relatives aux augmentations de privilèges, aux escalades horizontales (exécution sur des machines tierces), etc.

Le détail d’un fichier peut être représenté comme suit :

• Une remédiation automatique ou sur demande :

Dans l’objectif de prioriser les interventions des équipes de sécurité, des mécanismes de scoring de la criticité des alertes permettent aux opérateurs de hiérarchiser les actions. Et, même si la suppression automatique de processus malveillants permet une première remédiation facile, d’autres remédiations « on-demand » et réalisables à distance sont envisageables :

A noter que les mécanismes présentés ci-dessus ne sont pas forcément présents dans toutes les solutions se présentant comme EDR. La présence d’un antivirus intégré n’est par exemple pas une garantie, tant l’efficacité des autres mécanismes de détection s’accélère et permet des performances de détection équivalentes.

Suivant le niveau de maturité de chaque solution, il est par conséquent nécessaire d’adopter une stratégie réalisée sur-mesure en regard des ressources matérielles/logicielles, des données métier à protéger et des ressources financières mobilisables.

Contextualisation pour une strategie sur-mesure

Une combinaison entre solutions historiques et innovantes

Puisque les EDR permettent la coexistence d’autres solutions de prévention, il n’est pas nécessaire de se séparer de son actuel antivirus afin de compléter ses défenses. Pour autant, l’aspect financier du maintien de deux solutions distinctes sur le même périmètre peut être un handicap.

De plus, certains EDR peuvent aussi intégrer des antivirus raisonnables, qui deviennent d’autant plus efficaces dans l’investigation des évènements lorsqu’ils sont liés à la même console de supervision. A l’inverse, plusieurs acteurs de solutions antivirales essayent de faire migrer leur solution vers les technologies EDR, ceci afin d’alimenter leur offre de protection Endpoint.

En se concentrant sur des scénarios adressables par la technologie EDR, nous pouvons noter la présence de solutions permettant :

1. L’utilisation d’une console d’investigation et de remédiation centralisée et permettant la protection de sites distants
2. L’interfaçage avec un SIEM ou des outils d’authentification (type Active Directory)
3. La restauration d’un OS infecté par un ransomware vers un état sain
4. L’adaptation de la remédiation opérée, afin qu’elle soit automatique ou manuelle

Des points de vigilance à adresser

Pour autant, un EDR n’est pas à considérer comme une solution miracle car :

• Il peut devenir destructeur entre de mauvaises mains, ce qui nécessite notamment un durcissement de configuration, une revue de la gestion des accès ou encore une procédure de patch management ;
• Certains mécanismes de contournement sont possibles, Wannacry en est un exemple via son utilisation d’un mécanisme de détection d’un environnement sandbox. Si une sandbox était utilisée pour l’exécuter, le virus retardait le lancement de son attaque (le temps que se déroulent les analyses de protection) afin de contourner la défense ;
• Il représente une potentielle surface d’attaque supplémentaire, avec ses propres vulnérabilités logicielles, en raison par exemple du besoin de privilèges élevés des agents déployés sur les postes.

« En 2019, les fonctionnalités des antivirus et des EDR auront fusionné dans une seule et même offre » (Gartner)

L’intérêt que représentent les EDR n’est pas anodin, comme partagé dans une étude Gartner prédisant la fusion de leurs mécanismes de détection, d’investigation et de remédiation avec un socle plus mature, celui des antivirus (source : Gartner, « Magic Quadrant for Endpoint Protection Platforms 2017 », 2017), à partir de 2019.

Le chiffre d’affaires généré par le marché des EDR a doublé entre 2015 et 2016. L’intérêt grandissant de ce domaine d’innovation laisse prédire, selon Gartner, une croissance annuelle de près de 50% du chiffre d’affaires global lié aux EDR jusqu’en 2020.

Actuellement présent sur près de 5% de l’ensemble des équipements compatibles, ce nouvel outil à la mode semble prédisposé à davantage de résonnance dans les stratégies de protection de nos postes de travail, de serveurs mais aussi de nos smartphones.

Les éditeurs

Une liste -non exhaustive- d’acteurs du monde des EDR est renseignée à titre indicatif ci-dessous.

Cet article EDR : Nouveau challenger dans la protection des endpoints est apparu en premier sur RiskInsight.