Security-by-Design und die grundlegenden Anforderungen des CRA

Problem in der Praxis

In vielen Organisationen entsteht Produktsicherheit punktuell. Es gibt einen Penetrationstest vor dem Release, eine Liste offener Findings und ein Bauchgefühl, dass das Produkt "sicher genug" ist. Sichere Standardkonfiguration, Datenminimierung und die bewusste Reduktion der Angriffsfläche werden selten als zusammenhängendes Konzept behandelt. Stattdessen liefern Produkte mit weit geöffneten Defaults aus, sammeln mehr Daten als nötig und exponieren Dienste, die niemand braucht.

Der CRA macht diese Lücken sichtbar. Er verlangt unter anderem, Produkte risikobasiert ohne bekannte ausnutzbare Schwachstellen auszuliefern, sie mit einer sicheren Standardkonfiguration bereitzustellen, Vertraulichkeit, Integrität und Verfügbarkeit zu schützen, nur die für den Zweck erforderlichen Daten zu verarbeiten und die Angriffsfläche so klein wie möglich zu halten. Diese Anforderungen lassen sich nicht kurz vor dem Inverkehrbringen nachrüsten. Sie sind Architektur- und Prozessentscheidungen, die früh fallen müssen.

CISO-Einordnung

Die wesentlichen Cybersicherheitsanforderungen des CRA sind in Anhang I der Verordnung gebündelt und in zwei Blöcke gegliedert. Der erste Block beschreibt Produkteigenschaften, der zweite die Schwachstellenbehandlung über den Lebenszyklus. Aus CISO-Sicht lohnt es sich, diese Logik in wenige steuerbare Leitfragen zu übersetzen:

• Welche Daten muss das Produkt wirklich verarbeiten, und welche können wir weglassen?
• Welche Funktionen, Ports und Schnittstellen sind im Auslieferungszustand aktiv, und warum?
• Welche Standardeinstellungen sind sicher, und welche zwingen den Kunden zu einer bewussten Risikoentscheidung?
• Wie schützen wir Vertraulichkeit, Integrität und Verfügbarkeit der verarbeiteten Daten?
• Wie verteilen wir Sicherheitsupdates verlässlich, und wie lange?

Diese Fragen sind bewusst generisch. Sie ersetzen nicht den Verordnungstext, aber sie machen die grundlegenden Anforderungen für Produkt- und Engineering-Teams handhabbar. Wichtig ist die Altitude: Der CISO steuert das Konzept und die Nachweisbarkeit, nicht jede einzelne technische Einstellung.

Security-by-Default verdient besondere Aufmerksamkeit. Der CRA fordert eine sichere Standardkonfiguration. Das verschiebt die Beweislast: Nicht der Kunde muss das Produkt absichern, sondern der Hersteller muss begründen, warum ein Default unsicher ausgeliefert wird. Ähnlich verlangt der CRA sichere Update-Mechanismen, möglichst automatisch und mit der Möglichkeit, automatische Updates abzuschalten.

Umsetzungsperspektive

Der CRA denkt in Lebenszyklen, nicht in Releases. Sicherheit muss von der Risikobewertung über Architektur und Implementierung bis in Betrieb und Wartung reichen. Etablierte Rahmenwerke liefern hier das organisatorische und technische "Wie", ohne den CRA zu ersetzen:

• ISO/IEC 27001 und 27002 beschreiben, wie ein sicherer Entwicklungsprozess organisatorisch aussieht (sichere Architektur, Sicherheitstests, getrennte Umgebungen). Lizenziert, daher nur Strukturbezug, keine Anforderungsliste.
• NIST SSDF (SP 800-218) ist eine frei verwendbare Prozessreferenz für sichere Softwareentwicklung und gut auf Schwachstellenbehandlung und SBOM abbildbar.
• IEC 62443 (sicherer Produktentwicklungslebenszyklus und Komponentenanforderungen) gilt als wichtiger Kandidat für harmonisierte Normen; deren Anwendung kann später eine Vermutungswirkung für die Konformität entfalten.
• BSI TR-03183 verdichtet die CRA-Anforderungen und behandelt unter anderem SBOM und den Umgang mit Schwachstellen. Frei zugänglich und nützlich, aber nicht rechtsverbindlich und ohne Vermutungswirkung.

