Wiz e Google SecOps: come funziona l'integrazione

Risposta breve: Wiz e Google SecOps si collegano in due direzioni. Wiz invia a Google Security Operations le sue Issue e Detection, cioè i rischi cloud già messi in ordine di priorità e le minacce rilevate; dal lato opposto, i playbook di SecOps interrogano Wiz via API per leggere i dettagli e chiudere, ignorare o commentare una Issue. Così il contesto del cloud entra nello stesso posto dove il SOC legge endpoint, identità e posta.

Questo articolo spiega cosa passa, come si configura e cosa resta da decidere. Se ti serve prima sapere che cos'è Wiz, lo trovi in Wiz cos'è: la cloud security che ora è di Google; se ti serve la parte SIEM, in Google SecOps: cos'è e come funziona.

Perché collegare Wiz a un SIEM

Wiz e Google SecOps rispondono a due domande diverse. Wiz guarda il cloud e dice che cosa è esposto: configurazioni errate, vulnerabilità, permessi eccessivi, dati sensibili, e soprattutto le combinazioni di questi elementi che formano un percorso d'attacco. Google SecOps raccoglie gli eventi di tutto il resto dell'ambiente e li correla per seguire un attacco mentre si sposta.

Presi da soli, ognuno vede metà della scena. Un accesso sospetto su un'identità, letto nel SIEM, pesa in modo diverso se Wiz sa che quell'identità ha un ruolo amministrativo su un bucket di dati personali. È il punto che Google ha messo al centro chiudendo l'acquisizione di Wiz: nel post dell'11 marzo 2026 Thomas Kurian, CEO di Google Cloud, scrive che i team di security operations usano lo stesso contesto costruito da Wiz per rilevare, indagare e fermare gli attacchi in corso sui carichi cloud critici, e annuncia una piattaforma che combina Wiz con Google Security Operations per lo sviluppo, la build e il runtime (blog Google Cloud, 11/03/2026).

Detto in termini operativi: Wiz fa la fotografia del cloud, il SIEM e il SOC fanno il monitoraggio continuo. L'integrazione è il ponte fra le due cose. La fotografia iniziale, e cosa contiene, la descriviamo in cloud security assessment: cos'è e cosa ricevi.

Cosa passa da Wiz a Google SecOps

La direzione principale è da Wiz verso il SIEM. La guida di Google SecOps sulla raccolta dei log Wiz (pagina Collect Wiz logs, aggiornata il 28/09/2026) descrive un flusso in cui è Wiz a spingere i dati, attraverso una regola automatica configurata nel tenant Wiz.

Che cosa si invia

Due tipi di oggetti, scelti come condizione della regola:

• Issue: i rischi che Wiz ha già correlato e messo in priorità, comprese le combinazioni tossiche;
• Detection: le minacce rilevate, che con Wiz Defend arrivano da log cloud, segnali del sensore a runtime e contesto di rischio.

Google consiglia di includere nell'invio anche le evidenze della Issue, cioè gli elementi che spiegano perché è stata aperta. Per un analista è la differenza fra ricevere un titolo e ricevere un caso leggibile.

In che formato

La regola offre due formati di uscita:

• Native, lo schema Wiz con campi come categoria, sorgente del trigger e progetti. È l'opzione che Google raccomanda. I dati arrivano in SecOps con il tipo di log WIZ_IO, che il parser di Google traduce nel modello dati unificato (UDM): account e progetto cloud, utente, risorsa, esito di sicurezza.
• OCSF, l'Open Cybersecurity Schema Framework, uno schema aperto. In questo caso i dati arrivano con il tipo di log OCSF.

La scelta conta per chi scrive le regole di rilevamento: le regole e le ricerche si costruiscono sui campi UDM, quindi il formato decide quali campi saranno popolati.

Come si configura

I passi, nella sequenza della guida Google:

1. dalla console Google SecOps si recuperano il Customer ID (SIEM Settings, Profile) e il file di autenticazione per l'ingestion (SIEM Settings, Collection Agents);
2. nel tenant Wiz si crea l'integrazione Google SecOps, indicando nome, scope, Customer ID ed endpoint regionale dell'istanza, e caricando il file di autenticazione. Wiz usa la Ingestion API standard di Google SecOps;
3. in Wiz si aggiunge la regola automatica (Policies, Automation Rules): scope, condizione su Issue o Detection, formato, filtri, e l'azione che invia a Google SecOps.

Tre dettagli della guida evitano sorprese. La regola vale solo per i casi futuri: le Issue già aperte che compaiono nell'anteprima non vengono inviate. Il volume delle azioni è soggetto a limiti di servizio e di picco. E una regola può portare fino a dieci azioni, quindi lo stesso evento può andare a SecOps e anche ad altre integrazioni configurate nel tenant. In testa alla stessa pagina c'è anche un avviso: Google ha deprecato la Ingestion API, quella che Wiz usa per l'invio, e la dismetterà il 20 luglio 2027, indicando la API che la sostituisce. La guida non dice ancora come cambierà l'integrazione Wiz: conviene chiederlo prima di accenderla.

Cosa fa Google SecOps verso Wiz

La seconda direzione passa dal lato SOAR di Google SecOps, cioè la parte che esegue i playbook. Il marketplace di SecOps ha un'integrazione Wiz (pagina Integrate Wiz with Google SecOps, aggiornata il 28/09/2026) che si collega all'API GraphQL del tenant Wiz con un service account, tramite Client ID e Client Secret.

Fra le azioni documentate ci sono:

• Ping, per verificare la connessione;
• Get Issue Details, che porta nel caso i dettagli di una Issue: gravità, tipo, risorsa coinvolta, regola che l'ha generata;
• Get Blue Agent Analysis, che recupera l'analisi dell'agente di Wiz su una minaccia;
• Resolve Issue, per le Issue di threat detection, con un motivo di chiusura (minaccia reale, non malevola, test di sicurezza, attività pianificata, non conclusiva);
• Ignore Issue, per le Issue di tipo Graph Control o Cloud Configuration, con motivo (falso positivo, eccezione, non si corregge);
• Reopen Issue e Add Comment To Issue.

Il senso pratico è che l'analista chiude il giro senza cambiare console: indaga in SecOps e lo stato della Issue in Wiz si aggiorna di conseguenza, con un commento che resta come traccia.

I permessi del service account

La documentazione separa le operazioni di lettura (scope come read:issues e read:threat_issues) da quelle di scrittura (write:issue_status, write:issue_comments e simili), e indica per ogni azione lo scope che le serve. Ammette in alternativa i permessi larghi read:all, write:all e update:all, se la policy interna non chiede granularità. Il consiglio, nostro, è partire dalle sole letture e aggiungere le scritture quando il playbook che le usa è scritto e provato.

E se il cloud è Google Cloud

Su Google Cloud c'è un terzo flusso, che va verso Wiz. La guida di architettura Google su Wiz e Google Cloud descrive come Wiz legga i finding di Security Command Center e gli audit log delle attività amministrative, per aggiungere eventi di minaccia al proprio grafo. Con Security Command Center Premium, Wiz importa le rilevazioni di Event Threat Detection: un tentativo di brute force SSH su una macchina esposta, con una vulnerabilità nota e una chiave che porta ai dati, si legge sul grafo come un'unica combinazione critica, da guardare subito.

La stessa guida conferma il modello di accesso: inventario tramite le API cloud con ruoli in sola lettura, e scansione dei dischi tramite snapshot che Wiz crea, monta in lettura e cancella a fine scansione. Quindi la scansione di Wiz passa via API, senza agenti, ma non lavora tutto in sola lettura: per creare e cancellare gli snapshot servono ruoli IAM specifici. Il sensore a runtime citato sopra per Wiz Defend è un'altra cosa: Wiz lo indica come componente aggiuntivo.

