CRA Resilienz & Verfügbarkeit: DoS-Schutz, Recovery und sichere Grundfunktionen

Der Cyber Resilience Act verlangt, dass Produkte ihre wesentlichen und grundlegenden Funktionen angemessen gegen Ausfälle schützen – auch nach einem Sicherheitsvorfall. Dazu gehören Resilienz- und Minderungsmaßnahmen gegen Denial-of-Service sowie die Begrenzung negativer Auswirkungen des Produkts auf andere Geräte und Netze.

Was verlangt der CRA bei Verfügbarkeit und Resilienz?

Anhang I Teil I Nummer 2 Buchstabe h verlangt den Schutz der Verfügbarkeit wesentlicher und grundlegender Funktionen, auch nach einem Vorfall, einschließlich Resilienz und Maßnahmen gegen Denial-of-Service. Buchstabe i ergänzt, dass Produkte negative Auswirkungen auf die Verfügbarkeit von Diensten anderer Geräte oder Netze minimieren sollen.

Die Pflicht ist risikobasiert. Die CRA-Risikobewertung muss zuerst klären, welche Funktionen für Sicherheit und Zweckbestimmung wirklich wesentlich sind.

Was ist eine wesentliche oder grundlegende Funktion?

Das ist keine pauschale technische Kategorie, sondern ergibt sich aus Produkt und Nutzung. Bei einem Router kann die sichere Netzkommunikation zentral sein, bei einer Zugangskontrolle die Entscheidung über Berechtigungen, bei einer Verwaltungssoftware möglicherweise die Integrität und Verfügbarkeit kritischer Konfiguration.

Hersteller sollten diese Funktionen ausdrücklich benennen. Ohne diese Priorisierung ist kaum nachvollziehbar, was ein Resilienztest eigentlich schützen soll.

Muss ein Produkt immer verfügbar sein?

Nein. Der CRA verlangt kein allgemeines SLA von 100 Prozent. Ein Produkt darf ausfallen, wenn dies technisch unvermeidbar ist; es sollte aber auf vorhersehbare Störungen angemessen vorbereitet sein und nicht wegen leicht provozierbarer Ressourcenerschöpfung dauerhaft unsicher werden.

Je nach Produkt kann ein kontrollierter Fail-Safe-Zustand besser sein als eine fehlerhafte Weiterfunktion. Entscheidend ist, dass das Verhalten aus Risiko und Zweckbestimmung abgeleitet ist.

Was ist Denial-of-Service im Produktkontext?

DoS bedeutet, dass ein Angreifer oder fehlerhaftes Gegenüber Ressourcen so beansprucht, dass legitime Funktionen nicht mehr verfügbar sind. Ursachen können übermäßige Requests, große Eingaben, offene Verbindungen, Speicherverbrauch, CPU-Last, Log-Fluten oder erschöpfte Datenbankverbindungen sein.

Auch lokale Schnittstellen können betroffen sein. Deshalb sollte der Hersteller nicht nur Internet-DDoS betrachten, sondern jede Ressource, die vernünftigerweise durch Eingaben kontrolliert werden kann.

Welche Schutzmaßnahmen sind möglich?

Typische Maßnahmen sind Rate Limiting, Quoten, Timeouts, Größenlimits, Connection Limits, Priorisierung kritischer Funktionen, Backpressure, Circuit Breaker, Ressourcenisolation und kontrolliertes Abschalten nicht wesentlicher Funktionen.

Was bedeutet Graceful Degradation?

Graceful Degradation bedeutet, dass ein Produkt bei Teilstörungen nicht unkontrolliert ausfällt, sondern Funktionen geordnet reduziert. Eine nicht kritische Statistikfunktion kann beispielsweise deaktiviert werden, während zentrale Sicherheits- oder Steuerfunktionen weiterlaufen.

Die Priorität muss vorab definiert sein. Sonst verbraucht eine optionale Funktion im Störfall möglicherweise genau die Ressourcen, die für die wesentliche Funktion benötigt werden.

Was bedeutet Fail Safe?

Fail Safe beschreibt einen Zustand, in dem ein Fehler nicht zu einer gefährlicheren oder unsichereren Situation führt. Bei Zugriffssystemen kann das je nach Schutzgut unterschiedlich aussehen: Manche Anwendungen müssen geschlossen bleiben, andere aus Sicherheitsgründen öffnen. Es gibt keine universelle Antwort.

