Purdue-Modell erklärt: Netzwerkzonen in der Produktion

TL;DR

Das Purdue-Modell (auch Purdue Enterprise Reference Architecture) definiert sechs Ebenen von physischen Prozessen (Level 0) bis zum Unternehmensnetzwerk (Level 5).
Zwischen Level 3 (Manufacturing Operations) und Level 4 (Enterprise IT) liegt die Industrial DMZ als zentrale Sicherheitsbarriere.
Jede Ebene hat eigene Sicherheitsanforderungen. Verkehr zwischen nicht benachbarten Ebenen sollte grundsätzlich nicht erlaubt sein.
Die EU-Maschinenverordnung 2023/1230 unterstützt diesen Ansatz, indem sie fordert, dass Netzwerkverbindungen von Maschinen keine Sicherheitsrisiken erzeugen dürfen.
Auch ohne millionenschwere Investition kannst du mit VLANs und einer dedizierten Firewall eine wirksame Grundsegmentierung erreichen.

Warum Netzwerkzonen in der Produktion unverzichtbar sind

Wenn ein Angreifer in dein Büronetzwerk eindringt, soll er nicht im nächsten Schritt deine Produktionsanlage steuern können. So einfach ist das Grundprinzip. Die Umsetzung ist natürlich komplexer, und genau dafür gibt es das Purdue-Modell.

Das Purdue Enterprise Reference Architecture Model (PERA) wurde in den 1990er-Jahren an der Purdue University entwickelt, ursprünglich nicht als Sicherheitsmodell, sondern als Referenzarchitektur für die Integration von Unternehmenssystemen mit Fertigungssystemen. Die ISA (International Society of Automation) hat es später als Grundlage für den Standard ISA-95 und den Sicherheitsstandard ISA/IEC 62443 übernommen.

Heute ist das Purdue-Modell der De-facto-Standard, wenn es um die Segmentierung von OT-Netzwerken geht. Auch wenn moderne Architekturen (Stichwort: Zero Trust für OT) darüber hinausgehen, bleibt es die beste Grundlage für eine strukturierte Netzwerksegmentierung in der Produktion.

Die sechs Ebenen des Purdue-Modells

Level 0: Physischer Prozess

Level 0 ist die physische Welt. Hier befinden sich die Sensoren und Aktoren, die den Produktionsprozess direkt messen und beeinflussen:

Temperatursensoren, Druckmessumformer, Durchflussmesser
Ventile, Motoren, Heizungen, Pumpen
Frequenzumrichter, Servomotoren
Lichtschranken, Näherungsschalter, Endschalter

Diese Geräte sind oft keine netzwerkfähigen Systeme im klassischen Sinn. Sie kommunizieren über analoge Signale (4-20 mA, 0-10 V) oder über Feldbusse (Profibus, AS-Interface, IO-Link). Zunehmend gibt es aber auch Sensoren mit Ethernet-Anbindung oder Funkschnittstellen (Bluetooth, LoRaWAN, 5G).

Sicherheitsrelevanz: Level 0 ist die Safety-Domäne. Wenn ein Sensor manipuliert wird, der eine sicherheitsrelevante Funktion überwacht (etwa den Druck in einem Kessel), kann das direkt zu physischen Schäden führen. Schutzmaßnahmen auf dieser Ebene sind primär physischer Natur: Zugangskontrollen zu Schaltschränken, Plomben an Verdrahtungen, Dokumentation aller Änderungen.

Level 1: Basissteuerung

Level 1 enthält die Steuerungssysteme, die den physischen Prozess direkt regeln:

Speicherprogrammierbare Steuerungen (SPS / PLC)
Remote Terminal Units (RTU)
Safety-Controller (Sicherheitssteuerungen)
Intelligente Antriebe mit eigener Regelung

Diese Geräte lesen die Sensordaten aus Level 0, verarbeiten sie gemäß dem programmierten Steuerungsprogramm und geben Steuerbefehle an die Aktoren aus. Eine SPS arbeitet typischerweise in einem festen Zyklus von wenigen Millisekunden. Jede Verzögerung in diesem Zyklus kann die Produktqualität beeinträchtigen oder im schlimmsten Fall zu gefährlichen Zuständen führen.

