Gestão de vulnerabilidades é o processo contínuo de identificar, priorizar, corrigir e verificar as falhas de segurança dos sistemas, aplicações e dispositivos de uma empresa. Ela se repete em ciclos: a cada varredura surgem falhas novas, as antigas mudam de prioridade quando passam a ser exploradas, e cada correção precisa ser confirmada antes de o item sair da lista.
Para a equipe de TI de uma empresa de médio porte, o desafio raramente está em encontrar vulnerabilidades, porque qualquer ferramenta de varredura retorna centenas delas. A dificuldade é decidir o que corrigir primeiro, em quanto tempo e como mostrar à diretoria que o risco está diminuindo. A seguir, mostramos como organizar esse ciclo para que ele caiba na rotina de uma equipe pequena.
Análise pontual ou gestão contínua: qual a diferença
Uma análise de vulnerabilidades é uma fotografia: mostra as falhas que existem em um dia específico. A gestão de vulnerabilidades é o acompanhamento dessa fotografia ao longo do tempo, com responsáveis, prazos e verificação. As duas se completam, e o pentest entra como uma terceira peça.
| Análise de vulnerabilidades | Gestão de vulnerabilidades | Pentest | |
|---|---|---|---|
| O que entrega | Lista de falhas encontradas em uma varredura | Falhas corrigidas, com prazo e evidência | Prova de até onde um atacante chegaria |
| Frequência | Pontual ou periódica | Contínua | Uma ou duas vezes por ano, ou após grandes mudanças |
| Quem participa | Segurança | Segurança, infraestrutura, desenvolvimento e donos dos sistemas | Equipe externa e segurança |
| Pergunta que responde | O que está vulnerável hoje? | O risco está caindo mês a mês? | As defesas aguentam um ataque real? |
As cinco etapas do ciclo de gestão de vulnerabilidades
Os elevadores de um prédio comercial passam por manutenção todo mês, mesmo quando funcionam bem. O técnico segue uma lista fixa de itens, inspeciona cada um, troca primeiro o que afeta a segurança dos passageiros, testa o elevador depois do reparo e registra tudo no livro de manutenção. O ciclo de gestão de vulnerabilidades tem a mesma disciplina:
- Inventário. Servidores, computadores, aplicações, serviços em nuvem e equipamentos de rede, cada um com um responsável. O que não está no inventário não entra na varredura.
- Varredura. Ferramentas especializadas inspecionam cada ativo e comparam versões e configurações com bases públicas de falhas conhecidas. Ativos expostos à internet pedem varreduras mais frequentes que os internos.
- Priorização. Nem toda falha merece a mesma urgência, assim como, no elevador, uma lâmpada queimada no painel pode esperar e um freio com defeito não. A próxima seção mostra os critérios.
- Correção. Na maior parte dos casos, significa aplicar um patch de segurança; em outros, mudar uma configuração ou desativar um serviço que ninguém usa.
- Verificação. Uma nova varredura confirma que a falha sumiu. Só então ela sai da lista, e o registro fica como evidência para auditorias.
O ciclo recomeça em seguida. Um caso muito comum é a empresa que faz as quatro primeiras etapas com cuidado e pula a quinta: o chamado é fechado quando o patch é instalado, mas a atualização não foi aplicada em parte dos computadores, e ninguém percebe até a varredura do mês seguinte.
Como priorizar vulnerabilidades além da nota CVSS
Cada falha catalogada publicamente recebe um identificador CVE (Common Vulnerabilities and Exposures) e, em geral, uma nota CVSS (Common Vulnerability Scoring System), que vai de 0 a 10 e mede a gravidade técnica. A nota é um bom ponto de partida, mas ordena a lista sem olhar para a sua empresa: uma falha 9,8 em um servidor isolado pode ser menos urgente que uma 7,5 em um sistema aberto à internet. Por isso, as equipes que priorizam bem cruzam a nota com outros quatro critérios.
| Critério | Pergunta que responde | Onde encontrar |
|---|---|---|
| Gravidade técnica | Quão grave é a falha em si? | Nota CVSS publicada para cada CVE |
| Exploração em andamento | Alguém já está usando essa falha em ataques reais? | Catálogo KEV (Known Exploited Vulnerabilities) da CISA, a agência de cibersegurança do governo dos Estados Unidos |
| Probabilidade de exploração | Qual a chance de ela ser explorada nos próximos 30 dias? | EPSS (Exploit Prediction Scoring System), mantido pelo FIRST, o mesmo fórum que mantém o CVSS |
| Exposição | O ativo pode ser alcançado pela internet? | O seu inventário e a configuração do firewall |
| Importância do ativo | O que deixa de funcionar se esse sistema cair? | Os donos de cada sistema na empresa |
Um exemplo ajuda a ver o efeito. Na mesma semana, a varredura encontra três falhas: uma com nota 9,8 em um servidor de testes sem acesso à internet; outra com nota 7,5 na VPN usada pelo trabalho remoto, já listada no catálogo KEV; e uma terceira com nota 8,1 no ERP, que não está no KEV, mas tem probabilidade alta de exploração no EPSS. Pela nota, a ordem seria servidor de testes, ERP e VPN. Pelo risco real, a VPN vem primeiro, porque está exposta à internet e a falha já é explorada em ataques reais; o ERP vem em seguida, porque a chance de exploração é alta e a operação depende dele; e o servidor de testes entra na próxima janela de manutenção.
Na prática, a ordem fica assim: primeiro, o que está no catálogo KEV e exposto à internet; depois, as falhas com probabilidade alta no EPSS ou nota alta em sistemas críticos; por último, o restante, agrupado em janelas de manutenção. Essa ordem reduz bastante a lista de urgentes, a ponto de uma equipe pequena conseguir tratá-la dentro do prazo.
Prazos de correção e o que fazer quando não dá para corrigir
Prioridade sem prazo vira só uma lista mais organizada. O passo seguinte é combinar, por escrito, em quanto tempo cada nível deve ser corrigido. Segue um exemplo de política, não uma norma, que deve ser ajustada à realidade de cada empresa:
| Prioridade | Exemplo | Prazo sugerido |
|---|---|---|
| Crítica | Falha do catálogo KEV em ativo exposto à internet | Até 7 dias |
| Alta | Nota CVSS alta em sistema importante para a operação | Até 30 dias |
| Média | Falha em ativo interno, sem exploração conhecida | Até 90 dias |
| Baixa | Falha de baixo impacto em ativo pouco usado | Próxima janela de manutenção |
Para cumprir esses prazos sem depender de trabalho manual, muitas equipes automatizam a distribuição de patches com ferramentas de gestão remota, como a plataforma NinjaOne, e reserva o tempo da equipe para os casos que exigem teste antes da atualização.
Quando a correção não é possível
Sempre haverá sistemas que não podem ser atualizados no prazo: um software antigo de que a produção depende, um equipamento cujo fabricante não publica mais correções ou uma falha nova ainda sem patch. Nesses casos, a falha não some da lista; ela vira uma exceção formal, com três elementos:
- ☐ Um controle compensatório, como isolar o sistema em uma rede separada, bloquear a porta afetada ou reforçar o monitoramento daquele ativo.
- ☐ Um responsável na área de negócio que aceita o risco por escrito.
- ☐ Uma data de revisão, para que a exceção não se torne permanente por esquecimento.
Os indicadores que mostram à diretoria que o risco está caindo
A diretoria não precisa ver a lista de CVEs. Precisa saber se o investimento está reduzindo o risco. Quatro indicadores respondem a isso com poucos números:
- Tempo médio de correção por prioridade. Mostra se os prazos combinados estão sendo cumpridos, e onde não estão.
- Cobertura da varredura. A porcentagem de ativos do inventário que foram varridos no mês. Cobertura baixa significa falhas que ninguém está vendo.
- Falhas críticas fora do prazo. É o número que mais interessa à diretoria, porque concentra o risco real.
- Exceções ativas. Quantas falhas estão aceitas formalmente e quando cada uma volta a ser revisada.
O formato que mais funciona é uma página só: os quatro números no topo, um gráfico simples com a evolução dos últimos meses e, embaixo, as três ou quatro falhas que precisam de decisão da diretoria, como uma janela de manutenção em um sistema crítico ou uma exceção que vence no mês. O detalhe técnico fica em um anexo para quem quiser consultar.
Apresentados todo mês, sempre no mesmo formato, esses números permitem comparar um período com o outro. Assim, a conversa com a diretoria passa a girar em torno da tendência: em três meses, as críticas fora do prazo caíram ou subiram?
Quatro erros que fazem o ciclo travar
Quando o ciclo para de avançar, a causa costuma estar no processo. Estes são os tropeços que mais aparecem nas empresas que atendemos:
| Erro | O que acontece | Como evitar |
|---|---|---|
| Inventário só do escritório | Serviços em nuvem, notebooks de quem trabalha em casa e sistemas contratados por outras áreas ficam fora da varredura | Revisar o inventário a cada trimestre com as áreas de negócio e com as faturas de serviços em nuvem |
| Varredura sem credenciais | A ferramenta olha cada ativo só por fora e deixa de ver versões de software e configurações internas | Fazer varreduras autenticadas, com uma conta de leitura criada só para isso |
| Corrigir tudo de uma vez no fim do mês | Uma falha crítica descoberta no dia 2 espera quase 30 dias pela janela de manutenção | Separar as críticas do lote mensal e tratá-las no prazo próprio |
| Donos dos sistemas fora da conversa | As áreas não liberam janelas de manutenção porque não sabem o que está em jogo | Combinar janelas fixas com cada área e mostrar o risco em linguagem de negócio |
Equipe interna ou serviço gerenciado: quem executa o ciclo
As ferramentas de varredura são acessíveis; o que pesa é o tempo de quem opera o ciclo todo mês, revisa falsos positivos, negocia janelas de manutenção com as áreas e prepara os relatórios. Em equipes pequenas, essa rotina compete com o suporte do dia a dia e costuma perder.
Por isso, muitas empresas mantêm a decisão e a aprovação das exceções dentro de casa e passam a execução do ciclo para um fornecedor. Discutimos essa divisão em detalhe no artigo sobre terceirização de TI e segurança.
Na TecnetOne fazemos a análise de vulnerabilidades de IPs, domínios e aplicações web com relatórios revisados por um engenheiro e as falhas priorizadas por impacto no seu negócio.
Perguntas frequentes sobre gestão de vulnerabilidades
Significa tratar as falhas de segurança como um processo contínuo, com responsáveis e prazos, em vez de correções isoladas. Uma vulnerabilidade é uma falha que pode ser explorada para invadir ou prejudicar um sistema; o termo corresponde ao inglês vulnerability management.
Depende da exposição de cada ativo. Sistemas acessíveis pela internet pedem varreduras frequentes, idealmente contínuas. Para os ativos internos, uma referência prática é acompanhar o ciclo mensal de atualizações da Microsoft, publicado na segunda terça-feira de cada mês, e varrer logo depois de aplicá-lo.
Não. A varredura encontra falhas conhecidas em grande escala; o pentest combina falhas e configurações como um atacante faria para mostrar até onde ele chegaria. Na prática, os achados do pentest entram no ciclo de gestão como qualquer outra falha, com prioridade e prazo.
Vulnerabilidade é a falha no sistema; ameaça é quem ou o que pode explorá-la; risco é a combinação das duas com o impacto para o negócio. A gestão de vulnerabilidades atua na primeira parte: reduz as falhas disponíveis para quem quiser atacar.
Pode ajudar. O artigo 46 da LGPD determina que os agentes de tratamento adotem medidas de segurança, técnicas e administrativas, aptas a proteger os dados pessoais. Um processo documentado de correção de falhas é uma forma de demonstrar essas medidas. Para avaliar o caso da sua empresa, consulte a sua equipe jurídica.
Sou apaixonado por SEO e copywriting na TecnetOne, onde combino conhecimento de tecnologia com otimização e redação persuasiva. Uso ferramentas e técnicas avançadas para aumentar a visibilidade on-line das empresas, para que estejam na vanguarda da tecnologia e alcancem resultados expressivos em um ambiente digital competitivo. Meu objetivo é criar estratégias eficazes que impulsionem o sucesso tecnológico e comercial dos nossos clientes.
