Détection et Réponse des Points de Terminaison – Blog de Sécurité IT Tec-Bite

À propos de cette offre

Nous vivons à une époque où les données sont les nouvelles tulipes, le nouvel or, le nouveau pétrole brut. La ruée vers nos données ne faiblit pas et prend parfois des proportions inquiétantes. Pensez aux ruées vers l'or du 19e siècle, aujourd'hui ce sont les données des utilisateurs de toutes sortes d'applications et de services qui sont exploitées. Chaque année, des milliards sont générés par l'acquisition, le traitement et la revente de nos données. Et quel rapport cela a-t-il avec la Détection et Réponse des Points de Terminaison (EDR) ? Comme pour les excès parfois douteux de la frénésie de collecte de données de certaines applications (exemple actuel ici : www.heise.de/ct/artikel/Wie-Avast-die-Daten-seiner-Kunden-verkaufte-4657290.html), un bon système EDR a bien sûr besoin d'autant de données que possible. Dans ce cas, elles servent cependant un but noble – à savoir la détection des attaques sur le réseau de l'entreprise. En fait, pas seulement cela. Si l'on dispose déjà des données, elles peuvent bien sûr aussi être utilisées pour d'autres choses utiles comme la gestion des vulnérabilités ou l'hygiène informatique. Plus d'informations un peu plus tard. Du recueil au Threat Hunting Cependant, la collecte des données ne suffit pas. Elles doivent aussi être analysées. Mot-clé : Threat Hunting. La prémisse est que l'on suppose déjà qu'un attaquant est actif sur les systèmes. Avec des critères de recherche ciblés, on veut démasquer le malfaiteur. Et c'est là que ça devient délicat : que doit-on chercher exactement ? L'idée d'une solution EDR est en soi de découvrir des activités suspectes inconnues. Donc des choses qui n'ont pas été détectées et bloquées en première instance par des solutions (NextGen) AV. Mais comment trouver l'inconnu ? Réponse : en ne cherchant pas seulement directement quelque chose de précis, ce que fait déjà une solution AV, mais en cherchant des indicateurs d'attaque. La méthode réactive : Indicators of Compromise Ces Indicators of Compromise (IOC) comprennent : Valeurs de hachage Adresses IP Domaines Artefacts hôtes (par ex. services, fichiers ou clés de registre suspects) trafic réseau suspect outils spécifiques Un article intéressant sur les Indicators se trouve ici : detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html. Il traite de la « Pyramid of Pain », qui montre selon moi bien la difficulté d'utiliser les différents types d'IOC lors de la chasse. Source : detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html, consulté le 09.04.2020 Mais où trouve-t-on ces IOCs ? Une possibilité est de puiser directement dans des Threat Intelligence Feeds, ce qui signifie aussi une mise à jour automatique. Une source possible pour ces flux est MISP (www.misp.software/index.html). Une autre possibilité est de créer soi-même des IOCs. Il existe aussi des outils web comme IOC Bucket (www.iocbucket.com/openioceditor). Quelle que soit la manière dont on travaille avec les IOCs, le problème est que c'est une méthode réactive. En soi, la même méthode que les mises à jour de signatures dans les solutions AV classiques. Les IOCs peuvent être comparés à la collecte de preuves dans une affaire criminelle. La sécurisation des preuves ne vient qu'après le crime. Nous ne sommes pas dans Minority Report. La méthode proactive – Indicators of Attack Pour répondre à ce défi, les Indicators of Attack IOAs entrent en jeu. Les IOAs offrent une méthode proactive de recherche de traces. Cela vise à prévenir ou au moins minimiser les dégâts. Des IOAs typiques sont par exemple : Un nombre inhabituellement élevé de connexions sur un serveur Activités sur un ordinateur ou dans le réseau à des heures inhabituelles Changements dans le comportement de communication d'un ordinateur, par ex. communication accrue vers des IP ou domaines spécifiques Scans de ports Nouveaux services en cours d'exécution sur certains ordinateurs Comptes locaux nouvellement créés sur des ordinateurs Activités de processus inhabituelles, par ex. suppression de copies de volume shadow Tactiques, Techniques et Procédures TTPs Un collègue a déjà écrit un article de blog intéressant sur les TTPs ici : www.tec-bite.ch/mitre-attack-angriff-ist-die-beste-verteidigung/ Comment faire du Threat Hunting sans chasseurs propres Avec les IOCs et IOAs, on dispose donc des moyens pour aider à la recherche. Mais comment chercher ? Dans les PME, il n'y a souvent pas d'équipes SOC propres, il manque donc simplement les spécialistes. D'autant plus important est qu'il soit possible pour des chasseurs moins expérimentés d'utiliser ces outils. En fin de compte, ce n'est pas seulement une question de savoir-faire, le temps joue aussi un grand rôle. Si aujourd'hui mon équipe IT est déjà bien occupée par le quotidien, un système EDR ne m'est guère utile. Si j'ai les données mais ne peux pas les utiliser, cela ne sert à rien. Dans ce cas, les fabricants proposent un service de type Managed SOC. Ainsi, on peut profiter des avantages d'un système EDR sans effort supplémentaire. En tant que pionnier dans l'utilisation des IOAs, CrowdStrike (www.avantec.ch/loesungen/avantec-newcomers/#crowdstrike) fixe de nouvelles normes avec sa plateforme Falcon. L'interface graphique est claire et compréhensible et offre des rapports pré-générés ainsi que des requêtes de chasse utiles. Voici une requête qui me retourne tous les téléchargements Powershell : event_simpleName=ProcessRollup2 FileName=powershell.exe (CommandLine=*Invoke-WebRequest* OR CommandLine=*Net.WebClient* OR CommandLine=*Start-BitsTransfer*) | table ComputerName UserName FileName CommandLine Le résultat dans l'interface : Pratique : chaque recherche effectuée reste dans l'historique des recherches et peut être réutilisée facilement : Les requêtes sont basées sur le Search Processing Language de Splunk. Pour ne pas trop approfondir dans cet article, je souhaite renvoyer ici à l'article « How to Hunt for Threat Activity with Falcon Endpoint Protection » de CrowdStrike. On le trouve ici : www.crowdstrike.com/blog/tech-center/hunt-threat-activity-falcon-endpoint-protection/. Ce qu'un EDR peut faire d'autre Comme mentionné au début, un système EDR ne sert pas seulement au Threat Hunting, mais offre aussi d'autres fonctions utiles comme l'hygiène informatique ou la gestion des vulnérabilités. L'hygiène informatique consiste essentiellement à savoir quelles applications sont installées sur quels ordinateurs, quelles versions de ces applications sont présentes, quels comptes sont utilisés sur quels systèmes et quels privilèges ils ont. Pour rester sur l'exemple de CrowdStrike, il y a pour cela le module Falcon Discover : Si je sais maintenant quelles applications et quelles versions sont sur mes systèmes, il serait aussi pratique de savoir si j'ai des failles de sécurité ouvertes. C'est là qu'intervient la gestion des vulnérabilités. Sur la plateforme CrowdStrike Falcon, le module Spotlight est disponible pour cela. Comme pour le module Discover, Spotlight offre une vue d'ensemble confortable des vulnérabilités ouvertes : les failles sont listées avec les identifiants CVE de MITRE. Comme les TTPs, les CVE (Common Vulnerabilities and Exposures) sont désormais utilisées comme standard par la plupart des fabricants de solutions de sécurité. Avec les informations de Spotlight, un administrateur système peut alors installer les correctifs manquants sur ses systèmes via WSUS, SCCM ou d'autres systèmes de gestion des correctifs et ainsi combler les failles. Conclusion Pour conclure, on peut dire que le Threat Hunting n'est pas une mince affaire. Pour un hunting efficace, il faut non seulement les bons outils mais aussi des connaissances approfondies. Comme la plupart des entreprises manquent de ce savoir-faire, il est conseillé au moins au début de recourir à un service géré. Ainsi, on peut immédiatement bénéficier d'une protection étendue et en même temps développer ses propres compétences sans pression. Les lecteurs attentifs auront peut-être remarqué que je n'ai pas encore abordé la partie Response de la Détection et Réponse des Points de Terminaison. J'aborderai ce sujet dans mon prochain article. L'article "Endpoint Detection and Response – wer (richtig) sucht, der findet!" est paru en premier sur Tec-Bite.