Zones, Conduits und Security Level: Schutzbedarfslogik für die OT

Problem in der Praxis

In vielen Werken ist die OT historisch flach gewachsen: Steuerungen, Bedienstationen und Feldgeräte hängen in wenigen großen Segmenten, die Verbindungen zur IT und nach außen sind entstanden, nicht entworfen. Wird ein Segmentierungsprojekt gestartet, orientiert es sich oft an der vorhandenen Netzwerktopologie statt am Schadenspotenzial.

Beim Security Level wird häufig falsch verhandelt. Entweder fordert jeder Bereich vorsorglich ein hohes SL, ohne die Kosten zu verantworten, oder ein Lieferant verspricht ein hohes SL für ein einzelnes Produkt und erweckt den Eindruck, die ganze Anlage sei abgesichert. Ohne saubere Zonen- und Conduit-Definition bleibt unklar, was geschützt werden soll; ohne risikobasiertes Ziel-SL bleibt unklar, wie gut.

CISO-Einordnung

Drei Begriffe tragen das Modell:

• Eine Zone ist eine Gruppe von Komponenten mit gemeinsamem Schutzbedarf. Maßgeblich ist die Konsequenz einer Kompromittierung, nicht die Netzgrenze. Sicherheitsgerichtete Funktionen, Steuerungskern und der Übergang zur IT gehören in unterschiedliche Zonen.
• Ein Conduit ist der bewusst definierte Kommunikationskanal zwischen Zonen mit eigenen Sicherheitsanforderungen. Was nicht über einen definierten Conduit läuft, soll nicht laufen.
• Das Security Level beschreibt das Schutzziel einer Zone abgestuft nach Angreiferfähigkeit: von zufälligem oder fahrlässigem Fehlverhalten (SL1) bis zu Angreifern mit erheblichen Ressourcen und Spezialwissen (SL4). Die Stufen dazwischen steigen mit der Angreiferfähigkeit.

Zu unterscheiden sind gefordertes Schutzziel (Target-SL), technische Fähigkeit einer Komponente (Capability-SL) und tatsächlich erreichter Schutz im Betrieb (Achieved-SL). Die Lücke zwischen Soll und Ist ist die eigentliche Steuerungsgröße: Sie zeigt, wo investiert, kompensiert oder bewusst Risiko akzeptiert werden muss. Das Ganze folgt dem Prinzip Defense-in-Depth: gestaffelte Schutzschichten statt einer einzigen Außengrenze. In der 62443-Reihe ist die risikobasierte Aufteilung konzeptionell dem Risk-Assessment-Teil (62443-3-2) zugeordnet, die SL-Systematik auf Systemebene 62443-3-3.

Umsetzungsperspektive

Sinnvoll ist eine Reihenfolge, die mit dem Risiko beginnt, nicht mit der Technik:

• Anlagenkontext: Welche Prozesse sind kritisch, welche Konsequenz hätte Ausfall oder Manipulation für Verfügbarkeit, Safety, Qualität und Umsatz?
• Zonen ableiten: Komponenten mit gleichem Schutzbedarf zusammenfassen, sicherheitsgerichtete Funktionen abgrenzen, einen kontrollierten OT/IT-Übergang vorsehen.
• Conduits benennen: nur betrieblich notwendige Verbindungen zulassen; alles andere wird begründungspflichtige Ausnahme.
• Target-SL je Zone aus der Risikobewertung ableiten, nicht aus dem Wunsch nach maximaler Sicherheit.
• Soll-Ist-Abgleich: Was leisten vorhandene Komponenten (Capability-SL), und wie schließt man die Lücke: durch Conduit-Maßnahmen, Kompensation oder Ersatzbeschaffung?

Das Rollenmodell der 62443 ordnet Verantwortung zu: Der Asset Owner (Betreiber) verantwortet Risiko und Ziel-SL, der System Integrator beziehungsweise Service Provider plant und wartet entlang dieser Vorgaben, der Product Supplier liefert Komponenten mit ausgewiesener Capability. Ohne klare Rollenzuordnung bleibt das Modell Papier.

