Who rated this post

Aumente cobertura sem explodir CPU, logs e falsos positivos

Ao customizar o IPS (blade IPS dentro de Threat Prevention), o objetivo não é “ligar tudo”. O objetivo é obter cobertura relevante e mensurável para o seu ambiente, controlando três variáveis críticas: precisão (falsos positivos), impacto de performance e operabilidade (volume de eventos + triagem).

1) Comece do jeito certo: perfil base + rollout controlado

1.1 Use um Threat Prevention Profile coerente como baseline

• Comece com um perfil base (ex.: “Recommended/Optimized”) em vez de construir tudo do zero no primeiro dia.
• Defina desde o início:
  • Ação padrão: Detect vs Prevent
  • Exceções: somente após evidência, não por feeling

1.2 Estabeleça baseline antes de mudar policy

Antes de habilitar mais proteções, meça em horário de pico:

• CPU / memória / throughput do gateway
• volume de eventos/logs do IPS
• top talkers / aplicações dominantes

Tuning sem baseline vira tentativa e erro — e o MTTR sobe quando algo quebra.

 

2) Critérios técnicos para escolher o que habilitar

2.1 Severity

• Use Severity para priorização: High primeiro, depois Medium conforme risco.
• Interprete corretamente: Severity indica o potencial de dano caso o ataque tenha sucesso, não “probabilidade”.

2.2 Confidence

• Priorize High Confidence para rollout inicial em Prevent:
  • menor chance de falso positivo
  • transição Detect → Prevent mais segura
• Proteções de baixa confiança exigem validação mais rigorosa e escopo menor.

2.3 Performance Impact

• Use o atributo de impacto para guiar rollout:
  • Low/Medium impact: primeira onda
  • High/Critical impact: só após sizing + validação em tráfego real
• Se o gateway está perto de saturação, prefira habilitar por escopo (rede/host/app) em vez de global.

2.4 Relevância para o ambiente (asset-driven IPS)

O IPS deve refletir sua exposição real:

• sistemas operacionais e versões em uso
• serviços expostos (HTTP/S, DNS, SMB, RDP, SIP etc.)
• aplicações críticas (ERP, VDI, APIs, SaaS)
• superfície de ataque (perímetro vs interno/DC)

IPS é mais eficaz quando “onde aplicar” faz parte do design.

 

3) Reduzindo falso positivo sem perder cobertura

3.1 Ajuste por escopo (gateway role)

• Perímetro: priorize exploits web, botnets, vetores de malware
• Interno/DC: priorize lateral movement (SMB/RDP/AD-related) conforme tráfego

3.2 Exceções devem ser granulares e baseadas em evidência

Exceção não é “desligar”. Exceção deve:

• reduzir escopo por host/rede/serviço
• permitir apenas padrão conhecido benigno
• documentar motivo (ticket/incidente/validação)
• ter prazo de revisão/expiração

Melhor prática: preferir exceções granulares a desabilitar proteção globalmente.

3.3 Desabilitar “categoria não aplicável” é ganho real

Se um OS/serviço não existe no ambiente, desabilitar categorias irrelevantes reduz CPU e ruído.

4) Tráfego criptografado: HTTPS Inspection com responsabilidade

“Ligar HTTPS Inspection” não é regra universal — é decisão arquitetural.

4.1 Quando faz sentido

• quando o risco está no tráfego web criptografado (phishing, malware delivery, exfil via SaaS/APIs) e você precisa visibilidade para Threat Prevention

4.2 Salvaguardas operacionais

• testar impacto por aplicação (pinning, mTLS, apps sensíveis)
• bypass controlado para apps quebrados
• rollout por ondas (grupos/policies)
• alinhamento com privacidade/compliance

5) Operacionalização: IPS eficiente, não barulhento

5.1 Ciclo contínuo (maturidade operacional)

• revisão semanal das proteções que mais disparam (volume + criticidade)
• análise de falsos positivos por aplicação
• mudanças pequenas e mensuráveis
• revisão trimestral de exceções (expirar exceção antiga traz valor imediato)

5.2 Atualização de proteções

• manter proteções IPS atualizadas e acompanhar mudanças relevantes
• em ambientes críticos, validar em tráfego real (staging quando possível)

6) Matriz rápida de decisão

7) Notas finais TAC-grade

• Nunca desabilite proteção sem:
  • evidência de falso positivo
  • entendimento do risco residual
  • alternativa (exceção granular, tuning, segmentação)
• IPS tuning é processo contínuo: baseline → mudança pequena → medir → repetir.
• “Mais proteção” não é “melhor segurança” se performance e visibilidade colapsarem.

Se a comunidade quiser, posso compartilhar um template prático de “Exceção bem-feita” (campos + justificativa + expiração) e um fluxo curto para identificar qual proteção está causando pico de CPU/logs.