Tutti stanno imparando la sicurezza AI in tempo reale — anche Google

Di recente ho avuto modo di parlare con Francis de Souza, COO di Google Cloud, dietro le quinte di un evento a Los Angeles. Nonostante il frastuono intorno a noi, de Souza — che ha il tono pacato e riflessivo di un professore — ha condiviso consigli preziosi per le aziende alle prese con questo momento di trasformazione della sicurezza nell’era dell’AI. “Ci sarà un periodo di transizione, poi arriveremo a un punto migliore,” ha osservato. Non stava parlando specificamente di Google, eppure è evidente che persino Google è ancora in fase di assestamento.

La sicurezza non è un’aggiunta: parte dalla piattaforma

Il punto centrale di de Souza è un mantra che i professionisti della sicurezza ripetono da anni e che l’AI ha reso improrogabile: la sicurezza non può essere un ripensamento. “Quando le aziende intraprendono il percorso sull’AI, devono adottare un approccio di piattaforma,” ha detto. “La sicurezza non è qualcosa che si aggiunge dopo, né qualcosa da demandare ai singoli dipendenti.” Ha messo in guardia in particolare sul fenomeno della “shadow AI” — dipendenti che usano strumenti consumer senza controllo organizzativo — sostenendo che fin dall’inizio le piattaforme adottate debbano garantire sicurezza, governance e tracciabilità. “Non esiste una strategia AI senza una strategia dei dati e una strategia di sicurezza: devono procedere insieme.”

Da notare: non stava facendo soltanto un pitch per Google Cloud. Quando gli ho fatto notare che i suoi consigli suonavano come una pubblicità per Google, ha ribattuto. Google, ha detto, è impegnata in un approccio multicloud, e ha argomentato che molte aziende convinte di lavorare su un’unica nuvola in realtà non lo fanno. “Anche scegliendo un solo cloud, si finisce per dipendere da applicazioni SaaS e da partner che magari usano altri cloud,” ha spiegato. “È fondamentale mantenere una postura di sicurezza coerente tra cloud diversi e tra modelli diversi.”

Un panorama delle minacce radicalmente diverso

Secondo de Souza, lo scenario delle minacce è cambiato al punto da rendere inadeguati i vecchi modelli difensivi, troppo lenti per gli attacchi odierni. Il tempo medio tra una violazione iniziale e il passaggio alla fase successiva di un attacco, ha notato, è sceso da otto ore a 22 secondi. E la superficie d’attacco si è estesa ben oltre il perimetro di rete tradizionale. “Oltre al vostro perimetro abituale, oggi ci sono i modelli. Ci sono le pipeline di dati con cui si addestrano i modelli. Ci sono gli agenti, ci sono i prompt. Tutto questo va protetto.”

Una minaccia poco discussa che de Souza ha evidenziato: gli agenti che attraversano i sistemi interni di un’azienda possono riportare alla luce depositi di dati dimenticati da anni. “Molte organizzazioni hanno vecchi server SharePoint [con controlli di accesso] mai aggiornati; finora non era un problema perché nessuno sapeva nemmeno dove fossero. Ma agenti che scorrono l’impresa li troveranno e potrebbero esporre quei dati.”

Difendere alla velocità delle macchine

La risposta, secondo lui, è affrontare la velocità delle macchine con la velocità delle macchine. “Sta emergendo una difesa nativa per l’AI, pienamente agentica, in cui le organizzazioni fanno girare agenti che gestiscono la sicurezza,” ha spiegato. “Invece di una difesa guidata dall’uomo o ‘human-in-the-loop’, si può passare a un modello con gli umani che supervisionano una difesa completamente agentica.” Questo però non è solo un tema tecnologico: “È un tema da consiglio di amministrazione e da comitato esecutivo, non solo da team di sicurezza.”

Competenze scarse e vulnerabilità in aumento

