Elastic Security: Criar uma Regra de Deteção e Guia de Investigação

Passo 1: Defina o Caso de Uso e escolha o tipo de Regra

Comece com uma frase comportamental: “Identificar um Processo de um tipo específico que é ativado num contexto inesperado em estações de trabalho de utilizadores”. Em seguida, defina o que é considerado uma correspondência, que Contexto é necessário e qual é uma explicação legítima. Só depois escolha o tipo de Regra.

Uma escolha errada cria uma Query complicada ou alertas instáveis. Se a ordem dos eventos é essencial, EQL é mais natural do que ES|QL. Se for necessária uma agregação, ES|QL ou Threshold são mais adequados. Custom query é boa para correspondência direta a campos.

Passo 2: Verifique o ECS e a prontidão dos dados

Elastic Common Schema — ECS — define nomes e estruturas comuns, como event.category, event.type, host.name, user.name, process.name, process.command_line e process.parent.name. Uma Regra que depende de campos que não estão mapeados de forma consistente funcionará numa Integração e falhará noutra.

Abra Sample events e verifique: event.category é um processo? event.type inclui start? process.command_line é recolhido ou oculto? process.entity_id existe? @timestamp é a hora do evento ou a hora de ingestão? Documente os Index patterns, Integrations, Version e Required fields. A lista de Required fields na interface é uma informação para o utilizador e não corrige o mapeamento real.

Passo 3: Escreva uma Query focada

No exemplo do laboratório, gostaríamos de identificar a criação de um Processo chamado lab-admin-tool.exe quando o Parent não é o software de gestão esperado. O nome é fictício. Numa Custom query, pode-se escrever um KQL simples:

event.category:process and event.type:start and process.name:"lab-admin-tool.exe" and not process.parent.name:"approved-manager.exe"

A Query indica uma anomalia, mas não prova maliciosidade. É preciso verificar Signer, Hash, Path, User, Host, Parent command line e frequência. Antes de criar a Regra, execute-a no Discover ou Timeline em diferentes intervalos. Verifique se existem campos Null, Variants no nome ou Sources que não são fiáveis.

Se o comportamento exige uma sequência — por exemplo, Process e depois Network connection do mesmo process.entity_id — passe para EQL. Se quiser resumir quantos Hosts executaram a ferramenta ou calcular o Count por Parent, ES|QL pode ser adequado.

Passo 4: Schedule e Lookback

A Regra inclui Query, Schedule e Actions. O Intervalo determina com que frequência é executada. O Lookback expande a janela de pesquisa para cobrir Eventos que chegam atrasados. Janelas sobrepostas podem criar Alertas duplicados se não houver Deduplication ou Suppression adequada. Uma janela muito curta perde dados tardios.

Verifique o Ingestion delay por fonte. Eventos de Endpoint podem chegar quase em tempo real, enquanto uma fonte Cloud ou Batch pode atrasar. Defina o Run every e o Additional look-back com base em medições. Após alterar o Pipeline ou a Integração, meça novamente.

Passo 5: Severity, Risk e MITRE

Severity descreve a gravidade da correspondência de acordo com o Caso de Uso; Risk score permite uma classificação numérica. Não use High para todas as Regras. Um Processo anómalo num Host de laboratório é diferente do mesmo Processo num Domain Controller. Pode-se usar Risk score override quando um campo fiável fornece Contexto, mas é preciso verificar Missing values e Range.

O mapeamento MITRE ATT&CK deve corresponder ao comportamento que a Regra deteta, não ao cenário de ataque completo que se imagina. Uma Regra que deteta Process execution não prova necessariamente Persistence ou Exfiltration.

Passo 6: Suppression e Exceptions

Alert suppression agrupa correspondências repetidas por campos para reduzir o volume. Não substitui uma Query correta. A Suppression por host.name pode ocultar desenvolvimentos se o mesmo Host produzir vários Comportamentos diferentes. Escolha campos que representem a unidade de investigação, por exemplo, host.id e process.hash, e defina um Window a partir de uma Baseline.

Exceptions excluem correspondências conhecidas. Crie uma Exception restrita: Hash assinado, Path, Parent específico e Grupo de Hosts definido, em vez de excluir process.name em toda a organização. Adicione Comment, Owner e data de Review. Quando possível, prefira uma lista de Exceptions gerida em vez de uma Query com dezenas de cláusulas NOT.

Passo 7: Escreva um Guia de Investigação

Um Guia de Investigação é um documento Markdown que é anexado à Regra e aparece ao lado do Alerta. Segundo o Elastic, um bom guia é construído em torno de Triage, Analysis e Response, começa com o contexto e não com uma lista de Comandos, e refere-se a campos de Alerta, Timeline queries e Osquery quando apropriado.

É possível referir-se a campos dinâmicos como host.name ou user.name e adicionar botões de Timeline quando a versão e a licença o suportam. Mantenha o guia curto e fácil de ler. O analista trabalha sob pressão; parágrafos longos e desordenados não serão lidos.

Passo 8: Validação e Ajuste

1. Execute Preview ou Query histórica e marque exemplos True, False e Benign Positive.
2. Teste a Regra num Positive sample simulado e num Negative sample. Verifique se falha quando um campo está em falta e não cria uma correspondência incorreta.
3. Ative inicialmente sem Resposta perigosa. Meça o Alert volume, tempos de investigação e qualidade do Contexto.
4. Verifique o status de execução da Regra, gaps, permissions e API key. As Regras são executadas com as permissões do último utilizador que as editou.
5. Ajuste Query, Schedule, Suppression e Exceptions separadamente para saber o que resolveu o problema.
6. Execute o Regression test após atualizar a Integração, o mapeamento ECS ou a versão do Elastic.

Checklist

• ✓Tipo de Regra adequado à questão.
• ✓Indices, Data view, ECS e Required fields verificados.
• ✓Query retorna uma unidade de investigação clara.
• ✓Schedule e Lookback cobrem Delay sem duplicação excessiva.
• ✓Severity, Risk e MITRE correspondem ao comportamento.
• ✓Suppression e Exceptions são restritas e documentadas.
• ✓Guia de Investigação inclui Triage, Analysis e Response.
• ✓Existem Owner, Review date, Metrics e Regression test.

Erros comuns

• Escolher EQL, KQL ou ES|QL por preferência e não pela questão.
• Copiar uma Prebuilt Rule sem verificar os requisitos de dados.
• Assumir que o ECS está mapeado porque o campo aparece em alguns eventos.
• Aumentar o Lookback sem entender as duplicações.
• Criar uma Exception ampla sobre Process name.
• Ativar Resposta automática antes da Validação.
• Escrever um Guia de Investigação que contém apenas “Verifique se é malicioso”.

Resumo e CTA

Escolha um Processo fictício num laboratório e construa uma Regra completa: Contrato de Dados, Query, Schedule, Risk, uma Exception, Guia de Investigação e Casos de Teste. Depois, peça a outro analista para investigar um Alerta sem explicação verbal. Se o guia e os campos não forem suficientes, melhore a Regra antes de adicionar mais lógica.

Perguntas frequentes