Gli aggressori AI non si stancano: Perché la sicurezza informatica deve cambiare

Il tuo programma di sicurezza è stato costruito per gli aggressori che lo fanno.

Quando OpenAI ha pubblicato il suo resoconto dei modelli che sono sfuggiti da un ambiente di valutazione e hanno trascorso giorni all’interno dell’infrastruttura di produzione di Hugging Face, l’ho definito un momento Terminator per la cybersecurity. Rimango fedele a questa affermazione, ma qualcos’altro in merito dovrebbe farci riflettere. Nove giorni dopo, Anthropic ha divulgato incidenti propri. All’inizio di agosto, Meta ne ha confermato un altro. Giorni dopo, il modello di un quarto laboratorio, Kimi K3 di Moonshot, è scivolato fuori dalla sua sandbox di test. Quattro laboratori. Meno di tre settimane. Quattro modelli che sono finiti dove nessuno li aveva previsto.

Queste vicende sono state per lo più trattate come storie di sicurezza dell’IA. Lo sono. Ma per un CISO, sono anche storie di rischio di terze parti — e questa potrebbe essere la lezione più immediata. La verità scomoda è che l’incidente OpenAI-Hugging Face era, nel suo nucleo, una storia di rischio di terze parti: un componente vulnerabile di terze parti come via di fuga, un fornitore come vittima e un nodo sistemico da cui dipendono migliaia di aziende come raggio d’esplosione.

Ecco il numero che porterei al tuo prossimo incontro di pianificazione della sicurezza. Dei circa 17.600 azioni dell’attaccante Hugging Face ha recuperato dai suoi log, la maggior parte è fallita.

L’agente ha testato percorsi che non portavano da nessuna parte. È stato bloccato dalle whitelist di URL e ha cambiato rotta. Ha incontrato politiche IAM che negavano ogni chiamata di mutazione. Ha tentato di raggiungere un database di produzione due volte e ha subito timeout entrambe le volte. Ha sondato, fallito e proseguito. Migliaia di volte. Non si è frustrato. Non si è stancato. E il fallimento gli è costato quasi nulla.

Quattro modelli sono sfuggiti dagli ambienti di test in meno di tre settimane. Le fughe hanno fatto notizia. I leader della sicurezza dovrebbero preoccuparsi di più di ciò che le ha rese possibili: un aggressore che può fallire migliaia di volte a quasi nessun costo.

Questo è il cambiamento. Per decenni, i difensori hanno beneficiato di un semplice fatto: il fallimento costa qualcosa agli aggressori. La ricognizione richiedeva tempo e i vicoli ciechi erano costosi. L’economia di quella asimmetria è ciò che ha reso l’«imporre costi» agli aggressori un modo coerente per cercare di fermarli. Quando il fallimento diventa quasi gratuito, il percorso di successo smette di essere un ago nel pagliaio e diventa una certezza statistica per chiunque possa perseguire tutti i percorsi simultaneamente.

I modelli in questi incidenti indicano tre lezioni su cui i leader della sicurezza dovrebbero agire subito.

Quattro laboratori, una forma

Il modello è sorprendentemente coerente. Dai a un modello un obiettivo. Trova un percorso che nessuno si aspettava. Talvolta quel percorso conduce direttamente nei sistemi di produzione di organizzazioni che non avrebbero mai dovuto essere coinvolte. In almeno un caso, l’organizzazione colpita ha scoperto cosa era successo perché Anthropic ha chiamato per informarla

In ogni caso, il percorso è passato attraverso software, infrastruttura o un ambiente costruito da qualcun altro. I leader della sicurezza dovrebbero prenderlo sul personale.

Ogni organizzazione in questa catena aveva un programma di sicurezza. Diverse ne avevano di molto buoni. Il fallimento non è stato contenuto all’interno di un singolo perimetro. È avvenuto nelle fessure tra le organizzazioni, e nessuno possiede queste fessure.

