I programmi di intelligenza artificiale dannosi stanno imponendo l'estensione del principio Zero Trust al codice.
Scopri come i malware basati sull'intelligenza artificiale minacciano la sicurezza informatica e perché il principio Zero Trust dovrebbe essere applicato al codice per proteggere i tuoi sistemi.
Le cose più importanti che devi sapere
- La velocità con cui l'intelligenza artificiale genera e modifica codice dannoso sconvolge i tradizionali controlli di sicurezza basati sulla revisione umana e sulle firme, rendendo necessari nuovi modelli di governance.
- I controlli di sicurezza tradizionali, incentrati sul codice sorgente o sul rilevamento post-esecuzione, non sono più sufficienti; dobbiamo invece passare alla valutazione del comportamento previsto del codice rispetto alle policy *prima* di consentirne l'esecuzione.
- L'applicazione del principio "zero trust in code" richiede la valutazione del comportamento di qualsiasi programma rispetto alle politiche stabilite *prima* della sua esecuzione, indipendentemente dalla sua origine o dai precedenti indicatori di affidabilità, identificando al contempo tutti i punti di ingresso del codice.
La sicurezza del software è sempre stata incentrata sullo sviluppo umano. Un tempo erano gli esseri umani a scrivere, revisionare e pubblicare il codice. Ora, le macchine si stanno assumendo questi compiti.

