Convergencia IT/OT y seguridad de planta: donde los departamentos deben unirse

La convergencia entre IT y OT no es un proyecto tecnológico, es una decisión de gobierno. Quien la trate como un asunto de cableado y firewalls habrá perdido antes de empezar, porque lo que falla en planta casi nunca es el equipo, sino la frontera invisible entre dos departamentos que se hablan poco y se respetan menos.

La práctica que observamos en industria y logística confirma una constante: la mayoría de los incidentes que paralizan una línea de producción no se explican por un atacante sofisticado, sino por la zona gris entre quien gestiona la red corporativa y quien gestiona el control industrial. En esa zona gris caben las actualizaciones que nadie aplica, los accesos remotos que nadie revisa y las cámaras de seguridad que están conectadas a la misma VLAN que el PLC porque, cuando se instalaron, no había con quién discutirlo. La fabricación, el almacén y el centro logístico se han llenado de sensores, robots, sistemas de videoanálisis y paneles de control que ya no pertenecen ni a la informática tradicional ni a la operación clásica. Pertenecen a un territorio nuevo que nadie reclamó a tiempo.

El malentendido fundacional

IT y OT crecieron en lógicas opuestas. La informática corporativa se construyó sobre la idea de confidencialidad: proteger datos, gestionar identidades, parchear sistemas, rotar contraseñas, asumir que cualquier dispositivo puede ser sustituido en cuestión de horas. La tecnología operacional, en cambio, se construyó sobre la idea de disponibilidad: que la línea no pare, que el horno no se enfríe, que la cinta no se detenga, que el SCADA siga leyendo el sensor incluso cuando el resto del mundo falla. Las dos lógicas tienen razón en su propio contexto. El problema aparece cuando el mismo edificio aloja las dos sin que nadie haya escrito cuál manda y cuándo.

Un técnico de IT formado en el paradigma corporativo aplica un parche urgente porque ha leído un boletín de INCIBE-CERT y considera, con razón desde su lógica, que la vulnerabilidad expuesta es inadmisible. El parche reinicia un servidor que también aloja, por una decisión histórica que nadie documentó, el historiador de procesos de la planta. La línea se detiene durante dos horas. La facturación del día se resiente. El jefe de planta, al día siguiente, prohíbe verbalmente que IT toque nada que afecte a la operación. A partir de ese momento, los parches dejan de aplicarse en una parte sustancial del entorno. Seis meses después, una variante de malware que aprovecha precisamente esa vulnerabilidad se mueve lateralmente desde la red de oficinas hasta el historiador. La línea se detiene durante setenta y dos horas, no dos.

El malentendido no es técnico. Es organizativo. Mientras IT y OT se traten como compartimentos con culturas separadas, cada incidente terminará siendo interpretado desde la cultura del que llega primero, no desde la lógica del riesgo real. Y la lógica del riesgo real, en una planta moderna, exige que ambos hablen el mismo idioma operativo antes de que ocurra el incidente, no después. El CCN-CERT lleva años publicando guías que insisten en este punto, y lo cierto es que las plantas que las leen son una minoría.

La planta como red, no como recinto

La planta industrial actual ya no se parece a la planta de hace quince años. No es un recinto cerrado con un control de accesos en la puerta y una sala de servidores en la oficina. Es una red distribuida en la que conviven controladores lógicos programables, robots de seguridad perimetral, cámaras con analítica embarcada, sensores ambientales, balanzas conectadas, lectores de matrícula en la entrada de camiones, sistemas de gestión de almacén, ERP corporativo, terminales en mano de operarios, dispositivos móviles del personal de mantenimiento, módems de proveedores externos que se conectan para hacer telemantenimiento de una máquina concreta y, cada vez más, sistemas de inteligencia artificial que analizan flujos de vídeo en tiempo real para detectar incidentes.

