Sobre el Cyber Resilience Act

Cada cierto tiempo aparecen leyes que afectan a Internet. Y lo tengo muy presente porque en su día dediqué demasiado tiempo a luchar contra algunos aspectos de la LSSI. Ahora llega el Cyber Resilience Act, o sea, la Ley de Ciberresiliencia.

Antes de nada, he de decir que todo lo que voy a decir creo que es bueno desde el punto de vista tecnológico, aunque hay algunos detalles sobre responsabilidades en los que hay ciertas dudas, sobre todo en lo que respecta al software de código abierto, y más cuando está hecho por múltiples personas.

IMPORTANTE: En este momento es una propuesta, que variará poco, excepto, probablemente, en los elementos más delicados.

Contexto de la CRA

El Cyber Resilience Act es una propuesta de Directiva Europea que se lanzó a la luz el 15 de septiembre de 2022, y que tiene un par de objetivos a los que creo, todos los usuarios, estaremos de acuerdo:

La creación de productos más seguros, desde el punto de vista de software.
Que los usuarios estén más seguros, utilizando productos más seguros.
Que haya un marco legal normalizado sobre medidas de seguridad.
Que haya transparencia en la seguridad de los productos y su desarrollo.

Hoy en día casi todo lleva un chip con algo de software más o menos elaborado, desde un firmware ahí puesto a piñón, hasta un sistema operativo como el que puede llevar tu teléfono móvil. Y eso, como cualquier software, no es fiable al 100 %, sobre todo con el paso del tiempo.

Hay que decir que la CRA tendrá excepciones, porque ya hay otra legislación que aplica a determinados dispositivos con software: los coches, los aviones y los dispositivos médicos. Creo que se puede entender por qué ya hay leyes sobre ello.

Creo que hay una frase que resume muy claramente el porqué:

Estas medidas deben, entre otras cosas, garantizar la seguridad en la adquisición, el desarrollo y el mantenimiento de las redes y sistemas de información, incluidas la gestión y la divulgación de las vulnerabilidades.
Cyber Resilience Act

Seguridad, ¿really?

Es muy interesante esta ley en algunos aspectos por una sencilla razón: los humanos no somos fiables. Y pongo un par de ejemplos muy sencillos:

Reutilización de contraseñas: ¿cuántas veces has puesto la misma contraseña, «que es la tuya», en muchos sitios distintos de Internet?
Actualización de software: ¿cuánto tiempo llevas sin darle a esa actualización pendiente de tu Windows o Mac?

Teniendo esto en cuenta, uno de los aspectos de la ley es la información sobre ciberseguridad, algo que los que nos dedicamos a esto somos muy conscientes, pero al resto de la gente, se la sopla un poco.

Todos queremos que no nos hackeen y salgan por ahí fotos comprometidas, conversaciones en las que rajas de tu pareja o vete a saber lo que tienes. Pero aunque nos dan la oportunidad, no la aplicamos por «vete a saber qué».

Soy tu nueva lavadora y puedes llamarme «Aqualis»

Estamos rodeados de cosas a las que poderle hablar… que si Siri, que si Alexa, que si Google… ¿Por qué no hablar con mi lavadora «Aqualis»?

INCISO: El nombre Aqualis es la respuesta de ChatGPT a esto: Invéntate un nombre para una lavadora, como si fuera una Siri, o Alexa.

Su Respuesta: ¡Claro! Un nombre adecuado para una lavadora inteligente podría ser “Aqualis”. Este nombre combina las palabras “aqua” (agua en latín) y “alis” (que puede derivarse de la palabra en inglés “ease”, que significa facilidad). Así, el nombre “Aqualis” sugiere una lavadora que maneja eficientemente el uso del agua y facilita el proceso de lavado para los usuarios. También tiene un sonido moderno y tecnológico, lo que lo hace apropiado para un dispositivo inteligente y avanzado como una lavadora con funciones de voz e inteligencia artificial.

Volviendo a mi nueva lavadora… Aqualis va a estar conectada a la wifi de mi casa, porque quiero poder hablar con ella por mi teléfono, o simplemente a través de Alexa y decirle: «ponte en marcha para que a las 17:00, cuando llegue a casa, pueda tenderte». Y ella hará cosas.

Que una lavadora lleve software incorporado puede estar muy bien. Es probable que depende del peso y cantidad de ropa, consuma menos agua y detergente, por lo que será más ecológica. Pero como cualquier tecnología, es probable que en un año haya quedado obsoleto o que deje de ser compatible con tu Alexa, porque alguna API¹ haya variado.

