Este blog es el octavo 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 hablando con líderes del sector.  Las organizaciones están aprendiendo que un 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 preparación de terceros se está convirtiendo en un factor crítico de éxito en virtud del Reglamento de Ciberresiliencia

Para muchos fabricantes y proveedores de software, los esfuerzos de preparación para el Reglamento de Ciberresiliencia (CRA) se centran inicialmente en actividades internas. Las organizaciones hacen inventario de sus productos, realizan evaluaciones de riesgos, implementan procesos de gestión de vulnerabilidades, desarrollan listas de materiales de software (SBOM) y establecen marcos de gobernanza diseñados para cumplir los requisitos normativos.

Todas estas son actividades esenciales.  Sin embargo, las empresas están descubriendo que las actividades centradas únicamente en el ámbito interno no son suficientes.

Su postura de cumplimiento puede depender tanto de sus proveedores como de su propia organización.

Los productos modernos rara vez se desarrollan íntegramente de forma interna. Dependen de ecosistemas complejos de fabricantes de componentes, proveedores de software, proveedores de servicios en la nube, desarrolladores externos, socios OEM, integradores de sistemas y comunidades de código abierto.  Cada uno de ellos representa un posible riesgo de cumplimiento.

Un proveedor que no pueda proporcionar información sobre componentes de software, apoyar investigaciones de vulnerabilidades, mantener actualizaciones de seguridad, responder a solicitudes de evidencias o participar en procesos coordinados de divulgación puede crear desafíos importantes para los fabricantes posteriores de la cadena que intentan cumplir las obligaciones de la CRA.

Esto está llevando a las organizaciones a replantearse su visión de las relaciones con los proveedores.

Lo que antes era principalmente una cuestión de compras se está convirtiendo rápidamente en una cuestión de ciberseguridad, cumplimiento y gobernanza. A medida que se acercan las fechas de aplicación de la CRA, muchas organizaciones están descubriendo que la preparación de los proveedores puede ser uno de los factores más importantes que diferencian a los programas de cumplimiento exitosos de aquellos que tienen dificultades.

Perspectivas para ejecutivos

Históricamente, la gestión de proveedores se centraba en aspectos como el coste, la calidad, los plazos de entrega, la capacidad de fabricación y los niveles de servicio. Los requisitos de ciberseguridad solían limitarse a cláusulas contractuales, cuestionarios de seguridad o evaluaciones periódicas.

La CRA cambia esta ecuación. Las organizaciones ahora son responsables de comprender la postura de ciberseguridad de los productos que introducen en el mercado, incluso cuando las tecnologías críticas proceden de terceros.

Las empresas están empezando a plantear nuevas preguntas sobre sus proveedores:

  • ¿Pueden nuestros proveedores proporcionar SBOM actualizadas?
  • ¿Con qué rapidez pueden los proveedores notificarnos las vulnerabilidades?
  • ¿Mantienen los proveedores procesos de desarrollo seguro?
  • ¿Pueden los proveedores apoyar las investigaciones de incidentes?
  • ¿Proporcionarán los proveedores evidencias de cumplimiento cuando se soliciten?
  • ¿Pueden los proveedores cumplir compromisos de soporte a largo plazo?
  • ¿Qué ocurre si un proveedor deja de ofrecer un componente crítico?

Estas preguntas afectan directamente a la capacidad de una organización para cumplir obligaciones relacionadas con la gestión de vulnerabilidades, la notificación de incidentes, la documentación técnica, la transparencia del software, el soporte durante el ciclo de vida del producto y las consultas regulatorias. Todos ellos son requisitos críticos en virtud de la CRA.

La gobernanza de proveedores se está convirtiendo en una cuestión empresarial estratégica, en lugar de ser una actividad de compras. Las organizaciones reconocen cada vez más que la madurez de ciberseguridad de los proveedores afecta directamente al riesgo regulatorio, la confianza de los clientes y la resiliencia operativa.

Por qué está aumentando el riesgo de los proveedores con la CRA

Varios factores están contribuyendo a la creciente importancia de la preparación de los proveedores.

Los productos dependen de cadenas de suministro complejas

Los productos conectados actuales suelen incluir procesadores integrados, sistemas operativos, software de código abierto, bibliotecas de terceros, servicios en la nube, módulos de comunicaciones y componentes de seguridad.

Las organizaciones suelen depender de cientos de proveedores para dar soporte a un solo producto.  Esta cifra aumenta considerablemente en empresas con carteras de productos amplias y diversas. Cuanto mayor es el ecosistema, mayor es el desafío de cumplimiento.

La visibilidad se detiene en los límites de los proveedores

Las organizaciones consideran difícil gestionar y supervisar sus propios procesos de desarrollo.  La visibilidad del cumplimiento de ciberseguridad suele disminuir de forma significativa cuando intervienen tecnologías de terceros.  Sin transparencia por parte de los proveedores, los fabricantes tienen dificultades para responder preguntas críticas de cumplimiento.

