Das 24-Stunden-Meldefenster des CRA ist ein Problem der Datenintegration

Um 9 Uhr morgens erscheint ein Eintrag in der KEV-Liste. Gemäß den Meldepflichten des Cyber Resilience Act (CRA), die ab dem 11. September 2026 gelten, müssen Hersteller von Produkten mit digitalen Elementen eine frühzeitige Warnmeldung an die zuständige Behörde übermitteln, wenn eine Schwachstelle aktiv ausgenutzt wird oder ein schwerwiegender Sicherheitsvorfall vorliegt. Für diese erste Meldung gilt eine Frist von 24 Stunden ab dem Zeitpunkt, zu dem der Hersteller Kenntnis von dem Sachverhalt erlangt. Wie CSO Online am 2. Oktober berichtete, erwarten Fachleute aus der Praxis, dass die Verordnung die manuelle Triage von Schwachstellen grundlegend verändern wird.

Die meisten Leser werden dies zunächst als Urteil über die eingesetzten Tools verstehen. Tatsächlich geht es jedoch vielmehr darum, ob eine Organisation definiert hat, was „aktiv ausgenutzt“ für ein bestimmtes Produkt bedeutet und wo die dafür erforderlichen Nachweise zu finden sind. Genau darin liegt der Unterschied zwischen dem CRA als bloßem Compliance-Dokument und seiner Umsetzung als technische und organisatorische Veränderung.

Die Nachweise liegen in unterschiedlichen Systemen

Für die fristgerechte Meldung müssen Informationen aus mehreren Systemen zusammengeführt werden, die ursprünglich nicht dafür ausgelegt waren, eine gemeinsame Frage zu beantworten: ein Eintrag in der KEV-Liste, Ergebnisse von Schwachstellenscans, Telemetriedaten aus dem SIEM, das Asset-Inventar und eine Software Bill of Materials (SBOM). CSO Online zitiert Joe Brinkley von Cobalt, der darauf hinweist, dass von einem Analysten nicht erwartet werden kann, eine KEV-Warnung zu erkennen, manuell eine statische SBOM zu durchsuchen und anschließend SIEM-Protokolle auszuwerten, um festzustellen, ob ein System tatsächlich aktiv angegriffen wird.

Louise Horton von der NCC Group betrachtet dieselbe Herausforderung aus der Governance-Perspektive. Ihrer Einschätzung nach hängt der Erfolg von ausgereiften Prozessen für das Schwachstellenmanagement, einer umfassenden Transparenz über Produkte und deren Abhängigkeiten sowie der Fähigkeit ab, Probleme schnell und präzise zu identifizieren, zu bewerten und zu melden. Eine entscheidende Frage bleibt jedoch häufig unbeantwortet: Wer ist befugt, diese Entscheidungen rechtzeitig zu treffen?

In einem Unternehmen, in dem ein einziges Sicherheitsteam sowohl für die Produktlandschaft als auch für das Unternehmensnetzwerk verantwortlich ist, liegt das Problem nicht unbedingt darin, dass geeignete Tools fehlen. Vielmehr kann es sein, dass die Person, die sich mit der SBOM auskennt, gerade in eine Eskalation mit einem Kunden eingebunden ist, während sonst niemand genau weiß, welche Komponente auf welchem Server läuft. Die 24-Stunden-Frist lässt keine Zeit, bis zur nächsten Statusbesprechung zu warten. Trifft die Warnmeldung um 9 Uhr ein, kann es sein, dass ausgerechnet der diensthabende Ingenieur reagieren muss, der die betreffende Komponente entwickelt hat. Das ist ein Vorteil, wenn die erforderlichen Nachweise leicht zugänglich sind. Es wird jedoch zum Risiko, wenn das notwendige Wissen ausschließlich in seinem Kopf vorhanden ist.

Die Anforderungen gelten für Produkte, die auf dem EU-Markt in Verkehr gebracht werden – unabhängig davon, wo der Hersteller seinen Sitz hat. Auch ein Produktteam außerhalb der EU, das an europäische Kunden liefert, muss dieselben Fristen berücksichtigen. Das ist besonders relevant in Regionen, in denen der CRA noch vorwiegend als europäische Compliance-Anforderung und nicht als operative Herausforderung betrachtet wird.

Triage-Regeln vor der Integration festlegen

Automatisierung ist das angestrebte Ziel. Workflow-Tools können einen Prozess jedoch nur dann beschleunigen, wenn die Schwellenwerte und Entscheidungspunkte zuvor dokumentiert wurden. Der erste Schritt ist einfacher, als viele Teams vermuten: Auf einer einzigen Seite sollte festgehalten werden, was in der eigenen Umgebung als aktive Ausnutzung gilt, welche Rolle die einzelnen Informationsquellen bestätigen darf und wie viel Zeit für jede Bestätigung zur Verfügung steht. Anschließend wird jede Bedingung dem konkreten System zugeordnet, das die dafür benötigten Nachweise enthält.

