Interrupção do banco de dados de vulnerabilidade nacional: o que aprendemos

Recentemente, tem havido preocupações crescentes sobre a falta de dados de Enumeração de Plataforma Comum (CPE) de entradas de vulnerabilidade no Banco de Dados Nacional de Vulnerabilidade (NVD). Reunindo histórias de pesquisadores e postagens nas redes sociais, a falta de informações sobre CPE, que está faltando nas entradas desde o início de fevereiro, representa uma preocupação crescente para praticamente qualquer pessoa na indústria de software. Ao mesmo tempo, não deveria ser uma surpresa.

O papel do CPE

O NVD utiliza outros sistemas padronizados, como o CPE, para identificar consistentemente os sistemas e plataformas afetados. Assim, sem dados CPE, uma vulnerabilidade parece não ter impacto nos sistemas. Isso pode ser facilmente remediado observando as informações da fonte. Mas na escala atual e na crescente complexidade do gerenciamento de dependências, os sistemas automatizados que utilizam fontes de dados como o NVD são essenciais.

Por outras palavras, qualquer pessoa que dependa de sistemas que utilizem exclusivamente fontes públicas como o NVD está potencialmente em risco há meses, apesar de não receber avisos em contrário. Esta perturbação é mais um exemplo de uma questão sistémica que evoluiu ao longo de muitos anos.

Rachaduras na parede

É difícil acreditar que o NVD se tornou o banco de dados de vulnerabilidades de software mais utilizado no mundo. Muitos scanners, analistas e fornecedores dependem dele diariamente para determinar qual software foi afetado por uma vulnerabilidade. Isto por si só ajuda a expor a escala e o impacto ao público quando falta informação no NVD.

Isto levanta a questão: com tantas organizações e sistemas automatizados dependendo de dados ricos sobre vulnerabilidades, por que o NVD não seria tratado como um sistema crítico?

Um único ponto de falha

Em sua essência, o NVD nunca foi concebido para ser a solução definitiva. E, embora seja fácil apontar o dedo ao NVD, muitos intervenientes importantes contribuíram para o estado atual. A história do NVD não serve apenas como um episódio de advertência, mas como um emblema nítido de questões sistémicas mais profundas que assolam a segurança cibernética. Esta última edição é mais o eco de um canário morto há muito tempo na mina de carvão da identificação e divulgação de vulnerabilidades, especialmente no que diz respeito às vulnerabilidades de software de código aberto.

Embora não sejam exaustivos, três pontos-chave ajudaram a moldar a ineficácia moderna do NVD.

1. Responsabilidades Compartilhadas

Historicamente, o panorama da cibersegurança foi moldado por ações e políticas da indústria de software e do governo dos EUA, juntamente com contribuições de investigadores individuais. Muitas narrativas enquadram os investigadores como meros oportunistas que procuram fama através da divulgação de vulnerabilidades. Embora isto possa ser verdade, tende a simplificar demasiado um ecossistema complexo onde, durante anos, grandes empresas tecnológicas penalizaram hackers de chapéu branco bem-intencionados, e o investimento do governo em recompensas de bugs alimentou inadvertidamente um mercado lucrativo para vulnerabilidades de dia zero.

2. Mudanças Corporativas e Evolução do Código Aberto

O que se tornou um mercado negro de vulnerabilidades, e não apenas para agências governamentais, tornou-se uma forma de as empresas controlarem as narrativas de vulnerabilidade através da divulgação selectiva. À medida que as empresas procuravam evitar divulgações independentes através da introdução dos seus programas de recompensa por bugs, inadvertidamente entraram num paradigma que exigia delas mais do que meras medidas reativas. A explosão do código aberto ao longo das últimas quatro décadas complicou ainda mais este cenário, levando sistemas tradicionais como o NVD aos seus limites sem uma evolução correspondente na gestão da qualidade e consistência dos seus resultados.

3. Maior responsabilidade

O verdadeiro cerne da questão não reside no NVD em si, mas no contexto mais amplo da responsabilidade do fabricante de software e do papel das agências governamentais. Historicamente, os fabricantes têm gerido a divulgação de vulnerabilidades através do controlo e do direito contratual, contribuindo para um cenário marcado pela falta de responsabilização. Vulnerabilidades recentes de alto perfil ressaltaram a necessidade de maior responsabilidade corporativa e políticas governamentais assertivas que garantam práticas de segurança e protocolos de divulgação mais rigorosos.

Melhores dados: este é o caminho

Simplesmente não há como pesquisar vulnerabilidades manualmente em grande escala. Assim, a dependência de sistemas automatizados para identificar e mitigar vulnerabilidades é crítica para a inovação na fabricação de software moderno.

No entanto, nem todos os dados são criados igualmente.

A ausência de dados CPE relativos a vulnerabilidades sublinha a necessidade de aperfeiçoar os quadros existentes para promover um ambiente onde as contribuições genuínas sejam reconhecidas e o ruído seja minimizado. A dependência estrita de ferramentas que extraem exclusivamente de uma única fonte de dados públicos continuará a apresentar lacunas que introduzem riscos acrescidos. Ao mesmo tempo, esperar que o NVD melhore ou se torne mais consistente não é uma opção.

Para garantir a integridade e a eficácia dos nossos esforços colectivos de segurança, a comunidade de segurança cibernética deve reavaliar a sua confiança no NVD e adaptar os seus processos para responder à dinâmica em evolução da gestão de vulnerabilidades.

À medida que navegamos nestas complexidades, a história que se desenrola em torno da NVD lembra-nos que enfrentar estes desafios envolve o reconhecimento de responsabilidades partilhadas, a promoção da colaboração entre sectores e o apoio inovador aos esforços comunitários. Ao mudar o nosso foco da culpa para a acção colectiva, podemos começar a desvendar as questões sistémicas que há muito dificultam o progresso no fornecimento de software seguro e protegido desde a concepção.

A postagem Interrupção do banco de dados de vulnerabilidade nacional: o que aprendemos apareceu pela primeira vez em The New Stack.