Wenn Sie sich mit Cybersecurity-Frameworks für die Industrie befasst haben, sind Sie wahrscheinlich schon mehr als einmal auf die IEC 62443 gestoßen und haben sich von ihr vielleicht auch ein wenig erdrückt gefühlt. Es handelt sich dabei nicht um ein einzelnes Dokument. Sie ist eine Normenreihe und umfasst technische Berichte, die jeweils eine andere Verantwortungsebene über den gesamten Lebenszyklus der operativen Technologie (OT) hinweg abdecken. Diese Struktur ist äußerst leistungsfähig, sobald man sie verstanden hat, kann jedoch verwirrend sein, wenn man sich ihr zum ersten Mal nähert oder versucht herauszufinden, welcher Teil tatsächlich für die eigene Rolle relevant ist. 

Dieser Blog schlüsselt die Normenreihe IEC 62443 in verständlicher Form auf. Sie erfahren, wie die einzelnen Teile organisiert sind, was mit jedem Teil erreicht werden soll, wer für die Umsetzung verantwortlich ist und wie die Teile ineinandergreifen, um einen vollständigen, risikobasierten Ansatz zum Schutz industrieller Steuerungssysteme zu bilden. Unabhängig davon, ob Sie als Anlagenbetreiber ein Sicherheitsprogramm aufbauen wollen, als Integrator ein neues Steuerungsnetzwerk entwerfen oder als Hersteller Komponenten für Kritische Infrastrukturen (KRITIS) entwickeln – dieser Artikel hilft Ihnen dabei, genau Ihre Rolle zu identifizieren. 

Die Normenreihe IEC 62443 ist in vier Kategorien unterteilt, welche die Verantwortlichkeiten der verschiedenen Akteure über den gesamten OT-Lebenszyklus hinweg widerspiegeln. 

Was ist die IEC 62443 und warum sie für die OT-Sicherheit entscheidend ist 

Die IEC 62443 ist eine international anerkannte Normenreihe, die für die Absicherung industrieller Automatisierungs- und Steuerungssysteme (Industrial Automation and Control Systems, IACS) entwickelt wurde. Im Gegensatz zu traditionellen IT-Sicherheitsframeworks wurde sie speziell für Umgebungen konzipiert, in denen funktionale Sicherheit (Safety), Systemverfügbarkeit und physikalische Prozesse Vorrang vor den klassischen Zielen der Datenvertraulichkeit haben. Der Ausfall eines Steuerungssystems bedeutet nicht nur einen Datenabfluss. Er kann einen Stillstand der Produktionslinie, die Beschädigung von Sachwerten, Umweltunfälle oder im schlimmsten Fall eine Gefahr für Leib und Leben von Menschen bedeuten. 

Genau aus diesem Grund greifen allgemeine IT-Sicherheits-Checklisten in OT-Umgebungen zu kurz. Das Einspielen von Patches bei einer speicherprogrammierbaren Steuerung (SCADA/PLC) im selben Rhythmus wie bei einem Laptop oder das Anwenden einer Intrusion-Prevention-Regel ohne Kenntnis der Auswirkungen auf die Echtzeitkommunikation kann mehr Risiken verursachen als beseitigen. Die IEC 62443 wurde unter Berücksichtigung dieser Realität entwickelt. Sie bietet Organisationen eine strukturierte, risikobasierte Methodik, welche die betrieblichen Rahmenbedingungen industrieller Systeme respektiert und gleichzeitig das Sicherheitsniveau messbar erhöht. 

Regulierungsbehörden, Versicherer und Branchenverbände ziehen die IEC 62443 bei der Bewertung des Reifegrads der OT-Sicherheitsarchitektur einer Organisation zunehmend heran. Die Einhaltung spezifischer Teile dieser Norm nachweisen zu können, entwickelt sich zu einem echten Wettbewerbsvorteil bei Lieferantenbewertungen, Versicherungsverlängerungen und behördlichen KRITIS-Audits im Maschinenbau, in der Energie- und Wasserwirtschaft sowie in anderen Sektoren Kritischer Infrastrukturen. 

Die Struktur der IEC-62443-Familie verstehen 

