Punti chiave
- Il costo di una migrazione SIEM non è una cifra fissa: dipende da volume di log (EPS), numero di detection da riscrivere, integrazioni e periodo di parallel run.
- I tempi realistici si contano in settimane per fase, non in giorni: un progetto mid-market tipico va da qualche settimana a diversi mesi.
- La voce che fa lievitare il conto più spesso è la riscrittura delle detection e la pulizia dei dati, non la licenza della piattaforma.
- Il parallel run (vecchio e nuovo SIEM attivi insieme) è la fase più costosa e va dimensionato bene: troppo corto è rischioso, troppo lungo è uno spreco.
La risposta onesta: non esiste un prezzo di listino per una migrazione SIEM, e chiunque te lo dia prima di aver guardato i tuoi numeri sta tirando a indovinare. Il costo e la durata dipendono da quattro cose concrete: quanti log produci, quante detection vanno riscritte, quante integrazioni servono e quanto tieni acceso il vecchio SIEM in parallelo. Cambia questi quattro parametri e il preventivo cambia di parecchio.
Quello che possiamo darti sono i tempi realistici e i fattori che muovono l'ago, così arrivi allo scoping sapendo cosa guardare. La regola generale: i tempi si contano in settimane per fase, non in giorni, e un progetto mid-market tipico va da qualche settimana per i casi semplici a diversi mesi per ambienti con molte sorgenti.
Un'altra cosa da sapere subito: la voce più cara non è quasi mai la licenza della nuova piattaforma. È il tempo umano per portare le detection e ripulire i dati. È lì che si concentra il conto, ed è lì che uno scoping fatto male brucia budget.
I fattori che determinano il costo
Cinque variabili spiegano quasi tutta la differenza tra un preventivo e l'altro.
- Volume di log (EPS). Gli eventi al secondo che il sistema deve gestire sono il primo numero da conoscere. Più log significa più dati da migrare, più capacità da dimensionare e, su modelli a consumo, più costo ricorrente. Ne parliamo nel confronto tra piattaforme e modelli di prezzo.
- Numero di detection da riscrivere. Ogni regola del vecchio SIEM va tradotta nel linguaggio del nuovo. Non è un copia e incolla: la logica va ripensata e testata. Cinquanta regole sono un conto, cinquecento un altro.
- Integrazioni con le sorgenti. Firewall, EDR, cloud, applicativi, Active Directory: ogni sorgente da collegare è un pezzo di lavoro. Alcune sono standard e veloci, altre custom e lente.
- Periodo di parallel run. Tenere vecchio e nuovo SIEM accesi insieme costa doppio finché dura. È necessario, ma va dimensionato: è la fase più cara del progetto.
- Pulizia dei dati. Sorgenti che mandano rumore, campi mal formattati, log duplicati. Se porti la spazzatura nel nuovo sistema, paghi per archiviarla e ci indaghi peggio. Pulire prima costa tempo, non pulire costa di più dopo.
Quanto dura una migrazione SIEM, fase per fase
Invece di una cifra secca, ha più senso ragionare a fasi. I tempi qui sotto sono ordini di grandezza per un contesto mid-market: il tuo caso può stare sotto o sopra a seconda dei cinque fattori di prima.
- Scoping e assessment (settimane). Misurare EPS, mappare le sorgenti, censire le detection realmente in uso, definire la retention richiesta. È la fase che nessuno dovrebbe saltare, perché è quella che rende credibili tutte le altre.
- Setup e integrazione sorgenti (settimane). Collegare le fonti di log al nuovo SIEM e verificare che i dati arrivino puliti e completi. La durata dipende quasi tutta dal numero e dal tipo di integrazioni.
- Riscrittura e tuning delle detection (settimane, spesso la fase più lunga). Portare le regole, adattarle al nuovo linguaggio, ridurre i falsi positivi. Qui si concentra gran parte del tempo umano.
- Parallel run (settimane). Vecchio e nuovo SIEM attivi insieme per confrontare che il nuovo veda gli stessi eventi e non perda nulla. Quando la fiducia è alta, si spegne il vecchio.
- Cutover e messa a punto (settimane). Passaggio definitivo e affinamento. Non finisce il giorno dello switch: le prime settimane servono a rifinire regole e soglie.
Messe in fila, per un progetto lineare si parla di qualche settimana; per ambienti con molte sorgenti e centinaia di detection, di diversi mesi. La differenza la fanno detection e integrazioni, non la piattaforma in sé.
Cosa fa lievitare il conto
Alcuni costi non si vedono nel preventivo iniziale ma arrivano puntuali. Vale la pena conoscerli prima.
- Detection nascoste o non documentate. Regole scritte anni fa, da persone che non ci sono più, senza documentazione. Vanno capite prima di riscriverle, e capirle costa tempo.
- Sorgenti "dimenticate". Fonti di log che nessuno ricordava e che saltano fuori a metà progetto. Ogni sorpresa allunga i tempi.
- Parallel run che si dilata. Se il confronto tra vecchio e nuovo non convince, il periodo in doppio si allunga, e con esso il doppio costo. Un buon scoping riduce questo rischio.
- Dati sporchi portati così com'erano. Rimandare la pulizia significa pagarla dopo, in archiviazione e in indagini più lente.
- Retention sottovalutata. Se la compliance chiede storici lunghi e la piattaforma li fa pagare a parte, il costo ricorrente cresce. Questo è anche uno dei punti dove i modelli delle piattaforme divergono di più.
Come si fa uno scoping serio prima di partire
Lo scoping è la fase che decide se il progetto starà nei tempi e nel budget. Farlo bene costa qualche settimana; saltarlo costa molto di più a valle. In concreto significa raccogliere quattro numeri veri.
- Il volume reale (EPS) e i picchi. Non la stima, la misura: quanti eventi al secondo, con quali punte.
- Le detection realmente attive. Non tutte le regole esistenti, solo quelle che servono davvero. Spesso una parte si può archiviare e non riscrivere.
- Le sorgenti da integrare, per tipo. Distinguere le integrazioni standard da quelle custom cambia radicalmente la stima dei tempi.
- La retention richiesta dalla compliance. Quanto storico devi tenere e quanto a caldo, perché è quello a determinare buona parte del costo ricorrente.
Con questi numeri in mano, il piano a fasi diventa credibile e il preventivo smette di essere un tiro al buio. Se la migrazione nasce dalla fine vita del tuo SIEM attuale, il tempo per lo scoping è adesso, prima che la scadenza detti i tempi al posto tuo: ne parliamo in QRadar end of life: cosa fare.
Migrazione o SOC gestito: due conti diversi
Una nota che aiuta a inquadrare il budget. Il costo della migrazione è una spesa di progetto, una tantum. Il costo del servizio di detection e response che gira dopo è ricorrente, ed è un'altra voce. A volte conviene ragionare sui due insieme, perché chi gestisce il SOC può assorbire parte del lavoro di migrazione. Abbiamo messo i numeri del servizio continuativo in quanto costa un SOC gestito, e raccontato un percorso concreto di migrazione in come migrare da QRadar a Google SecOps.
In sintesi: quanto costa una migrazione SIEM lo decidono volume di log, detection da riscrivere, integrazioni e parallel run, non la licenza. I tempi si contano in settimane per fase. Il modo più economico di affrontarla è uno scoping serio prima di partire. Se vuoi costruire quel piano sui tuoi numeri, guarda come lavoriamo sul servizio di observability e SecOps.
