Es entstand aus Arbeiten zur rechnerintegrierten Fertigung und beeinflusste die Funktionshierarchie von ISA-95 und IEC 62264. Sicherheitsarchitekten adaptieren die Ebenen üblicherweise, um über Vertrauensgrenzen, Kommunikationspfade und die Platzierung einer industriellen DMZ zu argumentieren.
Das Modell beschreibt Funktionen und ist keine verbindliche Netzwerk-Blaupause. Ebenennummerierung und die vertraute „Level-3.5"-DMZ variieren zwischen Implementierungen, und eine moderne Umgebung kann Cloud-Dienste, Edge Computing, Funksysteme, IIoT-Geräte, Remote-Betrieb und geteilte Plattformen umfassen, die nicht in eine einfache vertikale Hierarchie passen. Architekturentscheidungen sollten den tatsächlichen Funktionen, Gefährdungen, Verantwortlichkeiten und Datenflüssen folgen.
Wichtigste Punkte
Bestand abbildenAssets nach betrieblicher Funktion und Abhängigkeit einordnen, nicht nach Gerätename, Lieferant, IP-Bereich oder einem idealisierten Diagramm.
Erforderliche Flüsse identifizierenQuelle, Ziel, Richtung, Protokoll, Zeitverhalten, Zweck und Fehlerverhalten dokumentieren, bevor Grenzen entworfen werden.
Trennung durchsetzenFirewalls, Proxies, unidirektionale Gateways, eine IDMZ oder andere geeignete Kontrollen einsetzen, um unnötige direkte Kommunikation zwischen entfernten Vertrauensebenen zu verhindern.
Ausnahmen dokumentierenCloud-, Remote-, Safety-, Mobilfunk- und standortübergreifende Verbindungen erfassen, die die Hierarchie umgehen oder erweitern, Eigentümer zuweisen und kompensierende Kontrollen anwenden.
Wichtige EinschränkungEin Purdue-Diagramm ist kein Nachweis von Segmentierung oder Safety. Flache Routen, geteilte Credentials, unverwaltete Wartungsverbindungen, verwundbare Grenzdienste oder schlecht entworfenes Fehlerverhalten können die beabsichtigte Architektur besiegen und den Betrieb stören.