Muita empresa confunde gestão de vulnerabilidades com rodar um scanner uma vez por ano. O resultado é sempre o mesmo: um relatório de trezentas páginas com milhares de itens, que assusta, ninguém lê inteiro, e nada é corrigido. No ano seguinte, roda-se de novo e a lista está maior.
Gestão de vulnerabilidades não é encontrar problemas. É um ciclo que termina em problema corrigido, e recomeça.
As quatro etapas do ciclo
- Descobrir: saber o que você tem e o que cada coisa expõe.
- Priorizar: decidir o que corrigir primeiro, porque corrigir tudo é impossível.
- Corrigir: a etapa que de fato reduz risco, e a que mais empaca.
- Verificar: confirmar que a correção funcionou e não quebrou outra coisa.
A maioria para na primeira. É por isso que tantas empresas têm relatórios de vulnerabilidade e, mesmo assim, são comprometidas por uma falha que estava na lista.
Etapa 1: você não protege o que não conhece
Scanner só encontra o que ele sabe que existe. Antes de escanear, é preciso saber o que a empresa tem exposto, e esse levantamento se faz com o método que descrevi em Mapeando a superfície de ataque de uma empresa.
O ativo que ninguém lembrava, o servidor de teste que ficou no ar, é justamente o que não entra no escopo do scanner e vira a porta de entrada. Inventário atualizado é pré-requisito, não detalhe.
Etapa 2: priorizar, porque a severidade sozinha engana
Aqui está o erro que trava tudo. A empresa ordena a lista pela severidade que o scanner atribuiu, começa pelas críticas e afoga. O problema é que a severidade genérica ignora o seu contexto.
Uma falha classificada como crítica em um servidor interno, sem acesso externo e sem dado sensível, é menos urgente do que uma falha média em um sistema exposto à internet que processa pagamento. A priorização real cruza três perguntas:
| Pergunta | Por que importa |
|---|---|
| A falha é acessível de fora? | O que está exposto é atacado primeiro |
| Existe exploração conhecida circulando? | Falha com ataque pronto é muito mais urgente que falha teórica |
| O que roda ali dói se cair? | Sistema crítico eleva a prioridade de qualquer falha |
Uma falha explorada ativamente, em sistema exposto e crítico, é emergência independentemente da nota do scanner. Uma falha teórica, interna, em sistema sem importância, pode esperar. Priorizar assim reduz uma lista de milhares a uma dezena de itens que realmente importam esta semana.
Etapa 3: fazer a correção acontecer
Esta é a etapa que separa segurança de teatro de segurança. Encontrar é fácil e vira relatório bonito. Corrigir exige mexer em produção, coordenar com quem opera o sistema e assumir o risco de a atualização quebrar algo.
O que faz a correção acontecer não é técnico, é organizacional:
- Dono definido. Cada item priorizado tem um responsável nominal, não “a equipe de TI”.
- Prazo proporcional ao risco. Crítico exposto em dias, o resto em janelas planejadas.
- Janela de manutenção previsível. Correção sem espaço para acontecer não acontece.
- Registro do que foi decidido não corrigir. Aceitar um risco conscientemente é gestão; ignorá-lo é omissão.
Etapa 4: verificar, e recomeçar
Correção não conferida é suposição. Depois de aplicar, escaneie de novo aquele item específico para confirmar que a falha sumiu, e teste que o sistema continua funcionando. Correção que resolve a vulnerabilidade e derruba a aplicação não é vitória.
E então o ciclo recomeça, porque software novo surge, sistema novo entra, e falha nova é descoberta todo dia. Gestão de vulnerabilidades é uma esteira contínua, não um projeto com fim.
A frequência certa
Escaneamento anual é quase inútil: a foto envelhece no dia seguinte. O padrão razoável para uma empresa de médio porte é escaneamento contínuo ou ao menos mensal do que é exposto, com reavaliação imediata sempre que uma falha grave e explorada vira notícia.
O caso Dígitro, que analisei em outro texto, mostra por que a velocidade importa: entre uma falha virar pública e ser explorada em massa, o intervalo é curto. Quem escaneia uma vez por ano descobre tarde demais.
O indicador que importa
Não meça quantas vulnerabilidades você encontrou; isso só mede o scanner. Meça o tempo entre descobrir e corrigir uma falha grave. É esse número que diz se a empresa está reduzindo risco ou apenas colecionando relatórios. Se ele está caindo, a gestão funciona. Se está estável e alto, você tem um scanner, não um programa.