Riepilogo Tecnico: Benchmark Sola ISPM Cross-Vendor

Definizione del Problema

La rapida proliferazione di architetture multi-cloud e SaaS ha trasformato la gestione della postura di sicurezza delle identità (Identity Security Management - ISPM) in una sfida fondamentalmente cross-vendor. Rischi critici di sicurezza, come i percorsi di escalation dei privilegi e le configurazioni errate, interessano sempre più provider di identità (IdP), cloud service provider (CSP) e suite di produttività disparati che non sono mai stati progettati per interoperare. Sebbene i Large Language Models (LLM) siano sempre più impiegati nelle operazioni di sicurezza, il settore manca di un benchmark standardizzato e basato sui dati per valutare se l'IA agente possa eseguire un ragionamento affidabile attraverso questi confini frammentati.

Gli existing benchmark, come Spider 2.0 per il text-to-SQL, operano su schemi di database singoli e ben definiti con chiavi esterne esplicite. Al contrario, l'ISPM cross-vendor richiede la navigazione di sistemi disgiunti privi di schemi condivisi. Ciò crea un "Correlation Gap" (gap di correlazione), dove un agente deve eseguire una risoluzione di entità multi-hop (ad esempio, inferire che un'identità utente Okta corrisponda a un determinato ruolo IAM di AWS) senza metadati relazionali espliciti. Le attuali valutazioni non riescono a misurare la capacità di un agente di ricostruire le precise entità di supporto, le relazioni di join e le prove cross-platform necessarie per agire sulle conclusioni di sicurezza.

Metodologia

Il Benchmark Cross-Vendor Sola ISPM

Per colmare questo vuoto di valutazione, gli autori introducono un benchmark di livello produzione composto da 50 task basati su dati. Tali task sono implementati su un ambiente aziendale integrato e live che comprende otto piattaforme distinte:

• Identità e HR: Okta, Azure Active Directory, HiBob (HRIS).
• Cloud e Infrastruttura: AWS, Google Cloud Platform (GCP), MongoDB Atlas.
• Produttività e DevOps: Google Workspace, GitHub.

Il benchmark copre casi d'uso cross-vendor critici, tra cui vulnerabilità di bypass MFA, proliferazione di account dormienti in tenant federati e vettori di escalation dei privilegi multi-hop.

Pipeline di Generazione delle Domande:
I 50 task sono stati costruiti tramite una pipeline multi-agente iterativa:

1. Generazione: Un agente generativo consapevole dello schema, dotato di capacità di ricerca web, propone candidati di domande in linguaggio naturale e query SQL basati su temi di sicurezza definiti da esperti.
2. Filtraggio: Un filtro di esecuzione automatizzato scarta i candidati in cui la SQL fallisce l'esecuzione o non può essere risposta in modo deterministico dall'ambiente live.
3. Raffinamento: Un ciclo "Critic-Composer" raffina iterativamente domande e query rispetto a criteri definiti dagli esperti (correttezza tecnica, realismo operativo, conformità PPI).
4. Validazione: Un esperto di cybersecurity umano esegue la validazione finale per garantire l'unicità semantica e il realismo operativo.

Framework di Valutazione

Gli autori propongono un framework di valutazione completo che misura non solo la correttezza della risposta finale, ma anche la qualità della catena di ragionamento. Il framework utilizza un approccio LLM-as-a-Judge con un meccanismo di consenso a doppio giudice (Anthropic Claude Sonnet 4.6 e OpenAI GPT-4.1) e metriche strutturali deterministiche.

Metriche Chiave:

• Qualità della Risposta: AnswerCorrectnessVsGT (equivalenza semantica), AnswerVerdictCorrectnessVsGT (verdetto binario sì/no), SuccessRate e FailureRate.
• Retrieval e Uso del Contesto: ContextualRelevancy, RetrievalUseQuality ed EvidenceCompletenessVsGT.
• Qualità del Ragionamento: ReasoningUtility (progresso verso la risoluzione).
• Qualità della SQL: SQLSemanticAppropriateness ed SQLEquivalenceVsGT.
• Metriche Strutturali Deterministiche: Precisione, Recall e punteggi F1 per Tabelle e Join rispetto alla ground truth, garantendo che l'agente abbia identificato correttamente le fonti dati necessarie e i percorsi di join cross-vendor.

Setup Sperimentale

Lo studio valuta l'Agente Sola AI attraverso tre LLM frontier (GPT-5.5, Gemini 3.1 Pro, Claude 4.6 Sonnet e Claude 4.8 Opus) sotto cinque diverse configurazioni di contesto:

1. No Context: Scoperta autonoma cieca.
2. Schema Only: Definizioni di tabelle grezze.
3. Schema + Graph: Schemi più il Security Graph di Sola (percorsi di join cross-vendor espliciti).
4. Schema + Examples: Schemi più esempi few-shot di text-to-SQL.
5. Full Context: Schemi, Security Graph ed Esempi.

L'agente opera in modalità di esplorazione full-path, eseguendo ragionamento iterativo e journaling dei passaggi per isolare l'impatto del grounding contestuale sulle traiettorie di ragionamento esplicite.

