Welche Cybersecurity-Standards müssen Produkte in der EU bald erfüllen? [German Version]

Die Standardisierung für den Cyber Resilience Act (CRA) hat begonnen

Produkte “mit digitalen Elementen” müssen bald Cybersecurity-Auflagen erfüllen, um in der EU verkauft werden zu dürfen. Welche genau, das wird gerade erarbeitet. — Image generated by Midjourney

Es ist verständlicherweise die häufigste Frage, die ich zum Cyber Resilience Acts (CRA) bekomme: “Weiß man schon, welche Cybersecurity-Normen die Produkte werden erfüllen müssen?”
Lange war die Antwort “nein” — aber nun kommen wir ihr näher. Der Entstehungsprozess des CRA ist nämlich diesen Monat einen von der Öffentlichkeit kaum wahrgenommenen, aber dennoch wichtigen Schritt vorangegangen. Halten Sie sich fest:

Da der CRA das NLF unterstützt, haben CEN/CENELEC einen SReq erhalten, um hENs zu entwickeln.

Äh, was?
Klamüsern wir das mal auseinandern. Holen Sie sich lieber vorher einen Kaffee, das braucht jetzt ein bisschen.

CRA = Security ins CE-Kennzeichen

Sie erinnern sich vielleicht: Der CRA bedeutet nicht mehr und nicht weniger, als dass Security Teil des europäischen CE-Kennzeichens wird. Das ist keine kleine Sache, denn das CE-Kennzeichen ist nicht nur eine große Erfolgsgeschichte (wenn man einmal im Alltag anfängt, darauf zu achten, sieht man es überall), sondern auch ein komplexes Konstrukt. Darin verborgen stecken eine Menge EU-Werte.

Ziele des “New Approach” und “New Legislative Frameworks” (NLF): Weder Überregulierung noch Regulierungswirrwarr

Kleiner Exkurs in die Geschichte der “Conformité Européenne”, denn dafür steht “CE”: Die Geburtsstunde des Konzepts ist der 7. Mai 1985 bzw. der 21. Dezember 1989. Damals sind der “New Approach” für die Produktregulierung und das Gesamtkonzept für die EU-Konformitätsbewertung durch den europäischen Rat beschlossen worden.

Dem Wort “New Approach” kann man ansehen, dass es Schmerzpunkte gegeben haben muss, die eine Neuerung nötig machten. Und die gab es: Jeder EU-Mitgliedsstaat hatte andere Regeln für die Regulierung von Produkten, und dieser Regulierungswirrwarr machte es für Produkthersteller schwer, ihre Produkte in andere EU-Staaten zu exportieren.
Das CE-Konzept fußt deswegen seit seiner Geburt auf wichtigen Grundsätzen:

• Keine Überregulierung: Die Regulierung von Produkten durch die EU und ihre Mitgliedsstaaten soll auf ein unentbehrliches Mindestmaß beschränkt werden, die sogenannten “wesentlichen Anforderungen”. Damit soll der Handlungsspielraum der Industrie und der technische Fortschritt gefördert werden.
• Risikobasierter Ansatz: Es ist klar geregelt, welche Produkte überhaupt ein CE-Kennzeichen brauchen — und das hängt von ihrem Risikopotential ab. Das bedeutet auch, dass alle anderen Produkte kein CE-Kennzeichen tragen dürfen.
• Einheitliche, verlässliche Anforderungen: EU-Richtlinien (und auch ihre Umsetzung in nationale Gesetze) sind nicht der richtige Ort, um detaillierte technische Anforderungen festzulegen: Erstens ändern sich solche Anforderungen tendenziell schneller als ein Gesetz. Zweitens gibt es für technische Anforderungen aus gutem Grund konsensbasierte Normungsverfahren, um die Expertise einer ganzen Industrie abzubilden. Daher bedient sich das CE-Konzept dieser Expertise, indem es auf EU-weit geltende Normen verweist — die heißen dann “harmonisierte europäische Normen (hEN)”. Erfüllt ein Produkt diese Normen, ist die Übereinstimmung mit der CE-Richtlinie für dieses Produkt anzunehmen “Konformitätsvermutung”. Das schafft Klarheit und Verlässlichkeit für Produkthersteller.
• Freie Wahl der technischen Lösung: Es bleibt dem Produkthersteller überlassen, ob er die harmonisierten Normen anwendet oder sich für eine andere technische Spezifikation entscheidet. Ebenso darf nicht vorgeschrieben werden, welche technische Lösung für die Umsetzung der Anforderungen gewählt wird.

