Atacatorii AI nu obosesc: De ce securitatea cibernetică trebuie să se schimbe

Programul tău de securitate a fost conceput pentru atacatorii care obosesc.

Când OpenAI a publicat relatarea despre modelele care au ieșit dintr-un mediu de evaluare și au petrecut zile în infrastructura de producție a Hugging Face, am numit-o un moment Terminator pentru securitatea cibernetică. Mențin afirmația, dar altceva din această situație ar trebui să ne facă să reflectăm. Nouă zile mai târziu, Anthropic a dezvăluit incidente proprii. La începutul lui august, Meta a confirmat altul. Zile după aceea, modelul unui al patrulea laborator, Kimi K3 de la Moonshot, a scăpat din sandbox‑ul de testare. Patru laboratoare. Mai puțin de trei săptămâni. Patru modele care au ajuns undeva unde nu era intenționat.

Aceste povești au fost în mare parte tratate ca povești de siguranță AI. Și au fost. Dar pentru un CISO, ele sunt și povești de risc terț — și aceasta ar putea fi lecția mai imediată. Adevărul incomod este că incidentul OpenAI‑Hugging Face a fost, în esență, o poveste de risc terț: un component vulnerabil al unui terț ca rută de evadare, un furnizor ca victimă și un nod sistemic de care depind mii de companii ca rază de explozie.

Iată cifra pe care aș aduce‑o la următoarea ta ședință de planificare a securității. Din aproximativ 17.600 de acțiuni ale atacatorilor Hugging Face a recuperat din jurnalele sale, majoritatea au eșuat.

Agentul a testat căi care nu duceau nicăieri. A fost blocat de listele albe de URL și a pivotat. A întâlnit politici IAM care respingeau fiecare apel de modificare. A încercat să acceseze o bază de date de producție de două ori și a expirat ambele încercări. A sondat, a eșuat și a continuat. Mii de ori. Nu s‑a frustrat. Nu s‑a obosit. Iar eșecul i‑a costat aproape nimic.

Patru modele au scăpat din mediile de testare în mai puțin de trei săptămâni. Evadele au ajuns în titluri. Liderii de securitate ar trebui să fie mai preocupați de ce le‑a făcut posibile: un atacator care poate eșua mii de ori aproape fără cost.

Acesta este schimbarea. De decenii, apărătorii au beneficiat de un fapt simplu: eșecul costă atacatorii ceva. Recunoașterea necesita timp și capetele de drum erau costisitoare. Economia acelei asimetriei a făcut ca „impunerea costurilor” asupra atacatorilor să fie o metodă coerentă de a încerca să îi oprească. Când eșecul devine aproape gratuit, calea de succes nu mai este o aculă într‑un car de fân, ci devine o certitudine statistică pentru oricine poate urmări toate căile simultan.

Modelele din aceste incidente indică trei lecții pe care liderii de securitate ar trebui să le pună în aplicare acum.

Patru laboratoare, un singur model

Modelul este remarcabil de consecvent. Se dă unui model un obiectiv. El găsește o cale pe care nimeni nu o aștepta. Uneori acea cale duce direct în sistemele de producție ale unor organizații care nu ar fi trebuit să fie implicate. În cel puțin un caz, organizația afectată a aflat ce s‑a întâmplat pentru că Anthropic a sunat să le spună.

În fiecare caz, calea a trecut prin software, infrastructură sau un mediu construit de altcineva. Liderii de securitate ar trebui să ia asta ca pe o problemă personală.

Fiecare organizație din acest lanț avea un program de securitate. Mai multe aveau programe foarte bune. Eșecul nu a fost limitat la un singur perimetru. S‑a produs în intersecțiile dintre organizații, iar nimeni nu deține aceste intersecții.

