Industrielle Steuerungssysteme wurden nie mit Blick auf Cyber-Risiken entwickelt. Sie wurden für maximale Verfügbarkeit, Sicherheit und Präzision gebaut und sollten oft fünfzehn oder zwanzig Jahre lang unangetastet laufen. Genau diese Konstruktionsphilosophie ist der Grund für die Existenz der IEC 62443. Sie ist das, was einer gemeinsamen Sprache für OT-Sicherheit in der industriellen Welt am nächsten kommt. Sie bietet Anlagenbetreibern, Systemintegratoren und Geräteherstellern einen gemeinsamen Satz von Anforderungen, anstatt dass jede Anlage ihren eigenen Ansatz zum Schutz der Systeme neu erfindet, die Produktion, Energie und Wasser am Laufen halten.

Bevor wir beginnen, vergessen Sie nicht, unseren vorherigen Beitrag über „Eine technische Analyse des fairlife-Cyber-Vorfalls“ hier zu lesen.

Für OT-Sicherheitsverantwortliche, Werksleiter und CISOs, die für kritische Infrastrukturen (KRITIS) verantwortlich sind, ist die Einhaltung der IEC 62443 keine theoretische Übung mehr, die den am stärksten regulierten Sektoren vorbehalten ist. Versicherer fragen bei der Vertragsverlängerung danach. Kunden fragen im Rahmen von Lieferantenbewertungen danach. Regulierungsbehörden beziehen sich darauf, wenn sie branchenspezifische Regeln gestalten. Und immer häufiger fragen Vorstände danach, weil sie miterlebt haben, wie vergleichbare Unternehmen wochenlange Produktionsausfälle durch Vorfälle erlitten haben, die eine segmentierte, gut geführte Umgebung hätte eindämmen können. Dieser Leitfaden schlüsselt auf, was der Standard tatsächlich verlangt, warum diese Anforderungen existieren und wie man sie in ein tragfähiges Programm statt in einen Stapel Papierkram verwandelt.

Was ist die IEC 62443 und warum existiert sie?

Die IEC 62443 ist eine Reihe internationaler Normen, die sich speziell auf die Absicherung von industriellen Automatisierungs- und Steuerungssystemen (IACS) konzentrieren – die speicherprogrammierbaren Steuerungen (PLC), Prozessleitsysteme, SCADA-Plattformen, Human-Machine-Interfaces (HMI) und Sicherheitssysteme, die Produktionsanlagen, Stromnetze, Wasserversorger und andere kritische Infrastrukturen betreiben. Im Gegensatz zu allgemeinen IT-Sicherheits-Frameworks, die jedes Asset als im Wesentlichen austauschbar behandeln, wurde die IEC 62443 mit Blick auf die spezifischen Realitäten der Operational Technology (OT) verfasst: lange Lebenszyklen von Geräten, Priorität auf Funktionale Sicherheit (Safety),

Echtzeit-Verfügbarkeitsanforderungen und ein Mix aus modernen und jahrzehntealten Geräten, die im selben Netzwerk koexistieren.

Die Norm ist insofern ungewöhnlich, als sie sich nicht nur an eine Zielgruppe richtet. Sie legt Anforderungen für Anlagenbetreiber fest, die die Anlage betreiben, für Systemintegratoren, die das Steuerungssystem entwerfen und implementieren, und für Produkthersteller, die die zugrunde liegenden Komponenten produzieren. Diese dreiseitige Struktur ist bewusst gewählt: Industrielle Sicherheitsausfälle lassen sich selten auf ein einziges schwaches Glied zurückführen. Sie lassen sich meist auf eine Lücke in der Aufteilung der Verantwortung zwischen den Personen zurückführen, die das System gebaut haben, den Personen, die es integriert haben, und den Personen, die es nun täglich betreiben.

