IT/OT: integrar la red de una planta con la corporativa sin poner en riesgo la producción

Qué vas a conseguir

Conectar la red de una planta con la corporativa de forma que el negocio vea los datos de producción y los proveedores puedan dar soporte, sin que un cambio pensado para las oficinas llegue a una línea. En la parte de oficinas, un error se arregla con un reinicio; en la planta, un PLC que deja de recibir órdenes para la línea, y una hora de línea parada se mide en piezas que no salen. La regla de toda la guía: en OT manda la disponibilidad, y cualquier cosa que IT haga en la planta se acuerda antes con el jefe de planta y con el responsable de automatización.

Antes de empezar

• El responsable de OT o de automatización de cada planta y el jefe de planta: son quienes deciden cuándo se toca algo. Sin ellos no se empieza.
• Los planos de red de la planta, aunque estén desactualizados, y las listas de equipos que entregaron los integradores y fabricantes de cada línea.
• El calendario de paradas planificadas de producción del año: es tu calendario de ventanas.
• Los contratos de soporte de los fabricantes (SCADA, PLC, robots) y qué acceso remoto exige cada uno.
• Acceso de lectura al firewall entre IT y la planta y a los switches de la red de planta.

1. Inventario de activos OT sin escanear

En OT no se lanza un escaneo de red para "ver qué hay". Un barrido de puertos o un escáner de vulnerabilidades puede colgar un PLC antiguo o un panel de operador, y eso es una línea parada. El inventario se construye con fuentes que no tocan los equipos:

• Listas de los fabricantes e integradores: cada línea se entregó con su documentación (as-built): modelos, firmware, direcciones IP.
• Recorrido físico por los armarios con el responsable de automatización: etiquetas, modelos, qué está conectado a qué.
• Tablas de los switches de planta: leer la tabla de direcciones MAC y la tabla ARP del switch es pasivo para los equipos conectados.
• Una sonda pasiva de OT conectada a un puerto SPAN (espejo) del switch: escucha el tráfico, reconoce protocolos industriales (Modbus TCP, EtherNet/IP, S7, OPC UA) y deduce qué es cada equipo sin enviarle nada.

›show mac address-table vlan 120          Mac Address Table-------------------------------------------Vlan    Mac Address       Type        Ports----    -----------       --------    ----- 120    0008.dc2a.11f0    DYNAMIC     Gi1/0/3 120    001d.9c4b.07a2    DYNAMIC     Gi1/0/5 120    5cf8.21e4.9b10    DYNAMIC     Gi1/0/12›show ip arp vlan 120

Si alguien propone "un escaneo suave" en producción, la respuesta es no. Los escaneos activos, si hacen falta, se hacen en una parada planificada, con el responsable de automatización delante y equipo a equipo.

Cada activo va a una ficha con lo mismo en todas las plantas:

La CMDB es el sitio natural para estas fichas, con una clase propia para activos OT.

2. Niveles Purdue, zonas y conductos

El modelo Purdue ordena la planta por capas, de la máquina al ERP:

La norma IEC 62443 (en concreto la parte 3-2) añade dos ideas sencillas:

• Una zona es un grupo de equipos con las mismas necesidades de seguridad: por ejemplo, todo lo de la línea 2 (sus PLC, sus HMI y su SCADA). Lo que pasa dentro de una zona no afecta a otra.
• Un conducto es el único camino permitido entre dos zonas, con lo que puede pasar por él: quién, hacia dónde, qué protocolo y en qué sentido.

En la práctica: una VLAN y un segmento por zona, un firewall entre zonas y una lista de conductos aprobada por OT. Si dos equipos de zonas distintas hablan, lo hacen por un conducto que alguien ha documentado.

3. La DMZ industrial

La regla de oro: ninguna conexión cruza directamente de la red corporativa a la planta. Todo termina en la DMZ industrial (nivel 3.5) y desde ahí se sirve o se reenvía:

• Réplica del historian: el historian de la planta (nivel 3) envía sus datos a una réplica en la DMZ. Los usuarios de oficina y los informes consultan la réplica, nunca el historian de la planta.
• Jump host: el único punto de entrada para administrar o dar soporte a equipos de la planta. Se entra con MFA y desde ahí, solo a los equipos autorizados.
• Relé de parches y antivirus: un servidor WSUS y el servidor de distribución del antivirus en la DMZ. Los equipos de la planta descargan de ahí, no de Internet ni de los servidores corporativos.
• Intercambio de ficheros: si producción necesita recibir recetas u órdenes en fichero, una carpeta en la DMZ con análisis antivirus, no un recurso compartido de la oficina mapeado en un HMI.

Los equipos de la planta no deberían estar en el dominio corporativo. Si lo están, en una OU propia que bloquea la herencia y con GPO pensadas para OT; la guía de GPO de seguridad se aplica a oficinas, y sus directivas solo llegan a OT tras probarlas con el fabricante.

4. Reglas del firewall por conducto

Cada regla del firewall corresponde a un conducto de la lista, con su número de cambio en el comentario. Un ejemplo de la planta de Northwind en Zaragoza:

• Nada de reglas any hacia la planta ni de objetos compartidos con reglas de oficinas: los objetos de OT se nombran OT-... y solo se usan en reglas de OT.
• Los protocolos industriales (Modbus TCP 502, EtherNet/IP 44818, S7 102) no deberían cruzar de la red corporativa a la planta. Si alguno cruza, es un conducto que hay que revisar.
• Las reglas de la planta no entran en las "limpiezas de reglas sin uso": un conducto que se usa una vez al mes en un cambio de formato sigue siendo necesario.

La guía de FortiGate explica cómo escribir estas políticas con mínimo privilegio.

5. Acceso remoto de proveedores

El fabricante del SCADA o el integrador de la línea necesitan entrar para dar soporte. El acceso se da siempre por el mismo camino:

1. Una cuenta por persona del proveedor, nunca una cuenta compartida "proveedor-scada", y deshabilitada por defecto.
2. Entrada por VPN o portal con MFA, solo hasta el jump host.
3. Aprobación de la sesión: el proveedor la pide con un ticket; el responsable de automatización la aprueba para una ventana concreta (por ejemplo, de 14:00 a 16:00) y solo hacia los equipos de esa línea.
4. Desde el jump host, solo los destinos de su conducto. Las sesiones se graban si la herramienta lo permite.
5. Al acabar, la cuenta vuelve a deshabilitarse y el ticket recoge qué se hizo.

Los módems 4G o los programas de control remoto que algunos integradores dejan instalados "para soporte" saltan todo lo anterior. En el recorrido del inventario, búscalos y quítalos con el responsable de la planta.

Si la empresa ya tiene una herramienta de cuentas privilegiadas, como en la guía de CyberArk, las cuentas de proveedores de OT van en un safe propio con sesiones grabadas.

6. Parches y antivirus en ventanas de parada

• Solo en paradas planificadas, acordadas con el jefe de planta: nunca durante la producción, aunque el parche sea "solo de seguridad".
• Lista de compatibilidad del fabricante: los fabricantes de SCADA publican qué actualizaciones de Windows y qué versiones de antivirus han validado con su software. Lo que no está en la lista, no se instala.
• Primero en un equipo de pruebas: un HMI o una estación de repuesto con la misma imagen.
• Copia antes de tocar: imagen de los servidores SCADA y de las estaciones de ingeniería con la restauración probada.
• Antivirus: firmas desde el relé de la DMZ con un retraso (por ejemplo, 24 horas detrás de las oficinas), exclusiones que indica el fabricante y análisis completos programados solo en paradas. En equipos que no admiten antivirus, control de aplicaciones (lista blanca).

En el calendario de paradas, cada ventana tiene su lista: qué equipos, qué parches, quién de OT valida que la línea arranca y cuál es la vuelta atrás.

7. Copias de los programas de PLC

Si un PLC se avería o alguien borra parte de su programa, la línea no arranca hasta que se recarga. Sin copia, hay que pedirla al integrador, que quizá ya no la tenga.

• El responsable de automatización saca la copia con el software de ingeniería del fabricante (subida del programa desde el PLC) después de cada cambio y, como mínimo, cada trimestre.
• IT pone el repositorio: una carpeta en un servidor de la planta, con versiones, acceso solo para automatización y copia a otra ubicación.
• Cada copia con su ficha: PLC, versión, fecha, quién y por qué (cambio de receta, mejora, corrección).
• Comprobar de vez en cuando que el programa del PLC coincide con la última copia: la herramienta de ingeniería permite comparar el programa del equipo con el del repositorio. Una diferencia es un cambio sin registrar.

