Migrare da QRadar a Google SecOps: il percorso in 5 fasi

La risposta breve: si migra da QRadar a Google SecOps in 5 fasi, in quest'ordine: (1) discovery e inventario di cosa hai davvero, (2) mapping dei log sul modello dati UDM di Google SecOps, (3) porting delle detection nel linguaggio YARA-L, (4) parallel run con i due sistemi accesi insieme, (5) cutover finale con lo spegnimento di QRadar. Il segreto non è nessuno di questi passi preso da solo: è l'ordine, e soprattutto non saltare il parallel run.

Il rischio numero uno di una migrazione SIEM non è tecnico, è di copertura: spegnere il vecchio sistema prima di aver verificato che il nuovo vede davvero gli attacchi. Con un time-to-ransom che ormai si misura in pochi giorni (Mandiant M-Trends 2025), una settimana di detection cieca durante la transizione è esattamente la finestra che un attaccante cerca. Ecco perché il percorso va fatto a fasi, con calma, e perché l'ultima cosa che si spegne è QRadar.

Vediamo le 5 fasi una per una, con i tempi realistici, i punti dove ci si fa male e dove entra un partner gestito.

Fase 1: discovery e inventario

Prima di spostare qualcosa, devi sapere cosa hai. Sembra ovvio, ma è la fase che quasi tutti sottovalutano, ed è quella che decide i tempi di tutto il resto. Qui si fa l'inventario di due cose:

• Le fonti dati. Quali sistemi mandano log a QRadar: firewall, endpoint, Active Directory, server, applicazioni cloud, apparati di rete. Per ognuno serve capire formato, volume e come sono collegati.
• Le detection attive. Quante regole hai, quali scattano davvero e quali non hanno mai prodotto un alert utile. Quasi sempre emerge la stessa cosa: una fetta consistente delle regole è rumore, ereditata da configurazioni vecchie che nessuno ha mai ripulito.

Il valore di questa fase è duplice: da un lato dimensiona il progetto (il numero di fonti e di regole è la variabile che pesa di più sui tempi), dall'altro ti permette di non portare la spazzatura nel sistema nuovo. Migrare è l'occasione perfetta per fare pulizia, non per fotocopiare il disordine.

Pitfall: partire a mappare senza inventario. Ti ritrovi a metà progetto a scoprire fonti dati che nessuno aveva censito, e i tempi saltano.

Fase 2: mapping delle fonti sul modello UDM

Google SecOps normalizza tutti i log in un modello dati unico, l'UDM (Unified Data Model). Ogni evento, da qualsiasi fonte arrivi, viene ricondotto a una struttura comune. È una delle cose che rende la piattaforma potente, ma è anche il lavoro tecnico centrale della migrazione: ogni fonte dati va mappata sui campi UDM.

In pratica significa dire alla piattaforma: "questo campo del log del firewall è l'IP sorgente, quest'altro è l'utente, quest'altro è l'azione". Per le fonti comuni (i grandi vendor di firewall, endpoint, cloud) esistono parser già pronti che accorciano molto il lavoro. Per le fonti custom o meno diffuse, il mapping va costruito e verificato a mano.

Pitfall: dare per scontato che "tanto c'è il parser". Un mapping fatto male non rompe niente in modo visibile, semplicemente le tue regole non scatteranno come dovrebbero perché guardano campi vuoti o sbagliati. Ogni fonte va validata con dati reali prima di considerarla chiusa.

Fase 3: porting delle detection in YARA-L

Le regole di detection di QRadar non si esportano e si importano: la logica va ripensata e riscritta nel linguaggio di Google SecOps, YARA-L. Questo spaventa, ma è meno drammatico di come sembra, per due motivi.

Primo: dalla fase 1 sai già quali detection contano davvero, quindi non riscrivi tutto, riscrivi quello che serve. Secondo: Google SecOps porta con sé un corredo di regole già pronte e curato dal team Mandiant, che in molti casi copre già scenari per cui in QRadar avevi regole fatte in casa. Spesso il porting è più un lavoro di adattamento e integrazione che di riscrittura da zero.

Il lavoro vero è mantenere l'intento di ogni regola: cosa doveva rilevare, con quali condizioni, con quale soglia. È qui che l'esperienza fa la differenza, perché una regola tradotta in modo letterale ma senza capirne lo scopo diventa inutile.

Pitfall: tradurre le regole "meccanicamente", una per una, senza rivedere se hanno ancora senso. Finisci per replicare nel nuovo sistema gli stessi falsi positivi che ti facevano impazzire nel vecchio.

Fase 4: parallel run, la fase che ti salva

Questa è la fase più importante di tutte, e quella che non va mai saltata per fare prima. Per un periodo, i due sistemi ricevono gli stessi log in parallelo: QRadar continua a girare come sistema di riferimento, Google SecOps lavora accanto in modalità di validazione.

