LLM Security by Design: Coinvolgere la sicurezza in ogni fase dello sviluppo

Poiché i modelli linguistici di grandi dimensioni (LLM) sono sempre più diffusi nelle aziende e nelle applicazioni, la necessità di misure di sicurezza robuste non è mai stata così grande. Un LLM, se non adeguatamente protetto, può comportare rischi significativi in termini di violazione dei dati, manipolazione del modello e persino problemi di conformità normativa. È qui che il coinvolgimento di una società di sicurezza esterna diventa fondamentale.

In questo blog esploreremo le considerazioni chiave per le aziende che desiderano assumere un team di sicurezza per valutare e proteggere i loro sistemi alimentati da LLM, nonché i compiti specifici che dovrebbero essere intrapresi nelle diverse fasi del ciclo di vita dello sviluppo di LLM.

Fase 0: Modello di hosting (fisico vs. cloud)

La scelta del modello di hosting, fisico o basato sul cloud, può avere implicazioni significative per la sicurezza di un modello linguistico di grandi dimensioni (LLM). Ogni approccio comporta una serie di considerazioni sulla sicurezza che devono essere valutate attentamente.

Preoccupazioni di sicurezza fisica:

• Sicurezza fisica e del centro dati - Ospitare un modello LLM su un'infrastruttura fisica introduce rischi come l'accesso non autorizzato alla struttura, il furto o l'interruzione dei sistemi critici. Queste minacce possono derivare non solo da vulnerabilità tecniche, ma anche da fattori umani, come l'ingegneria sociale o il pedinamento. Per mitigare questi rischi, è necessario condurre un test di penetrazione fisica. Questo include la simulazione di tentativi di intrusione reali, come l'impersonificazione o l'aggiramento del personale, nonché la valutazione della resilienza delle barriere fisiche, dei sistemi di sorveglianza, dei controlli di accesso e delle protezioni ambientali (ad esempio, l'alimentazione e la protezione antincendio).
  
• Sicurezza della rete - Le implementazioni LLM on-premise sono particolarmente vulnerabili ai cyberattacchi esterni e alle minacce interne se l'architettura di rete sottostante non è ben protetta. Firewall mal configurati, servizi esposti o controlli di accesso troppo permissivi possono aprire la porta allo sfruttamento. Per affrontare in modo proattivo questi rischi, è necessario condurre un'accurata revisione dell'architettura di rete e una valutazione della sicurezza. Ciò include la valutazione della segmentazione, delle regole del firewall, dell'accesso VPN, delle capacità di rilevamento delle intrusioni e dei controlli di accesso, per garantire che l'ambiente LLM sia protetto da compromissioni sia esterne che interne.
  
• Rischi della catena di fornitura - I modelli di LLM ospitati on-premise si basano molto sui componenti hardware, che possono introdurre rischi se provengono da fornitori non affidabili o non verificati. Chip compromessi, firmware maligni o dispositivi manomessi potrebbero minare l'integrità dell'intero sistema. Per ridurre questo rischio, un team di sicurezza dovrebbe eseguire una revisione completa della catena di approvvigionamento, valutando le pratiche di approvvigionamento, verificando l'affidabilità del fornitore, ispezionando fisicamente i componenti hardware e convalidando l'integrità del firmware/software, per garantire che l'infrastruttura sia priva di minacce incorporate e aderisca ai principi di approvvigionamento sicuro.

Rischi di sicurezza dell'hosting basato sul cloud:

• Configurazioni errate nel cloud - Quando un LLM è ospitato nel cloud, la postura di sicurezza dipende fortemente da come vengono configurati i servizi del cloud. A differenza degli ambienti fisici, dove le organizzazioni hanno il pieno controllo dell'hardware e dei livelli di rete, gli ambienti cloud introducono l'astrazione e, di conseguenza, una serie di rischi diversi. Risorse mal configurate, come bucket S3 aperti, ruoli IAM troppo permissivi o endpoint API non protetti, possono esporre dati di formazione sensibili, artefatti di modelli o credenziali. Per affrontare questo problema, i team di sicurezza dovrebbero condurre una revisione completa della configurazione del cloud. Ciò comporta l'audit delle autorizzazioni di archiviazione, delle politiche di gestione dell'identità e dell'accesso, delle impostazioni di sicurezza della rete e degli endpoint esposti, per identificare e correggere le configurazioni errate che potrebbero portare ad accessi non autorizzati o alla perdita di dati.
  
• Disallineamento della responsabilità condivisa - Uno degli aspetti più importanti - e spesso trascurati - della sicurezza del cloud è la comprensione del modello di responsabilità condivisa. A differenza dell'hosting fisico, dove l'organizzazione possiede l'intero stack di sicurezza, i fornitori di cloud proteggono l'infrastruttura, mentre i clienti sono responsabili della protezione dei loro dati, applicazioni e configurazioni. L'incomprensione di questa divisione può causare asset non protetti o punti ciechi nella copertura della sicurezza. I team di sicurezza possono essere d'aiuto tracciando chiaramente le responsabilità, sviluppando il giusto set di controlli di sicurezza e implementando processi che assicurino che tutti i componenti dell'ambiente LLM, specialmente quelli gestiti dai clienti, siano adeguatamente protetti.
  
• Minacce interne - Sebbene sia raro, esiste il rischio che i dipendenti dei fornitori di cloud possano abusare dell'accesso privilegiato. Per affrontare questo problema, le organizzazioni devono applicare una crittografia forte e controlli di accesso basati sui ruoli e implementare un monitoraggio dettagliato e una registrazione di audit. I team di sicurezza possono aiutarla verificando che i dati sensibili siano crittografati a riposo e in transito, e che qualsiasi accesso dal lato del provider sia trasparente e registrato.
  
• Compliance normativa - L'hosting di LLM nel cloud può introdurre requisiti normativi aggiuntivi in base al settore e all'area geografica (ad esempio, GDPR, HIPAA, ecc.). I team che si occupano di sicurezza devono valutare gli obblighi normativi e progettare un quadro di Compliance che includa controlli sulla residenza dei dati, politiche di crittografia, auditing degli accessi e procedure di risposta alle violazioni. In questo modo si assicura che l'ambiente LLM sia in linea con gli standard legali e le best practice del settore.

Nel valutare il modello di hosting per un LLM, le organizzazioni devono valutare attentamente i rischi e i controlli di sicurezza associati agli approcci fisici e basati sul cloud. Una comprensione approfondita delle implicazioni di sicurezza, nonché dei requisiti e dei vincoli specifici dell'organizzazione, è fondamentale per determinare la soluzione di hosting più appropriata. Le seguenti fasi sono applicabili, sia che si utilizzi un modello di hosting fisico o cloud.

Fase 1: Curatela dei dati

La qualità di un modello linguistico di grandi dimensioni è direttamente legata alla qualità dei dati su cui viene addestrato. Sebbene la cura dei dati sia tipicamente uno sforzo di scienza dei dati e di ingegneria, possono comunque emergere rischi di sicurezza. Dal punto di vista della sicurezza, questo è un punto critico per rivedere l'affidabilità delle fonti di dati e implementare controlli che salvaguardino il modello dall'avvelenamento, dalle violazioni della privacy e dai risultati distorti.

• Rischi di avvelenamento dei dati - La formazione su dati non verificati o avversari può introdurre in un LLM vulnerabilità nascoste, pregiudizi o persino comportamenti dannosi. Questo è particolarmente preoccupante quando si utilizzano fonti pubbliche di Internet o set di dati forniti dalla comunità. I team di sicurezza dovrebbero condurre una revisione dell'architettura e/o un modello di minaccia per valutare i flussi di lavoro di ingestione dei dati. Queste revisioni aiutano a identificare i punti deboli in cui gli attori malintenzionati potrebbero inserire dati avvelenati e a garantire che l'organizzazione applichi controlli come la convalida dei dati, il whitelisting dei domini e il monitoraggio dei contenuti anomali.
  
• Violazioni della privacy e della conformità - Gli insiemi di dati pubblici spesso includono contenuti generati dagli utenti che possono contenere informazioni di identificazione personale (PII) o altri dati sensibili, che potrebbero portare a non conformità normativa o a violazioni della privacy. I professionisti della sicurezza dovrebbero lavorare a stretto contatto con i team che si occupano dei dati per esaminare i meccanismi di redenzione e filtraggio della privacy della pipeline. Ciò comporta la verifica dell'esistenza di strumenti basati su regole e classificatori per rilevare e rimuovere le PII e che questi processi siano regolarmente controllati per verificarne l'efficacia.
  
• Avvelenamento a livello di embedding - Anche dopo la pulizia standard, gli input avversari possono persistere attraverso i livelli di embedding, introducendo sottili cambiamenti nel modo in cui il modello interpreta determinati contenuti. Sebbene sia difficile da rilevare, questo rischio emergente può essere mitigato attraverso una valutazione avversaria guidata dalla ricerca o dal coordinamento con i team rossi che si concentrano sul comportamento dell'embedding LLM. La sicurezza dovrebbe essere coinvolta nelle discussioni sulla progettazione del tokenizer e sulla robustezza dell'embedding per i modelli ad alto rischio.

Fase 2: Architettura del modello

In questa fase, l'organizzazione sta selezionando e/o progettando l'architettura neurale che definirà il modo in cui l'LLM apprende e genera l'output. La maggior parte dei moderni LLM sono costruiti su architetture di trasformatori. Sebbene queste decisioni architettoniche siano principalmente tecniche, hanno implicazioni significative per la sicurezza. Se non controllate, le vulnerabilità introdotte nel livello del modello, soprattutto nei modelli open-source, possono diventare minacce permanenti e persistenti. Sebbene questa fase non coinvolga tradizionalmente i professionisti della sicurezza, il loro inserimento precoce consente una difesa preventiva contro i rischi profondamente radicati.

• Componenti del modello nascosti - Se un aggressore ottiene l'accesso durante la formazione o modifica un modello open-source, potrebbe introdurre un comportamento dannoso direttamente nell'architettura del modello. Ad esempio, un livello di decodifica modificato in un modello basato su trasformatori potrebbe essere progettato per emettere contenuti retrodatati specifici quando viene attivato da determinate richieste. Per mitigare questo problema, i team di sicurezza dovrebbero condurre una revisione dell'architettura incentrata sull'integrità del modello. Ciò include la convalida della provenienza della formazione, l'esame dei livelli critici del modello per verificare la presenza di modifiche non autorizzate e l'individuazione di comportamenti sospetti nelle richieste di test controllati.
  
• Integrità del modello e fiducia nell'open source - Molte organizzazioni utilizzano modelli open source per accelerare lo sviluppo. Tuttavia, questi modelli possono presentare problemi di fiducia se i dati di formazione, l'architettura o la cronologia delle modifiche non sono trasparenti. I team di sicurezza dovrebbero implementare flussi di lavoro di vetting e auditing dei modelli per verificare la fonte, il percorso di formazione e qualsiasi modifica preapplicata prima che il modello venga distribuito o ulteriormente perfezionato.
  
• Scelte architettoniche che migliorano la sicurezza - Mentre la maggior parte dei team si concentra sulla precisione o sull'efficienza, alcune scelte architettoniche possono migliorare la sicurezza. Ad esempio, l'integrazione di moduli di rilevamento delle anomalie o la progettazione del modello per supportare la formazione avversaria possono migliorare la resilienza agli attacchi futuri. I professionisti della sicurezza dovrebbero consigliare o raccomandare componenti architettonici incentrati sulla sicurezza durante le prime conversazioni di progettazione, soprattutto nelle implementazioni ad alto rischio o critiche per la sicurezza.

Fase 3: Formazione su scala

Poiché l'LLM viene addestrato su scala, non c'è molto da fare per il team di sicurezza, se prima ha eseguito una revisione approfondita dell'architettura e dei modelli di minaccia. Dovrebbe concentrarsi sull'assicurare che il processo di formazione stesso sia sicuro e stabile:

• Esaminare la sicurezza dell'infrastruttura di formazione - Valutare i controlli fisici, di rete e di accesso in atto per proteggere l'ambiente di formazione da accessi non autorizzati o interruzioni.

Fase 4: Valutazione

Durante la fase di valutazione, le prestazioni dell'LLM vengono valutate utilizzando set di dati di riferimento per misurare la sua conoscenza, il suo ragionamento e la sua precisione in diversi compiti. I benchmark comuni includono Hellaswag (ragionamento di senso comune), MMLU (conoscenza specifica del dominio) e TruthfulQA (veridicità e resistenza alle idee sbagliate). Sebbene questi strumenti siano utili per misurare le prestazioni generali, introducono anche una superficie unica per i rischi di sicurezza. In questa fase, i professionisti della sicurezza si concentrano principalmente nel garantire che le pratiche di valutazione siano affidabili, prive di contaminazioni e non soggette a manipolazione.

• Contaminazione della valutazione - Gli aggressori possono tentare di manipolare il processo di valutazione inserendo domande di riferimento (ad esempio, da Hellaswag o MMLU) nel corpus di pre-addestramento del modello. Se non viene individuato, questo può gonfiare in modo significativo i punteggi dei benchmark e dare una falsa impressione della qualità del modello. I team di sicurezza dovrebbero collaborare con gli ingegneri ML per implementare il rilevamento della contaminazione dei benchmark, verificando che nessun dato di valutazione sia trapelato o memorizzato durante l'addestramento.
  
• Fiducia nei valutatori e nei benchmark - Non tutti i benchmark sono uguali e alcuni possono mancare di rigore o di trasparenza. Affidarsi a benchmark mal costruiti o troppo ristretti può dare luogo a metriche di performance fuorvianti. I professionisti della sicurezza devono contribuire a vagliare gli strumenti di valutazione e i set di dati, assicurandosi che provengano da fonti affidabili, che siano ben mantenuti e che siano in linea con gli obiettivi e la tolleranza al rischio dell'organizzazione.
  
• Integrità del Processo di valutazione - Gli script di valutazione, i set di dati e la logica dei punteggi possono essere manomessi se non sono adeguatamente protetti. I team di sicurezza devono esaminare l'infrastruttura di valutazione, assicurandosi che l'accesso sia limitato, che il controllo delle versioni sia in atto e che i risultati siano riproducibili e verificabili per mantenere la fiducia nei risultati.

Fase 5: Miglioramenti successivi

Quando l'LLM matura oltre la sua formazione di base, i team spesso lo migliorano con la messa a punto, la Generazione Aumentata dal Recupero (RAG) e l'ingegneria richiesta per migliorare le prestazioni, introdurre competenze nel dominio o integrare conoscenze in tempo reale. Se da un lato questi miglioramenti sbloccano potenti capacità, dall'altro creano nuovi problemi di sicurezza, soprattutto quando si tratta di dati sensibili o di applicazione di policy. In questa fase, il ruolo del team di sicurezza è quello di valutare il modo in cui queste tecniche vengono implementate e garantire che il controllo degli accessi, la gestione delle risposte e le salvaguardie etiche non vengano compromesse nel processo.

• Rischi legati alla messa a punto - La messa a punto di un modello su dati sensibili o proprietari senza le dovute protezioni può esporre involontariamente informazioni riservate agli utenti finali. Ad esempio, la messa a punto di un modello su rapporti governativi interni o sui dati dei clienti senza un controllo degli accessi a livello di chat può provocare divulgazioni non autorizzate. I team di sicurezza devono rivedere i set di dati di fine-tuning e assicurarsi che i limiti di accesso controllati siano applicati agli output del modello, soprattutto quando i modelli sono distribuiti in ambienti multiutente.
  
• Misconfigurazioni dell'integrazione RAG - RAG (Retrieval Augmented Generation) estende la conoscenza di un LLM recuperando il contesto da una base di conoscenza personalizzata, ma se i controlli di accesso non sono implementati al livello di recupero, i dati sensibili possono essere divulgati. Ad esempio, un utente potrebbe essere in grado di accedere ai dati finanziari di un altro utente se il sistema RAG recupera i documenti in modo indiscriminato. I team di sicurezza devono valutare l'implementazione del RAG per quanto riguarda l'applicazione dei controlli di accesso, l'individuazione dei documenti e la verificabilità dei contenuti recuperati.
  
• Risultati RAI (Intelligenza Artificiale Responsabile) dopo la messa a punto - Se da un lato la messa a punto può rafforzare la sicurezza del modello, dall'altro può rendere più difficile il rilevamento di comportamenti indesiderati o di violazioni delle policy, soprattutto se il modello ha imparato a evitare sottilmente il rilevamento. I professionisti della sicurezza dovrebbero collaborare con i team RAI per verificare la presenza di bypass di prompt avversari e di violazioni della sicurezza in casi limite, anche su modelli che sono stati messi a punto per l'allineamento.
  
• Area di superficie dell'ingegneria dei prompt - I prompt o le istruzioni di sistema mal progettati possono portare a un comportamento indesiderato del modello o creare vulnerabilità di iniezione dei prompt, soprattutto quando i modelli sono integrati nelle applicazioni. Sebbene l'ingegneria dei prompt sia generalmente considerata una tecnica a basso rischio, i team di sicurezza dovrebbero rivedere i prompt di sistema e la costruzione dei prompt a livello di applicazione per garantire che siano resistenti agli input avversari e che non sovrascrivano i comportamenti critici di sicurezza.

Fase 6: Integrazione API

A questo punto del ciclo di vita, l'LLM passa da un chatbot passivo a un componente di sistema attivo che può interagire con applicazioni e servizi del mondo reale tramite API. Che si tratti di reimpostare le password, di recuperare dati interni o di elaborare le richieste degli utenti, l'integrazione API introduce una nuova potenza significativa e un rischio corrispondente. Dal punto di vista della sicurezza, questa è la fase in cui i principi tradizionali di sicurezza delle API convergono con le preoccupazioni specifiche del LLM, come la prompt injection, l'esecuzione indiretta e la manipolazione dell'intento. Diventa una delle fasi più critiche per i test offensivi, soprattutto quando le applicazioni guidate da LLM iniziano a prendere decisioni e ad agire per conto degli utenti.

• Problemi di autenticazione e autorizzazione - Quando gli LLM iniziano ad attivare chiamate API, è fondamentale verificare che solo gli utenti autorizzati possano eseguire azioni sensibili. I team che si occupano di sicurezza devono garantire un'autenticazione forte (ad esempio, OAuth, chiavi API) e autorizzazioni mirate, in modo che il modello non possa eseguire azioni privilegiate per conto di utenti non autorizzati.
  
• Iniezione di prompt e abuso di API - Gli LLM interpretano il linguaggio naturale e decidono quale API chiamare in base all'input dell'utente. Gli aggressori possono cercare di manipolare i prompt per innescare comportamenti indesiderati o dannosi. I team di sicurezza devono testare le vulnerabilità di prompt injection, assicurandosi che il modello non possa essere indotto a chiamare l'API sbagliata o a bypassare i controlli di sicurezza.
  
• Mancanza di convalida degli input - Se gli input dell'utente passati alle API non sono convalidati in modo appropriato, possono portare a errori, fughe di dati o persino attacchi di iniezione. I team di sicurezza devono verificare che i livelli middleware e API convalidino e sanifichino tutti gli input, indipendentemente dal fatto che provengano da un utente o dall'LLM.
  
• Funzionalità sovraesposte - Le API possono esporre più funzionalità di quelle necessarie all'LLM, aumentando il rischio di uso improprio. La sicurezza dovrebbe applicare il principio del minimo privilegio, dando al modello l'accesso solo agli endpoint di cui ha veramente bisogno.
  
• Rischi rilevanti di OWASP LLM - Molti rischi di questa fase si allineano con i rischi principali di OWASP. Gli esperti di sicurezza dovrebbero fare riferimento all'elenco come guida per i test.

Conclusione

La sicurezza di un LLM è una sfida complessa e sfaccettata che richiede un approccio completo, fase per fase. Collaborando con un team di sicurezza esperto, le aziende possono navigare tra le considerazioni di sicurezza uniche dello sviluppo e dell'implementazione di un LLM, assicurando che i loro modelli siano robusti, affidabili e conformi alle normative pertinenti e agli standard del settore. Dando priorità alla sicurezza fin dall'inizio, le organizzazioni possono sbloccare il pieno potenziale degli LLM salvaguardando i loro dati, i loro sistemi e la loro reputazione.