Das OT-Sicherheitsprogramm des Betreibers (IEC 62443-2-1)

Problem in der Praxis

OT-Umgebungen sind historisch von Engineering und Instandhaltung geprägt, nicht von der IT-Security. Wird ein klassisches IT-Sicherheitsprogramm unverändert übergestülpt, entstehen typische Reibungspunkte:

• Verfügbarkeit und Prozessstabilität haben oft Vorrang. Ein Patch lässt sich nicht beliebig einspielen, weil Wartungsfenster, Herstellerfreigaben und Safety-Wechselwirkungen zu beachten sind.
• Langlebige Anlagen nutzen Legacy-Protokolle und Komponenten, die nie für eine vernetzte Welt entworfen wurden.
• Das Asset-Inventar ist häufig unvollständig; niemand kann verlässlich sagen, welche Steuerungen, Engineering-Workstations und Fernzugänge existieren.
• Verantwortung ist zwischen IT, OT und Dienstleistern unklar verteilt.

Spätestens wenn ein Auditor, ein Kunde, eine Aufsicht im NIS2-Kontext oder ein Vorfall Fragen stellt, zeigt sich die Lücke: oft Einzelmaßnahmen, aber kein nachvollziehbares Betreiberprogramm.

CISO-Einordnung

IEC 62443 unterscheidet drei Rollen: den Asset Owner (Betreiber), den System Integrator beziehungsweise Service Provider und den Product Supplier (Hersteller). Das Betreiber-Sicherheitsprogramm nach 62443-2-1 ist Aufgabe des Asset Owners. Der CISO sollte diese Rollentrennung nutzen, um Verantwortung sauber zu adressieren, statt Hersteller- und Betreiberpflichten zu vermischen.

Konzeptionell lehnt sich das Betreiberprogramm an die Logik eines ISMS an: Kontext, Rollen, Risiken, Maßnahmen, Nachweise, Reaktion und Verbesserung in einem wiederholbaren Regelkreis. Hinzu kommen OT-spezifische Konzepte der Normenfamilie, die als Orientierung dienen, nicht als Checkliste:

• Zones & Conduits: Aufteilung der Anlage in Sicherheitszonen mit definierten Kommunikationskanälen als Grundlage für Segmentierung und Risikobewertung (Defense-in-Depth).
• Security Levels (SL1 bis SL4): gestufte Schutzziele nach Angreiferfähigkeit, von zufälligem Fehlverhalten bis zu Angreifern mit erheblichen Ressourcen.
• die sieben Foundational Requirements als Gliederungsrahmen technischer Anforderungen.

Wichtig: ISO/IEC 27001, IT-Grundschutz und vergleichbare ISMS-Ansätze sind IT-zentriert und decken OT-Spezifika wie Verfügbarkeitsprimat, Legacy-Protokolle, Patch-Restriktionen und Safety-Wechselwirkung nicht vollständig ab. IEC 62443 ergänzt hier OT-spezifisch.

Umsetzungsperspektive

Aus CISO-Sicht sollte ein OT-Sicherheitsprogramm mit einem kleinen, betreibbaren Kern starten und mit dem ISMS verzahnt werden:

• Governance und Rollen für OT: klare Verantwortung zwischen IT-Security, OT-/Werkleitung und Dienstleistern, eingebunden in die ISMS-Governance.
• Asset-Management: ein gepflegtes Inventar der OT-Systeme, Netze und Fernzugänge als Fundament. Ohne belastbares Inventar bleibt jedes Steuerungselement unscharf.
• Risikobasierte Segmentierung: Zonen und Conduits, um kritische Bereiche zu trennen und Schutzbedarf differenziert zuzuweisen.
• Zugriffsmanagement: kontrollierte Identitäten und Berechtigungen, besonders für privilegierte Zugänge, Engineering-Werkzeuge und Fernwartung Dritter.
• Patch- und Schwachstellenmanagement, OT-gerecht: bewertet, getaktet, an Wartungsfenster und Herstellerfreigaben gebunden, mit kompensierenden Maßnahmen, wenn ein Patch nicht möglich ist.
• Monitoring, Reaktion und Dienstleistersteuerung: ein OT-tauglicher Incident-Prozess abgestimmt mit Safety und Betrieb sowie Anforderungen an Integratoren und Service Provider.

