Was ist das Purdue-Modell? Definition, Ebenen & Best Practices

Das Purdue-Modell ist der Bundesstandard für die Segmentierung von ICS-Netzwerken und organisiert OT-Umgebungen in sechs hierarchische Ebenen mit durchgesetzten Vertrauensgrenzen.

Was ist das Purdue-Modell?

Eine einzige kompromittierte HMI-Workstation verschafft einem Angreifer direkte Befehlsgewalt über SPS, die physische Prozesse steuern. Der Unterschied, ob diese Workstation hinter drei durchgesetzten Sicherheitsgrenzen sitzt oder sich ein flaches Netzwerk mit Ihrem unternehmensweiten E-Mail-Server teilt, ist praktisch gesehen das Purdue-Modell.

Die Purdue Enterprise Reference Architecture (PERA), allgemein bekannt als Purdue-Modell, ist ein hierarchisches Referenzrahmenwerk, das industrielle Steuerungsnetzwerke (ICS) in klar abgegrenzte funktionale Ebenen segmentiert – von physischen Prozessen auf Feldebene bis hin zu Unternehmens-IT und externen Netzwerken. Entwickelt wurde das Modell 1991 am Laboratory for Applied Industrial Control der Purdue University von Theodore J. Williams und dem Industry-Purdue University Consortium for Computer-Integrated Manufacturing. Ursprünglich adressierte das Modell Datenflüsse in rechnerintegrierter Fertigung, nicht Cybersicherheit.

Mit der Anbindung von OT an IT wurde die hierarchische Struktur zur natürlichen Grundlage, um zu definieren, was über Netzwerkgrenzen hinweg kommunizieren darf und was nicht. Heute organisiert das Modell ICS-Umgebungen in die Ebenen 0 bis 5 (plus eine kritische Ebene 3.5 Industrial DMZ), jeweils mit definierten Komponenten, Vertrauensgrenzen und Sicherheitsanforderungen.

DOE-Forschung bestätigt, dass das Modell „als Basisarchitektur für alle industriellen Steuerungssystem-Frameworks wie API 1164 und NIST 800-82 verwendet wird.“

Zu verstehen, was das Purdue-Modell ist, ist jedoch nur der erste Schritt. Seine Bedeutung für die moderne industrielle Sicherheit ergibt sich daraus, wie es diese hierarchische Struktur in konkrete Cybersicherheitsmaßnahmen übersetzt.

Wie das Purdue-Modell mit Cybersicherheit zusammenhängt

Der zentrale Sicherheitswert des Purdue-Modells liegt in der Schaffung klarer Vertrauensgrenzen zwischen OT- und IT-Umgebungen, wodurch Defense-in-Depth durch geschichtete Sicherheitszonen ermöglicht wird. ISA-95 hat den hierarchischen Ansatz formal in standardisierte Terminologie überführt, und ISA/IEC 62443 baut seine Zonen- und Conduits-Sicherheitsarchitektur direkt auf dem Fundament des Modells auf.

CISA, NIST und das DoD befürworten das Purdue-Modell aktiv in aktuellen Leitlinien für 2025:

• CISAs Empfehlungen für 2025 bezeichnen es als „Leitfaden für geschichtete Sicherheitszonen“
• NIST hat es in SP 800-82 Revision 3 integriert
• Das Verteidigungsministerium verweist darauf in Zero-Trust-OT-Leitlinien

Wenn Sie Architekturentscheidungen gegenüber Prüfern oder Regulierungsbehörden verteidigen, genießt das Purdue-Modell behördenübergreifende bundesstaatliche Unterstützung.

Die Fertigungsindustrie machte 2025 laut dem IBM X-Force 2026 Index 27,7 % aller Cyberangriffe aus – der höchste Wert aller Branchen im fünften Jahr in Folge. Diese Zahlen zeigen, warum strukturierte Segmentierung in industriellen Umgebungen keine optionale Verbesserung ist.

