IEC 62443 im Zusammenspiel mit ISO 27001, IT-Grundschutz und NIS2

Problem in der Praxis

Viele Unternehmen haben ein zertifiziertes IT-ISMS und gehen davon aus, die Produktion sei damit abgedeckt. Im Audit fällt dann auf, dass die OT entweder ganz aus dem Scope ausgeklammert oder mit IT-Maßnahmen behandelt wurde, die im Produktionsumfeld nicht tragen. Ein monatliches Patchfenster, automatische Reboots oder zentrale Endpoint-Agenten lassen sich auf eine seit Jahren laufende Steuerung nicht ohne Weiteres anwenden.

Gleichzeitig wird IEC 62443 oft als reines Hersteller- oder Integratorthema missverstanden. Der Betreiber delegiert die Norm an Lieferanten und übersieht, dass die Serie ein eigenes Betreiber-Sicherheitsprogramm vorsieht, das an ein ISMS anschlussfähig ist. Das Ergebnis sind zwei getrennte Welten, die spätestens bei NIS2-Sektorpflichten oder Kundennachweisen sichtbar werden.

CISO-Einordnung

Der Denkfehler ist die Annahme, man müsse sich zwischen den Frameworks entscheiden. Tatsächlich beantworten sie unterschiedliche Fragen:

• ISO 27001 und IT-Grundschutz: Wie steuern wir Informationssicherheit organisatorisch und nachweisbar?
• IEC 62443: Wie sichern wir Automatisierungs- und Steuerungssysteme technisch und prozessual ab, ohne Verfügbarkeit und Safety zu gefährden?
• NIS2: Welche Sektoren müssen Risikomanagement betreiben, und worüber muss berichtet werden?

IEC 62443 wird seit 2021 von der IEC als horizontale, also branchenübergreifend anwendbare Norm geführt. Sie ist in vier Schichten gegliedert: General, Policies and Procedures, System und Component. Das erklärt auch das Rollenmodell, das für die Pflichtenzuordnung maßgeblich ist: Asset Owner als Betreiber, System Integrator beziehungsweise Service Provider und Product Supplier als Hersteller. Wer welche Anforderungen trägt, hängt von der Rolle ab, nicht vom Framework.

Konzeptionell sind drei Bausteine relevant: Zones and Conduits (Aufteilung in Sicherheitszonen mit definierten Kommunikationskanälen, Grundlage für Risikobewertung und Defense-in-Depth), die Security Levels SL1 bis SL4 (gestufte Schutzziele nach Angreiferfähigkeit, vom fahrlässigen Fehlverhalten bis zum Angreifer mit erheblichen Ressourcen) und das Betreiber-Sicherheitsprogramm als organisatorischer Teil, der direkt an ein ISMS andockt.

Umsetzungsperspektive

Aus CISO-Sicht ist die saubere Reihenfolge wichtiger als die Wahl des Frameworks. Zuerst entsteht das Managementdach: Ein bestehendes ISO-27001- oder IT-Grundschutz-ISMS wird so erweitert, dass OT explizit in Scope, Risikologik und Verantwortlichkeiten auftaucht und damit kein Sonderfall neben dem ISMS ist, sondern eine Anwendung darauf.

Darunter wird die OT-Tiefe aufgebaut: Betreiber-Sicherheitsprogramm für die Prozesse, Zonen und Conduits für die technische Grundordnung, Security Levels für die Übersetzung von Risikoaussagen in Schutzanforderungen je Zone. So lassen sich Risikoentscheidungen aus dem ISMS bis auf Zonen- und Komponentenebene durchreichen.

Das BSI ICS-Security-Kompendium dient als Brücke. Es liegt in Version 2.0.0 vom 23.04.2024 vor, ist frei zugänglich und zitierbar und hat den Blick von ICS auf den weiteren Begriff Operational Technology erweitert; bisher getrennte Dokumente für Betreiber sowie für Hersteller und Integratoren wurden zusammengeführt. Es verbindet OT-Praxis und IT-Grundschutz-Logik, ohne kostenpflichtige Normtexte zu reproduzieren.

Auf der Regulierungsseite gibt NIS2 das Was und Wozu vor: Risikomanagement-Pflichten für Industrie- und KRITIS-Sektoren wie verarbeitendes Gewerbe, Chemie, Energie, Wasser und Abwasser sowie Verkehr. IEC 62443 und das ICS-Kompendium liefern das Wie für die OT. Die deutsche Umsetzung erfolgt über das NIS2-Umsetzungsgesetz mit Änderungen im BSIG; konkrete Paragrafenverweise und Behördenzuordnungen sind vor verbindlicher Nutzung gegen den aktuellen Gesetzesstand zu prüfen.

