Bankaufsichtliche Anforderungen an die IT (BAIT): Vorbild für alle Unternehmen

Die Bankenaufsicht hat in den vergangenen Jahren Regelungen zur Sicherstellung eines sicheren IT-Betriebs in Finanzinstituten aufgestellt. Diese Regelungen sind in der Praxis erprobt und sowohl durch Sonderprüfungen als auch durch die fortschreitende Entwicklung der IT-Anforderungen, -Möglichkeiten und -Bedrohungen geschärft worden.

Auch für Unternehmen, die nicht-beaufsichtigt bzw. gar nicht im Finanzumfeld tätig sind, die aber einen gesteigerten Wert auf IT-Sicherheit legen und Risiken minimieren wollen, können aus den Regelungen der Aufsicht interessante Aspekte für die Risikomitigation ziehen und so ihren IT-Betrieb und die damit verbundenen Prozesse optimieren. Das bedeutet aber auch, dass die Zusammenarbeit zwischen der IT und den Fach- und Stabsbereichen zuweilen überprüft und angepasst werden muss.

Normative Einordnung und Überblick

Banken und Versicherungen sind ein wesentlicher Stützpfeiler einer funktionierenden Volkswirtschaft und folgerichtig auch grundsätzlich als kritische Infrastruktur (vgl. u.a. § 7 BSI-Kritisverordnung) normativ eingestuft. Die Gesellschaft vertraut darauf, dass Banken jederzeit über eine angemessene Eigenkapitalausstattung und eine ausreichende Liquidität verfügen. Kernaufgabe der Bankenaufsicht ist, die Kreditinstitute hier wirksam zu überwachen. Aber: Ein entscheidender Erfolgsfaktor ist dabei auch eine jederzeit funktionierende IT-Infrastruktur. Die Weiterentwicklung der aufsichtsrechtlichen Vorgaben hat dazu geführt, dass die Sicherstellung der Informationsverarbeitung den gleichen Rang wie die ausreichende Kapital- und Liquiditätsausstattung erlangt hat.

Damit Kreditinstitute ihren Aufgaben nachkommen können, sind sie gemäß § 25a Kreditwesengesetz zu einem ordnungsgemäßen Geschäftsbetrieb verpflichtet. Diese Generalnorm wurde durch weitere Erlasse ausgestaltet. Ein zentrales Regelungskonvolut stellen dabei die „Mindestanforderungen an das Risikomanagement“ (MaRisk) dar. Hiermit werden aufbau- und ablauforganisatorische Regelungen allgemeiner Natur (Teil A) wie auch bankgeschäftsspezifischer Natur (Teil B) beschrieben.

Die „Bankaufsichtlichen Anforderungen an die IT“, kurz BAIT, ergänzen und konkretisieren hier die MaRisk in den nachfolgend genannten IT-relevanten Themengebieten weiter und sind mit ihr untrennbar verbunden:

• IT-Strategie und IT-Governance,
• Informationsrisiko- und -sicherheitsmanagement,
• operative Informationssicherheit,
• Identitäts- und Rechtemanagement,
• IT-Projekte und Anwendungsentwicklung,
• IT-Betrieb und IT-Nofallmanagement,
• Auslagerungen und sonstiger Fremdbezug von IT-Dienstleistungen,
• Management der Beziehungen mit Zahlungsdienstnutzern und
• kritische Infrastrukturen.

Vom IT-Risikomanagement zum „Informationssicherheits-“ bzw. „Informationsrisikomanagement“

MaRisk und BAIT sind inzwischen in der Praxis erprobt und wurden mehrmals im Zusammenspiel mit der Kreditwirtschaft mittels – zuletzt jährlichen – Konsultationsprozessen nachgeschärft. Erwähnenswert hierbei ist unter anderem, dass in den Regularien im Zeitverlauf aufsichtsrechtlich der IT-Begriff zusehends gestrichen und durch das Wort „Information“ ersetzt wurde. So wurde aus dem IT-Risikomanagement das „Informationssicherheits-“ bzw. „Informationsrisikomanagement“. Ein deutlicher Beleg dafür, dass nicht die verwendete Hard- oder Software im Fokus der Aufsicht stehen, sondern die Informationen, die hier verarbeitet werden.

