Secure Development und Komponenten (IEC 62443-4-1/4-2) als CRA-Nachweisweg für OT-Produkte

Problem in der Praxis

In vielen Produktorganisationen wird Sicherheit spät im Projekt nachgerüstet, am Ende über einen Penetrationstest geprüft und über Termindruck gesteuert. Schwachstellen werden dann gefunden, wenn das Design fixiert ist, und Patch-Fähigkeit, Update-Mechanismen oder ein definiertes Support-Ende waren nie Teil der Spezifikation.

Genau das macht der CRA zum Problem. Er verlangt Sicherheit nicht als punktuellen Test, sondern über den Lebenszyklus: sicheres Design, Umgang mit Lieferkette und Komponentenherkunft (SBOM), strukturierte Schwachstellenbehandlung, Sicherheitsupdates und ein klar kommuniziertes Support-Ende. Erschwerend stehen OT-Komponenten oft jahrzehntelang im Feld, Updates sind nur in Wartungsfenstern möglich, und Verfügbarkeit und Safety haben Vorrang. Sicherheit muss daher eingebaut sein, nicht später aufgesetzt.

CISO-Einordnung

Die 62443-Serie ordnet Pflichten über Rollen zu. Der Product Supplier (Hersteller) verantwortet die Produktteile 4-1 und 4-2, der System Integrator plant und integriert, der Asset Owner betreibt. Diese Rollentrennung zeigt dem CISO, wofür die eigene Organisation als Lieferant geradesteht und was nachgelagerte Rollen verantworten.

Inhaltlich gilt vereinfacht: 4-1 ist der Prozess, 4-2 das Produkt. 4-1 umfasst unter anderem Bedrohungsmodellierung, sichere Implementierung, Verifikation sowie Schwachstellen- und Patch-Management bis zum End-of-Life. 4-2 leitet technische Anforderungen je Komponententyp ab - typischerweise eingebettete Geräte, Host-Geräte, Netzkomponenten und Softwareanwendungen.

Verbindendes Konzept ist der Security Level (SL 1-4): gestufte Schutzziele nach unterstellter Angreiferfähigkeit, vom zufälligen Fehlverhalten bis zum Angreifer mit erheblichen Ressourcen. Die Norm unterscheidet angestrebten (Target-SL), erreichten (Achieved-SL) und vom Produkt leistbaren Level (Capability-SL); die technischen Anforderungen sind über sieben grundlegende Anforderungsfamilien (Foundational Requirements) strukturiert, etwa Identifikation/Authentisierung oder Systemintegrität. Für das Management reicht: Ein höherer SL bedeutet mehr Anforderungen, Aufwand und Nachweise - er ist eine Entscheidung, kein Defaultwert.

Der CRA-Bezug ist der eigentliche Hebel: 4-1/4-2 gelten als der technische Weg, Produkt- und Komponentensicherheit gegenüber dem CRA darzustellen. Harmonisierte europäische Normen (hEN) auf 62443-Basis sind in Erarbeitung; eine formale Vermutungswirkung (presumption of conformity) entsteht aber erst mit der Listung im EU-Amtsblatt. Status und Termine sind derzeit offen und vor jeder Berufung darauf zu prüfen.

Umsetzungsperspektive

Sinnvoll ist die Reihenfolge Prozess vor Produkt. Zuerst wird der Entwicklungslebenszyklus nach 4-1 etabliert: Verantwortlichkeiten, Bedrohungsmodellierung als fester Schritt, sichere Coding- und Build-Praktiken, Verifikation und vor allem ein belastbarer Prozess für Schwachstellenmeldungen und Updates. Dieser Prozess wirkt produktübergreifend und ist die Basis aller späteren Nachweise.

Darauf setzt die produktbezogene Arbeit nach 4-2 auf. Pro Produkt wird ein Ziel-SL festgelegt - abgeleitet aus Einsatzkontext, Schutzzielen des Betreibers und der Zonen-Architektur, in der die Komponente später stehen wird. Aus dem Ziel-SL ergeben sich die technischen Anforderungen, gegen die entwickelt und getestet wird.

Der dritte Strang ist die Nachweiskette. CRA wie 62443 leben von Belegen: Bedrohungsmodelle, Testberichte, SBOM, Schwachstellen-Historie, Update-Nachweise. Diese Artefakte sollten als Nebenprodukt des Prozesses entstehen, nicht kurz vor einem Audit rekonstruiert werden. Das frei nutzbare BSI ICS-Security-Kompendium (Version 2.0.0) liefert dafür eine OT-Begriffs- und Best-Practice-Basis mit Brücke zum IT-Grundschutz.