Um zu verstehen, wie diese Segmentierung in der Praxis funktioniert, müssen Sie wissen, was auf jeder Ebene existiert und welche Sicherheitsverpflichtungen jede trägt.

Die sechs Ebenen des Purdue-Modells

Das Purdue-Modell definiert sechs funktionale Ebenen (0–5) sowie die Industrial DMZ, die zur Bewältigung der IT/OT-Konvergenz hinzugefügt wurde. Jede Ebene enthält spezifische Komponenten, weist ein definiertes Risikoprofil auf und erfordert eigene Sicherheitsmaßnahmen.

Ebene 0: Physischer Prozess

Der tatsächlich gesteuerte industrielle Prozess. Sensoren, Aktoren, Ventile, Motoren und Produktionsanlagen befinden sich hier. Die Hauptanforderung ist physischer Zugangsschutz und Schutz der Signalintegrität.

Ebene 1: Basissteuerung

Echtzeitfähige programmierbare Steuerung physischer Prozesse. SPS, RTUs, Safety Instrumented Systems (SIS) und intelligente elektronische Geräte führen Steuerungslogik aus. Sie sind besonders wertvolle Ziele, da ihre Kompromittierung die direkte Manipulation physischer Prozesse ermöglicht. Sie laufen typischerweise auf Echtzeitbetriebssystemen ohne Unterstützung moderner Authentifizierung oder Patch-Management. Das DOE klassifiziert die Ebenen 0 und 1 gemeinsam als Safety Zone mit kritischem Risikoprofil.

Ebene 2: Überwachungssteuerung

Mensch-Maschine-Interaktion und überwachende Kontrolle. HMIs, SCADA-Systeme, Bedienerarbeitsplätze und lokale Steuerungsserver sind hier angesiedelt. Diese Ebene ist das primäre Ziel für laterale Angriffe aus der IT, da sie Windows-basierte Betriebssysteme ausführt und gleichzeitig direkte Befehlsgewalt über SPS der Ebene 1 besitzt – eine kritische Überwachungs- und Eindämmungslücke in vielen Umgebungen.

Ebene 3: Standortbetrieb

Werksweite Betriebsführung. Manufacturing Execution Systems (MES), Data Historians, Batch-Steuerungssysteme und OT-Netzwerküberwachungsplattformen aggregieren alle OT-Daten nach oben. Historians auf dieser Ebene sind häufige IT/OT-Brückenknoten und wurden historisch als Pivot-Punkte zwischen den Umgebungen ausgenutzt.

Ebene 3.5: Industrial DMZ (iDMZ)

Diese Schicht existierte im ursprünglichen Modell der 1990er Jahre nicht. DOE-Leitlinien besagen: „Diese Ebene war im ursprünglichen Purdue-Modell nicht vorgesehen; mit der fortschreitenden Konvergenz von OT und IT ist diese abstrakte Schicht jedoch unerlässlich, um die Trennung der Kommunikation sicherzustellen.“ Sie enthält Perimeter-Firewalls an IT- und OT-Grenzen, Data Diodes, Proxy-Server, Historian-Replikate und Jump-Server. Es gibt keine direkten IT-zu-OT-Verbindungen durch diese Zone.

Ebene 4: Unternehmensnetzwerk

Unternehmens-IT-Systeme einschließlich ERP, CRM, Active Directory und Geschäftsanwendungen. Die entscheidende Anforderung: keinerlei direkte Konnektivität zu Ebene 2 oder darunter.

Ebene 5: Externes Netzwerk

Systeme mit Internetanbindung, Cloud-Dienste und Anbieterzugangsportale, die – bei korrekter Architektur – keinen Pfad zu OT haben, ohne mehrere Sicherheitsgrenzen zu durchqueren.

Das Verständnis dieser Komponenten ist notwendig, aber zu wissen, wie der Datenverkehr zwischen ihnen fließt, ist entscheidend für die tatsächliche Durchsetzung von Sicherheit.

