IEC 62443 verständlich erklärt: Der Praxisleitfaden für mehr OT-Sicherheit

Wer heute eine Maschine mit dem Internet verbindet, hat ein Problem geschaffen, das kein Firewall-Regelwerk allein löst. Ich saß letztes Jahr mit einem Instandhalter vor einer Abfüllanlage, die für Fernwartung freigeschaltet war. Sein Kommentar: „Das hat die Steuerungsfirma eingerichtet, ich weiß nicht, wie das läuft." Genau in diesem Satz steckt der Grund, warum die IEC 62443 existiert. Sie ist keine Technikvorschrift für Firewalls, sondern eine Arbeitsteilung. Nirgends steht geschrieben, dass der Hersteller der Anlage für die Sicherheit im Netz des Betreibers verantwortlich ist. Genau diese Lücke hat die Norm geschlossen.

IEC 62443 einfach erklärt: kein Regelwerk, eine Aufteilung

Die Kernidee lässt sich in einem Satz zusammenfassen: Sicherheit entsteht nicht am Werkszaun, sondern in der Lieferkette. Wenn ein Gerät ab Werk unsicher gebaut ist, kann der Betreiber noch so viele Netzsegmente ziehen. Wenn der Betreiber sein Netz offenlässt, nützt das sicherste Gerät nichts. Die Norm beschreibt deshalb Anforderungen getrennt für jeden, der in diesem Kreislauf eine Rolle spielt.

Woher sie kommt

Die Wurzeln liegen bei der ISA in den USA, in der Reihe ISA-99. Daraus wurde 2010 die erste IEC-Fassung, und seitdem wird die Familie ergänzt und überarbeitet. Das erklärt eine Eigenheit, die viele irritiert: Manche Teile tragen den Status einer Norm, andere den eines technischen Reports. Ein vollständiges, abgestimmtes Werk mit durchgehendem Reifegrad ist sie bis heute nicht.

Drei Rollen, die nicht mehr miteinander reden müssen

Das Modell unterscheidet:

1. Asset Owner (Betreiber) — die Anlage, das Netz, die Verantwortung für den Betrieb.
2. Integrator — wer Systeme baut, zusammenschaltet, in Betrieb nimmt.
3. Product Supplier (Hersteller) — wer Geräte, Steuerungen, Software liefert.

Jeder findet in der Norm die Teile, die ihn betreffen. Der Betreiber liest 2-1 und 2-4, der Integrator 3-2 und 3-3, der Hersteller 4-1 und 4-2. Genau diese Sortierung ist der praktische Wert: Niemand muss den gesamten Ordner lesen.

Der Aufbau der Normenfamilie im Überblick

Vier Blöcke, durchnummeriert von 1 bis 4. Ich habe hier lange gebraucht, bis ich das System verstanden habe — es erschließt sich nicht von selbst, weil die Nummerierung nach Zielgruppe sortiert ist, nicht nach technischer Logik.

Block	Inhalt	Zielgruppe
62443-1-x	Allgemeine Konzepte, Begriffe, Terminologie, Metriken	alle
62443-2-x	Anforderungen an ein Sicherheitsmanagementsystem beim Betreiber (2-1), Patch-Management (2-3), Anforderungen an Dienstleister (2-4)	Betreiber
62443-3-x	Risikobewertung und Systemarchitektur (3-2), Systemanforderungen mit Security Level (3-3)	Integrator, Betreiber
62443-4-x	Sicherer Produktentwicklungsprozess (4-1), technische Produktanforderungen (4-2)	Hersteller

Wer nach einem IEC 62443 PDF oder einem deutschen Download sucht: Die offiziellen Dokumente sind kostenpflichtig, über DIN, VDE oder die IEC selbst zu beziehen. Manche Teile sind als VDE-Schriftenreihe auf Deutsch erschienen. Die englische Fassung ist übrigens die Referenz — Übersetzungen hinken hinterher, und in der Praxis liest fast jeder, den ich kenne, die englische Originalfassung. Nicht schön, aber Realität.

