O ajuste de regras de correlação no SIEM começa por uma decisão que muita gente pula: distinguir regra mal escrita de regra correta que dispara sobre atividade legítima do ambiente. O ajuste de regras de correlação no SIEM significa alterar a consulta, o limiar ou a agenda da regra para que ela só corresponda a eventos genuinamente suspeitos, enquanto a exceção serve para o caso em que a lógica está certa mas um ator conhecido como seguro — um servidor de gerenciamento, um scanner autorizado — continua gerando alerta. Escolher o mecanismo errado degrada o sinal: suprimir o que deveria ser exceção deixa lacunas, e reescrever a lógica para caber um caso específico fragiliza a detecção para todos os demais cenários. Este artigo organiza esse processo em diagnóstico, escolha de mecanismo, um método de sete etapas e métricas de acompanhamento.
Diagnóstico antes do ajuste
Nenhum ajuste deve partir de impressão. O primeiro passo é medir a regra como ela está: volume de alertas por dia, distribuição por severidade, proporção de incidentes fechados como falso positivo e entidades que mais aparecem nos disparos. Sem essa linha de base, não há como saber se a mudança melhorou ou piorou o quadro — e o time repete o ciclo de apagar incêndios sem acumular aprendizado.
Plataformas modernas já expõem parte desse diagnóstico pronto. O Elastic oferece pré-visualização da regra contra um intervalo histórico antes de habilitá-la, mostrando o que ela teria detectado sem criar alertas reais, o que permite ver falsos positivos óbvios e ausências de detecção antes do impacto operacional. O Microsoft Sentinel traz painéis de insights sobre regras analíticas com estatísticas de incidentes abertos e fechados por classificação. Use os dois recursos como rotina, não como exceção: cada mudança de regra ganha um período de observação com alertas visíveis e notificações pausadas até o volume se mostrar sustentável.
Ajustar a lógica ou criar exceção
A decisão central do ajuste tem quatro mecanismos possíveis, e cada um atua em um ponto distinto do pipeline. A tabela a seguir resume quando usar cada um:
| Mecanismo | Quando usar | Efeito |
|---|---|---|
| Ajuste da lógica | A consulta é ampla demais e captura comportamento normal em qualquer ambiente | Refina consulta, limiar ou agenda; melhora o sinal de origem |
| Exceção | A lógica está correta, mas um caso seguro específico do ambiente dispara a regra | Bloqueia a criação do alerta sem alterar a regra |
| Supressão | A mesma entidade dispara a regra repetidamente em pouco tempo | Agrupa disparos duplicados em um único alerta |
| Pausa de ações | Janela de manutenção ou implantação em observação | Alertas continuam sendo criados; só as notificações param |
A ordem importa: ajuste e exceção são avaliados antes de o alerta existir; supressão e pausa agem depois. Tratar com supressão o que deveria ser exceção deixa o primeiro alerta gravado e capaz de acionar uma escala. No Microsoft Sentinel, a regra de automação fecha o incidente e, por padrão, expira automaticamente após 24 horas, reduzindo a chance de falso negativo por uma exclusão esquecida — comportamento que encaixa bem exceções ainda em validação. Para exceções duradouras, a recomendação da documentação é referenciar watchlists na consulta em vez de listar valores na mão: a mesma watchlist pode ser aplicada a várias regras, permitindo gestão centralizada das exceções, e um analista pode incluir uma exceção sem editar a regra.
Em regras de processo autorizado, a alternativa a excluir é duplicar: mantém-se a regra original com exceção para o ator legítimo e cria-se uma cópia com risco reduzido que captura apenas aquele ator, preservando visibilidade sem poluir o fluxo de prioridade alta. O mesmo raciocínio vale para exclusões por host.name, process.name e user.name, os três campos que concentram a maior parte dos falsos positivos benignos.
Método de ajuste em sete etapas
- Documente a intenção da regra: qual comportamento de ataque ela detecta, quais fontes de log sustentam a detecção e qual o resultado esperado. Sem isso, o ajuste vira tentativa e erro.
- Meça a linha de base: alertas por dia, taxa de falso positivo e entidades recorrentes nos últimos disparos. Registre os números antes de mudar qualquer coisa.
- Classifique os disparos: separe falsos positivos por causa comum — aplicação interna, ferramenta administrativa, scanner, janela de manutenção — e agrupe por campo, não por caso individual.
- Escolha o mecanismo: consulta ampla em qualquer ambiente pede ajuste de lógica; caso seguro e específico pede exceção; repetição da mesma entidade pede supressão; implantação nova pede pausa de ações com observação.
- Altere um parâmetro por vez: limiar, janela de tempo ou filtro. Mudanças simultâneas impossibilitam atribuir o efeito observado a uma causa.
- Valide no histórico: rode a versão alterada contra um período passado e confirme que os verdadeiros positivos conhecidos continuam sendo detectados. Em regras de correspondência de indicadores, a documentação do Elastic orienta agendar regras de correspondência de indicadores em intervalos de uma hora ou mais e limitar o look-back adicional a no máximo 24 horas, evitando consultas gigantescas e sobrecarga do cluster.
- Registre a mudança: versão, autor, motivo e resultado esperado, em repositório versionado. A regra ajustada sem histórico é dívida técnica disfarçada de melhoria.
Erros que anulam o ajuste
Três falhas concentram a maior parte dos retrocessos. A primeira é a exclusão genérica: exceptuar um processo ou usuário sem delimitar também o host abre caminho para o atacante que se apropria daquela identidade. A segunda é o ajuste guiado por um único incidente — a consulta é estreitada até caber o caso da semana e deixa de detectar variações do mesmo ataque, incluindo sequências de movimento lateral já cobertas por outras regras do seu laboratório, como a detecção de pass the hash no SOC. A terceira é não reavaliar exceções: o ator excluído muda de função, a ferramenta é desativada e a exclusão permanece como porta silenciosa. Exceções precisam de data de revisão, da mesma forma que regras precisam de dono.
Um quarto erro merece destaque: confundir volume baixo com regra boa. Uma regra que quase não dispara pode estar saudável ou pode estar quebrada — por exemplo, uma mudança no formato de log derrubou a extração de um campo e ninguém percebeu. Regras silenciosas exigem teste periódico contra dados que sabidamente contêm o comportamento-alvo, prática que faz parte da resposta estruturada a incidentes descrita no guia de detecção e resposta a ransomware no SOC.
Métricas que sustentam a melhoria
O ajuste sem métrica é opinião. Acompanhe por regra, em janela fixa de 30 dias: volume médio de alertas por dia, taxa de verdadeiro positivo sobre o total de incidentes fechados, tempo médio de triagem por alerta e idade da última revisão da regra. Um painel simples com esses quatro números já revela as regras que merecem atenção na próxima ciclo de manutenção — normalmente 10% das regras concentram a maior parte do ruído e do tempo do analista.
Estabeleça também um gatilho objetivo: regra com taxa de falso positivo acima de um limite definido pelo time entra na fila de revisão com prioridade, e regra sem verdadeiro positivo em dois trimestres entra em avaliação de desativação. Manter regra inútil ativa tem custo real de atenção e risco falso de sensação de cobertura. Ajuste é ciclo contínuo, com agenda definida, não projeto de fim de trimestre.
