Do CVSS ao RBVM: como fazer uma priorização de vulnerabilidades bem feita

Quando você usa o Sistema de Pontuação de Vulnerabilidades Comuns (CVSS) pela primeira vez, é fácil pensar que esta é a ferramenta perfeita para a triagem e priorização de vulnerabilidades. Uma pontuação mais alta deve significar uma vulnerabilidade mais crítica, certo? Na verdade, essa abordagem não funciona muito bem. Todos os anos, vemos aumentar a quantidade de vulnerabilidades com pontuações CVSS altas. As equipes de segurança simplesmente não conseguem corrigi-las a tempo, mas a grande maioria dessas falhas nunca é realmente explorada em ataques do mundo real. Enquanto isso, os invasores estão constantemente aproveitando vulnerabilidades menos chamativas com pontuações mais baixas. Há outras armadilhas ocultas também, desde questões puramente técnicas, como pontuações conflitantes do CVSS, até questões conceituais, como a falta de contexto de negócios.

Essas não são necessariamente deficiências do próprio CVSS. Isso no entanto destaca a necessidade de usar a ferramenta corretamente, como parte de um processo de gerenciamento de vulnerabilidades mais sofisticado e abrangente.

Discrepâncias no CVSS

Você já notou como a mesma vulnerabilidade pode ter pontuações de gravidade diferentes, dependendo da fonte disponível? Uma pontuação do pesquisador de cibersegurança, outra do fornecedor do software vulnerável e outra de um banco de dados nacional de vulnerabilidades? Nem sempre é apenas um simples erro. Às vezes, diferentes especialistas podem discordar sobre o contexto da exploração. Eles podem ter ideias diferentes sobre os privilégios com os quais um aplicativo vulnerável é executado ou se tem interface com a Internet. Por exemplo, um fornecedor pode basear sua avaliação nas suas práticas recomendadas, enquanto um pesquisador de segurança pode considerar como os aplicativos são normalmente configurados em organizações do mundo real. Um pesquisador pode classificar a complexidade da exploração como alta, enquanto outro a considera baixa. Esta não é uma ocorrência incomum. Um estudo de 2023 da Vulncheck descobriu que 20% das vulnerabilidades no Banco de Dados Nacional de Vulnerabilidades (NVD) tinham duas pontuações CVSS3 de fontes diferentes e 56% dessas pontuações pareadas estavam em conflito entre si.

Erros mais comuns ao usar o CVSS

Por mais de uma década, a FIRST tem defendido a aplicação metodologicamente correta do CVSS. No entanto, as organizações que usam as classificações CVSS em seus processos de gerenciamento de vulnerabilidades continuam cometendo erros típicos:

1. Usar a pontuação base do CVSS como o principal indicador de risco. O CVSS mede a gravidade de uma vulnerabilidade, não quando ela será explorada ou o impacto potencial de sua exploração na organização sob ataque. Às vezes, uma vulnerabilidade crítica é inofensiva no ambiente de uma empresa específica porque reside em sistemas insignificantes e isolados. Por outro lado, um ataque de ransomware em larga escala pode começar com uma vulnerabilidade de vazamento de informações aparentemente inócua com uma pontuação 6 no CVSS.
2. Usar a pontuação CVSS básica sem ajustes de Ameaça/Temporal e Ambientais. A disponibilidade de patches, exploits públicos e medidas compensatórias influencia significativamente como e com que urgência uma vulnerabilidade deve ser tratada.
3. Concentrar-se apenas em vulnerabilidades acima de uma determinada pontuação. Essa abordagem às vezes é exigida por reguladores governamentais ou setoriais (“corrigir vulnerabilidades com pontuação CVSS acima de 8 dentro de um mês”). Como resultado, as equipes de cibersegurança enfrentam uma carga de trabalho continuamente crescente que, na realidade, não torna sua infraestrutura mais segura. A quantidade de vulnerabilidades com pontuações CVSS altas identificadas anualmente tem aumentado rapidamente nos últimos 10 anos.
4. Usar o CVSS para avaliar a probabilidade de exploração. Essas métricas são mal correlacionadas: apenas 17% das vulnerabilidades críticas são exploradas em ataques.
5. Usar apenas a classificação CVSS. A sequência de vetores padronizada foi introduzida no CVSS para que os defensores pudessem entender os detalhes de uma vulnerabilidade e calcular independentemente sua importância dentro de sua própria organização. O CVSS 4.0 foi especificamente revisado para facilitar a contabilização do contexto de negócios usando métricas adicionais. Quaisquer esforços de gerenciamento de vulnerabilidades baseados exclusivamente em uma classificação numérica serão amplamente ineficazes.
6. Ignorar fontes adicionais de informação. Confiar em um único banco de dados de vulnerabilidades e analisar apenas o CVSS é insuficiente. A ausência de dados sobre patches, provas de conceito funcionais e casos de exploração do mundo real dificultam a decisão de como lidar com as vulnerabilidades.

O que o CVSS não revela sobre uma vulnerabilidade

O CVSS é o padrão do setor para descrever a gravidade de uma vulnerabilidade, as condições sob as quais ela pode ser explorada e seu impacto potencial em um sistema vulnerável. No entanto, além dessa descrição (e da pontuação CVSS básica), há muito mais que o sistema não cobre:

