0:00:02 Emily Wearmouth: Si è parlato molto dei potenziali rischi che i modelli di IA Frontier potrebbero presentare, e l'ospite di oggi ci offrirà una prospettiva alternativa. È un red teamer all'interno di una squadra di sicurezza, e sta usando i modelli di frontiera con grande efficacia. Quindi benvenuti al podcast Security Visionaries, Mohit Kulamkolly. Mohit è un ingegnere senior nel red team all'interno del team di sicurezza di Netskope, ed è fantastico averti con noi, Mohit.
0:00:26 Mohit Kulamkolly: Grazie. Grazie per avermi invitato. Sì, felice di essere al podcast. Sì.
0:00:31 Emily Wearmouth: Hai scritto un paio di post sul blog, e mi hanno spinto a contattarti perché quello di cui hai parlato in quegli articoli è un lavoro che tu e il tuo team più ampio avete svolto usando questi modelli nei vostri sforzi di red teaming. Volevo parlarne un po', e ci sono un paio di diversi, li chiamerò esperimenti. Spero che questo non li faccia sembrare troppo piccoli. Ci sono un paio di esperimenti e modelli diversi che hai usato, e la mia intenzione è farti molte domande che, si spera, svelino tutti i dettagli e le scoperte che hai fatto man mano che hai fatto. Da quando ha avuto accesso ai modelli di IA di frontier, e credo che Netskope sia entrato in "Glasswing" a giugno di quest'anno, il vostro team ha condotto esperimenti davvero informativi. Se ho capito bene, avete messo quei modelli di frontiera sulla strada dei prodotti di sicurezza di Netskope, e cercate di vedere se riescono a trovare gravi bug di sicurezza, in particolare bug di corruzione della memoria.
0:01:26 Emily Wearmouth: Ora, i nostri ascoltatori provengono da una chiesa molto ampia, quindi potresti iniziarci, Mohit, spiegando a un ascoltatore che forse non ha mai toccato direttamente la ricerca sulle vulnerabilità, cos'è un bug di corruzione della memoria e perché potrebbe essere considerato una delle categorie di falla di sicurezza più pericolose e difficili da trovare?
0:01:45 Mohit Kulamkolly: Sì, certo, certo. Sì, questo lo cattura con precisione. Quindi partiamo da cosa si sistema la corruzione della memoria, come hai giustamente sottolineato. Quindi un bug di corruzione della memoria si verifica quando un software gestisce male il proprio spazio di memoria allocato in modo sbagliato. Quindi questo è gestito dal sistema operativo, ma poi viene assegnato e deciso dal software stesso. Quindi, quando ciò accade, porta a vulnerabilità che possono attivare molteplici altri effetti all'interno del sistema operativo, il che non è un comportamento previsto. Allora perché è pericoloso? Perché, quindi faremo un passo indietro sul perché sia pericoloso capirlo meglio. Quindi possiamo suddividere il sistema operativo in due parti. Quindi uno sarà la modalità utente e l'altro sarà la modalità kernel. Quindi la modalità utente è dove restano tutti i programmi, tutti i nostri programmi, e la modalità kernel è quella che è collegata al sistema operativo.
0:02:44 Mohit Kulamkolly: E la modalità utente richiede sempre elementi dal kernel per eseguire certe azioni e tutto il resto. Quindi qui inizia la superficie d'attacco. Quindi, se un programma va in crash in modalità utente, rimarrà all'interno della modalità utente stessa. E quando inizia a chiedere cose al kernel, anche l'attaccante può vedere questo o può usarlo. Quindi, attraverso quel percorso, può anche far crashare i problemi del sistema operativo, il che porta a più vulnerabilità. Ecco perché è molto pericoloso rispetto ad altre vulnerabilità.
0:03:15 Emily Wearmouth: E cosa cercavate di scoprire puntando questi modelli di IA a quei bug di corruzione della memoria?
0:03:22 Mohit Kulamkolly: Quindi, fondamentalmente, Netskope opera all'interno del sistema all'interno dell'entità del sistema operativo del cliente. E da lì, se viene attivata una vulnerabilità, si tratta di una vulnerabilità da corruzione della memoria. Come ho detto, può causare inattività del sistema oppure vulnerabilità di escalation dei privilegi e tutte queste cose. Quindi l'obiettivo era vedere se una vulnerabilità all'interno di Netskope Client in particolare potesse essere portata a qualcosa che influenzasse il sistema operativo. Quindi stiamo passando dal nostro programma al quadro più ampio, che è più catastrofico rispetto al semplice Netskope Client crollo. Quindi sì, questo era l'obiettivo.
0:04:03 Emily Wearmouth: E prima di vedere come usi gli strumenti di IA, come normalmente cercheresti queste vulnerabilità prima di avere Frontier AI?
0:04:13 Mohit Kulamkolly: Quindi, prima di iniziare cercando di capire qual è la superficie d'attacco. Quindi esistono API scritte per questo tipo di comunicazione che avviene dalla modalità utente alla modalità kernel. Quindi cerchi prima di capire quali API ci sono e come il programma viene scritto, completamente da una prospettiva black box. Quando dico scatola nera, non abbiamo il codice sorgente, niente del genere. Ed è così che abbiamo iniziato. Da lì cercheremo di vedere se un payload che inviamo o un dato che inviamo provoca un crash all'interno di un sistema o di quel particolare sistema operativo. E continuiamo a provarci più e più volte per capire quale carico utile o istruzione sia in causa del fallo. È allora che cerchiamo di sviluppare fuzzer da soli. Questo è ciò che abbiamo dettagliato ora. Quindi ho sviluppato fuzzer che aiutano a individuare queste vulnerabilità.
0:05:10 Mohit Kulamkolly: Ma avere l'IA in questo quadro ha portato a un livello di test New diverso, in cui è necessaria molta, molta più competenza per entrare in questo ambito. E poi, grazie all'avvento dell'IA, possiamo intensificare ulteriormente la situazione.
0:05:29 Emily Wearmouth: E citerò qui il tuo post sul blog. Quindi, nella prima fase del lavoro che hai fatto, e stavi usando OpenAI 5.5, ho capito bene?
0:05:38 Mohit Kulamkolly: Modello informatico.
0:05:39 Emily Wearmouth: Hai detto che il punto di partenza era che non puoi semplicemente chiedere all'IA, trovarmi un bug e fidarti della risposta. Devi dargli gli stessi strumenti che userebbe un vero cacciatore di insetti umano e costringere ogni sua affermazione a essere confrontata con un sistema reale in esecuzione. Quindi, per prendere i punti in ordine, prima di tutto, perché è pericoloso? Potremmo saperlo. Dimmi chiaramente, perché è pericoloso fidarsi semplicemente della parola di un modello che ha trovato una vulnerabilità? E cosa potrebbe andare storto se salti quella fase di verifica?
0:06:09 Mohit Kulamkolly: Sì, certo. Quindi, prima di approfondire, penso che potrei finire per contraddire questa affermazione da un po', perché è quello che il Mito mi ha insegnato con gli esperimenti New . Quello che succede con questi modelli cyber, OpenAI 5.5 o il modello cyber, è che vengono addestrati su una quantità enorme di dati, tutte vulnerabilità e risultati di sicurezza. Quindi permette di allucinare in situazioni in cui deve fare supposizioni invece che informazioni. Quindi, se chiedi semplicemente al modello di trovare la vulnerabilità per te, quello che succede è che è l'unica cosa che conosce. Quindi deve concludere dalle sue assunzioni iniziali. Quindi in un certo senso è buono, cosa che abbiamo capito più avanti. Inizialmente, quando volevamo scrivere, dovevamo assicurarci di essere il più deterministici possibile nei nostri risultati. Ed è stato allora che abbiamo deciso, ok, iniziamo con quello che sappiamo.
0:07:11 Mohit Kulamkolly: Cerchiamo di approfondire questo aspetto, e poi passeremo al capitolo di ciò che non sappiamo e cosa può fare il modello.
0:07:17 Emily Wearmouth: Ok. Quindi raccontami cosa hai effettivamente costruito qui. Com'è effettivamente un laboratorio per un sistema del genere?
0:07:24 Mohit Kulamkolly: Sì, senza entrare nei dettagli molto specifici di come sia, a un livello molto generale, è solo che stai dando a un ricercatore di vulnerabilità gli strumenti di cui ha bisogno. Voglio dire, deve essere necessario per eseguire certe azioni. Quindi pensateci: ci sono missioni virtuali in cui il software sarà eseguito. Ci sono missioni virtuali in cui gli strumenti saranno in funzione. Così li ho collegati tutti, ho collegato i punti e ho dato questo al modello, poi gli ho chiesto di cercare una vulnerabilità in modo molto specifico che avrei visto con la mia esperienza con le precedenti operazioni di caccia. Così abbiamo iniziato. Così appare il laboratorio a un livello molto generale.
0:08:12 Emily Wearmouth: Farò una domanda potenzialmente complicata. Quindi nell'ultima settimana o due ci sono state molte storie su agenti e IA che escono dai sandbox e fanno cose che forse rispondono al compito assegnato, ma certamente non in un modo con cui ci sentiremmo a nostro agio. Ci sono delle barriere specifiche che state mettendo intorno a questi esperimenti prevedendo che possano provare a rompere? Come fai a assicurarti che non succeda?
0:08:36 Mohit Kulamkolly: Sì, quindi è una domanda molto buona perché soprattutto in questo contesto, quando a un agente viene chiesto di svolgere un compito specifico, non lo diciamo in modo molto specifico. È quello che ho fatto inizialmente, e ho capito che potesse essere un limitatore per l'agente. Per uscire da questo, abbiamo creato un ambiente sandbox individuale. Quindi ogni missione virtuale ha un ambiente sandbox, che non può essere danneggiato o accessibile se esplicitamente non glielo permettiamo. Soprattutto nel caso di questi test di macchine Windows e tutto il resto, invece di eseguire un container Docker o concetti simili, le missioni virtuali funzionano meglio. Questo è il livello di isolamento che abbiamo costruito per i singoli utensili e il tipo di accesso che hanno ad essi. E facciamo tutti questi test su un sistema e una missione separati senza un adeguato accesso a internet.
0:09:34 Emily Wearmouth: Immagino che tenerlo fuori internet sia uno degli aspetti chiave per limitarne la capacità di andare fuori controllo. Hai anche menzionato nell'articolo che hai costruito tutto attorno a una macchina target specificamente autorizzata a crashare e a una macchina separata che la sorveglia con un debugger. Perché hai tenuto questi problemi separati e perché è utile permettere che crashi invece di fermarlo prima che ciò accada?
0:09:58 Mohit Kulamkolly: Sì, quindi questo è tutto il concetto di questa vulnerabilità di corruzione della memoria e perché è interessante. Quindi, ogni volta che un sistema cerca di scoprire che una memoria viene gestita male da un programma, si passa a una fase di fail-safe. Quindi questo è un crash stage di ciò che succede. Quindi, quando cerchi di testare un singolo bug, quando cerchi di testare un singolo payload a livello microscopico, il modo migliore per confermare che il bug esiste inizialmente è vedere se crasha o meno. E se c'è un crash assurdo, significa che sta avvenendo una cattiva gestione della memoria. Poi potremo discutere di come possiamo farlo crescere, quali produzioni di sistema dobbiamo aggirare, e così via. Quindi queste cose emergono in una fase successiva. Ma per aggiungere a una cosa interessante che hai menzionato, perché non metterlo in pausa poco prima che crashi?
0:10:53 Mohit Kulamkolly: Quindi esiste anche un sistema simile. Quindi lo facciamo anche internamente. È un'infrastruttura di snapshot fuzzing che abbiamo costruito, in cui cerchiamo di riprenderla subito prima che crashi, così da poterla rigiocare milioni di volte e trovare New varianti della nostra vulnerabilità. Quindi sì, questo è tutto il contesto.
0:11:12 Emily Wearmouth: E ho un'ultima domanda su questa fase dell'esperimento. Mi riservo il diritto di chiedere di più, ma al momento penso di averne uno. Sembra che molte delle prime ipotesi del modello sui bug si siano rivelate sbagliate. Che si basassero su assunzioni obsolete sul software. E mi chiedevo perché avessi deciso che stava succedendo così? E cosa pensi che il modello abbia imparato sbagliando e attraversando quella fase di errori?
0:11:43 Mohit Kulamkolly: Sì, quindi quello che succede a questo tipo di software è che è difficile testarlo perché dipende molto dall'ambiente su cui viene distribuito. Quindi, se vengono apportate piccole modifiche al sistema operativo, diciamo che c'è una funzione o un programma che dovrebbe essere in esecuzione in background, non è in esecuzione, il software non si comporterà come dovrebbe. Quindi questo è uno dei motivi per cui il sistema non solo deve adattarsi a qualsiasi ambiente abbia per le vulnerabilità, ma allo stesso tempo deve anche capire il passo successivo in base al risultato che ne ottrae. Quindi non è solo questo, ok, questa è la procedura standard, vai avanti. Quindi devi assicurarti che il sistema accetti questo oppure che il software sia pronto ad accettare quella procedura operativa standard e che funzioni prima di iniziare a inserire payload.
0:12:39 Mohit Kulamkolly: Perché se non inserisci un'IA qui, succederà che manderò molti payload e poi l'IA non lo farà o il software non risponderà nemmeno. Quindi, come posso testarlo? Quindi è per questo che il modello ha fatto quella correzione. Sì.
0:12:54 Emily Wearmouth: A destra. Quindi, quello di cui abbiamo parlato finora è stata la fase uno. Quindi avevi gli esseri umani, tu, che progettavano tutti i passaggi, e poi all'IA veniva chiesto di eseguire compiti all'interno di un processo che avevi progettato tu. Voglio che ora passiamo alla tua seconda fase. Ora, per la seconda fase, hai cambiato modello e hai iniziato a giocare con Claude Mythos invece. C'era un motivo per cambiare questo o era solo che inizialmente volevate fare esperimenti con entrambi? Oppure c'è stato un vantaggio che pensavi di ottenere passando a un modello diverso?
0:13:30 Mohit Kulamkolly: Non proprio. Abbiamo solo New strumenti sofisticati e New analoghi.
0:13:34 Emily Wearmouth: Ci siamo passati tutti. Ok. E su questo secondo punto cercherò di abbozzare cosa era diverso, e poi sono sicuro che illuminerai un po' di più. Quindi, invece di progettare ogni passaggio e poi chiedere al modello di eseguire, hai chiesto al modello di decidere cosa indagare. Poi gli hai chiesto di dimostrare qualsiasi bug trovato contro un sistema reale. E poi, che sembra essere un elemento piuttosto critico di questo, è che richiedeva anche che avesse una seconda copia indipendente di sé stessa ricontrollata rispetto a quella prova. Quindi gli dai più processi da fare, ma stai anche aggiungendo più controlli perché stai togliendo più persone dal carico di lavoro. Puoi spiegarmi cosa ti ha spinto, dal concludere e concludere sui tuoi esperimenti OpenAI, cosa ti ha spinto a progettarlo in questo modo?
0:14:30 Mohit Kulamkolly: Abbiamo preso lezioni da OpenAI quando abbiamo iniziato i test con Mythos. Quindi sotto il cofano, tutta la sicurezza, tutti i modelli. Quindi sono tutti fondamentalmente sistemi di previsione. Anche se diciamo cose come che hanno sviluppato New software e tutto il resto, loro semplicemente prevedono cosa succederà in modo molto efficiente in base al contesto che viene dato. Quindi, più si limita il contesto o si mette il contesto al guinzaglio, più succederà che anche il tipo di informazioni che può produrre diminuirà. Quindi, quando testavamo con OpenAI, l'abbiamo prodotto come fuzzer. Gli abbiamo chiesto di costruire sopra questo. Ora volevamo vedere se, dato che gli abbiamo dato il fuzzer, l'unica cosa che è riuscito a costruire è un'estensione di quello.
0:15:21 Mohit Kulamkolly: Così abbiamo rimosso il fuzzer dalla scena e poi gli abbiamo insegnato come costruiamo il fuzzer e come puoi farlo da solo. O puoi farlo da solo oppure puoi semplicemente fare ciò che ritieni giusto per raggiungere questa particolare interfaccia del programma. Ecco perché abbiamo voluto provarci in questo modo. Quindi invece di guardarla intorno. Quindi è andata molto bene. Così abbiamo capito come si comportava il modello e i modi creativi necessari per individuare una vulnerabilità. Quindi questo è il nocciolo della questione.
0:15:57 Emily Wearmouth: Ci sono state considerazioni extra da considerare perché questa volta avevi passato più controllo? C'erano modi diversi in cui strutturavi le cose o qualche barriera aggiuntiva che sentivi di dover implementare?
0:16:10 Mohit Kulamkolly: Sì, più isolamento. Penso che più isolamento fosse ciò che era fondamentale. Il modello, non sul nostro sistema funzionante. Quindi avevamo un laptop separato solo per testare questo. Era fuori dalla rete. E poi sì, questa volta ci siamo messi tutto. Quindi, invece di chiedergli di usare gli strumenti presenti nel sistema, ci siamo assicurati che fosse sempre più isolato. Sì, è tutto.
0:16:35 Emily Wearmouth: Ok. E poi immagino che integrandolo con il controllo di ciò che sta producendo, ci siano anche barriere extra attorno alle conclusioni che sta tracciando, immagino che tu stia integrando nel modello.
0:16:47 Mohit Kulamkolly: Sì, sì. A destra.
0:16:49 Emily Wearmouth: Come hai evitato che si convincesse di avere ragione? Come hai fatto a tenere quel doppio controllo abbastanza separato da non poterlo fare? Voglio dire, una delle cose che abbiamo visto nell'ultima settimana è stata un agente che è andato letteralmente al punto di creare deep fake di dipendenti per ottenere l'approvazione interna. Quindi sappiamo che l'IA sa come convincere. Come hai fatto a essere sicuro che non si stesse solo convincendo da solo o da questo controllo secondario che quello che stava facendo fosse giusto?
0:17:21 Mohit Kulamkolly: Sì. La cosa principale è ciò di cui abbiamo parlato prima, il modello è un sistema di previsione e il contesto una parte chiave qui. Vorrei riprendere lo stesso concetto anche qui, il contesto. Quindi quasi sempre, il 100% delle volte quando un modello sbaglia, è perché non ha il contesto giusto o ha un contesto indesiderato, direi. Quindi il motivo per cui esistono due sistemi separati è per lo stesso motivo. Quindi, ogni volta che un modello guarda New lavoro, significa semplicemente che sta guardando da un contesto semplice a una finestra. Quindi, in questo modo, non fa alcuna supposizione errata che era stata creata in precedenza. Quindi, anche nel caso che hai menzionato, tutto si riduce a ciò che il modello deve raggiungere. Quindi l'obiettivo per un agente potrebbe non essere quello per l'altro.
0:18:16 Emily Wearmouth: Ah, interessante.
0:18:18 Mohit Kulamkolly: E basandosi anche su quello che hai detto, l'obiettivo iniziale potrebbe non essere creare deep fake di quel particolare dipendente, ma piuttosto aggirare questo sistema di approvazione. Quindi farà tutto ciò che può, ma il modello non ha fatto nulla di dannoso dal suo contesto, mentre dal contesto esterno sì. Quindi il contesto è un re. Sì.
0:18:40 Emily Wearmouth: Quindi immagino che tu abbia creato un po' di attrito tra i due livelli: se non controlla il proprio lavoro, è un agente AI diverso a controllare il lavoro così da non collaborare e mantenere una certa separazione tra i due. È un punto di design davvero interessante.
0:18:58 Mohit Kulamkolly: Esatto, esatto. Sì.
0:19:00 Emily Wearmouth: Raccontaci alcune delle cose che ha trovato questa persona. Come funzionava? Che risultato è venuto?
0:19:08 Mohit Kulamkolly: Quindi sì, abbiamo ottenuto molti buoni risultati da questi due esperimenti iniziali che abbiamo fatto. Quindi siamo riusciti a trovare circa 17-18 vulnerabilità solo sui software open source. Quindi questi software sono qualcosa che Netskope utilizza per costruire i nostri prodotti. Ma poi queste vulnerabilità vengono trovate nei pacchetti a monte e poi segnalate al personale giusto che li gestisce. E poi ho scoperto queste vulnerabilità legate alla corruzione della memoria. Quindi c'erano anche 15-20 vulnerabilità di corruzione della memoria. E poi infine, per il controllo differenziale, ne abbiamo trovati quattro o cinque. Quindi non si tratta di una questione su scala condivisa, sono state trovate 20.000 vulnerabilità, e questa è solo una piccola scala di cui parlo, 15-20. Il motivo o la parte chiave da notare qui è che ogni vulnerabilità, quando segnalata da un cliente o su Netskope, sarà contabilizzata a un FMI.
0:20:15 Mohit Kulamkolly: Quindi quegli incidenti con il FMI porteranno a enormi perdite per quell'entità che li ha subiti. Quindi trovarlo nei nostri prodotti ci sta facendo risparmiare molti soldi e garantendo la fiducia dei nostri clienti su ciò che ci stanno opponendo.
0:20:35 Emily Wearmouth: Sì. Ora ho scritto di nuovo dal tuo articolo qualcosa che volevo esplorare e che sembrava particolarmente interessante. C'era un bug che il modello ha trovato sul lato kernel, e hai raccontato una storia su un crash che non è successo finché non ha scoperto qualcosa di sottile su come viene allocata la memoria dietro le quinte. Vuoi raccontarci a un livello generale quell'esempio particolare?
0:20:59 Mohit Kulamkolly: Sì, certo, certo. Quindi penso che questa vulnerabilità fosse in un parser di configurazione. Quindi questo parser di configurazione copiava sostanzialmente il valore del registro in un'allocazione di pool di dimensioni esatte usando una funzione di copia string-length. E questa funzione di copia collegata a stringhe non aveva un controllo in uscita che fosse presente. Quindi assegno fuori limite. Per questo motivo, questa è una vulnerabilità da manuale fuori dal vincolo, e può essere sfruttata molto facilmente. Quindi, per arrivare a questa vulnerabilità, c'erano quasi cinque o sei precondizioni da soddisfare. Quindi le precondizioni saranno semplici come verificare se il software accetta un tipo specifico di nome di servizio o se accetta qualcosa di diverso o una versione diversa che accetta. Queste sono tutte precondizioni.
0:21:54 Mohit Kulamkolly: Quindi, dopo aver risolto tutte le precondizioni, il crash non è ancora avvenuto. Quindi doveva entrare nel debugger, cercare di semplificare l'allocatore. Poi ha capito che il sistema operativo apparentemente aggiungeva qualcosa chiamato null terminator, che è molto comune. E poi l'allocator arrotondava quel buffer in una tabella piena praticamente. Questo ha causato una lettura fuori dal limite per non atterrare dove avevamo dovuto atterrare. Quindi ha capito la geometria dell'allocatore su come sta accadendo, e ha cambiato il suo exploit per farlo corrispondere esattamente a ciò che ci si aspetta che scateni il guasto. Quindi è quello che è successo lì, a un livello molto alto. Sì.
0:22:35 Emily Wearmouth: Parte del motivo per cui ti ho chiesto di spiegarlo è perché volevo vivere il momento di colpo di testa. Voglio dire, la complessità e gli strati di dettaglio in cui si sta entrando, se si immagina un mondo in cui si raggiungesse più manualmente quel risultato, intendo, che durata, quante ore di lavoro? Come sarebbe? O pensi che succeda solo per caso?
0:23:02 Mohit Kulamkolly: Voglio dire, sarebbero giorni e giorni di impegno. E poi, come hai detto tu, sarebbe anche un incidente. Quindi, poiché è molto difficile capire queste cose, perché quando guardi un debugger e cerchi di capire dove l'allocator ha sbagliato, è difficile perché devi dare un senso a molte informazioni presenti. Potresti non essere un esperto in quel particolare ambito specifico che stai guardando, ma allora devi conoscere tutte queste cose per assicurarti di collegare i puntini. Quindi, di nuovo, sì, potrebbe essere un caso imbattersi in questi problemi o mesi e ore di impegno per trovare questa vulnerabilità.
0:23:40 Emily Wearmouth: Ce n'è stato un altro che ho trovato interessante nel tuo articolo. Era un bug che ha richiesto diversi giorni e migliaia di tentativi per essere risolto, anche con l'IA. Hai parlato che un equivalente umano richiederebbe giorni e giorni. Anche con l'IA in funzione, questa ha richiesto diversi giorni e migliaia di tentativi. Cosa ha fatto andare avanti quel processo? Cosa è cambiato tra i tentativi falliti e quello che finalmente ha funzionato? E perché non è arrivato al tempo? Voglio dire, quanto tempo, se ci avesse messo invece di migliaia di tentativi, se fossi arrivato a centinaia di migliaia, avrebbe semplicemente rinunciato e non l'avrebbe trovata? Ho fatto alcune domande diverse lì. Scegli tu.
0:24:18 Mohit Kulamkolly: No, ha senso. Quindi, in realtà, per quella vulnerabilità o per trovare quell'istanza particolare, il motivo per cui il processo è stato difficile è che non avevamo il codice sorgente. Non avevamo una tabella dei simboli, non avevamo nulla. Abbiamo fatto un vero e proprio test black box. Quindi la questione è che per questo tipo di vulnerabilità, quando cerchi di scoprirle, ci sono molte sfumature che ci sono prima ancora di arrivare alla vulnerabilità stessa. Quindi, per la parte dell'IA per i tempi di scadenza, è il modo in cui è stata progettata che ti troverai ad affrontare molte di queste reazioni negative che la tua ipotesi iniziale potrebbe funzionare o meno. Non dovresti aspettare che un'ipotesi si completi mentre l'altra passa alla successiva. Quindi, invece di una moda lineare, era per lo più una moda parallela.
0:25:09 Mohit Kulamkolly: Quindi gli agenti generano sotto-agenti quando necessario per esplorare queste ideologie finché non trovi o capisci il modo giusto per affrontarle. Ecco perché per lo più non ha scaduto. Penso che abbia durato alcuni giorni per individuare questo tipo di vulnerabilità, soprattutto per la complessità e la disponibilità di meno informazioni. Ma sì, i sotto-agenti hanno funzionato lì.
0:25:34 Emily Wearmouth: Quindi sto per allontanarmi un po', e penso che valga la pena, si spera, che gli ascoltatori abbiano capito che questi due articoli che hai pubblicato valgono davvero la pena di essere letti. Quindi includeremo dettagli su dove puoi leggere altri dettagli di questo dettaglio nelle note dello show. Ma facciamo un attimo di sguardo dagli esperimenti esatti che hai condotto e riflettiamo su cosa significhi questo nel contesto più ampio e cosa significhi per alcuni dei nostri ascoltatori quando pensano ai loro ambienti e forse non hanno accesso a tutti questi modelli di frontiera a questo punto? Credo che la prima cosa a cui penso sia se questa capacità non è esclusiva di Netskope. C'è una vasta lista di organizzazioni che hanno accesso a questi modelli, e anche quelli che non sono considerati modelli frontier stanno diventando sempre più intelligenti.
0:26:17 Emily Wearmouth: Quindi, se questa tecnica ti aiuta a trovare bug nel tuo codice e nei tuoi sistemi e sono disponibili o strumenti simili sono disponibili per chiunque, cosa significa per il team di sicurezza medio che magari non ha un team di ricerca come il tuo e si trova dalla parte di altri che usano questi sistemi per attaccare e individuare questi problemi? Quando guardi a questa sfida che il settore sta affrontando, come la vedi?
0:26:47 Mohit Kulamkolly: Sì, quindi quello che alla fine accadrà è che i modelli diventeranno sempre più economici a causa del modo in cui stanno avanzando anche in termini di sicurezza, in ogni prospettiva di sviluppo. Quindi penso che quello che succederà è che alcuni degli altri modelli, ora tutti potranno accedere a modelli open source open weight per esplorare queste cose. Quindi quello che consiglierei a qualsiasi team di ricerca sulla sicurezza, qualunque cosa stiano cercando di fare e vogliano iniziare a fare, è di iniziare a fornire a queste IA gli strumenti giusti. E poi, con gli strumenti giusti che fornisci all'IA, più rimarrai sorpreso e più esplorazione può fare da sola per capire queste cose. Quindi invece di considerarlo come uno strumento complesso necessario per collegarlo a uno strumento diverso che c'è.
0:27:42 Mohit Kulamkolly: Ad esempio, supponiamo che tu abbia bisogno di un server MCP che deve essere usato per collegare uno strumento, ma non hai un server MCP per quello. Quindi dovrai scriverlo da zero e poi costruirlo sopra. Quindi questa è una curva di apprendimento che potresti dover superare per arrivare da quel lato. Quindi pensaci come anche il server MCP è solo qualunque API venga esposta, tu lo stai semplicemente collegando all'IA, tutto qui. Quindi è solo codice semplice. Cerca di capirlo. E poi, se riesci a collegare il tuo strumento, altrimenti puoi connetterti con gli strumenti, devi iniziare a scrivere cose da solo o usare l'IA per scriverle. In questo modo, una volta che inizi a dare agli strumenti le cose sensoriali, occhi, naso, orecchie. E una volta che hai tutte queste informazioni, gli strumenti inizieranno a elaborare o l'IA inizierà a elaborare le informazioni come vuoi e allora ti darà risultati migliori.
0:28:37 Mohit Kulamkolly: Quindi sì, è così che la vedo io.
0:28:40 Emily Wearmouth: Pensi che un approccio del genere cambierà in modo significativo il modo in cui le aziende software o tecnologiche distribuiscono il loro software? Cambierà le linee temporali? Cambierà le aspettative o i costi? Quali pensa possano essere queste implicazioni?
0:28:57 Mohit Kulamkolly: Assolutamente sì. Quindi sì, come ho detto, quello che succederà è che le vulnerabilità di sicurezza diventeranno più economiche da scoprire man mano che l'IA avanza. Quindi quello che succederà è che la soluzione diventerà più costosa. Quindi, con il prezzo a cui stiamo distribuendo il software in questo momento. Quindi la correzione di queste vulnerabilità diventerà costosa e poi sarà più difficile da eseguire. Quindi, quando abbiamo come Netskope ha questo da ancora prima del periodo in cui l'AI lo faceva, abbiamo il nostro SDLC di sviluppo. Quindi, in quel caso, il software non è un secondo pensiero. Mi dispiace, ma la sicurezza non è un secondo. È un pensiero che inizia dalla lavagna quando inizi a pensare a un prodotto in sé. Quindi, se segui questo approccio particolare, chiedi all'IA di costruire un modello di minaccia per un prodotto subito dopo aver preparato un PRD o un documento di requisiti di prodotto.
0:29:54 Mohit Kulamkolly: Quindi questo di per sé ti darà un'idea di cosa aspettarti mentre costruisci il prodotto stesso. Quindi più contenuti Contesto per l'IA, comunque, l'IA costruirà queste cose. Così puoi dare più contesto all'IA affinché tali vulnerabilità non esistano nella fase successiva del tuo software.
0:30:08 Emily Wearmouth: È un'idea davvero interessante perché attraverso questi esperimenti, si prende qualcosa che era già costruito in tutta la sua complessità e si chiede all'IA di rovistare e trovare problemi. Ma stai suggerendo che in realtà potresti usare questi sistemi quando hai solo un concetto di prodotto e qualche schizzo di come potrebbe essere l'architettura e già inizi a far sì che i sistemi di IA spuntino falle nei tuoi piani, così che quel rigore di sicurezza sia davvero presente fin dall'inizio. Non devi investire tempo ed energie per costruire qualcosa che potrebbe non funzionare. Puoi iniziare a trovare problemi prima che esistano.
0:30:45 Mohit Kulamkolly: Esatto, esatto. Esattamente.
0:30:47 Emily Wearmouth: Non ci avevo nemmeno pensato. Quindi, se un team di sicurezza vuole fare qualcosa, e credo che in particolare un team di sicurezza sia responsabile di una parte di una proprietà digitale di qualche tipo, potrebbe essere perché sono fornitori o perché stanno costruendo applicazioni private ed elementi privati all'interno del loro stack. Se volessero fare qualcosa del genere per la prima volta, qual è il primissimo passo che potresti temere che possano saltare e che tu voglia semplicemente ritirarli? Hai parlato un po' di alcune delle cose che potrebbero iniziare a fare da soli. Qual è la cosa che vuoi tenere in mano, ma prima fare questo?
0:31:26 Mohit Kulamkolly: Sì. Ok. No, ha senso. Quindi, quello che penso soprattutto per queste scoperte è che l'IA, non pensiamo affatto alla parte delle allucinazioni. Supponiamo che l'IA individui tutte le vulnerabilità. Quindi, se l'IA riesce a trovare 20.000 vulnerabilità, non è giusto lanciare questi 20.000 risultati ai tuoi sviluppatori e dire: chiedi loro di risolverle. Quindi questa è l'unica cosa a cui dobbiamo stare attenti. Trovare vulnerabilità è una cosa, ma avere un piano di bonifica è l'altro fattore importante qui. Quindi, prima ancora di iniziare a parlare di queste vulnerabilità, bisogna iniziare a discutere con il proprio sviluppatore per capire da dove dovremmo iniziare a guardare le vulnerabilità e quali sono i fattori chiave. Quindi solo quando hai questa sinergia, queste vulnerabilità saranno utili. Altrimenti si accumulerà nella tua lunga lista di vulnerabilità come non risolte, 20.030.000 di esse.
0:32:26 Mohit Kulamkolly: Quindi questa è l'unica cosa che avrei in mente prima di immergermi più a fondo o iniziare a usare questi strumenti sofisticati.
0:32:34 Emily Wearmouth: È un ottimo punto. Quindi sì, metti tutti i dettagli giusti su quello che stai facendo, con il rigore, i giusti limiti e approccio, ma allontanati un po' e pensa all'impatto che il tuo programma avrà sugli altri e non iniziare a creare un aumento di 500 volte nella coda di qualcun altro solo perché non ti piacerà per questo.
0:32:54 Mohit Kulamkolly:Esatto.
0:32:56 Emily Wearmouth: Geniale. Beh, Mohit, grazie mille per essere stato con me a parlare di tutto questo oggi. Appena ho letto gli articoli, ho capito che dovevo farti entrare, quindi apprezzo davvero che tu abbia trovato il tempo. E sento anche che questo non è il tuo esperimento finale. Abbiamo detto che era la fase uno e la fase due, e vedo dal luccichio nei tuoi occhi che forse sta già avvenendo una fase tre. Quindi, dove dovrebbero andare i nostri ascoltatori per seguire il lavoro che stai facendo e le scoperte che stai facendo?
0:33:23 Mohit Kulamkolly: Certo. Sì. La maggior parte di questo lavoro sarà documentata sul blog Lens direttamente sul sito web di Netskope. E sì, se c'è qualcos'altro, altro, lo pubblicheremo anche sui siti della community di Netskope. Ma sì, ci saranno altre cose in arrivo per questo test.
0:33:41 Emily Wearmouth: Favolosa. Penso che dovremo riportarti nel podcast e ascoltarli man mano che accadono. Grazie mille, Mohit.
0:33:47 Mohit Kulamkolly: Grazie, Emily.
0:33:48 Emily Wearmouth: Hai ascoltato il podcast Security Visionaries e, se ti è piaciuto questo episodio, ti consiglio vivamente di dare un'occhiata al nostro catalogo antico, che puoi trovare su una qualsiasi delle tue piattaforme di podcast preferite. E anche i nostri episodi più recenti sono su YouTube se volete vedere i nostri volti sorridenti mentre vi parliamo. Quindi godetevi e ci vediamo la prossima volta.
){kind=icon}
