Programas de divulgação de vulnerabilidades misteriosas e complexas atrapalham a segurança

A maioria das vulnerabilidades do produto agora são descobertas não pelo fornecedor afetado, mas por fontes externas, como pesquisadores terceirizados, e estão em todo o mapa.
As vulnerabilidades que criam brechas de segurança em potencial nos produtos da Internet das coisas (IoT) e do sistema de controle industrial (ICS) continuam crescendo.

Mais de 600 foram divulgados no primeiro semestre deste ano, de acordo com o mais recente ICS Risk &Vulnerability Report da Claroty. A maioria tem gravidade alta ou crítica, pode ser explorada fácil e remotamente e torna o componente afetado completamente inutilizável. Um quarto não tem correção ou pode ser apenas parcialmente corrigido.

Um exemplo da destruição potencial que poderia ser causada por vulnerabilidades desconhecidas à espreita na cadeia de fornecimento de software é o cluster BadAlloc recentemente denominado em RTOS e bibliotecas de suporte de vários fornecedores. Eles podem ser explorados para ataques de negação de serviço ou execução remota de código.

clique para imagem em tamanho real

(Fonte:Instituto Nacional de Padrões e Tecnologia)

Milhões de dispositivos de IoT e de tecnologia operacional (OT) - bem como sistemas de consumo, como carros e dispositivos médicos - são potencialmente afetados. Mesmo assim, os usuários OEM e proprietários de ativos não sabiam da existência dessas falhas até que a Microsoft as divulgou em abril.

No entanto, a maioria das vulnerabilidades do produto agora são descobertas não pelo fornecedor afetado, mas por fontes externas, como pesquisadores terceirizados. É por isso que existem programas de divulgação de vulnerabilidade (VDPs). Como explica o 2021 Ultimate Guide to Vulnerability Disclosure da Bugcrowd, os VDPs foram configurados para fornecer “um mecanismo para identificar e corrigir vulnerabilidades descobertas fora do ciclo típico de desenvolvimento de software”. Eles geralmente são administrados por entidades federais, organizações da indústria e alguns grandes fornecedores de produtos.

Sem consistência entre programas

Em resposta a uma diretiva operacional vinculativa de setembro de 2020 da Agência de Segurança Cibernética e de Infraestrutura (CISA), as agências federais estão postando suas políticas de divulgação de vulnerabilidade - confusamente, também indicado pela sigla “VDP”. Em julho, a CISA anunciou sua plataforma VDP. Fornecido pela Bugcrowd e EnDyna, ele servirá às agências federais civis como um site gerenciado centralmente onde os pesquisadores de segurança e outros podem relatar vulnerabilidades nos sites das agências.

Ron Brash
Mas a maioria dos VDPs controla vulnerabilidades em produtos, não em processos ou configurações. Infelizmente, há muito pouca consistência entre eles. “Esses programas estão espalhados por todo o mapa:até mesmo as agências federais dos EUA fazem suas próprias coisas”, disse Ron Brash, diretor de insights de segurança cibernética da Verve Industrial Protection, ao EE Times . “Nenhum deles está configurado para eficiência máxima.” Mesmo aqueles com bons mecanismos, como os programas NIST e ISO / IEC, têm disparidades entre esses mecanismos:o que é relatado e como, aplicação e como as mudanças necessárias são feitas por um determinado grupo.

Brash também culpou a falta de transparência nos relatórios. O governo dos Estados Unidos não desenvolveu o código para os produtos do tipo COTS que geralmente compra, portanto, as agências federais não têm propriedade real e devem agir como guardas de trânsito, disse ele. “As pessoas que deveriam estar fazendo o‘ policiamento ’não têm o conhecimento para realmente entender as questões em questão, ou seu impacto; não pode remediar com eficácia as vulnerabilidades devido a orçamentos, aprovações, uma plataforma EoL inadequada ou a incapacidade de provocar um fornecedor para fornecer uma correção; e não tem os meios para aplicar consequências ou forçar melhorias. ”

A propriedade também está faltando para um determinado conselho e para a sincronização do que é feito sobre isso nos programas governamentais e portais de fornecedores. “É o melhor esforço”, disse Brash. “Os grandes fornecedores geralmente assumem a propriedade, mas suas várias unidades de negócios podem fazer isso de maneira diferente. Uma vez que cada produto pode combinar vários produtos, o número de fornecedores se multiplica ainda mais. ”

Sistema de relatórios CVE tem limitações

