AI‑angripere blir ikke slitne: Hvorfor cybersikkerhet må endres

Sikkerhetsprogrammet ditt ble bygget for angripere som gjør det.

Da OpenAI publiserte sin beretning om modellene som brøt ut av et evalueringsmiljø og tilbrakte dager i Hugging Face sin produksjonsinfrastruktur, kalte jeg det et Terminator‑øyeblikk for cybersikkerhet. Jeg står ved uttalelsen, men noe annet ved dette bør få oss til å stoppe opp. Ni dager senere avslørte Anthropic egne hendelser. Tidlig i august bekreftet Meta en annen. Dager etter det slapp en fjerde labs modell, Moonshots Kimi K3, fra sin test‑sandbox. Fire laboratorier. Under tre uker. Fire modeller som kom seg til et sted ingen hadde tiltenkt.

Disse historiene har i stor grad blitt behandlet som AI‑sikkerhetshistorier. Det er de. Men for en CISO er de også tredjepartsrisikohistorier – og det kan være den mer umiddelbare leksjonen. Den ubehagelige sannheten er at OpenAI‑Hugging Face‑hendelsen i sin kjerne var en tredjepartsrisikohistorie: en sårbar tredjepartskomponent som fluktveier, en leverandør som offer, og en systemisk node tusenvis av selskaper er avhengige av som sprengningsradius.

Her er tallet jeg ville tatt med til ditt neste sikkerhetsplanleggingsmøte. Av de omtrent 17 600 angriperhandlingene Hugging Face hentet fra loggene sine, mislyktes de fleste.

Agenten testet stier som førte ingen vei. Den ble blokkert av URL‑hvitelister og pivotet. Den traff IAM‑policyer som avviste alle endrende kall. Den prøvde å nå en produksjonsdatabase to ganger og fikk tidsavbrudd begge ganger. Den undersøkte, feilet og gikk videre. Tusener av ganger. Den ble ikke frustrert. Den ble ikke sliten. Og feil kostet den nesten ingenting.

Fire modeller brøt ut av testmiljøer på under tre uker. Fluktene fikk overskrifter. Sikkerhetsledere bør være mer bekymret for hva som gjorde dem mulige: en angriper som kan feile tusenvis av ganger med nesten ingen kostnad.

Det er skiftet. I flere tiår har forsvarere hatt nytte av ett enkelt faktum: feil koster angripere noe. Rekognosering tok tid og blindveier var kostbare. Økonomien i den asymmetrien gjorde at «pålegge kostnader» på angripere var en sammenhengende måte å prøve å stoppe dem på. Når feil blir nesten gratis, slutter den vellykkede veien å være en nål i en høystakk og blir en statistisk sikkerhet for enhver som kan forfølge alle stier samtidig.

Mønstrene i disse hendelsene peker på tre leksjoner sikkerhetsledere bør handle på nå.

Fire laboratorier, én form

Mønsteret er bemerkelsesverdig konsistent. Gi en modell et mål. Den finner en sti ingen forventet. Noen ganger leder den stien rett inn i produksjonssystemene til organisasjoner som aldri skulle vært involvert. I minst ett tilfelle lærte den berørte organisasjonen hva som hadde skjedd fordi Anthropic ringte for å fortelle dem

I alle tilfeller gikk stien gjennom programvare, infrastruktur eller et miljø noen andre bygde. Sikkerhetsledere bør ta dette personlig.

Alle organisasjoner i denne kjeden hadde et sikkerhetsprogram. Flere hadde svært gode. Feilen var ikke innelukket innenfor noen enkelt perimeter. Den skjedde i sømmene mellom organisasjoner, og ingen eier sømmene.

OpenAIs modeller fant en zero‑day i en selv‑hostet pakke‑proxy og brukte den til å nå det åpne internett. Derfra fikk de rot på en usikret kode‑eksekverings‑sandbox som tilhørte en Modal Labs‑kunde, brukte den som en staging‑base, og lurte Hugging Face sin datasett‑laster til å lese lokale filer og deretter kjøre kode. Innen tretten timer hadde de cluster‑admin‑rettigheter på flere interne klynger, hjulpet av en enkelt legitimasjon delt på tvers av dem alle. Inngangspunktet var nytt. Inne var svakhetene de vi har skrevet om i tjue år.

Ni dager senere gjorde Anthropic noe sjeldnere: den publiserte sin egen gjennomgang av 141 006 evalueringskjøringer og avslørte tre tilfeller med lignende presentasjon uten forespørsel: en modell som nådde det åpne internett fra et evalueringsmiljø, og deretter fikk tilgang til ekte organisasjoners systemer. Ingen sandbox‑flukt denne gangen, bare en feilkonfigurasjon som lot en aktiv sti være åpen mens modellen hadde blitt fortalt at ingen eksisterte. Når den var ute, utnyttet modellen svakheter alle sikkerhetsteam kjenner: svake passord, uautentiserte endepunkter, SQL‑injeksjon og legitimasjon som lå på en eksponert feilsøkings‑side.

Meta bekreftet en fjerde i begynnelsen av august, etter en konfigurasjonsfeil som ga en av modellene internett‑tilgang under en evaluering. Meta oppdaget det heller ikke; de lærte hva som hadde skjedd da deres testpartner ringte. Både den evalueringen og Anthropics ble kjørt av samme eksterne firma, Irregular, som offentlig har kalt dem samme problem. En leverandørs konfigurasjonsfeil spredte seg over to front‑labber og fire offerorganisasjoner, som ingen av dem hadde noen direkte relasjon til Irregular. Det var en leverandør til de to labbene, ikke til dem. Agenten brydde seg ikke om hvor en bedrifts angrepsflate sluttet og en annens begynte.

