Che differenza c'è tra un SIEM e un XDR?

Il SIEM parte dai dati: ingerisce eventi da qualunque sorgente sappia mandargli un log, li normalizza e lascia a chi lo configura il compito di scrivere le regole. L'XDR parte dal rilevamento: è legato ai sensori del suo fornitore, soprattutto endpoint, identità e posta, e arriva con la logica di correlazione già scritta per quei sensori. Il primo è più largo e richiede più lavoro, il secondo è più stretto e più immediato. Nella pratica convivono spesso: l'XDR presidia bene l'endpoint, il SIEM tiene insieme quello che l'endpoint non vede, come il gestionale, il centralino o l'accesso fisico.

La NIS2 obbliga ad avere un SIEM?

No. La direttiva NIS2 e il decreto legislativo 138/2024 che la recepisce in Italia chiedono misure di gestione dei rischi e la capacità di rilevare, gestire e notificare gli incidenti entro tempi stretti, ma non impongono alcuna tecnologia specifica e non nominano il SIEM. Il punto pratico è un altro: chi deve notificare un incidente significativo con un preallarme rapido ha bisogno di accorgersene, e in un'infrastruttura con molte sorgenti diverse la correlazione è il modo più diretto per riuscirci. Resta una scelta di mezzi, che va giustificata rispetto al rischio e non a una casella da spuntare.

Cos'è un SIEM e quando serve davvero?

Un SIEM è la piattaforma che raccoglie e correla in tempo quasi reale gli eventi di sicurezza dei sistemi aziendali.

Un SIEM, sigla di security information and event management, è una piattaforma che raccoglie in un unico punto gli eventi prodotti da server, applicativi, firewall, sistemi di posta e identità cloud, li normalizza in un formato comune e vi applica regole di correlazione per far emergere in tempo quasi reale le sequenze che somigliano a un attacco. La differenza rispetto a un archivio di log sta tutta nel verbo: l'archivio conserva e restituisce quello che gli viene chiesto, il SIEM ragiona sul flusso mentre passa e alza un allarme senza che nessuno abbia formulato la domanda. Un tentativo di accesso fallito non significa niente; trecento tentativi falliti su venti account diversi, seguiti da un accesso riuscito da un paese in cui l'azienda non ha dipendenti, sono un'altra cosa. Il valore della piattaforma è tutto qui: tenere insieme eventi che, presi uno per uno, nessuno guarderebbe.

Come funziona, e dove si decide l'esito

Il termine nasce da un rapporto Gartner del 2005 firmato da Amrit Williams e Mark Nicolett, che univa due mercati fino ad allora distinti, la gestione delle informazioni di sicurezza e quella degli eventi. Il ciclo è rimasto lo stesso: ingestione, normalizzazione, correlazione, allarme. La parte che decide l'esito però non è nessuna delle quattro, è la taratura che sta in mezzo. Una regola scritta bene distingue l'amministratore che lavora di notte dall'attaccante che sta usando le sue credenziali; una regola presa dal catalogo predefinito e mai toccata produce ogni giorno decine di allarmi che dopo la prima settimana nessuno legge più. Il secondo vincolo è economico e struttura l'intero progetto: le licenze si pagano quasi sempre a volume di dati ingeriti o a eventi al secondo, quindi mandare al SIEM tutto quello che si ha è il modo più rapido per moltiplicare la spesa senza migliorare di nulla la capacità di accorgersi di qualcosa. Le sorgenti si scelgono: identità, posta, endpoint, perimetro, accessi privilegiati. Il resto resta nell'archivio del log management, dove costa poco e si consulta quando serve.

Un esempio concreto

In un gruppo industriale con 600 dipendenti e tre stabilimenti, quattro sistemi diversi registrano nel giro di venti minuti quattro eventi banali: la VPN accetta una connessione da un operatore di rete mai visto prima, l'agente sugli endpoint segnala uno strumento di estrazione credenziali bloccato su un portatile, il controller di dominio crea un nuovo account amministrativo e il firewall vede un trasferimento verso un servizio di archiviazione esterno. Nessuno dei quattro sistemi ha visto la sequenza, perché ognuno ha visto solo il proprio pezzo, dentro la normale rumorosità di un'infrastruttura. Il SIEM la vede perché i quattro eventi condividono lo stesso account nel giro di venti minuti, e la trasforma in un unico allarme con priorità alta. È la differenza tra chiudere la faccenda quella sera con una risposta all'incidente e scoprirla settimane dopo dal riscatto.

Quando serve e quando no

Un SIEM ha senso quando ricorrono tre condizioni insieme: sorgenti eterogenee che nessun singolo strumento vede tutte, un rischio o un obbligo che rende inaccettabile accorgersi di un incidente settimane dopo, e soprattutto qualcuno che gli allarmi li guardi davvero. La terza è quella che manca quasi sempre. Una piattaforma installata e non presidiata non è una difesa parziale: è un costo ricorrente il cui unico esito è un cruscotto che nessuno apre. La funzione descritta alla voce SOC, interna o affidata a un fornitore, va quindi decisa prima della piattaforma e non dopo. Per un'azienda con un perimetro semplice l'ordine ragionevole è un altro: prima la conservazione dei log fatta come si deve, che per gli accessi degli amministratori di sistema il Provvedimento del Garante del 27 novembre 2008 rende già un obbligo, poi il rilevamento sugli endpoint con qualcuno che risponde, e il SIEM quando le sorgenti da tenere insieme sono davvero più di una manciata. Detto senza giri di parole: a molte PMI il SIEM non serve, o non serve ancora, e comprarlo prima del resto sposta soldi dalla difesa alla licenza.