OT/ICS-Security verstehen: warum Betriebstechnik eigene Regeln braucht

Problem in der Praxis

Viele Unternehmen behandeln OT lange als Verlängerung der IT. Sicherheitsrichtlinien, Patch-Zyklen und Tool-Standards aus der Office-Welt werden auf die Produktion übertragen, ohne die Betriebslogik der Anlage zu berücksichtigen. Das führt zu vorhersehbaren Reibungen: Ein automatisches Patch-Fenster kann eine Steuerung in einen ungetesteten Zustand bringen. Ein aktiver Schwachstellenscan kann eine alte SPS oder ein HMI zum Absturz bringen. Und Legacy-Protokolle ohne Authentisierung lassen sich nicht einfach abschalten, weil der Prozess sonst stillsteht.

Spätestens bei einem Vorfall oder einer NIS2-getriebenen Prüfung zeigt sich die Lücke: Es gibt zwar ein ISMS für die IT, aber niemand kann belastbar sagen, welche OT-Assets existieren, in welchen Zonen sie liegen, wer für ihre Sicherheit verantwortlich ist und welches Schutzniveau angestrebt wird. Das ist kein Dokumentationsproblem, sondern ein Steuerungsproblem.

CISO-Einordnung

Der CISO sollte OT-Security nicht als zweites, isoliertes Sicherheitsprogramm aufbauen, sondern als eigenständige Domäne unter einem gemeinsamen Steuerungsdach. Drei Konzepte der 62443-Serie helfen, die OT-Welt managementtauglich zu strukturieren, ohne in technische Detailtiefe zu kippen.

Erstens das Rollenmodell. Die Serie verteilt Verantwortung auf drei Rollen entlang der Wertschöpfungskette: den Asset Owner (Betreiber), der für Betrieb und Risiko der Anlage verantwortlich ist; den System Integrator beziehungsweise Service Provider, der plant, integriert und wartet; und den Product Supplier (Hersteller), der Komponenten und Produkte entwickelt. Diese Trennung klärt, welche Pflichten im eigenen Haus liegen und welche vertraglich an Integratoren und Lieferanten zu adressieren sind.

Zweitens das Zonen-Konzept. Zones & Conduits bedeutet, eine Anlage in Sicherheitszonen mit definierten Kommunikationskanälen (Conduits) zu zerlegen. Das ist die OT-Variante von Segmentierung und Defense-in-Depth und zugleich die Grundlage für Risikobewertung und Schutzlevel-Zuweisung.

Drittens der Schutzlevel-Begriff. Die Security Levels SL1 bis SL4 stufen Schutzziele nach der angenommenen Fähigkeit des Angreifers ab: von zufälligem oder fahrlässigem Fehlverhalten bis zu Angreifern mit erheblichen Ressourcen und Spezialwissen. So lassen sich Schutzanspruch und Investition pro Zone bewusst festlegen, statt überall dasselbe Niveau anzustreben.

Umsetzungsperspektive

Die 62443-Serie ist branchenübergreifend anwendbar und seit 2021 von der IEC als horizontale Norm anerkannt. Sie gliedert sich in vier Schichten: allgemeine Grundlagen, Policies und Prozesse, System-Ebene und Komponenten-Ebene. Für die Managementeinordnung reichen wenige Ankerpunkte je Rolle.

• Betreiber-Sicherheitsprogramm: Beschreibt Aufbau und Pflege eines OT-Security-Management-Programms für Asset Owner. Es ist an ein ISMS anschlussfähig und damit der natürliche Andockpunkt für einen CISO, der bereits ISO 27001 oder IT-Grundschutz betreibt.
• System-Ebene: Führt Security Levels und Zonen-Konzept zusammen; hier entscheidet sich, welches Schutzniveau eine Zone erreichen muss.
• Hersteller-Ebene: Der Secure Development Lifecycle adressiert sichere Produktentwicklung beim Hersteller, von Bedrohungsmodellierung über Verifikation bis zu Schwachstellen-, Patch-Management und End-of-Life.
• Komponenten-Ebene: Technische Komponentenanforderungen, abgeleitet aus sieben Foundational Requirements und den Security Levels. Diese sieben Kategorien (u. a. Identifikation und Authentisierung, Nutzungskontrolle, Systemintegrität, Datenvertraulichkeit, eingeschränkter Datenfluss, rechtzeitige Reaktion, Verfügbarkeit) sind ein Gliederungsrahmen, keine auszufüllende Checkliste.