Auslagerungsmanagement

Und in Zeiten einer zunehmenden dezentralen Informationsverarbeitung, des Kundenzugriffs über Onlinebanking bzw. die Bereitstellung immer weiterer digitaler Services steigt auch das Risiko von Hackerangriffen und anderen Methoden der Cyberkriminalität. Die Auslagerung von Services in die Cloud, insbesondere, sofern es sich um nicht-bankspezifische Prozesse handelt, kann ein wichtiger Baustein in der IT-Strategie sein, um derartige Risiken zu mitigieren. Somit ist es nicht nur dem strategischen Ziel, sich als Bank auf die Kernaufgaben zu konzentrieren, geschuldet, wenn der Systembetrieb einem professionelleren Dienstleister überlassen wird, als es ein einzelnes Finanzinstitut naturgemäß jemals sowohl aus technischer als aus fachlicher Sicht umsetzen könnte. Dabei ist jedoch auch zu beachten, dass die Nutzung von Cloud-Diensten im Kontext der IT-Strategie stehen muss. Folglich sind bei deren Beschaffung neben der Fach- und der IT-Abteilung auch weitere Bereiche wie dem (IT-)Risikomanagement, die Informationssicherheits- und Datenschutzbeauftragten hinzuzuziehen. Interessenskonflikte bei der Beschaffung sind hier nicht auszuschließen. Und je besser der Dienstleister die jeweiligen Anforderungen und Interessen kennt, umso eher wird das von diesem angebotene Produkt konsensfähig sein. Als Dienstleister im finanzbeaufsichtigten Bereich ist es wiederum mithin erforderlich, sich mit genau diesen Regularien zu befassen. Maßgebliche Grundlagen sind dabei die Regelungen zu Auslagerungen im Abschnitt AT 9 der MaRisk. Diese sind insbesondere dann maßgeblich, wenn die „Bereitstellung von IT-Systemen, Projekten/Gewerken oder Personalgestellung“ (Zitat BAIT) durch Dritte einen bankspezifischen Prozess betreffen. Die Entscheidungshoheit, ob eine wesentliche Auslagerung vorliegt, obliegt hier dem Kreditinstitut – mithin muss ein externer Dienstleister und die von diesem beauftragten Subunternehmer sich darauf gefasst machen, dass sein Leistungsangebot als wesentliche Auslagerung klassifiziert wird und die daraus resultierenden Anforderungen umsetzen können.

MaRisk und BAIT in der Praxis

Dies bedeutet in der Praxis, dass u.a. weitreichende Informations- und Zutrittsrechte eingeräumt werden müssen, wie auch hinreichende Kündigungsfristen mit Regelungen zur Rückübertragung der ausgelagerten Tätigkeiten bzw. Informationen auf das Institut oder einen anderen Dienstleister. Ebenso ist institutsintern ein Auslagerungsregister zu führen und ein regelmäßiges Monitoring des Dienstleisters vorzunehmen, der hier die zu diesem Zweck erforderlichen Informationen regelmäßig und zeitnah bereitstellen muss.

Aber an dieser Stelle muss auch betont werden, dass Rechenzentrumsbetreiber in der Praxis eine derartige Vorzugsbehandlung eben nur den der Finanzaufsicht unterliegenden Unternehmen gewähren, obschon es sicher auch für andere Unternehmen wünschenswert wäre.

