2025 war kein gutes Jahr für Salesforce-Kunden. Eine dubiose kriminelle Gruppe verübte eine Reihe von Angriffen auf deren Kunden, die letztendlich Organisationen wie Tech-Giganten wie Google und Cisco sowie Luxusmarken wie Chanel und Louis Vuitton betrafen. Selbst kritische Infrastrukturanbieter wie Qantas Airways, FedEx und TransUnion wurden von den Angreifern, die sich Scattered LAPSUS$ Hunters, ShinyHunters oder ähnliche Namen nennen, lahmgelegt. Die Gruppe, die offenbar ein Zusammenschluss von Mitgliedern verschiedener krimineller Banden ist, soll über 760 Organisationen und rund 1.5 Milliarden Datensätze kompromittiert haben.

Salesforce beteuert jedoch, dass es sich nicht um ein selbstverschuldetes Problem handele. Wie konnte ein Angriff zur größten Quelle von Datendiebstahl im Jahr 2025 werden, ohne dass der Anbieter irgendeine Verantwortung übernimmt?

Es ist leicht nachvollziehbar, warum Salesforce die Verantwortung in diesem Fall ablehnte. Die Angreifer scheinen keine Sicherheitslücken in der Online-Plattform des Anbieters ausgenutzt zu haben.

Stattdessen gelangten die Angreifer über Sicherheitslücken bei den Kunden in die Salesforce-Systeme, wie etwa unzureichende OAuth-Governance, fehlende MFA-Durchsetzung, mangelhafte Integrationsprüfung und Anfälligkeit für Social Engineering.

Eine typische Methode, um Zugriff zu erlangen, war die Erstellung einer gefälschten Version der Salesforce Data Loader-App, die Kunden zum Herunterladen ihrer Salesforce-Daten verwenden.

Die Gruppe „Scattered LAPSUS$“ nutzte diese gefälschte Software, um einen Gerätecode an die Server von Salesforce zu senden, der von einem Salesforce-Nutzer eingegeben werden sollte. Anschließend rief ein Mitglied der Bande das Opfer an und gab sich als Mitarbeiter des Kundendienstes aus. Das Opfer wurde aufgefordert, sich bei Salesforce einzuloggen und den Gerätecode einzugeben, wodurch die gefälschte App (über die das Opfer nichts wusste) unwissentlich als legitim bestätigt wurde. So erhielten die Kriminellen Zugriff auf die sensiblen Salesforce-Daten des betroffenen Unternehmens.

Diese Sicherheitslücken bei Kunden sind keine Ausnahmen. Gartner prognostiziert dass 99 % der Sicherheitslücken in Cloud-Umgebungen bis 2025 auf Kundenfehler zurückzuführen sein werden. Dies geht aus einer aktuellen Studie von AppOmni hervor. erklärt dass 70 % der SaaS-Vorfälle auf eine Mischung aus kundenseitig verursachten Berechtigungsproblemen und Fehlkonfigurationen zurückzuführen sind.

Das Modell der gemeinsamen Verantwortung verstehen

Die Sorge besteht darin, dass Kunden von Softwareanbietern sich in falscher Sicherheit wiegen könnten, indem sie sich allein auf die Plattform des Anbieters verlassen, insbesondere wenn die Software in der Cloud gehostet wird. Tatsächlich ist die Sicherheit der Anbieterplattform jedoch nicht automatisch gleichbedeutend mit Datensicherheit.

Die Cloud-Branche hat sogar einen Begriff dafür: geteilte Verantwortung. Es handelt sich um ein gemeinsames Verständnis darüber, wo die Verantwortung des Dienstanbieters/Software-Hosts endet und die des Kunden beginnt. Viele Unternehmen scheinen dies nicht zu verstehen; 53 % der Befragten von AppOmni, die sich als sicherheitsbewusst bezeichnen, tun dies aufgrund der Stärke der Sicherheitsmaßnahmen ihrer Anbieter. Wie die Angriffe auf Salesforce gezeigt haben, kümmern sich selbst diejenigen, die dies verstanden haben, oft nicht ausreichend um die Sicherheit auf ihrer Seite dieser Grenze.

Bei Salesforce und SaaS-Plattformen übernimmt der Anbieter in der Regel die Bereitstellung einer sicheren Plattforminfrastruktur, des Kernanwendungscodes, Verfügbarkeitsgarantien sowie integrierter Sicherheitsfunktionen wie Multi-Faktor-Authentifizierung (MFA) und Verschlüsselung. Kunden sind somit für Maßnahmen wie die Verwaltung von Benutzerkonten, die Durchsetzung von MFA und die Verwaltung von OAuth-Tokens, die Implementierung des Prinzips der minimalen Berechtigungen, die Integration von Drittanbietern und die entsprechende Konfiguration der Sicherheitseinstellungen verantwortlich.

Es liegt auch in der Verantwortung der Nutzer, ihre Mitarbeiter über Sicherheitsbedrohungen zu schulen. Angesichts der bei diesen Angriffen eingesetzten Social-Engineering-Methoden scheint dies eine Schwachstelle gewesen zu sein. Selbst wenn es Angreifern gelingt, Nutzer zu täuschen, sollte die Nutzeraktivität überwacht und Anomalien erkannt werden.

Wie Compliance-Rahmenwerke dazu beitragen können, diese Verstöße zu verhindern

Diese Schwächen werden durch ISO 27001:2022, SOC 2 und NIS 2 explizit durch Zugriffskontrolle, Lieferantenüberwachung und Konfigurationsmanagement-Anforderungen adressiert. Unternehmen sollten diese Standards nutzen, um ihre Sicherheitslage zu verbessern und nicht zu den Marken zu gehören, deren Systeme kompromittiert wurden.

Zum Beispiel die Zutrittskontrollserie A.5.15 Erfordert die Festlegung dokumentierter Zugriffskontrollrichtlinien durch die Anwendung der Need-to-know- und Need-to-use-Prinzipien. A.5.16 befasst sich mit dem Identitätsmanagement, während A.5.17 die Verwaltung von Authentifizierungsinformationen untersucht und sichere Speicherung und Übertragung, Verschlüsselung ruhender und übertragener Daten sowie regelmäßige Rotation vorschreibt.

A.5.18 Dies umfasst Zugriffsrechte. Es erfordert formale Prozesse für die Bereitstellung, Änderung und den Entzug von Zugriffsrechten mit Genehmigung der Anlagenbesitzer sowie regelmäßige Überprüfungen, mindestens jährlich. Compliance-Manager sollten auch Abschnitt A.8.2 zu privilegierten Zugriffsrechten berücksichtigen.

Diese Kontrollmechanismen erfordern zentrale Register, regelmäßige Prüfungen und die Überprüfung der Legitimität vor der Zugriffsgewährung. Genau diese Maßnahmen hätten verhindert, dass Opfer von Social Engineering schädliche Anwendungen autorisieren.

Dies ist nicht das erste Mal, dass Unternehmen aufgrund eigener Konfigurationsentscheidungen (oder deren Unkenntnis) Opfer von Sicherheitslücken werden. Man denke nur an die Reihe von Sicherheitsvorfällen bei Snowflake-Kunden im Jahr 2024, die auf gestohlene Zugangsdaten und fehlende Zwei-Faktor-Authentifizierung (MFA) zurückzuführen waren (obwohl Snowflake MFA anbot). Da Unternehmen zunehmend auf SaaS setzen und ihre sensibelsten Daten in diesen Infrastrukturen speichern, liegt es in ihrer Verantwortung, den Zugang zu diesen Systemen angemessen zu schützen.