Jonathan Zanger, Chief Technology Officer di Check Point – Intervista

Jonathan Zanger, Chief Technology Officer di Check Point, offre una rara combinazione di esperienza di intelligence militare di élite, profonda competenza in materia di intelligenza artificiale e leadership operativa in startup e grandi aziende. Prima del suo attuale incarico, ha ricoperto il ruolo di CTO presso Trigo, dove ha guidato lo sviluppo di sistemi di intelligenza artificiale e visione artificiale di nuova generazione che consentono la vendita senza attrito e la prevenzione delle perdite su larga scala, allineando il prodotto e la R&D con il dispiegamento commerciale nel mondo reale. In precedenza, ha ricoperto ruoli di leadership nella R&D presso Trigo e ha trascorso oltre un decennio nell’unità d’élite israeliana Unit 8200, dirigendo infine una divisione di R&D informatica responsabile di iniziative di intelligence e sicurezza informatica a livello nazionale e guadagnando il massimo riconoscimento nazionale per il suo lavoro.

Check Point Software Technologies (CHKP ) è un leader globale nella sicurezza informatica, che fornisce soluzioni di sicurezza guidate dall’intelligenza artificiale e distribuite nel cloud, progettate per proteggere aziende e governi da minacce digitali sempre più sofisticate. L’azienda serve oltre 100.000 organizzazioni in tutto il mondo con una piattaforma completa che protegge reti, ambienti cloud, endpoint e utenti attraverso un approccio di prevenzione che mira a fermare gli attacchi prima che si verifichino. La sua architettura integrata sfrutta l’intelligenza artificiale e l’intelligence sulle minacce in tempo reale per semplificare le operazioni di sicurezza, ridurre il rischio e consentire alle organizzazioni di crescere in sicurezza man mano che adottano l’intelligenza artificiale, il cloud computing e i sistemi distribuiti.

Ha guidato iniziative di sicurezza informatica e intelligenza artificiale su larga scala, ha costruito sistemi guidati dall’intelligenza artificiale presso Trigo e ora sovrintende alla strategia di intelligenza artificiale presso Check Point. Quali modi di fallimento specifici ha osservato quando i sistemi di intelligenza artificiale passano da ambienti controllati alla produzione, soprattutto quando hanno accesso a strumenti e dati aziendali?

Due cose cambiano fondamentalmente in produzione. In primo luogo, la scala trasforma i casi limite in eventi quotidiani. Un tasso di falsi positivi dello 0,1% sembra eccellente in laboratorio, ma quando si elaborano milioni di interazioni, ciò si traduce in migliaia di incidenti che richiedono attenzione. Gli outlier statistici nei test diventano realtà operative su larga scala.

In secondo luogo, la produzione significa esposizione avversariale. In un ambiente controllato, gli input sono benigni e prevedibili. Nel mondo reale, alcuni utenti e attaccanti proveranno attivamente a ingannare il sistema, sfruttando ogni canale di dati non attendibile disponibile per manipolare il comportamento. Il passaggio dalla demo alla produzione non è un problema di scalabilità. È un passaggio da un ambiente cooperativo a uno conteso, e ciò richiede ipotesi di progettazione fondamentalmente diverse.

Nei sistemi agente, in cui i modelli possono chiamare API, eseguire codice e concatenare azioni, quali sono le superfici di attacco più critiche che i team di sicurezza non strumentalizzano ancora correttamente?

La superficie critica che la maggior parte dei team sottovaluta è il dato stesso. I sistemi agente accedono regolarmente a fonti di dati non attendibili — e-mail in entrata, siti web, biglietti Jira, codice open source, documentazione esterna. Tali dati vengono inglobati e analizzati dai modelli come parte del loro processo di ragionamento.

Ciò crea due rischi concreti. In primo luogo, l’avvelenamento della memoria — dove il contenuto manipolato modella sottilmente le risposte e le decisioni future del modello senza alcun prompt di iniezione evidente. In secondo luogo, l’iniezione di prompt indiretta — dove le istruzioni avversarie vengono incorporate in quei dati esterni ed effettivamente “jailbreak” il modello dall’interno. L’attaccante non tocca mai direttamente il prompt. Semplicemente pianta le istruzioni dove l’agente le troverà.

L’iniezione di prompt è spesso inquadrata come un problema del modello, ma nella pratica diventa un problema a livello di sistema. Come dovrebbero le aziende ridisegnare la loro architettura per isolare gli input del modello, l’esecuzione degli strumenti e l’accesso ai dati sensibili?

