Attack path analysis: le combinazioni tossiche del cloud

La risposta breve: l'attack path analysis ricostruisce la catena di passi con cui un attaccante potrebbe arrivare da un punto d'ingresso, di solito internet, fino a una risorsa critica del tuo cloud. Una combinazione tossica è l'insieme di problemi che, presenti insieme, aprono quella strada. Serve a decidere cosa correggere prima, perché un rischio letto da solo non dice quanto sei esposto davvero.

Chi cerca questi termini di solito ha lo stesso problema: una console di sicurezza che segnala centinaia o migliaia di problemi, un team piccolo, e nessun modo serio di dire quali dieci contano. Vediamo cosa sono i percorsi di attacco, come li calcolano le piattaforme, cosa non vedono e come si usano nel lavoro di tutti i giorni.

Perché un rischio isolato non dice l'esposizione vera

Gli strumenti tradizionali valutano un problema alla volta. Lo scanner di vulnerabilità assegna una gravità alla CVE, il controllo delle configurazioni segnala una porta aperta, lo strumento sui permessi trova un ruolo troppo largo. Ogni lista ha la sua logica, e nessuna guarda le altre.

Prendi tre segnalazioni che, lette una per una, finirebbero tutte in fondo alla coda:

• una macchina virtuale raggiungibile da internet su una porta applicativa;
• una vulnerabilità di gravità media nel software che ci gira sopra;
• un ruolo assegnato a quella macchina che può leggere un bucket con i dati dei clienti.

Messe insieme non sono tre problemi medi: sono una strada che va da internet ai dati. Al contrario, una vulnerabilità critica su un server interno, senza esposizione e senza permessi interessanti, può aspettare. È la differenza tra gravità del singolo problema ed esposizione dell'azienda, ed è il motivo per cui la priorità calcolata riga per riga sbaglia così spesso.

Wiz, nella pagina della sua Academy dedicata all'attack path analysis (marzo 2026), descrive il problema nello stesso modo: le scansioni delle singole vulnerabilità producono migliaia di risultati senza mostrare quali si concatenano in un percorso sfruttabile.

Cos'è un attack path

Le definizioni dei principali vendor convergono. Nella documentazione di Microsoft Defender for Cloud un percorso di attacco è la serie di passi con cui un potenziale attaccante entra nell'ambiente e arriva agli asset: parte da un punto d'ingresso esterno, per esempio una risorsa vulnerabile esposta su internet, segue i movimenti laterali possibili, come un'identità collegata con permessi su altre risorse, e arriva a un obiettivo critico, come un database con dati sensibili.

Google Cloud, nella documentazione di Security Command Center, lo descrive come la rappresentazione visiva e interattiva di uno o più percorsi che un attaccante ipotetico potrebbe seguire dalla rete internet pubblica fino a una delle risorse che hai indicato come di alto valore.

Vale la pena distinguere tre concetti che spesso si confondono:

• Vettore di attacco: la porta d'ingresso, per esempio un'email di phishing, un software non aggiornato, una credenziale esposta.
• Superficie di attacco: l'insieme di tutte le porte possibili, cioè ogni servizio esposto, endpoint API, identità e configurazione sbagliata.
• Percorso di attacco: quello che succede dopo la porta, cioè dove l'attaccante può andare una volta dentro e quanti passi gli servono per arrivare a ciò che conta.

Cos'è una combinazione tossica

Il termine toxic combination lo usano soprattutto Wiz e Google. Nella documentazione di Security Command Center una combinazione tossica è un gruppo di problemi di sicurezza che, quando si presentano insieme secondo un certo schema, creano un percorso verso una o più risorse di alto valore, che un attaccante determinato potrebbe usare per comprometterle.

Lo stesso documento introduce un secondo concetto utile, il chokepoint: una risorsa o un gruppo di risorse in cui convergono più percorsi di attacco. Il valore pratico è evidente: correggere un chokepoint può chiudere più combinazioni tossiche in un colpo solo. Per un team con poche ore a disposizione è spesso il primo intervento da fare.

Esempi di combinazioni tossiche

Ogni ambiente ha le sue. Qualche esempio, per rendere l'idea:

• Esposizione, vulnerabilità e identità: workload raggiungibile da internet, software con una vulnerabilità sfruttabile, ruolo con accesso a dati sensibili.
• Segreto dimenticato e privilegi alti: una chiave di accesso salvata in chiaro sul disco di una macchina esposta, che appartiene a un'identità con permessi amministrativi.
• Storage aperto e dati personali: un bucket leggibile pubblicamente che contiene dati soggetti al GDPR.
• Container privilegiato in un cluster esposto: un pod con privilegi elevati in un cluster Kubernetes raggiungibile dall'esterno, da cui si può passare al nodo e poi alle credenziali del cloud.
• Movimento laterale tra account: un ruolo che si può assumere da un account di sviluppo poco presidiato e che apre la strada all'account di produzione.

Molti di questi anelli sono errori di configurazione comuni, quelli che abbiamo raccolto in errori di configurazione cloud. L'analisi dei percorsi non li sostituisce: li mette in relazione.

Come funziona l'attack path analysis

Il metodo è simile su tutte le piattaforme. Wiz lo scompone in quattro fasi, che sono un buon schema anche per valutare uno strumento:

1. Scoperta di asset e rischi. Inventario completo di workload, identità, configurazioni e dati, con la ricerca di vulnerabilità, segreti esposti, configurazioni sbagliate e permessi eccessivi.
2. Mappa a grafo. I rischi vengono collegati alle risorse in un grafo: questa macchina ha un IP pubblico, usa questa identità, questa identità legge questo database.
3. Individuazione dei percorsi. Sul grafo si cercano le sequenze di azioni possibili e le combinazioni tossiche, dove più problemi a basso rischio si concatenano in un percorso ad alto impatto.
4. Priorità. I percorsi vengono ordinati per impatto: quelli che arrivano agli asset critici o a privilegi elevati salgono in cima.

Le differenze stanno nei dettagli, e conviene conoscerle:

• Google Cloud Security Command Center (livello Premium, con attivazione a livello di organizzazione) fa girare simulazioni in cui un attaccante virtuale prova tecniche note per raggiungere le risorse di valore. Le simulazioni girano circa ogni sei ore e comunque almeno una volta al giorno, e assegnano un punteggio di esposizione ai problemi e alle risorse delle categorie supportate.
• Microsoft Defender for Cloud calcola i percorsi sul proprio cloud security graph, nel piano Defender CSPM, e dichiara di verificare con scansioni di raggiungibilità attive se un'esposizione è davvero accessibile dall'esterno, per ridurre i falsi positivi.
• AWS Security Hub genera gli exposure finding: correla i segnali di Security Hub CSPM, Amazon Inspector, GuardDuty e Macie, insieme alla raggiungibilità di rete e ai permessi IAM, per individuare i rischi che nascono dalla combinazione di più fattori.

Il punto comune è il grafo. Senza un modello che colleghi risorse, identità, rete e dati, i percorsi non si calcolano. È per questo che l'analisi dei percorsi è diventata una funzione centrale delle CNAPP, di cui trovi componenti e logica in CNAPP, cos'è e quali componenti ha.

Cosa l'analisi dei percorsi non vede

Uno strumento che ordina i rischi è utile solo se si sa dove smette di vedere. La documentazione di Google è esplicita su questi limiti, e valgono in buona parte per tutti:

• L'attaccante simulato parte da internet. Le simulazioni non modellano utenti interni, malintenzionati o negligenti, che hanno già un accesso legittimo.
• Un punteggio zero non vuol dire rischio zero. Secondo Google i punteggi non tengono conto, per esempio, delle minacce interne, delle vulnerabilità zero-day e delle infrastrutture di terze parti.
• Un percorso è una possibilità, non un attacco in corso. Per vedere gli attacchi reali servono i servizi di rilevamento delle minacce e qualcuno che li guardi: è il lavoro del SOC, non della postura.
• Senza i gioielli definiti, le priorità sono generiche. Finché non indichi quali risorse sono davvero di valore, avverte Google, punteggi, percorsi e combinazioni tossiche non riflettono le tue priorità.
• Vede solo ciò che è collegato. Un account cloud dimenticato fuori dall'inventario, un SaaS non integrato o un ambiente on premise non collegato non entrano nel grafo.

