Por/By: Lion Focus Insights
Durante muito tempo, uma das formas mais práticas de organizar a correção de vulnerabilidades foi começar pelas críticas, seguir para as altas e continuar descendo a lista. E não há nada de errado em usar a severidade como ponto de partida. Quando existem centenas ou milhares de findings e é preciso estabelecer algum critério, ela oferece uma referência objetiva e fácil de entender.
O problema aparece quando ela vira também o ponto de chegada.
Imagine uma vulnerabilidade com CVSS 9.8 em um servidor interno, segmentado e sem acesso direto pela Internet. Em outro ambiente existe uma vulnerabilidade 7.5 em uma aplicação pública. Ela pode ser alcançada externamente e, além disso, há evidências de exploração dessa vulnerabilidade no mundo real.
Se você tivesse capacidade para corrigir apenas uma delas hoje, começaria necessariamente pela 9.8?
Provavelmente seria necessário saber um pouco mais antes de responder.
E é justamente esse “saber um pouco mais” que torna a priorização de vulnerabilidades interessante.
O CVSS não está errado
Às vezes a discussão sobre priorização acaba colocando o CVSS no papel de vilão, como se usar severidade fosse uma prática ultrapassada. Não é isso.
O CVSS continua sendo uma referência importante para representar características técnicas de uma vulnerabilidade de forma padronizada. Vetor de ataque, complexidade, privilégios necessários, interação do usuário e possíveis impactos sobre confidencialidade, integridade e disponibilidade fazem parte dessa avaliação.
O que ele não pretende fazer sozinho é responder qual vulnerabilidade representa o maior risco para uma organização específica.
O próprio FIRST, responsável pelo CVSS, faz essa distinção ao explicar que o CVSS Base mede severidade, e não risco. O Base Score representa características intrínsecas da vulnerabilidade, independentemente das particularidades de cada ambiente.
Isso parece apenas uma diferença conceitual, mas na prática muda bastante coisa.
Em análises de vulnerabilidades, é relativamente comum encontrar situações em que o finding de maior CVSS não é necessariamente aquele que mais chama nossa atenção. Uma vulnerabilidade menos severa pode estar em uma condição muito mais favorável para um atacante.
Então começam a aparecer outras perguntas.
Esse ativo está exposto? A vulnerabilidade pode ser explorada remotamente? Existem condições específicas para que a exploração funcione? Há exploit disponível? Existem evidências de ataques utilizando essa vulnerabilidade?
Veja que não estamos descartando a severidade. Estamos colocando contexto ao redor dela.
É por isso que uma forma útil de pensar na priorização é considerar três dimensões:
Severidade + Explorabilidade + Exposição
Não como uma fórmula universal capaz de calcular todo o risco de uma organização, mas como três informações que ajudam bastante a responder uma pergunta muito mais prática: por onde começamos?
Algumas informações mudam bastante a fila
Vamos voltar às duas vulnerabilidades do início.
A primeira tem CVSS 9.8, mas está em um ambiente interno e segmentado. A segunda tem CVSS 7.5, está exposta à Internet e descobrimos que existem evidências de exploração ativa.
A primeira não deixou de ser crítica. Seu CVSS também não precisa mudar.
Mas agora sabemos algo sobre a segunda que não estava representado simplesmente pela severidade.
Um exemplo bastante claro desse tipo de informação é o Known Exploited Vulnerabilities Catalog (KEV), mantido pela CISA. O catálogo reúne vulnerabilidades para as quais existem evidências de exploração no mundo real, e a própria CISA recomenda utilizá-lo como uma das entradas para priorização.
Isso não significa que tudo o que aparece no KEV deva automaticamente passar na frente de qualquer outra vulnerabilidade. Também não significa que aquilo que não está no catálogo seja pouco importante.
Mas, se estamos tentando decidir o que tratar primeiro, saber que uma vulnerabilidade está efetivamente sendo utilizada por atacantes é uma informação difícil de ignorar.
Há ainda situações em que não temos evidência de exploração conhecida, mas queremos entender melhor a possibilidade de isso acontecer.
É nesse espaço que entra o EPSS (Exploit Prediction Scoring System). Mantido pela FIRST, ele estima a probabilidade de uma vulnerabilidade publicada ser explorada in the wild nos próximos 30 dias.
É comum encontrar discussões colocando CVSS e EPSS lado a lado como se fosse necessário decidir qual deles é melhor. Talvez a pergunta esteja mal colocada.
Eles nos contam coisas diferentes.
Uma vulnerabilidade pode ter severidade alta e baixa probabilidade estimada de exploração. Outra pode ter severidade menor e apresentar sinais muito mais relevantes do ponto de vista de ameaça.
E ainda falta uma informação importante nessa história: onde essa vulnerabilidade está.
A mesma vulnerabilidade, três situações diferentes
Pense na mesma vulnerabilidade crítica presente em três ativos.
Um deles é um servidor de laboratório isolado. Outro está disponível apenas na rede interna. O terceiro é um serviço publicado diretamente na Internet.
A vulnerabilidade é a mesma. O CVSS é o mesmo. Se olharmos apenas para uma exportação do scanner, os três findings podem acabar praticamente lado a lado.
Para um atacante externo, entretanto, não são três situações iguais.
Quando analisamos uma exposição, uma das primeiras coisas que queremos entender é justamente se aquele caminho está disponível para um atacante. Um serviço publicado na Internet naturalmente merece uma análise diferente de algo que não pode ser alcançado da mesma maneira.
Isso também mostra por que Gestão de Vulnerabilidades e visibilidade da superfície de ataque começam a se encontrar.
Não adianta saber apenas que uma vulnerabilidade existe. Saber onde ela existe e como aquele ativo está exposto ajuda a entender melhor o cenário.
E o contexto pode ir além.
Se sabemos que determinado ativo suporta uma operação crítica, contém informações sensíveis ou possui uma função importante para o negócio, essa informação pode influenciar a decisão. O mesmo acontece com controles compensatórios que dificultem uma exploração ou reduzam seu possível impacto.
Nem sempre essas informações estarão disponíveis. Na realidade, muitas vezes não estarão.
E talvez esse seja outro ponto importante: não precisamos esperar ter um modelo perfeito de risco para melhorar a priorização. Se hoje conseguimos combinar severidade, informações sobre explorabilidade e exposição, já temos muito mais contexto do que uma fila baseada exclusivamente em CVSS.
À medida que a organização amadurece e consegue incorporar criticidade dos ativos, controles e possíveis impactos ao negócio, a análise pode ganhar novas camadas.
O NIST aborda justamente essa relação entre riscos cibernéticos, prioridades organizacionais e recursos disponíveis. Afinal, decidir prioridade também significa reconhecer algo bastante concreto: nenhuma organização possui capacidade ilimitada para tratar tudo ao mesmo tempo.
O scanner terminou. Agora começa outra parte do trabalho.
Esse talvez seja um dos aspectos menos discutidos da Gestão de Vulnerabilidades.
Encontrar vulnerabilidades ficou relativamente eficiente. Dependendo do ambiente, não é difícil produzir uma lista enorme delas.
O scanner termina e aparecem 500, 2.000, 10.000 findings.
E agora?
Se a resposta for simplesmente ordenar a planilha de Critical até Low e enviá-la para os responsáveis, ainda resta uma parte considerável do problema.
Alguém terá que decidir o que fazer primeiro.
É nessa hora que uma vulnerabilidade 7.5 pode começar a incomodar mais do que uma 9.8. Ou que um finding que estava há semanas no backlog muda de prioridade porque surgiu um exploit. Ou porque entrou no KEV. Ou simplesmente porque alguém descobriu que aquele servidor que todos acreditavam ser interno também responde pela Internet.
Essas situações ajudam a perceber que prioridade não é uma característica permanente da vulnerabilidade.
O CVSS pode continuar exatamente igual enquanto tudo ao redor dele muda.
Essa talvez seja uma das diferenças mais importantes entre classificar uma vulnerabilidade e gerenciar a exposição associada a ela.
Há também um risco no sentido contrário. Quando começamos a adicionar contexto, é tentador procurar uma nova pontuação que resolva definitivamente o problema: juntamos CVSS, EPSS, KEV, exposição, criticidade e mais algumas variáveis e esperamos que o resultado diga exatamente o que fazer.
Esses modelos podem ser muito úteis. Mas ainda precisam ser interpretados.
Não existe uma nota que conheça perfeitamente cada arquitetura, cada controle, cada dependência e cada consequência possível para o negócio.
Em algum momento, principalmente nos casos mais relevantes, ainda será necessário analisar evidências e tomar uma decisão.
E isso não é uma deficiência do processo. É parte dele.
Então, o que deveria vir primeiro?
Voltemos pela última vez ao nosso CVSS 9.8 e ao 7.5.
Com as poucas informações do início do artigo, provavelmente não seria responsável decidir apenas olhando para os números.
Depois descobrimos que o 7.5 está exposto à Internet e possui evidências de exploração. Agora temos motivos concretos para considerar tratá-lo antes.
Se amanhã descobrirmos que o 9.8 está em um ativo crítico, acessível por outro caminho e envolvido em uma cadeia de ataque relevante, talvez a decisão mude novamente.
É assim que deveria ser.
Gestão de Vulnerabilidades não precisa abandonar a severidade. Precisa apenas reconhecer que ela representa uma parte da decisão.
No final, quando uma equipe tem milhares de vulnerabilidades e capacidade para tratar apenas uma parcela delas agora, saber qual possui o maior CVSS é útil.
Mas dificilmente será a única pergunta que ela vai querer fazer.
Referências
- FIRST — CVSS v4.0 User Guide
- CISA — Known Exploited Vulnerabilities Catalog
- FIRST — Exploit Prediction Scoring System (EPSS)
- NIST — Prioritizing Cybersecurity Risk for Enterprise Risk Management
Continue explorando
- O que é superfície de ataque e por que ela muda continuamente?
- O que é CTEM e como funciona o Continuous Threat Exposure Management?
- O que é um vetor de ataque? Entenda a relação com a superfície de ataque
Quer levar essa visão para a sua superfície de ataque?
Conheça como o Lion Focus ajuda a descobrir, acompanhar, validar e priorizar exposições cibernéticas.
Leonnes Cybersecurity
Cyber Exposure Platform