Sicherheitsrelevanz: SPS-Systeme sind das primäre Angriffsziel in der OT-Welt. Malware wie Stuxnet (2010) und TRITON/TRISIS (2017) hat gezeigt, dass Angreifer in der Lage sind, Steuerungsprogramme zu manipulieren. Die Absicherung von SCADA und SPS erfordert spezifische Maßnahmen. Die Härtung von Level-1-Systemen (Firmware-Updates, Zugangskontrollen, Programm-Integrität) ist eine der wichtigsten Maßnahmen.

Level 2: Prozessüberwachung

Level 2 umfasst die Systeme, mit denen das Bedienpersonal den Produktionsprozess überwacht und steuert:

SCADA-Systeme (Supervisory Control and Data Acquisition)
HMI-Panels (Human Machine Interface)
Engineering-Workstations (für die SPS-Programmierung)
Data Historians (lokale Prozessdatenarchive)
Alarmmanagementsysteme

Auf dieser Ebene laufen typischerweise Windows-basierte Systeme. Die SCADA-Software visualisiert den Produktionsprozess, sammelt Alarme und ermöglicht dem Bediener, Parameter zu ändern oder manuell einzugreifen. Engineering-Workstations dienen der Programmierung und Konfiguration der SPS-Systeme auf Level 1.

Sicherheitsrelevanz: Level 2 ist besonders verwundbar, weil hier IT-typische Betriebssysteme (Windows) in einem OT-Kontext laufen. Die Systeme können oft nicht gepatcht werden (weil der SCADA-Hersteller das Update nicht freigegeben hat) – ein typisches Problem des Patch-Managements in der OT und Antivirensoftware ist manchmal nicht kompatibel. Gleichzeitig sind es die Systeme, über die ein Angreifer Zugriff auf die Steuerungen in Level 1 erhält.

Level 3: Manufacturing Operations

Level 3 ist die Ebene der Produktionssteuerung und -planung:

Manufacturing Execution System (MES)
Batch-Management-Systeme
Labor-Informationsmanagementsysteme (LIMS)
Zentrale Historian-Server
Produktionsplanung und -scheduling
Qualitätsmanagementsysteme

Diese Systeme koordinieren den gesamten Produktionsprozess. Das MES übersetzt die Kundenaufträge aus dem ERP-System in konkrete Maschinenbelegungen und Produktionsreihenfolgen. Es sammelt die Produktionsdaten aller Linien und stellt sie für Auswertungen bereit.

Sicherheitsrelevanz: Level 3 ist die oberste Ebene der OT-Welt und gleichzeitig die Schnittstelle zur IT. Hier müssen die Datenflüsse sorgfältig kontrolliert werden. Das MES braucht Zugriff auf die Steuerungssysteme in Level 2 (nach unten) und auf das ERP-System in Level 4 (nach oben). Es ist damit ein Brücken-System mit besonderem Schutzbedarf.

Die Industrial DMZ: Die zentrale Sicherheitsbarriere

Zwischen Level 3 und Level 4 liegt die Industrial DMZ (Demilitarisierte Zone). Sie ist das Herzstück der Purdue-Architektur aus Sicherheitssicht.

Die DMZ enthält Systeme, die sowohl von der IT- als auch von der OT-Seite erreichbar sein müssen, aber selbst weder direkt zur IT noch zur OT gehören:

Jump-Server für Remote-Zugriff auf OT-Systeme
Replizierte Historian-Server (spiegeln Daten aus Level 3 für IT-Zugriff)
Datentransfer-Server (Dateien, die zwischen IT und OT ausgetauscht werden)
Patch-Management-Server für OT (laden Patches aus dem Internet, stellen sie für OT bereit)
Anti-Malware-Update-Server

Das Kernprinzip der DMZ: Kein direkter Verkehr zwischen IT (Level 4/5) und OT (Level 0-3). Alle Kommunikation läuft über die DMZ-Systeme. Die Firewalls auf beiden Seiten der DMZ sind so konfiguriert, dass:

Von IT nach DMZ: Nur definierte Verbindungen zu den DMZ-Diensten erlaubt
Von DMZ nach OT: Nur definierte Verbindungen zu den benötigten OT-Systemen erlaubt
Von IT nach OT direkt: Komplett blockiert
Von OT nach IT direkt: Komplett blockiert

Dieses Modell stellt sicher, dass ein Angreifer, der das IT-Netzwerk kompromittiert hat, nicht direkt auf OT-Systeme zugreifen kann. Er muss zuerst ein DMZ-System kompromittieren, was eine zusätzliche Hürde darstellt.