Deshalb muss der sichere Fehlerzustand aus Zweckbestimmung, Umfeld und möglichen Schäden abgeleitet und dokumentiert werden.

Wie behandelt man Abhängigkeiten von Cloud-Diensten?

Ist eine Remote-Komponente für eine Produktfunktion notwendig, muss ihr Ausfall im Resilienzmodell berücksichtigt werden. Das Produkt sollte klar definieren, welche Funktionen offline weiterlaufen, welche Daten gepuffert werden und wie Wiederverbindung funktioniert.

Der geplante Beitrag CRA Remote-Datenverarbeitung ordnet ein, wann Cloudbestandteile zum Produkt gehören. Für Resilienz ist unabhängig davon wichtig, Abhängigkeiten realistisch zu testen.

Wie verhindert man Retry-Stürme?

Fehlerhafte Wiederholungslogik kann einen Ausfall verschärfen. Wenn tausende Geräte nach einer Störung gleichzeitig jede Sekunde neu verbinden, entsteht zusätzliche Last. Exponentielles Backoff, Jitter und Limits können solche Effekte reduzieren.

Diese Mechanismen sollten in realistischen Flottenszenarien getestet werden. Ein einzelnes Testgerät zeigt keinen synchronisierten Retry-Sturm.

Welche Rolle spielen Backups?

Backups unterstützen Recovery, sind aber nur ein Teil der Resilienz. Es muss klar sein, welche Daten gesichert werden, wie aktuell sie sein müssen, wer auf sie zugreifen kann und wie ein Restore getestet wird.

Ein Backup, das nie wiederhergestellt wurde, ist kein belastbarer Nachweis. Außerdem müssen Vertraulichkeit und Integrität der Sicherung berücksichtigt werden, wie im Artikel CRA Kryptografie beschrieben.

Wie plant man Recovery?

Recovery beginnt mit klaren Zielen: Welche Funktion muss zuerst zurückkehren? Welche Konfiguration ist vertrauenswürdig? Welche Schlüssel oder Credentials müssen möglicherweise erneuert werden? Wie wird verhindert, dass eine kompromittierte Komponente einfach wiederhergestellt wird?

Der Recovery-Prozess sollte technische und organisatorische Schritte enthalten. Bei komplexen Produkten kann ein Wiederanlaufplan mit Verantwortlichen, Prüfungen und Nutzerinformation nötig sein.

Wie testet man Resilienz?

Tests sollten gezielt Störungen erzeugen: Netzwerkverbindungen trennen, abhängige Dienste ausschalten, Ressourcen begrenzen, hohe Last erzeugen, Speichermedien füllen, Updates unterbrechen und Neustarts auslösen. Dabei wird geprüft, wie das Produkt reagiert und ob wesentliche Funktionen geschützt bleiben.

Diese Tests gehören in das regelmäßige Security Testing. Wichtig sind auch Wiederholung und Versionierung nach größeren Architekturänderungen.

Was muss bei Logging unter Last passieren?

Ein Angriff kann enorme Logmengen erzeugen. Logging darf dann nicht selbst zum Ausfallgrund werden. Rotation, Quoten, Priorisierung und begrenzte Detailtiefe können verhindern, dass Speicher oder CPU durch Protokollierung erschöpft werden.

Gleichzeitig müssen kritische Security Events erhalten bleiben. Der Artikel CRA Logging & Monitoring behandelt diesen Zielkonflikt.

Wie verhindert das Produkt Schäden an anderen Netzen?

Anhang I verlangt auch, negative Auswirkungen auf die Verfügbarkeit anderer Geräte oder Netze zu minimieren. Ein kompromittiertes Produkt sollte beispielsweise nicht leicht als Quelle massiver Scan-, Spam- oder DDoS-Aktivität missbrauchbar sein.

Ausgehende Rate Limits, sichere Standardkonfiguration, Begrenzung automatischer Verbindungen und Schutz vor Übernahme können dazu beitragen. Das betrifft besonders Produkte mit hoher Bandbreite oder großer installierter Basis.

Welche Rolle spielt Ressourcenisolation?

Wenn nicht kritische Komponenten dieselben Ressourcen wie wesentliche Sicherheitsfunktionen nutzen, kann ein Fehler alles lahmlegen. Prozess-, Container-, Speicher- oder Thread-Isolation kann den Blast Radius begrenzen.