Als deutschsprachige Brücke bietet sich das frei zugängliche BSI ICS-Security-Kompendium (Version 2.0.0) an. Es verallgemeinert von ICS auf Operational Technology, führt zuvor getrennte Sichten für Betreiber und Hersteller zusammen und verbindet die OT-Welt mit der Begriffs- und Best-Practice-Basis des IT-Grundschutz. So entsteht eine gemeinsame Sprache zwischen IT-Security, OT-Technik und Management.

Typische Fehler

1. OT wird als Verlängerung der IT behandelt; IT-Standardprozesse werden ohne Anpassung auf die Produktion ausgerollt.
2. Es gibt kein belastbares OT-Asset-Inventar und keine Zoneneinteilung, also auch keine Basis für Risiko- und Schutzlevel-Entscheidungen.
3. Verfügbarkeit und Safety-Wechselwirkung werden in der Risikobewertung unterschätzt, weil die IT-Brille Vertraulichkeit priorisiert.
4. Verantwortlichkeiten zwischen Betreiber, Integrator und Hersteller bleiben unklar und werden nicht vertraglich verankert.
5. Es wird ein einheitliches Maximalschutzniveau angestrebt, statt Schutzlevel je Zone risikobasiert festzulegen.
6. Die ISO-27001-Zertifizierung wird als Beleg für OT-Sicherheit gewertet, obwohl der OT-Scope faktisch nicht abgedeckt ist.

Risiken und Trade-offs

Der zentrale Trade-off der OT ist Verfügbarkeit gegen Veränderung. Jede Maßnahme, die Patch, Neustart oder Konfigurationsänderung erfordert, konkurriert mit dem Produktionsprimat und teils mit Safety-Vorgaben; sie muss deshalb in geplanten Wartungsfenstern und mit Rückfallszenarien gedacht werden. Ein hoher Ziel-Schutzlevel erhöht zugleich Aufwand und Komplexität, ein zu niedriger lässt Risiken offen.

Auch organisatorisch gibt es einen Trade-off: Zentralisiert der CISO OT-Security vollständig bei der IT-Security, drohen Akzeptanzverluste und Praxisferne. Belässt er sie vollständig in der Technik, fehlen Steuerung und Nachweisbarkeit. Tragfähig ist meist ein gemeinsames Steuerungsdach mit klarer OT-Fachverantwortung.

Entscheidungspunkte

• Wer ist im eigenen Haus Asset Owner für welche Anlagen, und welche Pflichten gehören vertraglich zu Integratoren und Herstellern?
• Wie wird der OT-Scope vom IT-Scope abgegrenzt, und unter welchem gemeinsamen Steuerungsdach laufen beide?
• Nach welcher Logik werden Zonen gebildet und Ziel-Schutzlevel je Zone festgelegt?
• Wird das vorhandene ISMS (ISO 27001 / IT-Grundschutz) um eine OT-Domäne erweitert oder ein eigenes OT-Security-Programm aufgebaut?
• Welche regulatorischen Treiber (NIS2, CRA) betreffen die eigenen Sektoren und Produkte, und welche OT-Nachweise folgen daraus?

Praktische Empfehlungen

1. Beginnen Sie mit einem OT-Asset-Inventar und einer groben Zoneneinteilung; ohne diese Basis bleibt jede Schutzlevel-Diskussion abstrakt.
2. Legen Sie das Rollenmodell explizit fest und übersetzen Sie Hersteller- und Integratorpflichten in Beschaffungs- und Serviceanforderungen.
3. Definieren Sie Ziel-Schutzlevel risikobasiert pro Zone statt eines einheitlichen Maximalanspruchs.
4. Docken Sie das OT-Security-Programm an Ihr bestehendes ISMS an, statt eine isolierte Parallelwelt zu schaffen.
5. Nutzen Sie das frei verfügbare BSI ICS-Security-Kompendium als gemeinsame Sprache zwischen IT, OT und Management.
6. Verankern Sie Verfügbarkeits- und Safety-Restriktionen fest in der OT-Risikobewertung und planen Sie Maßnahmen entlang von Wartungsfenstern.

Relevante Normreferenzen

• IEC/ISA 62443-Serie: Referenz für OT/ICS-Security (IACS). Kostenpflichtig; hier nur Struktur und Konzept (Rollen, Zones & Conduits, Security Levels), keine Volltexte oder Anforderungslisten.
• BSI ICS-Security-Kompendium (Version 2.0.0): frei zugänglicher deutschsprachiger Bezugsrahmen und Brücke zum IT-Grundschutz.
• ISO/IEC 27001: Referenz für das ISMS-Dach; deckt OT-Spezifika nicht vollständig ab.
• NIST SP 800-82 und NIST CSF: komplementäre OT-Leitlinien (Public Domain).