Gestão de vulnerabilidades.

Um ciclo, não uma varredura

A gestão de vulnerabilidades é muitas vezes reduzida a «executar o scanner», mas a varredura é a parte fácil. A disciplina é um ciclo que se repete: manter um inventário preciso do que se possui, descobrir as fraquezas nesses ativos, priorizar o punhado que realmente importa, remediá-las e verificar se a correção se manteve. Um scanner moderno entregará milhares de achados num parque de porte médio. Tratar essa lista como uma fila de tarefas é a forma como as equipas se esgotam enquanto a sua exposição real permanece aberta. O valor está no funil, dos milhares de achados em bruto até ao pequeno conjunto sobre o qual se atua esta semana.

Também depende de algo que a maioria das equipas subestima: conhecer o seu parque. Uma vulnerabilidade num servidor exposto à Internet que executa uma aplicação de negócio crítica é um problema diferente da mesma falha numa máquina de teste isolada. Sem inventário de ativos nem titularidade, a priorização não tem nada em que se apoiar, razão pela qual o ciclo começa pela descoberta e identificação em vez da varredura em si.

O vocabulário: CVE, CVSS e KEV

Três pontos de referência sustentam a maior parte da conversa sobre priorização, e os profissionais usam-nos em combinação em vez de isoladamente.

O erro comum é ordenar pela pontuação CVSS e trabalhar de cima para baixo. Um CVSS alto num ativo que ninguém consegue alcançar importa menos do que uma falha de gravidade média que consta num catálogo de vulnerabilidades conhecidas por estarem a ser exploradas num sistema exposto. Os programas maduros combinam a gravidade teórica com sinais reais: existe um exploit funcional, a vulnerabilidade está a ser ativamente explorada, e quão exposto e crítico é o ativo afetado. É essa combinação, não a pontuação em bruto, que conduz a fila.

A priorização é todo o trabalho

O enquadramento honesto é que a priorização é o produto da gestão de vulnerabilidades. As entradas são a criticidade do ativo, a disponibilidade de um exploit e a exposição do negócio, e a saída é uma decisão defensável sobre o que é corrigido primeiro e o que espera. É aqui que a função justifica o seu valor, porque nenhuma equipa pode nem deve remediar tudo de uma só vez.

1. Criticidade do ativo: o que o sistema faz pelo negócio e o que pode alcançar se for comprometido.
2. Disponibilidade de um exploit: se existe um exploit funcional e se a falha está a ser usada em circulação.
3. Exposição do negócio: o ativo está exposto à Internet, que dados detém, e que controlos compensatórios já se encontram à sua frente.

Onde se enquadra na governança

A gestão de vulnerabilidades raramente é opcional uma vez que se está dentro de um quadro reconhecido. Um SGSI ISO/IEC 27001 espera um processo definido para gerir as vulnerabilidades técnicas, e os auditores pedirão para ver o ciclo em funcionamento, não apenas uma licença de scanner. O NIST Cybersecurity Framework trata a identificação e a gestão de vulnerabilidades como centrais para as funções Identify e Protect, e regulamentos como NIS2 e DORA pressupõem que as organizações encontram e remedeiam ativamente as fraquezas em vez de esperarem que um incidente as revele. Em todos os casos, a evidência que um avaliador deseja tem a mesma forma: como descobre, como prioriza, os SLA segundo os quais remedia, e as métricas que provam que o ciclo se está a fechar.