A CISA patrocina os dois VDPs mais centrais dos EUA:o National Vulnerability Database (NVD), hospedado pelo National Institute of Standards and Technology (NIST), e o programa Common Vulnerabilities and Exposures (CVE) um pouco mais antigo, executado pelo MITER, que detalha publicamente vulnerabilidades conhecidas. A CISA também hospeda os alertas ICS-CERT, que incluem exploits e problemas.

“Mesmo se ignorarmos todo o processo de divulgação e aspectos de pesquisa, o sistema [de relatórios CVE] é misterioso e complexo”, disse Brash. “A maioria dos proprietários de ativos não tem o conhecimento necessário para entender adequadamente os conselhos de segurança OT / ICS ou para agir sobre eles. Então, eles ficam paralisados ​​pela quantidade de informações. ” Essa complexidade fica clara assistindo a apresentação de Brash no YouTube, um 101 para decifrá-los.

O sistema CVE não inclui tudo:um número crescente de vulnerabilidades não aparece lá. De acordo com o Risk Based Security, 2.158 vulnerabilidades foram publicadas em julho, 670 delas sem um CVE ID.

“Os CVEs são limitados a vulnerabilidades que afetam uma ampla gama de software que muitas empresas podem usar”, disse o pesquisador de segurança independente John Jackson, fundador do grupo de hackers éticos Sakura Samurai, ao EE Times . “[Mas] uma vulnerabilidade pode ser específica para lógica em software ou em um servidor que apenas uma empresa possui.”

Os VDPs federais visam principalmente agências federais, disse Brash. Pouco está disponível para empresas comerciais:algumas indústrias têm seus próprios reguladores, como a North American Electric Reliability Corporation (NERC) para concessionárias de energia elétrica. Embora as políticas e procedimentos da agência federal possam ser espelhados para uso na indústria privada, eles podem mudar a cada eleição presidencial, ele apontou.

“Alguns projetos de comunidade de código aberto estão gerenciando divulgações de vulnerabilidades muito bem”, disse Brash. “Por exemplo, algumas partes do kernel do Linux são bem gerenciadas; outros nem tanto, e isso nem mesmo considerando o ecossistema geral do Linux. E quando comparados a outros projetos de software livre e de código aberto, ou mesmo vários produtos proprietários, eles também têm práticas de segurança altamente variáveis. ”

Relatórios, problemas de divulgação

A falta de consistência entre os programas, especialmente na geração de relatórios, pode colocar os pesquisadores terceirizados em apuros, sem mencionar os possíveis problemas legais causados ​​pela Lei de Fraude e Abuso de Computadores (CFAA).

John Jackson

“Muitos VDPs exigem que os hackers não discutam suas descobertas, mas os programas não os pagam, nem lhes dão qualquer incentivo para hackear”, disse Jackson. “Além disso, eles geralmente são mal gerenciados ou mal gerenciados por pessoas que não são da área de segurança, o que dificulta a colaboração. Os VDPs que usam o Bugcrowd são um bom começo porque permitem que os hackers colaborem de forma eficaz e os triagers podem dar uma olhada na vulnerabilidade primeiro para confirmá-la. Ainda assim, isso não diminui a necessidade de segurança regular. ”

Um relatório de 2016 do NTIA Awareness and Adoption Group disse:“A grande maioria dos pesquisadores (92%) geralmente se envolve em alguma forma de divulgação coordenada de vulnerabilidades. A ameaça de ação legal foi citada por 60% dos pesquisadores como uma razão pela qual eles podem não trabalhar com um fornecedor para divulgar. Apenas 15% dos pesquisadores esperavam uma recompensa em troca da divulgação, mas 70% esperavam uma comunicação regular sobre o bug. ”

De acordo com o 2021 Ultimate Guide do Bugcrowd, 87% das organizações com seu próprio VDP relataram ter obtido uma vulnerabilidade crítica dele. Mas enquanto 99% dizem que consideram juntar-se ao seu VDP com um programa de recompensa por insetos, apenas 79% dizem que realmente pagam pesquisadores por "descobertas impactantes".

Como o problema se torna especialmente complicado com vulnerabilidades em produtos IoT incorporados, o processo de divulgação deve ser padronizado, disse Brash. Também deve haver “uma vara para aplicá-lo”, tanto no lado do proprietário do ativo quanto no lado do desenvolvedor do produto OEM. Ele prevê um registro para produtos IoT incorporados, como aqueles para recalls de automóveis. “Acredito que deve ser responsabilidade do fornecedor e do integrador de sistema garantir que o proprietário do ativo seja pelo menos informado sobre uma vulnerabilidade em seu ativo. Como acontece com o recall de um carro, o proprietário pode então decidir aceitar o risco, consertá-lo ou comprar um produto diferente ”.

>> Este artigo foi publicado originalmente em nosso site irmão, EE Vezes.