La sicurezza dell'intelligenza artificiale non è compromessa, stiamo solo difendendo le cose sbagliate

Nel settore della sicurezza informatica, quando emerge una nuova tecnologia, iniziamo immediatamente a costruire barriere attorno ad essa. Lo abbiamo fatto con il cloud, lo abbiamo fatto con i container e ora lo stiamo facendo con l'intelligenza artificiale, solo che questa volta le barriere che stiamo costruendo sono nei posti completamente sbagliati.

Se oggi ti rechi in qualsiasi sede di revisione della sicurezza aziendale, sentirai le stesse priorità: proteggere i modelli di intelligenza artificiale, protezione dei dati di formazione, convalidando gli output e implementando copiloti basati sull'intelligenza artificiale. I fornitori si stanno affrettando a commercializzare strumenti di "sicurezza basata sull'intelligenza artificiale" che si concentrano esclusivamente sui controlli a livello di modello, come guardrail, difese di iniezione rapida e piattaforme di monitoraggio dei modelli.

Ma gli aggressori stanno usando le vostre integrazioni di intelligenza artificiale come autostrade per tutto il resto.

La vera superficie di attacco che nessuno sta guardando

Uno schema che osserviamo costantemente negli ambienti aziendali racconta una storia preoccupante: i team di sicurezza investono massicciamente nella protezione dei loro ambienti di sviluppo dell'intelligenza artificiale: controlli di accesso ai modelli, framework di governance dei dati, strumenti di sicurezza MLOps. Questo crea una falsa fiducia che la loro intelligenza artificiale sia "bloccata".

Ma se si mappa la superficie di attacco effettiva, si nota che i chatbot AI spesso detengono token OAuth per decine di piattaforme SaaS, chiavi API con permessi cloud eccessivi e relazioni di trust di identità che possono creare percorsi diretti da una semplice iniezione immediata all'infrastruttura di produzione. I modelli stessi possono essere sicuri, ma gli ecosistemi in cui vivono sono spesso completamente aperti, e questo non è un caso limite.

Le aziende utilizzano oggi in media oltre 130 applicazioni SaaS, con integrazioni di intelligenza artificiale che abbracciano provider di identità, infrastrutture cloud, database e sistemi business-critical. Ogni integrazione rappresenta un potenziale percorso di attacco e ogni connessione API rappresenta un limite di attendibilità che gli aggressori stanno attivamente sondando.

Il problema non è che i nostri strumenti di sicurezza basati sull'intelligenza artificiale siano difettosi. È che stiamo proteggendo singoli componenti mentre gli aggressori sfruttano le connessioni tra di essi.

Perché la sicurezza incentrata sul modello non coglie il punto

L'attuale approccio alla sicurezza dell'IA si basa su una fondamentale incomprensione del funzionamento degli attacchi moderni. Trattiamo l'IA come una risorsa autonoma che necessita di protezione, in modo simile a come potremmo proteggere un database o un'applicazione web. Ma l'IA in produzione non esiste isolata. È un nodo in un grafo complesso di identità, permessi, API e flussi di dati.

Consideriamo una tipica implementazione di intelligenza artificiale aziendale. Abbiamo un agente di intelligenza artificiale con accesso a Google Workspace. È connesso a Salesforce tramite API. È integrato con Slack per le notifiche. Estrae dati dai bucket AWS S3. È autenticato tramite Okta o Azure AD. Attiva flussi di lavoro in ServiceNow.

La sicurezza dell'IA tradizionale si concentra sul modello in sé: il suo livello di sicurezza, la convalida tempestiva, la sicurezza dell'output. Ma gli aggressori si concentrano sulle integrazioni: cosa possono raggiungere attraverso account di servizio compromessi, dove possono agire tramite manipolazioni delle API, quali limiti di trust possono superare attraverso integrazioni sfruttate.

L'attacco non inizia né finisce con il modello di intelligenza artificiale. Il modello è solo il punto di ingresso.

I percorsi di attacco non rispettano i confini del prodotto

È qui che la maggior parte delle organizzazioni si blocca. Hanno implementato strumenti di sicurezza che forniscono visibilità su un singolo dominio. Uno strumento monitora le autorizzazioni cloud. Un altro tiene traccia delle configurazioni SaaS. Un terzo gestisce la governance delle identità. Un quarto si occupa della gestione delle vulnerabilità.

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

Secondo GartnerLe organizzazioni utilizzano oggi in media oltre 45 strumenti di sicurezza. Eppure, nonostante questo ingente investimento, gli aggressori riescono a concatenare configurazioni errate in tutti questi domini, perché nessun singolo strumento è in grado di visualizzare il percorso completo dell'attacco.

Un aggressore non ha bisogno di trovare una vulnerabilità critica nel tuo modello di intelligenza artificiale. Gli basta trovare una catena. Potrebbe trattarsi di un ruolo IAM configurato in modo errato associato al tuo servizio di intelligenza artificiale, che dispone delle autorizzazioni per un bucket S3, che contiene le credenziali di un'applicazione SaaS con accesso amministrativo al tuo ambiente di produzione.

