IEC 62443

IEC 62443 ist eine internationale Normenreihe für die Cybersicherheit industrieller Automatisierungs- und Steuerungssysteme. Sie beschreibt Begriffe, Modelle, Prozesse und technische Anforderungen für Industrial Automation and Control Systems, kurz IACS. Für Embedded-Systeme und Industrieelektronik ist sie vor allem dort maßgeblich, wo Steuerungen, Sensoren, Gateways, Industrie-PCs, Netzwerkgeräte oder Softwarekomponenten in Produktionsanlagen eingesetzt werden.

Was umfasst die IEC 62443?

Die IEC 62443 behandelt Cybersicherheit im industriellen Umfeld. Sie richtet sich an mehrere Rollen: Betreiber von Anlagen, Integratoren von Automatisierungssystemen und Hersteller von Komponenten. Die Normenreihe trennt dabei zwischen Anforderungen an Organisationen, Systeme, Entwicklungsprozesse und einzelnen Komponenten.

Der Begriff IACS umfasst Automatisierungs- und Steuerungssysteme, die industrielle Prozesse überwachen, regeln oder steuern. Dazu gehören etwa Steuerungen, Bedienstationen, Engineering-Systeme, Netzwerkinfrastruktur, industrielle Software und eingebettete Geräte. Die IEC 62443 betrachtet solche Systeme nicht nur als IT-Systeme, sondern als Bestandteile technischer Anlagen, bei denen Verfügbarkeit, Integrität, kontrollierter Zugriff und Schutz vor Manipulation technische Folgen haben können.

Für Embedded-Geräte und Industrieelektronik sind besonders drei Teile der Normenreihe prägend:

  • IEC 62443-3-2 für die Security-Risikobeurteilung beim Systemdesign
  • IEC 62443-4-1 für den sicheren Produktentwicklungsprozess
  • IEC 62443-4-2 für technische Sicherheitsanforderungen an Komponenten
Diagramm der IEC 62443 Sicherheitsbausteine für IACS: General, Policies, System, Component; Fokus auf embedded software.
Vorläufige Gliederung der IEC 62443 (Quelle: EVS)

Wie funktioniert die IEC 62443?

Die Normenreihe arbeitet risikoorientiert. Zunächst wird der betrachtete Gegenstand beschrieben. In der IEC 62443-3-2 wird dafür das System under Consideration, kurz SUC, abgegrenzt. Dieses System wird mit seiner Umgebung, seinen Schnittstellen und seiner Architektur betrachtet.

Anschließend wird das System in Zonen und Übergänge unterteilt. Eine Zone fasst Bestandteile mit vergleichbaren Sicherheitsanforderungen zusammen. Ein Übergang beschreibt die Verbindung zwischen Zonen. Für jede Zone und jeden Übergang werden Risiken analysiert. Dabei werden Schwachstellen, Bedrohungen, vorhandene Gegenmaßnahmen und mögliche Folgen betrachtet.

Aus dieser Bewertung wird ein Ziel-Sicherheitslevel abgeleitet. Dieser Security Level beschreibt, welches Schutzniveau für eine Zone, einen Übergang, ein System oder eine Komponente angestrebt wird. Der Security Level ist keine allgemeine Qualitätsnote. Er bezieht sich auf Bedrohungsprofile, Ressourcen und Fähigkeiten möglicher Angreifer sowie auf den vorgesehenen Einsatzkontext.

Bei Produkten ergänzt die IEC 62443-4-1 diese Sicht durch Anforderungen an den Entwicklungsprozess. Sie beschreibt, wie Hersteller Sicherheitsanforderungen erfassen, sichere Architektur- und Implementierungsentscheidungen treffen, Sicherheitsprüfungen durchführen, Schwachstellen behandeln, Updates verwalten und Sicherheitsdokumentation bereitstellen.

Die IEC 62443-4-2 setzt an der Komponente an. Sie beschreibt, welche technischen Sicherheitsfunktionen industrielle Komponenten bereitstellen müssen, wenn sie für einen bestimmten Security Level ausgelegt werden. Die Norm betrachtet dabei etwa Embedded Devices, Host Devices, Network Devices und Software Applications.

Die wichtigsten Teile der Norm für Produkthersteller

IEC 62443-3-2

IEC 62443-3-2 behandelt die Security-Risikobeurteilung für das Systemdesign. Sie liefert eine Methode, um Sicherheitsanforderungen aus einer konkreten industriellen Architektur abzuleiten.

