Operations

Quanto costa e quanto dura una migrazione SIEM

Quanto costa una migrazione SIEM e quanto dura? I fattori che muovono il conto (volume di log, detection, integrazioni) e i tempi realistici a fasi.

6 min di lettura
Quanto costa e quanto dura una migrazione SIEM

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

  1. Il volume reale (EPS) e i picchi. Non la stima, la misura: quanti eventi al secondo, con quali punte.
  2. Le detection realmente attive. Non tutte le regole esistenti, solo quelle che servono davvero. Spesso una parte si può archiviare e non riscrivere.
  3. Le sorgenti da integrare, per tipo. Distinguere le integrazioni standard da quelle custom cambia radicalmente la stima dei tempi.
  4. 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.

Domande frequenti

Non c'è un prezzo unico: il costo dipende dal volume di log da portare, dal numero di regole di detection da riscrivere, dalle integrazioni con le sorgenti e da quanto dura il parallel run. Questi fattori spostano il conto molto più della licenza.
Si ragiona in settimane per fase. Un progetto mid-market va tipicamente da poche settimane per casi semplici a diversi mesi per ambienti con molte sorgenti e detection complesse.
La riscrittura delle detection da un linguaggio all'altro e la pulizia dei dati. Sono le attività che richiedono più tempo umano, ed è il tempo umano a pesare, non la piattaforma.
Sì, per un periodo. Il parallel run garantisce che il nuovo sistema veda gli stessi eventi del vecchio prima di spegnerlo. È la fase più delicata da dimensionare.
Misurando i numeri veri: EPS, sorgenti attive, regole di detection realmente usate, requisiti di retention. Da lì si costruisce un piano a fasi con tempi e costi credibili.

Parliamo della tua sicurezza.

Una call di 30 minuti per capire la tua postura attuale e dirti, senza impegno, dove conviene intervenire prima.

Prenota una call