Die Anforderungen des Cyberresilienzgesetzes (Cyber Resilience Act, CRA) sind in Anhang I des Gesetzes dokumentiert. Testteams müssen diese Anforderungen kennen, um sie auf Testsysteme anwenden zu können. Das europäische Cyberresilienzgesetz ist in einer Reihe von Dokumenten auf european-cyber-resilience-act.com/ gut dokumentiert. Die Rechtsvorschriften werden in 57 Artikeln beschrieben. Die technischen Anforderungen werden im Wesentlichen in Anhang I beschrieben.
Die Anforderungen des europäischen Cyberresilienzgesetzes sind in erster Linie in Anhang I definiert. Außerdem gibt es vier zusätzliche Anhänge:
Die Gemeinsame Forschungsstelle (Joint Research Centre, JRC) der EU und die Agentur der Europäischen Union für Cybersicherheit (European Union Agency for Cybersecurity, ENISA) haben ein Dokument veröffentlicht, aus dem hervorgeht, inwieweit die CRA-Anforderungen bestehenden Industriestandards entsprechen (einschließlich EN IEC 62443). Das kostenlose Dokument unter enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping ist ein hilfreicher Leitfaden für Unternehmen, die bereits einen dieser Standards übernommen haben.
Anhang I ist in zwei Abschnitte unterteilt. Abschnitt 1 behandelt die Eigenschaften der Produkte, während es in Abschnitt 2 darum geht, wie der Lieferant auf die Entdeckung von Sicherheitslücken reagieren soll.
(1) Produkte mit digitalen Elementen sind so zu entwerfen, zu entwickeln und herzustellen, dass sie ein den Risiken entsprechendes Maß an Cybersicherheit gewährleisten.
(2) Produkte mit digitalen Elementen sind ohne bekannte ausnutzbare Sicherheitslücken auszuliefern.
(3) Produkte mit digitalen Elementen müssen auf der Grundlage der in Artikel 10 Absatz 2 genannten Risikobewertung, sofern zutreffend,
a) mit einer sicheren Standardkonfiguration ausgeliefert werden, einschließlich der Möglichkeit, das Produkt in den ursprünglichen Zustand zurückzusetzen.
b) durch geeignete Kontrollmechanismen, einschließlich, aber nicht beschränkt auf Authentifizierungs-, Identitäts- oder Zugriffsverwaltungssysteme, den Schutz vor nicht autorisiertem Zugriff sicherstellen.
c) mit Hilfe modernster Verfahren die Vertraulichkeit der gespeicherten, übermittelten oder anderweitig verarbeiteten personenbezogenen oder sonstigen Daten wahren, z. B. durch Verschlüsselung relevanter Daten im Speichersystem (Data at Rest) oder während der Übertragung.
(d) die Integrität der gespeicherten, übertragenen oder anderweitig verarbeiteten personenbezogenen oder sonstigen Daten, Befehle, Programme und Konfigurationen vor Manipulationen oder Änderungen schützen, die nicht vom Benutzer autorisiert sind, und Sicherheitsverletzungen melden.
e) nur personenbezogene oder sonstige Daten verarbeiten, die angemessen, relevant und auf das für die beabsichtigte Verwendung des Produkts erforderliche Maß beschränkt sind („Datenminimierung“).
f) die Verfügbarkeit wesentlicher Funktionen sicherstellen, einschließlich der Widerstandsfähigkeit gegen und der Eindämmung von Denial-of-Service-Angriffen.
g) ihre eigenen negativen Auswirkungen auf die Verfügbarkeit von Diensten anderer Geräte oder Netzwerke minimieren.
h) so entworfen, entwickelt und hergestellt werden, dass möglichst wenige Angriffsflächen vorhanden sind. Dazu zählen auch externe Schnittstellen.
i) so entworfen, entwickelt und hergestellt werden, dass die Auswirkungen eines Vorfalls mit Hilfe geeigneter Mechanismen und Techniken minimiert werden.
j) sicherheitsrelevante Informationen durch Aufzeichnung und/oder Überwachung relevanter interner Aktivitäten bereitstellen, einschließlich des Zugriffs auf oder der Änderung von Daten, Diensten oder Funktionen.
k) sicherstellen, dass Sicherheitslücken durch Sicherheits-Updates behoben werden können, gegebenenfalls auch durch automatische Updates und die Benachrichtigung der Benutzer über verfügbare Updates.
Wenn Sie ein Testsystem entwickeln, das diesen Anforderungen unterliegt, müssen Sie einen Entwicklungsprozess implementieren, der die erste Anforderung erfüllt. Es gibt mehrere Frameworks für die Sicherheitsentwicklung, darunter der Microsoft Secure Development Lifecycle und das in NIST 800-218 dokumentierte US Government Secure Software Development Framework. Obwohl diese nicht für Testsysteme oder Produkte wie LabVIEW oder TestStand entwickelt wurden, enthalten sie dennoch allgemeine Prinzipien, die für jede Systementwicklung gelten. Sie können sie verwenden, um einen Prozess für Ihr Team zu konzipieren, der die CRA-Anforderungen erfüllt.
Bei der Planung der Funktionen Ihres Testsystems müssen Sie die zusätzlichen Anforderungen des CRA berücksichtigen. Sie müssen einplanen, wie Sie den Zugriff auf das Testsystem sowohl durch Benutzer als auch durch externe Systeme kontrollieren werden. Sie müssen festlegen, welche Daten durch Verschlüsselung geschützt werden müssen und wie diese Daten verschlüsselt werden. Sie müssen Mechanismen zur Abwehr von Angriffen entwickeln. Sie müssen Aktivitäten in Prüfprotokollen dokumentieren. Außerdem müssen Sie Sicherheits-Updates für die Komponenten des Systems einplanen.
Das alles bedeutet Mehrarbeit für Ihr Entwicklungsteam. Die zusätzlichen Kosten müssen daher während Ihrer Projektplanungsphasen entsprechend berücksichtigt werden. Erarbeiten Sie zusammen mit Ihren Kunden die möglichen Maßnahmen zur Erhöhung der Sicherheit. Ermitteln Sie auch, wer die Verantwortung für Updates nach der Bereitstellung trägt, um die Sicherheit des Systems aufrechtzuerhalten.
Denken Sie daran, dass Sicherheit auf Systemebene betrachtet werden muss. Einige Komponenten werden für sich allein nicht alle diese Anforderungen erfüllen. In Kombination mit anderen Komponenten des Systems lassen sich eventuelle Lücken jedoch überbrücken, sodass Sie eine insgesamt vollständige Systemsicherheit demonstrieren können.
Unterschätzen Sie auch weder den Nutzen einer vollständigen Sicherheitsdokumentation noch den dafür erforderlichen Aufwand. Sie müssen dokumentieren, wie das System die CRA-Anforderungen erfüllt. Dokumentieren Sie außerdem, wie das System auf eine sichere Basiskonfiguration zurückgesetzt werden kann. Diese Informationen sind unabdingbar, wenn ein Angriff das System lahmlegen sollte. Diese Dokumentation kann auch verwendet werden, um sicherzustellen, dass das System nicht von dieser sicheren Konfiguration abweicht.
Hersteller von Produkten mit digitalen Elementen müssen
(1) Sicherheitslücken und Komponenten des Produkts identifizieren und dokumentieren. Dazu gehört die Erstellung einer Software-Stückliste (Software Bill of Materials, SBOM) in einem gängigen und maschinenlesbaren Format, die mindestens die Hauptabhängigkeiten des Produkts abdeckt.
(2) entsprechend des Schweregrads der Risiken, die von Produkten mit digitalen Elementen ausgehen, Sicherheitslücken unverzüglich schließen und Maßnahmen zur Eindämmung der Auswirkungen bereitstellen. Dazu gehören auch Sicherheits-Updates.
(3) effektive und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts mit digitalen Elementen durchführen.
(4) nach der Bereitstellung eines Sicherheits-Updates öffentlich Informationen zu den behobenen Sicherheitslücken bekannt geben. Das umfasst eine Beschreibung der Sicherheitslücken, Informationen, die es Benutzern ermöglichen, das betroffene Produkt mit digitalen Elementen zu identifizieren, die Auswirkungen der Sicherheitslücken und ihren Schweregrad sowie Informationen, die den Benutzern helfen, die Auswirkungen der Sicherheitslücken zu minimieren.
(5) eine Richtlinie zur koordinierten Offenlegung von Sicherheitslücken implementieren und umsetzen.
(6) Maßnahmen ergreifen, um den Austausch von Informationen über potenzielle Sicherheitslücken in ihrem Produkt mit digitalen Elementen sowie in Komponenten von Drittanbietern, die in diesem Produkt enthalten sind, zu erleichtern. Dazu gehört auch die Angabe einer Kontaktadresse für die Meldung der im Produkt mit digitalen Elementen entdeckten Sicherheitslücken.
(7) Mechanismen zur sicheren Bereitstellung von Updates für Produkte mit digitalen Elementen implementieren, um sicherzustellen, dass ausnutzbare Sicherheitslücken rechtzeitig behoben oder ihre Auswirkungen minimiert werden.
(8) sicherstellen, dass Sicherheits-Patches oder -Updates, mit denen festgestellte Sicherheitsprobleme behoben werden können, unverzüglich und kostenlos zur Verfügung gestellt werden. Sie müssen auch relevante Informationen für Benutzer beinhalten, etwa zu möglichen Maßnahmen.
Die mit dem System gelieferte Dokumentation muss ggf. eine Software-Stückliste (SBOM) enthalten. Eine SBOM umfasst alle Softwarekomponenten des Systems. Bei Angriffen in jüngster Zeit war es für Unternehmen besonders wichtig, die Komponenten bzw. Systeme zu ermitteln, in denen die für Angriffe anfällige Software enthalten war. SBOMs sind für Unternehmen eine Möglichkeit, ihr Softwareinventar zu pflegen und herauszufinden, ob gemeldete Probleme für dieses Inventar relevant sind. Außerdem lassen sich so Systeme besser verwalten, die von diesen Problemen betroffen sind.
Je mehr SBOMs verfügbar sind, desto einfacher können Endbenutzer erkennen, wie anfällig ihre Systeme für Angriffe sind. Lieferanten werden häufiger aufgefordert, Sicherheits-Updates bereitzustellen. Lieferanten sind aufgrund des CRA verpflichtet, diese Updates noch fünf Jahre nach Lieferung eines Produkts oder Systems bereitzustellen. Ihr Team muss einen Plan entwickeln, um das zu ermöglichen.
Insgesamt werden die Anforderungen des CRA die Sicherheit von Testsystemen verbessern. Gleichzeitig erhöhen sich aber auch der Arbeitsaufwand für Systementwickler und die Erwartungen an Lieferanten wie NI.
Erfahren Sie, wie NI Ressourcen bereitstellt, um Ihr Team dabei zu unterstützen, diese Erwartungen zu erfüllen.