A Lei de Resiliência Cibernética da UE levanta preocupações sobre código aberto e segurança cibernética

A União Europeia está revisando sua proposta de Lei de Resiliência Cibernética (CRA), que visa fortalecer as defesas da Europa contra ataques cibernéticos e melhorar a segurança do produto.A lei tem como alvo uma ampla gama de produtos comercializados para consumidores europeus, incluindo dispositivos da Internet das Coisas (IoT), computadores de desktop e smartphones.Ele impõe requisitos de divulgação de vulnerabilidade aos fabricantes e distribuidores de dispositivos e apresenta novas disposições de responsabilidade de incidentes de segurança cibernética.

A Electronic Frontier Foundation (EFF), uma organização jurídica internacional líder sem fins lucrativos, recebeu com satisfação a intenção da legislação, mas também expressou preocupação de levantar preocupações sobre o código aberto e a segurança cibernética: a lei proposta penalizaria os desenvolvedores de código aberto que recebem qualquer receita adicional paratrabalho deles.Isso também exigiria que os fabricantes relatassem vulnerabilidades ativamente exploradas e não atingidas aos reguladores.Esse requisito tem o potencial de expor as circunstâncias e a exploração dessas vulnerabilidades a um público mais amplo, exacerbando ainda mais o dano que a legislação deve mitigar.

1. Ameaças para o software de código aberto

O software de código aberto é a espinha dorsal da Internet moderna.As contribuições de desenvolvedores de projetos de código aberto, como Linux e Apache, são usados gratuitamente e incorporados em produtos distribuídos a bilhões de pessoas em todo o mundo.Isso só pode ser alcançado por meio de fluxos de receita que recompensam os desenvolvedores por seu trabalho, incluindo doações individuais, subsídios e patrocínios da fundação.Esse ecossistema de desenvolvimento e financiamento é parte integrante da operação e segurança do mundo atual orientado a software.

O CRA impõe responsabilidade às atividades comerciais que trazem produtos vulneráveis ao mercado.Enquanto a seção 10 da lei proposta isenta os colaboradores de código aberto sem fins lucrativos da responsabilidade, isentando "atividades comerciais", a isenção define atividades comerciais de maneira ampla.Qualquer desenvolvedor de código aberto que solicite doações para seus softwares ou cobranças por serviços de suporte não é isento, portanto, eles seriam responsáveis por danos se seu produto inadvertidamente contiver uma vulnerabilidade e depois incorporá -lo ao produto, mesmo que não fizesse o produto.Freqüentemente, colaboradores e desenvolvedores de código aberto escrevem software e o disponibilizam a outras pessoas com boa vontade e gratidão.Se esses desenvolvedores receberem até uma recompensa por seu trabalho, isso os colocará em risco.Pequenas organizações que produzem código -fonte aberto para o bem público podem sujeitar toda a sua operação a desafios legais simplesmente porque não têm fundos para correr o risco.Isso forçaria desenvolvedores e organizações a abandonarem completamente esses projetos, prejudicando todo o ambiente de código aberto.

Em resposta, a Foundation Electronic Frontier pede o CRA para isentar mais indivíduos que fornecem software de código aberto a partir de responsabilidade, inclusive quando são pagos pelo seu trabalho.

2. Requisitos de divulgação de vulnerabilidades representam uma ameaça de segurança cibernética

O artigo 11 do texto proposto exige que os fabricantes divulguem voluntariamente as vulnerabilidades exploradas à Agência da União Europeia para Segurança Cibernética (ENISA) dentro de 24 horas.A ENISA seria então obrigada a encaminhar detalhes dessas vulnerabilidades para as equipes de resposta a incidentes de segurança dos Estados -Membros (CSIRTs) e órgãos de vigilância de mercado.Como uma medida de responsabilidade, esse requisito forneceria um incentivo para os fabricantes de produtos com registros de segurança de produtos ruins procurarem e mitigarem ativamente as vulnerabilidades.Independentemente da intenção, é provável que esse requisito tenha consequências não intencionais para os fabricantes que priorizam a segurança do produto.As vulnerabilidades que representam um sério risco de segurança para os consumidores são frequentemente tratadas como segredos de perto por essas empresas até que a correção seja aplicada adequadamente e implantada no dispositivo final.Essas vulnerabilidades podem levar semanas ou até meses para que as correções adequadas sejam aplicadas.

O curto prazo pode impedir que as empresas apliquem correções "profundas" que corrigem a causa raiz da vulnerabilidade, optando por correções "rasas" que apenas tratam dos sintomas.As correções profundas levam tempo, e o requisito de 24 horas iniciará um cronômetro na resposta e resultará em uma resposta a retalhos aleatórios.

O segundo impacto é que mais organizações e pessoas em breve tomarão conhecimento das vulnerabilidades, o que aumentará muito o risco de serem expostas a alguém que possa querer explorá -las maliciosamente.O conhecimento do governo de uma variedade de vulnerabilidades de software nos fabricantes pode criar metas tentadoras para hackers e espionagem.Os fabricantes preocupados com os resultados de segurança de seus clientes têm pouco controle ou insight sobre a segurança operacional da ENISA ou agências de estados membros que estão cientes dessas vulnerabilidades.Esse requisito de relatório aumenta o risco de que as vulnerabilidades sejam adicionadas ao arsenal ofensivo das agências de inteligência do governo.Os fabricantes não devem se preocupar com o fato de que o relatório de falhas em seu software levará a um desenvolvimento adicional de recursos de guerra cibernética às suas custas.

Outra questão é que os requisitos de relatório não incluem divulgação pública.Para que os consumidores tomem decisões informadas sobre os produtos que compram, as atualizações de segurança devem ser fornecidas juntamente com detalhes sobre vulnerabilidades de segurança.

Dados os riscos significativos associados a esse requisito, a Fundação Eletrônica Frontier exige que os legisladores europeus abstenham de imposição de prazos inflexíveis à fixação de vulnerabilidades para abordar questões de segurança e divulgar relatórios detalhados sobre vulnerabilidades ao ENISA somente após o fato de terem sido corrigidos.Além disso, é necessária uma divulgação detalhada dos procedimentos de correção de segurança.Os requisitos mais rígidos podem ser impostos a empresas medíocres na segurança do produto - mas essa deve ser a exceção, não a regra.