¿Cómo se actualiza el software de la lavadora? ¿Qué pasa si mi abuela no sabe usar su móvil para configurar su lavadora?

Los implicados

La ley diferencia bastante claramente en los unos y los otros. Básicamente, hay tres niveles de personas implicadas en este proceso, los fabricantes, los distribuidores y los creadores de código (por ejemplo, de bibliotecas externas o de código abierto).

Los fabricantes

En el caso de los fabricantes está bastante claro quiénes son y lo que, en principio, hacen. Su labor fundamental es «crear» un producto. Sí, estás pensando en tu marca de referencia, que es quien ha producido nuestra lavadora Aqualis, pero no, no sólo debes centrarte en un producto físico, también los hay productos virtuales, digitales, como un sistema operativo (llámese Windows, iOS, Mac o Android), o WordPress.

Como fabricante se van a tener ciertas responsabilidades:

Hacer una evaluación de los riesgos de ciberseguridad.
Crear documentación técnica (adjunta al producto) con respecto a ciberseguridad.
Hacer diligencia de los componentes de terceros, incluidos en el producto.

Esto, en resumen, significa que tú, como fabricante, eres responsable de la seguridad del software que incluyan los productos, o el propio software en sí, si es el producto, además de informar de ello y explicar qué medidas se han tomado en su creación.

También vas a ser responsable de indicar qué elementos de terceros se incluyen y de mantenerlos al día en tu software cuando haya actualizaciones. Asimismo, deberás de informar de posibles problemas de seguridad sobre ellos.

Un detalle importante que queda medio excluido son las versiones en desarrollo, es decir, las versiones alpha, beta o release-candidate, que deberán tener como un plazo establecido de tiempo de uso, es decir, que cuando haya una versión beta de algo se ha de indicar sí, o sí, que eso va a acabar en una versión final. En ningún caso, una versión no final podrá ir incluida en un producto final a disposición del público general.

Otra cosa importante es que cualquier software deberá llevar incluido un listado o lugar donde consultar las vulnerabilidades detectadas. Y esto se tendrá que hacer durante la vida útil del producto o durante cinco años desde su lanzamiento. Es decir, se crea una «garantía de, al menos, cinco años de mantenimiento de ciberseguridad de ese producto».

¿Qué pasa si se encuentra una vulnerabilidad? Pues que los fabricantes tienen 24 horas para informar a una entidad ENISA, que en España, si no me equivoco, debe ser el INCIBE. Además, también se debe informar a los usuarios de dicha vulnerabilidad. Si esa vulnerabilidad se detecta en algún bloque, biblioteca o cualquier elemento que sea código abierto, se deberá notificar también a los desarrolladores de esa pieza de código.

Los distribuidores

Cuando hablamos de una lavadora, el distribuidor es muy claro. No tiene por qué ser la empresa que lo vende, que también, sino, por ejemplo, alguien que crea una lavadora en «marca blanca» porque lo fabrica A, pero se vende con la marca B.

Por poner otro ejemplo, los procesadores o algunos componentes de los teléfonos móviles son de marcas conocidas que no tienen por qué corresponder con el que te vende el teléfono.

Pues, los distribuidores serán los responsables que, en territorio europeo, se cumpla el Reglamento. Esto significa que da igual dónde se haya fabricado o desarrollado algo, que si el software se va a ejecutar en territorio europeo o por un europeo, la ley le aplica, y es el responsable de que toda esa documentación que se tenía que dar, esté.

Incluso, si el distribuidor considera que ese producto no es conforme a la legislación, no lo comercializará.

Incluso, si el distribuidor es conocedor de que el fabricante, o alguno de los elementos ha cerrado, se deberá informar a los usuarios.

Los creadores de código

En este apartado voy a hacer referencia explícita a los desarrolladores de código abierto. Aunque es verdad que por desarrollarlo parece que no serán responsables de su código, siempre y cuando sea libre y esté disponible para su análisis. sí que hay ciertas dudas de su responsabilidad si cobras por ello, por ejemplo, si una empresa te paga por mantener algún producto de código abierto. Esta parte es por la que muchas entidades están luchando, con razón, para que se clarifique la implicación de estas personas en el conjunto de un software.

