As recomendações visam melhorar a cibersegurança e a resiliência, ao mesmo tempo que abordam as principais preocupações sobre a atual proposta de legislação da UE em matéria de ciber-resiliência.
Por Michael Hill
Vários grupos da indústria tecnológica e de TI publicaram uma lista de recomendações para melhorar o Cyber Resilience Act (CRA) da União Europeia (UE), que está atualmente a ser redigido por colegisladores. As associações instaram os decisores políticos a não darem prioridade à rapidez em detrimento da qualidade ao finalizarem as suas posições para evitarem resultados indesejados, citando áreas problemáticas que têm de ser abordadas na atual proposta.
A ARC da UE tem por objetivo estabelecer novos requisitos de cibersegurança para produtos com elementos digitais, reforçando as normas de cibersegurança para hardware e software, a fim de proteger os consumidores e as empresas de características de segurança inadequadas. Foi apresentado pela primeira vez por Ursula von der Leyen, presidente da Comissão Europeia (CE), em setembro de 2021, com uma proposta inicial publicada em setembro de 2022.
As recomendações visam melhorar a cibersegurança e a resiliência, ao mesmo tempo que abordam as principais preocupações partilhadas por empresas de todas as dimensões e de vários setores, como os criadores de software, os fabricantes de dispositivos e os fabricantes de componentes, de acordo com um documento da associação comercial mundial de tecnologia Information Technology Industry (ITI) Council. O ITI publicou as recomendações em conjunto com a Developers Alliance, a Software Alliance e a Computer & Communications Industry Associations (CCIA).
O âmbito do CRA deve ser mais restrito e mais claro
A primeira recomendação feita pelo grupo é que o âmbito proposto para a CRA deve ser mais restrito e mais claro. Qualquer referência a “soluções de tratamento de dados à distância” deve ser excluída do âmbito de aplicação da CRA para garantir a clareza jurídica e evitar sobreposições com a legislação existente e encargos desnecessários”, escreveram.
O software como serviço, a plataforma como serviço ou a infraestrutura como serviço não devem ser considerados no âmbito da ARC, e esta clarificação deve ser refletida no texto jurídico de base para proporcionar maior segurança jurídica e facilitar a sua aplicação em toda a zona euro, lê-se na recomendação.
Apelou também a uma maior clareza em relação ao software de fonte aberta (OSS), sugerindo a inclusão de uma exceção clara para o OSS no texto jurídico de base. “As características únicas do OSS devem ser tidas em conta em toda a proposta, nomeadamente quando se criam obrigações para os fabricantes relativamente aos componentes OSS que são integrados nos produtos.
Comunicação obrigatória de vulnerabilidades não corrigidas deve ser abolida
A terceira recomendação é que, no âmbito do ERC da UE, apenas as vulnerabilidades corrigidas que tenham sido ativamente exploradas e representem um risco significativo para a cibersegurança devem ter de ser notificadas. “A notificação obrigatória de vulnerabilidades não corrigidas
[atualmente proposta na CRA]
representa uma séria preocupação recentemente salientada por uma vasta coligação da indústria. Em geral, é crucial que as obrigações de notificação, incluindo o prazo de notificação e a autoridade competente, tanto no artigo 11.º, n.º 1 como no n.º 2, estejam em conformidade com a Diretiva SRI 2″, lê-se. Além disso, apenas os incidentes “significativos” devem estar sujeitos às obrigações de notificação previstas no artigo 11.º, a fim de evitar que os fabricantes e as autoridades responsáveis tenham de suportar uma carga de notificação impossível de gerir, acrescentou a compilação.
É necessário trabalhar para evitar obrigações desproporcionadas que aumentem riscos de cibersegurança
É necessário continuar a trabalhar para evitar obrigações desproporcionadas ou impossíveis e obrigações que aumentem os riscos de cibersegurança, lê-se na recomendação final. O anexo I do regulamento relativo aos requisitos essenciais deve estabelecer obrigações proporcionadas, uma vez que a obrigação absoluta de “fornecer um produto sem vulnerabilidades exploráveis conhecidas” é impossível de estabelecer. Isto porque a segurança dos produtos pode ser influenciada por numerosos fatores, incluindo o ambiente de implantação do produto, argumentaram os grupos. A proposta também ignora a possibilidade de os fabricantes atuarem antes e depois de colocarem um produto no mercado, acrescentaram. “A proposta deve ser limitada a qualquer vulnerabilidade crítica ou muito crítica conhecida publicamente.
Além disso, um período obrigatório de atualização de segurança baseado no “tempo de vida esperado do produto” é um conceito desproporcionado e juridicamente incerto, sendo necessária maior clareza. “Relacionar o “tempo de vida esperado do produto” apenas com as “expectativas razoáveis do utilizador” criará uma grande incerteza jurídica em todo o mercado único da UE, uma vez que os períodos de vida reais serão, em última análise, determinados pelas autoridades nacionais de fiscalização do mercado e pelos tribunais, e não pelos fabricantes”.
Além disso, a diferenciação obrigatória entre atualizações de segurança e de funcionalidade não é viável do ponto de vista prático e da flexibilidade necessária, nem para a conveniência dos utilizadores, segundo a recomendação. “Também gostaríamos de ver qualquer alteração à ARC que reconheça a diferença entre duas categorias de produtos: os de consumo e os de não consumo. É fundamental reconhecer que, no contexto B2B, os compradores são organizações que têm um nível suficiente de consciência e recursos de cibersegurança para tomar decisões de compra informadas.” No caso dos SBOM, o CRA deve oferecer flexibilidade e ter em conta as melhores práticas e as normas internacionais.
“Devem ser evitadas disposições que aumentem os riscos em vez de reforçarem a cibersegurança, como a divulgação de informações sobre a conceção e o desenvolvimento de produtos (Anexo V, ponto 2, alínea a), bem como a divulgação de pormenores sobre vulnerabilidades como parte de um SBOM (Anexo I, secção 2, ponto 1).” Do mesmo modo, a extensão do princípio da minimização dos dados da GRPD aos dados não pessoais no Anexo I, Secção 1, ponto 3, alínea e) “resultará em experiências de utilização mais pobres e estagnadas, sem qualquer benefício em termos de segurança, uma vez que os fabricantes ficarão limitados na recolha de dados anonimizados que são utilizados para o controlo da qualidade ou para a monitorização de potenciais ameaças à segurança”.