Der einfachste Weg, die IEC 62443 zu verstehen, besteht darin, sie nicht als ein einziges Dokument, sondern als vier Kategorien zu betrachten, die sich jeweils an eine andere Zielgruppe und eine andere Phase des OT-Lebenszyklus richten. 

Eine vereinfachte Übersicht über die Gruppierung der IEC-62443-Teile nach Kategorie, Anwendungsbereich und Zielgruppe. 

Allgemeines (Teil-1-Serie) 

Diese Dokumente legen das Fundament. Sie definieren die Terminologie, Konzepte und Modelle, auf die im weiteren Verlauf der Normenreihe Bezug genommen wird, einschließlich des grundlegenden Konzepts der Security Levels (Sicherheitsstufen), auf das wir gleich noch zurückkommen werden. Wenn Sie neu in diesem Bereich sind, ist dies der richtige Ausgangspunkt, auch wenn Organisationen hier selten den Großteil ihres Implementierungsaufwands investieren. 

Richtlinien und Prozesse (Teil-2-Serie) 

Diese Kategorie richtet sich direkt an Betreiber von Industrieanlagen. Sie definiert, wie ein funktionierendes Cybersecurity-Managementsystem (CSMS) für die OT aussehen sollte, wie das Patch-Management unter Berücksichtigung der Betriebskontinuität durchzuführen ist und was von Dienstleistern erwartet wird, die industrielle Systeme warten oder unterstützen. Wenn Ihre Organisation Governance-Strukturen für die OT-Sicherheit etablieren möchte, anstatt lediglich Technologie einzukaufen, ist dies der Bereich, mit dem Sie sich am intensivsten befassen werden. 

System (Teil-3-Serie) 

Hier wird die Risikoanalyse konkret. Sie führt die Methode der Segmentierung eines Netzwerks in Zonen und Leitungen (Zones and Conduits) ein, weist Ziel-Sicherheitsstufen basierend auf dem tatsächlichen Risiko zu und definiert die technischen Anforderungen, die ein System erfüllen muss, um die jeweilige Stufe zu erreichen. Betreiber und Systemintegratoren stützen sich beim Entwurf oder der Neugestaltung von Netzwerkarchitekturen maßgeblich auf diese Kategorie. 

Komponente (Teil-4-Serie) 

Diese Kategorie überträgt die Verantwortung auf die Produkthersteller. Sie definiert einen sicheren Produktentwicklungszyklus für Steuerungssystem-Produkte sowie spezifische technische Anforderungen, die einzelne Komponenten wie Steuerungen, Sensoren und Embedded Devices erfüllen müssen. Wenn Ihr Unternehmen industrielle Hard- und Software herstellt oder integriert, bestimmen diese Anforderungen, wie Produkte von Grund auf sicher konstruiert werden müssen, statt sie erst im Nachhinein abzusichern. 

Detaillierte Betrachtung der einzelnen Teile: Inhalte und Zielgruppen 

Gehen wir nun eine Ebene tiefer. Die Struktur der Kategorien zu kennen ist nützlich, aber erst das Verständnis der konkreten Anforderungen der einzelnen Teile macht die Theorie zu einer praxistauglichen Roadmap. 

Grundlegende Konzepte: Terminologie, Modelle und Lebenszyklus 

Die einleitenden allgemeinen Dokumente etablieren das gemeinsame Vokabular und die Konzeptmodelle, die in der gesamten Reihe verwendet werden. Dazu gehört, wie Assets gruppiert, Vertrauensgrenzen definiert und wie der gesamte Sicherheitslebenszyklus vom Design bis zur Außerbetriebnahme ablaufen soll. Das Überspringen dieser Phase führt in Projektteams häufig dazu, dass spätere Anforderungen falsch angewendet werden – meist aufgrund eines inkonsistenten Verständnisses von Grundbegriffen wie Zone, Leitung (Conduit) oder Security Level. 

Aufbau eines Cybersecurity-Managementsystems 

Die Anforderungen an das Sicherheitsprogramm beschreiben den Aufbau, den Betrieb und die kontinuierliche Verbesserung eines spezifisch auf die OT ausgerichteten Cybersecurity-Managementsystems. Es handelt sich hierbei nicht um ein einmaliges Projekt. Es umfasst Governance-Strukturen, Risikomanagement-Prozesse, Verantwortlichkeiten des Personals, die Vorfallsbehandlung (Incident Response) sowie die organisatorische Disziplin, die erforderlich ist, um ein Sicherheitsprogramm bei sich verändernden Bedrohungen und Systemlandschaften aktuell zu halten. 

