Conseils de meilleures pratiques pour le renseignement sur les menaces

Beaucoup de gens disent que le renseignement sur les menaces (TI) est bon, mais peu comprennent comment le préparer. Il y a encore moins de personnes qui savent quels processus mettre en œuvre pour que le TI fonctionne et génère des profits. De plus, un nombre négligeable de personnes savent comment choisir un fournisseur de flux, où vérifier un indicateur de faux positifs et si cela vaut la peine de bloquer un domaine que votre collègue vous a envoyé par WhatsApp.

Nous avions deux abonnements APT commerciaux, dix échanges d’informations, une douzaine de flux gratuits et une liste étendue de nœuds de sortie TOR. Nous avons également utilisé quelques reverseurs puissants, des scripts Powershell maîtres, un scanner Loki et un abonnement payant à VirusTotal. Non que le centre de réponse aux incidents de sécurité ne fonctionne pas sans tout cela, mais si vous voulez attraper des attaques complexes, vous devez aller jusqu’au bout.

Ce qui m’inquiétait particulièrement, c’était la possibilité d’automatiser la vérification des indicateurs de compromission (IOCs). Il n’y a rien de plus immoral que l’intelligence artificielle remplaçant un humain dans une activité qui nécessite de la réflexion. Cependant, j’ai réalisé que mon entreprise allait rencontrer ce défi tôt ou tard, car le nombre de nos clients augmentait.

Pendant plusieurs années d’activité de TI permanente, j’ai marché sur un tas de râteaux et j’aimerais fournir quelques conseils qui aideront les débutants à éviter les erreurs courantes.

Conseil 1. Ne mettez pas trop d’espoirs dans la détection par hachage : la plupart des malwares sont polymorphes ces jours-ci

Les données de renseignement sur les menaces viennent sous différentes formes et manifestations. Elles peuvent inclure des adresses IP de centres de commandement et de contrôle de botnet, des adresses e-mail impliquées dans des campagnes de phishing, et des articles sur les techniques d’évasion que les groupes APT sont sur le point de commencer à utiliser. Pour résumer, il s’agit de choses différentes.

Pour trier tout ce désordre, David Bianco a suggéré d’utiliser ce qu’on appelle le Pyramide de douleur. Elle décrit une corrélation entre les différents indicateurs que vous utilisez pour détecter un attaquant et la quantité de “douleur” que vous allez causer à l’attaquant si vous identifiez un IOC spécifique.

Par exemple, si vous connaissez le hachage MD5 du fichier malveillant, il peut être détecté facilement et avec précision. Cependant, cela ne causera pas beaucoup de douleur à l’attaquant, car l’ajout d’un seul bit d’information à ce fichier changera complètement son hachage.

Conseil 2. Essayez d’utiliser les indicateurs que l’attaquant trouvera techniquement compliqués ou coûteux à modifier

En anticipant la question de savoir comment découvrir si un fichier avec un hachage donné existe dans notre réseau d’entreprise, je dirai ceci : il existe différentes méthodes. L’une des méthodes les plus simples consiste à utiliser une solution qui maintient la base de données des hachages MD5 de tous les fichiers exécutables dans l’entreprise.

Revenons à la Pyramide de douleur. Contrairement à la détection par valeur de hachage, il est plus productif d’identifier les TTP (tactiques, techniques et procédures) de l’attaquant. C’est plus difficile à faire et nécessite plus d’efforts, mais vous allez causer plus de douleur à l’adversaire.

Par exemple, si vous savez que le groupe APT qui cible votre secteur de l’économie envoie des e-mails de phishing avec des fichiers *.HTA à bord, alors la création d’une règle de détection qui recherche de tels pièces jointes aux e-mails frappera l’attaquant en dessous de la ceinture. Ils devront modifier la tactique de spamming et peut-être même dépenser de l’argent pour acheter des exploits 0-day ou 1-day qui ne sont pas bon marché.

Conseil 3. Ne mettez pas trop d’espoirs dans les règles de détection créées par quelqu’un d’autre, car vous devez vérifier ces règles pour les faux positifs et les ajuster