Wie das Purdue-Modell funktioniert

Das Purdue-Modell erzwingt Sicherheit durch hierarchische Kommunikationskontrolle. Jede Ebene kommuniziert primär mit ihren unmittelbaren Nachbarn, und jeglicher Datenverkehr zwischen der OT-Zone (Ebenen 0 bis 3) und der IT-Zone (Ebenen 4 und 5) muss die Industrial DMZ auf Ebene 3.5 passieren.

NIST SP 800-82 Rev. 3 fordert explizit Firewall-Regeln, die verhindern, dass Geräte der Ebene 4 direkt mit Geräten der Ebenen 2, 1 oder 0 kommunizieren. Der Standard empfiehlt zudem, ausgehende Regeln ebenso streng wie eingehende zu gestalten, um sowohl eingehende Angriffe als auch ausgehende Datenexfiltration zu verhindern.

ISA/IEC 62443 formalisiert dies durch Zonen und Conduits. Eine Zone ist eine Sammlung von Assets mit gemeinsamen Sicherheitsanforderungen. Ein Conduit ist der Kommunikationskanal zwischen Zonen und muss auf das gleiche Kritikalitätsniveau wie die vertrauenswürdigste verbundene Zone abgesichert werden.

In der Praxis funktioniert der Datenfluss wie folgt:

• Sensoren der Ebene 0 liefern Daten an Controller der Ebene 1
• Controller der Ebene 1 melden an HMIs und SCADA-Systeme der Ebene 2
• Ebene 2 überträgt Daten an Historian-Systeme der Ebene 3
• Historian-Replikate der Ebene 3 in der DMZ stellen Daten für IT-Konsumenten der Ebene 4 bereit

IT-Systeme fragen OT niemals direkt ab

Diese Einweg-Datenarchitektur, verstärkt durch Firewalls, Zugriffskontrollen und optional Hardware-Data-Diodes, verhindert, dass ein Angreifer, der das Unternehmensnetzwerk kompromittiert, die Systeme erreicht, die physische Prozesse steuern.

Zentrale Vorteile der Implementierung des Purdue-Modells

Richtig implementiert liefert das Purdue-Modell einen kumulativen Sicherheitsnutzen in vier betrieblichen Bereichen.

• Defense-in-Depth durch durchgesetzte Segmentierung. Jede Purdue-Ebene bildet eine Sicherheitsgrenze, die ein Angreifer überwinden muss. Selbst wenn das Unternehmensnetzwerk vollständig durch Ransomware kompromittiert ist, kann eine korrekte Segmentierung den Betriebsausfall physischer Prozesse verhindern.
• Regulatorische und normative Konformität. Das Purdue-Modell bildet die explizite Grundlage für ISA/IEC 62443-Konformitätsbewertungen, NIST SP 800-82-Architekturvorgaben und aktive CISA-Empfehlungen. Die Implementierung bietet eine auditierbare, regulatorisch verteidigbare Architektur.
• Eindämmung lateraler Bewegungen. Der Verizon DBIR 2025 stellte fest, dass Ransomware inzwischen 44 % aller Datenpannen ausmacht. In OT-Umgebungen bedroht Ransomware direkt die Betriebsverfügbarkeit und Sicherheit, nicht nur Daten. Purdue-Segmentierung begrenzt die Ausbreitung von Ransomware von IT in OT-Zonen.
• Kompensierende Kontrolle für Altsysteme. Lebenszyklen industrieller Anlagen von 15 bis 25 Jahren bedeuten, dass Ihre OT-Umgebung wahrscheinlich Systeme enthält, die nicht gepatcht, authentifiziert oder mit modernen Tools überwacht werden können. CISAs Leitlinien empfehlen Netzwerksegmentierung explizit als primären Schutz für diese Systeme.

Diese Vorteile wirken sich nur dann aus, wenn die Implementierung solide ist. Und eine solide Implementierung beginnt mit dem Verständnis der strukturellen Herausforderungen, die das Purdue-Modell schwieriger umsetzbar machen, als es auf dem Papier erscheint.

