2025 har inte varit ett bra år för Salesforces kunder. En skum kriminell grupp genomförde en serie attacker mot sina kunder, vilket i slutändan drabbade organisationer som allt från teknikjättar som Google och Cisco till lyxmärken som Chanel och Louis Vuitton. Även leverantörer av kritisk infrastruktur som Qantas Airways, FedEx och TransUnion har drabbats av angriparna, kallade antingen Scattered LAPSUS$ Hunters, ShinyHunters eller varianter därav. Gruppen, som verkar vara en koalition av medlemmar från olika andra kriminella gäng, har enligt uppgift komprometterat över 760 organisationer och ungefär 1.5 miljarder register.

Men Salesforce säger att detta inte är ett problem de själva orsakat. Hur kunde en attack bli den största källan till datastöld år 2025, utan att leverantören erkände något ansvar?

Det är lätt att förstå varför Salesforce vägrade att ta ansvar för detta. Angriparna verkar inte ha utnyttjat några sårbarheter i leverantörens onlineplattform.

Istället tog sig angriparna in i Salesforce-systemen via brister i kundsäkerheten, såsom otillräcklig OAuth-styrning, saknad MFA-tillämpning, dålig integrationsgranskning och känslighet för social ingenjörskonst.

En typisk metod för att få åtkomst var att skapa en falsk version av Salesforce Data Loader-appen, som kunder använder för att ladda ner sin Salesforce-data.

Scattered LAPSUS$-gänget använde den här falska programvaran för att skicka en enhetskod till Salesforces servrar, vilken ska anges av en Salesforce-användare. Sedan ringde en av gängmedlemmarna offret och låtsades vara från företagets helpdesk. De bad offret att logga in på Salesforce och ange enhetskoden, vilket omedvetet bekräftade att den falska appen (som de inte vet något om) var legitim. Därefter fick brottslingarna tillgång till offrets företags känsliga Salesforce-data.

Dessa brister i kundsäkerheten är inte avvikelser. Gartner förutspår att 99 % av alla säkerhetsfel inom molnet fram till 2025 kommer att vara kundens fel. Ny forskning från AppOmni visar också visar att 70 % av SaaS-incidenterna härrör från en blandning av kundstyrda behörighetsproblem och felkonfigurationer.

Förstå modellen för delat ansvar

Oron här är att kunder som köper leverantörsprogramvara kan vaggas in i en falsk trygghetskänsla genom att enbart förlita sig på leverantörens plattform, särskilt när programvaran finns i molnet. Men i verkligheten är leverantörsplattformssäkerhet inte automatiskt detsamma som datasäkerhet.

Molnindustrin har till och med ett namn för detta: delat ansvar. Det är en ömsesidig förståelse för var tjänsteleverantörens/programvaruvärdens ansvar slutar och kundens börjar. Många företag verkar inte förstå detta; 53 % av AppOmni-respondenterna som beskriver sig själva som trygga med säkerheten gör det baserat på styrkan i sina leverantörers kontroller. Som Salesforce-attackerna visar hanterar även de som förstår det ofta inte säkerheten tillräckligt bra på sin sida av den gränsen.

För Salesforce- och SaaS-plattformar täcker leverantören vanligtvis säker plattformsinfrastruktur, kärnkod för applikationer, tillgänglighetsgarantier och inbyggda säkerhetsfunktioner som MFA-funktioner och kryptering. Det gör att kunderna ansvarar för åtgärder som att hantera användarkonton, tillämpa MFA och hantera OAuth-tokens, implementera lägsta möjliga privilegium, hantera tredjepartsintegrationer och konfigurera säkerhetsinställningar på lämpligt sätt.

Det är också upp till användarna att utbilda personalen om säkerhetshot. Med tanke på den sociala ingenjörskonst som är inblandad i dessa attacker verkar det ha varit en svag punkt. Men även om angriparna lyckas lura användare, bör det finnas ett element av att övervaka användaraktivitet och upptäcka avvikelser.

Hur regelverk för efterlevnad kan bidra till att förhindra dessa intrång

Det här är svagheter som ISO 27001:2022, SOC 2 och NIS 2 uttryckligen adresserar genom åtkomstkontroll, leverantörsövervakning och krav på konfigurationshantering. Företag bör använda dessa driftsstandarder för att förbättra sin hållning och undvika att hamna ytterligare en på listan över underskattade varumärken.

Till exempel åtkomstkontrollserien A.5.15 kräver att dokumenterade policyer för åtkomstkontroll upprättas genom att implementera principer för behovsstyrning och behovsstyrning. A.5.16 hanterar identitetshantering, medan A.5.17 utforskar hanteringen av autentiseringsinformation, vilket kräver säker lagring och överföring, kryptering i vila och under överföring, samt regelbunden rotation.

A.5.18 omfattar åtkomsträttigheter. Det kräver formella processer för att tillhandahålla, ändra och återkalla åtkomsträttigheter, med godkännande från tillgångsägare, och regelbundna granskningar minst en gång per år. Compliance-ansvariga kan också titta på A.8.2, som reglerar privilegierade åtkomsträttigheter.

Dessa kontroller kräver centraliserade register, regelbundna granskningar och validering av legitimitet innan åtkomst beviljas. Det är just de åtgärder som skulle ha hindrat offer för social ingenjörskonst från att auktorisera skadliga appar.

Det här är inte första gången vi har sett företag drabbas av dataintrång på grund av sina egna konfigurationsval (eller okunskap om sådana val). Den rad av dataintrång som drabbade Snowflakes kunder under 2024 dyker upp i tankarna, eftersom det berodde på stulna inloggningsuppgifter och brist på MFA (även om Snowflake erbjöd MFA). I ​​takt med att företag i allt högre grad förlitar sig på SaaS och placerar sina mest känsliga data i dessa infrastrukturer, ligger ansvaret på dem att säkerställa att de skyddar sina egna digitala grindar till dessa system ordentligt.