Lorsque vous commencez à créer des règles de détection, il y a toujours une tentation d’utiliser des règles prêtes à l’emploi. Sigma est un exemple de référentiel gratuit. Il s’agit d’un format de détection de méthodes indépendant du SIEM qui vous permet de traduire les règles du langage Sigma en règles ElasticSearch ainsi que des règles Splunk ou ArcSight. Le référentiel comprend des centaines de règles. Cela semble être une bonne chose, mais le diable, comme toujours, est dans les détails.

Examinons l’une des règles de détection de mimikatz. Cette règle détecte les processus qui ont tenté de lire la mémoire du processus lsass.exe. Mimikatz le fait lorsqu’il tente d’obtenir des hachages NTLM, et la règle identifiera le malware.

Cependant, il est crucial pour nous, experts qui ne détectent pas seulement mais répondent également aux incidents, de nous assurer qu’il s’agit réellement d’un acteur malveillant. Malheureusement, il existe de nombreux processus légitimes qui lisent la mémoire de lsass.exe (par exemple, certains outils antivirus). Par conséquent, dans un scénario réel, une règle comme celle-ci causera plus de faux positifs que de bénéfices.

Je ne veux pas accuser qui que ce soit à ce sujet – toutes les solutions génèrent des faux positifs ; c’est normal. Cependant, les spécialistes du renseignement sur les menaces doivent comprendre qu’il est toujours nécessaire de vérifier et d’ajuster les règles obtenues à la fois à partir de sources ouvertes et fermées.

Conseil 4. Vérifiez les noms de domaine et les adresses IP pour un comportement malveillant, non seulement au niveau du serveur proxy et du pare-feu, mais également dans les journaux du serveur DNS – et assurez-vous de vous concentrer à la fois sur les tentatives de résolution réussies et échouées

Les noms de domaine et les adresses IP malveillants sont les indicateurs les plus optimaux du point de vue de la simplicité de détection et de la quantité de douleur que vous infligez à l’attaquant. Cependant, ils semblent faciles à gérer seulement à première vue. Au moins, vous devriez vous demander où obtenir le journal de domaine.

Si vous vous limitez à vérifier les journaux du serveur proxy uniquement, vous pouvez manquer du code malveillant qui tente de requêter le réseau directement ou demande un nom de domaine non existant généré avec DGA, sans oublier le tunneling DNS – aucun de ceux-ci ne sera répertorié dans les journaux du serveur proxy d’entreprise. Les criminels peuvent également utiliser des services VPN avec des fonctionnalités avancées ou créer des tunnels personnalisés.

Conseil 5. Surveillez ou bloquez – décidez lequel choisir uniquement après avoir découvert quel type d’indicateur vous avez découvert et en reconnaissant les conséquences possibles du blocage

Chaque expert en sécurité informatique a été confronté à un dilemme non trivial : bloquer une menace ou surveiller son comportement et commencer à enquêter une fois que cela déclenche des alertes. Certaines instructions encouragent sans équivoque à choisir le blocage, mais parfois, le faire est une erreur.

Si l’indicateur de compromission est un nom de domaine utilisé par un groupe APT, ne le bloquez pas – commencez à le surveiller à la place. Les tactiques actuelles de déploiement d’attaques ciblées supposent la présence d’un canal de connexion secret supplémentaire, comme par exemple des applications de suivi de cellules qui ne peuvent être découvertes qu’à travers une analyse approfondie. Le blocage automatique vous empêchera de trouver ce canal dans ce scénario ; en outre, les adversaires réaliseront rapidement que vous avez remarqué leurs manigances.

En revanche, si l’IOC est un domaine utilisé par des rançongiciels, il doit être bloqué immédiatement. Mais n’oubliez pas de surveiller toutes les tentatives de requêter les domaines bloqués – la configuration de l’encodeur malveillant peut inclure plusieurs URL de serveurs de commandement et de contrôle. Certains d’entre eux peuvent ne pas être dans les flux et ne seront donc pas bloqués. Tôt ou tard, l’infection atteindra ces derniers pour obtenir la clé de chiffrement qui sera utilisée instantanément pour chiffrer l’hôte. La seule façon fiable de vous assurer que vous avez bloqué tous les C&C est de renverser l’échantillon.

