KI-gestützte Angriffe: Was „Claude Mythos” Banken lehrt

Mondoo
Interview: David Wolf
Herr Münch, Anthropics KI „Claude Mythos” fand in öffentlich zugänglichen Tests so genannte Zero-Day-Schwachstellen in viel genutzten Betriebssystemen und Webbrowsern. Anthropic selbst warnte, dass die Fähigkeiten seiner KI recht bald auch Online-Angreifern zur Verfügung stehen könnten. Müssen bei Finanzinstituten jetzt sämtliche Alarmglocken schrillen?
Das Bild der „schrillenden Alarmglocken” überzeichnet einen Teil und untertreibt einen anderen. Die Entdeckungsfähigkeit, die Mythos demonstriert, ist nicht beispiellos; neu sind Geschwindigkeit und Skalierung, mit denen sie eingesetzt werden kann.
Für die global systemrelevanten Banken in Programmen wie „Project Glasswing” ist das vertrautes Terrain. Für das deutsche regionale Finanzsystem – rund 700 Volksbanken und Sparkassen auf gemeinsamen Kernbankenplattformen – ist die Konsequenz strukturell.
Die entscheidende Frage für diese Institute lautet nicht, ob das Budget für Cybersicherheit mit dem einer Großbank mithalten kann. Sie lautet: Kann das Institut gegenüber dem Prüfer kontinuierlich und ohne Lücken nachweisen, dass seine Härtungsbaseline gegen das hält, was heute tatsächlich im Bestand läuft? Genau das verlangt DORA bereits.
KI-beschleunigte Schwachstellensuche macht die Differenz zwischen Anforderung und gelebter Realität lediglich sichtbarer – und im nächsten Prüfzyklus schwerer wegzudiskutieren.
Finanzinstitute nutzen oft dieselben Produkte, Drittdienstleister und Sicherheitsmechanismen. Wie lässt sich verhindern, dass eine einzelne Schwachstelle bei einer Bank nicht für die ganze Branche zum Problem wird?
Die strukturelle Konzentration ist real und kaum vermeidbar: Genossenschafts- und Sparkassensektor laufen jeweils auf wenigen, stark standardisierten Plattformen, betrieben durch Atruvia beziehungsweise Finanz Informatik. Eine Schwachstelle in einer dieser Plattformen ist per Definition eine Schwachstelle in hunderten Instituten gleichzeitig. Die ICT-Risiko-Verantwortung nach DORA verbleibt jedoch beim Einzelinstitut.
Drei Mechanismen reduzieren das Systemrisiko in der Praxis: Erstens muss die Härtungspolicy auf Verbundebene als Code formuliert sein: versioniert, abfragbar und in automatisierbarer Form an die Institute geliefert werden, nicht als PDF-Hinweis.
Die Zeit zwischen dem Bekanntwerden von Schwachstellen und Risiken für eine Verbund-Plattform und einer koordinierten Behebung in jedem Institut muss als „Key Risk Indicators” gemessen werden.“
Zweitens muss jede institutsspezifische Abweichung mit aufsichtsrechtlicher Begründung und der zugehörigen kompensierenden Maßnahme dokumentiert sein. So sieht der Verbund in der Aggregation, wo seine standardisierte Baseline tatsächlich nicht greift.
Drittens muss die Zeit zwischen dem Bekanntwerden von Schwachstellen und Risiken („Common Vulnerabilities and Exposures”, CVE) für eine Verbund-Plattform und einer koordinierten Behebung in jedem Institut als „Key Risk Indicators” (KRI) gemessen werden statt in herstellerspezifischen Einzelmeldungen zu verschwinden.
Ein Konzentrationsrisiko verschwindet nicht durch eine geteilte Plattform; es verlagert sich auf die Organisation, deren Schließungsgeschwindigkeit über das Sektor-Risiko entscheidet.
Dennis-Kenji Kipker, wissenschaftlicher Direktor des Cyberintelligence Institute, betont, DORA oder NIS2 seien zwar notwendig, aber noch nicht ausreichend. Die Balance zwischen Angriff und Verteidigung kippe. Wie sollten Finanzinstitute ihre technisch-organisatorischen Schutzmaßnahmen (TOMs) und Risikomanagement-Systeme zukünftig anpassen?
Patrick Münch ist CSO und Mitgründer von Mondoo (Website). Als Experte für IT-Sicherheit baute er bei der SVA ein erfolgreiches Team für Penetrationstests und Incident Response auf, um das Sicherheitsniveau von Unternehmen zu stärken und die Auswirkungen von Hackerangriffen zu begrenzen. Seine Schwerpunkte liegen in der Absicherung von Infrastrukturen sowie im Hacken von Hard- und Software. Bei Mondoo nutzt er seine langjährige Erfahrung, um Kunden vor Cybersecurity-Bedrohungen zu schützen.Bedrohungen durch Frontier-Modelle erfordern einen Übergang vom dokumentenbasierten Nachweis hin zu kontinuierlichem, code-basiertem Nachweis — sowohl auf Ebene der TOMs als auch im Risikomanagement. Drei Veränderungen sind zentral:
Erstens muss die KRI-Erhebung das Stadium der Tabellenkalkulation verlassen. In vielen Instituten werden zentrale Risikoindikatoren für DORA noch über Medienbrüche hinweg und mit Excel als führendem System zusammengetragen.
In der Geschwindigkeit, in der KI-gestützte Schwachstellensuche heute operiert, lässt sich auf diesem Weg kein aktuelles Lagebild erstellen. Die Nachweisebene muss automatisiert, versioniert und jederzeit rekonstruierbar werden.
Zweitens sollten Banken den Härtungsansatz umdrehen. Wer einen idealisierten Benchmark – CIS oder BSI-Grundschutz – als Ziel definiert, bekommt eine dokumentierte Lücke, die niemand systematisch schließt, weil Verbundplattformen den Benchmark aus eigener Kraft nicht erfüllen können.
Die Policy-as-Code-Ausgabe als Anforderungsbaseline zu nutzen, angepasst an das, was die Plattform tatsächlich konfigurierbar abbildet, und jede Abweichung mit aufsichtsrechtlicher Begründung zu dokumentieren, erzeugt prüfbare und belastbare Kontrollen.
Drittens dürfen Compliance-Reporting und operatives Schwachstellenmanagement nicht länger in unterschiedlichen Organisationen liegen. DORA zieht diese Trennlinie nicht, und Angreifer respektieren sie ebenfalls nicht.
Welche Anpassungen braucht es bei DORA-Tests, um KI-gestützte Angriffe zu simulieren?
Das DORA-TLPT-Regime ist derzeit eine periodische Übung, die für die betroffenen Institute in der Regel in mehrjährigen Abständen stattfindet. KI-beschleunigte Schwachstellensuche macht diese Taktung als alleinige Kontrolle strukturell unzureichend. Zwei Anpassungen sind besonders relevant:
Erstens müssen die Bedrohungsszenarien KI-gestützte Schwachstellensuche und KI-gestützte Exploit-Entwicklung als Grundannahme abbilden, nicht als aufkommendes Risiko. Die realistische Zeit zwischen öffentlicher Bekanntmachung eines neuen CVE und einem funktionierenden Exploit liegt heute im Minuten-, nicht im Tagesbereich. Ein TLPT-Szenario, das einen KI-getakteten Pfad von Disclosure zu Exploitation nicht enthält, bildet die Bedrohungsumgebung, in der Institute heute operieren, nicht realistisch ab.
Die realistische Zeit zwischen öffentlicher Bekanntmachung eines neuen CVE und einem funktionierenden Exploit liegt heute im Minuten-, nicht im Tagesbereich.“
Zweitens müssen TLPT-Ergebnisse durch kontinuierliche Kontrollnachweise ergänzt werden. Die relevante Frage lautet nicht mehr, „Hat die Verteidigung gegen diesen Red-Team-Einsatz gehalten?”, sondern: „Lässt sich die Kontroll-Evidenz gegen jedes neue CVE rekonstruieren, das zwischen diesem Test und dem nächsten erscheint – und wie schnell?”.
Time-to-Evidence und Time-to-Remediation gehören als gemessene Ergebnisse in das Testregime, neben der Frage, ob das Red-Team seine Ziele erreicht hat. Periodische Übungen alleine schließen diese Lücke nicht.
DORA betont das schnelle Schließen von sicherheitsrelevanten Lücken. Mit KI wie „Claude Mythos” verkürzt sich die Zeit zwischen Entdeckung und Ausnutzung einer Schwachstelle extrem. Wie können Banken Patch-Management und Incident Response beschleunigen?
Der Engpass liegt selten in der Erkennung. Er liegt im geschlossenen Kreis von der Erkennung bis zur verifizierten Behebung. Die meisten Institute messen „Mean Time To Repair” (MTTR) weiterhin in Monaten, während das Operationalisierungsfenster für ein neues CVE in Stunden gemessen wird.
Beschleunigung ist erreichbar, erfordert aber, die Behebung als Problem der Infrastruktur-Automatisierung zu behandeln und nicht als Problem der Sicherheitsberichterstattung. Konkret bedeutet das in der Kombination: vorgetesteter Behebungscode – Ansible, Terraform, Intune – gehört in die Härtungspolicy selbst und darf nicht reaktiv pro Vorfall generiert werden.
Die Zeit bis zur Behebung („Time-to-Remediation”, TtR) gehört auf dasselbe KRI-Dashboard wie die strategischen Risikoindikatoren.“
Tickets müssen mit vollständigem Kontext im Plattform-Engineering eintreffen: betroffenes Asset, identifizierter Verantwortlicher, anwendbarer Code, aufsichtsrechtliche Einordnung. CI/CD-Pipelines müssen Fixes für quellgesteuerte Assets ausliefern, damit eine zur Laufzeit behobene Schwachstelle beim nächsten Deployment nicht stillschweigend re-introduziert wird.
Für gemeinsame Verbundplattformen muss der Verbund Playbooks für die Behebung in maschinenlesbarer Form veröffentlichen, die die Institute über einen kodifizierten Prozess ausführen, nicht in Excel-Koordination. Die Zeit bis zur Behebung („Time-to-Remediation”, TtR) gehört auf dasselbe KRI-Dashboard wie die strategischen Risikoindikatoren, nicht in einen separaten operativen Bericht.
Die Präsidentin des Bundesamts für Sicherheit in der Informationstechnik (BSI), Claudia Plattner, erwartet „Umwälzungen im Umgang mit Sicherheitslücken und in der Schwachstellenlandschaft insgesamt”. Wie sehen Sie das?
Die Einschätzung ist zutreffend, aber die Umwälzung liegt im Betriebsmodell, nicht im Bedrohungsmodell. Die Richtung der Bedrohung – schnellere Entdeckung, schnellere Operationalisierung, breiterer Zugang zu Fähigkeiten – ist seit mehreren Jahren erkennbar.
Was sich mit Frontier-Modellen verändert: Betriebsmodelle, die für eine langsamere Taktung gebaut wurden, können sich nicht mehr verstecken. Periodische Scans, manuelle KRI-Erhebung, dokumenten-basierter Nachweis, getrennte Compliance- und Betriebsorganisationen – nichts davon übersteht den Kontakt mit einer Umgebung, in der ein neues CVE noch am Tag der Veröffentlichung ausgenutzt werden kann.
Für BSI-Grundschutz, DORA und NIS2 ergibt sich daraus eine konvergente Konsequenz: Die Art und Weise, wie Schwachstellen erfasst, priorisiert und geschlossen werden, muss zu einer kontinuierlichen, automatisierten und nachweisgeführten Disziplin werden. Der regulatorische Text in jedem dieser Rahmen impliziert das bereits.
Die organisatorische Fähigkeit, so zu arbeiten, baut der Sektor in seiner Breite gerade erst auf. Die Formulierung Plattners ist gerade deshalb nützlich, weil sie die Diskontinuität benennt und nicht die kommenden Jahre als bloße Verlängerung der vergangenen behandelt.
Die Art und Weise, wie Schwachstellen erfasst, priorisiert und geschlossen werden, muss zu einer kontinuierlichen, automatisierten und nachweisgeführten Disziplin werden.“
Schwachstellenanalyse-Systeme werden teilweise nur einem beschränkten Nutzerkreis zugänglich gemacht. Ist das ein vernünftiges Mittel, um Missbrauch zu verhindern, oder wäre eine allgemeine Verfügbarkeit besser?
Beschränkter Zugang ist eine sinnvolle Risikominderung, aber keine strategische Antwort. Programme, die die frühe Verfügbarkeit von Frontier-Fähigkeiten zur Schwachstellensuche auf systemrelevante Verteidiger begrenzen, kaufen Zeit.
Diese Zeit hat realen Wert: Institute im Geltungsbereich können testen, härten und ihre Playbooks aktualisieren, bevor dieselbe Fähigkeit breit verfügbar ist. Modelle wie „Glasswing” sollten aus diesen Gründen unterstützt werden.
Die strategische Frage ist, was nach der Diffusion passiert. Diffusion ist der Basisfall. Open-Source-Pendants entstehen, gegnerische Fähigkeiten reifen, das Zugangskontrollfenster wird kleiner. Der dauerhafte Vorteil der Verteidigung kann nicht auf dem Vorenthalten von Fähigkeiten beruhen. Er beruht darauf, ob die Verteidigung einen geschlossenen Kreis von der Veröffentlichung bis zur verifizierten Behebung betreibt, der mit der Geschwindigkeit der offensiven Seite Schritt hält.
Investitionen in Programme mit beschränktem Zugang sind gerechtfertigt, sollten aber mit Investitionen in eine kontinuierliche, code-basierte Behebungsinfrastruktur kombiniert werden. Diese wird in jedem Fall benötigt, sobald Zugangsbeschränkungen erodieren. Das eine kauft Wochen. Das andere ist das, was über den Rest des Jahrzehnts trägt.
Vielen Dank für das Gespräch, Herr Münch.dw
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/245112


Schreiben Sie einen Kommentar