Convergencia IT/OT: Guía de Supervivencia para Líderes Industriales

La convergencia IT/OT debe crear intercambios de datos gobernados, no una red plana. IT puede aportar identidad, registros, analítica y gestión de servicios mientras OT conserva la autoridad sobre los procesos físicos, las restricciones de seguridad y las ventanas productivas. NIST SP 800-82 Rev. 3 considera el rendimiento, la confiabilidad y la seguridad requisitos propios de OT; por eso, las prácticas empresariales deben adaptarse, no copiarse sin cambios.

Este es un modelo operativo neutral respecto de proveedores, no un diseño de referencia para toda planta. No promete Zero Trust, cumplimiento, producción ininterrumpida ni eliminación del riesgo. Cada sitio aún necesita analizar peligros del proceso y riesgos de ciberseguridad, validar la recuperación y aprobar cambios mediante su proceso de gestión del cambio.

Empezar por la responsabilidad, no por los equipos

La convergencia se frena cuando cualquiera puede pedir una conexión, pero nadie responde por sus consecuencias. Conviene usar un RACI pequeño para cada servicio que cruza límites:

Decisión	Accountable	Responsible	Consulted
Impacto en proceso y seguridad	Gerente de planta	Ingeniero de control	Seguridad, operaciones
Diseño de zonas y conductos	Responsable de seguridad OT	Ingeniero de red	Seguridad IT, integrador
Propósito y retención de datos	Dueño empresarial del dato	Dueño de aplicación	Dueño OT, legal/privacidad
Ventana de cambio y reversión	Dueño del activo OT	Responsable de mantenimiento	Proveedor, producción

El dueño del activo acepta el riesgo operativo. Seguridad IT define controles empresariales, pero no parchea ni escanea controladores unilateralmente. Los proveedores reciben tareas acotadas y acceso temporal, nunca propiedad permanente. Hay que registrar la autoridad de escalamiento y quién puede terminar una sesión o iniciar la reversión.

Separar zonas y conductos

ISA/IEC 62443 usa zonas para agrupar activos con requisitos de seguridad comunes y conductos para controlar la comunicación entre zonas. Ese modelo resulta más útil que una etiqueta como “OT confiable”. La clasificación debe partir de la función y la consecuencia: sistemas de seguridad, control básico, supervisión, operaciones del sitio, zona desmilitarizada industrial (IDMZ) y servicios empresariales pueden necesitar zonas distintas.

La IDMZ es un amortiguador, no otro nombre para toda la red OT. Allí se terminan o intermedian servicios transfronterizos: réplicas de historiadores, transferencia administrada de archivos, jump hosts, repositorios de actualizaciones y relés de registros. Los firewalls de los lados empresarial y de control deben aplicar reglas revisadas de forma independiente. La red empresarial no debe enrutar directamente hacia PLC, estaciones de ingeniería o sistemas de seguridad, ni se deben aplanar VLAN solo para facilitar el descubrimiento.

Definir flujos antes que reglas de firewall

Cada flujo debe inventariar dueño, origen, destino, dirección, protocolo, autenticación, sensibilidad, frecuencia, retención y comportamiento ante fallas. La denegación predeterminada solo tiene sentido después de documentar los flujos necesarios. Esta prueba determinista ilustra la intención; es únicamente una matriz allow/deny, no sintaxis desplegable:

Origen	Destino	Propósito	Veredicto
Historiador OT	Réplica IDMZ	Publicar historial de proceso aprobado	ALLOW
Analítica empresarial	Réplica IDMZ	Leer historial aprobado	ALLOW
Relé de registros OT	Colector IDMZ	Reenviar eventos de seguridad	ALLOW
Usuario empresarial	PLC	Programación directa	DENY
Proveedor en Internet	Estación de ingeniería	Sesión directa de soporte	DENY
Réplica IDMZ	Sistema de seguridad	Comando de control	DENY

La matriz no permite comandos de control a través del límite. Una política real también requiere puertos, endpoints, certificados, límites de tasa, monitoreo, vencimiento y un dueño identificado.

Intermediar el acceso remoto

El soporte remoto debe ingresar mediante un servicio aprobado y un jump host endurecido en la IDMZ, con cuentas nominativas, autenticación multifactor cuando sea técnicamente viable, autorización para un activo y una tarea, ventana aprobada, registro de sesión y revocación rápida. El acceso se deshabilita al terminar. Deben evitarse cuentas compartidas, split tunneling, módems sin supervisión y rutas entrantes directas a activos críticos. Operaciones necesita observar y terminar la sesión; el acceso de emergencia exige un procedimiento separado y probado.

Convertir los controles en operación

El inventario OT debe incluir hardware, firmware, software, ubicación de red, función, dueño, criticidad, dependencias, versiones soportadas, estado de backup y rutas de acceso remoto. Se mantiene durante compra, puesta en servicio, cambio y retiro. El descubrimiento pasivo puede complementar registros; el escaneo activo requiere aprobación OT y pruebas previas.

La identidad puede federarse cuando el sistema lo soporte, conservando cuentas locales de recuperación controladas para perder dependencias empresariales. Se centralizan eventos de autenticación, cambio de configuración, firewall, jump host y seguridad con tiempo sincronizado. No todo equipo heredado genera registros útiles; su conducto debe monitorearse y la brecha debe quedar documentada.

Parches y backups se ejecutan en ventanas aprobadas por producción. Hay que probar actualizaciones en sistemas representativos, verificar restricciones del proveedor y medios de recuperación, capturar lógica y configuraciones buenas conocidas, y definir condiciones de suspensión. Tener copias no demuestra recuperabilidad: hacen falta restauraciones controladas y, cuando corresponda, copias offline o inmutables.

Cambiar por etapas y conservar la reversión

Línea base: confirmar responsables, inventario, diagramas, flujos, backups, restauraciones y criterios de aceptación.
Piloto: habilitar un flujo de solo lectura y baja consecuencia por la IDMZ; observar latencia, carga, registros y fallas.
Expansión: sumar flujos aprobados de a uno en ventanas de cambio, con vencimiento de reglas y revisión posterior.
Operación: reconciliar inventario, revisar cuentas y reglas, ejercitar respuesta a incidentes y medir recuperación.

Cada etapa necesita disparador de reversión, autoridad de decisión, última configuración buena conocida, ruta de restauración validada, plan de comunicación y evidencia de finalización. Si un cambio afecta la seguridad del proceso o el control confiable, corresponde detenerse y volver al estado aprobado, no improvisar alrededor del sistema de control.