Las vulnerabilidades se propagan a través de las cadenas de suministro

Una vulnerabilidad descubierta en un componente suministrado por un proveedor puede afectar rápidamente a varios productos. Cuando un proveedor informa de una vulnerabilidad, las organizaciones deben poder determinar qué productos están afectados, qué clientes pueden verse afectados, qué opciones de remediación existen y si son aplicables obligaciones de notificación regulatoria.

Esto requiere información precisa y oportuna de los proveedores.

La responsabilidad sobre el ciclo de vida se extiende más allá del lanzamiento del producto

La CRA hace hincapié en el soporte continuo y la gestión de vulnerabilidades, lo que exige a las organizaciones gestionar la ciberseguridad y el cumplimiento de los productos durante años después de su lanzamiento.  A su vez, las empresas trasladan estos requisitos a sus proveedores. En muchos casos, estos proveedores aún no están preparados para asumirlos.

Desafíos del mundo real

Gestionar vulnerabilidades procedentes de componentes de software de terceros siempre ha sido un desafío para los OEM. Con la CRA, este desafío ya no es solo una cuestión de seguridad, sino también un riesgo de cumplimiento. Cuando se divulga una vulnerabilidad crítica en un componente de software de terceros, los OEM que utilizan dicho componente contactan inmediatamente con el proveedor para solicitar aclaraciones. Si el proveedor no puede identificar con rapidez las versiones afectadas o proporcionar orientación sobre la remediación, los OEM quedan bloqueados y no pueden planificar una respuesta. Se pueden perder días mientras se recopila la información. El problema no es la capacidad de respuesta del fabricante, sino la falta de preparación del proveedor.

Los fabricantes de productos también pueden tener dificultades cuando se les pide demostrar la visibilidad de los componentes de software como parte de una revisión de preparación para la CRA.  Los fabricantes dependen de los proveedores para obtener SBOM completas de los componentes integrados en el producto.  Sin embargo, muchos proveedores todavía no están preparados para proporcionar SBOM completas y la documentación de respaldo necesaria para que los fabricantes desarrollen una comprensión completa de las dependencias de software. Esto crea un desafío de cumplimiento que se origina fuera de la organización.

Los OEM también tienen dificultades para adaptarse cuando un proveedor de tecnología interrumpe inesperadamente el soporte de un componente de software crítico. En muchos casos, el componente sin soporte sigue integrado en varios productos que todavía reciben soporte activo.  Los esfuerzos de remediación se vuelven costosos y disruptivos, y requieren importantes labores de rediseño para sustituir el componente.  Aunque el componente siga desempeñando la función requerida, la falta de soporte genera un riesgo de cumplimiento. El riesgo no surgió de una vulnerabilidad, sino de las decisiones del proveedor sobre el ciclo de vida.

Mejores prácticas para la gobernanza de proveedores en virtud de la CRA

Las organizaciones que abordan con éxito el riesgo de proveedores están adoptando varias estrategias comunes.

Establecer requisitos de ciberseguridad para los proveedores

Las organizaciones deben definir claramente sus expectativas en materia de divulgación de vulnerabilidades, disponibilidad de SBOM, actualizaciones de seguridad, notificaciones de incidentes y evidencias de cumplimiento. Siempre que sea posible, estos requisitos deben incorporarse a los acuerdos con proveedores.

Crear modelos de clasificación de riesgos de proveedores

No todos los proveedores conllevan el mismo nivel de riesgo.  Las organizaciones deben clasificar a los proveedores en función de la criticidad del producto, el impacto en la seguridad, los niveles de dependencia del software y la relevancia regulatoria.  Los proveedores de mayor riesgo deben estar sujetos a una supervisión más estricta.

Evaluar periódicamente la preparación de los proveedores

Las capacidades de ciberseguridad de los proveedores deben evaluarse periódicamente, no solo durante su incorporación. Las áreas de atención deben incluir la gestión de vulnerabilidades, las prácticas de desarrollo seguro, los procesos de respuesta a incidentes, la calidad de la documentación y los compromisos de soporte durante el ciclo de vida. Estas revisiones también deben incluir la gestión de cualquier vulnerabilidad o incidente cibernético descubierto o notificado.

Mejorar la visibilidad de la cadena de suministro de software

Las organizaciones deben mantener visibilidad sobre el uso que hacen de componentes suministrados por terceros. Esto debe abarcar las dependencias de software, la información de versiones y el estado del soporte. La visibilidad es la base de una gobernanza eficaz.

Planificar las interrupciones de proveedores

Las organizaciones deben establecer planes de contingencia para las interrupciones en la actividad de sus proveedores. Estas pueden derivarse de adquisiciones de proveedores, quiebras, discontinuación de productos o finalización del soporte. Estos planes aumentan la resiliencia y reducen el riesgo a largo plazo.

