Cyber Resilience Act und dauerhaftes Betriebsmodell

Cyber Resilience Act und Betriebsmodell

0:00 Wir sind beim letzten Modul, und hier entscheidet sich, was von diesen drei Tagen übrig bleibt. Aus fünfzehn Modulen werden entweder fünfzehn Einzelmaßnahmen, von denen in einem halben Jahr fünf noch laufen — oder ein Programm, das sich selbst trägt. Dazu kommt der regulatorische Rahmen, der in Europa ohnehin auf Sie zukommt.

0:18 Und der ist, das ist die gute Nachricht dieses Moduls, keine zusätzliche Arbeit: Er fragt im Wesentlichen nach dem, was wir in den letzten drei Tagen gebaut haben.

Cyber Resilience Act und dauerhaftes Betriebsmodell

0:28 Drei Schritte zum Abschluss. Zuerst die technische Einordnung der CRA-Pflichten — ohne Rechtsberatung, aber mit den Punkten, die den Entwicklungsprozess betreffen. Dann das Betriebsmodell: Verantwortungsmatrix, Ausnahmen, Kennzahlen. Und zum Schluss zwei neue Entwicklungen, die in beide Richtungen wirken — KI-generierter Code auf der einen Seite, die Fragen der Käufer auf der anderen.

0:51 Danach bauen wir das Nachweispaket und die Roadmap.

Technische Einordnung der CRA-Pflichten

0:55 Beginnen wir mit dem Anwendungsbereich. Die erste Reaktion vieler Teams lautet: Das betrifft uns nicht, wir bauen ja kein Gerät. Schauen wir uns die Definition genau an — sie ist deutlich weiter gefasst, als der Begriff „Produkt" vermuten lässt. Ein Produkt mit digitalen Elementen ist ein Software- oder Hardwareprodukt samt zugehöriger Fernverarbeitungslösungen, einschließlich getrennt in Verkehr gebrachter Komponenten.

1:20 Die Verordnung greift, wenn die bestimmungsgemäße oder vorhersehbare Nutzung eine direkte oder mittelbare logische oder physische Datenverbindung zu einem Gerät oder Netz umfasst. Lesen Sie das noch einmal im Hinblick auf Ihre eigene Software: Eine Anwendung, die auf dem europäischen Markt bereitgestellt wird und mit irgendetwas kommuniziert, ist damit erfasst.

1:39 Ausgenommen ist, was nicht kommerziell bereitgestellt wird oder unter andere Regelungen fällt. Vier Daten. In Kraft getreten ist die Verordnung im Dezember zweitausendvierundzwanzig. Im Juni dieses Jahres wurde das Kapitel zu den notifizierten Stellen anwendbar. Seit dem elften September — also seit dieser Woche — gelten die Meldepflichten, über die wir im letzten Modul gesprochen haben.

2:02 Und im Dezember zweitausendsiebenundzwanzig folgt die vollständige Anwendung. Das ist die Frist für die Produktpflichten, und gut fünfzehn Monate klingen komfortabel. Für Konformitätsbewertung und technische Dokumentation sind sie es nicht. Die Fußzeile bleibt wichtig: Das ist technische Orientierung, keine Rechtsberatung.

2:22 Vier Pflichten, und jede hat ein Gegenstück in diesem Seminar. Eine Risikobewertung begleitet Planung, Entwurf, Entwicklung, Herstellung, Lieferung und Wartung — das ist unser Bedrohungsmodell aus Modul zwei, fortgeschrieben. Die Anforderungen verlangen Sicherheit durch Gestaltung im Produkt selbst. Der Hersteller legt einen Supportzeitraum fest, in dem Schwachstellen wirksam behandelt werden — beachten Sie, dass die Länge Ihre Entscheidung ist, sie muss nur klar und verständlich beim Kauf angegeben sein.

2:51 Und die technische Dokumentation hält Risikobewertung und umgesetzte Maßnahmen fest. Vier Quadranten, und sie sind der Grund, warum ich dieses Modul ans Ende gestellt habe statt an den Anfang. Die Risikobewertung haben Sie in Modul zwei gebaut. Die umgesetzten Maßnahmen in den Modulen vier bis sieben. Den Bestandsnachweis in Modul neun und zehn. Den Herkunftsnachweis in Modul zwölf und dreizehn.

