Compliant, aber nicht sicher: Was der Fall V-Bank über die blinden Flecken regulierter Branchen verrät

Der V-Bank-Vorfall zeigt: Regulierung kann Risiken adressieren, aber Sicherheit entsteht nur dort, wo Regeln auch technisch durchgesetzt werden.

Der Vorfall bei der V-Bank ist zunächst ein klassischer Cybervorfall: Ein Angriff auf einen externen IT-Dienstleister führte zu einem unbefugten Zugriff auf Daten der Bank. Die V-Bank betont zugleich, dass ihre Sicherheitssysteme gegriffen hätten, dass zu keinem Zeitpunkt Konten oder Kontozugangsdaten betroffen gewesen seien und dass kein Geld abgeflossen sei; auch der operative Betrieb laufe weiter stabil. Genau diese Kombination macht den Fall für CISOs und CIOs interessant: Nicht das Kernbanksystem kollabierte, sondern ein angrenzender Teil der digitalen Lieferkette wurde zum Einfallstor.

Ein Vorfall in der digitalen Lieferkette

Bestätigt ist inzwischen mehr als nur ein “abstrakter Datenabfluss“. In ihren FAQ beschreibt die Bank, welche Daten nach aktuellem Kenntnisstand abgeflossen sind: Namen, Geburtsdaten, Kontaktinformationen wie Postanschrift, E‑Mail-Adresse und Telefonnummer sowie kontobezogene Informationen, darunter Vermögensstatus, Transaktionsdaten und Referenzkonten. Nicht betroffen gewesen seien dagegen Benutzernamen und Passwörter, Steuerdaten sowie der direkte Zugriff auf Konten oder Depots.

Nach derzeitigen Erkenntnissen stand der Vorfall im Zusammenhang mit einem externen zertifizierten IT-Dienstleister, der Cloud-Services für die V-Bank erbringt und Zugriff auf eine extern gehostete, vom Kernbanksystem getrennte Datenbank hat.

Die Bank hat nach eigenen Angaben Aufsichts- und Strafverfolgungsbehörden informiert, eine Taskforce gebildet und den vollständigen Neuaufbau des angegriffenen Systems eingeleitet; in diesem Zuge wurde auch die Endkunden-App abgeschaltet.

Regulierung setzt Leitplanken – aber keine Sicherheitsgarantie

Gerade weil der Finanzsektor stark reguliert ist, wirkt der Fall als Gegenbeispiel zur verbreiteten Annahme, Regulierung erzeuge automatisch Sicherheit.

Tatsächlich adressiert die Regulatorik das Problem durchaus: DORA verpflichtet Finanzunternehmen seit dem 17. Januar 2025 zu einem umfassenden IKT-Risikomanagement und zu einem Management von IKT-Drittparteienrisiken über den gesamten Lebenszyklus hinweg. Gefordert sind unter anderem Ex-ante-Risikobewertungen und Due Diligence vor Vertragsabschluss, vertraglich geregelte Unterstützung des Dienstleisters im Vorfallsfall, Exit-Strategien für kritische oder wichtige Funktionen sowie ein Informationsregister über bestehende IKT-Vertragsbeziehungen. BaFin fungiert dabei als nationaler Melde-Hub für IKT-Vorfälle im Finanzsektor.

Warum also bedeutet „compliant“ trotzdem nicht automatisch „sicher“?

Wirksame Sicherheit ist mehr als bloß ein bestandener Audit

Compliance in der Praxis verlangt zwar den Nachweis, dass Prozesse, Dokumentationen und Mindestkontrollen vorhanden sind; Sicherheit entscheidet sich jedoch daran, ob die dokumentierten Maßnahmen und Kontrollen im Alltag wirksam, aktuell und durchsetzbar sind.

Der Fall V-Bank illustriert genau diese Lücke: Drittparteienrisiko ist regulatorisch längst ein Thema, trotzdem reichte ein Angriffsweg über einen Dienstleister mit Zugriff auf eine externe Datenbank aus, um sensible Kundendaten zu kompromittieren.

DORA und die Aufsicht schaffen notwendige Leitplanken, aber keine technische Immunität. Für Finanzunternehmen (wie auch für jede andere Organisation) bleibt Sicherheit eine operative Disziplin mit kontinuierlicher Überwachung, Härtung, Rechtebegrenzung und schneller Reaktionsfähigkeit.

Wenn legitime Zugänge zum Risiko werden

Dass diese Lücke kein Sonderfall des deutschen Finanzmarkts ist, zeigen aktuelle Beispiele. Beim Angriff auf Change Healthcare gelangten Angreifer laut der öffentlichen Aussage von UnitedHealth-CEO Andrew Witty mit kompromittierten Zugangsdaten über ein Citrix-Portal in die Umgebung; für dieses Portal war keine Multifaktor-Authentifizierung aktiviert. Danach bewegten sich die Täter lateral im System, exfiltrierten Daten und setzten erst Tage später Ransomware ein. Der Fall war deshalb so gravierend, weil nicht nur ein Unternehmen, sondern ein zentraler Dienstleister innerhalb eines hochregulierten Sektors betroffen war – mit systemischen Auswirkungen auf ein ganzes Ökosystem. Das Muster ist dem der V-Bank nicht identisch, aber strukturell verwandt: Ein legitim wirkender Zugang – nicht zwingend ein klassischer Exploit – wird zum Hebel für einen weitreichenden Vorfall.