Es hilft auch zu verstehen, was die IEC 62443 nicht ist. Sie ist kein Produkt, das man kauft, kein einzelnes Zertifikat, das man an die Wand hängt, und kein einmaliges Projekt mit einem definierten Enddatum. Sie ist ein Lebenszyklus-Standard, was bedeutet, dass Sicherheit von der frühesten Engineering-Phase an eingeplant, über Jahre des Betriebs hinweg aufrechterhalten und bei jeder Änderung der Umgebung – einer neuen Lieferantenverbindung, einem neuen Fernzugriffsweg, einem Upgrade des Steuerungssystems – neu bewertet werden muss. Organisationen, die dies als zeitlich begrenztes Projekt betrachten, bestehen meist ihr erstes Audit und driften dann innerhalb von achtzehn bis vierundzwanzig Monaten stillschweigend aus der Compliance, schlicht weil keine Strukturen zur Aufrechterhaltung des Programms geschaffen wurden.

Diese Lebenszyklus-Orientierung ist auch der Grund, warum die IEC 62443 zunehmend zum Referenzpunkt wird, auf den Versicherer, Regulierungsbehörden und große Industriekunden verweisen, selbst in Sektoren, in denen kein Gesetz dies explizit vorschreibt. Wenn ein Framework auf kontinuierlichem Risikomanagement statt auf einer statischen Checkliste aufbaut, hält es einer echten Audit-Prüfung besser stand – und es führt zu einem Sicherheitsniveau, das die tägliche Betriebspraxis der Anlage tatsächlich widerspiegelt.

Die Struktur der IEC 62443 verstehen

Die vier Teile der Norm

Die IEC 62443 ist in vier Dokumentengruppen unterteilt, die jeweils eine andere Verantwortungsebene adressieren. Anstatt sich wie eine einzige, dichte Spezifikation zu lesen, funktioniert sie eher wie ein Satz von Bausteinen – allgemeine Konzepte an der Spitze, zunehmend spezifische technische Anforderungen, je weiter man nach unten geht.

Abbildung 1: Die vier Teile der IEC 62443, vom gemeinsamen Vokabular bis zu Anforderungen auf Produktebene.

Zentrale Compliance-Anforderungen der IEC 62443, die Unternehmen erfüllen müssen

Sobald man die Terminologie verstanden hat, läuft die Compliance nach IEC 62443 auf einige wenige, ineinandergreifende Anforderungen hinaus. Wenn Sie diese richtig umsetzen, ergibt sich der Rest des Programms – Richtlinien, Dokumentation, Audit-Nachweise – meist von selbst. Machen Sie hier Fehler, wird auch der größte Stapel an Papierkram einer Prüfung nicht standhalten.

Security Levels (SL 0–4): Schutz an Bedrohungen anpassen

Die IEC 62443 geht nicht davon aus, dass jedes Asset das gleiche Schutzniveau benötigt. Stattdessen definiert sie fünf Security Levels, die von SL 0 (kein spezifischer Schutz erforderlich) bis SL 4 (Schutz gegen einen hochmotivierten Angreifer mit umfangreichen Ressourcen und hochentwickelten Mitteln) reichen. Jeder Zone in einer Anlage wird basierend auf den Auswirkungen einer Kompromittierung ein Soll-Sicherheitsniveau (Target Security Level, SL-T) zugewiesen, und das tatsächlich erreichte Niveau (Achieved Security Level, SL-A) wird an diesem Soll-Wert gemessen.

Zonen und Conduits: Das Rückgrat der technischen Compliance

Eine Zone ist eine Gruppierung von Assets, die gemeinsame Sicherheitsanforderungen teilen – beispielsweise alle Steuerungen einer einzelnen Produktionslinie oder alle Engineering-Workstations in einem Leitstand. Ein Conduit (Verbindungskanal) ist der Pfad, über den Daten zwischen den Zonen übertragen werden. Hier werden Sicherheitskontrollen wie Firewalls, Protokollfilterung und Datendioden angewendet. Dieses Modell ist wichtig, weil es ein flaches Netzwerk, in dem „jeder jedem vertraut“, durch ein bewusst segmentiertes Netzwerk ersetzt. So wird verhindert, dass eine Kompromittierung in einer Zone mit geringerem Vertrauen – wie dem Office-Netzwerk – ungehindert in eine Zone vordringt, die physische Prozesse steuert.

Abbildung 2: Ein typisches Zonen- und Conduit-Modell zur Trennung von Enterprise, DMZ, Steuerung, Safety und Feldebene.

