Cosa devono sapere i responsabili aziendali sulla GenAI

Benvenuti al podcast dell'FS-ISAC, FinCyber Today. Sono Elizabeth Heathfield, responsabile degli affari aziendali all'FS-ISAC. Mentre l'AI generativa si trasforma da approccio innovativo a must economico, le aziende e i team devono imparare a pensare non solo all'AI, ma anche come l'AI. Patrick Sullivan, vicepresidente e CTO di Akamai, è qui con me per parlare di come i team addetti alla sicurezza possono sfruttare la natura deterministica degli strumenti basati sull'AI. Grazie mille per essere qui. È un vero piacere. Sono davvero entusiasta di parlare con te perché so che siamo entrambi appassionati di intelligenza artificiale.

Allora, parliamo di come gestire il rischio non deterministico. Si tratta di definire le regole di base e i principi fondamentali. Che cos'è il non determinismo nei modelli di GenAI? Allora, per dirla in altre parole, prima è importante apparecchiare la tavola. Quindi, se guardiamo ai modelli di AI generativa, di cui siamo tutti così entusiasti, in sostanza, eseguono una serie di complesse moltiplicazioni di matrici e poi cercano di completare la parola successiva con i risultati più probabili, a seconda della modalità con cui li abbiamo configurati, oppure con un'alternativa meno probabile. Ma cosa significa e perché diciamo che il rischio non è deterministico? Se si esegue un comando con una serie di input e il modello è completamente statico, il sistema non cambia, ma, se si esegue lo stesso comando, la volta successiva, si avranno risultati diversi e se lo si esegue di nuovo, si otterranno risultati ancora diversi. Si tratta di qualcosa di diverso da molti dei sistemi da noi tradizionalmente utilizzati. Si tratta quindi di un cambiamento di mentalità che bisogna comprendere appieno. Prendiamo, ad esempio, i test sulla sicurezza: se un payload latente in un attacco di tipo injection non riesce una volta, non significa che il vostro sistema non sia vulnerabile perché la volta successiva in cui lo stesso identico payload colpisce la stessa identica applicazione, l'attacco potrebbe riuscire apportando danni al sistema. Pertanto, penso sia importante comprendere bene tutto ciò, ma, capire questa situazione a livello intellettuale non basta: bisogna metterla in pratica. Quindi, bisogna tenere le dita sulla tastiera e gli occhi fissi sul monitor e osservare il momento in cui un payload latente colpisce un sistema. Se poi si ripete tutto in modo identico, occorre notare il diverso impatto esercitato per capire le implicazioni sul vostro sistema interno e sul livello di sicurezza.

Cosa si dovrebbe pensare riguardo a questo argomento per comprenderlo a fondo, soprattutto a livello aziendale? Penso sia importante sottolineare che non stiamo parlando di chatbot, ma di workflow più complessi, workflow agentici o qualcosa di simile. Quindi, penso che la buona notizia sia: in qualsiasi team addetto alla sicurezza per una qualsiasi delle varie organizzazioni, si cerca sicuramente di sfruttare appieno tutta la vasta offerta disponibile per la formazione. Non solo: ritengo che l'area su cui i responsabili dovrebbero concentrarsi sia fondamentale. Ma come si alza lo standard di riferimento e si garantisce all'intera organizzazione che si occupa di conformità alla sicurezza di prendere consapevolezza della cosa, dagli audit al red team fino ai team AppSec? Alcuni di essi, probabilmente, si annoieranno durante la formazione di base, ma penso sia importante stabilire uno standard di riferimento, magari con un workshop, un seminario o un hackathon sull'AI, in cui è molto facile coinvolgere tutti in modo pratico. Penso che la formazione pratica sia fondamentale. Inoltre, relativamente agli audit, bisogna chiedersi come riuscire a garantire la sicurezza. Se un test ha avuto esito positivo, come lo si può interpretare in un'ottica più ampia? La prossima volta che viene eseguito su un sistema statico, lo stesso test potrebbe avere esito negativo. Proprio così, dobbiamo essere tutti allineati. Bene, abbiamo stabilito di cosa si tratta, quindi, possiamo iniziare a parlare di alcune delle opportunità offerte per il settore finanziario e, in particolare, quali sono quelle offerte da questa nuova caratteristica della GenAI?

