IEC 62443
einfach erklärt.
Und prüfbar gemacht.

Die IEC 62443 ist die internationale Normenreihe für Cybersecurity in industriellen Automatisierungs- und Steuerungssystemen (Industrial Automation and Control Systems, IACS). Sie richtet sich an drei Rollen: Betreiber (Asset Owner), Systemintegratoren und Dienstleister sowie Komponentenhersteller. Für jede Rolle legt ein eigener Normteil fest, was sie nachweisen muss.

Die IEC 62443 ist selbst kein Gesetz, aber faktisch verbindlich. § 30 Abs. 2 BSIG verlangt von Einrichtungen unter NIS2, bei ihren Sicherheitsmaßnahmen den Stand der Technik einzuhalten und einschlägige europäische und internationale Normen zu berücksichtigen, und für OT ist das die IEC 62443. Der EU Cyber Resilience Act (CRA) fordert von Herstellern Security by Design, was sich mit IEC 62443-4-1 und -4-2 belegen lässt. Am häufigsten wird die Norm aber über das Lastenheft eines Kunden zur Pflicht.

Die Reihe hat vier Gruppen. Teil 1 legt Begriffe und Modelle fest. Teil 2 richtet sich an Betreiber und Dienstleister, darunter 2-1 (Security-Programm des Betreibers) und 2-4 (Anforderungen an Integrations- und Wartungsdienstleister). Teil 3 betrifft das System, darunter 3-2 (Risikoanalyse, Zonen und Conduits) und 3-3 (Systemanforderungen und Security Levels). Teil 4 betrifft Komponenten, mit 4-1 (sicherer Entwicklungsprozess) und 4-2 (technische Anforderungen an die Komponente).

Die IEC 62443-4-1 legt den sicheren Entwicklungsprozess eines Herstellers fest, die IEC 62443-4-2 die technischen Sicherheitsanforderungen an die fertige Komponente. 4-1 beschreibt also, wie entwickelt wird, 4-2, was das Produkt können muss. Für DevSecOps ist 4-1 der wichtigere Teil, weil sich der geforderte Prozess in einer CI/CD-Pipeline automatisieren lässt.

Die IEC 62443-2-4 legt fest, welche Security-Fähigkeiten Dienstleister nachweisen müssen, die Automatisierungslösungen integrieren oder warten, also typischerweise Systemintegratoren und Maschinenbauer im Service. Dazu gehören der Umgang mit Fernzugriffen, Patches, Backups und Konfigurationsänderungen. Betreiber nutzen den Teil, um diese Anforderungen vertraglich an ihre Lieferanten weiterzugeben.

ISO/IEC 27001 beschreibt ein Managementsystem für die Informationssicherheit einer Organisation, die IEC 62443 die Security von Automatisierungsanlagen und ihren Komponenten. ISO 27001 fragt, ob das Unternehmen seine Informationsrisiken steuert. Die IEC 62443 fragt, ob eine Zone, ein System oder eine Steuerung gegen einen bestimmten Angreifer geschützt ist, und verteilt die Pflichten auf Betreiber, Integratoren und Hersteller. Viele Betreiber nutzen beide: ISO 27001 für die Organisation, IEC 62443 für die Anlagen.

Die Security Levels beschreiben, gegen welchen Angreifer ein System geschützt ist. SL 1 schützt gegen zufällige Fehlbedienung, SL 2 gegen gezielte Angriffe mit einfachen Mitteln, SL 3 gegen Angreifer mit IACS-Kenntnissen und moderaten Ressourcen, SL 4 gegen Angreifer mit umfangreichen Ressourcen und hoher Motivation. SL 0 bedeutet, dass keine besonderen Anforderungen gelten. Welches Level eine Zone braucht, ergibt die Risikoanalyse nach IEC 62443-3-2.

SL-T (Target) ist das Ziel-Level, das die Risikoanalyse für eine Zone oder einen Conduit festlegt. SL-C (Capability) ist das Level, das ein System nach IEC 62443-3-3 oder eine Komponente nach IEC 62443-4-2 bei richtiger Konfiguration erreichen kann. SL-A (Achieved) ist das Level, das in der laufenden Anlage tatsächlich erreicht ist. Eine Komponente mit SL-C 3 bringt also noch kein SL-A 3, wenn sie mit Standardpasswort in Betrieb geht.