Herausforderungen bei der Implementierung des Purdue-Modells

Die Prinzipien des Purdue-Modells sind auf dem Papier klar. Die betriebliche Realität ihrer Umsetzung in laufenden Industrieumgebungen ist es nicht. Mehrere strukturelle Herausforderungen führen regelmäßig zu Diskrepanzen zwischen dem, was das Architekturdiagramm zeigt, und dem, was der Netzwerkverkehr tatsächlich tut.

1. IT/OT-Konvergenz schafft undokumentierte Architektur. Moderne betriebliche Anforderungen erzeugen kontinuierlich neue Verbindungen über Purdue-Grenzen hinweg. Peer-Review-Forschung aus 2025 identifiziert Datenflussanforderungen, Komplexität der Sicherheitszonen und Protokollbrücken als die drei Hauptprobleme der Konvergenz.
2. Altsysteme widersetzen sich modernen Sicherheitskontrollen. SPS und RTUs der Ebene 1 laufen typischerweise auf Echtzeitbetriebssystemen mit proprietären Protokollen, die von den meisten IT-Sicherheitswerkzeugen nicht inspiziert werden können. Sie können keinen Endpoint-Agent auf einer SPS mit RTOS von 2005 installieren. Netzwerkbasierte Segmentierung bleibt die einzige praktikable Kontrolle.
3. Betriebssicherheit schränkt Sicherheitsoptionen ein. NIST SP 800-82 Rev. 3 fordert explizit, dass Segmentierung „Betriebsleistung und Sicherheit“ berücksichtigt. ICS-Umgebungen tolerieren keine Authentifizierungsfehler oder Netzwerklatenzen, die in der IT akzeptabel wären. Keine Sicherheitskontrolle darf zum Single Point of Failure für Produktions- oder Sicherheitssysteme werden.
4. Cloud und IIoT haben keine klare Purdue-Zuordnung. Das DOE gibt an, dass Geräte der Ebenen 0 und 1 aufgrund von Echtzeitanforderungen nicht für Virtualisierung oder Cloud-Hosting geeignet sind. Cloud und Virtualisierung gelten ab Ebene 3, aber viele Organisationen integrieren Cloud-Analytik und IIoT-Sensoren ohne klares Rahmenwerk für deren Zuordnung.
5. Remotezugriff verletzt Grundprinzipien. Traditionelle VPN-Lösungen schaffen oft direkte Verbindungen zu unteren OT-Ebenen und verletzen damit direkt die Kontrollhierarchie des Purdue-Modells. CISA hat dokumentiert, dass pro-russische Hacktivistengruppen OT-Steuergeräte erfolgreich über minimal gesicherte, internetexponierte VNC-Verbindungen kompromittiert haben.

Das Wissen um diese Herausforderungen hilft, sie zu antizipieren. Doch die gefährlichsten Fehler entstehen durch eigene Entscheidungen der Teams.

Häufige Fehler beim Purdue-Modell, die es zu vermeiden gilt

Wo Herausforderungen strukturell sind, sind Fehler Entscheidungen: Maßnahmen, die Teams bei Design, Implementierung oder laufender Verwaltung treffen und damit die Schutzwirkung des Modells untergraben. Dies sind die Fehler, denen CISA Threat Hunter in realen Industrieumgebungen am häufigsten begegnen.

Bereitstellung von VLANs ohne Durchsetzung von Inter-VLAN-Zugriffskontrolle. CISAs proaktive Threat Hunt entdeckte Organisationen mit korrekt konfigurierten separaten IT- und SCADA-VLANs, aber ohne entsprechende Firewall-Regeln, sodass Inter-VLAN-Routing uneingeschränkt möglich war. Das Ergebnis: „Ein nicht privilegierter Benutzer im IT-Netzwerk [konnte] seine Anmeldedaten nutzen, um auf das kritische SCADA-VLAN zuzugreifen.“ VLANs allein sind ein Netzwerkmanagement-Tool, keine Sicherheitskontrolle.

