Freund oder Feind? So oder so, der Cyber ​​Resilience Act kommt

Die Europäische Kommission hat Technologieanbieter und -verkäufer im Visier. Verbraucher und Unternehmen leiden schon zu lange unter schlecht konzipierter, konstruierter und gewarteter Software und Hardware. Es wird behauptet, dass die Wirtschaft der Cyberkriminalität der Hauptnutznießer dieser Versäumnisse ist, die nach Angaben der Kommission im Jahr 5.5 einen Wert von 4.7 Billionen Euro (2021 Billionen Pfund) hatten. Das Ausmaß der Herausforderung ist enorm. Die Anzahl neuer Software-Schwachstellen von der US-Regierung gemeldet im Jahr 2022 stieg die Zahl jährlich um ein Viertel auf 25,096 – ein weiterer Rekordwert.

Die Antwort der EU ist der Cyber ​​Resilience Act (CRA). Obwohl die Ausarbeitung noch nicht abgeschlossen ist, haben einige argumentiert, dass seine Bestimmungen eine Bedrohung für die Open-Source-Community darstellen und sogar die digitale Welt weniger sicher machen könnten.

Was steht im CRA?

Ziel des CRA ist es, Verbraucher und Unternehmen beim Kauf von Produkten mit einer „digitalen Komponente“ zu schützen. Es versucht anzusprechen zwei zentrale Herausforderungen:

• Die in vielen Produkten integrierten Cybersicherheitsmaßnahmen, einschließlich Software und angeschlossenen Geräten wie intelligenten Babyphones, und/oder unzureichende Updates für Software und Geräte
• Das Fehlen eines branchenweiten „Drachenzeichens“, das Technologiekäufern helfen könnte, besser zu verstehen, welche Produkte sicher sind und wie sie sicher eingerichtet werden können

In diesem Sinne ist die CRA-Ziele zu:

• Harmonisieren Sie die Regeln für Hersteller und Einzelhändler, die digitale Produkte entwickeln/verkaufen, in der gesamten Union
• Führen Sie eine Reihe strenger Cybersicherheitsanforderungen auf, die „die Planung, das Design, die Entwicklung und die Wartung“ dieser Produkte regeln
• Verpflichten Sie relevante Hersteller/Wiederverkäufer zu einer Sorgfaltspflicht für den gesamten Lebenszyklus digitaler Produkte
• Führen Sie ein neues CE-Zeichen ein, das darauf hinweist, dass Produkte CRA-konform sind. Dies soll Herstellern und Einzelhändlern einen Anreiz geben, der Sicherheit Priorität einzuräumen, und es IT-Käufern ermöglichen, fundiertere Entscheidungen zu treffen

Was ist abgedeckt und was ist erforderlich?

So wie es steht, die Gesetzgebung „gilt für alle Produkte, die direkt oder indirekt mit einem anderen Gerät oder Netzwerk verbunden sind, mit Ausnahme bestimmter Ausschlüsse wie Open-Source-Software oder Dienste, die bereits durch bestehende Regeln abgedeckt sind, was für medizinische Geräte, Luftfahrt und Autos der Fall ist.“

Diese Produkte sind in drei Kategorien unterteilt:

Standard: Produkte mit geringem Risiko wie intelligente Spielzeuge und Kühlschränke, Videospiele und andere häufig verwendete Software und Geräte, die nach Angaben der Kommission 90 % des Marktes abdecken. Unternehmen müssen eine Selbstbewertung durchführen, um sicherzustellen, dass ein Produkt den relevanten Sicherheitsstandards entspricht.

Klasse I: Produkte mit hohem Risiko, einschließlich Identitäts- und Zugriffsverwaltung Software; Browser; Passwort-Manager; Tools zur Erkennung bösartiger Software; Produkte, die VPNs verwenden; Konfigurations-, Überwachungs- und Ressourcenverwaltungstools für die Netzwerkverwaltung; Sicherheitsinformations- und Ereignismanagementsysteme (SIEM); Patch-Management-Tools; Software zur Verwaltung mobiler Geräte und Apps; Fernzugriffssoftware; Mikrocontroller; Betriebssysteme; Firewalls; Router und Modems; industrielle Steuerungsgeräte; und jedes industrielle IoT, das nicht unter Klasse II fällt.