Allora, stiamo assistendo a un'adozione della tecnologia dell'AI a ritmi diversi nelle varie organizzazioni. Alcuni responsabili hanno apertamente dichiarato che, anche se fanno parte di un'organizzazione matura, non si può lasciare l'opportunità offerta dall'intelligenza artificiale alle startup e alle società di tecnofinanza più intraprendenti. Anche la nostra azienda deve sfruttare queste opportunità, tenendo sotto controllo i rischi. In questo contesto, le organizzazioni potrebbero implementare innanzitutto alcuni di questi strumenti AI, ad esempio, nei "copiloti" per sviluppatori. Stiamo iniziando a vedere alcuni di questi risultati con un conseguente aumento della produttività per gli sviluppatori. Ho letto uno studio recente, pubblicato la settimana scorsa da uno dei nostri partner di Apiiro, in cui è emerso che, durante lo sviluppo dei copiloti GenAI, il numero di aggiornamenti software aumenta di 4 volte in base alle PR inviate. Inoltre, si potrebbe verificare un aumento medio di 10 volte nei vari strumenti AST che vengono eseguiti. Molti di questi sono duplicati, ma, in generale, la velocità aumenta, quindi sono ideali per le attività aziendali. Tuttavia, se il team addetto alla sicurezza, in particolare, quella delle app, non riesce ad automatizzare le operazioni, l'azienda viene travolta dalla concorrenza. Quindi, si tratta di un'opportunità, come anche la sicurezza. Riceviamo tantissimi avvisi dai nostri straordinari strumenti. Se leggete i rapporti sulle violazioni, vi potrete rendere conto che è accaduto un brutto incidente. Quindi, anche se i nostri strumenti hanno emesso i relativi avvisi, spesso, si è verificato un altro incidente altrove, che, tuttavia, è passato inosservato alle analisi condotte dagli addetti alla sicurezza. Quindi, se la nostra protezione è maggiore, perché magari garantita dall'AI, possiamo eseguire alcune di queste azioni e abbassare la soglia di ciò che viene esaminato più attentamente. Si tratta di un'opportunità anche per noi. Bene, abbiamo parlato di alcune opportunità. Ora, parliamo di alcuni dei rischi.

Quali sono i rischi che le organizzazioni si trovano ad affrontare? Pensiamo alla gestione dei rischi, magari in un modo leggermente diverso rispetto a quanto succedeva prima, ora con la GenAI? Quali sono i rischi correlati? Certo. Allora, se guardiamo al settore AppSec, abbiamo, anzi, io personalmente, ho trascorso forse due decenni ad occuparmi dei rischi relativi alla sicurezza delle applicazioni. Uno dei principali anti-pattern osservati quando ci sono problemi legati all'AppSec riguarda la combinazione di codice o istruzioni con i dati. In questo caso, la situazione si complica: i dati vanno qui, le istruzioni lì e i comandi SQL vengono inseriti nel database, insomma una serie di problemi. Le istruzioni del sistema operativo, quando vengono interpretate, comportano alcuni rischi. Abbiamo notato che, con queste applicazioni GenAI, si mescolano istruzioni e dati in un cocktail potenzialmente pericoloso. Credo che il modello su cui riflettere sia quello della cosiddetta "triade tossica", ad esempio, quando ci sono dati provenienti da fonti esterne, nel sistema vengono inseriti dati relativi all'addestramento o query, oltre ai dati interni che vengono inseriti con la tecnologia RAG o qualche altro tipo di sistema che accede ai dati riservati, di cui oggi dobbiamo preservare la privacy, ossia dobbiamo sapere esattamente chi ha accesso a tali informazioni. Infine, abbiamo il terzo elemento, ovvero un canale di comunicazione. Le API... la connessione diretta è la cosa peggiore, ma anche l'accesso ad altri elementi come l'e-mail o i moduli di controllo dei software, un repository pubblico o Slack, insomma uno qualsiasi di questi strumenti. Se combiniamo questi tre elementi nella cosiddetta "triade tossica", ci assumiamo, probabilmente, un qualche tipo di rischio. Pertanto, abbiamo bisogno di contromisure estremamente valide. Quindi, se riusciamo a limitarci magari a due di questi elementi, forse avremo più possibilità di implementarli tutti e tre.

