OT-Netzwerksegmentierung für die Verteidigung: Das Purdue-Modell mit Klassifizierungs-Overlay

Operational-Technology(OT)-Netzwerke in Verteidigungssystemen — die Steuerungsebenen hinter Radaren, Antriebsanlagen, Waffensystem-Prüfständen, Magazinhandhabung, Bodenstations-Antennenarrays — versagen anders als Enterprise-IT. Ein Ransomware-Vorfall auf einer Unternehmens-Dateifreigabe ist wiederherstellbar; ein verwirrter speicherprogrammierbarer Controller in einer Antriebsanlage während einer umkämpften Passage ist es nicht. Die erste Engineering-Frage lautet daher nicht „wie patchen wir schneller", sondern „wie ist das Netzwerk aufgeteilt und was überquert jede Grenze". Das ist die Segmentierungsfrage, und seit fünfzig Jahren ist die kanonische Antwort die Purdue Enterprise Reference Architecture, geschichtet über die Zonen-und-Conduits-Sprache von IEC 62443. Dieser Artikel durchläuft das Modell End-to-End und überlagert dann verteidigungsspezifische Belange: Klassifizierung, Cross-Domain-Transfer, Monitoring eines angeblich Air-Gapped-Stacks und die Akkreditierungs-Papiere, die die Architektur letztlich erfüllen muss.

1. Warum Purdue immer noch zählt

Purdue wurde ursprünglich für Chemie- und Fertigungsprozesssteuerung entworfen, aber seine Kernerkenntnis — dass ein Netzwerk in Schichten mit streng definierten Vertrauensbeziehungen zwischen ihnen zerlegt werden kann — hat jede Generation der Hardware überlebt, auf die es angewendet wurde. Ein „flaches OT"-Netzwerk, in dem Engineering-Workstations, Historians, Mensch-Maschine-Schnittstellen und Feldcontroller alle eine ungefilterte Layer-2-Broadcast-Domain teilen, kann nicht verteidigt werden. Es gibt keine beobachtbare Grenze, an der ein Analyst sagen kann „Verkehr, der diesen Punkt überquert, sollte Modbus sein, sonst nichts"; jeder Host vertraut implizit jedem anderen Host; ein einzelnes kompromittiertes Laptop erreicht jeden PLC über ARP.

IEC 62443 fängt denselben Instinkt mit anderem Vokabular ein: Eine Zone ist eine Gruppe von Assets mit gemeinsamen Sicherheitsanforderungen, und ein Conduit ist der kontrollierte Pfad zwischen Zonen. Conduits, nicht Hosts, sind, wo Sicherheitskontrollen durchgesetzt werden. Die Purdue-Levels sind in Wirklichkeit eine Standard-Zoning-Vorlage — ein Ausgangspunkt, den Verteidigungsprogramme anpassen statt neu erfinden. Für den Rest dieses Artikels verwenden wir Purdue-Level-Nummern und IEC-62443-Zonen-/Conduit-Begriffe synonym; in der Verteidigungs-Cybersicherheits-Praxis beschreiben sie dasselbe Artefakt.

2. Die sechs Purdue-Levels

Level 5 — Enterprise. Corporate IT: E-Mail, ERP, Intranet, Auftragnehmer-Zugang. Auf einem Verteidigungsstandort ist das das nicht-klassifizierte Geschäfts-LAN, auf dem Prüfer, Lohnabrechnung und Programmmanager leben. Es darf Prozess-Equipment niemals direkt berühren.

Level 4 — Site Business Planning and Logistics. Wartungsmanagement, Ersatzteil-Inventar, Auftragssysteme. Für ein See-Kampfsystem ist das die landseitige Logistik-Kette; für eine Luftabwehr-Batterie das Depot-Level-Support-System. Immer noch IT-artig, immer noch in einem IT-Rhythmus gepatcht.

Level 3.5 — Industrial DMZ. Die wichtigste einzelne Zone im Modell. Jeder Fluss zwischen Enterprise-IT und Operations durchquert hier, terminiert und neu-originiert von vermittelten Diensten: Historian-Replikate, Jump-Hosts, Patch-Staging, Antimalware-Update-Mirrors. Kein natives Protokoll überquert die DMZ; nichts auf Level 3 etabliert eine Session mit etwas auf Level 4 oder höher außer über einen DMZ-Proxy.

