Los requisitos de la CRA se documentan en el anexo I de CRA. Los equipos de pruebas deben entender cómo aplicar estos controles a los sistemas de pruebas. La ley europea de ciberresiliencia (CRA) está bien documentada en una serie de documentos publicados en european-cyber-resilience-act.com/. La legislación se describe en 57 artículos. Afortunadamente, los requisitos técnicos se describen principalmente en el anexo I.
Los requisitos de la CRA europea se definen principalmente en el anexo I. También hay cuatro documentos adicionales del anexo:
El Centro Común de Investigación (JRC) de la UE y la Agencia de Ciberseguridad de la Unión Europea (ENISA) publicaron un documento para describir cómo los requisitos de la CRA se ajustan a las normas industriales existentes, incluyendo la norma EN IEC 62443. Su documento gratuito en enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping es una guía útil para las empresas que ya han adoptado una de estas normas.
El anexo I se divide en dos secciones. La sección 1 aborda las propiedades de los productos y la sección 2 aborda cómo responderá el proveedor al descubrimiento de vulnerabilidades.
(1) Los productos con elementos digitales se diseñarán, desarrollarán y producirán de tal manera que garanticen un nivel adecuado de ciberseguridad en función de los riesgos;
(2) Los productos con elementos digitales se entregarán sin ninguna vulnerabilidad explotable conocida;
(3) Sobre la base de la evaluación de riesgos a que se refiere el artículo 10, apartado 2, y cuando proceda, los productos con elementos digitales:
a) se entregarán con una configuración segura por defecto, incluyendo la posibilidad de restablecer el producto a su estado original;
b) garantizar la protección contra el acceso no autorizado mediante mecanismos de control adecuados, incluyendo, entre otros, los sistemas de autenticación, identidad o gestión del acceso;
(c) proteger la confidencialidad de los datos almacenados, transmitidos o procesados de otro modo, personales o de otro tipo, por ejemplo cifrando los datos pertinentes en reposo o en tránsito con mecanismos de última generación;
(d) proteger la integridad de los datos almacenados, transmitidos o procesados de otro modo, órdenes, programas y configuración personales o de otro tipo, contra cualquier manipulación o modificación no autorizada por el usuario, así como informar sobre las corrupciones;
(e) procesar solo datos, personales o de otro tipo, que sean adecuados, pertinentes y limitados a lo necesario en relación con el uso previsto del producto («minimización de datos»);
f) proteger la disponibilidad de funciones esenciales, incluyendo la capacidad de recuperación frente a los ataques de denegación de servicio y la mitigación de sus efectos;
(g) minimizar su propio impacto negativo en la disponibilidad de servicios prestados por otros dispositivos o redes;
h) ser diseñado, desarrollado y producido para limitar las superficies de ataque, incluyendo interfaces externas;
i) ser diseñado, desarrollado y producido para reducir el impacto de un incidente utilizando mecanismos y técnicas adecuados de mitigación de la explotación;
j) proporcionar información relacionada con la seguridad registrando y/o supervisando la actividad interna pertinente, incluyendo el acceso a los datos, servicios o funciones o su modificación;
k) garantizar que las vulnerabilidades puedan abordarse mediante actualizaciones de seguridad, incluyendo, cuando proceda, actualizaciones automáticas y la notificación de las actualizaciones disponibles a los usuarios.
Si está desarrollando un sistema de pruebas que está sujeto a estos requisitos, deberá adoptar un proceso de desarrollo que cumpla con el primer requisito. Hay múltiples marcos de desarrollo de seguridad disponibles, incluyendo el ciclo de vida de desarrollo seguro de Microsoft y el framework gubernamental de desarrollo de software seguro, documentado en NIST 800-218. Si bien estos no están desarrollados para sistemas de pruebas o productos como LabVIEW o TestStand, contienen principios generales que se aplican a cualquier desarrollo de sistemas. Puede usarlos para crear un proceso para su equipo que cumpla con los requisitos de la CRA.
Al planificar las características de su sistema de pruebas, tendrá que considerar los requisitos adicionales de la CRA. Tendrá que planificar el control del acceso al sistema de pruebas, tanto por parte de los usuarios como de los sistemas externos. Deberá identificar qué datos deben protegerse mediante cifrado y cómo serán cifrandos esos datos. Necesitará desarrollar defensas contra ataques. Necesitará documentar la actividad en registros de auditoría. Y tendrá que planificar las actualizaciones de seguridad de los componentes del sistema.
Este trabajo supondrá una carga adicional para su equipo de desarrollo, y debe considerar cuidadosamente los costos adicionales durante las fases de planificación del proyecto. Trabaje con su cliente para comprender las opciones de seguridad y quién será el responsable de las actualizaciones del sistema posteriores a la implementación para mantener la seguridad del sistema.
Es importante señalar que la seguridad debe considerarse a nivel del sistema. Algunos componentes no cumplirán todos estos requisitos por sí solos. Pero combinado con otras partes del sistema, esas lagunas deben protegerse para que pueda demostrar la plena seguridad del sistema.
Por último, no subestime el valor y el esfuerzo de proporcionar documentación de seguridad completa. Debe documentar cómo el sistema cumple con los requisitos de la CRA. Y debe incluir documentación para restaurar el sistema a una configuración segura de referencia: este será un recurso crítico si un ataque alguna vez deshabilita el sistema. También se puede utilizar para garantizar que el sistema no se ajuste lejos de esa configuración segura.
Los fabricantes de los productos con elementos digitales deberán:
(1) identificar y documentar las vulnerabilidades y componentes contenidos en el producto, incluso mediante la elaboración de una lista de materiales de software en un formato de uso común y lectura mecánica que cubra al menos las dependencias de nivel superior del producto;
(2) en relación con los riesgos planteados a los productos con elementos digitales, abordar y remediar las vulnerabilidades sin demora, incluso proporcionando actualizaciones de seguridad;
(3) aplicar pruebas y revisiones efectivas y regulares de la seguridad del producto con elementos digitales;
(4) una vez que se haya puesto a disposición una actualización de seguridad, divulgar públicamente información sobre vulnerabilidades corregidas, incluyendo una descripción de las vulnerabilidades, información que permita a los usuarios identificar el producto con elementos digitales afectados, los impactos de las vulnerabilidades, su gravedad e información que ayude a los usuarios a remediar las vulnerabilidades;
5) Establecer y aplicar una política de divulgación coordinada de la vulnerabilidad;
6) tomar medidas para facilitar el intercambio de información sobre posibles vulnerabilidades en su producto con elementos digitales, así como en componentes de terceros contenidos en dicho producto, incluso proporcionando una dirección de contacto para la notificación de las vulnerabilidades descubiertas en el producto con elementos digitales;
(7) proporcionar mecanismos para distribuir de forma segura las actualizaciones de los productos con elementos digitales a fin de garantizar que las vulnerabilidades explotables se corrijan o mitiguen oportunamente;
(8) garantizar que, cuando se disponga de parches o actualizaciones de seguridad para abordar los problemas de seguridad detectados, se difundan sin demora y de forma gratuita, acompañados de mensajes de asesoramiento que faciliten a los usuarios la información pertinente, incluyendo las posibles medidas que deban adoptarse.
La documentación que entrega con el sistema puede necesitar incluir un SBOM.. Un SBOM incluye todos los componentes de software del sistema. En ataques recientes, las empresas han experimentado una búsqueda urgente de componentes para identificar qué sistemas contienen el software que está abierto a ataques. Los SBOM proporcionan una forma para que las empresas mantengan un inventario de software, comparen ese inventario con los problemas notificados y administren los sistemas que contienen los problemas.
Más SBOMs aumentarán la transparencia para los usuarios finales de las formas en que sus sistemas son vulnerables a los ataques. Los proveedores serán llamados más frecuentemente para proporcionar actualizaciones de seguridad. Los proveedores están obligados por la CRA a proporcionar estas actualizaciones durante 5 años después de la entrega de un producto o sistema - su equipo necesita desarrollar un plan para proporcionar ese soporte.
En conjunto, estos requisitos de la CRA mejorarán las defensas de seguridad de los sistemas de pruebas. Pero también aumenta la cantidad de trabajo en los desarrolladores de sistemas y las expectativas que tienen en proveedores como NI.
Vea cómo NI proporciona recursos para ayudar a su equipo a cumplir con estas expectativas.