Wie die Cybersecurity von Produkten 2024 reguliert wird [German version]

Ein Überblick

Cybersicherheit kritischer Infrastrukturen wird seit Jahren reguliert, und in Europa gibt es derzeit viel Wirbel um die NIS-2-Richtlinie, die den Anwendungsbereich dieser Regulierung stark erweitert. Gleichzeitig werden aber erstmals neben Produktnutzern und -betreibern (z. B. in kritischen Infrastrukturen) auch Produktanbieter reguliert. Zeit für einen Überblick über die Regulierungslandschaft zum Thema Cybersecurity für Produkte 2024.

• In der EU ist die Richtlinie über Funkanlagen (RED), die sich mit der Cybersicherheit aller drahtlos kommunizierenden Geräte befasst, bereits in Kraft, und der Cyber Resilience Act (CRA), der Cybersicherheit zu einer Marktzutrittsschranke für fast ALLE Produkte macht, wird wahrscheinlich noch in diesem Jahr in Kraft treten.
• Im Vereinigten Königreich ist der Product Security and Telecommunications Infrastructure Act (PSTI), der dem CRA ähnelt, bereits in Kraft.
• Für Autos gibt es zwei neue UN-Regelungen (UNECE R 155 und R 156), die seit diesem Sommer gelten und Cybersicherheit zu einer zwingenden Voraussetzung für die Typgenehmigung von Autos machen. Dies hat bereits dazu geführt, dass einige Volkswagen- und Porsche-Modelle vom Markt genommen wurden. Wenn Sie sich gefragt haben, warum Sie keinen Volkswagen Up oder Porsche Cayman mehr kaufen können — jetzt wissen Sie es.
• Darüber hinaus werden in vielen Ländern freiwillige Labels für die Cybersicherheit von Produkten entwickelt, oft speziell für das Internet der Dinge (IoT). Oft werden diese Kennzeichen gegenseitig anerkannt, zum Beispiel zwischen Singapur und Deutschland sowie Singapur und Finnland. Singapur führt auch eine Initiative zum Entwurf einer ISO-Norm (ISO/IEC 27404) für IoT-Cybersicherheitslabels an, die auf den Erfahrungen mit Singapurs eigenem Cybersicherheitslabel für IoT-Verbraucher basiert.
• Zwar keine Regulierung, aber die US-Behörde CISA (Cybersecurity & Infrastructure Security Agency) betreibt momentan eine „Security by Design“-Initiative, die auch ein „Secure by Design“-Pledge beinhaltet. Beteiligte Produkthersteller verpflichten sich, Security während der Entwicklung ihrer Produkte zu berücksichtigen.

Ziele

Die Ziele all dieser Initiativen sind sehr ähnlich. Hier sind sie:

1. Produkte werden sicherer (bzw. haben weniger Schwachstellen)
2. Die Hersteller nehmen die Cybersecurity ernst (oft kann man hier ein „endlich“ hinzufügen). Und zwar während des gesamten Produktlebenszyklus, d. h. es werden auch dann noch Security-Updates bereitgestellt, wenn das Produkt schon in Gebrauch ist.
3. Die Nutzer — oder Käufer — können beim Kauf oder der Nutzung des Produkts fundierte Entscheidungen zur Cybersicherheit treffen.
4. Sensibilisierung für bestehende Cybersicherheits-Industriestandards oder sogar deren Durchsetzung.

Regulierungen sind etwas anderes als Standards, deshalb ist dieses Ziel Nummer 4 so wichtig. Für den CRA sind die durchzusetzenden Normen eine längere Liste von harmonisierten EU-Normen, kurz hENs, die noch festgelegt werden müssen. (IEC 62443 ist ein heißer Kandidat für OT-Produkte).

Für den PSTI soll die IoT-Norm EN 303645 befolgt werden.

Für die UNECE-Regluierung der Standard ISO / SAE 21434 für Cybersecurity-Engineering in der Automobilindustrie.

Bei den IoT-Labels hängt der genaue Standard vom Land und vom Label ab, aber meistens wird auf mindestens einen verwiesen.