2008 kam dann noch das New Legislative Framework (NLF) hinzu. Es erweitert und vereinheitlicht das bestehende Konzept und enthält auch wichtige Begriffsdefinitionen — einige davon werden wir noch brauchen. Eine wichtige inhaltliche Ergänzung war die Ausweitung der Herstellerpflichten über das “Inverkehrbringen” hinaus: Meldepflichten bei Gefahren und Rückrufmanagement bei Verdacht auf “Konformitätsmängel”. Und eine Risikoanalyse wurde auch zur Pflicht.
Sie ahnen es schon: Deswegen ist im CRA das Schwachstellenmanagement für eine bestimmte Zeit nach Verkauf des Produkts so prominent verankert. Denn diese Grundsätze muss der CRA natürlich auch auf die Cybersecurity übertragen. Cybersecurity ins CE-Kennzeichen zu integrieren bedeutet eben, dass man nicht mit einem weißen Blatt beginnt, sondern buchstäblich auf der Basis von dutzenden Seiten eng bedruckten Papiers — das Produkt jahrelangen Verhandelns, Interessensausgleichs und Lernens aus der Praxis. Beim Thema Produktregulierung ist die EU nun wirklich ein “alter Hase”.

Deswegen ist es wichtig zu verstehen, welche Werte hinter diesem Papier stehen — eben nicht der der EU grundsätzlich immer vorgeworfene “Regulierungswahn”. Besser fasst es vielleicht das hier zusammen:
The CRA is standing On the shoulders of giants — mit allen Vor- und Nachteilen.

Hersteller, Inverkehrbringer: Wer ist für die CE-Konformität der Produkte verantwortlich?

Einen Begriff müssen wir noch schnell einführen, bevor es ans Eingemachte geht: Das “Inverkehrbringen”.
Der Begriff ist in der Beschluss 768/2008/EC (Teil des New Legislative Frameworks) definiert als “die erstmalige Bereitstellung eines Produkts auf dem Gemeinschaftsmarkt”.
(Die englische Übersetzung ist übrigens “placing on the market”: “the first making available of a product on the Community market”).

Das Inverkehrbringen definiert also einen Zeitpunkt, und zu diesem Zeitpunkt muss das CE-Kennzeichen angebracht sein. Der Hersteller ist derjenige, der das Konformitätsbewertungsverfahren durchführen und das CE-Kennzeichen anbringen muss. Aber es kann natürlich sein, dass jemand anders das Produkt “in Verkehr bringt”: Ein Händler oder ein Importeur (“Einführer”). Importeuere müssen “gewährleisten”, Händler “überprüfen”, dass der Hersteller das Konformitätsbewertungsverfahren durchgeführt und das CE-Kennzeichen angebracht hat.

Es gibt eine Bedingung, die dazu führt, dass der Händler oder Importeur die Pflichten des Herstellers übernehmen muss, also selbst die Konformitätsbewertung durchführen muss — nachzulesen im Beschluss 768/2008/EC, Artikel R6: Nämlich wenn er “ein Produkt unter seinem eigenen Namen oder seiner eigenen Marke in Verkehr bringt oder ein bereits auf dem Markt befindliches Produkt so ändert, dass die Konformität mit den geltenden Anforderungen beeinträchtigt werden kann”.

Und hier schließt sich der Kreis zur Diskussion über die Security-Verantwortung für Open-Source-Software aus dem letzten Monat: Die Open-Source-Community setzt sich dafür ein, dass für Open-Source-Software genau diese Bedingung gelten soll. Das ist gemeint, wenn davon die Rede ist, dass der “Inverkehrbringer” der Software für ihr CE-Kennzeichen verantwortlich sein soll.

Übrigens: Den im Deutschen im Zusammenhang mit dem CE-Kennzeichen häufig verwendeten Begriff “Inverkehrbringer” gibt es in der EU-Gesetzgebung gar nicht. Es gibt nur das “Inverkehrbringen”, das einen Zeitpunkt im Produktlebenszyklus kennzeichnet. Den “Inverkehrbringer” könnte man vereinfacht zusammenfassen als den “Hersteller, Einführer oder Händler, der das Produkt erstmals auf dem Gemeinschaftsmarkt bereitstellt”.

Harmonisierte europäische Normen (hEN): Die konkreten Anforderungen, die Produkte erfüllen müssen