Esa red no tiene un perímetro nítido. Tiene capas. Y cada capa fue instalada por un proveedor distinto, en un momento distinto, con una documentación distinta, bajo una autoridad distinta. El proveedor del SCADA documentó su instalación al jefe de mantenimiento. El proveedor del ERP documentó la suya al CIO. El proveedor del sistema de videoanálisis documentó la suya al responsable de seguridad física. El proveedor del control de accesos documentó la suya al responsable de recursos humanos, porque la lectura de tarjetas alimenta el cómputo de horas. Cuatro responsables, cuatro documentaciones, cuatro contratos de mantenimiento, cuatro calendarios de actualización. Y una sola red física por la que todo eso circula.

En este contexto, la pregunta sobre quién es responsable de la seguridad de planta deja de tener una respuesta única. Pasa a tener varias respuestas parciales que, sumadas, no cubren el cien por cien del riesgo. Quedan zonas en las que ningún responsable se reconoce competente, y son precisamente esas zonas las que un atacante busca. La experiencia, también recogida en nuestra obra "BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad", muestra que la planta moderna debe ser leída como una red completa, con un mapa único, antes de que cualquier conversación sobre convergencia tenga sentido. Sin mapa, la convergencia es una palabra, no una práctica.

La frontera que ya no existe

Durante años se enseñó a los responsables de seguridad industrial el modelo Purdue como si fuera un dogma. Niveles claramente separados, cada uno con su función, y entre el nivel tres y el nivel cuatro una zona desmilitarizada que actuaba como esclusa entre el mundo corporativo y el mundo de control. El modelo sigue siendo útil como referencia conceptual. Como descripción de la realidad de una planta del año actual, se queda corto.

La razón es sencilla. La presión de negocio empuja constantemente a que datos que antes vivían exclusivamente en el nivel dos suban al nivel cuatro, y a veces más arriba, hasta sistemas en la nube que ningún responsable de OT habría aceptado hace una década. Se quiere visibilidad de producción en tiempo real para el comité de dirección. Se quiere mantenimiento predictivo basado en algoritmos que se entrenan con datos del proceso. Se quiere optimización energética, cálculo de huella de carbono, conexión con clientes que exigen trazabilidad. Cada uno de esos requerimientos perfora una capa del modelo Purdue. Y cada perforación se hace, casi siempre, sin que el responsable de seguridad industrial sea consultado a tiempo, porque la conversación se mantiene entre IT y la dirección de operaciones.

Resultado: la planta tiene una arquitectura formal en el diagrama y otra arquitectura real en el cable. Las dos no coinciden. Cuando un auditor externo, sea de una compañía privada o de un organismo público como el CNPIC en el caso de operadores críticos, llega para revisar la situación, encuentra esa brecha. El diagrama presentado en la primera reunión es limpio. La inspección física de los armarios, las VLAN y los cortafuegos cuenta una historia distinta. Esa historia distinta es la verdadera superficie de ataque. Aceptar que la frontera de antes ya no existe es el primer paso honesto de cualquier estrategia de convergencia. El segundo es decidir quién va a redibujarla y con qué autoridad.

El gobierno compartido como única arquitectura viable

La convergencia técnica sin convergencia de gobierno es una trampa. Se pueden unir redes, integrar SIEM, desplegar sondas que monitoricen tráfico industrial, contratar plataformas de detección específicas para protocolos como Modbus, Profinet o OPC UA. Si por encima de toda esa inversión no existe una autoridad capaz de tomar decisiones que afecten simultáneamente a IT y a OT, la inversión se gestionará en silos. Un silo nuevo, eso sí, con un nombre moderno, probablemente con la palabra ciberseguridad en el cargo, pero un silo al fin y al cabo.

El gobierno compartido exige tres elementos que rara vez están presentes desde el principio. Primero, un comité con representación equilibrada de IT, OT, seguridad física, mantenimiento y dirección de operaciones, que se reúna con cadencia regular y que tenga capacidad real de bloquear decisiones unilaterales de cualquiera de sus miembros. Segundo, un mapa único de activos que incluya tanto los servidores corporativos como los PLC, las cámaras, los sensores y los robots, con su responsable nominado y su ciclo de vida documentado. Tercero, un protocolo de escalada que defina, antes del incidente, quién decide qué cuando una alerta afecta simultáneamente a la disponibilidad de la línea y a la confidencialidad de la red corporativa. Sin ese protocolo, cada incidente se resolverá según el carácter de la persona que esté de guardia esa noche, no según el interés de la compañía.