Und dann gibt es speziell für den CRA ein weiteres Ziel, das oft übersehen wird. Der CRA, der nur kurz nach der neuen Verordnung über kritische Infrastrukturen (NIS-2) in Europa in Kraft tritt, hat nämlich auch das Ziel, den Betreibern kritischer Infrastrukturen das Leben leichter zu machen. Sie sind für die Cybersecurity ihrer Anlagen verantwortlich und hatten in der Vergangenheit oft Schwierigkeiten, von ihren Produktlieferanten ausreichend sichere Komponenten zu verlangen (und / oder geeignete Informationen, um die Security der gekauften Komponenten zu beurteilen). Der CRA wird bei beidem helfen: bei den Security-Eigenschaften der Produkte und ihrer Dokumentation.

Striktheit und Strategie

Hier ist ein Überblick darüber was man als Striktheit der Regulierungen bezeichnen könnte. Striktere Regulierungen zwingen Produkthersteller, mehr zu tun:

Eine Regularie ist strikter, wenn sie nicht freiwillig ist, sondern eine echte Markteintrittshürde für Produkte darstellt: Man darf sein Produkt nicht mehr verkaufen, wenn man die Compliance nicht nachweisen kann (y-Achse). Außerdem kann man davon ausgehen, dass Hersteller eine Vorschrift ernster nehmen, wenn sie sich für den Konformitätsnachweis einer Bewertung durch Dritte unterziehen müssen, als wenn sie die Konformität einfach selbst erklären können (x-Achse).

In dieser Landschaft findet sich das „Secure by Design“-Pledge der CISA — wenig überraschend, da es sich nicht um eine Regulierung handelt! — in der unteren linken Ecke, ist also am wenigsten strikt: Es ist freiwillig, und die Hersteller geben eine Selbsterklärung ab.

Dasselbe gilt für IoT-Kennzeichnungssysteme, die auf einer Selbsterklärung beruhen, aber in einigen Ländern eine Bewertung durch eine dritte Partei erfordern. Übrigens können die ISA/IEC 62443-Zertifikate als ein weiteres freiwilliges Produktsicherheitskennzeichen eingestuft werden, das eine Bewertung durch Dritte erfordert — auch wenn auch diese Zertifikate natürlich nicht mit Regulierungen gleichzusetzen sind, da sie von keiner Regierung gefordert werden.

Im Gegensatz zu diesen freiwilligen Kennzeichen gibt es allerdings auch die veritablen Markteintrittshürden:

In the UK for example, the government has been trying to convince manufacturers to follow the secure by design principles for IoT outlined in EN ETSI 303645. The standard was internationally recognized. Everybody agreed it was good. But few people implemented it. That‘s why the UK government now mandates product security for consumer IoT in ist PSTI act. It’s based on self-declaration though, so still not in the upper right corner of the rigor landscape.

In Großbritannien zum Beispiel hat die Regierung zunächst ohne strikte Regulierung versucht, die Hersteller davon zu überzeugen, die in EN ETSI 303645 dargelegten Security by Design-Grundsätze für das Internet der Dinge zu befolgen. Die Norm war international anerkannt. Alle waren sich einig, dass sie gut ist. Aber nur wenige haben sie umgesetzt. Deshalb schreibt die britische Regierung jetzt in ihrem PSTI Act die Cybersecuirty für Verbraucher-IoT-Produkte gemäß EN ETSI 303645 vor. Der PSTI-Act basiert allerdings auf einer Selbererklärung, ist also immer noch nicht das Ende der Fahnenstange, was die Striktheit der Regulierung angeht.

Die UN und die EU gehen mit R 155/156, RED und CRA einen Schritt weiter: Sie kombinieren eine echte Markteintrittshürde mit einer Bewertung durch Dritte. Sie erreichen dies, indem sie Cybersecurity in bestehende Mechanismen für Markteintrittshürden einbauen:

