Log management vs SIEM: differenze e quando basta il primo

La risposta breve: il log management raccoglie, conserva e rende consultabili i log dei sistemi; il SIEM usa quegli stessi log per rilevare gli attacchi, mettendo in relazione eventi di sorgenti diverse e generando alert con una priorità. Il log management basta quando l'obiettivo è conservare e ritrovare, per un audit, un guasto o un'indagine a posteriori. Serve un SIEM quando devi accorgerti di un attacco mentre è in corso.

Nella guida del NIST sul tema, la SP 800-92, il SIEM è una delle due grandi famiglie di software su cui si costruisce un'infrastruttura di log management, accanto alla raccolta centralizzata basata su syslog. Ogni SIEM fa log management, non ogni log management fa il lavoro di un SIEM. La definizione completa è nella guida su cos'è un SIEM e come funziona.

Cos'è il log management

Un log è la registrazione di un evento avvenuto in un sistema o in una rete: un accesso, un errore, una regola del firewall che scatta. La NIST SP 800-92 (settembre 2006) definisce il log management come il processo con cui i dati di log vengono generati, trasmessi, conservati, analizzati ed eliminati. La bozza di revisione, la SP 800-92 Rev. 1 dell'11 ottobre 2023, ancora allo stato di bozza pubblica, al posto di analizzare scrive accedere: il log management è la filiera che porta il dato a chi lo usa, e l'analisi è uno degli usi che rende possibili.

Le sue funzioni, secondo la SP 800-92:

• Raccolta dai sistemi che generano i log verso uno o più server, con una console per consultarli e produrre report.
• Parsing, filtro e aggregazione: si estraggono i campi, si scartano le voci inutili, si accorpano quelle ripetute (mille righe di una scansione diventano una riga con un contatore).
• Conservazione: rotazione, compressione, archiviazione. NIST distingue la retention ordinaria dalla preservation, cioè tenere log che di norma si eliminerebbero perché riguardano un incidente o un'indagine.
• Integrità: un'impronta di ogni file archiviato, conservata in modo sicuro, rivela le modifiche successive.
• Eliminazione delle voci vecchie che non servono più o sono già archiviate.

Dove finisce il log management e comincia il SIEM

Il confine non sta nell'elenco delle funzioni: tra quelle del log management la SP 800-92 mette anche normalizzazione e correlazione. Sta nello scopo e nella profondità.

Sullo scopo, in una nota della sezione dedicata al SIEM, NIST scrive che i prodotti di log management, anche quando hanno funzioni simili, sono di norma pensati per un'ampia varietà di log e, nella formula della guida, sono not focused on the analysis of security-related log entries. La stessa nota precisa che questo non vuol dire che non si possano usare per la sicurezza.

Sulla profondità, la guida spiega che per ogni tipo di sorgente supportata un SIEM sa quali campi contano, salvo i formati generici come syslog, per esempio quale campo del log di una certa applicazione contiene l'indirizzo IP di origine, e che questo migliora in modo significativo normalizzazione, analisi e correlazione rispetto a un software che conosce le sorgenti in modo meno dettagliato. Un server SIEM analizza i dati di tutte le sorgenti, correla gli eventi, individua e mette in ordine di priorità quelli significativi e, se lo si vuole, avvia una risposta.

In pratica:

• La domanda. Il log management risponde a cosa è successo, quando qualcuno lo chiede. Il SIEM valuta in continuo regole di rilevamento sui dati che arrivano, per dire se sta succedendo qualcosa adesso.
• Il modello dei dati. Un log management può conservare il dato com'è e indicizzarlo per la ricerca. Un SIEM riconduce ogni evento a campi noti (utente, host, IP, tipo di evento), così una regola scritta una volta vale per firewall, VPN e controller di dominio. Lo schema decide anche cosa si può chiedere ai dati, come spiega il confronto tra SIEM e security observability.
• Il risultato. Il log management produce archivi, ricerche e report. Il SIEM produce casi: alert con priorità e contesto. Fra le funzioni tipiche NIST cita proprio il dare più priorità a un attacco contro un sistema operativo vulnerabile o un host più importante.
• Chi lavora e cosa costa. Il log management serve a sistemisti, sviluppatori e audit, e il suo costo segue volume e durata della conservazione. Il SIEM aggiunge regole da mantenere, falsi positivi da calibrare e qualcuno che lavori gli alert a ogni ora. I modelli di costo sono confrontati nella guida alla scelta di un software SIEM.