Erst durch diese Zuordnung wird die SBOM zu einer „lebendigen Datenstruktur“, wie Brinkley es beschreibt. Ein Compliance-Export, der nur einmal pro Quartal aktualisiert wird, kann keine dringende Anfrage um 22 Uhr beantworten. Die SBOM muss sich direkt aus der Alarmierungspipeline abfragen lassen, die KEV-Einträge verarbeitet. Das Asset-Inventar sollte außerdem nicht nur den Servernamen liefern, sondern auch den Produktverantwortlichen oder die Build-Nummer identifizieren.

Auch eine Warnmeldung, die an einem Freitagnachmittag um 16 Uhr eingeht, setzt die 24-Stunden-Frist in Gang, sobald der Hersteller Kenntnis von dem relevanten Sachverhalt erlangt. Bei Teams ohne rund um die Uhr besetzte Security Operations kann sich die Bearbeitung dadurch bis in den Abend oder ins Wochenende erstrecken. Der Prozess muss deshalb auch von einem diensthabenden Ingenieur ausgeführt werden können, der die Zuordnung der Komponenten nicht auswendig kennt. Die Dokumentation muss das Wissen bereitstellen, das andernfalls nur bei einzelnen Mitarbeitenden vorhanden wäre. Ein Dashboard allein kann dieses Problem nicht lösen.

An diesem Punkt wird aus einer regulatorischen Vorgabe ein Integrationsprojekt. Die Aufgabe ähnelt dem Aufbau von Detection- und Incident-Response-Prozessen: Es braucht eine Warnmeldung, zugängliche Nachweise und einen Entscheidungsprozess, den der diensthabende Ingenieur ohne zusätzliche Eskalation ausführen kann. Für Teams, die bereits mit einer umfangreichen Roadmap arbeiten, übernehmen unsere Implementierungsservices solche Umsetzungsaufgaben. Es ist einfacher, diese Arbeit jetzt zu begründen, als nach einer erstmals verpassten Meldefrist.

Die schwierigere Frage betrifft nicht die Tools

Die rechtliche Frage, welche Produkte in den Anwendungsbereich fallen und wann die jeweilige Frist beginnt, sollte mit juristischen Fachleuten geklärt werden. Die operative Frage ist einfacher: Wenn für eine Komponente in einem ausgelieferten Produkt ein KEV-Eintrag erscheint, kann das Unternehmen alle betroffenen Produkte identifizieren und noch am selben Arbeitstag feststellen, ob die Schwachstelle aktiv ausgenutzt wird?

Wenn die ehrliche Antwort lautet, dass dies vermutlich davon abhängt, ob die richtige Person gerade erreichbar ist, sollte das Unternehmen zunächst eine einseitige Triage-Spezifikation erstellen und festlegen, welche Systeme gemeinsam eine Anfrage beantworten müssen.

Dieselbe Anforderung erhöht auch die Erwartungen an die eigenen Lieferanten. Ein Anbieter sollte nachvollziehbar erklären können, wie eine KEV-Warnung innerhalb eines Tages zu einer fristgerechten Meldung führt. Kann er diesen Datenfluss nicht beschreiben, existiert seine CRA-Bereitschaft bislang möglicherweise nur auf dem Papier. Diese Frage ist bei der nächsten Lieferantenbewertung durchaus berechtigt – und letztlich wird auch eine Aufsichtsbehörde wissen wollen, wie dieser Prozess funktioniert.

Wenn neben dem CRA auch Verpflichtungen aus NIS2 oder DORA bestehen, empfiehlt es sich, alle Anforderungen im Rahmen desselben Framework-Mappings zu betrachten. So lassen sich Überschneidungen und gemeinsame Lücken identifizieren, beispielsweise bei Meldefristen, der Transparenz in der Lieferkette und der eindeutigen Zuordnung von Verantwortlichkeiten. Dadurch wird verhindert, dass der CRA zu einem weiteren isolierten Compliance-Prozess wird.

Wenn die erste KEV-Warnmeldung für eines Ihrer Produkte um 9 Uhr eingeht, sollten Sie sich eine Frage stellen: Wer kann bis Mittag bestätigen, ob die Schwachstelle aktiv ausgenutzt wird? Lautet die Antwort auf diese Frage ein Personenname, ist der Prozess bereits anfällig. Können Sie sich dagegen auf eine dokumentierte Datenquelle und einen klar definierten Prüfprozess verlassen, sehen die Voraussetzungen für das kommende Quartal ganz anders aus.