Level 3 — Site Operations. Produktionsweite Systeme: der operative Historian, Batch-Management-Server, anlagenweite Engineering-Anwendungen, OT-Domain-Controller, OT-Patch-Server. Auf einem Waffensystem-Prüfstand ist das der Range-Control-Raum — der Ort, an dem Testleiter Läufe über mehrere Zellen orchestrieren.

Level 2 — Supervisory Control. HMIs, lokale Engineering-Workstations, Alarm-Server, Sichtlinien-SCADA. Für eine Antriebsanlage ist das die Maschinen-Kontrollkonsole; für ein Radar der taktische Anzeigeserver des Operators. Menschen steuern den Prozess von Level 2 aus.

Level 1 — Basic Control. PLCs, RTUs, sicherheitsinstrumentierte Systeme, dedizierte Controller. Die Logik, die Dampfdruck hält, eine Antenne schwenkt, einen Werfer sequenziert oder einen Reaktor abschaltet. Echtzeit, deterministisch, oft nicht in der Lage, auch nur eine Millisekunde Jitter zu tolerieren, die durch eine fehlkonfigurierte Firewall eingeführt wird.

Level 0 — Process. Sensoren und Aktuatoren, Ventile, Motoren, Wandler, die Physik des Systems. Zunehmend digital (HART, IO-Link, Profibus-PA, FOUNDATION Fieldbus) und daher zunehmend Teil des Cybersicherheits-Scopes.

Die entscheidende Eigenschaft ist, dass je tiefer man geht, desto deterministischer, desto weniger gepatcht und desto weniger fähig das Equipment ist, sich selbst zu verteidigen. Ein Level-1-Controller, gebaut 2009, hat keine Authentifizierung auf seinem Engineering-Protokoll. Der gesamte Zweck der Segmentierung ist, das mit Grenzkontrollen zu kompensieren.

3. Klassifizierungs-Overlay auf Purdue-Zonen

Die Verteidigung fügt eine zweite Achse hinzu, die Purdue nicht vorhersah: Klassifizierung. Eine NATO-RESTRICTED-Logistikansicht eines Wartungsrückstands und eine GEHEIM-taktische Ansicht derselben Plattform können auf demselben Purdue-Level leben, können aber keine Broadcast-Domain teilen. Das Ergebnis ist eine Matrix: Purdue-Level auf einer Achse, Klassifizierung auf der anderen.

In der Praxis kollabiert die Matrix auf eine kleine Anzahl akkreditierter Kombinationen. Level-5-Enterprise ist typischerweise NICHT-KLASSIFIZIERT oder NATO RESTRICTED. Die Industrial DMZ kann auf mehreren Klassifizierungen existieren, eine pro Enklave. Levels 3 bis 0 — die eigentliche Prozesssteuerung — sind normalerweise auf die höchste Klassifizierung jeglicher von ihnen behandelten Daten festgesetzt, nach dem Prinzip, dass der Controller die Klassifizierung nicht aus seinem eigenen Zustand strippen kann. Der Level-1-Controller eines Radars, der eine klassifizierte Wellenform betreibt, sitzt in einer GEHEIM-Enklave, auch wenn der Controller selbst ein Commodity-PLC ist.

Der architektonisch ehrliche Schritt ist, die Matrix früh zu zeichnen, jede Zelle mit ihrem Akkreditierungsverantwortlichen und ihren erlaubten Conduits zu beschriften und sich zu weigern, irgendetwas zu deployen, das nicht in eine beschriftete Zelle passt. Hier treffen sich auch Zero-Trust-Prinzipien mit klassischer Defense-in-Depth: identitätsbewusste Policy innerhalb einer Zone, hardwaregestützte Trennung zwischen Klassifizierungen.

4. Cross-Domain-Solutions in OT

Sobald die Matrix existiert, wird die Frage, wie Daten zwischen Zellen wandern. Zwei Kategorien von Cross-Domain-Solutions dominieren OT-Deployments.

Einweg-Datendioden. Hardware-Geräte (Owl, Waterfall, Fox-IT FoxDataDiode, Advenica), die physisch Verkehr nur in eine Richtung erlauben — typischerweise ein Glasfaser-Sender auf einer Seite und ein Empfänger auf der anderen, ohne möglichen Rückweg auf der physischen Schicht. Der klassische OT-Use-Case ist der Export von Historian-Daten von Level 3 zu einem Level-4- oder Enterprise-Replikat, ohne die OT-Seite irgendwelchem Rückverkehr auszusetzen. Dioden sind die richtige Antwort, wenn der Datenfluss monoton ist: Telemetrie raus, nichts rein. Sie sind die falsche Antwort für alles, was Bestätigungen, Patches rein oder Remote-Hersteller-Support braucht.