Errores comunes

Muchas organizaciones se encuentran con desafíos similares relacionados con los proveedores.

Suponer que los proveedores están preparados para la CRA

Muchos proveedores aún están desarrollando sus propios programas de cumplimiento. Algunos ni siquiera han comenzado todavía.  Las empresas deben validar la preparación de sus proveedores en lugar de darla por sentada.

Centrarse únicamente en los proveedores de primer nivel

Los riesgos críticos suelen originarse en niveles más profundos de la cadena de suministro. Las organizaciones deben evaluar las dependencias indirectas siempre que sea posible. Por ejemplo, un módulo de comunicaciones utilizado en un dispositivo IoT conectado tiene sus propias dependencias de cadena de suministro. El módulo puede incluir propiedad intelectual de hardware con licencia de uno o varios proveedores de hardware, software desarrollado internamente por el proveedor del módulo y componentes de software con licencia.  La visibilidad de la cadena de suministro debe extenderse a toda la lista de proveedores y subproveedores.

Tratar las evaluaciones de proveedores como ejercicios de compras

Las capacidades, los productos y los compromisos de soporte de los proveedores evolucionan con el tiempo.  Las empresas deben implementar calendarios de reevaluación periódica.

Pasar por alto las dependencias de código abierto

Los componentes de código abierto integrados en soluciones de proveedores pueden introducir desafíos adicionales de visibilidad y gobernanza y no deben pasarse por alto. Trataremos este tema con más detalle en nuestra próxima publicación del blog.

Acciones para OEM y proveedores de software

Las organizaciones que deseen reforzar la preparación de sus proveedores deben considerar las siguientes acciones.

Prioridades inmediatas

  1. Inventariar los proveedores críticos y las dependencias de software.
  2. Identificar a los proveedores que dan soporte a productos sujetos a los requisitos de la CRA.
  3. Evaluar la madurez de ciberseguridad de los proveedores.
  4. Revisar los procesos de divulgación de vulnerabilidades de los proveedores.
  5. Evaluar la disponibilidad y calidad de las SBOM de los proveedores.
  6. Documentar los compromisos de soporte de los proveedores.
  7. Crear requisitos de cumplimiento de seguridad para los proveedores y revisar los requisitos contractuales de los proveedores en relación con dichos requisitos.
  8. Establecer procedimientos de escalado para eventos de seguridad relacionados con proveedores.

Las organizaciones que comiencen estos esfuerzos con antelación reducirán significativamente los futuros riesgos de cumplimiento y operativos.

Cómo puede ayudar OmniTrust Certify

Gestionar las obligaciones de cumplimiento relacionadas con proveedores puede volverse rápidamente abrumador, especialmente para organizaciones con grandes carteras de productos y cadenas de suministro complejas de software y componentes. OmniTrust Certify ayuda a las organizaciones a comprender cómo las dependencias de terceros afectan a productos individuales, a su riesgo de ciberseguridad y a su conformidad regulatoria.

Certify permite a fabricantes y proveedores de software:

  • Crear un perfil dinámico del producto que incorpore componentes de proveedores, software, firmware y dependencias
  • Crear o importar SBOM e identificar dependencias de software de terceros
  • Vincular proveedores y componentes con los productos en los que se utilizan
  • Identificar vulnerabilidades y riesgos cibernéticos asociados con componentes de terceros
  • Mantener evidencias de seguridad, cumplimiento y ciclo de vida proporcionadas por los proveedores
  • Evaluar el impacto de los riesgos de proveedores frente a las normativas y estándares aplicables, incluida la CRA
  • Crear trazabilidad entre proveedores, componentes, vulnerabilidades, riesgos, controles, requisitos y evidencias
  • Reevaluar los productos afectados a medida que cambien los componentes de proveedores, las vulnerabilidades, el estado del soporte o los requisitos regulatorios

Al conectar las dependencias de proveedores con el mismo registro dinámico del producto utilizado para el riesgo cibernético y la conformidad regulatoria, Certify ayuda a las organizaciones a comprender no solo si un proveedor representa un riesgo, sino qué productos están afectados, qué significa eso para el cumplimiento y qué medidas deben tomarse.

Resumen

Una lección crítica que está surgiendo de los primeros esfuerzos de implementación de la CRA es que el cumplimiento ya no se limita a las fronteras de la organización. Su capacidad para demostrar la conformidad puede depender, en última instancia, de las organizaciones que proporcionan el software, los componentes, las tecnologías y los servicios utilizados en sus productos.

Los fabricantes y proveedores de software que tengan éxito en el marco de la CRA tendrán que extender la gobernanza de la ciberseguridad más allá de sus propias fronteras y a lo largo de toda la cadena de suministro del producto. Porque, en el mundo conectado de hoy, sus proveedores pueden convertirse en su mayor riesgo de cumplimiento.