3:15 Sie haben also nicht drei Tage lang Technik gelernt und müssen jetzt zusätzlich Compliance bauen. Sie haben die Substanz gebaut, nach der gefragt wird — was fehlt, ist die Ordnung, in der man sie vorlegen kann. Der erste Punkt ist derjenige, den man am billigsten beheben kann: Der Supportzeitraum wird nicht festgelegt und ist beim Kauf nicht erkennbar.

3:37 Das ist eine Entscheidung und eine Zeile in der Produktbeschreibung. Der zweite widerspricht dem Wortlaut — die Risikobewertung entsteht zum Abschluss, obwohl sie den ganzen Zyklus begleiten soll. Der dritte ist ein Dokumentationsfehler: Beschrieben wird das Produkt, nicht die umgesetzten Maßnahmen. Und der vierte ist der organisatorische Klassiker — die Zuständigkeit liegt bei niemandem, weil es als Rechtsthema gilt und die Rechtsabteilung es als Technikthema sieht.

Ein belastbares Programm statt Einzelmaßnahmen

4:04 Im zweiten Kapitel geht es um die Frage, wie aus dem, was Sie gebaut haben, etwas Dauerhaftes wird. Und der Unterschied zu einem Projektplan ist fundamental: Ein Betriebsmodell hat kein Ende. Es beschreibt nicht, was getan wird, sondern wer es dauerhaft trägt. Ein Betriebsmodell hält drei Dinge fest: wer welche Maßnahme dauerhaft trägt, wie Ausnahmen entstehen und enden, und woran der Fortschritt gemessen wird.

4:28 Der mittlere Punkt ist der, der am häufigsten fehlt — und er ist der wichtigste. Denn Maßnahmen scheitern selten daran, dass sie falsch waren. Sie scheitern daran, dass es keinen geordneten Weg gab, in einem Einzelfall davon abzuweichen — und dann weicht man ungeordnet ab. Das ist der Unterschied zwischen einer Regel mit Ventil und einer Regel, die irgendwann still ignoriert wird.

4:50 Vier Kennzahlen, und die dritte Spalte macht sie erst nützlich. Der Anteil signierter Artefakte reagiert auf Lücken in der Pipeline. Der Anteil verifizierter Deployments zeigt Umgehungswege — das ist die Kennzahl, die aufdeckt, wenn jemand an der Regel vorbei ausrollt. Das Alter der ältesten Ausnahme misst den Verfall der Disziplin und ist eine meiner Lieblingskennzahlen, weil sie so unbestechlich ist.

5:14 Und die Zeit von Meldung bis Behebung zeigt Engpässe im Ablauf. Die Fußzeile: Eine Kennzahl ohne benannte Reaktion ist Dekoration. Fünf Regeln für den Umgang mit Ausnahmen. Jede trägt Frist, Begründung und verantwortliche Person — das kennen Sie aus Modul sechs. Ausnahmen entstehen an einer Stelle, nicht im jeweiligen Werkzeug; sonst gibt es keine Übersicht.

5:36 Ab einer Schwelle entscheidet die Leitung, nicht das Team — das schützt übrigens auch das Team. Abgelaufene Ausnahmen werden sichtbar statt stillschweigend verlängert. Und die Liste wird regelmäßig durchgesehen und gekürzt. Die Fußzeile nennt die Bedingung dafür: ein fester Termin, sonst findet die Durchsicht nach dem zweiten Monat nicht mehr statt.

5:58 Wir kommen auf die Rolle aus Modul drei zurück, jetzt mit konkreter Funktion. Security Champions sind die Stelle, an der Fragen gestellt werden, bevor eine Eskalation nötig wird — sie halten den Ablauf niedrigschwellig. Der zweite Punkt ist die Bedingung, ohne die es nicht funktioniert: Sie brauchen Zeit im Plan, sonst bleibt die Rolle ein Titel.

