2025 har ikke været et godt år for Salesforces kunder. En lyssky kriminel gruppe har iværksat en række angreb på sine kunder, hvilket i sidste ende har påvirket organisationer lige fra tech-giganter som Google og Cisco til luksusmærker som Chanel og Louis Vuitton. Selv kritiske infrastrukturudbydere som Qantas Airways, FedEx og TransUnion er blevet overfaldet af angriberne, kaldet enten Scattered LAPSUS$ Hunters, ShinyHunters eller variationer deraf. Gruppen, der synes at være en koalition af medlemmer fra forskellige andre kriminelle bander, har angiveligt kompromitteret over 760 organisationer og cirka 1.5 milliarder optegnelser.
Men Salesforce siger, at dette ikke er et problem, de selv har forårsaget. Hvordan blev et angreb den største kilde til datatyveri i 2025, uden at leverandøren indrømmede noget ansvar?
Det er let at forstå, hvorfor Salesforce nægtede at bære skylden i denne sag. Angriberne ser ikke ud til at have udnyttet nogen sårbarheder i leverandørens online platform.
I stedet kom angriberne ind i Salesforce-systemerne via mangler i kundernes sikkerhed, såsom utilstrækkelig OAuth-styring, manglende MFA-håndhævelse, dårlig integrationsgodkendelse og modtagelighed for social engineering.
En typisk metode til at få adgang var at oprette en falsk version af Salesforce Data Loader-appen, som kunderne bruger til at downloade deres Salesforce-data.
Scattered LAPSUS$-holdet brugte denne falske software til at sende en enhedskode til Salesforces servere, som skulle indtastes af en Salesforce-bruger. Derefter ringede en af banden til offeret og foregav at være fra deres virksomheds helpdesk. De bad offeret om at logge ind på Salesforce og indtaste enhedskoden, hvilket ubevidst bekræftede den falske app (som de ikke ved noget om) som legitim. Derefter fik de kriminelle adgang til offervirksomhedens følsomme Salesforce-data.
Disse fejl i kundesikkerheden er ikke anomalier. Gartner forudsiger at 99 % af cloud-sikkerhedsfejl frem til 2025 vil være kundens skyld. Nyere forskning fra AppOmni viser også viser at 70 % af SaaS-hændelser stammer fra en blanding af kundestyrede tilladelsesproblemer og fejlkonfigurationer.
Forståelse af modellen med delt ansvar
Bekymringen her er, at kunder af leverandørsoftware kan blive lullet ind i en falsk følelse af sikkerhed ved udelukkende at stole på leverandørens platform, især når den software hostes i skyen. Men i virkeligheden er leverandørplatformsikkerhed ikke automatisk lig med datasikkerhed.
Cloudindustrien har endda et navn for dette: delt ansvar. Det er en gensidig forståelse af, hvor tjenesteudbyderens/softwareværtens ansvar slutter, og kundens begynder. Mange virksomheder synes ikke at forstå dette; 53 % af AppOmni-respondenterne, der beskriver sig selv som sikre på sikkerhed, gør det baseret på styrken af deres leverandørers kontroller. Som det fremgår af Salesforce-angrebene, håndterer selv dem, der forstår det, ofte ikke sikkerheden godt nok på deres side af den linje.
For Salesforce- og SaaS-platforme dækker leverandøren typisk sikker platforminfrastruktur, kerneapplikationskode, tilgængelighedsgarantier og indbyggede sikkerhedsfunktioner som MFA-funktioner og kryptering. Det overlader det til kunderne at være ansvarlige for foranstaltninger som administration af brugerkonti, håndhævelse af MFA og administration af OAuth-tokens, implementering af least privilege access, håndtering af tredjepartsintegrationer og korrekt konfiguration af sikkerhedsindstillinger.
Det er også op til brugerne at træne personalet i sikkerhedstrusler. I betragtning af den social engineering, der er involveret i disse angreb, synes det at have været et svagt punkt. Men selv hvis angriberne formår at narre brugerne, bør der være et element af overvågning af brugeraktivitet og opdagelse af anomalier.
Hvordan compliance-rammer kan hjælpe med at forhindre disse brud
Dette er svagheder, som ISO 27001:2022, SOC 2 og NIS 2 eksplicit adresserer gennem adgangskontrol, leverandørtilsyn og krav til konfigurationsstyring. Virksomheder bør se hen til disse driftsstandarder for at forbedre deres holdning og undgå at blive endnu en på listen over undervurderede brands.
For eksempel adgangskontrolserien A.5.15 kræver etablering af dokumenterede adgangskontrolpolitikker ved at implementere principperne "need-to-know" og "need-to-use". A.5.16 håndterer identitetsstyring, mens A.5.17 undersøger styringen af autentificeringsinformation, hvilket kræver sikker lagring og transmission, kryptering i hvile og under transit samt regelmæssig rotation.
A.5.18 dækker adgangsrettigheder. Det kræver formelle processer for tildeling, ændring og tilbagekaldelse af adgangsrettigheder med godkendelse fra aktivsejere og regelmæssige gennemgange mindst én gang årligt. Compliance-chefer kan også se på A.8.2, der regulerer privilegerede adgangsrettigheder.
Disse kontroller kræver centraliserede registre, regelmæssige revisioner og validering af legitimitet, før der gives adgang. Det er netop de foranstaltninger, der ville have forhindret ofre for social engineering i at godkende ondsindede apps.
Det er ikke første gang, vi har set virksomheder lide under brud på grund af deres egne konfigurationsvalg (eller uvidenhed om sådanne valg). Rækken af brud, der ramte Snowflakes kunder i 2024, dukker op i tankerne, da det stammede fra stjålne legitimationsoplysninger og mangel på MFA (selvom Snowflake tilbød MFA). Efterhånden som virksomheder i stigende grad er afhængige af SaaS og placerer deres mest følsomme data i disse infrastrukturer, er det deres ansvar at sikre, at de beskytter deres egne digitale porte til disse systemer korrekt.
