O pacote mensal de correções de agosto da Microsoft veio pesado: mais de 400 falhas de uma vez, dezenas delas classificadas como críticas, e pelo menos uma já sendo explorada por atacantes antes mesmo da correção sair. Diante de uma lista desse tamanho, muita equipe de TI sente o mesmo aperto: por onde começar?
A resposta prática não é “corrija tudo agora”, porque isso é impossível e paralisante. É “priorize com critério”. Este texto é um guia de como transformar uma montanha de correções numa fila que faz sentido.
Nem toda falha pesa igual
O erro comum é tratar a lista como se todas as falhas fossem urgentes do mesmo jeito. Não são. Duas perguntas separam o que precisa de pressa do que pode esperar:
| Pergunta | Por que decide a prioridade |
|---|---|
| A falha já está sendo explorada? | Uma falha em uso ativo é emergência, não importa a nota |
| O sistema afetado está exposto? | O que a internet alcança corre mais risco que o interno |
| O que o atacante ganha com ela? | Controle total pesa mais que um incômodo menor |
| Você realmente usa aquilo? | Corrigir o que não roda é gastar energia à toa |
No pacote deste mês, uma das falhas já explorada permitia a um usuário local com pouco privilégio virar administrador da máquina. Esse tipo, explorado e de alto impacto, vai para o topo da fila, na frente de dezenas de outras com nota alta mas sem uso ativo conhecido.
A janela que decide o desfecho
O intervalo entre a correção sair e ela ser aplicada é onde o ataque mora. Foi assim no caso Equifax, onde uma falha com correção disponível havia meses continuou aberta até virar um dos maiores vazamentos da história. A correção existir não protege ninguém; a correção aplicada, sim.
Por isso a meta não é zerar a lista, é fechar rápido a parte que mais expõe. Um punhado de falhas críticas e exploradas, corrigidas em dias, protege mais do que a lista inteira corrigida em meses.
Um processo que sobrevive ao volume
Para não afundar a cada pacote mensal, vale ter um método fixo:
- Saiba o que você tem. Sem inventário, não dá para saber o que a lista te afeta. Foi a lição da Log4Shell: ninguém corrige o que não sabe que roda.
- Cruze a lista com o que é exposto e crítico. Comece por aí.
- Priorize o que já está sendo explorado. Emergência real fura a fila.
- Teste antes de aplicar em massa, para a correção não virar o próprio incidente.
- Registre o que ficou pendente e por quê, para não perder o rastro do risco aceito.
O básico que protege mais que o avançado
Pacotes gigantes de correção assustam, mas escondem uma boa notícia: a esmagadora maioria dos ataques usa falhas conhecidas, com correção disponível, que ficaram sem aplicar. Ou seja, a defesa mais eficaz não é a tecnologia mais nova, é a disciplina de corrigir a tempo o que importa. Quem domina a priorização transforma o susto mensal de centenas de falhas numa rotina controlada, e tira do atacante justamente a porta que ele mais usa: a que já tinha fechadura, mas ninguém trancou.