¡Las uniones ES|QL ya están aquí! ¡Sí, uniones!

Elasticsearch 8.18 incluye nuestro primer JOIN de estilo SQL: el comando LOOKUP JOIN de ES|QL. Ya está disponible en vista previa técnica y permite la correlación y el enriquecimiento de datos con sets de datos de búsqueda fácilmente actualizables. ¿Necesitas agregar información de host y activos a tus eventos? No hay problema. ¿Quieres comprobar qué direcciones IP o URL están en listas de inteligencia de amenazas? ¡Claro! ¿Realizar actualizaciones en el set de datos de búsqueda y usarlas inmediatamente? ¡También!

Lookup Join es un LEFT OUTER JOIN de estilo SQL que se basa en un nuevo modo de índice llamado lookup para el lado derecho. El índice lookup podría ser activos, datos de inteligencia de amenazas como IP maliciosas conocidas, información de pedidos, información de empleados o clientes — hay infinitas posibilidades.

Históricamente, Elasticsearch carecía de capacidad de unión, aunque con el tiempo se hicieron algunos intentos en esa dirección, como nested, _parent y tipos de campo join, y enrich. Por lo general, fomentamos la desnormalización de los datos colocando los datos de referencia junto a los eventos en el mismo índice, o uniones del lado del cliente. Estas soluciones dificultan la escalabilidad para volúmenes de datos más grandes y pueden ser limitantes cuando hay una gran variedad de datos y casos de uso. Es hora de que Elasticsearch tenga uniones. Y ahora es posible: ES|QL no es solo un lenguaje — está construido sobre un nuevo motor de cómputo. El motor ES|QL hace posibles las características avanzadas, como la unión.

Para habilitar las lookup joins, creamos un nuevo modo de índice: "lookup". Un índice lookup es similar a un índice regular ("mode:standard" es el predeterminado), lo que significa que se puede actualizar directamente. La principal diferencia es que un índice lookup es de un solo shard. Por lo tanto, está limitado a 2 000 000 000 documentos, un límite de Lucene para un solo shard. Esto debería ser más que suficiente para almacenar los datos del lado derecho en muchos de los casos de uso de las lookup joins. Imponer este límite nos ayuda a evitar algunos de los problemas asociados con las uniones totalmente distribuidas al reducir la cardinalidad de origen del lado derecho de la unión. Esto también nos indica qué sets de datos planeas usar como referencias lookup para que podamos encontrar formas de optimizarlos en el futuro. 

Aparte del modo de índice de búsqueda, no hay restricciones en los datos de origen ni ninguna preparación de datos requerida para realizar una unión. Eso significa que es fácil agregar sets de datos de búsqueda y es fácil mantenerlos actualizados. 

Parte de esto ya ha sido posible con el comando ENRICH en ES|QL. ENRICH se optimizó para búsquedas en tiempo de ingesta en pipelines de ingesta y pequeños sets de datos que no cambian a menudo, por lo que fue conveniente pero no ideal. Lookup Join es más fácil de configurar y gestionar que ENRICH: 

• Sin crear políticas de enriquecimiento

• Sin ejecución de políticas

• Los índices de búsqueda son modificables

• Hay menos copias de los datos

• Mejor manejo de coincidencias múltiples: mientras que la función enrich crea campos con múltiples valores cuando hay varias coincidencias, la función lookup join crea varias filas. Esto hace que sea más fácil realizar análisis adicionales como agrupar y agregar, como bytes transferidos por usuario o totales de pedidos.

• Lookup Join permite especificar el campo de coincidencia sobre la marcha

Aquí tienes solo algunas de las formas en que podrías usar una función LOOKUP JOIN: 

• Unirte a eventos de seguridad con inteligencia de amenazas para enriquecer aún más el evento

• Consultar mi conjunto actual de hosts o la información más reciente sobre amenazas o metadatos internos

• Correlacionar lecturas de IOT con metadatos estáticos o dinámicos (fabricante, unidad de volumen)

• Combinar eventos de seguridad con información del host para más contexto y filtrado

• Agregar algunos datos como la criticidad de los activos (este usuario es un ejecutivo)

• Agregar los AID de CrowdStrike a una fuente que tenga nombres de host

• Comprobar si cierta dirección IP aparece en los feeds de inteligencia de amenazas

• Agregar información de empleados a los eventos

Las posibilidades son infinitas.

Ahora agrega el LOOKUP JOIN en el índice de búsqueda de entornos (el mío se llama envs_lkp):

Existen errores en producción y aseguramiento de calidad (QA). Podemos hacer una unión con una lista que indica qué equipo es propietario de cada servidor web para ver a quién debemos contactar:

¡A los analistas de Security les encantan sus joins! Tal vez quieran:

• Identificar las IPs de los clientes que solicitan URLs maliciosas conocidas

• Correlacionar con la información de activos para agrupar eventos y asignar prioridad o riesgo

Podrías descargar una lista de URL maliciosas de URLhaus en Abuse.ch y subirla a un índice de búsqueda.

Necesitarás al menos un lookup index para usar la lookup join. Estamos diseñando maneras de hacer que sea fácil y conveniente crear y actualizar lookups en Kibana. Por ahora, puedes comenzar creando un índice de lookups de varias maneras — el detalle clave es que el modo de índice debe ser “lookup.”.

Proporciona un nombre de índice y selecciona “Buscar” en el menú desplegable modo índice:

Haz clic en Crear para crear un índice de búsqueda vacío. 

En el panel de navegación izquierdo de Kibana, haz clic en machine learning, y a continuación, file data visualizer (o escribe “subir” en la barra de búsqueda de Kibana).

Selecciona o arrastra y suelta tu archivo — CSV funciona bien para esto.

Después de hacer clic en Importar, proporciona un nombre para el índice y haz clic en Avanzado para revelar la configuración del índice. Aquí, querrás agregar el index.mode: lookup.

Completa la carga del archivo haciendo clic en Importar. Se creará un índice y una Data view. 

En todos los casos, ahora puedes hacer referencia al índice de búsqueda en tus consultas ES|QL.

O bien, crea una data view. 

Q: ¿Puedo enviar datos de Logstash o de un agente?
¡Sí! Solo ten en cuenta que un índice de búsqueda no es un flujo de datos y es solo un shard, así que puedes "solo" enviar hasta 2 000 000 000 de documentos a cada índice de búsqueda.

Y las uniones de búsqueda son solo el principio. Nos gustaría ofrecer otros tipos útiles de uniones, como uniones inner o subconsultas, y también permitir unir contra cualquier índice (no solo índices de búsqueda).