IEC 62443

Überblick

IEC 62443 in fünf Minuten

Geschäftlicher Nutzen

In industriellen Unternehmen ist Cybersecurity unmittelbar mit Wertschöpfung verbunden. Ein Ausfall kann nicht nur Daten betreffen, sondern Materialfluss, Produktionsqualität, Liefertermine, Maschinensicherheit, Umweltauflagen und vertragliche Verpflichtungen. IEC 62443 schafft eine gemeinsame Sprache für Management, IT, OT, Engineering, Einkauf und Lieferanten.

Warum OT anders ist

Viele Sicherheitsprinzipien gelten in IT und OT gleichermaßen. Prioritäten und Randbedingungen unterscheiden sich jedoch. In der OT stehen sichere und vorhersehbare Prozesszustände, Verfügbarkeit, Integrität von Steuerungsfunktionen und kontrollierte Änderungen im Vordergrund. Systeme haben oft lange Lebenszyklen, eingeschränkte Wartungsfenster, proprietäre Protokolle und direkte physische Auswirkungen.

Aufbau der IEC-62443-Normenfamilie

Die Reihe ist nach Themen und Rollen gegliedert. Nicht jeder Teil gilt gleichermaßen für jedes Unternehmen. Betreiber benötigen insbesondere ein Security Program und eine risikobasierte Systemarchitektur. Integratoren und Service Provider müssen sichere Integrations- und Wartungsprozesse beherrschen. Produktlieferanten benötigen einen sicheren Entwicklungslebenszyklus und Komponenten mit definierten technischen Sicherheitsfähigkeiten.

Rollen und gemeinsame Verantwortung

Shared Responsibility bedeutet nicht geteilte Unklarheit. Jede Schnittstelle benötigt eindeutige Verantwortliche, Sicherheitsanforderungen, Freigaben, Eskalationswege und Nachweise.

Security Program für Asset Owner

IEC 62443-2-1:2024 beschreibt Anforderungen an Richtlinien und Verfahren eines Security Programs für Betreiber industrieller Automatisierungs- und Steuerungssysteme. Das Programm muss in die Unternehmensführung eingebettet sein und den Betrieb über den Lebenszyklus steuern.

System Under Consideration

Das System Under Consideration (SUC) ist die fachliche und technische Abgrenzung des Systems, für das Risiken und Sicherheitsanforderungen bestimmt werden. Ein ungeklärter Scope führt zwangsläufig zu Lücken: Schnittstellen werden übersehen, zentrale Dienste nicht berücksichtigt oder Verantwortlichkeiten zwischen Werk, Konzern-IT und Lieferanten verschoben.

Zum SUC gehören typischerweise

• Steuerungen, HMI, SCADA, Historian und Engineering-Systeme,
• Produktionsserver, virtuelle Plattformen und lokale Verzeichnisdienste,
• Netzkomponenten, Firewalls, Remote-Access-Systeme und Managementschnittstellen,
• Verbindungen zu MES, ERP, Qualitätsmanagement, Cloud- und Supportdiensten,
• externe Wartungszugänge und mobile Engineering-Geräte,
• physische Standorte, Schaltschränke, Bedienplätze und Kommunikationsstrecken.

Die Abgrenzung muss fachlich begründet werden. Ein System ist nicht außerhalb des Scopes, nur weil es von einem anderen Team betrieben wird.

OT-Risikobewertung

IEC 62443-3-2 beschreibt einen systematischen Weg von der Definition des SUC über Zonen und Conduits bis zur Festlegung eines Ziel-Security-Levels je Zone und Conduit. Die Bewertung sollte realistische Bedrohungsszenarien und betriebliche Auswirkungen betrachten. Rein generische Risiken wie „Malware möglich“ reichen nicht aus.

Zones & Conduits

Zonen gruppieren logische oder physische Assets mit gemeinsamen Sicherheitsanforderungen. Conduits beschreiben kontrollierte Kommunikationswege zwischen Zonen. Das Modell ist mehr als eine Netzwerkzeichnung: Es verbindet Risiko, Architektur und Anforderungen.

Qualitätsmerkmale eines guten Modells

