Comentário sobre o Programa CVE

O último mês marca 25 anos de operação do programa Common Vulnerabilities and Exposures (CVE), lançado em setembro de 1999. É difícil imaginar um mundo sem os CVEs. Grande parte das atividades de “gerenciamento de vulnerabilidades”, antes da popularização do programa CVE, baseava-se em comparar números de versão a partir de varreduras remotas e executar explorações duvidosas encontradas em lugares obscuros da internet para validar descobertas. Progredimos muito no que diz respeito ao rastreamento de vulnerabilidades, no entanto, nossa jornada tem sido repleta de desafios, incluindo:

• Incentivos: Como mencionei anteriormente, incentivos para criar CVEs são, às vezes, problemáticos.
• Volume: Para manter o ritmo com a quantidade de CVEs criados a cada ano, tivemos que aumentar o formato de numeração e designar CNAs (CVE Numbering Authority), espalhando a responsabilidade e dificultando a consistência.
• Rastreamento de datas: Em certas circunstâncias, CVEs serão emitidos no ano atual, mas com uma designação do ano anterior. Isso pode levar a análises imprecisas sobre vulnerabilidades na base de dados CVE.
• Mercado livre: Embora existam algumas orientações e barreiras, na maior parte, qualquer pessoa pode solicitar a emissão de um CVE, o que causou problemas com a automatização do processo de criação de CVEs com base em bugs corregidos em repositórios do GitHub.

A criação de um rastreamento formal para vulnerabilidades foi um marco para a indústria, mas não foi até 2005 que começamos a atribuir uma classificação de severidade usando CVSS. No entanto, essa abordagem também enfrenta desafios, tais como:

• Classificação subjetiva: Qualquer um pode classificar uma vulnerabilidade usando CVSS. Precisamos de mecanismos de verificação que permitirão ver diferentes pontuações.
• Reflete apenas a vulnerabilidade: CVSS, muitas vezes, é scoreado pelo CNA que mantém o software, que pode não ter incentivos para dar uma pontuação alta.
• Múltiplas versões de CVSS: Desde que a versão 1 do CVSS foi lançada em 2005, três versões subsequentes foram lançadas até novembro de 2023, sem que as actualizações de pontuação fossem necessariamente feitas ou difíceis de rastrear.

Próximos Passos

Dada a existência de prós e contras em cada um desses programas, como se pode decidir qual vulnerabilidade corrigir primeiro? Muitos se apoiarão em um mecanismo — provavelmente CVSS — e aplicarão um número mágico para decidir quais vulnerabilidades patchar. O problema é que essa é uma visão limitada. É essencial considerar que nem todas as vulnerabilidades críticas terão uma pontuação CVSS alta.

Uma abordagem mesclada não parece uma má ideia, mas confiar exclusivamente em orientações externas é equivalente a sacudir uma Bola Mágica e esperar que ela indique o que deve ser corrigido.

O que realmente importa durante o processo de patching é o impacto sobre a organização. Minha melhor recomendação é identificar as partes mais críticas de seu negócio, relacioná-las aos sistemas e aplicações, e corrigir esses primeiro, mantendo um foco em maximizar o número de patches aplicados aos sistemas prioritários.

Conclusão

Com frequência, ouço pessoas desconsiderando vulnerabilidades que podem ser devastadoras por vários motivos, como “Ninguém está atacando essas vulnerabilidades hoje”, “Não sou alvo de ataques de nações-estado” e “Um atacante teria que já estar no sistema”. Nenhuma dessas afirmações é relevante se um grupo determinado de atacantes busca sucesso, porque eles atacarão cada fraqueza em sua superfície de ataque: hardware, firmware, e software, desde o nível mais baixo até a nuvem.

Remediar vulnerabilidades é um processo complexo, e múltiplos fatores influenciam a decisão de aplicar um patch ou milhares deles em diversos sistemas. Apesar da complexidade, devemos continuar a aprimorar esse processo, ou os atacantes se beneficiarão enormemente dele. E, por favor, deixe a Bola Mágica de lado.

#CVE #Vulnerabilidades #Cybersecurity #SegurançaDaInformação #CVSS #GestãoDeRisco #Tecnologia

autor ref: Paul Asadoorian
ref:https://www.darkreading.com/vulnerabilities-threats/vulnerability-prioritization-magic-8-ball