Parlando specificamente degli strumenti di cui le aziende si avvalgono, che sono basati sui modelli di settore, è come se fosse lì che avviene tutto il processo di combinazione? Sì, forse. Ritengo che i modelli di settore ci forniranno questi dati esterni, che, tuttavia, risultando fin da subito disponibili, potrebbero essere manipolati dai criminali, i quali rendendosi conto di poterli sfruttare, potrebbero generare output corrispondenti all'attività desiderata. Se aggiungete tutto ciò ad altri fattori, vi potrete ritrovare in un momento difficile. È questa certo una parte dei rischi a cui ora le aziende sono esposte. Allora come bisogna gestire i rischi che si ritiene opportuno affrontare tenendoli sotto controllo? Una volta si viveva in un mondo dai contrasti più definiti, del tipo "sì o no" o "bianco o nero". Ora, viviamo in un mondo dai contorni più sfumati, in cui un modello ci offre ciò che ci serve, ma magari anche un altro modello potrebbe risultare ugualmente utile? Come possiamo riuscire a capire quali modelli dobbiamo utilizzare? Sì, è una domanda difficile perché i sistemi che utilizziamo non sempre vanno bene, ma non dobbiamo perdere la fiducia. Forse, bisogna utilizzare tecniche diverse: magari, un modello che controlla un altro modello per esaminare le varianti rispetto alle richieste precedenti. Nel caso di altri sistemi critici, vedo che alcune organizzazioni non sono pronte ad escludere totalmente l'intervento dell'uomo dalle loro attività aziendali perché si sentono più protette. Tuttavia, nel settore della sicurezza, spesso, l'uomo è l'anello debole. Sembra quindi un po' ridicolo ritornare al passato in tal senso, ma questi sono alcuni dei controlli compensativi. Sicuramente è qualcosa che dobbiamo tenere a mente: vedremo risposte molto sicure, ma decisamente sbagliate, in questa fase del percorso aziendale. Ecco, vorrei parlare proprio di questo: come facciamo ad evitare il fallimento? E poi, ovviamente, c'è un intero mondo di progettisti che cercano di creare soluzioni di intelligenza artificiale in grado di controllare l'intelligenza artificiale, in cui la presenza dell'uomo è ancora importante. Tuttavia, in realtà, questi processi potrebbero richiedere più tempo all'uomo per la verifica di quanto l'uomo avrebbe impiegato manualmente fin dall'inizio. E sicuramente ci sono anche altre componenti. Si tratta di un nuovo sistema costoso. Esistono diversi modi per provare a valutare, controllare se si tratta di un'operazione automatizzata o effettuata dall'uomo e così via. Ma abbiamo anche molti requisiti normativi. Come dovremmo stare al passo con tutti i requisiti GRC nel complesso, ad esempio, mentre cerchiamo di capire come muoverci? Anche perché il processo non è rapido, ma ci vorrà un po' di tempo.

Certamente. Allora, possiamo notare un'enorme discrepanza di velocità tra il ritmo delle innovazioni che si susseguono in questo settore, il più rapido di qualsiasi altra cosa che io abbia visto nella mia carriera, e la velocità con cui sappiamo che opera l'organismo di regolamentazione. Quindi, certamente vogliamo essere empatici nei confronti dei nostri amici del GRC che stanno affrontando questa discrepanza. Tuttavia, allo stesso tempo, molte normative estremamente rigorose si basano su principi fondamentali e molti di questi aspetti si estenderanno anche a questo ambito. Allora, cominciamo da domande basilari: l'inventario delle risorse è adeguato? Dove andranno implementate queste tecnologie? Abbiamo parlato di determinismo e non determinismo. Certamente, va sottolineato che, se conoscete il modello e avete il controllo amministrativo di questo sistema, potete manipolarlo e configurare o azzerare le sue impostazioni per forzarlo a risultare deterministico. Esistono alcune aree che possono trarre vantaggio dal fatto che i requisiti di sicurezza e conformità esercitano una certa tensione sulle attività aziendali perché alcuni sistemi potrebbero non avere la necessità di essere non deterministici. Se si tratta di un'applicazione "noiosa" in ambito legale o contabile oppure in altri contesti, non bisogna essere particolarmente creativi, anzi si desidera privilegiare la prevedibilità per un agente. In altre aree, alcuni potrebbero sostenere di volere un campione più ampio di risultati meno probabili per generare ciò che l'uomo percepisce come creatività proveniente dai sistemi. Ma penso che bisogna porsi domande difficili per capire se si ha davvero bisogno di un livello di comportamento non deterministico all'interno di un sistema, che dovrebbe essere messo alla prova e per cui andrebbe fornita una giustificazione, quindi si cerca di rendere il comportamento il più deterministico possibile.

