Les jointures ES|QL sont arrivées ! Oui, les jointures !

Elasticsearch 8.18 inclut notre premier JOIN de style SQL : la commande LOOKUP JOIN d’ES|QL.LOOKUP JOIN. Il est désormais disponible en aperçu technique et permet la corrélation et l’enrichissement des données grâce à des ensembles de données lookup facilement mises à jour. Besoin d’ajouter des informations sur les hôtes et les ressources à vos événements ? Pas de problème. Vous souhaitez vérifier quelles adresses IP ou URL figurent sur les listes de renseignement des menaces ? Bien sûr ! Vous pouvez mettre à jour l’ensemble de données lookup et les utiliser immédiatement !

Lookup Join est un LEFT OUTER JOIN de style SQL qui repose sur un nouveau mode d’index appelé lookup pour le côté droit. L’index lookup peut inclure des actifs, des données de renseignement sur les menaces comme des IP connues comme malveillantes, des informations de commande, des informations sur les employés ou les clients : les possibilités sont infinies.

Historiquement, Elasticsearch ne prenait pas en charge JOIN, malgré quelques tentatives au fil du temps, comme les types de champs imbriqués, _parent et join, ainsi que l’enrichissement. Nous préconisions généralement la dénormalisation des données en plaçant les données de référence avec les événements dans le même index, ou en effectuant des jointures côté client. Ces solutions nuisent à la scalabilité pour les grands volumes de données et peuvent s’avérer limitantes en cas de forte variété de données et de cas d’utilisation. Il est temps qu’Elasticsearch intègre les jointures. Et c’est désormais possible : ES|QL n’est pas qu’un simple langage, il repose sur un nouveau moteur de calcul. Ce moteur ES|QL permet d’implémenter des fonctionnalités avancées telles que JOIN.

Pour activer Lookup Join, nous avons créé un nouveau mode d’index : lookup. Un index lookup est similaire à un index classique (le mode standard est le mode par défaut), ce qui signifie qu’il est directement modifiable. La principale différence est qu’un index lookup ne comporte qu’une seule partition. Il est donc limité à 2 milliards de documents, une limite imposée par Lucene pour une partition. Cela devrait largement suffire pour stocker les données du « côté droit » dans de nombreux cas d’utilisation de Lookup Join. L’imposition de cette limite permet d’éviter certains problèmes liés aux jointures entièrement distribuées en réduisant la cardinalité source du côté droit de la jointure. Cela nous indique également quels ensembles de données vous prévoyez d’utiliser comme références lookup afin que nous puissions trouver des moyens de les optimiser à l’avenir. 

Hormis le mode Lookup Index, il n’y a aucune restriction quant aux données sources et aucune préparation des données n’est requise pour effectuer une jointure. Cela signifie qu’il est facile d’ajouter des ensembles de données de recherche, et de les maintenir à jour. 

Certaines de ces fonctionnalités étaient déjà disponibles grâce à la commande ENRICH dans ES|QL. ENRICH a été optimisé pour les recherches sur l’heure d’ingestion dans les pipelines d’ingestion et pour les petits ensembles de données qui ne changent pas souvent. C’était donc pratique mais pas idéal. Lookup Join est plus facile à configurer et à gérer que Enrich : 

• Aucune politique d’enrichissement à créer

• Aucune exécution de politique

• Les index de recherche sont modifiables

• Il y a moins de copies des données

• Meilleure gestion des correspondances multiples, alors que la fonction Enrich crée des champs à valeurs multiples lorsqu’il existe plusieurs correspondances, la fonction Lookup Join crée plusieurs lignes. Cela permet d’effectuer plus facilement des analyses supplémentaires, comme le regroupement et l’agrégation, par exemple le nombre d’octets transférés par utilisateur ou le total des commandes.

• Lookup Join permet de spécifier à la volée le champ de correspondance

Voici quelques-unes des manières dont vous pourriez utiliser un LOOKUP JOIN : 

• Associer des événements de sécurité aux renseignements sur les menaces afin d’enrichir davantage un événement

• Comparer la liste actuelle d’hôtes aux dernières informations sur les menaces ou aux métadonnées internes

• Corréler les lectures IOT avec des métadonnées statiques ou dynamiques (fabricant, unité de volume)

• Associer les événements de sécurité aux informations de l’hôte pour plus de contexte et de possibilités de filtrage

• Ajouter quelques informations, telles que la criticité des actifs (cet utilisateur est un cadre)

• Ajouter les AID de CrowdStrike à une source qui possède des noms d’hôte

• Vérifier si certaines adresses IP figurent dans les flux de renseignements sur les menaces

• Ajouter des informations sur les employés aux événements

Les possibilités sont infinies.

Ajoutez maintenant le LOOKUP JOIN à l’index de recherche de l’environnement (le mien s’appelle envs_lkp) :

Il y a des erreurs dans la production et l’assurance qualité (QA). Nous pouvons croiser ces données avec une liste indiquant à quelle équipe appartient chaque serveur web afin de déterminer qui nous devons contacter :

Les analystes sécurité adorent Join ! Ils pourront ainsi profiter des fonctionnalités suivantes :

• Identifier les adresses IP des clients qui demandent des URL malveillantes connues.

• Corréler avec les informations des actifs afin de regrouper les événements et d’attribuer la priorité ou le risque.

Vous pouvez télécharger une liste d’URL malveillantes depuis URLhaus sur Abuse.ch et l’importer dans un index de recherche.

Vous aurez besoin d au moins un Lookup Index pour utiliser Lookup Join. Nous concevons des moyens pour faciliter et rendre pratique la création et la mise à jour des recherches dans Kibana. Pour l’instant, vous pouvez commencer par créer un index de recherche de plusieurs manières  : le point essentiel est que le mode de l’index doit être Lookup.

Indiquez un nom d’index, et sélectionnez Lookup dans la liste déroulante du mode index :

Cliquez sur Créer pour créer un index de recherche vide.

Dans le volet de navigation gauche de Kibana, cliquez sur Machine learning, puis File data visualizer (ou tapez « télécharger » dans la barre de recherche de Kibana).

Sélectionnez ou glissez-déposez votre fichier, le format CSV est parfaitement adapté.

Après avoir cliqué sur Importer, indiquez un nom pour l’index, puis cliquez sur Avancé pour afficher les paramètres de l’index. Ici, vous pourrez ajouter index.mode : lookup.

Complétez le téléchargement du fichier en cliquant sur Importer. Un index et un Data view seront créés. 

Dans tous les cas, vous pouvez désormais faire référence au Lookup index dans vos requêtes ES|QL.

Ou alors, créez une data view. 

Q : Puis-je envoyer des données depuis Logstash ou un agent ?
Oui ! Gardez simplement à l’esprit qu’un index de recherche n’est pas un flux de données et qu’il ne s’agit que d’une seule partition ; vous ne pouvez donc envoyer « que » jusqu’à 2 milliards de documents à chaque index de recherche.

Et les Lookup Join ne sont que le début. Nous aimerions proposer d’autres types utiles de jointures, comme les jointures internes (INNER) ou les sous-requêtes, et aussi permettre la jonction contre n’importe quel index (pas seulement les indices de recherche).