Die stille Gefahr: Warum Third Parties zur größten Schwachstelle werden

Die stille Gefahr: Warum Third Parties zur größten Schwachstelle werden

Es knirscht selten laut, wenn es passiert. Kein großer Knall, keine rot blinkenden Warnlampen. Stattdessen: eine kleine Konfigurationsänderung bei einem Dienstleister, ein unscheinbares Update, eine freundliche E-Mail eines „Partners“, ein Browser-Plugin aus einem Hersteller-Marketplace. Wochenlang wirkt alles normal, die Dashboards bleiben grün. Und doch hat sich die Risikolage grundlegend verschoben – nur eben nicht dort, wo das eigene SOC hinschaut. Die Schwachstelle liegt außerhalb des Perimeters, außer Reichweite der üblichen Telemetrie und häufig auch jenseits der eigenen Zuständigkeiten. Genau dort, wo moderne Wertschöpfung in der Praxis stattfindet: bei Third Parties.

Dass Drittparteien zur Achillesferse werden, ist keine überraschende Schlagzeile – aber die Mechanik dahinter wird in vielen Unternehmen unterschätzt. Third Parties stehen mitten in unseren Prozessen, tragen weitreichende Berechtigungen, hosten Daten, signieren Updates, verwalten Identitäten, triagieren Tickets, betreiben Infrastruktur und liefern das, was Kundinnen und Kunden direkt erleben: Verfügbarkeit, Geschwindigkeit, Qualität. In dieser Rolle sind sie nicht „außen“, sondern innen – oft mit mehr Rechten, mehr Einblick und mehr Steuerungsmacht als das, was wir im eigenen Haus für selbstverständlich halten.

Dieser Beitrag erzählt, warum das so ist, wie Angriffe über Dienstleister tatsächlich funktionieren, weshalb „Vertrauen“ ohne Prüfbarkeit ein Geschäftsrisiko ist – und wie Unternehmen Third-Party-Beziehungen so führen, dass aus der Achillesferse eine robuste Stärke wird. Kein Alarmismus, sondern ein Blick auf Strukturen, die sich leise verschieben: von Verträgen zu Realitäten, von Einzelprüfungen zu kontinuierlicher Nachweisfähigkeit, von Checklisten zu gelebter Resilienz.

Abhängigkeit ist der neue Normalzustand

Organisationen haben zwei Arten von Komplexität: die selbst gewählte – Outsourcing, SaaS, Cloud, externe Expertise – und die geerbte – Legacy-Systeme, historische Partnerschaften, Lieferketten, die über Jahrzehnte gewachsen sind. Beide erzeugen Abhängigkeiten, aber nur die erstere wird bewusst gesteuert. Die geerbte Komplexität führt dazu, dass niemand mehr genau sagen kann, wie viele Third Parties tatsächlich an einem kritischen Prozess beteiligt sind, wo sich deren Infrastruktur befindet und welche Subdienstleister im Hintergrund arbeiten.

Das wäre weniger dramatisch, wenn Third Parties lediglich „Werkzeuge“ wären. In der Realität sind sie Mitakteure: Managed Service Provider administrieren Verzeichnisdienste und Endpunkte, Zahlungsdienstleister halten Umsatzströme am Leben, Cloud-Provider hosten Kernprozesse, spezialisierte Softwarehäuser liefern Updates für die Systeme, die Kundendaten verarbeiten. Wer hier stillsteht, steht überall still. Diese Hebelwirkung macht Drittparteien attraktiv – für Geschäftsmodelle und für Angreifer.

Warum gerade Third Parties so oft der erste Riss sind

Drei Prinzipien erklären die Anfälligkeit:

1. Privilegienbündelung: Dienstleister erhalten aus Praktikabilität häufig breitere Rechte als interne Teams – „damit es schnell geht“. Diese Rechte bleiben bestehen, auch wenn Projekte enden oder Personal wechselt.
2. Informationsasymmetrie: Unternehmen wissen weniger über die Innenansicht des Anbieters als der Anbieter über die Innenansicht des Kunden. Dieses Ungleichgewicht erschwert echte Bewertung.
3. Vertrauensdurchreichung: Was dem Kunden sicher erscheint („ISO-Zertifikat“, „SOC-Report“), wird ungeprüft durchgereicht an Subdienstleister – die wiederum eigene Ketten haben. Aus einer Beziehung werden drei, aus drei zehn.