Patch-Management ohne Beeinträchtigung der Produktion 

Einer der praxisnahsten Teile der gesamten Reihe befasst sich damit, wie Software-Updates und Patches in industriellen Umgebungen bewertet, getestet und eingespielt werden sollten. Er berücksichtigt eine Realität, die IT-fokussierte Frameworks oft vernachlässigen: Man kann ein Update für eine Steuerung (SCADA/PLC) in einem kontinuierlichen chemischen Prozess oder einer Turbine in einem Kraftwerk nicht ohne sorgfältige Validierung durchführen. Dieser Teil bietet eine klare Struktur für kompensierende Sicherheitsmaßnahmen und gestaffelte Rollouts, falls ein sofortiges Patchen betrieblich nicht möglich ist. 

Anforderungen an Dienstleister 

Viele OT-Umgebungen sind auf externe Integratoren und Wartungsdienstleister angewiesen, die direkten Zugriff auf die Steuerungssysteme haben. Dieser Teil definiert die Erwartungen an eine sichere Arbeitsweise dieser Dienstleister – vom sicheren Fernzugriff bis hin zum Umgang mit Zugangsdaten und Geräten bei der Arbeit vor Ort oder per Remote-Zugang. Angesichts der Häufigkeit, mit der externe Zugriffe bei realen OT-Sicherheitsvorfällen eine Rolle spielen, ist dies keineswegs eine reine Formalität. 

Risikoanalyse, Zonen und Leitungen 

Dies ist häufig der Ausgangspunkt für jedes seriöse Architekturprojekt. Der Teil beschreibt, wie eine strukturierte Risikoanalyse durchgeführt und wie diese Analyse in Zonen – logische oder physikalische Gruppierungen von Assets mit ähnlichen Sicherheitsanforderungen – übersetzt wird. Diese sind durch Leitungen (Conduits) verbunden, welche den Datenfluss und den Datenverkehr steuern. Richtig umgesetzt, ist diese Segmentierung eine der effektivsten Maßnahmen, um einen Sicherheitsvorfall einzudämmen, bevor er sich auf eine gesamte Anlage ausbreitet. 

System-Sicherheitsanforderungen und Security Levels 

Nachdem Zonen und Leitungen definiert sind, spezifiziert dieser Teil die technischen Anforderungen, die ein System innerhalb einer bestimmten Zone erfüllen muss. Diese sind in sieben grundlegende Anforderungen (Foundational Requirements) unterteilt, wie etwa Zugriffskontrolle, Nutzungskontrolle, Systemintegrität und Vertraulichkeit von Daten. Jeder Zone wird basierend auf dem Bedrohungsszenario, dem sie standhalten muss, ein Ziel-Security-Level zugewiesen. Dies ermöglicht es Unternehmen, den Schutzbedarf risikogerecht und wirtschaftlich zu bestimmen, anstatt überall dieselben Controls anzuwenden. 

Security Levels beschreiben die Professionalität der Bedrohung, der eine Zone standhalten soll – von der zufälligen Gefährdung bis hin zu staatlichen Akteuren. 

Sicherer Produktentwicklungszyklus 

Auf Herstellerseite definiert dieser Teil die Prozesse, die ein Lieferant beim Design, der Entwicklung und der Pflege von Steuerungssystem-Produkten einhalten sollte. Dazu gehören sichere Programmierpraktiken, Schwachstellenmanagement (Vulnerability Handling), Bedrohungsanalysen (Threat Modeling) und Sicherheitstests über den gesamten Produktlebenszyklus hinweg. Unternehmen nutzen diesen Teil zunehmend als Benchmark bei der Beschaffung, um von Lieferanten den Nachweis zu fordern, dass ihr Entwicklungsprozess diesen Anforderungen entspricht. 

Technische Anforderungen an Komponenten 