En cualquier caso, una cosa no quita la otra, y dejando de lado las «multas», lo que sí que queda claro es que la seguridad debe ser un componente muy claro en lo que a documentación, versiones y demás.

Si desarrollas código, eres responsable de que sea seguro, de eso no cabe duda que la ley es clara. Como digo, otra cosa es la responsabilidad que haya sobre el software.

Un ejemplo que se me viene a la cabeza es el de PHPMailer, la biblioteca PHP que usan muchísimos otros programas para enviar correo (como por ejemplo, WordPress).

La documentación

Si una cosa me ha quedado clara al leer toda la documentación es que se va a tener que crear más documentación. Y esto será independiente de las responsabilidades, multas o a quién echar la culpa: el software va a tener documentación específica de seguridad.

Todo producto (ya sea hardware, software o lo que sea que lleve una pieza de código) va a requerir una documentación en el que se incluyan:

Todos los medios y herramientas que se han usado para probar el software del producto.
La documentación se tendrá que publicar antes (o en el momento) del lanzamiento del producto. Nunca después.
La documentación tiene que estar activa mientras ese producto exista, con un mínimo de cinco años.
La documentación debe estar en una lengua oficial del Estado o en una «lengua aceptable».

Ciberseguridad, por defecto

Esta legislación marca una base muy básica: todo producto debe pensarse con la seguridad por defecto.

Y esto tiene algunas implicaciones implícitas:

El software se entregará sin ninguna vulnerabilidad (conocida).
La configuración por defecto (y de reset) debe ser segura y restrictiva.
Debe incluir por defecto sistemas que impidan el acceso no autorizado.
Debe proteger la confidencialidad de los datos personales (y, en general, de todos los datos).
Trataran los datos únicamente necesarios.
Las vulnerabilidades se subsanarán mediante actualizaciones automáticas y notificando al usuario.

Esto, digamos, es lo que se debe hacer «dentro del producto», pero no es lo único. Las vulnerabilidades y los análisis también deberán ser públicos.

Se identificarán las vulnerabilidades mediante un formato comúnmente utilizado y legible por máquina.
Se llevarán a cabo exámenes eficaces y periódicos.
Una vez haya una actualización de seguridad, se divulgarán las vulnerabilidades subsanadas con una descripción.
Se aplicará una política de divulgación coordinada de vulnerabilidades, además de intercambio de información.
Se preverán sistemas de distribución segura de las actualizaciones, sin demora y de forma gratuita.

Código abierto

Para no obstaculizar la innovación o la investigación, el presente Reglamento no debe aplicarse a los programas informáticos libres y de código abierto desarrollados o suministrados al margen de una actividad comercial. Este es el caso, en particular, de los programas informáticos, incluidos su código fuente y sus versiones modificadas, que se comparten abiertamente y son accesibles, utilizables, modificables y redistribuibles libremente.

En el contexto de los programas informáticos, una actividad comercial puede caracterizarse no solo por la aplicación de un precio a un producto, sino también por la aplicación de un precio a los servicios de asistencia técnica, por el suministro de una plataforma de software a través de la cual el fabricante monetiza otros servicios o por el uso de datos personales por razones distintas de las relacionadas exclusivamente con la mejora de la seguridad, la compatibilidad o la interoperabilidad del programa informático.
Cyber Resilience Act

Cómo afecta a WordPress

A partir de aquí voy a exponer mi opinión personal en lo que yo entiendo que va a ser necesario aplicar en la Comunidad WordPress, a varios niveles.

Core de WordPress

Lo primero es que, todo esto que se expone aquí no debería afectar a los desarrolladores del Core de WordPress, ya sean voluntarios o tengan algún tipo de financiación. El Core es código abierto creado por un grupo de personas y, parece, que no debería afectar, a nivel responsabilidad.

Otra cosa es la parte de documentación, que estoy convencido de que va a aplicar sí o sí a todo software. En principio esto no debería afectar mucho, ya que actualmente ya se van publicando todas las informaciones sobre seguridad de las versiones del núcleo, aunque sí creo que se va a tener que optimizar, y que se tendrán que sacar versiones exclusivas de seguridad de versiones mayores y menores en concreto, a modo de hotfix², sin incluir cambios en la funcionalidad.

Esto significa que si tú tienes la versión 6.2.1 y hay un parche, se aplicaría la versión 6.2.1.1, que corrige eso en concreto. Hay que tener en cuenta que las actualizaciones de seguridad son obligatorias y forzadas, por lo que no se va a poder estar sobrescribiendo cosas de los usuarios a lo loco.