Der Ablauf beginnt mit der Beschreibung des betrachteten Systems. Danach werden Zonen und Übergänge festgelegt. Für diese Bereiche werden Risiken bestimmt und bewertet. Daraus entstehen Ziel-Security-Levels und daraus abgeleitete Sicherheitsanforderungen.

Typische Bedrohungen im industriellen Umfeld betreffen die Verfügbarkeit, Integrität und Vertraulichkeit. Beispiele sind Eingriffe in Steuerungsfunktionen, blockierte sicherheitsbezogene Einrichtungen, unterdrückte Warnmeldungen, veränderte Messwerte, manipulierte Betriebsparameter oder ausgespähte Zugangsdaten. Die IEC 62443-3-2 ordnet solche Bedrohungen nicht isoliert ein, sondern im Zusammenhang mit Systemarchitektur, Schwachstellen und bereits vorhandenen Schutzmaßnahmen.

Für Embedded- und Industrieelektronik ist dieser Teil der Norm bedeutsam, weil die Anforderungen an ein Gerät oft aus der Systemumgebung entstehen. Eine Steuerung, ein Sensor oder ein Gateway kann in einer abgeschotteten Zone andere Anforderungen haben als in einer Architektur mit direkter Verbindung zu übergeordneten Systemen oder externen Diensten.

Zones und Conduits

Das Konzept der Zones and Conduits ist eines der zentralen Architekturprinzipien im Risiko-Teil. Es dient dazu, industrielle Systeme nicht als ein großes, einheitliches Netzwerk zu betrachten, sondern in sicherheitstechnisch sinnvolle Bereiche aufzuteilen. Ziel ist nicht nur eine bessere Übersicht, sondern vor allem die kontrollierte Begrenzung von Kommunikation, Zugriffen und möglichen Angriffsauswirkungen.

Eine Zone ist eine Gruppe von Systemen, Komponenten oder Netzwerksegmenten, die aus Security-Sicht ähnlich behandelt werden sollen. Die Systeme innerhalb einer Zone haben also vergleichbare Schutzanforderungen, ähnliche Funktionen oder vergleichbare Risiken. Eine Zone kann zum Beispiel aus mehreren Steuerungen einer Maschine bestehen, aus einem HMI mit den zugehörigen Controllern, aus einem Engineering-Netzwerk oder aus einem Bereich mit besonders kritischen Prozessfunktionen.

Wichtig ist: Eine Zone ist nicht zwingend identisch mit einem IP-Subnetz, einem Schaltschrank oder einer physischen Anlage. Solche Merkmale können bei der Definition helfen, sie sind aber nicht allein entscheidend. Eine Zone ist in erster Linie eine Security- und Architekturentscheidung. Sie beschreibt, welche Systeme gemeinsam betrachtet werden und welches Schutzprofil für diese Systeme gelten soll.

Ein Conduit beschreibt dagegen die Verbindung zwischen Zonen. Über einen Conduit findet Kommunikation zwischen zwei oder mehreren Zonen statt. Das können physische Netzwerkverbindungen, Firewall-Regeln, VPN-Verbindungen, Remote-Access-Strecken, Protokollübergänge oder auch Applikationsschnittstellen sein. Der Conduit ist damit nicht nur „das Kabel“ zwischen zwei Bereichen, sondern die definierte und kontrollierte Kommunikationsbeziehung zwischen Zonen.

Der entscheidende Punkt ist: Nicht jede Zone darf frei mit jeder anderen Zone kommunizieren. Stattdessen wird festgelegt, welche Kommunikation erforderlich ist, welche Protokolle genutzt werden dürfen, welche Systeme miteinander sprechen dürfen und welche Schutzmaßnahmen am Übergang notwendig sind. Genau an diesen Übergängen entstehen die wichtigsten Security-Mechanismen einer segmentierten industriellen Architektur.

Zonen und Conduit Modell in der IEC 62443
Zonen und Conduit Modell in der IEC 62443

Eine Zone kann in der Praxis zum Beispiel ein Anlagennetz sein, in dem eine oder mehrere SPSen, dezentrale I/O-Module, Antriebe, Sensorik, Feldbusse und gegebenenfalls auch drahtlose Schnittstellen zusammengefasst werden. Die Zone beschreibt dann einen funktionalen und sicherheitstechnischen Bereich der Anlage.