Eine nichtbanktypische Tätigkeit wie eine Eingangsrechnungsverarbeitung , ein Personal-Managementsystem oder eine digitale Signatur dürfte man hingegen kaum als wesentliche Auslagerung deklarieren. Und auch Auslagerungen, die nicht als wesentlich qualifiziert werden, die Aufsicht spricht dann von einem „sonstigen Fremdbezug“, unterliegen, wie die BAIT ergänzend zu den Regelungen der MaRisk ausführt, einer Risikobewertung wie auch einer Steuerung und Dienstleisterüberwachung durch das Institut und bedürfen angemessenen vertraglichen Vereinbarungen.

Bei Cloudlösungen sind übrigens zwei Beteiligte dabei zu bewerten: der Anbieter und damit Software-/Lösungshersteller einerseits und der Betreiber, also das Rechenzentrum, andererseits. Der Anbieter selber tritt hier üblicherweise als Generalunternehmer auf, muss jedoch seinerseits sicherstellen, dass der Betreiber auch die Vorgaben kennt und umsetzen kann. So treffen einige Vorgaben der MaRisk bzw. BAIT den Anbieter in der Praxis eher weniger (was sollte die Bankenaufsicht durch einen persönlichen Besuch beim Anbieter prüfen wollen, außer ggf. den Support?), aber gleichwohl muss dieser für die nötige Transparenz sorgen. Nur so kann ein vertrauensvolles Miteinander aller Beteiligten entstehen.

Schutzziele der BAIT im Rahmen des Informationsrisikomanagements (IRM)

BAIT und MaRisk definieren vier Schutzziele, die im Rahmen eines Informationssicherheits-Managementsystems zu betrachten, bewerten und sicherzustellen sind:

1. Verfügbarkeit der IT-Systeme
2. Integrität der Daten (d.h. Sicherstellung der Unveränderbarkeit von Daten bzw. Dokumenten und Schutz vor Datenverlust)
3. Authentizität (Absender und Empfänger von Informationen müssen korrekt sein)
4. Vertraulichkeit (Sicherstellung eines Berechtigungskonzeptes bzw. sicheren Verschlüsselung für den Empfänger).

Hierbei sind Informationen nicht singulär zu betrachten, sondern es ist jeweils auf den Informationsverbund – über den es gilt, sich entsprechende Kenntnis zu verschaffen – abzustellen. Der Informationsverbund ist das Zusammenspiel von Prozessen und Systemen wie auch von Systemen zu Systemen über Schnittstellen. Ferner ist auch die Bedrohungslage von außerhalb einzubeziehen. Es bedarf also eines entsprechenden Informationsrisikomanagements (IRM), das „frei von Interessenskonflikten“ zu implementieren ist.

Informationssicherheitsmanagements (ISM)

Wie die genannten Schutzziele erreicht werden können, ist dann wiederum Aufgabe des Informationssicherheitsmanagements (ISM). Schwerpunkt des ISM ist also die Bewertung der Informationssicherheit aus prozessualer Sicht unter Berücksichtigung der übergeordneten IT-Strategie. Diese wiederum wird von der Geschäftsleitung vorgegeben und beschreibt die IT-Infrastruktur, -Architektur und Ablauforganisation sowie die Standards, an denen sich das Institut orientiert. In der IT-Strategie sind auch die Maßnahmen zur Erreichung der strategischen Ziele zu beschreiben. In einer Informationssicherheitsleitlinie wird die Strategie konkretisiert, insbesondere wie die genannten Schutzziele beachtet werden können. Damit IT-Strategie und Informationssicherheitsleitlinie keine leeren Phrasen bleiben, ist als deren Hüter ein Informationssicherheitsbeauftragter (ISB) zu implementieren.

Die Tätigkeit des IRM und ISM setzt somit auch eine Kenntnis über die praxisrelevanten Risiken voraus. Die Fachbereiche sind, ggf. unterstützt von der Revision oder anderen Stabsbereichen, insofern zu befähigen, Risiken zu erkennen und zu benennen. Ein besonderes Vertrauensverhältnis zwischen den Fachbereichen und dem IRM und ISM ist hier vonnöten.

