Cyber Resilience Act (CRA) in der Produktentwicklung

Der Cyber Resilience Act (CRA) verpflichtet Hersteller von Produkten mit digitalen Elementen, Cybersecurity bereits bei der Entwicklung und über den gesamten Produktlebenszyklus zu berücksichtigen. Für Entwicklungsabteilungen bedeutet das: Sicherheitsrisiken systematisch bewerten, technische Schutzmaßnahmen in Architektur und Software integrieren und deren Umsetzung nachvollziehbar dokumentieren. Entscheidend ist, wie sich diese regulatorischen Pflichten in bestehende Engineering-Prozesse überführen lassen – von der ersten Risikoanalyse bis zum Schwachstellenmanagement nach der Markteinführung.

Der Cyber Resilience Act stellt konkrete Anforderungen an die Sicherheit von Produkten mit digitalen Elementen. In dieser Weiterbildung erarbeiten Sie anhand eines durchgängigen Praxisbeispiels, wie Sie diese Anforderungen in der Produktentwicklung berücksichtigen. Dabei verbinden Sie regulatorische Vorgaben mit etablierten Methoden des Security Engineering und leiten daraus technische Maßnahmen sowie erforderliche Nachweise ab.

Nach der Weiterbildung können Sie:

• CRA-Anforderungen für eigene Produkte identifizieren und den jeweiligen Entwicklungsaufgaben zuordnen.
• Cybersecurity-Risiken mithilfe von Risk Assessment und Threat Modeling systematisch bewerten.
• Security Requirements und technische Schutzmaßnahmen für Embedded-Systeme ableiten.
• Geeignete Security-Testing-Verfahren zur Überprüfung der Sicherheitsanforderungen auswählen.
• Schwachstellenmanagement, Drittkomponenten und technische Nachweise in bestehende Entwicklungsprozesse integrieren.

Nutzen der Weiterbildung

Die Weiterbildung erhöht die Sicherheit bei technischen Entscheidungen zur CRA-Umsetzung. Ein strukturiertes Vorgehen erleichtert die frühzeitige Berücksichtigung von Sicherheitsanforderungen und reduziert das Risiko kostspieliger Nacharbeiten. Das durchgängige Praxisbeispiel unterstützt den Transfer in eigene Entwicklungsprojekte und verbessert die Nachvollziehbarkeit getroffener Sicherheitsentscheidungen.

Hinweis: Die Seminarunterlagen und Präsentationsfolien sind in englischer Sprache.


Donnerstag, 15. und Freitag, 16. April 2027
jeweils von 9:00 bis 16:30 Uhr, inkl. Pausen

TAG 1

1. Cyber Resilience Act – kurz und bündig

• Geltungsbereich und regulatorische Einordnung (z. B. New Legislative Framework, NLF)
• Betroffene Produkte: Produkte mit digitalen Komponenten
• Zeitachse und Herstellerpflichten
• Lebenszyklusperspektive für Entwickler
• Rollen im Unternehmen aus Engineering-Sicht
• Verbindung und Gemeinsamkeiten mit Functional Safety
• Wichtige Definitionen:
  • Intended Purpose / Reasonably Foreseeable Use / Reasonably Foreseeable Misuse
• Supportperiode
• Einführung des Asset-Begriffs: Was muss geschützt werden?
• Definition der Risikobewertung
• Risikobehandlung identifizierter Risiken
• Übungsbeispiel Teil 1: Beschreibung eines Beispielprodukts mit digitalen Elementen (PDE) als Grundlage für die folgenden Übungen

2. CRA-spezifische Anforderungen für Hersteller

• Was bedeutet der CRA für die konkrete Entwicklungsarbeit?
• Umsetzungsbeispiele der Herstellerpflichten (Artikel 13)
• Berichtspflichten (Artikel 14)
• Praktische Umsetzung der wesentlichen Security-Anforderungen (Anhang I, Teil I)
• Notwendige Prozesse zur Behandlung von Sicherheitslücken (Anhang I, Teil II)
• Übungsbeispiel Teil 2: Umsetzung der Pflichten aus Artikel 13 und 14 am Beispiel-PDE

3. Durchführung eines beispielhaften Risk Assessments