Hinzu kommt Psychologie: Intern ist Sicherheit sichtbar – Firewalls, Patches, Pen-Tests. Bei Dritten ist Sicherheit eine Behauptung. Zwischen Behauptung und Beweis liegt die Lücke, durch die Angriffe gehen.

Fünf Lieferketten – eine Risikoarchitektur

Third-Party-Risiken zeigen sich in unterschiedlichen „Aggregatzuständen“. Wer sie getrennt denkt, übersieht ihre Wechselwirkungen.

1. Software-Lieferkette: Vom Git-Commit über CI/CD und Artefakt-Server bis zur Signatur und zum Update-Pfad. Risiken: Dependency Confusion, kompromittierte Build-Systeme, schwache Signaturprozesse, manipulierte Update-Server.
2. Cloud & SaaS: Identitäten, Datenhaltung, Subprozessoren, Mandantentrennung. Risiken: überbreite OAuth-Scopes, fehlende Tenant-Isolation, undurchsichtige Telemetrie, Shadow-Integrationen.
3. Service-Lieferkette (Menschen): Externe Admins, 24/7-Operations, Entwicklungs- und Supportteams. Risiken: geteilte Konten, fehlendes Offboarding, dauerhafte Adminrechte, unsaubere Begleitung vor Ort.
4. Physische Lieferkette: Hardware, Ersatzteile, Transport, Entsorgung. Risiken: Manipulation im Transit, fehlende Chain-of-Custody, Restdaten auf Rückläufern, gefälschte Komponenten.
5. Daten- & Wissenslieferkette: Exporte, Analysen, Trainingsdaten, Prompt-Uploads. Risiken: Zweckentfremdung, rechtliche Grauzonen, intransparente Retention, Trainingsnutzung durch Anbieter.

Gemeinsam ist allen: Ein Fehler skaliert. Nicht ein Opfer, sondern viele. Nicht ein Server, sondern ganze Regionen. Nicht ein Datensatz, sondern Millionen.

Wie Angriffe über Dritte in die Organisation gelangen

Das legitime Update

Ein Update ist die perfekte Tarnkappe: signiert, erwartet, automatisiert. Manipulierte Pipelines liefern sauberen Code plus Beifracht. Der Rollout erfolgt „as designed“. Detection? Schwierig, solange Telemetrie aus dem Anbieterland fehlt. Die ersten Spuren tauchen in Egress-Logs oder im DNS auf – wenn überhaupt.

Der privilegierte MSP

Ein Managed Service Provider verwaltet Verzeichnisse und EDR. Ein Phishing-Angriff trifft einen Techniker, Token werden abgefischt, das RMM-Tool wird missbraucht. Innerhalb von Minuten rollen Skripte, deaktivieren Schutz, löschen Backups, setzen Policy-Ausnahmen. Nicht ein Kunde ist betroffen, sondern Dutzende gleichzeitig.

Die freundliche OAuth-App

Produktivitäts-Apps werden testweise verbunden – mit Scopes wie „read/write all mail“ oder „drive.readwrite“. Die App nutzt Subprozessoren, die ihrerseits Telemetrie aggregieren. Ein einzelner kompromittierter Subdienst reicht, um legitime API-Zugriffe in Massen zu ermöglichen – ohne verdächtige Logins.

Der physische Zwischenfall

Switches kommen mit deaktivierter Signaturprüfung, Laptops werden im Transit geöffnet, Festplatten aus MFPs nicht gelöscht. Der Schaden wirkt langsam, aber tief: unerklärliche Ausfälle, sporadische Verbindungen, Datenreste in falschen Händen.

Die KI-Abkürzung

Teams laden sensible Dokumente in generative Dienste, um schneller zu arbeiten. Der Anbieter loggt Prompts, nutzt Support-Kopien oder experimentelle Features. Wochen später sickern Muster ins Ökosystem – keine klare Spur, nur Wahrscheinlichkeiten. Rechtlich sauber? Vielleicht. Risikoarm? Nein.

Warum Zertifikate allein nicht reichen

Zertifizierungen sind wichtig – aber sie sind Vergangenheitszeugnisse. Sie sagen etwas über den Auditzeitraum, selten über den aktuellen Sicherheitszustand. Ein SOC-Bericht kann solide Prozesse attestieren und dennoch die eine, konkrete Fehlkonfiguration nicht abbilden, die heute den Unterschied macht. Zudem ist nicht jeder Scope gleich: „ISO 27001 for the corporate HQ“ ist etwas anderes als „inklusive aller Produktionsumgebungen und Subprozessoren“. Wer nur auf Logos schaut, prüft nicht – er hofft.