Operationelle Risiken in der Praxis reduzieren

Im Rahmen der operativen Umsetzung all dieser Managementaufgaben, Leitlinien, Strategien und Maßnahmen gilt es, die IT-Systeme regelmäßig bzw. anlassbezogen zu prüfen, Gefährdungen zu identifizieren und möglichst zu mitgieren, aufgetretene Ereignisse zu analysieren und letztlich aus all den Ergebnissen die bestehenden Strategien und Leitlinien zu schärfen und nachzujustieren. ISM und IRM sind mithin eng einzubeziehen. Zugleich hat sich das beaufsichtigte Institut grundsätzlich bei der Ausgestaltung der IT-Systeme und -Prozesse an gängige Standards zu orientieren. Die BAIT nennt in diesem Kontext den IT-Grundschutz des Bundesamtes für Sicherheit in der Informationspolitik, aber auch die Standards nach ISO/IEC 270XX. Da es sich hier um eine beispielhafte Aufzählung handelt, dürften gleichwohl auch vergleichbare oder sich an den ISO 270XX orientierende Standards, wie z.B. der Industriestandard nach TISAX, aufsichtsrechtlich Anerkennung finden.

Bezogen auf die Umsetzung gehen die BAIT dabei insbesondere auf die Ausgestaltung

1. des Identitäts- und Rechtemanagements
2. der organisatorischen Grundlagen für IT-Projekte und die Anwendungsentwicklung
3. und den IT-Betrieb selbst ein.

1. Identitäts- und Rechtemanagement

Das Identitäts- und Rechtemanagement ist dabei nach dem Prinzip der Sparsamkeit („Need to know-“/ „Least Privilege-Prinzip“) auszulegen. Hierbei ist auch zu beachten, dass nicht nur der Zugang zu Informationen in IT-Systemen, sondern auch der (physische) Zutritt zu regeln ist. Vergabe und Verwaltung von Berechtigungen sind dabei zu dokumentieren und mittels interner Genehmigungsprozesse zu vergeben; ferner ist hier fortlaufend zu monitoren und die Berechtigungen sind, wo es nötig ist, anzupassen.

2. IT-Projekte und Anwendungsentwicklung

Hinsichtlich der IT-Projekte sehen die BAIT vor, dass diese angemessen zu steuern und hierüber, wie auch über Projektrisiken, an die Geschäftsleitung zu berichten ist. Auch sind die IT-Projekte in ihrer Gesamtheit zu betrachten und daraus resultierende Risiken und Abhängigkeiten zu berücksichtigen.

Auch für die Anwendungsentwicklung, die stets unter Beachtung der vier genannten Schutzziele steht, sind Prozesse für die Entwicklung, Umsetzung, Test, Abnahme und Freigabe zu implementieren. Hierbei müssen auch Anforderungen an die Funktionalität dokumentiert (Lastenheft, Pflichtenheft) und – Obacht! – genehmigt werden. Selbiges gilt übrigens für nicht-funktionale Anforderungen wie Anforderungen an die Informationssicherheit, Wartbarkeit oder Ergonomie. Herausforderungen können insofern bestehen, da die Entwicklung ja neben den genannten Schutzzielen auch im Wesentlichen die Anforderungen der Fachabteilungen an eine optimale Nutzbarkeit beachten muss.

Die Anwendung sowie an ihr vorgenommene Anpassungen sind stets nachvollziehbar zu dokumentieren. Um das Schutzziel der Integrität zu erfüllen, müssen Vorkehrungen getroffen werden, die eine versehentliche oder absichtliche Manipulation erkennen lassen Und auch das Erfordernis, Anwendungen angemessen zu testen, ist festgeschrieben. Testaktivitäten und Testergebnisse sind dabei zu dokumentieren. Hierbei ist eine Testumgebung zu verwenden, die im Wesentlichen der Produktivumgebung zu entsprechen hat.

