Equipes defensivas perdem mais tempo calibrando o alerta errado do que respondendo ao incidente certo. O problema atinge qualquer organização que opera um SIEM com catálogo de regras em crescimento constante, e a ação prioritária é tratar detecção como código: um formato canônico para as regras, conversão automatizada, métricas de ruído por regra e um processo formal de aposentadoria do que deixou de funcionar. Este guia mostra como montar esse pipeline com regras Sigma, o conversor sigma-cli e o planejamento de logs recomendado pelo NIST, sem amarrar a operação à linguagem proprietária de um fornecedor.
O ruído nasce na regra
Ruído não é um atributo do SIEM; é consequência de como cada regra foi escrita, implantada e mantida. Três padrões explicam a maior parte do excesso de alertas em catálogos maduros: seleções amplas demais para o volume real do ambiente, regras duplicadas que chegam em pacotes de conteúdo instalados em camadas sobrepostas e ausência de uma pessoa responsável pela regra depois do primeiro falso positivo. Sem dono, a regra barulhenta é silenciada às pressas durante um plantão e nunca volta a ser avaliada.
A degradação também acontece no sentido oposto, e é a mais perigosa: regras que continuam listadas como ativas mas não disparam mais. No Elastic Security, por exemplo, regras atualizadas por usuários sem privilégios suficientes podem parar de gerar alertas silenciosamente, porque a execução usa os privilégios de quem editou a regra por último. O catálogo, portanto, precisa de auditoria em duas direções ao mesmo tempo: quais regras disparam demais e quais deixaram de disparar sem que ninguém percebesse. Painel que só mede volume de alertas esconde a segunda metade do problema.
Sigma torna a regra portátil
Sigma é um formato aberto e estruturado para descrever detecções sobre eventos de log, no papel que o Snort ocupa para tráfego de rede e o YARA para arquivos. A regra é escrita uma vez em YAML, com fonte de log, seleção, filtros de falso positivo e severidade declarados de forma explícita, e depois convertida para a linguagem de consulta do SIEM em uso. Depois da aposentadoria do conversor legado, a conversão passou a ser feita pelo sigma-cli, construído sobre pySigma, com backends para as plataformas comuns de mercado.
O ganho prático é duplo. Primeiro, a equipe deixa de reescrever a mesma lógica de detecção a cada migração de plataforma, porque a regra canônica sobrevive à troca de fornecedor. Segundo, passa a consumir o repositório comunitário mantido por centenas de contribuidores, que reúne milhares de regras prontas e pode ser implantado direto de um pipeline de CI/CD, com controle de versão sobre cada mudança. Para detecção em runtime no kernel Linux, o mesmo princípio de regra portátil e compartilhável se aplica às ferramentas analisadas no artigo sobre Falco e Tetragon.
O plano de logs do NIST
Antes de otimizar regras, é preciso saber quais fontes de log existem e quais decisões cada uma sustenta. A revisão do guia de gestão de logs do NIST, o SP 800-92, substitui a versão original de 2006 com uma mudança de foco deliberada: o escopo ficou restrito ao planejamento, e tanto a implementação de tecnologia quanto o uso analítico dos dados ficaram fora do documento. O conteúdo central virou um playbook de jogadas de alto nível — definir o estado alvo, inventariar fontes, estabelecer requisitos de retenção e acesso — pensado para dar à organização os dados de log de que ela precisa, e não o máximo de dados possível.
Essa ordem importa diretamente para o ruído. Regra nenhuma cobre bem uma fonte que ninguém mapeou, e retenção definida sem caso de uso associado vira custo puro de armazenamento. Quem procura um roteiro inicial de coleta pode combinar esse planejamento com o guia de logs de segurança já publicado aqui, que detalha as fontes mínimas para detectar ataques comuns.
Pipeline de regras como código
Regra de detecção merece o mesmo tratamento de código de produção: revisão, teste, versionamento e rollback. O fluxo mínimo tem cinco etapas, e pular qualquer uma delas devolve o ruído pelo buraco por onde saiu.
| Etapa | Objetivo | Erro comum |
|---|---|---|
| Autoria em Sigma | Lógica única, legível e revisável | Escrever direto na linguagem do SIEM |
| Conversão em CI | Gerar a query no pipeline, nunca à mão | Converter localmente e colar no console |
| Teste contra dados reais | Medir falso positivo antes de ativar | Ativar sem baseline do ambiente |
| Implantação versionada | Rollback rápido e histórico de mudança | Editar regra direto na interface |
| Revisão periódica | Aposentar regra morta ou barulhenta | Nunca mais olhar o catálogo |
Dois controles fazem a diferença entre um pipeline de demonstração e um que sustenta operação. O primeiro é a revisão por pares: toda mudança de regra passa por um segundo par de olhos antes de chegar ao SIEM, mesmo quando vem do repositório comunitário, porque regra escrita para outro ambiente carrega seleções que não fazem sentido no seu. O segundo é a auditoria de permissões do próprio pipeline: se a conta que implanta regras perde privilégios após uma reorganização de equipe, a detecção falha em silêncio, e o time só descobre na primeira investigação.
Checklist de operação
- P1: inventariar as fontes de log e as decisões que cada uma sustenta, seguindo o playbook do NIST.
- P1: auditar o catálogo por duas métricas: alertas gerados por regra e regras sem nenhum disparo no período de análise.
- P1: mover a autoria de regras para Sigma, com conversão no CI e revisão por pares obrigatória.
- P2: atribuir responsável e prazo de revisão a cada regra em produção.
- P2: definir critério objetivo de aposentadoria: regra sem disparo e sem justificativa documentada sai do catálogo.
- P2: reexecutar a auditoria de permissões do pipeline depois de qualquer mudança na equipe que administra o SIEM.