Gerenciamento de Vulnerabilidades do Zero: O Que É, Por Que Fazer e Quais Etapas Envolve
Descubra o que são vulnerabilidades, a importância crítica do gerenciamento de vulnerabilidades (VM) para a segurança cibernética e as etapas essenciais para implementar um programa eficaz do zero. Este guia prático aborda desde a identificação até a remediação, focando em proteger sua infraestrutura contra ameaças cibernéticas.
MundiX News·26 de junho de 2026·12 min de leitura·👁 1 views
Gerenciamento de Vulnerabilidades do Zero: O Que É, Por Que Fazer e Quais Etapas Envolve
Este artigo é a Parte 1 da série "Gerenciamento de Vulnerabilidades para Iniciantes", um guia prático de VM do zero. Os capítulos são independentes, mas se desejar seguir a ordem, consulte o índice e todas as partes da série aqui.
Tudo Muito Simples
O Que São Vulnerabilidades
Vulnerabilidades, ou falhas, são falhas no código-fonte ou desvios na lógica de operação de aplicações. Há também uma variação que muitos negligenciam: "misconfigurations" (configurações incorretas) de software. Um programa pode funcionar aparentemente bem, mas com um painel administrativo acessível pela internet com login e senha padrão. Formalmente, não é um erro de código, mas na prática, é uma porta aberta. E, claro, ao falar de vulnerabilidades, não podemos deixar de mencionar os exploits. Um exploit é uma ferramenta que permite explorar uma vulnerabilidade: um programa ou fragmento de código que transforma um "buraco teórico" em acesso real ao sistema. Lembre-se do principal: vulnerabilidades existem em qualquer software. Algumas ainda não foram encontradas, outras foram encontradas, mas ainda não divulgadas. A questão não é "temos vulnerabilidades?", mas sim "quais serão encontradas primeiro: por nós ou por um invasor?".
Por Que Corrigir Vulnerabilidades
Todos entendem que a infraestrutura de uma empresa deve ter medidas de proteção: antivírus, firewall, sistema SIEM. Mas por que, além disso, é necessário corrigir vulnerabilidades em estações de trabalho ou dispositivos de borda? A razão é que um invasor obtém acesso a um segmento da rede através delas, e a partir daí, nenhum antivírus o impedirá. Ao fechar vulnerabilidades em tempo hábil, não deixamos chances para um hacker realizar eventos indesejáveis para a empresa. Idealmente, as vulnerabilidades no perímetro devem ser eliminadas primeiro, pois levam a segmentos que estão por trás de um IP público e acessíveis pela internet a qualquer um. Anteriormente, já analisamos uma metodologia de prevenção de ameaças que parte do que um invasor procura em um sistema. Definimos sistemas-chave e de destino, aos quais um invasor (nem interno, nem externo) não deve ter acesso sob nenhuma circunstância. E corrigimos vulnerabilidades para cortar caminhos para os riscos mais significativos: perdas de reputação, falhas de equipamento, interrupção de processos de negócios, roubo de dinheiro, espionagem industrial.
Onde Corrigir Vulnerabilidades
Elas Estão Aumentando
A infraestrutura de uma empresa pode ser vasta: servidores, roteadores, firewalls, estações de trabalho, impressoras, CRM, soluções de segurança da informação, dezenas de aplicações web. Onde corrigir vulnerabilidades? Idealmente, em todos os lugares. Na prática, isso é impossível: há muitas vulnerabilidades, e seu número cresce a um ritmo alarmante. Veja a dinâmica segundo os dados do CVE Program: em 2023, foram publicadas 28.818 novas CVEs; em 2024, 39.962 (um aumento de quase 39%); em 2025, 48.185 [1]. Isso representa 133 novas vulnerabilidades por dia, incluindo fins de semana. O banco de dados russo BDU FSTEC também está crescendo e já ultrapassou 89 mil registros [2]. Mesmo que você corrija todas em um belo dia, amanhã surgirão centenas de novas.
Onde Procurá-las
Zonas de Atenção Elevada
Já que não é possível fechar tudo, é preciso identificar sistemas criticamente importantes onde não devem existir vulnerabilidades que permitam a ocorrência de eventos indesejáveis. Estes incluem, primeiramente:
DMZ, ou seja, o perímetro da rede.
Sistemas-chave (por exemplo, o firewall interno no núcleo da infraestrutura, responsável pela segmentação da rede).
Sistemas de destino (bancos de dados, "1C" e tudo o que o hacker realmente procura).
É nessas três áreas que devemos prestar atenção primeiramente.
Onde Buscar Informações Sobre Vulnerabilidades
Nem sempre os próprios fornecedores de software realizam a busca por vulnerabilidades. Mais frequentemente, as "brechas" são encontradas por pesquisadores independentes de segurança, que as reportam ao desenvolvedor. O fornecedor prepara um patch, o lança e publica informações sobre a vulnerabilidade. Isso é chamado de divulgação responsável. Mas isso nem sempre acontece. Existem vulnerabilidades de dia zero (zero-day), sobre as quais o fornecedor só fica sabendo após seu uso. Falaremos detalhadamente sobre elas no capítulo sobre exploits. A abordagem ideal para uma empresa é a realização de exercícios cibernéticos e a participação em programas de bug bounty. A empresa disponibiliza seu software em uma plataforma, anuncia recompensas por vulnerabilidades encontradas e as corrige. Essa cultura já se estabeleceu na Rússia: em 2025, hackers éticos encontraram quase 14 mil vulnerabilidades através das duas maiores plataformas russas de bug bounty (Standoff Bug Bounty e BI.ZONE Bug Bounty), e os pagamentos totais aos pesquisadores ultrapassaram um quarto de bilhão de rublos [3]. Quanto mais aberto um fornecedor ao mercado, quanto mais honestamente ele fala sobre suas vulnerabilidades, melhor a percepção dos usuários. Paradoxalmente, é um fato. Embora aqui também se possa argumentar, muito frequentemente a "publicação de vulnerabilidades" é interpretada como um título sensacionalista com o contexto: tudo acabou, o software não pode mais ser usado!.
Como Organizar a Correção de Vulnerabilidades
Ciclo Contínuo de Gerenciamento de Vulnerabilidades
Este é um trabalho complexo, e falaremos sobre cada um de seus componentes separadamente nos próximos artigos. A primeira palavra-chave é "processo". Encontrar vulnerabilidades não é suficiente; é preciso saber o que fazer com elas: estudar os dados de entrada, aplicar expertise, formular SLAs, desenvolver uma metodologia de correção. Etapas para construir um processo de gerenciamento de vulnerabilidades:
Gerenciamento de Ativos (Inventário) e Categorização de Ativos
Para responder à pergunta "onde procurar vulnerabilidades", é preciso entender do que a infraestrutura é composta. O processo de vulnerability management (VM) sempre se baseia no processo de asset management (AM). O inventário, como regra, já existe no departamento de TI com base em sistemas CMDB. Mas o departamento de Segurança da Informação (SI) também deve realizá-lo, com seus próprios olhos: o TI nem sempre foca em sistemas importantes para a segurança e, sejamos honestos, nem sempre compartilha informações com os profissionais de segurança (falaremos muito sobre a interação entre esses dois departamentos e esperamos que esta série de artigos ajude a melhorar o entendimento mútuo. O mínimo necessário é: inventário de sistemas-chave, de destino e do perímetro. Também priorizamos os nós e destacamos aqueles que são o caminho mais curto para os riscos. Ao realizar a categorização, vemos quais nós exigem atenção máxima e quais podem esperar. Aqui também se formula o SLA - um acordo com o departamento de TI sobre os prazos de correção. Uma vulnerabilidade criticamente perigosa não pode ser corrigida em três meses. E se um nó não for tão importante e a vulnerabilidade não for tão grave, pode-se esperar tranquilamente pela atualização planejada: por exemplo, para o Windows - o próximo Patch Tuesday. Aliás, a partir de 1º de março de 2026, para sistemas de informação estatais, os prazos de correção não serão mais um assunto interno da empresa: a Ordem FSTEC nº 117 exige a correção de vulnerabilidades críticas em 24 horas e de altas em 7 dias [4]. O regulador efetivamente introduziu um SLA obrigatório. Mais detalhes sobre isso no capítulo sobre as particularidades do gerenciamento de vulnerabilidades na Rússia.
Busca por Vulnerabilidades e sua Priorização
Antes de definir o SLA, as vulnerabilidades precisam ser encontradas. O método - manual, com ferramentas open source ou produtos comerciais - não é tão importante. O principal é obter uma imagem honesta dos pontos fracos. E, em seguida, categorizar as próprias vulnerabilidades: quais delas são realmente perigosas em sua infraestrutura específica. Analisaremos detalhadamente os métodos de avaliação e priorização mais tarde.
Como Corrigir Vulnerabilidades
Em seguida, é preciso decidir o que fazer com cada vulnerabilidade: corrigir, aplicar medidas compensatórias ou desativar o software. As principais medidas de correção são a instalação de atualizações ou a aplicação de medidas compensatórias. Medidas compensatórias são necessárias quando uma vulnerabilidade não pode ser corrigida com um patch ou quando não é viável (por exemplo, um ativo está prestes a ser desativado). O processo mais eficaz: a maioria das vulnerabilidades é corrigida durante as atualizações regulares, e as tendências e não corrigidas - fora do plano, em acordo com a SI. Falaremos mais sobre isso em um dos próximos artigos.
Correção de Vulnerabilidades, Frequentemente um Processo de Gerenciamento de Patches
Na verdade, a correção é mais frequentemente a instalação de um patch e se integra a um processo separado, cujo responsável são os especialistas de TI. O método de implantação de patches geralmente é escolhido com base no tamanho e complexidade da infraestrutura. Onde há poucas máquinas, as atualizações são frequentemente instaladas manualmente, uma a uma - e isso funciona bem. Em redes grandes e complexas, isso não funciona mais: sistemas centralizados entram em ação, que distribuem os patches automaticamente. A vantagem da automação é clara. Menos operações manuais significam menos erros. As atualizações são distribuídas mais rapidamente. E também podem ser instaladas quando a carga nos sistemas é mínima - por exemplo, à noite. Eu mesmo pessoalmente fui a janelas tecnológicas às 2 da manhã para atualizar clusters de equipamentos de rede, para conseguir fazer tudo antes do amanhecer, pois o serviço deve funcionar continuamente durante o dia.
Controle da Correção e Melhoria do Processo
Dar uma tarefa não é suficiente, é preciso verificar se ela foi concluída. Caso real: conversamos com um cliente que possui um scanner de vulnerabilidades, perguntamos: "Vocês escanearam a infraestrutura, e depois o quê?" Resposta: "Recebemos o relatório e o entregamos ao departamento de TI para que realizem o gerenciamento de patches". Só isso. Sem relatório diferencial, sem comparação com os resultados do próximo escaneamento. O departamento de TI poderia nem ter aberto esses relatórios, e ninguém notaria. Os relatórios chegam, o TI opera de acordo com seu processo interno, as vulnerabilidades se acumulam. E, por último, a melhoria do processo. Soa banal, mas o objetivo é específico: o tempo de correção de vulnerabilidades deve diminuir a cada trimestre. Se não diminuir, o processo se degrada.
Problemas Típicos
Recentemente, houve uma transmissão ao vivo da AM Live sobre gerenciamento de vulnerabilidades. E em uma das pesquisas, os espectadores nomearam os principais obstáculos para um gerenciamento de vulnerabilidades completo em suas organizações:
(Gráfico de pesquisa: "Qual é o principal obstáculo para o gerenciamento completo de vulnerabilidades?")
E aqui estão os problemas que eu destacaria especificamente:
Falta de inventário.
Muitas vulnerabilidades.
SLAs de baixa qualidade ou ausentes.
Falta de categorização de vulnerabilidades.
Violação dos prazos de correção acordados.
Os reguladores, aliás, sabem muito bem desses problemas. O FSTEC em 2022 publicou uma metodologia para avaliar a criticidade das vulnerabilidades (atualizada em junho de 2025), em maio de 2023 - um guia para organizar o processo de gerenciamento de vulnerabilidades, e a Ordem nº 117 tornou esse processo obrigatório para sistemas estatais [4]. O NKCKI tem sua própria metodologia de tomada de decisão sobre atualizações. A tendência é clara: o gerenciamento de vulnerabilidades está se transformando de uma "boa prática" em um requisito.
No final de 2022 (e em outros anos não foi diferente), o NKCKI em seu relatório citou vulnerabilidades não corrigidas no perímetro como o principal caminho de penetração de invasores na infraestrutura interna. Um exemplo ilustrativo é a vulnerabilidade ProxyLogon no Microsoft Exchange, publicada em 2021. Anos após o lançamento do patch, ainda a encontrávamos em 1 em cada 3 clientes. O patch existe. Há anos. Simplesmente não é aplicado. Por quê? As respostas são sempre diferentes, veja a captura de tela acima, há muitos problemas!.
Importância do Processo VM. Objetivos e Tarefas
O cenário de ameaças cibernéticas está em constante mudança e não a nosso favor. De acordo com o relatório M-Trends da Mandiant, os exploits são o método mais comum de infecção inicial (33% dos incidentes) [6]. O perfil do invasor também mudou. Hackers não são mais indivíduos isolados: é uma indústria com divisão de trabalho. Alguém escreve malware e exploits, alguém vende acessos prontos a empresas já invadidas, alguém realiza ataques. Cada um faz seu trabalho, como em um negócio normal. E alguns usam IA, mas isso é um grande tema para um holivar, discutiremos separadamente. Se não houver um exploit público para uma vulnerabilidade, ele pode ser comprado. Por exemplo, um exploit para CVE-2022-24086 era vendido em fóruns de hackers por 30.000 (segundo Sansec, novembro de 2022). Caro? Para um criminoso, é um investimento: a plataforma é difundida, através dela é possível roubar dados de cartões bancários (ataques MageCart) ou distribuir malware. Os custos são recuperados na primeira vítima, especialmente se forem operadores de ransomware: segundo a Palo Alto Networks Unit 42, o valor médio do resgate em 2022 já ultrapassava 900 mil dólares [7]. Compradores para exploits caros existem.
Uma dor separada: às vezes, uma empresa simplesmente configura um scanner que procura vulnerabilidades e considera que o processo existe. Isso não é um processo. Nossa tarefa é determinar quais vulnerabilidades existem em quais ativos, como corrigi-las e controlar as ações dos especialistas de TI. O principal objetivo do gerenciamento de vulnerabilidades é retardar ou, idealmente, parar o hacker. Quando o hacker atinge o perímetro e começa a agir, temos um arsenal completo: firewall para proteção de aplicações web, analisadores de código que capturam erros antes da saída do software para produção, sistemas SIEM para análise de eventos, firewall interno para detecção de reconhecimento na rede. Existem também produtos da classe NTA (network traffic analysis): eles analisam o tráfego de rede e veem se alguém está realizando reconhecimento ou ataque, inclusive de dentro da infraestrutura, ao contrário dos IDS clássicos. Mas todos esses meios funcionam melhor quando é difícil para o hacker. O objetivo do VM é tornar impossível invadir você: primeiramente, através de vulnerabilidades conhecidas (1-day) no perímetro, depois, através de vulnerabilidades conhecidas em toda a infraestrutura. Idealmente, dificultar ao máximo a invasão, mesmo através de 0-day, por meio de análise de código (SAST, DAST, IAST) e configuração correta dos sistemas. Cada caminho fechado é um tempo adicional para a equipe do SOC detectar o invasor e detê-lo.
Principais Objetivos do Gerenciamento de Vulnerabilidades
Redução do Nível de Risco. Quanto menos falhas e quanto mais rápido forem corrigidas, menores os riscos para a organização.
Continuidade dos Processos de Negócios. Brechas na segurança levam a interrupções de sistemas e serviços. O VM permite evitar isso.
Proteção da Informação. Dados são um dos ativos mais valiosos de uma empresa; ao gerenciar vulnerabilidades, prevenimos acesso não autorizado, vazamentos e distorção de dados.
Conformidade Legal. Os requisitos dos reguladores para gerenciamento de vulnerabilidades se tornam mais rigorosos a cada ano, e as multas aumentam. Um processo de VM bem estabelecido ajuda a passar por auditorias sem dores de cabeça.
Se resumirmos tudo, obtemos a seguinte tese para um especialista em SI:
"Não devo ser invadido através da exploração de vulnerabilidades."
Principais Tarefas do Gerenciamento de Vulnerabilidades
Inventário de Ativos: Uma lista completa de recursos de informação e dispositivos da organização com seus atributos.
Detecção de Vulnerabilidades: Monitoramento de fontes (boletins de fornecedores, bancos de dados de vulnerabilidades como NVD e BDU FSTEC) e escaneamento da infraestrutura com ferramentas especializadas.
Determinação do Nível de Perigo: Avaliação do impacto de cada vulnerabilidade na segurança da organização: facilidade de exploração, impacto real nos negócios.
Correção de Vulnerabilidades: Aplicação de patches, reconfiguração, substituição de software, monitoramento intensificado, desativação de componentes vulneráveis, alteração de processos de negócios em caso de aceitação de riscos ou substituição de software vulnerável.
Controle da Correção Oportuna: Verificação de que as vulnerabilidades foram realmente corrigidas e que novas não surgiram.
Melhoria Contínua: Aprimoramento de ferramentas e métodos, treinamento de pessoal, troca de experiências com a comunidade (espero que meus materiais também ajudem a aprimorar).
Processo VM em Termos de Resultado
Correção Oportuna de Vulnerabilidades no Perímetro e Ativos-Chave
Não há mais tempo para hesitar. Segundo a Mandiant, o tempo médio entre a publicação de uma vulnerabilidade e o surgimento de um exploit funcional foi reduzido para 5 dias, e um quarto das CVEs exploradas já são atacadas no dia da publicação [6]. O VulnCheck registra um cenário ainda mais rigoroso: quase 29% das vulnerabilidades com exploração confirmada foram usadas por invasores antes mesmo da divulgação pública [8]. O escaneamento de seus sistemas começa minutos após a divulgação de informações sobre uma vulnerabilidade em acesso aberto, às vezes até antes mesmo do exploit estar pronto. Portanto, é preciso definir antecipadamente os eventos indesejáveis, entender quais sistemas participam de sua implementação, classificar os ativos e, a partir disso, calcular os requisitos de velocidade de correção. Quando uma vulnerabilidade já está sendo divulgada nas notícias, é tarde demais para construir o processo.
Detecção e Correção Rápida de Shadow IT
Shadow IT são partes não oficiais e não controladas da infraestrutura: um servidor que um desenvolvedor configurou "rapidamente" há três anos, um ambiente de teste esquecido, um serviço criado contornando o departamento de TI. Mesmo que 90% dos sistemas estejam cobertos por medidas de segurança, você será invadido através dos 10% restantes, sobre os quais você não sabe. Pior ainda, e por mais estranho que pareça: um especialista em SI não pode fisicamente identificar vulnerabilidades em um nó que não está em seu quadro de visão. Isso significa que, quando as informações sobre uma nova vulnerabilidade de tendência surgirem, ele não poderá informar ao departamento de TI em poucas horas o que exatamente precisa ser corrigido urgentemente. E os hackers, aliás, também sabem criar nós dentro da infraestrutura e usá-los como plataforma, enquanto não sabemos deles.
Redução do Número de Vulnerabilidades
O fluxo de novas vulnerabilidades está aumentando: 48 mil CVEs em 2025 contra 25 mil em 2022 [1]. É impossível "limpar" completamente a infraestrutura: um segundo após o último patch, surgirá uma nova vulnerabilidade. Este é um processo contínuo, e isso é normal. Mas o número de vulnerabilidades críticas e relevantes deve diminuir, idealmente, tender a zero. E a mensurabilidade é importante aqui: você deve saber quantas vulnerabilidades existem na infraestrutura, quão rápido elas são corrigidas e se o número de vulnerabilidades corrigidas está crescendo. Se o processo estiver bem construído, a curva desce. Se não houver curva alguma - você não tem um processo, apenas sensações.
Compreensão de Quais Vulnerabilidades São Inaceitáveis e Monitoramento de Tendências
Dentro dos sistemas de perímetro, chave e de destino, existem ativos de diferentes importâncias. Por exemplo, equipamentos Cisco podem estar no perímetro ou podem ser um ambiente de teste dentro da infraestrutura virtual. Ambos precisam ser atualizados, mas as prioridades são diferentes: de um ambiente de teste, um invasor não chegará ao "1C: Contabilidade", mas de um dispositivo de perímetro - sim. Atenção especial merecem as vulnerabilidades de tendência - aquelas que estão sendo ativamente exploradas em ataques agora. O FSTEC as marca no BDU (em 2025, mais de duzentas delas foram registradas [9]), os fornecedores de sistemas de análise de segurança as marcam em seus produtos, e no mundo, um papel semelhante é desempenhado pelo catálogo CISA KEV. Quando uma vulnerabilidade entra nessas listas, a contagem regressiva é em horas.
E como está aí?
Você se reconhece nos problemas típicos? Qual deles dói mais em sua empresa - a falta de inventário, SLAs ruins ou a guerra eterna entre SI e TI? E você tem um proprietário dedicado para o processo de VM ou é uma "carga adicional por compatibilidade"?
Materiais Adicionais:
Vulnerabilidades de tendência: como as ciberameaças para negócios estão mudando (rbc.ru)
A Segurança da Informação pode trazer resultados tangíveis? (YouTube, Alexey Lukatsky)
Apanhar em 12 horas: como encontrar e corrigir vulnerabilidades de tendência em software
Gerenciamento de Vulnerabilidades: um guia prático para proteger a infraestrutura
Anti-Malware.ru: "Em 2025, hackers éticos encontraram 13.690 vulnerabilidades em empresas russas", janeiro de 2026.
Ordem FSTEC da Rússia de 11.04.2025 nº 117 (entrou em vigor em 01.03.2026); documento metodológico FSTEC "Guia para organização do processo de gerenciamento de vulnerabilidades em um órgão (organização)" de 17.05.2023; metodologia de avaliação do nível de criticidade das vulnerabilidades FSTEC (ed. de 30.06.2025).
https://fstec.ru/
Sem cartão para começar · Planos a partir de R$49/mês
Gerenciamento de Vulnerabilidades do Zero: O Que É, Por Que Fazer e Quais Etapas Envolve
Este artigo é a Parte 1 da série "Gerenciamento de Vulnerabilidades para Iniciantes", um guia prático de VM do zero. Os capítulos são independentes, mas se desejar seguir a ordem, consulte o índice e todas as partes da série aqui.
Tudo Muito Simples
O Que São Vulnerabilidades
Vulnerabilidades, ou falhas, são falhas no código-fonte ou desvios na lógica de operação de aplicações. Há também uma variação que muitos negligenciam: "misconfigurations" (configurações incorretas) de software. Um programa pode funcionar aparentemente bem, mas com um painel administrativo acessível pela internet com login e senha padrão. Formalmente, não é um erro de código, mas na prática, é uma porta aberta. E, claro, ao falar de vulnerabilidades, não podemos deixar de mencionar os exploits. Um exploit é uma ferramenta que permite explorar uma vulnerabilidade: um programa ou fragmento de código que transforma um "buraco teórico" em acesso real ao sistema. Lembre-se do principal: vulnerabilidades existem em qualquer software. Algumas ainda não foram encontradas, outras foram encontradas, mas ainda não divulgadas. A questão não é "temos vulnerabilidades?", mas sim "quais serão encontradas primeiro: por nós ou por um invasor?".
Por Que Corrigir Vulnerabilidades
Todos entendem que a infraestrutura de uma empresa deve ter medidas de proteção: antivírus, firewall, sistema SIEM. Mas por que, além disso, é necessário corrigir vulnerabilidades em estações de trabalho ou dispositivos de borda? A razão é que um invasor obtém acesso a um segmento da rede através delas, e a partir daí, nenhum antivírus o impedirá. Ao fechar vulnerabilidades em tempo hábil, não deixamos chances para um hacker realizar eventos indesejáveis para a empresa. Idealmente, as vulnerabilidades no perímetro devem ser eliminadas primeiro, pois levam a segmentos que estão por trás de um IP público e acessíveis pela internet a qualquer um. Anteriormente, já analisamos uma metodologia de prevenção de ameaças que parte do que um invasor procura em um sistema. Definimos sistemas-chave e de destino, aos quais um invasor (nem interno, nem externo) não deve ter acesso sob nenhuma circunstância. E corrigimos vulnerabilidades para cortar caminhos para os riscos mais significativos: perdas de reputação, falhas de equipamento, interrupção de processos de negócios, roubo de dinheiro, espionagem industrial.
Onde Corrigir Vulnerabilidades
Elas Estão Aumentando
A infraestrutura de uma empresa pode ser vasta: servidores, roteadores, firewalls, estações de trabalho, impressoras, CRM, soluções de segurança da informação, dezenas de aplicações web. Onde corrigir vulnerabilidades? Idealmente, em todos os lugares. Na prática, isso é impossível: há muitas vulnerabilidades, e seu número cresce a um ritmo alarmante. Veja a dinâmica segundo os dados do CVE Program: em 2023, foram publicadas 28.818 novas CVEs; em 2024, 39.962 (um aumento de quase 39%); em 2025, 48.185 [1]. Isso representa 133 novas vulnerabilidades por dia, incluindo fins de semana. O banco de dados russo BDU FSTEC também está crescendo e já ultrapassou 89 mil registros [2]. Mesmo que você corrija todas em um belo dia, amanhã surgirão centenas de novas.
Onde Procurá-las
Zonas de Atenção Elevada
Já que não é possível fechar tudo, é preciso identificar sistemas criticamente importantes onde não devem existir vulnerabilidades que permitam a ocorrência de eventos indesejáveis. Estes incluem, primeiramente:
DMZ, ou seja, o perímetro da rede.
Sistemas-chave (por exemplo, o firewall interno no núcleo da infraestrutura, responsável pela segmentação da rede).
Sistemas de destino (bancos de dados, "1C" e tudo o que o hacker realmente procura).
É nessas três áreas que devemos prestar atenção primeiramente.
Onde Buscar Informações Sobre Vulnerabilidades
Nem sempre os próprios fornecedores de software realizam a busca por vulnerabilidades. Mais frequentemente, as "brechas" são encontradas por pesquisadores independentes de segurança, que as reportam ao desenvolvedor. O fornecedor prepara um patch, o lança e publica informações sobre a vulnerabilidade. Isso é chamado de divulgação responsável. Mas isso nem sempre acontece. Existem vulnerabilidades de dia zero (zero-day), sobre as quais o fornecedor só fica sabendo após seu uso. Falaremos detalhadamente sobre elas no capítulo sobre exploits. A abordagem ideal para uma empresa é a realização de exercícios cibernéticos e a participação em programas de bug bounty. A empresa disponibiliza seu software em uma plataforma, anuncia recompensas por vulnerabilidades encontradas e as corrige. Essa cultura já se estabeleceu na Rússia: em 2025, hackers éticos encontraram quase 14 mil vulnerabilidades através das duas maiores plataformas russas de bug bounty (Standoff Bug Bounty e BI.ZONE Bug Bounty), e os pagamentos totais aos pesquisadores ultrapassaram um quarto de bilhão de rublos [3]. Quanto mais aberto um fornecedor ao mercado, quanto mais honestamente ele fala sobre suas vulnerabilidades, melhor a percepção dos usuários. Paradoxalmente, é um fato. Embora aqui também se possa argumentar, muito frequentemente a "publicação de vulnerabilidades" é interpretada como um título sensacionalista com o contexto: tudo acabou, o software não pode mais ser usado!.
Como Organizar a Correção de Vulnerabilidades
Ciclo Contínuo de Gerenciamento de Vulnerabilidades
Este é um trabalho complexo, e falaremos sobre cada um de seus componentes separadamente nos próximos artigos. A primeira palavra-chave é "processo". Encontrar vulnerabilidades não é suficiente; é preciso saber o que fazer com elas: estudar os dados de entrada, aplicar expertise, formular SLAs, desenvolver uma metodologia de correção. Etapas para construir um processo de gerenciamento de vulnerabilidades:
Gerenciamento de Ativos (Inventário) e Categorização de Ativos
Para responder à pergunta "onde procurar vulnerabilidades", é preciso entender do que a infraestrutura é composta. O processo de vulnerability management (VM) sempre se baseia no processo de asset management (AM). O inventário, como regra, já existe no departamento de TI com base em sistemas CMDB. Mas o departamento de Segurança da Informação (SI) também deve realizá-lo, com seus próprios olhos: o TI nem sempre foca em sistemas importantes para a segurança e, sejamos honestos, nem sempre compartilha informações com os profissionais de segurança (falaremos muito sobre a interação entre esses dois departamentos e esperamos que esta série de artigos ajude a melhorar o entendimento mútuo. O mínimo necessário é: inventário de sistemas-chave, de destino e do perímetro. Também priorizamos os nós e destacamos aqueles que são o caminho mais curto para os riscos. Ao realizar a categorização, vemos quais nós exigem atenção máxima e quais podem esperar. Aqui também se formula o SLA - um acordo com o departamento de TI sobre os prazos de correção. Uma vulnerabilidade criticamente perigosa não pode ser corrigida em três meses. E se um nó não for tão importante e a vulnerabilidade não for tão grave, pode-se esperar tranquilamente pela atualização planejada: por exemplo, para o Windows - o próximo Patch Tuesday. Aliás, a partir de 1º de março de 2026, para sistemas de informação estatais, os prazos de correção não serão mais um assunto interno da empresa: a Ordem FSTEC nº 117 exige a correção de vulnerabilidades críticas em 24 horas e de altas em 7 dias [4]. O regulador efetivamente introduziu um SLA obrigatório. Mais detalhes sobre isso no capítulo sobre as particularidades do gerenciamento de vulnerabilidades na Rússia.
Busca por Vulnerabilidades e sua Priorização
Antes de definir o SLA, as vulnerabilidades precisam ser encontradas. O método - manual, com ferramentas open source ou produtos comerciais - não é tão importante. O principal é obter uma imagem honesta dos pontos fracos. E, em seguida, categorizar as próprias vulnerabilidades: quais delas são realmente perigosas em sua infraestrutura específica. Analisaremos detalhadamente os métodos de avaliação e priorização mais tarde.
Como Corrigir Vulnerabilidades
Em seguida, é preciso decidir o que fazer com cada vulnerabilidade: corrigir, aplicar medidas compensatórias ou desativar o software. As principais medidas de correção são a instalação de atualizações ou a aplicação de medidas compensatórias. Medidas compensatórias são necessárias quando uma vulnerabilidade não pode ser corrigida com um patch ou quando não é viável (por exemplo, um ativo está prestes a ser desativado). O processo mais eficaz: a maioria das vulnerabilidades é corrigida durante as atualizações regulares, e as tendências e não corrigidas - fora do plano, em acordo com a SI. Falaremos mais sobre isso em um dos próximos artigos.
Correção de Vulnerabilidades, Frequentemente um Processo de Gerenciamento de Patches
Na verdade, a correção é mais frequentemente a instalação de um patch e se integra a um processo separado, cujo responsável são os especialistas de TI. O método de implantação de patches geralmente é escolhido com base no tamanho e complexidade da infraestrutura. Onde há poucas máquinas, as atualizações são frequentemente instaladas manualmente, uma a uma - e isso funciona bem. Em redes grandes e complexas, isso não funciona mais: sistemas centralizados entram em ação, que distribuem os patches automaticamente. A vantagem da automação é clara. Menos operações manuais significam menos erros. As atualizações são distribuídas mais rapidamente. E também podem ser instaladas quando a carga nos sistemas é mínima - por exemplo, à noite. Eu mesmo pessoalmente fui a janelas tecnológicas às 2 da manhã para atualizar clusters de equipamentos de rede, para conseguir fazer tudo antes do amanhecer, pois o serviço deve funcionar continuamente durante o dia.
Controle da Correção e Melhoria do Processo
Dar uma tarefa não é suficiente, é preciso verificar se ela foi concluída. Caso real: conversamos com um cliente que possui um scanner de vulnerabilidades, perguntamos: "Vocês escanearam a infraestrutura, e depois o quê?" Resposta: "Recebemos o relatório e o entregamos ao departamento de TI para que realizem o gerenciamento de patches". Só isso. Sem relatório diferencial, sem comparação com os resultados do próximo escaneamento. O departamento de TI poderia nem ter aberto esses relatórios, e ninguém notaria. Os relatórios chegam, o TI opera de acordo com seu processo interno, as vulnerabilidades se acumulam. E, por último, a melhoria do processo. Soa banal, mas o objetivo é específico: o tempo de correção de vulnerabilidades deve diminuir a cada trimestre. Se não diminuir, o processo se degrada.
Problemas Típicos
Recentemente, houve uma transmissão ao vivo da AM Live sobre gerenciamento de vulnerabilidades. E em uma das pesquisas, os espectadores nomearam os principais obstáculos para um gerenciamento de vulnerabilidades completo em suas organizações:
(Gráfico de pesquisa: "Qual é o principal obstáculo para o gerenciamento completo de vulnerabilidades?")
E aqui estão os problemas que eu destacaria especificamente:
Falta de inventário.
Muitas vulnerabilidades.
SLAs de baixa qualidade ou ausentes.
Falta de categorização de vulnerabilidades.
Violação dos prazos de correção acordados.
Os reguladores, aliás, sabem muito bem desses problemas. O FSTEC em 2022 publicou uma metodologia para avaliar a criticidade das vulnerabilidades (atualizada em junho de 2025), em maio de 2023 - um guia para organizar o processo de gerenciamento de vulnerabilidades, e a Ordem nº 117 tornou esse processo obrigatório para sistemas estatais [4]. O NKCKI tem sua própria metodologia de tomada de decisão sobre atualizações. A tendência é clara: o gerenciamento de vulnerabilidades está se transformando de uma "boa prática" em um requisito.
No final de 2022 (e em outros anos não foi diferente), o NKCKI em seu relatório citou vulnerabilidades não corrigidas no perímetro como o principal caminho de penetração de invasores na infraestrutura interna. Um exemplo ilustrativo é a vulnerabilidade ProxyLogon no Microsoft Exchange, publicada em 2021. Anos após o lançamento do patch, ainda a encontrávamos em 1 em cada 3 clientes. O patch existe. Há anos. Simplesmente não é aplicado. Por quê? As respostas são sempre diferentes, veja a captura de tela acima, há muitos problemas!.
Importância do Processo VM. Objetivos e Tarefas
O cenário de ameaças cibernéticas está em constante mudança e não a nosso favor. De acordo com o relatório M-Trends da Mandiant, os exploits são o método mais comum de infecção inicial (33% dos incidentes) [6]. O perfil do invasor também mudou. Hackers não são mais indivíduos isolados: é uma indústria com divisão de trabalho. Alguém escreve malware e exploits, alguém vende acessos prontos a empresas já invadidas, alguém realiza ataques. Cada um faz seu trabalho, como em um negócio normal. E alguns usam IA, mas isso é um grande tema para um holivar, discutiremos separadamente. Se não houver um exploit público para uma vulnerabilidade, ele pode ser comprado. Por exemplo, um exploit para CVE-2022-24086 era vendido em fóruns de hackers por 30.000 (segundo Sansec, novembro de 2022). Caro? Para um criminoso, é um investimento: a plataforma é difundida, através dela é possível roubar dados de cartões bancários (ataques MageCart) ou distribuir malware. Os custos são recuperados na primeira vítima, especialmente se forem operadores de ransomware: segundo a Palo Alto Networks Unit 42, o valor médio do resgate em 2022 já ultrapassava 900 mil dólares [7]. Compradores para exploits caros existem.
Uma dor separada: às vezes, uma empresa simplesmente configura um scanner que procura vulnerabilidades e considera que o processo existe. Isso não é um processo. Nossa tarefa é determinar quais vulnerabilidades existem em quais ativos, como corrigi-las e controlar as ações dos especialistas de TI. O principal objetivo do gerenciamento de vulnerabilidades é retardar ou, idealmente, parar o hacker. Quando o hacker atinge o perímetro e começa a agir, temos um arsenal completo: firewall para proteção de aplicações web, analisadores de código que capturam erros antes da saída do software para produção, sistemas SIEM para análise de eventos, firewall interno para detecção de reconhecimento na rede. Existem também produtos da classe NTA (network traffic analysis): eles analisam o tráfego de rede e veem se alguém está realizando reconhecimento ou ataque, inclusive de dentro da infraestrutura, ao contrário dos IDS clássicos. Mas todos esses meios funcionam melhor quando é difícil para o hacker. O objetivo do VM é tornar impossível invadir você: primeiramente, através de vulnerabilidades conhecidas (1-day) no perímetro, depois, através de vulnerabilidades conhecidas em toda a infraestrutura. Idealmente, dificultar ao máximo a invasão, mesmo através de 0-day, por meio de análise de código (SAST, DAST, IAST) e configuração correta dos sistemas. Cada caminho fechado é um tempo adicional para a equipe do SOC detectar o invasor e detê-lo.
Principais Objetivos do Gerenciamento de Vulnerabilidades
Redução do Nível de Risco. Quanto menos falhas e quanto mais rápido forem corrigidas, menores os riscos para a organização.
Continuidade dos Processos de Negócios. Brechas na segurança levam a interrupções de sistemas e serviços. O VM permite evitar isso.
Proteção da Informação. Dados são um dos ativos mais valiosos de uma empresa; ao gerenciar vulnerabilidades, prevenimos acesso não autorizado, vazamentos e distorção de dados.
Conformidade Legal. Os requisitos dos reguladores para gerenciamento de vulnerabilidades se tornam mais rigorosos a cada ano, e as multas aumentam. Um processo de VM bem estabelecido ajuda a passar por auditorias sem dores de cabeça.
Se resumirmos tudo, obtemos a seguinte tese para um especialista em SI:
"Não devo ser invadido através da exploração de vulnerabilidades."
Principais Tarefas do Gerenciamento de Vulnerabilidades
Inventário de Ativos: Uma lista completa de recursos de informação e dispositivos da organização com seus atributos.
Detecção de Vulnerabilidades: Monitoramento de fontes (boletins de fornecedores, bancos de dados de vulnerabilidades como NVD e BDU FSTEC) e escaneamento da infraestrutura com ferramentas especializadas.
Determinação do Nível de Perigo: Avaliação do impacto de cada vulnerabilidade na segurança da organização: facilidade de exploração, impacto real nos negócios.
Correção de Vulnerabilidades: Aplicação de patches, reconfiguração, substituição de software, monitoramento intensificado, desativação de componentes vulneráveis, alteração de processos de negócios em caso de aceitação de riscos ou substituição de software vulnerável.
Controle da Correção Oportuna: Verificação de que as vulnerabilidades foram realmente corrigidas e que novas não surgiram.
Melhoria Contínua: Aprimoramento de ferramentas e métodos, treinamento de pessoal, troca de experiências com a comunidade (espero que meus materiais também ajudem a aprimorar).
Processo VM em Termos de Resultado
Correção Oportuna de Vulnerabilidades no Perímetro e Ativos-Chave
Não há mais tempo para hesitar. Segundo a Mandiant, o tempo médio entre a publicação de uma vulnerabilidade e o surgimento de um exploit funcional foi reduzido para 5 dias, e um quarto das CVEs exploradas já são atacadas no dia da publicação [6]. O VulnCheck registra um cenário ainda mais rigoroso: quase 29% das vulnerabilidades com exploração confirmada foram usadas por invasores antes mesmo da divulgação pública [8]. O escaneamento de seus sistemas começa minutos após a divulgação de informações sobre uma vulnerabilidade em acesso aberto, às vezes até antes mesmo do exploit estar pronto. Portanto, é preciso definir antecipadamente os eventos indesejáveis, entender quais sistemas participam de sua implementação, classificar os ativos e, a partir disso, calcular os requisitos de velocidade de correção. Quando uma vulnerabilidade já está sendo divulgada nas notícias, é tarde demais para construir o processo.
Detecção e Correção Rápida de Shadow IT
Shadow IT são partes não oficiais e não controladas da infraestrutura: um servidor que um desenvolvedor configurou "rapidamente" há três anos, um ambiente de teste esquecido, um serviço criado contornando o departamento de TI. Mesmo que 90% dos sistemas estejam cobertos por medidas de segurança, você será invadido através dos 10% restantes, sobre os quais você não sabe. Pior ainda, e por mais estranho que pareça: um especialista em SI não pode fisicamente identificar vulnerabilidades em um nó que não está em seu quadro de visão. Isso significa que, quando as informações sobre uma nova vulnerabilidade de tendência surgirem, ele não poderá informar ao departamento de TI em poucas horas o que exatamente precisa ser corrigido urgentemente. E os hackers, aliás, também sabem criar nós dentro da infraestrutura e usá-los como plataforma, enquanto não sabemos deles.
Redução do Número de Vulnerabilidades
O fluxo de novas vulnerabilidades está aumentando: 48 mil CVEs em 2025 contra 25 mil em 2022 [1]. É impossível "limpar" completamente a infraestrutura: um segundo após o último patch, surgirá uma nova vulnerabilidade. Este é um processo contínuo, e isso é normal. Mas o número de vulnerabilidades críticas e relevantes deve diminuir, idealmente, tender a zero. E a mensurabilidade é importante aqui: você deve saber quantas vulnerabilidades existem na infraestrutura, quão rápido elas são corrigidas e se o número de vulnerabilidades corrigidas está crescendo. Se o processo estiver bem construído, a curva desce. Se não houver curva alguma - você não tem um processo, apenas sensações.
Compreensão de Quais Vulnerabilidades São Inaceitáveis e Monitoramento de Tendências
Dentro dos sistemas de perímetro, chave e de destino, existem ativos de diferentes importâncias. Por exemplo, equipamentos Cisco podem estar no perímetro ou podem ser um ambiente de teste dentro da infraestrutura virtual. Ambos precisam ser atualizados, mas as prioridades são diferentes: de um ambiente de teste, um invasor não chegará ao "1C: Contabilidade", mas de um dispositivo de perímetro - sim. Atenção especial merecem as vulnerabilidades de tendência - aquelas que estão sendo ativamente exploradas em ataques agora. O FSTEC as marca no BDU (em 2025, mais de duzentas delas foram registradas [9]), os fornecedores de sistemas de análise de segurança as marcam em seus produtos, e no mundo, um papel semelhante é desempenhado pelo catálogo CISA KEV. Quando uma vulnerabilidade entra nessas listas, a contagem regressiva é em horas.
E como está aí?
Você se reconhece nos problemas típicos? Qual deles dói mais em sua empresa - a falta de inventário, SLAs ruins ou a guerra eterna entre SI e TI? E você tem um proprietário dedicado para o processo de VM ou é uma "carga adicional por compatibilidade"?
Materiais Adicionais:
Vulnerabilidades de tendência: como as ciberameaças para negócios estão mudando (rbc.ru)
A Segurança da Informação pode trazer resultados tangíveis? (YouTube, Alexey Lukatsky)
Apanhar em 12 horas: como encontrar e corrigir vulnerabilidades de tendência em software
Gerenciamento de Vulnerabilidades: um guia prático para proteger a infraestrutura
Anti-Malware.ru: "Em 2025, hackers éticos encontraram 13.690 vulnerabilidades em empresas russas", janeiro de 2026.
Ordem FSTEC da Rússia de 11.04.2025 nº 117 (entrou em vigor em 01.03.2026); documento metodológico FSTEC "Guia para organização do processo de gerenciamento de vulnerabilidades em um órgão (organização)" de 17.05.2023; metodologia de avaliação do nível de criticidade das vulnerabilidades FSTEC (ed. de 30.06.2025).
https://fstec.ru/
⬅️ Anterior: Cap. 0. "Quem precisa de mim, não vão me invadir"
·
📑 Índice da série
·
Próxima: Cap. 2. Gerenciamento de Vulnerabilidades à Russa ➡️
Se algo em sua infraestrutura está organizado de forma diferente, conte nos comentários. Se gostou, assine para não perder a próxima parte.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