Besser ist ein zweistufiges Vorgehen: (1) Zertifikate als Startsignal, (2) gezielte Nachweise für die eigene Risikolage. Es geht nicht um Misstrauen, sondern um Passung: Reicht das, was der Anbieter bietet, für das, was wir von ihm erwarten?

Governance statt Bauchgefühl: Das Betriebssystem der Drittrisiken

Effektives Third-Party-Risk-Management (TPRM) ist kein Formularwesen, sondern ein Betriebssystem für Beziehungen. Es verbindet Rechtsabteilung, Einkauf, IT, Security, Fachbereiche und Notfallmanagement zu einem durchgängigen Prozess. Die Bausteine:

1) Sichtbarkeit – wissen, was wirklich dran hängt

• Vollständiges Register aller Third Parties inkl. Subdienstleister, Regionen, Datenklassen, Privilegien, Exit-Komplexität.
• Identitäten-Inventar: Alle externen Personen- und Maschinenkonten, Rechte, Ablaufdaten, Eigentümer.
• Integrationskarte: OAuth-Apps, Webhooks, API-Keys, IP-Freischaltungen – zentral sichtbar.
• SBOM/DBOM: Software- und Daten-Stücklisten für Kernsysteme und Datentransfers.

Sichtbarkeit ist der Hebel: Nur wer Beziehungen kennen lernt, kann Risiken priorisieren.

2) Reduktion – die Angriffsfläche verringern, bevor man härtet

• Least Privilege konsequent: Rechte auf Aufgaben und Zeit begrenzen, Just-in-Time statt Dauer-Admin.
• Schnittstellen aufräumen: Veraltete Integrationen abschalten, doppelte Pfade konsolidieren.
• Datenminimierung: Weniger Kopien, kürzere Aufbewahrung, Pseudonymisierung für Analysen.
• Technologie-Sparsamkeit: So wenige Plattformen wie nötig, so viel Diversifikation wie sinnvoll.

3) Absicherung – Verträge, Technik, Prozesse

Verträge, die tragen: Meldeszenarien mit Fristen, Nachweisformaten, Logs; Right-to-Audit; Subprozessor-Transparenz; Exit-Klauseln (Datenportabilität, Support, Zeitfenster); klare Regelungen zu Retention, Training und Regionen bei KI/Analytics.

Technik, die schützt: Zero-Trust-Zugänge mit SSO/MFA/Device-Compliance; PAM für privilegierte externe Sessions; Segmentierung für Integrationen; API-/KI-Gateways mit Maskierung, Ratenlimit, Protokollierung; Sigstore/SLSA-Attestierungen; SBOM-Validierung vor Rollout; Egress-Kontrollen.

Prozesse, die halten: standardisierte On-/Offboarding-Flows; Change-Ankündigungen bei Sicherheitsrelevanz; Dual-Control für Hochrisikoaktionen; dokumentierte Entsorgung/Rückläufer; Begleitung von Fremden im RZ.

4) Überwachung – erkennen, was wirklich passiert

• Use-Cases im SIEM, die auf Dritte zielen: neue OAuth-Apps mit breiten Scopes; privilegierte Aktionen externer Konten außerhalb erlaubter Fenster; ungewohnter Egress aus Integrationssegmenten; Update-Server, die Artefakte aus unbekannten Netzen laden; SBOM-Drift.
• Telemetrie vom Anbieter: Admin-Events, Audit-Logs, Security-Feeds – maschinenlesbar.
• Canaries & Tripwires: Köderdaten/Workloads, die Alarm schlagen, wenn berührt.
• Drift-Checks: Vertrag vs. Realität (Regionen, IPs, Subprozessoren).

5) Resilienz – weiterarbeiten, wenn ein Glied reißt

• Alternativpfade für kritische Workflows (Read-only-Spiegel, Exporte, Caches).
• Manuelle Minimalprozesse (Telefonketten, Paper-Fallbacks) – dokumentiert, geübt.
• Backups, die nutzbar sind: Provider-unabhängig, offline, regelmäßig getestet.
• Exit-Proben im Kleinen: Datenumzug, Schnittstellenwechsel, Betrieb ohne Dienst – realistisch durchgespielt.
• Kommunikation: Vorlagen, Ansprechpartner, Fakten-Takt – intern wie extern.

Die heiklen Zonen – wo Third Parties strukturell wehtun

Identität & Rechte

