Cloud und Deep Observability für Banken-Compliance

Schwerpunkt: Rechenzentren & Digitale Souveränität

Tiho Saric von Gigamon hat langjährige Expertise in den Bereichen Deep Observability, Zero Trust und hybride Cloud-Sicherheit. Ein Interview. — Tiho Saric, Senior Sales Director, Gigamon Gigamon

Vor dem Hintergrund strenger Regulatorien wie DORA, dem EU AI Act und BaFin-Prüfungen zeigt Tiho Saric im Interview, wie Finanzinstitute durch Netzwerktransparenz compliance-konform agieren können. Dabei verdeutlicht er, wie Banken durch gezielte Datenfilterung nicht nur blinde Flecken eliminieren, sondern gleichzeitig ihre IT-Kosten senken.

von Dunja Koelwel

Herr Saric, können Banken im Falle einer BaFin-Prüfung lückenlos belegen, welche Datenströme zwischen den On-Premise-Systemen und Cloud-Workloads geflossen sind – unabhängig von den (manipulierbaren) Log-Daten der Cloud-Provider?

Ja das ist möglich. Es setzt allerdings voraus, dass der gesamte relevante Netzwerkverkehr an den Übergabepunkten zwischen zentralem Rechenzentrum und der Cloud beziehungsweise zwischen Niederlassungen und der Cloud an einer eigenen Beobachtungsschicht gespiegelt wird. In Software-Lösungen kommen dafür TAPs (Test Access Points), Switched Port Analyzer (SPAN) und VPC-Mirroring zum Einsatz. Mit diesen Werkzeugen können Banken alle Verbindungen selbst entweder als PCAPs oder angereicherte Flow-/Metadaten erfassen, ohne dass der normale Netzwerkbetrieb gestört wird. So entsteht ein eigener, unveränderbarer Beleg darüber, welche Datenströme wann und wohin geflossen sind, ohne auf Logs der Cloud-Provider angewiesen zu sein.

Wie können Banken die Aktivitäten externer Dienstleister (z.B. Cloud-Plattformen oder SaaS) in Echtzeit überwachen, um sicherzustellen, dass keine unautorisierten Datenabflüsse stattfinden?

Indem sie den gesamten Netzwerkverkehr zu und von externen Dienstleistern bereits an der Quelle abgreifen (Edge, Datacenter-Egress, Cloud-VPCs) und in Echtzeit an SIEM, NDR und DLP weitergeben. Gigamon liefert hier zusätzlich kontextreiche Anwendungs- und Cloud-Metadaten (z.B. App-Name, User, Ziel-SaaS, Datenmenge), sodass IT-Teams ungewöhnliche oder unautorisierte Transfers (z.B. großer Upload zu einem neuen SaaS-Ziel) direkt erkennen und in Beziehung setzen können – unabhängig davon, was Dienstleister selbst loggen.

Problem: Root-Cause-Analyse

Sind Banken in der Lage, innerhalb der engen DORA-Fristen eine belastbare Root-Cause-Analyse auf Basis von Netzwerk-Paketen (PCAPs) zu liefern, anstatt nur auf aggregierte Statistiken zu vertrauen?

Prinzipiell ja. Voraussetzung dafür ist allerdings eine Traffic-Erfassungsschicht. Finanzunternehmen zeichnen dafür an definierten Kontrollpunkten wie Zahlungsschnittstellen, Handelsplattformen, zentrale APIs oder kritische Cloud-Workloads Pakete beziehungsweise hochaufgelöste Metadaten auf. Kommt es zu einem Zwischenfall, stehen vollständige PCAPs und/oder detaillierte Sessions zur Verfügung, um eine Root-Cause-Analyse auf Paketebene, inklusive Ablaufkette, kompromittierte Systeme, exfiltrierte Daten, durchzuführen. Somit ist es möglich, DORA-Fristen mit belastbaren, forensisch verwertbaren Nachweisen einzuhalten, anstatt nur mit Metrik-Charts zu arbeiten.