Contributi Chiave

1. Suite di Domande ISPM Cross-Vendor: Un set standardizzato di 50 task che richiedono la risoluzione di entità multi-hop e la correlazione di dati tra sistemi diversi attraverso otto piattaforme aziendali integrate, rappresentando flussi di lavoro reali di investigazione sull'identità federata.
2. Framework di Metrica di Grounding delle Prove: Una nuova suite di valutazione che analizza l'intera catena di ragionamento, inclusa la ricostruzione strutturale dei join, la risoluzione di entità multi-schema e l'utilizzo del retrieval, andando oltre la semplice correttezza della risposta.
3. Studio di Ablazione sul Grounding Contestuale: Un'analisi sistematica che dimostra come il contesto relazionale strutturato (specificamente la topologia del grafo e i metadati dello schema) plasmi la fedeltà del ragionamento cross-vendor e l'efficienza di esecuzione.

Risultati

Guadagni di Performance dal Contesto

Lo studio dimostra che arricchire gli agenti con contesto relazionale strutturato migliora significativamente le prestazioni:

• Correttezza della Risposta: Sotto la configurazione Full Context, il modello con le migliori prestazioni (Claude 4.8 Opus) ha raggiunto un punteggio di AnswerCorrectnessVsGT del 78%, un miglioramento relativo di circa il 34% rispetto al baseline No Context (58%).
• Riduzione dei Fallimenti: La configurazione Full Context ha ridotto il FailureRate (inesattezze complete) al 4%, rispetto al 28–38% del baseline No Context.
• Efficienza: L'arricchimento dell'agente con il contesto ha ridotto il numero medio di query di esplorazione di circa il 70% in tutti i modelli. Ciò indica che il contesto relazionale esplicito trasforma l'inefficiente esplorazione per tentativi ed errori in strategie di esecuzione mirate e consapevoli del grafo.

Fedeltà Strutturale

L'inclusione del Security Graph (topologia cross-vendor) è stata identificata come il driver primario dei guadagni.

• Fedeltà dei Join: I modelli hanno mostrato traiettorie chiaramente ascendenti nei punteggi JoinsF1 quando veniva iniettata la conoscenza del grafo. Ad esempio, la fedeltà dei join di Gemini è salita da 0.55 (Schema Only) a 0.68 (Full Context).
• Ragionamento vs. Evidenza: Una scoperta critica è il divario tra AnswerVerdictCorrectness (verdetto di sicurezza di alto livello) e AnswerCorrectness (evidenza semantica completa). Anche in assenza di contesto, i modelli spesso ottenevano alti punteggi di verdetto (ad esempio, identificando correttamente l'esistenza di un rischio) ma fallivano nel ricostruire le precise entità di supporto e i percorsi di join. Il Full Context ha ridotto significativamente questo divario, provando che il limite primario degli LLM frontier in questo dominio non è la capacità di ragionamento astratto, ma la disponibilità di contesto relazionale esplicito per la risoluzione delle entità e il grounding delle prove.

Confronto tra Modelli

• Claude 4.8 Opus ha superato costantemente gli altri modelli, raggiungendo la massima accuratezza e i minimi tassi di fallimento sotto Full Context.
• GPT-5.5 ha dimostrato un'alta efficienza di esecuzione (minore numero di query) ma una minore accuratezza semantica rispetto ai top-tier modelli Claude.
• Gemini 3.1 Pro ha mostrato una forte sensibilità all'arricchimento contestuale, ma sembra aver raggiunto una soglia di saturazione del contesto in cui ulteriori livelli di metadati producevano rendimenti decrescenti.

Significato e Asserzioni

Il paper afferma che il Benchmark Sola ISpm Cross-Vendor fornisce il primo mezzo standardizzato per valutare se i sistemi agentici possano navigare in modo affidabile il "Correlation Gap" nell'identità federata.

Gli autori sostengono che:

1. Gli LLM non assistiti sono insufficienti per l'esplorazione affidabile di dati aziendali attraverso sistemi frammentati.
2. Gli LLM frontier possiedono una sostanziale capacità latente di ragionamento sulla sicurezza, ma la loro capacità di eseguire analisi cross-vendor affidabili è fondamentalmente limitata dalla mancanza di contesto relazionale strutturato.
3. L'orchestrazione del contesto è critica: Iniettare metadati ricchi — specificamente schemi relazionali, grafi semantici ed esempi few-shot — stabilizza fondamentalmente l'esecuzione text-to-SQL, agendo sia come moltiplicatore di accuratezza che come acceleratore operativo.
4. I grafi strutturali sono essenziali: L'integrazione di topologie di grafi strutturali è universalmente essenziale per raggiungere l'equilibrio ottimale tra l'accuratezza text-to-SQL e l'efficienza di runtime in ambienti cross-vendor.

Il lavoro conclude che la futura valutazione ISPM deve andare oltre i controlli di piattaforma isolati per valutare la capacità dell'agente di ricostruire le prove attraverso ecosistemi eterogenei, una capacità che attualmente dipende dall'esplicita orchestrazione di un contesto consapevole del dominio.