Die korrekte Definition von Zonen ist eine der folgenreichsten Entscheidungen in einem IEC 62443-Programm. Ziehen Sie die Zonengrenzen zu weit, gefährdet ein einziges kompromittiertes Gerät die gesamte Anlage. Ziehen Sie sie, ohne die tatsächlichen Datenflüsse zu verstehen, werden die von Ihnen eingerichteten Conduits entweder den legitimen Betrieb stören oder undokumentierte Pfade weit offenlassen. Genau hier muss eine strukturierte Risikoanalyse ansetzen, anstatt nur ein Netzwerkdiagramm abzuzeichnen.

Die sieben Foundational Requirements (FRs)

Unterhalb der Security Levels angesiedelt sind die sieben Foundational Requirements (Grundlegende Anforderungen) – die technischen Kategorien, an denen die Maßnahmen jeder Zone gemessen werden. Jede spezifische Anforderung im systembezogenen Teil der Norm lässt sich auf eine dieser sieben Anforderungen zurückführen.

IEC 62443 Risikoanalyse: Das Fundament der Compliance

Fast jede Audit-Lücke, auf die die Berater von Shieldworkz stoßen, lässt sich auf dieselbe Ursache zurückführen: Die Risikoanalyse wurde als reine Dokumentationsübung behandelt und nicht als das technische Fundament, das sie sein soll. Die IEC 62443 legt explizit fest, dass Soll-Sicherheitsniveaus, Zonengrenzen und Gegenmaßnahmen aus dem Risiko abgeleitet werden müssen – und nicht erst ausgewählt und im Nachhinein gerechtfertigt werden.

Abbildung 3: Der IEC 62443-Risikoanalyse-Lebenszyklus ist kontinuierlich, kein einmaliger Compliance-Meilenstein.

Eine fundierte Risikoanalyse nach IEC 62443 durchläuft im Allgemeinen sechs Phasen, und jede einzelne liefert Nachweise, die ein Auditor sehen möchte:

• Assets identifizieren und inventarisieren: Erstellen und pflegen Sie ein vollständiges, präzises Inventar von Steuerungen, Workstations, Netzwerkgeräten und Sicherheitssystemen, einschließlich Firmware und Konfigurationsdaten.

• Schwachstellen und Bedrohungen bewerten: Evaluieren Sie bekannte Schwachstellen in der Umgebung im Vergleich zu realistischen Bedrohungsszenarien, die für die Branche und die Region relevant sind.

• Auswirkungen und Wahrscheinlichkeit bestimmen: Schätzen Sie die betrieblichen, sicherheitsrelevanten, finanziellen und reputationsbezogenen Auswirkungen einer erfolgreichen Kompromittierung für jede Asset-Gruppe ab.

• Soll-Sicherheitsniveaus (SL-T) festlegen: Weisen Sie jeder Zone basierend auf der Auswirkungsanalyse das entsprechende SL-T zu, nicht auf Basis pauschaler Branchenstandards.

• Gegenmaßnahmen entwerfen und anwenden: Wählen Sie technische und organisatorische Maßnahmen aus, die den sieben Foundational Requirements zugeordnet sind, um die Lücke zwischen SL-A und SL-T zu schließen.

• Überwachen, neu bewerten und pflegen: Überprüfen Sie die Analyse bei Änderungen von Assets, Konnektivität oder Bedrohungslagen erneut, anstatt auf das nächste geplante Audit zu warten.

Dies ist auch der Punkt, an dem Organisationen den Aufwand am häufigsten unterschätzen. Eine übergeordnete, anlagenweite Risikoanalyse setzt Prioritäten, aber die IEC 62443 verlangt eine detailliertere Analyse Zone für Zone, bevor Gegenmaßnahmen finalisiert werden. Direkt zu den technischen Maßnahmen überzugehen – wie dem Kauf einer Firewall oder einer Monitoring-Plattform, bevor diese Analyse abgeschlossen ist –, führt regelmäßig dazu, dass Budget für die falschen Prioritäten ausgegeben wird, während die Lücken mit den gravierendsten Auswirkungen offenbleiben.

Reale Vorfälle, die zeigen, warum diese Anforderungen wichtig sind