Anche se l’AI può prendersi una fetta crescente del lavoro difensivo, chi è in grado di supervisionarla resta merce rara — mentre le vulnerabilità introdotte dall’AI stessa crescono più in fretta della capacità dei team di sicurezza di gestirle. “Avremo bisogno di persone per affrontare la ‘bug-pocalypse’,” ha detto al New York Times Lea Kissner, CISO di LinkedIn, aggiungendo che non si aspetta che il settore maturi una comprensione davvero solida della sicurezza dell’AI per almeno alcuni anni.

Quando la piattaforma è parte del problema

E qui torniamo ai fornitori di piattaforme. Nelle ultime settimane The Register ha pubblicato una serie di inchieste su sviluppatori Google Cloud che si sono visti recapitare bollette a cinque cifre in seguito a chiamate API non autorizzate ai modelli Gemini — servizi che molti di loro non avevano mai usato o attivato consapevolmente. Lo schema era ricorrente: chiavi API originariamente create per Google Maps e rese pubbliche secondo le linee guida di Google avevano acquisito la capacità di accedere a Gemini dopo che Google ne aveva ampliato lo scope, senza comunicarlo in modo chiaro.

• Rod Danan, CEO della piattaforma di preparazione ai colloqui Prentus, si è visto addebitare 10.138 dollari in circa 30 minuti dopo che gli aggressori hanno sfruttato la sua chiave API compromessa.
• Isuru Fonseka, sviluppatore di Sydney con un account violato in modo simile, si è svegliato con addebiti per circa 17.000 dollari australiani, convinto di avere un tetto di spesa di 250 dollari. Nessuno dei due sapeva che i sistemi automatici di Google avevano aggiornato i loro livelli di fatturazione in base alla cronologia dell’account, innalzando i limiti effettivi fino a 100.000 dollari senza consenso esplicito.

Dopo l’uscita del primo articolo, Google ha rimborsato entrambi. Tuttavia, l’azienda ha dichiarato a The Register di non avere intenzione di modificare la politica di upgrade automatico dei tier, sostenendo che la priorità è evitare interruzioni del servizio piuttosto che far rispettare le preferenze di budget impostate dagli utenti.

Revoca delle chiavi: la finestra di vulnerabilità

Nel frattempo, resta un altro nodo: cosa succede quando uno sviluppatore cerca di bloccare tutto. The Register ha riportato questa settimana i risultati della società di sicurezza Aikido, secondo cui anche chi intercetta subito una chiave compromessa e la elimina potrebbe non essere al sicuro. In base alle analisi di Aikido, gli aggressori possono continuare a usare quella chiave fino a 23 minuti dopo, perché la revoca si propaga gradualmente nell’infrastruttura di Google. Il ricercatore Joseph Leon ha raccontato a The Register che, in quella finestra, il tasso di successo è imprevedibile — in alcuni minuti oltre il 90% delle richieste risulta ancora autenticato — e il tempo basta per esfiltrare file e conversazioni cache da Gemini.

Leon ha anche notato che i formati di credenziali più recenti di Google non sembrano avere lo stesso problema: le credenziali delle service account si revocano in circa cinque secondi, e le nuove chiavi per Gemini con prefisso AQ impiegano circa un minuto. “Entrambi operano alla scala di Google,” ha scritto nel paper collegato. “Entrambi suggeriscono che il problema delle API key di Google sia tecnicamente risolvibile.” In altre parole, quei 23 minuti non sembrano un vincolo tecnico insormontabile, ma una questione di priorità.

Un buon consiglio, ma un divario da colmare

I suggerimenti di de Souza sono sensati e andrebbero presi sul serio. Non sbaglia quando afferma che sicurezza, dati e AI devono viaggiare insieme, e che serve una difesa capace di muoversi alla velocità delle minacce. Ma oggi esiste un disallineamento tra ciò che le piattaforme predicano e il ritmo con cui loro stesse si adattano. Vale la pena esserne consapevoli anche di questo.