Software SIEM: 7 criteri per scegliere quello giusto

La risposta breve: un software SIEM si sceglie su sette numeri, non su una lista di funzioni. Quanti log produci e come te li fanno pagare, quante delle tue sorgenti sono già supportate, quante detection arrivano pronte, fino a quando puoi guardare indietro nei log, quanto tempo serve per andare a regime, chi scrive le regole dopo il primo mese e cosa succede quando l'unico analista che sa usarlo se ne va.

Questa pagina non è una classifica con i voti: è la lista dei criteri che, nei progetti reali, separano un SIEM che dopo sei mesi funziona da uno diventato un archivio costoso di allarmi che nessuno legge. Se ti serve prima la definizione, parti dalla guida su cos'è un SIEM e come funziona.

Prima dei prodotti, i tuoi numeri

Nessun confronto ha senso finché non hai cinque dati in mano. Sono gli stessi che un fornitore serio ti chiederà alla prima call, e ti dicono se il preventivo che ricevi è calcolato o inventato.

• Volume giornaliero di log, in GB al giorno o in eventi al secondo: è il numero che muove il conto più di ogni altro.
• Elenco delle sorgenti, con marca e versione: firewall, EDR, identità, cloud, applicativi, sistemi legacy, eventuale OT.
• Retention richiesta, distinguendo il requisito di compliance da quello investigativo.
• Detection realmente in uso, non quelle configurate: quante regole generano alert che qualcuno guarda davvero.
• Ore di presidio disponibili: chi legge gli alert, in quali fasce orarie, e cosa succede il venerdì sera.

Sul terzo punto la normativa italiana è precisa. La misura PR.PS-04 dell'allegato 2 alla determinazione ACN 379907/2025, quello dei soggetti essenziali NIS, chiede log "generati e resi disponibili per il monitoraggio continuo", conservati "in modo sicuro, e possibilmente centralizzato", con tempistiche "definite e documentate" in accordo con gli esiti della valutazione del rischio. La retention non è una preferenza tecnica, è una scelta da motivare per iscritto.

Criterio 1. Il modello di costo segue il volume, non il software

La prima domanda non è quanto costa, ma su cosa si paga. I due modelli più diffusi sono entrambi ancorati ai dati, in modi diversi.

• A pacchetto con l'ingestion inclusa. La documentazione Google indica tre pacchetti Google SecOps, Standard, Enterprise ed Enterprise Plus, e specifica che "the pricing for all packages is based on ingestion volume": il prezzo di tutti i pacchetti è basato sul volume di ingestion.
• A consumo sul dato ingerito. Microsoft Learn documenta per Microsoft Sentinel un prezzo basato sul livello (tier) in cui il dato viene ingerito, con una modalità pay-as-you-go legata al volume effettivo e livelli di impegno che partono da 100 GB al giorno, alzabili in qualsiasi momento e abbassabili solo ogni 31 giorni.

La conseguenza è la stessa nei due casi: la leva sul costo non è lo sconto che strappi in trattativa, è quanto dato decidi di mandare e in quale forma. Prima della firma serve sapere quali sorgenti sono rumorose e se la piattaforma consente di filtrare o trasformare i dati prima dell'ingestione. Il confronto puntuale tra i due modelli sta in Google SecOps e Microsoft Sentinel a confronto, i fattori che muovono il conto di un passaggio di piattaforma in quanto costa una migrazione SIEM.

Criterio 2. Copertura delle sorgenti, verificata sul tuo inventario

Tutte le piattaforme dichiarano centinaia di integrazioni. Il numero da solo non dice niente: conta se dentro quelle centinaia ci sono le tue. La documentazione Google SecOps, per esempio, indica per il pacchetto Standard l'accesso a oltre 300 integrazioni SOAR predefinite. Buona base di partenza, ma la verifica resta la tua.

Il modo serio di farla è banale e quasi nessuno lo fa: prendi l'elenco delle tue sorgenti e chiedi al fornitore, riga per riga, se esiste un parser pronto, se è mantenuto da lui e cosa succede quando il vendor della sorgente cambia il formato dei log. Le risposte scomode arrivano sempre dagli stessi posti: applicativi verticali italiani, gestionali su misura e sistemi industriali. Una sorgente senza parser non è una casella da spuntare, è un progetto: stimala con le sue ore e il suo responsabile, o riapparirà a tre mesi dalla partenza sotto forma di angolo cieco.