Typische Fehler

1. OT wird aus dem ISMS-Scope ausgeklammert, statt als eigene Anwendung mit eigenen Risiken aufgenommen zu werden.
2. IT-Maßnahmen werden unverändert auf die Produktion übertragen und ignorieren Verfügbarkeits- und Safety-Primat.
3. IEC 62443 wird vollständig an Lieferanten delegiert, obwohl die Betreiberrolle ein eigenes Sicherheitsprogramm vorsieht.
4. Security Levels werden als Produktlabel verstanden statt als Ergebnis einer Risikobewertung je Zone.
5. NIS2-Sektorpflichten werden erst nach einem Vorfall geprüft, nicht im Rahmen der regulären Risikosteuerung.

Risiken und Trade-offs

Der zentrale Trade-off liegt zwischen Vereinheitlichung und OT-Realität. Ein zu stark IT-getriebenes Vorgehen erzeugt formale Konformität, aber Maßnahmen, die in der Anlage nicht gelebt werden; ein rein OT-getriebenes Vorgehen erzeugt technische Tiefe ohne Managementsteuerung und Nachweisbarkeit.

Zweitens erhöhen hohe Security Levels in jeder Zone Aufwand und können mit Verfügbarkeit und Wartbarkeit kollidieren; die SL-Zuweisung ist eine Risiko- und Kostenentscheidung, keine technische Maximierung. Drittens droht Scheinabdeckung, wenn mehrere Frameworks nebeneinander Dokumentation erzeugen, aber Risiken, Zonen, SL und Managemententscheidungen nicht verknüpft sind.

Entscheidungspunkte

• Wird OT in das bestehende ISMS integriert oder zunächst als eigenes OT-Sicherheitsprogramm aufgebaut und später angedockt?
• Welche NIS2-Relevanz hat das Unternehmen je Sektor, und welche Pflichten folgen konkret daraus?
• Welches Leitwerk führt: ISO 27001, IT-Grundschutz oder ein gemeinsames Dach, ergänzt um IEC 62443 für die OT-Tiefe?
• Welche Zonen brauchen welches Target-Security-Level, gemessen an Risiko statt an technischer Machbarkeit?
• Wie werden Hersteller- und Integratorpflichten vertraglich an die 62443-Rollen gebunden?

Praktische Empfehlungen

1. Verankern Sie OT explizit im ISMS-Scope und behandeln Sie sie als Anwendung auf dem bestehenden Managementdach, nicht als Parallelwelt.
2. Nutzen Sie das BSI ICS-Security-Kompendium als gemeinsame Sprach- und Brücken-Grundlage zwischen IT-Grundschutz und OT-Praxis.
3. Leiten Sie Security Levels aus einer Risikobewertung je Zone ab und dokumentieren Sie die Begründung, nicht nur das Ergebnis.
4. Binden Sie die 62443-Rollen vertraglich ein, damit Betreiber-, Integrator- und Herstellerpflichten klar zugeordnet sind.
5. Prüfen Sie NIS2-Betroffenheit und die deutsche Umsetzung anhand des aktuellen Gesetzesstands, bevor Sie Pflichten als gesetzt annehmen.

Relevante Normreferenzen

• IEC/ISA 62443-Serie: Referenz für OT/ICS-Security; kostenpflichtig, daher nur Struktur und Konzept, keine Volltexte oder Anforderungslisten. Editionen je Teil unterschiedlich (u. a. 62443-2-1 Ed. 2.0 von 2024, 62443-3-3 Ed. 1.0 von 2013, 62443-4-1 von 2018, 62443-4-2 von 2019); Versionsstand je Teil prüfen.
• ISO/IEC 27001: Referenz für das ISMS-Managementdach.
• BSI IT-Grundschutz: Referenz für den deutschen ISMS-Ansatz mit OT-Bezug.
• BSI ICS-Security-Kompendium V2.0.0 (23.04.2024): frei zugänglich, Brücke zwischen IT-Grundschutz und OT.
• NIST SP 800-82 und NIST CSF: komplementäre OT-Leitlinien als Bezug.
• NIS2-Richtlinie mit deutscher Umsetzung: regulatorischer Rahmen; konkrete Paragrafen und Behörden vor Nutzung prüfen.