Cosa chiedono le regole italiane sui log

Prima di scegliere conviene leggere cosa chiede davvero ogni norma.

Garante privacy: gli accessi degli amministratori di sistema

Il provvedimento del Garante del 27 novembre 2008 sugli amministratori di sistema (G.U. n. 300 del 24 dicembre 2008, modificato con il provvedimento del 25 giugno 2009), al punto 2, lettera f) del dispositivo, chiede di registrare gli accessi logici degli amministratori ai sistemi di elaborazione e agli archivi elettronici. Le registrazioni devono avere caratteristiche di "completezza, inalterabilità e possibilità di verifica della loro integrità", riportare i riferimenti temporali e la descrizione dell'evento ed essere conservate per un congruo periodo, "non inferiore a sei mesi". Il D.Lgs. 101/2018 (art. 22, comma 4) prevede che i provvedimenti del Garante continuino ad applicarsi in quanto compatibili con il GDPR.

Le FAQ del Garante sul provvedimento precisano che non è richiesto di registrare l'attività svolta, come i comandi impartiti, e che nei casi più semplici il requisito di inalterabilità può essere soddisfatto con gli strumenti software in dotazione e l'esportazione periodica dei log su supporti non riscrivibili; nei casi più complessi si può ricorrere a log server centralizzati. È un requisito di log management, non di rilevamento: comprare un SIEM solo per soddisfarlo vuol dire pagare una correlazione che nessuno usa.

NIS2: le misure di base dell'ACN

Per i soggetti NIS la determinazione ACN 379907/2025 fissa le misure di base: allegato 1 per gli importanti, allegato 2 per gli essenziali. Sui log la misura è la stessa per entrambi, PR.PS-04: "I registri di log sono generati e resi disponibili per il monitoraggio continuo". Chiede di registrare tutti gli accessi da remoto e quelli con utenze con privilegi amministrativi, di conservare "in modo sicuro e possibilmente centralizzato" almeno per i sistemi rilevanti i log necessari al monitoraggio degli eventi di sicurezza, e di fissare i tempi di conservazione in base alla valutazione del rischio. Fin qui è log management.

La misura DE.CM-01 cambia natura: chiede, almeno per i sistemi rilevanti, strumenti tecnici presenti, aggiornati, mantenuti e configurati in modo adeguato "per rilevare tempestivamente gli incidenti significativi". Per gli essenziali aggiunge il monitoraggio di accessi da remoto, attività dei sistemi perimetrali, eventi amministrativi di rilievo e accessi eseguiti o falliti a risorse di rete, endpoint e applicativi, con parametri quali-quantitativi per rilevare accessi non autorizzati o con abuso dei privilegi. Le misure non nominano il SIEM e non impongono uno strumento: chiedono un risultato, il rilevamento tempestivo, che un archivio non interrogato non produce.

L'art. 25 del D.Lgs. 138/2024 chiede una pre-notifica al CSIRT Italia entro 24 ore da quando si è venuti a conoscenza dell'incidente significativo e una notifica entro 72 ore con, ove disponibili, gli indicatori di compromissione. Quegli indicatori si ricavano dai log, se ci sono e se si possono cercare in fretta.

ISO/IEC 27001:2022

Nell'Annex A i temi corrispondono a tre controlli distinti: 8.15 (logging), 8.16 (attività di monitoraggio) e 8.17 (sincronizzazione degli orologi). Anche qui registrare e sorvegliare sono separati.

