Como estruturar um programa de gestão de vulnerabilidades

Um programa de gestão de vulnerabilidades não comeca com a escolha de uma ferramenta. Comeca com uma pergunta mais dificil: quem, na organização, responde por cada ativo? Sem essa resposta, qualquer scanner produz uma lista de achados que ninguem tem obrigacao de tratar.

Este guia descreve um roteiro para estruturar o processo do zero, ou para dar consistencia a um processo que hoje depende de esforco individual.

1. Defina o escopo antes do inventário

E tentador comecar descobrindo tudo que existe na rede. Na prática, um escopo mal definido produz um inventário extenso e uma equipe pequena demais para agir sobre ele. Comece por um recorte gerenciavel — por exemplo, ativos criticos para um processo de negocio específico — e expanda depois que o ciclo completo (avaliar, priorizar, corrigir, verificar) estiver funcionando nesse recorte.

2. Estabeleca donos, não só listas

Cada ativo no inventário precisa de um responsavel nomeado. Sem isso, a etapa de correcao não tem para onde ir: o achado fica documentado, mas ninguem o trata porque, formalmente, não e responsabilidade de ninguem.

3. Escolha um critério de priorização e escreva-o

A tentacao mais comum e priorizar apenas pela nota de severidade (CVSS). Funciona no começo e para de funcionar quando o volume cresce, porque a nota não diz nada sobre a probabilidade real de exploracao nem sobre a criticidade daquele ativo específico. Um critério simples, documentado e aplicado de forma consistente vale mais do que um critério sofisticado que só uma pessoa entende. Veja CVE, CVSS e EPSS: como interpretar para uma explicacao do que cada metrica mede.

4. Defina SLA de correcao por criticidade

Prazos de correcao diferentes para severidades diferentes — e, quando possível, para classes de ativo diferentes. Um prazo único para tudo tende a ser violado sistematicamente para os itens de menor severidade, o que corroi a credibilidade do próprio SLA.

5. Trate exceções como decisão, não como omissão

Nem toda vulnerabilidade sera corrigida no prazo. Sistemas legados, janelas de manutencao restritas e ausencia de correcao do fabricante são motivos legitimos. A diferença entre um programa maduro e um programa que só parece maduro está em registrar essas excecoes formalmente — com prazo de revisão e responsavel — em vez de deixa-las simplesmente pendentes.

6. Meca resultado, não atividade

Número de vulnerabilidades encontradas mede quanto a ferramenta trabalhou, não quanto o risco caiu. Metricas mais úteis:

• Tempo médio de correcao por criticidade.
• Percentual do inventário avaliado no último ciclo.
• Backlog de itens criticos em aberto, comparado ao ciclo anterior.

Quando o processo pede uma plataforma

Enquanto o volume de dados cabe em um relatorio e envolve uma ou duas pessoas, um scanner dedicado como o Nessus Professional tende a ser suficiente. Quando o processo passa a envolver multiplas equipes, multiplas fontes de dados e a necessidade de reportar risco de forma consolidada, o gargalo se move da avaliação para a priorização e a consolidacao — e e ai que uma plataforma de gerenciamento de exposição como o Tenable One passa a fazer sentido. Veja o que e Exposure Management para entender essa transicao em detalhe.