Transfer-Guards. Anwendungsbewusste Gateways (Forcepoint DDP, Fox-IT DataDiode im Guard-Modus, Everfox Trusted Gateway, Owl ReCon), die Inhalte, die eine Klassifizierungsgrenze überqueren, in beide Richtungen inspizieren und filtern. Ein Guard kann einen sanitisierten Wartungsauftrag von GEHEIM zu RESTRICTED freigeben, nachdem er verifiziert hat, dass er keine klassifizierten Annotationen trägt, oder ein geprüftes PLC-Firmware-Update aus einer niedrigeren Enklave in eine höhere ziehen. Guards sind langsamer, teurer und schwerer zu akkreditieren als Dioden, aber sie sind die einzige ehrliche Antwort, wenn bidirektionaler Fluss wirklich erforderlich ist.

Die Engineering-Regel ist, mit einer Diode anzufangen und nur dann auf einen Guard zu eskalieren, wenn der operative Use-Case beweist, dass bidirektionaler Fluss unvermeidlich ist.

5. East-West vs. North-South Segmentierung

Purdue ist primär ein North-South-Modell: Verkehr bewegt sich Ebenen hoch und runter und wird an jedem Conduit gefiltert. Aber moderne Angriffe sind East-West — sobald ein Gegner auf einem Level-2-HMI ist, ist der nächste Zug seitwärts zum benachbarten HMI, nicht aufwärts zum Historian. East-West-Segmentierung innerhalb eines Purdue-Levels ist daher die zweite Front.

Mikrosegmentierung in OT ist aus drei Gründen härter als in IT. Erstens tragen viele Legacy-Protokolle (Modbus/TCP, DNP3, IEC 60870-5-104, S7) keine Authentifizierung und gehen von einer flachen L2-Domain aus. Zweitens können Controller keine Host-basierten Firewalls ausführen, ohne ihre Echtzeit-Garantien und häufig ihre Hersteller-Garantie zu verletzen. Drittens bedeuten deterministische Timing-Budgets, dass ein fehlkonfigurierter Policy-Enforcement-Point die Anlage schneller niederreißen kann, als es der Angreifer getan hätte.

Die zwei praktischen Ansätze sind VLAN-plus-ACL-Designs auf gemanagten Industrieswitches (Hirschmann, Cisco IE, Moxa) und für OT zweckgebaute SDN-Overlays (TXOne, Claroty xDome Secure Access, Dragos mit NAC-Integrationen). VLANs sind vertraut und akkreditierbar, aber grob; SDN ist feinkörniger, führt aber einen Controller ein, dessen eigene Verfügbarkeit zum Single Point of Failure wird. Die meisten echten Programme enden damit, beides zu betreiben, mit VLANs als Baseline und SDN-Policies darüber für hochwertige Zellen.

6. Monitoring eines Air-Gapped-Stacks

Jedes OT-Programm behauptet, Air-Gapped zu sein. Fast keines ist es tatsächlich. Es gibt einen USB-Port am Engineering-Laptop, ein Hersteller-Laptop, das einmal pro Quartal vorbeikommt, ein Wartungsmodem, das auf dem Papier stillgelegt wurde, aber immer noch eine SIM-Karte hat, ein drahtloses Instrument, das während einer Generalüberholung hinzugefügt wurde. Die Architektur muss annehmen, dass der Air-Gap undicht ist, und entsprechend instrumentieren.

Passive Monitoring-Plattformen — Nozomi Networks Guardian, Claroty CTD/xDome, Dragos Platform, Tenable OT Security — sitzen auf Span-Ports innerhalb jeder Zone und rekonstruieren Asset-Inventare, Protokoll-Baselines und Anomalie-Signale aus passiv beobachtetem Verkehr. Sie injizieren niemals Pakete, was sie auf produktivem OT ohne Hersteller-Widerstand einsatztauglich macht. Kombiniert mit Historian-basierter Detektion (Abfragen gegen den Historian für unmögliche Sollwertänderungen, Befehlsraten über menschlicher Fähigkeit, Sequenzen, die Prozessverriegelungen verletzen) und Engineering-Workstation-EDR bilden sie einen verteidigbaren Monitoring-Stack, auch wenn das Netzwerk nominell isoliert ist. Das ist die Linie, die in unserem ICS/OT-Forensik-Walkthrough erforscht wird.

