Kontinuierliche Sicherheit, kontinuierliche Compliance

Wer ist diese Bank?

Diese Case Study beschreibt eine etablierte europäische Bank: ein reguliertes Institut mit einer Bilanzsumme im Milliardenbereich und einem weitverzweigten Filialnetz. Sie betreut Privat- und Firmenkunden und gehört zu einer größeren Bankengruppe, deren Mitglieder zentrale Dienste und Infrastruktur gemeinsam nutzen.

Anders als viele kleinere Institute, die den Großteil ihrer IT vom gemeinsamen Dienstleister der Gruppe beziehen, betreibt diese Bank einen großen Teil ihrer Infrastruktur selbst: das gesamte LAN, WAN und SD-WAN, den kompletten Security-Stack vom Endgerät bis zum Perimeter, den Rechenzentrumsbetrieb, die Storage-Virtualisierung und die Telekommunikation. Rund 70 bis 75 Prozent davon liegen nach wie vor on-premises – auf Basis von VMware, mit Windows- und Linux-Servern sowie Windows- und Mac-Endgeräten. Die Sicherheitsfunktion ist schlank aufgestellt: ein einziger Head of Security, unterstützt von einem kleinen Team und externen Beratern.

Was hat DORA für die Bank verändert?

Für den Head of Security der Bank ist die größte Bedrohung dieselbe geblieben: ein erfolgreicher Angriff – meist Ransomware –, der den Geschäftsbetrieb zum Stillstand bringt, weil die Systeme nicht mehr verfügbar sind. Verändert hat sich der Maßstab, an dem er gemessen wird. Für Banken hat DORA Vorrang: Inhaltlich überschneidet sie sich weitgehend mit der breiter angelegten NIS2-Richtlinie, doch als finanzsektorspezifische Regelung ist sie für Banken maßgeblich. Ihre Artikel zum IKT-Risikomanagement legen konkret fest, was zu tun ist und in welcher Qualität – mit der impliziten Erwartung, dass sich Unternehmen an anerkannten Frameworks wie der ISO-27001-Familie und NIST orientieren, ergänzt um die technischen Vorgaben der nationalen Cybersicherheitsbehörde.

Konkret wurde der Druck durch die verpflichtende Jahresprüfung der Bank. Diese wird nicht von einer Big-Four-Gesellschaft durchgeführt, sondern von ihrem externen Prüfungsverband – und sie schließt die IT-Prüfung ein. Die Prüfer bemängelten die fehlende Transparenz und Nachvollziehbarkeit des IKT-Risikomanagementprozesses und seiner Übergabe an das operationelle Risiko. Zu viele Medienbrüche zwischen den Systemen, manuelle, Excel-basierte Abläufe, wo Automatisierung längst hätte greifen müssen, und eine Methodik, die die Aufsicht nicht Schritt für Schritt nachvollziehen konnte.

Hinter der Feststellung steckte eine unbequemere Wahrheit über den Ausgangspunkt. Die Bank hatte überhaupt keine Härtungs-Baselines. Die Kennzahlen in ihrem Informationssicherheits-Managementsystem waren, in den Worten des Head of Security, schwach, rudimentär und spärlich. Key Risk Indicators (KRI) wurden von Hand zusammengetragen. Nichts davon hätte einer DORA-Prüfung standgehalten – und allen Beteiligten war das klar.

“Sie haben vier Excel-Tabellen, und irgendwann fließt daraus etwas ins operationelle Risiko – aber wir können nicht nachvollziehen, wie Sie von A nach B kommen. Bitte erklären Sie das.”

Die Prüfungsfeststellung, so wie der Head of Security die Position der Aufsicht beschreibt

Wie funktioniert Mondoo als Drehscheibe?

Der Head of Security der Bank beschreibt Mondoo als die Schaltzentrale, in der alle Informationen zusammenlaufen. Den Nutzen sieht er in zwei Bereichen, beide gespeist aus derselben Datenbasis, einer Single Source of Truth. Zum einen versorgt die Plattform das IKT-Governance-Framework mit konkreten, aktuellen Informationen aus der Infrastruktur. Zum anderen gibt sie dem operativen Team eine risikogewichtete Grundlage, um Patch- und Schwachstellenmanagement zu priorisieren – wobei eine Jira-Integration die Behebung direkt in den bestehenden Workflow überführt. Entscheidend dabei: Die Frameworks und ihre Kontrollen sind als nachvollziehbarer Code in der Plattform hinterlegt. Es gibt also keine Mapping-Tabellen zu erstellen und keine Herleitungen von Hand zu dokumentieren.

Wie hat die Bank Härtungs-Baselines von Grund auf aufgebaut?

