L’impatto diretto della “tokenomics” sui processi di cybersecurity

Di recente abbiamo pubblicato un post sugli attacchi “tokenomics” e “denial of wallet”: un nuovo tipo di attacco DDoS volto a spendere troppo i token IA. Ma prima che gli specialisti della sicurezza inizino a proteggere i processi di IA dei colleghi da questa nuova minaccia, dovrebbero ricordare che il lavoro stesso del dipartimento di sicurezza delle informazioni può diventare un bersaglio per un simile autore dell’attacco. Poiché i team di sicurezza stanno ora testando e implementando attivamente vari tipi di automazione basata sull’IA, la minaccia di interferenza esterna volta a paralizzare il sistema di difesa colpisce direttamente i propri processi e le tecnologie.

Elastic ha stimato che, a seconda dell’architettura “SOC basato su agente”, il triage di un singolo avviso da un host può costare 0,69 dollari per un insieme di agenti altamente specializzati o 3,42 dollari per un agente generico con 14 diverse competenze.

Tuttavia, queste medie nascondono un’ampia gamma di variazioni. In qualsiasi momento, l’elaborazione di base di un semplice avviso (ad esempio, un migliaio di token) può trasformarsi in un’indagine a catena che implica l’elaborazione di milioni di voci di registro, chiamate API e altri dati correlati, il che equivale a milioni di token in una questione di minuti.

Lo stesso Elastic riconosce di utilizzare il modello Claude Sonnet 4.6 nel proprio SOC. Questo solleva immediatamente la domanda: cosa succede quando il budget si esaurisce o vengono attivati i filtri di sicurezza del modello? Nello scenario peggiore, si verifica quanto segue: il SOC IA avvia un'”orchestra di agenti” per indagare su eventi sospetti simili a movimenti laterali nell’infrastruttura. L’agente chiama l’API di Anthropic, ma il budget mensile del dipartimento è stato esaurito e l’API restituisce gli errori. L’indagine si blocca e le persone lo scoprono mezza giornata dopo. Inoltre, se i “filtri di sicurezza” in continua evoluzione di uno dei principali provider di IA segnalano le richieste del SOC come dannose, lo stesso effetto è possibile anche senza esaurire il budget, come dimostrato dall’esperienza di Hugging Face nell’indagine sulla violazione della propria infrastruttura da parte di OpenAI.

Naturalmente, un autore dell’attacco ha interesse a un risultato del genere. Possono influenzare direttamente i costi dei difensori iniettando prompt dannosi nei dati a loro disposizione (record DNS TXT, intestazioni HTTP, commenti sul codice, nomi file e così via), contando sul fatto che tali prompt verranno elaborati dai sistemi di sicurezza delle informazioni. Ad esempio, nel caso di attacco GhostJacking, i registri WAF fungono da vettore per l’iniezione di prompt e in uno studio accademico è stato proposto un altro metodo: i ricercatori sono riusciti ad attaccare i guardrail di sicurezza LLM stessi, facendo sì che le richieste aumentino la latenza di 148 e il numero di token utilizzati di 63. In altre parole, il sistema teoricamente continua a funzionare correttamente, ma la latenza nell’elaborazione degli avvisi e i costi associati aumentano in modo significativo.

Errore automatico pericoloso

Negli scenari basati su agenti, l’esaurimento del budget non si manifesta come un errore esplicito con un messaggio “limite richiesta superato” e un avviso immediato per le parti responsabili. In determinate configurazioni possono verificarsi scenari di “guerriglia”: una richiesta al modello scade, il sistema passa automaticamente a un modello più economico e, di conseguenza, la qualità dei relativi output diminuisce e l’esecuzione di agenti secondari e attività periodiche smette di funzionare. Nel frattempo, il team di sicurezza potrebbe continuare a credere per ore che tutto funzioni come prima.

Come controllare i costi dell’IA nella cybersecurity

