DevSecOps in der Industrie: IEC 62443
Security-First für industrielle Umgebungen: Wie Sie IEC 62443 in Ihre CI/CD-Pipelines integrieren und DevSecOps-Praktiken auf OT-Systeme übertragen — ohne die Produktion auszubremsen.
Warum Security in der OT anders ist
In der IT-Welt ist DevSecOps mittlerweile etabliert: Security-Checks laufen automatisiert in der Pipeline, Schwachstellen werden in Stunden gepatcht, Container werden bei jedem Build gescannt. Shift Left — Security von Anfang an.
In der OT-Welt sieht die Realität anders aus. Hier laufen SPS-Steuerungen, die seit 15 Jahren unverändert im Einsatz sind. Hier gibt es Protokolle ohne Verschlüsselung, Systeme ohne Patch-Möglichkeit und Netzwerke, die nie für Konnektivität designed wurden — und jetzt plötzlich mit der Cloud verbunden sind.
IEC 62443 ist die internationale Normenreihe, die genau dieses Problem adressiert: Cybersecurity für Industrial Automation and Control Systems (IACS). Und DevSecOps ist der Ansatz, diese Anforderungen in automatisierte, reproduzierbare Prozesse zu überführen — statt sie manuell in Excel-Tabellen zu verwalten.
Die Bedrohungslage ist real
Industrielle Systeme sind zunehmend Ziel von Cyberangriffen. Ransomware-Angriffe auf Produktionsanlagen, Manipulation von Steuerungssystemen und Datendiebstahl sind keine Theorie mehr — sie passieren regelmäßig.
- Colonial Pipeline (2021): Ransomware legt größte US-Kraftstoff-Pipeline lahm
- Norsk Hydro (2019): LockerGoga-Ransomware — 71 Mio. USD Schaden
- TRITON/TRISIS (2017): Angriff auf Safety-Instrumented Systems in Petrochemie
IEC 62443: Was Sie wissen müssen
Die IEC 62443 ist keine einzelne Norm, sondern eine Normenreihe mit vier Teilen, die den gesamten Security-Lifecycle abdecken — vom Betreiber über den Integrator bis zum Komponentenhersteller.
Die 4 Teile der IEC 62443
Für DevSecOps ist besonders IEC 62443-4-1 relevant: „Product Security Development Life-Cycle Requirements". Diese Norm definiert, wie sichere Software für industrielle Systeme entwickelt werden muss — und lässt sich direkt auf CI/CD-Pipelines abbilden.
Die 4 Security Levels (SL 1–4)
IEC 62443 definiert vier Security Levels, die den Schutzgrad gegen unterschiedliche Bedrohungen beschreiben. Nicht jedes System braucht SL 4 — der richtige Level hängt von der Risikoanalyse ab.
Zufällige Verletzung
Schutz gegen unbeabsichtigte oder zufällige Verletzungen der Sicherheit. Basis-Hygiene: Passwortschutz, Netzwerksegmentierung.
Gezielte Angriffe (geringe Ressourcen)
Schutz gegen gezielte Angriffe mit begrenzten Ressourcen, allgemeinen Fähigkeiten und geringer Motivation.
Gezielte Angriffe (moderate Ressourcen)
Schutz gegen gezielte Angriffe mit spezifischen IACS-Kenntnissen, moderaten Ressourcen und mittlerer Motivation.
Gezielte Angriffe (hohe Ressourcen)
Schutz gegen staatliche Akteure mit umfangreichen Ressourcen, tiefem IACS-Wissen und hoher Motivation.
Die 7 Foundational Requirements — und was sie für Ihre Pipeline bedeuten
IEC 62443 definiert 7 grundlegende Sicherheitsanforderungen (Foundational Requirements). Jede lässt sich konkret auf CI/CD-Pipeline-Aktionen abbilden.
Identification & Authentication Control
Identifikation und Authentifizierung aller Benutzer, Geräte und Software-Prozesse.
Use Control
Autorisierung und Zugriffskontrolle nach dem Least-Privilege-Prinzip.
System Integrity
Sicherstellung der Integrität von IACS-Komponenten und Software.
Data Confidentiality
Vertraulichkeit von Informationen in Kommunikationskanälen und Datenspeichern.
Restricted Data Flow
Segmentierung von Netzwerken und Kontrolle des Datenflusses.
Timely Response to Events
Zeitnahe Reaktion auf Sicherheitsvorfälle durch Monitoring und Alerting.
Resource Availability
Sicherstellung der Verfügbarkeit des IACS trotz Denial-of-Service-Angriffen.
Die DevSecOps-Pipeline für IEC 62443
7 Stages, die Security von Anfang an integrieren — mit konkreten Tools und IEC-62443-Bezug.
Secure Commit
Pre-Commit-Hooks prüfen auf Secrets, Credentials und sensible Daten im Code. Keine API-Keys, keine Passwörter im Repository.
FR 1 (Identification & Authentication) — Credentials dürfen nicht im Quellcode liegen.
Static Analysis (SAST)
Statische Code-Analyse identifiziert Schwachstellen, unsichere Funktionsaufrufe und Compliance-Verstöße — bevor der Code kompiliert wird.
FR 3 (System Integrity) — Software-Integrität sicherstellen, bekannte Schwachstellenmuster erkennen.
Dependency Scanning
Automatische Prüfung aller Abhängigkeiten auf bekannte Schwachstellen (CVEs). Software Bill of Materials (SBOM) generieren.
FR 3 (System Integrity) — Supply-Chain-Security, keine bekannten Vulnerabilities in Abhängigkeiten.
Build & Sign
Artefakte werden in einer kontrollierten Umgebung gebaut und kryptographisch signiert. Jedes Artefakt ist nachvollziehbar.
FR 3 (System Integrity) — Nachweisbare Integrität und Authentizität von Software-Artefakten.
Dynamic Testing (DAST)
Laufende Systeme werden auf Schwachstellen getestet: offene Ports, unsichere Konfigurationen, Authentifizierungs-Bypasses.
FR 5 (Restricted Data Flow) — Unerlaubte Datenflüsse und offene Angriffsvektoren identifizieren.
Compliance Gate
Automatisierte Prüfung gegen IEC 62443 Anforderungen. Policy-as-Code definiert, welche Security-Level erfüllt sein müssen.
Alle FRs — Automatisierte Validierung der Zielvorgaben vor dem Release.
Deploy & Monitor
Kontrolliertes Deployment mit Security-Monitoring. Anomalie-Erkennung, Log-Analyse und Incident-Response-Prozesse.
FR 6 (Timely Response) — Sicherheitsvorfälle erkennen, protokollieren und zeitnah reagieren.
IT-Security vs. OT-Security: Die Unterschiede
DevSecOps-Praktiken aus der IT lassen sich nicht 1:1 auf die OT übertragen. Diese Unterschiede müssen bei der Pipeline-Gestaltung berücksichtigt werden.
Patch-Zyklen
Wöchentlich bis monatlich
Jährlich oder seltener — Patch erfordert Anlagenstillstand
Lebenszyklus
3–5 Jahre
15–30 Jahre — Legacy-Systeme ohne Security-Support
Verfügbarkeit
99,9 % (8,7 h Downtime/Jahr)
99,999 % (5,3 min Downtime/Jahr)
Fehlerfolgen
Datenverlust, Reputationsschaden
Personenschäden, Umweltschäden, Produktionsausfall
Protokolle
HTTP, TLS, SSH — standardisiert und verschlüsselbar
Modbus, OPC UA, PROFINET — oft unverschlüsselt
5 Quick Wins: Morgen starten
Sie müssen nicht gleich die komplette IEC 62443 umsetzen. Beginnen Sie mit diesen fünf Maßnahmen — sie liefern sofortigen Sicherheitsgewinn bei überschaubarem Aufwand.
Secrets aus dem Repository entfernen
NiedrigInstallieren Sie git-secrets oder detect-secrets als Pre-Commit-Hook. Kosten: 30 Minuten. Wirkung: sofort. Kein Credential landet mehr im Repository.
Dependency Scanning aktivieren
NiedrigTrivy oder OWASP Dependency-Check in die bestehende Pipeline einbauen. Ein zusätzlicher Stage, der alle Abhängigkeiten gegen CVE-Datenbanken prüft.
SBOM generieren
NiedrigMit Syft oder CycloneDX bei jedem Build eine Software Bill of Materials erzeugen. Regulatorisch zunehmend gefordert (EU Cyber Resilience Act).
Netzwerk-Segmentierung der Build-Umgebung
MittelJenkins-/GitLab-Server in ein eigenes VLAN. OT-Netzwerk nur über definierte Schnittstellen erreichbar. Kein direkter Zugriff aus dem Build-Netz auf Produktionsanlagen.
Security-Retrospektive einführen
NiedrigEinmal pro Quartal: Was waren unsere Security-Incidents? Welche Schwachstellen wurden gefunden? Was können wir verbessern? Gemeinsam mit IT und OT.
Fazit: Security ist kein Feature — es ist eine Grundlage
Die Zeiten, in denen OT-Systeme durch physische Isolation geschützt waren, sind vorbei. Industrielle Systeme sind vernetzt, angreifbar und zunehmend im Visier von Cyberkriminellen. IEC 62443 liefert den Rahmen, DevSecOps liefert die Methodik — und CI/CD-Pipelines liefern die Automatisierung.
Der Schlüssel ist Shift Left: Security nicht am Ende prüfen, sondern von der ersten Zeile Code an einbauen. Automatisiert, reproduzierbar und nachvollziehbar. Nicht als Bremse, sondern als Qualitätsmerkmal.
Starten Sie mit den Quick Wins, bauen Sie schrittweise auf und machen Sie Security zu einem natürlichen Teil Ihrer Delivery-Pipeline. Ihre Produktion — und Ihre Kunden — werden es Ihnen danken.
Security-Assessment für Ihre OT-Umgebung
Wo stehen Sie in Bezug auf IEC 62443? Unser kostenloser Quick-Scan identifiziert in 90 Minuten die drei größten Sicherheitslücken und die wirksamsten Sofortmaßnahmen.
Bereit für den nächsten Schritt?
Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Erstgespräch buchen