In un recente studio, Anthropic ha riferito che oltre l'80% del codice incorporato nel suo database di produttività è stato creato dal suo modello di intelligenza artificiale , Claude.
Le stesse capacità che aumentano la produttività degli sviluppatori stanno cambiando l'economia degli attacchi informatici.
Mentre gli avversari sono ancora impegnati a identificare il bersaglio, le macchine possono generare payload dannosi, testare varianti, adattare il codice a diversi ambienti e ripetere il processo a una velocità che i software di sicurezza non riescono a tenere il passo.
La velocità ha la precedenza sui dispositivi di sicurezza.
La maggior parte dei flussi di lavoro per la sicurezza del software aziendale prevede un periodo di revisione. Il codice viene scritto, controllato, testato, approvato e distribuito. Se in seguito si verifica qualcosa di sospetto, i team di sicurezza indagano e intervengono.
Questo modello fallisce quando il programma passa dalla semplice guida all'esecuzione nel giro di pochi minuti.
Il codice generato dall'IA può essere trasformato in script, dipendenze, attività di automazione o modifiche all'infrastruttura quasi istantaneamente. Nel frattempo, gli agenti di sviluppo possono modificare file, risolvere pacchetti ed eseguire comandi.
I revisori umani non fanno più parte del processo.
Gli aggressori possono utilizzare gli stessi meccanismi per generare vulnerabilità, testare tecniche di elusione e modificare il comportamento dei payload dannosi per diversi obiettivi. Ciò crea una maggiore versatilità con un minor numero di indicatori stabili che i difensori possono identificare.
Sebbene l'analisi basata sull'intelligenza artificiale possa migliorare lo screening, spesso produce probabilità, non politiche. E alla velocità delle macchine, "probabilmente sospetto" non è sufficiente. Pertanto, la necessità di regole e framework di governance per l'IA sta diventando sempre più urgente.
Le macchine stanno cambiando il modello di attacco.
Gli aggressori umani non scompariranno, ma una parte maggiore della catena di attacco è ora condotta dalle macchine.
L'intelligenza artificiale può automatizzare la ricognizione, accelerare la scoperta delle vulnerabilità, generare codice exploit, riscrivere payload dannosi e adattare le sequenze di comandi all'ambiente di destinazione. Tuttavia, la maggior parte delle misure difensive è progettata tenendo conto dei limiti umani: infrastrutture riutilizzate, scorciatoie e schemi tracciabili. Questi non si applicano agli attacchi automatizzati.
Il payload dannoso generato dalla macchina potrebbe non corrispondere a una firma nota o non avere una reputazione consolidata. Potrebbe essere creato, utilizzato brevemente e poi eliminato. Ma il malware basato sull'intelligenza artificiale deve interagire con l'ambiente di destinazione per raggiungere il suo obiettivo. Il suo comportamento non può nascondere le sue intenzioni; deve accedere alle risorse e modificare l'ambiente in modo da favorire l'attacco.
Ciò che un codice dannoso può fare è creare il segnale di sicurezza più duraturo.
La sicurezza deve porre una domanda diversa.
La sicurezza della catena di fornitura del software è migliorata, ma in molti casi si limita ancora a verificare le caratteristiche di impatto prima dell'esecuzione, anziché controllare l'esecuzione stessa.
Gli elenchi dei componenti software (SBOM), le firme e il codice sorgente offrono ai team di sicurezza maggiore fiducia nella composizione, nell'origine e nella data di compilazione del codice. Tuttavia, conoscere il codice sorgente non rivela cosa farà il programma una volta eseguito.
Un programma può superare tutti questi controlli e comunque creare rischi. Persino l'impatto di un processo di compilazione legittimo potrebbe violare le policy durante l'esecuzione, mentre uno script generato dall'IA potrebbe completare il suo compito previsto in un modo che compromette dati o sistemi. Di conseguenza, un elenco di dipendenze pulito non è garanzia di un comportamento sicuro, il che sottolinea l'importanza di non compromettere gli standard di programmazione, nemmeno con gli strumenti di IA.
La divulgazione delle informazioni dopo l'attuazione arriva troppo tardi.
Il rilevamento e la risposta rimangono necessari, ma intervengono dopo che la minaccia si è già infiltrata nell'ambiente. Quando un comportamento sospetto diventa visibile, il malware potrebbe aver già avuto accesso a informazioni riservate, alterato lo stato del sistema, aperto connessioni di rete o stabilito punti di continuità.
L'intelligenza artificiale riduce significativamente questo lasso di tempo. Il codice può essere creato, modificato e distribuito molto più velocemente di quanto gli esseri umani possano esaminarlo. Attendere che emergano prove successive all'esecuzione offre agli aggressori un ampio margine di manovra.
Dobbiamo anticipare il processo decisionale a una fase precedente. Invece di chiederci: "Possiamo contenere questo software se si comporta in modo anomalo?", la domanda dovrebbe essere: "Dovrebbe essere consentito che questo comportamento si verifichi fin dall'inizio?".
Ciò non significa sostituire i controlli esistenti, bensì spostare la posizione del varco di sicurezza critico.
Nessuna fiducia nelle istruzioni di programmazione
Il principio Zero Trust ha trasformato la sicurezza organizzativa, rifiutando la fiducia implicita. Utenti, dispositivi, sessioni e richieste di accesso non vengono considerati affidabili solo perché sembrano familiari; devono essere tutti verificati in base alle policy stabilite.
L'implementazione del software richiede lo stesso livello di verifica.
Non ci si può fidare di un codice solo perché proviene da un repository noto, è firmato da un editore riconosciuto, ha superato una pipeline di compilazione o non ha precedentemente mostrato comportamenti dannosi. Questi sono indicatori utili, ma non conclusivi.
Il principio Zero Trust for Code affronta questo problema. Prima dell'esecuzione di qualsiasi programma, il suo comportamento previsto deve essere valutato in base alle policy. Se il comportamento è accettabile, l'esecuzione può continuare. In caso contrario, l'elemento deve essere bloccato, limitato, messo in quarantena o sottoposto a revisione. Questa esigenza evidenzia l'importanza di stabilire regole e framework chiari per l'intelligenza artificiale che vadano oltre le semplici policy.
Le organizzazioni possono iniziare definendo ogni percorso attraverso il quale il codice entra nell'ambiente o viene eseguito con privilegi significativi. Ciò include canali di sviluppo formali come repository, pacchetti open source, container e pipeline di integrazione continua/distribuzione continua (CI/CD), nonché allegati e-mail, file scaricati, macro, estensioni del browser, programmi di installazione per endpoint, integrazioni di terze parti e script iniettati tramite strumenti di intelligenza artificiale o automazione.
Successivamente, è fondamentale identificare dove questi percorsi si basano su una fiducia preesistente. Se l'esecuzione è consentita perché il software proviene da una fonte attendibile, è stato firmato, ha subito un processo di compilazione o non ha precedenti di attività dannose, questo controllo è incompleto. Il comportamento deve comunque essere valutato prima che l'elemento possa essere autorizzato all'esecuzione. Ciò evidenzia anche la vulnerabilità alle vulnerabilità derivanti dalla crescente dipendenza dai fornitori di intelligenza artificiale.
Man mano che l'intelligenza artificiale si assume un ruolo sempre più importante nella creazione di codice, sia legittimo che dannoso, le organizzazioni non possono più dare per scontato che il codice che supera i controlli attuali debba essere eseguito. L'implementazione deve diventare una decisione di sicurezza ben ponderata.
Abbiamo stilato una lista delle migliori suite di sicurezza internet per PC, Mac e dispositivi mobili.
I commenti sono chiusi.