Welche Isolation nötig ist, hängt von Architektur und Plattform ab. Der Grundgedanke ist Secure by Design: Fehler einer Komponente sollen nicht automatisch das gesamte Produkt übernehmen.

Wie behandelt man Hardwarefehler?

Resilienz umfasst auch vernünftigerweise vorhersehbare Hardwarestörungen, wenn sie die Produktsicherheit beeinflussen. Watchdogs, redundante Speicherbereiche, sichere Bootpfade oder Fehlererkennung können je nach Gerät sinnvoll sein.

Der CRA ist kein allgemeines Zuverlässigkeitsgesetz. Relevant werden Hardwarefehler dort, wo sie Cybersicherheit und wesentliche Produktfunktionen betreffen.

Wie dokumentiert man Verfügbarkeitsanforderungen?

Die technische Dokumentation sollte wesentliche Funktionen, relevante Ausfallszenarien, Schutzmaßnahmen, Recoverykonzept und Testnachweise enthalten. Hilfreich ist eine Tabelle, die jedes Risiko mit Maßnahme und Test verbindet.

Auch bekannte Grenzen sollten beschrieben werden. Ein dokumentierter, begründeter Grenzwert ist besser als eine unrealistische Aussage „unbegrenzt belastbar“.

Welche Fehler treten häufig auf?

• Nur normale Lasttests, keine böswilligen Eingabemuster.
• Retries ohne Backoff verschärfen Ausfälle.
• Logs füllen unter Angriff den Speicher.
• Recovery stellt kompromittierte Konfiguration unverändert wieder her.
• Cloud-Abhängigkeiten werden nicht simuliert.
• Keine Priorisierung wesentlicher Funktionen.
• Backups existieren, Restore wurde nie getestet.

Wie können KMU Resilienz pragmatisch verbessern?

Ein guter Start ist eine Liste der fünf wichtigsten Produktfunktionen und ihrer kritischen Abhängigkeiten. Für jede Funktion werden drei Störungen ausgewählt und praktisch getestet. Daraus entstehen Limits, Timeouts, Recovery-Schritte und Monitoring.

Dieser fokussierte Ansatz ist häufig wertvoller als ein riesiges Business-Continuity-Dokument ohne konkrete Produkttests.

Wie wirkt sich ein Sicherheitsvorfall auf Recovery aus?

Nach einem Security Incident darf Recovery nicht nur Verfügbarkeit wiederherstellen. Es muss auch geklärt sein, ob Credentials, Schlüssel, Konfiguration oder Softwarestand kompromittiert wurden. Sonst wird der Angriffszustand möglicherweise einfach zurückgespielt.

Der Recovery-Plan sollte deshalb einen Security-Check vor der Rückkehr in den Normalbetrieb enthalten. Bei aktiv ausgenutzten Schwachstellen sind außerdem CRA-Meldepflichten zu prüfen.

Wie passt Resilienz zum Supportzeitraum?

Recovery- und Updatepfade müssen während des zugesagten Supportzeitraums funktionsfähig bleiben. Ein Recoveryimage, das nur veraltete und nicht mehr patchbare Software enthält, kann selbst ein Sicherheitsproblem werden.

Hersteller sollten deshalb Recovery-Artefakte, Schlüssel und Dokumentation in ihren Lifecycle-Prozess einbeziehen.

Was ist bei Flottenprodukten besonders wichtig?

Bei tausenden Geräten können zentrale Änderungen oder Ausfälle synchron wirken. Ein fehlerhaftes Update, Zertifikatsablauf oder Cloud-Ausfall kann viele Produkte gleichzeitig treffen. Flottenweite Resilienztests sollten solche gemeinsamen Fehlerquellen berücksichtigen.

Gestaffelte Rollouts, Jitter, Canary-Gruppen und gestufte Wiederherstellung können den Blast Radius reduzieren. Diese Maßnahmen sind nicht pauschal vorgeschrieben, können aber aus der Risikobewertung folgen.

Wie werden Verfügbarkeitsgrenzen an Nutzer kommuniziert?

Nutzerinformationen sollten relevante Voraussetzungen und Sicherheitsumgebungen benennen. Wenn eine Funktion zwingend Netzwerkzugang, Cloudverbindung oder regelmäßige Synchronisation benötigt, sollte das transparent sein.

Auch Recovery- und sichere Betriebsanweisungen gehören in die Dokumentation. So können Nutzer vernünftige Maßnahmen treffen, bevor ein Vorfall eintritt.

Müssen RTO und RPO im CRA festgelegt werden?