Versiones alpha, beta y RC

Como ya decía antes, en principio, esto no debería afectar a las versiones beta y RC de WordPress, que siempre han tenido una fecha clara de inicio y final, con la fecha del lanzamiento general, además de que, durante la fase beta y RC está abierto el sistema en HackerOne para reportar vulnerabilidades del nuevo código.

Así que, en este caso, creo que se está haciendo todo correctamente, ya como para no preocuparse mucho.

Extensiones de WordPress (plugins y temas)

Otra cosa van a ser los plugins y temas. Aunque sean gratuitos, la parte de documentación también se va a tener que hacer sí, o sí, aunque todavía no tengo claro el asunto de la responsabilidad. Por supuesto que los plugins comerciales tienen responsabilidad, pero en general los plugins hechos por varias personas no pueden considerarse que son de una gran comunidad.

Lo que sí que tengo claro es que vamos a tener que añadir algunos elementos en la documentación de los plugins. Por poner un ejemplo, en uno de los míos, WPVulnerability, yo ya he incluido algunas ideas de lo que podría suponer.

Esto es un ejemplo de la primera documentación, lanzada para la versión 2.2.1:

Básicamente, he incluido una sección de Seguridad, en la que hay enlaces a herramientas y documentación sobre la que me he basado además de un contacto, sobre la privacidad de los datos que se usan y guardan, del profiling (el impacto que tiene el plugin sobre WordPress), una sección de vulnerabilidades, que actualmente no hay, y espero que no haya nunca, y finalmente una lista de compatibilidades de software para que se valide su correcto funcionamiento.