L’iniezione di prompt non è un problema universale con una soluzione universale. Se un determinato input è legittimo o avversario dipende interamente dal contesto. Chiedere a un agente di “cambiare la password dell’amministratore” è perfettamente legittimo se si tratta di un agente di help desk tecnico. La stessa richiesta a un chatbot di un rivenditore online è un attacco.

È per questo che l’architettura conta più di qualsiasi tecnica di rilevamento singola. I sistemi necessitano di meccanismi deterministici e non deterministici che lavorano insieme. I controlli deterministici gestiscono l’accesso agli strumenti e ai dati in base all’identità dell’agente, all’identità dell’utente e al ruolo definito del sistema. I controlli non deterministici basati sui modelli aggiungono la capacità di comprendere il linguaggio, il contesto e l’intento. È necessario avere entrambi i livelli — l’applicazione rigida delle politiche e il ragionamento contestuale intelligente — perché nessuno dei due è sufficiente da solo.

Molti agenti di intelligenza artificiale si affidano alla generazione aumentata dal recupero e a fonti di dati esterni. Quali sono i rischi intorno all’avvelenamento dei dati e alla manipolazione del contesto in queste pipeline, e come possono essere mitigati in fase di esecuzione?

I rischi differiscono a seconda della direzione del flusso di dati. Per le fonti di dati interne, il rischio principale è la fuoriuscita di dati sensibili — esposizione di informazioni personali, condivisione di dati tra clienti, informazioni interne rese disponibili a parti non autorizzate. Per le fonti di dati esterni, i rischi includono il pregiudizio del modello a causa di informazioni non verificate, l’iniezione di prompt indiretta incorporata nel contenuto recuperato e la dipendenza da fonti non attendibili o manipolate.

La mitigazione deve avvenire a livello di transazione, in tempo reale. Ogni interazione agente deve essere protetta in entrambe le direzioni: assicurandosi che i dati sensibili non fuoriescano dall’interno verso l’esterno e che le informazioni avvelenate o avversarie non vengano alimentate dall’esterno nel sistema o nel modello. Non è possibile risolvere questo problema solo al momento dell’ingestione dei dati, perché il contesto è dinamico e il panorama delle minacce cambia continuamente.

Il suo Piano di difesa dell’intelligenza artificiale introduce un livello di controllo unificato attraverso l’uso dell’intelligenza artificiale da parte dei dipendenti, le applicazioni e i sistemi agente. Quali sono stati i più grandi sfidi architettonici nel costruire un sistema in grado di osservare e applicare le politiche attraverso un stack di intelligenza artificiale così frammentato?

Crediamo che nel prossimo futuro, i carichi di lavoro agente copriranno endpoint, applicazioni, servizi SaaS e carichi di lavoro cloud — tutti iperconnessi in ciò che chiamiamo “Internet degli agenti”. L’idea alla base del Piano di difesa dell’intelligenza artificiale è quella di scoprire, gestire e proteggere questa infrastruttura agente aziendale in evoluzione all’interno di un unico pannello di vetro.

La sfida architettonica fondamentale è valutare dinamicamente il profilo di rischio e il contesto di ogni agente mentre si sviluppa una protezione in tempo reale efficiente per ogni transazione agente. Ciò significa mantenere alti tassi di blocco contro minacce reali mentre si minimizzano i falsi positivi — alla velocità di produzione e alla scala, in più ambienti in esecuzione. Costruire un sistema in grado di osservare e applicare le politiche in modo coerente attraverso un stack di intelligenza artificiale così frammentato e in rapida evoluzione ha richiesto di ripensare come astraiamo e valutiamo l’attività dell’intelligenza artificiale a livello fondamentale.

La piattaforma enfatizza la presa di decisioni in tempo reale alla velocità della macchina su più lingue e flussi di lavoro. Come si bilancia la limitazione della latenza con la necessità di un’ispezione e controllo approfonditi delle azioni guidate dall’intelligenza artificiale negli ambienti di produzione?

Sviluppiamo e addestriamo modelli fondamentali specificamente per la prevenzione delle minacce, quindi utilizziamo tecniche di distillazione per renderli estremamente efficienti. Ciò ci consente di eseguire l’inferenza velocemente e con minimo calcolo — anche su CPU o GPU commodity — mantenendo la copertura multilingue e multimodale, inclusa l’analisi di immagini e audio, con massima accuratezza.

Questo approccio ci consente di ispezionare le transazioni agente in modo approfondito senza diventare un collo di bottiglia. La sicurezza che introduce ritardi inaccettabili verrà bypassata. La sicurezza che è invisibile al flusso di lavoro ma applica controlli significativi è quella che viene effettivamente distribuita e rimane distribuita.