La AEPD, en sus pronunciamientos sobre tratamientos en entornos industriales con captación de imagen, ha dejado claro que la dispersión de responsabilidades no exime de la obligación. Si la cámara de la planta capta a operarios y la grabación se almacena en un servidor cuya gestión nadie reclama, la responsabilidad sigue existiendo, simplemente está mal asignada. El mismo principio se aplica a la ciberseguridad de la planta. La responsabilidad existe siempre. Lo que cambia es si está nombrada o si está flotando. Cuando flota, el coste lo paga la compañía entera cuando llega el incidente.

Lo que un panel compartido cambia

Las plataformas que hoy permiten visualizar en un mismo panel los eventos de la red corporativa, los eventos de la red industrial y los eventos del entorno físico, incluidos los aportados por sistemas de videoanálisis y robótica de seguridad, no son una moda. Son la consecuencia natural de aceptar que la planta es una sola red. Y son útiles, pero solo si detrás del panel hay un equipo que sabe leerlo y una jerarquía que sabe actuar.

Un panel compartido cambia tres cosas concretas. La primera es la velocidad de correlación. Un movimiento físico no autorizado captado por un robot de patrulla en una zona de almacén, combinado con un intento de acceso al historiador de procesos desde la misma franja horaria, deja de ser dos incidentes desconectados y se convierte en un único patrón con un único nombre. La segunda es la calidad de la decisión. Quien ve los dos planos a la vez decide distinto del que ve solo uno. Lo que parecía un fallo de sensor en la red OT se entiende como sabotaje cuando se cruza con la imagen del perímetro. La tercera es la trazabilidad ante el regulador, el asegurador y el cliente. Aseguradoras agrupadas en Unespa están ajustando sus exigencias de cobertura para incidentes industriales, y el nivel de detalle que pueden aportar las plantas con paneles integrados marca diferencias tangibles en las primas y en las condiciones de renovación.

Lo que no cambia el panel, conviene decirlo, es la cultura. Una organización que no ha decidido quién manda en qué seguirá sin saberlo aunque tenga la mejor herramienta de visualización del mercado. El panel amplifica lo que ya hay. Amplifica una organización madura hasta hacerla extraordinaria, y amplifica una organización fragmentada hasta hacerla peligrosa, porque la fragmentación queda documentada en tiempo real y deja un rastro de decisiones contradictorias que cualquier auditor sabrá leer. La herramienta sirve. El gobierno la antecede.

El proveedor como riesgo y como palanca

Hay un actor que aparece tarde en casi todas las conversaciones sobre convergencia y que merece estar en el centro: el proveedor. La planta moderna tiene decenas de proveedores con acceso a parte de su red. El integrador del SCADA, el fabricante del robot, el mantenedor del sistema de control de accesos, el responsable del telemantenimiento de una máquina europea, el proveedor cloud del ERP, el especialista en analítica de vídeo. Cada uno de ellos es, técnicamente, un punto de entrada. Y cada uno de ellos tiene una política de seguridad propia que rara vez se audita con la profundidad que merece.

El operador de planta que aborda la convergencia sin abordar la gestión de proveedores está dejando el flanco más blando al descubierto. Las cifras cualitativas que se manejan en el sector indican que una proporción importante de los incidentes industriales graves de los últimos años entraron por la cadena de suministro, no por el perímetro propio. ENISA ha publicado análisis específicos sobre este vector. La conclusión es incómoda pero clara: la seguridad de una planta no es la seguridad de su red, es la seguridad de su red más la seguridad del eslabón más débil de su cadena de proveedores con acceso.

Esto convierte al proveedor en palanca, además de en riesgo. Quien gestiona bien a sus proveedores, exigiéndoles certificaciones, auditorías regulares, segmentación estricta de sus accesos y registros completos de cada intervención, está construyendo una capa de seguridad que ningún producto puede sustituir. Quien delega esa gestión en la confianza histórica con cada proveedor está heredando los problemas de seguridad de todos ellos sin saberlo. La diferencia entre las dos posturas no se ve en condiciones normales. Se ve el día en que un proveedor sufre un incidente y, desde su red, el movimiento lateral llega a sus clientes. Ese día, la planta que tenía segmentado el acceso lo detiene. La que no, no.