Die Anforderungen der IEC 62443 wurden nicht im luftleeren Raum verfasst. Jede einzelne lässt sich einer Kategorie von Ausfällen zuordnen, die im Industriesektor bereits realen Betriebsschaden angerichtet haben. Einige gut dokumentierte Vorfälle verdeutlichen dieses Muster sehr klar.

Ukrainisches Stromnetz, 2015 und 2016

Angreifer verschafften sich Zugang zu ukrainischen Stromverteilungsunternehmen und lernten durch lang anhaltende Aufklärung genug über die Steuerungsumgebung, um Leistungsschalter aus der Ferne zu öffnen und den Strom für Hunderttausende Kunden abzuschalten. Ein Folgeangriff im nächsten Jahr nutzte maßgeschneiderte Schadsoftware, die direkt mit den Protokollen des Stromnetzes kommunizieren konnte. Beide Vorfälle weisen auf dieselbe grundlegende Lücke hin, die FR 5 und das Zonen- und Conduit-Modell schließen sollen: unzureichende Segmentierung zwischen den Unternehmensnetzwerken und den Systemen, die in der Lage sind, die physische Infrastruktur direkt zu beeinflussen.

TRITON/TRISIS, 2017

Bei einem Vorfall in einer petrochemischen Anlage setzten Angreifer eine Schadsoftware ein, die speziell für die Neuprogrammierung von sicherheitsgerichteten Systemen (SIS) entwickelt wurde – der letzten Verteidigungslinie, die einen Prozess bei gefährlichen Bedingungen in einen sicheren Zustand bringen soll. Der Angriff war letztlich nur aufgrund eines Konfigurationsfehlers in der Schadsoftware selbst erfolglos. Er bleibt eines der deutlichsten Beispiele dafür, warum die IEC 62443 Sicherheitszonen die höchsten Soll-Sicherheitsniveaus zuweist: Die Kompromittierung eines Sicherheitssystems gefährdet nicht nur Daten oder Verfügbarkeit, sie gefährdet Menschenleben.

Norsk Hydro, 2019

Ein großer Aluminiumhersteller wurde von Ransomware getroffen, die sich von den IT-Systemen in die Betriebsumgebungen ausbreitete und mehrere Werke zwang, über einen längeren Zeitraum auf manuellen Betrieb umzustellen. Die transparente öffentliche Reaktion des Unternehmens machte dies zu einem der am besten untersuchten industriellen Ransomware-Fälle, vor allem weil er demonstrierte, wie schnell eine in der IT entstandene Kompromittierung auf die OT übergreifen kann, wenn Conduit-Maßnahmen und Netzwerksegmentierung unvollständig sind.

Oldsmar Wasseraufbereitungsanlage, 2021

Ein Operator bemerkte, dass sich ein Cursor von selbst bewegte und der Fernzugriff genutzt wurde, um den Natriumhydroxidgehalt im Trinkwasser einer Aufbereitungsanlage in Florida kurzzeitig zu erhöhen. Die Änderung wurde bemerkt und rückgängig gemacht, bevor das Wasser die Bevölkerung erreichte. Der Vorfall wurde jedoch zu einem viel zitierten Beispiel dafür, was passiert, wenn der Fernzugriff nicht streng reglementiert ist – eine Lücke, die genau in den Bereich von FR 1 und FR 2 fällt (Identifizierung, Authentifizierung und Nutzungskontrolle).

Colonial Pipeline, 2021

Ein Ransomware-Angriff auf die IT-Systeme des Unternehmens führte zu einer vorsorglichen, freiwilligen Abschaltung einer wichtigen Treibstoffpipeline, was die Kraftstoffversorgung in einer großen Region der USA über mehrere Tage hinweg störte. Bemerkenswert ist, dass die Betriebstechnologie (OT) selbst nicht direkt kompromittiert war – die Abschaltung war eine geschäftliche Entscheidung, weil die Abrechnungs- und IT-Systeme nicht verfügbar waren. Dies bleibt eines der meistgenannten Beispiele dafür, warum OT- und IT-Sicherheit nicht als völlig getrennte Probleme behandelt werden können und warum Governance-Anforderungen nach 62443-2 genauso wichtig sind wie technische Kontrollen.