• Jede Zone hat einen fachlichen Eigentümer und eine begründete Kritikalität.
• Jeder Conduit beschreibt Zweck, Protokolle, Endpunkte, Richtung und Schutzmaßnahmen.
• Unzulässige Kommunikationswege sind technisch blockiert, nicht nur dokumentiert.
• Temporäre und drahtlose Verbindungen werden ebenso berücksichtigt wie permanente Leitungen.
• Das Modell wird bei Anlagenänderungen, neuen Schnittstellen und Fernzugängen aktualisiert.

Security Levels SL 1–4

Security Levels beschreiben die Widerstandsfähigkeit gegen definierte Angreiferklassen. Sie sind keine allgemeine Reifegradnote für ein Werk und dürfen nicht pauschal aus Kundenanforderungen übernommen werden. Relevant sind insbesondere der Ziel-Security-Level (SL-T), die Fähigkeit eines Systems oder einer Komponente (SL-C) und der tatsächlich erreichte Zustand im Betrieb (SL-A).

Sieben Foundational Requirements

IEC 62443-3-3 strukturiert Systemanforderungen in sieben grundlegende Anforderungsbereiche. Diese bilden auch die Grundlage für technische Komponentenanforderungen in IEC 62443-4-2.

Defense in Depth und Purdue-Modell

Defense in Depth verbindet mehrere voneinander unabhängige Schutzebenen. Kein einzelnes Produkt soll das gesamte Risiko tragen. Das Purdue-Modell kann zur Strukturierung industrieller Ebenen hilfreich sein, ist jedoch kein Ersatz für die risikobasierte Zonen- und Conduit-Analyse. Moderne Architekturen mit Cloud, Edge, IIoT und zentralen Plattformen lassen sich nicht immer sauber in klassische Ebenen pressen.

OT Asset Management

Ein belastbares Asset-Inventar ist die Grundlage für Risiko, Patchen, Schwachstellenmanagement, Backup und Incident Response. Eine einmalige Excel-Liste genügt nicht. Notwendig sind Eigentümer, technische Attribute, Kritikalität, Abhängigkeiten und ein kontrollierter Aktualisierungsprozess.

Passive Discovery kann das Inventar verbessern, muss aber validiert werden. Nicht jedes beobachtete Gerät ist korrekt klassifiziert, und nicht jede Anlage kommuniziert permanent.

Netzsegmentierung und Industrial DMZ

Segmentierung begrenzt Reichweite und verhindert, dass Störungen oder Angriffe unkontrolliert zwischen Büro-IT, Werksdiensten und Produktionszellen wandern. Eine VLAN-Struktur ohne restriktive Regeln ist keine wirksame Segmentierung.

Sichere Fernwartung

Fernwartung ist häufig der kritischste externe Zugang zur Produktion. Dauerhafte Hersteller-VPNs, gemeinsame Konten oder direkt erreichbare Maschinen erhöhen das Risiko erheblich. Ein sicherer Prozess kombiniert technische Kontrolle und operative Freigabe.

Die Verantwortung endet nicht beim Dienstleister. Der Asset Owner muss sicherstellen, dass der Zugang zum Risikomodell und zu betrieblichen Anforderungen passt.

Identitäten und privilegierte Zugriffe

OT-Umgebungen enthalten häufig lokale Konten, fest hinterlegte Passwörter, Service-Accounts und herstellerseitige Standardzugänge. Die Verbesserung muss risikobasiert erfolgen und darf die Betriebsfähigkeit nicht gefährden.

• Personalisierte Konten für Bedienung, Engineering und Administration, soweit technisch möglich.
• Trennung von Standard- und Administrationskonten.
• Kontrollierter Umgang mit Notfallkonten und Offline-Hinterlegung.
• Regelmäßige Reviews von Rollen, Lieferantenzugängen und ausgeschiedenen Personen.
• Sichere Verwaltung technischer Konten, Schlüssel und Zertifikate.
• Keine unkontrollierte Kopplung kritischer OT-Systeme an globale Identitätsdienste ohne Ausfall- und Kompromittierungsanalyse.

Systemintegrität, Hardening und Malware-Schutz

