Cyber Resilience Act (CRA), MaRisk und BAIT: Jetzt wird es für Banken richtig ungemütlich

Der Cyber Resilience Act (CRA) bringt umfassende Veränderungen in der IT-Sicherheitslandschaft. CRA definiert die Regelungen von MaRisk und BAIT die Anforderungen an die IT-Sicherheit im Finanzsektor neu. Dr. Lutz Martin Keppeler und Manuel Poncza, Rechtsanwälte von der Sozietät Heuking Kühn Lüer Wojtek, skizzieren welche weitreichenden Auswirkungen dies für Banken und Finanzdienstleister hat.

von RA Dr. Lutz Martin Keppeler und RA Manuel Poncza, Sozietät Heuking Kühn Lüer Wojtek

Auf den Finanzsektor kommen bedeutende Veränderungen in der IT-Sicherheit zu, eingeleitet durch den Cyber Resilience Act (CRA).

Der CRA erweitert und präzisiert die Anforderungen an die IT-Sicherheit im Finanzwesen deutlich über die bestehenden MaRisk- und BAIT-Regelungen hinaus.

CRA schafft neue IT-Sicherheits-Pflichten für den Finanzsektor

§1 Prozesse des Risiko- und Informationssicherheitsmanagements unterliegen im Finanzsektor traditionell den Regelungen der „Mindestanforderungen an das Risikomanagement“ („MaRisk“) und den „Bankaufsichtliche Anforderungen an die IT“ („BAIT“). Im Rahmen der EU-Digitalisierungsstrategie werden jedoch neue rechtliche Vorgaben für die Informationssicherheit geschaffen, die neben MaRisk und BAIT bestehen werden und in ihrem Detaillierungsgrad und Anwendungsbereich weit über diese hinausgehen.

Insbesondere der Digital Operational Resilience Act („DORA“), die NIS2-Richtlinie und das deutsche NIS2-Umsetzungsgesetz und schließlich der Cyber Resilience Act („CRA“) werden bisher nicht gekannte Anforderungen mit sich bringen.”

So wie 2018 die Datenschutzgrundverordnung („DSGVO“) die Banken-IT vor große Herausforderungen gestellt hat, werden diese neuen IT-Sicherheitsnormen der EU in den kommenden Jahren für viel Arbeit in den IT-Abteilungen der Unternehmen im Finanzsektor sorgen.

In diesem Beitrag konzentrieren wir uns auf die Neuerungen, die den Banken durch den CRA drohen, da es sich hierbei um den – aus Bankensicht – fachfremdesten Rechtsbereich handelt, den viele IT-Sicherheitsbeauftragte in Banken möglicherweise noch nicht „auf dem Schirm“ haben.

Der CRA wird nach Inkrafttreten zu einer erheblichen Präzisierung der Anforderungen an die IT-Sicherheit auch für von MaRisk und BAIT regulierten Unternehmen führen. Dies liegt insbesondere daran, dass der CRA (i) in seinem Anwendungsbereich viel detailliertere Anforderungen an die IT-Sicherheit stellt (ii) vermutlich durch eine andere Behörde als die BaFin durchgesetzt werden wird (es ist jedoch noch nicht klar durch welche) und (iii) eigene Sanktionen bzw. eigene Bußgeldrisiken aufweist.

Was regeln MaRisk und BAIT und wie abstrakt sind diese Regelungen?

Die MaRisk und die BAIT beinhalten Vorgaben für finanzsektorspezifische Risiko- und Informationssicherheitsprozesse. Es handelt sich hierbei nicht um Gesetze oder Verordnungen, sondern um Rundschreiben der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin).

Gegenstand der Regelwerke sind insbesondere die Identifikation von geschäftsprozess- und compliance-bezogenen Risiken und die Verpflichtung zur Einführung von Maßnahmen zu deren Behandlung.

So beinhalten die Regelwerke etwa Vorgaben zur Einführung einer Informationssicherheitsleitlinie, der Einrichtung der Funktion des Informationssicherheitsbeauftragten oder zur Einführung eines Notfallmanagements. Hinsichtlich der technischen Ausgestaltung beinhaltet die MaRisk keine Regelungen. Auch die BAIT beinhaltet in Abschnitt 5 „Operative Informationssicherheit“ lediglich sechs allgemein gehaltene Regelungen zu informationssicherheitsrechtlichen Aspekten, nach welchen die regulierten Unternehmen dem Stand der Technik entsprechende, operative Informationssicherheitsmaßnahmen und Prozesse, etwa zur Risikoerkennung und -behandlung, zu implementieren haben.