Die Zonenübergänge sind die Punkte, an denen Kommunikation mit anderen Zonen möglich wird. Dazu zählen zum Beispiel Verbindungen zu einem HMI-Netz, einem Engineering-Netzwerk, einem Leitsystem, einer Cloud-Anbindung oder einem Fernwartungszugang. Solche Übergänge werden im IEC-62443-Kontext als Conduits betrachtet oder zumindest über Conduits beschrieben.

Wichtig ist dabei: Auch Wartungsschnittstellen, Service-Ports, USB-Zugänge, drahtlose Schnittstellen, Diagnoseadapter, temporäre Engineering-Verbindungen oder Remote-Access-Lösungen können Einstiegspunkte in eine Zone sein. Aus Angreifersicht sind genau diese Punkte interessant, weil sie Kommunikation in einen geschützten Bereich ermöglichen. Es muss somit auch dokumentiert werden, welche Kommunikationswege in die Zone hinein und aus der Zone heraus existieren, welche davon dauerhaft aktiv sind, welche nur für Wartung oder Inbetriebnahme genutzt werden und welche Schutzmaßnahmen an diesen Übergängen greifen.

Bedeutung für ICAS-Hersteller

Hersteller von Industrieelektronik sollten im Rahmen der IEC-62443-Betrachtung früh einordnen, welche Rolle ihr Device in der späteren Anlagenarchitektur übernimmt. Ein Gerät kann ein Asset innerhalb einer Zone sein, zum Beispiel eine Steuerung, ein Sensor, ein Aktor, ein HMI oder ein Embedded Gateway innerhalb eines funktionalen Anlagenteils. Es kann aber auch eine Übergangsfunktion zwischen zwei Zonen übernehmen, etwa wenn es Kommunikation weiterleitet, Protokolle übersetzt, Fernzugriff ermöglicht, Daten in Richtung IT, Cloud oder Historian überträgt oder als Gateway zwischen Maschinen- und Leitebene eingesetzt wird.

Diese Unterscheidung ist sicherheitstechnisch relevant. Ein Device innerhalb einer Zone muss zu den Schutzanforderungen dieser Zone passen. Ein Device im Conduit dagegen beeinflusst unmittelbar, welche Kommunikation zwischen Zonen möglich ist und welche Angriffswege dadurch entstehen. In diesem Fall geht es nicht nur um die Absicherung des Geräts selbst, sondern auch um Zugriffskontrolle, Protokollbegrenzung, Authentisierung, Logging, Updatefähigkeit und die Frage, ob unerwünschte Kommunikation zwischen Zonen verhindert werden kann.

Für Hersteller bedeutet das: Die Security-Anforderungen an ein Produkt hängen nicht nur von dessen Funktion ab, sondern auch von dessen architektonischer Rolle im Gesamtsystem. Ein identisches Embedded Device kann je nach Einsatzfall unterschiedlich bewertet werden. Als lokaler Teilnehmer innerhalb einer Zone gelten andere Anforderungen als bei einem Gerät, das zwei Netzbereiche verbindet oder Daten aus einer OT-Zone in andere Systeme überträgt. Deshalb sollte bereits in der Produktentwicklung dokumentiert werden, für welche Einsatzszenarien das Device vorgesehen ist, welche Kommunikationsbeziehungen unterstützt werden und welche Schutzmechanismen an Zonengrenzen verfügbar sind.

IEC 62443-4-1

IEC 62443-4-1 beschreibt Anforderungen an einen Secure Product Development Lifecycle. Der Normteil behandelt damit den Entwicklungsprozess, nicht einzelne technische Funktionen eines Produkts.

Die Anforderungen sind in Praktiken gegliedert. Dazu gehören Sicherheitsmanagement, Spezifikation von Sicherheitsanforderungen, sicheres Design, sichere Implementierung, Sicherheitsverifizierung und -validierung, Behandlung sicherheitsbezogener Probleme, Sicherheits-Update-Management und Sicherheitsdokumentation.

Der Ansatz entspricht dem Prinzip Security by Design. Sicherheitsanforderungen sollen in der Anforderungsanalyse, im Design, in der Implementierung, beim Test, bei der Freigabe und während der Wartung berücksichtigt werden. Für Hersteller von Embedded-Systemen bedeutet das etwa, dass Authentifizierung, Update-Mechanismen, Protokollierung, sichere Standardkonfigurationen oder der Umgang mit Schwachstellen nicht erst nach der Produktfreigabe betrachtet werden.

