"Modelo Purdue" suena a jerga de consultor, que te va a cobrar una lanota. Pero detrás del nombre hay algo muy práctico: es el mapa que explica por qué una red industrial no se protege como una red de oficina, sino por capas. Para la gente que viene de TI, pudieramos hacer una analogía un tanto burda con el modelo OSI. Si entiendes este mapa, entiendes casi todas las decisiones de seguridad que vienen después.
Es la continuación natural de una idea que ya planteamos: por qué IT y OT no son lo mismo. El modelo Purdue es la forma de ordenar esa diferencia.
Qué es el modelo Purdue (y para qué sirve de verdad)
Nació hace décadas como una forma de describir cómo se organiza la información en una planta industruial, desde el sensor que mide una variable análoga (cómo temperatura, presión, etc.) hasta el sistema corporativo que factura, como SAP. Con el tiempo se convirtió en la referencia estándar para segmentar redes industriales: no es un reglamento, es un mapa de niveles que ayuda a decidir qué habla con qué, y qué nunca debería hacerlo.
Modelo Purdue: de la planta (OT, abajo) a la empresa (TI, arriba), con la DMZ industrial como frontera.
De abajo hacia arriba: los niveles
El modelo se lee como se opera una planta, desde el mundo físico hacia el negocio:
- Nivel 0 — Proceso físico: sensores, actuadores y motores. El mundo real que se mide y se mueve.
- Nivel 1 — Control básico: los PLC, RTU y DCS que dan las órdenes a ese mundo físico.
- Nivel 2 — Supervisión de área: el SCADA y las HMI, las pantallas desde donde un operador vigila y ajusta.
- Nivel 3 — Operaciones del sitio: MES, historian y los sistemas que coordinan la producción de toda la planta.
- Niveles 4 y 5 — Negocio y corporativo: correo, ERP, ofimática, internet. Esto ya es TI pura y dura, la de siempre.
Los niveles 0 a 3 son OT. Los niveles 4 y 5 son TI. Y entre ambos mundos hay una pieza que decide casi todo.
La frontera que de verdad importa: la DMZ industrial
El nivel 3.5, la DMZ industrial, es el corazón del modelo desde la óptica de seguridad. La regla es sencilla de enunciar y difícil de respetar: ningún sistema de TI habla directamente con un sistema de OT. Todo lo que necesita cruzar —replicar datos del historian para que negocio los consulte, bajar parches, dar acceso remoto a un proveedor— pasa por esa zona intermedia, esa frontera, de forma controlada y auditable.
¿Por qué importa tanto? Porque es lo que contiene un ataque que empezó en la oficina. Si un ransomware entra por un correo en el nivel 4 y no existe esa frontera, tiene línea directa hacia los controladores que mueven la producción. Con una DMZ bien hecha, el ataque se queda del lado de TI. Esa es la diferencia entre un susto y una planta detenida.
Por qué el modelo casi nunca está limpio en la realidad
Aquí toca ser honestos: en campo, el diagrama perfecto es la excepción, no la regla. Lo que se encuentra con más frecuencia es una red plana donde la HMI, el ERP y la laptop de un contratista conviven en el mismo segmento; equipos de control de hace quince años con sistemas operativos sin soporte; y accesos remotos que alguien habilitó "temporalmente" hace tres años para no manejar hasta la planta, saltándose todos los niveles de una sola vez.
Nada de esto se hizo por negligencia. Se hizo para que la producción no se detuviera, que es la prioridad legítima de quien opera una planta. El problema es que esas soluciones prácticas son exactamente los caminos que un atacante recorre. El modelo Purdue no sirve para juzgar ese desorden, sino para ordenarlo: muestra dónde deberían estar las fronteras que hoy no existen.
Cómo usarlo sin volverlo dogma
El error opuesto también existe: tratar el modelo como una receta que hay que implementar al pie de la letra, con los cinco niveles y sus DMZ, cueste lo que cueste. Para la mayoría de las empresas eso ni es necesario ni es realista de golpe.
Lo útil es usarlo como referencia para decidir por dónde empezar: identificar qué cruza hoy la frontera entre TI y OT, cuáles de esos cruces son injustificables, y construir la segmentación de forma gradual, priorizando por riesgo. Ese ejercicio —mapear la realidad contra el modelo— es la base del servicio de ciberseguridad OT/industrial que operamos, y casi siempre revela más de lo que la empresa esperaba.
Porque la pregunta que el modelo Purdue ayuda a responder no es "¿tengo los cinco niveles bien dibujados?", sino una mucho más incómoda y más útil: ¿qué está cruzando ahora mismo entre mi oficina y mi planta, y quién lo autorizó?