SIEM na Prática: Construindo Casos de Uso que Reduzem Ruído no SOC

O maior risco de um SIEM mal ajustado não é deixar passar um ataque — é gerar tanto ruído que os analistas param de confiar nos alertas. Construir bons casos de uso é o trabalho que separa um SOC funcional de um SOC que só acumula tickets.

O problema do alerta genérico

Regras “de prateleira” (out-of-the-box) tendem a ser demasiado amplas para um ambiente específico. Um alerta de “múltiplas tentativas de login falhadas” pode ser normal para um serviço com retry automático mal configurado, e crítico para uma conta de administrador de domínio.

Estrutura de um caso de uso

• Objetivo: que técnica ou comportamento esse caso de uso deteta, mapeado ao MITRE ATT&CK quando possível.
• Fonte de dados: que logs alimentam a regra, e se essa cobertura de facto existe no ambiente.
• Lógica de correlação: a condição exata — não apenas “evento X ocorreu”, mas “evento X ocorreu Y vezes, de origem incomum, fora do horário habitual”.
• Severidade e resposta: o que o analista deve fazer ao receber esse alerta — sem isso, o alerta só gera trabalho sem direção.

Reduzindo falsos positivos sem perder cobertura

Listas de exceção (allowlists) para comportamento legítimo conhecido — como jobs de backup ou scanners de vulnerabilidade autorizados — reduzem ruído sem desligar a regra inteira. O importante é rever essas exceções periodicamente: uma allowlist esquecida vira um ponto cego permanente.

Um SOC maduro mede a qualidade dos seus casos de uso pela taxa de verdadeiros positivos acionáveis, não pelo número de alertas gerados por dia.