• Quem encontrou a vulnerabilidade? O fornecedor, um pesquisador ético que relatou a falha e esperou por um patch, ou foi um agente malicioso?
• Existe um exploit disponível publicamente? Em outras palavras, existe um código prontamente disponível para explorar a vulnerabilidade?
• Qual o grau de praticidade de explorar em cenários do mundo real?
• Existe um patch disponível? Esse cobre todas as versões de software vulneráveis e quais são os possíveis efeitos colaterais de aplicá-lo?
• A organização deve tratar a vulnerabilidade? Ou isso afeta um serviço de nuvem (SaaS) onde o provedor corrigirá automaticamente as falhas?
• Há sinais de exploração ocorrendo no ciberespaço?
• Se não houver nenhuma, qual é a probabilidade de os invasores aproveitarem essa vulnerabilidade no futuro?
• Quais sistemas específicos dentro da sua organização são vulneráveis?
• A exploração é praticamente acessível a um invasor? Por exemplo, um sistema pode ser um servidor da web corporativo acessível a qualquer pessoa online ou pode ser uma impressora vulnerável fisicamente conectada a um único computador que não tem acesso à rede. Um exemplo mais complexo pode ser uma vulnerabilidade no método de um componente de software, na qual o aplicativo de negócios específico que usa esse componente nunca chama o método.
• O que aconteceria se os sistemas vulneráveis fossem comprometidos?
• Qual é o custo financeiro de tal evento para a empresa?

Todos esses fatores influenciam significativamente a decisão de quando e como corrigir uma vulnerabilidade ou mesmo se a correção é necessária.

Como ajustar o CVSS? A RBVM tem a resposta!

Muitos fatores que muitas vezes são difíceis de explicar dentro dos limites do CVSS são fundamentais para uma abordagem popular conhecida como gerenciamento de vulnerabilidades baseado em risco (RBVM).

O RBVM é um processo cíclico e holístico, com várias fases principais que se repetem regularmente:

• Inventário de todos os ativos de TI da sua empresa. Isso inclui tudo, desde computadores, servidores e software até serviços em nuvem e dispositivos IoT.
• Priorize ativos por importância: identificando suas joias da coroa.
• Verifique ativos quanto a vulnerabilidades conhecidas.
• Enriqueça os dados de vulnerabilidade. Isso inclui refinar as classificações CVSS-B e CVSS-BT, incorporar inteligência de ameaças e avaliar a probabilidade de exploração. Duas ferramentas populares para medir a explorabilidade são EPSS (outra classificação FIRST que fornece uma probabilidade percentual de exploração no mundo real para a maioria das vulnerabilidades) e bancos de dados de consulta como CISA KEV, que contém informações sobre vulnerabilidades exploradas ativamente pelos invasores.
• Defina o contexto de negócios: entender o impacto potencial de uma exploração em sistemas vulneráveis, considerando suas configurações e como eles são usados em sua organização.
• Determine como a vulnerabilidade pode ser neutralizada por meio de patches ou medidas compensatórias.
• A parte mais empolgante: avaliar o risco do negócio e definir prioridades com base em todos os dados coletados. As vulnerabilidades com a maior probabilidade de exploração e possível impacto significativo em seus principais ativos de TI são priorizadas. Para classificar vulnerabilidades, você pode calcular o CVSS-BTE, incorporando todos os dados coletados no componente ambiental ou usar metodologias de classificação alternativas. Aspectos regulatórios também influenciam a priorização.
• Definir prazos para a resolução de cada vulnerabilidade com base em seu nível de risco e considerações operacionais, como o momento mais conveniente para as atualizações. Se as atualizações ou os patches não estiverem disponíveis, ou se sua implementação introduzir novos riscos e complexidades, medidas compensatórias são adotadas em vez da remediação direta. Às vezes, o custo de corrigir uma vulnerabilidade supera o risco que ela representa, e pode se optar por não corrigi-la. Nesses casos, a empresa aceita conscientemente os riscos da vulnerabilidade que está sendo explorada.

Além do que discutimos, é crucial analisar periodicamente o cenário de vulnerabilidades e a infraestrutura de TI da sua empresa. Após essa análise, você precisa introduzir medidas de cibersegurança que impeçam que classes inteiras de vulnerabilidades sejam exploradas ou aumentem significativamente a segurança geral de sistemas de TI específicos. Essas medidas podem incluir microssegmentação de rede, implementação de privilégios mínimos e adoção de políticas de gerenciamento de contas mais rigorosas.

Um processo de RBVM implementado corretamente reduz drasticamente a carga sobre as equipes de TI e de segurança. As equipes gastam seu tempo de forma mais eficaz, pois seus esforços são direcionados principalmente para falhas que representam uma ameaça genuína aos negócios. Para compreender a escala desses ganhos de eficiência e economia de recursos, considere este PRIMEIRO estudo. A priorização de vulnerabilidades usando somente EPSS permite que você se concentre em apenas 3% das vulnerabilidades e alcance 65% de eficiência. Em contraste, priorizar pelo CVSS-B requer abordar 57% das vulnerabilidades com uma eficácia sombria de 4%. Aqui, “eficiência” refere-se à correção bem-sucedida de vulnerabilidades que realmente foram exploradas em estado selvagem.