Zonen, Conduits und Security Level: der eigentliche Kern

Hier passiert das, was in den meisten Einführungen fehlt. Zwei Konzepte, die zusammengehören und ohne die der Rest der Norm leer bleibt.

Zonen und Conduits

Eine Zone ist ein Bereich mit gleichem Schutzbedarf. Alle Geräte darin dürfen sich gegenseitig vertrauen. Ein Conduit ist der Übergang zwischen zwei Zonen — die Verbindung, die kontrolliert werden muss. Das klingt banal, ist aber der Punkt, an dem in der Praxis die meisten Anlagen durchfallen: Es gibt Zonen, aber der Weg dazwischen ist ein offener Port, den niemand dokumentiert hat.

Ich habe vor zwei Jahren eine Anlage gesehen, in der die Fernwartung über einen Router lief, der seit Inbetriebnahme nie angefasst worden war. Kein Passwortwechsel, keine Protokollierung, kein Zeitstempel. Nach der Norm wäre das ein Conduit ohne definierte Eigenschaften — und damit ein Befund.

Security Level: SL 1 bis 4

Die Norm kennt vier Stufen, und das Entscheidende ist die Unterscheidung zwischen zwei Blickwinkeln:

• SL-T (Target) — was ein System leisten soll, abgeleitet aus der Risikobewertung.
• SL-A (Achieved) — was das System tatsächlich erreicht.
• SL-C (Capability) — was ein einzelnes Produkt technisch könnte.

SL 1 bedeutet Schutz gegen beiläufige Verstöße, SL 4 gegen gezielte Angriffe mit erheblichen Ressourcen. Zwischen SL-T und SL-A klafft in echten Anlagen oft eine Lücke — und genau diese Lücke ist der Grund, warum ich die Norm für nützlich halte. Sie zwingt zu einer ehrlichen Bestandsaufnahme statt zu einem Häkchen-Set.

IEC 62443-4-1 und 4-2: der Hersteller im Fokus

Wer ein Produkt für die Automatisierung baut, kommt an diesen beiden Teilen nicht vorbei.

Was 62443-4-1 konkret verlangt

Die IEC 62443-4-1 beschreibt einen sicheren Produktentwicklungsprozess, kurz SDL. Im Kern acht Praktiken, die über den gesamten Lebenszyklus greifen: Bedrohungsmodellierung, sichere Designvorgaben, Codierungsrichtlinien, Testverfahren, Schwachstellenmanagement, Update-Mechanismen, Dokumentation und die Reaktion auf gemeldete Lücken. Das ist kein Zertifikat, das man einmal erwirbt. Es ist ein Prozess, der bei jedem Release neu belegt werden muss.

Was viele unterschätzen: Der Hersteller muss nachweisen, dass er Sicherheitslücken aktiv annimmt und behebt. Ein Produkt, das seit fünf Jahren kein Update mehr gesehen hat, erfüllt diese Anforderung im Zweifel nicht — auch wenn es technisch einwandfrei läuft.

IEC 62443-4-2: was das Gerät können muss

Die IEC 62443-4-2 ist die andere Seite: technische Anforderungen an das Gerät selbst. Identifikation und Authentifizierung, Rollenkonzept, Verschlüsselung, Protokollierung, Ressourcenverfügbarkeit. Jede Anforderung ist einem Security Level zugeordnet — SL 1 bis 4, gestaffelt nach Aufwand und Angreifermodell. Ein Sensor mit SL 1 braucht weniger als eine Steuerung mit SL 3.

Ehrlich gesagt: In meinem ersten Jahr mit der Norm habe ich den Unterschied zwischen 4-1 und 4-2 nicht verstanden und beide in einen Topf geworfen. Erst als ein Lieferant erklärte, er habe den Prozess, aber nicht die Produktanforderungen, wurde es klar. Zwei verschiedene Nachweise.

Was das für den Betrieb bedeutet — und warum NIS2 die Sache beschleunigt

