La sicurezza dell’AI non è rotta, stiamo solo difendendo le cose sbagliate

L’industria della sicurezza informatica ha un modello per quando emerge una nuova tecnologia, iniziamo immediatamente a costruire muri attorno ad essa. L’abbiamo fatto con il cloud, l’abbiamo fatto con i container e adesso stiamo facendo lo stesso con l’AI, solo che questa volta i muri che stiamo costruendo sono completamente nel posto sbagliato.

Entra in qualsiasi revisione della sicurezza aziendale oggi e sentirai le stesse priorità: proteggere i modelli di AI, proteggere i dati di formazione, validare le uscite e distribuire copiloti alimentati da AI. I vendor stanno correndo per vendere strumenti di “sicurezza AI” che si concentrano esclusivamente sui controlli a livello di modello, come guardrail, difese contro l’iniezione di prompt e piattaforme di monitoraggio dei modelli.

Ma gli attaccanti stanno utilizzando le tue integrazioni di AI come autostrade per accedere a tutto il resto.

La vera superficie di attacco che nessuno sta guardando

Un modello che osserviamo costantemente attraverso gli ambienti aziendali racconta una storia preoccupante di team di sicurezza che investono molto nella protezione dei loro ambienti di sviluppo di AI: controlli di accesso ai modelli, framework di governance dei dati, strumenti di sicurezza MLOps. Ciò dà una falsa sensazione di sicurezza che il loro AI sia “bloccato”.

Ma quando si mappa la vera superficie di attacco, si vede che gli chatbot di AI spesso detengono token OAuth per decine di piattaforme SaaS, chiavi API con autorizzazioni eccessive nel cloud e relazioni di fiducia dell’identità che possono creare percorsi diretti da una semplice iniezione di prompt all’infrastruttura di produzione. I modelli stessi possono essere sicuri, ma gli ecosistemi in cui vivono sono spesso completamente aperti e non si tratta di un caso limite.

Le aziende utilizzano ora una media di 130+ applicazioni SaaS, con integrazioni di AI che coprono provider di identità, infrastrutture cloud, database e sistemi business-critici. Ogni integrazione è un potenziale percorso di attacco e ogni connessione API è un confine di fiducia che gli attaccanti stanno attivamente sondando.

Il problema non è che i nostri strumenti di sicurezza AI siano rotti. È che stiamo proteggendo componenti individuali mentre gli attaccanti sfruttano le connessioni tra di essi.

Perché la sicurezza centrata sui modelli non funziona

L’approccio attuale alla sicurezza AI si basa su un fondamentale malinteso di come funzionano gli attacchi moderni. Trattiamo l’AI come un asset autonomo che necessita di protezione, simile a come potremmo proteggere un database o un’applicazione web. Ma l’AI in produzione non esiste in isolamento. È un nodo in un grafico complesso di identità, autorizzazioni, API e flussi di dati.

Considera un tipico deployment di AI aziendale. Hai un agente di AI con accesso al tuo Google Workspace. È connesso a Salesforce attraverso API. È integrato con Slack per le notifiche. Estrae dati da bucket AWS S3. È autenticato attraverso Okta o Azure AD. Attiva workflow in ServiceNow.

La sicurezza tradizionale dell’AI si concentra sul modello stesso: la sua postura di sicurezza, la convalida dei prompt, la sicurezza delle uscite. Ma gli attaccanti si concentrano sulle integrazioni: cosa possono raggiungere attraverso account di servizio compromessi, dove possono spostarsi attraverso manipolazioni API, quali confini di fiducia possono attraversare attraverso integrazioni sfruttate.

L’attacco non inizia o finisce con il modello di AI. Il modello è solo il punto di ingresso.

I percorsi di attacco non rispettano i confini dei prodotti

Ecco dove la maggior parte delle organizzazioni si blocca. Hanno distribuito strumenti di sicurezza che forniscono visibilità in un singolo dominio. Uno strumento monitora le autorizzazioni cloud. Un altro traccia le configurazioni SaaS. Un terzo gestisce la governance dell’identità. Un quarto gestisce la gestione delle vulnerabilità.

Ogni strumento ti mostra il suo pezzo del puzzle. Nessuno di essi ti mostra come i pezzi si connettono.

Secondo Gartner, le organizzazioni utilizzano ora una media di 45+ strumenti di sicurezza. Eppure, nonostante questo enorme investimento, gli attaccanti stanno catenando insieme misconfigurazioni attraverso questi domini perché nessuno strumento può vedere l’intero percorso di attacco.

Un attaccante non deve trovare una vulnerabilità critica nel tuo modello di AI. Gli basta trovare una catena. Forse è un ruolo IAM mal configurato attaccato al tuo servizio di AI, che ha autorizzazioni per un bucket S3, che contiene credenziali per un’applicazione SaaS che ha accesso amministrativo alla tua infrastruttura di produzione.