Questo terzo flusso è specifico di Google Cloud. La guida Google sui log Wiz descrive Wiz come piattaforma che copre Google Cloud, AWS, Azure, OCI e Kubernetes, e tra i prerequisiti dell'integrazione elenca un'istanza Google SecOps e l'accesso privilegiato a Wiz.

Cosa è cambiato con l'acquisizione

L'integrazione non nasce con l'acquisizione. Wiz l'aveva annunciata il 28 maggio 2024, quando era ancora un'azienda indipendente, come invio delle Issue verso Google Security Operations (blog Wiz). Wiz era anche fra i primi partner del programma Google Unified Security Recommended, come ricorda il post di chiusura di Google.

Le novità successive sono due:

• l'11 marzo 2026 Google ha chiuso l'acquisizione, ha confermato che il marchio Wiz resta e che i prodotti continuano a funzionare sui principali cloud, fra cui Amazon Web Services, Microsoft Azure e Oracle, e ha indicato l'integrazione con Google Security Operations, la threat intelligence di Google e Mandiant come direzione del prodotto combinato (blog Google Cloud, 11/03/2026);
• il 22 aprile 2026, a Google Cloud Next, Google ha annunciato di aver aggiornato il modo in cui le rilevazioni di Wiz Defend arrivano in Google Security Operations e in Mandiant Threat Defense, il servizio Mandiant di detection e response erogato dentro SecOps, per rendere più semplice configurare l'inoltro automatico delle informazioni sulle minacce (Francis deSouza, blog Google Cloud, 22/04/2026).

Prima di accenderla: cinque decisioni

La configurazione tecnica è breve. Le decisioni che rendono utile l'integrazione richiedono più tempo, e conviene prenderle prima.

1. Cosa inviare. Inviare tutte le Issue a un SOC che non ha mai visto il cloud è il modo più rapido per produrre alert fatigue, cioè il problema da cui Wiz dovrebbe liberarlo. Di solito si parte dalle Issue critiche e dalle Detection, e si allarga dopo.
2. Native o OCSF. Native è la scelta raccomandata da Google e porta il parser WIZ_IO; OCSF ha senso se l'organizzazione ha già standardizzato su quello schema.
3. Quali regole di rilevamento scrivere. Il valore arriva quando una regola in SecOps lega un evento Wiz a un evento di identità, di endpoint o di rete sulla stessa risorsa. Senza regole di correlazione, i dati Wiz restano un'altra coda.
4. Chi corregge. Il SOC rileva e indaga, ma chiudere una porta o ridurre un permesso spetta a chi amministra il cloud. Serve un passaggio di consegne definito, altrimenti la Issue si chiude in SecOps e resta aperta nella realtà.
5. Chi guarda, e quando. Una Detection a runtime arrivata alle tre di notte vale quanto la persona che la legge. È la stessa scelta fra team interno e servizio gestito che si fa per tutto il SOC.

In sintesi

Wiz invia a Google SecOps Issue e Detection tramite una regola automatica, in formato Native (log WIZ_IO) o OCSF; i playbook SOAR di SecOps leggono i dettagli da Wiz e ne aggiornano lo stato. Su Google Cloud, Wiz legge a sua volta i finding di Security Command Center. L'integrazione esiste dal 2024, e dopo l'acquisizione Google ha aggiornato l'inoltro delle rilevazioni di Wiz Defend. Per il quadro della categoria, CNAPP e SIEM a confronto, c'è la nostra guida CNAPP: cos'è.

AmagisTech è partner Wiz e lavora su Google SecOps: colleghiamo la fotografia del cloud al monitoraggio del SOC. Se vuoi partire da cosa è esposto oggi nei tuoi account, ti mostriamo la fotografia del tuo cloud con Wiz.