Wie eine Finanz-IT den Wechsel zu Managed WAF durchzog 

Wie läuft eigentlich der Wechsel zu einer Cloud-basierten DDoS- und WAF-Lösung ab? Ein Praxisbericht aus der Finanzbranche zeigt, worauf es bei der Auswahl, Migration und dem laufenden Betrieb wirklich ankommt. 

Borut Lape ist Senior Cyber Security Officer bei der Quipu GmbH, dem zentralen IT-Dienstleister der Procredit Group. Die Gruppe betreibt Banken in Osteuropa und Deutschland, Hauptsitz Frankfurt. Wer für Finanzinstitute die IT verantwortet, hat wenig Spielraum bei Ausfällen und noch weniger bei DDoS-Angriffen auf Online-Banking-Dienste.

Trotzdem passierte genau das: Innerhalb eines Jahres traf es Quipu dreimal. Keine volumetrischen Angriffe, aber gezielte Web-Application-Attacken, die die Dienste trotzdem in die Knie zwangen. Der Grund war ernüchternd simpel: Man hatte sich auf den integrierten Schutz des Cloud-Anbieters verlassen.

Der Cloud-Schutz reichte nicht

Die Frontend-Server liefen bereits in der Cloud, Rate-Limiting und Buffer-Funktionen des Providers sollten genügen. „Wir haben angenommen, dass wir ausreichend geschützt sind“, sagt Lape. Die Angreifer brauchten dafür keine riesigen Botnetze. Bereits eine überschaubare Anzahl von Bots reichte, um Dienste zum Absturz zu bringen.

Die einzige Sofortmaßnahme war, Rate-Limits herunterzuschalten oder den Zugriff auf bestimmte Länder zu sperren. Beides schränkte die Funktionalität der Dienste erheblich ein. Für ein Institut, das digitales Banking als Kernprodukt versteht, keine akzeptable Dauerlösung. Die Anfrage an den Cloud-Anbieter nach einer besseren Konfiguration brachte keine befriedigende Antwort. Es gebe keine universelle Lösung, hieß es, man müsse den Schutz pro Ressource manuell tunen, ohne Garantien.

Marktanalyse mit unerwarteten Hürden

Quipu begann, den Markt systematisch zu sondieren. Top-Anbieter wurden kontaktiert, Präsentationen eingeholt, erste Anforderungen kommuniziert. Dabei zeigte sich schnell: Die Anbieter arbeiten mit sehr unterschiedlichen Preismodellen. Manche verlangen nach Traffic-Volumen, andere nach Anzahl der URLs oder Domains, wieder andere schnüren Bundles. Das machte einen direkten Vergleich schwierig.

Zwei eigene Anforderungen erwiesen sich dabei als echte Stolpersteine. Erstens betreibt Quipu Dienste auf Custom Ports, also nicht nur auf den Standardports 80 und 443. Viele Anbieter unterstützen das schlicht nicht. Zweitens wollte man einen vollständig verwalteten Dienst, eine sogenannte Managed WAF. Dabei handelt es sich um eine Web Application Firewall, die nicht selbst betrieben wird, sondern vom Anbieter rund um die Uhr überwacht, gepflegt und bei Bedarf angepasst wird. Sie analysiert den eingehenden HTTP-Datenverkehr, erkennt Angriffsmuster wie SQL-Injection oder gezielte DDoS-Attacken auf Anwendungsebene und blockt sie, bevor sie die eigenen Systeme erreichen.

Die Erfahrung mit einer früheren On-Premise-WAF-Lösung hatte gelehrt, was passiert, wenn internes Know-how abwandert und niemand mehr das System sauber administrieren kann.

On-Premise vs. Cloud-managed: Der entscheidende Unterschied

Sean Power, Solution Engineer bei Link11, erklärt den Unterschied so: Bei einer On-Premise-Appliance kauft man Hardware, lässt sie ins eigene Rechenzentrum liefern, installiert sie im Rack und trägt ab dann alle Verantwortung selbst. Lizenzkosten, Betrieb, Personal. Der kritischere Punkt aber: Kommt ein Angriff, ist er bereits im eigenen Rechenzentrum angekommen, bevor die Appliance überhaupt reagieren kann. Die Bandbreite ins Datacenter kann schlicht nicht mithalten, und andere Systeme im selben Rack leiden unter dem Kollateralschaden.

Eine vollständig cloud-basierte Managed-Lösung dreht das Prinzip um: Der Angriff bleibt in der Cloud und erreicht das Rechenzentrum nie. Kein Capex für Hardware, kein Warten auf Lieferung, kein Personalaufwand für den Betrieb.

Für Quipu, dessen Dienste ohnehin bereits in der Cloud liefen, war eine virtuelle Appliance in der Cloud zwar theoretisch denkbar. Aber auch das hätte Ressourcenplanung, Patching und laufende Wartung bedeutet. Kein attraktiver Weg.

Warum Link11 den Zuschlag bekam

Link11 war bereits als DDoS-Schutzanbieter für die Netzwerkinfrastruktur im Einsatz, mit guter Erfahrung. Also wurde das Unternehmen in den Evaluierungsprozess einbezogen. Was dann auffiel: Während große Anbieter träge reagierten, lange auf Angebote warten ließen und wenig Interesse an den spezifischen Anforderungen zeigten, agierte Link11 anders. Persönlicher Kontakt, schnelle Rückmeldungen und vor allem ein dedizierter Engineer, der sich tief in jede einzelne Applikationskonfiguration einarbeitete.

„Wir hatten das Gefühl, für die großen Player ein kleiner Kunde zu sein“, sagt Lape. Bei Link11 sei das anders gewesen.

Power beschreibt die Passgenauigkeit aus seiner Perspektive so: Etwa 75 Prozent der Anforderungen deckten die Standardfunktionen ab, weitere 20 Prozent ließen sich durch Konfiguration lösen. Die restlichen fünf Prozent wurden eigens entwickelt. Kein vorgefertigtes Paket, bei dem sich der Kunde anpassen muss, sondern eine Lösung, die sich dem Kunden anpasst.

Migration: Kein Sprint, sondern ein kontrollierter Dauerlauf

Die Implementierung läuft noch. Mehr als die Hälfte der Anwendungen ist bereits migriert, aber noch nicht mit allen verfügbaren Sicherheitsfunktionen. In einer Bankenumgebung ist das eine bewusste Entscheidung: Jeder Schritt wird sorgfältig getestet, jede Änderung analysiert.

Der Zeitplan sieht rund drei Monate für das grundlegende Onboarding aller Ressourcen vor, danach nochmals drei bis sechs Monate, um alle Sicherheitsfunktionen vollständig zu aktivieren. Power räumt ein, dass das zu den längeren Onboardings gehört, sieht darin aber keinen Nachteil. Technisch wäre ein Onboarding in wenigen Stunden möglich. Aber schnell ist nicht dasselbe wie sicher.

Was andere daraus lernen können

Lapes Ratschlag an Unternehmen, die Ähnliches vorhaben: Zuerst die eigene Infrastruktur gründlich inventarisieren. Bei Quipu tauchten im Laufe der Migration noch Dienste auf, die anfangs nicht im Blick waren und besondere Anforderungen mitbrachten. Dann ausreichend Zeit für Tests einplanen und dabei nicht nur auf Papier und Präsentationen vertrauen, sondern die Zusammenarbeit mit dem Anbieter im echten Betrieb erproben. Denn zwischen dem, was ein Anbieter verspricht, und dem, wie die tägliche Zusammenarbeit tatsächlich läuft, liegt manchmal ein erheblicher Unterschied.