{"id":15363,"date":"2026-01-05T06:15:50","date_gmt":"2026-01-05T11:15:50","guid":{"rendered":"https:\/\/www.netwitness.com\/blog\/key-metrics-to-evaluate-siem-system\/"},"modified":"2026-05-05T02:42:31","modified_gmt":"2026-05-05T06:42:31","slug":"key-metrics-to-evaluate-siem-system","status":"publish","type":"blog","link":"https:\/\/www.netwitness.com\/it\/blog\/key-metrics-to-evaluate-siem-system\/","title":{"rendered":"Indicatori chiave per valutare l’efficacia del SIEM in un SOC"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Overview\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t

In che modo i team SOC valutano l'efficacia effettiva di un sistema SIEM?<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

I team<\/span>\u00a0SOC valutano l’efficacia del SIEM esaminando i risultati, non il volume degli avvisi. L’attenzione \u00e8 rivolta alla capacit\u00e0 dei log SIEM di garantire un rilevamento pi\u00f9 rapido, avvisi pi\u00f9 chiari e una risposta pi\u00f9 tempestiva. Metriche quali il tempo di rilevamento e risposta<\/span>\u00a0<\/span>(MTTD\/MTTR)<\/span>, la qualit\u00e0\u00a0<\/span>ed azionabilit\u00e0 degli<\/span>\u00a0avvisi e la copertura del monitoraggio\u00a0<\/span>dei log indicano se il SIEM sta migliorando il monitoraggio della sicurezza o semplicemente aggiungendo rumore operativo.<\/span><\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Il vostro SIEM SOC \u00e8 sommerso dagli avvisi. Gli analisti sono esausti. La direzione vuole prove che l’investimento nel monitoraggio della sicurezza sia\u00a0davvero\u00a0\u00a0giustificato. Vi suona familiare?\u00a0<\/span>\u00a0<\/span><\/p>

Il punto \u00e8 questo: la maggior parte delle organizzazioni tratta il proprio software di sicurezza informatica SIEM come una scatola nera. I log entrano, gli avvisi escono e nessuno sa davvero se funziona finch\u00e9 non si verifica un problema. Questa non \u00e8 sicurezza operativa. \u00c8 solo una messinscena.\u00a0<\/span>\u00a0<\/span><\/p>

Analizziamo le metriche che contano davvero quando si valuta se il sistema SIEM sta facendo il suo lavoro o sta solo intaccando il budget.<\/span>\u00a0<\/span><\/p>

\u00a0<\/span><\/p>

Perch\u00e9 \u00e8 importante misurare l’efficacia dei sistemi SIEM<\/span><\/span><\/strong><\/h2>

Prima di addentrarci nei KPI SIEM specifici per SOC, vediamo perch\u00e9 non si tratta solo di un altro esercizio di spuntare caselle.\u00a0<\/span>\u00a0<\/span><\/p>

Quando si eseguono operazioni di monitoraggio della sicurezza con un sistema SIEM, ci si trova di fronte a tre realt\u00e0: tempo limitato a disposizione degli analisti, superficie di attacco illimitata e\u00a0team dirigenziali\u00a0che vogliono vedere il ROI in un foglio di calcolo. Senza metriche concrete, non \u00e8 possibile ottimizzare il monitoraggio dei log, giustificare il<\/span>\u00a0<\/span><\/p>

numero di dipendenti e dimostrare che i migliori strumenti SIEM stanno<\/a> riducendo il rischio.<\/span>\u00a0<\/span><\/p>

Ci\u00f2 significa che le metriche non servono a creare dashboard sofisticate, ma a rendere il SOC pi\u00f9 intelligente, veloce e difendibile.<\/span><\/p>

\"SIEM<\/span><\/p>

Metriche fondamentali che descrivono il vero sistema SIEM<\/span><\/span> <\/strong><\/h2>

Tempo medio di rilevamento (MTTD)<\/span><\/span><\/strong><\/h3>

Questo \u00e8 semplice. Quanto tempo occorre dall’inizio di un attacco affinch\u00e9 i log SIEM attivino un allarme che venga notato?\u00a0<\/span>\u00a0<\/span><\/p>

Il\u00a0<\/span>MTTD<\/span><\/a>\u00a0medio in tutti i settori \u00e8 di circa 207 giorni. S\u00ec, giorni. Se il vostro \u00e8 misurato in ore, siete gi\u00e0 in vantaggio. Se \u00e8 misurato in minuti per le minacce critiche, siete al top.\u00a0<\/span>\u00a0<\/span><\/p>

Ma ecco cosa sfugge alla maggior parte delle persone: l’MTTD non riguarda solo i vostri strumenti di monitoraggio SIEM. Riguarda la qualit\u00e0 dei log, le regole di correlazione e il fatto che i vostri analisti si fidino abbastanza degli allarmi da indagare immediatamente. Un MTTD basso con un alto numero di falsi positivi \u00e8 insignificante.<\/span>\u00a0<\/span><\/p>

Tempo medio di risposta (MTTR)<\/span><\/span><\/strong><\/h3>

Il rilevamento \u00e8 solo met\u00e0 della battaglia. L’MTTR misura il divario tra \u201cvediamo il problema\u201d e \u201cabbiamo contenuto il problema\u201d.\u00a0<\/span>\u00a0<\/span><\/p>

Per un\u00a0<\/span>SOC SIEM<\/span><\/a>\u00a0ben calibrato, \u00e8 auspicabile che questo valore sia inferiore a un’ora per gli incidenti critici. Qualunque valore superiore a quattro ore significa che i vostri\u00a0playbook\u00a0di risposta devono essere migliorati, che i vostri percorsi di escalation sono interrotti o che i vostri analisti non dispongono degli strumenti necessari per agire rapidamente.\u00a0<\/span>\u00a0<\/span><\/p>

Cosa influenza l’MTTR? I soliti sospetti: affaticamento da allarmi,\u00a0runbook\u00a0poco chiari, troppi strumenti nello\u00a0stack\u00a0e analisti che dedicano pi\u00f9 tempo alla raccolta di informazioni\u00a0di contesto piuttosto\u00a0che alla risposta vera e propria.\u00a0<\/span>\u00a0<\/span><\/p>

La configurazione del monitoraggio dei log dovrebbe alimentare direttamente i flussi di lavoro di risposta, fornendo contesto e prove utili fin dal primo allarme, invece di creare ulteriori passaggi di indagine che rallentano il contenimento.<\/span><\/p>

Rapporto tra allarmi e incidenti<\/span><\/span><\/strong><\/h3>

Questo \u00e8 il parametro che distingue i SOC maturi dalle fabbriche di allarmi. Su 1.000 allarmi, quanti si trasformano in incidenti reali che meritano di essere indagati?\u00a0<\/span>\u00a0<\/span><\/p>

Se sei al di sotto del 10%, hai un problema di messa a punto. I tuoi log SIEM sono troppo rumorosi, le tue regole di correlazione sono troppo sensibili o stai monitorando cose che non contano.\u00a0\u00a0<\/span>\u00a0<\/span><\/p>

I SOC pi\u00f9 performanti puntano a tassi di conversione del 15-25%. Ci\u00f2 significa che quando scatta un allarme, c’\u00e8 una buona probabilit\u00e0 che sia reale. Gli analisti iniziano a fidarsi del sistema. I tempi di risposta diminuiscono. Tutti sono pi\u00f9 soddisfatti.\u00a0<\/span>\u00a0<\/span><\/p>

Per migliorare questo aspetto, concentratevi sulla riduzione dei falsi positivi attraverso una migliore configurazione del monitoraggio dei log e una correlazione pi\u00f9 intelligente. Non limitatevi a disattivare gli allarmi rumorosi. Cercate di capire perch\u00e9 scattano e risolvete\u00a0il problema\u00a0alla radice.<\/span>\u00a0<\/span><\/p>

Copertura della fonte di log<\/span><\/span><\/strong><\/h3>

Non \u00e8 possibile rilevare ci\u00f2 che non si vede. Questa metrica tiene traccia della percentuale delle risorse critiche che inviano log SIEM alla piattaforma.\u00a0<\/span>\u00a0<\/span><\/p>

Puntare a una copertura superiore al 95% delle risorse di livello 1 (controller di dominio, database di grande valore, server connessi a Internet). Se la copertura \u00e8 inferiore, si creano punti ciechi che un aggressore potr\u00e0 individuare.\u00a0<\/span>\u00a0<\/span><\/p>

Ma la copertura non riguarda solo la quantit\u00e0. Si stanno ottenendo i log giusti? I log degli eventi di Windows senza la registrazione\u00a0PowerShell\u00a0abilitata sono quasi inutili per rilevare gli attacchi moderni. Il monitoraggio dei log dovrebbe tenere traccia della qualit\u00e0 dei log, non solo del loro volume.<\/span>\u00a0<\/span><\/p>

Precisione nel rilevamento delle minacce<\/span><\/span><\/strong><\/h3>

Questo parametro misura il tasso di veri positivi. Quando il monitoraggio SIEM segnala qualcosa come dannoso, con quale frequenza si tratta\u00a0davvero di una minaccia reale?\u00a0<\/span>\u00a0<\/span><\/p>

Il calcolo \u00e8 semplice: dividi il numero di veri positivi confermati per il totale degli avvisi esaminati.<\/span>\u00a0
Se il risultato \u00e8 inferiore al 40%, significa che i tuoi analisti stanno trascorrendo la maggior parte della giornata a inseguire falsi allarmi.<\/span><\/p>

Migliorare l’accuratezza significa disporre di feed di intelligence sulle minacce pi\u00f9 efficaci, regole di correlazione ottimizzate e una convalida regolare rispetto ai modelli di attacco noti. I migliori strumenti SIEM forniscono i framework necessari a tal fine, ma \u00e8 comunque necessario l’intervento umano per la convalida e la regolazione.<\/span>\u00a0<\/span><\/p>

Metriche di produttivit\u00e0 degli analisti<\/span><\/span> <\/strong><\/h3>

\u00c8 qui che la questione si fa interessante. Quanti allarmi pu\u00f2 gestire efficacemente un analista per turno? Quanto tempo richiede in media un’indagine? Qual \u00e8 il tasso di chiusura dei casi?\u00a0<\/span>\u00a0<\/span><\/p>

Un analista SOC produttivo dovrebbe essere in grado di indagare su 15-25 allarmi\u00a0nell\u2019arco di un\u00a0turno di otto ore, ipotizzando una complessit\u00e0 ragionevole. Se\u00a0il vostro team\u00a0gestisce pi\u00f9 di 50 allarmi a persona, o sta ignorando la maggior parte di essi oppure il monitoraggio dei log sta generando troppo rumore.\u00a0<\/span>\u00a0<\/span><\/p>

Tieni traccia del tempo impiegato per ogni fase dell’indagine: triage iniziale, raccolta delle prove, analisi e documentazione. Se gli analisti dedicano pi\u00f9 tempo alla documentazione che alle indagini, i tuoi flussi di lavoro devono essere ottimizzati.<\/span><\/p>

Metriche di acquisizione e<\/span>d<\/span>\u00a0elaborazione dei dati<\/span><\/strong><\/h3>

Per un monitoraggio della sicurezza realmente in tempo reale, il ritardo di acquisizione dovrebbe essere inferiore a 60 secondi per le fonti di log critiche. Qualsiasi ritardo superiore ai cinque minuti significa operare con una visibilit\u00e0 parziale, se non cieca, proprio quando serve di pi\u00f9.<\/span>\u00a0<\/span><\/p>

\u00c8 inoltre essenziale controllare la capacit\u00e0 EPS (eventi al secondo). Se il SIEM funziona costantemente oltre l\u201980% della capacit\u00e0 di licenza, basta un singolo evento di sicurezza o un picco improvviso di attivit\u00e0 per iniziare a perdere log durante un incidente.<\/span>\u00a0
E perdere log nel momento critico non \u00e8 un rischio teorico: \u00e8 un fallimento operativo.<\/span>\u00a0<\/span><\/p>

Punteggio di efficacia della regola<\/span><\/span><\/strong><\/h3>

Non tutte le regole di correlazione sono uguali. Tieni traccia delle regole che individuano effettivamente le minacce e di quelle che generano solo rumore.<\/span>\u00a0<\/span><\/p>

Per ogni regola di rilevamento, misura:\u00a0il numero totale di\u00a0<\/span>attivazioni, il<\/span><\/b>\u00a0tasso di veri positivi,\u00a0il\u00a0tempo necessario per l’indagine ed il numero di\u00a0incidenti\u00a0effettivamente\u00a0generati. Elimina le regole che danno costantemente risultati insoddisfacenti. Il tuo SIEM per il monitoraggio della sicurezza dovrebbe diventare pi\u00f9 intelligente nel tempo, non solo pi\u00f9 grande.<\/span>\u00a0<\/span><\/p>

Le regole che producono risultati costantemente scadenti dovrebbero essere eliminate o ricalibrate.<\/span>\u00a0
Un SIEM efficace non si limita ad accumulare regole nel tempo:\u00a0<\/span>diventa pi\u00f9 intelligente<\/span><\/b>, riducendo il rumore e aumentando il valore per il SOC.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t

\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Migliora il rilevamento e la risposta alle minacce con NetWitness\u00ae SIEM<\/p>\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Un sistema\u00a0<\/span>SIEM<\/span><\/a>\u00a0deve, prima di tutto,\u00a0<\/span>acquisire correttamente i log che gli vengono inviati<\/span>.<\/span><\/b>\u00a0Per questo \u00e8 fondamentale monitorare il\u00a0<\/span>ritardo di acquisizione<\/span><\/b>\u00a0\u2014 quanto i log arrivano in ritardo rispetto al tempo reale \u2014 insieme agli\u00a0<\/span>errori di\u00a0parsing<\/span>\u00a0<\/span><\/b>e agli<\/span>\u00a0<\/span><\/b>eventi di perdita dei dati<\/span>.<\/span>\u00a0<\/span><\/p>