Ähnlich lehrreich war die Snowflake-Kampagne des Jahres 2024. Dort gab es nach öffentlich gewordenen Analysen keinen Produkt-Exploit im engeren Sinne; kompromittiert wurden vielmehr Kundenkonten, für die gestohlene Zugangsdaten vorlagen und bei denen keine MFA aktiviert war. Sicherheitsanalysen und Berichte betonten, dass die Kampagne auf Konten ohne Zwei-Faktor-Authentifizierung zielte und dass gestohlene Credentials – teils aus Infostealer-Kontexten – als Eintrittskarte dienten. Auch hier zeigt sich: Wo Identitäten und Zugänge nicht wirksam abgesichert sind, hilft die formale Existenz von Sicherheitsvorgaben oder Cloud-Governance-Dokumenten nur begrenzt. Nicht der Regelverstoß auf Papier, sondern die fehlende technische Durchsetzung an der Identität entscheidet.

In dieselbe Kategorie fällt auch FortiBleed: Die von Sicherheitsforschern so bezeichnete Kampagne rund um kompromittierte Fortinet-FortiGate- und SSL-VPN-Zugangsdaten gilt als Paradebeispiel dafür, wie wiederverwendete oder schwache Zugangsdaten, fehlende Multifaktor-Authentifizierung, unzureichende Härtung internetexponierter Managementschnittstellen und nicht vollständig umgesetzte Herstellerempfehlungen zu einem systemischen Risiko werden können. Die möglichen Folgen reichen von unbefugtem VPN- oder Administratorzugriff über Konfigurationsänderungen an Firewalls bis hin zu lateraler Bewegung, Persistenz und nachgelagerten Ransomware- oder Datendiebstahlkampagnen.

Auch hier liegt die Lehre weniger in einer einzelnen Schwachstelle als in der mangelnden operativen Durchsetzung vorhandener Sicherheitsmaßnahmen: Wer Passwörter rotiert, MFA erzwingt, Managementzugänge vom öffentlichen Internet trennt, Logs prüft und Geräte konsequent aktualisiert, reduziert genau jene Angriffsfläche, die FortiBleed so gefährlich macht.

Identitätssicherheit ist Kernbestandteil – aber nicht die ganze Antwort

Genau an diesem Punkt trifft ein Kommentar von Bare.ID-CEO Elmar Eperiesi-Beck ins Schwarze. Ja, IAM, Least Privilege, phishing-resistente MFA und perspektivisch Passkeys sind zentrale Bausteine, weil sie kompromittierte Identitäten und unnötige Berechtigungen direkt adressieren.

Aber für Enterprise-Sicherheit reicht es nicht, Identitäten sauber zu verwalten, wenn Drittparteienzugriffe, externe Datenbanken, Cloud-Administrationspfade und privilegierte Service-Konten nicht in ein ganzheitliches Sicherheitsmodell eingebettet sind.

Auch DORA verweist neben dem Drittparteienmanagement ausdrücklich auf Risikomanagement, Incident Reporting, Resilienztests und Aufsichtsmechanismen für kritische IKT-Drittdienstleister.

Mit anderen Worten: Identitätssicherheit ist ein Kern, aber kein Ersatz für Zero-Trust-Architekturen, Monitoring und Detection, Netzwerk- und Datensegmentierung, belastbare Incident-Response-Prozesse und klare Governance.

Die operative Lehre für CISOs und CIOs

Für CISOs und CIOs liegt die eigentliche Lehre deshalb weniger in der Forderung nach noch mehr Compliance, sondern in der Frage, wo die reale Kontrolllücke sitzt.

Erstens müssen Unternehmen Drittparteien nicht nur vertraglich, sondern auch technisch steuern: mit vollständigem Inventar, risikobasierten Zugriffsmodellen, laufender Überprüfung von Berechtigungen und klaren Exit- sowie Sperrmechanismen für kompromittierte Partnerkonten.

Zweitens gehört Identitätssicherheit an die Spitze der Prioritätenliste – nicht als IAM-Projekt, sondern als operative Durchsetzung von Least Privilege, starker Authentisierung und zentral widerrufbaren Zugängen über interne wie externe Identitäten hinweg.

Drittens braucht es Sichtbarkeit: Protokollierung, Anomalieerkennung und ein Incident-Response-Modell, das gerade bei Vorfällen in der Lieferkette schnell genug ist, um einen externen Zugang automatisiert zu isolieren.

Und viertens sollte Governance nicht bei der Frage enden, ob ein Institut DORA-konform dokumentiert ist; entscheidend ist, ob die Organisation im Ernstfall einen betroffenen Dienstleister, ein kompromittiertes Konto oder eine gefährdete Datenverbindung in Minuten statt in Tagen unter Kontrolle bekommt.

Fazit

Der Fall V-Bank ist damit kein Beleg für das Scheitern von Regulierung – sondern für die nüchterne Einsicht, dass Regulierung nur den Rahmen setzt. Sicherheit entsteht dort, wo dieser Rahmen technisch und organisatorisch wirksam umgesetzt wird.

Unternehmen und Organisationen brauchen nicht mehr Compliance-Vorgaben", ist Eperiesi-Beck überzeugt. “Vielmehr benötigen sie erprobte technologische Lösungen, die Identitäten und damit Zugänge zu den Systemen von Grund auf schützen. Angriffe wie auf die V-Bank zeigen, dass die digitale Lieferkette die Angriffsfläche erheblich erweitert.”