Hardening reduziert unnötige Funktionen, Dienste, Schnittstellen und Standardkonfigurationen. In OT-Systemen muss jede Änderung mit Herstellerfreigaben, Funktionstests und Rückfalloptionen abgestimmt werden.

Patch- und Vulnerability-Management

OT-Patchmanagement ist ein Risikoprozess, kein reiner Kalenderprozess. Relevante Faktoren sind Ausnutzbarkeit, Exposition, Prozesskritikalität, Herstellerfreigabe, Testbarkeit, Wartungsfenster und kompensierende Maßnahmen.

IEC TR 62443-2-3 unterstützt die strukturierte Kommunikation von Patchinformationen zwischen Produktlieferanten und Betreibern. Für den Asset Owner bleibt entscheidend, dass Informationen in einen funktionierenden Entscheidungs- und Umsetzungsprozess überführt werden.

Logging, Monitoring und Anomalieerkennung

OT-Monitoring soll relevante Abweichungen erkennen, ohne den Prozess unnötig zu beeinflussen. Passive Netzwerksensorik, Firewall-Logs, Remote-Access-Protokolle, Windows- und Serverlogs sowie Ereignisse aus SCADA und Engineering können kombiniert werden.

Prioritäre Anwendungsfälle

• neue oder unbekannte Geräte und Kommunikationsbeziehungen,
• ungeplante Änderungen an Steuerungen oder Engineering-Projekten,
• fehlgeschlagene oder ungewöhnliche Anmeldungen,
• Fernwartung außerhalb genehmigter Zeitfenster,
• Kommunikation zwischen Zonen, die nicht dem Sollmodell entspricht,
• Malware-Indikatoren und auffällige Dateiübertragungen,
• Ausfall kritischer Security- oder Infrastrukturkomponenten.

Alarme benötigen Verantwortliche, Prioritäten und Reaktionsanweisungen. Eine Sensorplattform ohne geregelte Bearbeitung verbessert die Sicherheit kaum.

Backup, Recovery und Resilienz

OT-Backups umfassen mehr als Serverdaten. Zu sichern sind unter anderem SPS-Programme, Roboterprogramme, HMI-Projekte, SCADA-Konfigurationen, Rezepturen, Firmwarestände, Netzwerk- und Firewallkonfigurationen, Lizenzinformationen und Engineering-Projekte.

OT Incident Response

OT-Incident-Response muss Cybersecurity, Produktion, Engineering, Safety, Qualität, Kommunikation und Management zusammenführen. Standard-IT-Maßnahmen wie sofortiges Abschalten oder Neuinstallieren können gefährliche oder wirtschaftlich unverhältnismäßige Folgen haben.

Übungen sollten reale Szenarien berücksichtigen: kompromittierter Fernzugang, Ransomware in der Werks-IT, manipuliertes Engineering-Projekt, Ausfall zentraler Produktionsdienste oder unbekanntes Gerät in einer Zelle.

Lieferanten und Service Provider

Maschinenbauer, Integratoren, Wartungsfirmen und Produktlieferanten prägen das Sicherheitsniveau erheblich. Anforderungen müssen bereits in Spezifikation und Beschaffung verankert werden. Nachträgliche Sicherheitsnachrüstung ist häufig teuer oder technisch begrenzt.

IEC 62443-2-4 adressiert Sicherheitsprozesse von IACS-Service-Providern während Integration und Wartung. Verträge sollten nicht nur allgemeine Security-Klauseln enthalten, sondern prüfbare Pflichten und Übergaben.

Secure Product Development und Komponenten

IEC 62443-4-1 beschreibt Anforderungen an einen sicheren Produktentwicklungslebenszyklus. Dazu gehören Security-Anforderungen, sichere Architektur, Implementierung, Verifikation, Umgang mit Schwachstellen, Security-Updates und Produktende. IEC 62443-4-2 beschreibt technische Sicherheitsanforderungen an IACS-Komponenten.

Eine Komponentenbescheinigung allein beweist nicht, dass die integrierte Anlage sicher ist. Architektur, Konfiguration, Betrieb und organisatorische Prozesse bleiben entscheidend.

Safety und Security

Safety und Security haben unterschiedliche Methoden, beeinflussen sich aber gegenseitig. Ein Cyberangriff kann Safety-Funktionen beeinträchtigen; eine Security-Maßnahme kann wiederum Verfügbarkeit oder deterministisches Verhalten verändern.

