0
0
Existe um manual padrão e práticas recomendadas para quando uma organização descobre ou é notificada sobre uma vulnerabilidade de software: A organização trabalha rapidamente para corrigir o problema e, assim que uma correção estiver disponível, divulga essa vulnerabilidade para o benefício da comunidade. Este manual nem sempre é perfeito, mas estabelece um compromisso razoável entre fornecer tempo para corrigir uma vulnerabilidade e disseminar esse conhecimento para ajudar a prevenir vulnerabilidades semelhantes no futuro.
A legislação recentemente proposta da UE, denominada Lei de Resiliência Cibernética ( CRA ), ameaça derrubar esta prática, ao exigir que as empresas comuniquem vulnerabilidades antes de serem adequadamente corrigidas. Se esta legislação for aprovada na forma actualmente proposta, o resultado poderá ser desastroso.
O principal problema: uso indevido de informações
Geralmente apoiamos os objetivos da Lei de Resiliência Cibernética. Tal como está actualmente redigida, grande parte da legislação melhoraria para melhor a segurança cibernética da UE. Mas exigir que as empresas comuniquem vulnerabilidades não corrigidas provavelmente terá o efeito oposto e tornará as organizações e os cidadãos da UE menos seguros.
No âmbito da CRA (na sua forma atual), é assim que o requisito de comunicação funcionaria: quando um fabricante identifica uma vulnerabilidade ativamente explorada, o fabricante tem 24 horas para reportá-la à Agência da União Europeia para a Cibersegurança (ENISA). As informações e os detalhes sobre a vulnerabilidade seriam então transmitidos às equipas de resposta a incidentes de segurança informática (CSIRT) dos Estados-Membros, bem como às autoridades de fiscalização do mercado dos Estados-Membros.
O principal problema aqui é que essas informações podem ser mal utilizadas.
Historicamente, as vulnerabilidades identificadas, mas não corrigidas, permaneceram ocultas por uma razão: no momento em que os malfeitores souberem do problema, eles correrão para explorá-las. Embora a CRA não exija que as empresas transmitam à ENISA as especificações técnicas completas de uma vulnerabilidade explorada, exige que as empresas comuniquem uma vulnerabilidade “com detalhes” – e esses detalhes podem ser mais do que suficientes para atrair a atenção de um atacante experiente. Como afirma o Guia CERT para divulgação coordenada de vulnerabilidades : “O mero conhecimento da existência de uma vulnerabilidade em um recurso de algum produto é suficiente para que uma pessoa habilidosa a descubra por si mesma”.
Além disso, se todos os relatórios de vulnerabilidade não corrigidos forem primeiro reunidos no mesmo local e depois distribuídos a 27 governos diferentes em toda a UE, os arsenais resultantes tornar-se-ão alvos irresistíveis para os atacantes. A CRA (tal como está redigida atualmente) também não protege adequadamente contra agências governamentais que tenham acesso a esta informação (e potencialmente a utilizem indevidamente).
A CRA também corre o risco de fornecer cobertura para outras leis problemáticas de divulgação de vulnerabilidades, especificamente os Regulamentos da China sobre a Gestão de Vulnerabilidades de Segurança de Produtos de Rede (RMSV). Esta lei de 2021 exige que os fornecedores de produtos de rede da China notifiquem imediatamente o governo chinês sobre quaisquer vulnerabilidades detectadas em produtos de rede. Estudos de investigação sugerem que estas divulgações de vulnerabilidades estão agora a ser utilizadas para fins de inteligência e que o regulamento pode ter prejudicado o acesso dos fornecedores de software às informações sobre vulnerabilidades, ao dissuadir os hackers éticos de procurarem vulnerabilidades.
Ao encorajar hackers éticos a procurar e reportar potenciais vulnerabilidades, as empresas salvaguardaram tanto os seus próprios negócios como os dados dos seus clientes. Mas o CRA pode ter um efeito inibidor sobre esse tipo de pesquisa de segurança de boa-fé e as empresas podem decidir adotar uma abordagem da qual a ignorância é uma felicidade – afinal, se um hacker ético revelar uma vulnerabilidade não corrigida, a empresa terá que reportar transmiti-lo à ENISA com todos os riscos potenciais associados. Para muitas empresas, pode simplesmente não valer a pena.
Como podem os reguladores da UE manter a nossa segurança de forma mais eficaz?
Tenho algumas sugestões:
1. Na ausência de um incidente de segurança significativo, as leis devem proporcionar às organizações tempo suficiente para mitigar uma vulnerabilidade descoberta antes de serem forçadas a divulgá-la 2.
As autoridades devem garantir que qualquer informação sobre vulnerabilidade assim divulgada seja devidamente protegida e compartilhada apenas em um base de necessidade de saber.
3. As agências governamentais deveriam ser proibidas de usar essas informações para outros fins (por exemplo, vigilância).
4. A lei deveria fazer um esforço maior para proteger os pesquisadores de segurança, fazendo uma distinção entre vulnerabilidades descobertas no decorrer de pesquisas de boa-fé e vulnerabilidades explorado por atores maliciosos
Os intervenientes maliciosos já têm muitas vantagens neste cenário atual de cibersegurança – não deveríamos dar-lhes outra vantagem. Não somos os únicos a sentir que as vulnerabilidades não corrigidas não devem ser sujeitas a comunicação imediata: uma declaração da DigitalEurope expressando esta opinião foi assinada por inúmeras partes interessadas importantes, tanto públicas como privadas, incluindo o Hacking Policy Council co-fundado pela HackerOne. Os grupos de defesa do consumidor também manifestaram preocupação com os requisitos de divulgação de vulnerabilidades da CRA e instaram os decisores políticos da UE a instalarem salvaguardas contra a utilização indevida.
Trabalhando em conjunto, os sectores público e privado devem esforçar-se por obter resultados políticos que permitam a descoberta e divulgação de vulnerabilidades sem colocar as empresas e os consumidores em riscos desnecessários. Para esse fim, a HackerOne, em parceria com o Hacking Policy Council e os nossos colegas signatários, continuará a cooperar com o Parlamento Europeu, a Comissão e o Conselho e a defender o tipo de comunicação de vulnerabilidades que mantém todos ao máximo seguros.
FONTE: HELP NET SECURITY