La Ley de Resiliencia Cibernética de la UE plantea preocupaciones sobre el código abierto y la ciberseguridad
La Unión Europea está revisando su propuesta Ley de Resiliencia Cibernética (CRA), cuyo objetivo es fortalecer las defensas de Europa contra los ataques cibernéticos y mejorar la seguridad del producto.La ley se dirige a una amplia gama de productos comercializados para los consumidores europeos, incluidos dispositivos de Internet de las cosas (IoT), computadoras de escritorio y teléfonos inteligentes.Impone requisitos de divulgación de vulnerabilidad a los fabricantes y distribuidores de dispositivos, e introduce nuevas disposiciones de responsabilidad por incidentes de ciberseguridad.
La Electronic Frontier Foundation (EFF), una organización legal internacional sin fines de lucro líder, dio la bienvenida a la intención de la legislación, pero también expresó su preocupación de que plantee preocupaciones sobre el código abierto y la seguridad cibernética: la ley propuesta penalizaría a los desarrolladores de código abierto que reciben ingresos adicionales para los ingresos adicionales parasu trabajo.También requeriría que los fabricantes informen vulnerabilidades explotadas activamente y no parpadeadas a los reguladores.Este requisito tiene el potencial de exponer las circunstancias y la explotación de estas vulnerabilidades a un público más amplio, exacerbando aún más el daño que la legislación está destinada a mitigar.
1. Amenazas a software de código abierto
El software de código abierto es la columna vertebral de la Internet moderna.Las contribuciones de los desarrolladores de proyectos de código abierto como Linux y Apache se usan libremente e incorporan en productos distribuidos a miles de millones de personas en todo el mundo.Esto solo se puede lograr a través de flujos de ingresos que recompensen a los desarrolladores por su trabajo, incluidas las donaciones individuales, las subvenciones y los patrocinios de cimientos.Este ecosistema de desarrollo y financiación es parte integral de la operación y la seguridad del mundo de software actual.
La CRA impone responsabilidad en las actividades comerciales que traen productos vulnerables al mercado.Mientras que la sección 10 de la ley propuesta exime a los contribuyentes de código abierto sin fines de lucro de la responsabilidad al eximir "actividades comerciales", la exención define las actividades comerciales de manera demasiado amplia.Cualquier desarrollador de código abierto que solicite donaciones para su software o cargos por servicios de soporte no está exento, por lo que serían responsables de los daños..A menudo, los contribuyentes y desarrolladores de código abierto escriben software y lo ponen a disposición de otros a partir de la buena voluntad y la gratitud.Si estos desarrolladores reciben incluso una recompensa para su trabajo, los pondrá en riesgo.Las pequeñas organizaciones que producen código de código abierto para el bien público pueden someter toda su operación a desafíos legales simplemente porque carecen de los fondos para correr el riesgo.Esto obligaría a los desarrolladores y organizaciones a abandonar estos proyectos por completo, dañando todo el entorno de código abierto.
En respuesta, la Fundación Electronic Frontier pide a la CRA para eximir aún más a las personas que proporcionan software de código abierto de responsabilidad, incluso cuando se les paga por su trabajo.
2. Los requisitos de divulgación de vulnerabilidad representan una amenaza de ciberseguridad
El artículo 11 del texto propuesto requiere que los fabricantes revelen voluntariamente vulnerabilidades explotadas a la Agencia de la Seguridad Cibernética (ENISA) de la Unión Europea dentro de las 24 horas.ENISA se requeriría que envíe detalles de estas vulnerabilidades a los equipos de respuesta a incidentes de seguridad informática de los Estados miembros (CSIRTS) y los organismos de vigilancia del mercado.Como medida de responsabilidad, este requisito proporcionaría un incentivo para los fabricantes de productos con registros de seguridad de productos deficientes para buscar y mitigar activamente las vulnerabilidades.Independientemente de la intención, es probable que este requisito tenga consecuencias no deseadas para los fabricantes que priorizan la seguridad del producto.Las vulnerabilidades que representan un riesgo de seguridad grave para los consumidores a menudo son tratadas como secretos estrechamente guardados por estas compañías hasta que la solución se aplique y se despliega adecuadamente en el dispositivo final.Estas vulnerabilidades pueden llevar semanas o incluso meses para que se apliquen las soluciones adecuadas.
El período de tiempo corto puede evitar que las empresas apliquen soluciones "profundas" que corrijan la causa raíz de la vulnerabilidad, optando por las soluciones "superficiales" que solo abordan los síntomas.Las correcciones profundas toman tiempo, y el requisito de 24 horas comenzará un temporizador en la respuesta y dará como resultado una respuesta de retazos a la altura.
El segundo impacto es que más organizaciones y personas pronto se darán cuenta de las vulnerabilidades, lo que aumentará enormemente el riesgo de que estarán expuestos a alguien que quiera explotarlas maliciosamente.El conocimiento del gobierno de una variedad de vulnerabilidades de software en los fabricantes podría crear objetivos tentadores para piratería y espionaje.Los fabricantes preocupados por los resultados de seguridad para sus clientes tienen poco control o visión de la seguridad operativa de las agencias de ENISA o estados miembros que son conscientes de estas vulnerabilidades.Este requisito de informes aumenta el riesgo de que las vulnerabilidades se agregarán al arsenal ofensivo de las agencias de inteligencia del gobierno.Los fabricantes no deben preocuparse de que informar fallas en su software conduzca a un mayor desarrollo de las capacidades de guerra cibernética a su costa.
Otro problema es que los requisitos de informes no incluyen la divulgación pública.Para que los consumidores tomen decisiones informadas sobre los productos que compran, se deben proporcionar actualizaciones de seguridad junto con detalles sobre vulnerabilidades de seguridad.
Dados los riesgos significativos asociados con este requisito, la Fundación Electronic Frontier pide a los legisladores europeos que se abstengan de imponer plazos inflexibles para solucionar vulnerabilidades para abordar los problemas de seguridad y publicar informes detallados sobre las vulnerabilidades a ENISA solo después de haber sido solucionadas.Además, se necesita una divulgación detallada de los procedimientos de solución de seguridad.Se pueden imponer requisitos más estrictos a las empresas que son mediocres en la seguridad del producto, pero esta debería ser la excepción, no la regla.