Governance, Organisation und Kennzahlen

IEC 62443 wird unwirksam, wenn sie ausschließlich als Netzwerkprojekt geführt wird. Die Geschäftsleitung muss Produktionsrisiken akzeptieren, Investitionen priorisieren und Zielkonflikte zwischen Verfügbarkeit, Kosten, Safety und Security entscheiden.

Kennzahlen müssen Entscheidungen auslösen. Eine grüne Ampel ohne Aussage zu Restrisiken, Ausnahmen und Wirksamkeit ist wertlos.

Dokumente und Nachweise

Dokumentation soll Betrieb steuern und Entscheidungen nachvollziehbar machen. Ein übergroßes Handbuch ohne operative Evidenz überzeugt weder Management noch Auditor.

Assessment- und Auditperspektive

Eine belastbare Bewertung prüft nicht nur, ob Dokumente existieren. Sie verbindet Design, Umsetzung und Wirksamkeit. Interviews, technische Stichproben, Architekturprüfungen und Betriebsnachweise müssen zusammenpassen.

Typische Stichproben

• ein externer Fernwartungsvorgang vom Antrag bis zum Session-Log,
• eine kritische Schwachstelle vom Advisory bis zur Entscheidung,
• ein SPS- oder HMI-Backup einschließlich Restore-Test,
• eine Firewallregel einschließlich Zweck, Owner und Review,
• eine neue Maschine von Spezifikation und Abnahme bis zum Inventar,
• ein ausgeschiedener Lieferanten- oder Mitarbeiterzugang.

Praxisfälle

Typische Projektfehler

1. IEC 62443 als reine Netzwerksegmentierung behandeln.
2. Ein pauschales Security Level für das gesamte Unternehmen festlegen.
3. Das System Under Consideration zu eng definieren.
4. Zonen nach Organigramm statt nach Risiko und Funktion bilden.
5. VLANs mit wirksamer Segmentierung verwechseln.
6. Direkte Fernwartungszugänge aus Komfortgründen beibehalten.
7. Legacy-Systeme ohne kompensierende Maßnahmen akzeptieren.
8. OT-Assets nur einmalig inventarisieren.
9. Patchen ausschließlich an Herstellerfreigaben delegieren.
10. Backups erstellen, aber Restore und Ersatzhardware nicht testen.
11. Produktion, Engineering und Instandhaltung zu spät einbinden.
12. Safety-Auswirkungen von Security-Änderungen nicht bewerten.
13. Lieferantenanforderungen erst nach der Beschaffung stellen.
14. Komponentenzertifikate als Nachweis der Systemsicherheit missverstehen.
15. Monitoring einführen, ohne Alarmverantwortung zu definieren.
16. Incident-Pläne aus der Büro-IT unverändert übernehmen.
17. Ausnahmen ohne Owner, Ablaufdatum und Restrisiko dokumentieren.
18. Referenzarchitekturen definieren, aber lokale Abweichungen nicht steuern.
19. Governance und Budgetentscheidungen auf die IT delegieren.
20. Das Projekt nach einem Assessment als abgeschlossen betrachten.

Typische Feststellungen

Reifegradmodell

Roadmap 30 / 60 / 90 / 180 / 365 Tage

Vergleich mit anderen Frameworks

Die Frameworks konkurrieren nicht zwingend. Ein Unternehmen kann ISO 27001 als Managementsystem nutzen, NIS2 als Rechtsrahmen, TISAX für Automotive-Kundennachweise und IEC 62443 für industrielle Systeme und Produkte.

Orientierungschecklisten

Geschäftsleitung

• Sind Produktionsausfall, Safety, Qualität und Lieferverpflichtungen in Cyberrisiken abgebildet?
• Gibt es einen verantwortlichen Sponsor und klare Risikoakzeptanz?
• Sind kritische OT-Investitionen, Legacy-Risiken und Lifecycle-Budgets sichtbar?
• Werden externe Betreiber- und Lieferantenabhängigkeiten gesteuert?

CIO / CISO