Lo que permanece

Lo que permanece, después de todos los argumentos técnicos, es una observación sencilla. La convergencia IT/OT no se resuelve con productos. Se resuelve con personas que tengan autoridad cruzada, con un mapa único de activos, con un protocolo de escalada escrito antes del incidente, y con una gestión de proveedores que reconozca el riesgo donde está. Todo lo demás, los paneles, los sensores, las sondas, los robots, son consecuencia de esas cuatro decisiones, no sustituto.

La planta que toma esas decisiones temprano paga un coste de coordinación elevado durante los primeros meses y un coste residual bajo durante los años siguientes. La planta que las pospone paga un coste residual bajo al principio y un coste catastrófico el día que el incidente llega. La asimetría entre ambos caminos es la razón por la que la convergencia merece tratarse como decisión de dirección, no como proyecto de departamento.

Para quien quiera dar el primer paso sin compromiso, una conversación confidencial de sesenta minutos con la dirección suele bastar para situar el punto de partida. Quien necesite un diagnóstico estructurado puede recorrer una auditoría de tres a cinco días, con entregables definidos por escrito y sin obligación posterior. Quien quiera ir más lejos puede acordar un piloto de noventa días sobre un emplazamiento concreto, con un criterio de éxito fijado antes de empezar. Los tres caminos están descritos con detalle en el libro "BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad", y los tres conducen al mismo punto: una planta cuya seguridad ya no depende de quién esté de guardia esa noche.

Preguntas frecuentes

¿Qué es la convergencia?

La convergencia IT/OT es la integración operativa y de gobierno entre la informática corporativa y la tecnología operacional de planta. No se reduce a conectar redes, aunque ese sea su aspecto más visible. Implica un mapa único de activos, una autoridad compartida capaz de tomar decisiones que afecten a ambos dominios, protocolos de escalada definidos antes del incidente y una gestión coordinada de proveedores. Su objetivo no es unificar tecnologías, sino eliminar las zonas grises entre departamentos en las que el riesgo se acumula sin responsable nombrado.

¿Quién es responsable?

La responsabilidad debe ser nominal y compartida, no difusa. En la práctica funcionan los modelos con un responsable de seguridad industrial que reporta al comité de dirección y que coordina, no subordina, al CIO, al jefe de mantenimiento, al responsable de seguridad física y al de operaciones. La AEPD y el CNPIC, cada uno en su ámbito, insisten en que la dispersión de competencias no diluye la obligación. Si nadie está nombrado para un activo, alguien lo está por defecto, normalmente la dirección general, que descubre su responsabilidad cuando ya es tarde.

¿Qué herramientas la unen?

Las plataformas que integran SIEM corporativo con sondas específicas de protocolos industriales como Modbus, Profinet u OPC UA, combinadas con sistemas de gestión de eventos físicos provenientes de videoanálisis, control de accesos y robótica de seguridad, son hoy la base técnica de la convergencia. Sin embargo, la herramienta sin gobierno amplifica el desorden previo. Lo recomendable es definir primero el modelo de autoridad y el mapa de activos, y solo después elegir la plataforma que ejecute esas decisiones. ENISA y el CCN-CERT publican criterios útiles para esa elección.

¿Qué reglas de escalada?

Las reglas de escalada deben estar escritas antes del incidente, no improvisadas durante él. Una estructura mínima incluye: definición de niveles de severidad combinando impacto en disponibilidad operacional e impacto en confidencialidad o integridad de datos; designación nominal del decisor para cada nivel; tiempos máximos de respuesta por nivel; criterios para detener una línea de producción ante una alerta de ciberseguridad; protocolos de comunicación con reguladores como INCIBE-CERT o CNPIC cuando proceda; y un registro auditable de cada decisión tomada, con su justificación, accesible posteriormente para análisis y para defensa ante asegurador o regulador.