• Für Autos gab es bereits eine von der UNECE durchgesetzte Fahrzeugtypgenehmigung. Jedes Fahrzeug muss sie durchlaufen, bevor es auf den UNECE-Märkten verkauft werden darf — und das umfasst weit mehr als die EU: zum Beispiel gehören auch USA, das Großbritannien und Russland zu den UNECE-Mitgliedern.
• Auf dem europäischen Markt gibt es für viele Produkte bereits das CE-Kennzeichnen. Bislang gab es vor allem Vorschriften für die Safety der Produkte— zum Beispiel für Sonnenbrillen, Druckbehälter oder Kinderspielzeug.

Der Vorteil bei der Nutzung bestehender Markteintrittshürden besteht darin, dass die Strukturen zur Durchsetzung — Marktüberwachungsbehörden, Standardisierungsorganisationen und Prüfinstitute — bereits vorhanden sind.

Die UNECE R155 und R156 und der CRA haben also den höchsten Grad an Striktheit, den eine Regulierung erreichen kann:

Nicht nur, dass die Produkte zwingend Cybersecurity-Anforderungen erfüllen müssen (sonst dürfen sie nicht mehr verkauft werden) — die Einhaltung dieser Anforderungen wird auch durch Dritte überprüft.

Etwas vereinfachend gibt es also zwei verschiedene Strategien, die eine Regierung für die Cybersecurity von Produkten verfolgen kann:

Security als Selbstverständlichkeit

Sie können die Hersteller und ihre Kunden dazu ermutigen, Security als eine Selbstverständlichkeit zu betrachten. Security ist etwas, über das man nicht mehr viel nachdenken muss, sondern das in die Produkte eingebaut ist, ähnlich wie Autos, die immer einen Sicherheitsgurt haben. Es gibt keine Produkte mehr, die nicht zumindest über einige grundlegende Cybersicherheitsmerkmale verfügen. Damit werden Käufer davor geschützt, ein Produkt ohne grundlegende Cybersecurity zu kaufen.

Security als Wettbewerbsvorteil

Oder sie können die Hersteller und ihre Kunden ermutigen, Security als Wettbewerbsvorteil zu sehen. Sie lassen Produktanbieter darum konkurrieren, wer die beste Security integriert hat, und vertrauen darauf, dass die Kunden die sichereren Lösungen bevorzugen. Sie ermöglichen es Käufern, eine informierte Kaufentscheidung hinsichtlich Security zu treffen — wenn sie dies wollen.

Regularien, die auf Markteintrittshürden abzielen, folgen eher der Strategie „Security als Selbstverständlichkeit“, während freiwillige Security-Labels eher der Strategie “Security als Wettbewerbsvorteil” zuzuordnen sind.

Aber natürlich ist die Welt nicht so schwarz-weiß. Man kann einige Security-Merkmale als Selbstverständlichkeit durchsetzen und Käufern zusätzlich Informationen zur Verfügung stellen, damit sie über andere Merkmale selbst entscheiden können. Und so machen es die Regulierungen, die Markteintrittshürden stellen, in der Regel auch.

Geltungsbereich

Bis hierher haben wir nur betrachtet, wie sich die Produkt-Security-Regulierungen in Bezug auf Ziele und Strategie unterscheiden, aber natürlich gibt es auch Unterschiede bei ihren Anwendungsbereichen:

• Die meisten IoT-Labels sind für IoT-Produkte für private Verbraucher gedacht.
• Ähnlich verhält es sich beim PSTI-Act.
• Die RED-Direktive betrifft nur Funkgeräte (und damit natürlich auch manche Verbraucher-IoT-Produkte).
• Das Secure-by-Design-Pledge der CISA richtet sich an Softwarehersteller (natürlich ist in IoT-Produkten auch Software enthalten, also gibt es auch da Überlappungen) .
• Dann gibt es die UNECE-Regulierung, die Fahrzeuge betrifft (die natürlich wiederum Funkgeräte und Software enthalten können, aber das wird nun kompliziert in der Darstellung).
• Und dann gibt es den Cyber Resilience Act (CRA), der ALLE der oben genannten Produkt umfasst (außer die Autos — die sind explizit ausgenommen, da ja schon woanders reguliert).

