Triagem de CVE

Um scanner entrega-lhe quatrocentos identificadores CVE e uma coluna de gravidade que chama críticos a quase todos. Esta mesa ordena a lista pelo que está realmente a ser explorado: o catálogo KEV da CISA para a exploração conhecida, as pontuações EPSS da FIRST para a probabilidade de exploração e o CVSS para o impacto —cada dado impresso junto à prioridade que produziu, para que a ordem seja auditável e não um número mágico—.

Ainda não foram encontrados identificadores CVE na entrada.

Trabalha com uma fila de patches todas as semanas? Vigie os seus sites grátis com o myeventwatch — alertas de expiração e indisponibilidade, sem cartão.

Como funciona a ordenação

Cada identificador é procurado em três fontes e recebe uma faixa de prioridade conforme a primeira regra que cumpre. P1 é pertencer ao catálogo de vulnerabilidades exploradas conhecidas (KEV) da CISA: não são previsões —a CISA só inclui um CVE com provas de exploração ativa—, por isso uma entrada KEV supera tudo o resto, e a tabela mostra a sua data-limite de correção e se a CISA marca uso conhecido de ransomware. P2 é uma pontuação EPSS de 0,10 ou superior: o EPSS, mantido pela FIRST, modela a probabilidade de um CVE ser explorado nos próximos 30 dias, e 0,10 é alto —a grande maioria dos CVE pontuados está abaixo de 0,01, por isso também se mostra a coluna de percentil, para manter a pontuação bruta honesta—. P3 é uma pontuação base CVSS de 7,0 ou superior (Alta ou Crítica) sem sinal de exploração: grave se for usada, sem que se saiba que é usada. P4 é tudo o resto que tem dados. Dentro de uma faixa, as linhas ordenam-se por EPSS e depois por CVSS —e cada cabeçalho de coluna volta a ordenar a tabela, porque a sua fila pode diferir legitimamente da ordem predefinida—. O que a faixa nunca faz é esconder os seus dados: se discordar da prioridade de uma linha, os números de onde ela saiu estão na mesma linha.

De onde vêm os dados e quão frescos são

O catálogo KEV e as pontuações EPSS são guardados em cache diariamente no servidor da sysosx —ambos os editores publicam um ficheiro em lote por dia, por isso a mesa descarrega esses ficheiros uma vez por dia e a sua consulta lê as cópias locais—. O cabeçalho do resultado indica a data própria de cada fonte (a data de publicação do catálogo, a data de pontuação EPSS) e quando foi obtida, para que saiba sempre que dia de dados ordenou a sua lista. O CVSS é a exceção: nem o KEV nem o EPSS o incluem, por isso as pontuações vêm da NVD —obtidas uma vez, na primeira vez que um CVE é procurado, e guardadas em cache permanentemente no servidor, porque uma pontuação CVSS publicada não muda—. Uma colagem muito recente pode, por isso, mostrar algumas pontuações como pendentes: isso significa que a cache ainda não chegou a esses identificadores, não que eles não tenham pontuação —volte a executar a lista pouco depois e elas completam-se—. As consultas novas são limitadas por visitante como as outras verificações do servidor, e repetir a mesma colagem é servido a partir de uma cache breve. Por baixo, a página chama GET /api/check/cve-triage no servidor da sysosx com os identificadores extraídos.

O que esta mesa não lhe pode dizer

Três limites honestos. Primeiro, «Não está nos dados em cache de hoje» é uma ausência em três conjuntos de dados, não um veredicto: não é explorado conhecido, não tem pontuação EPSS e a NVD não tem registo —pode continuar a ser novo, disputado ou pontuado com outro identificador, e merece uma revisão manual em vez de um encolher de ombros—. Segundo, os dados de exploração falam do CVE no mundo, não do seu ativo: um P4 num servidor exposto à internet pode superar um P1 numa caixa de testes isolada, e só você sabe qual é qual —faça primeiro a triagem do lote exposto à internet, que é também por que a mesa aceita 200 identificadores de cada vez em vez de fingir que uma ordenação serve para todo um parque—. Terceiro, a inclusão no KEV vai atrás da exploração e o EPSS é um modelo, não um oráculo; ambos são provas muito melhores do que a gravidade sozinha, e nenhum substitui ler o aviso do fornecedor para os P1. O raciocínio por trás da ordenação —e um exemplo resolvido— está em fazer a triagem dos CVE por exploração, não só por gravidade.

