El Modelo Purdue sigue siendo el mapa correcto. Dejó de coincidir con el terreno.
Toda conversación sobre seguridad OT empieza por la jerarquía de cinco niveles, y casi toda planta real tiene tráfico que la atraviesa sin detenerse. Esta guía cubre qué son los niveles, qué les hicieron el acceso remoto, el IIoT y la analítica en la nube, y qué aplicar en su lugar cuando rediseñar la red no es una opción.
Última actualización:
¿Qué es el Modelo Purdue?
El Modelo Purdue, formalmente la Purdue Enterprise Reference Architecture (PERA), organiza un sistema de control industrial en niveles, desde el proceso físico en el nivel 0 hasta la TI corporativa en los niveles 4 y 5, con una DMZ industrial en el nivel 3.5 como frontera entre la operación y el negocio. Se escribió en los años noventa en la Universidad de Purdue como modelo de integración industrial, no como control de seguridad. El uso en seguridad vino después y descansa sobre una suposición: que el tráfico se mueve verticalmente, nivel a nivel, y que cada frontera es un sitio donde inspeccionarlo.
Esa suposición es la que ha fallado. Los niveles siguen siendo un vocabulario común excelente, y solo por eso vale la pena conservarlos. Lo que ya no se sostiene es la idea de que el diagrama describe cómo se mueven realmente los paquetes en una planta moderna.
Los niveles del Modelo Purdue y qué vive en cada uno
Seis escalones, contando la DMZ. La numeración sube desde el proceso físico, al revés que la mayoría de diagramas de red, y es una fuente habitual de confusión.
| Nivel | Nombre | Qué hay ahí | Si se compromete |
|---|---|---|---|
| Nivel 5 | Empresa | TI corporativa, ERP, correo, red de negocio. | Interrupción del negocio y un punto de apoyo con camino hacia la operación. |
| Nivel 4 | Negocio del sitio | Planificación de planta, logística, servicios TI del sitio. | La planificación queda expuesta y el atacante está a un salto de la DMZ. |
| Nivel 3.5 | DMZ industrial | La frontera TI/OT: saltos, servidores de parches, intermediarios de datos, historiadores replicados. | Se pierde todo el sentido del modelo. Ambos lados quedan expuestos a la vez. |
| Nivel 3 | Operaciones del sitio | Control de planta, historiadores, estaciones de ingeniería, MES. | Recetas y lógica de control quedan al alcance, y las herramientas de ingeniería escriben hacia abajo. |
| Nivel 2 | Supervisión | SCADA, HMI, consolas de operador DCS. | Se puede mostrar una cosa a los operadores mientras otra ocurre en el proceso. |
| Nivel 1 | Control básico | PLC, RTU, variadores, controladores de seguridad. | La lógica de control puede alterarse. Aquí empiezan las consecuencias físicas. |
| Nivel 0 | Proceso físico | Sensores, actuadores, válvulas, motores. | El proceso en sí. El daño se mide en equipos y seguridad de personas, no en datos. |
El nivel 3.5 es el discutido. No aparece en la PERA original; lo añadió la comunidad de seguridad precisamente porque el modelo no tenía respuesta para la frontera TI/OT. Conviene recordarlo cuando se presenta la DMZ como la idea central del modelo.
Tres flujos que atraviesan la jerarquía sin detenerse
Ninguno es un ataque. Son conexiones ordinarias, autorizadas y aprobadas por el negocio, y por eso cuesta discutirlas y por eso siguen ahí.
El acceso remoto reduce la pila a un solo salto
Una VPN de proveedor termina cerca del borde corporativo y alcanza un salto capaz de hablar con los controladores. En el diagrama ese camino cruza cinco fronteras. En la red es un único salto, y una credencial cubre toda la distancia. La separación existe en el dibujo, no en la tabla de rutas.
El IIoT manda telemetría de lado, fuera del edificio
Una pasarela de borde publica directamente contra un servicio en la nube. Nunca toca los niveles 1, 2 ni 3, así que ninguna frontera la inspecciona, y el camino de vuelta es una entrada sin vigilancia por debajo de todo lo que la DMZ alcanza a ver.
La analítica en la nube borra la línea entre nivel 3 y nivel 4
En cuanto un historiador replica a un panel en la nube, la distinción entre operaciones y negocio es un acuerdo de licencia, no un control de red. Un inquilino de nube comprometido llega a datos de planta que dos cortafuegos debían custodiar.
Por qué la DMZ industrial concentra el riesgo en lugar de reducirlo
La respuesta del modelo a la frontera TI/OT es un cruce único, compartido y muy defendido. Tenía sentido cuando los cruces eran raros. Escala mal cuando todo necesita cruzar.
Una brecha expone ambos lados
Todo lo que importa está delante o detrás de la DMZ. No hay una tercera posición. Comprometer el cruce es comprometer el planteamiento, no una máquina.
Flujos sin relación comparten un único cuello de botella
Sesiones de proveedor, telemetría, distribución de parches y replicación de historiadores pasan por la misma frontera con la misma postura, porque solo hay una que ofrecerles.
La visibilidad termina en el cruce
La DMZ puede registrar que se permitió una conexión. Lo que esa conexión hace después, de este a oeste, sobre una red de planta plana, no es algo que un control de frontera esté situado para ver.
Los cambios llegan con semanas de retraso
Cada integración nueva es una solicitud de regla de cortafuegos. Las reglas se acumulan, nadie retira las viejas, y la política efectiva se aleja de la documentada.
Donde el auditor pide algo que el modelo no sabe producir
Esto suele ser lo que fuerza la conversación. Los marcos se movieron hacia evidencia por activo y por identidad, y una frontera de nivel no la genera.
Zonas y conductos de IEC 62443
La 62443 pide definir zonas por riesgo y los conductos entre ellas, y luego aplicar y documentar ambos. Los niveles Purdue son un punto de partida para las zonas, pero no son lo mismo, y meter un nivel entero en una zona rara vez se sostiene por riesgo.
NIST SP 800-82r3
La revisión actual se apartó de presentar Purdue como la arquitectura de referencia y se movió hacia la segmentación por zonas y el Zero Trust. Citar Purdue como su arquitectura ya no encaja limpiamente con la guía.
NERC CIP-005
El perímetro de seguridad electrónica debe enumerarse, y cada vía de acceso que lo atraviesa debe estar registrada. Los túneles de proveedor que eluden la jerarquía son justo lo que la norma quiere ver listado, y los que menos suelen aparecer en el diagrama.
CMMC y NIST SP 800-171
Se exige mínimo privilegio por sistema, con una traza por acceso. Una segmentación gruesa que mete decenas de activos en una zona de confianza no puede mostrar quién alcanzó qué activo, solo que algo alcanzó la zona.
Qué usar en su lugar, comparado con honestidad
Nada de lo que sigue sustituye al Modelo Purdue como vocabulario. Lo sustituye como estrategia de aplicación, el trabajo para el que nunca se diseñó.
| Enfoque | Qué cambia | Qué cuesta |
|---|---|---|
| Zonas y conductos (IEC 62443) | Las zonas se trazan por riesgo y no por función, y cada conducto entre ellas es explícito y documentado. | Un análisis de riesgo real, y el trabajo político de acordar zonas entre operaciones y TI. |
| Microsegmentación | El radio de impacto pasa a ser un activo o un grupo pequeño, en vez de un nivel entero. | Tradicionalmente un rediseño de VLAN y enrutamiento, y por eso se atasca en plantas existentes. |
| Zero Trust para OT | Identidad y política se comprueban en cada sesión, en vez de deducirse de la subred de origen del paquete. | Una capa de identidad que las redes OT no suelen tener, y algún sitio donde aplicarla. |
| Redes definidas por software | La política se define centralmente y se despliega, con lo que deja de acumularse la deriva de configuración. | Infraestructura y competencias nuevas, en la práctica solo viable en proyectos nuevos. |
| Mantener Purdue y añadir aplicación | Los niveles siguen siendo el lenguaje común; el control real se traslada a una frontera por activo. | Lo menos disruptivo, pero solo funciona si el punto de aplicación puede situarse ante activos que no se pueden modificar. |
Fronteras por activo sin volver a dibujar la red
Casi todas las opciones anteriores dan por hecho que se puede reestructurar la red. En una planta en marcha, con equipos que no se pueden parchear, apagar ni redireccionar, ahí es donde suele morir el proyecto. La alternativa es dejar la topología en paz y poner la frontera delante de los activos que importan, de uno en uno.
Se conecta a la red que ya tiene
El equipo se conecta a la red existente en lugar de cortarla, así que el primer día es de bajo impacto. Después usted dirige hacia él los flujos que quiere proteger, activo por activo, y nada se mueve hasta que usted lo mueve.
Una frontera por activo, no por nivel
Cada activo protegido queda tras su propia frontera aplicada. Alcanzar uno no concede nada hacia el siguiente, así que el movimiento lateral que la DMZ nunca veía no tiene adónde ir.
Identidad en la sesión, no en la subred
Cada conexión se vincula a una identidad con nombre, a un activo concreto y a un protocolo, con un límite temporal. Esa es la evidencia por activo que piden CIP-005, CMMC y la 62443, producida por la operación y no por un proyecto de auditoría aparte.
Funciona con equipos que no pueden cambiar
El activo conserva su IP, su firmware y su configuración. Un controlador de hace dos décadas obtiene la misma frontera aplicada que una estación de ingeniería actual, porque no se le pide nada.
Cómo avanzar sin sustituirlo todo
Nada de esto exige abandonar el modelo ni reconstruir la red. Exige averiguar dónde discrepan el dibujo y la planta, y cerrar las diferencias por orden de prioridad.
- 01
Cartografíe el tráfico que realmente tiene, no el que el diagrama sugiere. Cada VPN, cada pasarela de borde, cada replicación a la nube. La diferencia entre ambos documentos es el hallazgo.
- 02
Ordene los activos por consecuencia y no por nivel. Un controlador de seguridad y un PLC de alumbrado están en el mismo nivel y no son el mismo problema.
- 03
Ponga una frontera delante de los activos de mayor consecuencia primero, y valide el patrón en unos pocos antes de comprometerse a un despliegue.
- 04
Sustituya los túneles compartidos por acceso con nombre, acotado y limitado en el tiempo. Una credencial de proveedor que abre toda una red es la mayor brecha en la mayoría de instalaciones.
- 05
Registre en la frontera que ha creado, no solo en el borde de planta, y establezca qué es normal por activo para que lo anormal se vea.
- 06
Mantenga los niveles Purdue en su documentación y en sus conversaciones. Perder el vocabulario común cuesta más de lo que ahorra.
Llévese el análisis completo.
La versión larga: cómo se erosiona la jerarquía en la práctica, por qué la DMZ industrial concentra el riesgo que debía reducir, y la arquitectura por activo que la sustituye.
12 páginas
Qué aprenderá
Dónde dejan los cinco niveles de describir el tráfico real, y cuál de las tres elusiones suele aparecer primero en una planta existente.
La arquitectura por activo
Cómo desplegar fronteras por activo de forma incremental frente a equipos que no se pueden parchear, redireccionar ni apagar.
Vea cómo es su jerarquía sobre la red
Si su diagrama Purdue y su tráfico real se han separado, podemos repasar dónde están las elusiones en su red y qué haría falta para poner una frontera ante los activos críticos.
Seguridad de redes OT
Cómo se impone una arquitectura de zonas en varios sitios sin rediseñar las VLAN.
Ver la soluciónRepasar su propia topología
Una revisión sobre su instalación: dónde elude el tráfico la jerarquía, qué activos están expuestos y cómo sería la aplicación de políticas.
Preguntas sobre el Modelo Purdue
El nivel de la DMZ industrial, que no aparece en la Purdue Enterprise Reference Architecture original. Lo añadió después la comunidad de seguridad.
Como arquitectura de seguridad, en gran medida sí. Como vocabulario común para describir una instalación industrial, no, y sigue siendo el más útil disponible. La distinción importa: los niveles siguen siendo una buena forma de explicar dónde encaja un sistema, pero la suposición que sostiene el uso en seguridad, que el tráfico cruza los niveles en orden y puede inspeccionarse en cada frontera, ya no es cierta en una planta con acceso remoto de proveedores, pasarelas IIoT y replicación a la nube. Conserve los niveles para describir. No dependa de ellos para aplicar.
El Modelo Purdue es una jerarquía descriptiva de niveles funcionales. IEC 62443 es una norma que pide definir zonas por riesgo, definir los conductos entre ellas y aplicar y documentar requisitos de seguridad para cada una. Los niveles Purdue se usan a menudo como primer borrador de las zonas 62443, pero no son equivalentes, porque una zona se define por riesgo compartido y no por función compartida. Dos activos del mismo nivel Purdue pertenecen con frecuencia a zonas distintas.
Describen cosas sin relación y no son alternativas. El modelo OSI tiene siete capas que describen cómo se estructura una comunicación de red, desde la señalización física hasta la aplicación. El Modelo Purdue tiene niveles que describen dónde encajan los sistemas en una planta, desde el proceso físico hasta la TI corporativa. OSI responde a cómo se construye un paquete; Purdue responde a qué hace una máquina y dónde pertenece.
El nivel 0 es el proceso físico, sensores y actuadores. El nivel 1 es el control básico, los PLC, RTU y controladores de seguridad. El nivel 2 es la supervisión, SCADA y HMI. El nivel 3 son las operaciones del sitio, historiadores, MES y estaciones de ingeniería. El nivel 3.5 es la DMZ industrial, la frontera TI/OT. Los niveles 4 y 5 son el negocio del sitio y la TI corporativa. La numeración sube desde el proceso físico, al revés que la mayoría de diagramas de red.
No, y plantearlo como una elección no suele ayudar. El movimiento productivo es conservar los niveles como documentación y lenguaje común, y cambiar dónde ocurre la aplicación: de una frontera entre niveles a una frontera delante de cada activo, con la identidad comprobada en cada sesión. En la práctica la mayoría de instalaciones acaban con Purdue en la pared y aplicación por activo en la red, lo cual es una posición coherente y no un compromiso.