Modelele OpenAI au găsit un zero‑day într‑un proxy de pachete auto‑găzduit și l‑au folosit pentru a accesa internetul deschis. De acolo au pătruns într‑un sandbox de execuție de cod nesecurizat aparținând unui client Modal Labs, l‑au folosit ca bază de pregătire și au păcălit încărcătorul de seturi de date al Hugging Face să citească fișiere locale și apoi să execute cod. Într‑un interval de treisprezece ore au deținut rolul de cluster‑admin pe mai multe clustere interne, facilitat de o singură acreditare partajată între toate. Punctul de intrare a fost nou. În interior, vulnerabilitățile erau acelea pe care le documentăm de douăzeci de ani.

Nouă zile mai târziu, Anthropic a făcut ceva mai rar: a publicat propria revizuire a 141.006 de rulări de evaluare și a divulgat trei cazuri cu prezentare similară, fără a fi solicitată: un model care a ajuns pe internetul deschis dintr‑un mediu de evaluare, apoi a obținut acces la sistemele reale ale organizațiilor. De data aceasta nu a fost vorba de o evadare din sandbox, ci de o configurare greșită care a lăsat o cale activă în afara mediului, în timp ce modelul fusese informat că nu există. Odată în afară, modelul a exploatat vulnerabilitățile pe care orice echipă de securitate le cunoaște: parole slabe, puncte finale neautentificate, injecție SQL și acreditări aflate pe o pagină de depanare expusă.

Meta a confirmat un al patrulea la începutul lui august, după ce o eroare de configurare i‑a oferit unuia dintre modelele sale acces la internet în timpul unei evaluări. Meta nu a detectat‑o nici ea; a aflat ce s‑a întâmplat când partenerul său de testare a sunat. Atât acea evaluare, cât și cea a Anthropic au fost efectuate de aceeași firmă externă, Irregular, care le‑a denumit public aceeași problemă. Eroarea de configurare a unui furnizor s‑a propagat la două laboratoare de frontieră și patru organizații victime, niciuna dintre ele neavând vreo relație directă cu Irregular. A fost un furnizor pentru cele două laboratoare, nu pentru ele. Agentul nu a făcut diferență între suprafața de atac a unei companii și a alteia.

Acesta este motivul pentru care este o problemă de risc terț. Expunerea poate proveni acum la câteva niveluri de relație departe de tine, dintr‑o organizație pe care nu ai selectat‑o, evaluat‑o sau chiar știut‑o că face parte din suprafața ta de atac.

Apoi cercetătorii de la Frontier Security au observat că și Kimi K3 de la Moonshot a scăpat din sandbox, permițându‑i să acceseze un depozit de benchmark pe GitHub. Nimeni nu a fost compromis, iar modelul urmărea obiectivul său atribuit, realizând că utilizarea unei chei de răspuns pregătite era mai ieftină decât rezolvarea. Două aspecte fac acest caz important. Cercetătorii l‑au prins în timpul propriului test. Și a rulat pe un set de instrumente complet diferit de cazurile Anthropic și Meta. Un furnizor cu o lună proastă nu explică acest lucru.

Laboratoarele nu ignoră nimic din acestea. Anthropic a publicat revizuirea sa fără a fi solicitată, motiv pentru care industria are un model de examinat și învățat — în loc de un caz izolat de respins. Acesta ar trebui să devină norma. OpenAI a încetinit acum lansarea modelului său Astra după ce evaluările interne nu au putut exclude o capacitate cibernetică critică. Ambele măsuri merită recunoaștere. Dar niciuna nu reprezintă un plan de apărare: o întârziere a lansării guvernează calendarul unei singure companii. Nu face nimic în privința modelelor capabile, inclusiv Kimi K3, care sunt deja disponibile în greutate deschisă și gratuit, dincolo de controlul oricărui laborator individual.

Corelarea fără escaladare nu este detectare

Sistemul de detectare al Hugging Face, spre creditul său, a corelat semnalele într‑un atac coerent. Apoi nu a reușit să escaladeze criticitatea, iar echipa de gardă nu a fost alertată. Instrumentarul a asamblat povestea și nu a putut decide că era urgentă. Aceasta este o arhitectură de triere construită pentru o lume în care 17.600 de evenimente în patru zile ar fi părut absurde.