Ogni singola misconfigurazione potrebbe avere un punteggio “medio” o “basso” nei tuoi strumenti di sicurezza. Ma catenate insieme? Quella è un’esposizione critica. E è completamente invisibile se stai guardando ogni dominio di sicurezza in isolamento.

L’imperativo della gestione dell’esposizione

È per questo che la conversazione deve spostarsi dalla “sicurezza AI” alla gestione continua dell’esposizione alle minacce per ambienti integrati con AI.

Non è sufficiente chiedersi se i nostri modelli di AI siano sicuri. I team di sicurezza devono capire cosa un attaccante possa effettivamente raggiungere se compromette un account di servizio di AI. Devono avere visibilità su come le misconfigurazioni attraverso cloud, SaaS e sistemi di identità possano essere catenate insieme. Devono sapere come le integrazioni di AI stanno cambiando la loro superficie di attacco in tempo reale. E devono priorizzare i rischi in base all’effettiva possibilità di attacco, non solo ai punteggi di gravità.

La maggior parte dei programmi di sicurezza ancora priorizza i rischi in isolamento, utilizzando punteggi CVSS e checklist di conformità che ignorano completamente se una vulnerabilità è effettivamente sfruttabile nel tuo ambiente specifico.

Questo gap è ancora più pronunciato con i sistemi di AI perché cambiano costantemente. Nuove integrazioni vengono aggiunte settimanalmente. Le autorizzazioni evolvono. Le connessioni API si spostano. La tua superficie di attacco dell’ultimo mese non è la tua superficie di attacco di oggi, ma la tua valutazione di sicurezza probabilmente lo è.

Cosa significa sicurezza consapevole dei percorsi di attacco

Proteggere l’AI in produzione richiede un approccio fondamentalmente diverso e si riduce a quattro cambiamenti chiave nel modo di pensare.

Primo, è necessaria una visibilità unificata attraverso i domini di sicurezza. Smetti di chiedere a ogni strumento di sicurezza di operare nel suo silo. I tuoi strumenti di sicurezza cloud, governance dell’identità, gestione SaaS e scanning delle vulnerabilità detengono tutti pezzi del puzzle del percorso di attacco. Devono condividere dati in tempo reale in modo che tu possa vedere come le misconfigurazioni si catenano insieme.

Secondo, abbraccia la simulazione continua del percorso di attacco. Non aspettare i test di penetrazione o gli esercizi di red team per scoprire percorsi sfruttabili. Testa continuamente come un attaccante potrebbe muoversi attraverso il tuo ambiente, concentrandoti sull’effettiva sfruttabilità piuttosto che affidarti a punteggi di gravità teorici.

Terzo, priorizza in base al contesto. Un bucket S3 mal configurato non è critico solo perché è pubblico. È critico se è pubblico e contiene credenziali e quelle credenziali hanno accesso privilegiato e sono raggiungibili da un asset esposto a internet. Il contesto conta più di qualsiasi punteggio individuale.

Quarto, spostati verso la rimozione preventiva. Quando il tuo team di sicurezza sta indagando su un allarme, hai già perso tempo di risposta prezioso. La difesa moderna richiede la capacità di chiudere percorsi sfruttabili prima che vengano utilizzati, non dopo un incidente.

L’avvertimento che non possiamo ignorare

Man mano che l’AI si integra in ogni livello dello stack aziendale, la superficie di attacco si sta espandendo più velocemente di quanto i team di sicurezza possano ragionare manualmente. Stiamo aggiungendo integrazioni di AI al ritmo di 10 volte più veloce di quanto stiamo proteggendole.

Se stai proteggendo l’AI in isolamento, proteggendo il modello mentre ignori l’ecosistema in cui opera, sei già in ritardo. Gli attaccanti non pensano in termini di strumenti, pensano in termini di percorsi. Non sfruttano singole vulnerabilità. Catena insieme misconfigurazioni attraverso tutto il tuo ambiente.

Le aziende che avranno successo nel proteggere l’AI non saranno quelle con il maggior numero di strumenti di sicurezza AI. Saranno quelle che capiscono che la sicurezza dell’AI è inscindibile dalla gestione dell’esposizione su tutta la loro superficie di attacco.

La sicurezza del modello è un requisito minimo. Ciò che conta è capire cosa un attaccante possa raggiungere quando compromette un’integrazione di AI. Fino a quando i team di sicurezza non potranno rispondere a questa domanda continuamente, in tempo reale, su tutto il loro ambiente, non stanno proteggendo l’AI. Stanno solo sperando che i muri che hanno costruito siano nel posto giusto.