• Sind IT/OT-Schnittstellen, Identitäten, Monitoring und Incident-Prozesse abgestimmt?
• Bestehen validierte Zonen- und Conduit-Modelle?
• Werden Risiken, Ausnahmen und kompensierende Maßnahmen nachvollziehbar geführt?
• Existiert ein globaler Standard mit lokalen Verantwortlichkeiten?

OT / Engineering

• Sind kritische Assets, Programme, Versionen und Wiederanlaufabhängigkeiten bekannt?
• Werden Änderungen, Fernzugriffe, Patches und Backups kontrolliert?
• Enthalten neue Spezifikationen konkrete Security-Anforderungen?
• Sind Safety- und Produktionsauswirkungen bei Security-Maßnahmen berücksichtigt?

Audit / Assessment

• Stimmen Dokumentation, technische Konfiguration und tatsächlicher Betrieb überein?
• Sind Stichproben vom Antrag bis zum Betriebsnachweis nachvollziehbar?
• Werden Security Levels risikobasiert begründet?
• Ist Wirksamkeit über Tests, Kennzahlen, Alarme und Verbesserungen belegt?

Häufige Fragen

Ist IEC 62443 nur für kritische Infrastrukturen?

Nein. Die Reihe gilt für industrielle Automatisierungs- und Steuerungssysteme in vielen Branchen und kann auch für Maschinen, Produktionslinien, Gebäudeautomation oder andere Automatisierungsumgebungen relevant sein.

Ist IEC 62443 eine einzelne Norm?

Nein. Es handelt sich um eine Normenfamilie mit Grundlagen, Betreiber- und Serviceprozessen, Systemanforderungen sowie Produktentwicklungs- und Komponentenanforderungen.

Wer ist Asset Owner?

Die Organisation, die das IACS besitzt oder betreibt und die Verantwortung für dessen sicheren Betrieb trägt. In IEC 62443-2-1:2024 ist der Operator im Kontext eingeschlossen.

Was ist ein System Under Consideration?

Die klar abgegrenzte industrielle Umgebung, für die Risiken, Zonen, Conduits und Sicherheitsanforderungen bestimmt werden.

Was ist eine Zone?

Eine Gruppe von Assets mit gemeinsamen Sicherheitsanforderungen, Kritikalität oder Funktion.

Was ist ein Conduit?

Ein kontrollierter Kommunikationspfad zwischen Zonen, für den Zweck und Sicherheitsanforderungen definiert werden.

Ist das Purdue-Modell vorgeschrieben?

Nein. Es kann als Orientierung dienen, ersetzt aber nicht das risikobasierte Zonen- und Conduit-Modell.

Was bedeutet SL-T?

Target Security Level: der risikobasiert festgelegte Zielwert für eine Zone oder einen Conduit.

Was bedeutet SL-C?

Capability Security Level: die technische Sicherheitsfähigkeit eines Systems oder einer Komponente.

Was bedeutet SL-A?

Achieved Security Level: der tatsächlich erreichte Sicherheitszustand im integrierten und betriebenen System.

Muss jedes Werk SL 3 erreichen?

Nein. Security Levels werden je Zone und Conduit aus Risiken abgeleitet. Pauschale Vorgaben sind häufig fachlich und wirtschaftlich ungeeignet.

Kann eine Firewall IEC-62443-Konformität herstellen?

Nein. Die Normenfamilie umfasst Governance, Risiko, Architektur, Produkte, Betrieb, Lieferanten und Lifecycle.

Was ist IEC 62443-2-1?

Der Teil mit Anforderungen an das Security Program für Asset Owner im Betrieb von IACS.

Was ist IEC 62443-2-4?

Anforderungen an Sicherheitsprozesse von IACS-Service-Providern bei Integration und Wartung.

Was ist IEC 62443-3-2?

Anforderungen an die Sicherheitsrisikobewertung für Systemdesign, einschließlich SUC, Zonen, Conduits und SL-T.

Was ist IEC 62443-3-3?

System Security Requirements und Security Levels, strukturiert in sieben Foundational Requirements.

Was ist IEC 62443-4-1?

Anforderungen an einen sicheren Produktentwicklungslebenszyklus.

Was ist IEC 62443-4-2?

Technische Sicherheitsanforderungen an IACS-Komponenten.

