Sintesi Tecnica: Framework CyberLLM per la Cybersecurity Automobilistica

1. Definizione del Problema

La transizione verso i Veicoli Definiti dal Software (SDV) ha ampliato significativamente la superficie di attacco automobilistica, introducendo vulnerabilità attraverso codice sorgente, log di runtime e topologie di deployment. Sebbene i Large Language Models (LLM) offrano il potenziale per ragionare su questi artefatti eterogenei e proporre rimediazioni, la loro applicazione in ambienti critici per la sicurezza affronta due sfide primarie:

1. Natura Probabilistica: Gli LLM possono generare allucinazioni sulle scoperte o mancare di rilevare problemi, rendendoli inaffidabili come unica base per decisioni di sicurezza.
2. Vincoli di Sicurezza (Safety): Gli agenti autonomi che agiscono sui veicoli non devono mai eseguire azioni insicure o non autorizzate, anche quando gli input sono manipolati in modo avversariale (ad esempio, tramite prompt injection o avvelenamento della memoria).

Gli strumenti attuali tipicamente affrontano questi livelli in isolamento utilizzando scanner basati su regole o revisioni manuali, mancando della capacità di ragionare tra i livelli o di agire autonomamente con supervisione. È necessario un framework che bilanci il rilevamento autonomo con un involucro di sicurezza deterministico e verificabile.

2. Metodologia: Il Framework CyberLLM

CyberLLM è un framework multi-agente, orchestrato da LLM, progettato per rilevare autonomamente vulnerabilità ed eseguire rimediazioni sotto una guardia di sicurezza formale a runtime. Il sistema opera su una pipeline guidata da schemi dove ogni agente deriva da un BaseAgent comune, garantendo la provenienza obbligatoria per tutti gli input.

A. Architettura di Rilevamento a Livelli

La fase di rilevamento fonde l'analisi deterministica con il raffinamento tramite LLM per ottenere un alto richiamo (recall) senza sacrificare la precisione:

• Pavimento Deterministico (Deterministic Floor): Un livello "sempre attivo" composto da:
  • Regole Regex: Pattern multiriga e case-insensitive per il codice.
  • Analizzatori AST: Esecuzione in sandbox di strumenti come Bandit (Python) e Semgrep (altri linguaggi).
  • Controlli del Grafo di Topologia: Analisi statica dei file YAML di deployment rispetto a invarianti (ad esempio, attori esterni che detengono archi di scrittura verso la memoria).
  • Analizzatori di Log: Rilevatori temporali/statistici per anomalie come tentativi di brute-force o canali covert DNS.
• Passaggio di Raffinamento LLM: Gli esiti deterministici vengono iniettati come contesto nei crawler LLM. L'LLM è rigorosamente istruito per raffinare, spiegare o estendere le scoperte esistenti piuttosto che inventarne di nuove. Un passaggio di "critica della completezza" mira specificamente ai difetti semantici (ad esempio, data race, TOCTOU) che le regex non possono rilevare.
• Fusione (Merging): Le scoperte vengono de-duplicate; il livello deterministico funge da verità di base (ground truth), con l'LLM che aggiunge valore solo quando identifica nuovi loci genuini.

B. Motore di Decisione e Risposta

Un Agente Decisionale aggrega le scoperte, le etichetta utilizzando una tassonomia di asset centrata sull'uomo (sette categorie) e seleziona una risposta a livelli (nessuna/soft/moderata/hard).

• Memoria e Feedback: L'agente interroga un archivio di memoria cross-sessione firmato per incidenti passati simili. I precedenti possono aumentare il livello della risposta, ma non possono mai abbassarlo. Se un tentativo precedente è stato rifiutato, il sistema aumenta automaticamente il livello della risposta.
• Generazione dell'Azione: Un Generatore di Azioni costruisce un piano di rimedio. Esso si basa su un playbook deterministico basato su ID di regola come pavimento. Un opzionale tool-selector LLM può aggiungere passaggi da un registro di strumenti in stile MCP, ma sono ammessi solo strumenti di sola lettura, osservazione o verifica; le azioni distruttive sono proibite.

C. Guardia di Sicurezza a Runtime (Runtime Security Guard)

Prima che qualsiasi azione venga eseguita, una SecurityGuard impone quattro proprietà di sicurezza contestuali (derivate da Siu et al. [1]) e un oracolo di allineamento dell'azione indipendente:

1. Allineamento del Task: L'obiettivo rientra nell'insieme consentito.
2. Allineamento dell'Azione: Il tipo di azione è compatibile con l'obiettivo.
3. Autorizzazione della Sorgente: Tutti gli input provengono da fonti autenticate.
4. Isolamento dei Dati: Le azioni scrivono solo su destinazioni fidate.