Klasse II: Noch risikoreichere Produkte als Klasse I. Beinhaltet einige Betriebssysteme; Firewalls; Mikrocontroller; Industrie-Router und Modems; Schalter; Smartcards und Lesegeräte; sichere Elemente; Hardware-Sicherheitsmodule; intelligente Zähler; Einbrucherkennung; Sensor- und Aktorkomponenten für Roboter; und IIoT-Geräte, die von in NIS 2 beschriebenen Unternehmen verwendet werden.

Wenn dieselben Produkttypen in Klasse I und II aufgeführt sind, wird die richtige Stufe anhand von Risikofaktoren festgelegt, z. B. ob ein Produkt in sensiblen NIS-2-Umgebungen ausgeführt wird, mit privilegiertem Zugriff ausgeführt wird, zur Verarbeitung persönlicher Informationen verwendet wird und eine Schwachstelle enthält was eine „Vielzahl“ von Menschen betreffen könnte; oder ob es bereits schädliche Auswirkungen verursacht hat.

Anhang I beschreibt die Sicherheitsanforderungen für Hersteller digitaler Produkte. Sie sollten:

• Sie müssen so konzipiert, entwickelt und hergestellt werden, dass ein „angemessenes“ Sicherheitsniveau gewährleistet ist
• Keine bekannten ausnutzbaren Schwachstellen aufweisen
• Wird standardmäßig mit einer sicheren Konfiguration geliefert
• Sorgen Sie für Schutz vor unbefugtem Zugriff
• Schützen Sie die Vertraulichkeit und Integrität persönlicher und anderer Daten
• Verarbeiten Sie nur die minimal erforderliche Datenmenge
• Schützen Sie die Verfügbarkeit wesentlicher Funktionen, beispielsweise vor DDoS-Angriffen
• Sie müssen so konzipiert, entwickelt und hergestellt werden, dass Angriffsflächen begrenzt und die Auswirkungen von Vorfällen verringert werden
• Überwachen Sie interne Aktivitäten, um relevante sicherheitsrelevante Informationen bereitzustellen

Anhang I enthält außerdem eine ausführliche Liste von Anforderungen für den Umgang mit Schwachstellen. Dazu gehört auch, dass Hersteller Schwachstellen unverzüglich dokumentieren, beheben und beheben, die Produktsicherheit regelmäßig testen und Informationen über alle von ihnen behobenen Fehler öffentlich offenlegen. Die CRA verlangt außerdem von den Entwicklern, Richtlinien zur Offenlegung von Schwachstellen durchzusetzen, Informationen über Fehler weiterzugeben und eine Möglichkeit bereitzustellen, Sicherheitsupdates zu verteilen, und zwar unverzüglich und kostenlos.

Berichts- und Konformitätsanforderungen

Während Hersteller der Standardklasse effektiv selbst beurteilen können, ob ein Produkt marktreif ist, müssen Hersteller der Klasse I eine Konformitätsbewertung durch Dritte durchführen oder harmonisierte Standards anwenden. Alternativ könnten sie europäische Zertifizierungssysteme für Cybersicherheit auf ihre Produkte anwenden. Diejenigen der Klasse II müssen sich einer Konformitätsbewertung durch einen Dritten unterziehen.

Die CRA verlangt außerdem von Herstellern, dass sie die Sicherheitsbehörde ENISA innerhalb von 24 Stunden nach Bekanntwerden einer aktiv ausgenutzten Schwachstelle oder eines Sicherheitsvorfalls benachrichtigen. Importeure und Händler müssen die Hersteller ebenfalls unverzüglich über neue Fehler informieren und gegebenenfalls die nationalen Marktüberwachungsbehörden bei schwerwiegenden Risiken.

Könnte ein ISMS Herstellern helfen?