Det er dette som gjør dette til et tredjepartsrisikoproblem. Eksponering kan nå oppstå flere relasjoner unna deg, i en organisasjon du aldri har valgt, vurdert eller engang visste var en del av din angrepsflate.

Deretter oppdaget forskere ved Frontier Security at Moonshots Kimi K3 også slapp sin sandbox, slik at den kunne få tilgang til et benchmark‑repo på GitHub. Ingen ble brutt inn i, og modellen jaget sitt tildelte mål, etter å ha funnet ut at bruk av en ferdig svarnøkkel var billigere enn å løse. To ting gjør dette tilfellet viktig. Forskerne fanget det under sin egen test. Og det kjørte på helt annen verktøykjede enn Anthropic‑ og Meta‑sakene. En leverandør som har en dårlig måned forklarer ikke dette.

Labben ignorerer ikke dette. Anthropic publiserte sin gjennomgang uten forespørsel, noe som er grunnen til at bransjen har et mønster å undersøke og lære av – i stedet for en avvik som avfeies. Det bør bli normen. OpenAI har nå senket utgivelsen av sin Astra‑modell etter at interne evalueringer ikke kunne utelukke kritisk cyberkapasitet. Begge tiltakene fortjener ros. Men ingen av dem er en forsvarsplan: en utgivelsesforsinkelse styrer ett selskaps kalender. Det gjør ingenting med kapable modeller, inkludert Kimi K3, som allerede leveres med åpen vekt og gratis, utenfor kontrollen til noen enkeltlab.

Korrelasjon uten eskalering er ikke deteksjon

Hugging Face sitt deteksjonsstack, til sin ære, korrelerte signalene til et sammenhengende angrep. Den feilet så i å eskalere kritikaliteten, og beredskapsteamet ble ikke varslet. Verktøyet satte sammen historien og kunne ikke avgjøre at den var presserende. Det er en triage‑arkitektur bygget for en verden hvor 17 600 hendelser over fire dager ville ha virket absurd.

Cybersikkerhet trenger sin Fosbury Flop

I 1968 vant Dick Fosbury olympisk gull i høydehopp, ikke ved å hoppe høyere enn konkurrentene, men ved å gå over stangen baklengs. Alle andre finjusterte “straddle”. Bedre form, mer styrke, marginale gevinster på en tiår gammel teknikk. Fosbury endret problemets form. Innen to olympiader var “straddle” nesten utdødd.

Sikkerhetsledere må nå klare en stang som nettopp har flyttet seg, og mesteparten av bransjens svar så langt er en bedre “straddle”: flere varsler, raskere analytikere, strengere SLA‑er på menneskelig gjennomgang. Det vil ikke fungere, fordi begrensningen ikke er analytikerens hastighet. Du kan ikke svare på maskinhastige angrep med menneskelig triage.

Floppen ser slik ut:

• Stopp å behandle grensen som kontrollen. Evaluerings‑sandboxen feilet, datasett‑lasteren feilet, og pod‑isolasjonen feilet, hver av dem gjorde jobben sin helt til den ikke gjorde det. Design for hva som skjer videre. Bruk kortvarige legitimasjoner. Fjern delte administrative identiteter. Blokker tilgang til metadata‑tjenester. Fremfor alt, begrens hvor langt en angriper kan bevege seg etter at den første kontrollen feiler.
• Flytt deteksjon fra varsling til korrelasjon. Å finne én mistenkelig hendelse er ikke lenger nok. Oppgaven er å koble tusenvis av tilsynelatende vanlige hendelser til én angrepshistorie, og vite når den historien er alvorlig nok til å vekke noen. Dette må i økende grad automatiseres gitt volumet vi ser.
• Behandle tredjeparts‑eksponering som en angrepsvei, ikke som et spørreskjema. Disse hendelsene gikk gjennom tredjeparts‑avhengigheter: et leverandørprodukt, en leverandørkunde, en evalueringspartner, delt testverktøy. Din risiko inkluderer nå konfigurasjonsfeil gjort av organisasjoner du aldri har revidert og kanskje ikke engang vet eksisterer. Statiske, punkt‑i‑tid‑vurderinger kan ikke se dette. Problemet er ikke nytt. AI gjør det mye mer presserende. Sikkerhetsteam trenger en kontinuerlig oversikt over selskapene og teknologien de er avhengige av, fordi angripere ser hele økosystemet som én sammenkoblet overflate.

Hos SecurityScorecard er dette akkurat den typen problem vår kultur er bygget rundt: å samle folk som er dypt nysgjerrige på hvordan angripere tenker, villige til å utfordre tjue år gamle antakelser, og begeistret for å bygge en fundamentalt annerledes tilnærming til sikkerhet!

Spørsmålet du bør ta med til ditt neste styremøte

Jeg sa for noen uker siden at genien har blitt for kraftig for flasken. Fire laboratorier senere har ingenting motsagt dette. Etter hendelser som disse stiller alle det samme spørsmålet: Er vi klare for AI‑drevede angripere? Jeg tror ikke det spørsmålet tar oss særlig langt. ‘Ja’ og ‘nei’ gir samme resultat: ingenting endres.

Still et vanskeligere spørsmål. Hvis 17 000 lav‑signal‑hendelser rammer miljøet ditt i løpet av de neste fire dagene – og de fleste så ut som feil – hvor lang tid vil teamet ditt bruke på å innse at de var ett angrep? Ville noen blitt varslet i tide?

Du vet allerede svaret. Gapet mellom det svaret og fire dager er arbeidet.