EN 18031 und der CRA: Was Security-Testing belegen kann, und was nicht

Seit EN 18031 im Amtsblatt zitiert wurde, stellen uns Product-Teams eine Variante derselben Frage: „Wenn wir gegen EN 18031 testen, sind wir dann CRA-konform?" Die ehrliche Antwort ist Nein, und die Frage hinter der Frage ist nützlicher: Was kann technisches Testing tatsächlich belegen, für welchen Rahmen, und was bleibt in jedem Fall eine Dokumentationsentscheidung? Diese Note trennt drei Dinge, die ständig vermischt werden: den Standard, die Verordnung und die Evidenz.

Zuerst die Fakten, weil sie häufig falsch dargestellt werden. EN 18031 ist ein dreiteiliger Standard zur Sicherheit von Funkanlagen, harmonisiert unter der Radio Equipment Directive (RED), nicht unter dem Cyber Resilience Act. Ein CRA-Harmonisierungsstandard ist bislang nicht im Amtsblatt zitiert; EN 18031 ist am besten als Stepping Stone zu verstehen, dessen technische Inhalte vieles antizipieren, was der CRA verlangen wird. Dagegen zu testen produziert starke Evidenz. Sie produziert keine Konformitätsvermutung gegenüber dem CRA.

Die drei Teile, kurz

EN 18031-1 behandelt Netzwerkschutz, 31 Anforderungen an sichere Kommunikation, Update-Mechanismen, Zugriffskontrolle und ähnliche Eigenschaften für internetverbundene Funkanlagen. Teil 2 behandelt den Schutz personenbezogener Daten mit 40 Anforderungen; bemerkenswert: Ein erheblicher Teil lässt sich durch die Erklärung des Herstellers erfüllen statt durch Prüfung. Teil 3 behandelt Betrugschutz bei Finanztransaktionen mit 34 Anforderungen. Für die meisten vernetzten Produkte konzentriert sich die technische Arbeit auf Teil 1, und dort überlappt er am stärksten mit dem, was Security-Testing immer schon getan hat.

Was Testing belegt, und was nicht

Drei Arten von Evidenz stehen am Ende jedes Konformitätsgesprächs, und sie sind nicht austauschbar:

• Design-Dokumentation zeigt Absicht: die Architektur, die Zugriff beschränken sollte; der Update-Mechanismus, der signiert sein sollte. Sie beantwortet: „Was haben Sie designed?"
• Testberichte zeigen Umsetzung: Die Signaturprüfung hat ausgeführt, die Zugriffskontrolle hat gegriffen, das Update wurde abgelehnt. Sie beantwortet: „Verhält sich das Produkt unter den getesteten Bedingungen wie designed?"
• Adversariale Befunde. Penetrationstesting, zeigen Verhalten unter Bedingungen, für die niemand designed hat. Sie beantwortet: „Was passiert, wenn jemand genau das versucht, was das Design nicht vorgesehen hat?"

Konformitätsrahmen konsumieren überwiegend die ersten beiden. Sicherheitsrealität wird erheblich von der dritten entschieden. Ein Produkt kann Erklärungen anhäufen und trotzdem einen offenen Debug-Port ausliefern; ein Produkt kann jede funktionale Security-Prüfung bestehen und trotzdem jedem Inhaber eines geteilten Credentials vertrauen. Die Rahmen wissen das, deshalb erlauben die „c"-Mechanismen (Conditional Requirements) der EN 18031 ausdrücklich belastbarere Evidenz für höhere Risikoklassen, einschließlich adversarialem Testing.

Tests auf CRA-Anforderungen mappen, der nützliche Teil

Auch ohne CRA-Konformitätsvermutung ist die technische Überlappung real und nutzbar. Die wesentlichen Anforderungen des CRA-Anhangs I. Secure by Default, sichere Updates, keine „wissentlich und aktiv" ausnutzbaren Schwachstellen, Schutz gespeicherter und übertragener Daten, Minimierung der Angriffsfläche, sind exakt die Eigenschaften, die eine EN-18031-orientierte Testkampagne prüft. Ein pragmatisches Muster, das wir Product-Teams empfehlen: eine technische Evidenzbasis bauen, gegliedert nach Security-Eigenschaft (Boot-Integrität, Update-Sicherheit, Zugriffskontrolle, Key-Management, Kommunikationssicherheit, Datenschutz), und sie heute der RED-Erklärung dienen lassen und morgen der CRA-Konformitätsbewertung. Die Tests ändern sich nicht; die Papiere, die sie füttern, schon.

Was sich mit dem CRA ändert, sind die Kosten von Lücken. Unter der RED ist ein fehlendes Stück ein Compliance-Risiko. Unter dem Reporting- und Assessment-Regime des CRA wird dasselbe fehlende Stück, etwa ein Update-Mechanismus, der alte signierte Images akzeptiert, siehe Firmware Anti-Rollback, zur Schwachstelle mit anlaufender 24-Stunden-Meldefrist (siehe CRA Vulnerability Reporting). Das Standards-Gespräch und das Incident-Gespräch konvergieren auf dieselben technischen Fakten.

Vorbereiten ohne Compliance-Theater

Die Teams, die von EN 18031 profitieren, behandeln ihn als Testplan, nicht als Talisman. Konkret: die Security-Eigenschaften des Produkts einmal ehrlich auf die relevanten Anforderungen mappen; identifizieren, wo die Evidenz eine Erklärung ist, die ein Test sein sollte; die technisch relevanten Befunde beheben, egal, welche Verordnung gefragt hat; und die Evidenz so strukturiert halten, dass sie sich wieder verwerten lässt. Die Teams, die leiden, drucken die Anforderungsliste aus, antworten 105-mal mit „Ja", und stellen in einem Vorfall oder Assessment fest, dass die Antworten das Design beschrieben, nicht das Produkt.

Das ist am Ende die ehrliche Zusammenfassung des ganzen EN-18031/CRA-Verhältnisses: Die Rahmenwerke werden sich weiterentwickeln, und die technischen Fragen, um die sie kreisen, ändern sich überhaupt nicht: Ist Ihre Boot-Kette echt, Ihr Update-Pfad sicher, Ihre Identity pro Gerät, Ihre Daten geschützt? Wer diese Fragen mit Evidenz beantworten kann, ist auf das nächste Dokument vorbereitet, das sie stellt, egal, wie es heißt.