Typische Fehler

1. Zonen entlang vorhandener Netzsegmente und VLANs statt entlang von Schutzbedarf und Schadenspotenzial.
2. Conduits nicht explizit definiert; faktisch bleibt Any-to-any-Kommunikation bestehen.
3. Target-SL pauschal hoch ("SL3 für alles") ohne Risikobegründung und Kostenverantwortung.
4. Begrenzte Capability-SL von Legacy-Komponenten ignoriert statt kompensiert.
5. Ein zertifiziertes Einzelprodukt mit der Sicherheit der gesamten Zone verwechselt.
6. Modell einmal erstellt, nie gepflegt; mit jeder Anlagenänderung verliert es Realitätsbezug.

Risiken und Trade-offs

Segmentierung in der OT steht in einem Spannungsfeld, das die IT so nicht kennt. Der Verfügbarkeits- und Echtzeitprimat erlaubt nur begrenzte Eingriffe, viele Legacy-Protokolle können sich nicht authentisieren, Patches sind nur in engen Wartungsfenstern möglich, und Schutzmaßnahmen dürfen die funktionale Sicherheit (Safety) nicht beeinträchtigen. Jede Conduit-Maßnahme ist gegen diese Randbedingungen abzuwägen.

Auch das Zielniveau ist ein Trade-off: Ein zu hohes Target-SL erzeugt Kosten ohne Risikonutzen, ein zu niedriges lässt kritische Zonen ungeschützt. Ebenso ist zwischen Über- und Untersegmentierung zu balancieren: zu viele kleine Zonen werden unbeherrschbar, zu wenige verfehlen die Schutzwirkung.

Entscheidungspunkte

• Welche Konsequenzschwere rechtfertigt eine eigene Zone, und wo verlaufen die Vertrauensgrenzen?
• Welches Target-SL ist je Zone angesichts Risikoappetit und Budget angemessen?
• Wie wird mit der Lücke zwischen Capability-SL und Target-SL umgegangen: aufrüsten, kompensieren oder Risiko akzeptieren?
• Wer ist je Zone und je Conduit verantwortlich, und wie verteilt sich die Verantwortung zwischen Betreiber, Integrator und Hersteller?
• Wie wird das Modell bei Anlagenänderungen aktuell gehalten?

Praktische Empfehlungen

1. Mit einer konsequenzbasierten Risikobewertung beginnen, nicht mit dem Netzplan.
2. Den kontrollierten OT/IT-Übergang und die Abgrenzung sicherheitsgerichteter Funktionen als ersten, besonders wirksamen Schritt behandeln.
3. Je Zone das Target-SL samt Begründung dokumentieren und Achieved gegen Target als lebendes Lücken-Register führen.
4. Bei Legacy-Komponenten die Lücke über Conduit- und Kompensationsmaßnahmen schließen.
5. SL-Anforderungen in Beschaffung und Änderungsmanagement verankern; Lieferanten nach der Capability-SL fragen.
6. Das frei verfügbare BSI ICS-Security-Kompendium als gemeinsame Begriffsbasis und Brücke zum IT-Grundschutz nutzen.

Relevante Normreferenzen

• IEC 62443-3-3 (System security requirements and security levels): SL-Systematik auf Systemebene; Edition 1.0 (2013-08). Kostenpflichtig, nur Konzeptbezug.
• IEC 62443-3-2 (Risk assessment für Zones & Conduits): risikobasierte Segmentierungslogik. Kostenpflichtig, nur Konzeptbezug.
• BSI ICS-Security-Kompendium, Version 2.0.0 (Stand 23.04.2024): frei zugängliche deutschsprachige Grundlage und Brücke zum IT-Grundschutz.
• ISO/IEC 27001: ISMS-Dach; deckt OT-Spezifika nicht vollständig ab und wird durch 62443 ergänzt.
• NIST SP 800-82 (Guide to OT Security): komplementäre OT-Leitlinie.