La primera fecha límite del Reglamento sobre la seguridad de los sistemas de información ( Ley de Ciberresiliencia ) entró en vigor la semana pasada. El Reglamento sobre la seguridad de los sistemas de información (Ley de Ciberresiliencia , CRA) es la nueva normativa de la UE que establece los requisitos mínimos de ciberseguridad para todos los productos con elementos digitales, incluidos sus componentes básicos (hardware y software). Se aplica a cualquier persona que comercialice productos en el mercado de la UE, no solo a las empresas con sede en la UE.
Los requisitos completos no entrarán en vigor hasta finales del año que viene. Todos los productos con elementos digitales que se vendan en la UE deberán cumplir los requisitos de seguridad de la CRA a más tardar el 11 de diciembre de 2027. Hemos tratado este tema con más detalle en nuestra primera entrada del blog sobre la CRA.
Llevo tres años siguiendo de cerca la evolución de esta normativa. Ahora que la Plataforma Única de Presentación de Informes (SRP) ya está en funcionamiento, quiero compartir mis primeras impresiones y desmentir algunos mitos sobre cómo hay que cumplir con la CRA, para que puedas seguir adelante con confianza.
Uso de la nueva plataforma única de presentación de informes de la CRA
A partir del 11 de septiembre, las empresas están obligadas por ley a notificar a las autoridades de la UE cualquier vulnerabilidad que esté siendo explotada activamente o cualquier incidente grave en un plazo de 24 horas desde que tengan conocimiento de ello. Pueden hacerlo a través de la nueva Plataforma Única de Notificación (SRP).
Al informe inicial (tras 24 horas) le sigue una notificación en un plazo de 72 horas que incluye información sobre la amenaza y las medidas de mitigación. Las organizaciones deben presentar un informe final en un plazo de 14 días desde que esté disponible una corrección para las vulnerabilidades explotadas, o en el plazo de un mes desde la notificación de 72 horas en el caso de incidentes graves.
Hasta ahora, los únicos campos obligatorios del informe inicial son:
- Tipo (vulnerabilidad o incidente)
- Título
- Resumen
- Nombre del fabricante
- Estados miembros en los que está disponible el producto
- Nombre del producto
- Versión
En la sección «Producto», también se solicita, de forma opcional, el tipo de producto (clasificación) y, por supuesto, puedes añadir varios productos. ¡Y ya está!
La notificación voluntaria se pondrá en marcha en una fase posterior, lo que permitirá a cualquier persona comunicar vulnerabilidades sin sufrir consecuencias legales. Mientras tanto, utiliza la plataforma únicamente para las notificaciones obligatorias.
Puedes consultar estos detalles y mucho más en el manual del SRP de la CRA.
Ley de Ciberresiliencia desmontar mitos
En Aikido Security recibimos muchas preguntas relacionadas con la CRA y sus obligaciones en materia de notificación de incidentes. A continuación, aclaro algunos de los conceptos erróneos más comunes que he oído.
Mito n.º 1: Tenemos que comunicar a la ENISA todas las vulnerabilidades que detectemos
En realidad, no es necesario que notifiques todas las vulnerabilidades que encuentres en tu producto (¡una gran noticia!). Las únicas vulnerabilidades que debes notificar son aquellas que se están explotando activamente en tu producto con fines maliciosos, o un incidente grave que afecte a la seguridad de tu producto.
Por lo tanto, si detectas una vulnerabilidad en tu producto, pero no tienes pruebas ni indicios de que haya sido explotada, no estás obligado a notificarla. Sin embargo, si tienes conocimiento de que ha sido explotada por un actor malintencionado, sí que tendrás que notificarla. Por eso, te recomiendo que priorices las vulnerabilidades en función de su explotabilidad, para evitar que se conviertan en incidentes que deban notificarse en el futuro.
Mito n.º 2: El informe final debe presentarse 14 días después de haber detectado la vulnerabilidad
Eso no es cierto. La indicación real es que el informe final (sobre las vulnerabilidades explotadas) solo debe presentarse 14 días después de haber aplicado la corrección. Mucha gente interpreta que son 14 días desde el momento en que se descubrió por primera vez, y entonces se asusta ante un plazo que no existe. ¡Esto te da más tiempo, ya que dos semanas no es un plazo realista para algunos productos!
Aquí tienes la cronología completa:
- En un plazo de 24 horas, envía una alerta temprana. («Ha pasado algo»)
- Pasadas 72 horas, envía una notificación de vulnerabilidad. («Esto es lo que ha pasado.»)
- 14 días después de publicar una solución para las vulnerabilidades que se están explotando activamente, envía el informe final. («Así es como lo hemos solucionado.»)
- Un mes después del plazo de 72 horas para notificar los incidentes graves, envía el informe final. («Así es como gestionamos el incidente.»)
Mito n.º 3: Basta con informar a la ENISA de la vulnerabilidad y ya está
Lamentablemente, esto es solo un paso. Según la CRA, debes notificar directamente a la Plataforma Única de Notificación (SRP), a la que tienen acceso tanto tu CSIRT local como la ENISA. Sin embargo, también debes informar a los usuarios afectados por un incidente de las medidas correctivas que pueden aplicar para mitigar el impacto de dicha vulnerabilidad. Dependiendo del incidente, es posible que tengas que informar a toda tu base de usuarios.
Mito n.º 4: Tenemos que registrarnos en la Plataforma Única de Notificación ahora que ya está en funcionamiento
No, no hace falta que hagas nada ahora mismo si no tienes nada que comunicar. Al principio no tenía muy claro este tema, pero el manual de usuario me lo ha aclarado: de hecho, la ENISA recomienda a las empresas que esperen antes de realizar el prerregistro.
Me preocupaba un poco que, si no te registras previamente, acabaras teniendo que esperar a que el CSIRT validara tus datos en caso de emergencia. Por suerte, esto no supone ningún problema. Un representante autorizado (AR) puede enviar notificaciones incluso mientras la validación esté pendiente. La plataforma acepta hasta 20 envíos de usuarios no validados, lo que permite que hasta 20 personas de una misma empresa puedan registrarse para presentar informes.
Primeras impresiones y perspectivas de futuro
Mis primeras impresiones sobre el CRA SRP son, en general, positivas. La verificación de mi cuenta como empleado real de Aikido (la «Asociación de Representantes Asignados») tardó tres días laborables en completarse por parte del CSIRT de Bélgica. Esta verificación garantiza que los trolls no puedan reclamar tu empresa antes que tú.
La plataforma tuvo algunos problemas de implementación el día 11, pero todo volvió a estar operativo en unas pocas horas. Una vez configurada, recibirás una notificación por correo electrónico en cuanto se autorice tu asociación. También admite la autenticación mediante clave de acceso, aunque te recomiendo encarecidamente que configures algunos dispositivos de respaldo para que no te quedes sin acceso.
De cara al futuro, las próximas normas armonizadas (que están por entrar en vigor) son realmente lo que todo el mundo debe tener en cuenta, ya que definen las normas técnicas concretas para fabricar productos que cumplan con la normativa. Sin duda, te interesará profundizar en estos borradores lo antes posible. Si no lo haces, corres el riesgo de diseñar productos que no cumplan los requisitos y que, más adelante, obliguen a realizar costosos rediseños.
Presta especial atención a la norma EN 40000-1-1 (que establece la terminología) y a la EN 40000-1-3 (que establece las normas para la gestión y la divulgación de vulnerabilidades). ¡Familiarizarte con estas normas desde el principio te dará una ventaja considerable sobre tus competidores!
El futuro del Ley de Ciberresiliencia
Este plazo de septiembre no fue más que el primer paso. Todos los productos con elementos digitales que se vendan en la UE deberán cumplir íntegramente los requisitos de seguridad de la CRA a más tardar el 11 de diciembre de 2027. A partir de esa fecha, los productos que no cumplan con dichos requisitos ya no podrán comercializarse en el mercado de la UE, lo que supondrá una pérdida directa de ingresos para las empresas que no estén preparadas.
Para los consumidores, un etiquetado claro les permitirá conocer el periodo de soporte y las especificaciones de seguridad antes de comprar un producto. Además, los productos deberán ser seguros de serie nada más sacarlos de la caja, y contar con actualizaciones gratuitas garantizadas durante al menos cinco años.
Un efecto secundario es que la UE ahora puede utilizar todos los informes de vulnerabilidades para desarrollar la EUVD (Base de Datos Europea de Vulnerabilidades). Esto puede cubrir el vacío dejado por la NVD del NIST, que se encuentra sepultada bajo un enorme volumen de trabajo atrasado y ha anunciado que ya no calificará ni enriquecerá cada envío de CVE. Personalmente, creo que esto también está relacionado con la creciente opinión de que la UE debería ser más independiente desde el punto de vista tecnológico. Con los datos de la CRA, la UE tiene la oportunidad de crear una base de datos propia. A medida que aumenten las notificaciones, veremos si la UE logra estos objetivos.
Por ahora, seguiremos de cerca la evolución de los sistemas y os mantendremos al corriente de las novedades.
Cómo te ayuda el aikido a cumplir con los requisitos de la CRA
Aunque ninguna herramienta puede encargarse de presentar tus informes a la CRA por ti, supervisamos el catálogo de «Vulnerabilidades explotadas conocidas» (KEV) de la CISA. Esto significa que el filtro «Estado de explotación» de tu feed de Aikido solo muestra las vulnerabilidades con una explotación conocida en el mundo real, que son las que tienen más probabilidades de provocar un incidente. Esto te permite priorizarlas y evitar los eventos que deben notificarse. También puedes consultar la puntuación de gravedad de una vulnerabilidad para ver si «explotada activamente en el entorno real» figura como factor contribuyente. Ese es tu indicador temprano para comprobar si has sido objeto de un ataque intencionado y si se aplican las obligaciones de notificación.
Utiliza CVE análisis de explotabilidad para ver cómo se podría explotar realmente un CVE en tu código fuente. Resulta útil para establecer prioridades y, en caso de que acabes presentando una notificación, para describir la naturaleza técnica de la vulnerabilidad tanto a las autoridades reguladoras como a los usuarios.
Aunque la CRA pueda parecer una serie de obligaciones más de las que hay que tener en cuenta, no tiene por qué resultar abrumadora. Descubre más sobre cómo Aikido puede ayudarte a cumplir los requisitos de la CRA.
También puedes concertar una llamada con nosotros y te ayudaremos.