6:17 Der dritte macht Entscheidungen sichtbar: Die Verantwortungsmatrix hält fest, wer entscheidet und wer nur beteiligt ist. Und der vierte ist der, an dem im Ernstfall alles hängt — ohne benannte Leitungsentscheidung ist Risikoakzeptanz eine ungedeckte Unterschrift. Der erste Punkt ist die häufigste Schwäche von Roadmaps in diesem Feld: Sie bestehen aus Werkzeugen statt aus Wirkungen.

6:40 „Werkzeug X einführen" ist kein Ziel, „jedes ausgelieferte Image trägt eine verifizierbare Herkunft" schon. Der zweite ist die Kennzahl ohne Reaktion. Der dritte ist die verstreute Ausnahmeverwaltung — sie lebt in den Werkzeugen und taucht in keiner Übersicht auf. Und der vierte ist der stille Tod des Betriebsmodells: Es wird beschlossen und keiner Rolle dauerhaft zugeordnet, und dann trägt es im Alltag niemand.

Neue Quellen im Entwicklungsalltag

7:05 Im dritten Kapitel schauen wir nach vorn — auf zwei Entwicklungen, die in entgegengesetzte Richtungen wirken. Auf der einen Seite kommt neuer Code aus einer Quelle, die es vor wenigen Jahren nicht gab. Auf der anderen stellen Ihre Kunden Fragen, die sie früher nicht gestellt haben. Codevorschläge und automatisch vorgeschlagene Abhängigkeiten sind eine neue Eingangsquelle in die Lieferkette.

7:27 Und sie durchlaufen dieselben Vertrauensgrenzen wie jeder andere fremde Beitrag — nur ohne Herausgeber, ohne Versionsnummer und ohne Reputation, an der sich etwas festmachen ließe. Das ist der entscheidende Unterschied zu einer Bibliothek: Bei der können Sie nachsehen, wer sie pflegt und wie sie bewertet wird. Bei einem Vorschlag gibt es nichts nachzusehen.

7:47 Er ist plausibel oder nicht, und Plausibilität ist kein Herkunftsnachweis. Der erste Punkt ist der konkreteste: Eine vorgeschlagene Bibliothek existiert womöglich gar nicht — und wenn jemand diesen Namen dann anlegt, haben Sie eine Verwechslung, die Sie sich selbst gebaut haben. Das ist Dependency Confusion mit umgekehrten Vorzeichen. Der zweite Punkt: Ein Vorschlag kennt weder Wartungszustand noch Lizenzlage.

8:11 Der dritte ist die beruhigende Nachricht — die Prüfung bleibt dieselbe wie in Modul fünf: Namensraum, Quelle, Wartung, Bewertung. Und der vierte: Das Vier-Augen-Prinzip gilt für vorgeschlagenen Code wie für geschriebenen, vielleicht sogar etwas mehr. Jetzt die Gegenrichtung, und die kommt aus dem Beschaffungswesen. Käufer verlangen zunehmend eine maschinenlesbare Stückliste aller Fremdkomponenten — das haben wir gebaut.

8:37 Sie fragen, wie quelloffene Bestandteile geprüft werden und wer das verantwortet — Modul fünf und drei. Sie fragen nach einer veröffentlichten Richtlinie zur Schwachstellenmeldung — Modul fünfzehn. Und sie fragen nach einer Roadmap, welche Schwachstellenklassen bereits beseitigt wurden. Vier Fragen, vier Antworten, die Sie nach diesen drei Tagen geben können.

8:57 Das ist übrigens ein Vertriebsargument, nicht nur eine Pflicht. Jetzt bringen wir alles zusammen: Bedrohungsmodell, Befunde, Stückliste, Provenance, Signaturen, Entscheidungen und offene Maßnahmen — jeweils mit Datum und Verantwortlicher. Der Hinweis nennt einen schönen Selbsttest: Ließe sich damit eine Kundenanfrage beantworten, ohne etwas nachzubauen?

