Este blog es el cuarto 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.
Por qué la ciberseguridad posterior a la comercialización se está convirtiendo en el desafío que define la preparación para la CRA
Durante décadas, la mayoría de las organizaciones de desarrollo de productos han operado con un modelo relativamente simple: diseñar el producto, probar el producto, lanzar el producto y pasar a la siguiente versión o al siguiente producto.
El éxito se medía en función de completar el desarrollo a tiempo, cumplir los requisitos de rendimiento, superar las pruebas de calidad e implementar todos los requisitos del producto.
La Ley de Ciberresiliencia (CRA) de la Unión Europea ha cambiado fundamentalmente la forma de medir el éxito.
El lanzamiento del producto ya no es la meta. Es el punto de partida.
Históricamente, los esfuerzos de desarrollo seguro de productos se centraban en desarrollo seguro, evaluaciones de riesgos, evaluaciones de conformidad y documentación técnica. Esto ha cambiado con la adopción de la CRA. Los fabricantes y proveedores de software reconocen cada vez más que algunas de las obligaciones más importantes de la CRA comienzan después de que los productos llegan a los clientes.
Ahora las empresas deben implementar programas que permanezcan activos durante toda la vida útil del producto. Entre ellos se incluyen gestión de vulnerabilidades, divulgación coordinada, actualizaciones de seguridad, notificación de incidentes, supervisión de la cadena de suministro de software, comunicaciones con clientes y compromisos ampliados de soporte del producto.
Para muchas organizaciones, esto representa un cambio operativo importante. La pregunta ya no es:
«¿Es este producto lo bastante seguro para lanzarlo?»
La pregunta se ha convertido en:
«¿Podemos mantener la responsabilidad de ciberseguridad durante los próximos cinco, siete o incluso diez años?»
Perspectivas para ejecutivos
Muchas organizaciones abordaron inicialmente el cumplimiento de la CRA como otros esfuerzos de cumplimiento de ciberseguridad: como una iniciativa de desarrollo de producto. Suponían que era un proceso sencillo: realizar evaluaciones de seguridad, implementar las funciones de seguridad necesarias, completar las pruebas requeridas y documentar el cumplimiento. Sin embargo, las organizaciones están aprendiendo que esta visión subestima enormemente el alcance de la regulación.
La CRA introduce un modelo de ciclo de vida para la responsabilidad de ciberseguridad. Se espera que los fabricantes gestionen y divulguen vulnerabilidades, proporcionen actualizaciones de seguridad y notifiquen a los clientes cualquier vulnerabilidad o problema. También deben mantener visibilidad continua sobre vulnerabilidades, dependencias de software, actualizaciones de seguridad, notificaciones a clientes, actividades de respuesta a incidentes, compromisos de soporte y postura de riesgo del producto.
Esto representa un cambio significativo en la forma de gestionar la seguridad de los productos. Bajo la CRA, las organizaciones deben invertir en capacidades operativas a largo plazo que persistan mucho después de que los equipos de ingeniería pasen a la siguiente versión del producto o a un nuevo esfuerzo de desarrollo.
La preparación para la CRA no consiste solo en seguridad de producto. También requiere gobernanza del ciclo de vida del producto.
Por qué las obligaciones posteriores al lanzamiento son tan desafiantes
Mantener la ciberseguridad y la preparación para auditorías de la CRA después del lanzamiento del producto es considerablemente más difícil de lo que muchas organizaciones esperaban inicialmente. Varios factores contribuyen al desafío.
Los productos siguen evolucionando
Las actualizaciones de software, mejoras de funciones, actualizaciones de componentes de terceros y nuevos casos de uso de clientes cambian constantemente los perfiles de riesgo de los productos. Una evaluación de riesgos completada durante el desarrollo o en el lanzamiento puede quedar desactualizada rápidamente.
Las vulnerabilidades no dejan de aparecer
Los investigadores de seguridad y los actores maliciosos siguen encontrando nuevas vulnerabilidades que afectan a sistemas operativos, componentes de código abierto, software comercial y plataformas de hardware. Las organizaciones deben evaluar continuamente si estas vulnerabilidades afectan a productos ya lanzados.
Los equipos de producto siguen adelante
Una vez lanzado un producto, los equipos de ingeniería suelen trasladar su atención a futuras versiones o nuevos esfuerzos de desarrollo. Mientras tanto, los productos heredados permanecen en uso durante años, periodo durante el cual puede desaparecer el conocimiento institucional. Sin procesos formales de ciclo de vida y una documentación sólida, puede perderse el conocimiento sobre las capacidades y la arquitectura de seguridad del producto.
Las cadenas de suministro de software se vuelven más complejas
Los productos modernos suelen contener decenas o incluso cientos de componentes de software, cada uno de los cuales puede introducir vulnerabilidades. Las empresas deben tener visibilidad sobre cada componente y todas sus actualizaciones.
Requisitos de notificación a clientes
La CRA exige a las organizaciones notificar a los clientes nuevas vulnerabilidades descubiertas, actualizaciones de seguridad y cambios en las condiciones de soporte. Cumplir estos mandatos requiere desarrollar capacidades operativas que muchas organizaciones no habían necesitado anteriormente.
Desafíos del mundo real
Muchas empresas reutilizan componentes de software en múltiples sistemas. Si se descubre una vulnerabilidad crítica en una biblioteca de código abierto o software propietario, puede resultar difícil para las organizaciones gestionar el proceso de actualización y notificación a clientes.
Una sola vulnerabilidad puede afectar a múltiples versiones de varios productos distintos. Identificar los productos afectados puede exigir buscar entre múltiples productos, recuperar documentación de sistemas dispares, revisar listas históricas de materiales de software y coordinar equipos de ingeniería.
Abordar la vulnerabilidad en sí puede ser relativamente sencillo. Pero sin repositorios centralizados de documentación que incluyan Listas de Materiales de Software (SBOM) completas, puede ser difícil determinar qué productos están afectados.
Las empresas también afrontan dificultades para cumplir los requisitos posteriores a la comercialización de la CRA debido a problemas de estructura organizativa.
Las responsabilidades de gestión de vulnerabilidades posteriores al lanzamiento suelen distribuirse entre equipos de producto, organizaciones de soporte y grupos de ingeniería. Como resultado, reunir documentación para auditorías de cumplimiento puede resultar más difícil de lo esperado.
Las empresas que dan soporte a múltiples familias de productos entre distintas unidades de negocio afrontan desafíos similares. En muchos casos, cada equipo puede gestionar de forma diferente las actualizaciones, los procesos de soporte y el seguimiento de vulnerabilidades.
Los esfuerzos de preparación para la CRA requieren procesos estandarizados entre equipos, junto con responsabilidad ejecutiva para coordinar los esfuerzos de cumplimiento.
Mejores prácticas para un cumplimiento sostenible de la CRA
Las organizaciones que más avanzan están tratando la ciberseguridad posterior a la comercialización como una disciplina operativa permanente en lugar de como un ejercicio de cumplimiento.
Cree programas de seguridad durante el ciclo de vida
Las responsabilidades de ciberseguridad deben comenzar en la concepción del producto y continuar mientras el producto reciba soporte. Las organizaciones deberían establecer procesos formales que cubran supervisión de vulnerabilidades, actualizaciones de seguridad, respuesta a incidentes, comunicaciones con clientes y retirada del producto.
Mantenga visibilidad continua del producto
Las organizaciones necesitan visibilidad actualizada sobre inventarios de productos, componentes de software, dependencias de terceros, propiedad del producto y estado de soporte.
Sin visibilidad, la gestión eficaz posterior a la comercialización se vuelve imposible.
Establezca responsabilidades claras
Cada producto debería tener responsabilidades claramente definidas para supervisión de seguridad, evaluación de vulnerabilidades, gestión de actualizaciones e informes de cumplimiento.
La falta de responsabilidades definidas suele generar brechas.
Automatice donde sea posible
Los procesos manuales se vuelven cada vez más difíciles a medida que crecen las carteras de productos. La automatización puede mejorar el seguimiento de vulnerabilidades, la recopilación de evidencias, la gestión de SBOM, los informes de cumplimiento y la preparación para auditorías.
Integre el cumplimiento en las operaciones de producto
Las organizaciones deberían evitar tratar las actividades de la CRA como proyectos de cumplimiento separados. En su lugar, los requisitos de la CRA deben convertirse en parte de las operaciones estándar de gestión y soporte del producto.
Errores comunes
Muchas organizaciones encuentran obstáculos similares cuando comienzan a abordar las obligaciones posteriores a la comercialización.
Considerar el cumplimiento como una actividad previa al lanzamiento
Quizá el error más común sea suponer que el cumplimiento termina con el lanzamiento. En realidad, muchas obligaciones comienzan después del despliegue. Y suelen ser las obligaciones más difíciles de cumplir.
Subestimar los requisitos de soporte a largo plazo
Las organizaciones suelen centrarse en las actividades de desarrollo y pasar por alto los recursos necesarios para mantener compromisos de seguridad continuos.
Mantener inventarios de productos incompletos
Si las organizaciones no pueden identificar qué productos están desplegados y qué software contienen, responder a vulnerabilidades se vuelve difícil.
Depender de documentación fragmentada
La evidencia dispersa en múltiples sistemas genera ineficiencias operativas y riesgos de cumplimiento.
Tratar las actualizaciones de seguridad solo como tareas de ingeniería
Las actualizaciones de seguridad suelen requerir coordinación entre equipos de ingeniería, asuntos legales, soporte, gestión de producto, calidad y dirección ejecutiva.
Acciones para OEM y proveedores de software
Las organizaciones que buscan reforzar su preparación posterior a la comercialización para la CRA deberían considerar las siguientes acciones.
Prioridades inmediatas
- Revisar los procesos actuales de soporte y mantenimiento de productos.
- Inventariar todos los productos y plataformas de software compatibles.
- Establecer procedimientos formales de supervisión de vulnerabilidades.
- Identificar responsables de las actividades de ciberseguridad posteriores a la comercialización.
- Revisar la visibilidad de componentes de software y las prácticas de SBOM.
- Evaluar la preparación para respuesta a incidentes y divulgación.
- Evaluar los procesos de comunicación con clientes.
- Identificar brechas en la gestión de evidencias.
Las organizaciones que comiencen estos esfuerzos pronto estarán mucho mejor posicionadas a medida que se acerquen los plazos de aplicación de la CRA.
Cómo puede ayudar OmniTrust Certify
Una de las lecciones más constantes que surgen de los programas de preparación para la CRA es que las organizaciones pueden completar una evaluación inicial con relativa rapidez. El verdadero desafío es mantener la información actualizada a medida que evolucionan los productos, aparecen vulnerabilidades, cambian los proveedores y las regulaciones continúan madurando.
OmniTrust Certify ayuda a automatizar este proceso. Certify proporciona un sistema de registro centralizado para la ciberseguridad y el cumplimiento de productos durante todo el ciclo de vida.
Con OmniTrust Certify, fabricantes y proveedores de software centralizan cada producto conectado en un Perfil de Producto vivo que realiza un seguimiento continuo del riesgo cibernético, la conformidad regulatoria, las evidencias, la propiedad y los cambios del producto, manteniendo a los equipos de ingeniería, seguridad, producto y cumplimiento trabajando con la misma versión de la realidad.
En lugar de tratar el cumplimiento de la CRA como un proyecto puntual, Certify permite a las organizaciones establecer un enfoque sostenible del ciclo de vida para la gobernanza de ciberseguridad.
Resumen
Las organizaciones que tendrán éxito bajo la CRA no son simplemente aquellas que pueden crear productos seguros. Son las organizaciones que pueden mantener, supervisar, documentar y defender continuamente la seguridad de esos productos durante toda su vida operativa.
Por eso, bajo la Ley de Ciberresiliencia, el verdadero trabajo comienza después del lanzamiento del producto.
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 #5: El plazo de notificación de 24 horas es en realidad un problema de visibilidad»
