Shadow Victims: IR-Playbooks für Vorfälle bei Dritten
10.09.2026 third-party-riskincident-responsesaas-securitycrisis-communication
Ein Ransomware-Vorfall im eigenen Netzwerk ist planbar: Man zieht das Kabel, isoliert Endpunkte, aktiviert das Playbook. Aber was passiert, wenn der Vorfall gar nicht im eigenen Netzwerk stattfindet, sondern bei einem SaaS-Vendor, dessen OAuth-Token seit Monaten in den eigenen Systemen liegen? Genau dieses Szenario hat sich 2025/2026 zum Regelfall entwickelt – und die meisten IR-Pläne sind darauf schlicht nicht ausgelegt.
Die 117-Tage-Lücke
Der aktuelle Third-Party-Breach-Report zeigt das Ausmaß des Problems in nackten Zahlen: Vendor-Breaches betreffen inzwischen im Schnitt 5,28 nachgelagerte Opfer, dazu kommen 26.000 unbenannte “Shadow Victims” und Offenlegungsverzögerungen von 117 Tagen. Das bedeutet: Zwischen dem tatsächlichen Kompromittierungszeitpunkt beim Vendor und dem Moment, in dem die eigene Organisation überhaupt erfährt, dass sie betroffen ist, können fast vier Monate vergehen – Zeit, die die eigene Meldepflicht-Uhr längst nicht mehr berücksichtigt, weil sie formal erst mit der eigenen Kenntnisnahme beginnt, faktisch aber oft parallel zu Presseanfragen und Kundenanrufen läuft.
Verschärfend kommt hinzu, dass Vendor-Kompromittierungen selten Einzelfälle bleiben: 2025 war geprägt von einem beispiellosen Anstieg des “Blast Radius” durch Vorfälle bei Dritten – jeder einzelne Vendor-Breach fordert im Schnitt 5,28 nachgelagerte Opfer, der höchste je gemessene Wert. Der Begriff “Shadow Victim” beschreibt dabei ein Phänomen, das klassische Meldeprozesse ins Leere laufen lässt: Analysen gehen über benannte Opfer hinaus und betrachten aggregierte Offenlegungen, bei denen ein Vendor Auswirkungen gegenüber seinem Kundenstamm meldet, ohne konkrete Organisationen zu nennen. Für IR-Teams heißt das: Man kann Wochen im Unklaren verbringen, ob man überhaupt zur betroffenen Gruppe gehört.
Die Größenordnung des Problems bestätigt auch der aktuelle Verizon DBIR: Der Bericht verzeichnete eine Drittparteien-Beteiligung in 48 Prozent aller analysierten Breaches – der höchste je gemessene Wert und ein Anstieg von 60 Prozent gegenüber dem Vorjahreswert von 30 Prozent. Third-Party-Incidents sind damit kein Randthema mehr, sondern der Regelfall, auf den IR-Prozesse ausgelegt sein müssen.
Fünf Komma Zwei Acht: Konzentrationsrisiko als IR-Problem
Besonders brisant wird es bei sogenannten “Hub”-Vendoren – SaaS-Plattformen, die Hunderte oder Tausende Kunden gleichzeitig bedienen. Eine Untersuchung der meistgenutzten Anbieter unter den Forbes Global 2000 ergab: 70 Prozent dieser kritischen Hubs weisen ungepatchte, bekannte Schwachstellen (KEVs) auf, und bei 62 Prozent zirkulieren bereits Unternehmenszugangsdaten in Stealer-Logs. Ein einziger kompromittierter Hub kann damit Dutzende IR-Teams gleichzeitig in Bewegung setzen – ohne dass diese Teams jemals Zugriff auf forensische Artefakte beim eigentlichen Tatort erhalten.
Das grundlegende IR-Dilemma bleibt: Containment im eigenen Netzwerk ist möglich, Eradication beim Vendor nicht. Ein Standing-Access-Problem, das durch veraltete Berechtigungskonzepte verschärft wird – lang laufende, permanente Vendor-Zugänge bieten Angreifern über Monate hinweg ein Zeitfenster, das bei Just-in-Time-Modellen gar nicht erst entstünde.
Playbooks für einen Tatort, den man nicht betreten darf
Was also tun? Die naheliegende Antwort: dedizierte Third-Party-Incident-Playbooks statt generischer Eskalationspfade. Empfehlungen aus der Praxis sind eindeutig: Der IR-Plan sollte konkrete Szenarien für Drittparteien enthalten – etwa “Ausfall des Zahlungsdienstleisters” oder “Datenleck über den CRM-Vendor” – und im Voraus festlegen, wer benachrichtigt werden muss. Das betrifft nicht nur Kunden, sondern auch Aufsichtsbehörden, Versicherer und gegebenenfalls betroffene Endnutzer.
Vertraglich sollte dieser Prozess bereits vor dem Ernstfall verankert sein: Wo Lieferanten-Transparenz fehlt, sollten Organisationen strukturierte Vendor-Bewertungen, stärkere vertragliche Kontrollen und Anforderungen zur IR-Koordination für kritische Anbieter durchsetzen. Reife Third-Party-Risk-Management-Programme gehen dabei über reine Compliance-Checklisten hinaus: Sie umfassen Inventarisierung, Kritikalitäts-Tiering, Datenmapping, Zugriffsreview, vertragliche Anforderungen, Sicherheitsnachweis-Prüfung, Incident-Koordination und technische Validierung für hochriskante Integrationen.
Für die Praxis bedeutet das: Tabletop-Übungen müssen künftig Szenarien enthalten, in denen der Angreifer nie das eigene Netzwerk betritt, sondern nur über einen kompromittierten OAuth-Token eines Drittanbieters agiert. Wer als IR-Verantwortlicher heute noch keinen Kontaktbaum für die zehn kritischsten SaaS-Vendoren im Notfallordner hat, sollte diese Lücke vor dem nächsten Vorfall schließen – nicht danach.
← Zurück zur Übersicht