Die IEC 62443 ersetzt keine gesetzliche Pflicht. Sie liefert aber das Vokabular, mit dem man eine Pflicht erfüllen kann. Wer als Betreiber kritischer Infrastruktur unter NIS2 fällt, muss Risikomanagement nachweisen — und die IEC 62443 ist der anerkannte Weg, das für industrielle Steuerungssysteme zu tun. In der Praxis sehe ich bei Kunden drei wiederkehrende Muster:

• Der Betreiber hat ein Sicherheitsmanagementsystem nach ISO 27001, aber die Anlage darin ist ein blinder Fleck.
• Der Hersteller liefert ein Produkt mit SL-2-Fähigkeit, aber niemand dokumentiert, welches SL im Betrieb erreicht wird.
• Die Fernwartung ist der einzige Kanal von außen und gleichzeitig der am schlechtesten kontrollierte.

Der dritte Punkt ist der häufigste. Und der unangenehmste, weil er meistens von der Instandhaltung eingerichtet wurde, nicht von der IT.

Kosten, Aufwand und die unangenehme Wahrheit über Zertifikate

Was kostet das? Ich kann keine belastbaren Zahlen nennen, weil die Spanne absurd groß ist — zwischen einem Audit für einen einzelnen Netzwerkkomponenten-Hersteller und einer Zertifizierung über ein komplettes Werk liegen Welten. Was ich sagen kann: Der Aufwand steckt nicht im Audit, sondern in der Vorbereitung. Die Lücke zwischen „wir haben eine Firewall" und „wir haben eine dokumentierte Zonenarchitektur" ist bei den meisten Betrieben größer als erwartet, und sie kostet Monate, nicht Wochen.

Ein häufiger Irrtum: Man könne „IEC 62443 zertifiziert" werden. Das geht nicht. Zertifiziert werden Prozesse (etwa der Entwicklungsprozess nach 4-1), Produkte (nach 4-2) oder ein Managementsystem (nach 2-1). Die Norm selbst ist ein Rahmen, kein Prüfsiegel.

Häufige Fragen zur Norm

Sollte man die englische oder die deutsche Fassung lesen?

Die englische. Die deutschen Übersetzungen sind teils vorhanden, aber die Referenz ist der englische Originaltext — und in internationalen Projekten wird ohnehin englisch gearbeitet. Wer nur eine Fassung kauft, sollte zur englischen greifen.

Ersetzt die IEC 62443 die ISO 27001?

Nein. Die beiden ergänzen sich. Die ISO 27001 beschreibt ein allgemeines Managementsystem für Informationssicherheit, die IEC 62443 die spezifischen Anforderungen für industrielle Steuerungssysteme. Wer beides braucht, kann auf das Mapping zurückgreifen, das zeigt, welche Anforderungen sich entsprechen — aber die Anlagenebene deckt die ISO 27001 nicht ab.

Wo bekommt man die Dokumente?

Über die offiziellen Normungsstellen, also DIN, VDE oder direkt bei der IEC. Kostenlos ist nur der Einstieg über die Übersichtsdarstellungen und die Begriffsklärung. Für die eigentliche Arbeit braucht man die kostenpflichtigen Texte.

Was von der Norm bleibt

Die IEC 62443 ist kein Regelwerk, das man abarbeitet und dann abhakt. Sie ist ein Vokabular, mit dem Betreiber, Integrator und Hersteller anfangen können, über dieselbe Sache zu sprechen. Der Satz des Instandhalters — „das hat die Steuerungsfirma eingerichtet, ich weiß nicht, wie das läuft" — ist genau das Problem, das die Norm adressiert. Nicht mit einer technischen Vorschrift, sondern mit der Frage: Wer ist für welchen Teil verantwortlich, und wo ist das dokumentiert?

Eine Frage, die ich mir seit dem Gespräch vor der Abfüllanlage stelle und die mich nicht loslässt: Wie viele Anlagen laufen in deutschen Werken, bei denen niemand den Router kennt, der die Fernwartung ermöglicht? Ich vermute, es sind mehr, als jeder Betreiber zugeben würde.