Worum geht es in Anhang I?
Wer sich mit der Cyberresilienz-Verordnung beschäftigt, landet früher oder später bei Anhang I. Hier stehen die sogenannten “grundlegenden Cybersicherheitsanforderungen”, also die wesentlichen Sicherheitsanforderungen, die Produkte mit digitalen Elementen erfüllen müssen, bevor sie auf den europäischen Markt kommen.
Anhang I, Teil I, Punkt (2) enthält dreizehn Anforderungen, von Authentifizierung über Verschlüsselung und Datenminimierung bis hin zu Logging und sicherer Löschung. Die üblichen Verdächtigen, wenn man so will.
Wenn ich in Gesprächen mit technischen Leitern auf diese Anforderungen zu sprechen komme, sehe ich meist eine von zwei Reaktionen: Entweder Schulterzucken, “wird schon nicht so schlimm”, oder leichte Panik, “wir müssen jetzt alles umsetzen, für jedes Produkt”. Beides geht am Kern vorbei.
Der Satz, den man nicht überlesen sollte
Anhang I, Teil I, Punkt (2) beginnt mit einem Satz, der gerne überflogen wird:
“Auf der Grundlage der Bewertung der Cybersicherheitsrisiken gemäß Artikel 13 Absatz 2 müssen Produkte mit digitalen Elementen, soweit zutreffend, […]”
Danach folgen die dreizehn Anforderungen. Der einleitende Satz enthält zwei Schlüssel zum Verständnis dieses Teils von Anhang I.
Was bedeutet “Auf der Grundlage der Bewertung der Cybersicherheitsrisiken”?
Der erste Schlüssel: Die Risikobewertung bildet die Grundlage dafür, welche Anforderungen aus Anhang I, Teil I, Punkt (2), auf das eigene Produkt anwendbar sind und wie sie umgesetzt werden. Maßgeblich ist eine dokumentierte Einschätzung, die zum Produkt passt.
Artikel 13(3) verlangt, dass die Risikobewertung ausdrücklich angibt, ob und in welcher Weise die Sicherheitsanforderungen aus Anhang I, Teil I, Punkt (2), auf das jeweilige Produkt anwendbar sind und wie sie umgesetzt werden.
Das “ob” ist entscheidend. Der CRA rechnet ausdrücklich damit, dass bestimmte Anforderungen für bestimmte Produkte schlicht nicht zutreffen.
Die Risikobewertung ist also kein optionaler Vorschritt. Sie ist der Kompass.
Was bedeutet “where applicable”?
Der zweite Schlüssel: “Where applicable”, in der deutschen Fassung “soweit zutreffend”, ist weder ein Schlupfloch noch eine Floskel. Es ist die bewusste Anerkennung, dass nicht jede Anforderung auf jedes Produkt passt.
Ein vielleicht etwas überspitztes Beispiel aus Kundengesprächen ist die Bluetooth-Zahnbürste. Nehmen wir an, jemand hackt sie. Was passiert? Sie vibriert in der falschen Frequenz. Das ist ärgerlich, aber es ist kein Sicherheitsrisiko, das Secure Boot rechtfertigt.
Bei einer Neuentwicklung kann man argumentieren: State of the Art, warum nicht gleich richtig machen. Aber ein Bestandsgerät mit diesem Risikoprofil nachträglich mit Secure Boot auszustatten, wäre, vorsichtig formuliert, unverhältnismäßig.
Erwägungsgrund 55 der Verordnung erläutert die Begründung der Nichtanwendbarkeit in der technischen Dokumentation. Er nennt als Beispiel eine Anforderung, die “mit der Art eines Produkts mit digitalen Elementen unvereinbar” ist.
Der CRA nennt dort sogar den Fall, dass ein Produkt aus Interoperabilitätsgründen auf Standards setzen muss, deren Sicherheitseigenschaften nicht mehr als State of the Art gelten. Auch dann muss der Hersteller die Risiken adressieren, aber eben auf andere Weise, etwa durch Einschränkung des Einsatzzwecks auf vertrauenswürdige Umgebungen oder durch transparente Nutzerinformation.
Das heißt: Die Prüfung der Anwendbarkeit ist keine Ausrede, um Anforderungen zu umgehen. Es geht aber auch nicht darum, pauschal alles umzusetzen. Der CRA erwartet eine begründete Entscheidung.
Wie schätze ich ein, was für mein Produkt gilt?
Die kurze Antwort: durch eine ehrliche Risikobewertung.
Nicht durch blindes Abhaken aller dreizehn Punkte aus Anhang I, Teil I, Punkt (2), und auch nicht durch das bequeme “bei uns ist ja alles nicht so kritisch”.
Erwägungsgrund 54 macht die Richtung deutlich: Hersteller sollen bestimmen, “welche anderen grundlegenden Cybersicherheitsanforderungen in Bezug auf die Produkteigenschaften für die betreffende Art von Produkten mit digitalen Elementen von Bedeutung sind.”
Die Anwendbarkeitsprüfung aus Artikel 13(3) bezieht sich dabei auf die Produktanforderungen aus Anhang I, Teil I, Punkt (2). Die Anforderungen an die Behandlung von Schwachstellen aus Teil II sind davon getrennt geregelt.
Bei den Produktanforderungen aus Teil I, Punkt (2), kommt es auf Fragen an wie:
- Welche Daten verarbeitet mein Produkt? Personenbezogene? Sicherheitskritische? Gar keine?
- Was passiert im schlimmsten Fall, wenn das Produkt kompromittiert wird?
- Ist das Produkt vernetzt? Erreichbar aus dem Internet? Teil einer kritischen Infrastruktur?
- Kann ein kompromittiertes Gerät andere Geräte oder Netzwerke beeinflussen?
Die Fragen helfen dabei, zwei Dinge greifbarer zu machen: Welche Auswirkungen hätte eine erfolgreiche Kompromittierung, und wie realistisch und relevant ist das jeweilige Bedrohungsszenario für das konkrete Produkt und seinen Einsatzkontext? Erst wenn beides zusammen betrachtet wird, entsteht eine belastbare Einschätzung des Cybersicherheitsrisikos. Daraus lässt sich ableiten, welche Anforderungen aus Anhang I, Teil I, Punkt (2), für das Produkt relevant sind und in welcher Form sie berücksichtigt werden müssen.
Was der CRA für den Entwicklungsalltag bedeutet
Im Kern fordert der CRA das, was gute Softwareentwicklung schon vor zwanzig Jahren hätte sein sollen: Risiken bewerten, bewusst entwerfen, Aktualisierungen ermöglichen, Schwachstellen ernst nehmen.
Wir versuchen seit über zehn Jahren, unseren Kunden genau das zu vermitteln. Wer das in den letzten Jahren bereits gelebt hat, wird in den meisten Anforderungen nichts grundlegend Überraschendes finden.
Neu ist allerdings der regulatorische Rahmen drumherum: Nachweisbarkeit, Meldewege, technische Dokumentation und EU-Konformitätserklärungen.
Der CRA bringt den üblichen regulatorischen Mehraufwand mit, den man aus anderen Bereichen kennt. Und hier liegt eine der echten Herausforderungen: diesen Papierkram so in den Entwickleralltag zu integrieren, dass er nicht zum Fremdkörper wird. Dass er nicht neben der eigentlichen Arbeit steht, sondern Teil davon ist.
Spätestens mit der vollständigen Anwendung des CRA wird genau das zu einer zentralen Aufgabe im Entwicklungsalltag.
Was kommt als Nächstes?
Dieser Artikel ist der Auftakt zu einer Serie.
In den folgenden Beiträgen nehmen wir uns jeweils eine der dreizehn Anforderungen aus Anhang I, Teil I, Punkt (2), einzeln vor. Jeder Artikel wird den jeweiligen Punkt einordnen, erklären, was er in der Praxis bedeutet, und diskutieren, für welche Produkttypen er besonders relevant ist und für welche eher nicht.
Ziel ist, die Anforderungen so zu übersetzen, dass man als technischer Leiter einschätzen kann: Was muss ich tun, was kann ich begründet lassen, und wo fange ich am besten an?