Durch die allgemein gehaltenen Regelungen bleibt es dabei dem Unternehmen in weiten Teilen selbst überlassen, wie es diese Anforderungen umsetzt. Diese Freiheit ist jedoch nicht schrankenlos gewährleitet. Denn wenn die BAIT in Ziff. 5.2 beispielsweise eine „dem Stand der Technik entsprechende“ „Verschlüsselung von Daten bei Speicherung und Übertragung gemäß Schutzbedarf“ fordert, wird man hierunter in sicherlich keinem Fall etwa eine AES-Verschlüsselung mit 56, 128 oder 192 Bit verstehen können – egal wie der Schutzbedarf eingestuft wird.

Die Zielrichtung von MaRisk und BAIT, gleich, ob man sie nun als „zu oberflächlich“ oder „bewusst weit gehalten“ interpretieren möchte, ist dabei die Ausgestaltung unternehmensinterner Geschäftsprozesse.”

Kein zentraler Aspekt in diesem Zusammenhang ist jedoch die Frage, was die Unternehmen zu beachten haben, wenn sie ihren Kunden Hard- oder Software zur Nutzung anbieten. Genau an dieser Stelle wird künftig der CRA relevant.

Was regelt der CRA?

a.) Überblick
Der CRA ist eine, derzeit noch in den Trilog-Verhandlungen befindliche, produktsicherheitsrechtliche EU-Verordnung, welche die Anforderungen regelt, die „Produkte mit digitalen Elementen“ vor dem Inverkehrbringen bzw. dem Bereitstellen auf dem Markt zu erfüllen haben. Solche Produkte mit digitalen Elementen sind z.B. sämtliche Banking-Apps für Kunden Web-basierte Trading-Portale, Online-Payment-Lösungen usw.

b) Gegenstand des CRA
Inhaltlich regelt der CRA etwa, dass nur solche Produkte mit digitalen Elementen auf den Markt gebracht werden dürfen, die keine bekannten Sicherheitsschwachstellen haben und für die keine bekannten Exploits existieren. Werden Schwachstellen bekannt, sind für diese unverzüglich Patches bereitzustellen.

c.) „Secure-by-default“; automatische Sicherheitsupdates
Die Produkte mit digitalen Elementen sind mit einer secure-by-default Konfiguration zu entwickeln und haben, sofern möglich, das automatische Einspielen von Sicherheitsupdates als Standardeinstellung zu umfassen. Gleichzeitig muss das automatische Einspielen von Sicherheitsupdates aber mit einer easy-to-use opt-out Möglichkeit deaktiviert werden können und der Nutzer über verfügbare Sicherheitsupdates informiert werden.

d.) Verpflichtung bzgl. Software Bill of Material
Hersteller solcher Produkte, als welche auch diejenigen gelten, die die Produkte im eigenen Namen vertreiben (regelmäßig also auch die Banken selbst) haben zusätzlich eine Software Bill of Materials (kurz: SBOM) zu erstellen, die mindestens sämtliche Top-Level Dependencies beinhaltet. Ob diese SBOM unmittelbar anhand des Source Codes oder etwa durch eine binary code analysis erstellt wird, ist dabei nicht von Bedeutung.

Eine besondere Herausforderung wird in diesem Zusammenhang Open Source Software darstellen. Denn die Hersteller dieser sind in vielen Fällen vom Anwendungsbereich des CRA ausgenommen, sodass etwa die Patch-Pflichten für diese nicht gelten.”

Bindet allerdings ein Softwarehersteller Open Source Software in sein Produkt, etwa in Form von libraries, in den Source Code ein, übernimmt er hiermit auch die Verantwortlichkeit für das Patchmanagement dieser Software. Stellt im Falle einer bekanntwerdenden Schwachstelle (zuletzt etwa log4j) der Anbieter der Open Source Software nicht zeitnah ein Update bereit, ist der Hersteller verpflichtet, anderweitige Lösungen für das Patchen der Sicherheitslücke zu suchen und ggf. die verwendete Open Source Software gegen eine Alternative auszutauschen.

