SEMAIQ · Automatización y PLC · Querétaro
Ciberseguridad en PLC y redes industriales OT
Por qué la seguridad de redes industriales OT no es igual a la de TI
En tecnología de la información la prioridad es la confidencialidad: si los datos se filtran, hay multas y daño reputacional. En tecnología de operación la prioridad se invierte, y el orden es disponibilidad, integridad y confidencialidad. Un paro de línea de diez minutos puede costar más que cualquier filtración de datos de producción. Ese solo cambio de prioridades explica por qué las herramientas y las políticas de la oficina fallan cuando se aplican al piso de planta.
El segundo factor es la vida útil. Un servidor de TI se renueva cada tres a cinco años y se parchea de forma automática; un PLC trabaja en campo entre quince y treinta años, con firmware que casi nunca se actualiza al ritmo de las vulnerabilidades publicadas. En ese contexto un parche no es una tarea de rutina: es un proyecto pequeño, con ventana de mantenimiento, respaldo previo, prueba en banco y plan de reversa. Quien trata el controlador como un servidor más termina con ventanas mal planeadas o, peor, con equipos que nunca se actualizan.
El tercer factor son los protocolos. Modbus TCP, el protocolo industrial más extendido, no tiene autenticación ni cifrado: cualquier equipo que esté en el mismo segmento puede escribir registros en el controlador sin credenciales. S7comm y EtherNet/IP no están diseñados para exponerse a redes no confiables. Esto ya lo detallamos al comparar las características de PROFINET, EtherNet/IP y Modbus TCP: la consecuencia de seguridad es la misma en los tres casos, el control depende de la red que los transporta.
Hay un cuarto punto que suele sorprender a los equipos de sistemas: en OT las herramientas activas son un riesgo operativo. Un escaneo de puertos agresivo o una sonda de vulnerabilidades puede saturar el stack de red de un controlador con recursos limitados y tumbarlo. Por eso en planta se monitorea con espejo de puerto (SPAN) o con un TAP pasivo, y nunca con barridos activos sin ventana y sin autorización del responsable de producción.
La superficie de ataque real de una planta de manufactura
Cuando se hace el inventario honesto de cómo entra el riesgo, la lista se parece poco a las películas: casi siempre son caminos de operación legítimos que se abrieron por comodidad y nunca se cerraron.
Programación remota e ingeniería con laptop
Cada computadora de ingeniería con TIA Portal, Studio 5000 o el software del variador es una llave maestra: tiene los proyectos, las herramientas de firmware y la capacidad de poner al controlador en modo de programación. Cuando esas laptops se conectan a la red de oficina para el correo, la actualización de Windows o la impresora, y después al switch de la celda para hacer un ajuste, se convierten en el puente que nadie autorizó. La regla es sencilla: el equipo de ingeniería vive en su propia zona, sale a internet solo por caminos controlados y no navega mientras está conectado al control.
HMI y SCADA expuestos
El HMI es el punto más cómodo para atacar, porque casi siempre habla dos idiomas: protocolo industrial hacia el PLC y servicios de TI hacia el resto del mundo. Un panel que responde en la red corporativa con escritorio remoto o con un servidor web de diagnóstico es acceso directo a la operación. Y un servidor SCADA con sistema operativo sin actualizar arrastra todas las vulnerabilidades conocidas de su versión, además de compartir credenciales con el resto de la red cuando el dominio es el mismo para oficina y planta.
USB y memoria extraíble
Históricamente, el vector más efectivo contra instalaciones industriales ha sido la memoria USB: entra con el ingeniero del proveedor, con el programa del variador, con el respaldo que alguien trae del escritorio. Basta un archivo ejecutable malicioso copiado en una carpeta del proyecto para propagarse en cuanto el archivo se abre en la computadora de ingeniería. La defensa práctica es tener memorias asignadas por área, escaneadas en un equipo aislado, y bloquear la ejecución desde medios extraíbles en todas las computadoras que tocan el control.
VPN de proveedores y routers celulares
El acceso remoto es hoy el vector dominante en incidentes industriales publicados, y la razón es simple: es el único punto que debe estar disponible desde fuera. Un caso conocido, el malware FrostyGoop en 2024, alcanzó controladores de calefacción a través de un router que ni siquiera aparecía en el diagrama oficial de la red. La misma lógica aplica en una nave industrial: un módem celular que el proveedor instaló para dar mantenimiento, un port forward para la empresa de monitoreo o una VPN de sitio a sitio sin multifactor son puertas permanentes. Cada acceso remoto debe tener dueño, fecha de caducidad y registro de sesiones.
Tabla de amenazas, vectores típicos y controles recomendados
Esta es la tabla que usamos como base de diagnóstico en una planta. Se ordena de la amenaza más frecuente a la más sofisticada, y en la columna de control se indica el primer movimiento que tiene efecto real.
| Amenaza | Vector típico | Control recomendado |
|---|---|---|
| Acceso no autorizado al controlador | VPN de proveedor permanente, escritorio remoto o IP pública en el PLC | Acceso solo por jump host con MFA y sesión con caducidad; eliminar cualquier publicación del controlador hacia internet |
| Movimiento lateral desde oficina | Red plana que comparte VLAN entre oficina, HMI, PLC y variadores | Segmentación por zonas y conductos (IEC 62443), con DMZ industrial para el intercambio de datos |
| Manipulación de lógica o de setpoints | Protocolos sin autenticación (Modbus TCP, S7comm, CIP) | Firewall industrial con reglas explícitas por origen, destino y puerto; listas blancas de comunicación |
| Pérdida total de control ante incidente | Sin respaldo vigente o respaldo nunca probado | Respaldo del proyecto y de la configuración versionado, fuera del equipo de ingeniería y con restauración probada |
| Cambio no autorizado en el programa | Contraseña compartida o protección de bloques desactivada | Niveles de acceso por función, protección de bloques, llave en RUN y bitácora de cambios firmada |
| Malware introducido por mantenimiento | USB y laptops de ingeniería compartidas | Medios asignados y escaneados en equipo aislado; bloqueo de ejecución desde USB en equipos de control |
| Exposición que nadie conoce | Inventario incompleto de activos y firmware | Inventario con modelo, versión de firmware, nivel de parcheo y responsable por activo |
Defensa en profundidad: zonas y conductos según IEC 62443
La serie de normas IEC 62443 es el marco de referencia para proteger sistemas de automatización industrial. Su idea central es arquitectónica y muy aplicable: agrupa los activos en zonas que comparten el mismo nivel de confianza y conecta esas zonas solo a través de conductos controlados. Cada zona recibe un nivel de seguridad objetivo, y todo el tráfico que cruza un límite pasa por un punto donde se puede filtrar y registrar. La consecuencia práctica es que el atacante que compromete la red de oficina ya no tiene un camino directo al controlador.
La estructura que funciona en planta suele tener cuatro o cinco zonas: control básico (PLC y variadores), supervisión (HMI y SCADA local), seguridad funcional cuando existe, operación de sitio (historiador, respaldos, servicio de parches) y el perímetro hacia la red corporativa. Si tu celda tiene un PLC de seguridad, ese segmento merece el nivel más alto y no debe compartir VLAN con el HMI ni con nada que tenga salida a internet; sobre ese criterio ya escribimos en la guía de PLC de seguridad.
En cuanto a la aplicación, hay tres reglas que resuelven la mayor parte del problema. Primero: no debe existir ruta directa entre la red de negocios y las celdas; el intercambio de datos con el ERP o con analítica en la nube se termina en una DMZ industrial, con réplica del historiador o servicios de intermediación. Segundo: las VLAN por sí solas no segmentan, solo ordenan; sin un firewall con política de denegación por defecto y reglas explícitas, la separación es decorativa. Tercero: las comunicaciones entre celdas se documentan flujo por flujo —qué se mueve, de dónde a dónde, en qué dirección y por qué puerto— y lo que no está en la lista no se permite.
Endurecimiento del controlador: de la llave RUN/PROGRAM al bloque protegido
Aunque el controlador no tenga autenticación de red, sí tiene defensas propias que casi siempre están sin usar. La primera es física y se ignora todo el tiempo: la llave de modo en RUN. Un PLC sin llave, o con la llave en modo de programación por comodidad, permite que cualquiera con una laptop y el software de ingeniería detenga la línea o altere la lógica. La segunda es el control de acceso al tablero: gabinete cerrado con llave, puerto de programación no expuesto en la puerta y registro de quién entra a la sala eléctrica.
La tercera es la protección lógica y es donde más terreno se gana con menos inversión. Los controladores modernos manejan niveles de acceso con contraseña: en las familias SIMATIC S7-1200 y S7-1500 existen cuatro niveles que limitan lectura, escritura, cambio de estado RUN/STOP y actualización de firmware, además de la protección de know-how y la protección de bloques, que impide leer el código sin la contraseña. En la plataforma Allen-Bradley, ControlLogix y CompactLogix ofrecen protección de rutina con nombre de usuario y roles, además de la protección de código fuente del proyecto. Configurar esto toma una tarde y evita que el programa completo de la máquina se copie con un clic.
Hay tres detalles operativos que se pasan por alto: las contraseñas deben estar en un gestor y no compartidas en el cuerpo del correo; la protección aplica también a los usuarios de mantenimiento, porque un nivel demasiado abierto equivale a no tenerlo; y cualquier cambio de lógica debe quedar registrado con fecha, autor y motivo. Si necesitas apoyo para configurar estos niveles sin afectar el ciclo de producción, nuestro equipo de programación de PLC en Querétaro lo hace dentro de la ventana de mantenimiento.
Respaldos, inventario y parcheo: la higiene que evita el desastre
La defensa más rentable ante un incidente no es un firewall: es poder restaurar. Si el controlador se detiene, se corrompe el proyecto o alguien modificó la lógica, la recuperación depende de tener el respaldo correcto, con la versión correcta de la configuración y del firmware, listo para cargarse en minutos. La mayoría de las plantas cree que tiene respaldos; casi ninguna ha probado la restauración en un equipo de banco.
- Respaldo completo y versionado. No solo el programa: la configuración de hardware, las recetas, los parámetros del variador y la configuración de red, con nombre y fecha en el archivo.
- Fuera del equipo de ingeniería. Una copia en repositorio con acceso controlado y otra en medio separado; un respaldo que solo vive en la laptop del programador no existe.
- Restauración probada. Al menos una vez al año, cargar el respaldo en un controlador de banco y verificar que la máquina arranca con esa versión.
- Inventario de activos y firmware. Modelo, número de serie, versión de firmware, nivel de parcheo y responsable por cada PLC, HMI, switch y variador de la planta.
- Avisos de seguridad del fabricante. Suscripción a los boletines de Siemens y Allen-Bradley; las vulnerabilidades relevantes se publican a tiempo y casi siempre con mitigación disponible antes del parche.
- Parcheo con ventana. Agrupado, planeado y con plan de reversa; nunca en plena producción ni por iniciativa individual de un técnico.
Monitoreo y detección: ver lo que ya está pasando en la red
La detección en OT se apoya en tres fuentes. La primera es la más subestimada: el buffer de diagnóstico del propio controlador. Los eventos de cambio de modo RUN/STOP, las fallas de módulo, los accesos rechazados por nivel de protección y los reinicios quedan registrados ahí, con fecha y hora. Revisar ese registro de forma periódica —y sincronizar el reloj del PLC— convierte al controlador en un sensor de seguridad casi gratuito.
La segunda son los sistemas de detección de intrusiones para redes industriales. Un IDS industrial entiende el contenido de los protocolos, no solo los puertos: distingue una lectura de registros de Modbus de una escritura, o una operación de control legítima de una anómala, y alerta cuando aparece una escritura desde una dirección que nunca lo había hecho. Se alimenta de un espejo SPAN o de un TAP pasivo, sin enviar ni un paquete activo hacia los equipos.
La tercera es la comunicación de datos con seguridad real. Si vas a exponer información de proceso hacia supervisión, analítica o nube, esa ruta debe salir con OPC UA usando modo firma y cifrado, con certificados X.509 y listas de confianza, y con registros de auditoría protegidos; cuando se usa el modo sin seguridad, cualquiera que llegue al puerto puede leer la operación. Profundizamos en esa arquitectura en nuestra guía de OPC UA para monitoreo remoto de PLC.
Caso práctico: línea de ensamble con red plana y acceso de proveedor
Situación (caso representativo): una planta de autopartes del Bajío con cuatro celdas de ensamble automatizado y una celda de robot con visión. Toda la nave —PLC, HMI, variadores, computadora de calidad, impresoras de etiquetas y la oficina de producción— compartía una sola red plana con direccionamiento asignado a mano. El integrador original había dejado una VPN al router de sitio a sitio para dar soporte, con usuario compartido y sin segundo factor. Cada celda tenía su propia secuencia de arranque, sin documentación de las comunicaciones entre PLC y HMI.
Diagnóstico: el levantamiento pasivo mostró tres hallazgos críticos. Había dos HMI con el servidor web de diagnóstico habilitado y alcanzables desde la red de la oficina; la computadora de visión tenía el firewall del sistema operativo desactivado porque “bloqueaba la cámara”; y ninguno de los seis controladores tenía protección de bloques ni llave de modo configurada, con credenciales de nivel administrador que se habían compartido por mensajería durante el arranque de la línea.
Solución implementada por fases, sin detener la producción:
- Inventario completo de activos con modelo, firmware y responsable, y respaldo versionado del proyecto de cada controlador y de los parámetros de los variadores.
- Segmentación en cuatro zonas: control por celda, supervisión, operación de sitio y DMZ industrial, con un firewall con política de denegación por defecto y reglas explícitas por origen, destino y puerto.
- Cierre de accesos: se eliminaron los servicios de diagnóstico en HMI, se desactivó el acceso permanente del integrador y se habilitó acceso remoto por jump host con multifactor, sesión con caducidad de horas y registro para auditoría.
- Endurecimiento de controladores: niveles de acceso con contraseña por rol, protección de bloques, llave de modo en RUN y bitácora de cambios firmada por el responsable de mantenimiento.
- Monitoreo: el buffer de diagnóstico de cada PLC se recolecta en el servidor de sitio y un IDS industrial pasivo vigila las escrituras Modbus entre zonas, con alerta únicamente hacia el responsable de automatización para no generar ruido.
Resultados: ninguna escritura de control llegó a ser posible desde la red de oficina; los cambios de lógica quedaron trazables con autor y motivo; el tiempo de restauración de una celda ante una falla de memoria del controlador bajó a menos de una hora, porque el respaldo correcto estaba versionado y probado; y el acceso de mantenimiento del proveedor pasó de permanente a ventanas agendadas con registro de sesión.
Cómo introducir estos cambios sin parar la producción
La objeción más común no es de presupuesto: es de riesgo. “No podemos tocar la red porque la línea no puede parar”. El enfoque que funciona es por fases y con reversa probada en cada paso. La secuencia que aplicamos es esta:
- Levantamiento pasivo primero. Se observa el tráfico real y se documentan los flujos existentes antes de proponer cualquier cambio. Sin este mapa, cerrar reglas es adivinar.
- Cambios de configuración sin impacto en ciclo. Contraseñas, niveles de acceso, protección de bloques, llave de modo y cierre de servicios innecesarios en HMI se hacen en paros de línea normales o por celda, no en la línea completa.
- Segmentación con modo observador. El firewall se instala primero en modo de monitorización para comparar lo que el tráfico real hace contra las reglas propuestas; la política se activa después, cuando ya no hay sorpresas.
- Prueba en banco antes de planta. Cambios de firmware y de proyecto se validan en un controlador de laboratorio con la misma versión del equipo de campo, con el respaldo listo para reversa.
- Ventana con plan de reversa escrito. Hora de inicio, tarea, criterio de éxito, responsable y procedimiento de retorno. Si en la ventana el criterio no se cumple, se revierte; no se improvisa.
- Cierre con documentación. Diagrama de zonas y conductos actualizado, inventario de activos, bitácora de cambios y política de accesos remotos firmada.
La continuidad operativa y la seguridad no se pelean cuando el proyecto se plantea como un plan de fases con criterios de aceptación claros. Ese es el enfoque con el que trabajamos con plantas del Bajío y del resto del país, desde el diagnóstico hasta la puesta en marcha.
Preguntas frecuentes
¿Se puede proteger un PLC que no tiene autenticación propia?
Sí, con controles compensatorios. Como el controlador no autentica por sí mismo, la protección se construye alrededor: segmentación con firewall industrial, reglas por dirección y puerto, listas blancas de origen, control de acceso físico al tablero, protección de bloques con contraseña y monitoreo pasivo del tráfico. Ningún control aislado basta; el resultado sale de la suma de capas.
¿Puedo instalar antivirus en el PLC?
No, y no es el punto. El PLC no ejecuta sistemas operativos de propósito general ni recibe software de terceros. La protección real se hace en la red que lo rodea y en quién puede conectarse: segmentación, control de puertos, acceso remoto con MFA y sesiones auditadas. El antivirus sí aplica en el nivel de las computadoras de ingeniería y del HMI industrial basado en PC.
¿Qué significa segmentar la red de la planta en la práctica?
Significa separar por funciones y por criticidad, no solo por VLAN. Cada celda o grupo de celdas con el mismo nivel de confianza forma una zona; el tráfico entre zonas cruza únicamente por un punto controlado, con reglas explícitas de qué se comunica, en qué dirección y por qué puerto. Las comunicaciones de oficina a control nunca deben llegar directo al PLC: pasan por una DMZ industrial.
¿Cada cuánto tiempo debo respaldar el programa del PLC?
Después de cada cambio validado y siempre antes de cualquier intervención: actualización de firmware, parcheo, modificación de lógica o ajuste de proceso. El respaldo debe estar versionado, guardado fuera del equipo de ingeniería y con la restauración probada en banco. Un respaldo que nunca se restauró no es un respaldo: es un archivo.
¿La VPN del proveedor o del integrador es una amenaza real?
Es una de las principales puertas de entrada en entornos OT. Una VPN que permanece abierta de forma permanente y sin multifactor convierte el acceso de mantenimiento en un camino estable hacia el controlador. La práctica recomendada es acceso por salto intermedio (jump host), MFA obligatorio, sesiones con tiempo definido, grabación de sesión y revocación automática al cerrar la ventana de mantenimiento.