Quando basta il log management

Un log management fatto bene, centralizzato, con integrità e tempi di conservazione decisi per iscritto, è sufficiente se:

• l'obiettivo è dimostrare: access log degli amministratori, tracciabilità chiesta da un cliente, evidenze per un audit;
• i log servono soprattutto all'esercizio: guasti, prestazioni, errori applicativi;
• le indagini sono a posteriori: si ricostruisce chi ha fatto cosa dopo una segnalazione;
• il rilevamento è coperto altrove, per esempio da un EDR presidiato o da un servizio MDR, e il log management resta l'archivio per le indagini;
• nessuna norma ti chiede il rilevamento: non sei un soggetto NIS, non sei un'entità finanziaria soggetta a DORA (che chiede di individuare tempestivamente le attività anomale) e nessun contratto chiede un monitoraggio continuo, quindi il rilevamento resta una scelta sul rischio.

Il limite lo indicava già la SP 800-92 nel 2006: tra i problemi del log management c'è fare in modo che gli amministratori analizzino i log in modo regolare ed efficace. Avere tutti i log in un posto è la premessa per accorgersi di qualcosa, non il fatto di accorgersene.

Quando serve un SIEM

• Sei un soggetto NIS. DE.CM-01 chiede di rilevare tempestivamente gli incidenti significativi. Il SIEM non è l'unico modo per arrivarci, ma è lo strumento costruito per questo lavoro.
• Gli attacchi che ti preoccupano attraversano più sistemi. Un accesso VPN da un paese insolito, poi un'utenza che ottiene privilegi amministrativi, poi una lettura massiva su un file server: ogni log, preso da solo, sembra normale.
• Il volume supera la lettura umana. Servono regole che lavorino per eccezioni.
• Devi rispondere in ore. Se ricostruire un incidente richiede di incrociare a mano file di sistemi diversi, la scadenza della notifica arriva prima della risposta.

Dal log management al SIEM, senza rifare il lavoro

Il passaggio non butta via niente, perché il SIEM legge dalla stessa filiera di raccolta. Conviene costruire il log management pensando al passo dopo.

1. Parti dallo scopo. NIST raccomanda di definire requisiti e obiettivi del logging prima delle politiche, e di rendere obbligatori registrazione e analisi dei dati più importanti: sapere perché si raccoglie ogni sorgente evita di pagare volume inutile.
2. Sincronizza gli orologi. La SP 800-92 mette fra i compiti ordinari la verifica che l'orologio di ogni host sia allineato a una sorgente di tempo comune, per esempio un server NTP. Con orari sfasati la correlazione mette in fila gli eventi nell'ordine sbagliato.
3. Rendi affidabile il trasporto. Già nel 2006 NIST notava che la maggior parte dei software syslog usava UDP, senza garanzia di consegna né cifratura in transito, e che esistevano versioni su TCP e TLS. Un log perso per strada non si recupera.
4. Scrivi conservazione e integrità: almeno sei mesi per gli access log degli amministratori, tempi legati alla valutazione del rischio per i soggetti NIS.
5. Decidi chi guarda, prima di comprare. Un SIEM che nessuno presidia di notte e nel fine settimana si ferma a metà. Le opzioni sono messe a confronto in SOC interno o gestito.

In sintesi

Il log management raccoglie, conserva e rende consultabili i log; il SIEM li usa per rilevare gli attacchi, correlando sorgenti diverse. Per gli access log degli amministratori di sistema chiesti dal Garante basta un log management con integrità e almeno sei mesi di conservazione. Per un soggetto NIS la misura PR.PS-04 è log management, la DE.CM-01 chiede il rilevamento tempestivo, e lì un archivio non basta più.

Se vuoi capire se i tuoi log oggi reggono quello che ti viene chiesto, o cosa manca per passare al rilevamento, parti dai nostri servizi di cybersecurity.