• Definition von Trust Boundaries und Schnittstellen
• Vollständige Betrachtung eines Assets entlang der definierten Vorgehensweise
• Dynamische Architekturansichten
• Bedrohungsmodellierung mit Microsoft STRIDE
• Funktionsbeschreibung
• Ableitung technischer Security Requirements
• Übungsbeispiel Teil 3: Durchführung eines Risk Assessments zur Bestimmung von Security Goals für das Beispiel-PDE
• Ableitung geeigneter Maßnahmen unter Berücksichtigung der wesentlichen Security-Anforderungen
• Diskussion typischer Herausforderungen in der Embedded-Entwicklung
• Abgleich mit dem zweistufigen Risk Assessment nach IEC 62443-3-2 für MVO, Transportation und weitere Bereiche
• Essenzielle Funktionen und Safety-Funktionen: Was passiert bei einem Versagen?
• Übungsbeispiel Teil 4: Auswahl von Cybersecurity Controls und Zuordnung der grundlegenden Security-Anforderungen zum Beispiel-PDE

TAG 2

4. Secure by Design & Default – Architektur

• Wie wird aus Security Principles eine CRA-Anforderung?
• Anwendung von Security-Prinzipien in frühen Architekturphasen
• Bedeutung zentraler CRA-Begriffe, z. B. Secure by Design und Secure by Default
• Architekturentscheidungen: Prinzip ? Architekturentscheidung ? technische Umsetzung
• ENISA Secure by Design and Default Playbook als Umsetzungshilfe für KMU
• Überführung allgemeiner Security-Prinzipien in CRA-Anforderungen und konkrete Engineering Controls:
  • Mapping der Security Principles auf die wesentlichen Anforderungen des Cyber Resilience Act
  • Mapping der Security Principles auf Sicherheitsprinzipien und Controls der NIST-SP-800-Standards
• Übungsbeispiel Teil 5: Bewertung und Einordnung des Mappings von Security Principles auf grundlegende Security-Anforderungen
• Security-Prinzipien weiterer Standards
• Architekturmuster für resiliente Embedded-Systeme
• Update-Fähigkeit und sichere Standardeinstellungen
• Schnittstellenhärtung und Isolation

5. Security Verification & Testing

• Wie lässt sich die Umsetzung von Security Requirements nachweisen?
• Verifikation von Security Requirements
• Code Review
• Static Analysis
• Dependency Scanning
• Vulnerability Scanning
• Fuzzing
• Penetration Testing
• Security Testing in CI/CD-Prozessen
• Regression Testing nach Security Fixes
• Übungsbeispiel Teil 6: Erstellung eines ersten Verifikations- und Validierungsplans für das Beispiel-PDE

6. Prozesse zur Behandlung von Sicherheitslücken und Vorfällen

• Umgang mit neu veröffentlichten CVEs in verwendeten Softwarebibliotheken
• Schwachstellenmanagement über den gesamten Produktlebenszyklus
• Interne Prozesse und Verantwortlichkeiten
• Meldemechanismen und Dokumentationspflichten
• Verzahnung mit Entwicklungs- und Release-Prozessen
• Verbindung zu Unternehmensprozessen und Managementsystemen

7. Integration von Drittkomponenten und Verwendung von Open Source

• Transparenz über tatsächlich verwendete Produktkomponenten
• Umgang mit Third-Party Components
• Sorgfaltspflichten bei der Verwendung von Drittkomponenten und Open-Source-Software
• SBOM-Grundlagen und Komponenten-Inventarisierung
• Integration in CI/CD und Build-Governance
• Übungsbeispiel Teil 7: Erstellung eines Aktionsplans für eine eingekaufte Komponente des Beispiel-PDE

8. Evidences und Nachweise

• Wie lässt sich die Berücksichtigung von Security nachweisen?
• Konkrete Beispiele der erforderlichen Dokumentation:
  • Benutzerdokumentation
  • Technische Dokumentation
• Aufbau eines effizienten internen und externen Monitorings
• Typische Hindernisse und praxisnahe Umsetzungstipps für die eigene Organisation
• Übungsbeispiel Teil 8: Skizze der Benutzerhinweise und technischen Dokumentation für das Beispiel-PDE