Die IEC 62443-4-1 verwendet außerdem Maturity Levels. Diese beschreiben, wie Entwicklungsprozesse umgesetzt und gesteuert werden. Die Stufen reichen von ad-hoc geprägten Abläufen über dokumentierte und organisationsweit definierte Prozesse bis zu Prozessen, die anhand von Messgrößen und Rückmeldungen verbessert werden.

IEC 62443-4-2

IEC 62443-4-2 beschreibt technische Sicherheitsanforderungen an Komponenten industrieller Automatisierungs- und Steuerungssysteme. Der Normteil betrifft einzelne Produkte, zum Beispiel Steuerungen, Sensoren, Switches, industrielle Firewalls, Gateways, Host-Systeme oder Softwareanwendungen.

Die Norm unterscheidet Komponentenklassen wie Software Applications, Embedded Devices, Host Devices und Network Devices. Embedded Devices sind für die Industrieelektronik besonders naheliegend, weil viele Steuerungs-, Mess-, Kommunikations- und Feldgeräte als eingebettete Systeme ausgeführt sind.

Die IEC 62443-4-2 gliedert ihre technischen Anforderungen in sieben Foundational Requirements:

  • Identification and Authentication Control
  • Use Control
  • System Integrity
  • Data Confidentiality
  • Restricted Data Flow
  • Timely Response to Events
  • Resource Availability

Diese Anforderungen betreffen unter anderem Identifikation und Authentifizierung, Zugriffskontrolle, Schutz der Systemintegrität, Vertraulichkeit von Daten, Begrenzung von Datenflüssen, Reaktion auf sicherheitsbezogene Ereignisse und Verfügbarkeit von Ressourcen.

Die IEC 62443-4-2 steht in enger Beziehung zur IEC 62443-4-1. Eine Komponente, die Konformität mit IEC 62443-4-2 beansprucht, muss nach einem Entwicklungsprozess erstellt worden sein, der IEC 62443-4-1 entspricht. Technische Sicherheitsfunktionen und Entwicklungsprozess werden damit zusammen betrachtet.

Verwendungsrahmen der IEC 62443

IEC 62443 wird in industriellen Automatisierungsumgebungen verwendet. Dazu zählen Fertigungsanlagen, Prozessanlagen, Energieversorgung, Maschinen, industrielle Netzwerke, Steuerungstechnik und Systeme mit IT-OT-Kopplung.

Bei Betreibern unterstützt die Normenreihe die Strukturierung von Schutzmaßnahmen für Anlagen und Steuerungssysteme. Bei Integratoren hilft sie, Systeme in Zonen und Übergänge aufzuteilen und Sicherheitsanforderungen in Architekturentscheidungen zu überführen. Bei Herstellern dient sie als Bezugsrahmen für Entwicklungsprozesse und technische Sicherheitsfunktionen von Komponenten.

Für Industrieelektronik entsteht der Bezug häufig über Komponentenanforderungen. Ein IIoT-Gateway, eine industrielle Firewall, eine speicherprogrammierbare Steuerung oder ein Condition-Monitoring-Sensor kann Funktionen enthalten, die nach IEC 62443-4-2 bewertet werden. Bei IIoT-Komponenten kommen zusätzliche Fragen hinzu, weil solche Geräte oft mit Cloud-Diensten kommunizieren, mehrere Funktionen in einem Gerät bündeln oder über Netzwerkschnittstellen dauerhaft erreichbar sind.

IEC 62443 trennt zwischen Systembetrachtung, Prozessanforderungen und technischen Komponentenanforderungen. Diese Trennung verhindert, dass eine einzelne Komponente ohne Kenntnis ihrer Umgebung pauschal als ausreichend geschützt betrachtet wird.

Die Normenreihe verwendet Security Levels. Diese Levels beschreiben das angestrebte Schutzniveau bezogen auf Bedrohungen und Einsatzkontext. Ein höherer Security Level ist nicht automatisch für jedes Produkt oder jede Zone erforderlich. Die Auswahl entsteht aus der Risikobeurteilung.

Zonen und Übergänge bilden ein Architekturmodell für industrielle Systeme. Sie helfen, Kommunikationsbeziehungen, Schutzbedarf und technische Maßnahmen räumlich oder logisch zu strukturieren.

