2025 was nie 'n goeie jaar vir Salesforce-kliënte nie. 'n Skaduryke kriminele groep het 'n reeks aanvalle op sy kliënte geloods, wat uiteindelik organisasies geraak het wat wissel van tegnologiereuse soos Google en Cisco tot luukse handelsmerke soos Chanel en Louis Vuitton. Selfs kritieke infrastruktuurverskaffers soos Qantas Airways, FedEx en TransUnion is deur die aanvallers aangeval, genaamd Scattered LAPSUS$ Hunters, ShinyHunters, of variasies daarvan. Die groep, wat blykbaar 'n koalisie van lede van verskeie ander kriminele bendes is, het na bewering meer as 760 organisasies en ongeveer 1.5 miljard rekords gekompromitteer.
Maar Salesforce sê dat dit nie 'n probleem is wat hulle self veroorsaak het nie. Hoe het 'n aanval die grootste bron van datadiefstal in 2025 geword, sonder dat die verskaffer enige verantwoordelikheid erken?
Dit is maklik om te verstaan waarom Salesforce geweier het om die skuld hiervoor te dra. Dit lyk nie of die aanvallers enige kwesbaarhede in die verskaffer se aanlyn platform uitgebuit het nie.
In plaas daarvan het die aanvallers die Salesforce-stelsels binnegekom via foute in kliëntsekuriteit, soos onvoldoende OAuth-beheer, ontbrekende MFA-afdwinging, swak integrasie-kontrole en vatbaarheid vir sosiale manipulasie.
'n Tipiese metode om toegang te verkry, was om 'n vals weergawe van die Salesforce Data Loader-app te skep, wat kliënte gebruik om hul Salesforce-data af te laai.
Die Scattered LAPSUS$-span het hierdie vals sagteware gebruik om 'n toestelkode na Salesforce se bedieners te stuur, wat veronderstel is om deur 'n Salesforce-gebruiker ingevoer te word. Dan sou een van die bende die slagoffer bel en voorgee dat hulle van hul maatskappy se hulptoonbank is. Hulle sou die slagoffer vra om by Salesforce aan te meld en die toestelkode in te voer, en onwetend die vals toepassing (waarvan hulle niks weet nie) as wettig bevestig. Dan kry die misdadigers toegang tot die slagoffermaatskappy se sensitiewe Salesforce-data.
Hierdie mislukkings in kliëntesekuriteit is nie anomalieë nie. Gartner voorspel dat 99% van wolksekuriteitsmislukkings teen 2025 die kliënt se skuld sal wees. Onlangse navorsing van AppOmni het ook shows dat 70% van SaaS-voorvalle voortspruit uit 'n mengsel van kliënt-beheerde toestemmingsprobleme en wankonfigurasies.
Verstaan die gedeelde verantwoordelikheidsmodel
Die bekommernis hier is dat kliënte vir verskaffersagteware in 'n vals gevoel van sekuriteit gebring kan word deur slegs op die verskaffer se platform staat te maak, veral wanneer daardie sagteware in die wolk aangebied word. Maar in werklikheid is verskaffersplatformsekuriteit nie outomaties gelyk aan datasekuriteit nie.
Die wolkbedryf het selfs 'n naam hiervoor: gedeelde verantwoordelikheid. Dit is 'n wedersydse begrip van waar die diensverskaffer/sagtewaregasheer se verantwoordelikheid eindig en die kliënt s'n begin. Baie ondernemings lyk nie of hulle dit verstaan nie; 53% van AppOmni-respondente wat hulself as vol vertroue in sekuriteit beskryf, doen dit gebaseer op die sterkte van hul verskaffers se beheermaatreëls. Soos blyk uit die Salesforce-aanvalle, hanteer selfs diegene wat dit wel verstaan, dikwels nie sekuriteit goed genoeg aan hul kant van daardie lyn nie.
Vir Salesforce- en SaaS-platforms dek die verskaffer tipies veilige platforminfrastruktuur, kerntoepassingskode, beskikbaarheidswaarborge en ingeboude sekuriteitskenmerke soos MFA-vermoëns en enkripsie. Dit laat kliënte verantwoordelik vir maatreëls soos die bestuur van gebruikersrekeninge, die afdwinging van MFA en die bestuur van OAuth-tokens, die implementering van toegang met die minste voorregte, die hantering van derdeparty-integrasies en die toepaslike konfigurasie van sekuriteitsinstellings.
Dit is ook gebruikers se verantwoordelikheid om personeel op te lei oor sekuriteitsbedreigings. Gegewe die sosiale manipulasie wat by hierdie aanvalle betrokke is, lyk dit asof dit 'n swakpunt was. Selfs al slaag aanvallers daarin om gebruikers te flous, moet daar 'n element wees van die monitering van gebruikersaktiwiteit en die opsporing van afwykings.
Hoe Nakomingsraamwerke hierdie oortredings kan help voorkom
Dit is swakpunte wat ISO 27001:2022, SOC 2 en NIS 2 eksplisiet aanspreek deur toegangsbeheer, verskaffertoesig en konfigurasiebestuurvereistes. Maatskappye moet na hierdie bedryfstandaarde kyk om hul standpunt te verbeter en te verhoed dat hulle nog een in 'n lys van onderdrukte handelsmerke word.
Byvoorbeeld, die toegangsbeheerreeks A.5.15 vereis die vestiging van gedokumenteerde toegangsbeheerbeleide deur die implementering van behoefte-om-te-weet en behoefte-om-te-gebruik beginsels. A.5.16 hanteer identiteitsbestuur, terwyl A.5.17 die bestuur van verifikasie-inligting ondersoek, wat veilige berging en oordrag, enkripsie in rus en in transito, en gereelde rotasie vereis.
A.5.18 dek toegangsregte. Dit vereis formele prosesse vir die voorsiening, wysiging en herroeping van toegangsregte, met magtiging van bate-eienaars, en gereelde hersienings ten minste jaarliks. Nakomingsbestuurders kan ook na A.8.2 kyk, wat bevoorregte toegangsregte reguleer.
Hierdie beheermaatreëls vereis gesentraliseerde registers, gereelde oudits en validering van legitimiteit voordat toegang verleen word. Dit is presies die maatreëls wat slagoffers van sosiale manipulasie sou verhoed het om kwaadwillige toepassings te magtig.
Dit is nie die eerste keer dat ons maatskappye sien ly aan oortredings as gevolg van hul eie konfigurasiekeuses (of onkunde oor sulke keuses) nie. Die reeks oortredings wat Snowflake-kliënte in 2024 raak, kom by my op, aangesien dit voortspruit uit gesteelde geloofsbriewe en 'n gebrek aan MFA (alhoewel Snowflake MFA aangebied het). Namate maatskappye toenemend op SaaS staatmaak en hul sensitiefste data in hierdie infrastrukture plaas, rus die onus op hulle om te verseker dat hulle hul eie digitale hekke na hierdie stelsels behoorlik bewaak.
