Ideias, informações e conhecimentos compartilhados pela equipe
de Investigação, Desenvolvimento e Inovação da BASE4 Security.
⦁ Apresentação do CVSSv4 na FIRST Conference 2023
https://www.first.org/cvss/v4-0/cvss-v40-presentation.pdf
⦁ Documentação e recursos do CVSS v4.0 Public Preview
https://www.first.org/cvss/v4-0/
Nesta postagem, analisamos a nova versão do CVSS (Common Vulnerability Scoring System), que é uma ferramenta fundamental para que profissionais de segurança cibernética, administradores de sistemas e desenvolvedores avaliem a gravidade das vulnerabilidades e determinem a resposta adequada. Aqui, exploramos sua história, finalidade e componentes, e mencionamos suas alterações em relação à versão anterior.
Uma breve revisão
O CVSS é um padrão aberto para avaliar a gravidade das vulnerabilidades de segurança dos sistemas, que propõe uma maneira de capturar as principais características de uma vulnerabilidade e produzir uma pontuação numérica que reflete sua gravidade e pode ser traduzida em uma representação qualitativa. Ele foi desenvolvido por um Grupo de Interesse Especial (SIG) da organização FIRST e passou por várias alterações ao longo do tempo. Seu objetivo é poder comunicar e compartilhar detalhes sobre vulnerabilidades usando uma linguagem comum, melhorando a colaboração e o compartilhamento de informações entre as organizações no ecossistema de segurança cibernética.
O sistema consiste em três grupos de métricas: métricas de base, que são características intrínsecas de uma vulnerabilidade; métricas temporais, que são características que mudam com o tempo; e métricas ambientais, que são características específicas de um determinado ambiente.
Uma longa história
O CVSS teve uma longa jornada até a versão atual. Tudo começou em 2003, quando o National Infrastructure Advisory Council (NIAC) do governo dos EUA iniciou a pesquisa que levou ao lançamento da versão 1 (CVSSv1) em 2005, com o objetivo de criar uma classificação de gravidade aberta e universalmente padronizada para vulnerabilidades de software. Na verdade, a versão inicial não foi submetida à revisão por pares nem à revisão por outras organizações, o que impediu que ela obtivesse validade científica. Por esse motivo, o NIAC selecionou o FIRST (Forum of Incident Response and Security Teams) para sua manutenção e desenvolvimento futuro.
O feedback e o retorno das empresas e dos profissionais que usavam o CVSSv1 na produção sugeriram que ele não era suficientemente adequado, portanto, no mesmo ano de seu lançamento, foi iniciado o trabalho na versão 2 (CVSSv2), que foi publicada em 2007. No entanto, a comunidade que migrou para o uso do CVSSv2 apontou a falta de granularidade em várias métricas, o que resultou em pontuações que não distinguiam adequadamente as vulnerabilidades de diferentes tipos e perfis de risco, além de exigir muito conhecimento do impacto, o que reduziu sua precisão. Essas e outras críticas levaram ao lançamento da versão 3 (CVSSv3) em 2015, após 3 anos de trabalho. Tudo parecia estar resolvido, mas o aprimoramento contínuo tinha de continuar, e o CVSSv3 ainda apresentava pontos fracos para a pontuação de vulnerabilidades em sistemas emergentes, como a Internet das Coisas (IoT) e outros, portanto, uma atualização para a versão 3.1 foi lançada em 2019.
Essa versão, embora altamente refinada e madura, recebeu várias críticas muito específicas, como o fato de a pontuação básica ter sido usada como a principal entrada para a análise de risco, de não representar detalhes suficientes em tempo real sobre ameaças e impactos suplementares, de ser aplicável somente a sistemas de TI (não representando sistemas como saúde, segurança humana e controle industrial). Também foi criticado o fato de que as pontuações publicadas pelos fornecedores eram frequentemente altas ou críticas, que a granularidade era insuficiente (menos de 99 pontuações discretas) e que as métricas temporais não influenciavam efetivamente a pontuação final. Além disso, foi frequentemente apontado que a fórmula e as contas eram complicadas e contra-intuitivas.
E assim chegamos a junho de 2023, quando a versão preliminar 4 foi lançada para consulta pública, que se encerra em 31 de julho, enquanto a publicação oficial ocorrerá no último trimestre do ano.
Novos recursos
A versão 4 do CVSS faz alterações substanciais no sistema, portanto, deve ser totalmente compreendida para que possa ser usada. Seus novos recursos incluem os mencionados abaixo.
Para enfatizar que o CVSS não é apenas a pontuação básica, foi adotada uma nova nomenclatura para identificar as combinações do grupo Base. São elas: CVSS-B para pontuação básica, CVSS-BT para pontuação básica mais pontuação de ameaça, CVSS-BE para pontuação básica mais ambiental e CVSS-BTE para pontuação básica mais ameaça mais ambiental.
O grupo de métricas temporárias foi renomeado como grupo de métricas de ameaças, o que envolve métricas de ameaças simplificadas e esclarecidas, a remoção do nível de correção (RL) e da confiança do relatório (RC) e a renomeação da "maturidade do código de exploração" para Maturidade da exploração (E) com valores mais claros. A ideia é ajustar a pontuação Base do "pior caso razoável" usando a inteligência de ameaças para reduzir a pontuação CVSS-BTE, abordando a preocupação de que muitas pontuações CVSS (Base) são muito altas.
A nova métrica "Attack Requirements" (Requisitos de ataque) tem como objetivo resolver o problema da falta de reflexão das condições de alta complexidade nos valores de complexidade "baixa" e "alta". Portanto, a definição foi dividida em duas métricas, denominadas "Attack Complexity" (AC) e "Attack Requirements" (AT), que transmitem respectivamente o seguinte: a primeira reflete a complexidade de engenharia da exploração necessária para evadir ou contornar tecnologias defensivas ou de aprimoramento da segurança (medidas defensivas) e a segunda reflete as condições prévias do componente vulnerável que tornam o ataque possível.
A métrica "interação do usuário" foi atualizada para permitir maior granularidade ao considerar a interação de um usuário com um componente vulnerável, e tem três opções: Nenhuma (N), quando o sistema pode ser explorado sem nenhuma interação do usuário humano além do atacante; Passiva (P), quando a exploração exige interação limitada do usuário-alvo com o componente vulnerável e o payload do atacante (interações não intencionais); e Ativa (A), quando a exploração exige que o usuário realize interações específicas e conscientes.
A métrica "Escopo" foi abandonada, e dizem que foi a métrica menos compreendida da história, porque causou uma pontuação inconsistente entre os fornecedores de produtos e implicou em uma "compressão com perdas" dos impactos dos sistemas vulneráveis. Como solução, as métricas de impacto foram expandidas em dois conjuntos para avaliação explícita: Confidencialidade (VC), Integridade (VI) e Disponibilidade (VA) do sistema vulnerável; e Confidencialidade (SC), Integridade (SI) e Disponibilidade (SA) dos sistemas afetados.
Um novo conjunto de métricas suplementares foi incorporado para transmitir atributos extrínsecos adicionais de uma vulnerabilidade que não afetam a pontuação final do CVSS-BTE: Segurança Física e Humana (S), Automatizável (A), Recuperabilidade (R), Densidade de Valor (V), Esforço de Resposta (RE) e Urgência do Provedor (U). O consumidor da informação pode usar os valores dessas métricas para tomar medidas adicionais, se desejar, aplicando a importância local, com a ideia de que nenhuma define o impacto numérico na pontuação final do CVSS. As organizações podem atribuir importância e/ou impacto efetivo a cada métrica (ou conjunto de métricas), atribuindo mais, menos ou nenhum efeito na análise de risco final. As métricas e os valores simplesmente transmitem características extrínsecas adicionais da própria vulnerabilidade.
A métrica "Automatable" (Automatizável) captura a resposta sobre se um invasor pode automatizar a exploração dessa vulnerabilidade em vários alvos com base nas primeiras quatro fases da Kill Chain (reconhecimento, armamento, entrega e exploração). A métrica "Recuperação" descreve a resiliência de um componente ou sistema para recuperar serviços, em termos de desempenho e disponibilidade, após a ocorrência de um ataque. A "densidade de valor" descreve os recursos sobre os quais o invasor obterá controle com um único evento de exploração e tem dois valores possíveis: difuso e concentrado.
A métrica "Esforço de resposta à vulnerabilidade" fornece informações adicionais sobre a dificuldade que os consumidores têm de responder inicialmente ao impacto das vulnerabilidades em seus produtos e serviços de infraestrutura. Assim, o consumidor pode levar em conta essas informações adicionais sobre o esforço necessário ao aplicar mitigações ou programar a correção. Por fim, a métrica "Supplier Urgency" (Urgência do fornecedor) busca facilitar um método padronizado para incorporar uma avaliação adicional fornecida pelo provedor, que pode ser qualquer agente da cadeia de suprimentos, embora o mais próximo do consumidor esteja em uma posição melhor para fornecer essas informações específicas.
Outros sistemas de pontuação também foram introduzidos e adotados para abordar aspectos complementares da avaliação de vulnerabilidade e da priorização de correções. Esses são dois acréscimos à pontuação de vulnerabilidade, que fornecem algum recurso de previsão e suporte à decisão. O primeiro é o EPSS (Exploit Prediction Scoring System), um sistema de pontuação de previsão de exploração, que é um esforço orientado por dados para estimar a probabilidade de uma vulnerabilidade de software ser explorada em 30 dias. O segundo é o SSVC (Stakeholder-Specific Vulnerability Categorisation), uma categorização de vulnerabilidade específica das partes interessadas, que é um sistema de árvore de decisão para priorizar ações durante o gerenciamento de vulnerabilidades.
A era OT no CVSS
Um dos acréscimos mais notáveis a essa versão é o novo foco na tecnologia operacional (OT) por meio de métricas e valores de segurança física e humana (Safety). Atualmente, muitas vulnerabilidades têm impactos fora da tradicional tríade C/I/A de impacto lógico. Há uma preocupação crescente de que, embora os impactos lógicos possam ou não ser reconhecidos em um sistema vulnerável ou afetado, é possível que ocorram danos tangíveis aos seres humanos como resultado da exploração de uma vulnerabilidade. Os setores de IoT, ICS (Industrial Control Systems, sistemas de controle industrial) e saúde, em particular, estão muito preocupados em poder identificar esse tipo de impacto para ajudar a priorizar os problemas alinhados com suas crescentes preocupações.
Isso é feito por meio da análise dos valores de segurança ambiental fornecidos pelo consumidor e pelo fornecedor. No primeiro caso, quando um sistema não tem uso ou finalidade pretendidos diretamente alinhados com a segurança física, mas pode ter implicações de segurança física em uma questão de como ou onde é implantado, é possível que a exploração de uma vulnerabilidade nesse sistema possa ter impactos de segurança física e humana que podem ser representados no grupo de métricas ambientais. Esse valor mede o impacto em um ator ou participante humano que pode ser ferido como resultado de uma vulnerabilidade. Diferentemente de outros valores de métricas de impacto, a segurança física só pode ser associada ao conjunto "Impactar sistemas subsequentes" e deve ser considerada além dos valores de impacto das métricas de disponibilidade e integridade. Em "Modified Subsequent System Integrity: Segurança Física" (MSI:S), a exploração compromete a integridade do sistema vulnerável (por exemplo, alteração na dosagem de um dispositivo médico), resultando em um impacto na saúde e na segurança humana. Em "Disponibilidade do sistema subsequente modificado: segurança física" (MSA:S), a exploração compromete a disponibilidade do sistema vulnerável (por exemplo, indisponibilidade do sistema de freios de um veículo), resultando em um impacto na saúde e na segurança humanas.
Por outro lado, temos a segurança suplementar fornecida pelo fornecedor, que se aplica quando um sistema tem um uso pretendido alinhado à segurança, de modo que é possível que a exploração de uma vulnerabilidade possa ter um impacto na segurança física, que pode ser representada no grupo de métricas suplementares. Seus valores possíveis são: Presente (P), quando as consequências da vulnerabilidade atendem à definição das categorias de consequências da IEC 61.508 de "marginal", "crítica" ou "catastrófica"; Negligenciável (N), quando as consequências da vulnerabilidade atendem à definição da categoria de consequências da mesma norma de "insignificante"; e Não definido (X), quando o valor não foi definido para essa vulnerabilidade. Deve-se observar que os fornecedores não são obrigados a fornecer métricas suplementares, e elas podem ser fornecidas conforme necessário, com base apenas no que o fornecedor decidir comunicar em cada caso.
A fórmula do sistema
A matemática por trás do cálculo no sistema CVSS foi criticada por muito tempo até a versão 3.1, portanto, um dos aspectos mais interessantes é o desenvolvimento de um novo sistema de pontuação, que consistia em um processo relativamente complexo em comparação com a forma (mais duvidosa) como era feito antes. O processo começou pegando os 15 milhões de vetores CVE-BTE em 270 conjuntos de equivalência, pedindo aos especialistas que comparassem os vetores que representavam cada um deles, calculando uma ordem de vetores do menos grave para o mais grave e, novamente, pedindo a opinião de especialistas para decidir qual grupo representa o limite entre as pontuações de gravidade qualitativa para ser compatível com os limites de pontuação de gravidade qualitativa do CVSS v3.x. Os grupos de vetores em cada intervalo de gravidade qualitativa foram então compactados na pontuação desse intervalo (por exemplo, 9 a 10 para crítico, 7 a 8,9 para alto etc.) e foi criado um fator de modificação que ajusta as pontuações em um grupo de vetores de modo que uma alteração em qualquer valor de métrica resulte em uma alteração na pontuação. A intenção é que a alteração da pontuação não seja maior do que a incerteza na classificação dos grupos de vetores, conforme coletado nos dados de comparação.
Como nas versões anteriores, uma calculadora on-line está disponível para facilitar a visualização dos atributos de cada grupo de métricas e também serve como um recurso didático para projetar cenários simulados que precisam ser quantificados.
Vulnerabilidades versus riscos
Outra questão que foi levantada como uma desvantagem na aplicação potencialmente leve ou descontextualizada do CVSS é a gravidade técnica versus risco. Por um lado, as pontuações do CVSS Base (CVSS-B) representam a gravidade em nível técnico, levam em conta apenas os atributos da própria vulnerabilidade e não são recomendadas para serem usadas isoladamente para determinar a prioridade de correção. Por outro lado, o risco pode ser analisado com os atributos completos do CVSS-BTE (pontuação básica, ameaça associada e controles ambientais), de modo que, se usadas corretamente, essas pontuações podem representar com mais precisão o conjunto completo de atributos para as pontuações de risco, até mesmo mais do que algumas metodologias.
Por fim, vale a pena observar que o FIRST recomenda várias práticas para o uso adequado do CVSS. Em primeiro lugar, o uso de fontes e bancos de dados para automatizar o enriquecimento das informações de vulnerabilidade, como o NVD (National Vulnerability Database) para métricas de base, o banco de dados de ativos para métricas ambientais e a inteligência de ameaças para métricas de ameaças. Também propõe encontrar maneiras de visualizar as informações de vulnerabilidade de acordo com atributos e pontos de vista importantes, como equipes de suporte, aplicativos críticos, visão interna versus externa, unidades de negócios ou requisitos normativos.
Conclusões
A versão 4 do CVSS traz consigo um nível muito alto de maturidade em relação às suas antecessoras. Se a intenção fosse chegar a esse ponto muito antes, talvez não fosse uma opção válida, pois as comunidades, as organizações e os profissionais tiveram que crescer com os lançamentos e com as exigências do setor. A responsabilidade da FIRST ao publicar esse tipo de trabalho é excessivamente grande, considerando os vários ambientes em que o sistema de pontuação é usado e, apesar das críticas às versões anteriores, eles sempre conseguiram fazer um trabalho adequado à necessidade do momento.