Seminar keySTREAM – Compliance mit dem Cyber Resilience Act

Übertragung regulatorischer Sicherheitsanforderungen auf Geräteidentität, Zugriffe, Updates, Schwachstellenprozesse und Nachweisführung.

Die Inhalte verbinden Architekturentscheidungen, nachvollziehbare Konfiguration und praktische Übungen. Jeder Arbeitsschritt wird zunächst an einer Referenzumgebung vorbereitet, anschließend kontrolliert ausgeführt und zuletzt mit einem Soll-Ist-Vergleich geprüft.

Inhaltsübersicht

1. Cyber Resilience Act: Produktumfang und Verantwortlichkeiten
2. Plattformauftrag und Sicherheitsziele
3. Lebenszyklus von der Integration bis zur Außerbetriebnahme
4. Technische CRA-Kontrollen über den Gerätelebenszyklus
5. Eindeutige Geräteidentitäten und Vertrauensbeziehungen
6. Architektur für sichere Firmware-Updates
7. Security Telemetry und belastbare Betriebsdaten
8. Nachweisführung, Schwachstellenprozess und technische Dokumentation

Zielsetzung

Nach dem Seminar können Produktumfang und Verantwortlichkeiten strukturiert erfasst, technische Kontrollen zugeordnet und belastbare Nachweise aus Plattform- und Betriebsdaten aufgebaut werden.

Zielgruppe

Produktverantwortliche, Security- und Compliance-Teams, technische Leiter, Architekten, Qualitätsmanagement und Betreiber vernetzter Produkte.

Voraussetzungen

Kenntnisse des eigenen Produktlebenszyklus und der internen Entwicklungs- oder Betriebsprozesse; juristische Vorkenntnisse sind nicht erforderlich.

Seminarinhalte

1. Cyber Resilience Act: Produktumfang und Verantwortlichkeiten

Regulatorische Anforderungen werden auf Produkt, Softwarebestand, Betreiberprozesse und Lieferkette abgebildet.

1. Schritt 1: Produktvarianten, digitale Elemente, Komponenten, Rollen und wirtschaftliche Akteure erfassen.
2. Schritt 2: Sicherheitsrelevante Funktionen und Abhängigkeiten über Entwicklung, Fertigung und Betrieb zuordnen.
3. Schritt 3: Verantwortlichkeiten für Schwachstellen, Updates, Meldungen und technische Unterlagen festlegen.
4. Schritt 4: Lücken zwischen vorhandenem Betriebsmodell und erforderlichen Nachweisen priorisieren.

2. Plattformauftrag und Sicherheitsziele

Zu Beginn wird der fachliche Auftrag in überprüfbare Sicherheits- und Betriebsziele übersetzt.

1. Schritt 1: Geschäftsprozess, Gerätetypen, Kommunikationswege und Schutzbedarf vollständig erfassen.
2. Schritt 2: Vertrauensgrenzen zwischen Fertigung, Gerät, Plattform, Cloud-Dienst und Betreiber kennzeichnen.
3. Schritt 3: Sicherheitsziele für Identität, Integrität, Vertraulichkeit, Autorisierung und Aktualisierbarkeit priorisieren.
4. Schritt 4: Messbare Abnahmekriterien sowie Zuständigkeiten für Einführung und Regelbetrieb festlegen.

3. Lebenszyklus von der Integration bis zur Außerbetriebnahme

Alle Sicherheitsfunktionen werden in einen durchgängigen Geräte- und Berechtigungslebenszyklus eingeordnet.

1. Schritt 1: Phasen für Integration, Produktion, Aktivierung, Verbindung, Betrieb, Aktualisierung, Eigentumswechsel und Stilllegung definieren.
2. Schritt 2: Je Phase erforderliche Identitäten, Schlüssel, Zertifikate, Richtlinien und Nachweise zuordnen.
3. Schritt 3: Statuswechsel, Ausnahmen und zulässige Rücksprünge als kontrolliertes Zustandsmodell beschreiben.
4. Schritt 4: Übergaben zwischen Entwicklung, Fertigung, Betreiber, Service und Endkunde mit eindeutigen Verantwortlichkeiten absichern.

4. Technische CRA-Kontrollen über den Gerätelebenszyklus

