Defensa de infraestructuras críticas en la Industria 4.0: ciberseguridad avanzada en entornos OT, CPS y sistemas conectados
14 de mayo de 2026
Cuando se analizan los ciberataques más significativos de la última década, emerge un patrón que merece atención: en la mayoría de los casos, el atacante no accedió directamente a su objetivo final. Entró a través de alguien en quien ese objetivo confiaba.
SolarWinds. Kaseya. Target. MOVEit. 3CX. En todos estos incidentes el vector de entrada fue un proveedor. Y en todos ellos las organizaciones afectadas contaban con políticas de seguridad, procesos de evaluación de terceros y, en muchos casos, certificaciones vigentes.
Esto no significa que esos controles sean inútiles. Significa que proteger la cadena de suministro requiere algo más que documentar el riesgo: requiere gestionarlo de forma operativa y continua. Hay una distancia real entre ambas cosas, y este artículo trata exactamente de eso.
Qué es la seguridad en la cadena de suministro (y qué no es)
La seguridad en la cadena de suministro —supply chain security— agrupa todos los controles, procesos y tecnologías destinados a proteger los sistemas, datos y operaciones de una organización frente a riesgos que llegan a través de terceros con acceso a su entorno.
Ese tercero puede ser cualquiera de estos perfiles, todos ellos habituales:
- Un proveedor de software que distribuye actualizaciones automáticas en los entornos de sus clientes.
- Un integrador tecnológico con acceso a la red interna para implementar o mantener sistemas.
- Un MSP (proveedor de servicios gestionados) que administra infraestructura crítica de forma remota.
- Una empresa de mantenimiento con acceso remoto a instalaciones industriales, OT o sistemas de climatización.
- Un partner comercial con integración directa vía API a sistemas de negocio o datos sensibles.
La diferencia crítica respecto a la seguridad interna es una sola: el control. Cuando el riesgo viene de dentro, la organización tiene herramientas para detectarlo, contenerlo y responder. Cuando viene de un tercero, esa visibilidad en la mayoría de organizaciones simplemente no existe.
Lo que no es la seguridad de la cadena de suministro: no es solo revisar si el proveedor tiene ISO 27001. No es solo enviar un cuestionario una vez al año. Y no es solo firmar un contrato con cláusulas de seguridad. Volveremos a esto.
Los ataques que convierten la teoría en urgencia
SolarWinds (2020): el ataque que redefinió lo que significa confiar en un proveedor
En diciembre de 2020 se descubrió que el software Orion de SolarWinds, una plataforma de monitorización de red usada por más de 18.000 organizaciones —incluyendo nueve agencias federales de Estados Unidos— había sido comprometido meses antes. Los atacantes insertaron código malicioso directamente en el proceso de compilación del software, de modo que las actualizaciones legítimas distribuían el payload a todos los clientes de forma automática y sin ninguna señal de alerta.
El vector de entrada no fue una vulnerabilidad técnica explotada en producción. Fue el proceso de construcción y distribución de software de un proveedor en el que miles de organizaciones depositaban su confianza. Las víctimas recibieron el ataque a través de una actualización que tenían razones objetivas para instalar.
Kaseya (2021): 1.500 empresas comprometidas en menos de dos horas
El grupo REvil explotó una vulnerabilidad de día cero en Kaseya VSA, herramienta de administración remota utilizada por cientos de MSP. El ataque no apuntó a los clientes finales: apuntó a los proveedores que gestionaban su infraestructura. El resultado fue la distribución automatizada de ransomware a entre 800 y 1.500 organizaciones en todo el mundo en un período de horas.
La lección es matemática: en lugar de comprometer 1.500 objetivos por separado, el atacante comprometió un punto en la cadena de distribución y dejó que el sistema hiciera el resto. El retorno sobre la inversión de ese ataque, en términos de impacto por esfuerzo, es difícil de superar.
Target (2013): 40 millones de tarjetas comprometidas por un proveedor de climatización
El caso Target sigue siendo uno de los más citados porque ilustra algo que muchas organizaciones prefieren no ver: el vector de entrada fue un proveedor de servicios de mantenimiento de instalaciones. Los atacantes obtuvieron sus credenciales, accedieron a la red corporativa de Target a través de ese acceso insuficientemente segmentado, se movieron lateralmente hasta los sistemas de punto de venta e instalaron malware que capturó datos de 40 millones de tarjetas durante semanas.
No fue un ataque técnicamente sofisticado. Fue un acceso de terceros sin los controles adecuados, explotado con paciencia y método.
MOVEit (2023): el ataque que las víctimas ni sabían que podía llegarles
En 2023, el grupo Cl0p explotó una vulnerabilidad de día cero en MOVEit Transfer, software de transferencia de archivos usado por miles de organizaciones. El resultado fue la extracción de datos de más de 2.500 entidades en todo el mundo. Muchas de las víctimas no usaban MOVEit directamente: lo usaban sus proveedores de externalización de procesos de negocio, y los datos afectados eran suyos.
Este último matiz es importante: en la cadena de suministro moderna, el riesgo no se limita a los proveedores directos. Se extiende a los proveedores de los proveedores. La superficie de ataque real es más grande de lo que cualquier inventario convencional recoge.
El fallo estructural: el modelo de confianza implícita
Analizar estos casos de forma aislada lleva a conclusiones incorrectas: “necesitamos mejores cuestionarios”, “hay que exigir más certificaciones”, “las auditorías deben ser más frecuentes”. El sector lleva una década repitiendo estas respuestas. Y los ataques a la cadena de suministro siguen creciendo.
El problema no es la falta de controles. Es que los controles que se implementan miden la apariencia de seguridad, no la seguridad real.
Un cuestionario de vendor risk assessment mide la capacidad de una organización para responder cuestionarios. Una certificación ISO 27001 garantiza que existe un sistema de gestión documentado y auditado. Ninguna de las dos garantiza que, en este momento, un atacante no tenga acceso activo a los sistemas del cliente a través de las credenciales de ese proveedor certificado.
¿Por qué persiste este modelo? Porque los incentivos de todos los actores apuntan en la misma dirección equivocada.
El proveedor quiere la certificación como requisito de acceso al mercado, no como compromiso genuino con la seguridad. La obtiene, la renueva anualmente con el mínimo esfuerzo y sigue operando igual.
La empresa cliente quiere reducir su exposición regulatoria y legal, no necesariamente su riesgo real. Si puede demostrar que realizó el proceso de evaluación y que el proveedor tenía certificación en regla, su responsabilidad se limita significativamente en caso de incidente.
El regulador diseña normas auditables, no necesariamente efectivas. Lo que no se puede medir en un formulario no existe en un marco regulatorio.
El resultado es un ecosistema perfectamente optimizado para documentar el riesgo, no para eliminarlo.
Los vectores que más se subestiman en la práctica
Accesos persistentes sin revisión activa
El patrón más frecuente: se crea una cuenta de acceso para un proveedor, se conceden los privilegios necesarios para el proyecto, el proyecto termina. El acceso permanece activo. Nadie lo revoca porque nadie tiene un proceso sistemático para hacerlo.
En organizaciones con decenas o cientos de proveedores activos, el inventario de accesos externos activos raramente coincide con la realidad. Hay accesos de proyectos terminados, de proveedores que han cambiado de personal, de integraciones que ya no se usan. Cada uno de esos accesos es una puerta abierta que nadie está vigilando.
Movimiento lateral desde accesos VPN mal segmentados
Cuando un proveedor accede mediante VPN corporativa tradicional obtiene conectividad con un segmento de red que, en muchos casos, es más amplio de lo estrictamente necesario. Si ese acceso es comprometido, el atacante no accede solo al sistema para el que el proveedor tenía autorización: accede a todo lo que ese segmento de red puede alcanzar.
El movimiento lateral desde accesos de terceros mal segmentados es uno de los vectores más frecuentes en incidentes contra infraestructuras críticas. No porque sea difícil de prevenir, sino porque la segmentación granular de accesos externos raramente se implementa con el rigor que se aplica a la red interna.
Dependencias de software no inventariadas
Entre el 80 y el 90% de cualquier aplicación moderna está compuesta por código de terceros: librerías open source, componentes comerciales, SDKs, frameworks, APIs de servicios externos. La organización raramente tiene un inventario completo y actualizado de estas dependencias —lo que se conoce como SBOM, Software Bill of Materials—, y menos aún un proceso automatizado para detectar cuándo alguna de ellas introduce una vulnerabilidad conocida.
Log4Shell en 2021 demostró el impacto real de este problema: una vulnerabilidad crítica en una librería de logging de Java afectó a cientos de miles de sistemas en todo el mundo, muchos de cuyos administradores no sabían siquiera que la librería estaba presente en su stack.
Tokens de API con privilegios excesivos y sin rotación
Las integraciones API entre organizaciones crean canales de comunicación directa entre sistemas que en muchos casos operan con tokens de autenticación de larga duración, sin rotación, sin monitorización de anomalías en el patrón de uso y con permisos más amplios de lo necesario para la función que realizan. Un token comprometido puede proporcionar acceso continuo durante meses sin que ninguna alerta se dispare.
Qué significa realmente controlar el acceso de terceros
El cambio necesario no es técnico en origen. Es conceptual: pasar de confiar en que el proveedor es seguro a verificar que el proveedor actúa de forma segura. Del control documental al control operativo.
En la práctica, esto se articula en cuatro principios que deben ser no negociables:
Principio 1: Ningún acceso permanente — Just-in-Time como estándar
El acceso de un tercero debe existir únicamente durante el tiempo en que es necesario para una tarea concreta. Se solicita, se aprueba con los privilegios específicos que requiere esa tarea, se concede con expiración automática y se revoca al finalizar sin intervención manual.
No hay credenciales persistentes. No hay canales permanentemente abiertos. Cada sesión de acceso es un evento controlado, no un estado indefinido.
Este principio, por sí solo, elimina una fracción muy significativa de la superficie de ataque: todos los accesos activos que ya no son necesarios.
Principio 2: Acceso intermediado — el sistema real nunca queda expuesto directamente
En lugar de conceder al proveedor acceso directo al sistema de destino, la conexión se establece a través de un entorno controlado que actúa como punto de intermediación. El proveedor trabaja dentro de ese entorno; el sistema de producción queda aislado de la conexión externa.
Si el dispositivo del proveedor está comprometido, el atacante accede al entorno intermediado. El sistema real permanece protegido por esa capa de aislamiento.
Principio 3: Microsegmentación — el acceso a A no implica visibilidad sobre B
El acceso de cada proveedor debe limitarse estrictamente al sistema, los datos y las operaciones que necesita para su función específica, sin conectividad con el resto de la infraestructura. La microsegmentación garantiza que un acceso comprometido no pueda convertirse en punto de partida para un movimiento lateral hacia sistemas críticos.
Principio 4: Registro completo de sesiones — trazabilidad que va más allá del log de eventos
Un log de eventos registra qué ocurrió: usuario X accedió al sistema Y a las 14:32. Un registro de sesión muestra cómo ocurrió: los comandos ejecutados, los archivos accedidos, los datos transferidos, cada acción realizada y en qué orden.
Grabar las sesiones de acceso de terceros con capacidad de reproducción, búsqueda y análisis transforma la trazabilidad en una herramienta operativa real: permite detectar comportamientos anómalos en tiempo real, investigar incidentes con precisión forense y demostrar ante reguladores el nivel efectivo de control sobre los accesos externos.
Cómo se ve esto en la práctica: un escenario real
Un técnico de un proveedor externo necesita acceder a un sistema SCADA en una planta industrial para actualizar firmware de un controlador.
Modelo habitual con VPN: Usa credenciales que lleva semanas sin utilizar. Obtiene conectividad con un segmento de red que incluye más sistemas de los que necesita. Hace el trabajo. Nadie monitoriza la sesión en detalle. El acceso sigue activo cuando termina la jornada, y al día siguiente, y la semana siguiente.
Modelo de control operativo: El técnico solicita acceso para esa tarea específica. Un responsable de la organización lo aprueba para un sistema concreto, con una ventana de tiempo definida. El acceso se concede a través de un entorno intermediado que solo le permite ver ese sistema. La sesión se graba en su totalidad. Si ejecuta un comando fuera del patrón esperado para esa tarea, se genera una alerta. Al cerrar la ventana de tiempo, el acceso se revoca automáticamente.
La diferencia en exposición al riesgo entre ambos modelos no es marginal. En un entorno donde un incidente en un sistema OT puede tener consecuencias operativas o físicas, esa diferencia puede ser crítica.
El marco regulatorio: NIS2 y DORA ya no son opcionales
Las principales normativas de ciberseguridad vigentes en Europa han incorporado la seguridad de la cadena de suministro como requisito explícito con consecuencias legales y económicas reales.
NIS2 exige a las organizaciones en sectores esenciales e importantes implementar medidas activas para gestionar el riesgo de sus proveedores: evaluar su postura de seguridad antes de establecer relaciones, verificar sus prácticas y controlar los accesos que se les conceden. El régimen sancionador alcanza los 10 millones de euros o el 2% de la facturación global anual.
DORA, en vigor desde enero de 2025 para el sector financiero, impone obligaciones específicas sobre la gestión del riesgo de proveedores tecnológicos críticos: inventario de dependencias, evaluación del riesgo de concentración, trazabilidad de los accesos y planes de contingencia documentados. El nivel de exigencia sobre los proveedores de servicios TIC considerados críticos es sustancialmente mayor que cualquier marco anterior.
ENS (Esquema Nacional de Seguridad), en su actualización de 2022, establece controles concretos sobre la gestión de proveedores en el ámbito de la Administración Pública española, con énfasis específico en el control de accesos externos y la trazabilidad en sistemas de categoría media y alta.
La novedad más relevante no es solo que estas normativas exigen más controles. Es que exigen que esos controles sean verificables y demostrables. El cuestionario anual sin monitorización real no va a cumplir los requisitos de supervisión de NIS2 cuando llegue el momento de la inspección.
Conclusión: el eslabón más débil eres tú si no controlas tu cadena
Los atacantes han llegado a una conclusión que el sector tarda en asumir: es más eficiente comprometer a un proveedor con controles débiles que atacar directamente a una organización bien protegida. El resultado es el mismo —acceso a los sistemas del objetivo real— pero el camino es exponencialmente más fácil.
Mientras las organizaciones invierten en proteger su perímetro interno, los atacantes lo rodean. Y lo rodean precisamente por donde el control es más laxo: el acceso de terceros.
La solución no requiere sustituir toda la arquitectura de seguridad. Requiere aplicar tres principios donde actualmente hay un vacío de control: ningún acceso persistente, ningún acceso sin trazabilidad completa, ningún acceso sin segmentación granular.
Proteger la cadena de suministro no es proteger a los proveedores. Es proteger el propio negocio frente al vector de ataque que más ha crecido en la última década, y que más va a crecer en la siguiente.
¿Quieres ver cómo Cosmikal implementa control de accesos de terceros con trazabilidad completa, sin VPN tradicionales y facilitando el cumplimiento de NIS2 y DORA?
Preguntas frecuentes sobre seguridad en la cadena de suministro
¿Qué es un ataque a la cadena de suministro? Un ataque a la cadena de suministro es aquel en el que el atacante no compromete directamente a su objetivo final, sino a un proveedor, partner o componente de software con acceso o integración en los sistemas del objetivo. El proveedor comprometido actúa como vector de entrada hacia la víctima real.
¿Cuáles son los ejemplos más relevantes de ataques a la cadena de suministro? Los casos más significativos son SolarWinds (2020), donde código malicioso fue distribuido a través de actualizaciones legítimas de software; Kaseya (2021), donde ransomware afectó a 1.500 empresas a través de su proveedor de servicios gestionados; y MOVEit (2023), que afectó a más de 2.500 organizaciones a través de una vulnerabilidad en software de transferencia de archivos.
¿Qué normativas europeas regulan la seguridad de terceros? Las principales son NIS2, que aplica a sectores esenciales e importantes; DORA, específica para el sector financiero y sus proveedores tecnológicos; y el Esquema Nacional de Seguridad (ENS) en el ámbito de la Administración Pública española. Las tres exigen controles activos sobre el acceso de terceros y trazabilidad demostrable.
¿Qué es el acceso Just-in-Time para proveedores y por qué es importante? El acceso Just-in-Time (JIT) es un modelo en el que los privilegios se conceden únicamente cuando son necesarios para una tarea específica y se revocan automáticamente al finalizar, sin dejar accesos persistentes. Elimina uno de los principales vectores de riesgo en la cadena de suministro: los accesos activos que ya no tienen justificación operativa.
¿Por qué no es suficiente una VPN para controlar el acceso de terceros? Una VPN proporciona cifrado en el canal de comunicación, pero no controla qué hace el proveedor una vez conectado, no limita su visibilidad a sistemas específicos, no registra la actividad con granularidad de sesión y no revoca el acceso de forma automática. Es una medida de transporte, no un mecanismo de control de accesos.
¿Qué es un SBOM y por qué es relevante en supply chain security? Un SBOM (Software Bill of Materials) es un inventario completo de todos los componentes de software de terceros presentes en una aplicación o sistema. Permite identificar qué dependencias externas están en uso y detectar cuándo alguna de ellas introduce una vulnerabilidad conocida, algo crítico para gestionar el riesgo de la cadena de suministro de software.
Contenido relacionado
