Requisitos esenciales de ciberseguridad de la CRA
Sytance · Actualizado
El anexo I establece los requisitos de base de la CRA para los productos con elementos digitales incluidos en su ámbito de aplicación. La parte I describe las propiedades de ciberseguridad del propio producto. La parte II describe el proceso del fabricante de gestión de vulnerabilidades durante el período de soporte.
Estructura del anexo I
El anexo I tiene dos partes. La parte I trata del producto. La parte II trata del proceso del fabricante de gestión de vulnerabilidades. El artículo 6 las vincula: un producto solo puede comercializarse si cumple los requisitos aplicables de la parte I y los procesos del fabricante cumplen la parte II.
Parte I: propiedades del producto
Configuración segura por defecto, datos protegidos, acceso controlado, funciones resilientes, capacidad de actualización, supervisión de la actividad y eliminación segura de datos y ajustes.
Parte II: gestión de vulnerabilidades
Procesos para detectar, documentar, corregir, divulgar y comunicar vulnerabilidades del producto y de sus componentes.
El artículo 13 exige al fabricante evaluar los riesgos de ciberseguridad. Esa evaluación determina cómo se aplican al producto los requisitos de la parte I.
Parte I: propiedades de ciberseguridad del producto
La parte I comienza con el resultado general esperado para el producto y, a continuación, enumera propiedades de seguridad que se aplican en función de la evaluación de riesgos de ciberseguridad y cuando corresponda. La lista es amplia porque la CRA abarca muchos tipos de software, hardware, componentes y tratamientos de datos a distancia que respaldan funciones del producto.
Los productos con elementos digitales se diseñarán, desarrollarán y producirán de manera que garanticen un nivel adecuado de ciberseguridad en función de los riesgos.
Reglamento (UE) 2024/2847, anexo I, parte I, punto 1
Una aplicación de consumo, una VPN industrial y un componente de hardware reutilizable pueden afrontar riesgos distintos aunque un requisito utilice las mismas palabras. La evaluación de riesgos explica cómo se aplican al producto los requisitos de la parte I y por qué un requisito no es aplicable si esa es la conclusión del fabricante.
La parte I pregunta principalmente si el producto puede:
- comercializarse sin vulnerabilidades explotables conocidas y con una configuración segura por defecto;
- abordar las vulnerabilidades mediante actualizaciones de seguridad, incluidas las automáticas cuando sean adecuadas para el producto;
- proteger el acceso, la confidencialidad, la integridad, la disponibilidad, los comandos, los programas, la configuración y los datos tratados;
- limitar las superficies de ataque y reducir el impacto de un incidente;
- registrar y supervisar la actividad de seguridad pertinente con un mecanismo para que el usuario pueda excluirse;
- permitir a los usuarios eliminar datos y ajustes de forma segura y transferir datos de forma segura si se admite esa transferencia.
Estas son propiedades del producto, no un patrón de implementación único. Un mismo requisito puede llevar a distintas decisiones técnicas para un dispositivo de consumo, un producto de red profesional, un SDK o un firmware destinado a integrarse en otros productos.
Parte II: gestión de vulnerabilidades
La parte II trata del proceso del fabricante. Se aplica desde que el producto se comercializa y durante todo el período de soporte. También abarca las vulnerabilidades de los componentes integrados en el producto, por lo que son importantes tanto la visibilidad de los componentes como la comunicación con los proveedores.
El fabricante debe identificar y documentar las vulnerabilidades y los componentes. El anexo I incluye expresamente una lista de materiales de software (SBOM) en un formato legible por máquina y de uso común, que abarque como mínimo las dependencias de nivel superior.
Las vulnerabilidades deben abordarse y corregirse sin demora en función de los riesgos que plantean para el producto. Cuando sea técnicamente viable, las actualizaciones de seguridad deberían separarse de las actualizaciones funcionales.
La parte II exige una política de divulgación coordinada de vulnerabilidades y una dirección de contacto para notificar vulnerabilidades. El artículo 13 también exige que los fabricantes informen a la persona o entidad que mantiene un componente integrado cuando detecten una vulnerabilidad en dicho componente.
Los mecanismos de actualización deben distribuir las correcciones de forma segura y oportuna. Cuando haya actualizaciones de seguridad disponibles, deben difundirse sin demora, normalmente de forma gratuita, y acompañarse de información que ayude a los usuarios a actuar.
Normas y pruebas
Las normas armonizadas pueden respaldar una presunción de conformidad únicamente cuando se publique la referencia pertinente en el Diario Oficial de la Unión Europea. Los proyectos, las correspondencias y las normas sectoriales aún pueden ser pruebas útiles, pero no sustituyen a la evaluación de riesgos específica del producto que exige el artículo 13.
La solicitud de normalización M/606 de la Comisión para la CRA pide a las organizaciones europeas de normalización que elaboren normas horizontales y verticales. Las preguntas frecuentes sobre la aplicación describen entregables horizontales para el marco de productos basado en riesgos, las propiedades de los productos de la parte I y la gestión de vulnerabilidades de la parte II, además de normas verticales para categorías de productos importantes y críticos.
La documentación técnica debería explicar cómo abordan los riesgos identificados para el producto las normas seleccionadas u otras medidas técnicas. A continuación, debería mostrar qué propiedades del producto y qué procesos de gestión de vulnerabilidades aplican esas medidas.
Consulte prEN 40000-1-4 Material público para consultar el material público actual sobre el proyecto de norma genérica de requisitos de seguridad previsto, y prEN 40000-1-3 Gestión de vulnerabilidades para consultar el borrador actual sobre gestión de vulnerabilidades.