Der Lebenszyklusgedanke zeigt sich auch in der Schwachstellenbehandlung: Komponenten und Schwachstellen identifizieren und dokumentieren, eine SBOM führen, zeitnah Sicherheitsupdates bereitstellen, regelmäßig testen und eine Coordinated-Vulnerability-Disclosure-Policy betreiben. Updates müssen über einen Unterstützungszeitraum bereitstehen, der sich an der erwarteten Nutzungsdauer orientiert. Operativ bündeln viele Hersteller diese Aufgaben in einer PSIRT-Funktion.

Typische Fehler

1. Security-by-Design wird als Testphase am Ende verstanden statt als Architekturprinzip am Anfang.
2. Produkte liefern mit unsicheren Defaults aus, weil Bequemlichkeit über Sicherheit gestellt wird.
3. Datenminimierung wird ignoriert, sodass das Produkt mehr Daten sammelt, als der Zweck erfordert.
4. Die Angriffsfläche bleibt groß, weil ungenutzte Dienste und Schnittstellen aktiv bleiben.
5. Der Unterstützungszeitraum und der Update-Mechanismus werden erst nach dem Release durchdacht.
6. ISO-, NIST- oder IEC-Rahmen werden als Pflichtenkatalog missverstanden statt als Hilfe zum Nachweis.

Risiken und Trade-offs

Sichere Defaults können die wahrgenommene Benutzerfreundlichkeit reduzieren. Ein Produkt, das standardmäßig restriktiv konfiguriert ist, wirkt zunächst sperriger als eines mit offenen Einstellungen. Der CRA verlangt dennoch die sichere Voreinstellung, sodass der CISO Usability-Erwartungen und Sicherheitsanforderungen aktiv ausbalancieren muss.

Datenminimierung und Angriffsflächenreduktion stehen oft im Spannungsfeld mit Produktambitionen. Zusätzliche Features, Telemetrie und Integrationen vergrößern Funktionsumfang und Angriffsfläche zugleich. Jede Funktion ist daher auch eine Sicherheitsentscheidung.

Ein weiterer Trade-off liegt im Zeithorizont. Ein langer Unterstützungszeitraum erhöht Vertrauen und Marktfähigkeit, bindet aber über Jahre Ressourcen für Updates und Schwachstellenbehandlung. Wer hier zu knapp plant, riskiert später Konformitäts- und Reputationsprobleme.

Entscheidungspunkte

• Welche grundlegenden Anforderungen sind für unsere Produktklasse besonders kritisch?
• Welche Standardkonfiguration liefern wir aus, und wie begründen und dokumentieren wir Abweichungen?
• Welches Datenmodell erfüllt den Zweck mit minimaler Datenverarbeitung?
• An welchem Rahmen orientieren wir den sicheren Entwicklungslebenszyklus, und wie binden wir künftige harmonisierte Normen ein?
• Wie lang ist unser Unterstützungszeitraum, und wie sieht der Update-Mechanismus konkret aus?

Praktische Empfehlungen

1. Verankern Sie die grundlegenden Anforderungen als Architekturprinzipien, bevor die Entwicklung beginnt.
2. Definieren Sie sichere Defaults verbindlich und behandeln Sie jede unsichere Voreinstellung als begründungspflichtige Ausnahme.
3. Führen Sie Datenminimierung und Angriffsflächenreduktion als feste Schritte im Design-Review ein.
4. Etablieren Sie SBOM, Schwachstellenbehandlung und eine CVD-Policy früh, nicht erst zum Release.
5. Nutzen Sie ISO/IEC-Secure-Development, NIST SSDF und IEC 62443 als Orientierung für das "Wie" und dokumentieren Sie die Konformität entlang des Lebenszyklus.
6. Planen Sie den Unterstützungszeitraum und den Update-Weg als Produktentscheidung mit klarer Verantwortlichkeit.

Relevante Normreferenzen

• Cyber Resilience Act, Verordnung (EU) 2024/2847: verbindliche Rechtsgrundlage; grundlegende Anforderungen in Anhang I (Produkteigenschaften und Schwachstellenbehandlung).
• ISO/IEC 27001 und 27002: Referenz für sicheren Entwicklungsprozess (lizenziert, nur Strukturbezug).
• IEC 62443: Referenz für sicheren Produktentwicklungslebenszyklus und Komponentenanforderungen; Kandidat für harmonisierte Normen.
• NIST SSDF (SP 800-218): frei verwendbare Prozessreferenz für sichere Softwareentwicklung.
• BSI TR-03183: frei zugängliche Umsetzungshilfe zum CRA, nicht rechtsverbindlich.