Conseil 6. Vérifiez tous les nouveaux indicateurs pour la pertinence avant de les surveiller ou de les bloquer

Gardez à l’esprit que les données de menace sont générées par des humains qui sont sujets à l’erreur, ou par des algorithmes d’apprentissage automatique qui ne sont pas non plus infaillibles. J’ai été témoin de différents fournisseurs de rapports payants sur l’activité des groupes APT qui ajoutaient accidentellement des échantillons légitimes aux listes de hachages MD5 malveillants. Étant donné que même les rapports de menace payants contiennent des IOC de mauvaise qualité, ceux obtenus via l’intelligence ouverte doivent certainement être vérifiés pour la pertinence. Les analystes de TI ne vérifient pas toujours leurs indicateurs pour les faux positifs, ce qui signifie que le client doit faire le travail de vérification pour eux.

Par exemple, si vous avez obtenu une adresse IP utilisée par une nouvelle itération de TrickBot, avant de l’utiliser dans vos systèmes de détection, vous devez vous assurer qu’il ne s’agit pas d’un service d’hébergement ou d’une adresse émanant de votre IP. Sinon, vous aurez du mal à gérer de nombreux faux positifs chaque fois que les utilisateurs visitant un site résidant sur cette plate-forme d’hébergement vont sur des pages Web complètement inoffensives.

Conseil 7. Automatisez tous les flux de données de menace au maximum. Commencez par automatiser complètement la vérification des faux positifs via une liste d’avertissement tout en instruisant le SIEM pour surveiller les IOC qui ne déclenchent pas de faux positifs

Afin d’éviter un grand nombre de faux positifs liés à l’intelligence et obtenus à partir de sources ouvertes, vous pouvez effectuer une recherche préliminaire pour ces indicateurs dans les listes d’avertissement. Pour créer ces listes, vous pouvez utiliser les 1000 premiers sites Web par trafic, les adresses des sous-réseaux internes, ainsi que les noms de domaine utilisés par les principaux fournisseurs de services tels que Google (GOOGL ), Amazon (AMZN ) AWS, MS Azure et d’autres. Il est également une excellente idée de mettre en œuvre une solution qui modifie dynamiquement les listes d’avertissement composées des principaux domaines / adresses IP que les employés de l’entreprise ont accédés au cours de la semaine ou du mois précédent.

La création de ces listes d’avertissement peut être problématique pour un SOC de taille moyenne, il est donc judicieux de considérer l’adoption de plateformes d’intelligence sur les menaces.

Conseil 8. Analysez l’ensemble de l’entreprise pour les indicateurs d’hôte, et non seulement les hôtes connectés au SIEM

En règle générale, tous les hôtes de l’entreprise ne sont pas connectés au SIEM. Par conséquent, il est impossible de vérifier s’ils contiennent un fichier malveillant avec un nom ou un chemin spécifique en utilisant uniquement la fonctionnalité standard du SIEM. Vous pouvez résoudre ce problème de la manière suivante :

1. Utilisez des analyseurs d’IOC tels que Loki. Vous pouvez utiliser SCCM pour le lancer sur tous les hôtes de l’entreprise, puis transférer les résultats vers un dossier de réseau partagé.
2. Utilisez des analyseurs de vulnérabilités. Certains d’entre eux ont des modes de conformité qui vous permettent de vérifier le réseau pour un fichier spécifique dans un chemin spécifique.
3. Écrivez un script Powershell et exécutez-le via WinRM.

Comme mentionné ci-dessus, cet article n’est pas destiné à être une base de connaissances complète sur la façon de faire du renseignement sur les menaces correctement. Cependant, en fonction de notre expérience, suivre ces règles simples permettra aux débutants d’éviter les erreurs critiques lors de la manipulation de différents indicateurs de compromission.