Ciberseguridad en la cadena de suministro: cómo controlar los riesgos de tus proveedores

Muchos incidentes graves pueden tener su origen en proveedores, servicios externos o dependencias tecnológicas. Un proveedor de software con credenciales mal gestionadas, un partner de mantenimiento con acceso remoto permanente, un servicio cloud sin segmentación adecuada. Cuando se habla de ciberseguridad de la cadena de suministro, se habla precisamente de eso: de la exposición que tu organización asume cada vez que delega una función, un dato o un acceso en alguien que no eres tú.

Para responsables de IT, CISO y dirección de operaciones, el reto ya no es solo blindar los sistemas propios. Es tener una fotografía clara, actualizada y auditable de qué terceros tocan qué activos, con qué controles y qué pasa si uno de ellos cae o sufre una brecha. Este artículo aterriza esa realidad en controles concretos, marcos de referencia y procesos replicables.

La seguridad de la cadena de suministro engloba todas las prácticas, controles y procesos destinados a reducir el riesgo que entra en tu organización a través de proveedores, subcontratistas, integradores, servicios gestionados y herramientas SaaS. En inglés se conoce como supply chain security y, en su dimensión digital, se solapa con lo que los marcos anglosajones llaman third party risk management o gestión de riesgos de terceros.

El problema es cualitativamente distinto al de la seguridad interna por varias razones:

• Falta de visibilidad directa. No gestionas los sistemas del proveedor, no ves sus logs y, en muchos casos, ni siquiera conoces sus subcontratistas (los llamados fourth parties).
• Superficie de ataque heredada. Cada integración, token OAuth, API o acceso VPN de un tercero puede ampliar la superficie de ataque y debe gestionarse de acuerdo con su nivel de riesgo.
• Dependencias críticas invisibles. Servicios aparentemente secundarios (un plugin, un conector, una herramienta de analítica) pueden tener permisos sobre datos sensibles sin que nadie lo haya revisado.
• Marco regulatorio creciente. Normativas como NIS2, DORA o el ENS, cuando resultan aplicables, refuerzan las obligaciones relacionadas con la gestión y documentación del riesgo de terceros.

Entender estas particularidades es el primer paso para dejar de tratar el riesgo de proveedores como un trámite contractual y empezar a tratarlo como lo que es: una línea más del plan de seguridad, con responsables, KPIs y evidencias.

Antes de aplicar controles, conviene enumerar los riesgos de ciberseguridad de proveedores más habituales. No todos aplican a todos los terceros, pero cualquier evaluación seria debería recorrerlos como checklist mínimo.

Se encuentran entre los riesgos más habituales y pueden generar un impacto elevado. Incluyen cuentas de proveedor con permisos excesivos, VPNs permanentes sin MFA, credenciales compartidas entre técnicos del partner, tokens de API sin rotación y accesos remotos que sobreviven al fin del contrato. Un gran porcentaje de brechas con origen externo empieza aquí, muchas veces precedidas de una campaña de phishing dirigida al propio proveedor.

Cuando un tercero procesa, almacena o transmite información de tu organización, debe cumplir las obligaciones legales, contractuales y de seguridad que correspondan a su papel en el tratamiento y protección de la información. Aquí entran las fugas por configuraciones incorrectas de almacenamiento cloud, los backups no cifrados, las copias de datos en entornos de desarrollo del proveedor y la falta de borrado seguro al finalizar la relación.

Trabajar la seguridad del dato con los proveedores debe ir más allá de una cláusula en el contrato.

La gestión de vulnerabilidades debe contemplar explícitamente el inventario de software externo. Los ataques tipo SolarWinds o Kaseya enseñaron que un proveedor comprometido puede distribuir código malicioso a cientos de clientes a través de una actualización legítima. Esto incluye librerías de terceros, dependencias open source, plugins de CMS, firmware de dispositivos y pipelines de CI/CD.

Si tu ERP, tu correo, tu facturación electrónica o tu plataforma de atención al cliente dependen de un único proveedor sin plan de contingencia, el riesgo cibernético se convierte en riesgo operativo puro. Un ransomware en tu partner puede dejarte sin operar durante días aunque tus sistemas estén intactos.

Aunque un incidente se haya originado en un tercero, tu organización no queda automáticamente exenta de responsabilidad: deberás analizar tus obligaciones, sin perjuicio de las responsabilidades que también puedan corresponder al proveedor.

Un proceso maduro de evaluación de proveedores se construye en fases claras y se mantiene vivo durante toda la relación. No es un cuestionario que se rellena una vez y se archiva.

No todos los proveedores merecen el mismo esfuerzo. Una posible clasificación sería:

• Tipo de información que tratan: pública, interna, confidencial, datos personales o categorías especiales de datos personales.
• Nivel de acceso a tus sistemas: sin acceso, acceso puntual, acceso continuo, acceso privilegiado.
• Impacto en continuidad si fallan: bajo, medio, alto, crítico.
• Volumen de la relación y profundidad de la integración técnica.

Con esta matriz obtienes una segmentación en, por ejemplo, cuatro niveles. Los proveedores de nivel crítico recibirán evaluación profunda y auditoría recurrente. Los proveedores de nivel bajo pueden someterse a una evaluación simplificada y a revisiones proporcionales al riesgo.

Para los proveedores que pasan el filtro de criticidad, la evaluación previa a la contratación debería incluir:

