Compliance IT Sicherheit – Besonderer Teil CRA

2. CRA

2.1 Oh Gott, noch ein Gesetz

Der Cyber Resilience Act stellt einen weiteren regulatorischen Versuch dar, die Risiken aus dem Betrieb von IT- Systemen zu mildern oder abzustellen. Es gab nur sektorale Anforderungen für bestimme Produkte (z.B. Fahrzeuge), der CRA gilt für alle Produkte mit digitalen Elementen (nachfolgend PDE genannt), Art 3 Nr. 1 . Der CRA ist am 10.12.2024 in Kraft getreten, seine ersten Wirkungen für die Hersteller (Meldepflichten) entfalten sich ab dem September 2026, der CRA gilt umfänglich ab dem 11.12.2027.

Es gibt also noch Zeit.

Der CRA gilt für die Produkte, die ab dem Anwendungsbeginn des CRA in den Verkehr gebracht werden, also Dezember 2027. Es sei denn, Sie bringen ab diesem Zeitpunkt Upgrades heraus, die das System mit wesentlichen neuen Funktionen versieht, dann gelten diese Regelungen schon dann.

Aber: Wer schon vorher Produkte auf den Markt bringen will, die dem CRA unterfallen, muss spätestens ab dem September 2026 in der Lage sein, die erforderlichen Meldungen abzugeben und egal ob das Produkt erst ab dem Dezember 2027 auf den Markt kommt oder nicht: Was als PDE 2028 auf dem Markt ist, muss CRA konform betrieben werden.

Die schönste Darstellung darüber, welche Folgen nun aus dem CRA zu ziehen sind, habe ich beim BSI gefunden.

Für kleinere Unternehmen gibt es Umsetzungshilfen, die direkt im CRA angelegt sind. Es wird Leitlinien und Supportcenter seitens des BSI geben und es soll selbst ein Sandboxverfahren geben, das die Überprüfung erleichtert.

Der CRA gilt vermutlich als lex generalis neben den Regelungen, die für spezielle Güter gelten, wie die Funkanlagenrichtlinie, die Medizinprodukte RL und die neue Maschinenverordnung.

2.2 Kurzer Überblick

2.2.1 Wer

Der CRA adressiert Hersteller, Bevollmächtigte, Importeuer und Händler, wobei der Pflichtenkanon sich in dieser Reihenfolge mindert.

2.2.2 Was

Erfasst werden (bis auf Ausnahmen) sämtliche „Produkte mit digitalen Elementen“, deren bestimmungsgemäßer Zweck eine Kommunikation über Datennetze voraussetzt oder bei denen man davon ausgehen kann, dass eine solche Verbindung hergestellt wird oder hergestellt werden könnte.

Es kommt nicht darauf an, ob die Verbindung hergestellt wird. Umfasst werden Systeme, die eine Kommunikation zwischen einem Server und Clients beinhalten. Aber es geht im Moment noch um die Erfassung eines Client-Systems, das Hardware und Software umfasst. Reine SaaS- Lösungen (Remote Accees per Browser oder unter Zuhilfenahme von Clientsoftware) sind nicht vom CRA erfasst.

Der CRA umfasst „embedded“ – wie auch „integrierte Software“, wie auch „stand-alone- Software“ – also Standardsoftware. Im Bereich BTB kann für Individualsoftware von den Regelungen des CRA abgewichen werden, sofern es um die Pflicht geht, kostenlose Sicherheitspatches  zu erstellen und zu liefern.

Für OSS gelten Sondervorschriften.

OSS,  die von einem kommer­zi­ellen Unter­nehmen dem Kunden vertraglich überlassen wird, unterfällt dem CRA.
OSS, die unabhängig von einer gewerblichen Tätigkeit überlassen wird, wird von dem Anwen­dungs­be­reich nicht erfasst.
Sofern OSS unter der Federführung einer NGO wie Linux oder Apache entwickelt wird, soll ein geminderter Haftungsumfang gelten.

2.2.3     Pflichtenkreis: Hersteller