Da bei Verstößen Strafen in Höhe von 15 Millionen Euro oder 2.5 % des Jahresumsatzes verhängt werden, müssen alle betroffenen Organisationen überlegen, wie sie sich an die neue Regelung anpassen. David Dumont, Partner von Hunton Andrews Kurth, erzählt ISMS.online dass Organisationen in einigen Sektoren, wie z. B. Hersteller von IoT-Medizingeräten, aufgrund bestehender regulatorischer Anforderungen möglicherweise bereits einen Vorsprung haben. Seine Partnerin in der Anwaltskanzlei, Sarah Pearce, fügt hinzu, dass Unternehmen die Vorschriften vollständig einhalten DSGVO, das „robuste Sicherheitskontrollen und damit verbundene Richtlinien und Verfahren“ fordert, sollte die Einhaltung der CRA „mit begrenzten Anpassungen erreichbar“ finden.

Es kann jedoch sein, dass nicht alles glatt läuft.

„Die Einhaltung strenger Bedingungen für die Einführung und Aufrechterhaltung digitaler Produkte auf dem EU-Markt kann zu zusätzlichen Kosten führen“, warnt Dumont. „Ein solcher zusätzlicher Compliance-Aufwand könnte es für kleine und mittlere Unternehmen schwieriger machen, auf dem digitalen Markt zu konkurrieren, und den technologischen Fortschritt behindern.“

Hier ist ein Informationssicherheits-Managementsystem (ISMS) könnte helfen, indem es die Einhaltung von ISO 27001 und die von Pearce genannten robusten, von der DSGVO vorgeschriebenen Kontrollen, Richtlinien und Verfahren unterstützt.

„Es gibt Überschneidungen zwischen bestehenden europäischen und internationalen Cybersicherheitsstandards wie ISO 27001 und einigen der wichtigsten Cybersicherheitsanforderungen der CRA“, erklärt Dumont. „Unternehmen, die sich an solche bestehenden Standards halten, können dies bei der Umsetzung der CRA-Compliance nutzen.“

Was sind die potenziellen Probleme?

Einige haben den Versuch der Kommission begrüßt, die Grundsicherheit und Transparenz bei Technologieprodukten zu verbessern. John Smith, CTO von Veracode EMEA, beschreibt es als „bahnbrechendes Gesetz“.

„Es bringt nicht nur mehr Transparenz in einen oft undurchsichtigen Bereich, sondern ermutigt auch Softwareanbieter, Hersteller und Einzelhändler, die Cybersicherheit für die von ihnen verkauften Produkte zu erhöhen, und hilft Käufern dabei, einfach robuste Produkte auszuwählen“, fügt er hinzu. „Hoffentlich wird dies Unternehmen dazu anregen, über die verbindlichen Anforderungen hinauszugehen und der Sicherheit einen höheren Stellenwert einzuräumen.“

Andere haben jedoch große Bedenken. Gemeinnützige Rechtegruppe Electronic Frontier Foundation hebt zwei potenziell schwerwiegende Auswirkungen hervor, wenn das CRA in seiner aktuellen Form verabschiedet wird:

Open Source: Jeder Open-Source-Entwickler, der um Spenden bittet oder Supportleistungen für seine Software in Rechnung stellt, haftet für Schäden, wenn sein „Produkt“ einen Fehler enthält, der sich in andere Produkte einschleicht. Angesichts der komplexen, vernetzten Natur von Open Source Software-Lieferkette, könnte dies eine abschreckende Wirkung auf die Branche haben und Entwickler dazu zwingen, die Region ganz aufzugeben.

Offenlegung von Sicherheitslücken: Erstens könnte der sehr kurze Zeitrahmen (24 Stunden) für die Meldung neuer Schwachstellen an die ENISA zu schnellen, aber „oberflächlichen“ Korrekturen führen, die nicht die Grundursache der Probleme beheben. Zweitens berichtet ENISA anschließend an die Computer Security Incident Response Teams (CSIRTs) und Marktüberwachungsbehörden der Mitgliedstaaten. Die EFF befürchtet, dass staatliche Hacker diese Schwachstelleninformationen ausnutzen und/oder an die Cybercrime-Community weitergeben könnten.

Leider scheint es nicht so zu sein, dass der Gesetzgeber diese Bedenken berücksichtigen wird.

„Angesichts der unbestreitbaren Zunahme von Cyber-Angriffen in den letzten Jahren mit enormen wirtschaftlichen und gesellschaftlichen Auswirkungen liegt die Notwendigkeit staatlicher Intervention auf der Hand und überwiegt wohl solche Bedenken“, schließt Pearce.