Criterio 3. Quante detection arrivano pronte, e quali

Un SIEM senza regole è un motore di ricerca sui log. La qualità del primo mese la determina il patrimonio di detection che arriva già scritto e mantenuto dal vendor, e quel patrimonio cambia con il pacchetto che compri.

La documentazione Google SecOps è esplicita e vale come esempio di lettura: il pacchetto Standard consente fino a 1.000 regole a evento singolo e 75 multi evento con un sottoinsieme di curated detection rules, mentre le Google Curated Detections illimitate partono dal pacchetto Enterprise, che alza anche i limiti sulle regole e aggiunge UEBA e Gemini; la prioritizzazione degli alert EDR e le detection Emerging and Active IR arrivano con Enterprise Plus.

In demo chiedi quali detection sono attive il primo giorno, su quali sorgenti e con quale copertura rispetto alle tecniche MITRE ATT&CK del tuo settore, chi le mantiene quando una tecnica cambia, e quante regole specifiche del tuo ambiente servono comunque. È l'ultima domanda a decidere il progetto: nessun catalogo di regole pronte sa che quel server FTP fa quel traffico strano da nove anni per una buona ragione.

Criterio 4. Retention: fino a dove puoi guardare indietro

È il criterio che si sottovaluta di più in fase di scelta e si rimpiange di più durante un incidente: quando ricostruisci un'intrusione, il punto di ingresso è quasi sempre settimane prima dell'alert che ti ha svegliato.

• Per Google SecOps la documentazione indica che "by default, Google retains 12 months of your data", estendibili fino a cinque anni in fase di ordine. Sono dati a caldo, quindi interrogabili.
• Per Microsoft Sentinel la documentazione indica che i dati ingeriti nel workspace sono conservati senza addebito per i primi 90 giorni, mentre oltre i 90 giorni la retention viene fatturata secondo i prezzi standard di Log Analytics, con la possibilità di spostare le tabelle a volume alto su un piano di archiviazione a costo inferiore.

Il collegamento con la compliance è diretto. L'articolo 25 del D.Lgs. 138/2024 fissa i tempi di notifica al CSIRT Italia: preallarme entro 24 ore, notifica entro 72 ore, relazione finale entro un mese. La relazione finale chiede causa, impatto e misure adottate: se i dati del periodo in cui l'attaccante è entrato non ci sono più, la scrivi a memoria.

Criterio 5. Il tempo di messa a regime

L'attivazione tecnica di una piattaforma cloud è veloce. Il tempo vero se ne va altrove, ed è quello che quasi nessun preventivo dettaglia.

• Collegare le sorgenti una per una e verificare che arrivino tutti gli eventi, non solo i primi.
• Controllare che i parser estraggano i campi utili: un log che entra ma non viene letto bene sembra copertura e non lo è.
• Calibrare le regole sul contesto e abbattere i falsi positivi fino a un numero gestibile in un turno.
• Definire cosa succede quando un alert scatta: chi lo prende, con quali tempi, chi viene svegliato.

Il criterio qui non è la piattaforma ma il piano: chiedilo a fasi, con date, responsabili e criteri di uscita, e chiedi chi fa il lavoro, se il vendor, un partner o il tuo team che nel frattempo ha anche il resto da fare. La misura ACN DE.CM-01, sempre nell'allegato 2, chiede strumenti tecnici "presenti, aggiornati, mantenuti e configurati in modo adeguato" per rilevare tempestivamente gli incidenti significativi: "aggiornati" e "mantenuti" descrivono un lavoro continuo, non un collaudo.

Criterio 6. Chi scrive le regole dopo il primo mese

Il detection engineering non finisce mai, perché non finiscono mai né le tecniche di attacco né i cambiamenti nella tua infrastruttura. Ogni nuovo applicativo, ogni migrazione, ogni acquisizione genera regole da scrivere, testare e mantenere.

C'è poi un dettaglio da guardare prima della firma: le regole si scrivono nel linguaggio della piattaforma. Google SecOps usa YARA-L, Microsoft Sentinel usa KQL, altre hanno la propria sintassi. Esiste un formato aperto, Sigma, che si definisce "a generic, open, and structured detection format" e permette di convertire una regola verso i backend supportati, ma la conversione va comunque verificata e testata. Il lavoro di detection engineering che fai oggi, quindi, è solo in parte trasferibile, e questo pesa sia sulla scelta iniziale sia su un eventuale cambio futuro, come si vede in una migrazione da QRadar a Google SecOps.