Die IEC 62443-3-2 beschreibt sieben Schritte. Das betrachtete System wird abgegrenzt, eine erste Risikobewertung durchgeführt und die Anlage in Zonen und Conduits aufgeteilt. Danach wird das Risiko mit dem tolerierbaren Risiko verglichen, für jede Zone und jeden Conduit eine detaillierte Risikoanalyse mit Ziel-Security-Level (SL-T) erstellt, die Anforderungen dokumentiert und vom Betreiber freigegeben. Das Ergebnis ist die Grundlage für alle technischen Maßnahmen.

Die IEC 62443 teilt eine Anlage in Sicherheitszonen mit ähnlichem Schutzbedarf, die nur über definierte, kontrollierte Übergänge (Conduits) miteinander kommunizieren. Jede Zone erhält aus der Risikoanalyse ihr eigenes Ziel-Security-Level. Das Modell ist die Grundlage für OT-Netzwerksegmentierung und für sichere Deployments aus einer CI/CD-Pipeline.

Das Purdue-Modell ordnet eine Industrieanlage in Ebenen von den Feldgeräten (Level 0) bis zur Unternehmens-IT (Level 4 und 5), meist mit einer Industrial DMZ auf Level 3.5 dazwischen. Viele Unternehmen nutzen diese Ebenen als ersten Entwurf für ihre Zonen. Die IEC 62443 schreibt das Modell aber nicht vor: Zonen folgen dem Schutzbedarf aus der Risikoanalyse, und eine Safety-Steuerung bekommt oft eine eigene Zone, obwohl sie auf derselben Ebene liegt wie die übrige Linie.

Die IEC 62443-4-1 verlangt einen sicheren Entwicklungs-Lebenszyklus (Secure Development Lifecycle) in acht Praktiken, von Security Management bis zu Security-Hinweisen für Anwender. Vier davon laufen direkt als Pipeline-Stufen: sichere Implementierung (Secrets-Scan, statische Analyse, Pflicht-Review), Security-Tests, Umgang mit Schwachstellen (Dependency Scan gegen die SBOM) und Security-Updates (signierte Artefakte). Security Management, Anforderungen und Threat Modeling bleiben Arbeit von Menschen, deren Ergebnis die Pipeline vor dem Release als Bedingung prüft, und die Security-Hinweise für Anwender entstehen als versioniertes Dokument je Release. Jeder Lauf hinterlässt so den Nachweis, den das Audit sehen will.

Maturity Level 2 („Managed“) heißt, dass der Entwicklungsprozess schriftlich festgelegt ist und die Beteiligten danach arbeiten können: Rollen, Verfahren und Schulung sind vorhanden. Für Level 3 („Defined“) muss der Hersteller zusätzlich belegen, dass der Prozess tatsächlich und wiederholt so gelebt wird, Level 4 („Improving“) verlangt Kennzahlen und laufende Verbesserung. Für eine Software heißt Level 2 in der Praxis: beschriebene Security-Anforderungen, Code-Reviews, Security-Tests, ein Verfahren für gemeldete Schwachstellen und Updates, jeweils mit Zuständigkeit.

Eine IEC-62443-Zertifizierung hat vier Schritte: Rolle und Scope festlegen (Produkt nach 4-1/4-2, System nach 3-3 oder Betrieb nach 2-1), Gap-Analyse gegen die relevanten Anforderungen, Audit durch eine akkreditierte Stelle (zum Beispiel TÜV oder ein Zertifizierer im ISASecure-Programm) und regelmäßige Überwachungsaudits. Eine automatisierte DevSecOps-Pipeline liefert die Nachweise für das Audit gleich mit.

Die Freigabe liegt beim Betreiber, der dafür im Security-Programm nach IEC 62443-2-1 Rollen und Verantwortlichkeiten festlegt. Bei sicherheitsgerichteten Funktionen kommt die Freigabe aus dem Safety-Prozess hinzu. Für den Nachweis zählt nicht die Erinnerung der Beteiligten, sondern die Spur: wer was wann auf welcher Grundlage freigegeben hat. Am verlässlichsten entsteht diese Spur als Nebenprodukt der Pipeline. Commit, Review, Testergebnis, signiertes Artefakt und Deployment-Log ergeben zusammen eine Kette, die im Audit ohne Nacharbeit vorzeigbar ist.

Safety schützt Menschen und Umwelt vor Gefahren, die von der Maschine ausgehen (funktionale Sicherheit). Security schützt die Maschine vor absichtlichen Angriffen und Manipulation (Cybersicherheit). Beide gehören zusammen, weil ein Angriff die funktionale Sicherheit aushebeln kann, wie der TRITON-Angriff auf ein Safety Instrumented System 2017 gezeigt hat.