EQL vs. ES|QL: Cuándo usar cada lenguaje en investigaciones de seguridad

Qué resuelve EQL

EQL es especialmente adecuada para secuencias ordenadas en el tiempo. Una Rule puede buscar un Process start y luego un Network event del mismo process.entity_id. Se pueden vincular Eventos por un campo común usando by, definir Timestamp, Event category y Tiebreaker, e incluso buscar Missing events en ciertos escenarios.

La ventaja es que la lógica refleja una historia: la etapa A ocurrió antes que la etapa B. En lugar de resumir dos tipos de Eventos en la misma ventana y asumir que están relacionados, EQL verifica el orden y la Key de vinculación. Por lo tanto, es útil para Process chains, Authentication sequences, File y luego Process, o un Evento que se espera que llegue y no llega.

sequence by process.entity_id
  [process where event.type == "start" and process.name == "lab-tool.exe"]
  [network where event.type == "connection" and network.direction == "egress"]

El ejemplo utiliza un nombre ficticio y datos de laboratorio. Busca un Proceso y luego una conexión de Red desde la misma entidad de Proceso. No prueba la malicia; se deben verificar Destination, Signer, Parent, User y Host context.

Qué resuelve ES|QL

ES|QL opera en tablas y admite procesamiento de Pipeline. Se comienza con FROM, se filtra con WHERE, se crean campos con EVAL, se resumen con STATS ... BY, se ordenan y se muestran Columns. Una Detection de tipo ES|QL convierte cada fila de Result en una Alert.

Es adecuada cuando la pregunta es cuantitativa o requiere Transformation: cuántos Hosts activaron una herramienta específica, qué Users crearon un volumen anómalo, cuál es la relación entre Success y Failure, o qué campo calculado supera un Threshold. No es la elección natural cuando el orden del Evento A y luego B es lo principal; Elastic recomienda usar EQL para secuencias ordenadas.

FROM logs-endpoint.events.*
| WHERE event.category == "process" AND event.type == "start"
| WHERE process.name == "lab-tool.exe"
| STATS executions = COUNT(*), hosts = COUNT_DISTINCT(host.id) BY user.name
| WHERE executions >= 5

Esta consulta resume las activaciones por usuario y filtra los Users con cinco o más activaciones. Responde a una pregunta diferente de EQL: "¿Quién activó la herramienta cuántas veces y en cuántos Hosts?", no "¿Un proceso específico creó una conexión después?".

Sequence vs. Pipeline

El mismo escenario con dos enfoques

Supongamos que el escenario general es una herramienta de laboratorio llamada lab-tool.exe que podría ejecutarse en un contexto anómalo. Primero se define la pregunta exacta:

• Pregunta EQL: ¿Se inició una instancia específica de la herramienta y luego creó una conexión de Red?
• Pregunta ES|QL: ¿Qué usuarios o Hosts ejecutaron la herramienta con una frecuencia anómala?
• Pregunta Custom query: ¿La herramienta se ejecutó con un Parent inesperado?

Las tres preguntas pueden soportar el mismo Use Case, pero no son equivalentes. EQL proporciona una relación cronológica. ES|QL proporciona una Baseline o Aggregation. Custom query proporciona una coincidencia directa. Una buena Detection architecture puede usar varias Rules, pero se deben evitar duplicidades y definir qué añade cada Rule.

Requisitos de datos

EQL requiere un Timestamp fiable y Event category. Las secuencias se benefician de Tiebreaker cuando los Eventos comparten el mismo tiempo. El campo de vinculación debe ser estable: process.entity_id es generalmente preferible a process.name, ya que varios Processes pueden compartir un nombre. Si entity_id falta o cambia entre Sources, la Sequence no funcionará como se espera.

ES|QL requiere que los Índices sean accesibles y que los campos coincidan con los comandos. La Agregación en un Field de tipo text en lugar de keyword, valores Null o un Schema inconsistente pueden cambiar los Results. En una Detection Rule, se debe considerar la Deduplication de Alerts, Schedule y Lookback. Las capacidades y los requisitos de ciertos Metadatos varían entre las versiones de Elastic, por lo que se debe consultar la documentación de la versión.

Ventajas y limitaciones

Ventajas de EQL

• Expresa el orden de los Eventos de forma legible.
• Vincula las etapas según una Entidad común.
• Adecuada para Process lineage y secuencias de comportamiento.
• Puede expresar la ausencia de un Evento esperado en escenarios soportados.

Limitaciones de EQL

• No es la herramienta natural para Agregación compleja y Statistics.
• Depende mucho de Timestamp, event.category y una Key estable.
• Una Sequence demasiado amplia puede ser costosa o ruidosa.

Ventajas de ES|QL

• Pipeline claro para filtrado, cálculo y Agregación.
• Creación de campos derivados mediante EVAL.
• STATS ... BY permite la Detection en valores resumidos.
• Adecuada para Hunting e informes tabulares.

Limitaciones de ES|QL

• No reemplaza a EQL cuando el orden de los Events es el requisito principal.
• Cada Row se convierte en una Alert, por lo que el Grain del resultado debe ser planificado.
• La Agregación puede perder el Raw event context si la Investigation Guide no proporciona Drill-down.

Matriz de selección

Ejercicio de laboratorio

1. Crear cinco eventos de Proceso ficticios y dos eventos de Red con process.entity_id.
2. Escribir una EQL que devuelva una Sequence solo cuando Network ocurre después de Process en la misma entidad.
3. Escribir una ES|QL que resuma el número de activaciones por user.name y host.id.
4. Cambiar el Timestamp de un Evento y verificar qué sucede con la secuencia.
5. Eliminar process.entity_id de un evento y verificar cómo afecta la calidad de los datos.
6. Escribir para cada Query una frase: qué prueba, qué no prueba y qué Drill-down se necesita.

Errores comunes

• Usar ES|QL para imitar una Sequence compleja cuando EQL es adecuada.
• Usar EQL para una pregunta que es un Count simple.
• Vincular por process.name en lugar de una Entidad estable.
• Ignorar Time zone, Ingestion delay y Tiebreaker.
• Convertir una Agregación en una línea de Alert sin campos que permitan la investigación.
• Copiar una Query de otra versión sin verificar Syntax y los requisitos de Metadatos.

Resumen y CTA

Antes de escribir una Query, escriba la pregunta en un papel: ¿Estoy buscando un Evento, una Sequence, un Count, una Transformation, un IOC o una Anomalía? La elección del lenguaje casi se deriva de la respuesta. En la práctica de HPI, se recomienda mantener la misma Telemetry y ejecutar EQL y ES|QL sobre ella, para ver cómo el modelo de la pregunta cambia el resultado de la investigación.

Preguntas frecuentes