Ferramentas relacionadas: o scanner de portas para saber que serviços um anfitrião expõe realmente (a metade de ativo de cada decisão sobre CVE), a verificação de saúde do site para o certificado, a expiração e os registos do mesmo anfitrião, e o classificador SSL quando a descoberta é uma configuração TLS e não um CVE.

Perguntas frequentes

De onde vêm os dados e quão frescos são?

Três fontes públicas, cada uma etiquetada com a sua data no resultado. O catálogo de vulnerabilidades exploradas conhecidas da CISA e as pontuações diárias EPSS da FIRST são descarregados para o servidor da sysosx uma vez por dia e guardados em cache lá —a sua consulta lê a cópia local, não consulta a CISA nem a FIRST em tempo real—. As pontuações CVSS vêm da NVD: a primeira consulta de um CVE obtém-no uma vez e guarda-o em cache permanentemente, porque uma pontuação CVSS publicada não muda. Se uma pontuação disser «pendente», a cache ainda não chegou a esse CVE —volte a executar a lista num minuto e ela completa-se—.

Um CVE do meu scanner falta ou mostra «não está nos dados em cache de hoje». É seguro?

Não há nenhuma conclusão assim disponível, e a página não fingirá o contrário. «Não encontrado» significa apenas que o identificador não aparece em nenhuma das fontes em cache de hoje —não está no catálogo KEV, não tem pontuação EPSS no ficheiro atual e a NVD não tem registo CVSS dele—. Todos os dias aparecem CVE novos, o EPSS só pontua os CVE que modelou, e um CVE pode ser real, grave e simplesmente demasiado novo para qualquer uma das três. Trate as linhas em falta como «triagem à mão», não como «ignorar».

Porque é que um CVSS 9,8 fica abaixo de um CVSS 7,5?

Porque a ordenação é por exploração, não por impacto. O 7,5 está no catálogo KEV: sabe-se que os atacantes o estão a usar, por isso é P1. O 9,8 tem uma pontuação EPSS alta ou nenhuma —grave se for explorado, mas sem provas de que alguém o esteja a explorar ainda—. A gravidade diz-lhe quão má seria uma violação; o KEV e o EPSS dizem-lhe quão provável é uma tentativa. A ordem de aplicação de patches deve seguir primeiro a probabilidade e usar a gravidade como desempate, que é o que as faixas P1–P4 codificam. O artigo ligado abaixo desenvolve o raciocínio completo.

O que significam exatamente as faixas de prioridade?

P1: o CVE está no catálogo KEV da CISA —explorado conhecido, aplique o patch agora e note a coluna de data-limite KEV—. P2: não está no KEV, mas a sua pontuação EPSS é de 0,10 ou superior —uma probabilidade modelada de 10 % ou mais de exploração nos próximos 30 dias, um ar muito rarefeito (muito menos de 1 % dos CVE pontuados)—. P3: nenhuma das duas coisas, mas uma pontuação base CVSS de 7,0 ou superior (Alta ou Crítica). P4: tem dados mas não cumpre nenhum limiar —agende-o normalmente—. Cada dado por trás da faixa é impresso na sua própria coluna; a faixa é uma ordem de classificação, não uma pontuação que tenha de aceitar por fé.

Posso fazer a triagem de mais de 200 CVE?

A mesa aceita 200 identificadores por consulta —cole a lista em dois lotes—. Esse limite evita que um pedido monopolize o verificador e, na prática, uma exportação de scanner é mais útil dividida por grupo de ativos de qualquer forma: faça primeiro a triagem do lote exposto à internet, porque o mesmo CVE é uma emergência diferente num servidor público e numa estação de trabalho isolada.