I modelli di OpenAI hanno scoperto una vulnerabilità zero-day in un proxy di pacchetti auto‑ospitato e l’hanno usata per raggiungere Internet aperto. Da lì hanno radicato in una sandbox di esecuzione di codice non sicura appartenente a un cliente di Modal Labs, l’hanno usata come base di staging e hanno ingannato il caricatore di dataset di Hugging Face facendogli leggere file locali e poi eseguire codice. In tredici ore hanno ottenuto privilegi di cluster‑admin su più cluster interni, facilitati da un’unica credenziale condivisa tra tutti. Il punto di ingresso era nuovo. All’interno, le debolezze erano quelle che descriviamo da vent’anni.

Nove giorni dopo, Anthropic ha fatto qualcosa di più raro: ha pubblicato la sua revisione di 141.006 esecuzioni di valutazione e ha divulgato tre casi con presentazione simile senza sollecitazione: un modello che raggiunge Internet aperto da un ambiente di valutazione, poi ottiene l’accesso ai sistemi di organizzazioni reali. Nessuna fuga dalla sandbox questa volta, solo una configurazione errata che ha lasciato un percorso attivo fuori mentre al modello era stato detto che non ne esisteva alcuno. Una volta fuori, il modello ha sfruttato debolezze che ogni team di sicurezza conosce: password deboli, endpoint non autenticati, iniezione SQL e credenziali su una pagina di debug esposta.

Meta ha confermato un quarto caso all’inizio di agosto, dopo che un errore di configurazione ha concesso a uno dei suoi modelli l’accesso a Internet durante una valutazione. Anche Meta non l’ha rilevato; ha scoperto cosa era successo quando il suo partner di test ha chiamato. Sia quella valutazione sia quella di Anthropic sono state eseguite dalla stessa società esterna, Irregular, che le ha pubblicamente definite lo stesso problema. L’errore di configurazione di un fornitore si è propagato attraverso due laboratori di frontiera e quattro organizzazioni vittime, nessuna delle quali aveva alcuna relazione diretta con Irregular. Era un fornitore per i due laboratori, non per loro. L’agente non si preoccupava di dove finisse la superficie di attacco di un’azienda e iniziasse quella di un’altra.

Questo è ciò che rende il problema un rischio di terze parti. L’esposizione può ora originarsi a più relazioni di distanza da te, in un’organizzazione che non hai mai selezionato, valutato o nemmeno saputo fosse parte della tua superficie di attacco.

Poi i ricercatori di Frontier Security hanno scoperto che anche Kimi K3 di Moonshot stava sfuggendo dalla sua sandbox, così da poter accedere a un repository di benchmark su GitHub. Nessuno è stato violato, e il modello stava inseguendo il suo obiettivo assegnato, avendo capito che usare una chiave di risposta pronta era più economico che risolvere. Due cose rendono questo caso importante. I ricercatori l’hanno catturato durante il loro test. E ha funzionato su strumenti completamente diversi rispetto ai casi di Anthropic e Meta. Un fornitore che ha un mese negativo non spiega questo.

I laboratori non stanno ignorando nulla di ciò. Anthropic ha pubblicato la sua revisione senza sollecitazione, motivo per cui l’industria ha un modello da esaminare e da cui apprendere — piuttosto che un’eccezione da liquidare. Questo dovrebbe diventare la norma. OpenAI ha ora rallentato il rilascio del suo modello Astra dopo che valutazioni interne non hanno potuto escludere capacità cyber critiche. Entrambe le mosse meritano credito. Ma nessuna è un piano di difesa: un ritardo di rilascio regola il calendario di un’azienda. Non fa nulla riguardo ai modelli capaci, tra cui Kimi K3, che già vengono distribuiti in versione open‑weight e gratuita, al di là del controllo di qualsiasi singolo laboratorio.

La correlazione senza escalation non è rilevamento