Un'altra cosa che ho sentito dire è suddividere le attività come parte del workflow dell'agentic AI e del sottoagente, che si occupa esclusivamente di questo compito, consentendo di tracciare con precisione eventuali problemi. Al contrario, se esiste un solo workflow con un'infinità di passaggi, è molto difficile capire il punto in cui qualcosa è andato storto. Se, invece, riuscite a suddividere un processo nelle sue parti più piccole, lo renderete più deterministico anche se non è ancora interamente automatizzato. Indubbiamente, si tratta di un altro ottimo esempio, in cui, ancora una volta, alcuni controlli legati ai requisiti di sicurezza e conformità garantiscono risultati migliori, come una separazione dei compiti, se si riesce ad inserire alcune di queste cose. Abbiamo il vantaggio di avere una solida base di principi fondamentali entro i quali operiamo, quindi, in alcuni casi, trattare questi sistemi come se non fossero diversi e imporre alcuni dei tradizionali meccanismi di controllo ci sarà utile. D'altra parte, però, i criminali stanno sfruttando la natura non deterministica di questo comportamento in modo da renderlo opportunistico, nella speranza che si verifichi un qualcosa di creativo a cui non avevamo pensato. Quindi, in un certo senso, siamo portati a pensare che, se diventiamo così deterministici da limitare la potenza, potremmo dare un vantaggio ai criminali. Sei d'accordo? Sì, penso di sì. Ritorniamo all'esempio dell'AppSec. Tradizionalmente, abbiamo creato API e applicazioni per consentire agli utenti di sfruttarle nel modo più opportuno guidati da una funzione di ricerca. In futuro, potremmo accorgerci che le API e le applicazioni web da noi sviluppate forniscono informazioni ad un agente o un chatbot. Quando dovete decidere l'istituto finanziario più appropriato per le vostre esigenze, dopo aver inserito una serie di condizioni, probabilmente, utilizzerete un agente o un chatbot. Le modalità di gestione di questi bot che forniscono informazioni per l'addestramento e di risposta a questi agenti potrebbero richiedere un trattamento diverso per ogni caso di utilizzo, a differenza di ciò che facciamo oggi nel caso di un generico visitatore web. Nel migliore dei casi, quindi, ci troviamo di fronte ad un cliente reale dietro queste tecnologie. Ovviamente, poi, invece, abbiamo casi di impersonificazione da parte di criminali, che sfruttano questi stessi strumenti per scopi dannosi. In futuro, dovremo affrontare un'automazione maggiore con sempre più bot che arrivano sul nostro sito e dovremo gestire l'identità delegata: sono il legittimo proprietario della mia identità, ma vorrei che un agente si occupasse di alcune questioni per mio conto. Qualcosa che stiamo già iniziando a vedere, ma siamo ancora agli albori di un fenomeno, che comporterà delle sfide per i team, in particolare per le autorizzazioni.

