Kollateralschaden im Cyberspace
Wenn Sicherheit zur Schwachstelle wird
Unterschätzter Einfluss geteilter Infrastrukturen auf die Resilienz digitaler Systeme
Von Marco Eggerling, Global CISO bei Check Point Software Technologies
Unerwartete Cyber-Bedrohungen können die Budgets für Cyber-Sicherheit schnell aufbrauchen und sorgfältig geplante Strategien zum Scheitern bringen. Unter diesen Herausforderungen sind DDoS-Angriffe (Distributed Denial of Service) ein Paradebeispiel dafür, wie unerwartete Risiken selbst die sichersten Systeme stören können. Um den Ablauf eines solchen Angriffs zu erörtern, stellen wir uns als fiktives Beispiel eine Bank vor.
Es ist ein normaler Abend im Security Operations Center (SOC) dieser Bank, wo das Team vor der Schichtübergabe die Fallanalysen abschließt. Plötzlich wird die Ruhe durch einen wichtigen Sicherheitsalarm unterbrochen. Dieser wurde ausgelöst, um eine starke Zunahme der Aktivitäten zu untersuchen, die sich auf die Firewalls der Bank auswirkten. Der Vorfall verursacht auch unerwartete Störungen beim Online-Banking, einer Plattform, die mit robusten Sicherheitsmaßnahmen wie DDoS-Schutz im Netzwerk und einer Web Application Firewall (WAF) ausgestattet ist.
Hier kommt der unterschätzte Einfluss geteilter Infrastrukturen auf die Resilienz digitaler Systeme zum Tragen. Trotz hochentwickelter Schutzmechanismen gerät die Online-Banking-Plattform unserer fiktiven Bank ins Wanken – nicht durch einen direkten Angriff, sondern als Kollateralschaden eines parallelen Angriffs auf ein anderes System.
Als glaubwürdigen Ausgangspunkt nehmen wir einen Angriff auf das sogenannte 3D-Secure-System an, das bei Online-Kreditkartentransaktionen zur Betrugsprävention eingesetzt wird. Cyber-Kriminelle nutzten gestohlene Kreditkartendaten, um über massenhafte Kleinsttransaktionen herauszufinden, welche Karten noch aktiv sind. Dieses Vorgehen erzeugte ein hohes Datenvolumen, das gezielt auf IP-Adressen des 3DS-Systems gerichtet war. Die Folge: Eine Überlastung des Netzwerks, die auf sämtliche Systeme übergriff, die denselben Perimeter oder dieselben Sicherheitsmechanismen nutzten – darunter auch das Online-Banking der Bank. Die Plattform wurde also nicht angegriffen, aber sie litt dennoch unter den Folgen.
Nun sagen wir, dass die Verteidigungsmaßnahmen schnell griffen. Über sogenanntes Traffic Scrubbing – das Umleiten und Filtern des Datenverkehrs über externe Infrastruktur – konnte der Angriff technisch eingedämmt werden. Doch auch diese Maßnahme hatte ihren Preis: Die zusätzliche Latenz beeinträchtigte die Service-Qualität und der gesamte Datenfluss verlangsamte sich spürbar. Noch gravierender waren jedoch die strukturellen Konsequenzen. Um die Sicherheit langfristig zu gewährleisten, musste das 3DS-System in die WAF integriert werden – mit separaten Regeln, dediziertem Schutz und deutlich höheren Kosten. Ein nicht unbeträchtlicher Teil des IT-Sicherheitsbudgets unserer fiktiven Bank wurde dafür umgewidmet.
Die zentrale Lehre aus diesem Beispiel ist unbequem, aber notwendig: Sicherheit endet nicht an den Grenzen einzelner Systeme. Wer Infrastruktur gemeinsam nutzt, teilt auch das Risiko. Der Angriff auf einen vermeintlich isolierten Teil kann unbemerkt auf andere Bereiche übergreifen – besonders dann, wenn Schutzmaßnahmen nicht konsequent segmentiert oder individuell ausgelegt sind. Hier liegt eine der größten Herausforderungen moderner Cybersecurity: Die Balance zwischen Effizienz und Isolation, zwischen Kostendruck und technischer Redundanz.
Zugleich zeigt der Vorfall, dass auch die besten präventiven Schutzmechanismen versagen können, wenn die Struktur, auf der sie aufbauen, nicht stabil genug ist. Firewalls, DDoS-Abwehrlösungen und Web Application Firewalls können nur so stark wirken, wie es das zugrunde liegende Netzwerkdesign erlaubt. Sichtbarkeit auf der Netzwerkebene reicht nicht aus, wenn kritische Dienste miteinander verknüpft sind. Die Entscheidung, bestimmte Schutzmaßnahmen inline zu betreiben, mag aus Sicherheitsgründen sinnvoll erscheinen, sie kann aber die Transparenz in akuten Krisensituationen deutlich verringern.
Die strategische Konsequenz daraus muss eine tiefere Integration von Sicherheitsarchitektur und Geschäftsverständnis sein. Wer für Cybersecurity verantwortlich ist, muss nicht nur Angriffsvektoren erkennen und technische Lösungen implementieren, sondern vor allem das Geschäft und seine Prozesse verstehen. Nur wer weiß, welche Systeme wie miteinander verknüpft sind und welche Abhängigkeiten bestehen, kann Risiken realistisch bewerten und Prioritäten richtig setzen. Die Budget-Planung muss dabei ebenso mitgedacht werden.
Sicherheit ist keine statische Größe, sondern ein dynamisches Feld – geprägt von stets aktualisierten Bedrohungen, technischen Neuerungen und regulatorischen Anforderungen. Wer heute investiert, muss morgen auf das Unvorhergesehene reagieren können. Ein finanzieller Spielraum – etwa durch eine Budgetreserve von zwanzig Prozent – sollte Standard sein. Ebenso unverzichtbar sind regelmäßige Krisenübungen, klare Eskalationsmechanismen und personell wie strukturell abgesicherte Reaktionsprozesse. Sogar dann, wenn ein Angriff erfolgreich abgewehrt wird, entscheidet der Umgang mit seinen Nebenwirkungen über die tatsächliche Resilienz eines Unternehmens.
Schließlich bleibt auch die Rolle des Menschen zentral. Künstliche Intelligenz und Automatisierung können helfen, schneller zu reagieren und verdächtige Muster zu erkennen. Doch die Verantwortung für Entscheidungen, für Kommunikation mit Behörden, Kunden oder der Öffentlichkeit, verbleibt beim Menschen. Die Komplexität von Krisen verlangt daher Führung, nicht nur technische Reaktion.
Unser Fallbeispiel ist zwar erfunden, aber seine Aussagekraft real. Kollateralschäden im Cyber-Raum sind keine Phänomene. Sie sind Ausdruck eines Sicherheitsverständnisses, das noch zu häufig in isolierten Kategorien denkt. Wer Sicherheit ernst nimmt, muss sie als verzahnt mit allem begreifen – technisch, organisatorisch, strategisch. Nur so lässt sich verhindern, dass Schutzmechanismen selbst zur Schwachstelle werden und Angriffe auf andere Systeme durchschlagen. (Check Point Software Technologies: ra)
eingetragen: 09.05.25
Check Point Software Technologies: Steckbrief
Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.