Moderne Programme für das Drittanbieterrisikomanagement bewerten in der Regel das Sicherheitsniveau eines Lieferanten, ohne die technischen Vertrauenspfade (Trust Paths), die dieser Lieferant in das Unternehmen hinein schafft, angemessen zu messen.

Ein Anbieter mit einem geringen inhärenten Risiko kann sich schnell in einen schwerwiegenden Sicherheitsvorfall verwandeln, wenn seine Integration mit privilegiertem Zugriff auf Identitätssysteme, SaaS-Anwendungen, sensible Datensätze, Administrationskonsolen oder nachgelagerte Dienstleister missbraucht wird.

 Jüngste Vorfälle im SaaS-Ökosystem verdeutlichen diesen Unterschied. In mehreren Fällen war die kritische Sicherheitsfrage nicht, ob die betroffene Organisation eine ausnutzbare Schwachstelle aufwies, sondern ob ein Angreifer, der einen vertrauenswürdigen Vermittler kompromittiert hatte, legitime Zugriffsrechte auf nachgelagerte Systeme und Daten erben konnte.

Vor diesem Hintergrund schlägt dieser Bericht einen Wechsel vom Vendor Risk zum Access-Path Risk (Zugriffspfad-Risiko) vor: Es muss nicht nur bewertet werden, wer der Lieferant ist, sondern welche technischen Vertrauensbeziehungen er herstellt, welche Privilegien diese Beziehungen verleihen und wie schnell sie widerrufen werden können.

Strategische Erkenntnisse

1. Auflösung der Perimeter-Sicherheit: Der Sicherheitsperimeter von Unternehmen endet nicht mehr an der Firewall oder beim Identity Provider (IdP). Er erstreckt sich auf jede SaaS-Plattform, jeden Cloud-to-Cloud-Connector und jeden Managed Service Provider (MSP), der über delegierte Administrations- oder Lese-/Schreibrechte verfügt.

2. Versagen des traditionellen TPRM: Zertifizierungen, Prüfungsberichte und periodische Fragebögen bleiben nützliche Bestandteile der Due Diligence von Lieferanten, aber sie bieten von sich aus kein kontinuierlich aktualisiertes Inventar der produktiven Zugriffspfade, Berechtigungsumfänge, Token, Service-Accounts und nachgelagerten Abhängigkeiten.

3. Die Notwendigkeit eines Drittanbieter-"Kill-Switches": Organisationen benötigen technische, automatisierte Funktionen, um OAuth-Token, API-Keys, Service-Accounts und föderierte Vertrauensbeziehungen zu einem kompromittierten Anbieter sofort zu trennen, ohne unbetroffene Geschäftsdienste zu beeinträchtigen.

Evidenz- und Vertrauensbewertung

Um strengen Standards für Bedrohungsanalysen gerecht zu werden, werden die analytischen Erkenntnisse in diesem Bericht anhand des Standard-CTI-Vertrauensmodells (High, Moderate, Low) in Verbindung mit Bewertungen der Quellenzuverlässigkeit kategorisiert.

Hinweis: Detaillierte Anschuldigungen bezüglich der genauen Anzahl offengelegter Datensätze oder spezifischer Erpressungssummen, die ausschließlich auf Leak-Portalen von Bedrohungsakteuren veröffentlicht werden, müssen als Behauptungen der Angreifer behandelt werden, bis sie durch unabhängige forensische Prüfer, behördliche Offenlegungen oder Strafverfolgungsbehörden verifiziert wurden.

Anatomie eines Vorfalls: Zeitlicher Ablauf einer Kompromittierung des vertrauenswürdigen Zugriffs

Der folgende synthetische Zeitablauf veranschaulicht den typischen Lebenszyklus einer Sicherheitsverletzung über den vertrauenswürdigen Zugriff von Drittanbietern in miteinander vernetzten SaaS-Ökosystemen.

Phase der Erstkompromittierung: Social Engineering und Diebstahl von Zugangsdaten

T-30 Tage bis T-7 Tage

Bedrohungsakteure führen gezielte Voice-Phishing- (Vishing) oder Social-Engineering-Kampagnen über den Helpdesk gegen IT-/Support-Mitarbeiter des Anbieters durch. Die Angreifer erlangen gültige MFA-Sitzungstoken oder administrative Zugangsdaten.

Kompromittierung der Anbieterinstanz & Ernte von API-Schlüsseln

T-0 Tage

Der Angreifer greift auf den internen Management-Tenant des Anbieters zu (z. B. Kundenverwaltungsplattform, CRM- oder Support-Instanz). Anstatt Malware zu verteilen, extrahiert der Angreifer aktive mandantenübergreifende API-Schlüssel, OAuth-Zugriffstoken und Integrations-Geheimnisse (Secrets), die in der Umgebung des Anbieters gespeichert sind.

Indirekter Abfluss von Kundendaten

T+2 Tage

Unter Verwendung gestohlener, legitimer API-Zugangsdaten verbindet sich der Bedrohungsakteur direkt mit den SaaS-Umgebungen der Kunden oder verbundenen Datenbanken. Anfragen stammen von legitimen Endpunkten oder Cloud-Proxys, wodurch die herkömmliche Erkennung von Perimeter-Anomalien umgangen wird.

Erpressung & öffentliche Bekanntgabe

T+5 Tage

Der Bedrohungsakteur kontaktiert den Anbieter oder die betroffenen Unternehmenskunden mit Erpressungsforderungen und veröffentlicht Datenproben in Darknet-Foren oder Leak-Portalen, um Zahlungen zu erzwingen.

 Erkennung des Vorfalls, Eingrenzung des Umfangs & Behebung