¿Debe estar esto por defecto en WordPress? Probablemente sí. Creo que el readme.txt de los WordPress debería incluir estas secciones por defecto, sobre todo la primera que debe ser obligatoria, y finalmente un sistema de contacto con los desarrolladores (algo que ya se está discutiendo #6939 y #7259).

Hay que tener en cuenta que esto será considerado «producto no-crítico», pero que hay excepciones como los plugins de firewalls o seguridad, en general, que se considerarán de una clase superior.

Equipo Meta

En cualquier caso, ambas cosas van a afectar a Meta, el equipo responsable de mantener WordPress.org.

Por un lado, como decía con Core, se va a tener que facilitar la actualización masiva de todos los WordPress de forma unilateral (aunque el usuario no quiera) de sus sitios con los parches de seguridad.

Pero esto no sólo va a afectar al núcleo, si no, también a plugins y temas que estén en el repositorio, y los plugins y temas premium que, aunque no tengan licencia, los desarrolladores van a tener la obligación de actualizar las vulnerabilidades en remoto.

En lo que respecta a WordPress.org, sé que ya existen soluciones para ello, que se aplican puntualmente si un desarrollador lo pide y afecta a un mínimo de instalaciones. Toda esa parte ahora se va a tener que automatizar.

Lo más probable es que, como ya he hablado alguna vez en algún corrillo, al subir una nueva versión ser´de obligado cumplimiento el segundo paso que se puede activar al subir elementos (en el que hay que confirmar la publicación de un plugin, por ejemplo) con algún tipo de indicación de que esa versión es una versión de seguridad, y de esa forma se tendrá que aplicar a todas las instalaciones.

Intuyo que esto va a dar más trabajo al equipo de plugins y temas, porque habrá que validar que efectivamente esa actualización sólo incluye el parche, y no se incluye nada más, e incluso habrá que ver qué responsabilidad hay si alguien mete algo que no toca cuando no toca, ya que ahora tendremos multas a aplicar a quien haga las cosas mal.

Soy de sistemas o de hosting

De todos a los que les puede afectar esta ley, a los de sistemas y hosting es donde tengo más dudas. Es probable que haya que ver cómo se compatibiliza este Reglamento con la LSSI³.

Por un lado, habrá que ver cómo se obliga a los sistemas operativos a aplicar los parches de seguridad en remoto, algo que en algunos casos es un servicio prémium de los desarrolladores de los sistemas. En general muchos de ellos ya tienen esta posibilidad, que por ejemplo yo aplico por defecto en todos los clientes.

En general, los sistemas operativos ya funcionan con u sistema de parches de tipo «hotfix», que sólo corrigen eso que está mal, sin cambiar a una versión mayor, por lo que en teoría, esto ahora simplemente deberá venir por defecto, sí o sí.

La duda que me queda es qué responsabilidad habrá tanto en hostings que ofrecen mantenimiento activo como los que no sobre el software que se incluye (no el del sistema), como puede ser el de WordPress. ¿Debe ser el hosting el que aplique los parches si el usuario no lo hace, aunque se rompa?

Esto es lo que me lleva a dudar con respecto al conocimiento de los proveedores de servicios con la LSSI, y con el elemento clave que es que «se cobra por el mantenimiento». En este caso, habrá que esperar a ver cómo se compatibiliza todo.

Soy una agencia o mantengo WordPress

Aquí es donde la gente va a pringar más. Todo aquella agencia que monte un WordPress o que lo mantenga, es responsable sí o sí de los sitios. Mantener los WordPress ya no será una opción, será una obligación siempre y cuando seas la empresa «que me hace la web».

Si le revendes hosting al cliente, si le haces una web, si se la mantienes vas a ser responsable, aunque le cobres 1 céntimo al año a ese cliente y por mucho que «WordPress es gratis». En este punto, el Reglamento es claro. Una cosa es quién hace WordPress y otro es quién «se aprovecha» de WordPress, como código abierto.

Entre algunos elementos importantes será que al entregar el proyecto se le deberá informar al cliente de todos los riesgos de seguridad, todos los plugins deberán estar actualizados a la última versión (gratuitos, de pago, premium..) y nunca se podrá incluir un plugin obsoleto. Incluso, si se detecta que alguien tiene un plugin obsoleto, se deberá informar y eliminar.

Personalmente, este momento me gusta, porque va a erradicar del mundo a la gente que hace webs «porque es mi cuñado», y va a obligar a profesionalizar al sector.

Soy desarrollador

Como desarrollador, si has llegado aquí, ya más o menos tendrás claro qué es lo que va a tocar.

Por un lado, todo el software que se haga deberá basarse en los estándares WordPress. Nada podrá publicarse si no cumple el WPCS (por reducirlo a una cosa). Al final es que tendrás que demostrar de alguna manera, o al menos informar, de que has cumplido algunas documentaciones y que has pasado algunas herramientas mínimas de seguridad.

Creo que el trabajo que está haciendo el Equipo de Review de Plugins va a ser muy importante con su Plugin Check.

Por otro lado, como decía antes, vamos a tener que ver mejoras en el sistema de publicación de código (plugins y temas), su gestión, su información…

Soy implementador

Aquí es donde seguramente acaben muchos de los programadores que no quieran responsabilidad. Le pedirán al cliente que les instalen un Elementor o un Visual Composer (lo tendrá que hacer otro) y ellos se limitarán a «maquetar», pero no podrán instalar ningún plugin extra sin permiso.

WordPress Vulnerability

Sin duda, la creación hace un año de la WordPress Vulnerability Database API va a ser de gran uso en los próximos meses.

Ahora mismo soy la única entidad independiente que mantiene información de las vulnerabilidades de WordPress (ya que los otros implicados, gestionan más o menos dinero por la detección de vulnerabilidades y dependen del negocio de la seguridad).

Básicamente, el plugin de WPVulnerability deberá ser algo que probablemente el propio WordPress tenga que incluir de serie en todas las instalaciones, ya que «informar» es una de las bases de la ley.

Así que, si quieres empezar por ti o por tus clientes, ya estás tardando en ponerlo.

WPVulnerability

Próximos pasos

Como decía desde el principio, el Reglamento aún no está aprobado, aunque se espera que se haga a finales de 2023 (probablemente bajo el mandado de España en la Unión Europea, algo que no sé si es bueno o malo).

En cualquier caso, hay que ponerse las pilas porque esto va a llegar antes o después, en meses más que en años (aunque la aplicación real será en años), y no debemos dejarnos llevar por el tiempo, y que pase como con el RGPD y las prisas de última hora y la «privacidad por defecto».

Mi recomendación personal, que, como ya has podido ver, he comenzado a aplicar, es eso, aplicar la parte de informar y documentar, que no deja de ser un ejercicio de transparencia interesante y óptimo en el caso de proyectos de código abierto.

Si tienes alguna duda, sugerencia, que conste primero que no soy abogado, pero estoy abierto a comentar cualquier aspecto, ya que me afecta directamente en mi trabajo, demás de que el tema de la seguridad es algo que me gusta.