Seguridad de PLC. Proteja los controladores que no pueden protegerse solos.
La seguridad de PLC consiste en proteger los controladores que gobiernan procesos físicos, imponiendo identidad, segmentación y auditoría delante de dispositivos que no pueden defenderse.
Última actualización:
La seguridad de PLC trata de proteger los controladores lógicos programables que gobiernan procesos físicos. La mayoría de los controladores en campo, como Siemens S7, Rockwell ControlLogix y Schneider Modicon, no pueden autenticar a un usuario, cifrar su tráfico, recibir parches ni ejecutar un agente. Por eso un PLC no se asegura en el dispositivo. Se asegura delante del dispositivo: un proxy industrial local intermedia cada conexión, comprueba quién pregunta, permite solo los comandos que cada usuario necesita, mantiene el PLC fuera de la red plana y registra la sesión. Este es un control compensatorio, y se corresponde con IEC 62443 y NIST 800-82. Lo que está en juego es físico: un controlador manipulado altera un proceso, así que un comando erróneo significa una línea detenida, equipos dañados o una consigna insegura.
Por qué los PLC son difíciles de proteger
Un PLC es un controlador robusto pensado para gobernar un proceso durante veinte años, no para defenderse en una red. Las familias presentes en la mayoría de las plantas, Siemens S7-1200 y S7-1500, Rockwell ControlLogix y CompactLogix, y Schneider Modicon, comparten cuatro puntos débiles.
No se pueden parchear
Los fabricantes rara vez publican actualizaciones de firmware, y no se puede desconectar un controlador en marcha para aplicarlas. Los fallos conocidos quedan abiertos durante años, muchos de ellos listados en los avisos de ICS de CISA. Así que "no podemos parchearlo" ya no satisface a un auditor ni a una aseguradora cibernética. Esperan un control compensatorio documentado, no un riesgo aceptado.
Confían por defecto
La mayoría de los protocolos de PLC no tienen autenticación ni cifrado de fábrica. Modbus/TCP (port 502), Siemens S7comm (port 102), EtherNet/IP CIP (44818), DNP3 (port 20000) y Profinet permiten que cualquier dispositivo de la red lea o escriba registros y envíe comandos. Existen versiones seguras, S7comm-plus, CIP Security y DNP3 Secure Authentication, pero son opcionales y rara vez se activan.
Vienen con credenciales por defecto
Las contraseñas por defecto y codificadas de fábrica son habituales y están bien documentadas. Casi nunca se cambian, porque cambiar una arriesga romper una integración que funciona.
Una VLAN ya no basta
Los PLC, las HMI y las estaciones de ingeniería a menudo comparten una única red plana, y ponerlos en una VLAN ya no basta. Una VLAN separa el tráfico, pero no controla quién puede llegar a un controlador concreto ni registra lo que hizo. El control de acceso por puerto como 802.1X ayuda, pero es complejo de operar y mantener a escala de planta, y sus registros son difíciles de vincular con lo que un usuario hizo realmente en el controlador. La estación de ingeniería es el punto débil, ya que ejecuta el software que programa el PLC (TIA Portal, Studio 5000). El objetivo es un acceso granular y trazable a la máquina misma, por usuario y por comando, no solo una zona de red.
Cómo atacan a los PLC
La mayoría de los PLC ejecutan cualquier comando válido que reciben sobre un protocolo sin autenticar, así que la vía de ataque es corta. Esto no es teoría: desde las intrusiones de Unitronics en 2023 contra servicios de agua de EE. UU. que aún usaban credenciales por defecto, hasta los incidentes rastreados a lo largo de 2026, CISA y los investigadores de amenazas de OT siguen encontrando controladores expuestos a internet y con credenciales por defecto. Las técnicas de abajo son las mismas, mapeadas a MITRE ATT&CK for ICS.
| Táctica | Técnica (ID) | Qué ocurre en un PLC |
|---|---|---|
| Acceso inicial | External Remote Services (T0822) | Una VPN de proveedor o un host de salto da a un tercero comprometido un amplio alcance dentro de la red OT. |
| Acceso inicial | Internet Accessible Device (T0883) | Un PLC expuesto a internet lo encuentra Shodan o Censys y se accede a él directamente. |
| Movimiento lateral | Default Credentials (T0812) | Las contraseñas por defecto documentadas permiten que un atacante inicie sesión en el controlador. |
| Ejecución | Unauthorized Command Message (T0855) | Sin autenticación, un mensaje Modbus (port 502) o S7comm (port 102) manipulado escribe registros o cambia la lógica. |
| Ejecución | Program Download (T0843) | Una estación de ingeniería comprometida usa TIA Portal o Studio 5000 para enviar lógica alterada al controlador, por la misma vía que usa un ingeniero real. |
| Deterioro del control del proceso | Manipulation of Control (T0831) | Consignas o lógica alteradas llevan el proceso a un estado inseguro: sobredosificar un producto químico, sobrepresurizar una línea o forzar un equipo más allá de un límite. |
Asegure un PLC sin tocarlo
No se puede endurecer la mayoría de los PLC directamente, así que se añaden los controles que faltan delante de ellos: identidad, mínimo privilegio y un registro que el dispositivo nunca tuvo. Esto es lo que hace Trout Access Gate. Es un proxy industrial resiliente que se ejecuta de forma local delante de sus controladores e impone acceso ligado a identidad, listas de permitidos por comando, microsegmentación y auditoría completa, sin agente en el PLC y sin interrupciones para desplegarlo. Los auditores lo llaman un control compensatorio. Ninguno de los seis pasos de abajo toca el controlador.
01Coloque un punto de control delante del controlador
Trout Access Gate se sitúa en la ruta hacia el PLC e intermedia cada conexión. El controlador nunca se toca ni se parchea, y el proxy permanece transparente para el proceso, de modo que no afecta la temporización del lazo de control ni a un sistema de seguridad (SIS) conectado.
02Autentique cada conexión por identidad
Vincule el acceso a un usuario o dispositivo con nombre a través de su directorio (Active Directory, Microsoft Entra ID), con MFA en la capa de red, no una IP o contraseña compartida.
03Permita solo lo que cada usuario necesita
Delimite el acceso por activo, protocolo y comando. Un ingeniero llega a los PLC que le corresponden; un proveedor llega a una máquina para una tarea, con tiempo limitado.
04Segmente el PLC fuera de la red plana
Use microsegmentación para que una estación comprometida no pueda alcanzar el controlador, sin rediseñar la VLAN ni readireccionar IP.
05Registre cada sesión
Conserve un registro a prueba de manipulaciones de quién se conectó, a qué controlador, por qué protocolo y qué comandos se ejecutaron, listo para una auditoría o un incidente.
06Mantenga el proceso en marcha si el control se degrada
El proxy ahora está en la ruta, así que constrúyalo para la disponibilidad: ejecútelo con conmutación por error para que un solo fallo nunca detenga el proceso, y dé a los operadores una vía break-glass documentada que a su vez quede registrada.
Lo que un control compensatorio debe producir
Un control que no puede producir evidencia no es un control. Los auditores y las aseguradoras cibernéticas aceptan registros, no afirmaciones. Para cada controlador detrás del proxy, debería poder exportar:
- Atribución de identidad: el usuario o dispositivo con nombre detrás de cada sesión, no una IP ni una cuenta compartida.
- Prueba de mínimo privilegio: el alcance por activo y por comando que se permitió a cada identidad.
- Registros a nivel de comando: qué comandos de protocolo y escrituras de registros llegaron al controlador, y cuáles se bloquearon.
- Registros a prueba de manipulaciones y con hora sincronizada con un periodo de retención declarado, para que una cronología sobreviva a una investigación.
- Cobertura: qué controladores están detrás del control y cuáles no, vinculados al inventario de activos.
- Prueba de que no se puede eludir: control en la ruta, no detección fuera de banda, con la vía break-glass a su vez registrada.
- El mapeo: cada elemento vinculado al requisito específico de IEC 62443, NIST 800-82, CMMC o NERC CIP que evalúa su auditor. La evidencia permanece de forma local, no en una nube de proveedor.
Lista de verificación de seguridad de PLC
Una secuencia práctica para asegurar una flota de controladores, del inventario al mapeo con marcos.
| # | Acción | Detalle |
|---|---|---|
| 01 | Inventaríe cada PLC | Cree un inventario en vivo de controladores, HMI y RTU, incluidos los dispositivos heredados que no pueden ejecutar un agente. Use descubrimiento pasivo: las CPU más antiguas pueden fallar o perder E/S bajo un escaneo activo, así que nunca escanee de forma activa un controlador en marcha. |
| 02 | Elimine la exposición a internet | Retire los PLC de cualquier ruta accesible desde internet, y confirme que ninguno esté expuesto vía Shodan o Censys. |
| 03 | Cambie o proteja las credenciales por defecto | Reemplace las contraseñas por defecto donde pueda; donde no pueda, imponga autenticación delante del dispositivo. |
| 04 | Imponga identidad y MFA en la capa de red | Exija autenticación con nombre y respaldada por MFA antes de que cualquier sesión llegue a un controlador. |
| 05 | Segmente IT de OT, y PLC de PLC | Microsegmente para bloquear el movimiento lateral hacia los controladores, sin recablear. |
| 06 | Controle el acceso de proveedores y remoto | Intermedie el acceso de terceros por activo, con tiempo limitado y registrado, y retire las cuentas VPN permanentes. |
| 07 | Registre y conserve las sesiones | Conserve registros de sesión a prueba de manipulaciones y con hora sincronizada, vinculados a la identidad, con un periodo de retención que satisfaga a su auditor, regulador o aseguradora. |
| 08 | Programe los cambios en torno al proceso, no contra él | Active el control en una ventana de mantenimiento planificada, deje los sistemas de seguridad (SIS) fuera de alcance, y confirme que la línea funciona sin cambios antes y después. |
| 09 | Mapee los controles con los marcos a los que responde | Documente cada control frente a IEC 62443, NIST 800-82 Rev 3 y CISA CPGs, más las directivas de la TSA, NERC CIP o CMMC donde apliquen. |
Seguridad de PLC e IEC 62443
Los PLC heredados cumplen por sí solos casi ninguno de los requisitos fundamentales de IEC 62443. Un control compensatorio delante del controlador cierra la brecha y produce la evidencia, y el mismo control cubre los demás marcos a los que responde un operador de EE. UU.: NIST 800-82 Rev 3, CISA CPGs y, donde apliquen, las directivas de la TSA, NERC CIP y CMMC.
| Requisito de IEC 62443 | La brecha del PLC | Cómo cubrirla |
|---|---|---|
| FR 1 Control de identificación y autenticación | Los PLC no tienen autenticación nativa | Acceso ligado a identidad impuesto en el proxy |
| FR 2 Control de uso | Sin control por comando en el dispositivo | Lista de permitidos por activo, protocolo y comando |
| FR 3 Integridad del sistema | Comandos sin autenticar pueden alterar la lógica | Solo los comandos autorizados llegan al controlador |
| FR 4 Confidencialidad de los datos | Los protocolos heredados envían comandos en texto claro | Cifrar la sesión del lado del cliente; confinar el texto claro al segmento delante del controlador |
| FR 5 Flujo de datos restringido | Redes planas, sin zonas ni conductos | Microsegmentación en zonas y conductos |
| FR 6 Respuesta oportuna a eventos | Sin registro nativo en el dispositivo | Registros de sesión a prueba de manipulaciones para detección y auditoría |
| FR 7 Disponibilidad de recursos | Sin protección frente a sobrecarga o una integración rota | Control en la ruta con conmutación por error y una vía break-glass registrada |
Qué hacer esta semana
- Liste cada PLC y dónde se ubica en la red.
- Compruebe si algún controlador es accesible desde internet.
- Averigüe qué PLC siguen usando credenciales por defecto o compartidas.
- Compruebe si el acceso remoto de proveedores depende de cuentas permanentes o VPN abiertas.
- Intente nombrar, para un controlador crítico, quién accedió a él y qué comandos envió en los últimos 30 días. Si no puede, esa es la brecha.
- Saque la sección de OT de su solicitud de seguro cibernético y lea cómo le pide gestionar los activos que no se pueden parchear.
Preguntas sobre seguridad de PLC, respondidas
agentes en el PLC, sin interrupciones para desplegar
La seguridad de PLC es proteger los controladores lógicos programables, los dispositivos que gobiernan procesos físicos, frente al acceso no autorizado y la manipulación. Como la mayoría de los PLC no pueden autenticar, cifrar ni recibir parches, se impone la seguridad de PLC delante del controlador: acceso ligado a identidad, segmentación y auditoría en la capa de red.
Coloque un control compensatorio delante de él. Un proxy industrial local intermedia cada conexión al controlador: autentica al usuario, permite solo los comandos que necesita, segmenta el PLC fuera de la red plana y registra la sesión. El PLC nunca se modifica, y permanece en línea.
No en el PLC mismo, ya que la mayoría de los controladores no lo admiten. En su lugar se impone MFA en la capa de red: un usuario se autentica con MFA contra su directorio antes de que cualquier sesión llegue al controlador. El efecto es un acceso al PLC protegido con MFA sin cambiar el dispositivo.
Escanee con cuidado. Los controladores más antiguos pueden fallar, perder E/S o dejar de responder bajo un escaneo activo de puertos, así que el descubrimiento en una planta en marcha debería ser pasivo: lea el tráfico que ya está en el cable en lugar de sondear el dispositivo. Reserve las pruebas activas a una ventana de mantenimiento contra una unidad de repuesto o fuera de línea.
Credenciales por defecto, exposición a internet, protocolos sin autenticar, firmware sin parchear, redes planas, estaciones de ingeniería y portátiles de proveedores comprometidos, y acceso remoto de proveedores sin control. Cada uno permite que un atacante llegue a un controlador y emita comandos, o envíe nueva lógica, que este ejecuta sin cuestionar.
Las aseguradoras esperan uno cada vez más. Las solicitudes de seguro cibernético preguntan cómo gestiona los activos de OT que no se pueden parchear, MFA y segmentación, y "no podemos parchearlo" sin un control es una señal de alarma en la renovación y una disputa a la hora de la reclamación. Un control compensatorio que impone identidad, mínimo privilegio y segmentación delante del controlador, y produce evidencia de sesión, responde al cuestionario y a la reclamación.
Para cada controlador: la identidad con nombre detrás de cada sesión, el alcance por activo y por comando que se le permitió, los comandos que llegaron al dispositivo, registros a prueba de manipulaciones y con hora sincronizada con un periodo de retención, la cobertura de qué controladores están protegidos, y un mapeo de cada elemento al requisito de IEC 62443, NIST 800-82, CMMC o NERC CIP que evalúa su auditor. La evidencia se exporta de forma local, no desde una nube de proveedor.
IEC 62443 espera identificación y autenticación, control de uso, integridad del sistema, zonificación y registro de eventos. Los PLC heredados no cumplen ninguno de forma nativa, así que los operadores satisfacen los requisitos con un control compensatorio que los impone delante del controlador y documenta el mapeo.
Sí, porque piden lo mismo con distintas palabras: acceso ligado a identidad, mínimo privilegio, segmentación y registro delante de activos que no pueden hacerlo por sí mismos. Un único punto de control delante del controlador produce la evidencia para IEC 62443, NIST 800-82 Rev 3, CISA CPGs, las directivas de la TSA, NERC CIP y CMMC.
Inventaríe cada controlador, compruebe la exposición a internet y las credenciales por defecto, verifique la segmentación y el acceso basado en identidad, confirme que el acceso de proveedores está intermediado y registrado, y mapee cada control a IEC 62443 o NIST 800-82. La lista de verificación de esta página lo recorre paso a paso.