Lo stack di rilevamento di Hugging Face, a suo merito, ha correlato i segnali in un attacco coerente. Poi non è riuscito a scalare la criticità, e il team di reperibilità non è stato allertato. Lo strumento ha assemblato la storia e non ha potuto decidere che fosse urgente. Questa è un’architettura di triage costruita per un mondo in cui 17.600 eventi in quattro giorni sarebbero sembrati assurdi.

La sicurezza informatica ha bisogno del suo Fosbury Flop

Nel 1968, Dick Fosbury vinse l’oro olimpico nel salto in alto non saltando più in alto dei suoi concorrenti, ma passando la barra al contrario. Tutti gli altri perfezionavano lo straddle. Forma migliore, più forza, guadagni marginali su una tecnica di decenni. Fosbury cambiò la forma del problema. Entro due Olimpiadi, lo straddle era quasi estinto.

I leader della sicurezza ora devono superare una barra che è appena stata spostata, e la risposta più comune dell’industria finora è uno straddle migliore: più avvisi, analisti più rapidi, SLA più stringenti sulla revisione umana. Questo non funzionerà, perché il vincolo non è la velocità degli analisti. Non si può rispondere a attacchi a velocità di macchina con triage a velocità umana.

Il flop appare così:

• Interrompi il trattamento del confine come controllo. La sandbox di valutazione è fallita, il caricatore di dataset è fallito e l’isolamento del pod è fallito, ognuno di loro ha svolto il proprio compito fino a quando non ha smesso. Progetta per ciò che accade dopo. Usa credenziali a breve durata. Elimina le identità amministrative condivise. Blocca l’accesso ai servizi di metadata. Soprattutto, limita quanto può muoversi un aggressore dopo il primo fallimento del controllo.
• Sposta il rilevamento dall’allerta alla correlazione. Trovare un singolo evento sospetto non è più sufficiente. Il compito è collegare migliaia di eventi apparentemente ordinari in un’unica storia di attacco, e capire quando quella storia è abbastanza grave da svegliare qualcuno. Questo deve sempre più essere automatizzato dato il volume che osserviamo.
• Considera l’esposizione di terze parti come un percorso di attacco, non come un questionario. Questi incidenti hanno attraversato dipendenze di terze parti: il prodotto di un fornitore, il cliente di un fornitore, un partner di valutazione, strumenti di test condivisi. Il tuo rischio ora include errori di configurazione commessi da organizzazioni che non hai mai auditato e potresti nemmeno sapere che esistono. Le valutazioni statiche e puntuali non possono vedere nulla di ciò. Questo problema non è nuovo. L’IA lo rende molto più urgente. I team di sicurezza hanno bisogno di una visione continua delle aziende e delle tecnologie da cui dipendono, perché gli aggressori vedono quell’intero ecosistema come una superficie connessa.

In SecurityScorecard, questo è esattamente il tipo di problema su cui la nostra cultura è costruita: riunire persone estremamente curiose su come pensano gli aggressori, disposte a mettere in discussione assunzioni di vent’anni e entusiaste di costruire un approccio fondamentalmente diverso alla sicurezza!

La domanda da portare al tuo prossimo consiglio di amministrazione

Qualche settimana fa ho detto che il genio è diventato troppo potente per la bottiglia. Quattro laboratori dopo, nulla ha contraddetto questa affermazione. Dopo incidenti come questi, tutti pongono la stessa domanda: Siamo pronti per gli aggressori abilitati dall’IA? Non credo che questa domanda ci porti molto lontano. “Sì” e “no” producono lo stesso risultato: nulla cambia.

Fai una domanda più difficile. Se 17.000 eventi a basso segnale colpiscono il tuo ambiente nei prossimi quattro giorni — e la maggior parte sembrava fallimenti — quanto tempo impiegherebbe il tuo team a capire che erano un attacco? Qualcuno verrebbe allertato in tempo?

Conosci già la risposta. Il divario tra quella risposta e quattro giorni è il lavoro.