Das Purdue-Modell ist weiterhin die richtige Karte. Zum Gelände passt sie nicht mehr.
Jedes Gespräch über OT-Sicherheit beginnt mit der fünfstufigen Hierarchie, und in fast jeder realen Anlage läuft Verkehr mitten hindurch. Dieser Leitfaden erklärt, was die Ebenen sind, was Fernzugriff, IIoT und Cloud-Analytik aus ihnen gemacht haben, und was stattdessen durchzusetzen ist, wenn ein Netzumbau nicht zur Debatte steht.
Zuletzt aktualisiert:
Was ist das Purdue-Modell?
Das Purdue-Modell, formal die Purdue Enterprise Reference Architecture (PERA), gliedert ein industrielles Steuerungssystem in Ebenen, vom physischen Prozess auf Ebene 0 bis zur Unternehmens-IT auf den Ebenen 4 und 5, mit einer industriellen DMZ auf Ebene 3.5 als Grenze zwischen Betrieb und Geschäft. Es entstand in den 1990er-Jahren an der Purdue University als Modell für Fertigungsintegration, nicht als Sicherheitsmaßnahme. Die sicherheitstechnische Nutzung kam später und beruht auf einer Annahme: dass Verkehr sich vertikal bewegt, Ebene für Ebene, und dass jede Grenze eine Stelle ist, an der man ihn prüfen kann.
Genau diese Annahme ist gefallen. Die Ebenen bleiben ein ausgezeichnetes gemeinsames Vokabular, und schon deshalb lohnt es sich, sie zu behalten. Was nicht mehr trägt, ist die Vorstellung, das Schaubild beschreibe, wie Pakete in einer modernen Anlage tatsächlich laufen.
Die Ebenen des Purdue-Modells und was auf jeder liegt
Sechs Stufen, die DMZ mitgezählt. Die Nummerierung steigt vom physischen Prozess aufwärts, umgekehrt zu den meisten Netzdiagrammen, und ist eine klassische Verwechslungsquelle.
| Ebene | Name | Was dort liegt | Bei Kompromittierung |
|---|---|---|---|
| Ebene 5 | Unternehmen | Unternehmens-IT, ERP, E-Mail, das weitere Geschäftsnetz. | Geschäftsunterbrechung, und ein Standbein mit Weg Richtung Betrieb. |
| Ebene 4 | Standortgeschäft | Werksplanung, Logistik, Standort-IT. | Die Planung liegt offen und der Angreifer ist einen Sprung von der DMZ entfernt. |
| Ebene 3.5 | Industrielle DMZ | Die IT/OT-Grenze: Sprungserver, Patch-Server, Datenbroker, replizierte Historians. | Der ganze Sinn des Modells entfällt. Beide Seiten liegen gleichzeitig offen. |
| Ebene 3 | Standortbetrieb | Werksweite Steuerung, Historians, Engineering-Arbeitsplätze, MES. | Rezepturen und Steuerlogik sind erreichbar, und Engineering-Werkzeuge schreiben nach unten. |
| Ebene 2 | Leitebene | SCADA, HMI, DCS-Bedienstationen. | Dem Bedienpersonal lässt sich eines anzeigen, während am Prozess anderes geschieht. |
| Ebene 1 | Basissteuerung | SPS, Fernwirkeinheiten, Antriebe, Sicherheitssteuerungen. | Steuerlogik kann verändert werden. Hier beginnen die physischen Folgen. |
| Ebene 0 | Physischer Prozess | Sensoren, Aktoren, Ventile, Motoren. | Der Prozess selbst. Schaden bemisst sich in Anlagen und Personensicherheit, nicht in Daten. |
Ebene 3.5 ist die umstrittene. Sie steht überhaupt nicht in der ursprünglichen PERA; die Sicherheitsgemeinde hat sie ergänzt, gerade weil das Modell keine Antwort auf die IT/OT-Grenze hatte. Das ist zu bedenken, wenn die DMZ als Kernidee des Modells dargestellt wird.
Drei Verbindungen, die mitten durch die Hierarchie laufen
Keine davon ist ein Angriff. Es sind gewöhnliche, genehmigte, vom Geschäft abgesegnete Verbindungen, weshalb sie schwer zu bestreiten sind und weshalb es sie weiterhin gibt.
Fernzugriff schrumpft den Stapel auf einen Sprung
Ein Lieferanten-VPN endet nahe der Unternehmensgrenze und erreicht einen Sprungserver, der mit Steuerungen spricht. Auf dem Schaubild kreuzt dieser Weg fünf Grenzen. Auf dem Netz ist es ein einziger Sprung, und eine Zugangsberechtigung deckt die ganze Strecke. Die Trennung besteht in der Zeichnung, nicht in der Routing-Tabelle.
IIoT schickt Telemetrie seitwärts aus dem Gebäude
Ein Edge-Gateway veröffentlicht direkt an einen Cloud-Endpunkt. Es berührt die Ebenen 1, 2 und 3 nie, also prüft es keine Grenze, und der Rückweg ist ein unbeobachteter Zugang unterhalb von allem, was die DMZ sehen kann.
Cloud-Analytik löscht die Linie zwischen Ebene 3 und 4
Sobald ein Historian in ein Cloud-Dashboard repliziert, ist die Unterscheidung zwischen Standortbetrieb und Geschäft eine Lizenzfrage, keine Netzkontrolle. Ein kompromittierter Cloud-Mandant erreicht Anlagendaten, vor denen zwei Firewalls stehen sollten.
Warum die industrielle DMZ Risiko bündelt statt es zu senken
Die Antwort des Modells auf die IT/OT-Grenze ist ein einziger, gemeinsam genutzter, stark verteidigter Übergang. Das war sinnvoll, als Übergänge selten waren. Es skaliert schlecht, wenn alles hinüber muss.
Ein Einbruch legt beide Seiten offen
Alles Wesentliche liegt entweder vor oder hinter der DMZ. Eine dritte Position gibt es nicht. Wer den Übergang kompromittiert, hat die Anordnung kompromittiert, nicht einen Host.
Alles Ungleiche teilt sich einen Engpass
Lieferantensitzungen, Telemetrie, Patch-Verteilung und Historian-Replikation laufen durch dieselbe Grenze mit derselben Haltung, weil es nur eine gibt, die man ihnen geben kann.
Die Sichtbarkeit endet am Übergang
Die DMZ kann protokollieren, dass eine Verbindung erlaubt wurde. Was diese Verbindung danach tut, von Ost nach West, über ein flaches Anlagennetz, ist nichts, wofür eine Grenzkontrolle positioniert ist.
Änderungen hinken dem Betrieb um Wochen hinterher
Jede neue Anbindung ist ein Firewall-Regelantrag. Die Regeln häufen sich, niemand entfernt die alten, und die wirksame Richtlinie entfernt sich von der dokumentierten.
Wo Prüfer etwas verlangen, das das Modell nicht liefern kann
Das erzwingt oft das Gespräch. Die Regelwerke haben sich zu Nachweisen je Asset und je Identität bewegt, und eine Ebenengrenze erzeugt solche nicht.
Zonen und Conduits nach IEC 62443
Die 62443 verlangt, Zonen nach Risiko und die Conduits dazwischen zu definieren und beides durchzusetzen und zu dokumentieren. Purdue-Ebenen sind ein Ausgangspunkt für Zonen, aber nicht dasselbe, und eine ganze Ebene als eine Zone zu führen, ist risikoseitig meist nicht haltbar.
NIST SP 800-82r3
Die aktuelle Fassung stellt Purdue nicht mehr als Referenzarchitektur dar, sondern rückt zonenbasierte Segmentierung und Zero Trust in den Vordergrund. Purdue als eigene Architektur anzuführen, deckt sich nicht mehr sauber mit der Leitlinie.
NERC CIP-005
Der elektronische Sicherheitsperimeter muss aufgezählt und jeder Zugriffsweg hindurch erfasst sein. Lieferantentunnel, die die Hierarchie umgehen, sind genau das, was die Norm gelistet sehen will, und stehen am seltensten im Schaubild.
CMMC und NIST SP 800-171
Minimalrechte werden je System verlangt, mit einem Nachweis je Zugriff. Grobe Segmentierung, die Dutzende Assets in eine Vertrauenszone legt, kann nicht zeigen, wer welches Asset erreicht hat, nur dass etwas die Zone erreicht hat.
Was stattdessen taugt, ehrlich verglichen
Nichts davon ersetzt das Purdue-Modell als Vokabular. Was folgt, ersetzt es als Durchsetzungsstrategie, also in der Rolle, für die es nie entworfen wurde.
| Ansatz | Was sich ändert | Was es kostet |
|---|---|---|
| Zonen und Conduits (IEC 62443) | Zonen werden nach Risiko statt nach Funktion gezogen, und jeder Conduit dazwischen ist ausdrücklich und dokumentiert. | Eine echte Risikobetrachtung und die politische Arbeit, Zonen zwischen Betrieb und IT abzustimmen. |
| Mikrosegmentierung | Der Wirkungsradius wird ein Asset oder eine kleine Gruppe statt einer ganzen Ebene. | Traditionell ein VLAN- und Routing-Umbau, weshalb es an Bestandsanlagen scheitert. |
| Zero Trust für OT | Identität und Richtlinie werden je Sitzung geprüft, statt aus dem Subnetz des Pakets geschlossen zu werden. | Eine Identitätsschicht, die OT-Netze meist nicht haben, und einen Ort, sie durchzusetzen. |
| Software-definierte Netze | Richtlinien werden zentral definiert und ausgerollt, sodass sich keine Konfigurationsdrift mehr ansammelt. | Neue Infrastruktur und neues Betriebs-Know-how, praktisch nur auf der grünen Wiese. |
| Purdue behalten, Durchsetzung ergänzen | Die Ebenen bleiben die gemeinsame Sprache; die eigentliche Kontrolle wandert an eine Grenze je Asset. | Am wenigsten störend, funktioniert aber nur, wenn der Durchsetzungspunkt vor Assets treten kann, die sich nicht ändern lassen. |
Grenzen je Asset, ohne das Netz neu zu zeichnen
Die meisten Optionen oben setzen voraus, dass sich das Netz umbauen lässt. In einer laufenden Anlage mit Geräten, die sich nicht patchen, abschalten oder umadressieren lassen, stirbt das Projekt üblicherweise genau dort. Die Alternative ist, die Topologie in Ruhe zu lassen und die Grenze vor die Assets zu setzen, auf die es ankommt, eines nach dem anderen.
Sie tritt dem vorhandenen Netz bei
Die Appliance verbindet sich mit dem bestehenden Netz, statt es aufzutrennen, der erste Tag ist also wirkungsarm. Danach lenken Sie die zu schützenden Flüsse Asset für Asset über sie, und nichts bewegt sich, bevor Sie es bewegen.
Eine Grenze je Asset, nicht je Ebene
Jedes geschützte Asset sitzt hinter seiner eigenen durchgesetzten Grenze. Eines zu erreichen bringt nichts in Richtung des nächsten, die Seitwärtsbewegung, die der DMZ verborgen blieb, hat also kein Ziel mehr.
Identität an der Sitzung, nicht am Subnetz
Jede Verbindung ist an eine benannte Identität, ein bestimmtes Asset und ein Protokoll gebunden, mit Zeitgrenze. Das ist der Nachweis je Asset, den CIP-005, CMMC und die 62443 verlangen, erzeugt aus dem Betrieb statt aus einem separaten Audit-Projekt.
Sie funktioniert an Geräten, die sich nicht ändern lassen
Das Asset behält seine IP, seine Firmware und seine Konfiguration. Eine zwanzig Jahre alte Steuerung erhält dieselbe durchgesetzte Grenze wie ein aktueller Engineering-Arbeitsplatz, weil von der Steuerung nichts verlangt wird.
Wie man vorankommt, ohne alles zu ersetzen
Nichts davon verlangt, das Modell aufzugeben oder das Netz neu zu bauen. Es verlangt herauszufinden, wo Zeichnung und Anlage auseinandergehen, und die Lücken nach Priorität zu schließen.
- 01
Erfassen Sie den Verkehr, den Sie tatsächlich haben, nicht den, den das Schaubild nahelegt. Jedes VPN, jedes Edge-Gateway, jeden Cloud-Replikationsjob. Die Differenz zwischen beiden Unterlagen ist der Befund.
- 02
Ordnen Sie Assets nach Konsequenz statt nach Ebene. Eine Sicherheitssteuerung und eine Beleuchtungs-SPS liegen auf derselben Ebene und sind nicht dasselbe Problem.
- 03
Setzen Sie zuerst eine Grenze vor die Assets mit der größten Konsequenz und erproben Sie das Muster an einer Handvoll, bevor Sie einen Rollout zusagen.
- 04
Ersetzen Sie geteilte Tunnel durch benannten, eng gefassten, zeitlich begrenzten Zugriff. Eine Lieferanten-Zugangsberechtigung, die ein ganzes Netz öffnet, ist in den meisten Beständen die größte einzelne Lücke.
- 05
Protokollieren Sie an der Grenze, die Sie geschaffen haben, nicht nur am Anlagenrand, und legen Sie je Asset fest, was normal ist, damit das Unnormale auffällt.
- 06
Behalten Sie die Purdue-Ebenen in Dokumentation und Gesprächen. Das gemeinsame Vokabular zu verlieren kostet mehr, als es einspart.
Nehmen Sie die vollständige Analyse mit.
Die Langfassung: wie die Hierarchie in der Praxis erodiert, warum die industrielle DMZ genau das Risiko bündelt, das sie senken sollte, und die Architektur je Asset, die an ihre Stelle tritt.
12 Seiten
Was Sie erfahren
Wo die fünf Ebenen aufhören, realen Verkehr zu beschreiben, und welche der drei Umgehungen an einer Bestandsanlage meist zuerst vorliegt.
Die Architektur je Asset
Wie sich Grenzen je Asset schrittweise gegen Geräte ausrollen lassen, die sich nicht patchen, umadressieren oder abschalten lassen.
Sehen Sie, wie Ihre Hierarchie auf dem Netz aussieht
Wenn Ihr Purdue-Schaubild und Ihr realer Verkehr auseinandergelaufen sind, gehen wir gemeinsam durch, wo die Umgehungen in Ihrem Netz liegen und was es hieße, den kritischen Assets eine Grenze vorzusetzen.
OT-Netzwerksicherheit
Wie sich eine Zonenarchitektur über Standorte hinweg durchsetzen lässt, ohne VLANs neu zu planen.
Zur LösungDie eigene Topologie durchgehen
Eine Durchsprache an Ihrem Bestand: wo Verkehr die Hierarchie umgeht, welche Assets exponiert sind und wie die Durchsetzung aussähe.
Fragen zum Purdue-Modell
Die Ebene der industriellen DMZ, die in der ursprünglichen Purdue Enterprise Reference Architecture nicht vorkommt. Die Sicherheitsgemeinde hat sie später ergänzt.
Als Sicherheitsarchitektur weitgehend ja. Als gemeinsames Vokabular zur Beschreibung eines Industriebestands nein, und es ist weiterhin das nützlichste verfügbare. Die Unterscheidung zählt: Die Ebenen bleiben eine gute Art zu erklären, wo ein System sitzt, aber die Annahme hinter der sicherheitstechnischen Nutzung, dass Verkehr die Ebenen der Reihe nach kreuzt und an jeder Grenze geprüft werden kann, gilt in einer Anlage mit Lieferanten-Fernzugriff, IIoT-Gateways und Cloud-Replikation nicht mehr. Behalten Sie die Ebenen zum Beschreiben. Verlassen Sie sich nicht auf sie zum Durchsetzen.
Das Purdue-Modell ist eine beschreibende Hierarchie funktionaler Ebenen. IEC 62443 ist eine Norm, die verlangt, Zonen nach Risiko zu definieren, die Conduits dazwischen zu definieren und für jede Sicherheitsanforderungen anzuwenden und zu dokumentieren. Purdue-Ebenen dienen oft als erster Entwurf für 62443-Zonen, sind aber nicht gleichwertig, denn eine Zone bestimmt sich über geteiltes Risiko und nicht über geteilte Funktion. Zwei Assets auf derselben Purdue-Ebene gehören häufig in verschiedene Zonen.
Sie beschreiben Unzusammenhängendes und sind keine Alternativen. Das OSI-Modell hat sieben Schichten, die beschreiben, wie eine einzelne Netzkommunikation aufgebaut ist, von der physischen Signalisierung bis zur Anwendung. Das Purdue-Modell hat Ebenen, die beschreiben, wo Systeme in einer Anlage sitzen, vom physischen Prozess bis zur Unternehmens-IT. OSI beantwortet, wie ein Paket gebaut wird; Purdue beantwortet, was eine Maschine tut und wohin sie gehört.
Ebene 0 ist der physische Prozess, Sensoren und Aktoren. Ebene 1 ist die Basissteuerung, die SPS, Fernwirkeinheiten und Sicherheitssteuerungen. Ebene 2 ist die Leitebene, SCADA und HMI. Ebene 3 ist der Standortbetrieb, Historians, MES und Engineering-Arbeitsplätze. Ebene 3.5 ist die industrielle DMZ, die IT/OT-Grenze. Die Ebenen 4 und 5 sind Standortgeschäft und Unternehmens-IT. Die Nummerierung steigt vom physischen Prozess aufwärts, umgekehrt zu den meisten Netzdiagrammen.
Nein, und es als Entweder-oder zu rahmen, hilft meist nicht. Der produktive Schritt ist, die Ebenen als Dokumentation und gemeinsame Sprache zu behalten und zu ändern, wo die Durchsetzung stattfindet: von einer Grenze zwischen Ebenen zu einer Grenze vor jedem Asset, mit Identitätsprüfung je Sitzung. In der Praxis enden die meisten Bestände mit Purdue an der Wand und Durchsetzung je Asset im Netz, was eine stimmige Position ist und kein Kompromiss.