BAIT im Cloud-Betrieb

Es stellt sich insofern die Frage, wie mit cloudbetriebenen Lösungen, zum Beispiel dem Dokumentenmanagementsystem, vorzugehen ist. Besonderes Merkmal bei Cloudlösungen ist es ja, dass allen Cloudnutzern immer automatisch die aktuelle Softwareversion bereitsteht. Test- und Produktivumgebung sind damit technisch auf dem gleichen Stand.

Schließt damit die Vorgabe der BAIT den Cloudbetrieb aus?

Eine derartig enge Auslegung der BAIT dürfte aus meiner Sicht nicht angemessen sein, und die inzwischen vielfältige Nutzung von Cloudservices auch durch beaufsichtigte Unternehmen, die gewiss nicht an der Bankenaufsicht vorbeigegangen ist, spricht hier eine eindeutige Sprache. Auch die BaFin hat sich in der Vergangenheit nicht als „Cloud-Gegner“ positioniert, sondern befürwortet ausdrücklich einen professionellen modernen Cloud-Betrieb im Vergleich zu schwergewichtigen, veralteten und kaum wartbaren Eigenanwendungen. Wichtig ist in diesem Kontext aber, dass sich der Dienstleister verpflichtet, nur einen solchen Softwarestand zu veröffentlichen, der zuvor umfangreich getestet wurde. In diesem Zusammenhang sei auch noch einmal darauf hingewiesen, dass sowohl die MaRisk als auch die BAIT den Einsatz von Standards, und damit auch Standardsoftware – wo es möglich ist – fordert.

3. IT-Betrieb

Und zuletzt sei noch auf den IT-Betrieb eingegangen. Diese hat die Komponenten sauber zu dokumentieren, zum Beispiel im Hinblick auf Standorte und Supportzeiträume, regelmäßig zu aktualisieren und ein Lebenszyklus-Management zur Steuerung der Risiken aus veralteten bzw. nicht mehr vom Hersteller unterstützten Systemen vorzuhalten. Änderungen sowie auftretende Störungen sind zu dokumentieren und zu bewerten; bei Störungen ist zudem die Ursachenanalyse sowie die Lösungsfindung zu belegen. Übrigens ergibt sich aus der BAIT nicht die zwangsläufige Pflicht, die Störungen in wie auch immer gearteten Zeiträumen abzuhelfen. Eine Abhilfe ist selbstredend vonnöten, wenn dies der Risikoreduzierung dient. Ein Anspruch gegenüber dem Dienstleister, Abhilfe in einem gewissen, dem Dringlichkeitsgrad entsprechenden Zeitrahmen verpflichtend zu schaffen, ist zwar aus Kundensicht wünschenswert. In der Praxis jedoch nicht umsetzbar, zumal auch bei einem Eigenbetrieb eine allein an Dringlichkeitsstufen definierte Fehlerbehebungszeit praxisfern ist. Dies bedeutet nicht, dass mit einem Dienstleister, und das ist auch üblich, eine Reaktionszeit vereinbart wird, innerhalb dieser – je nach definierter Dringlichkeit – auf den Supportfall zu reagieren hat, mit dem Ziel, für eine baldmögliche Abhilfe Sorge zu tragen. Datensicherungen sind vorzunehmen und in einem Datensicherungskonzept zu regeln. Die Verfahren zur Datensicherung und – Wiederherstellung sind mindestens jährlich zu testen.

Fazit: die BAIT schaffen Überblick und schließen einen Cloud-Betrieb nicht aus

Die BAIT geben einen guten Überblick über Maßnahmen, die geeignet sind, IT-Risiken zu erkennen und zu minimieren. Man mag zwar einwenden, dass großteils Selbstverständlichkeiten beschrieben werden; aber die Praxis zeigt sicherlich, dass viele Unternehmen aus vielerlei Gründen in einzelnen Punkten Nachholbedarf haben oder es an geeigneten Strukturen, Dokumentationen und Prozessen fehlt.