Indirekt werden Softwarehersteller hierdurch verpflichtet, eine „alternative Software Bill of Materials“ zu führen, was mitunter mit einem enormen Verwaltungsaufwand verbunden sein kann.”

e.) Überblick über weitere Verpflichtungen
Überblicksartig lassen sich weitere Verpflichtungen des „Hersteller“ unter dem CRA wie folgt zusammenfassen (wobei berücksichtigt werden muss, dass das finale Wording des CRA noch nicht erlassen wurde – Änderungen sind also noch möglich). Einige der unten genannten Verpflichtungen sind ähnlich detailliert ausgestaltet wie die oben genannten Regeln zu SBOM und Freiheit von Sicherheitslücken:

• Durchführung eines Konformitätsbewertungsverfahrens
• Erstellung der technischen Dokumentation
• Überwachungs- und Abhilfepflichten
• Aufbewahrungspflichten
• Verfahrens- und Informationspflichten
• Korrektur- und Rückrufpflichten
• Meldepflicht bzgl. Schwachstellen gegenüber ENISA 24 Stunden ab Bekanntwerden und gegenüber Nutzern unverzüglich nach Bekanntwerden

Im Falle eines Verstoßes haben Unternehmen die Verstöße unverzüglich zu beseitigen und in einigen Fällen sogar auf dem Markt bereitgestellte Produkte zurückzurufen. Bei Verstößen drohen den Unternehmen künftig zusätzlich Bußgelder und Vertriebsbeschränkungen bzw. -verboten. Die Entwürfe des CRA gehen von einem Bußgeldrahmen von bis zu EUR 15 Mio. EUR aus (die DSGVO lässt grüßen).

Fazit

Auch wenn der Finanzsektor aktuell bereits über verschiedene Regelungen zur Informations- und IT-Sicherheit verfügt, werden mit dem CRA künftig viele neue Vorgaben, mit einer anderen Zielrichtung, auf die Branche zukommen.”

Einerseits gilt: Wer bisher nicht aus Eigeninteresse seine IT auf einen sehr hohen Sicherheitsstandard gebracht hat (und z.B. über SBOM für alle Kunden-Apps und Kunden-Webportale verfügt), auf den wird kein überwältigender Mehraufwand zukommen. Auf der anderen Seite ist zu bedenken, dass mit dem CRA aus produktsicherheitsrechtlicher Sicht völlig neue Anforderungen kommen werden, die die Banken bisher vernachlässigen konnten. Dies betrifft z.B. das Konformitätsbewertungsverfahren (inkl. CE-Kennzeichnung).

Es wird erwartet, dass der CRA noch vor März 2024 verabschiedet wird und dann nach einer Übergangsfrist von 12 bzw. 24 Monaten in Kraft tritt.”

Einerseits könnte man sich angesichts der langen Übergangsfristen entspannt zurücklehnen. Andererseits sei nochmals an die DSGVO erinnert, die ebenfalls eine Umsetzungsfrist von 24 Monaten vorsah. Trotz dieser Übergangsfristen wurde es ab Ende 2017 eng für Prozesse, die erst technisch implementiert werden mussten (wie z.B. die ordnungsgemäße Löschung). Auch wird es einige Zeit dauern, bis der Gesetzgeber eine oder mehrere Behörde(n) für zuständig erklärt (evtl. z.B. das BSI?) und diese Behörden dann beginnen, „Guidance Paper“ zu veröffentlichen.

Die lange Übergangsfrist ist also trügerisch.”

Wer technisch und organisatorisch viel aufzuholen hat, sollte diesen Aufwand bereits für das ganze Jahr 2024 intensiv einplanen. Die weiteren Entwicklungen in diesem Zusammenhang sind daher unbedingt zu beobachten, damit das Aufsetzen neuer oder Anpassen bestehender Prozesse mit ausreichend zeitlichem Vorlauf in Angriff genommen werden kann.RA Dr. Lutz Martin Keppeler, RA Manuel Poncza, Sozietät Heuking Kühn Lüer Wojtek