Beyond Purdue: OT-Segmentierung mit IEC 62443

Die Illusion der Segmentierung: Wenn Diagramme nicht zur Realität passen

Organizations often feel confident in their OT architecture. They have firewalls between levels, a DMZ, and clearly labeled networks. On paper, the structure looks aligned with industry best practices.

But real-world environments frequently behave very differently than the drawing suggests.

Common challenges include:Viele Organisationen sind von ihrer OT-Architektur überzeugt. Firewalls zwischen den Levels, eine DMZ und klar beschriftete Netzwerke – auf dem Papier wirkt alles wie nach Lehrbuch.

In der Realität verhalten sich Umgebungen jedoch häufig ganz anders, als es die Zeichnung suggeriert.

Typische Herausforderungen sind:

• Flache Layer-2-Netze innerhalb eines Levels, die ungehinderte laterale Bewegung ermöglichen.

Beispiel: Kontrollnetze, in denen Firewalls Level 3 von Level 2 trennen – innerhalb von Level 2 ist jedoch alles von allem erreichbar.

• Remote-Zugriffspfade (VPNs, Vendor-Tools), die das Modell vollständig umgehen.

Beispiel: Von Herstellern gewartete Maschinen mit eigenen Mobilen Routern, die Hintertüren ins Netz eröffnen.

• Geteilte Services oder Engineering-Workstations, die unbeabsichtigte Cross-Zone-Konnektivität schaffen.

Beispiel: Historian-Server, die OT mit IT verbinden, mit zu weit gefassten Regeln, weil „die Produktion es braucht“.

• Cloud- und IIoT-Integrationen, die nicht sauber in die hierarchische Level-Struktur passen.

Beispiel: Outbound-Tunnel von cloud-verbundenen Geräten, die DMZ-Grenzen faktisch aushebeln.

‍

Das Purdue-Modell wurde nie für diese modernen Realitäten entwickelt. Und weil es nicht risikobasiert ist, kann es nicht erklären, warum bestimmte Kommunikationswege stärker geschützt werden müssen – oder ob die Architektur modernen Bedrohungen standhält.

‍

Warum diese Lücke entsteht

Wenn das Purdue-Modell so weit verbreitet ist – warum hält sich die Verwirrung?

Weil es simpel, vertraut und operativ intuitiv ist. Und weil OT-Umgebungen stärker von Verfügbarkeit, Hersteller-Vorgaben und Betriebskontinuität geprägt sind als von abstrakten Security-Frameworks.

Mehrere Faktoren verstärken diese Lücke:

Operative Prioritäten

Produktions-Uptime dominiert Entscheidungen. Wenn eine Verbindung zur Fehlersuche benötigt wird, wird sie häufig zuerst freigeschaltet und – wenn überhaupt – später überprüft.

Missverstandene Rollen

IT, OT, Engineering, Automatisierungshersteller und Integratoren tragen alle zum Netzwerk bei, doch niemand „besitzt“ die OT-Sicherheitsarchitektur Ende-zu-Ende.

Falsches Vertrauen in das Diagramm

Ein Purdue-Diagramm wirkt strukturiert – also gehen Teams davon aus, dass Segmentierung bereits existiert, auch wenn die Controls darunter unvollständig oder zu permissiv sind.

Fehlende Sicherheitsziele

Purdue definiert Levels, aber keine Security Levels, Risikoklassen oder Zonen-Ziele.

Ohne diese bleibt Segmentierung eine technische Layout-Frage, kein Sicherheits-Control.

Hier liefert IEC 62443 die fehlende Struktur.

‍

Wo IEC 62443 übenrimmt

IEC 62443 interessiert sich nicht für Level 0–5. Es interessiert sich für Risiko, Kritikalität und Vertrauensgrenzen.

‍

Seine Kernkonzepte schaffen Klarheit, die Purdue allein nicht liefern kann:

Zonen

Gruppen von Assets mit gleichen Sicherheitsanforderungen – unabhängig davon, auf welchem Purdue-Level sie liegen.

Conduits

Kontrollierte Kommunikationspfade zwischen Zonen, in denen Authentifizierung, Filterung und Inspektion durchgesetzt werden.

Security Levels (SL)

Definierte Schutzziele basierend auf den Bedrohungsfähigkeiten, gegen die sich eine Organisation verteidigen muss.

‍

Damit wird Segmentierung neu gerahmt – von:

‍„Wo gehört dieses Gerät hin?“

zu

„Welche Sicherheitsanforderungen gelten für diese Funktion – und wie darf sie kommunizieren?“

Dieser Unterschied ist fundamental. Purdue liefert Struktur; IEC 62443 liefert Sicherheits-Intent.

‍

Was sollten Sie als Nächstes tun?

OT-Segmentierung zu verbessern bedeutet nicht, Purdue wegzuwerfen oder die gesamte Architektur neu zu zeichnen. Es beginnt damit, anzuerkennen, dass Hierarchie allein keine Sicherheit schafft, und das Design an IEC-62443-Prinzipien auszurichten.

‍

Führende Organisationen starten typischerweise mit:

1. Topologie von Sicherheit trennen

Purdue bleibt wertvoll – nur eben nicht als Segmentierungs-Framework.

Der erste Schritt ist, „wo etwas steht“ von „wie es geschützt werden muss“ zu trennen. ‍

2.Sinnvolle Sicherheitszonen definieren

Statt nach Level zu gruppieren, werden Zonen nach Risiko, Funktion, Exposure und Kritikalität gebildet.

3.Vertrauenswürdige Conduits etablieren

Verbindungen zwischen Zonen sind bewusst, begründet und gesteuert – nicht einfach erlaubt, weil „das System es braucht“.

4.Security Levels einführen

Die Security Levels der IEC 62443 verwandeln Architektur von einem Visualisierungsmodell in eine verteidigbare Position entlang realistischer Bedrohungsszenarien.

5.Segmentierung in Governance verankern

Architektur bleibt nur sicher, wenn Access Control, Vendor-Integrationen, Change-Management und Beschaffungsanforderungen sie dauerhaft unterstützen.

‍

Das löst kein Tool allein.

Es erfordert koordiniertes Vorgehen zwischen Betrieb, Engineering, IT und Security sowie eine Design-Methodik, die IEC-62443-Konzepte in praktische, standort-spezifische Entscheidungen übersetzt.

Von Diagrammen zu verteidigbarer Architektur

Das Purdue-Modell und IEC 62443 sind keine konkurrierenden Ansätze. Zusammen ergeben sie ein vollständiges Bild:

• Purdue hilft zu verstehen, wie die Umgebung aufgebaut ist.
• IEC 62443 definiert, wie sie geschützt werden muss.

‍

Doch beide Sichtweisen in eine kohärente, funktionierende Architektur zu überführen, ist alles andere als trivial. Industrielle Realitäten – Hersteller-Constraints, Legacy-Systeme, Verfügbarkeitsanforderungen und regulatorischer Druck – verlangen maßgeschneiderte Lösungen statt generischer Templates.

‍

Bei BxC unterstützen wir Organisationen dabei, diese Lücke zu schließen: Wir evaluieren bestehende Architekturen, identifizieren Fehlanpassungen und entwickeln Segmentierungsstrategien, die operativ praktikabel und compliance-seitig verteidigbar sind.

‍

Denn in der OT ist Segmentierung kein Diagramm.

Sie ist eine Sicherheitsentscheidung – und sie muss in der realen Welt funktionieren.