Con il crescente ruolo dell’intelligenza artificiale (IA) in vari settori, la domanda sul suo impatto sul mercato del lavoro nella cybersecurity sta diventando sempre più rilevante. Da un lato, l’automazione e i sistemi intelligenti possono accelerare e migliorare notevolmente i processi di protezione dei dati e delle infrastrutture IT. Dall’altro lato, c’è la preoccupazione che l’IA possa sostituire le persone in alcune funzioni, riducendo così il numero di posti di lavoro disponibili. Dalle mie osservazioni fino ad oggi, sarà esattamente il contrario (almeno per i professionisti della sicurezza)!
Le potenzialità dell’IA nella cybersecurity
L’IA ha la capacità di analizzare enormi quantità di dati in breve tempo, cosa fondamentale nella cybersecurity, dove la rapidità di reazione alle minacce è spesso decisiva. Gli algoritmi di machine learning possono rilevare minacce precedentemente sconosciute basandosi sull’analisi dei pattern comportamentali e dei dati storici. Questo permette di identificare e rispondere più rapidamente e con maggiore precisione agli incidenti di sicurezza. L’automazione dei processi di analisi e risposta alle minacce può portare a una riduzione dei posti di lavoro per gli analisti di sicurezza di livello inferiore, che si occupano di monitoraggio e risposta agli allarmi di routine. D’altra parte, emergono nuove specializzazioni come l’ingegneria del machine learning nella cybersecurity, la gestione di sistemi di difesa intelligenti o l’analisi delle minacce avanzate con l’uso dell’IA. Gli specialisti dovranno non solo comprendere il funzionamento dei moderni strumenti di IA, ma anche essere in grado di svilupparli e adattarli alle specifiche esigenze di sicurezza.
Automazione del codice = più errori di sicurezza + nuove classi di vulnerabilità
Introduzione di errori tramite strumenti automatici
Mai prima d’ora creare applicazioni è stato così semplice, accessibile a persone non tecniche e veloce. Questo causa un “boom” di molte nuove applicazioni. Ciò è accompagnato anche da un aumento dell’integrazione di elementi IA nel software esistente. Tuttavia, l’automazione, in particolare sotto forma di generatori di codice o framework di sviluppo, può portare alla creazione di errori non intenzionali e falle di sicurezza. Questi strumenti, operando su schemi e algoritmi prestabiliti, possono non considerare condizioni specifiche o sfumature di sicurezza che sono comprese e applicate da programmatori esperti. Ad esempio, il codice generato automaticamente potrebbe non essere adeguatamente protetto contro attacchi come SQL Injection o Cross-site Scripting (XSS), se lo strumento non è configurato correttamente per considerare queste minacce.
XSS in Zoomin Zdocs
Un esempio di tale errore, dove l’IA viene implementata rapidamente, è il semplice “Reflected Cross-site Scripting” che ho trovato nell’applicazione Zoomin Zdocs. Sembra una buona idea introdurre un assistente IA per la gestione della documentazione di un’applicazione, dove possiamo porre domande per capire come utilizzare il software. Tuttavia, bisogna ricordare che le risposte dell’IA possono essere in qualche modo imprevedibili e causare errori di sicurezza. Nell’applicazione Zoomin, bastava chiedere all’assistente cosa ne pensava di:
<img src=1 href=1 onerror="javascript:alert(document.domain)"></img>?
perché rispondesse di non poter trovare una risposta alla nostra domanda, citandola
I'm sorry, but I couldn't find a definitive answer to: <img src=1 href=1 onerror="javascript:alert(document.domain)"></img>?. Please provide more context or clarify your query.
L’intera richiesta appariva così:
POST /api/aisearch/stream HTTP/1.1 |
Risposta del server:
HTTP/2 200 OK |
Come si può vedere, i dati di input non sono stati validati e sanitizzati correttamente, portando all’esecuzione del codice JavaScript iniettato:
Esempio di pseudocodice con visualizzazione errata della risposta:
function displayResponse(userInput):
# Leggi i dati di input dall'utente
query = userInput
# Visualizza la risposta senza sanitizzazione dei dati di input
# Questo è errato, poiché consente l'esecuzione dello script contenuto in userInput
print("Risposta alla tua domanda: " + query)
Esempio di pseudocodice con visualizzazione corretta della risposta:
function sanitize(input):
# Rimuovi o codifica i caratteri speciali HTML nei dati di input, ad es. <, >, ", ' e altri
return input.replace("<", "<").replace(">", ">").replace("\"", """).replace("'", "'")
function displayResponse(userInput):
# Leggi i dati di input dall'utente
query = userInput
# Sanitizza i dati di input
safeQuery = sanitize(query)
# Visualizza la risposta in modo sicuro
# La sanitizzazione previene l'esecuzione di codice maligno
print("Risposta alla tua domanda: " + safeQuery)
La vulnerabilità (insieme a molte altre) è stata segnalata e corretta dal produttore.
Ripetizione degli errori
Uno dei principali difetti dell’automazione è la replicazione dello stesso codice in molti luoghi, che può portare alla diffusione di errori o vulnerabilità su larga scala. Quando un errore si trova in un componente che genera codice (e l’IA può essere addestrata su codice con errori), ogni applicazione o sistema che utilizza quel codice è potenzialmente vulnerabile. Questo fenomeno scala il problema della sicurezza, rendendolo più difficile da gestire e correggere.
Difficoltà nell’audit e nella revisione del codice
Il codice generato automaticamente è spesso complesso o creato in modo non intuitivo per i programmatori “umani”. Questo può rendere difficili le revisioni manuali del codice, che sono cruciali per identificare errori logici sottili o vulnerabilità di sicurezza. La mancanza di trasparenza e comprensione del codice generato può portare a trascurare problemi importanti durante i test di sicurezza.
Nuove classi di vulnerabilità
L’automazione può introdurre nuove classi di vulnerabilità che sarebbero meno probabili nel caso della creazione manuale del codice. Ad esempio, le dipendenze tra moduli generati automaticamente potrebbero non essere completamente comprese o controllate dai programmatori, aprendo la strada ad attacchi legati alle dipendenze e alla logica delle applicazioni. Emergono anche nuove classi di vulnerabilità come l’injection di prompt.
OWASP Top 10 for Large Language Model Applications
Un anno fa OWASP ha iniziato a lavorare per identificare e fornire raccomandazioni per proteggersi dalle principali minacce derivanti dall’uso di LLM – OWASP Top 10 for LLLM. L’elenco è il seguente:
LLM01: Injection di prompt
Manipolazione di un modello di linguaggio ampio (LLM) tramite input appropriati che causano azioni non intenzionali del LLM. Le injection dirette sovrascrivono i prompt di sistema, mentre le injection indirette manipolano i dati da fonti esterne.
LLM02: Gestione non sicura degli output
La vulnerabilità si verifica quando l’output di un LLM è accettato senza controllo, esponendo i sistemi backend. L’abuso può portare a conseguenze gravi come XSS, CSRF, SSRF, escalation dei privilegi o esecuzione remota di codice.
LLM03: Avvelenamento dei dati di addestramento
Si verifica quando i dati di addestramento del LLM vengono manipolati, introducendo vulnerabilità o errori che influenzano la sicurezza, l’efficacia o il comportamento etico. Le fonti includono Common Crawl, WebText, OpenWebText e libri.
LLM04: Evasione del modello
Gli aggressori causano operazioni ad alto consumo di risorse su LLM, portando a una degradazione del servizio o a costi elevati. La vulnerabilità è aggravata dall’intensità delle risorse di LLM e dall’imprevedibilità degli input degli utenti.
LLM05: Vulnerabilità della supply chain
Il ciclo di vita delle applicazioni LLM può essere compromesso da componenti o servizi vulnerabili, portando ad attacchi di sicurezza. L’uso di set di dati esterni, modelli pre-addestrati e plugin può aumentare il numero di vulnerabilità.
LLM06: Divulgazione di informazioni riservate
LLM può rivelare inavvertitamente dati riservati nelle sue risposte, portando a accessi non autorizzati, violazioni della privacy e problemi di sicurezza. È fondamentale implementare la sanitizzazione dei dati e politiche d’uso rigorose per prevenire ciò.
LLM07: Progettazione insicura dei plugin
I plugin LLM possono avere input non sicuri e controlli di accesso insufficienti. La mancanza di controlli applicativi facilita lo sfruttamento e può portare a conseguenze come l’esecuzione remota di codice.
LLM08: Eccessiva autonomia
I sistemi basati su LLM possono intraprendere azioni che portano a risultati non intenzionali. Il problema deriva dall’eccessiva funzionalità, dai troppi privilegi o dall’autonomia concessa ai sistemi basati su LLM.
LLM09: Dipendenza eccessiva
Sistemi o persone che dipendono troppo da LLM senza supervisione possono essere esposti a disinformazione, errori di comunicazione, problemi legali ed errori di sicurezza a causa di contenuti non corretti o inappropriati generati da LLM.
LLM10: Furto del modello
Riguarda l’accesso non autorizzato, la copia o il furto di modelli proprietari LLM. L’impatto include perdite economiche, perdita del vantaggio competitivo e potenziale accesso a informazioni riservate.
Cosa fare? Come vivere?
OWASP, insieme alla lista Top 10 for LLLM, ha rilasciato una serie di raccomandazioni per un approccio sicuro all’implementazione di LLM nella propria organizzazione – LLM AI Cybersecurity & Governance Checklist. Di seguito presento quelle relative alla programmazione:
- Modella le minacce per i componenti LLM e definisci i confini di fiducia dell’architettura.
- Sicurezza dei dati: verifica come i dati vengono classificati e protetti in base alla loro sensibilità, inclusi i dati personali e aziendali. (Come vengono gestiti i permessi degli utenti e quali meccanismi di protezione sono implementati?)
- Controllo degli accessi: implementa controlli degli accessi secondo il principio del privilegio minimo e applica misure di difesa stratificata.
- Sicurezza del processo di addestramento: richiedi un controllo rigoroso della gestione dei dati di addestramento, dei processi, dei modelli e degli algoritmi.
- Sicurezza degli input e degli output: valuta i metodi di validazione degli input e il modo in cui gli output vengono filtrati, sanitizzati e convalidati.
- Monitoraggio e risposta: mappa il flusso di lavoro, monitora e rispondi per comprendere l’automazione, garantisci il logging e l’audit. Conferma la sicurezza dei registri di audit.
- Includi il test delle applicazioni, la revisione del codice sorgente, il processo di valutazione delle vulnerabilità e i test di penetrazione nel processo di sviluppo del prodotto.
- Verifica le vulnerabilità esistenti nel modello LLM o nella supply chain.
- Considera l’impatto delle minacce e degli attacchi sulle soluzioni LLM, come l’injection di prompt, la divulgazione di informazioni sensibili e la manipolazione del modello.
- Esamina l’impatto degli attacchi e delle minacce sui modelli LLM, inclusi l’avvelenamento del modello, la gestione impropria dei dati, gli attacchi alla supply chain e il furto del modello.
- Sicurezza della supply chain: richiedi audit di terze parti, test di penetrazione e revisioni del codice per i fornitori esterni (sia all’inizio che nel processo regolare).
- Sicurezza dell’infrastruttura: chiedi quanto spesso il fornitore esegue test di resilienza? Quali sono i loro SLA in termini di disponibilità, scalabilità e prestazioni?
- Aggiorna i manuali di risposta agli incidenti e includi gli incidenti legati a LLM negli scenari di esercitazioni di sicurezza continuativa.
- Identifica o espandi le metriche per confrontare l’IA generativa nella cybersecurity con altri approcci per misurare i miglioramenti delle prestazioni attesi.