T+14 Tage

Incident-Response-Teams (IR) führen anomale API-Aufrufvolumina auf die mit dem Anbieter verknüpften Integrationsschlüssel zurück. Unternehmen initiieren eine Notfall-Rotation von Zugangsdaten, erklären aktive OAuth-Freigaben für ungültig und trennen föderierte Vertrauenspfade.

Die Angriffsfläche des Unternehmens: Anfälligkeit vernetzter SaaS-Ökosysteme

Das SaaS-Verbindungsnetz

Moderne Cloud-Infrastrukturen bestehen nicht mehr aus isolierten Silos. Sie bilden ein komplexes, hochgradig vernetztes Netz, in dem SaaS-Anwendungen kontinuierlich über REST-APIs im Hintergrund, Webhooks und föderierte SSO-Authentifizierungspfade kommunizieren.

Wenn ein Unternehmen einen Drittanbieter integriert – beispielsweise durch die Verknüpfung einer Marketing-Automatisierungs-Engine, einer Design-Plattform, eines Analysetools oder einer Customer-Success-Plattform mit einem zentralen CRM –, entstehen transitive Vertrauenspfade.

Hauptvektoren für indirekten Zugriff

• OAuth-Anwendungsautorisierungen: Benutzer oder IT-Administratoren gewähren OAuth-Apps von Drittanbietern langlebige Zugriffstoken (refresh_tokens) mit weitreichenden Berechtigungsumfängen (data:read, user:write).

• Hartcodierte API-Secrets: In Kundenumgebungen integrierte Software von Drittanbietern basiert häufig auf statischen API-Schlüsseln, die in Konfigurationsdateien von Clients oder gemeinsamen Key-Vaults gespeichert sind.

• Mandantenübergreifende Service-Accounts: Managed Service Provider (MSPs) und SaaS-Anbieter nutzen zentrale Service-Accounts oder Master-Management-Schlüssel, die Abfragen über Tausende verschiedener Kundenmandanten hinweg durchführen können.

• Identitätsföderation & SSO-Delegierungen: Vertrauensbeziehungen, die zwischen Identity Providern (IdPs) via SAML/OIDC eingerichtet wurden, ermöglichen es kompromittierten Konten des Anbieters, sich nahtlos in Kundenumgebungen zu authentifizieren.

Legitimer Zugriff vs. Ausnutzung von Schwachstellen

Der Sicherheitsbetrieb konzentriert sich historisch auf das Patch-Management und die Behebung von Schwachstellen (z. B. CVE-Exploitation). Der Missbrauch von legitimem Zugriff umgeht jedoch nahezu alle traditionellen Erkennungsmechanismen.

Kritikalität des Zugriffspfads

Bei Shieldworkz haben wir eine umfassende Methode ausgearbeitet, um die Auswirkungen von Zugriffen und Berechtigungen zu verstehen und zu formulieren. Dies wird Unternehmen dabei helfen, weit über die bloße vage Diskussion des inhärenten Anbieterrisikos hinauszugehen und das tatsächliche Access-Path-Risiko zu messen. Das Access-Path-Risiko kann wie folgt ausgedrückt werden:

Kritikalität des Zugriffspfads = Berechtigung × Datensensitivität × Reichweite × Persistenz × Erkennbarkeit × Widerrufbarkeit

Und das sind die Dimensionen:

·      Berechtigung (Privilege)

o   Was kann die Integration tun?

·      Reichweite (Reach)

o   Auf wie viele Systeme/Mandanten kann sie zugreifen?

·      Datensensitivität (Data sensitivity)

o   Welche Informationen kann sie erreichen?

·      Persistenz (Persistence)

o   Wie lange bleibt der Zugriff nach einer Rotation der Zugangsdaten oder Kontoänderungen bestehen?

·      Erkennbarkeit (Detectability)

o   Können anomale Aktivitäten zuverlässig identifiziert werden?

·      Widerrufbarkeit (Revocability)

o   Wie schnell kann jeglicher Zugriff entzogen werden?

Bestimmung des Schadensradius (Blast Radius)

Diese Fragen helfen dabei, den Schadensradius präziser zu bestimmen:

·      Wie viele Mandanten?

·      Wie viele Systeme?

·      Welche Berechtigungen?

·      Welche Daten?

·      Welche geografischen Zuständigkeiten (Jurisdiktionen)?

·      Welche nachgelagerten Abhängigkeiten?

·      Wie lange könnten Zugangsdaten gültig bleiben?

·      Wie schnell kann der Zugriff entzogen werden?

MITRE ATT&CK-Mapping: Taktiken des vertrauenswürdigen Zugriffs

Bedrohungsakteure, die Vertrauenspfade von Drittanbietern ausnutzen, agieren primär innerhalb der folgenden Vektoren des MITRE ATT&CK-Frameworks:

Das ATT&CK-Mapping ist technikabhängig und sollte auf der Grundlage des tatsächlich beobachteten Angreiferverhaltens erstellt werden, anstatt es bloß aus dem Vorhandensein einer OAuth- oder SaaS-Integration abzuleiten.

Schwachstellen im traditionellen Drittanbieterrisikomanagement (TPRM)

Konventionelle TPRM-Programme können eine erhebliche Sichtbarkeitslücke hinterlassen, wenn die Bewertungen von Lieferanten nicht mit den technischen Zugriffsbeziehungen verknüpft sind, die in der Produktion etabliert sind.