Der CRA schreibt keine pauschalen Recovery Time Objectives oder Recovery Point Objectives für jedes Produkt vor. Solche Zielwerte können aber ein sinnvolles internes Werkzeug sein, wenn Verfügbarkeit oder Datenwiederherstellung sicherheitsrelevant sind. Sie übersetzen eine allgemeine Resilienzerwartung in prüfbare technische Anforderungen.

Die Werte sollten aus Zweckbestimmung und Risiko entstehen. Für eine Komfortfunktion können Stunden akzeptabel sein; bei einer sicherheitskritischen Steuerfunktion kann schon eine kurze Unterbrechung erheblich sein.

Wie werden Kapazitätsgrenzen sicher getestet?

Hersteller sollten nicht nur einen durchschnittlichen Lastfall messen, sondern bewusst Grenzbereiche untersuchen. Dazu gehören viele parallele Sitzungen, große Eingaben, ungewöhnliche Requestfolgen, gefüllte Queues und erschöpfte externe Ressourcen. Ziel ist zu erkennen, ob das Produkt kontrolliert begrenzt oder in einen unvorhersehbaren Zustand fällt.

Aus den Tests entstehen technische Limits und Alarmwerte. Diese sollten in der Produktkonfiguration verankert sein und bei Architekturänderungen erneut geprüft werden.

Wann ist ein lokaler Notbetrieb sinnvoll?

Produkte mit Cloud- oder Netzwerkabhängigkeiten können für bestimmte Kernfunktionen einen lokalen Notbetrieb vorsehen. Dabei muss klar sein, welche Funktionen ohne zentrale Dienste sicher weiterlaufen und welche bewusst gesperrt werden. Ein Offline-Modus darf nicht stillschweigend Authentisierung oder andere Schutzkontrollen umgehen.

Solche Betriebsarten sollten wie normale Produktfunktionen getestet, dokumentiert und in Nutzerinformationen beschrieben werden. Dadurch wissen Anwender im Vorfall, was weiterhin sicher möglich ist.

Wie werden Resilienzmaßnahmen priorisiert?

Ein Hersteller sollte zuerst die Fehlerquellen behandeln, die gleichzeitig viele Nutzer oder sicherheitskritische Funktionen treffen können: zentrale Cloudabhängigkeiten, globale Schlüssel, Updateinfrastruktur, gemeinsame Datenbanken oder gemeinsam genutzte Kernkomponenten. Danach folgen lokale und weniger weitreichende Ausfallszenarien.

Diese Priorisierung verhindert, dass viel Aufwand in seltene Einzelfehler fließt, während systemweite Single Points of Failure unbeachtet bleiben.

Wie sollte man gemeinsame Fehlerursachen behandeln?

Redundanz schützt nur dann, wenn nicht beide Wege dieselbe Fehlerursache besitzen. Zwei Server im selben Rechenzentrum, zwei Dienste mit demselben ablaufenden Zertifikat oder mehrere Geräte mit demselben globalen Schlüssel können gleichzeitig ausfallen. Hersteller sollten deshalb bei kritischen Funktionen auch gemeinsame Abhängigkeiten betrachten.

Ein Resilienzreview kann solche Single Points of Failure sichtbar machen und entscheiden, wo echte Unabhängigkeit, gestaffelte Rollouts oder alternative Betriebswege erforderlich sind.

Wie werden Resilienztests nach Änderungen wiederholt?

Ändert sich eine zentrale Abhängigkeit, Cloudarchitektur, Datenbank, Updateinfrastruktur oder Ressourcenbegrenzung, sollten die dazugehörigen Störungsszenarien erneut getestet werden. Ein alter Last- oder Recoverytest beweist nicht automatisch, dass die neue Architektur dieselbe Belastbarkeit besitzt.

Ein einfacher Trigger im Change-Prozess kann festlegen, welche Resilienztests bei welcher Änderung wiederholt werden. Dadurch bleibt der Nachweis mit der tatsächlich ausgelieferten Produktversion verbunden.

Wo stehen Resilienz und Verfügbarkeit im CRA?

Die ausdrücklichen Anforderungen finden sich in Anhang I Teil I Nummer 2 Buchstaben h und i der Verordnung (EU) 2024/2847. Sie verlangen Schutz wesentlicher Funktionen einschließlich DoS-Maßnahmen und die Minimierung negativer Auswirkungen auf andere Geräte und Netze.