Das am meisten unterschätzte Feld. Ein einziger externer Admin mit Domain-Rechten ist ein Risikotransformator. Abhilfe: JIT/JEA, MFA obligatorisch, Device-Bindung, Netz-Scopes, Sitzungsaufzeichnung, Ablaufdaten pro Zugriff. Keine geteilten Konten, nie.

OAuth & Marktplätze

„Schnell mal verbinden“ ist der neue Trojaner. Governance braucht Admin-Consent, Scope-Reviews, Rezertifizierungen, App-Allowlists, Transparenz über Subdienste. Ein internes „App-Store-Modell“ hilft: geprüfte Apps, klar markierte Risiken, einfache Beantragung.

Schlüssel & Secrets

API-Keys in Extensions, Tokens in Logs, lange Gültigkeit – das ist das Einfallstor Nummer eins für Massenzugriffe. Lösung: Vault statt Datei, Rotation, Scopes eng, Kurzläufer, Anomalie-Alarme auf Nutzungsmuster.

SBOM & Update-Disziplin

Ohne SBOM patchen Sie blind. Mit SBOM allein patchen Sie zu viel. Es braucht Risikobewertung: Welche Komponenten sind exponiert, kritisch, ersetzbar? Welche Mitigations existieren? Rollout-Entscheidungen folgen Kritikalität, nicht Mailinglisten.

KI & Datenabfluss

KI ist nicht das Risiko – unkontrollierter Egress ist es. Governance für KI-Dienste heißt: Gateway mit Maskierung, No-Training-Verträge, Retention definieren, rote Daten intern halten, RAG-Grenzen hart ziehen, Prompts und Antworten klassifizieren.

Von Compliance zu Nachweisfähigkeit

Audits sind kein Hindernis, sondern eine Gelegenheit. Dritte, die bereitwillig Belege liefern, die Formate akzeptieren, die Proben zulassen, sind strategische Partner. Entscheidend ist der Wechsel von „Wir erfüllen“ zu „Wir beweisen im Alltag“: Logs, Attestierungen, Reports, wiederholbare Tests. Nachweisfähigkeit schafft nicht nur regulatorische Ruhe – sie schafft Vertrauen, das echten wirtschaftlichen Wert hat.

Kultur: Vertrauen, das prüft, und Prüfen, das befähigt

TPRM scheitert selten an Technik, häufiger an Kultur. Zwei Extreme sind gleichermaßen dysfunktional: Blindes Vertrauen („Die sind doch zertifiziert“) und Misstrauensbürokratie („Ohne 50 Seiten Fragebogen geht nichts“). Dazwischen liegt die reife Haltung: partnerschaftliche Strenge. Klare Erwartungen, kurze Wege, schnelle Entscheidungen, faire Fristen – und Konsequenz, wenn Zusagen nicht gehalten werden. Gute Anbieter wissen das zu schätzen; schlechte fallen dadurch auf.

Auch intern braucht es ein Mindset-Upgrade: Fachbereiche sollen früh melden, wenn sie neue Dienste brauchen; Security liefert benutzbare Pfade; Einkauf verhandelt nicht nur Preis, sondern Portabilität und Beweisführung; das Management misst nicht Papier, sondern Resilienzwert.

Metriken, die wirklich steuern

• Sichtbarkeitsgrad: Anteil kritischer Third Parties mit vollständigem Profil (Subprozessoren, Regionen, Logs, Exit-Pfad).
• Rechtehygiene: Prozent externer privilegierter Zugriffe, die JIT sind; mittlere Rechtelebensdauer.
• OAuth-Disziplin: Zahl ungeprüfter Apps, Anteil breiter Scopes; Rezertifizierungsquote.
• SBOM-Abdeckung: Anteil Kernsysteme mit aktueller SBOM; mittlere Zeit von CVE → Entscheidung.
• Drift-Treffer: Abweichungen zwischen Vertrag und Telemetrie pro Quartal.
• Incident-Metriken: Time-to-Inform (Dritter → Sie), Time-to-Contain (intern), Kommunikationszeit zu Kunden/Behörden.
• Exit-Reife: Zahl bestandener Teil-Exits; Zeit, bis Alternative produktiv ist.
• Kostenklarheit: Anteil Ausgaben mit Use-Case-Zuordnung; Schattenkosten-Quote sinkend.
• Schulungswirkung: Meldungen aus Fachbereichen pro Monat (Fragen statt Vorfälle); Abnahme der „Schatten-Integrationen“.

Diese Metriken sind keine Kosmetik. Sie verändern Verhalten – wenn sie sichtbar sind, Owner haben, Ziele und Eskalationen.

Gegenbeispiele: Wo es trotz guter Absichten scheitert

