Vou aplicar patches de segurança
Resposta rápida
Aplicar patches de segurança é o trabalho silencioso que mais previne incidente. O ciclo bem feito tem cinco etapas: identificar vulnerabilidades novas via fonte oficial (boletim do fornecedor, CISA KEV, alertas do scanner interno), classificar por criticidade real (não só CVSS — considere se há exploit público, se o sistema é exposto, se a vulnerabilidade é remotamente explorável), priorizar fila por SLA por criticidade (crítico em 72 horas, alto em duas semanas, médio no ciclo mensal), testar em ambiente de homologação quando possível, aplicar em janela controlada com plano de rollback. CVE crítico com exploit ativo segue processo emergencial que pula o ciclo mensal. Sem disciplina de patching, vulnerabilidade conhecida fica aberta por meses — e é por aí que entra a maior parte dos ataques bem-sucedidos.
Na empresa pequena, patching geralmente é responsabilidade do MSP em servidores e do próprio Windows Update nas estações. O risco é dupla cegueira: pessoa não sabe se o MSP está aplicando regularmente, e Windows Update individual depende de cada usuário não adiar. A disciplina mínima viável: confirmar trimestralmente com o MSP quais patches foram aplicados nos servidores e cobrar relatório; ativar Windows Update for Business ou política de domínio para empurrar atualizações em estações; ter uma planilha simples de inventário (sistemas, versão atual, última atualização). Para CVE crítico do tipo que vira manchete (Log4j, MOVEit, ProxyShell), responsabilidade é cobrar ação rápida do MSP — não esperar o ciclo mensal. Em empresa pequena, o difícil é saber o que está exposto, não decidir patchar; visibilidade resolve metade do problema.
Na empresa média, patching ganha estrutura: ferramenta de gestão (WSUS, SCCM, Intune, ferramenta MDM, distribuição via Ansible/Puppet em Linux), janela mensal formal para o ciclo regular, processo emergencial para CVE crítico. Scanner de vulnerabilidade interno (Nessus, Qualys, OpenVAS, Rapid7) começa a fazer sentido para visibilidade do que está exposto. O risco característico desse porte é a exceção que vira regra: sistema legacy que "não pode ser atualizado", aplicação que travou em versão antiga, servidor pessoal de alguém. Cada exceção justificada vira anos sem atualização, e o conjunto delas é a superfície de ataque real. Disciplina de exceção com prazo, dono e compensação (segregação de rede, monitoramento extra) é o que evita o legacy virar passivo crônico.
Na empresa grande, patching é processo industrializado com scanner contínuo de vulnerabilidades, integração ao SOC, automação via configuration management, distribuição em anéis de risco (laboratório, piloto, produção geral), SLA formal por criticidade, KPI rastreado. Ferramenta enterprise (Tenable, Qualys, Rapid7, Microsoft Defender Vulnerability Management) gera a fila priorizada. O risco aqui é volume: milhares de vulnerabilidades abertas a qualquer momento, equipe pequena de patching, fila crescendo. Priorização por exploit ativo (CISA KEV catalog, exploit-DB) é o filtro que separa o que importa do ruído — CVSS alto sem exploit é menos urgente que CVSS médio com exploit em uso. Métrica que importa: mean time to patch crítico, percentual de ativos no compliance window, vulnerabilidades acima do SLA.
- Você não sabe o quanto seus sistemas estão atualizados hoje
- Patch crítico de boletim recente ainda não foi aplicado
- Existem sistemas "que não podem ser atualizados" há anos
- Não há processo definido para CVE crítico emergencial
- Atualizações são aplicadas só quando algo já quebrou
- Scanner de vulnerabilidade nunca foi rodado ou está desatualizado
Priorizar patch pela ameaça real, não só pelo CVSS
O CVSS (Common Vulnerability Scoring System) dá uma nota de 0 a 10 para a gravidade técnica de uma vulnerabilidade. É útil, mas é só uma parte. Priorização madura considera três dimensões adicionais: existe exploit público disponível? A vulnerabilidade é explorável remotamente ou exige acesso local? O ativo afetado está exposto à internet ou em rede interna segregada?
CVSS alto sem exploit é menos urgente do que CVSS médio com exploit ativo em uso. Vulnerabilidade interna em rede segregada é menos urgente do que vulnerabilidade em servidor exposto. O catálogo KEV (Known Exploited Vulnerabilities) da CISA é referência prática — quando uma vulnerabilidade entra nesse catálogo, prioridade máxima independente da nota CVSS.
SLA típico por criticidade
Crítico (CVE com exploit ativo, sistema exposto): 72 horas. Processo emergencial: análise, teste curto, janela emergencial, aplicação.
Alto (CVE alto, sem exploit ativo conhecido): 14 dias. Pode esperar o próximo ciclo se ele for em até duas semanas.
Médio (CVE médio): 30 dias. Ciclo mensal regular.
Baixo: 90 dias ou próximo refresh do sistema.
- Atualize a fila de vulnerabilidades. Scanner interno, boletins de fornecedor, fontes de threat intelligence (CISA KEV, mailing lists especializadas).
- Classifique cada nova entrada. Criticidade, exploit ativo, exposição do ativo. Cada vulnerabilidade recebe SLA conforme matriz.
- Defina o lote do ciclo. Tudo do SLA do mês mais o que entrar de novo no nível médio. Crítico já saiu via processo emergencial.
- Teste em homologação. Para patches em sistemas críticos, validar em ambiente de teste antes de produção. Atalho ocasional vira retrabalho caro quando o patch quebra a aplicação.
- Aplique em anéis de risco. Primeiro estações de teste, depois piloto controlado, depois produção geral. Em escala, automação distribui os anéis.
- Comunique janelas perceptíveis. Reboot que afeta sistemas críticos, qualquer aplicação que cai, qualquer mudança visível ao usuário.
- Verifique cobertura. Pós-ciclo, scanner roda de novo. Patches aplicados? Sistemas que falharam por algum motivo entram em retentativa imediata.
O processo emergencial para CVE crítico
Quando aparece CVE crítico com exploit ativo, o ciclo mensal não serve — a janela é de horas a poucos dias. Processo emergencial precisa estar definido antes da crise: quem decide aplicar fora de ciclo, qual o procedimento mínimo (não pula rollback, mas pula etapas demoradas de aprovação), como comunicar com urgência, como medir conclusão.
Em janela emergencial, três disciplinas mantêm-se mesmo na pressa: backup ou snapshot antes da aplicação, plano de rollback escrito mesmo que curto, validação pós-aplicação. O custo de aplicar patch mal validado em emergência costuma ser maior do que esperar duas horas extras para fazer certo.
Como tratar sistemas que não podem ser patcheados
Toda empresa tem alguns: sistema legacy que travou em versão antiga, equipamento médico ou industrial sem update do fabricante, software de fornecedor que perdeu suporte. A resposta correta não é ignorar — é compensar.
Compensações típicas: segregação de rede (sistema isolado, com acesso restrito por firewall), monitoramento extra (qualquer atividade incomum dispara alerta imediato), redução de superfície (desativar serviços não usados, fechar portas não necessárias), prazo para substituição registrado no roadmap. Cada exceção tem dono, justificativa escrita, controles compensatórios e prazo. Sem isso, "exceção" vira "indefinida" e o passivo de segurança cresce em silêncio.
Patchar pelo CVSS sozinho. Sem considerar exploit ativo e exposição, fila prioriza errado. CVE crítico interno sem exploit pode esperar; CVE médio externo com exploit precisa de hoje.
Janela única em produção sem anéis. Quando o patch quebra algo, difícil isolar a causa. Aplicar em anéis (lab, piloto, produção) cria pontos de detecção antes da escala.
Exceção permanente sem compensação. Sistema "que não pode patchar" sem segregação de rede e monitoramento extra é convite. Cada exceção precisa de dono, prazo e controle compensatório.
Patching sem scanner pós-validação. Aplica e assume sucesso. Patch que falhou em algum host fica invisível até o scanner próximo apontar a mesma vulnerabilidade não corrigida.
- Inventário de ativos está atualizado
- Scanner de vulnerabilidade rodou no mês
- Fila de vulnerabilidades foi priorizada por exploit e exposição
- SLAs por criticidade estão dentro do alvo
- Crítico recente foi aplicado via processo emergencial
- Patches do ciclo foram testados em homologação onde aplicável
- Aplicação em produção seguiu anéis de risco
- Exceções têm dono, prazo e controle compensatório registrados
- Scanner pós-validação confirmou cobertura