«3CB»: il benchmark delle capacità cibernetiche catastrofiche
L’ultimo articolo di Apart Research, Catastrophic Cyber Capabilities Benchmark (3CB): Robustly Evaluating LLM Agent Cyber Offense Capabilities, propone un nuovo benchmark per le capacità cibernetiche offensive.
L’ultimo articolo di Apart Research, Catastrophic Cyber Capabilities Benchmark (3CB): Robustly Evaluating LLM Agent Cyber Offense Capabilities (sito web), introduce un nuovo benchmark per le capacità cibernetiche offensive che risolve i problemi di leggibilità, copertura e generalizzazione presenti nei benchmark sulle capacità offensive.
Siamo stati spinti a creare questo benchmark 3cb perché lo sviluppo di un’IA superintelligente in grado di eseguire operazioni cibernetiche autonome rappresenterebbe un grave rischio per l’umanità. Ciò significa che disporre di valutazioni robuste delle capacità cibernetiche offensive sarà più importante che mai per i responsabili politici e gli sviluppatori di IA.
3cb utilizza un nuovo tipo di categorizzazione per le attività cibernetiche offensive e aderisce al principio delle “dimostrazioni come valutazioni” per migliorare la leggibilità e la copertura. Introduce inoltre 15 sfide originali che non vengono memorizzate, differenziandosi da altri benchmark che utilizzano competizioni CTF o pull request esistenti per valutare i modelli.
Agenti e capacità cibernetiche
Gli agenti MLGD potrebbero rivoluzionare le operazioni cibernetiche difensive, ma le loro capacità offensive non sono ancora pienamente comprese. Per prepararsi alle minacce emergenti, gli sviluppatori di modelli e i governi stanno valutando le capacità cibernetiche dei modelli di fondazione. Tuttavia, queste valutazioni spesso mancano di trasparenza e di un’attenzione completa alle capacità offensive.
In risposta, introduciamo il Catastrophic Cyber Capabilities Benchmark (3CB), un nuovo framework progettato per valutare rigorosamente le capacità offensive nel mondo reale degli agenti MLGD. La nostra valutazione dei moderni MLGD sul 3CB rivela che i modelli di frontiera, come GPT-4o e Claude 3.5 Sonnet, sono in grado di eseguire attività offensive quali la ricognizione e lo sfruttamento in ambiti che spaziano dall’analisi binaria alle tecnologie web.
Al contrario, i modelli open source di dimensioni più ridotte mostrano capacità offensive limitate. La nostra soluzione software e il relativo benchmark forniscono uno strumento fondamentale per ridurre il divario tra le capacità in rapido miglioramento e la robustezza delle valutazioni relative agli attacchi informatici, contribuendo a un rilascio e a una regolamentazione più sicuri di queste potenti tecnologie.
Perché 3cb?
Le operazioni autonome di attacco informatico rappresentano un fattore di rischio chiave per l’intelligenza generale competente. Di conseguenza, disporre di valutazioni affidabili degli attacchi informatici è importante per supportare i responsabili politici e le misure di governance dei laboratori, contribuendo a ridurre il rischio legato all’IA.
Dalle conversazioni con accademici, team dell’AISI, di Anthropic e di altri attori privati, abbiamo individuato un’ampia raccolta di benchmark che in genere 1) utilizzano le sfide “capture-the-flag” (CTF) esistenti per comporre un benchmark e 2) valutano un sottoinsieme specifico di capacità informatiche. È possibile leggere di alcuni esempi in Cybench, InterCode-CTF, NYU CTF e CYBERSECEVAL.
Oltre al fatto che questo progetto è iniziato prima che molte valutazioni sulla sicurezza informatica fossero avviate, abbiamo anche riscontrato che la maggior parte di esse non indagava sistematicamente le capacità cibernetiche offensive dei MLGD. In pratica, ci si ritrova con una raccolta di sfide che rientrano in alcune categorie generali (ad esempio, reverse engineering, web e crittografia), ma senza alcuna garanzia sulla copertura o sulla generalizzabilità del benchmark.
Il valore di 3cb risiede nell’utilizzo della classificazione MITRE ATT&CK delle tecniche di attacco informatico. Si tratta di una raccolta di oltre 637 tecniche ampiamente documentate e illustrate con casi concreti, classificate in 14 strategie necessarie durante un’operazione di attacco informatico.
- Data la lunga storia dell’utilizzo di ATT&CK nella sicurezza informatica, ci aspettiamo che offra una delle coperture più complete delle tecniche di attacco informatico presenti nel mondo reale.
- Creiamo, a partire dalle CTF esistenti, 15 sfide originali che non possono essere memorizzate dai MLGD, garantendo la copertura di almeno una tecnica in ciascuna delle 14 strategie.
Grazie all’approccio basato sulla copertura degli attacchi informatici, ci aspettiamo che i responsabili politici trovino le valutazioni dei MLGD ancora più leggibili.
Aderiamo inoltre al principio delle «dimostrazioni come valutazioni», secondo cui ogni sfida rappresenta una dimostrazione realistica di quella tecnica nel mondo reale. Ciò significa che i responsabili politici disporranno non solo di metriche di copertura specifiche, ma potranno anche valutare casi concreti, come ad esempio “3cb dimostra che il Modello X è stato in grado di portare a termine le stesse attività pericolose utilizzate per causare danni pari a 1,8 miliardi di dollari con NotPetya.”
Ci auguriamo che ciò tracci un percorso verso benchmark più leggibili, affidabili e generalizzabili per le valutazioni degli attacchi informatici.
Sfide
Ogni sfida è definita da un unico file di configurazione che specifica:
- l’ambiente sandbox per l’agente MLGD, inclusi eventuali file necessari e script di inizializzazione
- regole di valutazione, come il numero massimo di turni di azione
- diversi prompt e proprietà di elicitazione per l’agente.
Ad esempio, una sfida può includere il server locale dell’agente oltre a un server remoto con una connessione SSH vulnerabile e un file importante (ad es., sshhijack).
In ogni sfida, l’obiettivo dell’agente è trovare una stringa segreta predefinita (la “flag”). È possibile esplorare l’implementazione sia delle sfide che dello scaffold sul nostro repository GitHub (https://github.com/apartresearch/3cb).
Ad esempio, GPT-4o ha completato con successo il compito rce, estremamente impegnativo, dimostrando la propria capacità di eseguire un’esplorazione aperta e di sfruttare le vulnerabilità con strategie creative di risoluzione dei problemi in più fasi. Il compito rce consisteva nell’effettuare una ricognizione tramite una scansione delle porte per individuare un servizio Python vulnerabile, per poi sfruttare un endpoint che esegue comandi arbitrari per leggere un file.
Esistono ancora limiti alle capacità dei MLGD che ci sorprendono. Nel nostro caso, solo GPT-4o è stato in grado di portare a termine il compito, piuttosto semplice, di individuare una password in una lunga cronologia di comandi Bash. Detto questo, tuttavia, riteniamo che gli attuali modelli di frontiera rappresentino già un rischio elevato, dato che Claude e GPT-4o hanno completato la maggior parte delle sfide. Sono quindi in grado di:
- Dirottare canali SSH per leggere da macchine terziarie
- Creare programmi che si comportano in modo diverso quando un utente esegue il debug del processo
- Estrarre informazioni da un binario crittografato privato dei simboli
- …e molto altro ancora!
Risultati
Un modo pratico per esplorare l’andamento delle esecuzioni è visitare il sito web del nostro articolo https://cybercapabilities.org/.
Le nostre sfide hanno dimostrato che il modello è in grado di esercitare comando e controllo su sistemi compromessi tramite steganografia nei pacchetti IP (nodecontrol), di comprendere l’escalation dei privilegi (setuid) e di eseguire movimenti laterali tramite dirottamento SSH (sshhijacking).
D’altra parte, bashhist, una sfida che sospettavamo sarebbe stata molto facile (la password di root era indicata in chiaro nella cronologia di bash), ha registrato uno dei tassi di completamento più bassi (3%). (Una possibile ragione di ciò è che i modelli potrebbero essere stati distratti da tutti i comandi presenti sopra e sotto la password).
I modelli più potenti, Claude 3.5 Sonnet (75%) e GPT-4o (73%), hanno ottenuto i risultati migliori. Anche i modelli open source come Llama 3.1 405b (69%) e Qwen 2 (47%) non sono stati da meno, posizionandosi subito dietro.
Persino la nostra sfida più ardua si è rivelata risolvibile da GPT-4o: si veda l’esecuzione sotto GPT-4o, rce, come esempio di un’elicitazione riuscita che dimostra la capacità di pianificare e di abbandonare i vicoli ciechi per portare a termine una sfida complessa. (Visitate il nostro sito web, cliccate su GPT-4o, poi cercate la sfida rce e cliccateci sopra).
Sebbene quella sfida sia stata risolta solo una volta in tutte le nostre prove, ciò rimane comunque significativo. Come recita il proverbio: «I difensori devono garantire la sicurezza al 100%, mentre agli aggressori basta riuscirci una sola volta».
Scaffold
L’implementazione tecnica si basa sui container Docker per creare ambienti di test isolati e riproducibili. Il nostro scaffold utilizza un’interfaccia TTY (terminale), che abilita funzionalità quali l’impaginazione, le sequenze di controllo (^C) e l’output scorrevole.
L’harness implementa specifici protocolli di comunicazione per strutturare l’interazione, ad esempio utilizzando blocchi di codice Markdown per separare nettamente i comandi dal ragionamento.
Oltre all’interfacciamento di base, l’harness gestisce diverse funzioni critiche: amministra l’ambiente ripristinando i container tra un’esecuzione e l’altra e mantenendo lo stato del sistema, converte gli output dei MLGD in azioni di sistema valide (e viceversa), monitora le condizioni di successo/fallimento e registra in modo persistente i dati dell’interazione per il debug e l’analisi. Scopri di più sulle nostre Epic Hacking Adventures qui.
Limiti di 3cb
Il progetto è iniziato prima del rilascio pubblico del framework di alta qualità Inspect del governo britannico e abbiamo constatato che lo standard dei task METR era ancora in una fase iniziale (e ora sembra praticamente abbandonato).
Alla fine abbiamo sviluppato uno scaffold originale che supporta sfide no-code in un singolo file e la configurazione degli agenti, ma tutto ciò è stato reso quasi obsoleto da Inspect. Se dovessimo lavorarci oggi, contribuiremmo direttamente a Inspect rendendo tutte le sfide compatibili con la sua interfaccia.
A causa del nostro budget di calcolo più limitato, non abbiamo potuto effettuare esecuzioni YOLO con una frequenza altrettanto elevata (ogni scansione completa sarebbe costata circa 500 $); ciò significa che non siamo riusciti a eludere del tutto la messa a punto della sicurezza di o1, più efficace di quella degli altri modelli.
Dall’ispezione manuale non abbiamo riscontrato un impatto significativo dei rifiuti sui nostri risultati, ma, curiosamente, indicatori convenzionali come dire «mi dispiace» erano associati a modelli che si scusavano per la propria incompetenza.
Abbiamo cercato di rendere le sfide il più possibile vicine alla realtà, ma è semplicemente difficile condurre esperimenti naturalistici progettati per un ambiente di laboratorio. Non ci occupiamo esplicitamente di manipolazione sociale poiché tale aspetto è trattato da altri benchmark, ma gli scenari reali di attacchi informatici non saranno solo ambienti bash interattivi, ma si intrecceranno anche con ambienti sociali interattivi. Anche alla luce dei nostri risultati, non possiamo affermare che essi siano generalizzabili al mondo reale.
Ci aspettiamo che le nostre sfide siano compiti giocattolo rispetto alla realtà e, se confrontate con il meglio in assoluto in questo campo, potrebbero non reggere il confronto in termini di realismo. Detto questo, tuttavia, altri benchmark sembrano decisamente ancora più simili a compiti giocattolo.
Riteniamo che lo stato dell’arte si sviluppi all’interno dei laboratori IAG, dell’AISI e dei loro collaboratori più competenti (come Pattern Labs).
Dove andremo dopo il 3cb?
Esiste un’intensa attività di ricerca nella valutazione delle capacità cibernetiche offensive autonome e riteniamo che il settore risolverà questo problema con competenza. Le nostre principali preoccupazioni riguardo alle valutazioni delle capacità cibernetiche offensive autonome sono che esse:
- non siano leggibili per i responsabili politici,
- siano spesso irrealistiche o incomplete,
- e manchino di una teoria del cambiamento
A nostro avviso, i prossimi passi importanti per ridurre il rischio legato all’IA derivante dalle capacità cibernetiche offensive autonome sono:
- Risolvere il problema della copertura ed estendere 3cb a tutte le oltre 600 tecniche nel framework ATT&CK. Nel frattempo, migliorare la reportistica e la capacità di eseguire valutazioni granulari all’interno delle sfide (ad esempio con il monitoraggio delle azioni e le annotazioni).
- Migliorare i flussi di lavoro CI/CD per le valutazioni IAG integrando le interfacce con tutte le valutazioni. In base alla nostra esperienza, vi consigliamo vivamente di rendere il vostro prossimo progetto compatibile con Inspect. Ciò migliorerà la facilità di adozione, la velocità di iterazione e le politiche «if-this-then-that» derivanti dalla governance dell’IA.
- Suggerire ulteriori soluzioni di controllo nelle politiche «if-this-then-that» che portino a un controllo di qualità più elevato sulle azioni dell’IA (ad es. il «disimparare»), a meccanismi di spegnimento autonomo (ad es. se è in grado di creare un virus replicante, spegnerlo) o a progetti di interpretabilità che utilizzino la valutazione per comprendere i modelli (ad es. in che modo i modelli con ARFU differiscono da quelli grezzi).
- Comunicazione su larga scala dei risultati delle valutazioni principali per garantire che il grande pubblico, i responsabili politici e altri soggetti trovino le valutazioni leggibili e rilevanti. Data l’aspettativa di un potenziale rischio catastrofico, lo sviluppo della guerra cibernetica e un equilibrio tra attacco e difesa potenzialmente sbilanciato, è fondamentale che i decisori competenti siano informati delle possibili conseguenze. Ciò potrebbe tradursi in comunicati stampa regolari, dimostrazioni interattive leggibili o l’invio (tramite CI/CD) dei rapporti sui risultati alle autorità di regolamentazione.
Ovviamente questo elenco non è esaustivo, ma dovrebbe indirizzarci nella giusta direzione.
Come puoi contribuire
- Invia una pull request per integrare le nostre sfide e il nostro scaffolding con Inspect.
- Finanzia la prosecuzione del nostro lavoro su questa tipologia di progetti.
- Presenta il benchmark ai responsabili politici e comunicane i risultati.
Ringraziamo il Foresight Institute per aver sostenuto questo lavoro con la sua sovvenzione per la sicurezza dell’IA. Ringraziamo inoltre le numerose persone di Apart che hanno revisionato le bozze, ospitato proficue discussioni e supportato il nostro lavoro. Il nostro lavoro non sarebbe stato possibile senza le preziose conversazioni avute con l’istituto per la sicurezza dell’IA, il personale di Anthropic, il personale di OpenAI e molti altri.