Este blog es el segundo de nuestra serie Historias desde las trincheras: Lecciones aprendidas sobre la CRA. Nuestro objetivo al desarrollar estos blogs es ayudar a fabricantes, proveedores de software y proveedores de productos conectados a comprender las realidades prácticas de la implementación de programas de cumplimiento de la CRA. Nos basaremos en las lecciones que hemos aprendido trabajando con nuestros clientes y conversando con líderes del sector. Las organizaciones están aprendiendo que el cumplimiento sostenible requiere capacidades de gobernanza, visibilidad, rendición de cuentas y gestión del ciclo de vida que van mucho más allá de las actividades tradicionales de ciberseguridad. Crear un producto seguro no es suficiente para lograr el cumplimiento de la CRA.
El cumplimiento de la CRA comienza con la clasificación de productos: por qué definir el alcance y los niveles de seguridad es un desafío inesperado para los fabricantes.
Perspectivas para ejecutivos
A medida que las organizaciones aceleran sus programas de cumplimiento de la Ley de Ciberresiliencia (CRA), muchos ejecutivos están descubriendo una realidad inesperada: el primer desafío no es implementar controles de seguridad, sino comprender qué productos están dentro del alcance, cómo deben clasificarse y qué obligaciones de ciberseguridad se aplican a cada uno.
Cuando se presentó por primera vez la CRA, la mayoría de las organizaciones suponía que el esfuerzo principal implicaría gestión de vulnerabilidades, desarrollo seguro, SBOM, notificación de incidentes y actividades de seguridad posteriores a la comercialización. Aunque esos requisitos siguen siendo importantes, los fabricantes están descubriendo que todo comienza con una pregunta mucho más fundamental: ¿qué productos están dentro del alcance y cómo deben clasificarse?
Alcance y clasificación de productos según la CRA
¿Qué productos están dentro del alcance y cómo deben clasificarse?
Para las empresas con carteras extensas de productos, responder a esta pregunta puede ser sorprendentemente difícil. Un fabricante típico puede tener cientos, quizá miles, de productos activos, ofertas heredadas, plataformas de software integrado, servicios en la nube, aplicaciones móviles, productos OEM y soluciones adquiridas mediante fusiones y adquisiciones. Determinar qué ofertas califican como productos con elementos digitales (PDE), comprender su perfil de riesgo y asignar las obligaciones de seguridad correspondientes se ha convertido en una iniciativa importante por sí misma.
Acertar es fundamental porque las decisiones de clasificación determinan casi todas las actividades posteriores de cumplimiento de la CRA, incluidos los controles de seguridad requeridos, los requisitos de documentación, las obligaciones de gestión de vulnerabilidades, los requisitos de notificación regulatoria, las actividades de supervisión posteriores a la comercialización y mucho más.
Asignar un producto a un nivel de seguridad inferior al que corresponde puede generar riesgo de cumplimiento durante años. Por otro lado, asignarlo a un nivel superior al necesario genera trabajo innecesario y costoso.
Para muchas organizaciones, esto se convierte en la base de toda actividad posterior relacionada con la CRA. La clasificación de productos influye en las evaluaciones de riesgo cibernético, la documentación requerida, las rutas de evaluación de conformidad, las obligaciones posteriores a la comercialización, los informes ejecutivos y, en última instancia, el costo y la complejidad de lograr el cumplimiento. Los errores cometidos al definir el alcance de los productos suelen propagarse por todo el programa de cumplimiento.
Por qué la clasificación de productos es tan difícil
Muchas organizaciones suponen que categorizar productos es un sencillo ejercicio administrativo. En realidad, a menudo requiere una amplia colaboración entre equipos de ingeniería, gestión de producto, asuntos legales, cumplimiento, ciberseguridad y dirección ejecutiva.
Varios factores contribuyen a la complejidad:
Ecosistemas mixtos de hardware y software
Los productos actuales rara vez existen como dispositivos independientes. Un controlador industrial conectado puede incluir firmware integrado, aplicaciones móviles, plataformas de gestión en la nube, API, servicios de análisis y componentes de software de terceros.
Las organizaciones deben determinar si estos componentes deberían tratarse como productos individuales, servicios de apoyo o elementos de un ecosistema de producto mayor.
Carteras de productos heredados
Muchos fabricantes mantienen productos que han evolucionado durante décadas. La documentación puede ser incompleta, la propiedad puede haber cambiado y las suposiciones de seguridad pueden dejar de ser válidas. Antes de clasificar los productos, las organizaciones suelen tener que asegurarse de disponer de un inventario preciso de lo que realmente venden y soportan. Para los productos heredados, deben localizar guías de usuario y documentación de ingeniería. En los peores casos, esa documentación debe recrearse.
Adquisiciones y consolidación de productos
Las empresas que han crecido mediante adquisiciones suelen heredar productos desarrollados con procesos, arquitecturas y modelos de seguridad diferentes. Como resultado, productos similares pueden tener niveles muy distintos de madurez de ciberseguridad y documentación, lo que complica el establecimiento de clasificaciones coherentes según la CRA.
Determinar los niveles de seguridad apropiados
Incluso después de identificar los productos dentro del alcance de la CRA, las organizaciones se enfrentan a otra pregunta difícil: determinar la clasificación de producto adecuada según la CRA y las obligaciones de ciberseguridad resultantes.
No todos los productos tienen el mismo perfil de riesgo. Un dispositivo IoT de consumo, un controlador de automatización industrial, una plataforma de gestión basada en la nube y un sistema integrado crítico para la seguridad pueden asignarse a niveles de seguridad diferentes bajo la CRA. Cada nivel exige controles de seguridad y niveles de garantía muy diferentes.
Determinar la postura de seguridad adecuada requiere evaluar la funcionalidad del producto, sus características de conectividad, el impacto potencial de una vulneración, los entornos de clientes y los requisitos del ciclo de vida operativo.
Muchas organizaciones están descubriendo que estas evaluaciones requieren mucho más tiempo, estructura y evidencia de lo previsto originalmente. La CRA exige documentación que respalde todas las decisiones sobre qué nivel de seguridad se asigna a cada producto.
Muchos OEM también están descubriendo que el número de productos que requieren evaluación supera ampliamente las expectativas iniciales. Los equipos ejecutivos suelen empezar identificando las principales líneas de productos que se venden. Después de realizar un inventario detallado, muchas organizaciones descubren que cada línea de productos se compone de múltiples versiones compatibles y consiste en una combinación de ofertas únicas de software y hardware, productos con marca OEM, servicios en la nube y aplicaciones móviles. El resultado suele ser un aumento de cinco veces o más en el número de productos dentro del alcance.
Otro desafío es la falta de coherencia en la clasificación. Sin un marco de clasificación estandarizado, los equipos de producto de distintas unidades de negocio suelen aplicar definiciones diferentes de riesgo y criticidad de seguridad. Como resultado, productos similares pueden recibir clasificaciones de seguridad radicalmente distintas, creando incoherencias de cumplimiento en toda la organización.
Mejores prácticas para la clasificación de productos y la determinación del nivel de seguridad
Las organizaciones con programas maduros de cumplimiento de la CRA están adoptando varias prácticas comunes:
Establezca una taxonomía formal de productos
Desarrolle un marco estandarizado para categorizar productos, software, servicios y componentes de apoyo. Una terminología y unos criterios de decisión coherentes reducen la confusión y mejoran la toma de decisiones entre unidades de negocio.
Cree equipos de clasificación interfuncionales
La clasificación no debería ser responsabilidad exclusiva de los equipos de cumplimiento o seguridad. Las organizaciones exitosas involucran a gestión de producto, ingeniería, ciberseguridad, asuntos legales, regulación y aseguramiento de calidad.
Implemente niveles de seguridad basados en riesgos
Desarrolle niveles de seguridad definidos según la exposición al riesgo y el impacto empresarial. Esto permite priorizar los esfuerzos de certificación según el riesgo empresarial y del producto, en lugar de tratar todos los productos por igual.
Mantenga un inventario vivo de productos
Las hojas de cálculo estáticas quedan obsoletas rápidamente. Las organizaciones necesitan inventarios mantenidos continuamente que hagan seguimiento de propiedad del producto, composición del software, clasificación de seguridad, estado del ciclo de vida y obligaciones regulatorias.
Documente las decisiones de clasificación
Los reguladores esperarán cada vez más que las organizaciones expliquen no solo sus conclusiones, sino también el razonamiento detrás de ellas. Mantener evidencias que respalden las decisiones de clasificación es esencial.
Establezca la documentación adecuada en el Perfil de Producto
Las organizaciones logran de forma consistente una mejor calidad de evaluación cuando la documentación técnica se reúne antes de comenzar las evaluaciones. Especificaciones de producto, diagramas de arquitectura, SBOM, manuales técnicos de referencia, documentación de seguridad y artefactos de ingeniería de apoyo mejoran significativamente la precisión de las evaluaciones y reducen trabajo innecesario de remediación posteriormente.
Errores comunes
Al trabajar con nuestros clientes, hemos visto varios errores comunes y evitables:
Suponer que los equipos de producto ya conocen su inventario
Muchas organizaciones descubren productos ocultos, versiones sin soporte, tecnologías adquiridas y componentes de software no documentados durante los esfuerzos de preparación para la CRA.
Tratar la clasificación como una actividad puntual
Los productos evolucionan, las funciones cambian, la conectividad aumenta y los proveedores actualizan los componentes utilizados para construirlos. La clasificación debe revisarse continuamente para mantener una postura de seguridad adecuada durante todo el ciclo de vida del producto.
Aplicar los mismos requisitos de seguridad a todos los productos
Un modelo de seguridad uniforme suele generar costos innecesarios al aplicar requisitos excesivamente estrictos a productos de menor riesgo y, al mismo tiempo, no concentrar recursos en productos de mayor riesgo. La CRA define múltiples niveles de seguridad para permitir que las organizaciones adapten su postura según el riesgo.
En lugar de un único modelo de seguridad aplicado a todos los productos, las empresas deberían adoptar un marco común con múltiples niveles de seguridad mapeados a los niveles de clasificación de seguridad de productos de la CRA.
Ignorar los componentes de proveedores
Los componentes de hardware y software de terceros, las tecnologías OEM y las soluciones de software de código abierto pueden afectar significativamente a la clasificación y las obligaciones de seguridad. Las empresas deben asegurarse de que los proveedores cumplan los requisitos de la CRA y proporcionen la documentación adecuada para respaldar los programas de cumplimiento de los productos finales que utilizan estos componentes.
Acciones para OEM y proveedores de software
Las organizaciones que comienzan su recorrido con la CRA deberían considerar las siguientes acciones inmediatas:
- Crear un inventario completo de todos los productos, software, servicios y activos digitales.
- Identificar los productos que probablemente califican como productos con elementos digitales.
- Desarrollar una metodología formal de clasificación y un proceso de aprobación.
- Crear un modelo de niveles de seguridad basado en riesgos.
- Establecer responsables para cada producto y plataforma.
- Mapear proveedores y dependencias de software.
- Documentar todas las decisiones de clasificación y su justificación.
- Implementar procesos de gobernanza para mantener las clasificaciones actualizadas con el tiempo.
Las empresas que aborden pronto los desafíos de clasificación reducirán significativamente los costos de cumplimiento posteriores y las interrupciones operativas.
Cómo puede ayudar OmniTrust Certify
Uno de los mayores desafíos a los que se enfrentan las organizaciones no es realizar la primera evaluación de la CRA, sino mantener información precisa del producto, evaluaciones de riesgo cibernético, evidencias regulatorias y decisiones de clasificación a medida que los productos evolucionan con el tiempo.
Certify ayuda a las organizaciones a establecer un proceso repetible creando un Perfil de Producto vivo para cada producto conectado. A partir de esa base, los equipos de seguridad pueden realizar de forma coherente evaluaciones de riesgo cibernético, evaluar obligaciones de la CRA, mantener evidencias de respaldo y reevaluar productos cada vez que cambien la documentación, las arquitecturas, las vulnerabilidades o las regulaciones.
En lugar de depender de hojas de cálculo y documentos desconectados, las organizaciones obtienen un sistema de registro colaborativo que respalda la clasificación de productos, la gobernanza del riesgo cibernético, la conformidad regulatoria, la gestión de evidencias y la preparación para auditorías durante todo el ciclo de vida del producto.
Como están aprendiendo muchos de los primeros adoptantes, el cumplimiento exitoso de la CRA comienza mucho antes de la gestión de vulnerabilidades y la notificación de incidentes. Empieza por comprender exactamente qué productos tiene, qué riesgos presentan y qué nivel de responsabilidad de seguridad requiere cada producto.
Acertar con las clasificaciones de productos puede ser el paso más importante para crear un programa sostenible de cumplimiento de la CRA. Haga clic aquí para obtener más información sobre Certify y nuestras soluciones de cumplimiento.
Suscríbase al blog en nuestra página principal del blog para recibir notificaciones sobre futuros blogs de esta serie, que continúa con «Blog #3: Por qué la madurez de seguridad no es suficiente para estar preparado para la CRA»