Ogni singola configurazione errata potrebbe avere un punteggio "medio" o "basso" nei tuoi strumenti di sicurezza. Ma se fossero concatenate? Sarebbe un'esposizione critica. Ed è completamente invisibile se si analizzano singolarmente ogni dominio di sicurezza.

L'imperativo della gestione dell'esposizione

Ecco perché il dibattito deve spostarsi dalla "sicurezza dell'IA" alla gestione continua dell'esposizione alle minacce per gli ambienti integrati con l'IA.

Non basta chiedersi se i nostri modelli di intelligenza artificiale siano sicuri. I team di sicurezza devono capire cosa può effettivamente raggiungere un aggressore compromettendo un account di un servizio di intelligenza artificiale. Devono avere visibilità su come configurazioni errate nei sistemi cloud, SaaS e di identità potrebbero essere concatenate. Devono sapere come le integrazioni di intelligenza artificiale stanno modificando la loro superficie di attacco in tempo reale. E devono dare priorità ai rischi in base all'effettiva attaccabilità, non solo ai punteggi di gravità.

La maggior parte dei programmi di sicurezza continua a dare priorità ai rischi in modo isolato, utilizzando punteggi CVSS e checklist di conformità che ignorano completamente se una vulnerabilità sia effettivamente sfruttabile nell'ambiente specifico.

Questo divario è ancora più pronunciato con i sistemi di intelligenza artificiale, perché cambiano costantemente. Nuove integrazioni vengono aggiunte settimanalmente. I permessi si evolvono. Le connessioni API cambiano. La superficie di attacco del mese scorso non è la superficie di attacco di oggi, ma la valutazione della sicurezza probabilmente sì.

Come si presenta realmente la sicurezza basata sul percorso di attacco

Per garantire l'uso dell'intelligenza artificiale nella produzione è necessario un approccio fondamentalmente diverso, che si riduce a quattro cambiamenti fondamentali nel modo di pensare.

Innanzitutto, è necessaria una visibilità unificata su tutti i domini di sicurezza. Smettete di chiedere a ogni strumento di sicurezza di operare in un proprio silos. Gli strumenti di sicurezza cloud, di governance delle identità, di gestione SaaS e di scansione delle vulnerabilità contengono tutti pezzi del puzzle del percorso di attacco. Devono condividere i dati in tempo reale in modo da poter vedere come si concatenano le configurazioni errate.

In secondo luogo, adotta la simulazione continua dei percorsi di attacco. Non aspettare test di penetrazione o esercitazioni di red team per scoprire percorsi sfruttabili. Testa continuamente come un aggressore potrebbe muoversi nel tuo ambiente, concentrandoti sulla reale sfruttabilità piuttosto che basarti su punteggi di gravità teorici.

Terzo, stabilisci le priorità in base al contesto. Un bucket S3 non configurato correttamente non è critico solo perché è pubblico. È critico se è pubblico e contiene credenziali, che hanno accesso privilegiato e sono raggiungibili da una risorsa esposta a Internet. Il contesto è più importante di qualsiasi punteggio individuale.

In quarto luogo, puntate alla correzione preventiva. Quando il vostro team SOC sta indagando su un allarme, avete già perso tempo prezioso di risposta. La difesa moderna richiede la capacità di bloccare i percorsi sfruttabili prima che vengano sfruttati, non dopo un incidente.

L'avvertimento che non possiamo ignorare

Con l'integrazione dell'intelligenza artificiale in ogni livello dello stack aziendale, la superficie di attacco si espande più rapidamente di quanto i team di sicurezza possano valutare manualmente. Stiamo aggiungendo integrazioni di intelligenza artificiale a una velocità 10 volte superiore a quella con cui le proteggiamo.

Se si protegge l'IA in modo isolato, proteggendo il modello ignorando l'ecosistema in cui opera, si è già in ritardo. Gli aggressori non pensano in termini di strumenti, ma in termini di percorsi. Non sfruttano singole vulnerabilità. Concatenano configurazioni errate nell'intero ambiente.

Le aziende che riusciranno a proteggere con successo l'IA non saranno quelle dotate del maggior numero di strumenti di sicurezza per l'IA. Saranno quelle che capiranno che la sicurezza dell'IA è inscindibile dalla gestione dell'esposizione su tutta la loro superficie di attacco.

La sicurezza del modello è una questione fondamentale. Ciò che conta è capire cosa può raggiungere un aggressore quando compromette un'integrazione di intelligenza artificiale. Finché i team di sicurezza non saranno in grado di rispondere a questa domanda in modo continuo, in tempo reale, in tutto il loro ambiente, non proteggeranno l'intelligenza artificiale. Spereranno solo che i muri che hanno costruito siano nei punti giusti.