2025 was geen goed jaar voor Salesforce-klanten. Een louche criminele groep voerde een reeks aanvallen uit op haar klanten, met uiteindelijk gevolgen voor organisaties variërend van techgiganten zoals Google en Cisco tot luxemerken zoals Chanel en Louis Vuitton. Zelfs aanbieders van kritieke infrastructuur zoals Qantas Airways, FedEx en TransUnion werden getroffen door de aanvallers, die Scattered LAPSUS$ Hunters, ShinyHunters of varianten daarvan worden genoemd. De groep, die een coalitie lijkt te zijn van leden van diverse andere criminele bendes, heeft naar verluidt meer dan 760 organisaties en ongeveer 1.5 miljard records gecompromitteerd.
Maar Salesforce zegt dat dit probleem niet door henzelf is veroorzaakt. Hoe kon een aanval in 2025 de grootste bron van datadiefstal worden, zonder dat de leverancier enige verantwoordelijkheid erkende?
Het is gemakkelijk te begrijpen waarom Salesforce weigerde de vinger op de zere plek te leggen. De aanvallers lijken geen misbruik te hebben gemaakt van kwetsbaarheden in het online platform van de leverancier.
In plaats daarvan kwamen de aanvallers in de Salesforce-systemen terecht via gebreken in de beveiliging van klanten, zoals ontoereikend OAuth-beheer, ontbrekende MFA-handhaving, gebrekkige integratiecontrole en kwetsbaarheid voor social engineering.
Een veelgebruikte methode om toegang te krijgen, was het creëren van een nepversie van de Salesforce Data Loader-app. Deze app gebruiken klanten om hun Salesforce-gegevens te downloaden.
De Scattered LAPSUS$-crew gebruikte deze nepsoftware om een apparaatcode naar de servers van Salesforce te sturen, die door een Salesforce-gebruiker zou moeten worden ingevoerd. Vervolgens belde een van de bendeleden het slachtoffer en deed alsof hij van de helpdesk van hun bedrijf kwam. Ze vroegen het slachtoffer om in te loggen op Salesforce en de apparaatcode in te voeren, waarmee ze onbewust bevestigden dat de nep-app (waar ze niets van wisten) legitiem was. Vervolgens kregen de criminelen toegang tot de gevoelige Salesforce-gegevens van het slachtoffer.
Deze tekortkomingen in de klantbeveiliging zijn geen afwijkingen. Gartner voorspelt dat 99% van de cloudbeveiligingsfouten tot 2025 de schuld van de klant zal zijn. Recent onderzoek van AppOmni toont ook aan shows dat 70% van de SaaS-incidenten voortkomt uit een combinatie van door de klant gecontroleerde machtigingsproblemen en verkeerde configuraties.
Het gedeelde verantwoordelijkheidsmodel begrijpen
De zorg hierbij is dat klanten van leverancierssoftware een vals gevoel van veiligheid krijgen door alleen op het platform van de leverancier te vertrouwen, vooral wanneer die software in de cloud wordt gehost. Maar in werkelijkheid staat de beveiliging van het leveranciersplatform niet automatisch gelijk aan gegevensbeveiliging.
De cloudindustrie heeft hier zelfs een naam voor: gedeelde verantwoordelijkheid. Het is een wederzijds begrip van waar de verantwoordelijkheid van de serviceprovider/softwarehost eindigt en die van de klant begint. Veel bedrijven lijken dit niet te begrijpen; 53% van de AppOmni-respondenten die zichzelf als zelfverzekerd in beveiliging beschrijven, baseert zich daarbij op de kracht van de controlemechanismen van hun leveranciers. Zoals blijkt uit de Salesforce-aanvallen, hebben zelfs degenen die er wel mee te maken krijgen, de beveiliging aan hun kant vaak niet goed genoeg geregeld.
Voor Salesforce- en SaaS-platforms dekt de leverancier doorgaans de beveiligde platforminfrastructuur, de kernapplicatiecode, beschikbaarheidsgaranties en ingebouwde beveiligingsfuncties zoals MFA-mogelijkheden en encryptie. Klanten zijn dus zelf verantwoordelijk voor maatregelen zoals het beheren van gebruikersaccounts, het afdwingen van MFA en het beheren van OAuth-tokens, het implementeren van toegang met minimale bevoegdheden, het verwerken van integraties met derden en het correct configureren van beveiligingsinstellingen.
Het is ook aan gebruikers om personeel te trainen in beveiligingsrisico's. Gezien de social engineering die bij deze aanvallen betrokken is, lijkt dat een zwak punt te zijn geweest. Maar zelfs als aanvallers erin slagen gebruikers voor de gek te houden, zou er toch een element van monitoring van gebruikersactiviteit en het detecteren van afwijkingen moeten zijn.
Hoe compliance-kaders kunnen helpen deze inbreuken te voorkomen
Dit zijn zwakke punten die ISO 27001:2022, SOC 2 en NIS 2 expliciet aanpakken door middel van eisen op het gebied van toegangscontrole, leverancierstoezicht en configuratiebeheer. Bedrijven zouden deze operationele normen moeten gebruiken om hun positie te verbeteren en te voorkomen dat ze het zoveelste merk worden in een lijst met gestolen merken.
Bijvoorbeeld de toegangscontroleserie A.5.15 Vereist het opstellen van gedocumenteerd toegangscontrolebeleid door de implementatie van need-to-know- en need-to-use-principes. A.5.16 behandelt identiteitsbeheer, terwijl A.5.17 het beheer van authenticatiegegevens onderzoekt, waarbij veilige opslag en transmissie, encryptie in rust en tijdens de overdracht, en regelmatige rotatie vereist zijn.
A.5.18 omvat toegangsrechten. Het vereist formele processen voor het verlenen, wijzigen en intrekken van toegangsrechten, met toestemming van de asset-eigenaren, en regelmatige evaluaties, minstens eenmaal per jaar. Compliancemanagers zouden ook A.8.2, het beheer van bevoorrechte toegangsrechten, kunnen bekijken.
Deze controles vereisen gecentraliseerde registers, regelmatige audits en validatie van de legitimiteit voordat toegang wordt verleend. Dit zijn precies de maatregelen die slachtoffers van social engineering ervan hadden kunnen weerhouden kwaadaardige apps te autoriseren.
Dit is niet de eerste keer dat bedrijven te maken krijgen met inbreuken vanwege hun eigen configuratiekeuzes (of onwetendheid over dergelijke keuzes). Denk bijvoorbeeld aan de reeks inbreuken die Snowflake-klanten in 2024 zullen treffen, die voortkwamen uit gestolen inloggegevens en een gebrek aan MFA (ondanks dat Snowflake MFA aanbood). Nu bedrijven steeds meer vertrouwen op SaaS en hun meest gevoelige gegevens in deze infrastructuren plaatsen, ligt de verantwoordelijkheid bij hen om hun eigen digitale poorten naar deze systemen goed te bewaken.










