Préambule
Dans notre premier article de la série Detonate, nous avons présenté le système Detonate et l'usage que nous en faisons chez Elastic. Nous avons également discuté des avantages qu'il offre à notre équipe lors de l'évaluation des performances de nos artefacts de sécurité.
Dans cette publication, nous expliquerons le fonctionnement de Detonate & et nous nous pencherons plus en détail sur la mise en œuvre technique. Il s'agit notamment de la manière dont nous sommes en mesure de créer cet environnement en bac à sable dans la pratique, de la technologie qui soutient l'ensemble du pipeline, et de la manière dont nous soumettons des informations au pipeline et dont nous les lisons.
Intéressé par d'autres articles sur Detonate ? Consultez la partie 1 - Click, Click...Boom! où nous présentons Detonate, pourquoi nous l'avons construit, comment il fonctionne, décrivons des études de cas et discutons des tests d'efficacité.
Architecture
Vous trouverez ci-dessous une vue d'ensemble de l'architecture de bout en bout de Detonate.
Le système global consiste en une série de files d'attente de messages et de travailleurs Python. Les tâches de détonation sont créées par un serveur API lorsqu'il accepte une demande contenant aussi peu d'informations que le hachage du fichier d'échantillons. La tâche se déplace ensuite d'une file d'attente à l'autre, prise en charge par des travailleurs qui exécutent diverses opérations en cours de route.
Le serveur et les travailleurs sont exécutés dans un conteneur sur Amazon ECS. Le pipeline peut également être mis en place localement à l'aide de Docker Compose pour le développement précoce et les tests de fonctionnalités.
Serveur API
Le serveur API Detonate est une application python FastAPI qui accepte une variété de demandes de cibles d'exécution : hachages d'échantillons, commandes natives (en bash ou Powershell, avec ou sans arguments), et fichiers téléchargés. Le serveur expose également des points d'extrémité pour récupérer les alertes et la télémétrie brute de l'agent à partir d'un cluster Elastic.
La documentation de l'API est générée automatiquement par FastAPI et incorporée dans notre schéma d'API global.
Interagir avec le serveur API - CLI
Nous avons construit un outil CLI (interface de ligne de commande) Python personnalisé pour interagir avec notre serveur Detonate. L'outil CLI est construit en utilisant la bibliothèque Python click ainsi que rich pour une belle expérience de formatage dans une fenêtre de terminal. Cet outil est particulièrement utile pour le débogage du pipeline, car il peut également être exécuté par rapport à une configuration locale du pipeline. L'outil est installé et exécuté à l'aide de Poetry, notre outil préféré pour la gestion des dépendances et l'exécution des scripts.
❯ DETONATE_CLI_API_ROOT_URL="${API_ENDPOINT_URL}" \
DETONATE_CLI_API_AUTH_HEADER="${API_KEY}" \
poetry run cli \
--hash "${MY_FILE_HASH}"Interagir avec le serveur API - Interface Web
En interne, nous hébergeons un site appelé Protections Portal (écrit à l'aide de composants Elastic UI ) pour aider notre équipe dans ses recherches. Pour une expérience plus interactive avec l'API Detonate, nous avons créé une page dans le portail pour interagir avec elle. Outre la soumission des tâches, l'interface Web permet aux utilisateurs de consulter le flux de toutes les détonations et les détails de chaque tâche.
Chaque tâche peut être développée pour en voir tous les détails. Nous fournissons les liens vers les données et la télémétrie recueillies lors de la détonation.
Interagir avec le serveur API - Client HTTP
Si nos utilisateurs veulent personnaliser la façon dont ils interagissent avec l'API de Detonate, ils peuvent également exécuter des commandes en utilisant le client HTTP de leur choix (tel que curl , httpie , etc.). Cela leur permet d'ajouter des détonations à des scripts ou comme étapes finales à la fin de leurs propres flux de travail.
Queues
Le pipeline est construit sur une série de files d'attente et de travailleurs. Ayant des exigences très basiques pour le moteur de file d'attente de messages, nous avons décidé d'opter pour Amazon SQS. L'un des nombreux avantages de l'utilisation d'un service populaire comme SQS est la disponibilité de ressources et de bibliothèques open-source sur lesquelles nous pouvons nous appuyer. Par exemple, nous utilisons les images Docker softwaremill/elasticmq comme moteur de file d'attente lors de l'exécution locale du pipeline.
Les files d'attente sont configurées et déployées à l'aide d'un code Terraform qui couvre l'ensemble de notre infrastructure de production et de mise en scène.
Travailleurs
Chaque travailleur est un script Python qui agit à la fois comme un consommateur et un producteur de file d'attente. Les travailleurs sont mis en œuvre dans notre mini-framework personnalisé, avec le code de base pour la gestion des erreurs, les tentatives et le contrôle intégrés. Notre travailleur de base est facilement extensible, ce qui nous permet d'ajouter de nouveaux travailleurs et de faire évoluer les travailleurs existants si des besoins supplémentaires apparaissent.
Pour la surveillance, nous utilisons la solution d'observabilité Elastic APM. Il est incroyablement puissant, nous donnant une vue sur le flux d'exécution et facilitant le débogage des problèmes de pipeline. Ci-dessous, nous pouvons voir une tâche Detonate se déplacer entre les travailleurs dans l'interface utilisateur d'APM :
Ces composants logiciels et d'infrastructure nous donnent tout ce dont nous avons besoin pour effectuer la soumission, l'exécution et la collecte de données qui constituent une détonation.
Détonations
Le pipeline peut exécuter des commandes et des échantillons dans des machines virtuelles (VM) Windows, Linux et macOS. Pour les environnements Windows et Linux, nous utilisons des instances VM dans Google Compute Engine. Grâce à la vaste sélection d'images publiques, il nous permet de fournir des environnements en bac à sable avec différentes versions de Windows, Debian, Ubuntu, CentOS et RHEL.
Pour les environnements macOS, nous utilisons des instances mac1.metal dans AWS et une solution de provisionnement de VM macOS à la demande de Veertu appelée Anka. Anka nous donne la possibilité de faire tourner rapidement plusieurs VM macOS fonctionnant sur la même instance macOS bare metal.
Detonate se concentre actuellement sur l'étendue de la couverture du système d'exploitation, l'extensibilité et la collecte de données contextuelles pertinentes à partir du pipeline. L'intégration de contre-mesures anti-analyse sophistiquées dans Detonate fait actuellement l'objet de recherches et d'études.
Approvisionnement des machines virtuelles
Afin de réduire au minimum notre empreinte dans la VM, nous utilisons des scripts de démarrage pour le provisionnement. Il est important de minimiser notre empreinte car nos activités au sein d'une VM sont incluses dans les événements que nous collectons, ce qui complique l'analyse après une exécution. Pour les machines virtuelles Windows et Linux, des scripts de démarrage GCP écrits en Powershell et bash sont utilisés pour configurer le système ; pour les machines virtuelles macOS, nous avons écrit des scripts bash et AppleScript personnalisés.
Les scripts de démarrage effectuent les étapes suivantes :
- Configurez le système. Par exemple, désactivez MS Defender, activez l'exécution des macros dans MS Office, désactivez les mises à jour automatiques du système, etc.
- Téléchargez et installez l'agent Elastic. Le script vérifie que l'agent est correctement enrôlé dans le Fleet Server et que les politiques sont appliquées.
- Téléchargez et faites exploser un échantillon, ou exécutez une série de commandes. L'exécution a lieu dans un processus d'arrière-plan, tandis que le script principal collecte les flux de données STDOUT / STDERR et dort pendant N secondes.
- Collecter les fichiers du système de fichiers (si nécessaire) et les télécharger dans le système de stockage. Cela nous permet d'effectuer toute vérification ou tout débogage supplémentaire une fois la détonation terminée.
Le cycle de vie de la VM est géré par les travailleurs start_vm et stop_vm. Comme nous nous attendons à ce que certaines détonations interrompent le flux d'exécution du script de démarrage (par exemple, dans le cas d'un ransomware), chaque VM a un TTL défini, ce qui permet au travailleur stop_vm de supprimer les VM qui ne sont plus utilisées.
Cette approche propre, avec le script de démarrage utilisé pour configurer tout ce qui est nécessaire à une détonation, nous permet d'utiliser les images VM des fournisseurs du catalogue d'images publiques de Google Cloud sans aucune modification !
Configuration du réseau
Certains des échantillons que nous faisons exploser sont malveillants et peuvent produire un trafic malveillant, tel que des analyses de réseau, des appels au C2, etc. Afin de préserver la sécurité de nos ressources en nuage et de l'infrastructure de notre fournisseur, nous limitons tout le trafic sortant des machines virtuelles. Les instances sont placées dans un VPC verrouillé qui n'autorise les connexions sortantes qu'avec une liste prédéfinie de cibles. Nous limitons les flux de trafic dans le VPC en utilisant les routes et les règles de pare-feu de Google Cloud, ainsi que les groupes de sécurité d'AWS.
Nous utilisons également les journaux de flux VPC dans GCE. Ces journaux nous permettent de voir le trafic du réseau privé initié par des machines virtuelles en bac à sable dans notre VPC.
Collecte de données télémétriques
Pour observer les détonations, nous utilisons l'agent Elastic avec l'intégration Elastic Defend installée avec toutes les protections en mode "Detect" (au lieu de "Protect"). Cela nous permet de collecter autant d'informations que possible à partir d'une VM, tout en permettant à la solution Elastic Security de produire des alertes et des détections.
Nous couvrons deux cas d'utilisation avec cette architecture : nous pouvons valider les protections (en comparant les événements et les alertes produits pour différentes versions de systèmes d'exploitation, versions d'agents, artefacts de sécurité déployés, etc.) et collecter la télémétrie pour l'analyse (pour les échantillons frais ou les nouveaux logiciels malveillants) en même temps. Toutes les données collectées sont conservées dans un cluster Elastic persistant et sont disponibles pour nos chercheurs.
En cours de production
Récemment, nous avons passé un mois complet à faire fonctionner le pipeline Detonate en production, sous la charge de multiples intégrations de données, en servant les utilisateurs internes à travers l'interface utilisateur en même temps. Jusqu'à présent, notre record est de 1034 détonations en une seule journée, et nous n'avons pas encore constaté de problèmes d'évolutivité ou de fiabilité.
Pour l'instant, la plupart des soumissions sont des échantillons spécifiques à Windows. Nous nous efforçons d'accroître notre couverture de Linux et de macOS également - restez à l'écoute pour les articles de blog sur la recherche qui arriveront bientôt !
Nous améliorons constamment notre prise en charge des différents types de fichiers, en veillant à ce que la détonation soit aussi proche que possible du comportement de déclenchement prévu.
Si l'on examine les détonations du mois dernier, on constate que la plupart des tâches ont été accomplies en moins de 13 minutes (avec une médiane de 515 secondes). Ce temps comprend la préparation des données de la tâche, l'approvisionnement et le nettoyage des machines virtuelles, l'exécution de l'échantillon et le traitement post-détonation.
Le service n'en est qu'à ses débuts, il est donc normal de voir des valeurs aberrantes. Étant donné que la majeure partie du temps d'une tâche est consacrée à l'attente de l'approvisionnement d'une VM, nous pouvons améliorer le temps d'exécution global en utilisant des images de VM personnalisées, en pré-démarrant les instances de VM et en optimisant les scripts de démarrage.
Et ensuite ?
Maintenant que vous savez comment fonctionne Detonate, nos prochains articles se pencheront sur des cas d'utilisation plus détaillés de Detonate. Nous verrons plus en détail comment ces détonations permettent de protéger un plus grand nombre de nos utilisateurs, y compris ici, chez Elastic !