Der CRA gibt erstens ein skaliertes ISMS für die Produktentwicklung, Produktbeobachtung und Wartung vor, das sich nach der Kritikalität der Produkte richtet.

Nach dem Art. 6 Abs. 1 dürfen Produkte mit digitalen Elementen nur dann in dem Markt vertrieben werden, wenn sie die grundsätzlichen Anforderungen des Anhangs 1 beachten.

2.2.3.1 ISMS: In den Verkehr bringen, Produktentwicklung

Diese Anforderungen werden hier auch Cybersicherheitsmerkmale genannt, wir lassen es bei dem Begriff Anforderungen. Die Anforderungen sind in verschiedenen Modulen zusammengefasst, wieder nach Sektoren und Kritikalität. Diese generellen  Anforderungen gelten für die meisten Standardprodukte.

  • Produkte müssen dem Stand der Technik entsprechend fehlerfrei auf den Markt kommen, dürfen also keinen bekannten, ausnutzbare Schwachstellen aufweisen.
  • Produkte müssen über eine sichere Standardkonfiguration verfügen. Und sie müssen per reset wieder bei Bedarf problemlos auf diese Konfiguration zurückgesetzt werden können. (Secure-by-default Konfiguration, gilt nicht bei Individualsoftware);
  • Erkannte Schwachstellen müssen durch Patches behoben werden (ggf. auch automatisch, wie bei Handys.);
  • Es müssen technische Kontrollmechanismen vor unbefugten Zugriff bestehen;
  • die vom PDE verarbeiteten Daten müssen gem. dem Stand der Technik und gemäß des Risikos vor unbefugten Zugriffen und Manipulationen geschützt werden (Zugriff);
  • die von dem PDE verarbeiteten Daten und die Funktionen und Prozesse der Software müssen vor Manipulationen geschützt werden (Integrität);
  • Es gilt der Grundsatz der Erforderlichkeit hinsichtlich des Umfangs und der Auswahl der Daten.
  • Grundlegende Funktionalitäten sollen vor DDOS Attacks geschützt werden. Das Risiko einer Cyberattacke sowie deren Auswirklungen soll durch die technische Konstruktion gemindert werden.
  • Sofern sicherheitsrelevante Informationen aufgezeichnet werden, müssen diese dem User überlassen werden;
  • Der User muss die Möglichkeit haben, mit dem PDE verarbeitete Daten und Einstellungen dauerhaft, sicher und einfach zu löschen.

Wer jetzt das Gefühl hat, da kenne ich schon eine Menge aus dem Thema Datenschutz, liegt richtig.

2.2.3.2      Konformitätsbewertung

Die Hersteller müssen die Erfüllung der Anforderungen mittels eines Konformitätsverfahrens nachweisen. Das ist ein schwieriges Thema. Wie schon oben gesagt, verspricht das BSI den KMUs und KKUs Hilfe bei dem Erstellen der Erklärung, so dass man abwarten muss, was kommt.