Als frei nutzbare deutschsprachige Grundlage dient das BSI ICS-Security-Kompendium (Version 2.0.0, 2024): Es verallgemeinert von ICS auf OT, führt Betreiber- und Hersteller-/Integratorensicht zusammen und bildet eine Brücke zum IT-Grundschutz.

Typische Fehler

1. Das OT-Programm wird als reines Technikprojekt behandelt, ohne Governance, Rollen und Taktung.
2. Maßnahmen werden geplant, bevor ein belastbares Asset-Inventar existiert.
3. IT-Patch-Logik wird unverändert auf OT übertragen und kollidiert mit Verfügbarkeit und Safety.
4. Fernzugänge von Dienstleistern bleiben unkontrolliert und undokumentiert.
5. OT-Sicherheit wird parallel zum ISMS betrieben, sodass Nachweise und Reporting doppelt und widersprüchlich geführt werden.

Risiken und Trade-offs

Der grundlegende Zielkonflikt der OT ist Verfügbarkeit gegen Veränderung. Jede Härtung, jeder Patch und jede Segmentierung kann den Betrieb stören. Wer zu vorsichtig agiert, häuft Schwachstellen an; wer zu forsch patcht, riskiert Produktionsausfälle oder Safety-Effekte. Der CISO muss diesen Konflikt bewusst steuern, statt ihn an Einzelpersonen zu delegieren.

Ein zweiter Trade-off liegt zwischen Standardisierung und Anlagenrealität: Einheitliche Vorgaben erleichtern Steuerung und Reporting, passen aber oft nicht zu heterogenen Anlagen, Standorten und Herstellern. Drittens droht eine Zuständigkeitslücke zwischen IT und OT: Fühlt sich niemand klar verantwortlich, entsteht trotz Programm keine Wirkung.

Entscheidungspunkte

• Welche Anlage oder welcher Standort ist der erste sinnvoll betreibbare Geltungsbereich des OT-Programms?
• Wie werden Verantwortlichkeiten zwischen IT-Security, OT-Betrieb und Dienstleistern verbindlich geschnitten?
• Wird das OT-Programm in das bestehende ISMS integriert oder eigenständig geführt, und wie werden Risiken und Nachweise zusammengeführt?
• Nach welcher Logik werden Patches und kompensierende Maßnahmen in der OT bewertet und freigegeben?

Praktische Empfehlungen

1. Starten Sie mit Asset-Inventar und Rollen, nicht mit Technikbeschaffung.
2. Verankern Sie das OT-Programm als OT-Ausprägung des ISMS, mit gemeinsamer Risiko- und Nachweislogik statt Parallelwelt.
3. Definieren Sie einen OT-gerechten Patch- und Änderungsprozess inklusive Wartungsfenstern, Herstellerfreigaben und kompensierenden Maßnahmen.
4. Bringen Sie Fernwartung und privilegierte Zugänge unter kontrollierte Identitäten und Protokollierung.
5. Nutzen Sie das BSI ICS-Security-Kompendium als gemeinsame Begriffs- und Best-Practice-Basis zwischen IT und OT.

Relevante Normreferenzen

• IEC 62443-2-1 (Security program requirements for IACS asset owners), Edition 2.0 (2024): Referenz für das Betreiber-Sicherheitsprogramm; kostenpflichtig, daher nur konzeptionelle Bezugnahme.
• IEC 62443-Serie allgemein: Referenz für Zones & Conduits, Security Levels und das Rollenmodell (Asset Owner, System Integrator/Service Provider, Product Supplier).
• BSI ICS-Security-Kompendium, Version 2.0.0 (2024): frei nutzbares deutschsprachiges Grundlagenwerk und Brücke zum IT-Grundschutz.
• ISO/IEC 27001: Referenz für das ISMS-Dach, in das ein OT-Programm eingebettet wird.
• NIST SP 800-82 (Guide to OT Security, aktuelle Revision): ergänzende OT-Leitlinie.