Dieser Teil wird konkret und definiert spezifische technische Anforderungen für einzelne Komponenten wie eingebettete Systeme (Embedded Devices), Netzwerkkomponenten, Host-Anwendungen und Software-Applikationen. Er ist das Gegenstück auf Komponentenebene zu den zuvor beschriebenen Systemanforderungen und stellt sicher, dass die einzelnen Bausteine eines Steuerungssystems in der Lage sind, das Sicherheitsniveau zu unterstützen, für das das Gesamtsystem ausgelegt ist. 

Risiken, Herausforderungen und Branchenerkenntnisse 

Das Verständnis der Struktur der IEC 62443 ist deshalb so wichtig, weil die adressierten Risiken real sind. Industrieunternehmen weltweit mussten bereits schwerwiegende Konsequenzen aufgrund von Sicherheitslücken tragen, die durch diese Norm gezielt geschlossen werden sollen. 

Ein bekanntes Beispiel der letzten Jahre betrifft einen globalen Aluminiumproduzenten. Eine Ransomware-Infektion breitete sich von der Unternehmens-IT in die Produktionsumgebungen aus und zwang mehrere Werke dazu, wochenlang auf manuellen Betrieb umzustellen. Der finanzielle Schaden ging in die zweistellige Millionenhöhe. Die Ursache lag in einer unzureichenden Segmentierung zwischen den Büronetzwerken und den operativen Systemen – genau die Schwachstelle, welche die Zonen- und Leitungsanforderungen verhindern sollen. 

Ein weiterer, häufig zitierter Vorfall betraf ein Wasserwerk in den USA, bei dem ein Operator einen unbefugten Fernzugriff bemerkte, der versuchte, die Chemikalienkonzentration im Aufbereitungsprozess zu verändern. Der Eingriff wurde rechtzeitig gestoppt, zeigte jedoch deutlich, dass Fernzugriffspfade von externen Wartungsdienstleistern – genau das Thema der Anforderungen an Dienstleister – nach wie vor zu den häufigsten Einfallstoren in sensible OT-Umgebungen gehören. 

Dies sind keine Einzelfälle. Sie stehen für ein wiederkehrendes Muster in der Fertigungsindustrie, im Energiesektor und bei Versorgungsunternehmen: flache Netzwerke ohne nennenswerte Segmentierung, komfortable, aber schlecht kontrollierte Fernzugriffe, zu langsame oder unvorsichtige Patch-Prozesse sowie Komponenten, die nie unter Sicherheitsaspekten entwickelt wurden, weil der Lieferant nicht dazu aufgefordert wurde. 

Folgende Risiken und Herausforderungen treten in OT-Umgebungen, die ihre Exposition noch nicht anhand der relevanten Teile der IEC 62443 bewertet haben, regelmäßig auf: 

• Flache oder unzureichend segmentierte Netzwerke, die es Angreifern ermöglichen, sich von einer einzigen kompromittierten Workstation lateral in kritische Prozesszonen vorzuarbeiten

• Veraltete Steuerungen (Legacy-Systeme) und Feldgeräte, die nie dafür ausgelegt wurden, Benutzer zu authentifizieren, Kommunikation zu verschlüsseln oder Manipulationen zu widerstehen 

• Direkt aus der IT übernommene Patch-Management-Prozesse, die ohne Rücksicht auf Verfügbarkeits- und Sicherheitsanforderungen der Produktion angewendet werden 

• Fernzugriffe für Lieferanten und Integratoren mit minimaler Überwachung, unzureichender Protokollierung oder fehlender zeitlicher Begrenzung 

• Beschaffungsentscheidungen ohne vertraglich oder in den Bewertungskriterien verankerte Sicherheitsanforderungen 

• Fehlen einer klaren Verantwortlichkeit für die OT-Cybersecurity, wobei die Zuständigkeiten zwischen Engineering, IT und Betrieb aufgeteilt sind 

• Sicherheitsprogramme, die nur auf dem Papier existieren, aber bei Veränderungen der Systemlandschaft weder getestet, geübt noch aktualisiert werden 

Was diese Herausforderungen besonders kostspielig macht, ist, dass sie selten durch eine einzige Maßnahme gelöst werden können. Eine Firewall allein behebt kein fehlerhaftes Segmentierungsdesign. Ein einzelnes Richtliniendokument löst keine inkonsistenten Patch-Prozesse. Genau deshalb verteilt die IEC 62443 die Verantwortung auf Governance, Architektur und Produktdesign, anstatt Sicherheit als isoliertes Problem einer einzelnen Abteilung zu betrachten. 