Sì. Ne abbiamo già parlato in precedenza nelle nostre conversazioni. Esistono anche i rischi legati a terze parti e alla supply chain, ossia -n parti, perché se si tratta di agenti che parlano con altri agenti e così via. Quindi, abbiamo i nostri fornitori, i cui agenti parlano con altri agenti e di cui non abbiamo alcuna visibilità. Sono come scatole nere una sopra l'altra, di cui siamo totalmente all'oscuro. Come dovremmo considerare la questione? Dobbiamo già affrontare la sfida legata alla gestione dei rischi nella supply chain. Ora, aggiungiamo quest'altro livello, in cui la nostra visibilità è ancora minore. Cosa dovremmo pensare al riguardo? Ritengo che la prima sfida da affrontare, dal lato del cliente, sia la necessità di capire se qualcuno sta sfruttando un agente, identificarlo nel modo appropriato e trattarlo come merita, verificando se si tratta dell'identità delegata che vogliamo autorizzare. Questo è il nostro primo passo. Dobbiamo anche considerare il fatto che possiamo avvalerci di terze parti, che, a loro volta, si affideranno ad -n parti. Quindi, ecco come gestiamo i rischi della nostra supply chain. Una delle nostre società affiliate ha messo in pratica questa strategia all'inizio dell'anno con una lettera aperta di Pat Opet ai fornitori di soluzioni SaaS, evidenziando in modo molto chiaro alcune lacune presenti nell'ecosistema attuale. Questi problemi verranno parzialmente risolti dai fornitori di soluzioni SaaS con una maggiore trasparenza su ciò che succede downstream. Stiamo osservando alcuni concorrenti che che cercano di imporre questa situazione. Abbiamo parlato molto di modelli LLM, che, in genere, si ritiene siano una caratteristica predefinita quando si parla di GenAI, ma si sente anche parlare molto delle potenziali capacità offerte dai piccoli modelli linguistici, soprattutto per specifici casi di utilizzo. In altre parole, non hai bisogno dell'oceano se anche un lago va bene. Potrebbe essere questa una possibile via per gestire alcuni rischi di tipo non deterministico? Penso di sì. Ritengo che questa sia un'altra area in cui la sicurezza sta esercitando una certa pressione sulle aziende perché pone domande del tipo: "Ma serve davvero un LLM completo se consideriamo tutti i rischi correlati?". Modellare le minacce sulla base di un LLM non è sensato perché bisogna chiedersi cose del tipo: "Potrei chiedere ad un'applicazione finanziaria come costruire un'arma di distruzione di massa?". Tutto ciò potrebbe far parte del proprio modello di minaccia, a seconda di come è stato addestrato, mentre i team addetti alla sicurezza mettono alla prova le aziende. Ci siamo chiesti se è realmente necessario un modello non deterministico oppure se un modello deterministico potrebbe funzionare in questo scenario, il che rientra nel controllo della configurazione. Allo stesso modo, ritengo sia importante capire se si ha davvero bisogno di un LLM o se un SLM sarebbe sufficiente in uno specifico caso di utilizzo, il che potrebbe essere un altro esempio di come la sicurezza potrebbe portare le aziende a conseguire migliori risultati. Questa è una domanda che si pone un numero sempre maggiore di organizzazioni e ritengo che si tratti di un'evoluzione positiva a cui stiamo assistendo.

Allora, abbiamo un modello ad una certa temperatura, ma dobbiamo anche controllare il contesto. Non si può semplicemente lasciar continuare lo stesso contesto all'infinito perché si va a compromettere la qualità del risultato finale. Inoltre, più risultati si hanno, più sono gli input, ossia più ce n'è, più costa. Quindi, bisogna riuscire a limitare un po' il tutto. Poi ci sono i prompt e, magari, ci sono anche modi per renderli più prevedibili. Possiamo disporre di modelli e librerie di prompt. Se li rendiamo più prevedibili, gli input in entrata sono più controllati, quindi potremmo anche essere in grado di gestire parte del comportamento non deterministico in queste diverse dimensioni. Una delle cose che sto notando è che dobbiamo educare gli altri a pensare che ci sono diverse dimensioni utili per sapere quali strumenti scegliere e che non c'è un solo modo, non è così? Sono totalmente d'accordo. Se guardiamo indietro storicamente mentre si susseguono le nuove tendenze, abbiamo visto gli aspetti negativi dal punto di vista della sicurezza. Poi quando abbiamo intrapreso il percorso dell'e-commerce. abbiamo osservato un'intera ondata di SQL injection, che hanno sovraccaricato le applicazioni web di interi database. Grazie a questa esperienza, abbiamo imparato come esaminare meglio gli input provenienti dalle nostre applicazioni. Inoltre, quando siamo passati al cloud, abbiamo visto emergere una serie di schemi simili. Ora, speriamo che, in questa tendenza, possiamo trarre qualche lezione dall'introduzione di alcune di queste applicazioni web collegate ai dati sensibili sul back-end o dalla nostra esperienza con il cloud? Possiamo trarre lezione dalle esperienze precedenti senza vedere i risultati negativi delle organizzazioni interessate, ossia senza viverle in prima persona? Speriamo che sia così anche nel nostro caso: riuscire a ridurre alcuni di questi rischi prima che si trasformino in violazioni gravi.

Bene, abbiamo trattato molti argomenti, ma se volessimo trarre una sola conclusione dalla nostra conversazione da lasciare a chi ci ha seguito, quale sarebbe? Abbiamo affrontato molti spunti interessanti, ma direi che la chiave è garantire al team addetto alla sicurezza delle informazioni di capire i principi fondamentali. Quindi, dobbiamo stabilire un livello base di formazione sull'AI, possibilmente pratico, che risulti interessante per le persone a cui si rivolge, come ad esempio, un seminario o un hackathon. Infatti, penso che, se abbiamo chiari molti dei nostri principi fondamentali, quando riusciremo a comprenderli, sapremo anche dove applicarli. A questo punto, direi che è tutto.