Level 4: Enterprise IT

Level 4 ist das klassische Unternehmensnetzwerk:

ERP-System (SAP, Microsoft Dynamics etc.)
E-Mail-Server
File-Server
Intranet und Collaboration-Tools
Business-Intelligence und Reporting

Aus OT-Sicht ist Level 4 „die IT". Die Systeme auf dieser Ebene nutzen Daten aus der Produktion (über die DMZ), aber sie haben keinen direkten Zugriff auf Steuerungssysteme.

Level 5: Enterprise Network / Internet

Level 5 umfasst das unternehmensweite Netzwerk, die Verbindung zwischen Standorten und den Internetzugang:

WAN-Verbindungen zwischen Standorten
VPN-Gateways
Internet-Proxy und Web-Filter
Cloud-Dienste
Externe Partnernetzwerke

Sicherheitsrelevanz: Level 5 ist der Eintrittspunkt für externe Angreifer. Von hier aus arbeiten sie sich durch die Ebenen nach unten. Jede Sicherheitsschicht, die sie dabei überwinden müssen, erhöht den Aufwand und die Chance, entdeckt zu werden.

Das Purdue-Modell in der Praxis umsetzen

Das Modell klingt in der Theorie klar und logisch. Die Umsetzung in einem gewachsenen mittelständischen Unternehmen ist jedoch voller Herausforderungen.

Ist-Zustand aufnehmen

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Zeichne dein Netzwerk so, wie es wirklich ist, nicht wie es sein sollte. Typische Erkenntnisse bei dieser Übung:

Es gibt keine echte Trennung zwischen IT und OT. Alles hängt am selben Core-Switch.
Der SCADA-Server hat eine IP-Adresse aus dem Büro-Subnetz.
Der Maschinenhersteller hat einen VPN-Router direkt an der Maschine installiert, der eine eigene Internetverbindung hat (am Unternehmensnetzwerk vorbei).
Die Engineering-Workstation steht im Büro des Instandhalters und ist gleichzeitig sein normaler Arbeitsplatz, mit E-Mail-Client und Internetzugang.
Zwischen verschiedenen Produktionsbereichen gibt es keine Segmentierung.

Diese Erkenntnisse sind nicht erfreulich, aber sie sind der Ausgangspunkt für Verbesserungen.

Soll-Zustand definieren

Ordne jedes System einer Purdue-Ebene zu. Dabei wirst du feststellen, dass manche Systeme nicht klar zuzuordnen sind. Ein typisches Beispiel: Der Historian-Server, der Daten aus der SCADA-Welt sammelt (Level 2/3) und gleichzeitig von der IT-Abteilung für Reporting genutzt wird (Level 4). Die Lösung: Zwei Historian-Instanzen. Eine in Level 3 für die Datensammlung, eine in der DMZ für den IT-Zugriff, mit einer unidirektionalen Replikation dazwischen.

Pragmatische Segmentierung

Du brauchst nicht sofort eine perfekte Purdue-Architektur. Eine pragmatische Grundsegmentierung mit drei Zonen ist ein guter Anfang:

Zone 1 - Enterprise (Level 4/5): Büro-IT mit allen Standardsystemen. Hier gelten die normalen IT-Security-Maßnahmen.

Zone 2 - DMZ: Brücken-Systeme, die beide Welten verbinden. Minimal: Ein Jump-Server für den Remote-Zugriff auf OT und ein Datentransfer-Server für den Austausch zwischen ERP und MES.

Zone 3 - Production (Level 0-3): Alle OT-Systeme. Intern kannst du später weiter segmentieren (separate VLANs für verschiedene Produktionslinien), aber die Trennung IT/DMZ/OT ist der wichtigste erste Schritt.

Zwischen den Zonen stehen Firewalls (oder ein Layer-3-Switch mit ACLs als Übergangslösung). Die Regeln:

Enterprise → DMZ: Erlaubt, aber nur zu definierten Diensten
DMZ → Production: Erlaubt, aber nur zu definierten Diensten und Protokollen
Enterprise → Production: Blockiert
Production → Enterprise: Blockiert
Production → DMZ: Erlaubt für definierte Datenflüsse (z.B. Historian-Replikation)

Typische Widerstände und wie du ihnen begegnest