Die folgenden Fehler verstärken diesen grundlegenden Fehler und sind in Live-Umgebungen ebenso häufig:

• Zu großzügige Firewall-Regeln bestehen lassen. „Temporäre“ Fehlerbehebungsregeln (allow any/any, offenes RDP/VNC) werden zu dauerhaften Bestandteilen, die Audits und Personalwechsel überdauern.
• Direkten IT-Zugriff auf Feldcontroller erlauben. NIST SP 800-82 Rev. 3 fordert Firewall-Regeln, die verhindern, dass Geräte der Ebene 4 mit denen der Ebenen 2, 1 oder 0 kommunizieren. Verstöße schaffen Angriffswege, die alle überwachenden Kontrollen umgehen.
• Implementierung als einmaliges Projekt betrachten. Organisationen, die Purdue-Segmentierung einführen und nie wieder überprüfen, sammeln mit der Zeit undokumentierte Verbindungen, wenn sich betriebliche Anforderungen ändern. Architekturvalidierung muss die tatsächliche Verkehrsanalyse und Regelüberprüfung umfassen, nicht nur die Diagrammprüfung.
• Breiten Anbieter-Remotezugriff in OT-Zonen gewähren. CISAs Threat Hunt Guidance identifiziert Anbieter-Remotezugriff als häufig ausgenutzte Schwachstelle. VPN-Zugänge, die direkt in OT-Zonen enden statt in DMZ-Jump-Servern, schaffen persistente Angriffswege.

Das Vermeiden dieser Fehler erfordert bewusste, standardkonforme Vorgehensweisen.

Best Practices für das Purdue-Modell

Zu wissen, was schiefgehen kann, ist die halbe Arbeit. Die andere Hälfte besteht darin, die Architektur so zu bauen und zu pflegen, dass sie betrieblichem Druck, Audit-Prüfungen und aktiven Bedrohungen standhält. Die folgenden Praktiken spiegeln aktuelle CISA-, NIST- und DOE-Leitlinien für ICS-Umgebungen wider.

Implementieren Sie eine zweifache Firewall-Industrial DMZ. CISAs Leitlinie ist eindeutig: Firewalls sowohl an der IT-DMZ-Grenze als auch an der OT-DMZ-Grenze bereitstellen, zwei separate Durchsetzungspunkte. Alle gemeinsam genutzten Dienste (Historians, Jump-Server, Remotezugriff-Endpunkte) müssen innerhalb der DMZ gehostet werden. DMZ-Hosts dürfen keine Verbindungen in OT-Zonen initiieren.

ICS-spezifische Sicherheitskontrollen einsetzen. Standard-IT-Firewalls sind unzureichend. CISA fordert SCADA-fähige Firewalls, die industrielle Protokolle auf Anwendungsebene inspizieren können, Application Allowlisting für autorisierte Protokolle und Deep Packet Inspection für industrielle Kommunikation.

Darüber hinaus verstärken vier operative Kontrollen die Architektur im Tagesgeschäft:

• Bidirektionale Kommunikationskontrollen durchsetzen. NIST SP 800-82 Rev. 3 empfiehlt, ausgehende Regeln ebenso streng wie eingehende zu gestalten, um sowohl eingehende Angriffe als auch ausgehende Datenexfiltration von kompromittierten OT-Systemen zu verhindern.
• Data Diodes für hochsichere Datenflüsse nutzen. Hardwarebasierte unidirektionale Datenübertragung für Historian-Replikation verhindert physisch Rückkommunikation und eliminiert das Risiko von Command-and-Control über Historian-Kanäle in OT.
• Architektur anhand des tatsächlichen Verkehrs validieren. Vergleichen Sie Firewall-Regelsätze mit Netzwerkdiagrammen. CISA Threat Hunts haben wiederholt festgestellt, dass diese einander widersprechen. Simulieren Sie Angreiferszenarien: Versuchen Sie, kritische SCADA-VLANs von kompromittierten nicht privilegierten IT-Konten aus zu erreichen.
• Jeden Remotezugriff in der DMZ terminieren. Jede Remote-Sitzung von Anbietern, Mitarbeitern und Auftragnehmern muss auf Jump-Servern der Ebene 3.5 mit Sitzungsprotokollierung enden, niemals direkt in OT-Zonen.