Für Hersteller verbindet die Normenreihe Entwicklungsprozess und Produktfunktion. Die IEC 62443-4-1 beschreibt, wie sichere Produkte entwickelt werden. Die IEC 62443-4-2 beschreibt, welche Sicherheitsfunktionen Komponenten bereitstellen müssen.

Grenzen und typische Missverständnisse

Ein häufiges Missverständnis besteht darin, IEC 62443 als reine Checkliste zu behandeln. Die Normenreihe verlangt eine Betrachtung von Systemgrenzen, Einsatzkontext, Architektur, Bedrohungen und Entwicklungsprozessen. Ohne Risikobeurteilung lässt sich ein Security Level nicht fachgerecht begründen.

Ein weiteres Missverständnis betrifft Security Levels. Sie beschreiben kein allgemeines Gütesiegel. Sie beziehen sich auf definierte Bedrohungsannahmen und Anforderungen. Eine Komponente mit einem bestimmten Security Level kann in einem anderen Systemkontext zusätzliche Maßnahmen benötigen.

Bei regulatorischen Anforderungen kann IEC 62443 eine Grundlage bilden, sie deckt aber nicht automatisch jeden Rechtsrahmen vollständig ab. In den Quellen wird etwa beschrieben, dass IEC 62443-4-1 prozessuale Anforderungen des Cyber Resilience Act unterstützen kann, für technische Anforderungen aber weitere Normen erforderlich sein können.

Genau dieser Aspekt wird immer wieder missverstanden, wenn Hersteller IEC 62443 als direkten Nachweis für ein „cyber-sicheres Produkt“ zu verstehen. Die Normenreihe beschreibt jedoch vor allem Prozesse, Rollen, Verantwortlichkeiten und Vorgehensweisen zur Entwicklung, Integration und zum Betrieb sicherer industrieller Systeme. Sie ist damit eher ein Management-System als eine Anforderungsdeokument.

Ein Hersteller kann sich beispielsweise attestieren oder zertifizieren lassen, dass seine Entwicklungsprozesse nach IEC 62443 ausgerichtet sind. Das bedeutet aber zunächst nur, dass bestimmte organisatorische und technische Entwicklungsprozesse definiert, dokumentiert und angewendet werden.

Der TÜV Süd bietet explizit folgendes Leistungsspektrum an.

  • Produkthersteller können sich nach IEC 62443-4-1 (sichere Produktentwicklung) zertifizieren lassen. 
  • Integratoren und Dienstleister können ein Zertifikat nach IEC 62443-2-4 (Sicherheitsprogramm von Dienstleistern) erhalten. 
  • Für Betreiber werden Zertifizierungen nach IEC 62443-2-1 angeboten

Daraus folgt nicht automatisch, dass jedes Produkt dieses Herstellers cyber-sicher ist oder in jeder Anlage sicher eingesetzt werden kann.

Ein Produkt kann nach einem IEC-62443-konformen Entwicklungsprozess entstanden sein und trotzdem Schwachstellen enthalten, für den konkreten Einsatzfall falsch konfiguriert sein oder nicht zu den Schutzanforderungen einer bestimmten Zone passen.

Eine Hersteller- oder Lieferantenattestierung ist für Integratoren damit ein hilfreicher Nachweis, ersetzt aber nicht die eigene Risikoanalyse und auch nicht die Prüfung, ob das konkrete Device zur vorgesehenen Zone oder zum vorgesehenen Conduit passt. Umgekehrt sollten Hersteller klar dokumentieren, was ihre Produkte tatsächlich leisten: Welche Schnittstellen sind vorhanden? Welche Security-Funktionen werden unterstützt? Welche Annahmen gelten für den Betrieb? Welche Konfigurationen sind sicherheitsrelevant? Welche Anforderungen müssen durch den Betreiber oder Integrator erfüllt werden?

IEC 62443 ist damit kein Gütesiegel, das ein Produkt pauschal sicher macht. Sie ist ein Rahmenwerk, mit dem Security systematisch behandelt werden kann. Der eigentliche Sicherheitsnachweis entsteht aber erst im konkreten Kontext: für ein bestimmtes Produkt, eine bestimmte Systemarchitektur, eine bestimmte Bedrohungslage und einen definierten Betrieb.

Synonyme:
IEC 62443-4-2, IEC 62443-4-1, IEC 62443-3-2, IEC 62443-3-3
Zurück zum Glossar