Il compito di gestire le spese, ovviamente, non è semplicemente una questione di “prevenzione di spese eccessive”. Il settore è già caduto in questa trappola durante l’implementazione SIEM: quando le aziende hanno dovuto pagare in base al volume dei dati di telemetria raccolti, hanno iniziato a limitare in modo selettivo, e non sempre efficace, la raccolta dei registri. Di conseguenza, si sono ritrovati con il rilevamento di punti ciechi. La stessa situazione potrebbe verificarsi con i token, ma più velocemente e su scala più ampia. Un criterio di taglio dei costi mal progettato potrebbe compromettere l’approfondimento delle indagini e la qualità delle risposte. E in assenza di tale criterio, la decisione di tagliare qualcosa non verrà presa dall’architetto o dal CISO durante la fase di progettazione del sistema, ma dall’analista di turno alle 3 di notte. In alternativa, potrebbe trattarsi di un limitatore automatico impostato dal fornitore del sistema.

Alcuni semplici principi possono aiutare a evitare sforamenti dei costi prevedibili e gestire al meglio le situazioni veramente imprevedibili.

Non immettere nel modello di intelligenza artificiale elementi che possono essere verificati con una query standard. Tutto ciò che è ripetitivo e noto in anticipo dovrebbe essere gestito alla vecchia maniera, con regole e query di dati. Questi possono essere sviluppati utilizzando l’IA, ma devono operare in modo deterministico. Il modello deve essere utilizzato solo quando è veramente necessaria la valutazione di una situazione ambigua.

Utilizzare limiti rigorosi e avvisare in modo aggressivo gli utenti quando vengono superati. I limiti devono essere combinati: un limite per attività, un limite giornaliero e così via. Gli avvisi di superamento dei limiti devono raggiungere immediatamente sia gli analisti in servizio che i responsabili del sistema nel suo insieme.

Decidere in anticipo cosa succede quando viene raggiunto un limite. Se fermarsi e risparmiare, perdendo un po’ il controllo, o continuare e pagare, è una decisione che deve essere presa prima che si verifichi un incidente.

Limitare le autorizzazioni degli agenti e il set di strumenti a loro disposizione. Meno azioni ha accesso il sistema, più efficacemente lavora su un’attività ristretta, minori sono le opportunità che ha di gonfiare i costi e meno è probabile che venga “sfruttato” da un estraneo.

Eseguire la scansione rigorosa dei dati esterni non attendibili. Richieste, messaggi e commenti in entrata, nonché vari campi tecnici in grado di contenere testo arbitrario (record DNS, intestazioni HTTP, nomi di file) possono non solo causare prompt injection, ma anche gonfiare deliberatamente il carico di lavoro. Limitarne le dimensioni e monitorare il carico che generano.

Per evitare interruzioni del servizio da parte di provider esterni e mantenere il controllo completo sui dati dell’organizzazione, valutare la possibilità di utilizzare modelli locali distribuiti in locale almeno per esigenze di sicurezza delle informazioni. Sebbene questi modelli potrebbero non essere all’avanguardia, la loro ristretta specializzazione e l’ottimizzazione con i dati dell’azienda forniranno prestazioni decenti senza errori imprevisti.

In un’architettura più complessa, l’utilizzo degli LLM può essere suddiviso in diversi livelli di criticità. La prima linea di difesa (routing, filtro del rumore, arricchimento dei dati) è gestita da modelli on-premises compatti. Questo riduce significativamente la volatilità del budget. Il secondo livello è costituito da un grande modello locale che gestisce il lavoro di merito: collegare gli eventi, testare ipotesi e ricostruire un quadro coerente di un incidente. Inoltre, non viene fatturato in base alla richiesta, ma il relativo throughput è limitato; pertanto, anziché superare il budget, potrebbero verificarsi sovraccarichi e code di eventi. Solo i casi isolati e veramente difficili vengono inoltrati a modelli avanzati basati sul cloud, preferibilmente con l’approvazione esplicita di un analista umano. In questo schema i costi variabili permangono, ma sono limitati a un ristretto numero di casi e ognuno rappresenta una scelta consapevole piuttosto che l’effetto collaterale di un script eseguito durante la notte.

In sostanza, tutto ciò replica il classico modello SOC a più livelli, in cui la prima riga filtra e la terza riga esamina, solo che i ruoli sono interpretati dai modelli anziché dalle persone.