Gli agenti di intelligenza artificiale operano sempre più con autorizzazioni delegate in più sistemi. Come dovrebbero le organizzazioni ripensare la gestione delle identità e degli accessi per attori non umani, soprattutto quando gli agenti espandono dinamicamente la loro portata attraverso l’uso degli strumenti?

L’errore che la maggior parte delle organizzazioni commette è trattare gli agenti di intelligenza artificiale come estensioni degli utenti umani o come account di servizio tradizionali. Nessuno dei due modelli si adatta. Pensateli come dipendenti digitali — entità con ruoli, responsabilità e confini definiti.

L’identità dell’agente dovrebbe essere definita da tre dimensioni: il flusso di lavoro specifico che l’agente sta eseguendo, l’utente che possiede o ha creato l’agente e l’utente che attualmente interagisce con esso. Tutti e tre i fattori plasmano ciò che l’agente dovrebbe essere autorizzato a fare. Oltre a ciò, le organizzazioni devono applicare i principi di zero trust agli agenti — non assumere mai la fiducia in base all’origine, verificare continuamente il comportamento e applicare l’accesso con il privilegio minimo a ogni passaggio. Senza questo, gli agenti accumuleranno silenziosamente più autorità di quanto chiunque avesse inteso.

La maggior parte delle aziende ha ora un uso di intelligenza artificiale ombra attraverso copiloti, plugin e script interni. Quali telemetrie dovrebbero raccogliere i team di sicurezza per ottenere una visibilità reale su come l’intelligenza artificiale interagisce con i dati sensibili?

La visibilità deve funzionare a livello di transazione agente — non solo prompt e risposte, ma chiamate di strumenti, i dati restituiti da quegli strumenti e le azioni intraprese in conseguenza. I team di sicurezza devono vedere l’intera catena: cosa è stato chiesto, quali dati sono stati acceduti, quali strumenti sono stati invocati, quali parametri sono stati passati e cosa è successo dopo.

Senza questa telemetria a livello di transazione, non è possibile rispondere a domande fondamentali su esposizione, abuso o impatto. L’intelligenza artificiale ombra non è pericolosa perché esiste. È pericolosa perché opera senza questo livello di governance o insight.

La red teaming dei sistemi agente è fondamentalmente diversa dal test delle applicazioni statiche. Come si simula il comportamento avversario attraverso flussi di lavoro multi-step, e quali tipi di sfruttamento sono più comunemente scoperti?

Operiamo Gandalf (https://gandalf.lakera.ai), che è l’esercizio di red teaming di intelligenza artificiale più grande al mondo. È una piattaforma crowd-sourced in cui gli utenti reali tentano di persuadere gli agenti di intelligenza artificiale a violare le loro barriere di protezione. Ciò ci fornisce un set di dati unico e in continua crescita di tecniche avversarie reali — non attacchi teorici, ma le strategie che le persone reali utilizzano per manipolare i sistemi di intelligenza artificiale.

Sfruttiamo quel set di dati per guidare le nostre capacità di red teaming. Gli attacchi che vediamo più spesso coinvolgono utenti che gradualmente persuadono gli agenti a violare i loro vincoli — attraverso l’iniezione di prompt indiretta, la riformulazione creativa, la manipolazione del contesto e lo sfruttamento dell’incremento della fiducia attraverso interazioni multi-step. Questi problemi sono invisibili se si testano solo prompt individuali. È necessario testare sequenze e campagne avversarie sostenute.

Man mano che gli attaccanti iniziano a utilizzare agenti autonomi per sondare i sistemi in modo continuo, ci si aspetta che la difesa si sposti verso controlli adattivi in tempo reale guidati dall’intelligenza artificiale, e quale è l’architettura di questo in pratica?

Sì. Le difese statiche non possono tenere il passo con gli attaccanti autonomi che operano in modo continuo. La difesa deve diventare adattiva, guidata in tempo reale e automatizzata. Ciò significa monitoraggio in tempo reale del comportamento dell’intelligenza artificiale, valutazione continua del rischio e applicazione immediata quando le politiche vengono violate. La velocità e la scala degli attacchi guidati dall’intelligenza artificiale saranno contrastate solo da difese alla velocità della macchina.

In pratica, la sicurezza diventa un ciclo di feedback piuttosto che un set di regole. I sistemi di intelligenza artificiale sono osservati, valutati e vincolati dinamicamente, alla stessa velocità e scala in cui operano. Questo passaggio è essenziale se le organizzazioni desiderano distribuire l’intelligenza artificiale in modo sicuro su larga scala.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Check Point Software Technologies.