PLCs expuestos a Internet: alcanzabilidad, confianza y recuperación
Ilustración conceptual aportada por el autor; no representa una configuración recomendada. Ver imagen completa ↗
Lectura del esquema: La presencia del rótulo CIP Security no acredita compatibilidad con MicroLogix 1100 o 1400. Debe verificarse el producto, firmware y perfil. La trayectoria roja tampoco implica que un atacante siempre pueda atravesar un firewall o una ACL.
Un PLC expuesto directamente a Internet puede convertirse en un riesgo operativo sin que el incidente dependa de una vulnerabilidad nueva. La arquitectura, la confianza entre equipos y la capacidad de recuperación también importan.
Qué documentan las fuentes
El 30 de julio de 2026, el FBI y la EPA emitieron una alerta sobre ataques contra MicroLogix 1100 y 1400 accesibles desde Internet. Desde el 27 de julio, empresas del sector de agua y aguas residuales en al menos siete estados de EE. UU. habían reportado incidentes. Los cambios de direcciones IP y contraseñas afectaron la supervisión y el control; entre los efectos operativos reportados hubo pérdida de presión e inundaciones. El documento también recoge al menos un reporte de cambios en archivos de proyecto. Fuente: alerta conjunta FBI/EPA.
Rockwell explica en SD1790 que este aviso no tiene un CVE asociado. Ofrece orientación para recuperar el acceso y reforzar la protección. Por tanto, las fuentes citadas no permiten atribuir estos incidentes a CVE-2021-33012.
Esa CVE es un antecedente distinto: PN1571, publicado en julio de 2021, afecta a todas las versiones de MicroLogix 1100 y describe una falla persistente provocable remotamente sin autenticación que impide entrar en RUN. El fabricante indica que reiniciar el equipo no resuelve esa condición y contempla recuperar un proyecto conocido.
Lectura de arquitectura: tres preguntas diferentes
Mi interpretación es que este caso invita a separar tres decisiones que suelen mezclarse al hablar de seguridad del controlador:
- Alcanzabilidad: ¿qué equipos y usuarios pueden llegar al PLC, por qué rutas y con qué necesidad operativa?
- Confianza: una vez establecida la comunicación, ¿qué mecanismos permiten comprobar la identidad y proteger los mensajes?
- Resiliencia: si cambia una configuración o se pierde el acceso, ¿cómo recuperamos el control y verificamos el proceso?
Una regla de red puede limitar el alcance de una estación, pero esa decisión no demuestra por sí sola que toda acción originada en ella sea legítima. Conviene revisar también quién administra la estación, qué permisos conserva y cómo se detectan cambios inesperados.
Dónde encaja CIP Security
Según ODVA, CIP Security aporta autenticación de dispositivos, integridad y autenticidad de mensajes y, según la configuración, confidencialidad. Su uso requiere productos y versiones compatibles con los perfiles correspondientes.
No debe interpretarse como una función disponible por defecto en MicroLogix 1100 o 1400. Aquí se introduce como criterio para evaluar arquitecturas y equipos compatibles. No constituye un parche para CVE-2021-33012 ni elimina la necesidad de limitar comunicaciones o gestionar las estaciones autorizadas.
Qué revisaría en una instalación
- Retirar la exposición directa y mediar el acceso remoto mediante una solución controlada.
- Revisar reglas de firewall y listas de acceso según los flujos realmente necesarios.
- Mantener copias offline del proyecto, comprobar su integridad y ensayar la recuperación.
- Vincular cada cambio con un responsable, una autorización y una verificación posterior.
SD1790 advierte que ciertos procedimientos de recuperación borran el programa y requieren una copia del proyecto. La intervención debe seguir la guía específica del modelo y un procedimiento operativo aprobado. Recuperar acceso al dispositivo no demuestra, por sí solo, que el proceso haya quedado en condiciones seguras.
En tu arquitectura actual, ¿qué impide que un dispositivo no autorizado llegue hasta los PLC y qué evidencia tendrías si una estación autorizada actuara de forma inesperada?