So, jetzt wird es endlich konkret. Wenn nun also ein Hersteller (oder “Inverkehrbringer” ein CE-Kennzeichen braucht, interessiert ihn eher weniger der Gesetzgebungswust von oben, sondern umso mehr: “Was muss das Produkt denn jetzt können”? Und damit kommen wir zu den harmonisierten europäischen Normen (hEN).

Eine Norm muss ein paar Bedingungen erfüllen, damit sie eine hEN werden kann.
Schauen wir noch einmal in den Beschluss 768/2008/EC: Eine harmonisierte Norm ist eine “Norm, die von einem der in Anhang I der Richtlinie 98/34/EG anerkannten europäischen Normungsgremien auf der Grundlage eines Ersuchens der Kommission nach Artikel 6 jener Richtlinie erstellt wurde”. Super, machste eine EU-Richtlinie auf, kriegste einen Verweis auf die nächste (die übrigens schon gar nicht mehr in Kraft ist).

Ich erspare Ihnen das — wir kürzen ein wenig ab:

1. Eine europäische Norm muss von einer europäischen Normungsorganisation (CEN, Cenelec und ETSI) verabschiedet werden.
2. Eine harmonisierte Norm ist (verkürzt gesagt) eine europäische Norm, die die Vermutungswirkung für das CE-Kennzeichen erfüllt und von der EU-Kommission angefordert wurde.
3. Die EU-Kommission kann CEN, Cenelec und ETSI mit der Erarbeitung von Normen in einer bestimmten Frist beauftragen. Die Normen müssen “marktorientiert sein, dem öffentlichen Interesse und den in dem Auftrag der Kommission klar dargelegten politischen Zielen Rechnung tragen und auf Konsens gegründet sein.”
4. Sobald es eine harmonisierte Norm zu einem Thema gibt, darf es keine nationalen Normen mehr geben, die dieser Norm widersprechen oder auch nur nicht vollständig entsprechen.

Nachlesen können Sie all das in der EU-Regulierung 1025/2012.

Eine harmonisierte Norm ist also ein überaus wichtiges Dokument. Es regelt, welche Anforderungen in einem bestimmten Bereich (z.B. Cybersecurity) tatsächlich gelten, um ein CE-Kennzeichen zu bekommen (ohne das das Produkt nicht auf den EU-Markt darf).
Doch damit nicht genug: Wenn es eine harmonisierte Norm gibt, müssen alle nationalen Normen zum selben Thema zurückgezogen werden. Das hat gute Gründe: die EU möchte ja Regulierungswirrwarr vermeiden.

Trotzdem bedeutet es, dass sich nun auf EU-Ebene bald entscheiden muss, welche Cybersecurity-Norm “das Rennen macht” und welche in der Irrelevanz (aka Archiv der “zurückgezogenen Normen”) verschwindet.

Das ist neu. Bislang gab es ja kein CE-Kennzeichen für Cybersecurity, und somit auch keine harmonisierten Cybersecurity-Normen. Bislang konnten verschiedene nationale und internationel Nomen gemütlich nebeneinanderherexistieren. Das geht bald nicht mehr. Die ein oder andere DIN-, VDI- oder VDE-Norm zur Cybersecurity wird also demnächst verschwinden, und möglicherweise die ein oder andere ISO- oder IEC-Norm an Bedeutung gewinnen oder verlieren.
Oder es entstehen ganz neue Normen, die wird jetzt noch gar nicht kennen.

Draft Standardization Request (SReq): Bald werden die Normen für den CRA ausgewählt (oder geschrieben)

So. Jetzt haben Sie alles Rüstzeug, um die Bedeutung des Statements ganz oben zu verstehen:

Da der CRA das NLF unterstützt, haben CEN/CENELEC einen SReq erhalten, um hENs zu entwickeln.

Jetzt klarer, oder?

Die CRA-Umsetzung soll nicht im Regulierungswirrwarr enden (das sagt das New Legislation Framework, NLF). Deswegen müssen die europäischen Normungsorganisationen CEN / CENELEC nun entscheiden, welche Normen (harmonisierte europäische Normen, hEN) für die Umsetzung des CRA relevant werden (“die Vermutungswirkung erfüllen”) — und möglicherweise ganz neue Normen schreiben.
Der Prozess dafür beginnt, sobald CEN/CENELEC von der EU-Kommission einen Standardization Request (SReq) erhalten, den sie dann beantworten müssen. Da der CRA noch nicht verabschiedet ist, haben CEN/CENELEC vorab einen Entwurf des geplanten SReq zur Kommentierung erhalten. So kann der Standardisierungsprozess möglichst früh (jetzt schon!) beginnen.

Normung funktioniert so, dass nationale Normungsorganisationen (wie DIN und DKE in Deutschland) sogenannte “Experten” an europäische Organisation (wie CEN/CENELEC) entsenden. Ich bin als Expertin in der DKE tätig, unter anderem für die Mitarbeit an der ISA/IEC 62443. Daher liegt mir der Draft Standardization Request (SReq) vor — und wir können zusammen einen kleinen Blick hineinwerfen:

Das Dokument hat drei Teile:

1. Den Haupttext, der den Bezug zum (noch nicht verabschiedeten) Cyber Resilience Act erklärt und von den Adressaten (CEN / CENELEC) die Erarbeitung von Standards oder die Revision existierender Standards einfordert.
2. Den ersten Annex, der detailliert die Inhalte der zu erstellenden / revidierenden Standards auflistet. Er is aufgeteilt in produktübergreifende Security-Anforderungen, produktspezifische Security-Anforderungen und Anforderungen an das Schwachstellenmanagement. Bei den produktspezifischen Anforderungen werden explizit auch Anforderungen an industrielle Automatisierungssysteme, SPSen, IoT etc. gefordert. Außerdem sind Deadlines angegeben, die zwischen Ende Mai 2025 und Ende Mai 2026 liegen.
3. Den zweiten Annex, der formale und inhaltliche Anforderungen enthält, die die entwickelten / revidierten Standards erfüllen müssen. Das sind durchaus sehr konkrete inhaltliche Vorgaben — etwa die Notwendigkeit, Anforderungen für sichere Softwareentwicklung und SBOMs zu definieren.

Warum ist das wichtig?

Fassen wir noch einmal zusammen, warum die Existenz des Draft Standardization Request (SReq) für den CRA so eine große Nachricht ist:

Wir wissen sicher, dass in den nächsten drei Jahren europäische Standards entstehen oder bestehende Standards als europäische Standards verabschiedet werden, die entscheiden, welche Security-Anforderungen Produkthersteller (bzw. “Inverkehrbringer”) erfüllen müssen, um ihr Produkt in der EU verkaufen zu können. Und im SReq ist auch schon recht deutlich erahnbar, was in diesen Standards stehen wird — teilweise, weil es explizit gefordert ist (siehe SBOMs und Co), teilweise gibt es Hinweise in den Metadaten und zwischen den Zeilen.

Für industrielle Automatisierungssysteme konkret diese beiden:

Erstens: Der Draft SReq wurde auch ans technische Komittee CLC/TC 65X geschickt, das “bereits als relevant identifiziert wurde”. Das TC 65X ist das Bindeglied des IEC-Komittees TC 65 (internationale Standardisierung) in die europäische Standardisierung beim CENELEC. Und das TC 65 ist verantwortlich für eine internationale Normenreihe, von der Sie sicher schon gehört haben: Die ISA/IEC 62443. Die EU-Kommission erwartet also offenbar, dass die ISA/IEC 62443 eine Rolle bei der Auswahl der harmonisierten Normen spielen könnte.

Zweitens die Formulierung im SReq-Anhang: “IACS”, Industrial Automation and Control Systems, ist ein Begriff, der von der ISA geprägt und verwendet wird — und nicht von vielen anderen Organisationen.

Der SReq gibt inhaltlich noch mehr her, wenn man sich im Detail mit ihm befasst. Für heute sprengt das hier den Rahmen… aber wenn Sie Interesse haben, knöpfen wir uns das Dokument bald noch einmal im Detail vor.

Wie geht es jetzt weiter?

Beim CEN/CENELEC wird nun eine “Standardization Request Ad Hoc Group (SRAHG)” einberufen, die sich um die Beantwortung des SReq (und die Kommentierung des Entwurfs) kümmert. Dort wird also entschieden, welche harmonisierten europäischen Normen (hEN) künftig definieren, welche Security-Anforderungen in der EU verkaufte Produkte erfüllen müssen. Klingt spannend? Finde ich auch. Ich bleibe dran, versprochen.

Dieser Beitrag ist als Teil des monatlichen “Security-Briefings für Hard Hats” erschienen.