• „Zertifikat = Freifahrtschein“: Der Anbieter ist ISO-zertifiziert, aber der Scope umfasst den relevanten Standort nicht. Das fällt erst auf, wenn Logs angefordert werden – und es keine gibt.
• „Ein Admin für alle Fälle“: Dienstleister erhält Domain-Admin „temporär“ – zwei Jahre später ist das Konto noch aktiv, MFA nur optional.
• „Wir patchen immer sofort“: Ein kritisches Update wird ohne Staging ausgerollt und bricht Integrationen; der Anbieter reagiert erst Tage später. Ohne Alternativpfad steht der Betrieb.
• „Exit? Später“: Nach fünf Jahren stellt sich heraus, dass Daten nur proprietär exportierbar sind. Die Portierung kostet Monate – mitten in einer Krise.
• „Shadow-SaaS als Innovator“: Ein Fachbereich bindet eigenmächtig einen Dienst an; erst bei einem Datenschutzersuchen fällt auf, dass Löschpfade fehlen.

Aus jedem Scheitern lässt sich eine Regel destillieren: Beweise vor Vertrauen, Zugriff vor Dauerrecht, Risikobewertung vor Automatismus, Portabilität vor Bequemlichkeit.

Zusammenarbeit statt Konfrontation

TPRM ist keine Polizeiarbeit. Die besten Ergebnisse entstehen, wenn man mit Dritten gemeinsam robuste Lösungen baut: standardisierte Fragebögen in maschinenlesbarer Form; Austausch über Indicators of Compromise; gemeinsame Tabletops; abgestimmte Wartungsfenster; geteilte Runbooks für Zwischenfälle. Diese Zusammenarbeit reduziert Friktion und erhöht die Geschwindigkeit – genau das, was Fachbereiche brauchen.

Ein Wort zur Skalierung: Von Excel zu Plattform

Solange zehn Lieferanten kritisch sind, funktioniert Excel. Ab hundert wird es zur Bremse. Skalierbares TPRM braucht Plattformen: zentrales Verzeichnis, Workflows, Dokumente, Nachweise, Telemetrie, Integrationen ins SIEM, in das GRC, in das Identity-System. Wichtig ist Offenheit: APIs statt PDF-Gefängnis, Events statt E-Mail-Anhänge, Standards statt Insellösungen. Wer Plattformen einführt, muss trotzdem die Freiheit behalten, für besondere Risiken tiefer zu bohren – Tools unterstützen, Entscheidungen trifft die Governance.

Rechtsräume und Ethik: Mehr als Technik

Third-Party-Beziehungen sind auch Rechtsbeziehungen. Datenflüsse über Grenzen hinweg, Auftragsverarbeitung, Haftung bei Ausfällen, Informationspflichten – all das gehört auf den Tisch, bevor der erste Datensatz fließt. Ebenso die ethische Dimension: Wie behandeln Anbieter die Daten ihrer Kunden? Wie transparent ist ihr Umgang mit Vorfällen? Wie ernst nehmen sie die Würde derjenigen, deren Daten wir verarbeiten? In einer Welt, in der Vertrauen ein Wettbewerbsfaktor ist, zählen diese Fragen doppelt.

Der rote Faden: Prüfbarkeit als Prinzip

Ob Software, Mensch, Cloud, Gerät oder Datenfluss – überall entscheidet dasselbe Prinzip: Prüfbarkeit. Nicht absolute Sicherheit, nicht Nullrisiko, nicht Papierberge, sondern die Fähigkeit, jederzeit zu zeigen, dass Risiken verstanden, begrenzt, überwacht und im Fall der Fälle beherrscht werden. Prüfbarkeit ist die Währung, mit der man Vertrauen kauft – bei Kunden, Aufsehern, Partnern und Mitarbeitenden.

Schluss: Die stille Gefahr hörbar machen – und beherrschen

Third Parties verschwinden nicht. Im Gegenteil: Sie sind die Grundlage moderner Wertschöpfung. Die Frage ist nicht, ob wir sie nutzen, sondern wie. Wer sie als blinde Flecken behandelt, wird von ihnen überrascht. Wer sie als Partner ernst nimmt, klare Regeln setzt, Beweise fordert, Zugriffe begrenzt, Telemetrie schafft und Resilienz baut, bekommt das, was in unsicheren Zeiten am wertvollsten ist: Handlungsfähigkeit.

Die stille Gefahr ist nur so lange still, wie niemand hinhört. Zeit, hinzuhören – und zu führen.