Praktische Empfehlungen und Best Practices 

Die Umsetzung der IEC 62443 erfordert nicht die gleichzeitige Einführung aller Teile der Norm. Ein phasenweises, risikobasiertes Vorgehen führt in der Praxis zu besseren Ergebnissen und stößt auf deutlich weniger internen Widerstand als der Versuch eines vollständigen Rollouts in einem Schritt. 

Beginnen Sie mit einer realistischen Risikoanalyse 

Bevor Sie festlegen, welches Security Level angestrebt werden soll, müssen Sie verstehen, was Sie tatsächlich schützen und wie die reale Bedrohungslage aussieht. Eine Risikoanalyse, die auf Ihren spezifischen Prozessen, den Auswirkungen auf die funktionale Sicherheit (Safety) und Ihrer Bedrohungsexposition basiert, spart erheblich Zeit und Budget im Vergleich zur pauschalen Anwendung eines Standards auf alle Assets unabhängig von deren Kritikalität. 

Definieren Sie Zonen und Leitungen vor dem Kauf von Technologien 

Es ist verlockend, sofort eine Next-Generation-Firewall oder eine OT-spezifische Monitoring-Plattform anzuschaffen. Widerstehen Sie diesem Impuls, bis die Netzwerksegmentierung sauber geplant ist. Technologie, die vor der Definition der Sicherheitsarchitektur beschafft wird, ist oft fehlerhaft konfiguriert, wird unzureichend genutzt oder im falschen Netzwerkbereich platziert. 

Richten Sie das Patch-Management an der betrieblichen Realität aus 

Etablieren Sie statt starrer Patch-Zyklen einen Prozess, der das tatsächliche Risiko jeder Schwachstelle für Ihre Umgebung bewertet, Updates nach Möglichkeit in einer repräsentativen Testumgebung validiert und kompensierende Maßnahmen wie Netzwerkisolation oder verstärktes Monitoring einsetzt, wenn ein sofortiges Einspielen von Patches betrieblich nicht vertretbar ist. 

Integrieren Sie Sicherheitsanforderungen in Beschaffungsverträge 

Wenn Sie neue Steuerungen (SCADA/PLC), Software oder industrielle IoT-Geräte beschaffen, fordern Sie von den Herstellern Auskunft darüber, wie ihr Entwicklungsprozess mit den Anforderungen an einen sicheren Produktlebenszyklus übereinstimmt. Hersteller, die dies nicht transparent darlegen können, liefern Ihnen einen wichtigen Hinweis darauf, wie es um die inhärente Sicherheit ihrer Produkte bestellt ist. 

Formalisieren Sie die Governance für Drittanbieter und Fernzugriffe 

Jede Remote-Verbindung in Ihre OT-Umgebung muss zeitlich begrenzt, lückenlos protokolliert und an einen spezifischen, freigegebenen Zweck gebunden sein. Dauerhafte Zugriffe für Integratoren und Wartungspartner gehören zu den häufigsten und am leichtesten vermeidbaren Risiken. 

Betrachten Sie das Sicherheitsprogramm als lebendes System 

Ein Cybersecurity-Managementsystem, das einmalig erstellt und danach nie wieder angepasst wird, verliert schnell den Bezug zur Realität. Planen Sie regelmäßige Überprüfungszyklen, Krisenstabsübungen und klare Zuständigkeiten ein, damit sich das Programm parallel zu Ihren Systemen, der Bedrohungslage und Ihrer Organisationsstruktur weiterentwickelt. 

Wie Shieldworkz Ihr Unternehmen unterstützt 

Shieldworkz unterstützt Anlagenbetreiber und Industrieunternehmen dabei, das Framework der IEC 62443 in einen praxisnahen, priorisierten Handlungsplan zu übersetzen, anstatt eine unüberschaubare Checkliste abzuarbeiten. Unser Ansatz basiert auf der Realität von Produktivsystemen im laufenden Betrieb, bei denen Sicherheit und Verfügbarkeit niemals zugunsten theoretischer Sicherheitsanforderungen aufs Spiel gesetzt werden dürfen. 