Bei allen fünf Vorfällen ist der rote Faden nicht das Fehlen eines einzelnen Tools. Es ist eine fehlende strukturelle Anforderung: Segmentierung, Zugriffskontrolle, Härtung von Sicherheitssystemen oder eine Governance, die IT- und OT-Entscheidungen miteinander verknüpft. Genau das ist die Lücke, die die IEC 62443 schließen soll.

Häufige Herausforderungen bei der Umsetzung der IEC 62443 Compliance

Jedes Unternehmen, mit dem Shieldworkz zusammenarbeitet, unterschätzt beim ersten ernsthaften Compliance-Versuch mindestens eine der folgenden Herausforderungen:

• Legacy-Systeme, die weder gepatcht noch gescannt werden können: Viele aktiv genutzte Steuerungen sind zehn bis fünfundzwanzig Jahre alt und wurden nie für moderne Authentifizierungsverfahren oder Endpoint-Agents ausgelegt.

• Ein kultureller Graben zwischen IT- und OT-Teams: Sicherheitsprioritäten, die Toleranz gegenüber Änderungen (Change-Control) und selbst die grundlegende Terminologie unterscheiden sich stark zwischen den beiden Gruppen, was jede gemeinsame Entscheidung verlangsamt.

• Unvollständige oder veraltete Asset-Inventare: Sie können Assets, die Sie nicht vollständig identifiziert haben, keine präzisen Sicherheitsniveaus zuweisen.

• Zonengrenzen, die nach Bequemlichkeit statt nach Risiko gezogen wurden: Netzwerke werden oft nach physischem Standort oder Lieferant segmentiert, nicht nach den tatsächlichen Auswirkungen einer Kompromittierung.

• Begrenzte interne OT-Sicherheitsexpertise: Die meisten Engineering-Teams in den Werken sind weder personell noch fachlich darauf ausgelegt, eine formelle Risikoanalyse nach einer internationalen Norm durchzuführen.

• Sensibilität für Ausfallzeiten, die Tests einschränkt: Die Validierung von Sicherheitsmaßnahmen erfordert oft Wartungsfenster, die in direktem Konflikt mit den Produktionsplänen stehen.

• Lücken bei Lieferanten und Integratoren: Anforderungen auf Komponentenebene nach 62443-4 hängen von Herstellern ab, die möglicherweise noch nicht nach dem Standard entwickeln, was Anlagenbetreiber dazu zwingt, dies durch zusätzliche Kompensationsmaßnahmen auszugleichen.

Best Practices zur Erreichung und Aufrechterhaltung der IEC 62443 Compliance

Unternehmen, die mit der IEC 62443 erfolgreich sind, folgen meist einer Abfolge, die der Logik des Standards selbst entspricht, anstatt direkt mit Tools oder Dokumentation zu starten.

• Starten Sie mit einem vollständigen, dynamischen Asset-Inventar. Passive Erkennungsmethoden, die sensible Steuerungen nicht stören, sind in Umgebungen, in denen aktives Scannen betriebliche Risiken birgt, unerlässlich.

• Führen Sie die Risikoanalyse durch, bevor Sie Technologien auswählen. Soll-Sicherheitsniveaus und Prioritäten für Schutzmaßnahmen sollten aus der Auswirkungsanalyse resultieren, nicht aus dem Produktkatalog eines Herstellers.

• Entwerfen Sie Zonen und Conduits basierend auf realen Datenflüssen. Bilden Sie ab, wie sich Informationen tatsächlich zwischen Systemen bewegen, bevor Sie Segmentierungsgrenzen auf dem Papier ziehen.

• Behandeln Sie das SL-T als geschäftliche Entscheidung, nicht nur als technische. Binden Sie die Werksleitung und die Safety-Teams ein, wenn Sie Soll-Niveaus für Zonen festlegen, die mit physischen Prozessen verknüpft sind.

• Etablieren Sie eine Governance, die IT und OT umspannt. Gemeinsame Richtlinien, abgestimmte Incident-Response-Pläne und ein gemeinsamer Eskalationspfad verhindern Koordinationsfehler, wie sie bei mehreren der oben genannten Vorfälle zu beobachten waren.

