Wywodzi się z prac nad produkcją zintegrowaną komputerowo i wpłynął na hierarchię funkcjonalną używaną przez ISA-95 i IEC 62264. Architekci bezpieczeństwa powszechnie adaptują warstwy do rozumowania o granicach zaufania, ścieżkach komunikacji i umiejscowieniu przemysłowej strefy DMZ.
Model jest sposobem opisywania funkcji, a nie obowiązkowym planem sieci. Numeracja warstw i znajoma strefa DMZ „Level 3.5" różnią się między implementacjami, a nowoczesne środowisko może obejmować usługi chmurowe, edge computing, systemy bezprzewodowe, urządzenia IIoT, operacje zdalne i platformy współdzielone, które nie mieszczą się w prostej hierarchii pionowej. Decyzje architektoniczne powinny wynikać z rzeczywistych funkcji, zagrożeń, własności i przepływów danych.
Najważniejsze punkty
Zmapuj to, co istniejeUmieszczaj zasoby według funkcji operacyjnej i zależności, a nie według nazwy urządzenia, dostawcy, zakresu IP czy idealizowanego diagramu.
Zidentyfikuj wymagane przepływyDokumentuj źródło, cel, kierunek, protokół, timing, cel i zachowanie przy awarii przed projektowaniem granic.
Egzekwuj separacjęUżywaj zapór sieciowych, proxy, bram jednokierunkowych, IDMZ lub innych odpowiednich kontroli, by zapobiegać niepotrzebnej bezpośredniej komunikacji między odległymi poziomami zaufania.
Dokumentuj wyjątkiRejestruj połączenia chmurowe, zdalne, bezpieczeństwa, mobilne i międzyzakładowe, które omijają lub rozszerzają hierarchię, przypisuj właścicieli i stosuj kontrole kompensujące.
Istotne ograniczenieDiagram Purdue nie jest dowodem segmentacji ani bezpieczeństwa. Płaskie trasy, współdzielone poświadczenia, niezarządzane łącza serwisowe, podatne usługi graniczne lub źle zaprojektowane zachowanie przy awarii mogą pokonać zamierzoną architekturę i zakłócić operacje.