• Oracolo ($H_a$): Un LLM judge indipendente verifica se la proposta azione serve realmente l'obiettivo dichiarato. Questo oracolo può solo restringere la decisione (approva $\to$ rifiuta), mai allargarla, garantendo che uno scanner subversato non possa forzare un'azione insicura.
• Gestione del Rifiuto: Se un'azione viene rifiutata, il sistema innesca una ri-pianificazione con un livello escalation anziché eseguire una correzione potenzialmente insicura.

D. Pipeline di Attacco Simmetrica

Per valutare la qualità della difesa, CyberLLM include una pipeline di red-teaming che rispecchia gli agenti di difesa. Essa genera script di exploit non distruttivi e solo per canary (ad esempio, shell injection, path traversal) basati sulla stessa base di regole. Ciò consente sia l'attacco che la difesa di essere misurati su scenari identici senza eseguire veri exploit.

3. Contributi Chiave

Il documento delinea quattro contributi primari:

1. Design di Rilevamento a Livelli: Uno stream unificato che fonde analizzatori regex, basati su AST e grafi di topologia con un passaggio di raffinamento LLM, dove il pavimento deterministico ancora e vincola l'LLM.
2. Motore di Decisione e Risposta: Un meccanismo che seleziona mitigazioni a livelli, aumenta la fiducia tramite memoria firmata e feedback di ri-pianificazione, ed esegue piani attraverso un registro di strumenti con verifica per ogni passaggio e rollback.
3. Guardia di Sicurezza a Runtime: Un livello di enforcement formale che applica quattro proprietà di sicurezza contestuali e un oracolo di allineamento dell'azione indipendente per prevenire azioni insicure, anche se i componenti a monte vengono subvertiti.
4. Pipeline di Attacco Simmetrica e Benchmark: Un sistema per generare e riprodurre exploit per una misurazione affiancata, valutato su un corpus etichettato a mano di moduli ECU automobilistici.

4. Risultati Sperimentali

Il framework è stato valutato su un benchmark indipendente e con ground-truth composto da nove moduli ECU automobilistici originali (C, C++, Rust) contenenti 47 vulnerabilità a livelli, oltre a due moduli di controllo puliti.

• Livello Deterministico (Fast Mode): Ha coperto il 34,0% (16/47) delle vulnerabilità etichettate con una precisione del 100% (zero falsi positivi sui controlli puliti).
• Livello Aumentato da LLM (Deep Mode): Aggiungendo il raffinamento LLM e i passaggi di completezza, la copertura è aumentata a circa il 70% (33/47) con un F1 score di 0,83.
• Mantenimento della Precisione: La modalità Deep ha mantenuto il 100% di precisione sui controlli puliti. Il raffinamento LLM non ha introdotto falsi positivi; ha principalmente migliorato il richiamo su difetti di logica a media severità (ad esempio, race condition sottili, errori off-by-one) che i pattern regex avevano mancato.
• Suddivisione per Linguaggio: I miglioramenti sono stati coerenti in C, C++ e Rust, con il passaggio LLM che ha aumentato significativamente il rilevamento di complessi difetti semantici.

5. Significato e Claim

Il documento sostiene che CyberLLM dimostra che gli agenti LLM possono svolgere una difesa cibernetica autonoma utile quando racchiusi in un involucro di sicurezza deterministico e verificabile.

• Bilanciamento tra Autonomia e Sicurezza: Il framework risolve la tensione tra l'autonomia dell'LLM e i vincoli di sicurezza assicurando che nessuna azione venga eseguita a meno che non soddisfi proprietà di sicurezza contestuali e formali.
• Contributo Quantificabile: I risultati quantificano il valore specifico dell'LLM: esso raddoppia approssimativamente il richiamo del pavimento deterministico senza introdurre un singolo falso positivo sul codice benigno.
• Robustezza: Il sistema è progettato in modo tale che, anche se uno scanner viene subvertito da input avversariali, la guardia indipendente e i meccanismi di memoria impediscano l'impegno di azioni insicure.
• Prospettive Future: Gli autori notano che, sebbene l'attuale approccio orientato al statico sia efficace, il lavoro futuro integrerà server di strumenti live, grounding RAG (Retrieval-Augmented Generation) su CVE e validazione contro testbench SDV ad alta fedeltà (ad esempio, CARLA).

Il documento conclude che la combinazione di raffinamento LLM ancorato, memoria a prova di manomissione ed enforcement formale a runtime fornisce una via percorribile verso una cybersecurity automobilistica autonoma e sicura.