Erweitern Sie Zero Trust auf höheren Ebenen. Sowohl CISAs Leitlinien 2025 als auch das Zero Trust für OT des DoD positionieren Zero Trust als Ergänzung zum Purdue-Modell, nicht als Ersatz. Identitätsprüfung gilt ab Ebene 3.5 und höher. Die Ebenen 0 bis 2 erfordern netzwerkbasierte Segmentierung als primäre Kontrolle.

Diese Praktiken spiegeln das Modell wider, wie es konzipiert wurde. Doch das Purdue-Modell selbst hat sich weiterentwickelt, und das Verständnis dieser Entwicklung ist für Teams in zunehmend konvergenten Umgebungen unerlässlich.

Die moderne Entwicklung: IT/OT-Konvergenz und Purdue 2.0

Das Purdue-Modell hat sich von einer 6-Ebenen-Architektur zu einem 7-Ebenen-Modell mit Ebene 3.5 als obligatorischer Sicherheitskontrolle entwickelt. Sicherheitsarchitekten sprechen heute von „Purdue 2.0“, was eine Anpassung und keinen Ersatz darstellt. Das Prinzip der hierarchischen Segmentierung in Kombination mit der Ebene 3.5 iDMZ bleibt der betrieblich am meisten validierte Ansatz zum Schutz physischer Industrieprozesse.

Für Sicherheitsteams, die diese zunehmend konvergenten Umgebungen verwalten, wird bereichsübergreifende Sichtbarkeit unerlässlich, um Bedrohungen zu erkennen, die IT/OT-Grenzen überschreiten, und verdächtige Aktivitäten über Endpunkte, Identitäten und Netzwerkverkehr hinweg zu korrelieren.

Wichtige Erkenntnisse

Das Purdue-Modell bleibt die bundesweit empfohlene Referenzarchitektur für ICS-Netzwerksegmentierung und organisiert Industrieumgebungen in hierarchische Ebenen mit durchgesetzten Vertrauensgrenzen. Die Industrial DMZ auf Ebene 3.5 ist inzwischen für jede vernetzte OT-Umgebung obligatorisch. 

Der Erfolg der Implementierung hängt von der Durchsetzung ab, nicht vom Design: Validieren Sie Firewall-Regeln anhand des tatsächlichen Verkehrs, terminieren Sie jeden Remotezugriff in der DMZ und setzen Sie ICS-spezifische Sicherheitskontrollen ein. Mit Ransomware in 44 % der Vorfälle und der Fertigung als meistangegriffene Branche im fünften Jahr in Folge ist Purdue-basierte Segmentierung keine Option, sondern Pflicht.

FAQs

Was ist das Purdue-Modell?

Die Purdue Enterprise Reference Architecture (PERA), allgemein als Purdue-Modell bezeichnet, ist ein hierarchisches Rahmenwerk, das industrielle Steuerungsnetzwerke (ICS) in verschiedene funktionale Ebenen unterteilt – von physischen Prozessen auf Ebene 0 bis hin zu Unternehmens-IT und externen Netzwerken auf den Ebenen 4 und 5. 

Sie wurde 1991 an der Purdue University entwickelt, ursprünglich für die rechnerintegrierte Fertigung konzipiert und hat sich seither als Standard-Referenzarchitektur für ICS-Sicherheit etabliert. Sie wird aktiv von CISA, NIST und dem Verteidigungsministerium unterstützt.