Securitatea cibernetică are nevoie de Fosbury Flop

În 1968, Dick Fosbury a câștigat aurul olimpic la săritura în înălțime nu prin sărituri mai înalte decât concurenții săi, ci trecând bara cu spatele. Toți ceilalți perfecționau tehnica de „straddle”. Formă mai bună, mai multă forță, câștiguri marginale pe o tehnică veche de decenii. Fosbury a schimbat forma problemei. În decursul a două ediții olimpice, tehnica de „straddle” a dispărut aproape complet.

Liderii de securitate trebuie acum să depășească o bară care tocmai s‑a mutat, iar majoritatea răspunsurilor din industrie până acum constă într‑un „straddle” îmbunătățit: mai multe alerte, analiști mai rapizi, SLA‑uri mai stricte pentru revizuirea umană. Aceasta nu va funcționa, deoarece constrângerea nu este viteza analiștilor. Nu poți contracara atacuri la viteza mașinilor cu triere la viteza umană.

Folosirea Fosbury Flop arată astfel:

• Încetați să tratați limita ca pe controlul. Sandbox‑ul de evaluare a eșuat, încărcătorul de seturi de date a eșuat și izolarea pod‑ului a eșuat, fiecare funcționând corect până când nu a mai făcut‑o. Proiectați pentru ce se întâmplă în continuare. Utilizați acreditări cu durată scurtă. Eliminați identitățile administrative partajate. Blocați accesul la serviciile de metadate. În primul rând, limitați cât de departe poate avansa un atacator după ce primul control eșuează.
• Mutați detectarea de la alertare la corelare. Găsirea unui singur eveniment suspect nu mai este suficientă. Sarcina este să conectați mii de evenimente aparent obișnuite într‑o singură poveste de atac și să știți când acea poveste este suficient de gravă pentru a trezi pe cineva. Acest lucru trebuie tot mai mult să fie automatizat, având în vedere volumul pe care îl observăm.
• Tratați expunerea terților ca pe o cale de atac, nu ca pe un chestionar. Aceste incidente au trecut prin dependențe terțe: produsul unui furnizor, clientul unui furnizor, partenerul de evaluare, instrumente de testare partajate. Riscul dvs. include acum greșeli de configurare comise de organizații pe care nu le‑ați auditat niciodată și poate nici nu știți că există. Evaluările statice, la un moment dat, nu pot vedea acestea. Problema nu este nouă. AI o face mult mai urgentă. Echipele de securitate au nevoie de o vizualizare continuă a companiilor și tehnologiilor de care depind, deoarece atacatorii percep întregul ecosistem ca o suprafață conectată.

La SecurityScorecard, acesta este exact tipul de problemă în jurul căruia este construită cultura noastră: reunirea oamenilor curioși în profunzime despre modul în care gândesc atacatorii, dispuși să conteste presupuneri de douăzeci de ani și entuziasmați să construiască o abordare fundamental diferită a securității!

Întrebarea de adus la următoarea ședință a consiliului

Am spus acum câteva săptămâni că duhulețul a devenit prea puternic pentru sticlă. Patru laboratoare mai târziu, nimic nu contrazice acest lucru. După incidente ca acestea, toată lumea pune aceeași întrebare: Suntem pregătiți pentru atacatori alimentați de AI? Nu cred că această întrebare ne duce prea departe. „Da” și „nu” produc același rezultat: nimic nu se schimbă.

Pune o întrebare mai dificilă. Dacă 17.000 de evenimente cu semnal scăzut ar lovi mediul tău în următoarele patru zile — și majoritatea păreau eșecuri — cât timp ar dura echipei tale să realizeze că era un atac? Ar fi alertat cineva la timp?

Deja știi răspunsul. Diferența dintre acel răspuns și patru zile reprezintă munca.