Am deutlichsten zeigt sich das bei der Härtung. Ohne Baselines als Ausgangspunkt drehte das Team die übliche Reihenfolge um: Man nimmt, was die Plattform prüft, erklärt das zur Anforderung und validiert anschließend jede Prüfung an der realen Umgebung. Lässt sich eine Kontrolle tatsächlich nicht erfüllen, weil ein Dienstleister der Gruppe eine Einstellung fest vorgegeben hat, auf die die Bank keinen Einfluss hat – etwa eine auf 10 Zeichen fixierte Mindestpasswortlänge gegenüber dem CIS-Level-2-Benchmark von 13 –, wird die Prüfung mit dokumentierter Begründung entfernt. So erfüllt die Bank laufend die aufsichtsrechtlichen Anforderungen – und das Bild ihrer Sicherheitslage bleibt zugleich ehrlich. Aus der Lücke heraus kann das Team seine Position risikogewichtet einordnen, Maßnahmen zur Behebung ableiten und regelmäßig sowie nachvollziehbar darüber berichten.

Wie werden DORA-Kennzahlen zum Nebenprodukt?

Dieselbe Disziplin zieht sich durch die Kennzahlen. KRIs und KPIs fließen heute automatisch aus Mondoo in den IKT-Risikomanagementprozess und das IKT-Risikoregister. Jede Kennzahl hat ein definiertes Profil: wie sie sich zusammensetzt, welcher Zielwert gilt und wie sie erhoben wird – jedes Mal auf dieselbe automatisierte, standardisierte und nachvollziehbare Weise. Was früher Handarbeit war, ist heute ein Nebenprodukt davon, dass die Plattform einfach ihre Arbeit macht.

Erst agentische Automatisierung macht das in dem Umfang und in dem Tempo möglich, die DORA verlangt. Zugleich sagt der Head of Security offen: Menschliches Urteilsvermögen lässt sich nicht wegautomatisieren. Zu entscheiden, welche Prüfungen für eine bestimmte Umgebung gelten, Ergebnisse zu validieren und über Ausnahmen zu urteilen – das ist Arbeit, die weder ein Tool noch eine KI abnehmen kann. Das ist keine Schwäche des Modells. Das ist die Kontrolle. Die Plattform liefert Nachweise in großem Umfang, und ein Mensch bleibt verantwortlich dafür, was sie bedeuten und welche operativen Änderungen daraus folgen – genau die Nachvollziehbarkeit, die die Aufsicht verlangt.

Was sollten neue Kunden über das Onboarding wissen?

Systeme und Infrastruktur in die Plattform zu bekommen, war – in seinen Worten – ein Kinderspiel. Die eigentliche Herausforderung liegt, wie bei jedem ernstzunehmenden Tool im Cyber- und Compliance-Umfeld, im Feintuning: zu entscheiden, welche Benchmarks für welche Systeme gelten, einzelne Prüfungen zu validieren und die Ergebnisse auf die Umgebung zuzuschneiden. Sein Rat an neue Kunden: der Versuchung widerstehen, alles auf einmal zu onboarden. Mit einem Asset-Typ anfangen – Windows-Endgeräte sind ein sinnvoller erster Kandidat. Verstehen, was die Plattform einem sagt, und erst dann erweitern. Wer gleich zu Beginn alles auf einmal will, verzettelt sich.

Dieser Erfahrungsbericht ist ehrlich, nicht geschönt – deshalb gehören auch die Reibungspunkte hierher. Weil die Agenten ihre Updates aus dem Internet beziehen, hat der Endpoint-Schutz der Gruppe etwas dagegen. Automatische Updates in nahezu Echtzeit sind für die Bank daher nicht möglich; sie spielt Updates stattdessen über die reguläre Softwareverteilung in einem langsameren Rhythmus aus. Es funktioniert, aber eben nicht automatisch. Hinzu kam ein einmaliges Reporting-Problem – Berichte wurden nicht erzeugt –, das im Rahmen des normalen Supportprozesses behandelt wurde. Und Mondoo ist keine vollständige End-to-End-GRC-Plattform – und will das auch nicht sein. Positiv hervorgehoben wurden das Entwicklungstempo, die neuen Integrationen und die durchweg kurzen Reaktionszeiten. Zur Kunden-Anbieter-Beziehung äußert sich der Head of Security unmissverständlich: rundum zufrieden.

Welche Ergebnisse hat die Bank erzielt?

Das messbare Ergebnis ist ein deutlich rückläufiger Trend bei den identifizierten Schwachstellen, festgehalten in einem früheren Review – getragen davon, dass das Team auf das reagiert, was die Plattform sichtbar macht. Das ist der Teil des Exposure Managements, auf den es am meisten ankommt: der Schritt vom Finden zum Beheben – die Lücke zwischen Entdeckung und Behebung schließen, statt nur darüber zu berichten.

Das strukturelle Ergebnis wiegt ebenso schwer: eine einzige Methodik und eine einzige Plattform statt zersplitterter, von Medienbrüchen durchzogener Abläufe – mit einem vollständigen Blick über die gesamte Systemlandschaft und nachvollziehbaren Nachweisen auf Abruf. Die Konsolidierung läuft bereits: Der klassische Schwachstellenscanner steht vor der Ablösung, der Wildwuchs an Tools wird reduziert, ein dediziertes Asset Management läuft parallel mit, und die Nachweise für Compliance und Exposure bündeln sich in Mondoo.

“Meiner Meinung nach sollte jede Bank damit arbeiten.”

Head of Security