Wie passt IEC 62443 zu ISO 27001?

ISO 27001 kann das Managementsystem und die Governance liefern; IEC 62443 vertieft industrielle Systeme, Rollen, Architektur und Produkte.

Wie passt IEC 62443 zu NIS2?

IEC 62443 kann bei der Umsetzung industrieller technischer und organisatorischer Maßnahmen helfen. Die NIS2-Betroffenheit und Rechtsanforderungen müssen separat bewertet werden.

Wie passt IEC 62443 zu TISAX?

TISAX bewertet Informationssicherheit im Automotive-Umfeld. IEC 62443 vertieft die Security von Produktions- und Automatisierungssystemen.

Wie passt IEC 62443 zum CRA?

IEC 62443-4-1 und 4-2 sind für Hersteller industrieller digitaler Produkte relevant und können Produktsecurity-Prozesse und technische Anforderungen strukturieren.

Braucht man ein vollständiges OT-Inventar?

Für belastbares Risikomanagement ja. Umfang und Tiefe müssen zur Kritikalität passen, aber unbekannte Assets lassen sich nicht wirksam schützen.

Darf OT automatisch gescannt werden?

Aktive Scans können Systeme beeinflussen. Verfahren müssen getestet, freigegeben und an Hersteller- sowie Betriebsanforderungen angepasst werden.

Wie oft müssen Patches installiert werden?

Es gibt keine pauschale Frist für alle Systeme. Entscheidungen müssen risikobasiert, dokumentiert und durch Patches oder kompensierende Maßnahmen behandelt werden.

Ist Antivirus auf jeder SPS erforderlich?

Nein. Schutzmaßnahmen müssen technisch geeignet und unterstützt sein. Häufig sind Segmentierung, Allowlisting, sichere Engineering-Prozesse und Monitoring relevanter.

Wie sollte Fernwartung aufgebaut sein?

Zentral, personalisiert, mit MFA, zeitlicher Freigabe, Zielbegrenzung, Protokollierung und Notfallabschaltung.

Was gehört in ein OT-Backup?

Neben Serverdaten auch Steuerungsprogramme, HMI- und SCADA-Projekte, Konfigurationen, Firmwarestände, Lizenzen und Netzkomponenten.

Wie testet man OT-Wiederherstellung?

Durch geplante technische Restore-Tests, Funktionsprüfung, dokumentierte Reihenfolge und Berücksichtigung von Ersatzhardware und Lizenzen.

Kann ein zertifiziertes Produkt automatisch sicher integriert werden?

Nein. Sichere Integration, Architektur, Konfiguration und Betrieb bleiben erforderlich.

Ist IEC 62443 gesetzlich verpflichtend?

Die Norm selbst ist grundsätzlich ein Standard. Sie kann durch Verträge, Kundenanforderungen, Ausschreibungen oder regulatorische Nachweiserwartungen faktisch relevant werden.

Wie beginnt ein Unternehmen?

Mit Sponsor, Scope, kritischem Asset- und Zugangsüberblick, Pilot-SUC, Risikobewertung und priorisierten Maßnahmen.

Wie lange dauert die Einführung?

Abhängig von Anzahl der Werke, Brownfield-Anteil, Lieferanten, Reife und Zielumfang. Ein Pilot kann in Monaten aufgebaut werden; ein konzernweiter Rollout dauert häufig länger.

Was sollte ein Assessment zuerst prüfen?

Governance, Inventar, Fernzugänge, IT/OT-Übergänge, Backups, Patchrisiken, Incident Readiness und kritische Lieferanten.

Müssen alte Anlagen ersetzt werden?

Nicht automatisch. Risiken können durch Segmentierung, Zugangskontrolle, Monitoring, Ersatzteilstrategie und andere kompensierende Maßnahmen reduziert werden. Langfristige Migration bleibt oft erforderlich.

Was ist das wichtigste Erfolgsmerkmal?

Klare gemeinsame Verantwortung zwischen Management, Produktion, Engineering, IT, Security und Lieferanten.

Glossar

IEC 62443 Executive Toolkit

Toolkit in Vorbereitung

Verwandte Themen

Primärquellen und fachliche Grundlage