9:19 Wenn Sie bei dieser Frage zögern, fehlt meist eines von zwei Dingen — entweder ein Datum, sodass unklar ist, worauf sich das Paket bezieht, oder ein Ansprechpartner, sodass die Rückfrage ins Leere läuft. Der erste Punkt ist der aus dem dritten Kapitel: Vorgeschlagene Abhängigkeiten werden übernommen, ohne die Existenz zu prüfen.

9:39 Der zweite beschreibt das typische Schicksal solcher Pakete — sie entstehen anlassbezogen und veralten zwischen zwei Anfragen; daher die Empfehlung, das Zusammenstellen zu automatisieren, soweit es geht. Der dritte ist ein Perspektivfehler: Die Nachweise liegen verteilt in Werkzeugen, die ein Außenstehender nicht sieht.

9:56 Und der vierte ist der kleine Fehler mit der größten Wirkung — es fehlt das Datum, und niemand kann sagen, auf welchen Stand sich das Paket bezieht.

Übung

10:05 In der letzten Übung machen Sie aus allem, was liegen geblieben ist, eine Roadmap. Vier Quartale, je Maßnahme eine Rolle, und drei Kennzahlen. Nicht mehr — und das ist ausdrücklich eine Beschränkung, keine Sparsamkeit. Eine Roadmap, die zwanzig Maßnahmen gleichzeitig verfolgt, verfolgt in Wahrheit keine. Der Wert entsteht durch das, was Sie bewusst nach hinten schieben, und dafür brauchen Sie die Reihenfolge aus dem Bedrohungsmodell.

10:32 Zwei Ergebnisse: das vollständige Nachweispaket und die Roadmap mit Rolle und Kennzahl je Maßnahme. Der Hinweis ist ernst gemeint: Drei Kennzahlen genügen. Mehr werden erhoben, aber nicht mehr gelesen — und eine nicht gelesene Kennzahl ist schlechter als keine, weil sie Aufwand erzeugt und Sicherheit vortäuscht. Wählen Sie die drei aus der Tabelle von vorhin, die zu Ihren größten Lücken passen. In einem Jahr können Sie immer noch nachschärfen, wenn diese drei sauber laufen.

11:00 Die Ergebnisse aller Module einsammeln und datieren. Die offenen Maßnahmen aus den Modulen fünf, sechs, dreizehn und fünfzehn zusammenführen — das sind die vier, die typischerweise etwas offenlassen. Nach Wirkung gegen das Bedrohungsmodell ordnen. Auf vier Quartale verteilen, je Maßnahme eine Rolle. Und drei Kennzahlen festlegen samt Reaktion.

11:21 Die Fußzeile schließt den Bogen dieser drei Tage: Die Reihenfolge stammt weiterhin aus Modul zwei. Das Bedrohungsmodell, das Sie am ersten Vormittag geschrieben haben, hat durchgehend getragen. Der erste Punkt ist die Roadmap, die alles enthält und deshalb nichts ordnet — Vollständigkeit ist hier kein Qualitätsmerkmal. Der zweite ist die Maßnahme ohne Rolle, die im ersten Quartal verschoben wird und danach jedes Mal.

11:46 Der dritte ist die Kennzahl, die Aktivität misst statt Wirkung: Die Zahl durchgeführter Scans sagt nichts, der Anteil verifizierter Deployments schon. Und der vierte ist der stille Verfall des Nachweispakets — es wird abgelegt und nie wieder aktualisiert. Setzen Sie dafür einen Termin, so wie für die Durchsicht der Ausnahmen.

Danke!

12:05 Damit sind wir am Ende. Wenn Sie vier Sätze aus diesen drei Tagen mitnehmen, dann diese. Die Lieferkette ist so stark wie ihre schwächste Übergabe — und die liegt fast nie dort, wo man zuerst sucht. Bedrohungsmodell, Stückliste, Provenance und Signatur gehören zusammen; einzeln ist jedes davon nur ein Dokument. Nachweise entstehen im Ablauf, nicht auf Nachfrage — alles andere ist Rekonstruktion unter Zeitdruck. Und der wichtigste: Beginnen Sie mit der Bedrohung, nicht mit dem Werkzeug.

12:35 Vielen Dank für Ihre Aufmerksamkeit und die Diskussionen.