Grundsätzlich wird es um Standardprodukte gehen, die als unkritische PDEs qualifiziert werden. Nur in Ausnahmefällen werden zusätzliche Konformitätsbewertungen durchgeführt werden müssen, die dann für „wichtige Produkte“ (Anhang III) oder noch eine Stufe weiter für kritische Produkte (Anhang IV) gelten. Für diese beiden Produktstufen gelten die Anforderungen der Kritikalität I und II. Für alle anderen Hersteller gilt, dass die Erfüllung der Konformität mit den grundsätzlichen Sicherheitsanforderungen (Zertifikat nach Art. 27 Nr. 9 CRA; oder Module A (Interne Kontrolle),B und C (EU Baumusterkontrolle) und (H: umfassende Qualitätskontrolle) durch die Hersteller selbst durchgeführt werden kann (wenn kein vorrangiger Rechtsakt besagt, dass doch ein Zertifikat nach einer anderen Regelung vorzulegen ist.)

2.2.3.3 ISMS: Lebenszyklus

Das ISMS muss während des gesamten Lebenszyklus ein PDEs aufrechterhalten werden. Und das ist zu dokumentieren. Trocken gesagt, sind die Anforderungen hier diejenigen, die man von den Herstellern schon seit langem kennt (vielleicht mit Ausnahme der pentests, die vielleicht irgendwann nicht mehr zum Stand der Technik gehören).

  • Es muss ein ISMS für den Lebenszyklus des Produktes geben.
  • Schwachstellen sind fortlaufend zu erkunden, insbesondere die Komponenten des Produktes sind zu überwachen (das schließt die SBOM Liste des BSI für OSS mit ein).
  • Es muss einen Mechanismus geben, wie Sicherheitspatches schnellstmöglich entwickelt und auf den PDEs implementiert werden können. Und das kostenlos (!), sofern es nicht um Individualsoftware im Bereich BTB geht.
  • sofern eine Schwachstelle eine in das Produkt integrierte OEM- Komponente ist, ist dies dem betreffenden Hersteller zu melden;
  • dem User müssen Informationen zu einer Schwachstelle gegeben werden (gemeinsam mit dem Patch);
  • Sicherheitspatches müssen für den Unterstützungszeitraum erstellt und ausgeliefert werden. Der Unterstützungszeitraum beträgt minimal 5 Jahre.
  • Überprüfungen der Cyberreselliance nach dem Stand der Technik.

2.2.3.4 Informations- und Meldepflichten

Informationspflichten
Während der Zeitspanne des Vertriebs zuzüglich des Unterstützungszeitraums müssen die in dem Anhang II genannten Informationen den Kunden und Usern zur Verfügung gestellt werden.

Meldepflichten
Binnen 24 Stunden sind schwerwiegende Attacken oder Vorfälle zu melden, nach spätestens 72h muss ein vorläufiger Bericht vorgelegt werden und nach 1 Monat ein Endgültiger. Wie bei der DSGVO sind dann auch die User zu informieren.

2.2.4 Pflichtenkreis: Händler

Die Händler haben zu überprüfen und sicherzustellen, dass die Importeure und Hersteller Ihre Pflichten nach dem CRA erfüllt haben. Zudem gilt die Pflicht, mit den Behörden zusammen zuarbeiten, ggf. Mängel zu beseitigen oder gar die Produkte wieder vom Markt zu nehmen.

2.2.5  Sanktionen

Was wäre eine europäische Richtlinie ohne drakonische Bußgelder? Auch hier können bis zu 10 Millionen bzw. 2% des Jahresumsatzes verhängt werden, bzw. sogar 15 Millionen bzw. 2.5% des Jahresumsatzes bei Verstößen gegen grundlegende Anforderungen des Anhangs I oder gegen die Pflichten aus dem Art 13 f. CRA.

Weitere Beiträge

Compliance IT Sicherheit – Besonderer Teil CRA

2. CRA 2.1 Oh Gott, noch ein Gesetz Der Cyber Resilience Act stellt einen weiteren regulatorischen Versuch dar, die Risiken aus dem Betrieb von IT- Systemen zu mildern oder abzustellen. Es gab nur sektorale Anforderungen für bestimme Produkte (z.B. Fahrzeuge),

Mehr lesen »

Compliance IT Sicherheit – Besonderer Teil NIS-2

1. NIS-2-RL Bei den Vorgaben der NIS-2-RL handelt es sich um eine Richtlinie der europäischen Union. Diese Vorgaben hätten bis zum 17.10.2024 in nationales Gesetz umgesetzt werden sollen. Dazu kam es nicht, weil zunächst der Bundesrat sein Veto gegen einzelne

Mehr lesen »

Compliance IT Sicherheit –Besonderer Teil DSGVO III

6. Ablaufpläne und Schulungen Die Organisatorischen Maßnahmen betreffen insbesondere Schulungen der Mitarbeiter – insbesondere im Bereich der Cybersecurity -, die die Mitarbeiter regelmäßig durchlaufen müssen. Nach Aussagen unserer Kunden sind über 90% der Cyberattacks nicht durch Hacker bedingt, die sich

Mehr lesen »
Nach oben scrollen