EQL vs ES|QL: Quando usar cada linguagem em investigações de segurança

O que o EQL resolve

O EQL é particularmente adequado para sequências ordenadas no tempo. Uma Rule pode procurar um Process start seguido de um Network event do mesmo process.entity_id. É possível ligar Events por um campo comum usando by, definir Timestamp, Event category e Tiebreaker, e até procurar Missing events em certos cenários.

A vantagem é que a lógica reflete uma história: a fase A ocorreu antes da fase B. Em vez de resumir dois tipos de Events na mesma janela e assumir que estão relacionados, o EQL verifica a ordem e a chave de ligação. Portanto, é útil para Process chains, Authentication sequences, File e depois Process, ou um Event que se espera que chegue e não chega.

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"]

Este exemplo usa um nome fictício e dados de laboratório. Procura um Process e depois uma Network connection da mesma entidade Process. Não prova malícia; deve-se verificar Destination, Signer, Parent, User e Host context.

O que o ES|QL resolve

O ES|QL opera em tabelas e suporta processamento em Pipeline. Começa-se com FROM, filtra-se com WHERE, cria-se campos com EVAL, resume-se com STATS ... BY, ordena-se e exibe-se Columns. Uma Detection do tipo ES|QL transforma cada linha de Result num Alert.

É adequado quando a questão é quantitativa ou requer Transformation: quantos Hosts executaram uma determinada ferramenta, quais Users criaram um volume anormal, qual a relação entre Success e Failure, ou qual campo calculado excede um Threshold. Não é a escolha natural quando a ordem Event A e depois B é o principal; a Elastic recomenda usar EQL para sequências 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 Query resume execuções por utilizador e filtra Users com cinco ou mais execuções. Responde a uma questão diferente do EQL: “Quem executou a ferramenta quantas vezes e em quantos Hosts?”, e não “Um determinado Process criou uma Connection depois?”.

Sequence vs Pipeline

O mesmo cenário com duas abordagens

Assumamos que o cenário geral é uma ferramenta de laboratório chamada lab-tool.exe que pode operar em contexto anómalo. Primeiro, definimos a questão exata:

• Questão EQL: Uma determinada instância da ferramenta começou e depois criou uma Network connection?
• Questão ES|QL: Quais utilizadores ou Hosts executaram a ferramenta com frequência anormal?
• Questão Custom query: A ferramenta foi executada com um Parent inesperado?

As três questões podem suportar o mesmo Use Case, mas não são equivalentes. O EQL fornece uma ligação cronológica. O ES|QL fornece uma Baseline ou Agregação. A Custom query fornece uma correspondência direta. Uma boa Detection architecture pode usar várias Rules, mas deve-se evitar duplicações e definir o que cada Rule adiciona.

Requisitos de dados

O EQL requer um Timestamp fiável e uma Event category. As sequências beneficiam de um Tiebreaker quando os Events partilham o mesmo tempo. O campo de ligação deve ser estável: process.entity_id é geralmente preferível a process.name, porque vários Processes podem partilhar um nome. Se entity_id estiver ausente ou mudar entre Sources, a Sequence não funcionará como esperado.

O ES|QL requer que os Indices sejam acessíveis e que os campos correspondam aos comandos. A Agregação num Field do tipo text em vez de keyword, valores Null ou um Schema inconsistente podem alterar os Results. Numa Detection Rule, deve-se considerar a Deduplication de Alerts, Schedule e Lookback. As capacidades e certos requisitos de Metadata variam entre as versões do Elastic, por isso deve-se verificar a documentação da versão.

Vantagens e limitações

Vantagens do EQL

• Expressa a ordem de Event de forma legível.
• Liga etapas por Entidade comum.
• Adequado para Process lineage e sequências comportamentais.
• Pode expressar a ausência de um Event esperado em cenários suportados.

Limitações do EQL

• Não é a ferramenta natural para Agregação complexa e Estatísticas.
• Depende muito de Timestamp, event.category e Key estável.
• Uma Sequence demasiado ampla pode ser cara ou ruidosa.

Vantagens do ES|QL

• Pipeline claro para filtragem, cálculo e Agregação.
• Criação de campos derivados usando EVAL.
• STATS ... BY permite Detection em valores agregados.
• Adequado para Hunting e relatórios tabulares.

Limitações do ES|QL

• Não substitui o EQL quando a ordem dos Events é o requisito central.
• Cada Row transforma-se num Alert, por isso o Grain do resultado deve ser planeado.
• A Agregação pode perder o Raw event context se o Investigation Guide não fornecer Drill-down.

Matriz de seleção

Exercício de laboratório

1. Crie cinco eventos de Process fictícios e dois eventos de Rede com process.entity_id.
2. Escreva uma EQL que retorne uma Sequence apenas quando a Rede ocorre após o Processo na mesma entidade.
3. Escreva uma ES|QL que resuma o número de execuções por user.name e host.id.
4. Altere o Timestamp de um Evento e verifique o que acontece à sequência.
5. Remova process.entity_id de um evento e verifique como a qualidade dos dados afeta.
6. Para cada Query, escreva uma frase: o que ela prova, o que ela não prova e qual o Drill-down necessário.

Erros comuns

• Usar ES|QL para simular uma Sequence complexa quando EQL é adequada.
• Usar EQL para uma questão que é um Count simples.
• Ligar por process.name em vez de Entidade estável.
• Ignorar Time zone, Ingestion delay e Tiebreaker.
• Transformar Agregação numa linha de Alert sem campos que permitam investigação.
• Copiar Query de outra versão sem verificar Syntax e requisitos de Metadata.

Resumo e CTA

Antes de escrever uma Query, escreva a pergunta numa folha: Procuro um Evento, Sequence, Count, Transformation, IOC ou Anomalia? A escolha da linguagem quase decorre da resposta. No exercício HPI, é recomendado manter a mesma Telemetry e executar EQL e ES|QL sobre ela, para ver como o modelo da pergunta altera o resultado da investigação.

Perguntas frequentes