Le domande da mettere nel contratto, non nella chiacchierata: quante regole nuove al mese sono previste, chi le scrive, chi le valida, dove sono documentate e chi risponde se una regola smette di funzionare dopo un aggiornamento.

Criterio 7. Cosa succede quando l'analista se ne va

Nel mid-market italiano la piattaforma la sa usare quasi sempre una persona sola: quella che ha fatto il progetto, conosce le eccezioni e sa perché quella regola è stata silenziata a marzo. Il giorno in cui cambia lavoro la conoscenza esce dalla porta con lei, e il SIEM continua a funzionare esattamente come prima, cioè producendo alert che da quel momento non legge più nessuno.

È un rischio di continuità, non tecnico, e si valuta prima della firma con tre domande: dove sono scritte le procedure operative, chi copre notti e weekend, cosa succede durante le ferie di agosto. Costruire in casa un presidio continuo significa un team di circa sei analisti, un costo di mercato nell'ordine di 400-600 mila euro l'anno di solo personale, con figure difficili da trovare e ancora più difficili da trattenere. Il confronto tra le due strade sta in SOC interno o gestito.

Le domande da mettere nella richiesta d'offerta

Per confrontare più fornitori sullo stesso metro, queste sei domande producono risposte comparabili e non si risolvono con una slide.

1. Su cosa si paga, e cosa succede al conto se il volume di log cresce del 30%.
2. Quante delle mie sorgenti, dal mio elenco, hanno un parser pronto e mantenuto da voi.
3. Quali detection sono attive il primo giorno e quali richiedono il pacchetto superiore.
4. Quanti mesi di dati restano interrogabili senza costi aggiuntivi, e quanto costa andare oltre.
5. Quante regole nuove al mese sono incluse, chi le scrive e chi guarda gli alert fuori orario.
6. Se tra tre anni cambio piattaforma, cosa mi porto via: i dati grezzi, le regole, i casi storici.

Tre errori che si pagano dopo

• Scegliere sul listino invece che sul volume. Il costo non è il prezzo d'ingresso, è la curva a tre anni mentre i log crescono.
• Comprare la piattaforma e rimandare la decisione su chi la gestisce. La licenza parte, il presidio no, e intanto gli alert si accumulano: le due decisioni vanno prese insieme, anche se i budget sono separati.
• Valutare l'open source solo sul costo di licenza. È una scelta legittima e a volte la migliore, ma la licenza a zero sposta il costo su infrastruttura, manutenzione delle regole e ore di persone, non lo elimina.

Dove sta andando la piattaforma

Una variabile in più, che non è un errore: le roadmap si muovono, ed è normale. Microsoft, per esempio, documenta che dopo il 31 marzo 2027 Microsoft Sentinel sarà disponibile solo nel portale Microsoft Defender e invita a pianificare la transizione. La domanda utile in fase di scelta è dove sta andando la piattaforma nei prossimi tre anni.

Il software è metà del lavoro

Il criterio che pesa più di tutti non compare in nessuna scheda prodotto: chi lo fa funzionare ogni giorno. Un SIEM ben scelto e in mano a nessuno dà lo stesso risultato di un SIEM scelto male, solo a un costo maggiore. Per l'ordine di grandezza del rischio che stai coprendo: secondo il report IBM Cost of a Data Breach 2025, nel comunicato di IBM Italia, il costo medio di una violazione dei dati in Italia è di 3,31 milioni di euro.

AmagisTech costruisce SOC gestiti per il mid-market italiano su piattaforma aperta, mettendo detection engineering e presidio continuo sopra la piattaforma che il cliente ha scelto. Se vuoi confrontare i tuoi numeri, volume di log, sorgenti e ore di presidio, prima di firmare una licenza, guarda i nostri servizi di observability e SecOps.

In sintesi: un software SIEM si valuta su sette criteri, il modello di costo legato al volume, la copertura reale delle tue sorgenti, le detection incluse nel pacchetto, la retention, il tempo di messa a regime, chi scrive le regole dopo il primo mese e chi presidia quando una persona manca. I primi quattro si leggono nella documentazione dei vendor. Gli ultimi tre riguardano il tuo team, e decidono se tra un anno avrai uno strumento o un archivio.