Correlação de eventos no SIEM é a técnica de ligar dois ou mais registros de log que, isolados, parecem inofensivos, mas que juntos descrevem uma etapa real de um ataque. Para um SOC pequeno, ela é o caminho mais curto entre uma tela cheia de alertas de baixo valor e poucas investigações com contexto: em vez de responder separadamente a cada logon suspeito e a cada criação de processo, o analista responde à combinação dos dois dentro de uma janela de tempo definida. O primeiro passo prático é escolher um cenário com duas etapas observáveis nos logs que você já coleta hoje e escrever uma regra que exija os dois sinais antes de disparar qualquer alerta.
Não é preciso travar essa lógica na sintaxe de um produto específico: o formato aberto Sigma converte uma única regra YAML em consulta para o SIEM que você já opera, de Splunk a Microsoft Sentinel, o que mantém a detecção portável quando a plataforma muda. Este guia assume que você já domina a anatomia de uma regra individual e avança para o nível seguinte: transformar pares de eventos em detecções com contexto, validando tudo em laboratório com logs sintéticos antes de qualquer uso em produção.
Por que correlacionar eventos
Ataques que avançam dentro da rede geram famílias distintas de log. O movimento lateral com reutilização de credenciais, por exemplo, produz logons de rede, montagens de compartilhamento administrativo e criação de serviço em máquinas que normalmente não conversam entre si. Cada sinal isolado aparece também em manutenção legítima de rotina; a combinação dos três, na ordem esperada e na janela certa, quase nunca. Correlacionar é, portanto, uma forma de reduzir falsos positivos sem enfraquecer a regra — o oposto de simplesmente subir o limiar de severidade, que só esconde o ruído e adia a investigação.
O mesmo raciocínio protege o estágio inicial de um incidente. Campanhas de bypass de MFA antes de ransomware deixam rastros em pares de eventos — uma tentativa de autenticação frustrada seguida de um acesso bem-sucedido de origem incomum — que valem pouco quando avaliados separados e muito quando avaliados juntos. O SOC que só enxerga eventos individuais precisa responder por cada um deles; o SOC que correlaciona responde pela história completa.
Como construir a correlação
Toda regra correlacionada responde a três perguntas antes de qualquer YAML: qual é a chave que amarra os eventos entre si (usuário, host, endereço de origem), qual é a janela de tempo aceitável entre as etapas e quais são as condições mínimas de cada etapa. Sem chave, a correlação vira soma cega de alertas; sem janela, ela nunca dispara ou dispara semanas depois do fato. Com as três respostas definidas, a regra desce para a estrutura padrão do Sigma — logsource, detection e metadados — e herda o controle de severidade do formato: a documentação oficial do Sigma, regras de nível alto e crítico indicam um incidente, enquanto níveis baixo e médio indicam atividade suspeita e violações de política. Uma correlação bem construída costuma merecer nível alto justamente porque o contexto combinado já eliminou a maior parte do ruído que faria um evento isolado parecer duvidoso.
Na prática, o trabalho de engenharia está em escolher chave de entidade, janela de tempo e condições mínimas que reflitam como o ataque realmente se desenrola, e não como seria conveniente consultar. Uma janela de quinze minutos pode ser suficiente para logon seguido de execução remota na mesma máquina, e totalmente inadequada para uma campanha que se espalha por dias. Comece estreito: um cenário, uma chave, uma janela, e só depois generalize.
Tabela de eventos correlacionáveis
A tabela abaixo organiza pares que um SOC pequeno consegue observar com coleta mínima. Os identificadores de evento do Windows listados são exemplos usados no meu laboratório com logs sintéticos e método documentado — servem como referência de montagem, não como garantia de detecção no seu ambiente, porque o formato e o volume de logs reais variam de rede para rede.
| Primeiro evento | Segundo evento | Chave sugerida | Janela |
|---|---|---|---|
| Logon interativo suspeito (exemplo sintético: evento 4624, tipo 9) | Execução de ferramenta de administração remota (exemplo: evento 4688 com PsExec) | usuário + host de origem | 15 minutos |
| Falha de autenticação repetida (exemplo: evento 4625) | Logon bem-sucedido do mesmo usuário (exemplo: evento 4624) | usuário + endereço de origem | 30 minutos |
| Criação de novo serviço (exemplo: evento 7045) | Conexão de saída iniciada pelo binário do serviço | host + caminho do binário | 10 minutos |
| Acesso a compartilhamento administrativo | Logon de rede em host de alto valor | origem + destino | 20 minutos |
Para quem ingere eventos do Windows em pipelines de análise, o modelo de dados já expõe o essencial: no Azure Monitor, a tabela WindowsEvent recebe eventos do Windows coletados e enviados pelo agente, com colunas como EventID e TimeGenerated. Esse par evento mais carimbo de tempo é o que qualquer pipeline de ingestão precisa preservar intacto, independentemente da marca do SIEM, porque a correlação depende de saber o que aconteceu e exatamente quando aconteceu.
Procedimento de validação em laboratório
- Gere logs sintéticos das duas etapas com carimbos de tempo controlados e documente o método de geração como parte do ativo de detecção.
- Escreva a regra com chave de entidade e janela explícitas, sem condições implícitas herdadas de exemplos copiados.
- Converta a regra para o backend do seu SIEM com o conversor oficial do Sigma e confira a consulta resultante antes de executar.
- Execute contra os logs sintéticos e confirme que o alerta só nasce quando o par completo aparece na janela definida.
- Adicione variações legítimas — a mesma ação sem a primeira etapa — e confirme que a regra permanece em silêncio.
- Registre a janela testada, as variações usadas e o resultado, formando a linha de base para a próxima rodada de melhoria.
Erros comuns na correlação
- Janela longa demais: qualquer par de eventos distantes vira incidente, e o analista volta a triar ruído.
- Chave de entidade ausente: o alerta soma eventos de usuários e máquinas diferentes como se fossem uma só história.
- Correlacionar tudo de uma vez: regras com quatro ou cinco condições raramente disparam em ambiente real; comece com pares.
- Validar só o caso positivo: sem variações legítimas no teste, você conhece o que a regra encontra, mas não o que ela ignora.
- Ignorar a ordem das etapas: logon depois da execução remota é manutenção; a ordem errada na regra inverte o significado.
Correlação não substitui a qualidade da coleta: se o log da primeira etapa nunca chega ao SIEM, a regra mais bem escrita permanece muda. Por isso, antes de ampliar as regras, confirme que os eventos de origem da tabela realmente estão presentes no pipeline — regra correlacionada sem telemetria das duas pontas é apenas um arquivo YAML bem organizado.