8. El ticket: "la línea 2 se ha parado tras un cambio de IT anoche"

Martes, 6:20. El turno de mañana avisa: la línea 2 de envasado está parada. El SCADA de la línea no recibe las órdenes del MES y los paneles de operador muestran que no hay orden de fabricación activa. Anoche hubo cambios de IT.

1. Primero, la línea: con el jefe de turno y el responsable de automatización. Ellos deciden si la línea puede trabajar en modo local mientras se investiga. Nadie de IT toca un PLC ni un HMI sin ellos.
2. Qué cambió anoche: el calendario de cambios muestra dos candidatos: una limpieza de objetos del firewall a las 23:00 y la actualización mensual de la GPO de seguridad con nuevas firmas de antivirus a medianoche.
3. El firewall: una traza del tráfico del MES hacia el SCADA de la línea 2:

›diagnose debug flow filter addr 10.40.20.10›diagnose debug flow show function-name enable›diagnose debug enable›diagnose debug flow trace start 10id=65308 trace_id=1 func=print_pkt_detail line=5911 msg="vd-root:0 received a packet(proto=6, 10.40.30.20:52814->10.40.20.10:4840) tun_id=0.0.0.0 from port7. flag [S], seq 3021457710, ack 0, win 64240"id=65308 trace_id=1 func=fw_forward_handler line=1015 msg="Denied by forward policy check (policy 0)"›diagnose debug disable

El tráfico del conducto C-06 cae en la política 0, la denegación implícita. En Log & Report › System Events, el registro de anoche dice que se editó el grupo de direcciones GRP-SERVIDORES-MES, compartido por una regla de oficinas y por la del conducto C-06, y se quitó el MES de la planta al "limpiar servidores antiguos".

Vuelta atrás: devolver el miembro al grupo, con un cambio de emergencia aprobado por el responsable de OT. La lista de revisiones de la configuración (Configuration › Revisions, en el menú del administrador) sirve para comparar el antes y el después; restaurar una revisión completa reinicia el equipo y deshace todo lo de la noche, así que se corrige el objeto, no la configuración entera.

Si el firewall está bien, la GPO o el antivirus: en un HMI, con el responsable de automatización:

›gpresult /scope computer /r›Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 20 | Where-Object Id -in 1116,1117 | Select-Object TimeCreated, Id, Message›& "C:\Program Files\Windows Defender\MpCmdRun.exe" -Restore -ListAll

Si gpresult muestra una GPO de oficinas aplicada al HMI, la OU de la planta no bloqueaba la herencia; si los eventos 1116 y 1117 muestran que el antivirus puso en cuarentena un componente del software del SCADA, se restaura con MpCmdRun.exe -Restore -Name <nombre>, se añade la exclusión del fabricante y se para la distribución de esas firmas a la planta.

Comprobación: la línea vuelve a recibir órdenes y el responsable de automatización da por buena la producción. Hasta entonces el ticket no se cierra.

Para que no se repita, el control de cambios incluye a OT:

• Todo cambio que toque una zona OT, un objeto usado en un conducto, una GPO que llegue a equipos de la planta o el antivirus de la planta necesita la aprobación del responsable de OT en el comité de cambios.
• Los activos y conductos de OT están en la CMDB, así que el análisis de impacto de un cambio los ve.
• Objetos del firewall propios de OT, sin compartir con oficinas.
• Firmas y parches a la planta por el relé de la DMZ, con retraso y tras un equipo de pruebas.

En el ticket: hora de la parada, cambio causante, vuelta atrás, hora de recuperación de la línea y las acciones preventivas, con su responsable.

Siguientes pasos

• La guía de LAN, WAN y WiFi entre plantas cubre la red de cada sede en la que se integra la red de planta.
• La de Defender Antivirus y reglas ASR explica las exclusiones y el modo auditoría antes de aplicar nada a un equipo de OT.
• La de DR/BCP sirve para dar a cada línea su RTO y probar la recuperación del SCADA y del historian.
• La de mantenimiento de VMware cubre los servidores virtuales de la planta y su calendario según los turnos.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.