7. Identität und Zugang in OT

Identität in OT wird von drei Populationen dominiert: Engineering-Workstations, die von Standortpersonal verwendet werden, Hersteller-Remote-Access-Sessions und Break-Glass-Konten, die für Schadenskontrolle vorgehalten werden. Jede erfordert ihre eigene Disziplin.

Engineering-Workstations sollten sich gegen ein OT-seitiges Verzeichnis authentifizieren — niemals das Enterprise-IT-Verzeichnis — mit hardwaregestützten Anmeldedaten und Session-Aufzeichnung. Die Corporate-Active-Directory über die Industrial DMZ zu teilen ist der häufigste architektonische Fehler in der Verteidigungs-OT; es verwandelt eine Enterprise-Anmeldedaten-Kompromittierung in eine OT-Kompromittierung. Paart das mit Hardware Roots of Trust auf den Workstations selbst, um die Anmeldedaten an das Gerät zu binden.

Hersteller-Remote-Access ist das ewige Risiko. Das richtige Muster ist ein Jump-Host in der Industrial DMZ, vermittelter Zugang mit voller Session-Aufzeichnung, zeitlich begrenzte Autorisierungen und ein Operator-im-Loop-„Bildschirmfreigabe"-Modell statt autonomer Hersteller-Konnektivität. Das falsche Muster — immer noch häufig — ist ein permanentes Site-to-Site-VPN aus dem Büro des Herstellers in Level 3.

Break-Glass-Prozeduren müssen existieren, weil OT-Prioritäten manchmal die Cyber-Prioritäten umkehren: In einem Schadensfall muss ein Wachhabender einen Controller jetzt überschreiben, nicht nach einer Token-Rotation. Dokumentiert die Break-Glass-Anmeldedaten, lagert sie physisch, loggt jede Verwendung und behandelt jede Verwendung als Vorfall, der eine Nachbetrachtung erfordert.

8. Akkreditierungs-Evidenz

Nichts davon zählt, wenn die Segmentierung die Akkreditierung nicht überlebt. Ein Authority-to-Operate(ATO)-Paket für ein Verteidigungs-OT-Segment enthält typischerweise: das Zonen-und-Conduit-Diagramm mit Klassifizierungslabels; die IEC-62443-Security-Level-Target(SL-T)-Bestimmung pro Zone, gerechtfertigt gegen das Bedrohungsmodell; Conduit-für-Conduit-Kontroll-Mappings (welche Filter, welche Protokolle, welches Logging); Evidenz der Cross-Domain-Solution-Akkreditierung (NCDSMO-Baseline für USA, nationale Äquivalente in NATO-Mitgliedern); Restrisiko-Statements für jede Kontrolllücke; und einen operativen Continuous-Monitoring-Plan, der beschreibt, wie das SL-T über die Zeit neu evidenziert wird.

SL-T-Bestimmung ist, wo Engineering auf Papierkram trifft. IEC 62443-3-2 definiert vier Security Levels (SL 1 bis SL 4), die die Fähigkeit des Gegners darstellen, dem die Zone widerstehen muss — vom Gelegenheitstäter bis zum Nationalstaat mit ausgedehnten Ressourcen. Ein Radar-Steuerungs-Segment auf einer vorn-eingesetzten Plattform ist typischerweise SL 3 oder SL 4. Der gewählte SL treibt jede nachgelagerte Kontrollanforderung in IEC 62443-3-3, von Passwort-Policy bis kryptographischer Algorithmuswahl. Wählt das SL zu niedrig und der Akkreditierer lehnt das Paket ab; wählt es zu hoch und ihr könnt es nicht leisten, es zu bauen.

Schließlich ist Re-Akkreditierung ein wiederkehrender Rhythmus, kein einmaliges Ereignis. Die meisten Verteidigungs-Regime erfordern alle drei Jahre eine vollständige Neubewertung und ein Delta-Review bei jeder „signifikanten Änderung" — was in OT das nächste Hersteller-Firmware-Update einschließt. Architektiert die Segmentierung so, dass sich die Evidenz selbst regeneriert: Konfiguration in Versionskontrolle erfasst, Monitoring-Ausgaben als Akkreditierungs-Artefakte archiviert, Änderungsaufzeichnungen mit Risiko-Neubewertungen verknüpft. Die Segmentierung, die ihr nicht neu beweisen könnt, ist die Segmentierung, die ihr nicht mehr habt.