Wie wissen Sie, dass Sie bereit für den Cyber Resilience Act (CRA) sind?
Lehren aus frühen Pilotprojekten der CRA zur Testung und Dokumentation
Die frühen Pilotprojekte von CRA zeigen, warum Compliance nicht nur eine Sicherheitsmaßnahme ist. Es geht darum, Cybersicherheit in realen Produkten zu erbringen, Beweise dafür zu sammeln und Teams dabei zu unterstützen, die neuen Verpflichtungen zu verstehen, insbesondere in Situationen mit knappem Ressourcenangebot.
Da der EU-Cyberresilienzakt (CRA) nun in Kraft ist und in den nächsten Jahren wichtige Pflichten eingeführt werden, stellen sich viele Organisationen dieselbe Frage: “Wie wissen wir, dass wir bereit sind?”
Die CRA legt grundlegende Anforderungen an die Cybersicherheit für Produkte mit digitalen Elementen (Hardware und Software), die in die EU verkauft werden. Außerdem setzt sie laufende Erwartungen hinsichtlich der Handhabung von Schwachstellen und der Meldung von Vorfällen fest, was bedeutet, dass die Einhaltung nicht nur eine einmalige Zertifizierung ist, sondern eine kontinuierliche Prozessführung ist.
In unseren Pilotanalysen konzentrierten wir uns auf zwei praktische Aspekte: (1) die Validierung von sicherheitsrelevanter Software von CRA-zertifizierten Anbietern auf realen Geräten und (2) die Validierung der CRA-Dokumentation und Checklisten durch Unterstützung einer Selbstbewertung der Dokumentation. Die Pilotprojekte waren kooperativ konzipiert und sollten den teilnehmenden Organisationen helfen, eine frühe Einschätzung der Bereitschaft zu erlangen und gleichzeitig reale Erfahrungen in die Software und die Anleitung einfließen zu lassen.
Die Cybersicherheitsfestigkeit in der chaotischen realen Welt testen
Die Erwartungen der CRA richten sich in der Regel nach dem Produkt: hat Ist die Sicherheit von Anfang an sichergestellt? Können die Teams nachweisen, wie sie die Softwarekomponenten und Schwachstellen im Laufe der Zeit bewältigen? CKann das Produkt reale Belastungen, missformatierte Eingaben, unerwarteten Verkehr und Protokoll-Ausfälle standhalten, ohne sich auf unsichere Weise zu verlangsamen? In vernetzten Produkten bedeutet das oft, die Software und die Schnittstellen zu testen, auf die Angreifer tatsächlich abzielen würden – Bluetooth, Wi-Fi und andere drahtlose Technologien.‑Fi, Mobilfunkverbindung und offene Dienste.
Eine Technik, die wir bei Piloten eingesetzt haben, heißt “protocol fuzzing”: Wir senden absichtlich unerwartete, ungültige oder häufig verwendete Nachrichten, um zu sehen, ob ein Produkt weiterhin sicher und vorhersehbar funktioniert. Es unterscheidet sich von “Breaking in”, um Zugang zu erlangen. Es geht um Widerstandsfähigkeit unter Stress und Fehlerverhaltensweisen. Das ist die Art von Situation, die aus einem geringen Fehler ein echtes Kundenproblem werden lassen kann.
Beispiel 1:
Smart Access-Produkt – Resilienzfehler sind nutzerbezogene Fehler
In einem Pilotprojekt mit einem Hersteller von Smart-Access-Geräten ergaben Fuzzing-Tests ein Szenario, in dem unerwarteter Traffic dazu führen könnte, dass das Produkt nicht mehr reagiert. Dies ist wichtig, da Resilienzprobleme nicht nur rein theoretisch sind: Ein Smart-Access-Gerät, das sich abschaltet oder nicht mehr reagiert, kann zu tatsächlichen Ausfallzeiten der Kunden, Supportkosten und Reputationsrisiken führen. Der Vorteil der frühzeitigen Erkennung von Problemen besteht darin, dass die Sanierung auf der Zeitlinie des Herstellers geplant werden kann, bevor gesetzliche Fristen und die Gefahr einer breiten Kundenschädigung eintreten.
Beispiel 2:
Intelligentes Heizen – starke Ergebnisse brauchen noch Beweise
Ein weiterer Pilot konzentrierte sich auf einen Anbieter von vernetzten Smart-Homes. Die technischen Testergebnisse waren hervorragend, da bei der Pilotumgebung keine wesentlichen Probleme auftraten. Das bedeutet jedoch nicht, dass die Arbeit abgeschlossen ist. Die Bereitschaft zur CRA-Implementierung hängt auch davon ab, dass die Kontrollen wiederholt werden können, dass sie entsprechend dem Entwicklungsstand des Produkts aktualisiert werden und dass Beweismittel zur Verfügung stehen, die zeigen, was während des Testprozesses getestet wurde, wann und wie Probleme im Laufe der Zeit behoben wurden.
Beispiel 3:
Das Problem “Wo beginnen wir?” (und warum helfen Checklisten?)
In einem Pilotprojekt für KMU war der größte Mehrwert die strukturierte Anleitung zur Durchführung der Dokumentations-Selbsteinschätzung. Die Organisation verfügte über fähige Ingenieure, verfügte jedoch über begrenzte Fachkompetenz zur Interpretation der Anforderungen, zur Entscheidung, welche Beweismittel ‘ausreichten’, und zur frühzeitigen Erkennung von Lücken. Ein checklistgestützter Ansatz half dabei, eine überwältigende Anzahl an Anforderungen in eine überschaubare Reihe von Aktionen zu übersetzen: Sammeln von vorhandenen Informationen, deren Zuordnung zu den CRA-Anforderungen, Identifizierung von Lücken und Iteration.
Die wichtigsten Erkenntnisse der Pilotprojekte sind, dass Werkzeuge und Dokumentation untrennbar miteinander verbunden sind. Werkzeuge helfen, echte technische Risiken aufzuzeigen; Dokumentation und Prozesse festlegen Ob diese Risiken auf konsistente, transparente Weise und in der von der CRA erwarteten Geschwindigkeit abgewickelt werden.
Warum Dokumentation wichtig ist: Um zu beweisen, dass man die richtigen Dinge getan hat (und weiterhin tun kann)
Für viele Teams ist der schwierigste Teil des CRA nicht der Durchführung eines Sicherheitstests. Vielmehr geht es darum, die Dokumentation und Prozesse zu erstellen und zu pflegen, die dahinter stehen. Dokumentation ist die Methode, um zu zeigen, dass die Sicherheitsarchitektur konzeptionell implementiert wurde, dass Schwachstellen konsistent behandelt werden und dass Verantwortlichkeiten in der gesamten Entwicklung, Produktentwicklung, Rechtsabteilung und Support klar definiert sind.
Bei Pilotprojekten stellten wir immer wieder fest, dass die Dokumentationsarbeit wie ein ‘Minenfeld’ wirken kann, insbesondere für KMU ohne eigene Rechtsabteilung oder Compliance-Abteilung. Anforderungen greifen über mehrere Disziplinen hinweg: Produktarchitektur, sichere Entwicklungspraktiken, Aktualisierungsunterstützungsperioden, Schwachstellenanalyse/Prüfung, Kundenkommunikation und Incident-Reporting. Das richtige Ergebnis zu erreichen, geht nicht nur darum, Prozessdokumente zu verfassen. Es geht darum, die tatsächliche Funktionsweise der Organisation zu gestalten.
Warum Resillion dabei ist: die Transformation der CRA-Intentionen in etwas, das Teams tatsächlich nutzen können
Die CRA hebt die Anforderungen an die Selbstkontrolle auf ein neues Niveau, aber viele Organisationen, insbesondere kleinere Hersteller, benötigen praktische Wege, um Anforderungen zu interpretieren und sie auf reale Produkte anzuwenden. Das ist das Ziel von CRACY (“CRA Compliance made easy”): Hilfestellungen und Werkzeuge, die die Selbstkontrolle nach CRA-Standards unterstützen und Teams dabei helfen, von Unsicherheit zu einem konkreten Plan zu gelangen.
Resillion Dies liegt an unserer Erfahrung in der Produkt-Security-Testing- und -Zertifizierung und daran, dass wir die CRACY-Arbeitspakete, die auf der Tooling-Seite ausgerichtet sind, leiten. In der Praxis bedeutet das: Wir sind Nicht nur die Entwicklung und Validierung von CRA-konformen Testansätzen, sondern auch die Koordination der Zusammenführung der Tools und die Sicherstellung, dass die Erfahrungen aus Pilotprojekten in Verbesserungen umgesetzt werden, die Vorteil die breitere Gemeinschaft.
Was kommt als Nächstes?
Über die Piloten hinaus traten drei Themen hervor:
Wenn Sie sind Wer Produkte mit digitalen Elementen in die EU auf den Markt bringt und eine frühzeitige Einschätzung der CRA-Bereitschaft wünscht, der ist am besten daran, schon vor Ablauf der Fristen rasante Entscheidungen zu treffen. Wir haben Die anonymisierten Pilotbeispiele in diesem Beitrag wurden so gewählt, dass sie Teilnahme Organisationen sind vertraulich, während sie die praktischen Erkenntnisse teilen, die gewonnen werden. Breit einsetzbar.
