Gestão de risco · vulnerabilidades
A fila de correção nunca termina porque está ordenada pela pergunta errada. Gravidade teórica não é o mesmo que risco real, e existem duas fontes públicas que dizem qual é qual.
Se o seu relatório de vulnerabilidades tem quatro mil itens críticos, ele não tem quatro mil prioridades. Tem quatro mil linhas e nenhuma prioridade.
Na maioria dos ambientes o time está correndo. Só está correndo na ordem errada.
O CVSS é uma nota de gravidade. Ele responde: se essa falha for explorada, o estrago é grande? Leva em conta se dá para explorar remotamente, se precisa de autenticação, o impacto em confidencialidade e disponibilidade. É uma boa medida do pior caso.
Só que ele não responde a pergunta que decide a sua semana: alguém está realmente usando isso?
Uma falha pode ter nota 9.8 e nunca ter sido explorada por ninguém, em lugar nenhum, porque exige uma condição que quase não existe na prática. Outra pode ter 7.5 e estar sendo usada em campanha ativa neste momento. Ordenar por CVSS coloca a primeira no topo e a segunda na página três.
A primeira é o catálogo KEV da CISA, de Known Exploited Vulnerabilities. Ele lista o que tem exploração confirmada em campo. Não é previsão, é fato observado. Hoje são pouco mais de 1.600 entradas, contra as centenas de milhares de CVEs já publicados. Essa desproporção é a informação mais útil que existe sobre a sua fila.
A segunda é o EPSS, do FIRST.org. Ele estima a probabilidade de uma vulnerabilidade ser explorada nos próximos 30 dias, em um valor de 0 a 1, recalculado diariamente. Um CVE com EPSS de 0,4 tem 40% de chance estimada; um com 0,0005 tem praticamente nenhuma.
As duas se complementam. O KEV diz o que já aconteceu. O EPSS estima o que está por vir, inclusive para o que ainda não entrou no catálogo.
A ordem que resolve é esta:
É uma inversão em relação ao que a maioria das ferramentas entrega por padrão, e ela muda o tamanho do problema. Ela encolhe sem que ninguém precise corrigir mais rápido: sai da frente o que nunca seria usado contra você.
As duas fontes são abertas e não dependem de contrato com ninguém. O KEV sai em JSON direto da CISA:
https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.jsonO EPSS tem API aberta no FIRST, que aceita consulta por CVE ou em lote:
https://api.first.org/data/v1/epss?cve=CVE-2021-44228Com o export do seu scanner em mãos, o cruzamento é uma planilha ou vinte linhas de script. Marque quais CVEs aparecem no KEV, anote o EPSS de cada um, e reordene. Na maioria dos ambientes, a lista do que merece atenção nesta semana cabe em uma tela.
O que isso custa não é dinheiro, é tempo. E não é uma vez só: o EPSS muda todo dia, o KEV ganha entradas novas, o inventário de máquinas não para quieto. Fazer uma vez responde como você está hoje; manter respondido é outro trabalho.
EPSS baixo não é autorização para ignorar. É dado vivo: um CVE com probabilidade irrisória hoje pode saltar amanhã, quando aparecer um exploit público. Consultar uma vez e guardar o número para sempre anula o benefício. Reconsulte.
O KEV não é exaustivo. Ele traz o que a CISA confirmou, não tudo que existe sendo explorado no mundo. Estar fora do catálogo é um bom sinal, e para por aí.
O contexto do ativo continua pesando. A mesma vulnerabilidade em um servidor exposto à internet e em uma estação de laboratório não têm a mesma urgência. Exploração provável em máquina que ninguém alcança é menos grave que exploração improvável na borda. Essa parte nenhuma pontuação externa consegue enxergar.
Todo ambiente tem. Sistema legado que não recebe atualização há anos, appliance de fornecedor que sumiu, aplicação que quebra se você mexer na biblioteca. Fingir que essas linhas vão desaparecer da fila é o que faz o relatório crescer para sempre.
Há três saídas honestas, e nenhuma delas é corrigir:
O que não vale é deixar na fila como pendência eterna. Uma linha que ninguém vai tratar polui a lista e faz o time perder confiança no próprio relatório.
Levar para a diretoria "temos quatro mil vulnerabilidades críticas" não produz decisão nenhuma, porque o número é grande demais para significar alguma coisa. Já "temos doze vulnerabilidades com exploração confirmada em campo, e nove delas estão em servidores expostos" é uma frase sobre a qual alguém consegue decidir.
O time continua fazendo o mesmo trabalho. O que ele ganha é conseguir explicar por que a fila está nessa ordem.
A ordenação canônica do produto é exatamente essa: KEV primeiro, depois EPSS, depois severidade e CVSS. A regra que escrevemos internamente é curta: fato de exploração vence probabilidade, e probabilidade vence gravidade teórica.
O EPSS é consultado ao vivo na API do FIRST e mantido em cache curto, para não trabalhar com número velho. O KEV vem do feed da CISA e é atualizado junto.
Há ainda uma decisão de processo por trás disso: um item só sai da fila quando uma nova varredura confirma a correção. Não sai porque alguém marcou como resolvido. Também não vira incidente de SOC: exposição tem ciclo de vida próprio, separado de ataque em andamento, porque as duas coisas têm urgências diferentes e competir pela mesma fila faz perder as duas de vista.
Mas o essencial deste texto você faz hoje, sem nós: baixe o catálogo da CISA, cruze com o seu inventário e veja quantas linhas sobram. Se forem poucas, você acabou de recuperar a semana do time. Se forem muitas, pelo menos agora são as certas.
Uma apresentação prática e adaptada à realidade do seu ambiente: acompanhe o fluxo de investigação da IZA e entenda como centralizar detecção, exposição e resposta em um único painel.