Identität, Zugriff, Integrität, sichere Updates und Schwachstellenbehandlung werden zu einem durchgängigen Kontrollsystem verbunden.

1. Schritt 1: Sichere Standardkonfiguration, minimale Berechtigung und eindeutige Geräteidentität als Basiskontrollen festlegen.
2. Schritt 2: Integritätsprüfung, Telemetrie, Attestierung und Ereignisreaktion an dokumentierte Risiken koppeln.
3. Schritt 3: Update-, Rotation-, Sperr- und Außerbetriebnahmeverfahren für die Unterstützungsdauer nachweisen.
4. Schritt 4: Kontrollen mit Negativtests und repräsentativen Störungsfällen auf Wirksamkeit prüfen.

5. Eindeutige Geräteidentitäten und Vertrauensbeziehungen

Eine eindeutige, nicht beliebig kopierbare Identität bildet den Ausgangspunkt für jede sichere Gerätekommunikation.

1. Schritt 1: Identitätsarten für Gerät, Produkt, Mandant, Anwendung und Betreiber voneinander abgrenzen.
2. Schritt 2: Eindeutigkeit, Herkunft und Bindung einer Geräteidentität an den Vertrauensanker überprüfen.
3. Schritt 3: Identität mit Geräteprofil, Eigentümer, Betriebsstatus und zulässigen Diensten verknüpfen.
4. Schritt 4: Duplikate, ungültige Zuordnungen und kompromittierte Identitäten erkennen und kontrolliert behandeln.

6. Architektur für sichere Firmware-Updates

Ein Updatepfad wird als Sicherheitsfunktion geplant und über die gesamte Produktlebensdauer erhalten.

1. Schritt 1: Firmwareformat, Bootkette, Speicherlayout, Updatequelle und Vertrauensanker erfassen.
2. Schritt 2: Authentizität, Integrität, Versionsprüfung und Schutz vor unzulässigem Downgrade definieren.
3. Schritt 3: Unterbrechung, unvollständige Übertragung und nicht startfähige Firmware mit sicheren Zuständen behandeln.
4. Schritt 4: Updatefähigkeit bereits in Hardwareauswahl, Speicherplanung und Produktionsfreigabe nachweisen.

7. Security Telemetry und belastbare Betriebsdaten

Telemetry wird auf sicherheitsrelevante und betrieblich verwertbare Signale begrenzt und eindeutig kontextualisiert.

1. Schritt 1: Benötigte Zustands-, Versions-, Fehler- und Sicherheitssignale je Geräteklasse festlegen.
2. Schritt 2: Signalquelle, Zeitbezug, Geräteidentität und Integrität der Meldung absichern.
3. Schritt 3: Normalwerte, Warnschwellen und kritische Ereignisse anhand realistischer Betriebsdaten definieren.
4. Schritt 4: Meldungen in priorisierte Arbeitsaufträge, Eskalationen und Nachweise überführen.

8. Nachweisführung, Schwachstellenprozess und technische Dokumentation

Technische Maßnahmen werden mit Entscheidungen, Prüfungen und Betriebsdaten zu belastbaren Nachweisen verbunden.

1. Schritt 1: Produkt- und Softwareinventar, Architekturentscheidungen und Sicherheitsanforderungen versioniert zusammenführen.
2. Schritt 2: Meldung, Bewertung, Priorisierung und Behebung von Schwachstellen als messbaren Prozess definieren.
3. Schritt 3: Update- und Incident-Nachweise mit betroffenen Versionen, Geräten und Fristen verknüpfen.
4. Schritt 4: Dokumentation regelmäßig gegen reale Konfiguration und tatsächliche Betriebsabläufe abgleichen.

Praxisübungen

• Produktumfang, Akteure und technische Abhängigkeiten eines Beispielprodukts abgrenzen.
• Anforderungen in konkrete Identitäts-, Zugriffs-, Update- und Betriebsmaßnahmen übersetzen.
• Schwachstellen- und Updateprozess mit Rollen, Fristen und Nachweisen modellieren.
• Nachweismatrix aus Architektur, Konfiguration, Test und Betriebsdaten erstellen.
• Lücken priorisieren und einen realistischen Umsetzungsplan formulieren.