Der CRA (Cyber Resilience Act) kann eine entscheidende Rolle für die Verbesserung der Cybersicherheit in Europa spielen. Das EU-Gesetz gilt für Produkte mit digitalen Elementen, was standardmäßig für alle Produkte gilt, die Software enthalten. Der CRA wendet, ähnlich wie andere Gesetze, einen risikobasierten Ansatz an, um zu bewerten, ob ein Produkt höhere Sicherheitsmaßnahmen erfüllen muss als andere. Der Großteil der Software fällt unter die Kategorie „Verbraucher“: Rund 80 % aller Softwareprodukte fallen in diese Kategorie. Sobald kritische Ressourcen, d. h. Dienste, die unter die NIS-2-Richtlinie fallen, von der Software betroffen sind, gelten strengere Regeln gemäß CRA. Der CRA soll den Zugang zum europäischen Markt regulieren und verhindern, dass unzählige Produkte auf den Markt kommen, für die keine Sicherheitsupdates verfügbar sind.
Eine Ausnahme von der oben genannten Regel bilden reine OpenSource-Komponenten, die keinerlei Anzeichen für eine Gewinnerzielungsabsicht aufweisen (reine Hobbyprojekte). Für andere Open-Source-Projekte gilt das Modell der Verwaltung: Jemand muss die Verantwortung für die Software übernehmen und die Regeln der CRA planen und auf die Software anwenden. Es gibt unterschiedliche Meinungen darüber, wie diese Verwaltung funktionieren wird, aber eine Folge könnte sein, dass jedes Unternehmen, das Open-Source-Software in seinen Produkten verwendet, automatisch zum Verwalter dieses Projekts wird (ähnlich wie bei einer Abspaltung des Projekts, siehe jedoch unten).
Es gibt technische und organisatorische Maßnahmen, die Unternehmen und Organisationen erfüllen müssen.
Die wichtigsten organisatorischen Maßnahmen für CRA-Software umfassen:
- Benutzer müssen in der Lage sein, Sicherheitslücken zu melden, und der Anbieter der CRA-Software muss Software-Sicherheitslücken innerhalb einer bestimmten Frist an die nationale Koordinierungsstelle und an CVE-Datenbanken melden. Dies ermöglicht es Kunden, umgehend auf mögliche kritische Sicherheitslücken zu reagieren, und verhindert den Schwarzmarkt für Sicherheitslücken, auf dem Hacker „unbekannte“ CVE für Softwareprodukte kaufen können. Korrekturen für Sicherheitslücken müssen gemäß der nächsten Regel bereitgestellt werden.
- Die Wartung und Veröffentlichung von Sicherheitskorrekturen für einen Zeitraum von fünf Jahren für jede Version. Der CRA schreibt vor, dass diese Sicherheitskorrekturen für die Nutzer der Software kostenlos sein müssen. Infolgedessen müssen insbesondere Unternehmen darauf achten, dass neue Funktionen nicht mit Sicherheitskorrekturen vermischt werden, da sonst auch die neuen Funktionen kostenlos angeboten werden müssten. Die Folge ist ein strengeres Release-Management.
- Die Pflege eines Katalogs der verwendeten Softwarebibliotheken und Materialien (SBOM). Insbesondere die SBOM ermöglicht es den Unternehmen, effizient nach Schwachstellen zu suchen, und ebnet den Weg für eine automatisierte Bearbeitung von Schwachstellen.
- Wenn Softwareunternehmen Open-Source-Software in ihren Produkten verwenden, müssen sie auch die Verantwortung für diese Software übernehmen, d. h. sie müssen Fehlerbehebungen an der Open-Source-Software vornehmen, als wäre es ihre eigene Software. Dadurch wird sichergestellt, dass auch das umfangreiche Ökosystem der Open-Source-Komponenten von den Regeln der CRA profitiert. Wenn Unternehmen keine Fehlerbehebung anbieten können, müssen sie andere Maßnahmen ergreifen oder die (fehlerhafte) Open-Source-Komponente aus ihrem Produkt entfernen.
- Die Dokumentation der Maßnahmen, die im eigenen Software-Stack angewendet wurden. Die Dokumentation muss zur Verfügung gestellt werden, und die EU wird auf dieser Basis die CE-Kennzeichnung für (Software-) Produkte erteilen. Zum Zeitpunkt der Erstellung dieses Artikels ist noch unklar, was genau die Dokumentation umfassen muss, und viele warten auf die Veröffentlichung der harmonisierten Normen.
Natürlich müssen NIS-2-Anbieter Sicherheitsupdates so schnell wie möglich auf der Grundlage ihres Risikoprofils anwenden.
Die wichtigsten technischen Maßnahmen für CRA-Software umfassen:
- Die Möglichkeit, Sicherheitsupdates für die eigene Software herunterzuladen. Dieser Schritt ist von entscheidender Bedeutung, da Sie in der Lage sein müssen, auf mögliche Mängel zu reagieren.
- Die Anwendung von Bedrohungsmodellen für das (Software-)Produkt. In der vernetzten Welt von heute gibt es viele Bedrohungen, die sich auf den Betrieb von Diensten auswirken. Ein Bedrohungsmodell stellt sicher, dass zumindest die wichtigsten Bedrohungen bereits abgedeckt sind und dass neue Softwareprodukte ein Mindestmaß an möglichen Sicherheitsvorkehrungen anwenden. Die Bedrohungsmodellierung erfolgt in der Regel auf der Grundlage von Angriffsvektoren des Benutzers, der Anwendung, des Netzwerks oder des physischen Systems.
- Die Integration und Anwendung eines sicheren Softwareentwicklungslebenszyklus. Während der Softwareentwicklung sollten die technischen Sicherheitsmaßnahmen bereits dokumentiert und angewendet werden. Dies erleichtert nicht nur die Dokumentation des Softwareprodukts, sondern stellt auch sicher, dass Authentifizierungs- und Autorisierungsmaßnahmen frühzeitig in der Entwicklung angewendet werden. Beispielsweise könnte die Anwendung von „Security by Design and Default“ sicherstellen, dass Standardpasswörter eine Mindestlänge von 16 Zeichen haben und Sonderzeichen enthalten. Die Anwendung von „Fail Safe“ stellt sicher, dass das System in einen Zustand zurückfällt, in dem keine zusätzlichen Schäden zu erwarten sind.
Die Konsequenz für Unternehmen, die Dienste im Rahmen der NIS-2 anbieten, ist, dass sie in ihrem Stack hauptsächlich CRA-konforme Software verwenden sollten. In einer Lieferkette aus CRA-Konformer Software ist sichergestellt, dass jede einzelne. CRA-konforme Software ist die Lieferkette für ihre Dienste und sie stellen sicher, dass Schwachstellen in der eigenen Software-Stack behandelt werden. Die CRA ergänzt somit die Sicherheitsvorkehrungen der NIS-2. Wenn möglich, sollten NIS-2-Anbieter ihre Software-Lieferkette bereits jetzt um CRA-Konformität bitten.
Anbietern wurde eine Frist von drei Jahren eingeräumt, um die CRA-Vorschriften auf ihre Softwareprodukte anzuwenden, bevor diese verbindlich werden. Mit der Veröffentlichung der harmonisierten Normen werden viele Dinge klarer werden. Dennoch können einige Maßnahmen bereits sofort ergriffen werden: So ist beispielsweise die Bereitstellung von Sicherheitsupdates für Ihre Software kein Hexenwerk und kann bereits vorbereitet werden.
Artikel von pi-ar GmbH