• Cuestionario de seguridad propio o basado en instrumentos reconocidos, como CAIQ o SIG, y alineado con referencias como ISO/IEC 27001 o el ENS cuando resulte aplicable.
• Revisión de certificaciones, declaraciones e informes de aseguramiento vigentes, como ISO/IEC 27001, conformidad con el ENS o informes SOC 2. ISO 28000:2022, especialmente útil para gestionar de manera integral la seguridad y resiliencia de la cadena de suministro.
• Comprobación de pólizas de ciberriesgo y cláusulas de responsabilidad.
• Revisión de política de gestión de incidentes y plazos de notificación.
• Validación técnica puntual cuando el riesgo lo justifique (pentest, revisión de arquitectura, revisión de evidencias).

El contrato debe trasladar obligaciones concretas, no principios genéricos: obligación de notificar incidentes en un plazo determinado, derecho a auditar, obligaciones de borrado, requisitos de MFA, condiciones y mecanismos de autorización o información previa para la subcontratación, especialmente en servicios críticos o que impliquen tratamiento de datos, y requisitos sobre ubicación geográfica de los datos.

El alta operativa de un proveedor es un momento crítico que suele descuidarse. Debe formalizarse: creación de cuentas con mínimo privilegio, segregación de red, inventariado del acceso, documentación de la integración y alta en los sistemas de monitorización.

Si usas Microsoft 365 como entorno colaborativo, los permisos sobre SharePoint, Teams y aplicaciones conectadas deben revisarse pieza a pieza desde el primer día; aquí Microsoft 365 para empresas ofrece controles granulares que conviene aprovechar desde el minuto uno.

El control de ciberseguridad en la cadena de suministro se articula en dos planos: el técnico (lo que haces en tus sistemas) y el organizativo (lo que haces en tus procesos). Ambos son necesarios y se refuerzan mutuamente.

• Gestión de identidades y accesos federada. Cuentas nominales por técnico del proveedor, MFA obligatorio, acceso Just-In-Time, revocación automatizada.
• Segmentación de red. Los accesos de terceros se enrutan a segmentos aislados con reglas explícitas. Nada de VPNs planas con acceso completo.
• Monitorización dedicada. Logs específicos para sesiones de proveedor, alertas por comportamiento anómalo, grabación de sesiones privilegiadas cuando aplique.
• Gestión de vulnerabilidades extendida. Inventario de software de terceros instalado en tu entorno, con revisión periódica. Más contexto sobre cómo trabajar esto en el detalle de gestión de vulnerabilidades.
• Cifrado de las comunicaciones en tránsito y de los datos almacenados; cuando el caso de uso lo permita, cifrado de extremo a extremo.
• DLP y clasificación del dato para detectar fugas hacia entornos de proveedor no autorizados.
• Hardening de integraciones: revisión de scopes OAuth, rotación de API keys, revisión de webhooks.

• Comité de riesgo de terceros con representación de IT, seguridad, legal, compras y negocio.
• Procedimiento de alta, revisión y baja documentado y con responsables claros.
• Plan de respuesta a incidentes conjunto con los proveedores críticos, incluyendo contactos 24/7 y simulacros periódicos.
• Formación cruzada: tanto a tu equipo (para que sepa identificar riesgos) como al del proveedor (para alinear criterios).
• Revisión periódica de la relación: no basta con la evaluación inicial. Reevaluación periódica basada en el riesgo —habitualmente anual en proveedores críticos— y siempre que se produzca un cambio relevante o un incidente.

Trabajar la ciberseguridad de proveedores sin apoyarse en marcos reconocidos obliga a reinventar la rueda. Estos son los más útiles en el contexto español y europeo:

• ISO/IEC 27001:2022, especialmente los controles 5.19 a 5.23 de su Anexo A, desarrollados con mayor detalle en ISO/IEC 27002:2022.
• ISO 28000, orientada a seguridad en la cadena de suministro en sentido amplio (incluye seguridad física y operativa, no solo digital).
• NIS2, que amplía el alcance de obligaciones de ciberseguridad y exige explícitamente gestión de riesgos de terceros para entidades esenciales e importantes.
• DORA para el sector financiero, con requisitos muy concretos sobre proveedores TIC críticos.
• Esquema Nacional de Seguridad (ENS) para proveedores que trabajan con administraciones públicas.
• NIST SP 800-161, guía de referencia para C-SCRM (Cyber Supply Chain Risk Management).

La clave no es certificarse por certificarse, sino usar estos marcos como estructura de los procesos internos y como lenguaje común con auditores, clientes y proveedores.

Lo que no se documenta, no existe. Un programa de gestión de riesgos de terceros debe producir evidencias auditables en todo momento: cuestionarios firmados, matrices de criticidad versionadas, registros de accesos revisados, actas del comité, resultados de pentests, SLAs de parcheado cumplidos o incumplidos, notificaciones de incidentes recibidas y gestionadas.

Estas evidencias cumplen tres funciones. Primero, defensiva: ante un incidente, Permite acreditar la diligencia aplicada y puede resultar relevante al evaluar responsabilidades, cumplimiento y medidas correctoras. Segundo, operativa: permite tomar decisiones basadas en datos sobre qué proveedores renovar, cuáles sustituir y dónde invertir en controles adicionales. Tercero, de mejora continua: analizar la serie histórica revela patrones (proveedores de qué sector fallan más, qué controles tienen mayor retorno, dónde aparecen reincidencias).

La auditoría de seguridad periódica, tanto interna como externa, ayuda a comprobar el diseño y la aplicación de los controles e identificar desviaciones o áreas de mejora.