Serve a rispondere alla domanda che conta: il nuovo sistema vede quello che vedeva il vecchio? Si confrontano gli alert, si verifica che le detection portate scattino quando devono, si affina il tuning sui dati reali del tuo ambiente. Quando quello che scatta su Google SecOps corrisponde (o migliora) quello che vedevi su QRadar, e i falsi positivi sono sotto controllo, solo allora sei pronto per il passo finale.

La durata del parallel run è la variabile che più spesso viene compressa sotto pressione, ed è l'errore più costoso. Va tenuto acceso abbastanza a lungo da vedere il tuo ambiente nei suoi cicli reali (fine mese, picchi di traffico, attività notturne), altrimenti stai validando a metà.

Pitfall: tagliare il parallel run per rispettare una data. È esattamente il modo in cui ti ritrovi scoperto senza saperlo.

Fase 5: cutover

Il cutover è il momento in cui Google SecOps diventa il sistema di riferimento e QRadar viene spento. Se le prime quattro fasi sono state fatte bene, questa è quasi un non-evento: è la conseguenza naturale di un parallel run andato a buon fine, non un salto nel vuoto.

Restano un paio di accortezze. Vanno decisi quanto a lungo conservare i dati storici di QRadar (spesso per obblighi di conformità serve tenere i log per un certo periodo) e vanno dismesse in modo ordinato le appliance. Ma il rischio operativo, a questo punto, è già stato tolto nella fase 4.

Quanto tempo serve davvero

La domanda che tutti fanno, e alla quale nessuno onesto può rispondere con un numero secco. La verità è che i tempi si misurano a fasi, in un arco di mesi, non in giorni, e la variabile che decide tutto è il volume: quante fonti dati e quante detection devi portare.

Un ambiente con poche fonti standard e un set di regole snello si muove in fretta. Un ambiente con decine di fonti custom, tante regole stratificate negli anni e requisiti di conformità stringenti richiede più tempo, soprattutto nelle fasi 2 e 3. Quello che possiamo dire con certezza è dove non tagliare: la discovery (fase 1) e il parallel run (fase 4). Comprimere quelle due è il modo più veloce per trasformare una migrazione pulita in un incidente. Se vuoi ragionare anche sul lato economico, abbiamo messo in fila le voci di costo (comprese quelle nascoste) in quanto costa una migrazione SIEM.

I rischi e i pitfall da tenere a mente

Riassumendo gli errori che vediamo più spesso, in ordine di gravità:

• Spegnere QRadar troppo presto. Il rischio numero uno. Il vecchio sistema è la tua rete di sicurezza finché il nuovo non ha dimostrato di reggere.
• Saltare l'inventario. Senza fase 1 non sai cosa stai migrando e i tempi diventano imprevedibili.
• Portare tutte le regole senza filtrarle. Migri il rumore insieme al segnale e riparti con gli stessi problemi.
• Mapping non validato. Le detection sembrano attive ma guardano dati sbagliati: un falso senso di sicurezza, il peggiore di tutti.
• Nessuno che guardi gli alert dopo il cutover. La piattaforma nuova è più capace, ma se nessuno risponde di notte e nel weekend hai solo cambiato marca al problema.

Il ruolo dell'MSSP

Si può migrare da soli? Tecnicamente sì. Ma sul mid-market italiano, dove i team di sicurezza sono piccoli e le competenze specialistiche scarseggiano, un partner gestito cambia due cose in concreto.

Durante la migrazione, il carico di lavoro raddoppia: devi mandare avanti la sicurezza di tutti i giorni e allo stesso tempo mappare, riscrivere e validare. Un MSSP assorbe quel picco invece di scaricarlo sul tuo team già al limite. E dopo il cutover, il partner tiene la detection e la response attive 24/7 sul nuovo sistema, che è poi la ragione per cui migri: non avere una piattaforma più bella, ma avere qualcuno in grado di accorgersi di un attacco e reagire quando conta.

Questo è il modello con cui AmagisTech accompagna le aziende del mid-market: prendiamo in carico l'intero percorso in 5 fasi e poi restiamo a gestire le security operations sul campo. Se stai valutando l'uscita da QRadar, ha senso capire prima cosa fare con QRadar end of life e confrontare le destinazioni possibili in Google SecOps vs Microsoft Sentinel.

In sintesi: migrare da QRadar a Google SecOps è un percorso in 5 fasi (inventario, mapping su UDM, porting in YARA-L, parallel run, cutover) che si misura in mesi e vive o muore su un principio: non spegnere il vecchio finché il nuovo non ha dimostrato di vedere gli attacchi. Se vuoi farlo senza restare scoperto e senza raddoppiare il carico sul tuo team, parti dai nostri servizi Observability & SecOps.