„Das haben wir schon immer so gemacht." Die gewachsene Struktur funktioniert, warum etwas ändern? Hier hilft ein konkretes Bedrohungsszenario: „Wenn Mitarbeiter X eine Phishing-Mail öffnet, kann der Angreifer in drei Schritten die Produktionssteuerung erreichen. Willst du das so lassen?"

„Die Segmentierung macht alles langsamer." Moderne Firewalls und Switches verarbeiten Industrieprotokolle ohne messbare Latenz. Die Sorge ist technisch unbegründet, aber du solltest sie ernst nehmen und im Zweifel mit einer Messung widerlegen.

„Der Maschinenhersteller braucht direkten Zugriff." Dann bekommt er einen Zugang über den Jump-Server in der DMZ. Mit eigenem Account, Multi-Faktor-Authentifizierung und Protokollierung. Nicht über einen ungesicherten VPN-Router, der am Unternehmens-Netzwerk vorbei direkt ins Internet geht.

„Das kostet zu viel." Eine Grundsegmentierung mit managed Switches (VLANs) und einer dedizierten Firewall kostet typischerweise zwischen 5.000 und 20.000 Euro für einen mittelständischen Standort. Das ist ein Bruchteil dessen, was ein Produktionsstillstand durch einen Ransomware-Angriff kostet.

Moderne Erweiterungen des Purdue-Modells

Das klassische Purdue-Modell hat Einschränkungen, die in modernen OT-Umgebungen relevant werden:

Cloud-Anbindung

Das Original-Modell kennt keine Cloud. Moderne Produktionsumgebungen senden aber Daten an Cloud-Plattformen für Analyse, Predictive Maintenance oder zentrale Überwachung mehrerer Standorte. Der empfohlene Ansatz: Cloud-Verbindungen laufen über die DMZ, nicht direkt aus der Produktionszone. Ein Edge-Gateway in der DMZ sammelt die Daten, filtert sie und leitet sie verschlüsselt an die Cloud weiter.

Wireless und IoT

Funksensoren und IoT-Geräte passen nicht sauber in das hierarchische Modell. Sie befinden sich physisch in Level 0/1, kommunizieren aber möglicherweise über eigene Funknetze direkt mit Cloud-Diensten. Hier ist es wichtig, das Funknetz als eigene Zone zu behandeln und den Verkehr über ein Gateway zu führen, das in der entsprechenden Purdue-Ebene steht.

Zero Trust für OT

Das Zero-Trust-Konzept (vertraue niemandem, verifiziere jeden Zugriff) wird zunehmend auch auf OT-Umgebungen angewandt. Es ergänzt das Purdue-Modell, indem es auch innerhalb einer Ebene Zugriffe kontrolliert. Allerdings ist die Umsetzung in der OT deutlich schwieriger als in der IT, weil viele OT-Protokolle keine Authentifizierung unterstützen. Zero Trust für OT ist daher eher ein langfristiges Ziel als ein sofortiger Handlungsplan.

Die Verbindung zur EU-Maschinenverordnung

Die EU-Maschinenverordnung 2023/1230 fordert ab 2027, dass die Sicherheitsfunktionen einer Maschine nicht durch digitale Verbindungen beeinträchtigt werden dürfen. Das Purdue-Modell liefert den strukturellen Rahmen, um genau das sicherzustellen.

Wenn eine Maschine in Level 1/2 steht und ihre Sicherheitsfunktionen durch eine korrekte Netzwerksegmentierung von externen Zugriffen geschützt sind, ist eine wesentliche Anforderung der Verordnung erfüllt. Umgekehrt: Wenn die Maschine direkt aus dem Internet erreichbar ist oder im selben Netzwerk wie die Büro-PCs hängt, wird es schwer, die Konformität mit der Verordnung zu argumentieren.

Für Maschinenhersteller, die nach der neuen Verordnung CE-kennzeichnen müssen, ist die Empfehlung einer Purdue-konformen Einbindung in der Betriebsanleitung ein sinnvoller Ansatz. Für Betreiber ist die Umsetzung einer sauberen Segmentierung ein wesentlicher Baustein, um sowohl NIS2 als auch die Maschinenverordnung zu erfüllen.

Fallbeispiel: Purdue-Segmentierung bei einem Metallverarbeiter