Für den Fall, dass Sie sich nun fragen, wo Operational Technology (OT) auf dieser Landkarte zu finden ist: Die habe ich in gelb in der obenstehenden Grafik eingezeichnet. Jede der Verordnungen betrifft auch ein wenig OT, aber keine davon ist wirklich für OT geschrieben — und das erklärt, warum sie für OT-Produkte oft nicht so richtig gut zu passen scheinen.

Anforderungen

Letzte Frage: Wenn Ihre Produkt unter eine dieser Regularien fällt — was müssen Sie dann eigentlich konkret tun?

Im untenstehenden Bild sehen Sie einige typische Anforderungen. Einige oder alle von ihnen finden sich in allen oben genannten Regularien wieder. Sie lassen sich grob in drei Kategorien einteilen:

Prävention von Sicherheitsvorfällen — Ihre “Zahnbürste”: alltägliche Maßnahmen und Grundsätze, die Sie bei der Entwicklung befolgen sollten, um Ihr Produkt so frei von Security-Schwachstellen wie möglich zu halten. Hier finden Sie zum Beispiel Security by Design-Prinzipien.

Notfallvorsorge für Sicherheitsvorfälle — Ihr Reifenstapel: alles, was dazu beiträgt, dass Sie im Falle eines Sicherheitsvorfalls weniger hart aufprallen: Maßnahmen zur Verringerung der Auswirkungen (wie Backups, Failover oder Safety-Funktionen).

Bewältigung von Sicherheitsvorfällen — Ihr Feuerwehrschlauch: alles, was Sie brauchen, um das Feuer schnell zu löschen, also einen Vorfall professionell zu bewältigen. Dazu gehören Prozesse, um schnell gute Security-Advisories und Security-Updates bereitzustellen.

Dass die Product-Security-Regularien hinsichtlich dieser Anforderungen alle so ähnlich sind, ist ein gutes Zeichen. Diese Anforderungen sind nicht umstritten, Sie können als ziemlich ausgereift angesehen werden. Es besteht ein breiter Konsens darüber, dass die Umsetzung dieser Maßnahmen eine gute Idee ist. Der gesamte Prozess der Ausarbeitung und Verhandlung des CRA war ein guter Indikator dafür: Obwohl er gewaltige Auswirkugen hat, hat nemand in Frage gestellt, dass der CRA notwendig ist. Alle Debatten drehten sich nur um Details der Umsetzung, z. B. ob Open-Source-Software in den Geltungsbereich gehört oder wie der Zeitraum für die Bereitstellung von Security-Updates definiert werden sollte.

Was heißt das in der Praxis?

Wirklich interessant wird es nun zu beobachten, wie all diese Regularien tatsächlich praktisch umgesetzt werden. Regularien sind naturgemäß immer ein wenig vage. Derzeit beobachten daher auch viele Produkthersteller nervös ihre Wettbewerber und fragen sich, wie alle anderen wohl die Produktsicherheit angehen werden.

Welche Security-Merkmale tatsächlich zur neuen Selbstverständlichkeit werden und wie die Security-Dokumentation typischerweise aussehen wird, hängt davon ab, was der Markt verlangt, was die Behörden prüfen und fordern, ob und wie hoch die Strafen für die Nichteinhaltung sind und wie die ersten erfolgreichen CRA-Umsetzungen aussehen (die wahrscheinlich oft kopiert werden).

So war es schon bei der Regulierung kritischer Infrastrukturen (EU: NIS), bei der Datenschutzregulierung (EU: DSGVO), und jetzt beginnt dieser Prozess eben für die Cybersecurity von Produkten.

Jetzt ist also die richtige Zeit, um als Betreiber kritischer Infrastrukturen Forderungen zu stellen und damit Standards zu setzen.

Jetzt ist auch die richtige Zeit, um als Produkthersteller voranzugehen, wenn Sie für vorbildliche Security bekannt sein wollen (siehe diesen weiterführenden Text darüber, wie das für den CRA aussehen könnte).