Banken sperren KI-Agenten aus Konten aus, ein SBOM, das einen Shai-Hulud-Vorfall nicht abgrenzen konnte, Passkeys, die Identität nicht absichern, wie lange Logs aufzubewahren sind, und ein 2.7-Befund, der sie abgeschaltet hat.
In dieser Ausgabe
- 01Banken sperren KI-Agenten aus Kundenkonten aus.
- 02Das SBOM sagte ihnen nicht, was tatsächlich ausgeführt worden war.
- 03Passkeys schließen das Passwortproblem. Identität schließen sie nicht.
- 04Ihr SOC möchte jeden Log für immer. Ihr DPO möchte sechs Monate.
- 05Ein mit 2.7 bewerteter Befund hat die Logs abgeschaltet, und niemand hätte ihn eingespielt.
Erhalten Sie den nächsten GRC Brief in Ihrem Postfach.
The GRC Brief abonnierenBanken sperren KI-Agenten aus Kundenkonten aus.
Axios berichtete am 22. Oktober, dass große US-Banken Drittanbieter-KI-Agenten in Kundenkonten erkennen, in der Regel weil der Kunde seinen Benutzernamen und sein Passwort weitergegeben hat. Der CEO von JPMorgan erklärte, dass das Zulassen beliebiger externer Agenten für Kunden und Bank zu riskant wäre. Bank of America hat Kunden daran erinnert, dass sie bei der Weitergabe ihrer Zugangsdaten für alles Folgende selbst verantwortlich sind. Viele Banken gehen stattdessen zu reinem Lesezugriff über. Eine abweichende Einschätzung von Bianco Research lautet, dass das Privatkundengeschäft von der Trägheit der Kunden profitiert und ein Agent, der ungenutztes Geld in einen Geldmarktfonds verschiebt, die Bank Geld kostet.
Quelle: Axios · 22 Oct 2026
Meine Einschätzung
Beide Erklärungen können gleichzeitig zutreffen, und das dahinterliegende Problem ist interessanter als beide. Ein Privatkunde hat keine Möglichkeit, einem Agenten eingeschränkte Befugnisse zu erteilen, also übergibt er das vollständige Zugangsdatenpaar. Das ist das Maschinenidentitätsproblem, über das ich im September geschrieben habe: eine Identität pro Agent mit aufgabengebundenen Berechtigungen. Der Kontoinhaber verfügt über keine dieser Werkzeuge, und die Bank kann Ihren Agenten nicht von einem Angreifer unterscheiden. Reiner Lesezugriff löst eine Hälfte. Ein Agent, der Ihre Kontoauszüge lesen kann, kann sie trotzdem offenlegen, wenn er kompromittiert oder manipuliert wird. Einen Transfer zu stoppen und die Vertraulichkeit zu schützen, sind zwei verschiedene Aufgaben.
Das SBOM sagte ihnen nicht, was tatsächlich ausgeführt worden war.
Beim ISC2 Security Congress schilderte Deepam Kanjani, Product Security Manager bei Atlassian, den Ablauf eines realen Shai-Hulud-Response. Das schädliche Paket befand sich drei Abhängigkeitsebenen tiefer und war für Top-Level-Scans unsichtbar. Als der Vorfall begann, war das SBOM des Teams bereits veraltet und es gab keine Laufzeit-Telemetrie, sodass nicht festgestellt werden konnte, was in mehr als 400 Diensten ausgeführt worden war. Seine Empfehlung ist konkret: SBOMs im Betrieb bei mehr als 98 Prozent der Produktionsdienste unter 72 Stunden aktuell halten und unbekannte Modulladevorgänge zur Laufzeit erkennen.
Quelle: Dark Reading · J. Vijayan, 27 Oct 2026
Meine Einschätzung
Ich habe Ihnen dieses Jahr zweimal gesagt, das SBOM als lebendiges Inventar zu behandeln, nicht als Prüfartefakt. Hier ist die Zahl, die mir bislang fehlte: 72 Stunden. Wird Ihres zum Build-Zeitpunkt erstellt und Ihr letztes Release war im September, beschreibt es ein System, das Sie nicht mehr betreiben. Und beachten Sie, welche Hälfte fast überall fehlt. Die Stückliste erfasst, was ausgeliefert wurde. Niemand beobachtet, was geladen wird. Während eines Vorfalls lauten die einzigen zwei Fragen: Was wurde ausgeführt, und wohin hat es kommuniziert? Eine Abhängigkeitsliste beantwortet keine davon.
Passkeys schließen das Passwortproblem. Identität schließen sie nicht.
Ein Vorbehalt vorab: Dies ist eine Expertenkolumne von Anbieterseite, kein redaktioneller Bericht. Das Argument gilt dennoch. Passkeys entfernen das wiederverwendbare Geheimnis und widerstehen Phishing, was den größten Teil der Angriffsfläche für Anmeldedaten schließt. Was sie nicht berühren, ist alles rund um den Authenticator: ob das Konto von Anfang an legitim angelegt wurde, was bei einem Gerätewechsel passiert, was der Wiederherstellungspfad als Nachweis akzeptiert und ob eine Sitzung nach einem einwandfreien Login entführt werden kann. Wenn Organisationen Passwörter abschaffen, verlagern Angreifer sich an diese Ränder.
Quelle: SecurityWeek · T. George, expert column, 30 Oct 2026
Meine Einschätzung
Die konkrete Variante davon haben Sie bereits zweimal gesehen. Im August: ein Phishing-Kit, das einen eigenen Passkey im Konto des Opfers einrichtete und den Passwort-Reset überlebte. Letzten Monat: ein betrügerischer externer MFA-Anbieter, der die Prüfung bestand, obwohl der zweite Faktor nie stattfand. Keiner dieser Angriffe richtete sich gegen die Kryptografie. Beide zielten direkt auf Registrierung und Wiederherstellung. Setzen Sie Passkeys also ein, sie sind nach wie vor der richtige Schritt. Dann beantworten Sie die zwei Fragen, die entscheiden, ob sie standhalten: Wer darf einen Passkey für ein Konto registrieren, und was akzeptiert Ihr Service Desk als Nachweis, wenn jemand anruft und sagt, er habe sein Gerät verloren.
Ihr SOC möchte jeden Log für immer. Ihr DPO möchte sechs Monate.
Ich habe dieses Thema diese Woche aufgeschrieben. Als PHP2Shell am 21. Oktober öffentlich wurde, forderte das Threat-Intelligence-Team von Amazon die Responder auf, mindestens ab dem 17. Oktober zu untersuchen, also vier Tage früher. Wenn Ihre Webserver-Logs wöchentlich rotieren, werden Sie nie herausfinden, ob Sie betroffen waren, bevor irgendjemand etwas bekannt gegeben hat. Fragen Sie Ihren DPO, wie lange dieselben Logs aufzubewahren sind, und Sie erhalten eine andere Antwort, denn sie sind voll von Adressen, Kennungen und manchmal vollständigen Request-Bodies. Fünf regulatorische Quellen nennen fünf verschiedene Fristen, und keine einzige gibt Ihnen eine universelle.
Quelle: My full breakdown · cyberacademy.net
Meine Einschätzung
Was alle fünf stattdessen verlangen, ist dasselbe: eine zweckgebundene Frist, schriftlich festgehalten mit einer Begründung. Der typische Fehler ist die werkzeugbezogene Festlegung von Aufbewahrungsfristen, denn „das SIEM speichert 90 Tage" ist eine Lizenzentscheidung im Sicherheitsgewand. Legen Sie die Fristen stattdessen nach Zweck fest: Erkennung, Untersuchung, Rechenschaftspflicht für privilegierte Zugriffe, gesetzliche Mindestfrist. Den strengsten Zweck, den Sie tatsächlich begründen können, lassen Sie den Ausschlag geben. Nutzen Sie dann die beiden Stellschrauben, die kaum jemand anfasst: Protokollieren Sie das Ereignis ohne den Datensatz selbst, und stufen Sie den Speicher so ab, dass weniger Personen auf ältere Daten zugreifen können. Ein Muster, das ich in fast jedem Audit feststelle: Der DPO wurde nie einbezogen. Artikel 38 schreibt vor, dass er es hätte sein sollen.
Ein mit 2.7 bewerteter Befund hat die Logs abgeschaltet, und niemand hätte ihn eingespielt.
Broadcom bewertet CVE-2026-41709 mit 2.7 von 10. Es handelt sich um einen unzureichenden Logging-Fehler in VMware ESX, der es jemandem mit bereits vorhandenen Administratorrechten auf einem Host ermöglicht, bestimmte Operationen durchzuführen, ohne dass diese in den Logs erscheinen. Am 28. Oktober legte CrowdStrike offen, dass die China-nahe Gruppe Warp Panda diesen Fehler Anfang 2026 als Zero-Day bei Spionage-Einbrüchen gegen US-Anwaltskanzleien genutzt hatte, gezielt um zu reduzieren, was der Audit-Trail zeigen würde. Broadcom lieferte einen Fix am 29. Juli. CISA nahm den Eintrag am selben Tag, an dem CrowdStrike veröffentlichte, in den Known-Exploited-Katalog auf, mit einer Bundesbehörden-Frist bis zum 11. November.
Quelle: CrowdStrike · 2026 Legal Threat Landscape Report, 28 Oct 2026
Meine Einschätzung
Lesen Sie dies zusammen mit dem Punkt oben, und beide zusammen ergeben das Kernproblem. Sie können Ihre Aufbewahrungsfristen perfekt kalibrieren, Ihren DPO konsultieren, Zweck und Zeitraum dokumentieren, und sind dennoch blind, weil jemand auf Hypervisor-Ebene die Aufzeichnung abgeschaltet hat. Überlegen Sie dann, was Ihr eigener Prozess damit gemacht hätte. Ein Wert von 2.7 liegt unter der Schwelle der meisten Patch-Richtlinien, also wäre er nie in die Warteschlange gekommen. Broadcom hat das Problem im Juli behoben, und nichts bewegte sich, bis ein Threat-Intelligence-Bericht die Gruppe drei Monate später namentlich nannte. Eine weitere Überprüfung lohnt sich: Die öffentlichen Quellen sind sich nicht einmal über den Score einig, manche führen ihn mit 7.6. Eine Differenz von fünf Punkten beim selben CVE entscheidet darüber, ob Ihre Richtlinie ihn überhaupt erfasst.