Typische Fehler

1. 4-1 und 4-2 werden gleichgesetzt - der Prozessnachweis wird mit Produktsicherheit verwechselt.
2. Der Ziel-SL wird ohne Einsatzkontext und Abstimmung mit Integrator und Betreiber gesetzt, oft pauschal zu hoch.
3. Schwachstellen- und Update-Management werden als Support-Thema statt als Entwicklungspflicht behandelt.
4. SBOM und Lieferkettenbetrachtung fehlen, obwohl der CRA sie faktisch voraussetzt.
5. Man verlässt sich auf eine noch nicht harmonisierte hEN-Vermutungswirkung, als wäre sie wirksam.
6. End-of-Support wird nie definiert, sodass Pflichten über den Lebenszyklus unklar bleiben.

Risiken und Trade-offs

Ein zu hoch gewählter Security Level treibt Entwicklungs- und Verifikationsaufwand, ohne den realen Einsatzkontext zu treffen; ein zu niedriger gefährdet Marktfähigkeit und CRA-Eignung. Zwischen Zertifizierbarkeit und echter Sicherheit besteht ein Spannungsfeld: Eine 4-1-Bestätigung belegt Prozessreife, garantiert aber kein fehlerfreies Produkt.

Ein zeitlicher Trade-off betrifft die Harmonisierung: Wer Produktentscheidungen fest an eine noch nicht im EU-Amtsblatt gelistete hEN bindet, geht ein Planungsrisiko ein - Abwarten kostet umgekehrt Marktzeit. Hilfreich ist, auf den stabilen 62443-Konzepten aufzubauen und die formale Harmonisierung als späteren, separat zu bestätigenden Schritt einzuplanen. Zu beachten ist zudem die Lizenzlage: Die kostenpflichtigen IEC-62443-Texte gehören in die lizenzierten Originale, nicht in interne Wikis oder Marketingmaterial.

Entscheidungspunkte

• Welche unserer Produkte fallen unter den CRA, und welche Rolle (Product Supplier) nehmen wir je Produkt ein?
• Etablieren wir zuerst einen produktübergreifenden 4-1-Prozess oder optimieren wir einzelne Produkte nach 4-2?
• Welcher Ziel-SL ist je Produkt aus Einsatzkontext und Betreiberanforderungen begründbar?
• Streben wir eine formale 4-1/4-2-Bestätigung an oder zunächst nur eine interne Konformität als Nachweisgrundlage?
• Wie und wann definieren wir End-of-Support und die zugehörigen Update-Verpflichtungen?

Praktische Empfehlungen

1. Trennen Sie in der Kommunikation klar Prozess (4-1) und Produkt (4-2) - das verhindert die häufigste Fehlannahme im Management.
2. Bauen Sie den Schwachstellen- und Update-Prozess zuerst; er hat die höchste CRA-Relevanz und wirkt produktübergreifend.
3. Leiten Sie den Ziel-SL aus dem realen Einsatzkontext ab und stimmen Sie ihn mit Integratoren und Betreibern ab.
4. Erzeugen Sie Nachweise (Bedrohungsmodell, Tests, SBOM, Update-Historie) als Nebenprodukt des Prozesses.
5. Behandeln Sie die CRA-Harmonisierung als Roadmap-Punkt mit Prüfstatus, nicht als gesicherte Vermutungswirkung.
6. Nutzen Sie das frei verfügbare BSI ICS-Security-Kompendium als interne Begriffs- und Best-Practice-Basis.

Relevante Normreferenzen

• IEC 62443-4-1 (Secure product development lifecycle requirements) und -4-2 (Technical security requirements for IACS components): Referenz für Entwicklungsprozess bzw. Komponentenanforderungen. Kostenpflichtig, nur Konzeptebene; Ausgaben teils in Revision - Versionsstand vor verbindlicher Nutzung prüfen.
• IEC 62443-3-3 / -3-2: Referenz für Security Levels sowie Zones & Conduits (Kontext der SL-Ableitung).
• BSI ICS-Security-Kompendium (Version 2.0.0): frei nutzbares deutschsprachiges Grundlagenwerk, Brücke zum IT-Grundschutz.
• ISO/IEC 27001: Referenz für das ISMS-Dach (OT-Spezifika nicht vollständig abgedeckt). NIST SP 800-82: ergänzende OT-Leitlinie.
• Cyber Resilience Act (CRA) und NIS2: EU-Rechtsrahmen, der das Wozu vorgibt; 62443 liefert das Wie für OT-Produkte.