• Durchführung OT-spezifischer Risikoanalysen, die Ihre tatsächlichen Assets, Prozesse und Ihre Bedrohungsexposition mit den für Ihre Umgebung relevantesten Anforderungen abgleichen 

• Konzeption von Zonen- und Leitungsarchitekturen (Zones and Conduits), die Vorfälle isolieren, bevor sie sich auf kritische Prozessbereiche ausbreiten können 

• Unterstützung bei der Definition und Operationalisierung eines Cybersecurity-Managementsystems (CSMS), das sich in Ihre bestehende Organisationsstruktur einfügt, statt ein starres Standard-Template überzustülpen 

• Unterstützung bei der Implementierung von Patch-Management-Strategien, welche die Dringlichkeit von Sicherheitsupdates mit der geforderten Betriebskontinuität in Einklang bringen 

• Überprüfung und Optimierung von Fernzugriffs- und Dienstleister-Richtlinien für Integratoren und Servicepartner 

• Beratung von Beschaffungsteams bei der Bewertung von Herstellersicherheitspraktiken auf Basis anerkannter Standards zur sicheren Softwareentwicklung 

• Bereitstellung kontinuierlicher Transparenz und Überwachung, die speziell auf industrielle Protokolle und das Verhalten von Steuerungssystemen (SCADA/PLC) zugeschnitten ist 

• Begleitung von Organisationen über eine phasenbasierte Roadmap, die den Reifegrad kontinuierlich aufbaut, anstatt eine risikoreiche Ad-hoc-Transformation zu erzwingen 

Wir arbeiten eng mit Ihren Engineering-, Betriebs- und Sicherheitsteams zusammen, da nachhaltige OT-Sicherheitsprogramme nur in Kooperation mit den Mitarbeitern gelingen, die die Prozesse am besten kennen. 

Fazit 

Die IEC 62443 ist keine bloße Checkliste, die man einmalig abarbeitet und dann vergisst. Sie ist ein ganzheitliches Framework, das darauf basiert, dass verschiedene Akteure über den OT-Lebenszyklus hinweg unterschiedliche Verantwortlichkeiten tragen und echte Sicherheit nur durch das Ineinandergreifen dieser Verantwortlichkeiten entsteht. Betreiber etablieren Governance und Sicherheitsarchitekturen. Integratoren entwerfen und implementieren sichere Systeme. Hersteller entwickeln von Beginn an sichere Produkte. Wenn diese Bausteine ineinandergreifen, erreichen Organisationen ein Sicherheitsniveau, das dem tatsächlichen Risiko angemessen ist, anstelle eines Flickwerks unzusammenhängender Einzelmaßnahmen. 

Diejenigen Unternehmen, die den größten Nutzen aus der IEC 62443 ziehen, identifizieren zunächst die Teile, die für ihre konkrete Rolle relevant sind, und entwickeln darauf basierend einen realistischen, stufenweisen Plan. Diese Klarheit zu gewinnen ist oft der schwierigste Schritt. Genau an dieser Stelle sorgt erfahrene Unterstützung für den Unterschied zwischen einer Norm, die im Regal verstaubt, und einer Praxis, die Risiken messbar minimiert. 

Buchen Sie eine kostenfreie Erstberatung mit unseren Experten 

Wenn Sie herausfinden möchten, welche Teile der IEC 62443 für Ihr Unternehmen relevant sind oder wie Sie dieses Framework in eine realistische Roadmap für Ihre spezifische Umgebung übersetzen können, steht Ihnen unser Team gerne zur Verfügung. Buchen Sie ein kostenfreies Erstgespräch mit den OT-Sicherheitsexperten von Shieldworkz und erhalten Sie eine klare, pragmatische und auf Ihre Systeme, Ihr Risikoprofil und Ihre Prioritäten zugeschnittene Beratung – ohne starre Standard-Checklisten.

Zusätzliche Ressourcen  

Ein herunterladbarer Bericht zum Stryker-Sicherheitsvorfall finden Sie hier  
Checkliste zur Bewertung und Auswahl von Lösungen zur Überprüfung von Wechselmedien (Removable Media Scan) finden Sie hier  
Eine auf der IEC 62443 basierende OT/ICS-Risikoanalyse-Checkliste für die Lebensmittel- und Getränkeindustrie finden Sie hier