Mit dem EU AI Act und den BaFin-Orientierungshilfen wird die Kontrolle über Trainingsdaten für KI-Modelle zur Pflicht. Wie können Banken garantieren, dass interne KI-Modelle zur Betrugserkennung nur mit anonymisierten oder maskierten Datenströmen trainiert werden, ohne dass sensible Kundendaten jemals den sicheren Bereich verlassen?

Das lässt sich durch die architektonische Trennung in der Netzwerkbeobachtungsschicht realisieren. In einer hochgesicherten Zone findet zunächst zentralisierte, policy-gesteuerte Entschlüsselung des relevanten Traffics statt. Direkt dort werden anschließend Filter-, Maskierungs- und Anonymisierungs-Regeln angewendet. Beispielsweise lassen sich Kartennummern, Namen, IBANs oder IDs entfernen oder maskieren.

Nur diese bereinigten Ströme (z.B. Transaktionstyp, Beträge in Buckets, Zeitverhalten, Geo-Infos) werden in Data-Lakes, Feature-Stores oder KI-Plattformen weitergeleitet.“

Alle Rohdaten mit Klarnamen bleiben im gesicherten Bereich und werden nicht exportiert.

Wie viel Budget könnten Banken einsparen, wenn man den Datenballast für SIEM (z.B. Splunk) um 70–80 % reduziert, indem Duplikate und irrelevante Traffic-Daten bereits an der Quelle herausgefiltert wird?

Tiho Saric, Gigamon

Tiho Saric ist Senior Sales Director bei Gigamon (Webseite) und befasst sich seit vielen Jahren mit Themen wie Deep Observability, Zero Trust und der Absicherung hybrider Cloud Umgebungen.

Da SIEM-Lizenzen und Infrastrukturkosten im Wesentlichen vom Datenvolumen abhängen, verhalten sich die Einsparungen in der gleichen Größenordnung. Ein Beispiel: Unternehmen XY kommt auf ein Volumen von 100 TB SIEM-Ingest pro Tag und muss dafür jährlich insgesamt (TCO; inklusive Lizenz, Storage und Compute) etwa 1,5 Millionen Euro bezahlen.

Eine 70-prozentige Reduktion des SIEM-Ingests (also nur noch 30TB pro Tag) schlägt sich in der Regel in 50 bis 60 Prozent geringeren SIEM-Kosten nieder, was ungefähr einer Ersparnis von 0,8 – 0,9 Millionen Euro pro Jahr entspricht. Bei einer 80-prozentigen Ingest-Reduktion wäre die Ersparnis entsprechend noch größer.

Problem: Blind Spots

Die Migration in die Cloud (z.B. AWS, Azure) schafft neue „Blind Spots“, während alte Kernbank-Systeme oft nicht agentenfähig sind. Wie lassen sich Bewegungen von Angreifern innerhalb von Cloud-Containern oder virtuellen Servern sichtbar machen, wenn herkömmliche Firewalls diesen internen Verkehr gar nicht erfassen?

Eine durchgehende Ost-/Westsicht in allen Netzwerksegmenten lässt sich auch ohne Agenten realisieren. Dabei kommen auf On-Prem, beziehungsweise Kernbankensystemen physische TAPs oder SPAN an Switches und Routern zum Einsatz. In Cloud-Umgebungen können Banken VPC/VNET-Traffic-Mirroring und virtuelle TAPs (z.B. GigaVUE Cloud Suite) nutzen, um den internen Traffic zwischen VMs, Containern und Microservices zu spiegeln. Ergänzend dazu existiert mit Precryption ein Tool, das auch verschlüsselten lateralen Verkehr sichtbar macht.

Die so gewonnenen Pakete und Metadaten gehen an NDR-, SIEM- und Forensik-Lösungen. Damit werden laterale Bewegungen von Angreifern innerhalb von Containern oder VMs sichtbar, auch wenn Firewalls diesen internen Verkehr nie gesehen hätten. Dies ist konsistent über Datacenter, Private Cloud und Public Cloud hinweg möglich.

Herr Saric, vielen Dank für das Interview.dk