Come usarla nel lavoro di tutti i giorni

L'attack path analysis rende di più quando entra in un ciclo, non quando si guarda una volta. Una sequenza che funziona anche con team piccoli:

1. Definisci i gioielli. I database con dati di clienti, i sistemi di pagamento, gli ambienti di produzione, le chiavi che firmano il software. Pochi e scelti con il business, non con la console.
2. Collega tutti gli account. Il percorso più pericoloso passa spesso dall'ambiente che nessuno controlla, come un progetto di test o un account di un fornitore.
3. Parti dai chokepoint. Se una sola correzione chiude dieci percorsi, viene prima delle altre.
4. Rompi l'anello più economico. Non serve correggere tutta la catena: togliere un permesso o chiudere un'esposizione costa meno che aggiornare un'applicazione legacy, e interrompe il percorso lo stesso.
5. Assegna un proprietario. Ogni percorso deve finire nel backlog del team che possiede la risorsa, con una scadenza concordata.
6. Rimisura. Dopo la correzione il percorso deve sparire dalla simulazione successiva. Se non sparisce, la correzione non è completa.

È la logica del CTEM applicata al cloud: scegliere il perimetro, scoprire, mettere in priorità ciò che è sfruttabile, validare e far correggere. Il ciclo completo è descritto in CTEM, cos'è il Continuous Threat Exposure Management.

Attack path analysis e NIS2

La NIS2 non nomina i percorsi di attacco, e nessuna norma impone uno strumento specifico. Ma l'art. 24, comma 2, del D.Lgs. 138/2024 chiede che le misure di gestione del rischio comprendano almeno, tra gli altri elementi, la gestione e la divulgazione delle vulnerabilità (lettera e), politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi (lettera f) e la gestione dei beni e degli assetti insieme al controllo degli accessi (lettera i).

Un'analisi dei percorsi documentata produce evidenze su tutti e tre i punti: un inventario degli asset cloud, un criterio motivato per decidere quali vulnerabilità correggere prima e la prova, simulazione dopo simulazione, che le correzioni hanno ridotto l'esposizione. È materiale che regge davanti a un auditor meglio di un elenco di CVE chiuse.

Wiz e le combinazioni tossiche

Wiz costruisce il proprio approccio intorno al Security Graph, il modello che collega asset, identità, permessi, vulnerabilità e attività sospette, e sopra il quale calcola percorsi di attacco e combinazioni tossiche. Si collega agli account cloud via API, senza agenti; l'analisi dei dischi passa da snapshot temporanei, e un sensore a runtime si aggiunge dove serve verificare cosa succede davvero sui workload.

Google ha completato l'acquisizione di Wiz l'11 marzo 2026. Nel post di Thomas Kurian, CEO di Google Cloud, Wiz è descritta come una piattaforma che costruisce una mappa in tempo reale di architettura applicativa, permessi, flussi di dati e comportamento a runtime, e da lì individua esposizioni e percorsi di attacco sfruttabili e li ordina per impatto sul business. Lo stesso annuncio conferma che il marchio Wiz resta e che i prodotti continuano a funzionare su AWS, Microsoft Azure e Oracle, accanto al portafoglio di sicurezza di Google che comprende Google Security Operations, Google Threat Intelligence e Mandiant Consulting. Per il quadro completo c'è Wiz, cos'è.

AmagisTech è partner Wiz. Lo usiamo per la fotografia del cloud: colleghiamo gli account, leggiamo i percorsi che arrivano alle risorse che contano e consegniamo l'elenco delle correzioni in ordine, partendo da quelle che chiudono più strade.

In sintesi

In sintesi: l'attack path analysis collega esposizione, vulnerabilità, permessi e dati in un grafo e mostra quali combinazioni portano davvero un attaccante alle risorse critiche. Le combinazioni tossiche e i chokepoint dicono cosa correggere prima, e spesso una sola correzione chiude più percorsi. Non vede gli insider né gli attacchi in corso, quindi affianca il SOC e non lo sostituisce. Se vuoi sapere quali percorsi esistono oggi nel tuo cloud, parti dalla fotografia del cloud con Wiz: via API, senza agenti, con le correzioni in ordine di priorità.