2025 har ikke vært et godt år for Salesforce-kunder. En lyssky kriminell gruppe satte i gang en rekke angrep på kundene sine, som til slutt rammet organisasjoner som spenner fra teknologigiganter som Google og Cisco til luksusmerker som Chanel og Louis Vuitton. Selv leverandører av kritiske infrastrukturer som Qantas Airways, FedEx og TransUnion har blitt overfalt av angriperne, kalt enten Scattered LAPSUS$ Hunters, ShinyHunters eller varianter av disse. Gruppen, som ser ut til å være en koalisjon av medlemmer fra diverse andre kriminelle gjenger, har angivelig kompromittert over 760 organisasjoner og omtrent 1.5 milliarder poster.

Men Salesforce sier at dette ikke er et problem de selv har forårsaket. Hvordan ble et angrep den største kilden til datatyveri i 2025, uten at leverandøren innrømmet noe ansvar?

Det er lett å forstå hvorfor Salesforce nektet å ta ansvar for dette. Angriperne ser ikke ut til å ha utnyttet noen sårbarheter i leverandørens nettplattform.

I stedet kom angriperne seg inn i Salesforce-systemene via feil i kundens sikkerhet, som utilstrekkelig OAuth-styring, manglende MFA-håndhevelse, dårlig integrasjonsgodkjenning og mottakelighet for sosial manipulering.

En typisk metode for å få tilgang var å lage en falsk versjon av Salesforce Data Loader-appen, som kunder bruker til å laste ned Salesforce-dataene sine.

Scattered LAPSUS$-gjengen brukte denne falske programvaren til å sende en enhetskode til Salesforces servere, som skal skrives inn av en Salesforce-bruker. Deretter ringte en av gjengen offeret og latet som om de var fra selskapets brukerstøtte. De ba offeret om å logge inn på Salesforce og skrive inn enhetskoden, og bekreftet dermed ubevisst at den falske appen (som de ikke vet noe om) var legitim. Deretter fikk kriminelle tilgang til offerets selskaps sensitive Salesforce-data.

Disse feilene i kundesikkerheten er ikke avvik. Gartner spår at 99 % av sikkerhetsfeil i skyen frem til 2025 vil være kundens feil. Nyere forskning fra AppOmni viser også viser at 70 % av SaaS-hendelser stammer fra en blanding av kundekontrollerte tillatelsesproblemer og feilkonfigurasjoner.

Forstå modellen for delt ansvar

Bekymringen her er at kunder av leverandørprogramvare kan bli lullet inn i en falsk trygghetsfølelse ved å stole utelukkende på leverandørens plattform, spesielt når programvaren ligger i skyen. Men i virkeligheten er ikke leverandørplattformsikkerhet automatisk det samme som datasikkerhet.

Skybransjen har til og med et navn for dette: delt ansvar. Det er en gjensidig forståelse av hvor tjenesteleverandørens/programvarevertens ansvar slutter, og kundens begynner. Mange bedrifter ser ikke ut til å forstå dette; 53 % av AppOmni-respondentene som beskriver seg selv som trygge på sikkerhet, gjør det basert på styrken i leverandørenes kontroller. Som det fremgår av Salesforce-angrepene, håndterer selv de som forstår det ofte ikke sikkerheten godt nok på sin side av den grensen.

For Salesforce- og SaaS-plattformer dekker leverandøren vanligvis sikker plattforminfrastruktur, kjerneprogramkode, tilgjengelighetsgarantier og innebygde sikkerhetsfunksjoner som MFA-funksjoner og kryptering. Det gjør at kundene er ansvarlige for tiltak som å administrere brukerkontoer, håndheve MFA og administrere OAuth-tokener, implementere tilgang med minste rettigheter, håndtere tredjepartsintegrasjoner og konfigurere sikkerhetsinnstillinger på riktig måte.

Det er også opp til brukerne å lære opp ansatte om sikkerhetstrusler. Gitt den sosiale manipuleringen som er involvert i disse angrepene, ser det ut til å ha vært et svakt punkt. Men selv om angriperne klarer å lure brukerne, bør det være et element av overvåking av brukeraktivitet og oppdagelse av avvik.

Hvordan samsvarsrammeverk kan bidra til å forhindre disse bruddene

Dette er svakheter som ISO 27001:2022, SOC 2 og NIS 2 eksplisitt adresserer gjennom tilgangskontroll, leverandørtilsyn og krav til konfigurasjonsstyring. Bedrifter bør se på disse driftsstandardene for å forbedre sin posisjon og unngå å bli enda en på listen over undervurderte merkevarer.

For eksempel adgangskontrollserien A.5.15 krever etablering av dokumenterte retningslinjer for tilgangskontroll ved å implementere prinsipper for «behov for å vite» og «behov for å bruke». A.5.16 håndterer identitetshåndtering, mens A.5.17 utforsker håndtering av autentiseringsinformasjon, som krever sikker lagring og overføring, kryptering i ro og under overføring, og regelmessig rotasjon.

A.5.18 dekker tilgangsrettigheter. Det krever formelle prosesser for å tildele, endre og tilbakekalle tilgangsrettigheter, med godkjenning fra eierne av aktiva, og regelmessige gjennomganger minst årlig. Samsvarsansvarlige kan også se på A.8.2, som regulerer privilegerte tilgangsrettigheter.

Disse kontrollene krever sentraliserte registre, regelmessige revisjoner og validering av legitimitet før tilgang gis. Det er nettopp disse tiltakene som ville ha forhindret ofre for sosial manipulering fra å autorisere skadelige apper.

Dette er ikke første gang vi har sett selskaper lide av sikkerhetsbrudd på grunn av egne konfigurasjonsvalg (eller uvitenhet om slike valg). Rekken med sikkerhetsbrudd som rammet Snowflakes kunder i 2024 dukker opp i tankene, siden de stammet fra stjålne legitimasjonsopplysninger og mangel på MFA (selv om Snowflake tilbød MFA). Etter hvert som selskaper i økende grad er avhengige av SaaS og legger sine mest sensitive data inn i disse infrastrukturene, er det deres ansvar å sørge for at de beskytter sine egne digitale porter til disse systemene på riktig måte.