Alertas del PLC al móvil y el modelo Purdue: ¿cuándo está bien saltarse el SCADA?

De Prompt a Planta es la serie donde compartimos, en abierto y completos, los prompts que permiten programar un PLC de Industrial Shields con Claude Code. Este artículo responde a la mejor pregunta que recibió el episodio 1.

La pregunta

En el episodio 1, programamos un ESP32 PLC 14 para enviar alertas de fallo de bomba directas al móvil por Telegram — sin SCADA, sin servidor intermedio. Un lector hizo la pregunta que todo ingeniero de control debería hacer:

"¿Cómo interfiere esto con el modelo Purdue para la seguridad de ICS?"

Es una pregunta justa, y la respuesta honesta da para un artículo.

Qué dice el modelo Purdue

El modelo Purdue es la arquitectura de referencia clásica de las redes industriales. Organiza la planta en niveles — sensores (0), controladores/PLCs (1), supervisión/SCADA (2), operaciones (3), una DMZ (3,5) y la red de oficina/internet (4-5) — y manda que el tráfico suba nivel a nivel, a través de fronteras controladas. Un PLC hablando directamente con una API de internet salta del nivel 1 al 5. En lectura estricta, es exactamente lo que el modelo existe para evitar.

La seguridad es proporcional a lo que proteges

Aquí está la parte que suele perderse: el modelo Purdue describe plantas que tienen arquitectura OT. Una parte enorme de las instalaciones reales no la tiene. Una estación de bombeo en el campo. Un taller con tres máquinas. Una línea aislada. Sin SCADA, sin red segmentada, sin DMZ — y sin ninguna alerta. Quien lleva esa máquina no está pensando en arquitecturas de referencia cuando se le para a las 3 de la mañana: solo quiere saberlo. Enterarse tres horas tarde tiene un coste muy real.

Para esas instalaciones, la alternativa realista a "el PLC envía un Telegram" no es una arquitectura Purdue completa. Es que nadie se entere en horas. Seguridad basada en riesgo significa comparar el patrón contra la alternativa real, no contra una arquitectura de referencia que esa instalación nunca tuvo.

Aun así, el patrón del episodio 1 es deliberadamente conservador:

• Solo saliente. El PLC abre una conexión TLS hacia fuera al puerto 443. No se abre ningún puerto de entrada; el PLC no es alcanzable desde internet.
• Solo notifica. Envía cambios de estado; no consulta ni acepta comandos entrantes.
• La salida se puede clavar. En el router o firewall, permite tráfico saliente solo hacia api.telegram.org, y nada más.
• Hardware solo-entradas. Si el PLC solo tiene entradas cableadas (monitorización pura, sin salidas), el peor caso de un compromiso es una alerta falsa o perdida — nunca una actuación sobre la máquina.
• Segmento de red propio. Cuelga el PLC de monitorización de su propia VLAN o de una SIM 4G: ni ve ni toca ningún otro nivel.

Dos líneas que importan. Primera: la alerta no es seguridad funcional — la protección de la máquina sigue siendo el relé térmico cableado; el mensaje de Telegram es una notificación adicional de mejor esfuerzo, nunca una capa de seguridad. Segunda: la precisión cuenta al defender el patrón — que el firmware no acepte comandos es una decisión de diseño verificada en la revisión de código (nunca consulta actualizaciones), no una imposibilidad arquitectónica: una conexión saliente establecida puede traer datos de vuelta si el código los pide. Esa puerta de revisión es parte de la seguridad.

Si tu planta SÍ tiene arquitectura OT: no saltes niveles

En una planta segmentada, el patrón directo es el equivocado — y el correcto ya está en el episodio 1 como "variante": el PLC publica sus eventos por MQTT a un broker en la DMZ (o nivel 2/3), y un servicio de esa zona — Node-RED, por ejemplo — es lo único que habla con internet. El PLC nunca sale de su zona; el notificador es un conducto controlado que puedes auditar, parchear y revocar en un solo sitio.

La superficie de programación

El hilo que originó este artículo levantó una segunda pregunta afilada: ¿cómo se programa el PLC — y es eso una puerta? La primera vez, por USB. Después puedes habilitar actualizaciones OTA por red para que nadie tenga que desplazarse hasta el cuadro — y esa superficie se decide al compilar: si no incluyes el soporte OTA en el firmware, ese camino simplemente no existe; no hay ningún servicio escuchando que proteger. Si lo habilitas, va con contraseña, firmware firmado y acceso solo desde la VLAN de mantenimiento. En corto: el firmware lo capa. "Expuesto" no es una propiedad del equipo — es una propiedad de lo que le compilas, y eso es exactamente lo que verifica la revisión de ingeniería.

IEC 62443, en tres ideas

El estándar moderno y certificable de seguridad ICS es IEC 62443. Si Purdue es el dibujo clásico, la 62443 es el reglamento vigente. Tres ideas cubren casi cualquier conversación:

1. Zonas y conductos. Agrupa los activos en zonas por criticidad; define los conductos controlados por los que las zonas pueden hablarse. El patrón DMZ de arriba es exactamente esto.
2. Niveles de seguridad (SL1-SL4). Cada zona recibe la protección que su modelo de amenaza requiere — del error accidental (SL1) al atacante profesional (SL4). No todo necesita SL4; decidirlo conscientemente es la clave.
3. Roles. El estándar reparte deberes entre fabricante del producto, integrador y propietario del activo. Cada uno tiene su parte.

El checklist honesto

• Activo aislado, sin red OT, sin alertas hoy → el patrón directo solo-saliente es una mejora pragmática. Clava la salida en el firewall, mantenlo solo-notificación y solo-entradas si es posible, valida en banco.
• Planta segmentada con SCADA/DMZ → el PLC publica MQTT dentro de su zona; un servicio de la DMZ envía la notificación. Nunca nivel 1 → internet.
• Endurecimiento para producción → valida el certificado TLS (fija la CA en vez de saltarte la verificación), trata el token del bot como una credencial (rótalo y nunca lo subas a un repositorio), y ten un plan de actualización del firmware.
• En ambos casos → la IA escribe el código, el ingeniero lo revisa, y la misma puerta de revisión aplica tanto si el código lo escribió un humano como un modelo.

Cada semana, un prompt real y verificado. Este artículo nació de la pregunta de un lector — que sigan llegando. Archivo completo y próximos episodios en este blog, y en la newsletter De Prompt a Planta.