Evaluación de riesgos de ciberseguridad de la CRA

Función de la evaluación de riesgos

A efectos del cumplimiento del apartado 1, los fabricantes llevarán a cabo una evaluación de los riesgos de ciberseguridad asociados a un producto con elementos digitales y tendrán en cuenta el resultado de dicha evaluación durante las fases de planificación, diseño, desarrollo, producción, entrega y mantenimiento del producto con elementos digitales, con el fin de minimizar los riesgos de ciberseguridad, prevenir incidentes y minimizar su impacto, también en relación con la salud y la seguridad de los usuarios.

Reglamento (UE) 2024/2847, artículo 13(2)

El artículo 13 exige que la evaluación de riesgos abarque el ciclo de vida del producto y se actualice según corresponda durante el período de soporte.

Qué explica la evaluación

Con arreglo al artículo 13(3), la evaluación debe tener en cuenta la finalidad prevista, el uso razonablemente previsible, las condiciones de uso, el entorno operativo, los activos que deben protegerse y el tiempo de uso previsto.

• qué requisitos de la parte I del anexo I se aplican al producto;
• cómo se aplican dichos requisitos al producto;
• cómo se aplica el requisito general de ciberseguridad basado en el riesgo del punto 1 de la parte I del anexo I;
• cómo se aplican los requisitos de gestión de vulnerabilidades de la parte II del anexo I;
• por qué no es aplicable un requisito, cuando esa sea la conclusión del fabricante.

Ejemplo: evaluación de una ruta de actualización de firmware

Considere un controlador conectado ficticio que recibe firmware de un servicio de actualización. Un atacante podría intentar sustituir la imagen antes de su instalación. La evaluación debe determinar si esto es posible y qué podría hacer el firmware modificado.

1. Establezca la ruta de actualización del modelo de controlador y de la versión de firmware. Identifique quién puede proporcionar una imagen, cómo llega al dispositivo y qué comprobaciones se realizan antes de la instalación.
2. Describa la amenaza: un atacante sustituye una imagen de firmware antes de la instalación. El activo es la integridad del código ejecutable; las consecuencias dependen de las funciones que el controlador pueda modificar.
3. Evalúe los controles existentes: determine dónde se verifica la imagen, qué claves de firma son de confianza y qué ocurre si falla la verificación. Una declaración de diseño por sí sola no demuestra el comportamiento de la versión publicada.
4. Vincule las medidas a la verificación: conserve el diseño aprobado de actualización y las pruebas con imágenes modificadas, firmas incorrectas y recuperación tras fallos. Registre el firmware y la configuración sometidos a prueba.
5. Explique el riesgo residual atendiendo a las condiciones de ataque y a las consecuencias previstas. Identifique los supuestos que aún deban confirmarse y las medidas adicionales necesarias. Revise la conclusión cuando cambien el mecanismo de actualización o la amenaza.

Un diagrama de flujo de datos (DFD) y STRIDE pueden ayudar a identificar las rutas de ataque para este análisis. La decisión sobre el riesgo sigue requiriendo datos del producto y resultados de verificación. Por ejemplo, antes de confiar en que la comprobación de firmas reduzca el riesgo, el equipo debería confirmarla con respecto al diseño y al firmware sometido a prueba.

Vínculo con la documentación técnica

El artículo 13(4) incorpora la evaluación de riesgos de ciberseguridad a la documentación técnica. El anexo VII exige que esta incluya una evaluación de los riesgos de ciberseguridad frente a los cuales se diseña, desarrolla, produce, entrega y mantiene el producto.

Respaldo de las normas

El proyecto de norma prEN 40000-1-2 explica el documento horizontal vigente de principios para la gestión de riesgos de ciberresiliencia. Puede ayudar a estructurar el trabajo, pero la obligación jurídica sigue derivándose del artículo 13 y del anexo I.