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
| Critério |
Recomendação inicial |
Evolução controlada |
| Severity |
High |
Add Medium conforme risco |
| Confidence |
High |
Medium/Low só com validação |
| Performance Impact |
Low/Medium |
High/Critical por escopo + sizing |
| Relevância |
Apenas aplicável aos ativos |
Revisão periódica |
| Exceções |
Mínimas e granulares |
Revisar/expirar; evitar disable global |
| HTTPS Inspection |
Planejada (não automática) |
Rollout por ondas + bypass governado |
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.
