Os necessários fazem o site funcionar. Os outros medem quais páginas ajudam e quais anúncios trazem quem precisa da DM11. Você escolhe, e pode rever pelo rodapé.
GESTÃO DE VULNERABILIDADES
Quase toda empresa que contrata varredura descobre a mesma coisa: achar é a parte barata. O relatório volta com centenas de itens, a equipe corrige os que dá, e seis meses depois os mesmos itens continuam ali, agora acompanhados de itens novos. Gestão de vulnerabilidades é o trabalho que transforma esse relatório em fila que anda, com ordem definida por risco de negócio e alguém responsável por cobrar até o item sumir.
Este é um trabalho de rotina, e não um evento. Ele não substitui o teste de intrusão, que prova o que um atacante consegue fazer, e o teste de intrusão não substitui esta rotina, que cobre o ano inteiro. Onde uma exigência formal pede as duas coisas, como no PCI DSS, elas são contratadas juntas e com escopos separados.
Quem conduz o trabalho
Análise de vulnerabilidades com Qualys Certified Specialist
CEH, hacker ético certificado pelo EC-Council
CISA, auditoria de sistemas de informação
17 anos de governança, riscos e conformidades
O QUE É
Gestão de vulnerabilidades é a rotina de descobrir o que está exposto, decidir o que importa primeiro, corrigir e conferir que a correção pegou. Cada uma dessas quatro etapas falha por um motivo diferente, e a que mais falha não é a descoberta. É a decisão de prioridade, porque ela exige alguém que conheça o negócio e tenha mandato para dizer que o item de gravidade alta pode esperar e o de gravidade média não pode.
É o item que quase todo mundo pula e o que mais compromete o resto. Um relatório que diz que 94% dos ativos estão em dia responde por 94% dos ativos que a varredura enxergou, e não do que a empresa tem. O que costuma ficar de fora é sempre parecido: equipamento de rede antigo, sistema que um fornecedor opera sozinho, ambiente de nuvem contratado por uma área e a máquina que ninguém sabe de quem é. A primeira medição útil não é a quantidade de falhas, é a diferença entre o que o inventário diz e o que a varredura encontrou.
O CVSS é uma escala pública que descreve quão grave é uma falha em abstrato, e é útil exatamente para isso. O que ele não sabe é onde aquele sistema está na sua empresa, o que ele guarda, se ele é alcançável de fora e se alguém está explorando aquilo agora. Uma falha de gravidade média num servidor exposto que guarda dado de cliente vence uma falha de gravidade alta numa máquina isolada de laboratório, todo dia. Ordenar a fila só pela nota é a forma mais comum de gastar o ano corrigindo o que não muda o risco.
A primeira é a gravidade técnica, que o CVSS entrega de graça. A segunda é a criticidade de negócio: o que aquele sistema sustenta, e o que acontece se ele parar ou vazar. A terceira é se a falha está sendo explorada no mundo real, porque uma falha antiga com exploração conhecida é mais perigosa que uma falha nova e teórica. Só a primeira vem pronta da ferramenta. As outras duas dependem do inventário e de uma conversa com quem opera, e é isso que separa gestão de vulnerabilidades de assinatura de scanner.
Não publicamos números de prazo porque eles não são nossos: quem define quanto tempo cada gravidade pode esperar é a empresa, junto de quem opera a TI. O que a DM11 faz é ajudar a chegar num acordo que sobreviva ao dia a dia, com o critério de exceção escrito e com data de revisão. O ponto é este: sem prazo acordado, a correção compete com o chamado do dia e perde sempre, e quando a TI é terceirizada isso precisa estar no contrato, ou não acontece.
QUANDO FAZ SENTIDO
As três terminam no mesmo lugar: existe informação sobre falhas e não existe processo que a transforme em redução de risco.
É o caso mais comum. A ferramenta foi comprada, roda, gera relatório, e o relatório é arquivado. Não falta tecnologia: falta prazo acordado por gravidade, dono por item e alguém com a tarefa explícita de cobrar. Quando a TI é operada por terceiro, falta também a cláusula de contrato que faz a correção concorrer em pé de igualdade com o chamado do dia.
O PCI DSS exige varredura trimestral de quem processa cartão, além do teste anual. Cliente grande em due diligence pergunta com que frequência a empresa varre e o que faz com o resultado, e a segunda parte da pergunta é a que costuma não ter resposta. Aqui o entregável que importa não é o relatório, é o registro de que a fila foi perseguida.
Nuvem contratada por área, aplicação nova todo trimestre, fornecedor que opera um sistema inteiro, fusão que juntou duas redes. Nesse cenário a primeira entrega útil não é a varredura, é o inventário: sem ele não há como saber o que ficou de fora, e todo percentual de cobertura é chute com aparência de dado.
TRADUZINDO O PEDIDO
As quatro formas em que o pedido chega, com o que cada uma significa na prática e o que muda o tamanho do trabalho.
| O que pediram | O que isso quer dizer | O que muda o tamanho |
|---|---|---|
| Queremos contratar varredura de vulnerabilidades | Descoberta recorrente do que está exposto, com revisão humana do resultado para separar achado real de falso positivo. | Quantidade e diversidade de ativos, se a nuvem entra no mesmo ciclo da rede, e se há ambiente que só o fornecedor acessa. |
| Precisamos de um programa contínuo | O ciclo inteiro: inventário, descoberta, validação, priorização, acompanhamento da correção e medição do que fechou. | Se já existe inventário, quantas equipes corrigem, se a TI é própria ou terceirizada, e se existe acordo de prazo por gravidade. |
| O cliente pediu evidência de que corrigimos | O que vai ser lido por terceiro é o registro do ciclo, e não a lista de achados: o que foi encontrado, o que foi corrigido, o que foi aceito e com qual justificativa. | O período que o exigente cobre, e se as exceções precisam estar formalizadas com dono e data de revisão. |
| Queremos priorizar melhor o que já encontramos | Trabalho de repriorização sobre a base existente, cruzando gravidade técnica com criticidade de negócio e exploração conhecida. | Tamanho da fila acumulada, se os ativos têm dono definido e se existe classificação do que cada sistema sustenta. |
Nenhum destes começa por comprar ferramenta. Quando já existe uma, o trabalho costuma ser fazê-la render, e isso é mais barato do que trocar.
HISTÓRIAS
Trocamos os nomes dos clientes com o mesmo sigilo que vai proteger a sua empresa depois. Os nomes mudam, o padrão dos problemas se repete. Quando o cliente autoriza, mostramos referências com nome numa conversa.
Serviços financeiros
A varredura acontecia no prazo, o relatório saía e ia para uma pasta. A equipe de infraestrutura corrigia o que dava entre um chamado e outro, sem prazo definido e sem ordem que alguém tivesse decidido. Os itens do topo eram sempre os mesmos, e ninguém sabia dizer se aquilo era ruim ou normal.
Não trocamos a ferramenta. Levantamos o inventário para descobrir o que ela não estava enxergando, definimos dono por ativo e sentamos com quem opera para acordar prazo por gravidade, com critério de exceção escrito. A fila passou a ser ordenada por gravidade, criticidade do sistema e existência de exploração conhecida, e não pela nota isolada.
Vários itens do topo da lista antiga desceram, porque estavam em ambiente isolado, e itens de gravidade média em servidor exposto subiram. A partir do terceiro ciclo a idade média da fila passou a cair, que é o número que a diretoria acompanha desde então.
Tecnologia
O relatório trimestral mostrava um percentual alto de ativos em dia, e a empresa apresentava esse número em due diligence. O que ninguém tinha medido era o denominador: a varredura cobria a rede corporativa, e não cobria as contas de nuvem abertas por áreas de produto nem o ambiente que um fornecedor operava sozinho.
Reconciliamos as listas que já existiam em lugares diferentes, a da TI, a do financeiro e a de quem assina contrato, e o inventário passou a vir da própria conta de nuvem em vez de uma planilha mantida à mão. O que o fornecedor opera virou conversa contratual antes de virar conversa técnica: quem varre, com que frequência, quem recebe e em que prazo corrige.
O percentual caiu no primeiro relatório depois da mudança, e essa queda foi a melhor notícia do projeto: pela primeira vez o número descrevia o ambiente inteiro. A empresa parou de apresentar cobertura em due diligence e passou a apresentar cobertura junto da diferença medida contra o inventário.
Comércio eletrônico
A exigência de varredura trimestral era cumprida, e o auditor pediu outra coisa: a prova de que os achados tinham sido tratados. Existiam quatro relatórios de descoberta e nenhum registro de correção, de aceitação de risco ou de exceção. O que tinha sido resolvido estava resolvido, e ninguém conseguia mostrar.
Montamos o registro do ciclo em vez de mais um relatório de achados: o que foi encontrado, o que foi corrigido com a data, o que foi aceito e por quem, e o que ficou como exceção com dono e data de revisão. A conferência de que a correção pegou passou a ser feita por nova varredura, e não pela palavra de quem corrigiu.
A auditoria seguinte recebeu o registro do ciclo e não pediu nada além. Um efeito lateral apareceu logo: com a exceção precisando de dono e data, o número de exceções informais caiu sozinho, porque várias existiam apenas por não terem sido escritas.
COMO CONDUZIMOS
O que separa este trabalho de uma assinatura de scanner é que cada etapa produz uma medição, e as medições dizem se o risco está caindo ou apenas mudando de nome.
Começa aqui porque tudo o mais depende disto. Levantamos os ativos, reconciliamos as listas que já existem em lugares diferentes, a da TI, a do financeiro e a de quem assina contrato, e definimos dono por item. Só então a cobertura da varredura passa a significar alguma coisa, porque ela é medida contra o inventário e não contra ela mesma.
Inventário conciliado, com dono e criticidade por ativo
O que sustenta cada sistema, para a priorização ter base
Ambientes que hoje ficam fora da varredura, listados com o motivo
Cobertura medida como a diferença entre inventário e o que a varredura alcança
O que passa a ser medidoA diferença entre o que a empresa tem e o que a varredura enxerga, em número.
A varredura roda na periodicidade acordada, e o resultado passa por revisão humana antes de virar tarefa. Essa revisão existe por um motivo prático: falso positivo entregue como tarefa queima a confiança da equipe que corrige, e depois de duas ou três vezes ela passa a tratar a fila inteira como ruído. O que sai daqui é uma lista validada, e não a exportação da ferramenta.
Varredura recorrente, com a periodicidade acordada em contrato
Revisão humana do resultado, separando achado real de falso positivo
Achado crítico comunicado fora do ciclo, sem esperar o relatório
Registro do que foi descartado e por quê
O que passa a ser medidoLista validada, com a taxa de falso positivo acompanhada ciclo a ciclo.
É a etapa que decide se o ano vai ser bem gasto. Cruzamos a gravidade técnica com a criticidade do ativo e com a informação de exploração conhecida no mundo real, e a fila sai ordenada por risco e não por nota. É aqui também que se define o prazo por gravidade, junto de quem opera, e o critério para registrar exceção com dono e data de revisão.
Fila ordenada por gravidade, criticidade de negócio e exploração conhecida
Prazo por gravidade acordado com quem opera, e não publicado por nós
Exceções registradas com dono, motivo e data de revisão
Encaminhamento por equipe responsável, com o item já atribuído
O que passa a ser medidoCada item da fila tem dono, prazo e uma razão escrita para estar naquela posição.
A etapa que transforma relatório em redução de risco. Acompanhamos a fila até o item sumir do ciclo seguinte, conferimos por nova varredura que a correção pegou, e medimos o que interessa: idade média da fila, quantos itens fecharam no prazo e quantos reabriram. O registro disso é o que a auditoria e o cliente pedem, mais do que a lista de achados.
Conferência por nova varredura de que a correção pegou
Idade da fila, itens fechados no prazo e itens reabertos, medidos por ciclo
Relatório de ciclo com o que fechou, o que ficou e a justificativa do que ficou
Registro pronto para auditoria e para o questionário do cliente
O que passa a ser medidoA fila tem idade média medida, e ela cai de um ciclo para o outro.
COM QUE FREQUÊNCIA
Não publicamos periodicidade padrão nem prazo de correção, porque os dois dependem do seu ambiente e de acordo com quem opera. Estes são os três fatores que mais mexem na cadência, e a primeira conversa já mostra em qual deles a sua empresa está.
Quando existe, ela define o piso e não o teto. O PCI DSS exige varredura trimestral de quem processa cartão, e cliente grande costuma perguntar a periodicidade no questionário de due diligence. Fora de exigência formal, a cadência é escolha, e a escolha certa depende dos dois fatores abaixo.
Ambiente estável, com poucas mudanças por trimestre, sustenta um ciclo mais espaçado sem perder nada. Ambiente onde entra aplicação nova todo mês, ou onde a nuvem cresce por decisão de área, precisa de ciclo mais curto, ou a varredura sempre descreve um ambiente que já mudou.
Este é o fator que mais gente esquece na hora de escolher a cadência. Varrer mais rápido do que a equipe consegue corrigir não reduz risco: aumenta a fila e o desânimo de quem a recebe. A cadência precisa caber na capacidade de correção, ou o processo produz relatório em vez de resultado.
PERGUNTAS FREQUENTES
As dúvidas que aparecem em quase toda primeira reunião, respondidas sem rodeio.
Não, e a confusão custa caro dos dois lados. A gestão de vulnerabilidades é rotina do ano inteiro e responde o que existe de errado e em que ordem resolver. O pentest é evento periódico e responde o que um atacante consegue fazer de verdade, encadeando falhas que isoladas pareciam pequenas. Uma cobre extensão, a outra cobre profundidade. Onde há exigência formal, as duas costumam ser pedidas: o PCI DSS, por exemplo, exige varredura trimestral e teste anual. A comparação completa está na página de pentest e análise de vulnerabilidade.
Na maioria dos casos, não. A ferramenta raramente é o problema: o que costuma faltar é inventário para saber o que ela não está enxergando, prazo acordado por gravidade, dono por item e alguém cobrando até o item fechar. Fazer render a ferramenta que já existe é mais barato e mais rápido do que trocar, e evita começar o ano num projeto de migração em vez de num projeto de redução de risco. Se em algum momento a ferramenta for mesmo o limite, isso aparece com evidência e não como opinião.
Não, e o motivo não é reserva comercial. O prazo de correção não é nosso para prometer: quem corrige é a sua equipe ou o seu fornecedor de TI, e um número publicado no site viraria compromisso de terceiro. O que fazemos é ajudar a chegar num acordo de prazo por gravidade que sobreviva ao dia a dia, com o critério de exceção escrito, e cobrar contra esse acordo. Quando a TI é terceirizada, esse acordo precisa estar no contrato com o fornecedor, ou a correção compete com o chamado do dia e perde sempre.
Resolve um terço dela. O CVSS descreve quão grave é uma falha em abstrato, e é bom nisso. O que ele não sabe é onde aquele sistema está na sua empresa, o que ele guarda, se é alcançável de fora e se alguém está explorando aquilo agora. Uma falha média num servidor exposto com dado de cliente vence uma falha alta numa máquina isolada de laboratório. As duas informações que faltam vêm do inventário e de uma conversa com quem opera, e é isso que separa este trabalho de uma assinatura de scanner.
Quatro números, e nenhum deles é a quantidade de falhas encontradas, que sobe quando a cobertura melhora e por isso não serve de termômetro. Medimos a cobertura, que é a diferença entre o inventário e o que a varredura alcança; a idade média da fila, que é o que mostra se ela anda; quantos itens fecharam dentro do prazo acordado; e quantos reabriram, que é o que denuncia correção que não pegou. Uma quinta medição útil é a taxa de falso positivo, porque ela prevê quando a equipe que corrige vai começar a ignorar a fila.
Os dois entram no mesmo ciclo, e são justamente os que costumam ficar de fora e deixar o percentual bonito por omissão. Em nuvem, o inventário precisa vir da própria conta e não de uma lista mantida à mão, porque o crescimento silencioso hoje é quase todo de lá. No que o fornecedor opera, a conversa é contratual antes de ser técnica: quem varre, com que frequência, quem recebe o resultado e em que prazo corrige. Sem isso escrito, o ambiente existe no seu risco e não no seu relatório.
Faz, e com escopo bem menor do que o nome sugere. Numa operação pequena o ganho grande não vem de ferramenta cara: vem de saber quantos equipamentos e serviços existem, ligar atualização automática onde não há motivo para não ligar, e ter uma pessoa olhando o resultado com regularidade. Isso já tira da mesa a maior parte do risco desta frente, porque o ataque comum usa falha conhecida, com correção publicada, em programa que todo mundo tem. O programa completo entra depois, quando o ambiente justificar.
Uma conversa curta já mostra quanto do seu ambiente a varredura de hoje não enxerga, e o que precisaria existir para a fila começar a diminuir. Se já houver ferramenta, o trabalho costuma ser fazê-la render.
Comparativos sobre este assunto
Ver os 13 comparativosCenter for Internet Security · versão 8.1, de junho de 2024 · consultado em
NIST, instituto nacional de padrões e tecnologia dos Estados Unidos · NIST CSWP 29, publicado em 26/02/2024 · consultado em
OWASP Foundation · edição 2025, primeira revisão desde 2021 · consultado em
PCI Security Standards Council · PCI DSS v4.0.1 · consultado em
Esta página é informativa e descreve como a DM11 lê e aplica as fontes acima. Ela não reproduz o texto das normas, não substitui a leitura do documento oficial e não substitui auditoria, certificação, avaliação independente ou aconselhamento jurídico. Onde a norma exige avaliação formal, quem conduz é um organismo, auditoria ou avaliador credenciado, sempre separado de quem preparou.