Der Betrieb von Softwarelösungen in der Cloud stellt dabei keinen Gegensatz zu den Vorgaben der BAIT dar. Aber die Cloudanbieter müssen sich intensiv mit den Vorgaben auseinandersetzen, da vom Grundsatz her die Auslagerung des IT-Betriebs in die Cloud dem Eigenbetrieb bei den Banken vollkommen gleichsteht. Die Übernahme des Betriebs durch Fremddienstleister kann – gerade in Zeiten des Fachkräftemangels und der erkennbaren demografischen Entwicklung, wonach die „Baby Boomer“ langsam das Rentenalter erreichen – Freiräume geben, um den vielfältigen Monitoringaufgaben gewachsen zu sein. Zugleich reduziert man so das Risiko von Cyberangriffen, da sich die großen Cloudanbieter hier viel effektiver wehren können, als es – insbesondere kleine und mittelgroße – Finanzinstitute und andere Unternehmen könnten. Die BaFin wird den Instituten im Hinblick aus den Anforderungen der BAIT heraus gewiss keine Steine in den Weg legen.

Und auch in der Praxis kann ein hohes Maß an IT-Sicherheit nur hergestellt werden, wenn ein vertrauensvolles Miteinander zwischen den Fachbereichen einerseits und den Personen, die sich mit den Themen der IT-Sicherheit und -Umsetzung befassen, herrscht. Nur im gemeinsamen Zusammenspiel können Risiken erkannt, bewertet und ggf. behoben werden. Die klare Definition von Verantwortlichkeiten, gerade auch in den Fachbereichen als „Prozess- und Risikoeigentümer“ kann hier hilfreich sein.

Exkurs: Strategien zur Identifizierung von und dem Umgang mit Informationsrisiken

Die MaRisk bzw. die BAIT sehen vor, dass bestehende bzw. zukünftige Risiken erkannt und rechtzeitig abgeholfen bzw. Strategien für eine Abwehr entwickelt werden. Hiervon umfasst sind neben den Geschäftsrisiken auch die Risiken aus dem Umgang mit Informationen bzw. dem IT-Betrieb. Eine derartige Risikostrategie baut dabei auf folgenden vier Fragestellungen auf:

• Art des Risikos: Hier gilt es zu identifizieren, welche Risiken das Institut im IT-Bereich überhaupt bestehen, um daraus abzuleiten, welche Risiken im Rahmen einer Risikostrategie betrachtet werden sollen.
• Herkunft bzw. Ursache des Risikos
• Dauer des Risikos und Zeitpunkt des Risikoeintritts: Wann entsteht das Risiko und wie lange wird die Risikosituation anhalten?
• Risikoappetit und Risikotragfähigkeit: Welche Risiken können in welchem Umfang getragen werden?
• Wann bestehen existentielle Bedrohungen?

Es können danach folgende Optionen zum Umgang mit Risiken getroffen werden:

• Risikoakzeptanz: Das Risiko ist bewusst und beherrschbar; es kann vom Institut übernommen werden.
• Risikoreduktion: Das Risiko wird durch vorausschauende Maßnahmen im Vorfeld reduziert, zum Beispiel durch den Einsatz von gewarteter, marktgängiger Standardsoftware im Vergleich zu einer Software-Individualentwicklung.
• Risikoausschluss: Das Risiko wird bewusst nicht eingegangen oder kann im Vorfeld durch vorausschauende Maßnahmen rechtzeitig ausgeschlossen werden, zum Beispiel durch Nutzung mehrerer georedundanter Rechenzentren (Weiterbetrieb bei Ausfall eines Rechenzentrums).
• Risikotransfer: Das Risiko wird auf einen Dritten übertragen (z.B. Cloudbetrieb) oder ein Dritter zahlt eine Entschädigung im Risiko-Eintrittsfall (z.B. Versicherung).