Ein mittelständischer Metallverarbeiter mit 180 Mitarbeitern und drei Produktionshallen hat das Purdue-Modell in sechs Monaten umgesetzt. Der Ausgangszustand: Ein flaches Netzwerk, in dem Büro-PCs, SCADA-Server und SPS-Steuerungen im selben Subnetz kommunizierten. Der Geschäftsführer hatte den Anstoß gegeben, nachdem ein Ransomware-Angriff bei einem Branchenkollegen zu drei Wochen Produktionsstillstand geführt hatte.

Monat 1-2: Ist-Aufnahme. Ein externer Berater hat zusammen mit dem IT-Leiter und dem Instandhaltungsleiter alle Netzwerkverbindungen dokumentiert. Das Ergebnis: 47 OT-Geräte (SPS, HMI, SCADA), drei Fernwartungszugänge (davon einer mit einem TeamViewer-Zugang, den der Maschinenhersteller 2019 eingerichtet und nie wieder deaktiviert hatte), und eine direkte Verbindung vom ERP-Server auf den MES-Server, der im selben VLAN wie die SCADA-Server stand.

Monat 3-4: Soll-Architektur und Beschaffung. Drei Zonen definiert: Enterprise, DMZ und Production. Zwei dedizierte Firewalls beschafft (eine zwischen Enterprise und DMZ, eine zwischen DMZ und Production). Einen Jump-Server in der DMZ aufgesetzt. Die Firewall-Regeln wurden gemeinsam von IT und Produktionstechnik erarbeitet, mit einer expliziten Liste aller erlaubten Verbindungen und Protokolle.

Monat 5: Umsetzung. Während eines geplanten Produktionsstillstands (Betriebsferien) wurden die neuen Firewalls installiert und die Netzwerkzonen konfiguriert. Der TeamViewer-Zugang wurde deaktiviert und durch einen Zugang über den Jump-Server ersetzt. Alle Fernwartungszugänge laufen jetzt über den Jump-Server mit individuellen Accounts und Protokollierung.

Monat 6: Monitoring und Feintuning. In den ersten Wochen nach der Umstellung gab es einige Verbindungsprobleme (ein IoT-Sensor, der regelmäßig Daten an einen Cloud-Dienst sendete und nun von der Firewall blockiert wurde; ein altes Diagnose-Tool, das eine direkte Verbindung zum SCADA-Server benötigte). Diese wurden identifiziert und gezielt in den Firewall-Regeln adressiert.

Gesamtkosten: Circa 15.000 Euro für Hardware (Firewalls, Jump-Server) plus 12.000 Euro für den externen Berater. Der IT-Leiter hat geschätzt, dass er circa 80 Stunden eigene Arbeitszeit investiert hat, der Instandhaltungsleiter circa 30 Stunden.

Ergebnis: Ein Pentest sechs Monate nach der Umsetzung hat bestätigt, dass ein Angreifer, der einen Büro-PC kompromittiert, nicht mehr direkt auf OT-Systeme zugreifen kann. Die Produktionstechniker haben nach anfänglicher Skepsis bestätigt, dass die Segmentierung den Betrieb nicht beeinträchtigt.

Checkliste: Purdue-Modell umsetzen

Zum Abschluss eine praktische Checkliste für die Umsetzung:

Netzwerk-Ist-Zustand dokumentiert (alle Verbindungen zwischen IT und OT)
Jedes OT-System einer Purdue-Ebene zugeordnet
Mindestens drei Zonen definiert (Enterprise, DMZ, Production)
Firewall zwischen Enterprise und DMZ installiert und konfiguriert
Firewall zwischen DMZ und Production installiert und konfiguriert
Kein direkter Verkehr zwischen Enterprise und Production möglich
Jump-Server in der DMZ für Remote-Zugriff auf OT eingerichtet
Alle Fernwartungszugänge über den Jump-Server geführt
Datenflüsse zwischen IT und OT über DMZ-Systeme dokumentiert
Firewall-Regeln nach dem Prinzip „Default Deny" konfiguriert
Segmentierung innerhalb der Production-Zone begonnen (z.B. separate VLANs pro Produktionslinie)
Monitoring an den Zonenübergängen eingerichtet
Dokumentation im ISMS aktualisiert (Netzwerkdiagramm, Asset-Zuordnung, Firewall-Regeln)

Die Zuordnung deiner OT-Assets zu den Purdue-Ebenen lässt sich in ISMS Lite gemeinsam mit Kritikalität, Abhängigkeiten und Zonenregeln dokumentieren, sodass du jederzeit einen auditfähigen Überblick hast.

Weiterführende Artikel