graph TD subgraph Vector_Ataque ["Vectores de Ataque Comunes"] IT["Phishing a Empleado IT"] -->|"Movimiento Lateral"| SCADA USB["Pendrive Infectado"] -->|"Conexión Local"| SCADA end subgraph SCADA_Layer ["Nivel de Supervisión (Windows/Linux)"] SCADA["Servidor SCADA
Vulnerabilidades:
- OS Obsoleto (Win 7/XP)
- Sin parchear
- Contraseñas débiles"] end subgraph Control_Layer ["Nivel de Control (PLCs)"] PLC["PLC Industrial
Vulnerabilidades:
- Protocolos en claro
- Sin Autenticación
- Lógica sin cifrar"] end SCADA -->|"Tráfico Modbus/S7
con payloads maliciosos"| PLC style IT fill:#e74c3c,color:#fff style USB fill:#e74c3c,color:#fff style SCADA fill:#f39c12,color:#fff style PLC fill:#27ae60,color:#fff

1. El Mito del "Air Gap"

Durante muchos años, la industria confió en una única medida de seguridad: el Air Gap (Aislamiento Físico). Se creía que si la red de la fábrica no estaba conectada a Internet, era inhackeable. Hoy, este concepto ha muerto. La Industria 4.0 exige extracción de datos, mantenimiento remoto y actualizaciones. Incluso si aislas la red, basta con que un operario de mantenimiento introduzca un Pendrive (USB) para actualizar un programa o descargar un log, cruzando instantáneamente el "Air Gap" e infectando la planta desde dentro.



2. Vulnerabilidades en el Nivel SCADA (Capa de Supervisión)

Los sistemas SCADA y las HMIs de gama alta suelen ejecutarse sobre sistemas operativos comerciales (Windows o Linux). Esto los convierte en el "eslabón débil" preferido por los atacantes, ya que sufren de las mismas vulnerabilidades que cualquier PC, pero agravadas por las limitaciones del entorno industrial:

  • Sistemas Operativos Obsoletos: Es muy común encontrar fábricas operando con Windows XP o Windows 7. Las empresas temen actualizar el SO por miedo a que el software SCADA antiguo deje de funcionar. Estos sistemas ya no reciben parches de seguridad de Microsoft.
  • Falta de Parcheo: Incluso con sistemas modernos, los parches no se instalan por miedo a parar la producción (Prioridad Disponibilidad - AIC).
  • Contraseñas Hardcodeadas y por Defecto: Muchos sistemas industriales traen contraseñas por defecto (ej. `admin` / `admin`) que jamás se cambian. Además, el software a menudo guarda contraseñas de base de datos en texto claro dentro de sus archivos de configuración.


3. Vulnerabilidades en el Nivel PLC (Capa de Control)

Si el SCADA es comprometido, el atacante tiene acceso directo a los PLCs. Históricamente, los PLCs fueron diseñados bajo el principio de "confianza implícita": asumen que cualquier mensaje que llega a su puerto de red es una orden legítima de un superior. Sus principales debilidades son:

  • Falta de Autenticación de Protocolos: Protocolos como Modbus TCP, DNP3 o versiones antiguas de S7 Comm no requieren usuario ni contraseña. Cualquiera en la red puede enviar la instrucción "Escribir Bobina 1 a True" y el PLC obedecerá ciegamente.
  • Lógica en Claro e Insegura: En PLCs antiguos, el programa (Ladder/SCL) viaja por la red sin cifrar. Un atacante puede esnifarlo, modificarlo y volver a inyectarlo (Replay Attack o Man-in-the-Middle) alterando el comportamiento de la máquina.
  • Denegación de Servicio (DoS): Los procesadores de red de los PLCs son frágiles. Una ráfaga de tráfico de red malformado o simplemente un exceso de peticiones Ping puede hacer colapsar la CPU del PLC, forzando una parada de emergencia de la planta.


4. El Cambio de Paradigma: Secure by Design

Afortunadamente, el sector está reaccionando. Los fabricantes (como Siemens, Rockwell o Schneider) están implementando medidas Secure by Design en las nuevas generaciones de controladores (ej. S7-1500). Esto incluye comunicaciones de programación cifradas con TLS, autenticación de usuario nativa en la CPU, deshabilitación de protocolos legacy por defecto, y firmas digitales en el firmware para evitar "downgrades" (intentos de cargar firmware antiguo y vulnerable).

El reto del técnico de UF1794 es proteger el hardware "legacy" existente utilizando topologías de Defensa en Profundidad (Zonas y Conductos con DPI) hasta que la maquinaria pueda ser renovada por equipos modernos.

Infografía de vectores de ataque desde IT y medios extraíbles hacia el nivel SCADA y posteriormente hacia el control del PLC.
Figura 1: El flujo clásico de un ciberataque industrial (Kill Chain). Los atacantes rara vez atacan al PLC directamente. Primero vulneran un eslabón débil (como un PC de oficina mediante Phishing o un pendrive USB). Desde ahí, realizan un "movimiento lateral" hasta el Servidor SCADA, que a menudo corre sistemas obsoletos sin parchear. Una vez controlado el SCADA, utilizan los propios protocolos industriales sin autenticación para enviar comandos maliciosos al PLC, destruyendo el proceso.
Fuente: Elaboración propia / Licencia: CC BY-NC 4.0.

📝 Evaluación Técnica: Vulnerabilidades OT

1. ¿Por qué el concepto de seguridad basado exclusivamente en el "Air Gap" (aislamiento físico total de la red de la fábrica) se considera actualmente obsoleto y peligroso?

2. ¿Cuál es el motivo principal por el que es tan común encontrar Servidores SCADA corriendo sobre sistemas operativos obsoletos y altamente vulnerables (como Windows XP) en el entorno industrial?

3. Muchos PLCs "legacy" (antiguos) son vulnerables a un ataque denominado "Replay Attack" (Ataque de Repetición). ¿Qué vulnerabilidad en los protocolos industriales clásicos permite este ataque?

🤖 Ejercicio Práctico 7: Simulador de Inyección de Comandos (Python)

Objetivo: Demostrar la extrema vulnerabilidad de los protocolos no autenticados simulando cómo unas pocas líneas de código pueden alterar un PLC.

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un analista de ciberseguridad industrial mostrando un vector de ataque didáctico. Escribe un script en Python utilizando `pyModbusTCP` para simular un ataque de inyección de comandos. El script debe: 1. Suponer que el atacante ya está dentro de la red local (por ejemplo, habiendo infectado un portátil de mantenimiento conectado a la red OT). 2. Conectarse a la IP del PLC víctima (usa '127.0.0.1' y puerto 502 para simulación local). 3. Sin necesidad de pasar por ninguna pantalla de login ni proporcionar contraseñas, enviar el comando `write_single_coil(0, True)`, simulando la orden de "Encender la bomba principal" que el atacante envía maliciosamente. 4. Leer el estado de la bobina para confirmar que el ataque tuvo éxito y mostrar un mensaje: "[!] ATAQUE COMPLETADO: El PLC obedeció la orden sin requerir autenticación." Comenta el código explicando que, en el mundo real, los firewalls internos (DPI) y la segmentación en Zonas son los únicos salvavidas contra esta falta de seguridad nativa de los protocolos.