• Passen Sie das Patch-Management an OT-Bedingungen an. Wo Patches nicht machbar sind, müssen kompensierende Maßnahmen wie Netzwerksegmentierung und Monitoring die Lücke schließen und entsprechend dokumentiert werden.

• Erstellen Sie einen OT-spezifischen Incident-Response-Plan. Allgemeine IT-Playbooks berücksichtigen selten funktionale Sicherheitsaspekte (Safety), physikalische Prozessauswirkungen oder die Notwendigkeit, die Produktion während der Eindämmung am Laufen zu halten.

• Führen Sie kontinuierliche Neubewertungen durch. Neue Assets, neue Lieferanten und neue Verbindungen sollten eine Überprüfung auslösen – das Warten auf das nächste geplante Audit lässt Sicherheitslücken viel zu lange offen.

Wie Shieldworkz Ihr Unternehmen unterstützt

Shieldworkz arbeitet an der Seite von OT-Sicherheitsverantwortlichen, Werksleitern und CISOs, um die Anforderungen der IEC 62443 in ein praktisches, sequenziertes Programm zu überführen, das auf dem tatsächlichen Risikoprofil jeder Anlage basiert – statt auf einer generischen Checkliste.

• Umfassende, primär passive Asset-Erkennung und Inventarisierung, die speziell auf sensible OT-Umgebungen zugeschnitten ist

• Strukturierte Risikoanalysen nach IEC 62443, einschließlich Auswirkungsanalyse und Bestimmung des Soll-Sicherheitsniveaus (SL-T)

• Zonen- und Conduit-Design basierend auf realem Netzwerkverkehr und Prozessdatenflüssen

• Gap-Analysen zum Vergleich der aktuellen Sicherheitsniveaus (SL-A) mit den Soll-Sicherheitsniveaus (SL-T)

• Entwicklung von Governance-Frameworks, die die Entscheidungsfindung in der IT- und OT-Sicherheit zusammenführen

• Kontinuierliche Überwachung und Erkennung von Anomalien, entwickelt für industrielle Protokolle und Legacy-Geräte

• OT-spezifische Incident-Response-Planung und Tabletop-Übungen

• Mitarbeiterschulungen, die interne OT-Sicherheitskompetenzen aufbauen, um Abhängigkeiten von externen Dienstleistern zu reduzieren

Das Ziel bleibt immer dasselbe: ein Compliance-Programm, das jeder Audit-Prüfung standhält und, was noch wichtiger ist, das tägliche betriebliche Risiko Ihres Unternehmens effektiv senkt.

Fazit

Die Einhaltung der IEC 62443 ist kein Zertifikat, das man einmal erwirbt und dann vergisst. Sie ist eine strukturierte Denkweise für industrielle Risiken. Sie verlangt von Unternehmen zu verstehen, welche Assets sie besitzen, was schiefgehen könnte, wie schwerwiegend die Folgen wären und welches Schutzniveau jeder Teil der Umgebung tatsächlich benötigt. Die Vorfälle, die in der Fertigungs-, Energie- und Wasserwirtschaft weiterhin Schlagzeilen machen, sind kein Beweis dafür, dass die Norm zu anspruchsvoll ist. Sie sind der Beweis dafür, was passiert, wenn ihre Kernanforderungen – Segmentierung, Zugriffskontrolle, Governance und kontinuierliche Risikoanalyse – nur unvollständig umgesetzt werden.

Für OT-Sicherheitsverantwortliche und Entscheidungsträger, die unter dem Druck stehen, messbare Fortschritte vorzuweisen, beginnt der effektivste Weg mit einer ehrlichen, von Experten begleiteten Bewertung des aktuellen Status der Organisation. Dieser erste Schritt schafft meist schneller Klarheit über die Prioritäten als monatelange interne Diskussionen.

Zusätzliche Ressourcen  

Ein herunterladbarer Bericht zum Stryker-Cyber-Vorfall hier  
Checkliste zur Bewertung und Auswahl von Anbietern für Lösungen zum Scannen von Wechselmedien hier  
Auf der IEC 62443 basierende OT/ICS-Risikoanalyse-Checkliste für die Lebensmittel- und Getränkeindustrie hier