Otimização de Alertas no Wazuh: reduzir ruído para PMEs em 2026

Você tem o Wazuh instalado, mas o painel está chorando com dezenas de alertas por hora? Esse é um problema real: quando tudo parece urgente, nada é. Vamos transformar seu SOC de sinal de fumaça em radar preciso.

O que são falsos positivos e por que são perigosos

Falsos positivos são alertas que apontam problemas que não existem. Parecem inofensivos, mas são perigosos por dois motivos: primeiro, cansam sua equipe. Analistas passam horas investigando "nada" enquanto um ataque real escapa. Segundo, criam o efeito "menino que gritou lobo" — quando um incidente real acontece, ninguém reage a tempo.

Imagine um sistema de alarme que dispara toda vez que um gato passa na rua. Depois da décima vez, você desliga o alarme. Na cibersegurança, isso custa caro: em 2026, o tempo médio para detectar uma violação ainda é de 287 dias para PMEs sem SOC otimizado.

Como o Wazuh gera alertas (em termos simples)

O Wazuh monitora três coisas principais: arquivos de log (syslog, application logs), eventos do sistema (logins, mudanças de configuração) e integridade de arquivos (alterações em binários e configurações). Cada evento é comparado contra regras — se bater, gera um alerta.

O problema é que as regras padrão são genéricas. Um login root em um servidor Debian pode ser normal para o administrador, mas o Wazuh não sabe disso. Ele vê "root login" e dispara nível 12 — alto. Se isso acontece 50 vezes por dia, sua equipe ignora tudo.

Onde começar: análise de 30 dias

Antes de mudar qualquer configuração, você precisa entender o que está acontecendo. No Wazuh, acesse o dashboard e filtre os últimos 30 dias. Conte:

• Quantos alertas por dia?
• Quais regras mais aparecem?
• Quais níveis de severidade são mais comuns?

Na prática, PMEs tipicamente têm 200-500 alertas/dia, com 60-80% em nível baixo (0-6). Esse ruído esconde os 10-20 alertas importantes.

Exemplo real: um cliente no setor de varejo tinha 847 alertas/dia. Depois da análise, descobrimos que 600 eram falhas de autenticação no VPN — usuários digitando senha errada. Nada de hacker, apenas esquecimento. Reduzimos para 120 alertas/dia úteis.

Supressão baseada em contexto

A otimização mais eficiente usa contexto. O Wazuh permite criar regras personalizadas em /var/ossec/ruleset/rules/local_rules.xml. Veja um exemplo prático:

Supressão de login de usuário específico:

<rule id="100100" level="0">
  <if_sid>5501</if_sid>
  <match>^ssh_failed_login|^user_login</match>
  <user>admin_sistema</user>
  <description>Ignorar falhas de login do admin do sistema</description>
</rule>

Isso diz ao Wazuh: quando o usuário "admin_sistema" falhar no SSH, não gere alerta. É um usuário legítimo, pode errar a senha.

Supressão por endereço IP:

<rule id="100101" level="0">
  <if_sid>5710</if_sid>
  <srcip>192.168.1.50</srcip>
  <description>Ignorar alertas do servidor de backup interno</description>
</rule>

O servidor de backup acessa outros servidores constantemente — é normal. Suprimir esses eventos reduz o ruído sem remover visibilidade.

Agrupamento e correlação

O Wazuh também pode agrupar eventos relacionados. Em vez de 50 alertas individuais de login falhado do mesmo IP, você recebe um alerta agrupado: "50 falhas de autenticação de 192.168.1.100 nos últimos 10 minutos".

Configure no ossec.conf:

<group>
  <rule_id>5710,5501,5502</rule_id>
  <alert_time_format>%Y-%m-%d %H:%M:%S</alert_time_format>
  <max_alerts>50</max_alerts>
  <timeframe>10</timeframe>
</group>

Isso melhora a legibilidade: um alerta agrupado vale mais que 50 espalhados.

Automação de resposta (Cortex)

Quando um alerta é real, você quer ação rápida. A integração Wazuh-Cortex permite automatizar respostas. Exemplos práticos:

• Bloquear IP automaticamente após 10 tentativas de login falhadas
• Isolar endpoint com detecção de malware
• Notificar equipe via Telegram para alertas críticos (nível 12+)

No arquivo /var/ossec/integrations/custom-cortex-integration.py:

if alert_level >= 12 and alert[rule][id] == 100200:
    block_ip(alert[srcip])
    send_telegram_message(f"IP {alert[srcip]} bloqueado - atividade suspeita detectada")

Isso reduz o tempo de resposta de horas para minutos. Em 2026, a velocidade de resposta é crítica: o custo médio de um incidente cai 60% quando detectado em menos de uma hora.

KPIs para medir sucesso

Como saber se sua otimização está funcionando? Acompanhe estes indicadores:

• Taxa de falsos positivos: (alertas investigados que não são incidentes) / (total de alertas investigados). Meta: < 15%
• Tempo de detecção (MTTD): tempo entre ataque e alerta válido. Meta: < 1 hora para incidentes críticos
• Tempo de resposta (MTTR): tempo entre alerta e resolução. Meta: < 4 horas
• Alertas por analista por dia: se > 100, há ruído excessivo

Relatório prático: um cliente no setor de saúde passou de 234 alertas/dia para 67, com MTTD reduzido de 8 horas para 47 minutos. O ROI do projeto foi de 7 meses.

Conexão com LGPD e NIS2

A LGPD Art. 46 exige que você monitore e responda a incidentes de segurança de dados. O NIS2 vai mais longe: exige detecção e notificação em até 72 horas para incidentes significativos.

Otimizar alertas não é luxo — é requisito de compliance. Se sua empresa não consegue detectar um vazamento em tempo hábil, você está em não-conformidade. Em 2026, as multas da LGPD podem chegar a 2% do faturamento.

Além disso, o NIS2 exige que você demonstre capacidade de resposta durante auditorias. Logs com ruído não servem como evidência. Você precisa de rastreabilidade clara, não um arquivo de 10GB de "nada".

Checklist de implementação

1. Baseline de 30 dias: não mude nada antes de medir
2. Identificar top 20 regras: concentre onde há mais volume
3. Criar regras de supressão: uma por vez, com anotação do motivo
4. Testar por 7 dias: verificar se nenhum incidente real foi suprimido
5. Documentar toda mudança: essencial para auditoria
6. Revisar mensalmente: padrões mudam, suas regras devem acompanhar
7. Integrar automação gradualmente: comece por um caso de uso (bloqueio de IP)

Perguntas frequentes

Posso simplesmente desabilitar todas as regras de nível baixo? Não. Nível baixo ainda pode indicar padrões suspeitos. Em vez de desabilitar, suprima com contexto. Se um evento é normal para sua empresa, crie uma regra personalizada para ignorar apenas aquele caso específico.

Quanto tempo leva para ver resultados? A primeira otimização (reduzir 50% do ruído) leva 2-3 semanas. Otimização completa (sub-15% de falsos positivos) leva 2-3 meses com ajustes contínuos.

Preciso de equipe dedicada? Para PMEs, uma pessoa dedicada (20-30h/semana) é suficiente nos primeiros 3 meses. Depois, manutenção é 5h/semana. O ROI é claro: menos tempo investigando "nada", mais tempo respondendo ao que importa.

O Wazuh Cloud é melhor para isso? O Wazuh Cloud simplifica gestão em ambientes distribuídos, mas a lógica de regras é a mesma. A diferença principal é centralização. Se você tem < 50 endpoints, a versão open-source é suficiente.