Sie haben den Begriff sicher schon gehört, vielleicht im Zusammenhang mit KRITIS, NIS2 oder einer Kundenanforderung. IEC 62443 gilt inzwischen als die zentrale Norm für die Absicherung industrieller Automatisierungssysteme. Aber ehrlich gesagt: Die Norm ist ein Dickicht aus Teilen, Zonen, Conduits und Security Levels. Und genau da scheitern viele – nicht am fehlenden Willen, sondern an der Struktur.
Ich habe in den letzten Jahren mehrere Projekte zur Umsetzung von IEC 62443 begleitet und bin dabei selbst in die typischen Fallen getappt. In diesem Artikel zeige ich Ihnen die praktische Landkarte der Norm – mit den konkreten Stolperfallen, die ich erlebt habe und die Sie vermeiden können.
Wichtige Erkenntnisse
- IEC 62443 ist keine einzelne Norm, sondern ein Rahmenwerk aus vier Teilen mit unterschiedlichen Zielgruppen.
- Zonen und Conduits sind kein theoretisches Konzept – sie entscheiden über die Wirksamkeit Ihrer Segmentierung.
- Security Levels (SL) definieren Anforderungen, aber die Diskussion um SL-A und SL-C ist ein häufiger Fehler bei der Umsetzung.
- Die Rollenverteilung (Betreiber, Integrator, Hersteller) bestimmt, welche Teile der Norm für Sie verbindlich sind – und welche nicht.
- Der Unterschied zwischen der Zertifizierung eines Produkts und der eines Prozesses wird oft missverstanden – mit weitreichenden Folgen für die Lieferkette.
IEC 62443 verstehen: Die Struktur ist der Schlüssel
Die Norm ist in vier Hauptteile gegliedert, die sich an unterschiedliche Akteure richten. Der erste Teil (IEC 62443-1-1) enthält die Terminologie und die Konzepte. Teil 2 (IEC 62443-2-x) adressiert den Betreiber und das Security Management System. Teil 3 (IEC 62443-3-x) betrifft die Systemintegratoren – hier finden Sie die Anforderungen an die Systemarchitektur. Und Teil 4 (IEC 62443-4-x) richtet sich an die Hersteller von Komponenten.
Viele machen den Fehler, sofort mit Teil 4-2 zu beginnen, weil sie ein Produkt zertifizieren möchten. Doch ohne die vorherige Analyse aus Teil 3 fehlt die Grundlage. Die Norm verlangt einen Top-down-Ansatz: Zuerst bestimme ich die Risiken und Zonen, dann die technischen Anforderungen.
Die vier Teile im Überblick
| Teil | Zielgruppe | Inhalt |
|---|---|---|
| 1-1 bis 1-5 | Alle | Begriffe, Konzepte, Metriken |
| 2-1 bis 2-5 | Betreiber | Security Management, Patches, Kennzahlen |
| 3-1 bis 3-3 | Integratoren | Risikobewertung, Zonen, Conduits, SL-Anforderungen |
| 4-1, 4-2 | Hersteller | Entwicklungsprozess (secure by design), Produktanforderungen |
Was bedeutet das für Sie konkret? Wenn Sie als Maschinenbauer Komponenten liefern, ist Teil 4 relevant. Wenn Sie Anlagen betreiben, fokussieren Sie auf Teil 2 und 3. Alles gleichzeitig in Angriff zu nehmen, überfordert – und genau das habe ich in einem meiner Projekte beobachtet, als ein Team versuchte, sämtliche Teile parallel umzusetzen. Das Ergebnis war ein Dokumentationsstau nach sechs Monaten.
Zonen und Conduits: Wo die Umsetzung gelingt oder scheitert
Der Kern des systemischen Ansatzes von IEC 62443 ist die Segmentierung in Zonen und Conduits. Eine Zone ist eine Gruppe von Anlagen oder Komponenten mit gleichen Sicherheitsanforderungen. Ein Conduit ist die Kommunikationsverbindung zwischen zwei Zonen – und genau dort werden die Firewalls und die Zugriffskontrollen umgesetzt.
Der häufigste Anfängerfehler? Zonen nach rein räumlichen Kriterien zu bilden – etwa „Halle A" und „Halle B". Das ist bequem, aber fachlich falsch. Zwei Maschinen in derselben Halle können völlig unterschiedliche Risikoprofile haben, wenn die eine mit dem Internet verbunden ist und die andere nicht. Die Zonenbildung folgt also dem Risiko, nicht der Geografie.
Und dann ist da noch die Frage der Tiefe. Eine Zone kann weitere Unterzonen enthalten. Das klingt theoretisch, hat aber praktische Konsequenzen: Jede verschachtelte Zone erfordert eigene Zugriffskontrollen und erhöht die Komplexität des Berechtigungsmanagements. In einem Projekt haben wir es mit vier verschachtelten Ebenen übertrieben – das Ergebnis war eine Wartungshölle, weil jede Änderung an der Berechtigungsstruktur durch vier Ebenen propagiert werden musste.
Security Levels verstehen und richtig anwenden
Die Norm definiert Security Levels von SL-1 bis SL-4, die ansteigende Anforderungen an die Widerstandsfähigkeit gegen Angriffe stellen. SL-1 schützt vor unbeabsichtigten Handlungen, SL-4 vor hochqualifizierten Angreifern mit gezielten Ressourcen. Soweit klar – aber die Praxis zeigt zwei häufige Missverständnisse.
Erstens: Die Verwechslung von SL-A (Achieved) und SL-C (Capability). SL-C beschreibt die Fähigkeit eines Produkts, bestimmte Sicherheitsfunktionen bereitzustellen. SL-A beschreibt, was in einer konkreten Installation tatsächlich erreicht wird. Ein Produkt kann SL-C-3 zertifiziert sein, aber in Ihrer Anlage nur SL-A-1 erreichen, weil die Konfiguration mangelhaft ist. Diese Unterscheidung ist nicht akademisch – sie entscheidet über die Wirksamkeit Ihres Sicherheitskonzepts.
Zweitens: Die Annahme, dass ein hohes SL automatisch bessere Sicherheit bedeutet. Das Gegenteil kann der Fall sein. Je höher das Level, desto komplexer die Anforderungen – und desto größer die Gefahr von Fehlkonfigurationen. Ein Ziel-SL-3, das schlecht implementiert ist, kann unsicherer sein als ein sauber umgesetztes SL-2. Diese Erkenntnis habe ich nach einer langen Nacht verdankt, in der wir ein Segment mit SL-4-Anforderungen geplant hatten und schließlich feststellten, dass die zusätzlichen Kontrollen den Betrieb so stark einschränkten, dass eine pragmatische Lösung bei SL-2 mit konsequenter Überwachung die bessere Wahl war.
Rollen und Verantwortlichkeiten: Wer macht was?
Ein weiterer Stolperstein ist die unklare Rollenverteilung. Die Norm unterscheidet drei Hauptakteure: den Asset Owner (Betreiber), den Integrator und den Komponentenhersteller. Diese Rollen sind nicht nur organisatorisch, sie bestimmen die Pflichten.
Der Betreiber ist für die Risikobewertung und die Definition der Zonen verantwortlich. Der Integrator setzt die Anforderungen aus Teil 3 um – er plant die Architektur und die Conduits. Der Hersteller entwickelt Produkte nach Teil 4-1 (Prozess) und 4-2 (Produktanforderungen). Wenn Sie in Ihrer Organisation mehrere Rollen einnehmen – etwa als Maschinenbauer, der auch die Wartung übernimmt – müssen Sie die Anforderungen aus beiden Perspektiven erfüllen.
Ich habe ein Projekt erlebt, in dem ein Hersteller die Verantwortung für die Zonenbildung übernahm, weil er die Anlage lieferte. Das führte zu Konflikten mit dem Betreiber, der für das Gesamtsystem verantwortlich war. Die Lösung war ein gemeinsamer Workshop, um die Grenzen der Verantwortlichkeiten festzulegen – im Nachhinein hätten wir damit am Anfang beginnen sollen.
Zertifizierung ist nicht gleich Zertifizierung
Die Norm kennt zwei unterschiedliche Zertifizierungsarten. Bei der Prozess-Zertifizierung nach Teil 4-1 wird der Entwicklungsprozess eines Herstellers geprüft – also die Frage, ob Security-Anforderungen im gesamten Lebenszyklus der Produktentwicklung berücksichtigt werden. Bei der Produkt-Zertifizierung nach Teil 4-2 wird ein konkretes Gerät auf die Erfüllung bestimmter Anforderungen geprüft.
Die Verwechslung dieser beiden führt regelmäßig zu Missverständnissen in der Beschaffung. Ein Kunde von mir verlangte von seinen Lieferanten eine „Zertifizierung nach IEC 62443", ohne zu spezifizieren, welche der beiden gemeint war. Die Folge war ein erheblicher Mehraufwand bei der Sichtung unvollständiger Nachweise. Meine Empfehlung: Präzisieren Sie in Ihren Ausschreibungen immer, ob Sie eine Prozess- oder Produktzertifizierung verlangen – sonst verlieren Sie viel Zeit.
Typische Fehler und Fallen bei der Umsetzung
Nach all den Projekten habe ich einige wiederkehrende Muster identifiziert, die ich hier – in der Hoffnung, dass Sie sie vermeiden – teile. Der erste Fehler ist die Konzentration auf Teil 4-2 ohne die Analyse aus Teil 3. Sie kaufen Produkte mit hohen SL-C-Zertifizierungen, aber Ihre Systemarchitektur ist nicht darauf ausgelegt – die Sicherheit bleibt eine Fassade.
Der zweite Fehler ist die Vernachlässigung von Conduits. Ich habe Anlagen gesehen, in denen perfekte Zonen definiert waren, aber die Kommunikationswege zwischen den Zonen nicht dokumentiert geschweige denn abgesichert waren. Die Zone ist nur so gut wie ihr schwächstes Conduit – das ist eine Lehre, die ich teuer bezahlt habe, als ein externer Test genau diese Lücke aufdeckte.
Und schließlich: die Unterschätzung des Dokumentationsaufwands. Die Norm verlangt eine umfangreiche Dokumentation – von der Risikobewertung über die Zonenpläne bis zu den Sicherheitsnachweisen. In einem mittelständischen Unternehmen haben wir festgestellt, dass fast 30 Prozent der Projektzeit für die Erstellung und Pflege dieser Dokumentation aufgewendet werden musste. Wer das nicht einplant, gerät unter Druck und beginnt, an den falschen Stellen zu sparen.
Konkrete nächste Schritte
Wenn Sie mit IEC 62443 beginnen möchten, dann tun Sie es in dieser Reihenfolge. Zuerst definieren Sie Ihre Rolle(n) und die daraus resultierenden Pflichten. Dann führen Sie eine Risikobewertung Ihrer bestehenden Anlagen durch – ohne den Anspruch, sofort alle Teile umzusetzen. Und schließlich planen Sie die Zonen und Conduits, bevor Sie über Produktzertifizierungen nachdenken.
Ein letzter Gedanke, der mir wichtig ist: Die Norm ist kein Selbstzweck. Es geht nicht darum, ein Zertifikat an die Wand zu hängen – es geht darum, Anlagen zu betreiben, die einen Angriff überstehen, ohne dass die Produktion lahmgelegt wird. Und in diesem Sinne ist die Norm auch ein Werkzeug, um das Gespräch mit dem Management und den Fachabteilungen zu strukturieren.
Was mich nach all den Jahren am meisten überzeugt hat: IEC 62443 ist grundsätzlich praxistauglich – wenn man bereit ist, die anfängliche Komplexität zu akzeptieren. Die Frage ist also nicht, ob Sie sich damit beschäftigen sollten. Die Frage ist, ob Sie bereit sind, bei sich selbst anzufangen – oder ob Sie warten, bis ein Kunde oder eine Prüfung Sie dazu zwingt.