Ist das Purdue-Modell im Jahr 2025 noch relevant oder wurde es durch Zero Trust ersetzt?

Das Purdue-Modell wird auch 2025 weiterhin aktiv von CISA, NIST und dem DoD empfohlen. Zero Trust ergänzt das Modell, ersetzt es jedoch nicht. Die CISA-Leitlinien für 2025 und die Zero Trust for OT-Dokumentation des DoD positionieren Zero Trust als Erweiterung, die ab Ebene 3.5 anwendbar ist. 

Die Ebenen 0 bis 2 unterstützen in der Regel keine identitätsbasierten Kontrollen, sodass die Netzwerksegmentierung der primäre Schutzmechanismus für die Steuerung physischer Prozesse bleibt.

Was ist der Unterschied zwischen dem ursprünglichen Purdue-Modell und dem Extended Purdue Model?

Das ursprüngliche Modell von 1991 definierte sechs Ebenen (0 bis 5) für Datenflüsse in der rechnerintegrierten Fertigung. Das Extended Purdue Model ergänzt Ebene 3.5, die Industrial DMZ, als verpflichtende Pufferzone zwischen OT (Ebenen 0 bis 3) und IT (Ebenen 4 und 5). 

Das DOE entwickelte diese Erweiterung speziell, weil die IT/OT-Konvergenz die ursprüngliche Grenze unzureichend machte. Jede aktuelle staatliche Empfehlung betrachtet Ebene 3.5 als essenziell.

Wie lässt sich das Purdue-Modell auf ISA/IEC 62443 abbilden?

ISA/IEC 62443 baut seine Zonen- und Leitungs-Sicherheitsarchitektur direkt auf den hierarchischen Ebenen des Purdue-Modells auf. Jede Purdue-Ebene entspricht einer Sicherheitszone mit definierten Sicherheitsstufen (SL 1 bis 4), die von Basisschutz bis hin zur Abwehr fortgeschrittener, staatlich unterstützter Angriffe reichen. 

Leitungen, die Zonen verbinden, müssen mit derselben Kritikalität gesichert werden wie die vertrauenswürdigste Zone, die sie verbinden. Diese Zuordnung bietet Sicherheitsteams eine prüfbare, standardkonforme Architektur für ICS-Compliance-Bewertungen und behördliche Überprüfungen.

Warum gilt Ebene 2 als die größte Sicherheitslücke in ICS-Umgebungen?

Ebene 2 umfasst SCADA-Systeme und HMIs, die Windows-basierte Betriebssysteme ausführen und gleichzeitig direkte Befehlsgewalt über Ebene 1 PLCs haben. Dadurch sind sie sowohl für gängige IT-Angriffstechniken anfällig als auch in der Lage, physische Prozesse zu steuern. 

Da Ebene 2 häufig den Dreh- und Angelpunkt zwischen einem Angriff auf das Unternehmensnetzwerk und der Beeinflussung physischer Prozesse bildet, stellt sie in realen Anlagen oft die größte Überwachungs- und Zugriffskontrolllücke dar.

Was ist der häufigste Fehler bei der Implementierung des Purdue-Modells?

Bereitstellung von VLANs ohne Durchsetzung von Inter-VLAN-Zugriffskontrollen. Proaktive Bedrohungssuchen der CISA dokumentierten Organisationen mit korrekt getrennten IT- und SCADA-VLANs, jedoch ohne Firewall-Regeln zwischen ihnen, wodurch nicht privilegierte IT-Benutzer auf kritische SCADA-Netzwerke zugreifen konnten. 

VLANs organisieren den Netzwerkverkehr; sie beschränken ihn jedoch nicht. Ohne entsprechende Firewall-Regeln, die die Kommunikation zwischen VLANs explizit einschränken, kann ein Angreifer, der das IT-Netzwerk kompromittiert, sich frei in OT-Systeme bewegen. VLAN-Segmentierung allein bietet keine sinnvolle Sicherheitsgrenze.