Los grupos industriales piden cambios en la Ley de Ciberresiliencia de la Unión Europea

Varios grupos de la industria tecnológica y de TI han publicado una lista de recomendaciones para mejorar la Ley de Ciberresiliencia (CRA) de la Unión Europea (UE), que actualmente están elaborando los colegisladores. Las asociaciones han instado a las autoridades a no dar prioridad a la velocidad sobre la calidad a la hora de ultimar sus posiciones para evitar resultados imprevistos, citando aspectos problemáticos que deben abordarse en la propuesta actual.

El CRA de la UE pretende establecer nuevos requisitos de ciberseguridad para los productos con elementos digitales, reforzando las normas de ciberseguridad para hardware y software con el fin de proteger a los consumidores y las empresas de características de seguridad inadecuadas. Fue presentada por primera vez por Úrsula von der Leyen, presidenta de la Comisión Europea (CE), en septiembre de 2021, con una propuesta inicial publicada en septiembre de 2022.

Las recomendaciones pretenden mejorar la ciberseguridad y la resistencia, al tiempo que abordan las principales preocupaciones compartidas por empresas de todos los tamaños y de diversos sectores, como desarrolladores de software, fabricantes de dispositivos y fabricantes de componentes, según un documento de la asociación mundial de comercio tecnológico Information Technology Industry (ITI) Council. El ITI publicó las recomendaciones junto con la Developers Alliance, The Software Alliance y la Computer & Communications Industry Associations (CCIA).

El ámbito de aplicación de la CRA debe ser más restringido y claro

La primera recomendación formulada por el colectivo es que el ámbito de aplicación propuesto de la CRA sea más restringido y claro. Cualquier referencia a "soluciones de tratamiento de datos a distancia" debería excluirse del ámbito de aplicación de la CRA para garantizar la claridad jurídica y evitar solapamientos con la legislación vigente y cargas innecesarias", escribieron.

El software como servicio, la plataforma como servicio o la infraestructura como servicio no deben considerarse dentro del ámbito de aplicación de la CRA, y esta aclaración debe reflejarse en el texto jurídico básico para proporcionar una mayor seguridad jurídica y facilitar su aplicación en toda la Eurozona, rezaba la recomendación.

También pedía mayor claridad en relación con el software de código abierto (OSS), sugiriendo que se incluyera en el texto jurídico básico una excepción clara del OSS. "Las características únicas del OSS deben tenerse en cuenta en toda la propuesta, también a la hora de crear obligaciones para los fabricantes por los componentes de OSS que se integran en los productos".

Debe suprimirse la notificación obligatoria de vulnerabilidades no parcheadas

La tercera recomendación es que, con arreglo a la ERC de la UE, sólo sea necesario notificar las vulnerabilidades parcheadas que hayan sido explotadas activamente y planteen un riesgo significativo para la ciberseguridad. "La notificación obligatoria de vulnerabilidades no parcheadas [propuesta actualmente en la CRA] representa una grave preocupación señalada recientemente por una amplia coalición de la industria. En general, es crucial que las obligaciones de notificación, incluidos el plazo de notificación y la autoridad competente, tanto en el artículo 11, apartados 1 y 2, estén en consonancia con la Directiva NIS 2", se lee. Además, sólo los incidentes "significativos" deberían estar sujetos a las obligaciones de notificación del artículo 11 para evitar una carga de notificación inmanejable para los fabricantes y las autoridades responsables, añadía la recopilación.

Es necesario trabajar para evitar obligaciones desproporcionadas que aumenten los riesgos de ciberseguridad

Es necesario seguir trabajando para evitar obligaciones desproporcionadas o imposibles, y obligaciones que aumenten los riesgos de ciberseguridad, rezaba la recomendación final. El Anexo I de la CRA sobre requisitos esenciales debería establecer obligaciones proporcionadas, ya que la obligación absoluta de "entregar un producto sin vulnerabilidades explotables conocidas" es un listón imposible de fijar. Esto se debe a que la seguridad del producto puede verse influida por numerosos factores, entre ellos el entorno de despliegue del producto, alegaron los grupos. También ignora el margen de actuación de los fabricantes antes y después de comercializar un producto, añadieron. "Esto debería limitarse a cualquier vulnerabilidad crítica o muy crítica conocida públicamente".

Asimismo, un periodo obligatorio de actualización de la seguridad basado en la "vida útil prevista del producto" es un concepto desproporcionado y jurídicamente incierto, por lo que se necesita más claridad. "Vincular la "vida útil esperada del producto" únicamente a las "expectativas razonables del usuario" creará una gran inseguridad jurídica en todo el mercado único de la UE, ya que los periodos de duración reales serán determinados en última instancia por las autoridades nacionales de vigilancia del mercado y los tribunales, no por los fabricantes”.

Además, la diferenciación obligatoria entre actualizaciones de seguridad y de funcionalidad no es viable desde el punto de vista práctico y de la flexibilidad necesaria, ni para la comodidad de los usuarios, según la recomendación. "También acogeríamos con satisfacción cualquier cambio en la CRA que reconozca la diferencia entre dos categorías de productos: los de consumo y los que no lo son. Es clave reconocer que en el contexto B2B, los compradores son organizaciones que tienen un nivel suficiente de concienciación sobre ciberseguridad y recursos para tomar decisiones de compra informadas." En el caso de los SBOM, la CRA debería ofrecer flexibilidad y tener en cuenta las mejores prácticas y las normas internacionales.

"Deben evitarse las disposiciones que aumentarían los riesgos en lugar de mejorar la ciberseguridad, como la divulgación de información sobre el diseño y el desarrollo del producto (anexo V, punto 2, letra a), así como la divulgación de detalles sobre vulnerabilidades como parte de un SBOM (anexo I, sección 2, punto 1)". Del mismo modo, la ampliación del principio del GRPD de minimización de datos a los datos no personales en el anexo I, sección 1, punto 3, letra e, “dará lugar a experiencias más pobres y estancadas para los usuarios sin ningún beneficio para la seguridad, ya que los fabricantes se verán limitados en la recopilación de datos anónimos que se utilizan para el control de calidad o el seguimiento de posibles amenazas a la seguridad”.